M08-L04 — Apply the workflow to your own project

Recording transcript

The workflow becomes yours when you can apply it to a small task outside the exact course sequence. In this lesson, you will complete one bounded transfer and evaluate the whole effort needed to reach a verified result. Use an appropriate local project or the supplied checkpoint-nine README clarification. You do not need a new framework, subscription, or board to finish this work.

Choose a task whose outcome you can observe. Examples include adding a missing error-path assertion, improving a reproducible setup step, or clarifying a report format. Avoid a broad goal such as modernize the entire project. A small task makes it easier to connect requirements, source changes, verification, and the effort you spend reviewing the result.

The supplied example asks you to clarify two different outcomes. A malformed fixture is rejected with a line-number diagnostic and exit two. A valid replay can intentionally produce fault and still exit zero. The README should explain that distinction without changing parser behavior or implying that a physical sensor failed. This is a complete maintenance task with a clear acceptance condition.

Write a brief before editing. Name the goal, starting source, relevant context, scope, and observable result. Preserve a baseline so you can compare changes and recover without erasing useful work. The brief should be understandable without the old conversation. If you use an agent, it supplies the current task while repository guidance and references supply maintained project context.

Read the format documentation and fixtures for the example task. Do not infer behavior from a vague memory of what a fault usually means. The project distinguishes input-file validity, policy state, and process result. Those definitions tell you what the paragraph needs to say and which commands can establish the distinction.

Make the bounded wording change and inspect the diff. The task does not require modifying the intentionally malformed fixture so every command succeeds. Removing the fault would weaken the demonstration. Preserve the relevant input and use its actual diagnostic as evidence for the explanation. A documentation repair should not silently change the software behavior it describes.

Run the relevant replay examples from the project root. Record actual commands, source identity, output, and process results. If an environment issue prevents execution, state the limitation. A supplied expected result is useful guidance, but it is not a receipt from your run. Keep the evidence's synthetic origin visible throughout the explanation.

Now examine effort. Generation or typing time is only part of verified delivery. Include preparation, editing or generation, review, diagnosis and repair, verification, and waiting. A response that arrives quickly can still require substantial work before it is correct and understandable. A slower first pass may reduce later repair. Measure the end point that actually matters to your project.

Separate active effort from waiting. Active effort is time you spend preparing, reading, editing, reviewing, or checking. Waiting may include model response, compilation, downloads, or account limits. These categories can move in different directions. Recording both gives a more useful picture than one unexplained number called time saved.

If you compare manual and AI-assisted approaches, use separate identical starting copies and common acceptance criteria. Do not give one a complete source pack and the other an ambiguous prompt without recording that difference. Preserve both artifacts and their review outcomes. A single task can reveal useful information, but it does not establish a permanent ranking of tools or models.

Leave unmeasured fields unmeasured. Do not fill a timing table with plausible numbers because it looks unfinished. You can report a qualitative observation and design a better measurement next time. The same rule applies to learner feedback: your own review or an agent walkthrough is not evidence that another person tested the instructions.

Build a small maintenance table for the result. Name the source or tool, its current recorded version, the trigger for review, and the relevant check. A compiler update calls for build and behavior evidence. A skill-description change calls for relevant and unrelated selection cases. A repaired link calls for navigation and rendered-content review. The check should match what changed.

Keep a working baseline before updates. Use a separate branch or disposable copy, read current official guidance for the component being changed, and preserve the earlier result. If the update fails, record the demonstrated incompatibility and return to the known state in that exercise environment. Rollback should not erase the evidence explaining why the update was rejected.

Record conditions that can affect a comparison. A first build may spend time creating output that a later run can reuse. One task may begin with a source already open while another includes searching for it. These are not reasons to abandon measurement; they are reasons to describe the starting conditions. When possible, alternate approach order across repeated tasks and keep the completion criteria fixed.

For a different board, transfer the workflow before copying hardware facts. Re-establish the exact product, sources, target options, and any physical interface assumptions. Hardware-independent policy may remain useful if its requirements still apply. Pin mappings and power aliases should not travel merely because the processor family is familiar. Compilation on the new target still has a separate physical-evidence boundary.

Your exercise submission contains the brief, artifact, diff, actual results, effort record, and a three-item maintenance plan. Finish with a concise handoff naming the completed task and its evidence, or the exact remaining question. A successful transfer is one you can explain and verify. It does not become more advanced simply because it involves more tools.

Pause here to complete the task. When reviewing it, ask whether another session could understand the result without your conversation and repeat the relevant check. Then explain one thing you learned about total effort, including review and repair. This makes the workflow adaptable: it helps you choose where an assistant is useful while retaining responsibility for the evidence and the decisions that turn output into engineering work.

Download transcript