bullswarm 0.19.0 → 0.21.0

package/AGENTS.md

@@ -57,18 +57,21 @@ bullswarm workflow runs delete <shortId> --yes
 ## Using bullswarm from another agent
 
 If you are an agent that wants to offload bounded work via bullswarm,
-read `skill/SKILL.md` — that's the agent-facing user guide. It covers
-when to reach for `run` vs `workflow draft`, the verify-step pattern,
-how to write prompts that pass the content gate, and the failure modes
-you'll hit. The skill is published alongside the package and is the
-canonical reference for the CLI surface.
+read `skill/SKILL.md` — that's the agent-facing user guide. Use
+`bullswarm delegate` (or the installed `/bullswarm` skill) by default: it
+previews whether one bounded agent or an autonomous workflow is appropriate,
+shows the conceptual plan, and executes the chosen engine. Reach for `run`,
+`workflow goal`, or a fixed workflow graph directly only when the caller has
+already chosen that execution shape. The skill is published alongside the
+package and is the canonical reference for the CLI surface.
 
 - Zero runtime dependencies. Node >= 18. Tests must never require network:
   prime `~/.bullswarm/meters/*.json` caches with fresh timestamps if needed.
 - Every verb must work non-interactively (no TTY). The interactive wizard is
   a human convenience, never a requirement.
 - Version single source: package.json. Release via
-  `node bin/bullswarm.js release patch|minor|major` then `git push --tags`
+  `node bin/bullswarm.js release patch|minor|major`, then `git push` and
+  `git push --tags`
   — CI publishes through npm trusted publishing (OIDC), no tokens.
 
 ## Adding a connector

package/CHANGELOG.md

@@ -1,5 +1,99 @@
 # bullswarm changelog
 
+## 0.21.0 — unified TUI shell and LLM-first delegation
+
+- The interactive workflow viewer is now one application shell instead of
+  several screens with their own rules. The workflows list, a run, a phase and
+  an agent are four depths of one hierarchy: every screen carries the same
+  persistent breadcrumb at the top (`Workflows › hdtdxs · timeline-segments ›
+  Verify › verify-renderer`), which drops its deepest segments first when the
+  terminal is too narrow to hold the whole path. All four depths share key
+  bindings generated from a single key-map definition: Up/Down (or k/j) move
+  within the current level, Enter and Right (or l) go one level in, Esc and
+  Left (or h) go one level out, and Tab/Shift+Tab jump to the next or previous
+  workflow, re-entering the sibling at the same depth when the equivalent phase
+  exists. The drill-down layout is uniform too — a left sidebar listing the
+  current level beside a right pane previewing the highlighted item — at every
+  depth and on narrow terminals as well, including the run list, which was a
+  full-width table with no preview pane before.
+
+- Workflow timelines now render in phase-segmented sections with continued
+  headers for interleaved phases, grouped Preflight scout/planner milestones,
+  elapsed or running phase state, and consistent desktop, narrow, and scroll
+  continuation behavior without per-line phase prefixes. Phase-completion
+  summary rows are retained, so rows such as `└─✓ completed 4/4` remain visible
+  beneath their phase headers.
+
+- Non-interactive `workflow tui <run-id>` output now includes the same static
+  segmented timeline as the interactive viewer, alongside the historical detail
+  tree, so real command output can be used to inspect and verify the layout.
+
+- Documentation now describes concerns as an attribute of a completed
+  outcome — `outcome.concerns` on a delivered result — rather than
+  presenting `completed_with_concerns` as its own terminal status to handle
+  separately from `completed`. Run records that carry the
+  `completed_with_concerns` status value, including legacy runs recorded
+  before this framing, remain fully readable: `runs result`, the TUI, and
+  `workflow watch` still read it exactly like `completed` — a delivered
+  result with concerns to review, never a failure.
+
+- Delegation classification now starts with deterministic signals and, in
+  automatic execution, lets an LLM refine the choice between a single delegate
+  and a workflow. `--dry-run` performs that same bounded low-effort
+  classification request (one analyze-lane, low-effort dispatch) before
+  printing the plan, so the preview matches what a live run would decide — it
+  never dispatches the work itself. `--classify deterministic` bypasses that
+  refinement and remains the instant, no-dispatch preview; `--classify llm`
+  requires the refinement and fails if no usable LLM decision is available.
+  An explicit `--mode single|workflow` remains the caller's choice and bypasses
+  automatic LLM classification.
+
+- OpenCode connector portability: `connectors/opencode2.json` no longer
+  hardcodes `--model kaihk/gpt-5.6-luna` in `spawn.cmd`. A plain OpenCode
+  install with no KaiHK provider configured now dispatches with OpenCode's
+  own default model instead of failing to resolve a KaiHK-only model.
+  `src/lib/opencode-kaihk.js` still injects the explicit
+  `--model <providerId>/gpt-5.6-luna` for each discovered KaiHK provider, so
+  the primary `opencode2` pool and any extra `opencode2:<id>` pools keep
+  dispatching with their pinned per-provider model exactly as before.
+
+## 0.20.0 — common agent delegation entry point
+
+- `/bullswarm` and `bullswarm delegate` now give agents one transparent entry
+  point for arbitrary self-contained tasks: classify the request as one bounded
+  delegate or an autonomous workflow, show the reason and conceptual plan, then
+  execute the selected engine. Explicit mode and lane overrides remain
+  available, and `--dry-run --json` exposes the decision after its bounded
+  classification request without dispatching the work itself.
+- Workflow decisions persist the suggested conceptual plan alongside the
+  original intent, while the packaged skill keeps the common path concise and
+  moves operational detail into a focused reference.
+- Planner context now labels the preflight scout as completion-ineligible and
+  requires the first program to contain a real delivery worker plus its
+  verifier, preventing an apparently complete scout report from causing a
+  rejected completion and redundant recovery round.
+- Ready siblings now honor a connector-owned soft concurrency preference. The
+  OpenCode route prefers one in-flight worker, so additional parallel work is
+  spread across healthy subscriptions instead of risking correlated headless
+  session exits; a lone eligible pool still runs rather than failing capacity.
+- Agent integration upgrades its managed awareness marker to advertise the
+  common interface consistently across Codex, Claude, and Grok.
+- Classification now understands negated and instructional mutation language,
+  so read-only requests that discuss how to add or write something do not
+  accidentally enter the build lane, while a later affirmative implementation
+  request still does.
+- A trailing `help` token remains contextual and side-effect-free even after
+  options, matching `-h` and `--help`; several README and setup/help examples
+  were also brought back into sync with the real CLI.
+- Historical workflow design documents now identify themselves as dated
+  implementation records and list the current `verify`, `decide`, and
+  `outputSchema` surfaces instead of presenting resolved gaps as current.
+- Extra KaiHK providers in `~/.config/opencode/opencode.json` (`kaihk-2`, …)
+  become `opencode2:<id>` pools, spawned with `--model <id>/gpt-5.6-luna`.
+  Spend is read from `GET /api/usage/token` plus
+  `/v1/dashboard/billing/usage` (USD = `total_usage / 100`). The HTML wallet
+  page still needs a browser session and is not the key API.
+
 ## 0.19.0 — unified workflow dashboard
 
 - Running `bullswarm workflow` on an interactive terminal now opens one

