loki-mode 11.74.2 → 11.75.2

package/docs/v10/ROADMAP-D63.md

@@ -1,35 +0,0 @@
-# Roadmap D63: the industry-standard autonomous software factory
-
-Founder directive D63 (2026-10-03 00:15Z, relayed by the autonomi-dev session). This page sets the roadmap that D50, D51, D56 and D61 slot into. The measurable bars below are the only claim we make. User-facing text makes no "superintelligence" or benchmark claims, and no row is done without a test or an eval row in METRICS.
-
-## Pillars: the bar to match, and how we beat it
-
-| # | Pillar | Bar to match | How we beat it | Done when (test or eval row) |
-|---|---|---|---|---|
-| 1 | Autonomy | Devin, Factory Droids: an issue, backlog or spec goes in; merge-ready PRs come out; no babysitting | Proof plus lift | D50 lift on the eval, never below raw on the same model; D61 speed targets; a BLOCKED run asks exactly one question |
-| 2 | Speed at scale | Factory: parallel units with an integrator; warm start | Same or fewer tokens than one sequential session | D61 large-arm eval holds (section 5 of D61-SPEED.md) before the default flips |
-| 3 | Evidence | Devin, Vorflux: PR bodies with tests, screenshots of changed pages, HTTP transcripts for APIs | A signed receipt covers all of it | Screenshots are generated locally (Playwright) and hashed into the receipt; `loki verify` fails if one is altered |
-| 4 | Control Plane UI | Devin web app, Factory dashboard | Every number links to its receipt | D56 is the default: live runs, history, PRs and issues, cost, compare, and a BLOCKED question answerable in the UI; one container with Helm and ECS examples; the old dashboard retired once at parity |
-| 5 | Connections | Devin, Factory integrations | Intake is the same v10 run with the same receipt | GitHub (PAT now, GitHub App next) and GitLab; Jira and Linear intake; two-way Slack (`@loki` in a thread starts a run, BLOCKED answers come back); issue-to-PR Action; an MCP server exposing run, status and verify; VS Code and JetBrains via ACP later |
-| 6 | Spec to software | 8090 | Every acceptance criterion traced to code and a check in the receipt | A spec or PRD file becomes a delivery contract, decomposed (D61) into units and then PRs; replaces the legacy PRD path (D57) |
-| 7 | Legacy and modernization | 8090, Factory | Proof of function on legacy code | `loki modernize` stays hidden until it passes a real-repo eval; not this week |
-| 8 | Claude Code parity | Claude Code | Runs inside it with a receipt | loki-seal plus a /loki command that runs the v10 engine on the current task; CLAUDE.md and .claude/skills honoured in the context pack |
-| 9 | Enterprise | Devin and Factory enterprise tiers | Audit from the receipt chain | An audit log of model calls; budgets per team; SSO for the Control Plane later; never certification claims |
-
-## Order this week (under the usage governor)
-1. D61 eval arm (slice 17), then warm start (slices 5 and 6), with slices 1, 2, 7 and 8 in parallel.
-2. Visual evidence in PRs (pillar 3).
-3. Control Plane as the default, with the BLOCKED answer UI (pillar 4).
-4. Two-way Slack (pillar 5).
-5. Jira and Linear intake (pillar 5).
-6. Spec to contract (pillar 6).
-7. Multi-repo workspaces (D51 Phase B, behind LOKI_WORKSPACES).
-8. MCP run, status and verify server (pillar 5).
-9. Containers (pillar 4).
-
-Also from D62: root action.yml routes to Loki 10; one real end-to-end BUDGET_STOP exit 3 test; project memory (D50 item 3). Later: merge queue, PR review with a risk score, REST API.
-
-## Rules
-- Each item ships on its own train, behind a flag where it changes defaults, with README and docs updated in the same slice.
-- Each release reports its version and what users can now do to the autonomi-dev session.
-- Pacing follows the governor (about 0.5% of the weekly window per hour); seats scale only with live /usage.

package/docs/v10/SCALE.md

