@bytesbrains/cruise-worker 0.0.0-stage → 0.12.1

package/migrations/0029_lane_jobs.sql

@@ -0,0 +1,146 @@
+-- A lane is named by a job, and the job is a word the board also uses.
+--
+-- 0026 stated that `role` is the board's job vocabulary. Nothing enforced it,
+-- and three of the five lanes disagreed with it or with themselves (#79). The
+-- moment tenants write their own lanes (#66) an unenforced vocabulary becomes
+-- decorative — every tenant invents a word for the same job and no
+-- cross-tenant question is answerable. So:
+--
+--   `role` becomes `job`. "Role" already means a member's RBAC role in this
+--   codebase; the prose everywhere else already said "job".
+--
+--   `job` is a closed set: the fourteen jobs the board publishes, plus `other`
+--   for a job the vocabulary does not name yet. `other` is the demand signal
+--   — the count of them is what the board should cover next — and is allowed
+--   on tenant lanes only. The CHECK enforces the set; the route enforces the
+--   tenant-only rule, because the table cannot say which caller wrote a row.
+--
+--   Every global lane's id is `bb/` + its job, and a test now says so.
+--
+-- The vocabulary itself is vendored, dated, in docs/vocabulary.md. Cruise
+-- takes the words from the board and fetches nothing from it.
+--
+-- Retired outright, with no alias: bb/security-review (a use of code-review,
+-- not a job), bb/cheap-fast (a posture and a constraint with no job in it —
+-- its description was chat-assistant at saver), and bb/long-context (a gate,
+-- not a job: allocation already picks a member whose window fits, inside any
+-- job lane). None has a production request against it. The ledger keeps the
+-- old ids as strings in requested_model; nothing references them by key.
+--
+-- The lane set lands at eight. document-understanding and rag-grounded-answers
+-- wait: vision and json_schema are unmeasured on every routable model, and a
+-- lane that lists and then refuses every request shaped like its job is the
+-- promise the member bar exists to prevent.
+--
+-- SQLite cannot rename a column under a CHECK or alter the CHECK, and
+-- lane_members references lanes, so both are rebuilt as in 0028.
+
+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',
+                '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')),
+  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/')
+  ),
+  -- A global lane is named by its job, and its job is a real one: `other` is
+  -- the demand signal and belongs to tenants. Tenant lanes name themselves.
+  CHECK (tenant_id IS NOT NULL OR (id = 'bb/' || job AND job <> 'other'))
+);
+
+-- Carry over what stays. bb/extraction's role was 'bulk-extraction'; "bulk"
+-- is throughput, a constraint, and the job is extraction.
+INSERT INTO lanes_new (id, tenant_id, job, description, enabled, created_by, created_at, updated_at)
+SELECT id, tenant_id,
+       CASE role WHEN 'bulk-extraction' THEN 'extraction' ELSE role END,
+       description, enabled, created_by, created_at, updated_at
+  FROM lanes
+ WHERE id IN ('bb/extraction', 'bb/agentic-coding');
+
+INSERT INTO lanes_new (id, job, description) VALUES
+  ('bb/chat-assistant',  'chat-assistant',
+   'Interactive turns where a capable small model is enough.'),
+  ('bb/code-review',     'code-review',
+   'Reads a diff or a repository and reasons about what is wrong with it. Tool calling and a large window; quality over price.'),
+  ('bb/code-completion', 'code-completion',
+   'Fill-in-the-middle and next lines. Members with a code-specialised training set.'),
+  ('bb/summarization',   'summarization',
+   'A long input to a short output.'),
+  ('bb/translation',     'translation',
+   'Between natural languages.'),
+  ('bb/deep-reasoning',  'deep-reasoning',
+   'Problems that reward thinking tokens. The one lane where the cheapest member is the wrong default; price still decides, so pin a model when it matters.');
+
+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,
+  PRIMARY KEY (lane_id, model_id)
+);
+
+INSERT INTO lane_members_new (lane_id, model_id, position)
+SELECT lane_id, model_id, position FROM lane_members
+ WHERE lane_id IN ('bb/extraction', 'bb/agentic-coding');
+
+-- Members: routable on production 2026-08-21, at least three per lane, with
+-- real price spread. Position keeps the listing stable and means nothing.
+INSERT INTO lane_members_new (lane_id, model_id, position) VALUES
+  ('bb/chat-assistant',  'mistral/ministral-8b-2512',                          1),
+  ('bb/chat-assistant',  'mistral/ministral-3b-2512',                          2),
+  ('bb/chat-assistant',  'mistral/mistral-small-latest',                       3),
+  ('bb/chat-assistant',  'workers-ai/@cf/google/gemma-4-26b-a4b-it',           4),
+  ('bb/chat-assistant',  'workers-ai/@cf/meta/llama-3.2-3b-instruct',          5),
+  ('bb/chat-assistant',  'workers-ai/@cf/zai-org/glm-4.7-flash',               6),
+  ('bb/chat-assistant',  'workers-ai/@cf/openai/gpt-oss-20b',                  7),
+
+  ('bb/code-review',     'deepseek/deepseek-v4-pro',                           1),
+  ('bb/code-review',     'mistral/mistral-large-2512',                         2),
+  ('bb/code-review',     'mistral/mistral-medium-2604',                        3),
+  ('bb/code-review',     'workers-ai/@cf/openai/gpt-oss-120b',                 4),
+  ('bb/code-review',     'deepseek/deepseek-v4-flash',                         5),
+
+  ('bb/code-completion', 'mistral/codestral-2508',                             1),
+  ('bb/code-completion', 'workers-ai/@cf/qwen/qwen2.5-coder-32b-instruct',     2),
+  ('bb/code-completion', 'workers-ai/@cf/qwen/qwen3.8-27b',                    3),
+  ('bb/code-completion', 'deepseek/deepseek-v4-flash',                         4),
+
+  ('bb/summarization',   'deepseek/deepseek-v4-flash',                         1),
+  ('bb/summarization',   'mistral/mistral-small-latest',                       2),
+  ('bb/summarization',   'mistral/ministral-8b-2512',                          3),
+  ('bb/summarization',   'workers-ai/@cf/google/gemma-4-26b-a4b-it',           4),
+  ('bb/summarization',   'workers-ai/@cf/zai-org/glm-4.7-flash',               5),
+  ('bb/summarization',   'workers-ai/@cf/meta/llama-3.2-3b-instruct',          6),
+
+  ('bb/translation',     'mistral/mistral-small-latest',                       1),
+  ('bb/translation',     'mistral/ministral-14b-2512',                         2),
+  ('bb/translation',     'mistral/mistral-medium-2604',                        3),
+  ('bb/translation',     'workers-ai/@cf/google/gemma-4-26b-a4b-it',           4),
+  ('bb/translation',     'workers-ai/@cf/aisingapore/gemma-sea-lion-v4-27b-it', 5),
+  ('bb/translation',     'deepseek/deepseek-v4-flash',                         6),
+
+  ('bb/deep-reasoning',  'deepseek/deepseek-v4-pro',                           1),
+  ('bb/deep-reasoning',  'workers-ai/@cf/qwen/qwq-32b',                        2),
+  ('bb/deep-reasoning',  'workers-ai/@cf/deepseek-ai/deepseek-r1-distill-qwen-32b', 3),
+  ('bb/deep-reasoning',  'workers-ai/@cf/openai/gpt-oss-120b',                 4),
+  ('bb/deep-reasoning',  'workers-ai/@cf/nvidia/nemotron-3-120b-a12b',         5),
+  ('bb/deep-reasoning',  'mistral/mistral-medium-2604',                        6);
+
+DROP INDEX idx_lane_members_lane;
+DROP INDEX idx_lanes_tenant;
+DROP TABLE lane_members;
+DROP TABLE lanes;
+ALTER TABLE lanes_new RENAME TO lanes;
+ALTER TABLE lane_members_new RENAME TO lane_members;
+
+CREATE INDEX idx_lane_members_lane ON lane_members (lane_id, position);
+CREATE INDEX idx_lanes_tenant ON lanes (tenant_id, enabled);

