muse-crew 0.7.9 → 0.7.11

package/API.md

@@ -80,6 +80,16 @@ Atomically park a task for human attention: sets `state` to `parked`, writes the
 
 Returns `{ "ok": true, "task": {...}, "settled_sessions": <n> }` with the updated task record and the count of sessions settled (`0` when none were running).
 
+### `resolvepublishunknown`
+
+Recovery contract for publish attempts parked with an `unknown` outcome (2026-09-14): the rebuild trigger's child failed structured closeout and the in-flight-only build-state poll could not see the completed build, so the workflow parked fail-closed — but the edit may still have gone through. When a platform audit build completed inside the publish window (between the Integrate-completion event and the unknown-outcome park), this action routes the task to the parent's independent content verification WITHOUT re-issuing the edit and WITHOUT stamping provenance. The original unknown ledger entry and park event are preserved; the resolution is appended to the publish ledger (`outcome: "unknown-resolved"`) and to the event log, and a `publish: verification-requested <commit>` note is written so `scan-verification-pending` claims the task on the next tick. The parent's read-back ([publish verification](docs/publish-verification.md)) remains the real verification and can still fail terminally. Cases that stay parked with `{ "resolved": false, ... }`: task not parked, latest ledger outcome not `unknown`, no usable commit on the unknown entry, no audit build inside the publish window, unobservable publish window (missing Integrate-completion or park event), or an already-resolved attempt (idempotent).
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `task_id` | uuid | yes | Must be parked with a latest publish-ledger outcome of `unknown` |
+
+Returns `{ "resolved": true, "task_id", "commit", "evidence_dir", "audit_report_ok" }` on success, or `{ "resolved": false, "reason" }` when the recovery preconditions are not met.
+
 ---
 
 ## Sessions
@@ -477,21 +487,19 @@ Phases whose outcome drives control flow (Build, Review, QA, Reproduce, Integrat
 Artifact Publish passes only when the parent has verified content independently:
 
 1. The workflow carries the merged diff to the artifact builder, polls the
-   build to completion, triggers an independent `artifact_inspect` read-back
-   of the changed regions, and parks with
+   build to completion, and parks with
    `publish: verification-requested <commit>` — it never stamps provenance
    and never treats the builder's applied-changes report as verification.
    The applied report is derived from the carried diff and demonstrated an
    unreliable false-negative mode (2026-09-12: `applied:[]` for a diff the
-   builder had applied); it is logged as observation only. The read-back
-   request carries the observed builder build identifier (`build.agent_id`)
-   so the read-back can be correlated to the exact builder run that built
-   this attempt.
-2. The parent compares the read-back against the merged diff mechanically
-   (every added line present, every removed line absent), correlates the
-   builder build identifier, and stamps provenance via `set-provenance` only
-   on a match. A mismatch, a build-id mismatch, or an unobtainable read-back
-   never stamps; the task stays parked.
+   builder had applied); it is logged as observation only.
+2. The parent's verification protocol (docs/publish-verification.md) owns
+   the independent content confirmation. The independent read-back step is
+   currently unavailable: `artifact_inspect` was removed by the platform
+   (2026-09-14) and no agent-callable replacement exists (`artifact.inspect`
+   is malfunction diagnosis, not a read-back tool). Until a read-back path
+   exists, the parent cannot confirm content independently and the task
+   stays parked at `publish: verification-requested`.
 
 Verification fails closed. The loop never retries a verification and never
 issues a blind re-publish on an unknown outcome.

package/docs/guide.md

@@ -302,7 +302,7 @@ For tasks that change anything rendered and visible in the project's artifact ("
 
 ### Publish content verification
 
