An agent's change can be partly useful and still need correction. This lesson teaches you to review each part against a brief, preserve the useful improvement, and reject an unrelated edit. We will work on a feature branch so that the proposal has a clear purpose and a clear relationship to the baseline.

Start from a clean CP01 practice checkout. Inspect Git status, the current branch, and recent history. If unexplained working edits exist, preserve and account for them first. A branch names a line of recorded development. It does not automatically hide or protect every uncommitted change already in the working tree.

Create the branch named feature slash report-origin using the command in the lesson. Confirm the resulting branch name. The name tells us what the task is about, but it does not enforce the scope. The brief and review will do that. If the branch already exists, inspect its state rather than inventing another near-identical name to get past an error.

Write a bounded request for a README clarification that the baseline uses synthetic input. Permit only the designated documentation paragraph. Preserve the host sample, firmware, dependencies, and build commands. Ask the agent to show the diff and distinguish checks actually run from proposed checks. This gives the resulting patch a concrete acceptance boundary.

Observe the actual agent actions. The assistant may produce exactly the requested change. If so, preserve that result honestly. We will not pretend it made a mistake for the camera. The course supplies a separate seeded review candidate that deliberately contains an unrelated edit so everyone can practice rejecting one. Keep the constructed-exercise label visible when using it.

The seeded candidate contains a useful README sentence and a change in the host baseline's fixed synthetic temperature from twenty-five to thirty. CP01 does not yet have a threshold policy or the later fixture parser. This is a sample-value change in the minimal host program. It is unrelated to a documentation-only request, even though the program may still compile and print valid-looking JSON.

Inspect the changed-file list before reading individual hunks. A README-only task touching host source deserves attention. Then read each hunk in context. Ask which requirement justifies it, what behavior it changes, and which check would reveal a mistake. The number of added lines is not a substitute for those questions.

Accept the origin clarification if it is accurate. Reject the host sample change because the brief preserves that value and supplies no reason to alter it. Your review note should name the file, the changed value, the consequence, and the requested correction. Keep the README sentence, restore the host sample to twenty-five, and rerun the applicable replay after correcting source.

This is a partial rejection, not a verdict that the entire answer is useless. Separating the two ideas preserves progress while keeping control of the engineering decision. A useful future idea can be written in a separate note, but it should not slip into the current task just because it appeared beside a correct edit.

Make the correction in the editor or through the documented exercise procedure. Inspect the diff again. If a file contains useful and unwanted changes, replacing the entire file from baseline may discard good work. Use the smallest understandable correction and verify its result. A blank diff achieved by removing every change would fail because the requested improvement would be gone.

Run the relevant baseline replay if source was touched. Check its actual output and exit result. The fixed sample should be restored and explicitly synthetic. This verifies the affected behavior in the host program; it does not establish physical operation. For the final pure documentation change, also read the paragraph in context and confirm its wording matches the evidence.

Stage and commit the reviewed candidate with a purpose-focused message. Push the feature branch to the verified private remote. Open a pull request with main as the base and your feature branch as the comparison. Inspect those branch selections before creation. A pull request aimed at the wrong base can show a confusing diff even when your local task is small.

Open Files changed and compare the hosted proposal with the final local diff. The intended README improvement should be present, and the unrelated host value should be unchanged. The review surface organizes discussion and checks; it is not an automatic certification of correctness. If you review your own practice proposal, call it a self-review rather than claiming another person approved it.

Write the description for someone who has not seen your conversation. Name the reporting ambiguity, the new explicit synthetic-origin wording, and the validation actually performed. Do not include abandoned suggestions unless they explain a relevant tradeoff. Do not list tests as passed if you only proposed running them. A concise, accurate description makes the reviewer’s next action clear.

For your exercise, submit the review note, corrected diff, applicable replay result, and private pull-request reference. If account access prevents the remote step, keep it pending while completing the local review. The local diff cannot serve as evidence that a pull request exists. Each action keeps its own observable result.

A review finding should survive being separated from the conversation. Include the relevant path, old and new value, requirement, and requested correction. Another contributor can then act on it without guessing what you meant by the extra change. When the correction arrives, inspect the new diff rather than approving it because the author says the issue is resolved. The evidence for resolution is the revised content and relevant check, not the acknowledgment.

You are ready to continue when the useful change remains, the unrelated edit is gone, and your evidence explains why. The next lesson introduces a deliberate text conflict and two different recovery operations. We will keep their starting states separate so that resolving meaning, discarding an unwanted working edit, and reversing a committed fault do not become one vague instruction to undo everything.