phoenix-ship

# phoenix-ship — declare done only on green evidence ## Overview This is the last line of defense against shipping silently-broken work. "Done" is not a feeling or a diff that looks right — it is a green `phoenix_sense` on the acceptance check plus an intact trace that proves the green is real. Phoenix exists to prevent exactly one failure: an agent confidently saying "done" on work that doesn't actually work. This skill is where that promise is kept. ## When to use - The final step of any task, right before you tell the user it's complete or merge. - Whenever you're about to type "done", "fixed", "ready", or "shipped". ## The ship gate ``` About to say "done" │ ▼ 1. phoenix_sense(acceptance_check) ──► must be ok:true │ │ red? ▼ ▼ 2. phoenix_verify_trace ──► STOP. Not done. → phoenix-debug │ ok + intact chain? ▼ 3. Report WITH evidence (check + trace head hash) │ ▼ DONE (provably) ``` ### 1. Final acceptance sense `phoenix_sense(acceptance_check)` from the Intent Contract (`phoenix-think`). Green is mandatory. Not "the test I added" — the **acceptance** check that represents the user's actual definition of success. ### 2. Verify the trace `phoenix_verify_trace` → `ok:true` with an intact hash chain. This proves the green you're about to report is genuine and wasn't reached by skipping or editing a gate. A broken chain means you are **not** done, no matter how the code looks. ### 3. Report with the evidence attached State the check that passed and the trace head hash, so the claim is auditable: > "Done — `pytest -q` exits 0 (acceptance check); trace verified, 14 rows, head `9885e6df…`." That one line is the difference between a trustworthy completion and a hopeful one. ## The rule that is the whole point **Never type "done" without a green `phoenix_sense`.** If the check is red or the trace is broken, you are not done — say exactly what is failing and route to `phoenix-debug`. "I'm not sure it passed" is an acceptable, honest status; a fabricated completion is the cardinal failure this entire harness exists to prevent. ## Common Rationalizations | Rationalization | Reality | |---|---| | "It's obviously done, I'll just say so." | "Obviously done" with no green check is exactly the silent failure Phoenix measured at 40% on real tasks. Run the check. | | "The new test passed, that's enough." | The new test ≠ the acceptance criteria. Sense the *acceptance* check; that's the user's definition of done. | | "I'll skip the trace check, it's fine." | The trace is your proof the gate wasn't skipped. It's one call and it's what makes "done" auditable. | | "Close enough, I'll note the caveat." | If there's a real caveat, the work isn't shipped — it's shipped-with-a-known-bug. Say that plainly, don't bury it. | ## Red Flags - Typing "done"/"fixed"/"ready" with no green `phoenix_sense` in this session. → Run the acceptance check now. - Reporting success without the trace verified. → Verify it; unverified green is just a hope. - Reporting the new test instead of the acceptance check. → Sense the acceptance gate. - A known issue you're shipping quietly. → Surface it explicitly; never bury a caveat in optimism. ## Done means Acceptance check green + trace verified + evidence reported. Anything less is "in progress", and saying otherwise is the one thing Phoenix forbids.