discipline:sweep-all — the fork stop-rule is inert (no detection mechanism) and contradicts setup's declared degraded mode

[kyle-sexton]

Summary

plugins/discipline/skills/sweep-all/SKILL.md step 1 carries a stop-rule:

if forks are unavailable, report that the inheriting audit fan-out cannot run and stop, rather than auditing blind

Nothing in the plugin defines how to determine that forks are unavailable. A grep across
plugins/discipline for fork|inherit|canary|probe|CLAUDE_CODE_ returns no detection mechanism.
A rule whose guard cannot be evaluated is inert, not merely under-specified.

Why this is HIGH, not cosmetic

With no way to evaluate the guard, the default path is the one that runs: N blind ledgers, merged
at step 3, and acted on at step 4, which instructs "correct forward … on the main thread now"
and therefore writes to the working tree. A correctness skill whose failure mode is confident,
fabricated corrections applied to real files.

This is observed, not hypothetical. A real full-batch invocation (plugin-quality:audit post-use
run, session 0666d581, 2026-07-26) dispatched eight subagent_type: "fork" audits and all
eight came back with no inherited conversation — fork mode was off and the request silently
produced fresh subagents. Two of the eight refused to fabricate a ledger from their system prompt;
that refusal is the only reason the run did not merge eight invented ledgers.

The plugin already declares the right degraded mode — in a file a sweep never loads

skills/setup/SKILL.md step 6:

Where it is off, only the session-start posture digest runs; note this so an unavailable fan-out
is expected, not a misconfiguration.

That contradicts sweep-all's "report and stop". Two contracts for one condition, and the better
one lives where a sweep never reads it — so the operator got nothing at all rather than a posture
digest.

This refutes the framing the audit was commissioned with. The commissioning brief asserted "no
degraded mode exists" and proposed building a three-rung fallback ladder. At plugin scope that is
wrong: a degraded mode is already the plugin's declared position. The fix is to stop the two files
disagreeing — not to build a ladder. The artifacts-only / main-thread-sequential ladder is
explicitly out of scope here; it re-creates the salience dilution the declared delta exists to
prevent.

Proposed fix

1. A preflight step in sweep-all, before the fan-out, in two stages:

   • Stage 1 — zero-dispatch, diagnostic only. A paired tool-schema check. Two documented
     sentences combine:

     • https://code.claude.com/docs/en/sub-agents — "fork mode removes the run_in_background
       parameter from the Agent tool"
     • https://code.claude.com/docs/en/env-vars — CLAUDE_CODE_DISABLE_BACKGROUND_TASKS: "Set to
       1 to disable all background task functionality, including the run_in_background
       parameter on Bash and subagent tools"

     So Agent lacking the parameter while Bash retains it rules out the disabled-background-
     tasks cause and leaves fork mode as the documented explanation; Agent carrying it means fork
     mode is not env-var-enabled. Neither branch is conclusive — the server-side rollout path is
     unstated in the docs — so stage 1 never gates. It explains what stage 2 finds.

   • Stage 2 — the decider: one inheritance-proof canary, at zero extra cost. Fold the canary
     into the lowest-ranked in-scope member's real audit fork: require an inheritance proof before
     any audit content, and only fan out the rest once the main thread verifies it. Fail closed —
     ambiguous, absent, or unverifiable proof is treated as not-inherited.

2. Move the degraded mode into sweep-all — on a failed preflight, run the session-start
   posture digest, report that the inheriting fan-out could not run and which signal said so, and
   name the direct-invocation path. setup keeps a one-line pointer instead of a second contract.
3. Define "failure" for the existing retry rule ("retry only a failed subset, once"): a
   returned ledger without valid inheritance proof is a failure. Today a fabricated ledger is not
   a "failure", so the retry rule misses the actual exposure.

Verification

Verified this session against pages fetched today: https://code.claude.com/docs/en/sub-agents
and https://code.claude.com/docs/en/env-vars. Plus a first-hand probe in a fork-enabled session:
a subagent_type: "fork" dispatch inherited the conversation, and its own schemas showed Agent
without run_in_background and Bash with it — the paired inference above, observed.

