Walk through a code change without replacing formal review

A code walkthrough should help participants understand a changed behavior, not turn a confident explanation into approval. Read a small authorized diff together and connect each important branch to an input, output, and test. Keep the change unchanged during this session so questions do not disappear into unrelated live edits.

Define the behavioral contract first

Write what the helper promises before discussing implementation. Identify which promise changes and which should stay the same. Keep credentials, private data, and production settings out of the example. An accessible sanitized diff is enough for a comprehension exercise.

Fictional practice example: a retry helper permits at most three completed calls, including the initial call. Three retries after an initial call would be a different contract. The following model is invented for this exercise; it does not describe current Kiguri code or an API. Resolve the meaning of attempt before evaluating a comparison operator.

Trace the changed path

In the fictional model, the completed-call counter starts at zero. Before each call, the original guard allows counter less than or equal to the limit; the revised guard allows counter strictly less than the limit. After every completed call, increment the counter. Stop on success; otherwise return to the guard. When the limit ends the loop, report the last failure, or no attempt if no call ran.

Keep an annotated change map: code location, incoming state, branch condition, resulting state, and the question it answers. Distinguish unchanged initialization and increment behavior from the changed guard. Inspect surrounding code when it explains a dependency, rather than reading every line merely because it is nearby.

Work through three concrete cases

With limit three and continuing failures, the revised guard permits calls at counters zero, one, and two. Their completions leave counter three, which fails the next guard: three calls ran. The original guard still permits a call at three, producing a fourth failure before stopping. Success on the second call stops both versions after two completed calls.

Also use an expressly fictional zero-allowed-calls fixture. The original guard permits one call at counter zero; the revised guard permits none and reports no attempt. This exposes the boundary without inventing a last error. Do not infer asynchronous timing from the model. Check when promises settle and what the actual code counts; record missing context instead of assuming it matches this sketch.

Connect tests to branches

For each supplied test, state its controlled input, asserted observation, and exercised branch. An early-success test may pass without reaching the attempt boundary. Ask what would change in the assertion if the original defect returned. For the fictional failure case, an assertion about completed-call count distinguishes four from three.

If test output is unavailable, label the test inspected rather than executed. Relevant test source is not a passing run. Keep timing, cancellation, and external-failure questions separate when the example cannot establish them. A walkthrough can reveal a coverage question without proving the patch correct.

Leave review questions with owners

Keep the annotated path, unresolved branches, and evidence needed for formal review. Name who will obtain missing context or run relevant checks through the established process. The conversation does not authorize merging, deploying, or modifying the system.

Ask another participant to trace the boundary without the author's narration. If they cannot locate the changed branch or connect it to an assertion, shared understanding remains incomplete. Preserve that gap as a review question rather than replacing it with a general vote of confidence.