Commit 42a0b60

- **The ship operation** (idempotent + crash-safe; implemented in FORGE-234 as the VERB-ONLY `forge orchestrate ship` — owner decision 2026-07-23: every step is deterministic git/gh/CLI work, no model worker exists for the ship phase; the verb finishes through the `complete --phase ship` choke point, which requires the pinned ship verdict + the fenced `ship_receipt.json` (attempt-scoped proof the operation ran: target SHA, admitted state version, probe disposition, PR identity) + a FRESH live PR-head read before `merge_pending` commits; SHIP policy failures — unsupported host, fork topology, PR conflict, probe failures — park durably via a `reviewed → blocked_on_question` question whose phase-aware answer resolves `retry_ship → reviewed` or cancels while blocked): (1) **write-ahead**: persist/refresh the durable **ship record** at `.forge/orchestrator/tasks/<task_id>/ship-record.json` (reviewed_head_sha, resolved base repo + base branch, then per-side-effect: PR id/URL, merge-attempt status) — the record is written **before** each external side effect and reconciled idempotently after it, so a crash between push, PR-create, and merge recovers via create-or-get; (2) re-run `settings.verify` in the task worktree; (3) verify the local head equals `reviewed_head_sha` — any post-review change (rebase-on-drift, `update-branch`, conflict resolution, third-party push) produces a new SHA that must re-enter verify + re-review before shipping proceeds (dual-host: cross-host review; single-host: CLI re-verification — §Single-host mode); (4) final secrets scan; (5) push; (6) create-or-get the PR via the RepoHost; (7) mark tracker `in_review`. **Forge creates NO standing auto-merge enablement** (`gh pr merge --auto`): GitHub's persisted auto-merge request cannot hold an expected head SHA, and GitHub auto-disables it only for pushes by users *without* write permission — a write-capable push after enablement could therefore merge unreviewed code. The merge is instead the atomic, head-bound step below.

The SHIP policy park (unsupported host, fork topology, PR conflict, honesty-probe

failure) writes a durable question and resolves it through the `answer` verb. Answer

selection and state resolution are **two independently serialized writes** — the answer

file's `wx` write is the single-writer reservation, and the state CAS is separately fenced.

That is sufficient for the sequential lifecycle and for competing supervisors (the durable

option always decides), but two narrow windows remain when a park races a *successor

attempt's* progress:

1. **Cancellation vs. successor lifecycle.** `cancel_task` is task-level and applies from

`blocked_on_question` or `reviewed`. If a superseding SHIP attempt has already moved the

task to `ready_for_review` (drift) or `merge_pending` before the operator answers, the

cancellation is published but cannot converge; the operator must use `forge orchestrate

cancel` directly.

2. **Orphan repair vs. resolved retry.** A SHIP invocation that snapshots an orphaned park

can commit its `reviewed → blocked_on_question` repair after a concurrent `retry_ship`

resolution reported "already applied", re-parking a task the operator just released.

Re-answering converges.

Neither window touches the merge path, the ship proof chain, or a normal ship: parks only

fire on repositories the orchestrator cannot legitimately ship to at all. Closing them

properly requires a **shared per-question transaction** covering answer selection and state

resolution together (rather than two serialized writes) — tracked as its own task so the

primitive gets a full design review.