Receiving Hack Review

Treat hack-risk findings as claims about ownership and implementation liabilities. Verify the current invariant owner before changing a workaround, fallback, or competing abstraction.

Skill Boundary

• Use hack-review to create or refresh the report.
• Use receiving-hack-review to consume the report and decide what to do next.
• Use regression-review instead when the concern is user-visible behavior rather than implementation shortcuts.
• Use receiving-code-review instead when the feedback is general code review rather than a hack-risk 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.