@bongos/core 1.17.0

package/migrations/070_box_intents.sql

@@ -0,0 +1,101 @@
+-- 070_box_intents.sql — #701 (ADR 0031 §1/§2, open-question §9.4): the box
+-- onboarding middleware — server-side auto-provision + wake-on-connect + the
+-- web/Chromebook Remote-Control pairing path.
+--
+-- Context
+-- -------
+-- The box lifecycle (provision/park/wake/deprovision) is OPERATOR-ONLY: it runs
+-- on the trusted control plane (scripts/gds/box.js) so the internet-facing web
+-- process never holds DO_API_TOKEN and a stolen builder token can never spin up
+-- or destroy infrastructure (routes/box.js header). That is the right security
+-- posture, but it leaves a non-technical / Chromebook newcomer with no hands-off
+-- on-ramp: someone has to run a CLI to give them a box, and a returning builder's
+-- parked box stays parked until an operator wakes it.
+--
+-- #701 closes that gap WITHOUT moving the DO token into the web process. The web
+-- side only ever RECORDS A REQUEST — an "intent" — in this queue. The existing
+-- control-plane runner (box-intent-runner.timer → `box.js run-intents --apply`,
+-- the same systemd-timer pattern as box-idle-suspend) drains the queue and does
+-- the actual DigitalOcean work. The web process stays powerless over infra: it
+-- can ask for a box to be provisioned or woken, never create or destroy one.
+--
+-- Two pieces:
+--   1. box_intents — the provision/wake request queue (this is the middleware).
+--   2. builder_boxes.remote_pairing_url/_at — where a box publishes its current
+--      Remote-Control pairing link (POST /box/pairing) so a Chromebook builder
+--      can read it from the browser (GET /box/pairing-link) without first SSHing
+--      into the box (open question §9.4).
+--
+-- Idempotent: safe to re-run.
+
+-- ---------------------------------------------------------------------------
+-- box_intents — the provision / wake request queue (the trust-boundary-safe
+-- bridge between the web process and the control plane).
+-- ---------------------------------------------------------------------------
+CREATE TABLE IF NOT EXISTS box_intents (
+  id            bigserial PRIMARY KEY,
+  builder_id    bigint NOT NULL REFERENCES builders(id) ON DELETE CASCADE,
+
+  -- The lifecycle op being requested. Only the two SAFE, builder-initiated ops
+  -- are queueable: 'provision' (first box) and 'wake' (recreate a parked box).
+  -- park/deprovision are NEVER queued from the web — those stay operator/sweep
+  -- only (a builder can't be tricked into destroying their own box).
+  action        text NOT NULL CHECK (action IN ('provision', 'wake')),
+
+  -- pending  → waiting for the runner to pick it up
+  -- running  → the runner claimed it and is doing the DO work
+  -- done     → the lifecycle op succeeded
+  -- error    → the op failed (last_error carries why); a fresh intent can be
+  --            enqueued (this row is no longer "open" so the partial unique
+  --            index below lets a retry through).
+  state         text NOT NULL DEFAULT 'pending'
+                  CHECK (state IN ('pending', 'running', 'done', 'error')),
+
+  -- Who asked. 'api:self' for a builder's own /box/ensure call; an actor tag for
+  -- anything the control plane enqueues. Audit only.
+  requested_by  text,
+
+  -- Retry accounting. The runner bumps attempts each time it claims the intent;
+  -- a small cap (enforced in the runner, not here) stops a poison intent from
+  -- looping forever.
+  attempts      int NOT NULL DEFAULT 0,
+  last_error    text,
+
+  created_at    timestamptz NOT NULL DEFAULT now(),
+  updated_at    timestamptz NOT NULL DEFAULT now(),
+  resolved_at   timestamptz
+);
+
+-- At most ONE open (pending|running) intent per builder. A builder hammering
+-- "connect" from a flaky Chromebook tab must not pile up a queue of redundant
+-- provisions — the second enqueue collides here and the route returns the
+-- already-open intent instead. Resolved (done|error) rows are exempt, so a retry
+-- after a failure is always allowed.
+CREATE UNIQUE INDEX IF NOT EXISTS ux_box_intents_open
+  ON box_intents (builder_id)
+  WHERE state IN ('pending', 'running');
+
+-- The runner's hot path: "oldest pending intent". A partial index keeps it tiny
+-- (it only ever indexes the unresolved tail, not the full history).
+CREATE INDEX IF NOT EXISTS idx_box_intents_pending
+  ON box_intents (created_at)
+  WHERE state = 'pending';
+
+-- ---------------------------------------------------------------------------
+-- builder_boxes — where an active box publishes its Remote-Control pairing link.
+-- ---------------------------------------------------------------------------
+-- A box running `claude rc` (the always-on Remote-Control service, infra/
+-- claude-rc.service) emits a pairing link a thin device drives the session from.
+-- For a Chromebook (no Claude Desktop) that link is the whole on-ramp, but it
+-- only exists ON the box — and reaching it would require SSH, which defeats the
+-- point. So the box POSTs its current link up to the GDS (POST /box/pairing,
+-- authenticated as the builder via the GDS token already on the box), and the
+-- builder reads it from the browser (GET /box/pairing-link). The URL is a
+-- short-lived Remote-Control handle, not a credential — but it IS sensitive, so
+-- it is only ever returned to the box's OWN builder, and cleared when the box is
+-- parked/destroyed (it is meaningless once the droplet is gone).
+ALTER TABLE builder_boxes ADD COLUMN IF NOT EXISTS remote_pairing_url text;
+ALTER TABLE builder_boxes ADD COLUMN IF NOT EXISTS remote_pairing_at  timestamptz;
+
+INSERT INTO schema_migrations (version) VALUES ('070_box_intents')
+  ON CONFLICT (version) DO NOTHING;

package/migrations/071_box_first_provision_approval.sql

@@ -0,0 +1,46 @@
+-- 071_box_first_provision_approval.sql — ADR 0035 Decision 2 (#717): a newcomer's
+-- FIRST box must be approved by an Archon before any paid droplet is created.
+--
+-- Context
+-- -------
+-- #701 (migration 070) made POST /box/ensure enqueue a provision/wake intent that
+-- the control-plane runner (box.js run-intents) auto-drains. That is correct for
+-- wakes and for a builder who has already EARNED a box — but anyone with a GitHub
+-- account can sign in and become a Xenos, and a Xenos is above the box provisioning
+-- floor, so a bare signup could cause a paid droplet (~$24/mo) to be created with
+-- NO human in the loop. On a ~$5,000/yr budget that is an open cost hole
+-- (ADR 0035 §Problem-3).
+--
+-- This migration adds a 'pending_approval' state to box_intents. A provision intent
+-- for a builder with no prior provisioned box is enqueued as 'pending_approval'
+-- (NOT 'pending'), so the runner — which only ever claims state='pending' — skips
+-- it until an Archon approves (POST /box/intents/:id/approve flips it to 'pending').
+-- Wakes and any subsequent provision auto-drain unchanged. The web tier still only
+-- RECORDS A REQUEST; it never holds DO_API_TOKEN (the migration 070 invariant) — so
+-- approval authorizes spend without granting the web any power over infrastructure.
+--
+-- Idempotent: safe to re-run.
+
+-- Widen the state CHECK to admit 'pending_approval'. Postgres has no ALTER ... ADD
+-- VALUE for a CHECK constraint, so drop + re-add. The inline column constraint from
+-- migration 070 is auto-named <table>_<column>_check.
+ALTER TABLE box_intents DROP CONSTRAINT IF EXISTS box_intents_state_check;
+ALTER TABLE box_intents ADD CONSTRAINT box_intents_state_check
+  CHECK (state IN ('pending', 'pending_approval', 'running', 'done', 'error'));
+
+-- Audit: who approved the held first-box provision, and when.
+ALTER TABLE box_intents ADD COLUMN IF NOT EXISTS approved_by text;
+ALTER TABLE box_intents ADD COLUMN IF NOT EXISTS approved_at timestamptz;
+
+-- 'pending_approval' is an OPEN state: it must count toward the one-open-intent-per-
+-- builder rule (else a builder could pile up approval requests). Recreate the partial
+-- unique index to include it. The runner's hot-path index (idx_box_intents_pending)
+-- stays on state='pending' only, so a held intent is NEVER claimed by the runner —
+-- approval (flip to 'pending') is precisely what makes it visible to the drainer.
+DROP INDEX IF EXISTS ux_box_intents_open;
+CREATE UNIQUE INDEX IF NOT EXISTS ux_box_intents_open
+  ON box_intents (builder_id)
+  WHERE state IN ('pending', 'pending_approval', 'running');
+
+INSERT INTO schema_migrations (version) VALUES ('071_box_first_provision_approval')
+  ON CONFLICT (version) DO NOTHING;

package/migrations/072_onboarding_ship_three_remove_primer.sql

@@ -0,0 +1,80 @@
+-- 072_onboarding_ship_three_remove_primer.sql — #766: reshape the Xenos path.
+--
+-- Two changes to the onboarding state machine (migrations 045 + 059):
+--
+--   1. Remove 'primer_read'. Newcomers no longer have to read the citizen's
+--      primer (or the "how the system works" maps) before they can work — the
+--      Xenos path is now purely action-based: bear the seal → choose a craft →
+--      survey the works → claim → ship. The primer page itself stays for
+--      Metic+ citizens; only the newcomer *requirement* is dropped. The
+--      primer_read stage, its claimable/claim gate, and the /builder-primer-read
+--      CLI path are all removed in the same change.
+--
+--   2. Rename 'first_ship' → 'ship_three'. The terminal action stage now clears
+--      only when the builder has THREE successfully shipped tasks — the same
+--      threshold that auto-promotes a Xenos to Thetes (#692 / ADR 0034). So the
+--      onboarding checklist's graduation and the xenos→thetes promotion become
+--      the same moment. The live "N of 3" counter the hall renders is computed
+--      in shapeForApi from the shipped-task count, NOT from this stage (the
+--      stage is binary: cleared at 3, uncleared before).
+--
+-- The DB only validates enum membership of current_stage; ordering lives in the
+-- app layer (src/bongos/onboarding-state.js STAGES). So this migration rewrites the
+-- affected rows, then swaps the CHECK constraint's allowed set.
+--
+-- Grandfathering:
+--   * Rows already at current_stage='graduated' (graduated under the old
+--     1-ship rule) stay graduated — we never demote an existing graduate, even
+--     if they have fewer than 3 ships. Their completed_stages 'first_ship'
+--     entry is renamed to 'ship_three' for audit consistency.
+--   * A row parked at current_stage='primer_read' has not yet picked a craft
+--     (primer_read came before pick_disciplines in the old order), so it
+--     advances to 'pick_disciplines'.
+--   * A row parked at current_stage='first_ship' (claimed/shipped once but not
+--     yet graduated — only possible transiently) advances to 'ship_three'; they
+--     now need three ships. (Under the old model first_ship in completed_stages
+--     implied graduation, so no NON-graduated row carries it in the array.)
+--
+-- Idempotent: safe to re-run.
+
+BEGIN;
+
+-- 1. Audit array: strip the removed stage, rename the renamed one. array_remove
+--    / array_replace are no-ops when the element is absent, so this is safe to
+--    re-run and safe on rows that never had either entry.
+UPDATE builder_onboarding_state
+   SET completed_stages = array_remove(completed_stages, 'primer_read');
+
+UPDATE builder_onboarding_state
+   SET completed_stages = array_replace(completed_stages, 'first_ship', 'ship_three');
+
+-- 2. Re-home current_stage values that are being removed/renamed BEFORE swapping
+--    the constraint, or the new CHECK would reject them.
+UPDATE builder_onboarding_state
+   SET current_stage = 'pick_disciplines'
+ WHERE current_stage = 'primer_read';
+
+UPDATE builder_onboarding_state
+   SET current_stage = 'ship_three'
+ WHERE current_stage = 'first_ship';
+
+-- 3. Swap the stage enum: drop the old constraint (if present) and add the new
+--    one. Name matches migrations 045/059 so re-running stays clean.
+ALTER TABLE builder_onboarding_state
+  DROP CONSTRAINT IF EXISTS builder_onboarding_state_stage_enum;
+
+ALTER TABLE builder_onboarding_state
+  ADD CONSTRAINT builder_onboarding_state_stage_enum
+  CHECK (current_stage IN (
+    'auth_complete',
+    'pick_disciplines',
+    'first_start',
+    'first_claim',
+    'ship_three',
+    'graduated'
+  ));
+
+INSERT INTO schema_migrations (version) VALUES ('072_onboarding_ship_three_remove_primer')
+  ON CONFLICT (version) DO NOTHING;
+
+COMMIT;

package/migrations/073_box_terminal_access.sql

@@ -0,0 +1,46 @@
+-- 073_box_terminal_access.sql — #760 (ADR 0038): the Chromebook on-ramp redesign.
+--
+-- Context
+-- -------
+-- Migration 070 added builder_boxes.remote_pairing_url/_at for the `claude rc`
+-- Remote-Control on-ramp: the box published a claude.ai pairing link UP to the
+-- GDS so a Chromebook builder could read it from the browser. #745 leg-5 then
+-- proved `claude rc` CANNOT run on a headless box — Anthropic gates Remote
+-- Control behind interactive Trusted-Devices enrollment + a controlling TTY +
+-- full-scope OAuth, and every non-interactive auth path (ANTHROPIC_API_KEY,
+-- setup-token, apiKeyHelper) is excluded from RC by design. No plumbing fixes it.
+--
+-- ADR 0038 replaces that path: the box serves its OWN browser session — ttyd (a
+-- basic-auth web terminal) on 127.0.0.1:7681, exposed via an outbound-only
+-- Cloudflare Tunnel (cloudflared). Inside it the builder runs NORMAL interactive
+-- `claude` in a real PTY, so /login + workspace-trust + device enrollment all
+-- work (there IS a human at a browser-backed terminal). The box reports its
+-- current terminal URL AND a per-box basic-auth credential UP to the GDS (the
+-- same up-report/serve-to-owner shape migration 070 built), and the builder
+-- reads BOTH from the browser (GET /box/terminal).
+--
+-- This migration adds the terminal_* columns. Unlike the RC pairing link (a
+-- bare handle), the terminal needs a CREDENTIAL too — hence the extra column.
+-- The remote_pairing_url/_at columns from 070 are now DEPRECATED and left in
+-- place (non-destructive); nothing writes them after this ships.
+--
+-- Staleness model (unchanged from 070): the value is only ever SERVED when the
+-- box is state='active' (GET /box/terminal gates on it) and only ever WRITTEN
+-- when active (boxes.setTerminalAccess gates on it), so a parked box's stale URL
+-- is simply never returned — no explicit NULL-clear needed. The credential
+-- persists in the box snapshot across park/wake (stable); the quick-tunnel URL
+-- changes on each cloudflared restart, so the box re-reports it after a wake.
+--
+-- Sensitivity: terminal_credential IS a secret (basic-auth password to a live
+-- shell). Like remote_pairing_url it is returned ONLY to the box's own builder
+-- (GET /box/terminal, requireBuilder, own resource). It never appears in any
+-- public surface or in box_events detail.
+--
+-- Idempotent: safe to re-run.
+
+ALTER TABLE builder_boxes ADD COLUMN IF NOT EXISTS terminal_url        text;
+ALTER TABLE builder_boxes ADD COLUMN IF NOT EXISTS terminal_credential text;
+ALTER TABLE builder_boxes ADD COLUMN IF NOT EXISTS terminal_at         timestamptz;
+
+INSERT INTO schema_migrations (version) VALUES ('073_box_terminal_access')
+  ON CONFLICT (version) DO NOTHING;

package/migrations/075_builder_sound_prefs.sql

@@ -0,0 +1,28 @@
+-- 075_builder_sound_prefs.sql — per-builder per-sound on/off preferences
+-- (V3.R91 / #786). Follow-up to the #781 sound system.
+--
+-- One jsonb column on `builders` (sound_prefs), default '{}'. Each entry maps a
+-- sound name (chime | alert | ship | triumph | fanfare) to a boolean: false =
+-- the builder has muted that sound. A MISSING key falls back to the system
+-- default (ON), so the column stays sparse — a builder who never opens the
+-- setting has '{}' and hears everything, exactly as before this shipped.
+--
+-- This deliberately mirrors migration 037 (skill_model_prefs): per-builder
+-- personalized config, sparse + irregular, read by primary key, with the
+-- allowlist + defaults living in code (src/bongos/sound-prefs.js) rather than a
+-- Postgres CHECK — so adding a sixth sound is a one-line code change, not a
+-- coordinated schema migration.
+--
+-- The toggle is stored server-side but the sound plays from a LOCAL hook
+-- (.claude/sounds/play.js); a SessionStart step (scripts/gds/fetch-sound-prefs.js)
+-- mirrors this column into ~/.config/otb/sound-prefs.json so the offline hook
+-- can honor it without a per-turn network call. play.js fails OPEN (plays) when
+-- the local file is absent, so a fresh machine still gets sounds.
+--
+-- Idempotent: safe to re-run.
+
+ALTER TABLE builders
+  ADD COLUMN IF NOT EXISTS sound_prefs jsonb NOT NULL DEFAULT '{}'::jsonb;
+
+INSERT INTO schema_migrations (version) VALUES ('075_builder_sound_prefs')
+  ON CONFLICT (version) DO NOTHING;

package/migrations/078_box_claude_active.sql

@@ -0,0 +1,22 @@
+-- migration 078: box claude_active flag + deprovision intent action
+--
+-- Two changes:
+--   1. builder_boxes.claude_active — the box-side heartbeat reports whether a
+--      `claude` process is running. The idle sweep skips boxes where this is
+--      true, so a running Claude session keeps the box alive indefinitely.
+--      Resets to false on deprovision (setBoxState clears it).
+--
+--   2. box_intents.action CHECK extended to include 'deprovision' — the new
+--      POST /box/close route enqueues this, and the intent runner calls
+--      cmdDeprovision. Keeps the DO token on the control plane (trust boundary
+--      holds); the web tier only ever records a request.
+
+ALTER TABLE builder_boxes
+  ADD COLUMN IF NOT EXISTS claude_active bool NOT NULL DEFAULT false;
+
+ALTER TABLE box_intents
+  DROP CONSTRAINT IF EXISTS box_intents_action_check;
+
+ALTER TABLE box_intents
+  ADD CONSTRAINT box_intents_action_check
+    CHECK (action IN ('provision', 'wake', 'deprovision'));

package/migrations/079_box_first_connected_at.sql

@@ -0,0 +1,20 @@
+-- migration 079: box first_connected_at — the monotonic "properly connected" signal
+--
+-- The onboarding "Path into the City" gains a first step, "Connect to thy dev
+-- box" (#823, follow-up to #777 / ADR 0039). It must clear the moment a
+-- newcomer actually reaches a working Claude on their box, and — being an
+-- onboarding milestone — it must NEVER un-tick afterwards.
+--
+-- builder_boxes.claude_active (migration 078) is the live signal: the box-side
+-- heartbeat (infra/box-heartbeat.sh) reports true while a `claude` process is
+-- running. But it flips back to false when Claude stops, so it can't back a
+-- monotonic step on its own. first_connected_at is the write-once derivative:
+-- boxes.bumpActivity stamps it (COALESCE, never overwritten) the first time a
+-- heartbeat reports claude_active=true. NULL until then; once set it stays set.
+--
+-- A heartbeat can only ping with a GDS token present on the box, so a
+-- claude_active=true beat also implies the GDS CLI is authenticated — this one
+-- signal subsumes the old cli_setup onboarding step it replaces.
+
+ALTER TABLE builder_boxes
+  ADD COLUMN IF NOT EXISTS first_connected_at timestamptz;

package/migrations/081_tasks_needs_migration.sql

@@ -0,0 +1,34 @@
+-- migration 081: re-home migration-number allocation onto tasks.needs_migration
+--
+-- touches[] cleanup [1/8] (task 876, architect audit
+-- docs/audits/touches-array-2026-06-09.md, Musk algorithm / deletion-emphasized).
+--
+-- Until now the ONLY trigger for reserving a migration number at claim time was
+-- the literal string 'migrations/' living inside a task's touches[] array
+-- (db.js claimTask + batchClaim). That coupled a load-bearing allocation to a
+-- free-text path array that drifts as code wanders into unexpected files — the
+-- exact friction the audit targets. Replace the string sentinel with an
+-- explicit boolean column the allocator keys off instead.
+--
+-- POST /tasks now sets needs_migration from the same detectsMigration()
+-- title/description regex that used to inject 'migrations/'. Backfill every task
+-- that still carries the old sentinel so no in-flight migration task loses its
+-- reservation trigger across the cutover. (Duplicate migration numbers merge
+-- cleanly and are NOT detectable at merge, so this column must land before the
+-- touches[] column is ever dropped — see cluster steps [4/8]+.)
+
+ALTER TABLE tasks
+  ADD COLUMN IF NOT EXISTS needs_migration boolean NOT NULL DEFAULT false;
+
+-- Backfill from the retiring sentinel: a task that declared 'migrations/' in
+-- touches[] is a migration-bearing task.
+UPDATE tasks
+   SET needs_migration = true
+ WHERE needs_migration = false
+   AND 'migrations/' = ANY (touches);
+
+-- Counter hygiene: 080_gds_v4_planning_seed.sql shipped without the customary
+-- counter bump, so the allocator handed out 080 while 080_*.sql already existed
+-- (the live collision that surfaced this task). Re-base the floor above this
+-- file so the next reservation can't collide.
+UPDATE migration_counter SET next_number = GREATEST(next_number, 82) WHERE id = 1;

package/migrations/084_tasks_security_sensitive.sql

@@ -0,0 +1,24 @@
+-- migration 084: tasks.security_sensitive — explicit Archon-only-broadcast flag
+--
+-- task 990 (owner requirement): "Security updates should only be posted to
+-- Archons and live in a separate Discord ship-feed channel." When a task with
+-- this flag set ships, ship.js routes its broadcast ONLY to the Archon-only
+-- #security-ship-feed channel — never the public #ship-news or the builder
+-- #ship-feed.
+--
+-- This is an EXPLICIT flag, NOT a heuristic. A title/description classifier here
+-- would be the wrong tool: a single misfire (a security fix mis-classified as
+-- routine) leaks the existence — and often the shape — of an unpatched exploit
+-- to a public channel before the fix is even live. The cost of a false negative
+-- is a disclosed vulnerability, so the flag is set deliberately by the director
+-- on the specific tasks that warrant it, never inferred.
+--
+-- No backfill: the director sets security_sensitive on specific tasks
+-- separately. Every task defaults to false (the safe-loud public broadcast).
+
+ALTER TABLE tasks
+  ADD COLUMN IF NOT EXISTS security_sensitive boolean NOT NULL DEFAULT false;
+
+-- Counter hygiene: keep the migration-number allocator above this file so the
+-- next reservation can't collide with 084.
+UPDATE migration_counter SET next_number = GREATEST(next_number, 85) WHERE id = 1;

package/migrations/085_security_engagement_docs.sql

@@ -0,0 +1,34 @@
+-- migration 085: security_docs — Archon-only sensitive security documents
+--
+-- task 991 (owner decision: "in the repo but Archon-gated → Archon-only server
+-- route"). The DATED security engagement reports (exploit-detail red-team
+-- reports — full repro, evidence, the attacker cookbook) must NOT live as files
+-- in the git clone: the repo is cloned in full onto every Metic+ dev box
+-- (threat-model §6.3), so a committed exploit report is an attacker cookbook on
+-- every box. Instead the report bodies live here in the prod DB and are served
+-- ONLY to Archons via GET /api/gds/security/docs/:slug (requireRank('archon')).
+-- The SAFE conceptual docs (threat-model.md, the README) stay in docs/security/;
+-- only the dated exploit reports move to this table. See ADR 0020 (the full
+-- operational threat model is intentionally kept off-repo) and threat-model §6.3.
+--
+-- This is a doc store: content_md is deliberately uncapped at the schema layer
+-- (full reports run tens of KB) — the route layer applies an explicit large cap,
+-- NOT the small LIMITS.DESCRIPTION used for task/report fields.
+--
+-- No seed: the director uploads each dated report after deploy via the POST
+-- route (slug e.g. 2026-06-12-newbuilder-redteam), so no exploit content ever
+-- touches the repo or a migration.
+
+CREATE TABLE IF NOT EXISTS security_docs (
+  id         bigserial PRIMARY KEY,
+  slug       text UNIQUE NOT NULL,
+  title      text NOT NULL,
+  content_md text NOT NULL,
+  created_at timestamptz NOT NULL DEFAULT now(),
+  updated_at timestamptz NOT NULL DEFAULT now()
+);
+
+-- Counter hygiene: 086_rename_disciplines.sql is already on main, so push the
+-- allocator floor above it (to 88) — the next reservation must not collide with
+-- 085, 086, or a not-yet-merged 087.
+UPDATE migration_counter SET next_number = GREATEST(next_number, 88) WHERE id = 1;

package/migrations/086_rename_disciplines.sql

@@ -0,0 +1,125 @@
+-- 086_rename_disciplines.sql — task #615 / GDS-V3: rename builder disciplines.
+--
+-- The original discipline set (migration 014 / 027) was:
+--   creative | engineering | unclassified
+--
+-- "creative" conflated two different kinds of contribution — making visual
+-- art assets vs. thinking/writing/scoping. A builder who can scope, research,
+-- and write but cannot produce pixel art had no clean home. The new set
+-- splits that axis three ways:
+--
+--   engineer — builds code: routes, scripts, game logic, infra, migrations
+--   artist   — produces visual assets: pixel-art tiles, sprites, icons,
+--              avatars, the art pipeline itself
+--   ideator  — contributes through thinking: idea capture, task scoping,
+--              research, docs/briefs, feedback, user observation, naming, lore
+--
+-- Plus 'unclassified' (task-only) for un-triaged work, unchanged.
+--
+-- This migration swaps BOTH discipline CHECK constraints and backfills the
+-- existing data:
+--
+--   tasks.discipline (mig 014, enum: creative|engineering|unclassified):
+--     engineering                            → engineer
+--     creative + art touches (art/, png,     → artist
+--       sprite, avatar, public/assets/)
+--     creative + docs/ touches               → ideator
+--     creative (ambiguous / no touches)      → unclassified  (hand-triage)
+--     unclassified                           → unclassified  (unchanged)
+--
+--   builders.preferred_disciplines (mig 027, enum: creative|engineering):
+--     engineering → {engineer}
+--     creative    → {artist, ideator}   (inclusive: the builder opted into
+--                   non-engineering work, so surface both new lanes; they can
+--                   narrow later in /settings)
+--
+-- Constraints are dropped BEFORE the data updates (so the UPDATEs aren't
+-- rejected by the old enum mid-flight) and re-added AFTER, matching the
+-- pattern in migration 059. Every UPDATE is a no-op on already-migrated
+-- values, so the whole file is idempotent and safe to re-run.
+--
+-- The discipline column is text (not a native enum) and the two SELECT t.*
+-- views (claimable_tasks, tasks_session_fit) project the column by value, so
+-- no view rebuild is needed — a value change is invisible to a `SELECT t.*`.
+
+BEGIN;
+
+-- =========================================================================
+-- 1. Drop both CHECK constraints so the backfill UPDATEs can run.
+-- =========================================================================
+ALTER TABLE tasks    DROP CONSTRAINT IF EXISTS tasks_discipline_check;
+ALTER TABLE builders DROP CONSTRAINT IF EXISTS builders_preferred_disciplines_check;
+
+-- =========================================================================
+-- 2. Backfill tasks.discipline.
+-- =========================================================================
+
+-- engineering → engineer
+UPDATE tasks SET discipline = 'engineer'
+ WHERE discipline = 'engineering';
+
+-- creative + art-production touches → artist (applied first so it wins over
+-- the docs rule when a task carries both art and docs paths).
+UPDATE tasks SET discipline = 'artist'
+ WHERE discipline = 'creative'
+   AND touches IS NOT NULL
+   AND EXISTS (
+     SELECT 1 FROM unnest(touches) AS t
+      WHERE t LIKE 'art/%'
+         OR t LIKE 'public/assets/%'
+         OR t ILIKE '%png%'
+         OR t ILIKE '%sprite%'
+         OR t ILIKE '%avatar%'
+   );
+
+-- creative + docs touches → ideator
+UPDATE tasks SET discipline = 'ideator'
+ WHERE discipline = 'creative'
+   AND touches IS NOT NULL
+   AND EXISTS (
+     SELECT 1 FROM unnest(touches) AS t
+      WHERE t LIKE 'docs/%'
+   );
+
+-- remaining creative (ambiguous / no touches) → unclassified for hand-triage
+UPDATE tasks SET discipline = 'unclassified'
+ WHERE discipline = 'creative';
+
+-- =========================================================================
+-- 3. Backfill builders.preferred_disciplines.
+--    Map each element through the rename table, flatten, de-dup, re-aggregate.
+--    engineering→{engineer}, creative→{artist,ideator}, anything already-new
+--    passes through unchanged (idempotent).
+-- =========================================================================
+UPDATE builders b
+   SET preferred_disciplines = COALESCE((
+         SELECT array_agg(DISTINCT m.mapped ORDER BY m.mapped)
+           FROM unnest(b.preferred_disciplines) AS d
+           CROSS JOIN LATERAL (
+             SELECT unnest(
+               CASE d
+                 WHEN 'engineering' THEN ARRAY['engineer']
+                 WHEN 'creative'    THEN ARRAY['artist', 'ideator']
+                 ELSE ARRAY[d]
+               END
+             ) AS mapped
+           ) AS m
+       ), '{}')
+ WHERE preferred_disciplines IS NOT NULL
+   AND array_length(preferred_disciplines, 1) > 0;
+
+-- =========================================================================
+-- 4. Re-add both CHECK constraints with the new enum.
+-- =========================================================================
+ALTER TABLE tasks ADD CONSTRAINT tasks_discipline_check
+  CHECK (discipline IN ('engineer', 'artist', 'ideator', 'unclassified'));
+
+-- preferred_disciplines never carries 'unclassified' (that's a task state,
+-- not an interest area), mirroring migration 027's narrower set.
+ALTER TABLE builders ADD CONSTRAINT builders_preferred_disciplines_check
+  CHECK (preferred_disciplines <@ ARRAY['engineer', 'artist', 'ideator']::text[]);
+
+INSERT INTO schema_migrations (version) VALUES ('086_rename_disciplines')
+  ON CONFLICT (version) DO NOTHING;
+
+COMMIT;

package/migrations/088_builders_anthropic_link.sql

@@ -0,0 +1,28 @@
+-- migration 088: per-builder Anthropic account attestation (V3.R10 / task 235, criterion C3)
+--
+-- C3 wants every builder shipping under their OWN credentials, with cost +
+-- authorship attributable to a real person. The GDS identity is already a
+-- GitHub OAuth login, but we also want to know WHICH Anthropic account is
+-- driving the Claude Code session that makes the API calls — so a forged or
+-- borrowed CLI token can be cross-checked against the Anthropic identity the
+-- trusted local agent reports.
+--
+-- A first-party "sign in with Anthropic" OAuth does not exist yet. Instead we
+-- lean on the fact that Claude Code itself is the trusted agent on the
+-- builder's machine: during /builder-setup it reads its own ~/.claude.json
+-- oauthAccount (emailAddress + accountUuid), the builder confirms the email,
+-- and we store the attested pair here. Thereafter the CLI sends the
+-- accountUuid as an X-Anthropic-User header and requireBuilder cross-checks it.
+--
+-- This is ATTESTATION, not strong auth (the header can be omitted) — the V4
+-- follow-up replaces it with real Anthropic OAuth when that ships. Both columns
+-- are NULL until a builder links, so the requireBuilder cross-check is inert
+-- for every existing builder and the column add is fully back-compat.
+
+ALTER TABLE builders
+  ADD COLUMN IF NOT EXISTS anthropic_email   text,
+  ADD COLUMN IF NOT EXISTS anthropic_user_id text;
+
+-- Counter hygiene: keep the migration-number allocator above this file so the
+-- next reservation can't collide with 088.
+UPDATE migration_counter SET next_number = GREATEST(next_number, 89) WHERE id = 1;

package/migrations/089_builders_monthly_budget.sql

@@ -0,0 +1,19 @@
+-- migration 089: per-builder monthly spend budget (V3.R84 / task 302, criterion C3)
+--
+-- C3 wants each builder to ship under their OWN cost ceiling, with a soft-cap
+-- warning before they hit it and a hard-cap refusal at it. This column is the
+-- per-builder override; NULL means "use the project default"
+-- (cost.DEFAULT_MONTHLY_BUDGET_USD) so the global default can move without a
+-- migration. An Archon sets a non-null value via PATCH /builders/:id/budget to
+-- raise or lower a specific builder's ceiling.
+--
+-- Spend is month-to-date over cost_log.recorded_at (date_trunc('month', now())),
+-- attributed by cost_log.builder_id (migration 046). No new spend column — the
+-- ledger already records every dollar; this only stores the ceiling.
+
+ALTER TABLE builders
+  ADD COLUMN IF NOT EXISTS monthly_budget_usd numeric;
+
+-- Counter hygiene: keep the migration-number allocator above this file so the
+-- next reservation can't collide with 089.
+UPDATE migration_counter SET next_number = GREATEST(next_number, 90) WHERE id = 1;