feature-verify (Phase 5)

An honest AC-by-AC gap report, using the real diff and real test results as evidence. Read-only.

Invoke: /feature-verify AB#1234 · Side effects: read-only · Writes: .shipflow/{id}/verify-report.md

The verdict the rest of the flow (and you) rely on. If the work isn’t ready, this is where that gets said — never glossed over to keep the flow moving.

Grading each acceptance criterion

Status	Meaning
MET	Implemented, and covered by a passing test — cited by code path and test name.
PARTIAL	Partly implemented, or implemented but not adequately tested.
MISSING	Not implemented, or the test doesn’t actually check the criterion.

“Looks fine” is not evidence — every grade cites a concrete file/function and test. Polyrepo: an AC needing work in two repos is MET only when both satisfy their part; a gap in either makes it PARTIAL.

Non-negotiables count too

product.md’s non-negotiables are graded the same way, as implicit acceptance criteria — a violated one forces NOT READY regardless of the work item’s own ACs.

Also checks

• Scope creep — any change mapping to no AC gets flagged (some is legitimate refactor per the plan; some should be its own work item) — surfaced for you to judge, not auto-resolved.
• Linking — the work-item reference must be present per linking.place_in, in every touched repo in polyrepo. Unplaceable is a blocker, not a footnote.

Verdict

READY only when every AC and non-negotiable is MET, linking is placed everywhere required, and tests are green everywhere. Otherwise NOT READY — and the flow does not proceed to feature-pr on its own. This phase is gated (governance.gates.after_verify): you approve the report before any PR opens.