-The artifact builder's `applied` report is derived from the diff the workflow carries to it, so comparing the report to the diff is circular — canary run 8 (2026-09-11) stamped provenance on a hollow build and every phase went green. The workflow therefore never stamps provenance itself: after the build lands it triggers an independent `artifact_inspect` read-back of the changed regions and parks with `publish: verification-requested <commit> (build <agent_id|agent_id unobserved>)`. The parent compares the read-back against the merged diff and stamps provenance only on a match (parent-driven — see `docs/publish-verification.md`); the park message records the observed builder build identifier as `(build <agent_id|agent_id unobserved>)`, and the parent correlates the read-back's live build agent_id against it — a mismatch logs `publish: build-mismatch <commit> …`, stays parked, and is never stamped (parent-driven — see `docs/publish-verification.md` step 4b). QA's provenance check then enforces the stamp mechanically, so an unverified publish fails loudly in QA instead of passing silently.
+The artifact builder's `applied` report is derived from the diff the workflow carries to it, so comparing the report to the diff is circular — canary run 8 (2026-09-11) stamped provenance on a hollow build and every phase went green. The workflow therefore never stamps provenance itself: after the build lands it parks with `publish: verification-requested <commit> (build <agent_id|agent_id unobserved>)`. The parent protocol owns the independent content confirmation (parent-driven — see `docs/publish-verification.md`); the park message records the observed builder build identifier as `(build <agent_id|agent_id unobserved>)`, and the parent correlates the read-back's live build agent_id against it — a mismatch logs `publish: build-mismatch <commit> …`, stays parked, and is never stamped (parent-driven — see `docs/publish-verification.md` step 4b). The independent read-back step is currently unavailable: `artifact_inspect` was removed by the platform (2026-09-14) and no agent-callable replacement exists (`artifact.inspect` is malfunction diagnosis, not a read-back tool), so the parent cannot confirm content independently and tasks stay parked at verification-requested until a read-back path exists. QA's provenance check then enforces the stamp mechanically, so an unverified publish fails loudly in QA instead of passing silently.
 
 ## Identities
 
@@ -430,4 +430,4 @@ crew-release.sh current
 
 5. **No backoff on retry.** Failed phases retry on the next tick with no delay. The consecutive-failure cap (default 3, then park — see "Failure handling and retry") bounds the retries, but there's no exponential backoff between attempts.
 
-6. **QA is code-blind.** Hazel uses `artifact_inspect` for visual/functional testing. She cannot read source code — this is by design (context isolation), but it means QA catches only what's visible or inspectable through the artifact's public interface.
+6. **QA is code-blind.** Hazel never reads source code — this is by design (context isolation), so QA covers the mechanical checks only: data-level effects via the Crew API, the docs gate, and the provenance check. There is currently no agent-callable visual-inspection tool (`artifact_inspect` was removed by the platform 2026-09-14; `artifact.inspect` is malfunction diagnosis, not a substitute), so visual/functional inspection of rendered output is unavailable until a capture path exists (see `docs/visual-verdict.md`).

package/docs/ooda-report.md