package/README.md

@@ -5,6 +5,11 @@ orchestrator, build and expand the plan, route bounded worker actions by quota,
 verify the result, and finish without an initiating agent authoring a graph.
 Every delegate output is judged by content before it counts.
 
+For agents, `/bullswarm` (or `$bullswarm` where skills use that syntax) is the
+common entry point. Its durable CLI equivalent is `bullswarm delegate`: it
+first explains whether the request needs one bounded agent or an autonomous
+workflow, shows the conceptual plan, and then executes the selected engine.
+
 Every command and nested subcommand supports contextual `-h` / `--help`
 without initializing state or executing the command:
 
@@ -66,6 +71,9 @@ bullswarm          # first run: interactive setup wizard
 bullswarm setup    # re-run or repair
 bullswarm pools    # meter state, pace position, quarantine status
 bullswarm strategy refresh --apply --yes  # approve capability-aware tier autopilot
+bullswarm delegate --cwd ~/some-repo --prompt "Explain the parser"            # one agent
+bullswarm delegate --cwd ~/some-repo --prompt "Audit all commands, fix help, and independently verify"  # workflow
+bullswarm delegate --dry-run --json --cwd ~/some-repo --prompt "Your task"     # bounded classification + decision/plan; no work dispatch
 bullswarm run --lane analyze --add-dir ~/some-repo --task-file /tmp/t.md --json
 bullswarm run --lane analyze --add-dir ~/some-repo --prompt "Inspect the parser" --json
 bullswarm workflow goal "Fix the failing tests and verify the change" --cwd ~/some-repo
@@ -78,6 +86,7 @@ bullswarm health   # re-judge saved outputs; catch gate failures
 |---|---|
 | `setup` | Discover installed agent CLIs, show quota state, toggle pools, suggest a routing table, write config. Approval-gated, idempotent. |
 | `integrate` | Register or remove the canonical Bullswarm skill and global awareness rules for Codex, Claude, and Grok. |
+| `delegate` | Explain and execute the smallest reliable shape: one content-verified agent or an autonomous verified workflow. |
 | `run` | route → dispatch → watch → verify → one JSON verdict |
 | `health` | Re-judge saved outputs against their verdicts; surface verify-gate failures and quarantine clusters |
 | `pools` | Show each pool's meter state, pace position, quarantine status |
