bullswarm 0.27.1 → 0.28.1

package/CHANGELOG.md

@@ -1,5 +1,246 @@
 # bullswarm changelog
 
+## 0.28.1 — summary bytes on the wire, monthly pacing
+
+- `workflow runs result <id> --summary` was budgeted by `fitResultSummary`
+  against compact `JSON.stringify(summary)` (`RESULT_SUMMARY_BYTE_BUDGET =
+  4096` in `src/workflow/v2-outcome.js`) but `jsonOut` printed
+  `JSON.stringify(obj, null, 2)`, so the bytes on the wire exceeded the
+  budget. `--summary` now prints compact single-line JSON
+  (`JSON.stringify(obj)` in `src/workflow/runs-cli.js`); `--json` without
+  `--summary` still pretty-prints the full envelope, and `--summary --json`
+  stays identical to `--summary`. Measured on
+  `tests/fixtures/real-result-ze5xz2.json` through the summariser / CLI:
+  compact `--summary` is 3,786 bytes
+  (`tests/workflow-result-summary.test.js` prints `result-summary size:
+  full=57141 summary=3786`; same figure as
+  `Buffer.byteLength(JSON.stringify(summarizeV2Result(fixture)))`); the
+  full envelope as `--json` prints it is 60,709 bytes
+  (`JSON.stringify(envelope, null, 2)` plus the trailing newline
+  `console.log` adds — `tests/workflow-result-summary.test.js` prints
+  `result-summary cli: prettyFull=60709`).
+
+- Routing paced every pool by `windows.seven_day ?? windows.monthly`
+  (`paceSnapshot` in `src/meters/framework.js`), so command-code — whose real
+  budget is a monthly credit allocation — was paced by its weekly rate-limit
+  window. Live meter, captured 2026-09-09T10:45:28Z and evaluated at
+  2026-09-09T11:09:44.982Z: weekly `used 73.1% elapsed 91.8% surplus +18.7`
+  against monthly `used 79.4% elapsed 75.3% surplus -4.1`, with 14.43 of 70
+  credits left for the 7.66 days to the 2026-09-17T03:06:55Z reset. Routing
+  therefore called it "the most-behind capable pool" and kept sending it work
+  while its monthly budget was already 4.1 points overspent. Pacing is now per
+  pool: `pacingWindowFor({connector, subscription})` resolves
+  `state.strategy.subscriptions[pool].quotaWindow`, then
+  `connector.subscription.quotaWindow`, normalised to `weekly` | `monthly` |
+  `null` (any other label — including a pre-0.28.1 free-text one — is ignored
+  for pacing and keeps the old weekly-first order). `paceSnapshot(snapshot,
+  nowMs, {pacingWindow})` takes `monthly` → `windows.monthly ??
+  windows.seven_day`, `weekly`/`null` → `windows.seven_day ??
+  windows.monthly`, and returns `pacingWindow` naming the window actually
+  used. `src/lib/config.js` `buildPools` resolves the choice once per pool
+  (where the connector and the state both are) and re-paces `usedPct`,
+  `elapsedPct`, `pace` and `paceResetsAt` off `reading.windows`, so cache,
+  stale and live readings are paced identically; the pool view carries
+  `pacingWindow`. The 5h gate is untouched: `command-code` still gates on 5h
+  `25.2%`. Connectors already declared this — `command-code` and the kaihk
+  pools `monthly`, `claude-code`/`codex`/`grok` `weekly`; nothing read it for
+  pacing before.
+- The spend model follows the pacing window. `WINDOW_KEYS` (framework.js)
+  gains `monthly: {snapshot: 'monthly', history: 'monthly', windowMs: null}`,
+  and `rateForWindow` (`src/lib/spend.js`) derives the bootstrap window start
+  with `meta.windowMs ?? monthlyWindowMs(resetsAtMs)` — the calendar month
+  ending at the provider's `resets_at` (M2), never an assumed 30 days.
+  `attachSpend` now writes `pool.spend.monthly` and `pool.projectedMonthlyPct`
+  next to the fiveHour/weekly fields, plus `pool.spend.pacing = {window,
+  ratePerMinute, source, samples}` and `pool.projectedPacingPct` for the
+  window that paces the pool (default `weekly`, so a pool that declares
+  nothing keeps its old numbers). `inflightLoad` (`src/lib/route.js`) charges
+  the in-flight penalty from `spend.pacing?.ratePerMinute ??
+  spend.weekly?.ratePerMinute` with that rate's own source label, so the
+  surplus and the penalty are measured in the same window; candidate rows gain
+  `pacingWindow` and `projectedPacingPct` beside the unchanged
+  `projectedWeeklyPct`.
+- Operator control and display. `bullswarm strategy set-subscription <pool>
+  --quota-window <weekly|monthly>` now selects the window that paces routing
+  (help text in `src/help.js`) and validates it: anything else exits 2 with
+  `--quota-window must be weekly or monthly (or unknown to clear)`, and
+  `unknown` clears the override back to the connector's declaration. Labels
+  already stored are ignored for pacing, never rejected on read. `bullswarm
+  pools` names the window in the meter column — `cmd-fixture    cost=5
+  lanes=chore monthly used 79.4% elapsed 75.3% [cache] surplus=-4.1
+  inflight=0 5h=25.2% ready` — and `pools --json` entries carry
+  `pacingWindow`. `strategy refresh`/`show` print the window on each
+  subscription line (`command-code: GOAT · ... · monthly 79.4% used · surplus
+  -4.1`) and carry `pacingWindow` next to the free-text `quotaWindow` label in
+  `--json`; `strategy inventory --json` carries it per provider.
+- Tests: 738 -> 750, 0 failures. The new behaviour is covered in
+  `tests/meters.test.js` (the live command-code snapshot as a fixture, the
+  helper's precedence, `buildPools` pacing), `tests/spend.test.js` (monthly
+  bootstrap window start, `spend.pacing`/`projectedPacingPct`),
+  `tests/route.test.js` (the penalty on the pacing window; weekly-only pools
+  unchanged), `tests/strategy-cli.test.js` (`--quota-window` validation) and
+  `tests/assignments.test.js` (the `pools` meter column and `--json`
+  `pacingWindow`).
+
+## 0.28.0 — context diet
+
+- `workflow runs result <id> --summary` prints a compact status-loop
+  envelope, `schemaVersion: "bullswarm.workflow.result-summary.v1"`. It
+  carries `runId`, `shortId`, `status`, `verified`, `executionMode`,
+  `reason`, `finishedAt`, the goal's first line trimmed to 120 characters
+  plus `goalBytes`, each requirement as `{ id, status, mandatory,
+  evidenceCount, why }` (`why` is the latest evidence's first line trimmed
+  to 200 characters), each action as `{ id, kind, lane, effort, status,
+  pool, model, reasoning, wallSec, outFile, bytes }`, `concerns: { count,
+  first }` (up to three one-liners), the `usage` block, and `next: { full:
+  "bullswarm workflow runs result <id> --json", outputs: [<outFile paths>]
+  }`. `--summary` implies JSON with or without `--json`; it is not
+  TTY-dependent. The full `bullswarm.workflow.result.v2` envelope is
+  unchanged and stays the default. Read the full envelope on a failed or
+  partial run, or before judging evidence. Flag, help, and example:
+  `src/lib/cli-flags.js`, `src/help.js` (`Usage: bullswarm workflow runs
+  result <shortId|runId> [--json] [--summary]`; `--summary` "print the
+  compact JSON status-loop envelope; implies --json"). A terminal `workflow
+  watch` prints `next: bullswarm workflow runs result <shortId> --json
+  --summary`.
+
+- Byte accounting on every action attempt. `state.attempts[].bytes` is
+  `{ taskFile, authorPrompt, kernel, dependencyInputs, output }` — the task
+  file the kernel wrote, the action's own prompt text as authored, the
+  remainder after subtracting that prompt and any embedded requirement
+  text, the sum of the dependency output files the task points at (0 when
+  there are none; `digestOf` drill-down paths are pointers, not inputs),
+  and the durable out file on completion. The result envelope copies the
+  last attempt's `bytes` onto `actions[]` and totals `usage.bytes: {
+  taskFiles, dependencyInputs, outputs }`. `workflow runs show` appends
+  `in <taskFile>/<dependencyInputs> out <output>` per attempt (the unit
+  fixture prints `in 3.1K/60.8K out 14.8K`); missing values stay blank /
+  null, never guessed. These are UTF-8 byte counts, never tokens.
+
+- `kind: "digest"` (analyze/low) is an extractive condensation of its
+  dependencies' outputs so an expensive consumer reads one artifact
+  instead of many raw out-files. The kernel writes the whole task: quote
+  verbatim (never paraphrase or judge) each source's delivered items,
+  validation numbers, commands and their output, unfinished work, and
+  every shared-file or integrator request; one section per source headed
+  by its absolute output path; no verdicts, no recommendations, no new
+  claims; target at most a quarter of the input bytes or 8 KB, whichever
+  is larger. The author's prompt is focus guidance only. Validation
+  (exit 2 with the reason at `workflow plan validate` and `workflow goal
+  --program`): a digest must depend on at least one action, must have
+  empty `evidenceFor`, owns no files, needs no `affects`. No evidence
+  action may list a digest in `dependsOn` — evidence reads the real
+  artifacts. Consumers that depend on a digest receive, in their
+  dependency artifacts, the digest entry plus `digestOf: [{ actionId,
+  outputFile }]` for each digested source. Use one when three or more
+  writers feed a single integrator, or when a consumer's dependency
+  outputs would exceed roughly 20 KB; never for evidence.
+
+- The planning contract states the kind. `workflow plan contract --json`
+  (`Usage: bullswarm workflow plan contract "<goal>" [--cwd <dir>]
+  [--json]`) returns 16 rules; `rules[5]` lists `digest=analyze/low` in
+  the kind table and `rules[6]` is the extractive digest rule (when to
+  insert one, `digestOf`, empty `evidenceFor` / `ownedFiles`, evidence
+  must not depend on a digest).
+
+- The packaged skill's status loop (`skill/SKILL.md`,
+  `skill/references/operations.md`) now recommends `bullswarm workflow
+  runs result <shortId> --json --summary`. Read the full envelope with
+  `--json` alone when the run is failed or partial, or before judging
+  evidence.
+
+- Measured numbers, each with its command. On the real 0.27.1 build run
+  `ze5xz2` (files under `.diet-inputs/`): `workflow runs result ze5xz2
+  --json` is 60,709 bytes on disk (`wc -c .diet-inputs/real-result-ze5xz2.json`;
+  the same file is `tests/fixtures/real-result-ze5xz2.json`). The 0.28.0
+  goal recorded that envelope's `requirements` as 39,231 bytes and `goal`
+  as 11,009 bytes. Re-measuring the same file: `Buffer.byteLength(goal)` =
+  10,996 (the summary's `goalBytes`) and `JSON.stringify(requirements)` =
+  39,288; compact `JSON.stringify` of the parsed envelope is 57,141.
+  `summarizeV2Result` of that fixture is 3,786 bytes —
+  `tests/workflow-result-summary.test.js` prints `result-summary size:
+  full=57141 summary=3786` (numbers re-measured in 0.28.1). The 0.28.0
+  goal recorded the integrator's inputs as 60,790 bytes; `wc -c` of the
+  seven dependency out-files under `.diet-inputs/` sums to 46,022
+  (out-surface 18,659, out-routing-cleanup
+  10,202, out-state-bugs 7,052, out-docs 6,831, out-dead-kernel 1,377,
+  out-verify-gate 974, out-dead-code 927) and the integrator task file is
+  14,768 (`wc -c .diet-inputs/task-integrate-attempt-1.md`), which
+  together are 60,790.
+
+- Fixture measurement, the same goal run twice under a temporary home
+  (`tests/workflow-context-diet-measurement.test.js`, which prints both
+  lines below). Three writers each padded to a few KB feed one integrator
+  directly, then the same three feed a `kind: "digest"` that feeds the
+  integrator: the integrator's `bytes.dependencyInputs` falls from
+  **12,477 bytes to 63 bytes** (`context diet: integrator dependencyInputs
+  without digest=12477 with digest=63`). The 63 is a floor, not a
+  condensation ratio — the deterministic fixture worker answers with a
+  fixed stub instead of really condensing. The ceiling is the byte target
+  the kernel writes into that digest's own task, **8,192 bytes** for this
+  input, and the test asserts the saving holds at that ceiling too
+  (8,192 < 12,477). The same run's envelopes print as `context diet: run B
+  envelope full=<n> summary=<n>` (the full envelope embeds the temporary
+  home's absolute paths, so its size varies a few bytes between runs; the
+  summary carries one `next.runDir` string plus basenames, so it does not);
+  the deterministic envelope comparison to quote is the real-run fixture
+  above (57,141 full vs the measured summary).
+
+- `workflow capabilities` now reports the closed kind list at
+  `engines.autonomousV2.actionKinds`, cloned from the validator's
+  `KIND_DEFAULTS` rather than hand-listed, so `digest` and every future
+  kind are discoverable by a probing agent
+  (`src/workflow/cli.js`). The planning contract's
+  `program.actionFields.kind` description is derived from the same table
+  (`src/workflow/v2-planner.js`).
+
+- `TIER_LANES` (`src/lib/strategy.js`) excludes kernel-owned kinds from the
+  effort-tier count, so the map stays `{ high: analyze, medium: build,
+  low: chore }`. A digest is a mechanism the kernel writes, not a nature of
+  work that should define which lane a tier routes to; counting it would
+  have flipped low from `chore` to `analyze` on the strength of an action
+  no planner has to reason about. No shipped connector's routing changes
+  either way — all six declare all three lanes.
+
+- The three KaiHK-backed OpenCode pools can now run gpt-5.6-luna at a
+  chosen reasoning level. `connectors/opencode2.json` declares
+  `reasoning: { flag: "--variant", levels: [low, medium, high, xhigh,
+  max], defaults: { high: high, medium: medium, low: low } }` — the same
+  five levels as `connectors/command-code.json`, which fronts the same
+  backend — so rungs for these pools stop printing `— (unsupported)`.
+  opencode only forwards a `--variant` its config declares for that
+  model, so the flag alone would be silently dropped;
+  `expandOpenCodeKaihkConnectors` (`src/lib/opencode-kaihk.js`) therefore
+  sets `env.OPENCODE_CONFIG_CONTENT` on the base pool and on every clone
+  to the variants for that pool's OWN provider id, via the new pure
+  helper `kaihkVariantsConfig(providerId, model = KAIHK_OPENCODE_MODEL)`:
+  `{"provider":{"kaihk-2":{"models":{"gpt-5.6-luna":{"variants":{"low":{"reasoningEffort":"low"},"medium":{"reasoningEffort":"medium"},"high":{"reasoningEffort":"high"},"xhigh":{"reasoningEffort":"xhigh"},"max":{"reasoningEffort":"max"}}}}}}}`.
+  opencode merges that JSON string over the config file, so the API key
+  and everything else in `~/.config/opencode/opencode.json` stays in
+  force. An `OPENCODE_CONFIG_CONTENT` the operator set by hand in the
+  installed connector is never overwritten, on the base pool or on the
+  clones. A medium/max dispatch on `opencode2:kaihk-2` composes
+  `opencode run --auto --model kaihk-2/gpt-5.6-luna <taskFile> --variant
+  max --format json`; a level already pinned in the template is replaced,
+  not duplicated. Per pool:
+  `bullswarm strategy set-rung opencode2 medium --model kaihk/gpt-5.6-luna --reasoning max`,
+  `bullswarm strategy set-rung opencode2:kaihk-2 medium --model kaihk-2/gpt-5.6-luna --reasoning max`,
+  `bullswarm strategy set-rung opencode2:kaihk-3 medium --model kaihk-3/gpt-5.6-luna --reasoning max`.
+  Existing installations pick the block up through
+  `upgradeConnectorMetadata` (`src/setup.js`), which backfills a missing
+  `reasoning` block and leaves a customised one alone. Non-KaiHK opencode
+  installations get no injected variants, so `--variant` is a no-op there
+  rather than an error — recorded in the connector's
+  `$comment-reasoning`.
+
+- Tests: 713 -> 738, 0 failures
+  (`env -u CLAUDE_CONFIG_DIR -u FORCE_COLOR -u NO_COLOR npm test`). Four
+  new files carry the new behaviour: `tests/workflow-bytes.test.js`,
+  `tests/workflow-digest.test.js`,
+  `tests/workflow-result-summary.test.js` (with the
+  `tests/fixtures/real-result-ze5xz2.json` envelope it measures) and
+  `tests/workflow-context-diet-measurement.test.js`.
+
 ## 0.27.1 — audit cleanup
 
 - Deleted the remaining dead symbols the 2026-09-09 audit listed as Tier A:

package/README.md

@@ -51,7 +51,12 @@ detaches safely.
    passing verification.
 2. **Pace by meter.** The scheduling resource is the subscription window:
    elapsed% minus used%, most-behind pool wins. Pace may only promote a
-   *cheaper* pool. Lanes are work-nature, never hard-coded to pools. The
+   *cheaper* pool. Lanes are work-nature, never hard-coded to pools. Which
+   window paces one pool is the subscription window that pool's connector
+   declares (`quotaWindow`: weekly for claude-code, codex and grok; monthly
+   for command-code and the kaihk pools), overridable per pool with
+   `bullswarm strategy set-subscription <pool> --quota-window <weekly|monthly>`
+   — `bullswarm pools` names it in the meter column. The
    5-hour window never paces — it gates: a pool at or above 75% of it is
    chosen only when no eligible pool below that line exists, and one at or
    above 90% is not dispatched at all.
@@ -180,6 +185,25 @@ per pool and tier, so the tier moves off whichever model held it while that
 model keeps its other tiers. Nothing about `state.json` changed shape: rungs are
 a view over `strategy.modelTiers` and `strategy.reasoning`.
 
+The KaiHK-backed OpenCode pools (`opencode2`, `opencode2:kaihk-2`,
+`opencode2:kaihk-3`) express reasoning as opencode's `--variant <level>`, at the
+same five levels as `command-code`. opencode only forwards a variant its own
+config declares for that model, so bullswarm injects them: each pool is spawned
+with `OPENCODE_CONFIG_CONTENT` declaring `low`/`medium`/`high`/`xhigh`/`max` as
+`reasoningEffort` variants of `<providerId>/gpt-5.6-luna`, merged over your
+`~/.config/opencode/opencode.json` (your API keys stay in force). Without that
+injection opencode accepts `--variant` and silently drops it. Set a rung per
+pool, using that pool's own provider prefix:
+
+```bash
+bullswarm strategy set-rung opencode2:kaihk-2 medium \
+  --model kaihk-2/gpt-5.6-luna --reasoning max
+```
+
+If you set `OPENCODE_CONFIG_CONTENT` yourself in
+`~/.bullswarm/connectors/opencode2.json`, bullswarm leaves it alone and injects
+nothing — you own the variants from then on.
+
 The benchmark evidence comes from Epoch AI's benchmarking hub, used under
 CC BY 4.0: Epoch AI, 'AI Benchmarking Hub'. Published online at epoch.ai.
 Retrieved from <https://epoch.ai/benchmarks>. `blended` is the mean of the
@@ -390,12 +414,25 @@ names that nature once and derives them:
 | --- | --- | --- |
 | `mechanical` | chore | low |
 | `io-read` | analyze | low |
+| `digest` | analyze | low |
 | `check` | analyze | medium |
 | `implement` | build | medium |
 | `integration` | build | high |
 | `architecture` | analyze | high |
 | `adversarial-acceptance` | analyze | high |
 
+`digest` is the one kind whose instructions the kernel supplies in full — your
+prompt for it is focus guidance only. It condenses the
+outputs of the actions it depends on — quoting each source's delivered items,
+validation numbers, commands, unfinished work, and requests verbatim, one
+section per source, with no verdicts of its own — so an expensive consumer
+reads one artifact instead of many raw output files, and the digest entry in
+that consumer's dependency artifacts still names every digested source for
+drill-down. Use one when three or more writers feed a single integrator, or
+when a consumer's dependency outputs would exceed roughly 20 KB. A digest must
+depend on at least one action, owns no files, needs no `affects`, and no
+evidence action may depend on one: evidence reads the real artifacts.
+
 Resolution is per field: an explicit `lane` or `effort` on the action wins,
 then the kind table, then an optional program-level `defaults` object — which
 may set only `effort` and `reasoning`, because lane follows the individual
@@ -439,6 +476,7 @@ bullswarm workflow runs show <shortId>
 bullswarm workflow watch <shortId>        # V2: attach, then one line per notable event
 bullswarm workflow watch <shortId> --next # print the next notable event and exit
                                           # relaunch with the --after/--since it prints
+bullswarm workflow runs result <shortId> --json --summary  # compact status-loop envelope once terminal
 bullswarm workflow                         # unified human workflow home
 bullswarm workflow tui <shortId>          # jump directly to one run timeline
 bullswarm workflow tui --json <shortId>
@@ -574,7 +612,8 @@ bullswarm workflow runs --historical --since yesterday --until today
 bullswarm workflow runs --all --from 2026-08-20 --to 2026-08-27
 bullswarm workflow runs --limit 20         # cap the result count
 bullswarm workflow runs show <shortId>     # state + report + summary
-bullswarm workflow runs result <shortId> --json  # stable result for the calling agent
+bullswarm workflow runs result <shortId> --json --summary  # compact status-loop envelope
+bullswarm workflow runs result <shortId> --json            # full envelope (failed/partial, or before judging evidence)
 bullswarm runs show <shortId>              # top-level shorthand
 bullswarm workflow runs delete <shortId> --yes    # remove the run dir
 ```
@@ -591,8 +630,10 @@ Values accept ISO timestamps, local `YYYY-MM-DD` dates, `today`, `yesterday`,
 `tomorrow`, `now`, or relative durations such as `30m`, `24h`, `7d`, and `2w`.
 
 After a workflow reaches a terminal state, agents should consume
-`workflow runs result <id> --json` instead of probing `state.json`, task files,
-or provider-specific output. Autonomous V2 returns the versioned
+`workflow runs result <id> --json --summary` for the status loop instead of
+probing `state.json`, task files, or provider-specific output. Read the full
+envelope with `--json` alone when the run is failed or partial, or before
+judging evidence. Autonomous V2's full document is the versioned
 `bullswarm.workflow.result.v2` envelope with kernel-computed status, fresh
 requirement evidence, per-action status/failure/output files, explicit gaps,
 usage, and verification qualification. New programs include `executionMode:
@@ -608,6 +649,75 @@ otherwise the command returns after printing this handoff.
 Time filters preserve the existing scope, so use `--all` or `--historical` when
 auditing completed runs.
 
+### Context diet
+
+The kernel now measures — and can shrink — what it puts in front of a model.
+These are UTF-8 byte counts, never tokens.
+
+**Status loop.** Poll with `--summary`; it implies JSON (with or without
+`--json`) and prints `schemaVersion: "bullswarm.workflow.result-summary.v1"`:
+`runId`, `shortId`, `status`, `verified`, `executionMode`, `reason`,
+`finishedAt`, the goal's first line (120 characters) plus `goalBytes`, each
+requirement as `{ id, status, mandatory, evidenceCount, why }`, each action as
+`{ id, kind, lane, effort, status, pool, model, reasoning, wallSec, outFile,
+bytes }`, `concerns: { count, first }`, `usage`, and `next: { full, runDir, outputs }` — every output name is a basename inside `next.runDir`.
+`--summary` is single-line JSON (`JSON.stringify`), so the bytes on the wire
+match the 4,096-byte fitter budget. As printed by the CLI on
+`tests/fixtures/real-result-ze5xz2.json`, the compact summary is 3,786 bytes
+and the pretty full envelope (`--json` alone) is 60,709 bytes.
+The full `bullswarm.workflow.result.v2` envelope is unchanged and remains the
+default. Read it (`--json` alone) on a failed or partial run, or before judging
+evidence. A terminal `workflow watch` prints the same compact command as
+`next:`.
+
+```bash
+bullswarm workflow runs result <shortId> --json --summary
+bullswarm workflow runs result <shortId> --json
+```
+
+`workflow runs result --help` states `Usage: bullswarm workflow runs result
+<shortId|runId> [--json] [--summary]`; `--summary` is "print the compact JSON
+status-loop envelope; implies --json".
+
+**Bytes.** Every attempt records `bytes: { taskFile, authorPrompt, kernel,
+dependencyInputs, output }` — the task file the kernel wrote, the action's own
+prompt as authored, the remainder after subtracting that prompt and any
+embedded requirement text, the sum of the dependency output files the task
+points at (0 when there are none), and the durable out file on completion.
+The result envelope copies the last attempt's `bytes` onto `actions[]` and
+totals `usage.bytes: { taskFiles, dependencyInputs, outputs }`.
+`workflow runs show` appends `in <taskFile>/<dependencyInputs> out <output>`
+per attempt (blank when unrecorded). Missing values are null, never guessed.
+
+**Digest.** `kind: "digest"` is analyze/low. It is an extractive condensation
+of its dependencies' outputs — quoted delivered items, validation numbers,
+commands, unfinished work, and integrator requests; no verdicts of its own.
+The kernel writes the whole task; the author's prompt is focus guidance only.
+Use one when three or more writers feed a single integrator, or when a
+consumer's dependency outputs would exceed roughly 20 KB. A digest must
+depend on at least one action, owns no files, has empty `evidenceFor`, and
+needs no `affects`. Evidence must not depend on a digest: evidence reads the
+real artifacts. Consumers that depend on a digest receive that digest plus a
+`digestOf` array of `{ actionId, outputFile }` so they can drill down; those
+paths are pointers, not extra `dependencyInputs`. (The kind table above
+derives lane and effort.)
+
+```json
+{
+  "schemaVersion": "bullswarm.workflow.program.v2",
+  "actions": [
+    { "id": "write-a", "kind": "implement", "dependsOn": [], "ownedFiles": ["a.ts"], "affects": ["requirement-1"], "evidenceFor": [], "purpose": "Write slice A", "prompt": "Implement A and report the checks you ran." },
+    { "id": "write-b", "kind": "implement", "dependsOn": [], "ownedFiles": ["b.ts"], "affects": ["requirement-2"], "evidenceFor": [], "purpose": "Write slice B", "prompt": "Implement B and report the checks you ran." },
+    { "id": "write-c", "kind": "implement", "dependsOn": [], "ownedFiles": ["c.ts"], "affects": ["requirement-3"], "evidenceFor": [], "purpose": "Write slice C", "prompt": "Implement C and report the checks you ran." },
+    { "id": "condense", "kind": "digest", "dependsOn": ["write-a", "write-b", "write-c"], "ownedFiles": [], "affects": [], "evidenceFor": [], "purpose": "Condense the writer outputs", "prompt": "Keep every acceptance number and every shared-file request." },
+    { "id": "integrate", "kind": "integration", "dependsOn": ["condense"], "ownedFiles": [], "affects": ["requirement-1", "requirement-2", "requirement-3"], "evidenceFor": [], "purpose": "Integrate and run the gates", "prompt": "Apply every request the digest carries and run the repository gates." }
+  ]
+}
+```
+
+An evidence action for those requirements depends on `write-a`, `write-b`, and
+`write-c` — never on `condense`.
+
 ### Live workflow dashboard
 
 For ordinary observation, use the non-interactive watcher. For V2 runs it
@@ -615,8 +725,9 @@ prints one attach line, then one line per notable event as it happens
 (action finished/failed/blocked/cancelled, evidence, stage completion,
 planner turn, stall/recovery, cancellation, and the existing pause and
 terminal `outcome:` / `next:` lines) and stays silent while work is merely
-in progress. Agent starts, mechanical retries, and steering delivery print
-only with `--verbose`. A usage-limit failure (`failureKind: 'quota'`) always
+in progress. A terminal watch's `next:` line is
+`bullswarm workflow runs result <shortId> --json --summary`. Agent starts,
+mechanical retries, and steering delivery print only with `--verbose`. A usage-limit failure (`failureKind: 'quota'`) always
 prints, verbose or not: `⚠ <actionId> usage limit on <pool> · paused until
 <deadline> · retrying on another pool`, followed once the mechanical retry
 lands on another pool by `↺ <actionId> now on <pool> · <model>`. The

package/connectors/opencode2.json

@@ -34,6 +34,12 @@
   "capabilities": ["strong-analysis", "code-reading", "file-editing", "workflow-planning"],
   "modelDiscovery": { "cmd": ["opencode", "models"], "parse": "lines", "includePattern": "^[^\\s]+/[^\\s]+$", "timeoutMs": 20000, "maxModels": 250 },
   "modelSelection": { "flag": "--model", "mode": "replace-or-append" },
+  "$comment-reasoning": "verified 2026-09-09 against opencode 1.18.25: `opencode run --help` documents `--variant  model variant (provider-specific reasoning effort, e.g., high, max, minimal)`. opencode only forwards a variant its CONFIG declares for that model, and the owner's opencode.json declares none, so on a bare install `--variant` is accepted and silently dropped. The level reaches the KaiHK API as `reasoning_effort` ONLY because expandOpenCodeKaihkConnectors (src/lib/opencode-kaihk.js) injects the five variants for <providerId>/gpt-5.6-luna through env.OPENCODE_CONFIG_CONTENT on every discovered KaiHK pool. Probed with that variable set: `--variant bogus` (reasoningEffort bogus-level) failed at the API with `level \"bogus-level\" not supported, valid levels: low, medium, high, xhigh, max`, and `--variant max` succeeded; probed again with the flag AFTER the positional task text, exactly where bullswarm appends it (`opencode run --auto --model <id>/gpt-5.6-luna <task> --variant <level> --format json`), with the same API rejection for the bogus level, so the position is proven too. Same five levels as connectors/command-code.json, which fronts the same backend. UNVERIFIED for non-KaiHK opencode providers: they get no injected variants, so the flag is a no-op there rather than an error.",
+  "reasoning": {
+    "flag": "--variant",
+    "levels": ["low", "medium", "high", "xhigh", "max"],
+    "defaults": { "high": "high", "medium": "medium", "low": "low" }
+  },
   "modelProfiles": [
     { "match": "(?:^|/)claude-fable-", "tier": "high", "qualityRank": 6, "autoRecommend": false },
     { "match": "gpt-5\\.6-sol$", "tier": "high", "qualityRank": 6, "autoRecommend": true },