package/migrations/0030_lane_requires.sql

@@ -0,0 +1,38 @@
+-- A lane's conditions, beside its list (#79 §6).
+--
+-- A member list says who may serve. A requirement says what every member
+-- must satisfy to be in the list at all — a constraint from the vendored
+-- vocabulary (docs/vocabulary.md), evaluated against the routing table's
+-- measured flags at allocation time and at the write. `bb/extraction`
+-- requiring `json-schema` is the lane promising the thing extraction is; a
+-- member that cannot is not a candidate for any request on it, not only for
+-- the ones that send a schema.
+--
+-- Only constraints the gates can evaluate today are accepted at the write:
+-- tools-required, json-schema, vision-required, long-context[:tokens], and
+-- no-training-on-data (which fails closed on an unmeasured data_retention,
+-- so it empties any lane today and is seeded nowhere). The others in the
+-- vocabulary are refused as not-yet-evaluable rather than stored and ignored.
+--
+-- `value` is the constraint's argument where it takes one — the token floor
+-- for long-context. NULL otherwise.
+
+CREATE TABLE lane_requires (
+  lane_id    TEXT NOT NULL REFERENCES lanes(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_)
+);
+
+-- The platform lanes whose job is a promise about capability. Each keeps at
+-- least three members after the requirement, as production measured them on
+-- 2026-08-22: extraction loses deepseek-v4-flash (json_schema = 0) and keeps
+-- four; the two coding lanes lose nothing.
+INSERT INTO lane_requires (lane_id, constraint_, value) VALUES
+  ('bb/extraction',     'json-schema',    NULL),
+  ('bb/code-review',    'tools-required', NULL),
+  ('bb/agentic-coding', 'tools-required', NULL);