@@ -85,6 +94,22 @@ bullswarm health   # re-judge saved outputs; catch gate failures
 | `doctor` | Machine-readable readiness report; self-heals on first call |
 | `workflow` | Start an autonomous goal, or run / validate / draft / inspect explicit workflows and their live instances. |
 
+### Delegate classification
+
+With the default `--mode auto`, `delegate` first uses deterministic task
+signals, then uses an LLM to refine the choice between a single delegate and a
+workflow during execution. If that optional refinement is unavailable or
+unusable, automatic mode uses the deterministic decision.
+
+Use `--classify deterministic` to bypass the LLM refinement — this is the
+instant, no-dispatch preview. Use `--classify llm` when an LLM decision is
+required: the command fails if it cannot obtain a usable one. In automatic
+mode, `--dry-run` still performs that same bounded low-effort classification
+request (one analyze-lane, low-effort dispatch) and prints the resulting
+decision — it never dispatches the work itself. An explicit `--mode single` or
+`--mode workflow` is the caller's decision and bypasses automatic LLM
+classification.
+
 Discover and validate workflow definitions without executing them:
 
 ```bash
@@ -204,7 +229,18 @@ bullswarm workflow goal "Implement and verify the change" --cwd . \
 The worker lock covers the scout, ordinary runs, fan-out items, repairs,
 re-verification, and runtime extraction helpers. A pool that cannot guarantee
 the requested model is ineligible rather than silently substituting another
-model. `--max-agents` and `--max-workflow-seconds` are
+model.
+
+The `opencode2` connector itself does not require a KaiHK provider: its base
+spawn command carries no hardcoded model, so a plain OpenCode installation
+dispatches with OpenCode's own configured default. When
+`~/.config/opencode/opencode.json` has one or more KaiHK providers configured,
+Bullswarm discovers them and pins an explicit `--model <providerId>/gpt-5.6-luna`
+per provider — the first as the primary `opencode2` pool, each additional one
+as its own `opencode2:<id>` pool — which is what the `--worker-model
+kaihk/gpt-5.6-luna` example above locks onto.
+
+`--max-agents` and `--max-workflow-seconds` are
 advisory planning targets; `--max-expansion-rounds` is also an advisory
 convergence target. Hard structural safeguards are adjusted with
 `--max-actions` and `--max-items-per-expansion`.
@@ -227,7 +263,7 @@ bullswarm workflow draft phase add audit-code discover
 bullswarm workflow draft phase add audit-code review
 bullswarm workflow draft step add audit-code discover list-files \
     --type run --lane chore --prompt "List every .js file in src/" \
-    --addDir '{{inputs.targetDir}}'
+    --add-dir '{{inputs.targetDir}}'
 bullswarm workflow draft step add audit-code review per-file \
     --type fanout --items-from 'outputs.list-files.outFile' \
     --lane analyze --concurrency 2 \
@@ -440,11 +476,16 @@ rather than discarding the run as a blanket failure. Delegates have no
 implicit wall-clock timeout; set a step's `timeoutSec` (or direct-run
 `--timeout`) only when an operator explicitly wants a hard termination timer.
 
-An autonomous `complete` remains strictly verified. A planner `stop` produces
-`completed_with_concerns` when a useful delivery exists, including unresolved
-verification concerns and the stopping reason; it produces `blocked` only
-when no useful delivery exists. `workflow runs result` treats the qualified
-delivery as ready while reporting `verified:false`.
+An autonomous `complete` remains strictly verified. A planner `stop` still
+delivers a completed outcome when a useful delivery exists: unresolved
+verification concerns and the stopping reason ride along as `outcome.concerns`
+and `outcome.reason`, attributes of that completed outcome rather than a
+separate terminal status. `stop` produces `blocked` only when no useful
+delivery exists. `workflow runs result` treats the completed outcome as ready
+while reporting `verified:false`. The status value `completed_with_concerns`
+still appears on some runs — including legacy ones recorded before this
+framing — and every consumer reads it exactly like `completed`: a delivered
+result with concerns to review, never a failure.
 
 The planner returns versioned JSON. It may propose `needs_more_work` with
 bounded `run`, inline-`fanout`, or `verify` actions. The deterministic runtime

package/bin/check-output-schema.js

@@ -0,0 +1,30 @@
+#!/usr/bin/env node
+
+import { readFileSync } from 'node:fs';
+import { isValidOutputSchema, validateAgainstSchema } from '../src/workflow/schema.js';
+
+function argValue(name) {
+  const index = process.argv.indexOf(name);
+  return index >= 0 ? process.argv[index + 1] : null;
+}
+
+const schemaPath = argValue('--schema');
+const valuePath = argValue('--value');
+if (!schemaPath || !valuePath) {
+  console.error('Usage: check-output-schema --schema <schema.json> --value <candidate.json>');
+  process.exit(2);
+}
+
+try {
+  const schema = JSON.parse(readFileSync(schemaPath, 'utf8'));
+  const value = JSON.parse(readFileSync(valuePath, 'utf8'));
+  const schemaValidity = isValidOutputSchema(schema);
+  const result = schemaValidity.ok
+    ? validateAgainstSchema(value, schema)
+    : { ok: false, errors: schemaValidity.issues };
+  process.stdout.write(`${JSON.stringify(result)}\n`);
+  process.exit(result.ok ? 0 : 1);
+} catch (error) {
+  process.stdout.write(`${JSON.stringify({ ok: false, errors: [error.message] })}\n`);
+  process.exit(1);
+}

package/connectors/opencode2.json

@@ -3,7 +3,7 @@
   "bin": "opencode",
   "configDirs": ["~/.config/opencode"],
   "spawn": {
-    "cmd": ["opencode", "run", "--auto", "--model", "kaihk/gpt-5.6-luna", "{taskFile}"],
+    "cmd": ["opencode", "run", "--auto", "{taskFile}"],
     "cwdMode": "pwd",
     "$comment-cwdMode": "QUIRK: resolves its project from $PWD, not the spawn cwd. The watcher MUST set env.PWD and spawn with cwd inside the target repo, or it will silently analyse the wrong repository and answer confidently about it."
   },
@@ -21,10 +21,12 @@
       { "match": { "path": "type", "equals": "text" }, "path": "part.text", "mode": "concat", "separator": "\n" }
     ]
   },
-  "$comment-auto": "--auto is required for headless workflow dispatch: task files live under ~/.bullswarm, outside the target repo, and OpenCode otherwise pauses for an interactive permission approval. --model pins the QA/runtime pool to Luna instead of the CLI default.",
+  "$comment-auto": "--auto is required for headless workflow dispatch: task files live under ~/.bullswarm, outside the target repo, and OpenCode otherwise pauses for an interactive permission approval. The base connector intentionally leaves --model unset so a plain OpenCode installation uses its own default; opencode-kaihk.js adds --model <providerId>/gpt-5.6-luna only for discovered KaiHK providers, after which modelSelection can replace it for assignments and step locks.",
   "$comment-exit1": "known failure mode: writes a complete correct answer, then dies with a Console-sync auth error and exit 1. The verdict sets contentUsableDespiteExit instead of discarding the work.",
   "meter": { "type": "none" },
   "costRank": 1,
+  "preferredConcurrency": 1,
+  "$comment-preferredConcurrency": "OpenCode's shared local/provider session can terminate sibling headless runs together under parallel load. Prefer one in-flight OpenCode worker and route other ready siblings to healthy pools; if no alternative is eligible, availability wins and OpenCode may still be used.",
   "lanes": ["analyze", "build", "chore"],
   "capabilities": ["strong-analysis", "code-reading", "file-editing", "workflow-planning"],
   "modelDiscovery": { "cmd": ["opencode", "models"], "parse": "lines", "includePattern": "^[^\\s]+/[^\\s]+$", "timeoutMs": 20000, "maxModels": 250 },

package/docs/claude-dynamic-workflow-mechanics.md

@@ -13,6 +13,8 @@ Every statement is tagged:
   (`docs/experiments/2026-08-29-ultracode-vs-bullswarm.md`).
 - **[INFERRED]** — my reading of how the harness must behave to satisfy the
   spec. Not confirmed by source; treat as a hypothesis.
+- **[IMPLEMENTED]** — behavior shipped in Bullswarm and backed by its source
+  and regression suite, rather than a claim about Claude's workflow contract.
 
 ## 0. The one-paragraph shape
 
@@ -349,7 +351,7 @@ author and the `Workflow` runtime.
    exist — the script's `while (!ok)` loop *is* the evidence — which is the
    general lesson: every piece of control flow bullswarm moves from planner
    into runtime needs its evidence rule moved with it.
-11. **[SPEC] Schema-enforced worker output** — a planner `run` action or fan-out
+11. **[IMPLEMENTED] Schema-enforced worker output** — a planner `run` action or fan-out
     `stepTemplate` may declare an object-typed `outputSchema` subset. The
     runtime appends instructions for one trailing matching JSON object, with no
     prose or markdown fences after it, then parses and validates the object.
@@ -363,7 +365,10 @@ author and the `Workflow` runtime.
     fields, and `fanout.itemsFrom` can consume `outputs.<id>.data.items` without
     extraction when it is already an array. Planner decision validation rejects
     `outputSchema` on a proposed `verify` because verify has a fixed verdict
-    shape.
+    shape. Schema-backed dispatches suppress ordinary same-pool retries so the
+    schema contract gets exactly its one bounded correction attempt. On resume,
+    a fan-out item is skipped only when both its verdict and declared schema
+    are satisfied; the schema must be declared on `stepTemplate.outputSchema`.
 
 **Honest limitation.** `itemsFrom` removes the planner *turn*, not the stage
 *barrier*: a verify depending on a data-driven fan-out waits for all items,

package/docs/dynamic-workflow-handoff.md

@@ -1,4 +1,4 @@
-# Bullswarm Dynamic Workflow Handoff
+# Bullswarm Dynamic Workflow Handoff (Historical)
 
 **Purpose:** iteration brief for making bullswarm's workflow system behave like
 Claude Code's dynamic workflows while preserving bullswarm's provider routing,
@@ -6,8 +6,10 @@ quota pacing, content verification, and agent-friendly CLI contracts.
 
 **Audience:** the next implementation agent.
 
-**Status:** build target, based on repository inspection, real OpenCode/Luna QA,
-and a Fleetlens inspection of Claude workflow telemetry.
+**Status:** historical implementation brief from 2026-08-21. The gaps and task
+list below describe the state at that date; they are not a current capability
+matrix. For current behavior use `README.md`, `skill/SKILL.md`,
+`docs/claude-dynamic-workflow-mechanics.md`, and the contextual CLI help.
 
 ## Executive Summary
 
@@ -23,10 +25,12 @@ understand request
   -> repeat until complete
 ```
 
