bullswarm 0.25.4 → 0.26.0

package/AGENTS.md

@@ -59,13 +59,13 @@ 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. 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.
+read `skill/SKILL.md` — that's the agent-facing user guide. There are
+exactly two ways to start work, and the caller chooses the shape itself: one
+bounded outcome goes to `bullswarm run`; parallel territories, integration,
+or independent acceptance go to `bullswarm workflow goal` with a program you
+author (`bullswarm workflow plan contract` returns the schema). There is no
+classifier or preview step. 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.

package/CHANGELOG.md

@@ -1,5 +1,184 @@
 # bullswarm changelog
 
+## 0.26.0 — two entry points, kinds and rungs
+
+- There are now exactly two ways to start work, and `bullswarm delegate` is
+  gone. `delegate` existed to decide, on the caller's behalf, whether a request
+  needed one agent or a workflow — with `--mode auto` it spent a real
+  analyze-lane dispatch on a deterministic-then-LLM classifier before doing any
+  of the actual work. The calling agent already knows the shape of its own
+  request, so that round trip bought latency and quota, not accuracy. `bullswarm
+  run` is the single-agent entry point and `bullswarm workflow goal` is the
+  workflow entry point; `bullswarm --help` names those two, in that order, and
+  `bullswarm delegate` now exits 2 with the standard unknown-verb message and
+  dispatches nothing. The packaged skill and the awareness block registered into
+  Codex, Claude, and Grok say the same thing in six lines: decide the shape
+  yourself, there is no preview step.
+
+- `bullswarm run --lane analyze` now defaults to `medium` effort instead of
+  `high`. The V2 validator has always defaulted an analyze action to medium, so
+  the same lane meant a different tier depending on which entry point you used.
+  `run` and the validator now read one exported `DEFAULT_EFFORT_BY_LANE` table,
+  and `run --help` states the corrected default.
+
+- Program actions can now say what they *are* instead of restating how to route
+  them. The optional `kind` field takes one of seven values — `mechanical`,
+  `io-read`, `check`, `implement`, `integration`, `architecture`,
+  `adversarial-acceptance` — and derives `lane` and `effort` from a table
+  exported alongside the existing per-lane default. Resolution is per field: an
+  explicit action field wins, then the kind table, then a new optional
+  program-level `defaults` object (`effort` and `reasoning` only), then the lane
+  default. A kind outside the closed list is a validation error with the allowed
+  values named, because it is a typo in the program rather than a runtime
+  condition. Programs that use neither `kind` nor `defaults` and state
+  `lane` and `effort` on every action normalise byte-identically to before;
+  `effort` itself is now optional and falls back to the per-lane default
+  where it used to be rejected as missing.
+
+- Two non-blocking advisories, never rejections. `all-writers-high` fires when
+  three or more build/chore actions run and none is below high effort;
+  `docs-at-high` fires when a build/chore action owns only `*.md` files at high
+  effort. `workflow plan validate --json` carries them as `advisories` and the
+  human output prints `advisory:` lines; `workflow goal --program` prints the
+  same lines at launch. Neither changes acceptance or an exit code. The kernel
+  records them on the run, and `workflow runs show` lists them.
+
+- `workflow runs result`, `runs show`, and `action show` print `kind` next to
+  lane and effort when an action has one. `workflow action show` now understands
+  autonomous V2 runs at all — it previously read only the V1 action ledger and
+  failed on every V2 run.
+
+- **Rungs: one pool's model plus its reasoning level, for one effort tier, read
+  and written as one thing.** `bullswarm strategy rungs [--json] [--pool <name>]`
+  prints one row per enabled pool and configured tier with the effective model
+  and its source, the effective reasoning level and the layer that chose it, the
+  dated Epoch benchmark evidence for that model *at that level* (`blended`, cost
+  per task, tokens per task), and the local record from the decision log for that
+  pool and tier (dispatches, median wall minutes, ok share). Absent evidence
+  prints `no evidence` and an unmeasured tier prints `no dispatches`; neither is
+  ever estimated. `strategy inventory --json` gained the same rows under `rungs`.
+
+- `bullswarm strategy set-rung <pool> <tier> --model <model> [--reasoning <level>]
+  [--force]` writes both halves of a rung in one atomic state save, so the model
+  and the thinking depth can never land separately. A rung is singular per pool
+  and tier: the tier moves off whichever model held it, and that model keeps its
+  other tiers. A level the connector cannot express is clamped to the strongest
+  it accepts and the clamp is printed. An unknown pool or tier exits 2; a model
+  absent from the pool's cached discovery exits 2 and lists the known models
+  unless `--force` is given. Neither `rungs` nor `set-rung` ever spawns model
+  discovery. No state migration: rungs are a projection of `strategy.modelTiers`
+  and `strategy.reasoning`, and `~/.bullswarm/state.json` gained no keys.
+
+- The setup wizard's tier step now shows each suggested rung with its benchmark
+  evidence line and asks one reasoning question per configured tier. **Behavior
+  change:** Enter keeps that connector's own per-tier default and writes nothing,
+  where the previous question stored a suggested level (`xhigh`/`high`/`medium`)
+  on a blank answer. Connector defaults remain the final fallback, so a pool with
+  no configured rung behaves exactly as before. Non-TTY and `--yes` paths are
+  unchanged.
+
+- A dated evidence datapack per model *and reasoning level*, from Epoch AI.
+  `data/epoch-benchmarks.json` (schema `bullswarm.epoch.benchmarks.v1`) is built
+  by the new `scripts/refresh-epoch-benchmarks.mjs` from Epoch's cursorbench,
+  deepswe, arc-agi-2, and critpt exports, and `src/lib/epoch-benchmarks.js`
+  reads it with the same cache → bundled → URL fallback as the OpenRouter pack.
+  `rungEvidence()` returns the mean of whichever of those four scores exist for a
+  (model, level) pair as `blended`, with cost and tokens per task from
+  cursorbench; `normalizeModelId()` is how connector model ids match the export.
+  The data is used under CC BY 4.0 — Epoch AI, 'AI Benchmarking Hub'. Published
+  online at epoch.ai. Retrieved from https://epoch.ai/benchmarks.
+
+- The daily refresh job is renamed `.github/workflows/refresh-benchmarks.yml` and
+  now refreshes both assets on the rolling `benchmark-data-latest` release: it
+  downloads and unzips Epoch's public export, runs the script, runs the new
+  tests, and uploads `epoch-benchmarks.json` next to `openrouter-benchmarks.json`.
+  The ambiguous `npm run refresh:benchmarks` script is split into
+  `refresh:openrouter` and `refresh:epoch`, since only one of the two now
+  refreshes "the benchmarks".
+
+- The OpenRouter builder is unchanged, and that is a finding rather than an
+  omission: the Artificial Analysis records in the 2026-09-08 capture carry only
+  `agentic_index`, `coding_index`, and `intelligence_index` per model, with no
+  reasoning-effort marker on any of the `reasoning_effort`, `effort`, `variant`,
+  `reasoning`, or `reasoning_level` fields checked, so there is no per-effort row
+  to keep. `data/README.md` records the field names inspected.
+
+## 0.25.5 — forecast-aware routing
+
+- Bullswarm now knows what it is already running. Every dispatch registers the
+  work it starts in a small ledger on disk (`~/.bullswarm/assignments/`, one
+  atomically written file per assignment), and every process reads it: a
+  `bullswarm run` in one terminal, a V1 runtime and four concurrent V2 kernel
+  actions all see each other's agents instead of each assuming the pool is
+  idle. Records whose process is gone, or that are older than 12 hours, are
+  pruned on read, so a crash cannot leave phantom load behind. `bullswarm
+  assignments` lists what is in flight right now — pool, run, action, how long
+  it has been going and how much longer it is expected to take — and
+  `bullswarm pools` carries the same count as `inflight=<n>`.
+
+- A spend model turns those records into percentage points. It measures how
+  fast a pool actually burns its 5-hour and weekly windows by pairing meter
+  readings with the worker-minutes dispatched between them, and how long an
+  assignment on a given lane and effort tier usually runs by taking the median
+  of real attempts from the decision log. Every number carries its basis —
+  `history` (measured), `bootstrap` (one window's usage so far), or the
+  documented `default` table — and the sample count behind it. A pool nobody
+  has measured reports `null`, never a plausible-looking guess.
+
+- Routing now decides on the forecast instead of on the last reading. Each
+  pool's projection (reading + what its in-flight agents will still spend) gets
+  the expected consumption of the assignment being routed added on top, and the
+  existing thresholds apply to that number: a pool projected at or above 75% of
+  its 5-hour window drops to the near-limit tier while its reading is still
+  below the line, and one projected at or above 90% is dropped from selection
+  as forecast-gated. Nothing is gated on an unknown forecast, and if every
+  capable pool is gated, the least loaded of them is still picked — with the
+  reason saying exactly that — rather than the action being stranded.
+
+- Parallel work now spreads instead of stacking. Within a tier, a pool's pace
+  surplus is reduced by the weekly quota its in-flight agents and this
+  assignment are expected to spend, and by at least a flat 3 surplus points
+  per in-flight agent (`DEFAULT_INFLIGHT_PENALTY_PCT`, `config.inflightPenaltyPct`
+  in state.json, `0` disables it). The floor matters: at measured weekly rates
+  a six-minute agent projects to under one point, which would leave a burst on
+  one pool. The charge is labeled `penalty` when the floor set it and by its
+  measured basis otherwise. Load also beats incumbency: an incumbent carrying
+  more in-flight agents than a challenger keeps neither its margin nor its cost
+  guard. Four actions launched within the same second land on
+  four different providers rather than all on the single most-behind one, and
+  the V2 kernel re-reads the ledger before every pick rather than only on its
+  throttled meter refresh, so actions launched seconds apart still see each
+  other.
+
+- Everything that observes routing shows the new numbers. `bullswarm
+  assignments [--json]` is a new command listing the live ledger; `bullswarm
+  pools` gained an `inflight=<n>` column and prints its 5-hour cell as
+  `5h=<reading>%-><projected>%` when in-flight work is expected to move it,
+  with `spend`, `projectedFiveHourPct` and `projectedWeeklyPct` in `--json`;
+  `bullswarm run --dry-run` prints the forecast the pick was made on and, being
+  a preview, still registers nothing and writes no decision log; and the
+  strategy control center shows each provider's in-flight count next to its
+  usage. Live meter readings are now retained as a capped per-pool series at
+  `~/.bullswarm/meters/history/<pool>.jsonl`, because the snapshot cache keeps
+  only the newest reading and a rate needs two.
+
+- A rate is only reported once the dispatch behind it is real: at least five
+  worker-minutes must be attributable to a window before its utilization
+  counts as percentage-points-per-minute. Without that floor a pool at 26% of
+  its 5-hour window with one six-second-old agent measures as 260% per minute
+  and forecasts every provider past the burst line, which is the failure this
+  model exists to prevent rather than cause.
+
+- All of it is visible after the fact. The routing reason names the in-flight
+  counts and projections that moved the pick (`5h used 30% -> 41% projected, 2
+  in flight`, `skipped near 5h limit (projected): wati 76%`, `forecast-gated
+  at/above 90%: …`, `preferred over busier: …`), every candidate row carries
+  `pace`, `effectiveSurplus`, `inflight`, `projectedFiveHourPct`,
+  `forecastFiveHourPct`, `projectedWeeklyPct`, `ratePerMinute`,
+  `estimateSource` and `forecastGated`, and the decision log records the
+  forecast the pick was made on. Pools that carry no ledger or spend fields
+  route exactly as they did before.
+
 ## 0.25.4 — reasoning levels
 
 - A connector now declares how its own CLI expresses a thinking level, and

package/README.md

@@ -6,10 +6,24 @@ evidence agents by quota, and computes completion from a durable requirement
 ledger 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.
+## Entry points
+
+There are exactly two ways to start work:
+
+```bash
+bullswarm run --lane analyze --add-dir ~/some-repo --prompt "Explain the parser" --json
+bullswarm workflow goal "Fix the failing tests and verify the change" --cwd ~/some-repo --program plan.json
+```
+
+`bullswarm run` is the single-agent entry point: route, dispatch, watch,
+verify, one JSON verdict. `bullswarm workflow goal` is the workflow entry
+point: you author the bounded action program and the kernel executes it to the
+end. For agents, `/bullswarm` (or `$bullswarm` where skills use that syntax)
+reads the packaged skill and goes straight to one of those two. The calling
+agent decides the shape itself from the request — one bounded outcome takes
+`run`, parallel territories, integration, or independent acceptance take
+`workflow goal`. There is no preview, classifier, or dispatcher command
+between them.
 
 Every command and nested subcommand supports contextual `-h` / `--help`
 without initializing state or executing the command:
@@ -79,9 +93,6 @@ bullswarm setup    # interactive provider/model configuration
 bullswarm setup --wizard  # broader worktree + integration questionnaire
 bullswarm pools    # meter state, pace position, quarantine status
 bullswarm strategy  # explicit alias for the same routing control center
-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 plan contract "Fix the failing tests and verify the change" --cwd ~/some-repo --json  # you are the planner
@@ -96,7 +107,6 @@ 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 the planning contract for an autonomous workflow you author (`--orchestrator` dispatches a planner agent instead). |
 | `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, 5-hour utilization (`5h=<n>%`, flagged `NEAR-5H-LIMIT` at or above 75%), quarantine status |
@@ -107,22 +117,6 @@ bullswarm health   # re-judge saved outputs; catch gate failures
 | `version` / `--version` | Print the installed Bullswarm version. |
 | `release` | Run the guarded local version-bump, commit, and tag workflow used before CI publishes to npm. |
 
-### 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
@@ -163,6 +157,44 @@ bullswarm strategy exclude-model claude-fable-5
 bullswarm run --effort high --lane analyze --task-file /tmp/task.md --json
 ```
 
+### Rungs
+
+A **rung** is one pool's model *plus its reasoning level* for one effort tier —
+the two halves you actually choose together. `bullswarm strategy rungs` reads
+them as one table and `bullswarm strategy set-rung` writes both halves in one
+atomic save:
+
+```bash
+bullswarm strategy rungs                      # every enabled pool x configured tier
+bullswarm strategy rungs --json --pool codex  # machine-readable, one pool
+bullswarm strategy set-rung codex high --model gpt-5.6-sol --reasoning xhigh
+```
+
+Each row carries the effective model and where it came from, the effective
+reasoning level and which layer chose it, the dated benchmark evidence for that
+model *at that reasoning level* (`blended`, `$/task`, `tok/task`), and what this
+machine recorded for that pool and tier (dispatch count, median wall minutes, ok
+share). Evidence and record are never estimated: a model the datapack does not
+cover prints `no evidence`, and a tier with no matching attempt prints `no
+dispatches`. `strategy inventory --json` carries the identical rows under
+`rungs`.
+
+Reading is free of side effects — no state write, no model discovery, no
+download. `set-rung` never spawns discovery either: a model absent from the
+pool's cached discovery exits 2 and lists the models it does know, unless you
+pass `--force`. A reasoning level the connector cannot express is clamped down
+to the strongest level it accepts and the clamp is printed. A rung is singular
+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 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
+cursorbench, deepswe, arc-agi-2, and critpt scores recorded for that exact
+model and reasoning level; cost and tokens per task come from cursorbench. See
+[data/README.md](data/README.md) for the schema and the refresh job.
+
 Setup first asks whether to analyze live usage and recommend routes or open the
 current configuration for manual editing. Analysis shows a spinner plus
 per-provider usage progress, then presents the proposed defaults before making
@@ -170,10 +202,13 @@ any routing change. Press `Y` to apply them or `N` to retain the current policy.
 The analysis selects at most one default model for each provider and effort
 tier. It uses OpenRouter's agentic, coding, and intelligence indices as quality
 signals and API-equivalent pricing as the budget signal. A repository-owned
-GitHub Actions job calls the authenticated OpenRouter APIs once per day and
-replaces a public, validated `openrouter-benchmarks.json` asset on the rolling
-`benchmark-data-latest` GitHub Release. Installed CLIs download only that public
-file and never need or receive an OpenRouter key.
+GitHub Actions job (`.github/workflows/refresh-benchmarks.yml`) refreshes two
+public assets on the rolling `benchmark-data-latest` GitHub Release:
+`openrouter-benchmarks.json` from the authenticated OpenRouter APIs, and
+`epoch-benchmarks.json` from Epoch AI's CC BY 4.0 benchmark export, which is
+what `strategy rungs` reads for per-model-per-reasoning-level evidence.
+Installed CLIs download only those public files and never need or receive an
+OpenRouter key.
 The sources are OpenRouter's [benchmarks API](https://openrouter.ai/docs/api/api-reference/benchmarks/list-benchmarks)
 and [models API](https://openrouter.ai/docs/api/api-reference/models/list-all-models-and-their-properties).
 The CLI caches the datapack under `~/.bullswarm/cache/`; network failure falls
@@ -227,6 +262,49 @@ name the utilization that decided the pick, and meters and quarantines are
 re-read before each dispatch — and again, live, right after a usage limit —
 so a long run never routes off the snapshot it launched with.
 
+Those thresholds are applied to the FORECAST, not to the last reading. A meter
+reading is already old when it arrives: agents dispatched seconds ago have
+spent quota the provider has not reported yet, and the assignment being routed
+will spend more. So each pool's projection — its reading plus the quota its
+in-flight agents are still expected to burn — gets this candidate's own
+expected consumption added, and the tiers apply to that number: a pool
+projected at or above 75% drops to the near-limit tier even while its reading
+is lower, and one projected at or above `BURST_BLOCK_PCT` (90) is left out of
+selection entirely as forecast-gated. If every capable pool is forecast-gated,
+routing still names the least loaded of them rather than stranding the action,
+and says so in the reason. A pool with no measured rate forecasts nothing and
+is never gated or deprioritized for a number nobody produced.
+
+Within a tier, pools already carrying work yield to quieter pools of similar
+pace: each pool's surplus is reduced by the weekly quota its in-flight agents
+and this assignment are expected to spend, and by at least a flat 3 surplus
+points per in-flight agent. That floor is what spreads work at real rates,
+where a six-minute agent projects to well under one point; the charge is
+labeled `penalty` when the floor set it and carries its measured basis
+(`history`, `bootstrap`) when the projection was larger. Load also beats
+incumbency: an incumbent carrying more in-flight agents than a challenger keeps
+neither its 10-point margin nor its cost protection, so the quieter pool wins
+as soon as its effective surplus is higher. A burst of parallel actions
+therefore spreads across providers instead of stacking on the single
+most-behind one.
+`bullswarm pools` shows each pool's `inflight=<n>` count and its 5-hour column
+as `5h=<reading>%-><projected>%` whenever in-flight work is expected to move
+it, `bullswarm assignments` lists what those agents are, `bullswarm run
+--dry-run` prints the forecast the pick was made on without registering
+anything, and every candidate row carries `pace`, `effectiveSurplus`,
+`inflight`, `projectedFiveHourPct`, `forecastFiveHourPct`, `ratePerMinute`,
+`estimateSource` and `forecastGated`, so a surprising pick can be read back
+number by number.
+
+The rates come from real records: every live meter reading is retained as a
+capped per-pool series (`~/.bullswarm/meters/history/<pool>.jsonl`) and paired
+with the worker-minutes dispatched between readings. Until at least five
+worker-minutes of dispatch are attributable to a window there is no rate at
+all — `null`, not a ratio of percentage points to seconds — so a fresh machine
+routes on pace and the flat penalty until it has measured something. The
+penalty itself is `config.inflightPenaltyPct` in `~/.bullswarm/state.json`
+(default 3; `0` turns the tie-breaker off).
+
 Model exclusions are hard routing policy. An excluded model is removed from
 recommendations and assignments, and Bullswarm pins a same-tier allowed model
 through the connector-owned model flag whenever the provider default could be
@@ -305,6 +383,42 @@ adversarial acceptance judgment. Merely being an analysis/evidence action or
 part of a difficult goal never promotes an action to high. The selected effort
 then resolves through the High/Medium/Low routes configured by `bullswarm setup`.
 
+### Kinds
+
+Stating lane and effort separately on every action means re-deciding two
+fields for work whose nature already implies both. The optional `kind` field
+names that nature once and derives them:
+
+| `kind` | lane | effort |
+| --- | --- | --- |
+| `mechanical` | chore | low |
+| `io-read` | analyze | low |
+| `check` | analyze | medium |
+| `implement` | build | medium |
+| `integration` | build | high |
+| `architecture` | analyze | high |
+| `adversarial-acceptance` | analyze | high |
+
+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
+action — then the per-lane default table. A `kind` outside that closed list is
+a validation error, not a runtime failure: it is a typo in your program, so
+`workflow plan validate` exits 2 and nothing launches. A program that uses
+neither `kind` nor `defaults` and states `lane` and `effort` on every action
+validates and runs exactly as before; the one widening is that `effort` is now
+optional and falls back to the per-lane default instead of being rejected.
+
+Two advisories report effort smells without ever rejecting anything.
+`all-writers-high` fires when three or more `build`/`chore` actions run and
+none is below high effort; `docs-at-high` fires when a `build`/`chore` action
+owns only `*.md` files at high effort. `workflow plan validate` includes them
+as `advisories` in `--json` and prints `advisory:` lines otherwise, `workflow
+goal` prints the same lines at launch, and both keep their exit codes. The
+kernel stores them on the run, so `workflow runs show` lists them afterwards,
+and `runs result`, `runs show`, and `workflow action show` print `kind` next to
+lane and effort.
+
 Reasoning depth is a third, independent decision. An action may carry an
 optional `reasoning` field — `low`, `medium`, `high`, `xhigh`, `max`, or
 `default` — that sets how hard the picked model thinks on that one action and

package/connectors/codex.json

@@ -117,7 +117,7 @@
     "flag": "--model",
     "mode": "replace-or-append"
   },
-  "$comment-reasoning": "Codex has no reasoning flag; the control is the config key `model_reasoning_effort`, overridden per invocation with the escape hatch verified from `codex exec --help` (codex-cli 0.153.4): `-c, --config <key=value>  Override a configuration value that would otherwise be loaded from ~/.codex/config.toml`. Accepted values verified from the official Codex config reference (https://learn.chatgpt.com/docs/config-file/config-reference, read 2026-09-09): `minimal | low | medium | high | xhigh` — \"Adjust reasoning effort for supported models (Responses API only; xhigh is model-dependent)\". `minimal` sits below bullswarm's common scale, so a request below `low` clamps up to `low`. Tier defaults stay at high/medium/low because `xhigh` is model-dependent; an explicit `xhigh` request passes through. Without this block Codex workers think at whatever config.toml sets (this machine: low).",
+  "$comment-reasoning": "verified 2026-09-09 against codex-cli 0.153.4: `codex exec -c model_reasoning_effort=max --model gpt-5.6-luna` ran (exit 0), printed `reasoning effort: max`, and the session rollout recorded reasoning_effort \"max\"; the public config reference still lists only minimal|low|medium|high|xhigh. `minimal` is accepted by the CLI but sits below bullswarm's ladder and is not declared.",
   "reasoning": {
     "args": [
       "-c",
@@ -127,7 +127,8 @@
       "low",
       "medium",
       "high",
-      "xhigh"
+      "xhigh",
+      "max"
     ],
     "defaults": {
       "high": "high",