muse-crew 0.14.10 → 0.14.11

package/API.md

@@ -114,6 +114,7 @@ Records the tick worker's direct issuance outcome (0.14.6). Compare-and-swap on
 | `refusal_text` | string | no | Required when `refused` |
 | `reclaimed` | boolean | no | Copy verbatim from the `scan-publish-intent` entry — true when a previous tick died mid-issuance |
 | `receipt_check` | `different`\|`unreadable`\|`match` | required when `reclaimed` is true, forbidden otherwise | The tick worker's step-2 version-receipt check outcome for the reclaimed claim |
+| `transmitted_payload_sha256` | 64-hex sha256 | no | Optional attestation of the payload bytes transmitted in the `artifact_edit` handoff (0.14.11 §2). Verbatim paste: attest the step-1-verified staged `diff_sha256` (those bytes are what was transmitted). Re-typed paste: hash the exact transmitted diff text (between the handoff's diff fences) via file-write + `sha256sum`, never through the shell. The handoff's wrapper prose is not attested. Must be 64-hex when present (usage error otherwise). Code compares it to the staged `diff_sha256` at record time; the hashes ride the `submitted` ledger entry and a MISMATCH is carried into the `version-acknowledged` note as `payload-fidelity: MISMATCH (transmitted <h> != staged <h>)` — diagnosis only, feeds no verdict. Honesty limit: this instrument measures self-reported consistency, a lower bound on the true mutation rate. Only an honest worker's MISMATCH carries signal — MATCH is uninformative by construction (copying `diff_sha256` from step 1 is uncloseable) and pre-transport paste truncation yields a silent false-MATCH. Absent attestation changes nothing. |
 
 `accepted` writes the issuer-stamped `submitted` ledger entry + `publish: edit-issued` note. `refused` writes `rejected` + terminal `publish: publish-refused`. Returns `{ "recorded": true, "edit_outcome" }` or `{ "recorded": false }` on CAS mismatch.
 

package/docs/decisions/AGENTS.md

@@ -50,6 +50,7 @@ re-verified that every `docs/decisions/*.md#anchor` reference in
 - `#publish-verify` — Publish verification
 - `#integrate-verify` — Integrate verification
 - `#already-merged-idem` — Already-merged idempotency
+- `#already-satisfied-spec` — Already-satisfied spec (baseline-pre-existing work; 2026-09-23, 0.14.11 §4)
 - `#ledger-trigger` — Ledger trigger
 - `#trigger-await` — Trigger await
 - `#diff-computation` — Diff computation

package/docs/decisions/publish-path.md

@@ -1214,6 +1214,17 @@ Applies to: standard, bugfix, chore.
     // interpolating it into the shell command cannot inject.
 ```
 
+<a id="already-satisfied-spec"></a>
+## Already-satisfied spec (baseline-pre-existing work)
+
+**The machine, not the paraphrase.** The Build prompt invites the already-satisfied claim: "If you verified the deliverable is already on the integration target (a prior merge landed it — do NOT re-implement working code), make no commit and declare `repo_diff: none` … The workflow verifies the claim mechanically from git — the task's own merge records, never your declaration, are the proof of delivery." The verification runs — and an unattributable claim verifies as `empty-no-work` → Cass plausibility (which correctly rejects non-runtime-state) or mechanical FAIL → rework budget → **park-with-reason**. That is the designed fail-closed outcome (Eric, 2026-09-22): if it parked with an understandable reason, that's even better.
+
+Why attribution-identity-first matters: `classify-branch` (the blocker-34 redesign) attributes `already-merged:<sha>` ONLY to the task's own lineage — a live merge carrying the branch tip, or the task's durable merge records. Work pre-existing in the pinned baseline (e.g. a feature commit that is an ancestor of the pinned baseline before the task existed) is neither — it is `empty-no-work`. Blocker-11's "accept already-merged as steady state" referred to the task's own merge lineage (a deliverable the task itself had merged), never to baseline-pre-existing work. There is no no-op-accept path, and none goes in without machine verification — a broken Build producing nothing must never read as DONE (critic-panel constraint, 2026-09-22). `parked-to-Todo` stays the designed human escape hatch.
+
+Prevention lives outside the product: the room-spec generator checklist carries `baseline-absence-verified` — the real absence check (e.g. `git merge-base --is-ancestor <feature> <baseline>`) with its command output recorded in the room spec JSON at filing time. If the check shows the work present in the pinned baseline, the spec is not filed as-is. (A mechanical baseline-absence check on a once-per-room human filing is process theater — Eric, 2026-09-22 — so the generator stays human and outside the system under test on purpose.)
+
+Applies to: standard, bugfix, chore.
+
 <a id="ledger-trigger"></a>
 ## Ledger trigger
 

package/lib/crew-api.js

@@ -1882,23 +1882,49 @@ function findSubmittedEntries(entries, commit) {
   return matches;
 }
 
+// 0.14.11 §2 — extract the record-time payload-fidelity fact from a
+// submitted ledger entry for the ack note. Only a MISMATCH is carried: MATCH
+// and absent attestation leave the note verbatim (strictly additive). The
+// compare is recomputed from the two co-located hashes — no stored flag
+// (stale-flag hazard). Deliberately no trimmed/lenient compare: the reframed
+// worker instruction dissolves the benign causes (shell mangling, newline
+// drift, fence confusion) at the source, so residual drift in the fallback
+// path is genuine paste deviation by definition.
+function entryFidelity(entry) {
+  if (!entry) return null;
+  const transmitted = entry.transmitted_payload_sha256 || null;
+  const staged = entry.diff_sha256 || null;
+  if (!transmitted || !staged || transmitted === staged) return null;
+  return { transmitted, staged };
+}
+
 // 0.14.6 §1.3 — record a positive version acknowledgement: stamp provenance
 // (certifying the issuance REQUEST was acknowledged — never byte equality),
 // write the terminal `publish: version-acknowledged` note, and re-queue the
 // task. Shared by scan-ack-pending and the record-version-ack command (the
 // re-claim path). The strict release cross-check refuses to stamp from a
 // stale cron body or a mid-deploy swap — fail closed.
-function recordVersionAck(db, ctx, { taskId, projectId, commit, version, via }) {
+//
+// 0.14.11 §2: `fidelity` is entryFidelity(entry) — when the issued payload's
+// attested hash differed from the staged diff, the deviation rides the note
+// as a first-class diagnosis fact. The ack still counts: the contract prices
+// receipt-attestation, not byte equality.
+function recordVersionAck(db, ctx, { taskId, projectId, commit, version, via, fidelity }) {
   const releaseName = resolveActiveRelease(ctx.crewHome);
   const ts = now();
   stampProvenance(db, {
     project_id: projectId, source_commit: commit, crew_release: releaseName,
     published_at: ts, task_id: taskId,
   });
+  const fidelityText = fidelity
+    ? ` payload-fidelity: MISMATCH (transmitted ${fidelity.transmitted} != staged ${fidelity.staged})`
+    : "";
   writeGuardedPublishNote(db, taskId,
     `publish: version-acknowledged ${commit} via=${via} — the artifact acknowledged this attempt's exact version ` +
     `(${via === "disk" ? "on-disk receipt .crew-publish-version" : "version-echoing builder report"}); ` +
-    `provenance stamped for crew release ${releaseName} (certifies the issuance request was acknowledged, not byte equality). Task re-queued.`,
+    `provenance stamped for crew release ${releaseName} (certifies the issuance request was acknowledged, not byte equality).` +
+    fidelityText +
+    ` Task re-queued.`,
     ts);
   db.prepare("UPDATE tasks SET state = 'in_progress', updated_at = ? WHERE id = ?").run(ts, taskId);
   return { ok: true, task_id: taskId, commit, version, via, crew_release: releaseName };
