baldart 4.53.3 → 4.53.5

package/CHANGELOG.md

@@ -5,6 +5,22 @@ All notable changes to BALDART will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [4.53.5] - 2026-06-18
+
+**The team-mode empty-result gate now distinguishes a rate-limit death from a genuine fabrication — and re-spawns transient failures STAGGERED, not in the same parallel burst.** Root-cause finding (from reading the actual subagent transcripts of the v4.53.4 incident — `~/.claude/projects/<mayo>/<session>/subagents/agent-*.jsonl`): the two `/new FEAT-0035` L2 coders that "came to rest" with no work were **killed mid-flight by API rate-limiting** — both transcripts end on the identical `API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited`, after the agent had done real work (file reads, a written plan) but before any edit. It was NOT model fabrication or a "decided nothing to do" stall (the v4.53.4 framing): a wide parallel wave (3 coders + orchestrator + other agents) saturated the API, the background teammate runtime does not auto-resume a rate-limited teammate, so it rested with no report + no diff, and the full re-spawn re-did the lost reads (the "paid twice" cost). Fix: the gate now reads the rested agent's LAST event — a transient API/rate-limit/overload error ⇒ a **transient infra failure** (re-spawn STAGGERED with backoff; never re-fire several transient-failed agents in the same parallel burst — it re-saturates the API; narrow the wave's fan-out width if rate limits recur; does not consume the genuine-failure Step-B budget), vs a CLEAN rest with no error ⇒ the genuine empty-result/fabrication path (one Step-B re-spawn → `AskUserQuestion`). Honest boundary: the cheaper real fix — *resuming* a rate-limited teammate instead of killing+re-spawning it — is Claude Code **runtime** behaviour, not BALDART's to fix in prose; BALDART mitigates (correct classification + staggered backoff + fan-out narrowing). **PATCH** (refines the v4.53.4 team-mode gate; no code/CLI/workflow change, no `baldart.config.yml` key).
+
+### Fixed
+
+- **`framework/.claude/skills/new/references/team-mode.md`** — the Step-C empty-result gate gains a CAUSE classification: transient infra failure (rate-limit/overload — re-spawn staggered with backoff, narrow the fan-out if recurring, no budget consumed) vs genuine empty-result/fabrication (clean rest, no error — the existing one-shot Step-B → `AskUserQuestion`). Corrects the v4.53.4 framing that attributed the silent rest to model fabrication.
+
+## [4.53.4] - 2026-06-18
+
+**Team-mode now has a MANDATORY empty-result / fabrication gate — a parallel coder that rests without doing the work no longer slips past on luck.** Observed on a real `/new FEAT-0035` L2 wave: of three coders spawned in parallel (03, 06, 07), **03 and 07 "came to rest" with NO completion report and zero file changes** (the empty-result failure pattern — same model-in-the-loop class as the v4.53.0 worktree-setup fabrication/stall), while 06 worked and reported normally. The orchestrator caught it only because it *improvised* a `git status` and noticed only 06's files had changed — the team-mode protocol (`team-mode.md` § Step C) merely said "read the completion report from the agent's output", assuming a report exists, and its failure branch only handled an agent that *reports* `status: failed`. So detection of a silent idle was model-discretion, not protocol: a less diligent run would have carried the empty work into the D pipeline and only hit it late/expensively at the D.3a AC-Closure or the Final build. Fix: Step C gains an explicit gate — for EACH agent, before logging it `done`, verify on disk that (a) it emitted the Step-7 completion report and (b) its `files_changed` actually changed in the worktree (`git status --porcelain` ∩ the card's File Ownership Map, using the v4.53.2 grep-verification discipline). No report on rest = empty-result; claimed-but-absent files = fabrication; both → the existing one-shot Step-B re-spawn (re-briefed to write + disk-confirm before reporting), second failure → `AskUserQuestion` skip/abandon. A legitimate zero-diff no-op (AC pre-satisfied) is the rare explicit exception, confirmed from the report's `evidence`. The coder brief (Step 7) is reinforced symmetrically: a `done` report is invalid with an empty diff. Cannot make coders not-idle (they do real work; the internal cause isn't recoverable from the trace — the agents left no report), but the DETECTION is now deterministic + mandatory instead of lucky. **PATCH** (protocol-hardening prose for team mode; no code/behaviour change in CLI or workflows, no `baldart.config.yml` key).
+
+### Fixed
+
+- **`framework/.claude/skills/new/references/team-mode.md`** — Step C gains a MANDATORY "Empty-result / fabrication gate": a teammate resting without a completion report, or with `files_changed` not present on disk, is an empty-result/fabrication failure → one Step-B re-spawn (disk-verify re-brief) → `AskUserQuestion` on a second failure; never accept "came to rest" as "done" without on-disk evidence. Step-7 completion-report mandate reinforced (a `done` report is invalid with an empty diff).
+
 ## [4.53.3] - 2026-06-18
 
 **The per-wave/Final Codex review wrapper is now a thin relay on a cheaper model, not an Opus agent that re-investigates Codex's findings.** Observed on a real `/new FEAT-0035` run: the `codex` discovery agent burned ~127k tokens / 26 tool calls — it launched the Codex companion (correct) but then **re-grepped/sed'd the source to "mechanically confirm" Codex's findings** before returning, despite the design already trusting them (`preValidated`, FP-checked by Codex). Root cause: the wrapper consumed Codex's **freeform `task` output** (prose), which forced a smart+expensive model to parse 6 fields per finding out of prose — and it over-reached into self-investigation. Fix: instruct Codex to emit its findings as strict JSON between explicit `<<<FINDINGS_JSON>>>` / `<<<END_FINDINGS_JSON>>>` sentinels (verified on two real companion runs: output round-trips cleanly through `JSON.parse` with all our fields incl. `domain` + `requires_action`, and the sentinels make extraction deterministic despite the companion's `[codex]` trace lines + the truncated "Assistant message captured:" echo — the truncated copy lacks the closing sentinel so the last-complete-pair awk skips it). The wrapper is now a **pure relay**: write the task to a temp file (no shell-quote breakage — same discipline as v4.53.2), launch Codex in the background, poll for the END sentinel, extract via a fixed awk, `JSON.parse`, return — **no re-grep, no re-verify**. Model dropped from the inherited Opus to **`haiku` per-wave** (a poll misfire degrades safely to the `code-reviewer` fallback, and the Final re-runs Codex batch-wide) and **`sonnet` at the Final** (last cross-model gate before merge — no downstream Codex backstop). The review *mechanism* (Codex `task` + `--cwd` worktree + the changed-file list) is unchanged from production — only the output format, the wrapper's scope, and the model tier change. **PATCH** (cost/economy refinement of existing workflows; no new capability, no schema/config key, no install change).

package/VERSION

@@ -1 +1 @@
-4.53.3
+4.53.5

package/framework/.claude/skills/new/references/team-mode.md

@@ -109,7 +109,7 @@ Agent tool call:
     d) Self-heal up to 3 times if checks fail
     e) Verify completeness: for each requirement, confirm code exists (read it)
     f) If any requirement is missing after implementation, implement it now
