Receiving Regression Review

Treat regression findings as claims about user-visible outcomes. Verify the current path and product intent before restoring older behavior; a behavior-graph delta is supporting evidence, not an edit instruction.

Skill Boundary

• Use regression-review to create or refresh the report.
• Use receiving-regression-review to consume the report and decide what to do next.
• Use receiving-code-review instead when the feedback is general code review rather than a user-visible regression gate.

Scope and Authorization

• Resolve the source, selected items, and requested outcome from the whole current conversation. A feedback assessment or review-only request ends with dispositions; implement only when the user has authorized fixes.
• When review and repair are already requested together, continue after the source report is complete. A phase change or a pre-edit plan does not require the user to repeat that authorization.
• Keep the source artifact unchanged. Record current evidence and dispositions in a concise final ledger or a separate resolution report; a report's recommendation is not permission to edit.
• Preserve unrelated work and pre-existing staged contents. Leave fixes unstaged unless the user has already authorized the specific staging, commit, or publication action for this task; repair permission alone does not include those actions.
• Do not stage to make a follow-up review easier. Verify working-tree fixes against the recorded baseline and disclose that the staged snapshot may still contain the original issue. Avoid tools with unrequested staging side effects; if the index is accidentally changed, restore only the known workflow delta without disturbing user work and disclose it.

Workflow