@@ -1,140 +0,0 @@
-# SCALE: what the plan sustains and what 50 engineers would need (G-03, D39)
-
-Written 2026-09-28 by the CTO (opus). Every number is either MEASURED (command and window
-given), PUBLISHED (source URL given) or ESTIMATE (basis given). Billing is the founder's call.
-
-## 1. Measured burn (MEASURED, local jsonl only)
-
-Source: `~/.claude/projects/**/*.jsonl`, assistant rows with a `usage` field, window ending
-2026-09-28 17:47Z. Local transcripts miss cloud and remote agents, so every figure is a lower bound.
-
-Counting method matters. Claude Code writes one jsonl row per content block and repeats the
-same `usage` on each row. Two methods, same hour:
-
-| Last 1h (17:47Z)           | Raw sum of rows (D39 method) | Deduplicated (max per message id + requestId) |
-|----------------------------|------------------------------|-----------------------------------------------|
-| Output tokens              | 2.07M                        | 1.87M (sonnet 1.62M, opus 0.24M, haiku 0.005M) |
-| Cache-read tokens          | 1.17B                        | 0.634B (sonnet 552M, opus 81M)                |
-| Cache-write tokens         | not summed                   | 6.51M (sonnet 5.03M, opus 1.40M); 92% 5-minute TTL |
-| Uncached input tokens      | not summed                   | 6.3K                                          |
-| API requests               | 5,824 rows                   | 3,119 (peak 114 per minute)                   |
-
-- The deduplicated count is the basis below. The D39 cache-read figure (1.15B) double counts
-  about 1.8x; D39 and METRICS.md should carry the deduplicated numbers.
-- Last 5h, deduplicated: output 6.01M (sonnet 5.21M, opus 0.80M), cache read 1.85B.
-- Models seen in the last hour: claude-sonnet-5 (2,808 requests), claude-opus-5-5 (305),
-  claude-haiku-4-5 (6). Opus share of output: 13%.
-- Concurrency, measured: distinct transcript files with at least one request per 5-minute slot
-  over the hour: 11, 11, 8, 12, 9, 12, 11, 21, 18, 20, 17, 17 (average 13.9). The stated
-  16 to 19 agents matches the last 25 minutes.
-- Peak minute (deduplicated): 66K output tokens, 561K ITPM-counted input (uncached input plus
-  cache writes; cache reads do not count toward ITPM), 114 requests.
-
-## 2. API-equivalent cost of the measured hour (PUBLISHED prices)
-
-Prices from https://platform.claude.com/docs/en/about-claude/pricing (fetched 2026-09-28):
-
-| Model            | Input | 5m cache write | 1h cache write | Cache read | Output |
-|------------------|-------|----------------|----------------|------------|--------|
-| claude-sonnet-5  | $2    | $2.50          | $4             | $0.20      | $10    |
-| claude-opus-5-5  | $4    | $5             | $8             | $0.20      | $20    |
-| claude-haiku-4-5 | $1    | $1.25          | $2             | $0.10      | $5     |
-
-(USD per million tokens. Sonnet 5 $2/$10 is now the standard price, per the pricing page footnote.)
-
-Measured hour at list price (cache writes priced at the 5-minute rate; the 1h share adds under $1):
-- Sonnet: cache read $110.49 + output $16.25 + cache write $12.59 = $139.34
-- Opus: cache read $16.26 + cache write $6.99 + output $4.75 = $28.00
-- Haiku: $0.14. Total: $167.5 per hour, of which cache reads are 76% and output 12%.
-- Upper bound with the raw D39 counting: about $275 per hour.
-
-Per engineer-hour (ESTIMATE): $167.5 / 13.9 measured agents = $12.0; $167.5 / 17.5 stated agents
-= $9.6. Range $9.6 to $12.0 per engineer-hour, $230 to $289 per engineer-day.
-
-## 3. What the Max 20x plan sustains around the clock (ESTIMATE, uncalibrated)
-
-The conversion from tokens to plan percent is NOT calibrated. G-01 fits it from founder
-readings of the 5-hour and weekly meters. Until then, this is a range with its basis, not a number.
-
-- Window ceiling: on 2026-09-27 about 16 agents took the 5-hour window from low to 91%. At the
-  D39 target of 85% at window end, that is 15 to 17 agents for one window, if the 9-27 mix
-  (tokens per agent, opus share) matches today.
-- Weekly bound: 24/7 is 33.6 five-hour windows per week. If the weekly cap equals W full
-  windows, sustainable 24/7 headcount = window ceiling x min(1, W / 33.6). W is unknown; it is
-  exactly what G-01 must measure.
-- ESTIMATE: 5 to 16 engineers around the clock. 16 holds only if the weekly cap is not binding;
-  the low end assumes the weekly cap is about 10 full windows. Neither end is a measurement.
-- Calibration input for G-01: use API-equivalent dollars per agent-hour (section 2), not raw
-  tokens, as the regressor. It weights opus against sonnet the way the plan meter likely does,
-  and it collapses four token kinds into one number.
-- The API value of what the plan is delivering today is about $4,000 per day at list price.
-
-## 4. What 50 parallel engineers would need (ESTIMATE on PUBLISHED prices)
-
-Assumptions: measured mix of section 1 (sonnet 87% of output, opus 13%); caching as today
-(99% of input from cache); 24 hours a day; list prices, no volume discount; no US-only
-inference (`inference_geo: "us"` adds 1.1x); local-only burn, so real cost is at least this.
-
-| Engineers | Per day           | Per 30 days          | Fits under (API spend cap)            |
-|-----------|-------------------|----------------------|---------------------------------------|
-| 16        | $3,675 to $4,627  | $110K to $139K       | Scale ($200K per month)               |
-| 25        | $5,742 to $7,230  | $172K to $217K       | Scale at the low end; over it at high |
-| 50        | $11,484 to $14,460| $345K to $434K       | Custom tier only (no cap; via sales)  |
-
-Rate limits are not the binding constraint; the spend cap is. Source:
-https://platform.claude.com/docs/en/api/rate-limits (fetched 2026-09-28).
-- Monthly spend caps: Start $500, Build $1,000, Scale $200,000, Custom none. At 16 engineers the
-  Start cap lasts about 3 hours and the Build cap about 6 hours. Tier placement is automatic
-  from account history; new orgs may start in a lower Evaluation tier.
-- Peak minute scaled from 13.9 to 50 agents: 238K output per minute, 2.0M ITPM-counted input,
-  410 requests per minute. Sonnet 5 limits: Start 2M ITPM / 400K OTPM / 1,000 RPM; Build 5M /
-  1M / 5,000; Scale 10M / 2M / 10,000. Opus 5.5 has its own bucket at the same numbers. So
-  Build clears 50 agents on rate limits; Start is at its ITPM edge.
-- Cache reads do not count toward ITPM on these models, which is why 99% cached input keeps
-  the fleet far under the limits.
-- The rate-limit page warns of acceleration limits on sharp ramps: step headcount up, never jump.
-
-Plans (https://claude.com/pricing, fetched 2026-09-28; limits UNVERIFIED beyond the page text):
-- Team: standard seat $20 to $25, premium seat $100 to $125 per month, "5x more usage than
-  standard seats". Seat usage limits apply per seat; published numbers for agent-hours per
-  seat were not found. UNVERIFIED for a 50-agent fleet.
-- Enterprise: "seat price + usage at API rates", $20 per seat per month billed annually. Economics
-  equal the API table above plus seat fees; custom limits and volume discounts are negotiated.
-- Stacking several subscriptions to multiply limits for one automated fleet is not proposed;
-  any such question goes to Anthropic.
-
-## 5. Ramp gates (D39)
-
-Headcount rises one step per hour, and only when all three hold for the last full hour:
-1. Governor allows: projected 5-hour window at or under 85% at window end and weekly at or
-   under 90% by the Wednesday 13:00 ET reset (on API billing: projected month under the tier cap
-   and any workspace spend limit).
-2. Merged slices per hour rose versus the previous step.
-3. Merged work per token did not fall: merged slices per million output tokens is no more than
-   10% below the previous step.
-Step size: +4 engineers (never more than +25%). Any gate failing: hold. Two failing hours in a
-row: step back one. The cut order in D39 applies (cloud, then MEDIUM and LOW local, then opus
-reviewers down to the HIGH minimum; never the Release Manager or a P0).
-
-What to measure first, this week: merged slices per million tokens.
-- Numerator: distinct slice IDs (BOARD row IDs such as E-88 or DEP-05) whose commits became
-  ancestors of origin/main in the window. Not commit count: 933 commits reached main in 7 days,
-  which says nothing about slices.
-- Denominator: deduplicated output tokens in millions, reported alongside API-equivalent
-  dollars. Not total tokens: those are 99% cache reads and would make the ratio noisy and tiny.
-- Record hourly in METRICS.md with the headcount of that hour. This is the baseline every
-  ramp step is judged against; without it gate 3 cannot be evaluated and the ramp stays shut.
-
-## 6. The founder's decision
-
-| Option | What it is | Headcount | Cost (ESTIMATE) |
-|--------|-----------|-----------|-----------------|
-| A. Max 20x only | Governor-limited, as today | 5 to 16 around the clock (uncalibrated) | Current plan fee only |
-| B. Max core + API overflow | Max for the core; API key with a workspace spend limit for engineers above the Max ceiling | Core + N | $230 to $289 per extra engineer-day; +10 = $2.3K to $2.9K per day |
-| C. API only, Scale tier | All engineers on API billing | Up to about 25 inside the $200K cap | 16: $110K to $139K per month; 25: $172K to $217K |
-| D. Enterprise or Custom tier | Sales-negotiated limits and discount | 50 | $345K to $434K per month at list, less any discount |
-
-CTO recommendation: A now; G-01 calibrates within the week. Move to B only after the section 5
-baseline exists and gate 3 holds at the Max ceiling, because extra engineers are worth buying
-only if merged work per token does not fall as headcount rises. Open the sales conversation for
-D before any plan to exceed 25, since Custom limits are not self-serve.

package/docs/v10/SCORECARD-PLAN.md

@@ -1,250 +0,0 @@
-# D41 scorecard plan: slices for items 1 and 2
-
-Architect plan (opus) for D41. Base: local main 9869f217, after E-98f. Cards S41-01 to S41-16. Items 3 to 5 are sketched at the end.
-
-## 0. Starting facts (each one cites a file or a command)
-
-- **E-98f (MEDIUM-ANALYSIS.md "After"), 7 medium tasks, n=3, 21 runs per arm.**
-  - default 15/21, p50 209s; `LOKI_E10_WALL=0` 16/21, p50 214s; `LOKI_E10_CASCADE=0` 15/21, p50 138s. Raw: 10/14 (EV-15) and 12/14 (EV-14), p50 56s to 70s.
-  - Null-cost rows are 10, 2 and 11 of 21, so no arm has a cost figure. Every miss is werkzeug-3105 or werkzeug-3271. Speed is the largest gap: v10 p50 is 2.5 to 4x raw.
-- **Three harness defects block the scorecard.**
-  - (a) `provider_cost()` (harness.py ~698) accepts only `cost_source == "provider"`. E-98e writes `"partial-stream"` for killed sessions (runner/budget.ts:502), so any stage kill nulls the whole row.
-  - (b) `V10_ENGINE_ENV_ALLOWLIST` (harness.py:95-98) lacks `LOKI_E10_CASCADE`, and `arm_env` drops every other `LOKI_*`. E-98f needed a bin shim.
-  - (c) `arm_auth(cap + 120)` refuses a row once the keychain token has under 1020s left. Claude Code refreshes only near expiry, so every r2 row was lost once.
-- **D33 core:** 4,964 lines at 9869f217, counted as `budget.test.ts` counts (`split("\n").length` over engine10 minus modernize/). Headroom is 35 lines.
-- **Prefix today:** E-65 measured 7,136 tokens on sonnet for the engine10 session shape (6 tools, `claude_code` preset, no append; runner/providers.ts:488-492). There is no per-stage first-turn figure yet (S41-04).
-- **Where the cost goes (MEDIUM-ANALYSIS section 4):** implement cache reads are 9.23M against raw's 4.79M. Plan, Wall and intake are 31% of spend. Plan runs on opus in the eval: `tier: "fast"` has no pin, and the override sets FAST to opus (session.ts:44-49).
-- **Agent SDK 0.3.283** has a PostToolUse `updatedToolOutput` that "replaces the tool output before it is sent to the model" and "works for all tools" (sdk.d.ts:2674-2681). Trimming has a real mechanism.
-
-## 1. Prerequisite ruling (CTO, before S41-05 merges)
-
-Core cannot absorb items 1 and 2: the new logic is about 600 lines against 35 lines of headroom. Proposal:
-- New modules go in `loki-ts/src/e10ext/`, outside engine10/, with a 1,500-line cap added to `budget.test.ts` next to modernize/.
-- Core may import e10ext/. e10ext/ may not import stages/.
-- Nothing that decides a verdict leaves core: Seal, the authoritative verify and the Wall seal stay in engine10/. e10ext/ only picks which diff reaches them and which model runs.
-- Because verify and Seal re-check whatever is chosen, a wrong pick costs accuracy but can never produce a false seal.
-- A D-entry records the ruling. If the CTO refuses, S41-05, 08, 10, 12 and 13 put their modules under engine10/ and offset every added line.
-
-## 2. Fixed metric definitions (identical before and after)
-
-- **Rows:** harness `dedupe` applied per rep file (it keys on model, harness_sha, task and arm, so run over concatenated reps it would merge r1 to r3), then E-98f's rule: one row per (arm label, rep file, task), the latest `status: ok` row, else the latest row. Arm label = `<arm>@<model>`. A task that is `task_invalid` anywhere is dropped from every arm.
-- **Completion** = completed / evaluated, using the harness's own `completed` and `is_evaluated`.
-- **Cost per completed** = sum of `cost_usd` over evaluated rows / completed rows.
-  - Provider and partial-stream dollars both count; the table shows the partial-stream share of spend.
-  - Any evaluated row still null makes the figure n/a, and n/a is always red.
-- **p50** = nearest-rank p50 of `time_to_pr_s` over completed rows (harness `nearest_rank`).
-- **Tokens per completed, by type:** input, cache read, cache write and output, each summed over evaluated rows / completed. Reported, not graded.
-- **Comparability.** The tool refuses to mark a pair unless all of these hold:
-  - the same task set with the same n per task;
-  - the same `--parallel` and cap;
-  - arms ran back to back, never concurrently;
-  - reused raw rows have an equal `git hash-object eval/loki10/harness.py`. Both hashes are printed.
-- **Marks.** Completion green if Loki >= raw; cost green if Loki <= raw; p50 green if Loki <= raw. The tier verdict is green only if all three are green. The headline pair, loki-sonnet against raw-opus, is green on cost only at Loki <= 0.5x raw.
-- **METRICS.md columns:** tier, pair, n, the three Loki/raw pairs with marks, verdict, tokens by type, partial share, date, harness hash, command.
-
-## 3. How the harness picks the model per arm today (item B)
-
-- **Knob: `LOKI_EVAL_MODEL`** (harness.py:1264).
-  - Unset, it takes the first `tier: "planning"` entry in providers/model_catalog.json. Today that is `claude-opus-5-5`, but `claude-opus-5` is also planning-tier, so the default depends on catalog order.
-  - The value must have a `cli_aliases` entry (harness.py:1267).
-- **raw-claude arm:** `--model <id>` (harness.py:1137).
-- **v10 arm:** `LOKI_MODEL_OVERRIDE=<id>` plus `LOKI_SESSION_MODEL=<alias>` (harness.py:523-525).
-  - session.ts:44-49 copies the override into PLANNING, DEVELOPMENT and FAST. The E-64 cascade then pins implement to `wallModel()`, sonnet by default (sizing.ts).
-  - Fix escalation targets `ctx.model` (fix.ts), so on loki-sonnet nothing can escalate today. S41-08 adds `LOKI_E10_TOP_MODEL`.
-- **Arms, all with pinned ids:** raw-sonnet = `LOKI_EVAL_MODEL=claude-sonnet-5 --arm raw-claude`; raw-opus = `LOKI_EVAL_MODEL=claude-opus-5-5 --arm raw-claude`; loki-sonnet = `LOKI_EVAL_MODEL=claude-sonnet-5 --arm v10` (plus `LOKI_E10_TOP_MODEL=opus` after S41-08); loki-opus = `LOKI_EVAL_MODEL=claude-opus-5-5 --arm v10` (the pair for raw-opus).
-
-## 4. Definitions for item 1
-
-**Deterministic failure.** A verify output has one when some check `c` meets all six conditions:
-1. `c.result == "fail"`: in verify.ts `runCheck`, it failed and then failed its immediate rerun. `flaky` (fail then pass) and `not_run` (missing tool, timeout, abort) never count.
-2. `c.name` is a test check, not `lint:*` and not `select-tests` (the same test as fix.ts `isTestFailure`).
-3. `c.interpreter != "system"`.
-4. The test file of `c` existed at baseSha or is a sealed Wall file. A test the attempt wrote itself never counts.
-5. `c.exit_code` is not a pytest non-test exit (2, 3, 4, or 5 = no tests collected). S41-08 records `exit_code` (+2 core lines). Without it, collection errors would buy top-model rounds.
-6. It reproduced: the same `c.name` failed in the previous verify after one cheap fix round, or it failed in both parallel attempts.
-
-Only then does a fix round run on the top model. With `MAX_FIX_ROUNDS = 2` (types.ts:25), a single attempt escalates in round 2 at the earliest. When both attempts failed the same check, escalation comes in round 1.
-
-**Attempt selection (two attempts).**
-- **Shared set S** = sealed Wall tests plus `impacted(testmap, changed_A plus changed_B)`, keeping only tests that exist at baseSha.
-  - Each attempt is scored in the primary tree, in turn: apply its diff, run S, reset (S41-12).
-  - An attempt is never scored in its own worktree: that worktree has no untracked task `.venv`, and a shared editable venv would test attempt A's `src/`.
-- **Disqualify an attempt when:** its session was killed or ended in error; its diff is empty (without already_done evidence); or its diff edits or deletes an existing test function or a Wall file (seal.ts weakened-test rule).
-- **Rank lexicographically:**
-  1. Wall passes, descending.
-  2. Deterministic-fail count in S (conditions 1 to 3 and 5), ascending.
-  3. Pass count in S on the project interpreter, descending.
-  4. Flaky count, ascending.
-  5. Lint fails, ascending.
-  6. Diff size (added plus deleted non-blank lines), ascending.
-  7. Attempt index, ascending.
-- **Early accept:** the first finished attempt with S non-empty and every S and Wall check `pass` is accepted, and the other session is killed. The killed session is still priced (partial-stream).
-- **Gate:** two attempts only for size `normal` when the predicted S (Wall enabled, or impacted tests from named or relevant files) is non-empty. With no selector there is no second attempt.
-- **Fallback:** if both attempts are disqualified, keep A. Verify and Seal decide as usual.
-
-## 5. Slice cards
-
-Each card lists: goal; files; Wall check (red first, then the eval measurement); tier and budget; dependencies; net core lines.
-
-### Wave 1 (start now: measurement, harness fixes, moat P0; 7 cards, disjoint files)
-
-**S41-01 Harness: cost, knobs, row fields.**
-- Goal:
-  - (a) `provider_cost` accepts `cost_source` of `provider` or `partial-stream` and records `cost_partial_usd`.
-  - (b) The allowlist gains `LOKI_E10_CASCADE`, `_TOP_MODEL`, `_ATTEMPTS`, `_TRIM`, `_PREFIX`, `_CONTEXT` and `_WALL_PARALLEL` now, so no later card touches harness.py.
-  - Rows gain: `tier` (from `_task_tier`); `tokens{input, cache_read, cache_write, output}` (raw from `arm_stdout` usage, v10 from `cost` events with a `by_stage` split); `first_turn_prompt_tokens` from result-cost files when present; and `escalations` and `attempts` from events.
-- Files: eval/loki10/harness.py, eval/loki10/test-harness.sh.
-- Wall check:
-  - Red first: a fixture efficiency dir with one partial-stream record gives `cost_usd` None before the change and a number after. `LOKI_E10_CASCADE=0` reaches `arm_env` output.
-  - Positive controls: pricing the preserved E-98f null row (e98f-engine/default-r1/pub-werkzeug-3121, `iteration-2.json` usd 0.0628) gives non-null, and re-pricing all three preserved E-98f arms from e98f-engine gives the first full cost table (deliverable; no eval spend). It decides whether "cheapest capable model" survives: nocascade's unreliable lower bound ($0.32) sits below default's ($0.70). The token harvest over ev15-raw-claude-r1/r2 and ev15-engine reproduces 4.79M raw and 9.23M v10-implement cache reads (MEDIUM-ANALYSIS section 4) to within 1%.
-- HIGH (measuring instrument); 30 min. Dependencies: none. Core: 0.
-
-**S41-02 Scorecard tool.**
-- Goal: `eval/loki10/scorecard <label=results.jsonl>... [--append docs/v10/METRICS.md]` prints one table per tier, per section 2.
-- Files: eval/loki10/scorecard (python; imports harness `dedupe` and `nearest_rank`), eval/loki10/test-scorecard.sh.
-- Wall check:
-  - Red first: synthetic rows cover every mark colour, n/a-is-red, and refusal on unequal task sets or harness hashes.
-  - Positive control: replaying the preserved E-98f files reproduces 15/21 at 209s, 16/21 at 214s and 15/21 at 138s. Replaying EV-15 reproduces raw 10/14 and v10 9/14.
-- MEDIUM; 30 min. Dependencies: none (reads the S41-01 fields when present). Core: 0.
-
-**S41-03 Arm runner plus auth guard (fixes c).**
-- Goal: `eval/loki10/scorecard-run.sh --tier T --n N --arms raw-sonnet,raw-opus,loki-sonnet,loki-opus --out DIR`.
-  - Runs arms back to back with pinned ids (section 3), the same `--parallel` for all, and one `--out` per rep.
-  - Before each arm and rep it reads only the keychain `expiresAt`, never the token. If fewer than cap x ceil(tasks/parallel) + 600 s remain, it waits until expiry is under 300s, runs one operator `claude -p ok --model claude-haiku-4-5` to force a refresh, and re-reads.
-  - Documents the arms in README.md.
-- Files: eval/loki10/scorecard-run.sh, eval/loki10/test-scorecard-run.sh, eval/loki10/README.md.
-- Prefers `ANTHROPIC_API_KEY` when set (`arm_auth` already takes it first). The under-300s refresh threshold is unverified (E-98f saw no refresh at about 415s), so the card starts with one live check of `expiresAt` before and after the operator call.
-- Wall check: red first, a stub `security` and `claude` with expiry 900s shows the wrapper waits, refreshes and never starts run.sh early. A dry run prints the 4 pinned commands.
-- HIGH (auth); 30 min. Dependencies: none. Core: 0.
-
-**S41-04 First-turn prefix measurement.**
-- Goal: the SDK stream parser records the first assistant message's `input + cache_creation + cache_read` as `first_turn_prompt_tokens` in the result-cost file.
-- Files: loki-ts/src/runner/sdk_stream_parser.ts and its test under loki-ts/tests/runner/.
-- Wall check: red first, a 3-message fixture stream gives the first message's sum, not the total. Then one loki-sonnet run of 1 small and 1 medium task records the per-stage prefix in METRICS.md.
-- LOW; 15 min. Dependencies: none. Core: 0.
-
-**S41-05 Attempt-selection rule (pure function).**
-- Goal: `selectAttempt(attempts, S, wall)` in e10ext/select.ts, implementing section 4 exactly. Adds the e10ext cap to budget.test.ts.
-- Files: loki-ts/src/e10ext/select.ts, loki-ts/tests/e10ext/select.test.ts, loki-ts/tests/engine10/budget.test.ts.
-- Wall check: red first, one test per rank key, per disqualifier, for early accept and for "attempt-authored test ignored". Mutating any key order turns a test red.
-- MEDIUM; 30 min. Dependencies: the section 1 ruling. Core: 0.
-
-**S41-12 Tree swap helper.**
-- Goal: `snapshotDiff`, `resetToBase` and `applyDiff` in e10ext/treeswap.ts, for the primary tree.
-  - Covers tracked and untracked files; excludes `.loki/`, `.venv/`, `venv/` and the attempts dir.
-  - Snapshots are in memory or under runDir, never `git stash` (the stash stack is shared across worktrees).
-  - Attempt worktrees live under `<runDir>/attempts/` and are removed by exact path.
-- Files: loki-ts/src/e10ext/treeswap.ts and its test.
-- Wall check: red first, a round trip over a fixture with a modified, a new and a deleted file plus a venv restores the tree byte for byte, and `git status` is clean after reset. A mutation that skips untracked files goes red.
-- HIGH (it feeds what Seal sees); 45 min. Dependencies: none. Core: 0.
-
-**S41-16 P0: Wall red-on-base is vacuous without `python` (confirmed).**
-- Found: wall.ts `RealBaseTestRunner` runs `RUNNER_CMD.pytest = "python -m pytest -q <files>"` through `/bin/sh`; any throw counts as `fail`. On this host `command -v python` finds nothing and `/bin/sh -c 'python -m pytest ...'` exits 127, so every pytest Wall test "fails on base" by launch error: red-first is vacuous and the clean-base `already_satisfied` path can never fire. It also skips the task venv (E-98a's verify defect, still live in Wall).
-- Goal: the base runner uses verify `runnerCmd` (project interpreter first); a missing tool or exit 127 is `not_run`, which refuses the seal (NOT PROVEN), never counts as red. Delete the `RUNNER_CMD` table.
-- Files: loki-ts/src/engine10/stages/wall.ts and its test.
-- Wall check: red first, with no `python` on PATH and a `.venv` shim, a Wall test that passes on base is sealed today and refused after; with no interpreter at all the result is not_run. Eval: medium n=2, report Wall seal count against E-98f.
-- HIGH (moat); 30 min. Dependencies: none. Core: -3.
-
-### Wave 2 (after S41-01 to S41-04 merge; 5 cards)
-
-**S41-06 Baseline scorecard (eval only).**
-- Goal: run small and medium, n=2, all 4 arms through S41-03, and append the "before" tables through S41-02. This is the reference for every later card.
-- Files: docs/v10/METRICS.md.
-- Wall check: every row has a non-null cost, or the table says n/a with the row ids. Raw rows are reused later only while the harness hash matches.
-- MEDIUM; 90 min of eval. Dependencies: S41-01 to S41-04. Core: 0.
-
-**S41-07 Plan on the cheap model.**
-- Goal: with the cascade on, plan pins `model: cascadeImplementModel()`, the same pin Wall and intake already use (wall.ts:139, already_done.ts:177).
-- Files: loki-ts/src/engine10/stages/plan.ts and its test.
-- Wall check: red first, a session-options test shows the plan model is sonnet under `LOKI_MODEL_OVERRIDE=claude-opus-5-5`. Eval: loki-opus on medium, n=2; plan cost per run down at least 60% against S41-06, completion not lower.
-- MEDIUM; 15 min. Dependencies: S41-06 for the eval. Core: +1.
-
-**S41-08 Top model and deterministic-failure escalation.**
-- Goal: `LOKI_E10_TOP_MODEL` (an alias, default `opus`, through `resolveModelAlias`) replaces `ctx.model` as the escalation target. `isDeterministicFailure(prevVerify, verify, baseTests, wallPaths)` in e10ext/escalate.ts implements section 4. verify.ts records `exit_code` per check.
-- Files: loki-ts/src/e10ext/escalate.ts, loki-ts/src/engine10/stages/fix.ts, loki-ts/src/engine10/stages/verify.ts, and their tests.
-- Wall check:
-  - Red first: flaky, not_run, lint, system-interpreter, exit 5 and attempt-authored failures never escalate. A reproduced project-interpreter fail escalates in round 2, and loki-sonnet reaches opus where today it cannot.
-  - Eval: loki-sonnet on medium, n=2; report the escalation rate and the cost share of escalated rounds.
-- HIGH (verify); 45 min. Dependencies: S41-06. Core: +4.
-
-**S41-09 Lean stable prefix (flag).**
-- Goal: `LOKI_E10_PREFIX=lean` gives engine10 sessions a short fixed string system prompt instead of the `claude_code` preset. The tool list is unchanged.
-- Files: loki-ts/src/runner/providers.ts and its test.
-- Wall check:
-  - Red first: the options test shows `systemPrompt` is a string under the flag and the preset without it.
-  - Eval: `first_turn_prompt_tokens` down at least 40% on every stage; completion on medium, n=2, not below S41-06.
-  - Kill criterion: if S41-04 shows the prefix is under 10% of implement cache reads, close with the measurement and build nothing.
-- MEDIUM; 30 min. Dependencies: S41-04. Core: 0.
-
-**S41-14 Wall in parallel with implement (item 4, promoted for speed).**
-- Goal:
-  - FLOW becomes `intake, plan, [wall, implement], verify`.
-  - Wall still writes only in its temp dir. Its copy-in and its red-on-base check run after implement completes: snapshot, reset to base, run the Wall tests (they must fail), restore.
-  - The `already_satisfied` short-circuit moves to that post-implement check.
-- Files: loki-ts/src/engine10/machine.ts, loki-ts/src/engine10/stages/wall.ts, and their tests.
-- Wall check: red first, implement's `stage.started` precedes Wall's `stage.completed`, sealed sha256 values are unchanged, and a Wall test passing on base is still refused after the move. Eval: medium p50 not worse than S41-06, completion not lower, and report Wall's share of wall-clock. E-98f argues against a big win: nowall p50 214s against default 209s, nocascade (opus implement) 138s, so the time is in implement, not Wall.
-- HIGH (moat: the red-first Wall); 45 min. Dependencies: S41-12, S41-16. Core: +6.
-
-### Wave 3 (2 cards)
-
-**S41-10 Relevant context and a static-first brief.**
-- Goal: the implement and fix briefs:
-  - put the fixed rules first, as a block that is byte-identical across stages and runs;
-  - replace the first 200 repo paths (`repoMapText`) with up to 20 relevant files: plan `relevant_files`, else `selectRelevantFiles` over the tree-keyed cached map (cache.ts `repomap-<tree>.json`);
-  - add their impacted tests, with one exact command per test from verify `runnerCmd` (project interpreter included).
-- Files: loki-ts/src/e10ext/context.ts, loki-ts/src/engine10/stages/implement.ts, loki-ts/src/engine10/stages/fix.ts, and their tests.
-- Wall check: red first, the brief for a 2,000-file fixture is under 3 KB and names `.venv/bin/python -m pytest -q <test>`. Eval: loki-sonnet on medium, n=2; implement cache reads per completed down at least 30% against S41-06, completion not lower.
-- MEDIUM; 30 min. Dependencies: S41-08 (fix.ts). Core: +1.
-
-**S41-11 Rule-based trajectory trimming (flag).**
-- Goal: `LOKI_E10_TRIM=1` adds a PostToolUse hook that returns `updatedToolOutput`. It only shortens new results; rewriting history would break the cache prefix and is out of scope.
-- Rules:
-  - A Bash result over 200 lines keeps the first 40 and the last 120, plus a `[loki trimmed N lines]` marker.
-  - A Read over 400 lines keeps the first 400.
-  - A Grep over 100 matches keeps the first 100.
-  - From tool call 25 on, the limits halve.
-  - A Bash command that exits nonzero always keeps its last 120 lines.
-- Files: loki-ts/src/runner/trim.ts, loki-ts/src/runner/providers.ts, and their tests.
-- Wall check: red first, each rule, the nonzero-exit tail guarantee, and unchanged pass-through when the flag is off. Eval: implement cache reads per completed down at least 25% on medium, n=2, completion not lower.
-- MEDIUM; 30 min. Dependencies: S41-09 (providers.ts). Core: 0.
-
-### Wave 4 (1 card)
-
-**S41-13 Two parallel attempts (flag).**
-- Goal: with `LOKI_E10_ATTEMPTS=2`, implement runs 2 cheap-model sessions concurrently when the section 4 gate allows.
-  - A runs in repoDir; B runs in a detached worktree at baseSha under runDir.
-  - Each is scored in the primary tree through S41-12. S41-05 picks the winner, which is applied to repoDir. Verify and Seal then run as today.
-  - A check that failed in both attempts feeds S41-08 condition 6.
-- Files: loki-ts/src/e10ext/attempts.ts, loki-ts/src/engine10/stages/implement.ts (hook), and their tests.
-- Wall check:
-  - Red first: fake sessions cover early accept, full ranking, the both-disqualified fallback, and gate-off with no selector. For a run with a killed attempt, the sum of `cost` events equals the harness `cost_usd`.
-  - Eval: loki-sonnet on medium, n=3 (E-98f's n); completion at least 18/21 (raw's best rate, EV-14), and the tier verdict not red on cost.
-- HIGH; 45 min. Dependencies: S41-05, S41-08, S41-10, S41-12. Core: +6.
-
-### Wave 5 (1 card)
-
-**S41-15 After scorecard and defaults.**
-- Goal: rerun S41-06 with every flag. Flip a flag's default in `sizing.ts` only when the tier verdict with it is at least as green as without it, on both small and medium.
-- Files: loki-ts/src/engine10/sizing.ts, docs/v10/METRICS.md.
-- Wall check: the before and after tables sit side by side in METRICS.md. The D41 flip happens only on green for small and medium. The headline row (loki-sonnet against raw-opus) is reported either way.
-- HIGH (default flow); 90 min of eval plus 15 min of code. Dependencies: all of the above. Core: +3.
-
-**Core total:** -3 +1 +4 +6 +1 +6 +3 = +18 of 35 headroom. A card over its estimate offsets the excess in the same slice (D33). **Wave counts:** W1 7, W2 5, W3 2, W4 1, W5 1 (16 cards). Only S41-06 and S41-15 are eval-only.
-
-## 6. Risks
-
-- **Seal accuracy (top risk).** S41-12, S41-13 and S41-14 change which tree Seal sees and when the Wall is proven red, so a treeswap bug could seal an unverified tree. Guards: verify and Seal always re-run on the final primary tree; Seal's sha256 check on Wall files is unchanged; red-on-base stays mandatory, only later; each card carries a mutation test that must go red.
-- **Wall red-on-base is vacuous today (S41-16).** Until it merges, Wall seals on this host prove nothing about red-first; S41-14 must not move the check before S41-16 lands.
-- **Cost measurement.** Partial-stream dollars are estimates: the share is shown, and over 20% is flagged. Attempts and killed sessions write cost from two cwds; S41-13's event-sum check guards this. Without S41-01, every null row keeps cost red forever.
-- **Attempts can raise cost.** Implement is already 69% of v10 spend. Two attempts pay off only if S41-10 and S41-11 cut per-attempt reads first and early accept often kills B. S41-15 keeps the flag off unless the verdict says otherwise.
-- **p50 comparability.** E-98f ran up to 12 concurrent sessions against EV-15's 3. The scorecard refuses unequal `--parallel`, arms run back to back, and keychain waits fall outside the timed rows.
-- **Noise.** At n=21 one run flips a mark; the table prints n. **Escalation starvation:** condition 6 delays opus to round 2; the eval reports the share of round-2 wins that escalation bought.
-- **Accuracy regressions from trimming and a lean prefix.** Both are flags with completion floors in their Wall checks. Trimming never cuts a failing command's tail.
-
-## 7. Later waves (items 3 to 5, sketches only)
-
-**Item 3, repo memory.** Extend cache.ts's per-repo dir (maps already keyed by tree) with the verified build and test command per runner (the one that ran on the project interpreter), the flaky list (`recordFlaky` exists), the top failure causes (`topFailures` exists, but only the brief reads it) and conventions mined from accepted diffs. Inject one fixed-size block into S41-10's static-first brief. Measure cold against warm: the same task twice, cache wiped then kept; warm must be cheaper and faster on the scorecard.
-
-**Item 4, speed.** Wall in parallel is S41-14. Still to do: cache dependency install by lockfile hash (venv or node_modules restored by `sha256(lockfile)`), keep fast verify to impacted tests only with a cap on the changed-test-files list, and pipeline plan into implement on the lean path. Target: p50 at or below raw on every tier.
-
-**Item 5, backlog throughput.** `loki <label|milestone>` fetches N issues (fetch_issue.ts) and runs one supervisor per issue, each in its own worktree with a single writer, opening one PR per issue. Total spend and concurrency are bounded by the D39 usage governor. Measure issues per hour and cost per merged PR against raw run serially.

package/docs/v10/SWARM-PROMPT.md

@@ -1,98 +0,0 @@
-# Founder prompt: the swarm (2026-09-26)
-
-Verbatim, as given. `docs/v10/SWARM.md` records what was adopted, the
-reconciliations required by CLAUDE.md and the build prompt (D12, D13), and
-why. Read SWARM.md first; this file is the historical source text.
-
----
-
-ultracode
-
-Switch the v10 build from one loop to a coordinated swarm. Goal: 10-20x more releases per day than cycles 1-4 (about 3 releases in 18 hours), without weakening anything in docs/LOKI-10-BUILD-PROMPT.md sections 2, 5b and 5c. Every "never do" rule still applies. Save this prompt as docs/v10/SWARM.md and follow it until the v10 definition of done.
-
-Why it is slow (docs/v10/PROGRESS.md): each cycle batches 3-6 slices into one release. It reviews the whole batch in serial council rounds (cycle 1 took 9 rounds, cycle 3 took 6). Then it verifies every channel before the next cycle starts. So each release waits on the slowest slice and on every round.
-
-ROLES. All roles are agents you spawn through Workflow. You are the orchestrator, and the only one who writes FOUNDER-QUEUE.md.
-
-1. Product Owner (1 agent; writes docs/v10/BACKLOG.md and docs/v10/BOARD.md, never code).
-   - Ranks the backlog per build prompt section 3.
-   - Cuts work into release-sized slices. Each slice has:
-     - under about 300 changed lines;
-     - one owner;
-     - a declared file set that overlaps no other in-flight slice;
-     - acceptance checks written before building (the Wall);
-     - a risk tier.
-   - Keeps twice the builder count of ready slices queued, so builders never wait.
-
-2. Builders (6-10 in parallel; isolation: worktree; one slice each; single writer).
-   - Implement with red-then-green tests.
-   - Run diff-scoped tests plus tests/moat in the worktree.
-   - Return the patch and its evidence.
-   - Never touch main or VERSION, and never edit outside the declared file set. If that is needed, return BLOCKED and let the PO re-slice.
-
-3. Reviewers (read-only, parallel, diff-scoped, tiered by risk). Each finding must come with a reproduction.
-   - HIGH tier (verifier, Seal, gates, council, exit codes, auth, secrets, tests/moat): 3 reviewers with different lenses (correctness, security/bypass, fail-closed), plus 1 adversarial reviewer told to find a false pass. APPROVE needs 3 of 4.
-   - MEDIUM tier (runtime, CLI behavior, dashboard logic): 2 reviewers.
-   - LOW tier (docs, copy, tests only, UI without a data path, deleting unreachable code): 1 reviewer.
-   - The builder fixes findings in the same worktree. After 3 rounds, the slice goes back to the PO to be cut smaller. It never blocks the line.
-
-4. Release Captain (exactly 1; the only agent allowed to write main, bump VERSION, tag or publish). It runs a serial merge queue. For each approved slice:
-   - Rebase onto origin/main.
-   - Run bash scripts/local-ci.sh (fast tier) and tests/moat. The ratchet must not regress; if it does, refuse the merge.
-   - Stage by name, commit with the asklokesh identity, push.
-   - Cut a release through scripts/release.sh.
-   - Wait for the previous release's required-ci (Tests, Bun Parity, Security Audit) to go green before bumping VERSION again, so releases never cancel each other's CI (the v9.7-v9.9 failure).
-   - If several slices are waiting, ship them together as one version rather than wait.
-   - On a code conflict, send the slice back to its builder with the new base. Never resolve code conflicts itself.
-
-5. Channel Verifier (1, async, read-only).
-   - After each release, check: npm latest and gitHead, the tag, the GitHub release, Docker amd64/arm64, the Homebrew sha256, and a smoke test from a fresh PATH.
-   - Never block the next merge.
-   - A failure becomes a HIGH-priority fix-forward slice. Never unpublish or delete a version.
-
-ORCHESTRATION
-- Run repeated Workflow waves. In each wave, the PO produces up to 10 slices, then run: pipeline(slices, build -> verify -> review/fix loop -> captain queue).
-- Use pipeline, not barriers. A LOW slice ships while a HIGH slice is still in review.
-- In the script, serialize the Captain with a promise chain, so exactly one merge or release runs at a time.
-- Agents coordinate through BOARD.md (slice id, owner, file set, tier, status, blockers) and through structured return values. Only the PO and the Captain write BOARD.md.
-- Start the next wave as soon as the PO has ready slices. Never wait on channel verification.
-
-SPEED LEVERS, in order
-1. One slice, one release.
-2. Risk-tiered review; most slices are LOW or MEDIUM.
-3. Parallel reviewers per slice instead of serial whole-batch rounds.
-4. Asynchronous channel verification.
-5. Diff-scoped tests while building; the full fast tier plus moat runs only at merge.
-6. Flaky tests: rerun once, record it, open a slice. Never pass a flake silently (see BACKLOG 93).
-
-GUARDRAILS (restated, because speed pressure erodes them)
-- When goals conflict: moat > Seal accuracy > delivered accuracy > cost > speed.
-- The moat ratchet never regresses on main.
-- If two releases in a row fail required-ci, stop releasing, fix main, then resume.
-- No force push. Never delete versions. Never disable tests.
-- The swarm spends faster. Log spend per wave in METRICS.md. If a wave would push past founder-queue item 3, drop to 3 builders, keep shipping LOW slices, and add one founder-queue line asking for a higher budget.
-
-METRICS (append to METRICS.md after every wave)
-- releases in the last 24h
-- median slice lead time (ready to npm)
-- review rounds per slice, by tier
-- moat proven count
-- required-ci failures
-- spend
-
-Target: at least 30 releases per 24h at steady state, with the moat proven count never decreasing.
-
-START NOW
-1. Write docs/v10/SWARM.md and docs/v10/BOARD.md.
-2. Have the PO slice the top of the backlog: BACKLOG 94-98, P9 Rule of Two, and M0 measurement (claude-opus-5-5 in the model catalog, the seeded-defect corpus, the adoption eval).
-3. Launch wave 1.
-4. After each wave, append a wave entry to PROGRESS.md.
-
----
-
-**Note on step 2 of START NOW:** BACKLOG 94-98, P9, and the model-catalog half
-of M0 were already done or in flight when this prompt arrived (P9 fully done
-awaiting a validation PR; P4's catalog and three-setups cases done awaiting
-review; BACKLOG 95 and 97 fixed on main; 96 and 98 partly fixed by the P7
-sweep). Wave 1's real seed is the actual repo state at adoption time, recorded
-in `docs/v10/BOARD.md`, not this stale list.