M04-L05 — Challenge: repair conflicting context
Repair a contradiction across current project documents and explain why the correction is justified. This module challenge combines readable Markdown, source identification, evidence classification, and bounded review. Use a new CP02 exercise copy so the deliberately wrong statement cannot contaminate your normal reference.
Seed this sentence in the exercise hardware note: “The selected Adafruit product 5477 has 8 MB flash.” In a separate exercise record, label the statement as an intentional fault. The challenge is to establish the correct claim from the applicable manufacturer source, then identify every current document that depends on it.
Open the exact product page and confirm the identifier. The documented example variant has 4 MB flash and 2 MB PSRAM. A family search can find an 8 MB/no-PSRAM sibling, which explains why a plausible stale note can be wrong. Resolve by identity and evidence, not by choosing whichever number appears most often in the repository.
Correct docs/hardware.md, then search the exercise documents for the product identifier and stale memory claim. Review each hit in context. An unrelated number or a dated historical result should not be globally replaced. Mark old guidance superseded when appropriate, and point it to the active hardware reference.
Follow the corrected links in the preview. Read the README and handoff as a new reader would. A correct central table is insufficient if the handoff still directs the next session to use the stale variant. Keep the correction small enough that the diff exposes the reasoning.
Write a short evidence note with the seeded claim, exact source and section, corrected claim, affected documents, and remaining unknowns. State that this is a documentation-based correction. It neither observes a physical board nor proves an upload. A screenshot of the diff can illustrate the repair, but the text and source should remain independently readable.
Use the module quiz after the challenge. A score of four out of five is the recommended self-check target; retry is encouraged. The quiz does not replace the practical evidence. Completion requires a coherent correction and an explanation that a reviewer can follow from claim to source to consequence.
Resources and completion
Use the Sensor Monitor CP02 download and its README.md; project paths in this lesson are relative to that root. Read Chapter 8–9 for the full lab and explanatory review answers. Figure IDs: SS09-04, SS08-03. Primary references: Adafruit product 5477 and GitHub Markdown tables. Complete the exercise, preserve actual evidence, and use the separate instructor answer key for self-check after attempting the task. Narration scripts are production sources; final transcripts must match the actual narrated edit.
Recording transcript
This challenge asks you to repair a contradiction that looks plausible. You will use the Markdown, source, and evidence habits from this module to correct a hardware note and find the current documents that depend on it. Start with a new checkpoint-two exercise folder. Keep your earlier work preserved so the deliberately wrong statement cannot become the active reference for another task.
The seeded sentence says that the selected Adafruit product five four seven seven has eight megabytes of flash. Put that sentence only in the exercise copy of the hardware note. In a separate exercise record, label it as an intentional fault. This label matters because an isolated wrong statement can later be copied into a handoff and mistaken for something an engineer verified.
Before correcting the number, decide what evidence would resolve the disagreement. A general web search for an ESP32-S3 board is not specific enough. A family name can lead to a sibling with different memory. We need the exact manufacturer's product page for the selected identifier. The task is to connect one claim to one applicable source, not to count how many search results repeat each number.
Open the product page and confirm the identity before reading its memory description. For the selected example, the documented configuration is four megabytes of flash and two megabytes of PSRAM. A related eight-megabyte variant exists, which makes the wrong note believable. The distinction is resolved by the product identifier and source, not by familiarity with the processor family.
Now correct the active hardware reference. Preserve the unit and identify the relevant source section. Add the access date for your check, and do not confuse that date with a product revision. The corrected row should explain its consequence for this project: the selected build configuration must match the documented example variant. It should also preserve the fact that no physical board revision was inspected in this exercise.
We are not finished when the central table is correct. Search the exercise documents for the product identifier and the stale eight-megabyte claim. Read each result in context. The README or handoff may still direct a future session to use the wrong variant. A useful repair updates current guidance that depends on the fact, while keeping historical records clearly scoped.
Do not perform a blind global replacement. Another document might describe a different product, or a dated result might accurately record an older configuration. Changing every occurrence of a number would destroy meaning. Decide whether each hit is active guidance, unrelated content, or history. If an old instruction is superseded, mark that relationship and link it to the current reference.
Inspect the dependency record before changing any build setting. A stale prose sentence does not prove that the maintained wrapper is wrong. The canonical target may already be correct. This distinction keeps the repair bounded. We want the diff to expose the actual problem and correction, rather than mixing them with unneeded source or configuration edits.
Next, open the Markdown preview and follow the hardware link from the README. Verify the file and section you reach. Return and read the handoff as a new session would. If it contains a contradictory summary, the project still has conflicting context. A link that resolves technically can still be misleading when its label or surrounding sentence implies the wrong source.
Write the correction note. Include the seeded claim, exact source, relevant location, corrected claim, affected current documents, and remaining unknowns. Explain that the error came from confusing variants. Keep the note short enough that another reviewer can trace the reasoning without reading the old conversation. The source supports the identity; your note explains why the project changed.
Be precise about evidence. This is a documentation-based correction. It does not establish that a physical board was connected, that a build ran, or that firmware was uploaded. If you perform an additional software check, record it separately with its actual command and result. A screenshot of the corrected diff illustrates the edit, but it is not evidence of an operation that never occurred.
You can pause now and complete the challenge. Use the separate exercise and answer key after your own attempt. Submit the corrected hardware reference, updated current links or handoff, reviewed diff, and source note. Name one claim that remains unverified physically. Preserve your starting copy so you can compare or restart without deleting useful work.
When reviewing the answer, look for four qualities. The source must identify the exact product. The correction must preserve the correct memory configuration and units. Current dependent guidance must agree. The evidence note must avoid claiming a physical observation. Different wording can satisfy those criteria. A polished page that still contains an unsupported pin mapping cannot pass simply because its main memory row is correct.
If the source cannot be opened, record the access limitation. You can inspect the release's supplied source notes and continue organizing the correction, but distinguish that from your own live verification. An unavailable page is a real limitation, not permission to invent a citation. The next action should name the exact missing check so another session can finish it without repeating the whole investigation.
This challenge demonstrates why a small knowledge base needs maintenance. A stale fact can survive in a handoff even after the main table is corrected. Naming a source of truth, checking dependent context, and preserving history with clear scope prevent that error from quietly reappearing. The same approach applies to a library version, a timer assumption, or a changed requirement in your own project.
Finish with the module quiz and read the explanations for any missed answers. Four correct answers out of five is the recommended self-check target, and retry is welcome. Quiz progress is separate from the practical artifact. What matters in the challenge is that you can defend the correction from source to claim to consequence, while stating exactly what the available evidence does and does not establish.
Download transcript