@@ -0,0 +1,123 @@
+# OODA Report
+
+The experiential report produced by the Reproduce and QA phases' see-act loop
+(2026-09-14; hardened 2026-09-15). When an agent drives the browser one step
+at a time — observing each frame, deciding the next action — the complete
+record of that session is the **OODA report**: the ordered
+Observe/Orient/Decide/Act trace, the archived frames, and a machine-readable
+terminal verdict.
+
+## Location
+
+```
+$CREW_HOME/task-evidence/<taskId>/<phase>/
+  ooda-log.jsonl      # ordered step records (every attempt preserved)
+  verdict.json        # latest terminal verdict (what the workflow reads)
+  verdicts.jsonl      # append-only ledger: every attempt's verdict, never overwritten
+  001-shot-desktop.png
+  002-click-desktop.png
+  ...
+```
+
+`<phase>` is `repro` (bugfix Reproduce), `postchange` (standard QA, bugfix QA).
+
+## ooda-log.jsonl
+
+One JSON object per line, appended after every browser action via
+`lib/append-ooda-step.js`:
+
+```json
+{"step":1,"attempt":"1","action":"aria","args":{},"exit":0,"screenshot":null,"observation":"Login button found in header.","ts":"..."}
+{"step":2,"attempt":"1","action":"shot","args":{},"exit":0,"screenshot":"/abs/.../001-shot-desktop.png","observation":"Header renders, no console errors.","ts":"..."}
+```
+
+Schema: `step` (positive int), `attempt` (the attempt/run identity —
+`"1"`, `"2"` for successive QA loops, `"repro-1"` for a reproduce run),
+`action`, `args` (object), `exit` (the see-act exit code), `screenshot`
+(absolute path or null), `observation` (the agent's 1–2 sentences: what was
+seen and what it implies — this is the payload, not the filename), `ts`
+(optional, agent-supplied).
+
+**Attempts never overwrite.** Step numbers are strictly monotonic *per
+attempt*: an attempt's first step is 1 and each following step is exactly
+previous+1. A retry starts a NEW `--attempt` in the same log — it never
+renumbers or overwrites. A non-monotonic step, a gap, or a corrupt line fails
+loudly (exit 2) and appends nothing.
+
+**Actions** (2026-09-15): `aria|shot|click|scroll|type` (see-act driver) plus
+the image tools — `crop|zoom|label|nup` (`lib/edit-image.py`: pixel-exact
+crop, pixel-crisp zoom, caption bars, n-up grids) and `compose`
+(`lib/render-html.js`: Chromium-rendered HTML compositions — the reef-qa
+pattern, real typography and layout for before/after and annotated evidence).
+Every frame-producing action (`shot|crop|zoom|label|nup|compose`) requires
+`--screenshot`: the frame the agent looked at must be the frame it logs. A
+captured-but-unlogged frame is invisible to everyone after the agent.
+
+The writer validates and fails loudly (exit 2) on bad input. The agent never
+hand-writes JSON — it supplies fields as flags.
+
+## verdict.json and verdicts.jsonl
+
+Written at phase end via `lib/write-ooda-verdict.js --dir <phase-dir>
+--attempt <id> --verdict <PASS|FAIL|NOT_POSSIBLE>`:
+
+```json
+{
+  "verdict": "PASS",
+  "attempt": "1",
+  "summary": "Footer fix verified on desktop and mobile.",
+  "expected": "published N hr ago, no Last polled mislabel",
+  "actual": "published 6 hr ago on both viewports",
+  "missing_evidence": []
+}
+```
+
+`verdict` is `PASS`, `FAIL`, or `NOT_POSSIBLE`. `missing_evidence` lists what
+was not checked — an honest gap is recorded, never hidden. Unknown/
+inconclusive is neither PASS nor FAIL.
+
+Two records are written:
+
+- `verdict.json` — the LATEST verdict, what the workflow closeout reads.
+  Overwritten on each call.
+- `verdicts.jsonl` — the append-only ledger. One JSON line per verdict,
+  NEVER overwritten: `{seq, attempt, verdict, summary, expected, actual,
+  missing_evidence[], reason?, ts?}`. `seq` is assigned mechanically
+  (existing lines + 1). A QA retry that FAILs after an earlier PASS keeps
+  both — a later attempt can never silently erase an earlier verdict.
+
+## Screenshot archival
+
+`SEE_ACT_ARCHIVE_DIR=<phase-dir>` (set on every see-act invocation — shell env
+vars do not persist between the agent's commands) funnels every screenshot
+into the phase dir automatically:
+
+- `--out` becomes optional; the archived path is the durable record.
+- Sequential names: `001-shot-desktop.png`, `002-click-mobile.png`, ...
+  (counter in `<dir>/.seq` — stable across the driver's one-process-per-invocation shape).
+- The JSON response carries `screenshot` (what to READ) and `archived` (the durable copy).
+- Explicit `--out` + archive: the file is captured to `--out` AND copied into the archive.
+- An unusable archive dir is `NOT POSSIBLE` (exit 3) — lost evidence fails loudly, never silently.
+
+No frame can be lost: Reproduce, QA, and exploratory hunting all funnel through
+the same wrapper.
+
+## Workflow integration
+
+- **Standard QA** (artifact): archive to `task-evidence/<task>/postchange/`,
+  bounded at 8 steps, logs every step, writes verdict.
+- **Bugfix Reproduce**: archive to `task-evidence/<task>/repro/`, bounded at 8
+  steps, logs every step, writes verdict (the bug is confirmed or not).
+- **Bugfix QA**: archive to `task-evidence/<task>/postchange/`, bounded at 8
+  steps, re-runs the reproduction steps plus surrounding views, logs every
+  step, writes verdict.
+
+No nested agents — the depth-1 work agent runs the browser steps itself.
+
+## Reading a report
+
+1. Read `verdict.json` for the terminal claim.
+2. Read `ooda-log.jsonl` for the ordered trace — each observation next to its frame.
+3. Open the archived PNGs and compare against the written observations. Never trust prose alone.
+
+The report is the evidence. A QA claim without its OODA report is an unverified claim.

package/docs/publish-verification.md

@@ -1,9 +1,16 @@
 # Publish content verification — parent protocol
 
+> **BLOCKED (2026-09-14):** `artifact_inspect` was removed by the platform.
+> No agent-callable replacement exists (`artifact.inspect` is malfunction
+> diagnosis, not a read-back tool), so the ferry step below cannot currently
+> run. Tasks park at `publish: verification-requested` and stay parked until
+> a read-back path exists. The rest of this document describes the protocol
+> as designed, so the shape is preserved for when the capability returns.
+
 Provenance is the artifact's claim that its live content came from a specific
-repo commit. The workflow used to stamp it; it no longer does. This document
-is the parent-side runbook. The workflow script handles the mechanical
-halves; the parent handles the stamp.
+repo commit. The workflow never stamps it. This document is the parent-side
+protocol. Deterministic code detects, claims, and certifies; the tick worker
+(the live root agent) is only the async ferry for the inspection.
 
 ## Why the parent stamps
 
@@ -34,37 +41,126 @@ The contract is split on purpose:
 
 - **Workflow-owned:** carrying the merged diff to the builder, the
   applied-report observation (logged, never a park), the build-completion
-  poll, post-deploy cleanup, triggering an independent `artifact_inspect`
-  read-back of the changed regions (carrying the observed builder build
-  identifier for correlation), recording the Publish session completed, and
+  poll, post-deploy cleanup, recording the Publish session completed, and
   parking with `publish: verification-requested <commit>` instead of
-  stamping.
-- **Parent-owned:** reading back the artifact's actual content, comparing it
-  mechanically against the merged diff, checking for supersession, stamping
-  provenance only on a match, reading the stamp back exactly, and re-queuing
-  the task to `in_progress`. In standard/bugfix, QA's provenance check then
-  enforces the stamp — an unstamped publish fails loudly in QA instead of
-  passing silently. Chore has no QA: the parent's stamp read-back is the
-  final gate.
+  stamping. The workflow does NOT trigger the read-back inspection — an
+  async inspection triggered from inside a workflow run delivers its result
+  to the root agent, never back into the run, so a workflow-side trigger is
+  an orphan the verifier cannot consume. The parent triggers the one
+  inspection it can actually receive.
+- **Parent-owned (deterministic code, ferried by the tick worker):**
+  scanning for verification-pending parks, atomically claiming them,
+  building the read-back request, triggering the inspection, waiting for the
+  result, comparing it mechanically against the merged diff, checking
+  build-ID correlation and supersession, stamping provenance only on a
+  match, reading the stamp back exactly, logging the terminal verdict, and
+  re-queuing the task to `in_progress`.
 
 No artifact publish completes without parent-stamped provenance. A missing or
 mismatched read-back never stamps.
 
+## The carried diff: BASE..HEAD from the stamped provenance
+
+The "merged diff" the workflow carries is `BASE..HEAD` where `BASE` is the
+previously-stamped provenance `source_commit` — the artifact's actual
+content — never `HEAD^1`. (Task `0c53af4e`, 2026-09-14: a push-time
+reconcile merge put the task's own changes behind an intermediate merge, so
+`HEAD^1..HEAD` carried only the reconcile delta and silently omitted the
+task's fix; the artifact built without it. The stamped base is the only
+ground truth for what the artifact already has; `BASE..HEAD` is the complete
+unpublished delta.)
+
+The workflow reads the base via `get-provenance` before computing the diff,
+and the computation is guarded mechanically:
+
+- Empty base (no provenance stamped) → the empty tree
+  `4b825dc642cb6eb9a060e54bf8d69288fbee4904`, and only then. A present but
+  malformed base SHA parks fail-closed.
+- `git merge-base --is-ancestor BASE HEAD` must pass; a non-ancestor base
+  parks fail-closed (the stamped provenance must lead to the integrated
+  commit, otherwise the artifact has drifted or the stamp is wrong).
+- The agent-reported base must equal the stamped base; a mismatch parks.
+- The expected base content hashes (pre-publish observation) are computed at
+  the stamped base, not the merge parent — the artifact's tree should match
+  the stamp, and the observation is only meaningful against it.
+
+The parent verifier (`lib/verify-publish.js`, `--base`) and the read-back
+request builder (`lib/build-readback-request.js`, `--base`) use the identical
+base: the previously-stamped provenance, or the empty tree for a genuine
+first publish. Request builder and verifier never disagree on the base.
+
+## The shape: code detects, the tick ferries, code certifies
+
+A standalone verification workflow cannot work with the async inspection
+model: async inspection results are delivered to the root agent of the
+agent tree, never into a workflow run — so a verify workflow would wait
+forever for a result it can never receive. The tick worker IS the live
+root agent, so it is the only component that can both trigger an
+inspection and receive its result. (The inspection tool itself,
+`artifact_inspect`, was removed by the platform 2026-09-14 — see the
+BLOCKED notice at the top.)
+
+But the tick worker is a generalist LLM, and the certification decision is
+safety-critical: a misjudged "match" stamps unverified content, and nothing
+downstream can ever detect it (QA checks the stamp, not the content). So the
+LLM never judges. The division:
+
+1. **Scan (code):** `scan-verification-pending` finds parked tasks whose
+   latest parent note is `publish: verification-requested`, with no terminal
+   verdict and no unexpired claim. It atomically claims each one by logging
+   `publish: verification-claimed <expiry>` (1-hour lease) — the task stays
+   parked, so the dispatcher never dispatches QA mid-verification, and a
+   second tick cannot start a duplicate verification. It also reconciles the
+   verified-but-still-parked gap (verdict recorded, re-queue lost to a crash)
+   back to `in_progress`.
+2. **Build (code):** `build-readback-request.js` builds the EXACT inspection
+   request from the publish delta — `git diff <base> <commit>` where
+   `<base>` is the previously-stamped provenance `source_commit` (or the
+   empty tree for a first publish). The tick never hand-writes the request,
+   and never uses `commit^1` as the base: push-time reconcile merges put
+   the task's own changes behind an intermediate merge, so `commit^1`
+   covers only the reconcile delta (2026-09-14, task `0c53af4e`).
+3. **Ferry (tick worker):** when a read-back tool is available, calls it
+   with the built request, waits for the async handoff, saves the full
+   result JSON to a file. (Currently blocked — no agent-callable tool
+   exists.)
+4. **Certify (code):** `verify-publish.js` parses the inspector's
+   machine-readable findings block, compares every added/removed diff line
+   against the reported present/absent verdicts, checks build-ID correlation
+   and supersession via git, and only then stamps provenance, reads the
+   stamp back exactly, logs the terminal verdict, and re-queues to
+   `in_progress`. Unparseable findings, mismatches, supersession, and stamp
+   failures all fail CLOSED with a terminal `publish: verification-failed`
+   verdict — never a stamp.
+   - **Envelope:** the tick saves the COMPLETE handoff — the full prose
+     report AND the full JSON result, both verbatim (raw prose, JSON, or
+     both concatenated are all accepted). Observed 2026-09-14: the
+     platform's JSON envelope carries NO machine-readable findings
+     block; the block lives in the prose handoff. The verifier locates
+     the findings block in prose text and JSON string values (including
+     double-encoded ones) and prefers the block whose file paths cover
+     the expected diff — an echoed request template or stray prose never
+     outranks the real block. No covering block => `unreadable-result`,
+     fail closed. Saving JSON-only strands verification.
+     fail closed.
+   - **Release identity:** `scan-verification-pending` resolves
+     `crew_release` through the crew home's `current` symlink (the immutable
+     active release) and cross-checks it against the running code's own
+     realpath. Unresolvable or disputed => the scan throws fail-closed
+     BEFORE writing any claim — provenance is never stamped `unknown`, and
+     a stale cron body running an old release cannot certify.
+
+The tick body (seed/cron-body-template.md, step 4.5) wires these together.
+The publisher never certifies itself, and the LLM never makes the
+safety-critical match decision.
+
 ## The park
 
 When the artifact build lands, the workflow parks the task with the message:
 
 ```
 publish: verification-requested <commit> (build <agent_id|agent_id unobserved>) — artifact build landed, post-deploy
-finalized, provenance NOT stamped. Parent: run docs/publish-verification.md
-(content read-back inspection <inspection_id> already triggered).
-```
-
-or, if the workflow's inspect trigger failed:
-
-```
-publish: verification-requested <commit> (build <agent_id|agent_id unobserved>) — ... (read-back inspect trigger
-failed: <reason> — parent: trigger artifact_inspect manually).
+finalized, provenance NOT stamped. Parent: run docs/publish-verification.md.
 ```
 
 The parked message is stored as `Parked: publish: verification-requested
@@ -80,71 +176,87 @@ task holds no resources.
 
 ## Parent verification procedure
 
+The automated path is the tick body's step 4.5 (scan → build → ferry →
+verify). The manual fallback below is the same protocol run by hand; it
+exists for when the artifact namespace is unavailable to the tick worker.
+
 For a task parked with `publish: verification-requested <commit>`:
 
 1. **Resolve the project.** Read the task's project via the Crew API
-   (`getproject`); you need `repo_path` (the git checkout) and the artifact
+   (`get-project`); you need `repo_path` (the git checkout) and the artifact
    slug (the project's publish target).
-2. **Expected change.** Run `git show <commit>` (or
-   `git diff <commit>^1 <commit>`) in `repo_path`. This is the expected
-   content — the same diff the workflow carried to the builder.
-3. **Actual content.** Get the read-back:
-   - If the park message names an `inspection_id`, read that inspection's
-     result (async `artifact_inspect` results are delivered to the parent,
-     like the visual-verdict inspections).
-   - If the trigger failed, call `artifact_inspect` yourself with
-     `repair_authorized: false` and the `verbatim_request` rebuilt from the
-     workflow source: `buildPublishReadbackRequest(taskId, commit, diff,
-     buildAgentId)` in `workflows/standard.js` (identical in `bugfix.js`
-     and `chore.js`) — pass the task id, the commit, the diff from step 2,
-     and the agent_id from the park message's `(build …)` suffix (ledger
-     lookup from step 4b if the suffix says `agent_id unobserved`; null if
-     neither is available).
-   - If no read-back can be obtained at all, log
-     `publish: verification-blocked <commit> <reason>` and leave the task
-     parked for human attention. Never stamp without a read-back.
+2. **Expected change.** The publish delta is `git diff <base> <commit>`
+   in `repo_path`, where `<base>` is the previously-stamped provenance
+   `source_commit` (read it via `get-provenance`; use the empty-tree sha
+   `4b825dc642cb6eb9a060e54bf8d69288fbee4904` when no provenance is
+   stamped yet — a first publish). Never use `commit^1` as the base and
+   never take the expected change from the builder's report: push-time
+   reconcile merges violate the `merge^1 == previously-published tree`
+   invariant, so `commit^1..commit` can omit the task's own fix
+   (2026-09-14, task `0c53af4e`).
+3. **Actual content.** When a read-back tool is available, call it with
+   `repair_authorized: false` and the `verbatim_request` built by
+   `lib/build-readback-request.js` (pass `--repo-path`, `--commit`,
+   `--base` (the same base as step 2),
+   `--task-id`, `--slug`, and `--build-agent-id` from the park message's
+   `(build …)` suffix when it is not `agent_id unobserved`). Currently
+   blocked — `artifact_inspect` was removed by the platform (2026-09-14)
+   and no agent-callable replacement exists. The request demands a
+   machine-readable findings block:
+   ```
+   FILE: <path>
+   ADDED: <exact added line> :: PRESENT|ABSENT
+   REMOVED: <exact removed line> :: PRESENT|ABSENT
+   END_FILE
+   ```
+   If no read-back can be obtained at all, log
+   `publish: verification-blocked <commit> <reason>` and leave the task
+   parked for human attention. Never stamp without a read-back.
 4. **Compare mechanically.** For every added (`+`) line in the diff, the
-   read-back must report it PRESENT in the artifact's current source. For
-   every removed (`-`) line, the read-back must report it ABSENT. Quote the
-   observed lines; do not infer from prose.
-4b. **Build-ID correlation.** Prove the read-back inspected the live build
-   of THIS publish attempt — not a different build's output:
+   read-back's machine-readable block must report it PRESENT in the
+   artifact's current source. For every removed (`-`) line, it must report
+   it ABSENT. The comparison is computed by `lib/verify-publish.js` — never
+   by eyeballing prose. A missing or malformed findings block fails closed
+   as `unreadable-result`, never as a pass.
+4b. **Build-ID correlation.** The read-back may have inspected a different
+   build's output than this publish attempt's:
    1. **Expected** = the agent_id in the park message's `(build …)` suffix.
       If the suffix says `agent_id unobserved`, look up the workflow's
       durable publish ledger at `$CREW_HOME/.publish-ledger/<slug>.jsonl`
       for the `submitted` entry with this `<commit>` and use its
       `agent_id` field (it may still be null — then this step is vacuous).
-   2. **Live** = the build agent_id the read-back reports for the live
-      build (the request asks for it explicitly; the inspector may state
-      that no build/agent_id is visible).
-   3. If expected and live are both non-null and DIFFER, the read-back may
-      have inspected a different build's output — log
-      `publish: build-mismatch <commit> expected <expected> observed <live>`,
-      stay parked, never stamp, never re-queue. This is not a retry signal:
-      a later inspection of the right build can be recorded by the human
-      if desired; the loop never re-drives the verification itself.
-   4. Otherwise the content match from step 4 decides; log the correlation
-      outcome (expected/live compared, or vacuous) in the `publish:
-      verified` note.
+   2. **Live** = whether the expected agent_id appears anywhere in the
+      read-back result (the live artifact status exposes no durable
+      agent_id — only an in-flight correlation ID that expires with the
+      publish attempt, so absence is the common case, not evidence of a
+      mismatch).
+   3. If expected is non-null and the read-back positively reports a
+      DIFFERENT live build identity for this attempt's output, log
+      `publish: build-mismatch <commit> expected <expected> observed
+      <live>`, stay parked, never stamp, never re-queue.
+   4. Otherwise the content match from step 4 decides — the stamp certifies
+      CONTENT, not the builder's identity. Log the correlation outcome
+      (correlated / unobserved) in the `publish: verified` note.
 5. **Supersession check.** Before stamping, prove the inspected live
-   artifact still represents the commit being certified. Read the crew's
-   current provenance record (`get-provenance`): if `source_commit` names a
-   commit NEWER than `<commit>` (a later Publish already landed), the
-   read-back is stale — do NOT stamp `<commit>` on top of it. Log
-   `publish: superseded <commit> by <newer_commit>` and leave the task
-   parked for human attention. Never claim commit A after commit B changed
-   the artifact.
-6. **Stamp, verify the stamp, then re-queue:**
+   artifact still represents the commit being certified: `git rev-parse
+   HEAD` in `repo_path` must equal `<commit>`. If HEAD has moved (a later
+   Publish landed), the read-back is stale — log
+   `publish: superseded <commit> by <head>` and leave the task parked for
+   human attention. Never stamp a superseded commit.
+6. **Stamp, verify the stamp, then re-queue** (all in `lib/verify-publish.js`;
+   the manual equivalent):
    - **Match** — stamp provenance with the Crew API CLI `set-provenance`
      (the crew-owned store). Do NOT use the artifact's `setprovenance`
      action — it writes a different, non-authoritative store that QA never
      reads, so the stamp would be invisible to every gate:
-     `set-provenance --json '{"source_commit":"<commit>","crew_release":"<basename of $crewHome/current>","published_at":"<date -u +%Y-%m-%dT%H:%M:%SZ>","task_id":"<task>"}'`.
-     Then read the stamp back with `get-provenance`
-     and confirm all four fields match exactly what was sent — a stamp
-     that cannot be read back is not a stamp. Only then log the task note
-     event `publish: verified <commit> (<inspection_id>)` and re-queue
-     with `update-task` → state `in_progress` (never `todo` — `todo`
+     `set-provenance --json '{"source_commit":"<commit>","crew_release":"<release>","task_id":"<task>"}'`
+     (crew_release is the basename of the active release, e.g.
+     `pkg-0.7.10`). Then read the stamp back with `get-provenance`
+     and confirm source_commit, crew_release, and task_id match exactly
+     what was sent — a stamp that cannot be read back is not a stamp. Only
+     then log the task note event
+     `publish: verified <commit> (<inspection_id>)` and re-queue with
+     `update-task` → state `in_progress` (never `todo` — `todo`
      restarts Triage and resets retry accounting). The dispatcher resumes
      at QA from the completed Publish session (standard/bugfix); chore has
      no QA — it proceeds to terminal completion. QA's provenance check
@@ -161,6 +273,61 @@ For a task parked with `publish: verification-requested <commit>`:
      for human attention. Never re-queue an unstamped-but-verified task into
      QA — QA would fail it and burn rework budget on a stamping problem.
 
+## Crash recovery
+
+- **Tick dies before triggering the inspection:** the claim expires after
+  1 hour; the next scan re-claims and re-verifies from scratch. The stamp
+  is an idempotent upsert, so a duplicate verification cannot corrupt it.
+- **Tick dies after the inspection but before the stamp:** same as above —
+  the next scan re-runs the whole verification (new inspection, new
+  comparison). Wasteful but correct.
+- **Crash between stamp and re-queue:** the next scan sees
+  `publish: verified` on a still-parked task and reconciles it to
+  `in_progress`. Failure verdicts are never reconciled — they stay parked
+  for human attention.
+- **Two ticks verify concurrently:** impossible — the atomic claim means the
+  second scan sees the unexpired `publish: verification-claimed` note and
+  skips. The lease expiry bounds the damage if a claimer dies.
+
+## Unknown-outcome recovery (2026-09-14, Gate 1 Journey 3 attempt 7)
+
+Attempt 7 parked at Publish with outcome `unknown`: the rebuild trigger's
+child failed structured closeout and the in-flight-only build-state poll
+could not see the completed build — even though the build HAD run (a fresh
+platform audit directory existed). Two mechanisms close this gap.
+
+**1. Workflow-side durable evidence.** Before the rebuild trigger, the
+workflow snapshots the artifact's audit-directory listing
+(`~/workspace/ts-spaces/<slug>/audits/` — best-effort, never a gate). On a
+structured-output failure with no in-flight build observed, it re-lists and
+diffs: a timestamped directory that appeared during the trigger window is
+positive evidence the edit went through and the build completed. The
+fallback never re-issues the edit, never stamps provenance, and only routes
+to the parent's independent content read-back. No new directory still parks
+`unknown` fail-closed. The ledger distinguishes the two confirmations: `edit
+confirmed via durable audit evidence …` vs `edit confirmed via build-state
+poll …`.
+
+The fallback's known limitation: audit directories are not attributed to
+tasks, so two concurrent publishes to the same artifact could cross-read.
+The consequence is bounded — the fallback only routes to the parent
+read-back, and the parent still certifies the exact commit's content
+mechanically (a wrong build's content fails closed as `publish:
+content-mismatch` / `publish: build-mismatch`, never stamps).
+
+**2. `resolve-publish-unknown` (Crew API).** For attempts already parked
+`unknown` before this fix: given a task parked with a latest ledger outcome
+of `unknown`, it derives the publish window (Integrate-completion event →
+unknown-outcome park event) and checks for a timestamped audit build inside
+that window. On evidence, it appends `unknown-resolved` to the ledger
+(never rewriting the original entry), writes `publish: unknown-resolved`
+and a mirrored `publish: verification-requested <commit>` note (the mirror
+is timestamped strictly later so the scan sees it as the latest), and leaves
+the task parked for the normal scan. Still-unknown cases stay parked:
+unparked task, non-`unknown` latest ledger outcome, missing commit, no audit
+build in the window, unobservable window, or an already-resolved attempt
+(idempotent).
+
 ## Exact note-event prefixes
 
 Case-sensitive, exact-prefix matches — match on prefixes, never on English
@@ -168,20 +335,29 @@ meaning:
 
 - `publish: verification-requested <commit>` — workflow park; contained in
   the stored `Parked: …` message.
+- `publish: verification-claimed <ISO-expiry>` — parent scan; atomic claim
+  with lease. Not a verdict.
 - `publish: verified <commit> (<inspection_id>)` — parent, after stamping
   AND reading the stamp back exactly; re-queued to `in_progress` (never
   `todo`).
 - `publish: content-mismatch <commit> <details>` — parent; exact FAIL
   evidence quoted; stays parked, never stamped, never re-queued to QA.
 - `publish: build-mismatch <commit> expected <expected> observed <live>` —
-  parent; the read-back inspected a different build's output than the
-  publish attempt (step 4b); stays parked, never stamped, never re-queued.
-- `publish: superseded <commit> by <newer_commit>` — parent; a later Publish
-  already landed; stays parked for human attention.
+  parent; the read-back positively identified a different build's output
+  (step 4b); stays parked, never stamped, never re-queued.
+- `publish: superseded <commit> by <head>` — parent; HEAD moved past the
+  commit; stays parked for human attention.
 - `publish: verification-blocked <commit> <reason>` — parent; no read-back
   obtainable; stays parked for a human.
+- `publish: unknown-resolved <commit>` — recovery; durable build evidence
+  found inside the publish window for a previously-unknown attempt (see
+  "Unknown-outcome recovery"). The original `unknown` outcome is preserved;
+  the mirrored `verification-requested` note (written strictly later) is
+  what the scan claims.
 - `publish: stamp-failed <commit> <reason>` — parent; read-back matched but
   the stamp call failed; stays parked for a human.
+- `publish: reconciled verified-but-parked -> in_progress` — parent scan;
+  the verified verdict was recorded but the re-queue was lost.
 
 ## Workflow differences
 
@@ -192,14 +368,3 @@ meaning:
   exact stamp read-back), the dispatcher proceeds to terminal completion.
   The parent's stamp read-back is the final gate — no downstream phase
   re-checks it.
-
-## Recovery: rebuilding the read-back request
-
-If the park message names no inspection and you must trigger the read-back
-manually, the request is deterministic — rebuild it from the workflow source
-(`buildPublishReadbackRequest` in `workflows/standard.js`, identical in
-`bugfix.js` and `chore.js`) with the task id, the `<commit>` from the park
-message, the diff from `git show <commit>` in the project's `repo_path`,
-and the agent_id from the park message's `(build …)` suffix (use the ledger
-lookup from step 4b if the suffix says `agent_id unobserved`; pass null if
-neither is available).