@bytesbrains/cruise-worker 0.0.0-stage → 0.12.0

package/migrations/0107_session_cap.sql

@@ -0,0 +1,65 @@
+-- A hard cap per run, so one stuck agent cannot spend the whole project (#651).
+--
+-- A project's cap is the only one a request answers to below the wallet, and
+-- the unit a loop runs away in is narrower than that: one agent run. One run
+-- stuck in a retry loop spends the project's day, and every other run in the
+-- project is refused with it. `x-cruise-session` already names a run (#394),
+-- and the ledger already keeps its digest (#617, 0098).
+--
+-- Three changes, each the smallest that carries the cap:
+--
+--   `spend` admits scope 'session'. A run's counter is one row, subject
+--   `<project id>:<sha256(session)>`, period 'lifetime', period_start ''. The
+--   project id is in the subject because a session is a caller's string and
+--   two projects may pick the same one. Lifetime rather than the project's
+--   period, decided on #651: a run that crosses midnight UTC is still the
+--   same run, and a cap that reset there would hand a runaway loop a fresh
+--   allowance at exactly the hour nobody is watching. It is counted on every
+--   request that carries a session, capped or not, inside the reserve's own
+--   statement, so a cap set mid-run already knows what the run has spent and
+--   #646 has a running figure to report. The daily sweep deletes a counter
+--   idle for 30 days (`src/session-budget.ts`). A counter is not an id the
+--   ledger references, so this does not break disable-never-delete: the
+--   ledger keeps the digest on every row and is the record.
+--
+--   `budgets.session_hard_micros` is the project's per-run cap. NULL is no
+--   cap. A request's `x-cruise-session-budget` may narrow it and never widen
+--   it, the rule the cache TTL already follows. On the project row only:
+--   the CHECK below refuses one on a tenant's wallet row, which has no runs.
+--
+--   `reservations.session_subject` names the counter a hold also charged, or
+--   NULL when it charged none. The settle and the sweep read it from the row,
+--   the way they already read `period_start`, so the window the reserve
+--   charged is the one the settle corrects, with no parameter to pass along.
+--
+-- CHECK constraints cannot be altered in SQLite, so `spend` is rebuilt the
+-- way 0085 rebuilt it. Nothing references it by foreign key and it had no
+-- index or trigger to recreate. The two new columns are plain ADD COLUMNs.
+CREATE TABLE spend_new (
+  scope         TEXT NOT NULL CHECK (scope IN ('project', 'tenant', 'session')),
+  subject       TEXT NOT NULL,
+  period        TEXT NOT NULL CHECK (period IN ('minute', 'day', 'month', 'lifetime')),
+  -- '' for lifetime. `YYYY-MM-DD HH:MM` for a minute, which is what
+  -- strftime('%Y-%m-%d %H:%M', 'now') gives (`src/budget.ts`).
+  period_start  TEXT NOT NULL,
+  spend_micros  INTEGER NOT NULL DEFAULT 0,
+  request_count INTEGER NOT NULL DEFAULT 0,
+  updated_at    TEXT NOT NULL DEFAULT (datetime('now')),
+  PRIMARY KEY (scope, subject, period, period_start),
+  -- A run is counted for its whole life and only that way.
+  CHECK (scope <> 'session' OR (period = 'lifetime' AND period_start = ''))
+);
+
+INSERT INTO spend_new (scope, subject, period, period_start, spend_micros, request_count, updated_at)
+SELECT scope, subject, period, period_start, spend_micros, request_count, updated_at
+  FROM spend;
+DROP TABLE spend;
+ALTER TABLE spend_new RENAME TO spend;
+
+-- What the sweep's prune reads: session counters, oldest first.
+CREATE INDEX idx_spend_session_idle ON spend (updated_at) WHERE scope = 'session';
+
+ALTER TABLE budgets ADD COLUMN session_hard_micros INTEGER
+  CHECK (session_hard_micros IS NULL OR (session_hard_micros >= 0 AND scope = 'project'));
+
+ALTER TABLE reservations ADD COLUMN session_subject TEXT;

package/migrations/0108_ledger_attempts.sql

@@ -0,0 +1,41 @@
+-- Every attempt a request's chain stepped past, so a rescue can be counted (#647).
+--
+-- When a lane's first member fails before any body and the second answers,
+-- the caller's request would have failed without Cruise. Nothing recorded it:
+-- the ledger keeps one row per request, naming the attempt that was served and
+-- its status, so a request rescued on its second attempt read exactly like one
+-- served on its first. `fallbacks()` in report.ts inferred a chain firing from
+-- `requested_model <> model` and had to exclude lanes, where that difference is
+-- allocation, not failure. So the common case, a lane rescue, was invisible,
+-- and so was a dark upstream that fallback was hiding from doctor.
+--
+-- One row per **failed** attempt, never for the one served: that one is the
+-- ledger row itself, and a request served first time writes nothing here, so
+-- the common path costs no extra row. Written in the same `db.batch` as the
+-- ledger row (`recordLedgerEntry`), as `ledger_components` is, so a request
+-- cannot land with its attempts and not its row or the other way round.
+--
+-- A **rescue** is then a ledger row with a 2xx `http_status` and at least one
+-- row here. Every row here is a failure by construction: the chain only steps
+-- on past an attempt `shouldFallOver` refused or that never answered. A
+-- request whose last candidate failed too has rows here and a failing status,
+-- and is not a rescue: it failed with Cruise as well.
+--
+-- Not priced, ever. A failed attempt is not billed (#647), and there is no
+-- cost column to tempt anyone.
+--
+-- `http_status` is NULL when the attempt never answered at all: a dead
+-- socket, or the deadline passing. Those are failures before any body as
+-- much as a 503 is, and the chain treats them alike.
+--
+-- Mid-stream failures do not fall over (v0.md §4), so they never reach here.
+CREATE TABLE ledger_attempts (
+  ledger_id   TEXT NOT NULL REFERENCES ledger(id),
+  -- 1-based position in the chain, as `Chain.candidates[].position` has it.
+  position    INTEGER NOT NULL CHECK (position >= 1),
+  model       TEXT NOT NULL,
+  upstream_id TEXT NOT NULL,
+  http_status INTEGER,
+  upstream_ms INTEGER,
+  PRIMARY KEY (ledger_id, position)
+);

package/migrations/0109_gemini_retention.sql

@@ -0,0 +1,39 @@
+-- Google AI Studio's retention, now that the key's tier is known: `retained`.
+--
+-- 0049 left every `google-ai-studio` row NULL, and 0061 kept it so, for one
+-- reason: Google's terms follow the **account tier**, a property of the
+-- credential that no page can answer. Free trains on prompts; paid does not.
+-- `test/catalogue.test.ts` pinned NULL with "see 0049 before setting this".
+--
+-- On 2026-10-15 (UTC) the key behind `PROVIDER_KEY_GOOGLE_AI_STUDIO` was
+-- replaced on staging and production, after the old one's credit ran out and
+-- every Google request answered 402. Its holder read the key's plan in AI
+-- Studio → API keys: **Tier 1**, a paid tier on a Cloud Billing account.
+--
+-- https://ai.google.dev/gemini-api/terms, last updated 2026-04-28, read
+-- 2026-10-15. For Paid Services:
+--
+--   "Google doesn't use your prompts (including associated system
+--    instructions, cached content, and files) or responses to improve our
+--    products"
+--
+--   "Google logs prompts and responses for a limited period of time, solely
+--    for detecting and preventing violations"
+--
+-- and "Your access to Gemini API is a 'Paid Service' only when accessing the
+-- API through a Cloud Project ... associated with an active billing account."
+--
+-- Kept for a limited period and not trained on: `retained`, the same answer
+-- and the same reading as xAI's in 0061. Not `none`, because a copy exists.
+--
+-- **This is a fact about the key, not the model.** A key replaced by one on
+-- the free tier makes every row here false while reading exactly like a
+-- measurement, and `no-training-on-data` (0030) would go on passing it. So
+-- whoever next sets `PROVIDER_KEY_GOOGLE_AI_STUDIO` reads its tier again and,
+-- if it is not paid, sets these rows back to NULL. By upstream, as 0061 does,
+-- so a row added to this host later inherits nothing.
+UPDATE models
+   SET data_retention        = 'retained',
+       data_retention_source = 'https://ai.google.dev/gemini-api/terms (Paid Services; key on Tier 1)',
+       data_retention_as_of  = '2026-10-15'
+ WHERE upstream_id = 'google-ai-studio';

package/migrations/0110_gemini_4_argon.sql

@@ -0,0 +1,110 @@
+-- Gemini 4 Argon, catalogued and priced (#677).
+--
+-- Google released `gemini-4-argon` on 2026-10-15 as its flagship reasoning
+-- model, positioned for long-horizon coding and security work. It is the
+-- candidate for Google's seat in the four coding lanes, which
+-- `gemini-3.1-pro-preview` holds today (0084, 0088).
+--
+-- This migration catalogues and prices. It staffs no lane: a member nobody has
+-- measured makes the lane's capability `null` (`src/lanes.ts`), so the swap is
+-- a later migration, after a conformance run has written its flags. That is
+-- the 0090 → 0091 order.
+--
+-- Every figure below was fetched 2026-10-15 UTC from Google's own pages, cited
+-- per row. Not from the launch email the issue quoted, and not from the board
+-- (board#384): #79 and #122 say why.
+--
+-- ## Which surface: compat, so this is a migration and not code
+--
+-- The launch sample calls `client.interactions.create`, and an Interactions-only
+-- model would have needed an adapter (`docs/upstreams.md`). It is not one. On
+-- 2026-10-15 UTC, with a paid Gemini API key:
+--
+--   GET  /v1beta/openai/models/gemini-4-argon        200, "Gemini 4 Argon"
+--   GET  /v1beta/models/gemini-4-argon               200, supportedGenerationMethods
+--                                                    generateContent, countTokens,
+--                                                    batchGenerateContent
+--   POST /v1beta/openai/chat/completions             200, content "ok", usage reported
+--
+-- The last call is the path Cruise sends Google chat through (0063's
+-- `provider_path_prefix`), so the row below routes with no request-path code.
+--
+-- ## Window and output
+--
+-- https://ai.google.dev/gemini-api/docs/models/gemini-4-argon (last updated
+-- 2026-10-14): context window 1,048,576 "unified input and output token
+-- limit"; output "65,536 (default synchronous) / up to 1,048,576 (with long
+-- decode)". Long decode is not a mode the compat endpoint offers, so the
+-- synchronous figure is the one a Cruise request can get.
+--
+-- The model resource disagrees: `GET /v1beta/models/gemini-4-argon` reports
+-- `outputTokenLimit: 32768`. The endpoint itself does not enforce that number.
+-- `max_tokens` 40,000, 65,536 and 70,000 all answered 200 on the same day, so
+-- 32,768 would refuse work Google accepts. `max_output` is a refusal threshold
+-- (`src/routing.ts`), so the page's figure is written.
+--
+-- ## Price, and the rise already on the page
+--
+-- https://ai.google.dev/gemini-api/docs/pricing (last updated 2026-10-15),
+-- paid tier, per 1M tokens:
+--
+--                        through 2026-11-30    from 2026-12-01
+--   input                $2.00                 $4.00
+--   output (incl. thinking) $10.00             $20.00
+--   context caching      $0.10                 $0.20
+--
+-- One price per category. Unlike 3.1 Pro, there is **no prompt-length tier**,
+-- so there are no conditional variants to fold into a lane's maximum. The rise
+-- is a second `effective_from` row, the mechanism 0049 used for Gemini 3.8
+-- Flash: `resolvePrice` takes max(effective_from) <= the request's day, so the
+-- price doubles at midnight UTC on 2026-12-01 with no second deploy and nobody
+-- needing to remember.
+--
+-- That matters most for the lanes. At the December rate Argon is $4 / $20, so
+-- once it is seated, a coding lane's price (the maximum across members, never
+-- the average) is no lower than that from 2026-12-01.
+--
+-- Caching is implicit only ("explicit caching is not supported"): Google
+-- decides what is a hit, and the cached rate is the price of one.
+-- Batch, Flex and Priority are not written, for 0049's reason.
+--
+-- Free tier: "not available". This catalogue reaches Google only on the paid
+-- key 0109 read, so that changes nothing here. A free key would get Google's
+-- refusal, which #149 handles.
+--
+-- ## Retention
+--
+-- `retained`, on 0109's reading of the paid-services terms. The model page
+-- says nothing to the contrary. 0109 set it by UPDATE on the rows that existed,
+-- and a row added after inherits nothing, so this row writes it itself. Whoever
+-- next replaces `PROVIDER_KEY_GOOGLE_AI_STUDIO` re-reads the tier for this row
+-- too.
+--
+-- ## What conformance should watch
+--
+-- Thinking is on by default. Without `reasoning_effort`, a one-word prompt
+-- sent directly to Google ran past 60 seconds with no headers. With
+-- `reasoning_effort: "low"`, the same prompt answered in 2.6 seconds. A unary
+-- request has 180 seconds (`UNARY_RESPONSE_TIMEOUT_MS`) and a streamed one 45
+-- seconds to headers, so a check that times out on this row is the default
+-- thinking budget, not the model being down.
+--
+-- Capabilities on the page (function calling, structured outputs, search
+-- grounding; image, video, audio and PDF input) are not written here.
+-- Conformance is their only writer.
+
+INSERT INTO models (id, upstream_id, upstream_model, max_context, max_output,
+                    data_retention, data_retention_source, data_retention_as_of) VALUES
+  ('google-ai-studio/gemini-4-argon', 'google-ai-studio', 'gemini-4-argon', 1048576, 65536,
+   'retained', 'https://ai.google.dev/gemini-api/terms (Paid Services; key on Tier 1)', '2026-10-15');
+
+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-10-15 00:00:00', 'google-ai-studio/gemini-4-argon', '2026-10-15', 0, '',
+   2000000, 10000000, 100000, 'https://ai.google.dev/gemini-api/docs/pricing',
+   'First observation: Gemini 4 Argon (#677, 0110). Introductory rate, stated to hold through 2026-11-30.'),
+  ('2026-10-15 00:00:00', 'google-ai-studio/gemini-4-argon', '2026-12-01', 0, '',
+   4000000, 20000000, 200000, 'https://ai.google.dev/gemini-api/docs/pricing',
+   'The rate from 2026-12-01, printed on the same page as the introductory one and dated by it. Not a forecast.');

package/migrations/0111_gemini_4_argon_lanes.sql

@@ -0,0 +1,80 @@
+-- Gemini 4 Argon takes Google's seat in the four coding lanes, and joins
+-- bb/deep-reasoning (#677).
+--
+-- 0110 catalogued it unmeasured. Conformance run 38757259408 (dispatched
+-- 2026-10-15 UTC, production, narrowed to this one row) measured it, and the
+-- run's mirror job copied the flags to staging and the demo:
+--
+--                       streaming  usage  tools  json_schema  vision  web_search
+--   gemini-4-argon          1        1      1         1         1         0
+--   gemini-3.1-pro-preview  0        1      1         0         1         0
+--
+-- Measured before staffed: the 0090 → 0091 order. Argon matches or beats 3.1
+-- Pro on every flag, so no lane loses a capability by the swap. Each of the
+-- four coding lanes has 3.1 Pro as a streaming=0 and json_schema=0 member, and
+-- a lane's capability is the intersection of its members (`src/lanes.ts`). With
+-- 3.1 Pro gone, a lane gains streaming or json_schema wherever 3.1 Pro was the
+-- only member without it.
+--
+-- ## The coding lanes: a swap, at the same seat and rank
+--
+-- bb/agentic-coding, bb/builder, bb/hunter and bb/code-review. Same position,
+-- same `quality_rank` 2, as 0091 did for Opus 5.5. Google's seat moves from a
+-- preview to the model Google ships for "long-horizon coding and security
+-- work". Rank 1 stays with Anthropic and OpenAI's frontier rows. Promoting
+-- Argon beside them is a judgement about how it codes, which no measurement
+-- here makes. 3.1 Pro stays catalogued and routable when pinned, because
+-- disable-never-delete is about rows, not seats.
+--
+-- Price: from 2026-12-01 Argon is $4 / $20 (0110). A lane's price is the
+-- maximum across its members, and gpt-6-astra ($10 / $50) is already in all
+-- four, so the swap leaves each lane's quoted price where it is, in December as
+-- now.
+--
+-- ## bb/deep-reasoning: added at rank 1
+--
+-- Google calls Argon "our flagship reasoning model" (models page, read
+-- 2026-10-15). bb/deep-reasoning's only frontier member is gpt-6-astra, at
+-- rank 1, so Argon joins it there as the second lab's frontier reasoner. The
+-- lane has no `lane_requires`, and Argon carries every flag the lane's members
+-- do, so its folded capabilities can only stay or grow. Selection stays
+-- `cheap`: under it Argon is depth behind the cheaper members, not the lane's
+-- first pick. Price is unchanged for the same reason as above, with astra
+-- already the maximum.
+--
+-- ## Not here
+--
+-- **The bb-adm/* lanes.** They belong to a tenant and are staffed through the
+-- control plane. No migration has written to them. bb-adm/code-review already
+-- holds Argon, added there by hand.
+--
+-- **Lanes whose job wants something cheap or small** (chat-assistant,
+-- extraction, summarization, translation, code-completion, rag-grounded-answers,
+-- web-search). A frontier reasoning model at $2–4 / $10–20 is the wrong member
+-- for any of them, and web-search needs `web_search`, which Argon measures 0.
+--
+-- Two statements per swap, for 0089's reason. `lane_members` is keyed
+-- (lane_id, model_id) and the control plane can rewrite a lane's members
+-- (`src/lanes-write.ts`). An environment where Argon was already added to one
+-- of these lanes would fail a bare UPDATE and stop the migration. OR IGNORE
+-- skips that row, and the DELETE takes 3.1 Pro out either way.
+--
+-- Selection policy is unchanged everywhere.
+
+UPDATE OR IGNORE lane_members
+   SET model_id = 'google-ai-studio/gemini-4-argon'
+ WHERE lane_id IN ('bb/agentic-coding', 'bb/builder', 'bb/hunter', 'bb/code-review')
+   AND model_id = 'google-ai-studio/gemini-3.1-pro-preview';
+
+DELETE FROM lane_members
+ WHERE lane_id IN ('bb/agentic-coding', 'bb/builder', 'bb/hunter', 'bb/code-review')
+   AND model_id = 'google-ai-studio/gemini-3.1-pro-preview';
+
+-- Last position, so the existing order is untouched. OR IGNORE for the same
+-- reason as above. Guarded on the lane existing, so an environment without it
+-- writes nothing rather than failing the foreign key.
+INSERT OR IGNORE INTO lane_members (lane_id, model_id, position, quality_rank)
+SELECT 'bb/deep-reasoning', 'google-ai-studio/gemini-4-argon',
+       coalesce((SELECT max(position) FROM lane_members WHERE lane_id = 'bb/deep-reasoning'), 0) + 1,
+       1
+ WHERE EXISTS (SELECT 1 FROM lanes WHERE id = 'bb/deep-reasoning');

package/migrations/0112_ledger_affinity.sql

@@ -0,0 +1,42 @@
+-- What the affinity pin did for a request, on the ledger (#662).
+--
+-- ## Why
+--
+-- A run that sends `x-cruise-session` (#394) is answered with
+-- `x-cruise-affinity: new | pinned | rebound`, and until now that header was
+-- the only place the state existed. #662 found an agent tenant's Builder run,
+-- `agent-38372995550` on 2026-10-13, that served two turns on
+-- `openai/gpt-6-astra` and then three on `kimi-k2.7-code`, breaking the prompt
+-- cache on the switch. The ledger showed no `ledger_attempts` row on any turn,
+-- so it was not a fallover, but it could not say which of the two remaining
+-- causes it was:
+--
+--   rebound  the pinned member failed a hard gate or lost headroom, and the
+--            lane redrew on purpose (`src/affinity.ts`, "What does")
+--   new      the pin was not found. It lives in KV, which is eventually
+--            consistent across locations, and the switch came 14 seconds
+--            after the pin was written, during three concurrent runs
+--
+-- The two have different fixes, so the column records which one happened.
+-- A `new` on a row whose session already has earlier rows is the lost-pin
+-- signature; a `rebound` is a decision, and the gate that made it is the
+-- next question.
+--
+-- ## `ledger.affinity`
+--
+-- The state `x-cruise-affinity` carried, exactly. NULL when no session was
+-- sent, when the request named a pinned model (the header is ignored for
+-- routing there), and on every existing row — no default, because a guessed
+-- state is worse than none. A cache hit records its state too: the hit was
+-- still admitted through the lane, and a run's turns should read whole.
+--
+-- No index. The question is always about one run, and `idx_ledger_session`
+-- (0098) already finds a run's rows; this column is read off them.
+--
+-- ## Order
+--
+-- This, then the Worker. The Worker before this never names the column; the
+-- one after it fails every ledger insert without it.
+
+ALTER TABLE ledger ADD COLUMN affinity TEXT
+  CHECK (affinity IS NULL OR affinity IN ('new', 'pinned', 'rebound'));

package/migrations/0113_contributor_lane_namespace.sql

@@ -0,0 +1,125 @@
+-- A second global lane namespace, `oss/`, for contributor lanes (#692).
+--
+-- A contributor lane holds only models whose hosts train on the traffic they
+-- serve, at the discounted rates that bought the consent. Choosing one is the
+-- consent, so the namespace is the disclosure — a caller cannot reach a
+-- training endpoint without spelling the word. Same visibility and writability
+-- as `bb/`: every tenant sees them, only the operator (and migrations) change
+-- them. No lane is created here; 0115 seats the first one, on the rows 0114
+-- catalogues.
+--
+-- ## Why a rebuild
+--
+-- SQLite cannot widen a CHECK, and the namespace rule lives in two of them:
+-- the global/tenant split from 0028, and the global id-is-job pin from 0029
+-- (as 0102 restated it). So this is 0102's shape, over the schema as it stands
+-- now — which is 0102's exactly, nothing since having touched these three
+-- tables. `lane_requires` constrains nothing new: the contributor rule is
+-- prefix-implied, not a vocabulary slug — the vocabulary is the board's and
+-- has no positive constraint — so it is enforced in the write and the
+-- allocator (`src/lanes-validate.ts`, `src/lanes-allocate.ts`), the way the
+-- web-search gate is job-implied rather than listed (0104).
+--
+-- **The window is real and is stated rather than argued small** (0102's
+-- words, still true): each statement is its own transaction on D1, so between
+-- `DROP TABLE lanes` and the `RENAME` a lane lookup finds no table and fails.
+-- Run it at the quietest hour, and expect a handful of lane requests to 500
+-- if traffic lands inside. Pinned-model requests do not read `lanes` and are
+-- unaffected.
+--
+-- ## What does not change
+--
+-- The `compress` CHECK refuses on `tenant_id IS NULL`, which already covers
+-- the new namespace: a contributor lane serves every tenant, so it cannot
+-- rewrite their tool outputs, for 0096's reason. Lane reads filter on
+-- `tenant_id IS NULL` (`VISIBLE_TO`, `src/lanes.ts`), so `oss/` lanes are
+-- visible everywhere with no query change. Reserving `oss` as a tenant id is
+-- the app's half (`assertTenantId`), as `bb` was — there is no table half to
+-- widen, because there never was one for `bb` either.
+
+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', 'web-search',
+                '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),
+  router      TEXT
+              CHECK (router IS NULL OR router IN ('jev')),
+  router_input TEXT NOT NULL DEFAULT 'hint'
+              CHECK (router_input IN ('hint', 'prompt')),
+  compress    INTEGER NOT NULL DEFAULT 0
+              CHECK (compress IN (0, 1) AND (compress = 0 OR tenant_id IS NOT NULL)),
+  CHECK (
+    (tenant_id IS NULL     AND (substr(id, 1, 3) = 'bb/' OR substr(id, 1, 4) = 'oss/')) OR
+    (tenant_id IS NOT NULL AND substr(id, 1, length(tenant_id) + 1) = tenant_id || '/'
+                           AND substr(id, 1, 3) <> 'bb/' AND substr(id, 1, 4) <> 'oss/')
+  ),
+  CHECK (tenant_id IS NOT NULL OR ((id = 'bb/' || job OR id = 'oss/' || 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,
+  router, router_input, compress
+)
+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,
+       router, router_input, compress
+  FROM lanes;
+
+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;
+
+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;
+
+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/0114_meta_contributor_models.sql

@@ -0,0 +1,55 @@
+-- Meta's contributor tier, catalogued at last: `muse-spark-1.2-contributor`
+-- and `muse-spark-1.3-contributor` (#692).
+--
+-- 0050 left the 1.2 row out, and 0052 the 1.3, for the same stated reason:
+-- the same model at $0.10 in / $0.20 out against $1.25 / $4.25, bought with
+-- *"permission to use your prompts and completions to train future Meta
+-- models"*, would win every request in any lane it joined — allocation is
+-- price-first — while `no-training-on-data` fires only for a lane that
+-- carries the requirement. Both comments end "waiting on a decision". This is
+-- the decision: contributor rows exist, but only contributor lanes may hold
+-- them. The namespace (0113), the write rule (`validMembers`) and the
+-- per-request gate (`allocate`) admit them to `oss/` lanes and nowhere else,
+-- so the cheapest row in the catalogue can no longer leak into a lane whose
+-- caller never consented.
+--
+-- Unmeasured, like 0110's Argon: conformance measures what the host serves,
+-- and the next scheduled run is the first that can see these rows. Until
+-- then they are catalogued, priced, and unroutable — pinned or in a lane —
+-- because an unmeasured model is not routable, in either namespace.
+--
+-- ## The figures
+--
+-- Rates as 0050 recorded them from Meta's pricing page on 2026-09-02
+-- (https://dev.meta.ai/docs/pricing-rate-limits): $0.10 in, $0.20 out, no
+-- prompt-size tier, no time-of-day tier. The cached-input rate for the
+-- contributor tier was never stated there, so it is NULL — unrecorded, not
+-- the standard tier's $0.15, which would be a guess wearing a figure's
+-- clothes. `observed_at` is when this row observes them, not when 0050 read
+-- the page; the note says where they come from.
+--
+-- `data_retention` is `trains` on the host's own quoted words above, the
+-- third value these columns have held. `as_of` is when eyes were last on the
+-- page — 2026-09-02, seven weeks back. That is honest rather than current:
+-- the training permission is the tier's definition, the thing the discount
+-- buys, so it cannot drift silently without the price rows drifting with it.
+-- 1M-token window and unstated output cap are the generations' own (0050,
+-- 0052), unchanged: a tier is a price and a term, not a different model.
+
+INSERT INTO models (id, upstream_id, upstream_model, max_context, max_output,
+                    data_retention, data_retention_source, data_retention_as_of) VALUES
+  ('meta/muse-spark-1.2-contributor', 'meta', 'muse-spark-1.2-contributor', 1048576, NULL,
+   'trains', 'https://dev.meta.ai/docs/pricing-rate-limits', '2026-09-02'),
+  ('meta/muse-spark-1.3-contributor', 'meta', 'muse-spark-1.3-contributor', 1048576, NULL,
+   'trains', 'https://dev.meta.ai/docs/pricing-rate-limits', '2026-09-02');
+
+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-10-21 00:00:00', 'meta/muse-spark-1.2-contributor', '2026-10-21', 0, '',
+   100000, 200000, NULL, 'https://dev.meta.ai/docs/pricing-rate-limits',
+   'First observation: contributor tier catalogued (#692, 0114). Rate as 0050 recorded it on 2026-09-02; cached input unstated.'),
+  ('2026-10-21 00:00:00', 'meta/muse-spark-1.3-contributor', '2026-10-21', 0, '',
+   100000, 200000, NULL, 'https://dev.meta.ai/docs/pricing-rate-limits',
+   'First observation: contributor tier catalogued (#692, 0114). Rate as 0050 recorded it on 2026-09-02; cached input unstated.');

package/migrations/0115_oss_chat_assistant_lane.sql

@@ -0,0 +1,41 @@
+-- The first contributor lane: `oss/chat-assistant` (#692).
+--
+-- ## One lane, two members, both unmeasured
+--
+-- The vocabulary asks three routable, measured members before a `bb/` lane
+-- exists, so that allocation is a decision. That rule is stated for `bb/`
+-- lanes; `oss/` lanes staff where contributor models exist, and two rows are
+-- the whole market today — the 1.2 and 1.3 contributor tiers 0114
+-- catalogued. A second member from another lab is a catalogue change, not a
+-- staffing failure.
+--
+-- One job, not one per job: `chat-assistant` is the definitionally general
+-- job, and these are general models. Staffing `oss/summarization` or
+-- `oss/translation` beside it would be a guess about what unmeasured models
+-- do well — the flags that answer that arrive with the first conformance run
+-- that sees the rows. More lanes follow measurement, as 0111 followed 0110.
+--
+-- Unmeasured members are a lane built today from models measured tomorrow,
+-- which the write explicitly allows: valid, listed, serving nothing until
+-- conformance admits them. The catalogue row says so honestly — capabilities
+-- null, retention `trains`, price the dearest member's.
+--
+-- ## The terms, on the row
+--
+-- No `lane_requires` row: the contributor rule is prefix-implied, not a
+-- vocabulary slug (0113). Selection stays `cheap` — under it the dearer
+-- generation is depth behind the cheaper, not the lane's first pick, and both
+-- are a tenth of anything in `bb/chat-assistant`. Both members unranked:
+-- placing 1.3 above 1.2 is a judgement about generations no measurement here
+-- makes (0111's reason), and an unranked member cannot serve a downgrade,
+-- which is the safe direction for a lane whose cache is off. The description
+-- carries the consent in plain words, because it is shown to callers beside
+-- the lane in `/v1/models`.
+
+INSERT INTO lanes (id, job, description) VALUES
+  ('oss/chat-assistant', 'chat-assistant',
+   'General chat on contributor-tier models: the host may train future models on this traffic, at the discounted rates that bought the consent. Choosing this lane is the consent.');
+
+INSERT INTO lane_members (lane_id, model_id, position, quality_rank) VALUES
+  ('oss/chat-assistant', 'meta/muse-spark-1.3-contributor', 1, NULL),
+  ('oss/chat-assistant', 'meta/muse-spark-1.2-contributor', 2, NULL);