Skip to main content

Pre-Semester Exam: Foundation Systems Assessment

Demonstrate study, file/editor, shell and Git skills already taught in Launchpad. No algorithms, recursion, statistics, Python programming or public contribution is required. Use a disposable folder and repository, never the only copy of real coursework.

Planning allowance: two active hours: A 30 minutes, B 45, C 30, D 15. These are estimates, not speed gates. Split sessions and use accessibility tools as needed. Command documentation and your setup instructions are allowed. Preserve an initial independent explanation before consulting notes for A3. Generated solutions and supplied answer keys cannot count as independent assessment; record assistance and use a fresh variant after solution exposure.

Setup and scoring​

Prepare the small fixtures below before timing. Charge this preparation to the existing 4–7-hour project assembly/clean-setup allowance, not an uncounted extra session. Creating the given files is setup, not an answer. A peer may prepare them; self-preparation is valid when labeled. No hidden instructor-provided files or accounts are assumed.

Each part scores 0–100. Task weights within A are 40/30/30; B 30/25/20/25; C 25/25/25/25. Each task has four criteria: award 0 for missing/incorrect, 1 for partial, or 2 for correct and independently explained. Task percentage = earned points ÷ 8 × 100; take the weighted task average for the part. D has four criteria scored the same way. Preserve criterion scores and reasoning. Compare unrounded percentages with the floors; rounding is for display only.

Overall = 0.25×A + 0.35×B + 0.25×C + 0.15×D. Require 75% overall and at least 70% in every part, plus the separate workload/progression gates. A high average cannot compensate for a missing readiness, recovery, Git or preparation-module outcome. Repair failed criteria on a fresh case rather than repeating every task.

Part A — Apply and inspect a study process​

A1 — Learn a bounded new passage (40% of A)​

Read this original source card:

An archive groups files into one container. Compression may reduce the space used, but an archive is not necessarily compressed. Creating an archive does not prove that all intended files were included. Reopen or extract a copy and compare its contents with the intended list before relying on it.

Use your study method, close the card, then explain it. Four criteria: (1) distinguish grouping from compression; (2) explain why archive creation alone does not prove completeness; (3) give a new example with a missing file and a suitable check; (4) record the attempt, source correction and next practice step. No particular note format is required. An unfamiliar term can be looked up and that assistance recorded.

A2 — Resume after an interruption (30% of A)​

Use a disposable copy of your setup README. Before pausing, leave a resume note with the current file, last verified step and next action. Pause naturally or simulate a task switch without noise or forced distraction; then resume and verify the intended step.

Four criteria: (1) a usable state/location note; (2) a safe resumption from that state; (3) an observed check rather than a claim of focus; (4) a realistic adjustment if the original block is no longer available. Assess the method, not sensory tolerance or recovery speed. Label simulated interruptions.

A3 — Retrieve and connect (30% of A)​

First answer without your notes; then check and correct. Four criteria: (1) distinguish a goal from a study process using your example; (2) explain a saved file versus unsaved editor state; (3) explain a Git working tree, staging area and commit in one change; (4) identify one weak explanation and a specific repair. A claimed perfect streak is not evidence of learning.

Part B — Work with files, text and the environment​

B1 — Organize without losing information (30% of B)​

Inside a new scratch folder create inbox with these files: plan.txt containing Practice files, notes.txt containing Copies need checks, session.log containing status=done topic=files, and draft.tmp containing Disposable draft. Inventory all four paths and contents before making changes.

Use shell commands to create notes and logs inside the scratch folder. Move the two text files to notes and the log to logs; leave the draft in inbox. Four criteria: (1) quote/identify the intended paths; (2) complete the requested organization; (3) confirm all four contents survive; (4) explain how to undo the moves. GUI use is allowed for inspection; nobody must prove a shell is faster than their GUI.

B2 — Inspect and filter text (25% of B)​

Create sessions.log with exactly these four lines:

status=done topic=files
status=paused topic=git
status=done topic=reading
status=done topic=files