-Bullswarm currently has a validated JSON plan, sequential phases, dynamic
-fan-out, retries, escalation, verification, resume, and a basic dashboard. It
-does not yet have the central `observe -> decide -> schedule` loop. Its graph
-is fixed after validation; only a fan-out's item count can expand at runtime.
+Bullswarm now has the control loop this brief proposed: a durable orchestrator
+observes completed work, proposes a bounded program, deterministic validation
+accepts or rejects it, and the runtime schedules ready actions before the next
+checkpoint. Static JSON workflows remain supported alongside zero-graph
+`workflow goal` execution. The rest of this document preserves the historical
+evidence and build rationale that led to that implementation.
 
 The target is not an uncontrolled mutable DAG and not an LLM that owns the
 runtime. The target is a hybrid:
@@ -235,6 +239,8 @@ Supported step types:
 - `run`: one delegate invocation.
 - `fanout`: one delegate invocation per item.
 - `verify`: a skeptical review of a prior output artifact.
+- `decide`: a durable adaptive planning gate whose proposal is validated before
+  any new action is appended or executed.
 
 The implementation is mainly in:
 
@@ -276,8 +282,19 @@ A later step can reference them with templates:
 {{outputs.previous.pool}}
 {{outputs.previous.outputText}}
 {{outputs.previous.outFile}}