@@ -2138,8 +2164,30 @@ commands["scan-publish-intent"] = (db, args, ctx) => {
 // tick worker calls this exactly once per artifact_edit call that completed
 // without error and without an explicit refusal.
 //
+// 0.14.11 §2 — payload-fidelity attestation (diagnosis only, never a
+// verdict): the optional `transmitted_payload_sha256` is the worker's
+// honest-effort attestation of the payload bytes it transmitted in the
+// artifact_edit handoff. Two sanctioned paths (seed/cron-body-template.md
+// 3b): verbatim paste → attest the step-1-verified staged diff_sha256
+// (those bytes are what was transmitted); re-typed paste → hash the exact
+// transmitted diff text (between the handoff's diff fences) via the
+// file-write tool + sha256sum, never through the shell. Code compares it to
+// the staged diff_sha256 at record time; a mismatch is carried into the
+// version-acknowledged note as a first-class fact and feeds no verdict.
+// The wrapper prose around the handoff is not attestable (no canonical
+// intended bytes exist for it) and is deliberately excluded: the payload is
+// the patch. Perfect attestation is impossible; this instrument measures
+// self-reported consistency — a lower bound on the true mutation rate.
+// Only an honest worker's MISMATCH carries signal: MATCH is uninformative by
+// construction (copying diff_sha256 from step 1 is uncloseable), and
+// pre-transport truncation yields a silent false-MATCH — the quiet direction,
+// accepted under diagnosis-only. The failure the attestation misses
+// (attested-match with garbage transmitted) degrades to today's behavior
+// (builder refuses → attempt times out).
+//
 // Args: { task_id, claim_expiry, edit_outcome: "accepted"|"refused",
-//         refusal_text? } — omit refusal_text unless refused.
+//         refusal_text?, transmitted_payload_sha256? } — omit refusal_text
+//         unless refused.
 //
 // `accepted` writes the issuer-stamped `submitted` ledger entry (carrying
 // the attempt's version) and mirrors `publish: edit-issued` — the ack scan
@@ -2212,6 +2260,15 @@ commands["record-intent-issuance"] = (db, args, ctx) => {
   } else if (receiptCheck !== undefined && receiptCheck !== null) {
     throw usageError("receipt_check is only valid for a reclaimed claim.");
   }
+  // 0.14.11 §2 — payload-fidelity attestation: optional, validated, strictly
+  // additive. A malformed-but-present attestation is a programmer error and
+  // fails closed at the API boundary.
+  const transmittedSha = args.transmitted_payload_sha256;
+  if (transmittedSha !== undefined && transmittedSha !== null &&
+      !/^[0-9a-f]{64}$/.test(String(transmittedSha))) {
+    throw usageError("transmitted_payload_sha256 must be a 64-hex sha256.");
+  }
+  const attestedSha = transmittedSha ? String(transmittedSha) : null;
 
   db.exec("BEGIN");
   try {
@@ -2250,6 +2307,13 @@ commands["record-intent-issuance"] = (db, args, ctx) => {
       // registry — the writer-side guard pattern from D7).
       note = `publish: publish-refused ${commit} attempt=${publishAttempt} — the platform refused the issued edit (${refusalText}). No re-issue; parked for human attention.`;
     } else {
+      // 0.14.11 §2 — the record-time fidelity compare: the attested hash of
+      // the transmitted payload bytes against the staged diff_sha256. The
+      // hashes ride the submitted entry; code recomputes MATCH/MISMATCH
+      // wherever it needs the verdict (entryFidelity), never a stored flag.
+      // Null attestation (absent) is strictly additive — the machine's
+      // behavior is unchanged. Feeds no verdict — diagnosis only.
+      ledgerLine.transmitted_payload_sha256 = attestedSha;
       ledgerLine.outcome = "submitted";
       ledgerLine.detail = "edit issued directly by the session-carrying tick worker (one-party publish); the staged diff carried the per-attempt version receipt" +
         (reclaimed ? `; reclaimed claim, step-2 receipt check was '${receiptCheck}' (a differing or unreadable receipt is not proof the prior attempt's edit did not land)` : "");
@@ -2442,8 +2506,12 @@ commands["scan-ack-pending"] = (db, args, ctx) => {
       // explicit REFUSALS only (negative evidence).
       const ackedAttempt = attempts.find((a) => diskVersion === expectedVersion(a));
       if (ackedAttempt !== undefined) {
+        // 0.14.11 §2 — the record-time fidelity fact rides the ack note
+        // (diagnosis only; the ack still counts).
+        const ackedEntry = validEntries.find((e) => e.publish_attempt === ackedAttempt) || null;
         recordVersionAck(db, ctx, {
           taskId, projectId: project.id, commit, version: expectedVersion(ackedAttempt), via: "disk",
+          fidelity: entryFidelity(ackedEntry),
         });
         acknowledged.push({ task_id: taskId, commit, attempt: ackedAttempt, via: "disk", crew_release: releaseName });
         continue;
@@ -2712,6 +2780,7 @@ commands["record-version-ack"] = (db, args, ctx) => {
   try {
     const res = recordVersionAck(db, ctx, {
       taskId, projectId: project.id, commit: matched.commit, version, via,
+      fidelity: entryFidelity(matched),
     });
     db.exec("COMMIT");
     return res;

package/package.json

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

package/seed/cron-body-template.md

@@ -87,9 +87,13 @@ The failures below are settled and recorded in the Gate 1 OODA state. The author
         The diff and rules are suggestions now, not byte-exact commands (this also sidesteps the platform newline-escaping defect on verbatim requests — the receipt file is what matters, not byte fidelity).
         Edit-request contract: call artifact_edit exactly once. Never retry the edit yourself. Tool unavailable (the artifact namespace would not load), a timeout, a transport error, or any otherwise ambiguous result is inconclusive: record NOTHING for this task, log the ambiguity in one line, and let the claim expire; the next scan re-claims and step 2's receipt check decides. An unrecorded outcome is the only honest record of an unknown one.
         After the call returns, inspect the result text. (2026-09-20 REVIEW) Do NOT record an "acknowledged" builder report — the positive builder-report path was circular (the worker knows the version, so the report proves nothing) and is removed; the ack scan reads the version receipt from the artifact's disk as the sole positive evidence. If the result is an explicit refusal → `node {crewHome}/lib/crew-api.js --crew-home {crewHome} record-builder-report --json '{"task_id":"<task_id>","version":"<version>","outcome":"refused","report_text":"<refusal text verbatim>"}'` (the command MECHANICALLY rejects unless `report_text` contains the exact version — if the refusal text lacks the version, do NOT call record-builder-report; just proceed to the record step with `refused`).
+     3b. **Attest the payload (code, diagnosis only — never a verdict).** After the `artifact_edit` call returns (only when it completed without error and without an explicit refusal), attest what you transmitted as the payload — two branches, no judgment:
+        - **Verbatim paste:** if you pasted the staged diff file's content unchanged into the handoff's `SUGGESTED PATCH` slot, the transmitted bytes are exactly the staged bytes: attest the `diff_sha256` you already verified in step 1's `sha256sum` (reuse that output — no second hashing needed).
+        - **Re-typed or altered paste:** if you re-typed, reformatted, or otherwise changed the diff while pasting, write the EXACT diff text you transmitted — the text between the ` ```diff ` fences of the handoff's `SUGGESTED PATCH` slot, fences excluded — to a temp file with your file-write tool (never through the shell: interpolating diff bytes into a quoted shell string corrupts `$`, backticks, quotes, and backslashes and would hash bytes that were never transmitted), then `sha256sum /tmp/<task_id>-payload.txt`. The write tool preserves exact bytes, including the trailing newline.
+        The wrapper prose around the patch is not attested — there is no canonical intended bytes for it; the payload is the patch. Pass the 64-hex hash as `transmitted_payload_sha256` on the `record-intent-issuance` call (step 4). Code compares it to the staged `diff_sha256` at record time: MATCH means the attested bytes matched the staged bytes; MISMATCH means the paste deviated (re-typing in transit is the failure mode this catches — the blocker-26 family). A MISMATCH is carried into the `version-acknowledged` note (`payload-fidelity: MISMATCH (transmitted <h> != staged <h>)`) — it never changes any verdict (the ack contract prices receipt-attestation, not byte equality). If the paste deviated, attest the deviation honestly and proceed to step 4 — do not re-paste, do not re-issue (step 3: never retry the edit). Perfect attestation is impossible (the paste itself can deviate); this instrument measures self-reported consistency — a lower bound on the true mutation rate, not the rate. Only an honest worker's MISMATCH carries signal: MATCH is uninformative by construction (copying `diff_sha256` from step 1 is uncloseable), and pre-transport truncation of the paste yields a silent false-MATCH — the quiet direction, accepted under diagnosis-only. Omit `transmitted_payload_sha256` if you cannot attest honestly; absent attestation changes nothing.
      4. **Record the outcome (code):**
-        `node {crewHome}/lib/crew-api.js --crew-home {crewHome} record-intent-issuance --json '{"task_id": "<task_id>", "claim_expiry": "<claim_expiry>", "edit_outcome": "<accepted|refused>", "refusal_text": "<first line>", "reclaimed": <true|false>, "receipt_check": "<different|unreadable>"}'`
-        (omit `refusal_text` unless refused; copy `reclaimed` verbatim from the scan entry — it is mechanical, never inferred; `receipt_check` is REQUIRED when `reclaimed` is true and must name the exact step-2 outcome — omit `receipt_check` when `reclaimed` is false. A `match` in step 2 never reaches this step: the edit already landed, so you ack instead of issuing.) Copy `claim_expiry` verbatim from the scan entry — it is the compare-and-swap. If the command returns `recorded: false`, log the reason and stop: another tick owns the task. `accepted` writes the issuer-stamped `submitted` ledger entry and mirrors `publish: edit-issued <commit> attempt=<n> version=<commit>:<attempt>` (the 4.5 ack scan claims it on a later tick); `refused` writes `rejected` and the terminal `publish: publish-refused` note. There is no outcome for an inconclusive call (step 3) — do not call record-intent-issuance at all when the edit's fate is unknown.
+        `node {crewHome}/lib/crew-api.js --crew-home {crewHome} record-intent-issuance --json '{"task_id": "<task_id>", "claim_expiry": "<claim_expiry>", "edit_outcome": "<accepted|refused>", "refusal_text": "<first line>", "reclaimed": <true|false>, "receipt_check": "<different|unreadable>", "transmitted_payload_sha256": "<64-hex attested in step 3b>"}'`
+        (omit `refusal_text` unless refused; omit `transmitted_payload_sha256` unless you attested in step 3b (accepted outcomes only); copy `reclaimed` verbatim from the scan entry — it is mechanical, never inferred; `receipt_check` is REQUIRED when `reclaimed` is true and must name the exact step-2 outcome — omit `receipt_check` when `reclaimed` is false. A `match` in step 2 never reaches this step: the edit already landed, so you ack instead of issuing.) Copy `claim_expiry` verbatim from the scan entry — it is the compare-and-swap. If the command returns `recorded: false`, log the reason and stop: another tick owns the task. `accepted` writes the issuer-stamped `submitted` ledger entry and mirrors `publish: edit-issued <commit> attempt=<n> version=<commit>:<attempt>` (the 4.5 ack scan claims it on a later tick); `refused` writes `rejected` and the terminal `publish: publish-refused` note. There is no outcome for an inconclusive call (step 3) — do not call record-intent-issuance at all when the edit's fate is unknown.
      - Prose never mints `publish:` notes directly. Any tick-authored publish note goes through exactly one path (code asserts the verb against the closed registry, rejects unknown verbs):
        `node {crewHome}/lib/crew-api.js --crew-home {crewHome} record-publish-note --json '{"task_id":"<task_id>","note":"<full note text>"}'`
    - Crash rules (fail closed, never blind re-issue): if this tick dies between the artifact_edit call and the record step, the next scan re-claims with `reclaimed: true` and step 2's version-receipt check decides between ack (`record-version-ack` with `via: "disk"`) and a fresh issuance — recorded with its explicit `receipt_check`, since a differing/unreadable receipt is not proof the prior attempt's edit did not land. The issuance contract is at-most-one RECORDED issuance per attempt; a duplicate physical issuance across a lease expiry is content-identical (the same checksummed staged diff) and bounded by the ack scan's 2-hour budget.

package/workflows/bugfix.js

@@ -1637,7 +1637,7 @@ while (i < STEPS.length) {
       reviewChangeExam =
         "The branch has no commits ahead of the integration target (see MECHANICAL FACT below) — there is no diff to examine. Judge the Build report's `repo_diff: none` claim on its plausibility.\n\n";
       reviewBranchRule =
-        "MECHANICAL FACT (computed by the workflow from git — never by a reviewer): the branch has no commits ahead of the integration target and no task-attributed merge on the target was verified; the Build report declares `repo_diff: none` (no repo change). Approve ONLY if the task's deliverable is plausibly runtime state (e.g. a cron definition, scheduler change, or dashboard/config state created outside the repo). Otherwise report 'no commits ahead of the integration target and no plausible runtime-state deliverable — the builder likely forgot to commit', then end your report with exactly this line: VERDICT: FAIL.\n";
+        "MECHANICAL FACT (computed by the workflow from git — never by a reviewer): the branch has no commits ahead of the integration target and no task-attributed merge on the target was verified; the Build report declares `repo_diff: none` (no repo change). Approve ONLY if the task's deliverable is plausibly runtime state (e.g. a cron definition, scheduler change, or dashboard/config state created outside the repo). Otherwise report 'no commits ahead of the integration target and no plausible runtime-state deliverable — the branch is empty and no task-attributed merge was verified', then end your report with exactly this line: VERDICT: FAIL.\n";
     } else {
       // Mechanical FAIL — Cass is never dispatched (see the dispatch gate
       // below). Instructions are unused; keep the shape.
@@ -2285,7 +2285,7 @@ while (i < STEPS.length) {
         : "Branch state (classified by the workflow from git): empty-no-work — the task branch has no commits ahead of the integration target, " +
           "no task-attributed merge on the target was verified" + (branchStateErr ? " (branch classification itself failed: " + branchStateErr + ")" : "") + ", " +
           "and the accepted Build report declared no `repo_diff: none` deliverable. " +
-          "No change was reviewed because there is no change to review. The builder likely forgot to commit.\n") +
+          "No change was reviewed because there is no change to review. The branch is empty and no task-attributed merge was verified.\n") +
       "Worktree: " + WORKTREE_HINT + "\n" +
       "Recovery: commit the deliverable on the task branch in the worktree above and re-run Review. If the deliverable is genuinely runtime state outside the repo, declare `repo_diff: none` in the Build report instead of leaving the branch empty without a declaration.\n" +
       "VERDICT: FAIL";

package/workflows/chore.js

@@ -1500,7 +1500,7 @@ while (i < STEPS.length) {
       reviewChangeExam =
         "The branch has no commits ahead of the integration target (see MECHANICAL FACT below) — there is no diff to examine. Judge the Build report's `repo_diff: none` claim on its plausibility.\n\n";
       reviewBranchRule =
-        "MECHANICAL FACT (computed by the workflow from git — never by a reviewer): the branch has no commits ahead of the integration target and no task-attributed merge on the target was verified; the Build report declares `repo_diff: none` (no repo change). Approve ONLY if the task's deliverable is plausibly runtime state (e.g. a cron definition, scheduler change, or dashboard/config state created outside the repo). Otherwise report 'no commits ahead of the integration target and no plausible runtime-state deliverable — the builder likely forgot to commit', then end your report with exactly this line: VERDICT: FAIL.\n";
+        "MECHANICAL FACT (computed by the workflow from git — never by a reviewer): the branch has no commits ahead of the integration target and no task-attributed merge on the target was verified; the Build report declares `repo_diff: none` (no repo change). Approve ONLY if the task's deliverable is plausibly runtime state (e.g. a cron definition, scheduler change, or dashboard/config state created outside the repo). Otherwise report 'no commits ahead of the integration target and no plausible runtime-state deliverable — the branch is empty and no task-attributed merge was verified', then end your report with exactly this line: VERDICT: FAIL.\n";
     } else {
       // Mechanical FAIL — Cass is never dispatched (see the dispatch gate
       // below). Instructions are unused; keep the shape.
@@ -1985,7 +1985,7 @@ while (i < STEPS.length) {
         : "Branch state (classified by the workflow from git): empty-no-work — the task branch has no commits ahead of the integration target, " +
           "no task-attributed merge on the target was verified" + (branchStateErr ? " (branch classification itself failed: " + branchStateErr + ")" : "") + ", " +
           "and the accepted Build report declared no `repo_diff: none` deliverable. " +
-          "No change was reviewed because there is no change to review. The builder likely forgot to commit.\n") +
+          "No change was reviewed because there is no change to review. The branch is empty and no task-attributed merge was verified.\n") +
       "Worktree: " + WORKTREE_HINT + "\n" +
       "Recovery: commit the deliverable on the task branch in the worktree above and re-run Review. If the deliverable is genuinely runtime state outside the repo, declare `repo_diff: none` in the Build report instead of leaving the branch empty without a declaration.\n" +
       "VERDICT: FAIL";

package/workflows/standard.js

@@ -1526,7 +1526,7 @@ while (i < STEPS.length) {
       reviewChangeExam =
         "The branch has no commits ahead of the integration target (see MECHANICAL FACT below) — there is no diff to examine. Judge the Build report's `repo_diff: none` claim on its plausibility.\n\n";
       reviewBranchRule =
-        "MECHANICAL FACT (computed by the workflow from git — never by a reviewer): the branch has no commits ahead of the integration target and no task-attributed merge on the target was verified; the Build report declares `repo_diff: none` (no repo change). Approve ONLY if the task's deliverable is plausibly runtime state (e.g. a cron definition, scheduler change, or dashboard/config state created outside the repo). Otherwise report 'no commits ahead of the integration target and no plausible runtime-state deliverable — the builder likely forgot to commit', then end your report with exactly this line: VERDICT: FAIL.\n";
+        "MECHANICAL FACT (computed by the workflow from git — never by a reviewer): the branch has no commits ahead of the integration target and no task-attributed merge on the target was verified; the Build report declares `repo_diff: none` (no repo change). Approve ONLY if the task's deliverable is plausibly runtime state (e.g. a cron definition, scheduler change, or dashboard/config state created outside the repo). Otherwise report 'no commits ahead of the integration target and no plausible runtime-state deliverable — the branch is empty and no task-attributed merge was verified', then end your report with exactly this line: VERDICT: FAIL.\n";
     } else {
       // Mechanical FAIL — Cass is never dispatched (see the dispatch gate
       // below). Instructions are unused; keep the shape.
@@ -2152,7 +2152,7 @@ while (i < STEPS.length) {
         : "Branch state (classified by the workflow from git): empty-no-work — the task branch has no commits ahead of the integration target, " +
           "no task-attributed merge on the target was verified" + (branchStateErr ? " (branch classification itself failed: " + branchStateErr + ")" : "") + ", " +
           "and the accepted Build report declared no `repo_diff: none` deliverable. " +
-          "No change was reviewed because there is no change to review. The builder likely forgot to commit.\n") +
+          "No change was reviewed because there is no change to review. The branch is empty and no task-attributed merge was verified.\n") +
       "Worktree: " + WORKTREE_HINT + "\n" +
       "Recovery: commit the deliverable on the task branch in the worktree above and re-run Review. If the deliverable is genuinely runtime state outside the repo, declare `repo_diff: none` in the Build report instead of leaving the branch empty without a declaration.\n" +
       "VERDICT: FAIL";