Use the taught shell text tools to select only lines beginning status=done , count matching records, and list distinct completed topic names. Keep duplicate records in the count. Four criteria: (1) correct matching records; (2) correct count; (3) distinct topic output; (4) explain the pipeline and demonstrate that the original file was not overwritten. No mean, standard deviation or program is needed.

B3 — Make and inspect an editor change (20% of B)​

Create setup-note.txt containing two lines: Open the practice folder. and Save the practice note. Change both occurrences of practice to study, then add Check the saved copy. on a third line. Four criteria: (1) use a search/navigation feature; (2) make both intended replacements without unrelated changes; (3) save and reopen the correct file; (4) show the before/after difference and explain an undo method. Use your preferred editor and access method, not a required shortcut sequence.

B4 — Diagnose the wrong location (25% of B)​

Create draft/setup.txt containing Version: draft and ready/setup.txt containing Version: checked. The reported problem is “I opened setup.txt and saw the draft even though the checked version exists.”

Four criteria: (1) state two plausible explanations before acting; (2) inspect the actual path and content; (3) open the intended checked version without deleting either copy; (4) write a focused help/repair note with evidence and a limitation. Do not damage your real shell configuration to simulate a fault.

Part C — Version, review and recover​

Use a fresh local practice repository. Git author identity can be configured for this repository only; use a non-sensitive example identity if publishing is not intended. No remote service, public profile or outside maintainer is required.

C1 — Establish a reviewable baseline (25% of C)​

Create and commit a README describing the practice artifact, including the sentence We tested a same-device copy., and a .gitignore that excludes scratch.tmp. Create that ignored file to test the rule. Four criteria: (1) correct repository and baseline files; (2) an actual commit with an accurate message; (3) evidence that scratch.tmp is ignored rather than committed; (4) explain working/staged/committed state using status and history. Do not include secrets.

C2 — Integrate two conflicting edits (25% of C)​

Commit plan.txt containing Next: review files on the current base branch. From that baseline create practice-a, replace the line with Next: review paths, and commit. Return to the base branch, create practice-b, replace the same line with Next: review copies, and commit. Merge practice-a into practice-b and resolve the expected conflict by preserving both intended activities in clear wording.

Four criteria: (1) branches really diverge from the same baseline; (2) identify the conflicting versions; (3) resolve and complete integration without conflict markers or lost intent; (4) inspect the resulting content/history and explain why a conflict occurred. Use your actual base branch name; do not assume main or master.

C3 — Review a change (25% of C)​

On a new branch, make a proposal that changes the README claim from “tested a same-device copy” to “guaranteed recovery from any device failure.” Review that diff before accepting it.

Four criteria: (1) identify the unsupported guarantee; (2) write specific, respectful feedback tied to the tested failure boundary; (3) revise the wording and preserve before/after evidence; (4) label peer review versus self-review accurately. A local solo simulation satisfies this mechanics/preparation task; it does not establish human collaboration. A hosted pull request is optional.

C4 — Recover a committed edit (25% of C)​

Create and commit a disposable note with known content, then commit an unwanted edit to that tracked note, then recover its earlier content with an explained Git recovery operation. Four criteria: (1) identify the intended previous state; (2) explain the chosen operation and its effect on history/uncommitted work; (3) actually restore and inspect the content; (4) preserve evidence and finish with an understood repository status. A new revert commit is sufficient; no force push, history corruption or deletion of the repository is needed.

Part D — Assemble the handoff​

Use the artifacts above and existing preparation-module records to write a short handoff README. Four criteria: (1) state the next feasible learning task and schedule; (2) give paths and steps for inspecting the organized files and successful restore; (3) link Git/review evidence and explain one limitation; (4) link readiness, SS/R/C/S/DS/AL and Module 2/3 quiz/practical records, disclose assistance and identify any pending gate. Reuse records rather than repeating all five module assessments.

Calibration and next step​

Attempt before opening the task-specific answer key. Passing the exam alone does not authorize Semester 00 entry. Inspect the checkpoint, project and all readiness/preparation gates. If work is missing, record a targeted repair and reforecast the schedule; a fixed extra week is not guaranteed to be enough.