+{{outputs.previous.data.field}}
 ```
 
+For a structured `run`, declare an object `outputSchema` when a later step
+needs typed data. The successful state record contains `data` and
+`schemaOk: true`; after the single schema correction retry fails it retains the
+output text and contains `schemaOk: false` and `schemaErrors`. A schema retry is
+observable as `action.output_schema_retry`, followed by
+`action.output_validated` only when the corrected object passes validation.
+The task also supplies an exact local schema-preflight command. The worker uses
+it on a temporary candidate before replying, while the runtime independently
+revalidates the captured response before exposing `data` downstream.
+
 A fan-out can use a prior output file as its item source:
 
 ```json
@@ -290,8 +307,13 @@ A fan-out can use a prior output file as its item source:
 }
 ```
 
-The runtime reads the referenced file and parses a JSON array. This is dynamic
-item expansion, not dynamic workflow graph expansion.
+The runtime first consumes an already-recorded array such as
+`outputs.discover.data.items`. For the legacy `outputs.<id>.outFile` form it
+reads the referenced file and parses a JSON array. This is dynamic item
+expansion, not dynamic workflow graph expansion. Fan-out schemas belong on
+`stepTemplate.outputSchema`; each item stores its own `data`, `schemaOk`, and
+possible `schemaErrors`, and resume re-runs only items whose verdict or schema
+is incomplete.
 
 ### Routing and model selection
 
@@ -335,6 +357,7 @@ Bullswarm currently has:
 - Recursion-depth propagation and guard
 - Resume of successful steps
 - Fan-out resume by item fingerprint
+- Structured worker output with one schema retry and durable schema state
 - Cooperative cancellation through `state.json`
 - Heartbeats during long dispatches
 - Basic interactive dashboard
@@ -346,6 +369,7 @@ Bullswarm currently has:
 bullswarm doctor --json
 bullswarm workflow capabilities --json
 bullswarm workflow inspect <file-or-name>
+bullswarm workflow runs result <shortId> --json
 bullswarm workflow tui --json
 bullswarm workflow tui --json <shortId>
 bullswarm workflow tui --json --cancel <shortId>
@@ -360,7 +384,14 @@ bullswarm workflow inspect <file-or-name>
 bullswarm workflow tui --json
 ```
 