-    g) Output the completion report (MANDATORY format below)
+    g) Output the completion report (MANDATORY format below). A `status: done` report is INVALID unless your `files_changed` are actually written to disk — never rest/report done with an empty diff (the orchestrator disk-verifies and will treat a no-change rest as an empty-result failure and re-spawn you).
 
     ### 7. Completion Report (MANDATORY)
     ```completion-report
@@ -140,6 +140,14 @@ For each completed agent:
 2. Log to tracker: card ID, status, files changed, build/lint status.
 3. Do NOT read or store implementation details — only the verdict.
 
+**Empty-result / fabrication gate (MANDATORY — since v4.53.4; do NOT accept "came to rest" as "done").** A background agent coming to rest is NOT proof it did the work. The observed failure mode (real, repeated): a teammate **idles and rests WITHOUT emitting the Step-7 completion report AND without changing any file** — a silent empty-result — while its peers in the same parallel wave completed normally. (Rarer twin: it reports `files_changed` it never wrote — fabrication.) Letting this slide is only caught later/expensively by the D.3a AC-Closure or the Final build; catch it HERE, deterministically, before running the rest of the D pipeline on empty work. For EACH agent, before logging it `done`, verify ON DISK:
+- **A Step-7 completion report was emitted.** A teammate that rested with **no completion report = empty-result failure.** (Do not infer "done" from the rest event alone.)
+- **Its `files_changed` actually changed in the worktree** — `git status --porcelain` intersected with that card's File Ownership Map is non-empty and covers the claimed paths (use the grep-verification discipline above — never a quote-broken check). **Zero changes in the card's ownership files = empty-result failure; report claims files that are not on disk = fabrication.**
+- A genuinely legitimate no-op card (its AC turned out already satisfied) is the rare exception: confirm it from the report's per-requirement `evidence` pointing at PRE-EXISTING code, and log it explicitly as `no-op (AC pre-satisfied)` — never assume zero-diff means success.
+**Classify the CAUSE before re-spawning — read the rested agent's LAST event:**
+- **Transient infra failure (the common cause of a silent empty rest in a WIDE parallel wave).** The agent's last output is an API error / `Rate limited` / overload / `(not your usage limit)` — i.e. the background teammate was **killed mid-flight by API rate-limiting** (it had done real work — reads, a plan — then died), NOT a model fabrication or "decided nothing to do". The runtime does NOT auto-resume a dead teammate, so it rests with no report + no diff. **Re-spawn it, but STAGGERED with backoff — do NOT re-fire several transient-failed agents in the same parallel burst** (that re-saturates the API and kills them again). Space them out (one at a time, or after a brief pause). This still costs a fresh run (the killed agent's reads are lost — the runtime cannot resume it), so **prevention beats recovery**: if a wave repeatedly hits rate limits, NARROW the parallel fan-out width for that wave (spawn fewer coders at once) rather than re-firing the full wave. A transient failure does NOT consume the Step-B genuine-failure budget.
+- **Genuine empty-result / fabrication.** The agent rested CLEANLY (no error in its last event), with no completion report and no diff. THIS is the model-fault case: take the one Step-B re-spawn below (same cap), re-briefing the coder with an explicit "write your ownership files and confirm them on disk before reporting done" mandate. A second empty result → `AskUserQuestion` (skip/abandon) — do not re-spawn a third time.
+
 **If an agent fails** (status: failed after 3 retries — the central repair cap):
 - Log failure in tracker `## Issues & Flags`.
 - Other agents in the group continue unaffected.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "baldart",
-  "version": "4.53.3",
+  "version": "4.53.5",
   "description": "Claude Agent Framework - Reusable framework for coordinating AI agents and humans in software projects",
   "bin": {
     "baldart": "./bin/baldart.js"