@bytesbrains/cruise-worker 0.0.0-stage → 0.12.0

package/migrations/0070_lane_member_quality_rank.sql

@@ -0,0 +1,98 @@
+-- A declared order among a lane's members, so a lane hit can only be an
+-- upgrade (#278, epic #272). Spec: #20, auto-mode.md §6.
+--
+-- ## What the rank is for
+--
+-- Lane scope relaxes exactly one term of the cache key — the model — so an
+-- answer a frontier member already produced can serve a request the lane
+-- would have sent to a cheaper one. That is a saving and a quality upgrade at
+-- once, which is what makes it safe. Reverse the direction and it is the
+-- worst failure available to this system: a worse answer, reported as a hit
+-- from a better model, invisible to the caller who is billed a fraction for
+-- it. `rank` is the column that fixes the direction.
+--
+-- 1 is best. A hit is served only when the entry's origin ranks at or above
+-- the member the lane would otherwise have sent to, and **NULL on either side
+-- is a miss** — an unranked member is not "probably fine", it is a model
+-- nobody has placed, and placing it is the act this column records.
+--
+-- ## Why it is declared, and not derived
+--
+-- Not from `position`, which is listing order and has never meant quality —
+-- 0026 says so in as many words: `lane_members` is the candidate set, not a
+-- priority. Not from price either: #19 scores on price alone precisely
+-- because quality is unmeasured, so deriving quality back out of price would
+-- be circular, and a lane's cheapest member is frequently not its worst.
+--
+-- auto-mode.md §6 asks for an ordering that is "statistically clear, not
+-- nominal", and holds that cross-model serving is permitted only across a
+-- margin wide enough to survive its own confidence interval. **There is no
+-- such measurement yet, and this column is not it.** It is a person's reading
+-- of model families and sizes, written down so the direction is at least
+-- stated rather than assumed. The margin is the follow-up, and it needs a
+-- quality signal this repo does not collect; that is named here so the next
+-- person does not mistake a declared order for the designed one.
+--
+-- ## The values below
+--
+-- Coarse on purpose, three or four tiers per lane rather than a total order.
+-- A tie asserts the two members are peers for this lane's job, and either may
+-- serve the other's answer; separating models this repo cannot tell apart
+-- would be a precision the input does not have. Proposed 2026-09-07 against
+-- the eight global lanes as they stood, and reviewed before merge by the
+-- person who owns them.
+--
+-- Tenant lanes are left NULL. Nobody here can rank another tenant's members,
+-- and the control plane is how their owner does it (#278).
+--
+-- ## Why `quality_rank` and not `rank`
+--
+-- #278 proposed `rank`, and the word was already taken twice. The published
+-- API reference uses "rank" for the *allocator's* order under `graduated`
+-- selection — "rate-limited first, then failing, then price"
+-- (`openapi-schemas-lanes.ts`) — and `tierOf` in `lanes-quota.ts` is the
+-- tenant's billing tier. Either collision is the kind that reads fine until
+-- somebody wires `graduated`'s shares to this column, at which point a lane
+-- distributes traffic by a quality order nobody meant it to, and the two
+-- meanings are close enough that the mistake would survive review. The name
+-- says which rank it is.
+
+ALTER TABLE lane_members ADD COLUMN quality_rank INTEGER;
+
+-- 1 = best. Written per lane, so a member appearing in two lanes can rank
+-- differently in each — `codestral` is a first-tier code-completion model and
+-- a second-tier agentic-coding one, and that is a fact about the job, not
+-- about the model.
+
+UPDATE lane_members SET quality_rank = 1 WHERE lane_id = 'bb/agentic-coding' AND model_id IN ('deepseek/deepseek-v4-pro');
+UPDATE lane_members SET quality_rank = 2 WHERE lane_id = 'bb/agentic-coding' AND model_id IN ('mistral/mistral-medium-2604', 'mistral/codestral-2508');
+UPDATE lane_members SET quality_rank = 3 WHERE lane_id = 'bb/agentic-coding' AND model_id IN ('deepseek/deepseek-v4-flash');
+UPDATE lane_members SET quality_rank = 4 WHERE lane_id = 'bb/agentic-coding' AND model_id IN ('workers-ai/@cf/qwen/qwen3.8-27b');
+
+UPDATE lane_members SET quality_rank = 1 WHERE lane_id = 'bb/chat-assistant' AND model_id IN ('mistral/mistral-small-latest');
+UPDATE lane_members SET quality_rank = 2 WHERE lane_id = 'bb/chat-assistant' AND model_id IN ('mistral/ministral-8b-2512', 'workers-ai/@cf/google/gemma-4-26b-a4b-it', 'workers-ai/@cf/openai/gpt-oss-20b', 'workers-ai/@cf/zai-org/glm-4.7-flash');
+UPDATE lane_members SET quality_rank = 3 WHERE lane_id = 'bb/chat-assistant' AND model_id IN ('mistral/ministral-3b-2512', 'workers-ai/@cf/meta/llama-3.2-3b-instruct');
+
+UPDATE lane_members SET quality_rank = 1 WHERE lane_id = 'bb/code-completion' AND model_id IN ('mistral/codestral-2508');
+UPDATE lane_members SET quality_rank = 2 WHERE lane_id = 'bb/code-completion' AND model_id IN ('deepseek/deepseek-v4-flash');
+UPDATE lane_members SET quality_rank = 3 WHERE lane_id = 'bb/code-completion' AND model_id IN ('workers-ai/@cf/qwen/qwen2.5-coder-32b-instruct', 'workers-ai/@cf/qwen/qwen3.8-27b');
+
+UPDATE lane_members SET quality_rank = 1 WHERE lane_id = 'bb/code-review' AND model_id IN ('deepseek/deepseek-v4-pro', 'mistral/mistral-large-2512');
+UPDATE lane_members SET quality_rank = 2 WHERE lane_id = 'bb/code-review' AND model_id IN ('mistral/mistral-medium-2604', 'workers-ai/@cf/openai/gpt-oss-120b');
+UPDATE lane_members SET quality_rank = 3 WHERE lane_id = 'bb/code-review' AND model_id IN ('deepseek/deepseek-v4-flash');
+
+UPDATE lane_members SET quality_rank = 1 WHERE lane_id = 'bb/deep-reasoning' AND model_id IN ('deepseek/deepseek-v4-pro');
+UPDATE lane_members SET quality_rank = 2 WHERE lane_id = 'bb/deep-reasoning' AND model_id IN ('workers-ai/@cf/openai/gpt-oss-120b', 'workers-ai/@cf/nvidia/nemotron-3-120b-a12b');
+UPDATE lane_members SET quality_rank = 3 WHERE lane_id = 'bb/deep-reasoning' AND model_id IN ('workers-ai/@cf/qwen/qwq-32b', 'workers-ai/@cf/deepseek-ai/deepseek-r1-distill-qwen-32b', 'mistral/mistral-medium-2604');
+
+UPDATE lane_members SET quality_rank = 1 WHERE lane_id = 'bb/extraction' AND model_id IN ('mistral/mistral-small-latest', 'deepseek/deepseek-v4-flash');
+UPDATE lane_members SET quality_rank = 2 WHERE lane_id = 'bb/extraction' AND model_id IN ('mistral/ministral-8b-2512', 'workers-ai/@cf/zai-org/glm-4.7-flash');
+UPDATE lane_members SET quality_rank = 3 WHERE lane_id = 'bb/extraction' AND model_id IN ('workers-ai/@cf/ibm-granite/granite-4.0-h-micro');
+
+UPDATE lane_members SET quality_rank = 1 WHERE lane_id = 'bb/summarization' AND model_id IN ('mistral/mistral-small-latest', 'deepseek/deepseek-v4-flash');
+UPDATE lane_members SET quality_rank = 2 WHERE lane_id = 'bb/summarization' AND model_id IN ('mistral/ministral-8b-2512', 'workers-ai/@cf/google/gemma-4-26b-a4b-it', 'workers-ai/@cf/zai-org/glm-4.7-flash');
+UPDATE lane_members SET quality_rank = 3 WHERE lane_id = 'bb/summarization' AND model_id IN ('workers-ai/@cf/meta/llama-3.2-3b-instruct');
+
+UPDATE lane_members SET quality_rank = 1 WHERE lane_id = 'bb/translation' AND model_id IN ('mistral/mistral-medium-2604');
+UPDATE lane_members SET quality_rank = 2 WHERE lane_id = 'bb/translation' AND model_id IN ('mistral/mistral-small-latest', 'mistral/ministral-14b-2512');
+UPDATE lane_members SET quality_rank = 3 WHERE lane_id = 'bb/translation' AND model_id IN ('workers-ai/@cf/google/gemma-4-26b-a4b-it', 'workers-ai/@cf/aisingapore/gemma-sea-lion-v4-27b-it', 'deepseek/deepseek-v4-flash');

package/migrations/0071_key_cache_pool.sql

@@ -0,0 +1,60 @@
+-- The pool a key's cached answers are shared within (#279, epic #272).
+-- Spec: #20, auto-mode.md §6, v0.md §4.
+--
+-- ## Why this column exists at all
+--
+-- auto-mode.md §6 is blunt about the trade: a cache spanning projects
+-- dissolves v0's isolation model deliberately, and cross-project sharing is
+-- where most of the savings live. Per-project is the default and stays the
+-- default; this column is the *widening*, and the whole design of it is that
+-- a caller cannot perform the widening on itself.
+--
+-- Three pools, and the key names one:
+--
+--   project   {tenant}:{project}   the default, and the only pool an unmarked key touches
+--   tenant    {tenant}             every marked key in the tenant
+--   platform  bb                   ours: the conformance runner, eval prep, internal tooling
+--
+-- `platform` is the deliberate version auto-mode.md §6 asks for — a `bb/` lane's hot set,
+-- paid for once at frontier quality, serving every project underneath. It is
+-- not something a tenant can reach: `issueKey` refuses it unless the key's
+-- project belongs to a tenant with `operator = 1` (0051), which is the same
+-- column that decides who may read the platform's own state, and `doctor`
+-- re-asks the question of every live key rather than trusting the write.
+--
+-- ## Why it is on the key, and not on the request
+--
+-- A traffic class is a label the caller chooses within what the key allows
+-- (`src/metadata.ts`), and that is exactly the shape this must not have. A
+-- caller declaring "my traffic carries no end-user content" is a caller
+-- widening its own cache pool, which is the mistake the gate exists to
+-- prevent — and it would be a privacy incident rather than a bug, because the
+-- widening is invisible from both sides: the project whose answer leaks sent
+-- a request that succeeded, and the project that received it was served a
+-- correct answer to its own question.
+--
+-- So it is set once, at issue, by someone who has read what the key will
+-- carry, and it lands in `audit_events` beside the issue like every other
+-- privileged act (0044). A key's pool can be narrowed afterwards; widening is
+-- a new key, because the argument for the wider pool was made about the
+-- traffic the old key was already sending.
+--
+-- ## Read down, write own
+--
+-- A marked key **reads** its own pool and every narrower one, and **writes**
+-- only its own. So a project key never sees another project's entry; a
+-- tenant-pool key never sees another tenant's; and a tenant-pool key's write
+-- is not visible to a project-pool key in the same project, which is the
+-- direction that keeps the default honest — an unmarked key behaves today
+-- exactly as it did before this migration, whatever its neighbours are marked.
+--
+-- ## The default, and why NOT NULL
+--
+-- Every key issued before this reads back `project`, which is what it has been
+-- doing since #274. NOT NULL with a default rather than a nullable column,
+-- because a null here would have to be *interpreted*, and the two readings
+-- ("unmarked, so narrowest" and "not yet decided") differ by exactly the
+-- privacy property this column carries.
+
+ALTER TABLE virtual_keys ADD COLUMN cache_pool TEXT NOT NULL DEFAULT 'project'
+  CHECK (cache_pool IN ('project', 'tenant', 'platform'));

package/migrations/0072_cache_digest.sql

@@ -0,0 +1,51 @@
+-- The two facts a tier-rule violation is found from (#281, epic #272; the
+-- rule is #20 and auto-mode.md §6, the measurement #21 and auto-mode.md §9).
+--
+-- A lane hit is an answer produced by a *different* model than the one this
+-- request would have been sent to, served on the strength of a declared
+-- order that says the origin ranks at or above it. Nothing measures that
+-- order (#19: score is price-only), so the only evidence that it is wrong
+-- comes from callers: a lane hit followed within minutes by the **same
+-- normalised body from the same key** asking `scope=off` or `scope=model` is
+-- a caller saying the replay was not good enough and paying for a live answer
+-- to prove it. That is the violation counter, target zero.
+--
+-- The ledger could not find one. It kept `cache_scope` and the origin (0068),
+-- and neither says what was asked nor lets two rows be recognised as the same
+-- request. Hence two columns.
+--
+-- ## `cache_digest`
+--
+-- The whole unsalted SHA-256 of the normalised body — the last term of the
+-- store key (`src/cache-store.ts`), so "the same request" here means exactly
+-- what it means to the cache, and the violation counter can join a hit to the
+-- live request that followed it. Not the prompt: the row still carries no
+-- content. Not "nothing a person wrote" either (#374): an unsalted digest of a
+-- short, guessable body confirms a guess exactly. Left unsalted on purpose —
+-- salting both this column and the store key would keep the join and close
+-- that oracle, at the cost that rotating the salt orphans every historical
+-- digest and invalidates every cache entry. The digest is returned by no
+-- route; who can read D1 can read the KV bodies directly. NULL when the cache
+-- was off (`CACHE_MODE=off`, or no binding), which is when nothing can hit and
+-- so nothing can be found to have hit wrongly; NULL on every row before this.
+--
+-- ## `cache_requested`
+--
+-- The scope the caller's `x-cruise-cache` asked for — `model`, `lane`, `off`
+-- — NULL when the header named no scope, and NULL, like the digest, when the
+-- cache was off. Kept separately from
+-- `cache_scope`, which is what *served* and is NULL on every miss: the
+-- violation is read from what was asked, on a row that was deliberately not
+-- served from cache.
+--
+-- The index is the join the counter makes: a hit's key and digest, then
+-- forward in time. Partial, because most rows have no digest and none of
+-- them can be the second half of a violation.
+
+ALTER TABLE ledger ADD COLUMN cache_digest TEXT;
+ALTER TABLE ledger ADD COLUMN cache_requested TEXT
+  CHECK (cache_requested IS NULL OR cache_requested IN ('model', 'lane', 'off'));
+
+CREATE INDEX IF NOT EXISTS idx_ledger_cache_digest
+  ON ledger (key_prefix, cache_digest, at)
+  WHERE cache_digest IS NOT NULL;

package/migrations/0073_lane_max_chain.sql

@@ -0,0 +1,51 @@
+-- A lane holds its own chain depth (#362).
+--
+-- `MAX_CHAIN = 3` in `src/fallback.ts` bounds how many candidates one request
+-- may try. It is a wall-clock bound and not a taste: every candidate gets the
+-- **full** upstream deadline, so a five-member lane on a bad day is five
+-- deadlines end to end, long after the caller stopped waiting. #244 wrote that
+-- down and this column does not touch it. What it adds is the ability to ask
+-- for **fewer**.
+--
+-- ## Two lanes want a shorter chain, and neither could ask
+--
+-- **Fail fast.** An interactive lane would rather hand back the provider's 429
+-- and its `retry-after` in milliseconds and let the client decide than spend a
+-- second full deadline discovering the same thing. A pinned model can already
+-- say this — a chain with no fallbacks is depth 1, and `fallback:set` writes
+-- it — and a lane could not. That asymmetry is what this closes.
+--
+-- **Members sharing an upstream.** `bb/long-context` is DeepSeek, DeepSeek,
+-- Mistral, Mistral. DeepSeek throttles per organisation, so a 429 on the first
+-- member is a 429 on the second: depth 3 there buys one useful attempt and one
+-- round trip that could not have gone differently. `fallbacks-write.ts` already
+-- warns an operator whose hand-written chain sits entirely on one upstream; a
+-- lane has no equivalent. #361 is the half of that needing no setting.
+--
+-- ## NULL, not 3
+--
+-- 0069 gave `cache_ttl_seconds` NOT NULL DEFAULT 0 because 0 was a real
+-- decision somebody could have made — the lane caches nothing — and every
+-- existing lane had in fact been doing it. This column's default is not a
+-- number. It is "whatever the platform bound is", and writing 3 into every row
+-- would state a figure nobody chose and pin each lane to it on the day
+-- `MAX_CHAIN` moves. So NULL means *defer to the platform*, every lane
+-- existing today reads back NULL, and the constant stays in one place.
+--
+-- ## The CHECK repeats the constant, deliberately
+--
+-- 1 to 3, which is `MAX_CHAIN` said in SQL, the way 0069's 2592000 is
+-- `CACHE_MAX_TTL_SECONDS` said in SQL. A value the request path would clamp
+-- away is a value somebody would later read back and trust, so the table
+-- refuses to hold one. The cost is that raising `MAX_CHAIN` needs a migration
+-- as well as a constant — which is correct: raising it is a claim about how
+-- long a Worker may hold a request open, and that deserves the paperwork.
+-- `lanes-validate.ts` refuses the same range earlier, with a message; this is
+-- the floor under it, not the report.
+--
+-- **Deploy order is migrate first, then the Worker.** Adding a column is
+-- invisible to code that does not name it, so the running Worker is
+-- unaffected; new code naming a column that is not there is what would fail.
+
+ALTER TABLE lanes ADD COLUMN max_chain INTEGER
+  CHECK (max_chain IS NULL OR max_chain BETWEEN 1 AND 3);

package/migrations/0074_hunter_builder_lanes.sql

@@ -0,0 +1,149 @@
+-- Platform lanes for an agent tenant's Hunter and Builder (#409).
+--
+-- Both consumers already send `x-cruise-session` (affinity, #394) and
+-- `x-cruise-class: agentic`, and both have been calling `bb/agentic-coding`.
+-- That lane is the right *surface* — long tool-use over a repository — and
+-- the wrong *job*: one quality ranking cannot optimise for "find and prove a
+-- vuln" and "implement and prove green" at once. Separate lanes let each
+-- product's outcome metrics retune members without dragging Claude Code's
+-- general coding agent along.
+--
+-- ## Vocabulary ahead of the board
+--
+-- `hunter` and `builder` are not on the model board's job list as of this
+-- migration. The board owns the words (#79); until it does, Cruise is one
+-- step ahead for two product-facing defaults that cannot wait on a tenant
+-- lane under `other`. The CHECK and `JOBS` grow together; a later board
+-- rename is a migration, same as 0029's `bulk-extraction` → `extraction`.
+--
+-- ## Why rebuild rather than ALTER
+--
+-- SQLite cannot widen a CHECK. 0029 put the closed job set on `lanes.job`;
+-- adding two words means recreating `lanes` (and its children that FK it).
+-- Same shape as 0028/0029: new tables, copy, drop children then parent,
+-- rename. No `PRAGMA foreign_keys` — D1 does not offer a usable deferral
+-- (0067).
+--
+-- ## Member pools
+--
+-- Same bar as every other `bb/` lane: ≥3 routable, measured members with
+-- real price spread. Overlap with `bb/agentic-coding` / `bb/code-review` is
+-- expected; the *ranks* diverge.
+--
+--   bb/hunter  — security expedition (prove by detonation). Prefer
+--                security-strong members; codestral stays out (coding
+--                polish invents plausible vulns). Flash is failover only.
+--   bb/builder — implementation loop (prove by green tests). Coding-
+--                strong first; flash last. Selection `graduated` on both
+--                so a cheap flash does not own the sticky run.
+--
+-- `tools-required` on both, same as agentic-coding. `long-context` is not
+-- seeded: several otherwise-fit members sit under 131k, and affinity already
+-- holds the member once the run starts — a cold pick among short-window
+-- models is a different problem than mid-run reallocation.
+
+CREATE TABLE lanes_new (
+  id          TEXT PRIMARY KEY,
+  tenant_id   TEXT REFERENCES tenants(id),
+  job         TEXT NOT NULL CHECK (job IN (
+                'chat-assistant', 'deep-reasoning', 'summarization', 'translation',
+                'content-writing', 'extraction', 'code-completion', 'agentic-coding',
+                'hunter', 'builder',
+                'code-review', 'document-understanding', 'speech', 'rag-grounded-answers',
+                'computer-use', 'content-moderation', 'other')),
+  description TEXT NOT NULL,
+  enabled     INTEGER NOT NULL DEFAULT 1,
+  created_by  TEXT NOT NULL DEFAULT 'migration',
+  created_at  TEXT NOT NULL DEFAULT (datetime('now')),
+  updated_at  TEXT NOT NULL DEFAULT (datetime('now')),
+  archived_at TEXT,
+  selection   TEXT NOT NULL DEFAULT 'cheap'
+              CHECK (selection IN ('cheap', 'random', 'weighted')),
+  selection_policy TEXT NOT NULL DEFAULT 'cheap'
+              CHECK (selection_policy IN ('cheap', 'random', 'weighted', 'graduated')),
+  cache_ttl_seconds INTEGER NOT NULL DEFAULT 0
+              CHECK (cache_ttl_seconds BETWEEN 0 AND 2592000),
+  cache_scope TEXT NOT NULL DEFAULT 'model'
+              CHECK (cache_scope IN ('model', 'lane')),
+  max_chain   INTEGER
+              CHECK (max_chain IS NULL OR max_chain BETWEEN 1 AND 3),
+  CHECK (
+    (tenant_id IS NULL     AND substr(id, 1, 3) = 'bb/') OR
+    (tenant_id IS NOT NULL AND substr(id, 1, length(tenant_id) + 1) = tenant_id || '/'
+                           AND substr(id, 1, 3) <> 'bb/')
+  ),
+  CHECK (tenant_id IS NOT NULL OR (id = 'bb/' || job AND job <> 'other'))
+);
+
+INSERT INTO lanes_new (
+  id, tenant_id, job, description, enabled, created_by, created_at, updated_at,
+  archived_at, selection, selection_policy, cache_ttl_seconds, cache_scope, max_chain
+)
+SELECT id, tenant_id, job, description, enabled, created_by, created_at, updated_at,
+       archived_at, selection, selection_policy, cache_ttl_seconds, cache_scope, max_chain
+  FROM lanes;
+
+INSERT INTO lanes_new (id, job, description, selection_policy) VALUES
+  ('bb/hunter', 'hunter',
+   'Autonomous security expedition over a pull request or repository: trace untrusted input to a dangerous sink, write a PoC, detonate it, and only then claim a finding. Not a diff review.',
+   'graduated'),
+  ('bb/builder', 'builder',
+   'Autonomous implementation loop: turn an issue into a green change. Edit, run tests, iterate on failures; finish verified-green or honestly unfinished.',
+   'graduated');
+
+CREATE TABLE lane_members_new (
+  lane_id      TEXT NOT NULL REFERENCES lanes_new(id),
+  model_id     TEXT NOT NULL REFERENCES models(id),
+  position     INTEGER NOT NULL,
+  weight       REAL NOT NULL DEFAULT 1 CHECK (weight > 0),
+  quality_rank INTEGER,
+  PRIMARY KEY (lane_id, model_id)
+);
+
+INSERT INTO lane_members_new (lane_id, model_id, position, weight, quality_rank)
+SELECT lane_id, model_id, position, weight, quality_rank FROM lane_members;
+
+-- Position is listing order only. quality_rank is 1 = best for this lane's job.
+INSERT INTO lane_members_new (lane_id, model_id, position, quality_rank) VALUES
+  ('bb/hunter',  'deepseek/deepseek-v4-pro',                    1, 1),
+  ('bb/hunter',  'mistral/mistral-large-2512',                  2, 2),
+  ('bb/hunter',  'mistral/mistral-medium-2604',                 3, 2),
+  ('bb/hunter',  'workers-ai/@cf/openai/gpt-oss-120b',          4, 3),
+  ('bb/hunter',  'deepseek/deepseek-v4-flash',                  5, 4),
+
+  ('bb/builder', 'deepseek/deepseek-v4-pro',                    1, 1),
+  ('bb/builder', 'mistral/codestral-2508',                      2, 1),
+  ('bb/builder', 'mistral/mistral-medium-2604',                 3, 2),
+  ('bb/builder', 'workers-ai/@cf/qwen/qwen2.5-coder-32b-instruct', 4, 3),
+  ('bb/builder', 'deepseek/deepseek-v4-flash',                  5, 4),
+  ('bb/builder', 'workers-ai/@cf/qwen/qwen3.8-27b',             6, 4);
+
+CREATE TABLE lane_requires_new (
+  lane_id     TEXT NOT NULL REFERENCES lanes_new(id),
+  constraint_ TEXT NOT NULL CHECK (constraint_ IN (
+                'long-context', 'tools-required', 'json-schema', 'vision-required',
+                'no-training-on-data',
+                'low-latency', 'high-throughput', 'open-weights', 'data-residency',
+                'audio-required', 'batch-api')),
+  value       TEXT,
+  PRIMARY KEY (lane_id, constraint_)
+);
+
+INSERT INTO lane_requires_new (lane_id, constraint_, value)
+SELECT lane_id, constraint_, value FROM lane_requires;
+
+INSERT INTO lane_requires_new (lane_id, constraint_) VALUES
+  ('bb/hunter',  'tools-required'),
+  ('bb/builder', 'tools-required');
+
+DROP INDEX idx_lane_members_lane;
+DROP INDEX idx_lanes_tenant;
+DROP TABLE lane_requires;
+DROP TABLE lane_members;
+DROP TABLE lanes;
+ALTER TABLE lanes_new RENAME TO lanes;
+ALTER TABLE lane_members_new RENAME TO lane_members;
+ALTER TABLE lane_requires_new RENAME TO lane_requires;
+
+CREATE INDEX idx_lane_members_lane ON lane_members (lane_id, position);
+CREATE INDEX idx_lanes_tenant ON lanes (tenant_id, enabled);

package/migrations/0075_hunter_builder_frontline.sql

@@ -0,0 +1,36 @@
+-- Restaff bb/hunter and bb/builder with frontline lab models.
+--
+-- 0074 staffed both from the DeepSeek/Mistral/Workers-AI pool that was
+-- already on `bb/agentic-coding`. That cleared the ≥3-routable bar; it did
+-- not put Google / Moonshot / Zhipu frontier at quality_rank 1. Both lanes
+-- are tools-required, so only members with a fresh tools=1 measurement
+-- may join (an unmeasured or tools=0 row never allocates).
+--
+-- What is absent on purpose (2026-09-12 UTC):
+--   anthropic/claude-*-5 — measured_at null; not routable
+--   openai/gpt-5.6-*     — measured, tools=0; fails tools-required
+-- Re-measure those with tools, then a later migration can promote them.
+--
+-- hunter still keeps codestral out (coding polish invents plausible vulns).
+-- mistral-large drops: tools=1 in the catalogue but measured_at null on
+-- production, so it was dead weight. Builder drops the qwen mid-tier now
+-- covered by Kimi coding / GLM-5.3 / Gemini Pro. Selection stays graduated.
+
+DELETE FROM lane_members WHERE lane_id IN ('bb/hunter', 'bb/builder');
+
+INSERT INTO lane_members (lane_id, model_id, position, quality_rank) VALUES
+  ('bb/hunter',  'google-ai-studio/gemini-3.1-pro-preview',     1, 1),
+  ('bb/hunter',  'deepseek/deepseek-v4-pro',                    2, 1),
+  ('bb/hunter',  'workers-ai/@cf/moonshotai/kimi-k2.6',         3, 2),
+  ('bb/hunter',  'mistral/mistral-medium-2604',                 4, 2),
+  ('bb/hunter',  'google-ai-studio/gemini-3.8-flash',           5, 3),
+  ('bb/hunter',  'workers-ai/@cf/openai/gpt-oss-120b',          6, 3),
+  ('bb/hunter',  'deepseek/deepseek-v4-flash',                  7, 4),
+
+  ('bb/builder', 'google-ai-studio/gemini-3.1-pro-preview',     1, 1),
+  ('bb/builder', 'deepseek/deepseek-v4-pro',                    2, 1),
+  ('bb/builder', 'workers-ai/@cf/moonshotai/kimi-k2.7-code',    3, 1),
+  ('bb/builder', 'workers-ai/@cf/zai-org/glm-5.3',              4, 1),
+  ('bb/builder', 'mistral/codestral-2508',                      5, 2),
+  ('bb/builder', 'mistral/mistral-medium-2604',                 6, 3),
+  ('bb/builder', 'deepseek/deepseek-v4-flash',                  7, 4);

package/migrations/0076_deepseek_flash.sql

@@ -0,0 +1,86 @@
+-- DeepSeek V4.1-Flash cutover (#375).
+--
+-- On 2026-09-10 DeepSeek shipped V4.1-Flash as `deepseek-flash` and retired
+-- V4-Flash / V4-Flash-Vision-Exp. The old API names still answer, temporarily,
+-- but they serve V4.1-Flash at that model's rate — so a Cruise row pinned to
+-- `deepseek-v4-flash` with the old price_observations is a silent misbill.
+-- From 04:00 UTC on 2026-09-14 the same happens to `deepseek-v4-pro` until a
+-- V4.1-Pro ships. Source: https://api-docs.deepseek.com/news/news260910
+--
+-- Do not UPDATE `upstream_model` in place on the old Cruise ids. That is the
+-- alias-drift failure 0013 and 0020 exist to prevent: the ledger, conformance
+-- and prices key on `models.id`, and a row that kept the old id while the
+-- host served a different model at a different rate would look continuous
+-- and be wrong. New pinned id, disable the retired ones, restaff the lanes.
+--
+-- Prices (USD per 1M tokens, in force 2026-09-10 04:00 UTC), from
+-- https://api-docs.deepseek.com/quick_start/pricing — off-peak cache hit
+-- $0.003 / input $0.15 / output $0.60; peak is 2x; window unchanged
+-- (mon-fri@01:00-04:00,mon-fri@06:00-10:00, 0039).
+--
+-- Workers AI dated rehosts (`…-0731` / `…-0813`) are a different host; leave
+-- them alone until Cloudflare's page moves.
+
+INSERT INTO models (id, upstream_id, upstream_model, max_context, max_output) VALUES
+  ('deepseek/deepseek-flash', 'deepseek', 'deepseek-flash', 1000000, 384000);
+
+INSERT INTO price_observations
+  (observed_at, model, effective_from, prompt_tokens_from, peak_utc,
+   input_micros_per_mtok, output_micros_per_mtok, cached_input_micros_per_mtok, source, note)
+VALUES
+  ('2026-09-12 00:00:00', 'deepseek/deepseek-flash', '2026-09-10', 0, '',
+   150000, 600000, 3000, 'https://api-docs.deepseek.com/quick_start/pricing',
+   'First observation: DeepSeek-V4.1-Flash as deepseek-flash (#375, 0076). Off-peak.'),
+  ('2026-09-12 00:00:00', 'deepseek/deepseek-flash', '2026-09-10', 0,
+   'mon-fri@01:00-04:00,mon-fri@06:00-10:00',
+   300000, 1200000, 6000, 'https://api-docs.deepseek.com/quick_start/pricing',
+   'Peak window unchanged from 0039; rate is 2x off-peak.');
+
+-- One Flash member per lane that held any retired DeepSeek id. Keep the best
+-- (lowest) quality_rank and earliest position among the removed rows so a
+-- Pro-at-rank-1 lane does not demote Flash to the old failover slot.
+INSERT INTO lane_members (lane_id, model_id, position, quality_rank)
+SELECT lane_id, 'deepseek/deepseek-flash', MIN(position), MIN(quality_rank)
+  FROM lane_members
+ WHERE model_id IN (
+         'deepseek/deepseek-v4-flash',
+         'deepseek/deepseek-v4-pro',
+         'deepseek/deepseek-v4-flash-vision-exp'
+       )
+ GROUP BY lane_id;
+
+DELETE FROM lane_members
+ WHERE model_id IN (
+         'deepseek/deepseek-v4-flash',
+         'deepseek/deepseek-v4-pro',
+         'deepseek/deepseek-v4-flash-vision-exp'
+       );
+
+-- 0018's cheap pair: rewrite onto the new id. Any chain that named a retired
+-- DeepSeek id as primary or fallback is dropped and the seeded pair restored.
+DELETE FROM model_fallbacks
+ WHERE model IN (
+         'deepseek/deepseek-v4-flash',
+         'deepseek/deepseek-v4-pro',
+         'deepseek/deepseek-v4-flash-vision-exp'
+       )
+    OR fallback_model IN (
+         'deepseek/deepseek-v4-flash',
+         'deepseek/deepseek-v4-pro',
+         'deepseek/deepseek-v4-flash-vision-exp'
+       );
+
+INSERT INTO model_fallbacks (model, position, fallback_model) VALUES
+  ('deepseek/deepseek-flash',      1, 'mistral/mistral-small-latest'),
+  ('mistral/mistral-small-latest', 1, 'deepseek/deepseek-flash');
+
+UPDATE models
+   SET enabled            = 0,
+       measured_at        = NULL,
+       measured_by        = NULL,
+       measurement_source = NULL
+ WHERE id IN (
+         'deepseek/deepseek-v4-flash',
+         'deepseek/deepseek-v4-pro',
+         'deepseek/deepseek-v4-flash-vision-exp'
+       );

package/migrations/0077_gpt_6_astra.sql

@@ -0,0 +1,35 @@
+-- GPT-6 Astra (#375).
+--
+-- OpenAI's models page now names `gpt-6-astra` the default starting point for
+-- complex reasoning and coding. Candidate for `bb/deep-reasoning` and
+-- `bb/agentic-coding` once measured — this migration only catalogues and
+-- prices. 0029 / 0049: a model enters a lane once it is routable in
+-- production, which is a later act after conformance writes the flags.
+--
+-- Figures fetched 2026-09-13 UTC from the host's own model page,
+-- https://developers.openai.com/api/docs/models/gpt-6-astra — not the board.
+-- Window 1,050,000 / max output 128,000 (stated). Standard $10 / $50 per 1M;
+-- cached input $1.00. Long context: prompts with more than 272K input tokens
+-- are priced at 2x input and cache rates and 1.5x output for the full request
+-- — same rule and boundary reading as 0049 (`prompt_tokens_from` = 272001).
+-- Cache writes ($12.50 = 1.25x input) are not a Cruise price column; Batch /
+-- Flex / Fast are not written either (0049 left those off for the same reason).
+--
+-- `data_retention` is `retained`, same unconditional API terms as the 0049
+-- gpt-5.6 rows.
+
+INSERT INTO models (id, upstream_id, upstream_model, max_context, max_output,
+                    data_retention, data_retention_source, data_retention_as_of) VALUES
+  ('openai/gpt-6-astra', 'openai', 'gpt-6-astra', 1050000, 128000,
+   'retained', 'https://developers.openai.com/api/docs/guides/your-data', '2026-09-13');
+
+INSERT INTO price_observations
+  (observed_at, model, effective_from, prompt_tokens_from, peak_utc,
+   input_micros_per_mtok, output_micros_per_mtok, cached_input_micros_per_mtok, source, note)
+VALUES
+  ('2026-09-13 00:00:00', 'openai/gpt-6-astra', '2026-09-13',      0, '',
+   10000000, 50000000, 1000000, 'https://developers.openai.com/api/docs/models/gpt-6-astra',
+   'First observation: GPT-6 Astra (#375, 0077).'),
+  ('2026-09-13 00:00:00', 'openai/gpt-6-astra', '2026-09-13', 272001, '',
+   20000000, 75000000, 2000000, 'https://developers.openai.com/api/docs/models/gpt-6-astra',
+   'Long-context tier: >272K input tokens, 2x input/cache and 1.5x output for the whole request.');

package/migrations/0078_astra_deep_reasoning.sql

@@ -0,0 +1,20 @@
+-- Staff gpt-6-astra on bb/deep-reasoning (#375).
+--
+-- Measured 2026-09-13 on staging and production: streaming, usage and
+-- json_schema pass; tools=0 and vision=0. The tools failure is OpenAI's
+-- chat-completions refusal of function tools when reasoning_effort is in
+-- play ("use /v1/responses or set reasoning_effort to 'none'"), not a proof
+-- the model has no tools forever — but the folded flag is tools=0 today, so
+-- bb/agentic-coding (tools-required) must not take it.
+--
+-- bb/deep-reasoning carries no tools gate. quality_rank 1: OpenAI's models
+-- page names Astra the default for complex reasoning. Lane selection is
+-- still `cheap`, so price keeps Flash and Workers AI ahead of Astra's
+-- $10/$50 until a policy change; rank is for graduated / the cache tier
+-- rule. Position 7 sits after the existing six members.
+--
+-- Not staffed elsewhere. Revisit agentic-coding when the probe (or the
+-- Responses path) can measure tools honestly.
+
+INSERT INTO lane_members (lane_id, model_id, position, quality_rank) VALUES
+  ('bb/deep-reasoning', 'openai/gpt-6-astra', 7, 1);

package/migrations/0079_gemini_flash_lite_extraction.sql

@@ -0,0 +1,15 @@
+-- Staff gemini-3.5-flash-lite on bb/extraction (#375).
+--
+-- Already measured on staging and production 2026-09-10: tools=1, vision=1,
+-- json_schema=1 — the last is what bb/extraction requires (0030). Audio input
+-- is priced at the text rate on Google's page (0049's row already holds that
+-- single rate). data_retention stays NULL until someone reads the account
+-- tier; extraction does not carry no-training-on-data, so NULL does not
+-- refuse the member.
+--
+-- quality_rank 2 with the other flash/cheap extractors (ministral-8b,
+-- glm-4.7-flash). Position 6 after the five members 0076 left. Not staffed
+-- elsewhere this pass.
+
+INSERT INTO lane_members (lane_id, model_id, position, quality_rank) VALUES
+  ('bb/extraction', 'google-ai-studio/gemini-3.5-flash-lite', 6, 2);

package/migrations/0080_priced_by.sql

@@ -0,0 +1,24 @@
+-- How a model's bill is shaped, when two models of one modality disagree (#240).
+--
+-- Until this column, `BILL` in `src/billing-block.ts` was keyed on modality
+-- alone. That is enough while every speech model is per character and every
+-- image model is per token — which was true when 0056–0059 landed. It is not
+-- enough once a host prices images per image with no token rate to convert
+-- from: xAI's `grok-imagine-*` (read 2026-09-06), which is why #240 re-opened.
+--
+-- The tempting alternative is to *derive* the shape: no token rows and an
+-- `image` component means per-image. That reads a misconfiguration — a
+-- token-priced model whose headline was retracted — as a legitimately
+-- component-priced one, and bills it on components alone. Silent under-
+-- counting, which 0011 exists to prevent. So the shape is **declared**,
+-- defaulted to the only value that has ever been true, exactly as `modality`
+-- arrived in 0056.
+--
+-- Speech rows already live on the component side of this pair; they move to
+-- `component` in the same statement so `BILL` keyed on `(modality, priced_by)`
+-- describes them rather than special-casing the modality. Grok Imagine itself
+-- is #284 — this migration only makes the column and the speech rewrite.
+ALTER TABLE models ADD COLUMN priced_by TEXT NOT NULL DEFAULT 'token'
+  CHECK (priced_by IN ('token', 'component'));
+
+UPDATE models SET priced_by = 'component' WHERE modality = 'speech';