/dev:technical-plan 2.4 has no protocol for a reviewer that goes idle without reporting — twice it nearly wrote 'panel could not be run' into an immutable record #453

New issue

Open

opened 2026-08-27 07:32:45 +00:00 by jbr870 · 0 comments

jbr870 commented

2026-08-27 07:32:45 +00:00

Owner

Observation

/dev:technical-plan §2.4 tells the lead how to spawn an expert panel and how to synthesize it, but
says nothing about the case where a reviewer goes idle without delivering its report. The step's
only failure-handling is for an unavailable model:

Probe one reviewer before fanning out. […] If it comes back unavailable, escalate the entire
panel to opus.

and its synthesis instruction assumes delivery:

After all teammates respond, the lead (you) synthesizes […]

There is no branch for responded-to-nobody. A lead that hits it has to invent a protocol on the
spot — and the sanctioned protocol already exists, three files away, in
_shared/procedures/wait-discipline.md §1a ("An idle signal is not a completion signal — check the
tree, then ask"), which §2.4 never references. §1a is written for /dev:develop and the QA
playbook; its Consumers list does not name /dev:technical-plan.

The consequence is not a slow panel. It is a false statement written into an immutable durable
record: the lead concludes the panel could not be run, and posts that as a finding.

Evidence

Instance 1 — feature-230, /dev:technical-plan (recorded in #45's PREQ, from the #37 time study).
Five reviewers returned nothing. Between 12:21 and 12:34 the lead spawned seven agents across two
models, ran two control probes, used sentinel-file wait loops, then concluded the subagent transport
was broken. It wrote the SREQ solo and posted the Phase Outcome at 12:37:13 carrying the finding
"panel could not be run".

The panel's results arrived at 12:37:47 — 34 seconds later, carrying two blocking concerns the
solo plan had missed. Cost: the SREQ rewritten and re-posted, a correction comment filed, ~25 minutes
of rework, and a durable record that was false. #45 exists because of this incident.

Instance 2 — issue #45, /dev:technical-plan, 2026-08-26 (this run). A five-lens Tier 3 panel was
spawned on fable. Four of the five went idle without delivering a report; only rev-security
returned one through the normal path.

Following §1a — read the tree before drawing any conclusion — the four transcripts showed each had
written a complete review; the reports were dropped, not the work. All four were recovered from
the transcripts and used. They carried 8 of the 12 blocking concerns the panel produced,
including three that changed the design:

read-side fail-closed gating of the new record kind (raised independently by 3 lenses),
a decision-dropping rule in the draft that would have let pipeline state advance on annulled
evidence (contradicting the feature's own AC-6),
the ref-substring hazard (F-PO-45-3-2 prefixes F-PO-45-3-21) — a bug class this suite has
already shipped once.

Had this run followed instance 1's path, it would have written "panel could not be run" into the
Phase Outcome of the feature whose entire purpose is recovering from that exact false record.

Recovery in both instances was cheap: instance 1 needed 34 more seconds of patience; instance 2
needed one transcript read. The recorded cost came entirely from concluding too early.

Recurrence

2 independent instances, in the same skill and the same step, ~3 weeks apart, on different
models. Structural as well: §2.4 is the only place in the suite that spawns a panel without
pointing at §1a, and it is a step whose output feeds an immutable record.

Hypothesis

A reference, not a new mechanism. In §2.4, after the probe-and-fan-out paragraph, state that an
unreported idle is not a completion signal and route to wait-discipline.md §1a's existing
ordered step — read the tree (the agent's transcript / its declared output), then ask it directly
with one round-trip, then reconcile and say which happened. Add /dev:technical-plan to §1a's
Consumers list so the pointer is bidirectional.

Two specifics worth writing down because both instances turned on them:

A reviewer's deliverable is its text, and the transcript holds it. Instance 2's four reviews
were recoverable by reading the last assistant message of each transcript. §1a's "read the tree"
is phrased for code (git log, git status, commits) and does not obviously cover a review panel,
whose tree is the transcript.
Never record "the panel could not be run" as a finding without having done the above. That
sentence is the failure mode, and it is what makes the record false.

Relationship to #45 (partial overlap — do not close as duplicate)

#45's roll-call removes the escape hatch: a terminal Phase Outcome must account for every agent the
phase spawned as reported or terminated, and there is deliberately no unrecoverable
disposition, so "I judged the transport broken" stops being something the record can say.

That is prevention, not instruction. It forces the lead to terminate or wait; it does not tell it
that the report is probably recoverable, or how. This ticket is the remaining half — the lead needs
to know the recovery step exists before it decides which disposition to write. Both instances
show the recovery is the cheap part; the expensive part is not knowing to try.

Sequence after #45: this amendment should land after #45's roll-call, so §2.4's new text can name
the roll-call as the thing the recovery feeds.

Suggested lane

Meta lane / /meta-amend, sequenced after #45. Bounded text edits to /dev:technical-plan §2.4
and wait-discipline.md's Consumers list; verifiable at HEAD; desk-check against both instances
above.

## Observation `/dev:technical-plan` §2.4 tells the lead how to spawn an expert panel and how to synthesize it, but says nothing about the case where a reviewer **goes idle without delivering its report**. The step's only failure-handling is for an *unavailable model*: > **Probe one reviewer before fanning out.** […] If it comes back unavailable, **escalate the entire > panel to `opus`**. and its synthesis instruction assumes delivery: > **After all teammates respond**, the lead (you) synthesizes […] There is no branch for *responded-to-nobody*. A lead that hits it has to invent a protocol on the spot — and the sanctioned protocol already exists, three files away, in `_shared/procedures/wait-discipline.md` §1a (*"An idle signal is not a completion signal — check the tree, then ask"*), which §2.4 never references. §1a is written for `/dev:develop` and the QA playbook; its Consumers list does not name `/dev:technical-plan`. The consequence is not a slow panel. It is a **false statement written into an immutable durable record**: the lead concludes the panel could not be run, and posts that as a finding. ## Evidence **Instance 1 — feature-230, `/dev:technical-plan`** (recorded in #45's PREQ, from the #37 time study). Five reviewers returned nothing. Between 12:21 and 12:34 the lead spawned seven agents across two models, ran two control probes, used sentinel-file wait loops, then concluded the subagent transport was broken. It wrote the SREQ solo and posted the Phase Outcome at 12:37:13 carrying the finding *"panel could not be run"*. **The panel's results arrived at 12:37:47 — 34 seconds later**, carrying two blocking concerns the solo plan had missed. Cost: the SREQ rewritten and re-posted, a correction comment filed, ~25 minutes of rework, and a durable record that was false. #45 exists because of this incident. **Instance 2 — issue #45, `/dev:technical-plan`, 2026-08-26** (this run). A five-lens Tier 3 panel was spawned on `fable`. **Four of the five went idle without delivering a report**; only `rev-security` returned one through the normal path. Following §1a — read the tree before drawing any conclusion — the four transcripts showed each had **written a complete review**; the reports were dropped, not the work. All four were recovered from the transcripts and used. They carried **8 of the 12 blocking concerns** the panel produced, including three that changed the design: - read-side fail-closed gating of the new record kind (raised independently by 3 lenses), - a decision-dropping rule in the draft that would have let pipeline state advance on annulled evidence (contradicting the feature's own AC-6), - the `ref`-substring hazard (`F-PO-45-3-2` prefixes `F-PO-45-3-21`) — a bug class this suite has already shipped once. Had this run followed instance 1's path, it would have written *"panel could not be run"* into the Phase Outcome **of the feature whose entire purpose is recovering from that exact false record.** Recovery in both instances was cheap: instance 1 needed 34 more seconds of patience; instance 2 needed one transcript read. The recorded cost came entirely from concluding too early. ## Recurrence **2 independent instances, in the same skill and the same step**, ~3 weeks apart, on different models. Structural as well: §2.4 is the only place in the suite that spawns a panel *without* pointing at §1a, and it is a step whose output feeds an immutable record. ## Hypothesis A reference, not a new mechanism. In §2.4, after the probe-and-fan-out paragraph, state that an **unreported idle is not a completion signal** and route to `wait-discipline.md` §1a's existing ordered step — read the tree (the agent's transcript / its declared output), *then* ask it directly with one round-trip, *then* reconcile and say which happened. Add `/dev:technical-plan` to §1a's Consumers list so the pointer is bidirectional. Two specifics worth writing down because both instances turned on them: - **A reviewer's deliverable is its text, and the transcript holds it.** Instance 2's four reviews were recoverable by reading the last assistant message of each transcript. §1a's "read the tree" is phrased for code (`git log`, `git status`, commits) and does not obviously cover a review panel, whose tree *is* the transcript. - **Never record "the panel could not be run" as a finding without having done the above.** That sentence is the failure mode, and it is what makes the record false. ## Relationship to #45 (partial overlap — do not close as duplicate) #45's roll-call removes the *escape hatch*: a terminal Phase Outcome must account for every agent the phase spawned as `reported` or `terminated`, and there is deliberately **no `unrecoverable` disposition**, so "I judged the transport broken" stops being something the record can say. That is prevention, not instruction. It forces the lead to terminate or wait; it does not tell it that the report is probably recoverable, or how. This ticket is the remaining half — the lead needs to know the recovery step exists **before** it decides which disposition to write. Both instances show the recovery is the cheap part; the expensive part is not knowing to try. Sequence after #45: this amendment should land **after** #45's roll-call, so §2.4's new text can name the roll-call as the thing the recovery feeds. ## Suggested lane **Meta lane / `/meta-amend`**, sequenced after #45. Bounded text edits to `/dev:technical-plan` §2.4 and `wait-discipline.md`'s Consumers list; verifiable at HEAD; desk-check against both instances above.

jbr870 added the

labels

2026-08-27 07:32:45 +00:00

jbr870 referenced this issue

2026-08-27 07:32:46 +00:00

Phase Outcomes: no supersede path when a posted outcome's premise turns out false #45