Ship

Ship closes the authorized local outcome and performs only the publication actions you actually granted. It's the shortest phase in Forge and the one with the most explicit limits, because this is where an agent that guesses causes real damage.

Who owns itCopy Anchor Link

Whoever was already responsible for the work. There's no mandatory Ship agent, and Ship reuses that owner for the current-evidence checks, the closure, and the authorized publication.

What it starts fromCopy Anchor Link

The exact Review-passed and Acceptance-passed candidate, the comparison base, the retained accepted baseline and approved change, the current canonical files, any applicable Spec-apply receipts, and your explicit external-action authority.

What proof it needsCopy Anchor Link

Before closure, Ship checks once that:

• the candidate and base still match Review and Acceptance;
• the required scenarios, NFRs, preserved obligations, and visual acceptance passed or carry explicit blocking gaps;
• the selected authority, runtime inputs, canonical files, and applicable receipt hashes still match the reviewed candidate; and
• each requested PR, merge, deployment, release, document publication, or other external action is explicitly authorized.

That's a freshness check, not a second review. Before publication, Ship runs Finish when approved Spec or knowledge meaning remains unapplied, or existing PR readiness needs reconciliation. Finish uses the guarded memory operation and records what was applied, skipped, and persisted. An exact inspected canonical-only delta from Finish does not by itself stale the implementation Review or Acceptance; code, runtime, test, configuration, uninspected canonical, or additional meaning changes return to the affected boundary. Structural checks, receipt matching, and a clean tree don't replace Review or Acceptance.

For an existing operation ID, Ship inspects its retained receipt and the current result hashes. Matching bytes are already applied, so it doesn't replay writes or invent another operation ID. Diverged bytes, malformed provenance, a missing Review or Acceptance reference, or a changed authority or runtime input stop the affected claim and name the owner who has to resolve it.

What it producesCopy Anchor Link

One concise ship.md closure recording the accepted candidate, the current candidate, the comparison base, the Review and Acceptance references, any Spec-apply receipts, the publication actions performed, and the limits. The accepted and final candidates are normally identical. Publication facts belong in that closure, so a deployment timestamp doesn't trigger a canonical status edit or another review loop.

If an authorized merge or rebase changes only Git identity, the historical verdicts stay under their original candidate, the exact old-to-new relationship is recorded, and Ship judges which proof still applies. An old verdict never gets relabelled. If the source, runtime input, authority, canonical meaning, or accepted behavior changed, the affected work routes back to Build, Review, or Acceptance before closure.

Where it stopsCopy Anchor Link

Ship stops at the authority you granted and goes no further. It uses READY_FOR_USER for an ungranted external action or an unresolved human-owned question of meaning.

What it doesn't authorizeCopy Anchor Link

Ship never implies merge, deployment, release, or publication authority you didn't grant. A PR request doesn't imply merge, and a merge request doesn't imply a production release. Mechanical freshness success proves neither semantic fidelity, nor Acceptance, nor deployment, nor publication.