package/migrations/0031_tenant_billable.sql

@@ -0,0 +1,15 @@
+-- Whether a tenant is charged for what it spends (#96, epic #106).
+--
+-- Three places in the request path make the same decision: when a request
+-- cannot be priced, charge the flat reservation and carry on. For the tenants
+-- that exist today — ours — that is correct: refusing our own pipeline over a
+-- missing price row is worse than absorbing the error. For a tenant that is
+-- billed it inverts: each of those places is a way to buy an arbitrarily
+-- expensive request for five cents, and all of them are discoverable from
+-- the public /admin/models response.
+--
+-- So the rule is per tenant, not global. Default 0: every existing tenant
+-- keeps the conservative behaviour, and nothing in this migration changes
+-- what any request does today. Setting it to 1 is a deliberate act at the
+-- point a tenant is invoiced (v0.md §6 phase 4), never a side effect.
+ALTER TABLE tenants ADD COLUMN billable INTEGER NOT NULL DEFAULT 0 CHECK (billable IN (0, 1));

package/migrations/0032_cache_hit_billing.sql

@@ -0,0 +1,35 @@
+-- Cache hits are billed at a published fraction of list (#98, epic #106).
+--
+-- A hit is served by the gateway's cache and reaches no provider, so it costs
+-- nothing upstream — and the ledger priced it at the full list rate anyway,
+-- charging the project as though the provider had answered. Internally that
+-- overstated spend against the invoice on every hit. To a billed tenant it
+-- would be an undisclosed markup wearing pass-through's clothes.
+--
+-- Not zero either. A hit writes the whole accounting trail and is the
+-- highest-margin traffic the platform serves; and auto-mode.md §8 names the
+-- incentive problem with pricing hits at all: billing less for them creates
+-- a reason to serve more of them, including hits that should not have been
+-- served. So the fraction is platform-wide and public, held here and dated
+-- like a price, never a constant in code and never negotiated per tenant —
+-- a discount on hits is a negotiation over how honest the cache is.
+CREATE TABLE cache_billing (
+  effective_from   TEXT PRIMARY KEY,
+  -- Share of list a hit is billed at, in basis points: 2000 is 20%.
+  hit_basis_points INTEGER NOT NULL CHECK (hit_basis_points BETWEEN 0 AND 10000),
+  recorded_at      TEXT NOT NULL DEFAULT (datetime('now'))
+);
+
+-- The opening figure. A change is a new row, so a month already charged keeps
+-- the basis it was charged at — the rule model_prices follows, for the same
+-- reason (0014).
+INSERT INTO cache_billing (effective_from, hit_basis_points) VALUES ('2026-08-23', 2000);
+
+-- What the list rate would have charged, beside what was. Equal on a miss;
+-- on a hit `cost_micros` is the fraction of this. The observed-rate view reads
+-- this column, or a model served mostly from cache would look like a
+-- provider that cut its price.
+ALTER TABLE ledger ADD COLUMN list_micros INTEGER NOT NULL DEFAULT 0;
+
+-- Every row so far was charged at list, hit or not.
+UPDATE ledger SET list_micros = cost_micros;

package/migrations/0033_sell_markup.sql

@@ -0,0 +1,37 @@
+-- The sell price: what a billed tenant is charged above list (#99, epic #106).
+--
+-- Pass-through plus a fee on top-ups does not clear on our volume — a 5% fee
+-- on $100 nets about $1.80 after card processing, and a $10 top-up is
+-- underwater — so margin comes from the request. It is defensible here where
+-- it would not be for a plain gateway because lane allocation and the cache
+-- reduce what a tenant spends, and `laneSavings` computes the counterfactual:
+-- "list plus the markup through Cruise is below list direct" is a number the
+-- ledger can show per lane per month, not a claim.
+--
+-- A percentage, not a second price list, so there is no cost/sell row to
+-- leak: the provider's list price is public and the markup is on the pricing
+-- page. Per tenant and dated like a price, so a change is a new row and a
+-- month already charged keeps its basis (0014's rule). A tier, when one
+-- exists (#104), is a policy that writes these rows; this is the primitive.
+--
+-- '*' is the platform default, resolved when a tenant has no row of its own.
+-- Seeded rather than implied, because a billed tenant silently charged 0%
+-- would look like a bug for exactly as long as nobody noticed the margin.
+CREATE TABLE sell_markups (
+  tenant_id      TEXT NOT NULL,
+  effective_from TEXT NOT NULL,
+  -- Above list, in basis points: 1000 is list plus 10%.
+  basis_points   INTEGER NOT NULL CHECK (basis_points BETWEEN 0 AND 10000),
+  recorded_at    TEXT NOT NULL DEFAULT (datetime('now')),
+  PRIMARY KEY (tenant_id, effective_from)
+);
+
+INSERT INTO sell_markups (tenant_id, effective_from, basis_points) VALUES ('*', '2026-08-23', 1000);
+
+-- What this does to existing numbers: nothing today. The markup applies only
+-- where `tenants.billable = 1`, and no tenant is. The day one is flipped, its
+-- `project_spend.spend_micros` and every `cost_micros` it writes from then on
+-- denominate in what the tenant pays, because that is what its cap is in —
+-- rows before that day stay as they were charged. A dashboard showing that
+-- tenant's budget shows the same column and needs no change, but its copy
+-- must not call it "provider cost".

package/migrations/0034_tiers_and_lane_quotas.sql

@@ -0,0 +1,38 @@
+-- Tiers, and the one quota that is cost recovery rather than packaging
+-- (#104, epic #106).
+--
+-- A pinned request writes seven or eight D1 statements; a lane request adds
+-- one lane_alternatives row per candidate that passed the gates, so a
+-- five-member lane is roughly 1.7× the write cost of a pinned one. Lanes are
+-- the differentiated feature and the expensive one. Members-per-lane is the
+-- cap that bounds our cost; lanes-per-tenant is the one a user understands.
+-- Both exist. NULL is unlimited.
+CREATE TABLE tiers (
+  id               TEXT PRIMARY KEY,
+  name             TEXT NOT NULL,
+  lanes            INTEGER CHECK (lanes IS NULL OR lanes >= 0),
+  members_per_lane INTEGER CHECK (members_per_lane IS NULL OR members_per_lane >= 1)
+);
+
+-- Opening figures. A price, a markup or a feature a tier carries beyond these
+-- two numbers lives where that thing lives — the markup in sell_markups, the
+-- subscription on the payments side — and a tier is the name that ties them.
+INSERT INTO tiers (id, name, lanes, members_per_lane) VALUES
+  ('free',       'Free',        1,    3),
+  ('core',       'Core',       10,    8),
+  ('pro',        'Pro',        50,   20),
+  ('enterprise', 'Enterprise', NULL, NULL);
+
+-- Not a REFERENCES: SQLite will not add a referencing column with a non-null
+-- default. Resolved against `tiers` on read, and an id that is not there is
+-- treated as Free — the quota fails closed, never open. A new tenant starts
+-- on Free; every tenant that exists today is ours and is not quota'd.
+ALTER TABLE tenants ADD COLUMN tier TEXT NOT NULL DEFAULT 'free';
+UPDATE tenants SET tier = 'enterprise';
+
+-- Disable-never-delete means a lane cannot be removed to free a slot, and a
+-- quota on lanes that can only ever grow is a lifetime one. So a lane can be
+-- archived: it stays in the table for the ledger rows that reference it, is
+-- disabled, is hidden from the listing by default, and does not count. That
+-- is what a user expects "delete" to do. Unarchiving needs a free slot.
+ALTER TABLE lanes ADD COLUMN archived_at TEXT;

package/migrations/0035_wallet_scope.sql

@@ -0,0 +1,68 @@
+-- The wallet: a tenant-scoped lifetime cap on the existing reservation
+-- (#101, epic #106).
+--
+-- A customer balance enforced anywhere but the reservation is not enforced,
+-- and a second reservation beside the project's — plus the compensating
+-- release for when the second fails after the first succeeded — is the shape
+-- of bug this repo has named twice (9798b4a, PR #112). So the wallet is not
+-- a subsystem beside budgets: it is the same one, given a scope. A project
+-- budget is a cap that resets; a wallet is a cap at tenant scope whose
+-- period is 'lifetime' and whose limit moves with credit grants (#102)
+-- instead of resetting. One table for both is what lets one INSERT reserve
+-- against both caps atomically, both rows or neither.
+--
+-- `budgets` and `spend` replace `project_budgets` and `project_spend` with
+-- (scope, subject) keys. The old names would have carried tenant rows under
+-- a project_* name — a column that lies, which is the thing five-for-five
+-- got removed for.
+CREATE TABLE budgets (
+  scope   TEXT NOT NULL CHECK (scope IN ('project', 'tenant')),
+  subject TEXT NOT NULL,
+  period  TEXT NOT NULL DEFAULT 'day' CHECK (period IN ('day', 'month', 'lifetime')),
+
+  -- Warn here; keep serving. For a wallet: the low-water mark on the balance.
+  soft_micros INTEGER,
+  -- Stop here. For a project: the period's cap. For a wallet: the total ever
+  -- granted — #102's credit grants move it up, a refund moves it down, and
+  -- it never resets. Null means uncapped, and for a wallet that state is
+  -- reported rather than silently fine, exactly as a project without a
+  -- budget row is.
+  hard_micros INTEGER,
+  reserve_micros INTEGER NOT NULL DEFAULT 50000,
+
+  -- How far below zero the balance may go before refusing (#101). A grace
+  -- *window* would need a clock inside a hot statement and would race the
+  -- requests it gates; an overdraft is the same integer with a different
+  -- sign, enforced by the statement that already compares against a bound.
+  -- Zero for self-serve; raised deliberately for a tenant with a verified
+  -- card on file. Meaningful on tenant rows only.
+  overdraft_micros INTEGER NOT NULL DEFAULT 0 CHECK (overdraft_micros >= 0),
+
+  updated_at TEXT NOT NULL DEFAULT (datetime('now')),
+  updated_by TEXT,
+  PRIMARY KEY (scope, subject),
+  -- A wallet never resets and a project cap always does.
+  CHECK ((scope = 'tenant') = (period = 'lifetime'))
+);
+
+INSERT INTO budgets (scope, subject, period, soft_micros, hard_micros, reserve_micros, updated_at, updated_by)
+SELECT 'project', project_id, period, soft_micros, hard_micros, reserve_micros, updated_at, updated_by
+  FROM project_budgets;
+DROP TABLE project_budgets;
+
+CREATE TABLE spend (
+  scope         TEXT NOT NULL CHECK (scope IN ('project', 'tenant')),
+  subject       TEXT NOT NULL,
+  period        TEXT NOT NULL CHECK (period IN ('day', 'month', 'lifetime')),
+  -- '' for lifetime: the period that never starts over.
+  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)
+);
+
+INSERT INTO spend (scope, subject, period, period_start, spend_micros, request_count, updated_at)
+SELECT 'project', project_id, period, period_start, spend_micros, request_count, updated_at
+  FROM project_spend;
+DROP TABLE project_spend;

package/migrations/0036_credit_grants.sql

@@ -0,0 +1,53 @@
+-- Credit grants: the only part of the revenue design that mints money
+-- rather than leaking it (#102, epic #106).
+--
+-- A grant endpoint turns an HTTP request into spendable balance, so the
+-- controls live in the schema where a new code path cannot bypass them.
+-- One row per grant, the payment intent id as the primary key: the payments
+-- side delivers at least once, and a redelivery is INSERT OR IGNORE — a
+-- schema no-op, not handler logic. Signed micros, so a refund or a
+-- chargeback is a negative row with its own reference; nothing here is ever
+-- updated or deleted, and a mistaken grant is reversed by a row that says
+-- so. The wallet's cap (#101) is derived: sum(micros) per tenant, recomputed
+-- in the same transaction as each grant, so the grants prove the counter and
+-- the counter is the fast path — and #103's reconciliation asserts the two
+-- agree on a schedule.
+CREATE TABLE credits (
+  payment_intent_id TEXT PRIMARY KEY,
+  tenant_id         TEXT NOT NULL REFERENCES tenants(id),
+  -- Signed. Positive is a top-up; negative is a refund or chargeback, which
+  -- may take the balance below zero toward the overdraft floor — that is the
+  -- stated policy, not a surprise found later. Never zero: a zero grant is a
+  -- payload bug, not a no-op to store.
+  micros     INTEGER NOT NULL CHECK (micros != 0),
+  -- `key:cru_svc_…` — the credential that granted, never a human. See below.
+  actor      TEXT NOT NULL,
+  -- The payments side's note: the conversion rate it used, its reference.
+  detail     TEXT,
+  created_at TEXT NOT NULL DEFAULT (datetime('now'))
+);
+CREATE INDEX idx_credits_tenant ON credits (tenant_id, created_at);
+
+-- Exactly one kind of credential may grant, and it is not a person.
+--
+-- No human role can grant credit: an owner who can top up their own tenant
+-- is a self-issue path, and the roles that exist were not designed to resist
+-- that. Not a virtual key either — a data-plane credential is designed to be
+-- copied into env files and CI, and #91 says the two must never be the same
+-- string. And not a second authentication path into /admin, which is the
+-- bug shape this repo has hit three times: this credential opens exactly one
+-- route, POST /payments/credits, on its own plane.
+--
+-- `cru_svc_…`: classifiable on sight, greppable by a scanner, rejected by
+-- shape on every other plane (the data plane parses only live|test). Hash
+-- and prefix storage, disable-never-delete, as virtual_keys.
+CREATE TABLE service_keys (
+  id         TEXT PRIMARY KEY,
+  prefix     TEXT NOT NULL UNIQUE,
+  key_hash   TEXT NOT NULL,
+  purpose    TEXT NOT NULL CHECK (purpose = 'credits'),
+  created_by TEXT NOT NULL,
+  created_at TEXT NOT NULL DEFAULT (datetime('now')),
+  revoked_at TEXT,
+  last_used_at TEXT
+);

package/migrations/0037_reconciliation.sql

@@ -0,0 +1,45 @@
+-- Reconciliation: the two books, asked on a schedule (#103, epic #106).
+--
+-- Ours is consumption, the payments side's is payments, and two books drift
+-- silently unless something asks. The precedent is the observed-rates view:
+-- nothing else in the platform noticed DeepSeek's rate move, and the view is
+-- what did. A finding is a row with the figures on both sides — not a log
+-- line — and a clean run is a row too, because "nothing found" and "nothing
+-- ran" must never look alike.
+--
+-- Reconciliation never corrects. It reports; corrections are new credit or
+-- ledger rows made by a person, with an audit trail.
+CREATE TABLE reconcile_runs (
+  id       TEXT PRIMARY KEY,
+  at       TEXT NOT NULL DEFAULT (datetime('now')),
+  -- How many findings this run wrote. Zero with clean = 1 is the good row.
+  findings INTEGER NOT NULL DEFAULT 0,
+  clean    INTEGER NOT NULL DEFAULT 0 CHECK (clean IN (0, 1))
+);
+
+CREATE TABLE reconcile_findings (
+  id         TEXT PRIMARY KEY,
+  run_id     TEXT NOT NULL REFERENCES reconcile_runs(id),
+  -- Which question was asked: 'wallet_counter' (the cap is the grants' sum),
+  -- 'spend_vs_ledger' (a period's counter equals its ledger rows' charges),
+  -- 'grant_vs_settled' (each credit re-confirmed against the system of
+  -- record), or 'unconfirmable' (the system of record could not be asked —
+  -- loud, never silent).
+  check_name TEXT NOT NULL,
+  -- Whose books the finding is about, for the control plane's scoping: the
+  -- wallet's tenant, the project's tenant, the credit's tenant. NULL for a
+  -- finding about the machinery itself — the surface being unaskable — which
+  -- names no tenant and is shown to every tenant. The /admin read scopes on
+  -- this **in SQL**; a finding's subject text is never parsed for it.
+  -- Raised in review of PR #116: the first draft returned every tenant's
+  -- findings to any viewer, which is the post-filtering shape admin-ledger.ts
+  -- exists to warn about.
+  tenant_id  TEXT,
+  -- What the finding is about: a tenant, a project/period, an intent id.
+  subject    TEXT NOT NULL,
+  expected   TEXT NOT NULL,
+  actual     TEXT NOT NULL,
+  detail     TEXT,
+  at         TEXT NOT NULL DEFAULT (datetime('now'))
+);
+CREATE INDEX idx_reconcile_findings_run ON reconcile_findings (run_id);

package/migrations/0038_balance_service_keys.sql

@@ -0,0 +1,35 @@
+-- A service key that can read a wallet and do nothing else (#120).
+--
+-- We can already mint balance unattended and not read it — the dashboard side
+-- put it plainly, and the write is the dangerous direction. A scheduled
+-- auto-top-up sweep needs the harmless half: is this tenant low? It should
+-- not have to hold the credential that grants to find out, so `purpose`
+-- gains a second value and becomes what it was always named as — the
+-- capability a key carries, one per consumer.
+--
+-- `credits` grants and reconciles. `balance` reads one tenant's wallet and
+-- has no other route. A key is issued for one or the other, never both.
+--
+-- SQLite cannot widen a CHECK in place, so the table is rebuilt. Note why
+-- that is safe here and was not in 0035, which taught this the hard way:
+-- the name and every column stay identical, so code deployed before this
+-- migration and code deployed after both read exactly the same shape. The
+-- rule from that lesson is not "never rebuild" — it is "leave no window
+-- where deployed code queries something that is not there", and a
+-- constraint-only change leaves none.
+CREATE TABLE service_keys_new (
+  id         TEXT PRIMARY KEY,
+  prefix     TEXT NOT NULL UNIQUE,
+  key_hash   TEXT NOT NULL,
+  purpose    TEXT NOT NULL CHECK (purpose IN ('credits', 'balance')),
+  created_by TEXT NOT NULL,
+  created_at TEXT NOT NULL DEFAULT (datetime('now')),
+  revoked_at TEXT,
+  last_used_at TEXT
+);
+
+INSERT INTO service_keys_new (id, prefix, key_hash, purpose, created_by, created_at, revoked_at, last_used_at)
+SELECT id, prefix, key_hash, purpose, created_by, created_at, revoked_at, last_used_at FROM service_keys;
+
+DROP TABLE service_keys;
+ALTER TABLE service_keys_new RENAME TO service_keys;

package/migrations/0039_deepseek_peak_is_weekdays.sql

@@ -0,0 +1,77 @@
+-- DeepSeek's peak window is Monday to Friday. Ours was every day, so every
+-- weekend morning since 2026-08-16 has been billed at double the rate DeepSeek
+-- charged.
+--
+-- The page says it in one sentence, fetched 2026-08-29 UTC:
+--
+--   "Peak hours are 01:00 - 04:00 and 06:00 - 10:00 UTC, Monday through Friday
+--    (all other hours are off-peak)."   https://api-docs.deepseek.com/quick_start/pricing
+--
+-- Where the days went. 0024 wrote the window from the announcement,
+-- news260813, which says only "Off-peak rates are 50% lower than peak" — no
+-- hours, no days. The hours came from the pricing table beside it and the days
+-- did not come at all; 0025 then copied the string onto v4-pro and
+-- v4-flash-vision-exp. Two migrations, one unread sentence, and nothing in
+-- between could have caught it: the resolver and the row agreed with each
+-- other, which is not the same as agreeing with DeepSeek.
+--
+-- The test that proved peak billing worked picked 2026-08-22T07:00:00Z. That is
+-- a Saturday. It asserted double and got double, and both were wrong.
+--
+-- What it cost, in the three places a price is read:
+--
+--   The ledger over-counted weekend 01:00-04:00 and 06:00-10:00 DeepSeek
+--   requests by 2x. Real traffic starts 2026-08-22 — itself a Saturday — from
+--   webapp through bb/extraction and bb/agentic-coding, and deepseek-v4-flash and
+--   deepseek-v4-pro are members of both.
+--
+--   The reservation (#97) reserved that same doubled upper bound, so a project
+--   near its cap was refused a request it could afford. A cap that stops
+--   traffic the provider would have charged half for is not the cap the tenant
+--   agreed to.
+--
+--   Lane allocation priced those members at 2x for the same hours, so the
+--   cheapest-passing-member decision went elsewhere and 0027 recorded the
+--   counterfactual against a rate nobody would have paid. The savings figure
+--   for those hours is wrong in both directions at once.
+--
+-- The ledger is not restated. Those rows record what this Worker computed, and
+-- rewriting them would destroy the only evidence that it computed the wrong
+-- thing. A tenant owed the difference is owed a credit grant (0036), which is
+-- append-only and says who decided it.
+--
+-- Why the day range goes in `peak_utc` rather than in a column of its own.
+-- 0024 said the next condition would be one more column on the row, and meant
+-- it — a region prices independently of an hour. A day does not: a row naming
+-- days and no hours means nothing, and every day range that will ever be
+-- written qualifies a window that is already there. One condition, one column,
+-- one parser. The primary key is (model, effective_from, prompt_tokens_from,
+-- peak_utc), so the string is also what makes these rows distinct from the ''
+-- row beside them, and it stays that way.
+--
+-- Grammar, in `src/pricing.ts`: `[Ddd-Ddd@]HH:MM-HH:MM`, comma-separated, days
+-- inclusive at both ends and allowed to wrap. Absent means every day, so every
+-- row written before this one still means what it said.
+--
+-- An unparsable prefix matches nothing and the '' row is used, which here is
+-- off-peak — the migration under-counts rather than doubling every bill. That
+-- was already the parser's rule; it is restated because a grammar with an
+-- optional prefix is easier to typo than one without, and this is the failure
+-- direction we accept in exchange.
+--
+-- Deploy the Worker before applying this, not after. The new parser reads a
+-- window with no day prefix exactly as the old one did, so new code against old
+-- rows is a no-op; old code against these rows cannot parse `mon-fri@…`, treats
+-- the window as never matching, and bills weekday peak hours at the off-peak
+-- rate until the deploy catches up. Code first has no gap in either direction.
+-- 0035 is the migration that learned this by leaving the gap open, and served
+-- 500s for a minute doing it (the phase-5 deploy).
+--
+-- Rewritten in place, not dated forward. A new `effective_from` would say the
+-- weekend rate changed on 2026-08-29. It did not; the row was never right, and
+-- 0011 corrected a misquoted price the same way.
+
+UPDATE model_prices
+   SET peak_utc = 'mon-fri@01:00-04:00,mon-fri@06:00-10:00'
+ WHERE peak_utc = '01:00-04:00,06:00-10:00'
+   AND model LIKE 'deepseek/%';