-## 3. Important Gaps, Ordered by Priority
+## 3. Historical Gaps, Ordered by Priority
+
+This section is an as-built checklist from the original handoff. The adaptive
+decision loop, bounded graph expansion, structured decisions, attempt ledger,
+ordered event log, cancellation, and timeline/dashboard surfaces described
+below are implemented now. The past-tense gap text is retained so reviewers can
+trace requirements to the resulting runtime and tests; it must not be read as
+current product status.
 
 ### P0: no observe-plan-execute loop
 

package/docs/dynamic-workflow-qa.md

@@ -94,6 +94,19 @@ the internal `review` artifact path. Bullswarm now deterministically infers that
 path for a verifier with one dependency and always appends the required JSON
 verdict contract. This is deliberately runtime knowledge, not caller steering.
 
+## Structured Output Evidence
+
+For an optional object `outputSchema` on a `run`, the runtime appends the
+contract to the worker prompt, parses the trailing object, and allows exactly
+one schema correction retry. The durable `state.json` record exposes
+`outputs.<id>.data` and `schemaOk`; a failed correction retains `schemaErrors`
+and the output text. Fan-out item records use the same fields under
+`outputs.<fanoutId>.items[]`. Offline regressions in
+`tests/workflow-adaptive.test.js` and `tests/workflow-gaps.test.js` verify retry
+events, persisted state, resume behavior, downstream rendering, and data-backed
+fan-out. The stable result envelope returns the durable artifact content; typed
+worker data remains inspectable in `state.outputs.<id>.data`.
+
 ## Acceptance interpretation
 
 - Provider output is accepted by content verification, never by exit status alone.

package/docs/experiments/2026-08-29-dogfood-bullswarm-builds-bullswarm.md

@@ -389,3 +389,165 @@ defect), every repair prompt says to edit only the reviewed work's files and nev
 requires one owner per file including an existing test the change breaks, and the validator line states run-wide id
 uniqueness. Direction from the user: "unless it is completely nonsense or unable to finish I don't see a reason to
 reject so easily". Claim to test on the next rerun: none of the three `8ebi8a` rejection reasons can produce ok:false.
