muse-crew 0.7.18 → 0.7.19

package/docs/publish-verification.md

@@ -42,18 +42,23 @@ The rule: **the builder's applied report is never a verification signal, in
 either direction.** A matching report certifies nothing (it is derived from
 the carried diff — circular by construction, canary run 8). A mismatching or
 empty report blocks nothing (false-negative mode demonstrated by `23ca8f3f`).
-The workflow computes the report comparison as an observation only — it
-never parks on it. The parent ignores the applied report entirely when
-deciding whether to stamp: an `applied:[]` or mismatched report with a
-matching independent read-back stamps normally.
+The workflow dropped the report entirely on 2026-09-16 (clean-room task
+`e2a8d9f8`): the trigger's JSON closeout contract traveled over the
+stochastic text channel and the runtime's JSON-candidate heuristic misfired
+on its prose ("workflow agent output was not JSON"), parking a task whose
+edit may have gone through. The trigger is now fire-and-forget — no schema,
+no consumed return value — and there is no builder report to observe:
+`applied_report` is a constant `missing-report` on the ledger line. The
+parent ignores the (absent) report entirely when deciding whether to stamp.
 
 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, recording the Publish session completed, and
-  parking with `publish: verification-requested <commit>` instead of
-  stamping. The workflow does NOT trigger the read-back inspection — an
+- **Workflow-owned:** carrying the merged diff to the builder, attributing
+  the edit itself (fire-and-forget trigger — no builder report — via
+  pre-trigger toolcheck, pre-trigger build-state baseline, and post-trigger
+  build-state diff), the build-completion poll, post-deploy cleanup,
+  recording the Publish session completed, and parking with `publish:
+  verification-requested <commit>` instead of 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
@@ -313,24 +318,40 @@ For a task parked with `publish: verification-requested <commit>`:
   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)
+## Unknown-outcome recovery (2026-09-14, Gate 1 Journey 3 attempt 7; fire-and-forget 2026-09-16)
 
 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
+platform audit directory existed). 2026-09-16 (clean-room task `e2a8d9f8`)
+showed the failure is worse than a catchable throw: the runtime's
+JSON-candidate heuristic rejects the trigger call itself ("workflow agent
+output was not JSON") whenever the child returns prose, whether or not the
+edit went through. The trigger is therefore fire-and-forget — no schema, no
+consumed return value — and the workflow always attributes the edit itself.
+Two mechanisms close the gap.
+
+**1. Pre-trigger toolcheck + baseline.** Before the trigger, a tiny schema'd
+child proves the artifact tool namespace is available (one bounded retry on
+explicit negative evidence — the only safe retry on the publish path:
+without the tools the edit provably did not go through) and captures a
+pre-trigger build-state baseline. After the trigger, the workflow diffs the
+post-trigger build state against the baseline: a build whose `agent_id` is
+new relative to the baseline is this edit's receipt. The baseline build's
+`agent_id` is never substituted — a build already in flight at baseline
+predates the trigger and is never attributed to this edit.
+
+**2. 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 …`.
+(`~/workspace/ts-spaces/<slug>/audits/` — best-effort, never a gate). When
+no in-flight receipt was 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's `detail` line distinguishes the two confirmations: `… edit
+confirmed via durable audit evidence (new audit dir …)` vs `… build receipt
+captured by workflow-owned build-state observation (pre/post-trigger diff)`.
 
 The fallback's known limitation: audit directories are not attributed to
 tasks, so two concurrent publishes to the same artifact could cross-read.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "muse-crew",
-  "version": "0.7.18",
+  "version": "0.7.19",
   "description": "Opinionated orchestration for Muse — workflows, identities, and tooling for autonomous software development.",
   "license": "UNLICENSED",
   "private": false,