M03-L05 — Challenge: recover known-good work
Outcome: Restore intended behavior while retaining useful work and a traceable history.
Start: M03-L01–04; supplied history bundle, working toolchain, and preserved practice project.
The challenge combines reproduction, review, and recovery. You receive a prepared fault checkpoint and a useful documentation idea. Your task is to return software to its known-good behavior, preserve the useful note, and produce a short evidence handoff. Do not solve the challenge by deleting the project or replacing shared history without understanding it.
Clone the generic history bundle into a new folder. Create a branch from FAULT-hysteresis, inspect the isolated bad commit, and reproduce its boundary failure. Preserve a useful README clarification in a separate reviewed commit after the recovery so its purpose remains clear. Use the exact fault procedure from Chapter 7; this later checkpoint is a supplied recovery fixture, not a new feature assignment.
Before choosing an operation, distinguish dirty working content, staged content, and committed history. If you have useful uncommitted wording, save it explicitly before a destructive file restore. Revert the isolated fault to retain history, then apply and review the useful README note. Run native tests and the target cross-build from the documented root.
Finish by reproducing the corrected committed source in another checkout where feasible through your private practice remote or a local branch clone. Record which path you used. A same-machine reproduction reuses installed dependencies and does not prove fresh-machine setup. The output remains synthetic/software evidence.
Your handoff should let another session find the current commit, changes made, actual checks, remaining limits, and next action. A claim that tests passed without a command/result record is incomplete. A clean diff achieved by discarding useful work is also incomplete. The success condition includes preservation as well as recovery.
Practice and completion
Complete the exercise, then compare your artifact with the separately distributed instructor answer. A lesson acknowledgment records your own progress; it does not certify that a physical test occurred.
Chapter 6, Chapter 7. Resources: Exact recovery sequence. Figure references: SS06-06; SS07-02–06.
Recording transcript
This challenge asks you to recover known-good work while preserving a useful improvement. It combines the GitHub and recovery habits from this module. Your result is a small handoff packet with a clear history and actual software evidence. The goal is not simply to make the terminal stop showing an error or to return the folder to any state that looks familiar.
Use a new clone of the supplied generic history bundle. Keep your earlier practice project intact. Create a branch from the prepared FAULT-hysteresis checkpoint and inspect the current commit. The history is manufactured for instruction, with an isolated bad comparison at its tip. That controlled setup lets you practice recovery without guessing which of many unrelated commits introduced a problem.
Write down the current folder, branch, and commit before running a test. Read the supplied failure description. The defect concerns clearing at exactly twenty-seven degrees Celsius: the strict comparison misses equality. This is a prepared later-policy example, not a request to develop the capstone in this module. The expected case is provided so you can judge the recovery independently.
Run the native test command from the documented root and preserve its real output. Confirm that the failure matches the supplied boundary problem. If the executable does not start or the compiler is missing, diagnose that setup issue separately. Do not claim the policy fault was reproduced when the program never reached its test cases.
Now identify the useful documentation improvement you want to keep. It might be a clearer sentence stating that all replay inputs are synthetic. Do not mix that improvement into the fault reversal before you understand the starting state. The challenge is easier to review when the corrective history and the new wording have distinct purposes.
Inspect Git status and both relevant diff views. If useful uncommitted text already exists, preserve it deliberately before any operation that might discard working content. For this prepared exercise, save the useful text in a separate scratch note outside the recovery copy, so the isolated fault remains at HEAD. Confirm the saved text is recoverable before continuing. A new preservation commit would move HEAD and require identifying the original fault commit explicitly before reverting it.
Choose the operation that matches the state. An unwanted working edit can be restored when you intend to discard it. An unwanted staged selection can be unstaged while keeping the file. An isolated committed fault can be reverted with a new corrective commit. These are different tasks, and the command options should follow your intended data change.
For the prepared fault, verify HEAD once more and create the revert. Inspect the new history. The bad commit should remain, followed by its reversal. You have not rewritten shared history or pretended the error never happened. Another reader can follow the problem and correction as explicit events.
Rerun the same native test command. The expected result is that the previously failing boundary now passes along with the other relevant checks. Save the actual result and source version. Then run the firmware cross-build using the matching target configuration. A host test and target build exercise different paths, so each needs its own result rather than borrowing confidence from the other.
Apply the useful README clarification after the recovery and inspect its diff. Preserve the original technical meaning and keep synthetic labeling explicit. If the note changes a build command, execute that command from the written context. If it changes only an explanatory sentence, a careful content review may be enough. Verification should match the claim instead of repeating a ritual unrelated to the change.
Commit the reviewed improvement with a descriptive message. Inspect the resulting history and status. The final packet should show an understandable progression: known fault, recorded reversal, and a useful documentation change. A single broad cleanup commit would make it harder to see what restored behavior and what improved the explanation.
Now reproduce the corrected committed source in another checkout. You may use your private practice remote when its access is available, or a clearly identified local clone of the corrected branch for source reproduction. Record the actual path. A local clone does not prove GitHub transport, and a remote push does not prove the second folder builds. Keep those observations separate.
Follow the second checkout's README and dependency record. Run the applicable native tests and cross-build from that root. This uses the already installed toolchain, so it checks source and instructions in the current environment rather than a completely fresh machine setup. If a required file was never committed, the reproduction may expose it. Correct the omission and repeat the affected check.
Write a concise handoff. Include the current commit, what changed, which commands ran, where their results are saved, known limitations, and the next action. Do not say tests passed without enough information to identify the run. Do not say the sensor works when the evidence is synthetic host behavior and cross-compilation. Precise scope makes the handoff more useful, not less complete.
Review the packet against the challenge rubric. Is the original failure visible? Was the right operation chosen? Does useful work remain? Can another person reproduce the final software checks? Are remote and physical claims accurate? Correct the missing artifact or affected check without redoing unrelated completed work.
Treat the handoff as a small interface for the next person. Put the current state first, followed by the evidence needed to trust it and the next concrete task. Keep historical diagnosis notes available through a link rather than making the reader reconstruct the present from a long chronology. A concise handoff can preserve considerable work when the original chat is unavailable, because it points directly to the source and results that govern the next decision.
Finish the module quiz after submitting the packet. You have now practiced a complete local-to-remote workflow with review and recovery. The next module gives the repository better written context: readable Markdown, sourced hardware facts, explicit decisions, and evidence records. Those documents will help both people and future agent sessions resume the project without depending on an old conversation.
Download transcript
