Check reference

Review code changes against requirement intent

A code edit can change a requirement's meaning without changing its text. authored_delta_expected asks for a current impact review of the affected requirement and source artifact in source-native projects.

What the check observes

The review binds a requirement and traced non-test file to their current identities. Go source uses an authored-behavior fingerprint that ignores ordinary formatting and comments while retaining behavior and trace annotations; unsupported or unparseable inputs use content bytes. The requirement side uses a semantic fingerprint. Changing formal content can reopen a previously reviewed pair even when that file is untouched. Approval metadata alone does not invalidate the pair.

Example: an internal refactor of a retry helper

Illustrative case. A helper is extracted while the approved retry limit and timeout behavior stay the same. An unchanged-intent review is appropriate only after checking that claim against the requirement and relevant observations.

proof review impact SYS-REQ-042 \
  --decision no-authored-change \
  --reason "Extracted retry helper; retry count, deadline and failure result remain unchanged"

Resolve the finding

Inspect the code delta and the requirement it implements, including failure behavior and boundary cases.
If this is an internal refactor, record a substantive unchanged-intent impact review for the current artifacts under the project's review policy.
If behavior changed, handle the feature or defect explicitly. Update intent only through an authorized change, and refresh the evidence needed for that change.

Run and interpret

proof audit --check authored_delta_expected --verbose

This is an implementation-stage warning in the source-native workflow. Overlay-audit projects use their own overlay freshness controls. Audit defaults to failing on warnings unless configured otherwise.

A recorded review is an accountable assertion, not a proof of behavioral equivalence. This check does not execute regression tests. Description-only changes have their own review check, and feature or defect backing is a separate concern.

Continue from here

Record change evidence. Review description changes.

Bring one code delta whose effect on an existing promise is difficult to judge. Bring a change to Proof.