+
+## Run `5cvj72` — bullswarm 0.20.0 builds bullswarm's next release (2026-08-31, real repo, installed runtime)
+
+Goal: (R1) remove the hardcoded `kaihk/gpt-5.6-luna` from `connectors/opencode2.json` while keeping KaiHK per-provider
+model injection, (R2) LLM-refined delegation classification on top of the deterministic guess, (R3) docs, (R4) full
+suite green. Launched through `bullswarm delegate` itself (dry-run preview → executed pinned `--mode=workflow`).
+
+Result: **13 min 58 s** (838 s), 1 planner turn (73 s, 8.7 %), 12 dispatches, parallelism 1.69, max 3 concurrent,
+9-action program (3 implementers ∥ → 3 unit verifies covering R1–R3 → suite verify covering R1–R4), auto-completed
+`completed_with_concerns` (1 informational concern), 388/388 tests — verified independently by the operator.
+
+Reliability events, all self-healed: `update-documentation` on claude-code/sonnet-5 failed the output substance gate
+("announcement without substance") → escalated to codex/gpt-5.6-terra, succeeded. `verify-classifier` rejected once —
+legitimately under the lenient bar (R2 demanded BOTH reasons in the decision; `refineDecision()` dropped the
+deterministic one; the focused tests themselves passed 18/18) — one repair round fixed it, re-verify accepted. The
+coverage-evidence flip fired only alongside that real concern; no false rejection this run.
+
+Routing: soft `preferredConcurrency:1` spillover worked as designed — 9/12 dispatches on `opencode2 kaihk-2/gpt-5.6-luna`
+(the all-tier assignment), while parallel siblings spilled to claude-code (fable-5 for `implement-classifier`,
+sonnet-5 for the failed docs attempt) and codex (terra). Note: the per-pool assignment pins the model only on its own
+pool; spillover pools use their connector default, so a luna-only run needs either per-pool assignments or no
+concurrent siblings.
+
+Post-run verification by the operator: repo connector via a temp home — KaiHK off ⇒ `["opencode","run","--auto",
+"{taskFile}"]` (no `--model`); KaiHK on ⇒ `--model kaihk/gpt-5.6-luna`, `kaihk-2/…`, `kaihk-3/…` injected per provider.
+Live `--classify=llm` end-to-end: decision came back `source: llm-classifier` with both reasons and a sensible verdict.
+Two observations recorded, not fixed: (a) `--dry-run` never consults the LLM, so the canonical skill flow
+(dry-run preview → pinned re-execute) exercises only the deterministic classifier; (b) the substance gate rejected a
+correct 16-char answer ("bullswarm 0.20.0") from the tiny smoke delegation — legitimately terse outputs still fail the
+40/80-char floors. Installed homes keep the old connector until a setup upgrade copies the new file.
+
+## Run p3jbha — always-LLM classification + cross-agent integration audit (2026-08-31)
+
+Goal (4 numbered requirements): make the LLM the deciding classifier for every auto-mode
+`delegate` call including `--dry-run` (deterministic stays as the pre-pass hint fed into the
+LLM prompt); make LLM fallback visible in the envelope instead of silent; update every doc
+that claimed dry-run was deterministic-only; write a read-only cross-agent integration audit
+for Claude/Codex/Grok. Launched through the **repo binary at 8908ef8** (installed 0.20.0
+predates the LLM classifier) via the canonical flow: `delegate --dry-run` preview → pinned
+`--mode=workflow`. Before launch: `claude-fable-5` added to `strategy exclude-model`
+(recorded no-Fable pref; last run's spillover violation), and three dangling
+`bullswarm.broken-20260830` symlinks removed from all three CLIs' skill dirs.
+
+**Preview accuracy specimen:** the deterministic classifier scored the goal correctly
+(workflow, score 7) but the phrase "read-only cross-agent integration audit" tripped
+`READ_ONLY_LABEL_RE`, so `hasMutationIntent` returned false and the suggested plan dropped
+its Execute phase entirely (Inspect→Verify→Deliver for a mostly-code-edit task). A live
+one-regex misfire — exactly the case for LLM-decided classification.
+
+**Outcome: completed_with_concerns (verified: true), auto-completed.** Wall 1,292 s
+(21m32s), attempt-busy 2,050 s, parallelism 1.59, max 3 concurrent, zero quota wait.
+14 dispatches: 2 planner turns (99 s total = 7.7%) + 12 worker attempts. Diff: 6 files
++72/−25 plus the new 411-line audit doc. Independently re-verified by the operator:
+`npm test` 389/389; live `--dry-run` auto → `source: llm-classifier` in 23.6 s with the
+deterministic sub-object preserved; `--dry-run --classify=deterministic` → 0.12 s, no
+dispatch.
+
+**Routing:** implement/verify work on opencode2 (kaihk-2/gpt-5.6-luna); docs on
+claude-code/claude-sonnet-5; the audit on claude-code/claude-opus-5 (822 s, the critical
+path). The only "fable" string in the run state is the exclusion entry itself — the
+mitigation held.
+
+**Reliability tally — 3 ok:false verdicts, 1 genuinely earned:**
+1. `verify-integration-audit` round 1: legitimate — the audit really ended with the
+   command appendix and lacked the required recommendations section; repair added §7
+   (five evidence-linked recommendations).
+2. `verify-documentation` round 1: cross-ownership overreach — it rejected R3's docs
+   because R4's `docs/integration-audit-2026-08-31.md` (owned by a *different, still
+   running* action, 822 s) did not exist yet. Under the runtime's lenient acceptance
+   standard, later-scheduled work and other actions' files are concerns, not rejections.
+3. `verify-integration-audit` re-verify after repair: **factually false** — it claimed
+   "no concrete recommendations appear at the end" and cited lines 384–411 as the final
+   section, while the repaired file (mtime 05:01:14Z, before the verifier started at
+   05:01:50Z) held §7 Recommendations at lines 345–383. The verifier anchored on its
+   previous verdict instead of re-reading. This exhausted maxRounds=1, failed the action,
+   blocked `verify-suite`, and forced planner turn 2 — which proposed a fresh
+   `verify-completion` that passed all four requirements with line-level evidence, then
+   auto-completed. Recovery cost ≈ 2 min of wall time.
+
+**Observations recorded, not yet fixed:** (a) re-verify verdict anchoring — the reverify
+prompt could require the verifier to re-read the changed files and address the repair's
+report before repeating a rejection; (b) requirement-coverage entanglement keeps making
+verifiers judge files other actions own (second run in a row); (c) the run's own audit
+deliverable found a real product defect: `integrate status` computes skill-link identity
+against the *invoking checkout's* path, so any other valid Bullswarm install reports
+`conflict`/exit 1 and `integrate install` refuses to repair it — stale skill symlinks are
+sticky until removed by hand (see docs/integration-audit-2026-08-31.md §2, §7).
+
+## Run wxfwda — retire completed_with_concerns + two dashboard truthfulness fixes (2026-08-31)
+
+User directive: "having concern is not a problem of bullswarm itself but part of the agent
+lifecycle, I do not think we need to formalize it as a feature" — plus two screenshot
+defects from viewing run p3jbha: permanent ✗ phase marks on a delivered run, and
+"Final Verification · 1/1 complete" over a pane saying "Not started yet" for the
+never-dispatched verify-suite. Launched through the repo binary at f11e544; the preview was
+the **first live canonical-flow use of the always-LLM classifier** — `source:
+llm-classifier` in 20.6 s, agreeing with the deterministic hint (workflow, score 7).
+
+**Outcome: auto-completed, verified: true.** Wall 1,541 s (25m41s), busy 3,110 s,
+**parallelism 2.02** (best of the series), max 4 concurrent, planner 80 s (5.2%),
+15 attempts, zero quota wait. Diff: 11 files +444/−67. Operator-verified: `npm test`
+**394/394** (5 new tests), and both defects proven fixed by rendering the real
+wf-mtgr56l1-167281 run dir with the new code — phase 6 renders `✓ Audit Verification 2/2`,
+phase 7 renders `⊘ Final Verification 0/1` with pane "⊘ verify-suite · never dispatched ·
+blocked by verify-integration-audit", planner panel "! Completed with 5 concerns" from the
+outcome envelope.
+
+**Design as landed:** new runs always terminate `completed` (or blocked/failed/…); the
+qualification lives in `outcome` (`verified`, `bestEffort`, `concerns`, new
+`qualification: 'verified'|'qualified'`). The stage `delivered_with_concerns` and event
+`run.completed_with_concerns` are gone for new runs. `completed_with_concerns` remains
+parse-only for legacy run dirs (the `budget_exhausted` precedent), rendered through the same
+outcome-driven sentences. Dashboard invariants: a delivered run's phase list carries no
+failure marks (attempt rows keep true history; failed/blocked/interrupted runs keep ✗);
+a never-dispatched dependency-blocked action gets `⊘`, is excluded from "N/N complete",
+and its pane names the failed dependency (`outputs[id].dependencyBlocked`, which the real
+runner already writes).
+
+**Reliability tally:** 1 rejection (verify-watcher-compatibility round 1) — cross-ownership
+again: its concerns *praised* the reviewed work (10/10 focused tests, correctly refused to
+touch unowned files) and complained about a missing `// legacy runs` comment in status.js,
+a file the action did not own. Repaired in 36 s, re-verified ok. Third run in a row where
+the only rejections judge files outside the reviewed work's ownership — the
+requirement-coverage entanglement follow-up is now clearly the top reliability fix.
+This run itself was labeled `completed_with_concerns` by the pre-change runtime it ran on —
+expected artifact, not a failed fix; the label class it removes dies with the next release.
+
+## Run hdtdxs — phase-segmented timeline (2026-08-31)
+
+User picked the segmented layout from a three-way mockup (headers on phase boundaries,
+`· continued` on interleave, per-line `[Phase: …]` prefixes dropped, chronology preserved).
+Launched through the repo binary at 5064c0f; preview `source: llm-classifier` in 16.6 s.
+**First run executing on the post-removal runtime: it terminated plain `completed`
+(qualification: qualified, 1 concern) — live validation of the wxfwda status collapse.**
+
+**Outcome: auto-completed, verified: true.** Wall 2,290 s (38m10s), busy 3,038 s,
+parallelism 1.33, max 2 concurrent, planner 214 s across 4 checkpoints + 1 correction
+(9.3%), 23 attempts. Diff: 3 files +440/−49. Operator-verified: `npm test` **400/400**
+(6 new tests) and `node --test tests/workflow-dashboard.test.js` 32/32 — which makes the
+run's single recorded concern (a focused-test failure on the narrow-width continuation
+header) stale by the time of handoff; the repair that closed verify-final-acceptance fixed
+it. Rendering both real run dirs shows 0 `[Phase:` prefixes and correct headers:
+`── Suite ─── 1m08s ──`, `── Verify · continued ─── 16m13s ──`,
+`── Final Acceptance Verify ─── 6m58s ──`; scrolled viewports re-emit a continuation
+header. Non-interactive `workflow tui <runId>` now prints the same segmented timeline
+(added mid-run after a verifier rejected the render evidence as unverifiable).
+
+**Reliability tally — the best verifier showing of the series: 5 rejections, ALL
+legitimate.** verify-renderer r1 (3 stale tests genuinely failing under the acceptance
+command), r2 (narrow variant genuinely still emitted `[Phase:` prefixes), verify-tests r1
+(CHANGELOG entry genuinely missing — this one cascaded: 8 downstream actions
+dependency-blocked across two recovery attempts before planner turn 4 landed the fix),
+verify-final-changelog r1 (the goal's required documentation choice genuinely absent),
+verify-final-acceptance r1 (render evidence genuinely invalid — non-interactive tui had no
+timeline; the repair added it). Zero cross-ownership rejections for the first time in four
+runs. Cost of the cascade: 2 extra planner turns + 1 planner correction (it tried to reuse
+a finished phase name), ~8 min of wall. Routing clean: opencode2/luna everywhere except
+add-tests on claude-code (856 s); the only "fable" string in state is the exclusion entry.
+
+**Cosmetic observations for a later pass:** an empty `── Planner · continued ──` header can
+render with no rows beneath it when its events fall outside the viewport; the top status
+line now reads `· done` for a plain completed run (new wording from the status collapse).