Unverified and to be flagged as such in the fix: what the harness actually does when the fork
subagent type is requested while fork mode is off. The current skill states it "falls back to a
fresh general-purpose subagent"; that behavior appears on no page fetched this session. It is an
observation from the failed run, and must be labelled observed-not-documented — in a plugin whose
flagship corrector is do-your-research.

Source: plugin-quality:audit post-use audit of discipline@0.9.0 (F1/F2, F10, F13).

[kyle-sexton]

This was generated by AI during triage.

Verified — the defect holds, with one premise correction

Confirmed against the repo source this session.

• The stop rule exists as prose in the sweep-all runbook's fan-out step: "so if forks are unavailable, report that the inheriting audit fan-out cannot run and stop, rather than auditing blind."
• No detection mechanism exists anywhere in the plugin. A sweep across every *.md and *.json under the discipline plugin for fork/inheritance/canary/probe/CLAUDE_CODE_ returns only prose mentions of CLAUDE_CODE_FORK_SUBAGENT in sweep-all and setup — no probe, no canary, no schema check. The guard cannot be evaluated, so the default path is the one that runs.
• The two-contract contradiction is real. setup step 6 declares the degraded mode ("Where it is off, only the session-start posture digest runs; note this so an unavailable fan-out is expected, not a misconfiguration"), and sweep-all says report-and-stop. Two contracts for one condition, and the better one lives in a file a sweep never loads. This half is not covered by sweep-all-disciplines: fork subagents silently do not inherit the conversation, and two of four claimed they did #1258 and is the item's original contribution.

Premise correction — there are TWO observed failure modes, not one

The item flags the runbook's "requesting the fork type falls back to a fresh general-purpose subagent" claim as observed-not-documented. The fetch this session is stronger than that flag:

• https://code.claude.com/docs/en/env-vars (fetched 2026-07-26), CLAUDE_CODE_FORK_SUBAGENT: "When enabled, Claude can request the fork subagent type to spawn a fork… When Claude doesn't request a subagent type, it still gets the general-purpose subagent." That sentence is scoped to not requesting a type while fork mode is enabled. It does not describe requesting fork while fork mode is off. https://code.claude.com/docs/en/sub-agents (fetched 2026-07-26) says nothing about that case either. The runbook's fallback claim is unsupported by either page.
• A second failure mode is observed in this repo's own autonomous lane. Two cycles ago a dispatch of subagent_type: "fork" returned a hard error — Agent type 'fork' not found — not a silent fresh subagent. In the current session the Agent tool schema still carries run_in_background, which by the item's own paired inference indicates fork mode is not env-enabled here.

This matters for the proposed fix: the two-stage preflight with an inheritance-proof canary is engineered for the silent mode (session 0666d581). Under the hard-error mode, detection is free — the dispatch simply fails — and a canary that costs a real audit fork buys nothing. Any fix must handle both, or state which it targets and why.

Classification and routing — cluster member of #1258

Priority: high, matching the carrier. This is the silent-fabrication exposure, and the corrections land on the working tree.

Routed as a decision-cluster member, not a duplicate and not separately human-gated. #1258 (needs-human, work-class: structural) already carries the one open decision this item's core half depends on:

whether the batched form should dispatch forks at all, given the observed behavior, or whether named subagents plus explicit context hoisting is the only shape that works

The stop rule's missing mechanism is the same defect #1258 states as "The runbook's stop rule needs a mechanism, not just a sentence." Answering the carrier's question decides whether a fork-availability preflight is the right shape at all. Linked via a native blocked-by edge; status: needs-decision applied, and no per-member needs-human label (one human touch on the carrier resolves the cluster).

What this item adds beyond the carrier, and what should be read with it when the decision is taken:

1. The sweep-all / setup degraded-mode contradiction — resolvable in either direction the carrier decides.
2. The retry-rule gap: a returned ledger without inheritance proof is not currently a "failure", so "retry only a failed subset, once" misses the actual exposure.
3. Both observed failure modes above.

