@bytesbrains/cruise-worker 0.0.0-stage → 0.12.0

package/migrations/0116_promo_credits.sql

@@ -0,0 +1,63 @@
+-- Promotional credit: free balance with no settled payment behind it (#692,
+-- shared with #688).
+--
+-- `POST /payments/credits` confirms every grant against the payments side's
+-- settled-intents surface, and no confirmation configured means no grants.
+-- That fails closed exactly as designed — and it means free credit cannot go
+-- through that route at all: there is no intent to confirm, so the only
+-- honest answer it can give is `intent_unconfirmed`. Trial credit, contributor
+-- incentives and partner free tiers all need a grant path that does not ask
+-- the system of record, because there is nothing to ask it about.
+--
+-- ## The shape: the same table, a marked row, a separate key
+--
+-- A promo grant is a row in `credits`, so the wallet cap — sum(credits),
+-- recomputed on every grant — counts it with no code change, and the grant
+-- history shows it beside paid credit. What marks it is `kind`: `payment`
+-- for everything this table has ever held, `promo` for the new rows. The
+-- default backfills the column honestly — every existing row arrived through
+-- confirmation — and a CHECK holds the closed set.
+--
+-- Two things read `kind`. Reconciliation's `grantsVsSettled` re-confirms
+-- every credit against the settled-intents surface; a promo row would fail
+-- that check every day forever, so it reads `payment` rows only. The promo
+-- backstop is not re-confirmation — there is nothing to re-confirm against —
+-- it is the audit trail (every grant writes one), the per-grant ceiling and
+-- the lifetime allowance the route enforces, and the separate capability
+-- below.
+--
+-- The capability is `promo`, on 0038's terms: one per key, issued for one
+-- value and never two. A `credits` key presented to the promo route is the
+-- same 401 as a string that was never a key, and a `promo` key presented to
+-- the payment route likewise — the lookup names its purposes, so neither
+-- holder learns the other exists. Minting free credit and minting settled
+-- credit are separate powers, and one leaked credential must not be both.
+--
+-- SQLite cannot widen a CHECK in place, so `service_keys` is rebuilt, and
+-- 0038's, 0042's, 0054's and 0064's note on why that is safe applies
+-- unchanged: the name and every column stay identical, so code deployed
+-- before this migration and code deployed after read exactly the same shape.
+-- Widening is the safe direction on its own — no existing row can fail the
+-- new CHECK, and a Worker deployed before this simply never matches a `promo`
+-- row, because `authenticate` names the purposes it will accept in the lookup
+-- itself.
+
+ALTER TABLE credits ADD COLUMN kind TEXT NOT NULL DEFAULT 'payment'
+  CHECK (kind IN ('payment', 'promo'));
+
+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', 'provision', 'tier', 'economics', 'promo')),
+  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/0117_oss_mirror_lanes.sql

@@ -0,0 +1,85 @@
+-- The contributor mirror set: `oss/` lanes for every `bb/` job the contributor
+-- models can actually serve (#692).
+--
+-- 0115 seeded the first lane, `oss/chat-assistant`, on unmeasured members.
+-- Conformance has since measured both contributor rows (2026-10-22):
+-- `tools` yes, `json_schema`, `streaming`, `vision` and `web_search` no, 1M
+-- context. So this seats eight more lanes on the same two members — nine
+-- with `oss/chat-assistant`, and deliberately not twelve. The three missing
+-- jobs are missing because the members fail their gates, not because
+-- somebody forgot them:
+--
+-- - `oss/web-search`: the search gate is job-implied (`lanes-search.ts`
+--   keys on `lane.job`, either namespace), and both members measure
+--   `web_search = 0`. A lane named web-search that can never search is a
+--   name without service — and a permanent `doctor` failure.
+-- - `oss/extraction` and `oss/rag-grounded-answers`: both jobs require
+--   `json-schema`, as their `bb/` lanes do, and both members measure 0.
+--   (The 1M window clears rag's `long-context 200000`; it is the schema
+--   check that refuses.) Same verdict: unservable today, seatable the day
+--   a contributor model measures the flag.
+--
+-- Seeding a lane that refuses every request is not neutral. `doctor` fails
+-- `lane_members` for it on every environment, every deploy's verify step
+-- has to re-judge the same known failure, and — the part that decides it —
+-- lanes are disabled, never deleted. A skipped job is one insert away; a
+-- dead lane is a row to explain forever. Nine contributor lanes that serve
+-- beats twelve of which three never do.
+--
+-- ## What the eight carry
+--
+-- The `bb/` lane's job, requires and selection, verbatim: same job, same
+-- gate. Four carry `tools-required` (both members measure `tools = 1`);
+-- four carry nothing. Descriptions are the `bb/` text plus the consent
+-- sentence from 0115, because the description is shown to callers beside
+-- the lane. Both members unranked, for 0115's reason: placing 1.3 above
+-- 1.2 is a judgement no measurement here makes.
+--
+-- These lanes serve the moment this applies — members measured, priced,
+-- `trains` — on every environment, with no Worker deploy and no seed step.
+-- Staging and the demo already hold the measurements this needs: 0114's
+-- rows shipped in the #693 deploy, and conformance's mirror copies flags,
+-- so the next `staging:seed`/`demo:seed` (or the next conformance run's
+-- mirror job) carries them across.
+
+INSERT INTO lanes (id, job, description) VALUES
+  ('oss/agentic-coding', 'agentic-coding',
+   'Long tool-use loops over a repository. Output tokens dominate the bill. Contributor tier: the host may train future models on this traffic, at the discounted rates that bought the consent — choosing this lane is the consent.'),
+  ('oss/builder', 'builder',
+   'Autonomous implementation loop: turn an issue into a green change. Edit, run tests, iterate on failures; finish verified-green or honestly unfinished. Contributor tier: the host may train future models on this traffic, at the discounted rates that bought the consent — choosing this lane is the consent.'),
+  ('oss/code-completion', 'code-completion',
+   'Fill-in-the-middle and next lines. Members with a code-specialised training set. Contributor tier: the host may train future models on this traffic, at the discounted rates that bought the consent — choosing this lane is the consent.'),
+  ('oss/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. Contributor tier: the host may train future models on this traffic, at the discounted rates that bought the consent — choosing this lane is the consent.'),
+  ('oss/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. Contributor tier: the host may train future models on this traffic, at the discounted rates that bought the consent — choosing this lane is the consent.'),
+  ('oss/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. Contributor tier: the host may train future models on this traffic, at the discounted rates that bought the consent — choosing this lane is the consent.'),
+  ('oss/summarization', 'summarization',
+   'A long input to a short output. Contributor tier: the host may train future models on this traffic, at the discounted rates that bought the consent — choosing this lane is the consent.'),
+  ('oss/translation', 'translation',
+   'Between natural languages. Contributor tier: 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/agentic-coding', 'meta/muse-spark-1.3-contributor', 1, NULL),
+  ('oss/agentic-coding', 'meta/muse-spark-1.2-contributor', 2, NULL),
+  ('oss/builder', 'meta/muse-spark-1.3-contributor', 1, NULL),
+  ('oss/builder', 'meta/muse-spark-1.2-contributor', 2, NULL),
+  ('oss/code-completion', 'meta/muse-spark-1.3-contributor', 1, NULL),
+  ('oss/code-completion', 'meta/muse-spark-1.2-contributor', 2, NULL),
+  ('oss/code-review', 'meta/muse-spark-1.3-contributor', 1, NULL),
+  ('oss/code-review', 'meta/muse-spark-1.2-contributor', 2, NULL),
+  ('oss/deep-reasoning', 'meta/muse-spark-1.3-contributor', 1, NULL),
+  ('oss/deep-reasoning', 'meta/muse-spark-1.2-contributor', 2, NULL),
+  ('oss/hunter', 'meta/muse-spark-1.3-contributor', 1, NULL),
+  ('oss/hunter', 'meta/muse-spark-1.2-contributor', 2, NULL),
+  ('oss/summarization', 'meta/muse-spark-1.3-contributor', 1, NULL),
+  ('oss/summarization', 'meta/muse-spark-1.2-contributor', 2, NULL),
+  ('oss/translation', 'meta/muse-spark-1.3-contributor', 1, NULL),
+  ('oss/translation', 'meta/muse-spark-1.2-contributor', 2, NULL);
+
+INSERT INTO lane_requires (lane_id, constraint_, value) VALUES
+  ('oss/agentic-coding', 'tools-required', NULL),
+  ('oss/builder', 'tools-required', NULL),
+  ('oss/code-review', 'tools-required', NULL),
+  ('oss/hunter', 'tools-required', NULL);

package/migrations/0118_project_management_job.sql

@@ -0,0 +1,112 @@
+-- `project-management` joins the closed job set (#695).
+--
+-- An agent tenant's PM runs — plan work, track status, drive tools over a project —
+-- file under `other` today (`bb-adm/project-management`), which is the
+-- demand signal working as designed: `other` names the job the vocabulary
+-- does not have yet. This is the vocabulary answering. The word is ahead of
+-- the board, as `hunter`, `builder` and `web-search` each were, and asked to
+-- be owned there (board#385), so the copy stays vendored rather
+-- than invented. If the board picks another word, it renames in a migration,
+-- as 0029 did for `bulk-extraction` → `extraction`.
+--
+-- SQLite cannot widen a CHECK, so this is the sixth rebuild of the `lanes`
+-- table's shape — 0028, 0029, 0074, 0102, 0113, and now this — over the
+-- schema as 0113 left it, with one word added to the job list. Nothing else
+-- moves: the namespaces, the id-is-job pin, the `other`-is-for-tenants rule
+-- (which is exactly why the PM lane needs a real job), the `compress` bar.
+-- No lane is created here; 0119 seeds the one this job exists for.
+--
+-- **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.
+
+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', 'project-management',
+                '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/0119_oss_project_management_lane.sql

@@ -0,0 +1,29 @@
+-- `oss/project-management`: the contributor lane for PM work (#695).
+--
+-- The use case is `bb-adm/project-management`'s — plan work, track status,
+-- drive tools over a project — on contributor models instead of standard
+-- ones. Staffed like the 0117 mirrors: the two Meta contributor tiers,
+-- `tools-required` as the `bb-adm` lane carries (both members measure
+-- `tools = 1`), `cheap` with 1.3 first. Both members cost the same, so the
+-- curated order falls out of listing order under `cheap` — no new selection
+-- semantic, which is why none was built.
+--
+-- This is the job 0118 exists for, and its only global lane: no
+-- `bb/project-management` is seeded, because `bb-adm/project-management`
+-- already serves PM on standard models and a `bb/` twin would duplicate it.
+-- The job addition makes one trivially seedable later if anyone wants it.
+-- Both members unranked, for 0115's reason.
+--
+-- Serves the moment this applies — members measured, priced, `trains` — on
+-- every environment, with no Worker deploy and no seed step.
+
+INSERT INTO lanes (id, job, description) VALUES
+  ('oss/project-management', 'project-management',
+   'Plan work, track status, and drive tools over a project. Long context and tool calling; quality over price. Contributor tier: 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/project-management', 'meta/muse-spark-1.3-contributor', 1, NULL),
+  ('oss/project-management', 'meta/muse-spark-1.2-contributor', 2, NULL);
+
+INSERT INTO lane_requires (lane_id, constraint_, value) VALUES
+  ('oss/project-management', 'tools-required', NULL);

package/migrations/0120_moonshot_k3_1_pro.sql

@@ -0,0 +1,107 @@
+-- Moonshot / Kimi, through the lab's own API: Kimi K3.1 Pro and K3.1 Pro Highspeed (#700).
+--
+-- #208 is the reason this file is small and the reason it exists at all.
+-- Moonshot was "a key, four models and no published price": `PROVIDER_KEY_MOONSHOT`
+-- is set on staging and production, the direct path built for Meta in 0050 covers
+-- any OpenAI-shaped host, and the only thing missing was a number. The Kimi API
+-- team's announcement of 2026-10-26 UTC is that number — for two new models, not
+-- for the K2/K3 rows #208 names, which stay unpriced.
+--
+-- ## What arrived, and that it is live
+--
+-- `kimi-k3.1-pro` and `kimi-k3.1-pro-highspeed`: first models of the K3.1 series,
+-- described as the most capable 3T-class open-weight models to date, 1,048,576-token
+-- context window, Highspeed at 2-3x the speed of Pro. Live on the Kimi API on
+-- announcement day — the vendor's own quickstart names both ids and sends them to
+-- `POST https://api.moonshot.ai/v1/chat/completions` with an OpenAI-shaped body:
+--
+--   https://platform.kimi.ai/docs/guide/kimi-k3-1-pro-quickstart.md (read 2026-10-26)
+--
+-- `base_url="https://api.moonshot.ai/v1"` is quoted from that page's own examples.
+-- **`.ai`, not `.cn`** — #208 records that `.cn` rejects this key with
+-- `invalid_authentication_error`, a different account estate, not a bad key.
+-- No `provider_path_prefix`: unlike Google (0063), Moonshot serves the OpenAI
+-- shape at its root, exactly like Meta's `https://api.meta.ai/v1` in 0050. No
+-- request-path code — `isDirect` in `src/routing.ts` is the whole of the branch,
+-- and `headersFor` already builds the fresh header set a third-party host needs.
+--
+-- ## The prices, and where each figure was actually read
+--
+-- The per-model figures below are from the vendor's announcement email
+-- (2026-10-26 UTC), not from a price cell on the host's page: the K3 series
+-- section of `https://platform.kimi.ai/docs/pricing/chat` (read 2026-10-26)
+-- states the 1,048,576-token window and the cache-write-by-TTL billing logic,
+-- and names this quickstart for ids and prices, but its table cells did not
+-- render a citable per-model figure on that read. #208's rule — a number is
+-- written only when somebody read it — is satisfied here in the form #208
+-- itself allows as option 2: announcement-derived, provenance in the note,
+-- correctable when the page prints the cells. Two independent reports print
+-- the same figures (Artificial Analysis: $2/$10; VentureBeat: $4/$20
+-- Highspeed), which is corroboration, not provenance — the note says which.
+--
+-- 1 MTok = 1,000,000 tokens; micros per MTok = USD x 1,000,000:
+--
+--   kimi-k3.1-pro:            input 2000000, output 10000000, cached 200000
+--   kimi-k3.1-pro-highspeed:  input 4000000, output 20000000, cached 200000
+--
+-- **Cache writes are recorded here, not as `price_components` rows.** K3
+-- billing charges cache writes separately by TTL (5min: $2.00/$4.00 per MTok;
+-- 1h: $4.00/$8.00 per MTok → 2000000/4000000 and 4000000/8000000 micros per
+-- MTok). `cache_write` has a vocabulary entry and no reader — `READERS` in
+-- `src/pricing-components.ts` reads `request`, `search`, `character` and
+-- `image` only — and a model carrying a row with no reader fails closed as
+-- `unread` at bound time. Writing the rows now would make both models
+-- unroutable to billed tenants, which is exactly why 0058 wrote none for
+-- Anthropic's write rates either. The reader lands first; the rows follow.
+--
+-- ## `data_retention` is NULL, and that is the read, not the default
+--
+-- Moonshot did not state a training term in the launch: third parties report
+-- "zero data retention available to API customers" as an enterprise on-request
+-- option, with default traffic not covered by it. An option on request is an
+-- account setting, the same shape as ElevenLabs' plan-dependent rows (0059)
+-- and the pre-0109 Google tier — so NULL joins `ACCOUNT_DEPENDENT` in
+-- `test/catalogue-retention.test.ts` rather than inventing `retained`, which
+-- would pass `no-training-on-data` on a guess. Fill when the terms are read (#454).
+--
+-- ## The K2 clock, and what this file does not do
+--
+-- The same announcement retires the K2 series: no newly registered users from
+-- 2026-10-31, all K2 models retired by end of December 2026. That touches
+-- `workers-ai/@cf/moonshotai/kimi-k2.6` and `kimi-k2.7-code` (0025), both lane
+-- members (0075, 0088) — K3.1 Pro is their migration target, and K2 member
+-- removal is its own dated follow-up once the retirement is confirmed, not
+-- this file.
+--
+-- Nothing here is routable and nothing joins a lane (0049's shape): both rows
+-- land with `measured_at` NULL, and the gate refuses them until a conformance
+-- run measures them. Lane placement is the allocation decision that follows
+-- measurement, tracked in #700's acceptance list.
+--
+-- ## The dates are UTC
+--
+-- Read 2026-10-26 on both the announcement and the pricing and quickstart
+-- pages. 0020 and 0021: a row dated in the future prices in the future and
+-- every request reads as unpriced until then.
+
+INSERT INTO upstreams (id, name, kind, base_url) VALUES
+  ('moonshot', 'Moonshot', 'provider', 'https://api.moonshot.ai/v1');
+
+INSERT INTO models (id, upstream_id, upstream_model, max_context, max_output) VALUES
+  ('moonshot/kimi-k3.1-pro',           'moonshot', 'kimi-k3.1-pro',           1048576, NULL),
+  ('moonshot/kimi-k3.1-pro-highspeed',  'moonshot', 'kimi-k3.1-pro-highspeed', 1048576, NULL);
+
+-- `max_output` stays NULL on both: no maximum output is published, so 0011's
+-- rule holds — never write a number you did not fetch — and `checkLimits`
+-- derives the bound from the window while billed callers send `max_tokens`.
+
+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-26 00:00:00', 'moonshot/kimi-k3.1-pro', '2026-10-26', 0, '',
+   2000000, 10000000, 200000, 'https://platform.kimi.ai/docs/pricing/chat',
+   'First observation: Kimi K3.1 Pro catalogued (0120, #700). Figures from the Kimi API team announcement 2026-10-26 UTC ($2.00 in, $10.00 out, $0.20 cached per MTok; cache writes $2.00 5min / $4.00 1h held in the migration comment, no reader yet); K3 series section of the pricing page confirms the 1,048,576 window and TTL-graded cache-write billing. Re-read the page before treating these as page-quoted.'),
+  ('2026-10-26 00:00:00', 'moonshot/kimi-k3.1-pro-highspeed', '2026-10-26', 0, '',
+   4000000, 20000000, 200000, 'https://platform.kimi.ai/docs/pricing/chat',
+   'First observation: Kimi K3.1 Pro Highspeed catalogued (0120, #700). Same provenance as the Pro row ($4.00 in, $20.00 out, $0.20 cached per MTok; cache writes $4.00 5min / $8.00 1h held in the migration comment).');

package/migrations/0121_jobs.sql

@@ -0,0 +1,100 @@
+-- Jobs: work submitted now and finished later, posted to a hook the project
+-- registered (#712, #714).
+--
+-- Every request Cruise has served until now is synchronous: the reserve, the
+-- upstream call and the settle all happen inside one invocation, and the
+-- journal (0106) exists for the case where that invocation dies. A job breaks
+-- the assumption the journal's threshold rests on — a provider batch has up to
+-- 24 hours to finish — so this migration adds the job, the hook it reports to,
+-- and the one column that tells the sweep a hold is long on purpose.
+--
+-- Provider batch (#716) is the first and, for now, only kind. The table says
+-- so in its CHECK rather than accepting kinds nothing writes: a kind is added
+-- by the migration that adds the code serving it.
+
+-- ## Webhook endpoints: registered, never per request
+--
+-- A job names one of these, never an arbitrary URL. Checking an address once,
+-- at registration, by a member with write access, is a check that can be
+-- audited; a URL in every request body is an SSRF surface on the data plane
+-- and a secret to hand out per call (#712).
+--
+-- **No secret is stored.** The signing secret is derived: HMAC-SHA256 of
+-- `<id>:<secret_version>` under the Worker secret `WEBHOOK_SIGNING_KEY`
+-- (`src/webhook-endpoints.ts`). A row here, read by anyone with console access
+-- to D1, signs nothing. Rotating bumps `secret_version`; for a day after,
+-- deliveries carry both signatures, which Standard Webhooks allows, so a
+-- receiver can roll its secret without dropping an event.
+--
+-- Disabled, never deleted: a job references the endpoint it delivered to.
+CREATE TABLE webhook_endpoints (
+  id              TEXT PRIMARY KEY,
+  project_id      TEXT NOT NULL REFERENCES projects(id),
+  url             TEXT NOT NULL,
+  secret_version  INTEGER NOT NULL DEFAULT 1 CHECK (secret_version >= 1),
+  rotated_at      TEXT,
+  created_at      TEXT NOT NULL DEFAULT (datetime('now')),
+  created_by      TEXT NOT NULL,
+  disabled_at     TEXT,
+  disabled_by     TEXT,
+  disabled_reason TEXT
+);
+
+CREATE INDEX idx_webhook_endpoints_project ON webhook_endpoints (project_id, disabled_at);
+
+-- ## Jobs
+--
+-- The money is not here. A job's hold is a `reservations` row like any other,
+-- named by `reservation_id`, so reconcile already counts it (src/reconcile.ts
+-- adds open holds to the ledger sum) and the one statement that enforces a cap
+-- is the one that took it. `reserved_micros` is the figure as reserved, kept
+-- because the journal row is deleted when the hold is released and the job
+-- should still say what it held.
+--
+-- `delivery` is separate from `status` because they fail separately: a batch
+-- can succeed and its hook be down for a day. `undelivered` is terminal for
+-- the callback, never for the result.
+--
+-- `idempotency_key` is unique per project, so a retried submit finds the job
+-- the first one made instead of reserving twice.
+CREATE TABLE jobs (
+  id                  TEXT PRIMARY KEY,
+  project_id          TEXT NOT NULL REFERENCES projects(id),
+  kind                TEXT NOT NULL CHECK (kind IN ('batch')),
+  status              TEXT NOT NULL DEFAULT 'queued'
+                      CHECK (status IN ('queued', 'running', 'succeeded', 'failed', 'cancelled')),
+  reservation_id      TEXT NOT NULL,
+  reserved_micros     INTEGER NOT NULL CHECK (reserved_micros >= 0),
+  webhook_endpoint_id TEXT REFERENCES webhook_endpoints(id),
+  delivery            TEXT NOT NULL DEFAULT 'none'
+                      CHECK (delivery IN ('none', 'pending', 'delivered', 'undelivered')),
+  delivery_attempts   INTEGER NOT NULL DEFAULT 0,
+  next_delivery_at    TEXT,
+  idempotency_key     TEXT,
+  error               TEXT,
+  created_at          TEXT NOT NULL DEFAULT (datetime('now')),
+  updated_at          TEXT NOT NULL DEFAULT (datetime('now')),
+  completed_at        TEXT,
+  delivered_at        TEXT,
+  UNIQUE (project_id, idempotency_key),
+  -- A callback is owed only once the job is over. Every writer already keeps
+  -- to this (the release and the sweep set `pending` in the statement that
+  -- makes the job terminal), and the schema says so, so a job still running
+  -- can never carry a delivery schedule for a later write to clobber (#717
+  -- review).
+  CHECK (delivery = 'none' OR status IN ('succeeded', 'failed', 'cancelled'))
+);
+
+CREATE INDEX idx_jobs_project ON jobs (project_id, created_at);
+-- What the delivery loop and doctor read: callbacks still owed, oldest first.
+CREATE INDEX idx_jobs_delivery ON jobs (delivery, next_delivery_at);
+
+-- ## The hold knows it belongs to a job
+--
+-- The sweep closes a hold older than two hours as abandoned
+-- (`ABANDONED_AFTER_SECONDS`), which is right for a request and wrong for a
+-- batch that is still inside its provider's window. A NULL here is every hold
+-- written before this migration and every synchronous one after it, so the
+-- sweep's existing rule is unchanged for them; a hold with a job gets the
+-- job's longer threshold instead (`JOB_ABANDONED_AFTER_SECONDS`).
+ALTER TABLE reservations ADD COLUMN job_id TEXT;