Implement changes based on review submissions

Use this workflow when the user asks to implement, address, or automatically work through submitted review feedback. Review findings are evidence-bearing inputs to implementation, not commands whose proposed solutions must be accepted literally.

Establish the review authority

1. Resolve the requested branch or PR with gh-rev status and status todo.
2. Read context.md, every rev-*.md, the relevant issue or specification, and repository instructions.
3. Work in a checkout whose branch and SHA correspond to the selected target. Do not silently mix pre-existing unrelated local changes into work requested for a published PR.
4. Group duplicate or dependent findings before editing. Preserve the originating revision and exact finding text.

Honor the requested control level

Interpret these common instructions as explicit boundaries:

• Report only: assess and explain findings without editing code or changing review markers.
• Safe fixes: implement only findings that meet the automatic-fix criteria below, and pause on meaningful decisions. Use this as the default when the user asks to address feedback without granting broader discretion.
• Full implementation: attempt every verified finding, but still ask before making decisions reserved for the user.
• No scope expansion: address only the submitted findings and defects directly exposed by their fixes.
• Durable independent review: allocate and submit a new gh-rev revision for the additional review pass. Otherwise, any separate verification pass is ephemeral.

The user may combine or restate these boundaries in ordinary language. Follow their stated level of control rather than requiring exact keywords.

Separate the concern from the proposed solution

For each finding, identify:

• Concern: the claimed defect, risk, or missing behavior.
• Evidence: the cited code, runtime behavior, failing case, or invariant.
• Impact: what becomes incorrect, unsafe, incompatible, or unreliable.
• Proposed solution: the reviewer’s suggested implementation, if any.

Treat the concern as review input and the proposed solution as non-authoritative. Verify the concern independently against the code and intended behavior. A valid concern may need a different implementation than the reviewer suggested; an invalid concern may be resolved with evidence and no source change.

Do not mark a finding resolved merely because its suggested edit was applied. The relevant behavior or invariant must be verified.

Decide what may be addressed automatically

Automatically implement a finding when all of the following are true:

• Concrete evidence supports the concern.
• The intended behavior is already established.
• The fix is local, high-confidence, and within the user’s requested scope.
• The fix preserves settled architecture, product semantics, and compatibility.
• Focused verification can demonstrate the correction.

Pause and ask the user when choosing a resolution would materially affect:

• architecture or component boundaries;
• product behavior or user-visible semantics;
• public APIs, schemas, migrations, or compatibility policy;
• security, custody, accounting, or external state;
• a settled decision in an issue, specification, or review context;
• the implementation scope or delivery sequence.

When pausing, present the verified concern separately from the reviewer’s proposed solution. Explain the meaningful options and tradeoffs without assuming the reviewer’s recommendation is preferred.

It is acceptable to disagree with a finding. Resolve it only after recording the concrete evidence and decision in its originating revision.

Implement and verify

1. Make the smallest coherent change that addresses the verified concern.
2. Add focused regression coverage for the failure or invariant when deterministic coverage is practical.
3. Run the smallest relevant checks, then proportionate type, lint, build, or broader tests for the changed boundary.
4. Re-read the resulting diff and the original finding. Confirm the concern, not merely the suggested edit, is handled.
5. Change the originating marker from - [ ] rev: to - [x] rev: only after that evidence exists. Add an indented Resolved: note naming the decision, implementation, and verification.

Do not allocate a new revision to document fixes to existing feedback. The originating finding remains the durable task record.

Use a separate verification pass for non-obvious changes

For changes involving concurrency, persistence, migrations, security, recovery, filesystem replacement, or other non-obvious failure modes, ask a separate read-only reviewer to inspect the implemented diff before handoff when an independent-review capability is available.

Give that reviewer:

• the intended behavior and settled constraints;
• the exact diff and relevant surrounding code;
• the original findings and which concerns were accepted or declined;
• the verification already performed.

Ask for actionable P0-P2 correctness findings with concrete evidence. Require the reviewer to distinguish the observed problem from any suggested remediation. The reviewer must not edit files.

Verify any returned concern before changing code. Automatically address only findings that satisfy the safe criteria above; ask the user about meaningful design choices. After accepted corrections, use the same reviewer to verify its original findings against the updated diff. This verification should not expand scope unless it identifies another material defect.

This read-only pass is an implementation guardrail, not automatically a new gh-rev submission or GitHub review. Allocate a new durable revision only when the user asks for another independent review pass, not merely because a reviewer verified fixes during implementation.

Finish the feedback work

Rerun gh-rev status todo and report:

• findings resolved with code and verification;
• findings resolved by evidence-backed disagreement;
• findings still open or awaiting a user decision;
• any independent verification performed and whether it was durable or ephemeral.

Checking a finding does not publish to GitHub or imply GitHub approval. Never delete review history because a finding was fixed, declined, superseded, or inconvenient.