Role-label warning: this repository's .work-item-tracker.json has a config block with no role_labels entry, so canonical roles resolve to the plugin defaults (agent-ready / needs-human). Both default labels exist live in this repo, but the resolution is a default, not a declared binding.

[kyle-sexton]

This was generated by AI during triage.

blocked by #1258 decision — native blocked-by edge applied. Per the decision-cluster rule this member carries no needs-human label of its own; resolving the carrier's decision unblocks the cluster in one human touch. Rationale in the triage comment above.

[kyle-sexton]

Plugin-quality audit finding (interactive session, human-confirmed before posting) — corroborating evidence for this issue, not a new report.

Independent evidence from /plugin-quality:audit on discipline:sweep-all, grounded against current official docs (fetched 2026-07-26):

1. The skill's own claimed fork-unavailable fallback is unverified and contradicted by two distinct observed failure shapes.

SKILL.md's "batched pass" step 1 states: "requesting the fork type falls back to a fresh general-purpose subagent that cannot see the conversation." Real-session evidence (work-items:work-loop cycles 25-26, same day) shows two DIFFERENT shapes, neither matching that claim:

• Named dispatch (Agent({subagent_type: "fork", name: "..."})): silent "Spawned successfully," no error, but zero forks ever delivered a retrievable ledger across 8 agents.
• Identical call minus name:: hard error Agent type 'fork' not found (fork absent from the enumerated available-agents list).

https://code.claude.com/docs/en/sub-agents documents the staged-rollout gate and CLAUDE_CODE_FORK_SUBAGENT, and covers the silent-general-purpose-fallback case only when NO type is specified — it does not document what happens when fork is explicitly requested while fork mode is off. The skill's own stated fallback for that explicit-request case doesn't match either observed shape.

2. Step 2 ("Collect every ledger") doesn't specify the delivery mechanism, and the evidence shows the wrong one being used.

Per https://code.claude.com/docs/en/sub-agents.md: "A background subagent's results reach Claude as a completion notification in a later turn... if you ask about progress first, it reports that the subagent is still running." The evidence shows ~10 follow-up SendMessage queries attempting to retrieve results — polling instead of waiting for the documented delivery.

3. Root-cause candidate for why polling never worked: SendMessage to a named agent resumes it, it does not retrieve a delivered result.

Per https://code.claude.com/docs/en/tools-reference (SendMessage row): sending to a named agent "auto-resumes [it] in the background without a new Agent invocation." If the 8 forks' actual completions were the idle_notifications that got discounted as noise, each follow-up SendMessage would predictably just re-trigger more idling rather than surface a result — which matches the observed pattern exactly (repeated idle pings, never content).

Cost evidence: the skill's own gotchas cite ~170K tokens/fork, ~1.4M for an 8-in-scope pass. The named-dispatch attempt very likely paid close to that full cost for zero retrieved findings.

Cross-check flag: a WebFetch summarized read of the sub-agents doc initially reported CLAUDE_CODE_FORK_SUBAGENT as undocumented; a raw-markdown re-fetch found it documented correctly. Worth noting as a general research-verification gotcha, unrelated to this skill specifically.

Suggested remediation, cheapest → most ambitious (not applied, this is evidence only):

1. Correct the "falls back to a fresh general-purpose subagent" sentence — the actual failure shape for an explicit fork request while unavailable is unconfirmed/observed to vary, not a documented silent fallback.
2. State in step 2 that fork results arrive as background completion notifications in a later turn (cite the doc), not a value to poll for via SendMessage.
3. Canary dispatch: fan out ONE fork first, confirm a retrievable result arrives, before committing the remaining N-1 — bounds worst-case spend to ~170K tokens instead of ~1.4M.
4. Pin CLAUDE_CODE_FORK_SUBAGENT explicitly via consumer settings.json env rather than relying on the unset staged-rollout bucket (which has no documented client-observable signal) — natural home is discipline:setup's existing config report.

Full findings: this audit's evidence/findings packets (session-local, not attached — ask if useful).