@bongos/core 1.19.715 → 1.19.724

package/docs/recipes/self-host.md

@@ -1,8 +1,8 @@
 # Self-hosting Cloud Bongos (Docker)
 
-Bring up a vanilla Cloud Bongos instance — the build platform + builders' hall + status dashboard, with no game — on any machine with Docker. Shipped by V4.R63 ([task #1202](https://example.com/builders#/task/1202), [ADR 0062](../adr/<redacted>.md)).
+Bring up a vanilla Cloud Bongos instance — the build platform + builders' hall + status dashboard, with no game — on any machine with Docker. Shipped by V4.R63 ([task #1202](https://example.com/builders#/task/1202), [ADR 0062](../adr/0062-medusa-instance-model-decoupling.md)).
 
-> **Relation to configurable-root ([ADR 0108](../adr/<redacted>.md)):** this is the **single-checkout** self-host shape — the whole repo (core + config) is baked into one image, so `resolveCoreRoot()` and `resolveInstanceRoot()` ([`src/instance-config.js`](../../src/instance-config.js)) both resolve to `/app` inside the container. ADR 0108 does not deprecate this path — it stays the cheap, supported shape for a quick reskin (this is how `cloudbongos.com` runs). The *installed-as-a-dependency* shape (a consumer repo running `npm install @bongos/core`) is the separate, heavier path ADR 0108 targets for a project that wants its own repo and its own upgrade cadence — see [`docs/recipes/packaging-the-core.md`](packaging-the-core.md).
+> **Relation to configurable-root ([ADR 0108](../adr/0108-instance-composition-configurable-root.md)):** this is the **single-checkout** self-host shape — the whole repo (core + config) is baked into one image, so `resolveCoreRoot()` and `resolveInstanceRoot()` ([`src/instance-config.js`](../../src/instance-config.js)) both resolve to `/app` inside the container. ADR 0108 does not deprecate this path — it stays the cheap, supported shape for a quick reskin (this is how `cloudbongos.com` runs). The *installed-as-a-dependency* shape (a consumer repo running `npm install @bongos/core`) is the separate, heavier path ADR 0108 targets for a project that wants its own repo and its own upgrade cadence — see [`docs/recipes/packaging-the-core.md`](packaging-the-core.md).
 
 ## One command
 
@@ -13,7 +13,7 @@ docker compose up
 That builds the image, starts Postgres, applies the build-system migrations (game-module migrations are skipped — this is a Bongos-only instance), and serves the builders' hall at **http://localhost:3000**.
 
 - The instance is **vanilla** by default: the neutral Cloud Bongos brand, every feature module (game, art pipeline, Discord, dev boxes) **off**. `.dockerignore` keeps the host's `config/branding.json` and `config/modules.json` out of the image, so it resolves to `config/branding.neutral.json` + `config/modules.neutral.json`.
-- **No OTB scope-truth is seeded.** OTB/product data (game versions, goals, done-when criteria) lives in opt-in seed migrations under `migrations/instance/` (plus a few guarded blocks in the mixed files 003/006). `scripts/migrate.sh` skips them unless `GDS_APPLY_INSTANCE_SEEDS=1`, so a fresh DB comes up with only the schema and platform-universal defaults (ranks, achievements) — no crash, no foreign-key failures, no leftover versions. Platform system principals (`bfg-system`, `discord-bot-system`) are generic and remain. See task 1704 / [ADR 0105](../adr/<redacted>.md).
+- **No OTB scope-truth is seeded.** OTB/product data (game versions, goals, done-when criteria) lives in opt-in seed migrations under `migrations/instance/` (plus a few guarded blocks in the mixed files 003/006). `scripts/migrate.sh` skips them unless `GDS_APPLY_INSTANCE_SEEDS=1`, so a fresh DB comes up with only the schema and platform-universal defaults (ranks, achievements) — no crash, no foreign-key failures, no leftover versions. Platform system principals (`bfg-system`, `discord-bot-system`) are generic and remain. See task 1704 / [ADR 0105](../adr/0105-instance-seed-migrations-out-of-core.md).
 - **No prod topology** is referenced: the database is a local container, the credentials are local demo values, and the app reaches Postgres over TCP via `PG*` env (see `docker-compose.yml`).
 
 To stop and wipe: `docker compose down -v` (the `-v` drops the `cloudbongos-db` volume).
@@ -35,7 +35,7 @@ Author `config/branding.json` from the neutral starter — see [the branding con
 
 **Or scaffold it with `bongos init`** ([task #1204](https://example.com/builders#/task/1204)): a short interview (or `bongos init --from spec.json` for a hands-free / CI run) that writes both config files, **seeds your first version + its done-when goal**, and **files the human-only kickoff steps** (register a GitHub OAuth app, first owner sign-in, repo binding, admission) as real tracked tasks — so a fresh instance has a claimable queue on day one instead of an empty hall. It never invents your branding (it points you at the fill prompt for that). Preview the whole plan with `bongos init --dry-run`.
 
-**Production hosting, optional (the `provisioning` module — [ADR 0111](../adr/<redacted>.md) §3).** If you enable the `provisioning` module and answer the interview's hosting questions (shape — co-tenant `$0` or a dedicated droplet — bring-your-own domain, credential ref, tier), init turns those answers into a real **provisioning request** (a queued `provision` intent the control-plane runner drains) instead of only filing a manual "production topology" task. The two irreducibly-human legs — the GitHub OAuth app and the first owner sign-in — stay guided/manual. If the module isn't enabled on the target instance, init falls back to the manual production-topology task, so nothing is silently skipped.
+**Production hosting, optional (the `provisioning` module — [ADR 0111](../adr/0111-instance-hosting-provisioning-module.md) §3).** If you enable the `provisioning` module and answer the interview's hosting questions (shape — co-tenant `$0` or a dedicated droplet — bring-your-own domain, credential ref, tier), init turns those answers into a real **provisioning request** (a queued `provision` intent the control-plane runner drains) instead of only filing a manual "production topology" task. The two irreducibly-human legs — the GitHub OAuth app and the first owner sign-in — stay guided/manual. If the module isn't enabled on the target instance, init falls back to the manual production-topology task, so nothing is silently skipped.
 
 ## Configuration surface
 
@@ -43,7 +43,7 @@ Author `config/branding.json` from the neutral starter — see [the branding con
 |---|---|---|
 | `PGHOST` / `PGPORT` / `PGUSER` / `PGPASSWORD` / `PGDATABASE` | Postgres connection (read by both the app pool and the migration runner) | the local `db` service |
 | `HOST` / `PORT` | bind address inside the container | `0.0.0.0` / `3000` |
-| `MEDUSA_GDS_ONLY` | `1` = hard force-skip the OTB **instance-seed** migrations (`migrations/instance/`) — belt-and-suspenders over the default. A vanilla instance never wants OTB's versions/goals/criteria (task 1704 / [ADR 0105](../adr/<redacted>.md)). | `1` |
+| `MEDUSA_GDS_ONLY` | `1` = hard force-skip the OTB **instance-seed** migrations (`migrations/instance/`) — belt-and-suspenders over the default. A vanilla instance never wants OTB's versions/goals/criteria (task 1704 / [ADR 0105](../adr/0105-instance-seed-migrations-out-of-core.md)). | `1` |
 | `GDS_APPLY_INSTANCE_SEEDS` | `1` = opt IN to applying the bundled OTB instance-seed migrations. Default (unset) = **skip** — so a self-host never inherits OTB scope-truth. Only the owning instance sets this, and only when rebuilding its DB from scratch (DR). | unset |
 | `BONGOS_PUBLIC_ORIGIN` | public origin for OAuth callbacks etc. | `http://localhost:3000` |
 

package/docs/recipes/server-bring-up.md

@@ -1,6 +1,6 @@
 # Recipe — putting your instance on a real host (`bongos serve`)
 
-> [ADR 0169](../adr/<redacted>.md), task [#1002398](https://cloudbongos.com/builders#/task/1002398). The server half of [`local-dev.md`](local-dev.md) / [ADR 0149](../adr/<redacted>.md): the **same** boot path `bongos dev` runs on your laptop, on a VPS.
+> [ADR 0169](../adr/0169-bongos-serve-server-bring-up.md), task [#1002398](https://cloudbongos.com/builders#/task/1002398). The server half of [`local-dev.md`](local-dev.md) / [ADR 0149](../adr/0149-bongos-dev-local-launcher.md): the **same** boot path `bongos dev` runs on your laptop, on a VPS.
 
 ## The short version
 

package/docs/recipes/ship-and-regrade.md

@@ -12,7 +12,7 @@
 
 1. **`completed`** — the claim resolves once local verification (smoke) passes. **The claim is consumed here.**
 2. **`confirmed`** — the v2 subagent quality grader (the 4-worker panel: Narc · Quality · Hacker · Efficiency Monger) passes. **Verified, but not yet paid.**
-3. **`shipped`** — branch auto-merged to `main` + deployed; the Discord `#ship-news` broadcast fires. **Credits land here** ([ADR 0120](../adr/<redacted>.md) pays on land, not on confirm) — so a task stranded at `confirmed` is unpaid until it lands.
+3. **`shipped`** — branch auto-merged to `main` + deployed; the Discord `#ship-news` broadcast fires. **Credits land here** ([ADR 0120](../adr/0120-pay-on-land-and-builder-owned-rebase-gate.md) pays on land, not on confirm) — so a task stranded at `confirmed` is unpaid until it lands.
 
 The grader reads **committed history** (`merge-base origin/main HEAD`…`HEAD`), independent of touches[] — so the diff it judges is whatever you've committed on the branch, not your working tree.
 
@@ -69,4 +69,4 @@ This writes a `task_grades` row with `grader_kind='lars'` so the audit trail sho
 
 - Learning `#43` — "Recover a task stuck at 'completed': re-grade standalone, then /merge-mode" (the manual procedure this recipe automates).
 - [`/merge-mode`](../../.claude/skills/merge-mode/SKILL.md) — lands `confirmed → shipped` when auto-merge bailed.
-- [ADR 0024](../adr/<redacted>.md) — the MAS grader panel.
+- [ADR 0024](../adr/0024-multi-agent-system-architecture.md) — the MAS grader panel.

package/docs/recipes/standalone-live-docs.md

@@ -1,7 +1,7 @@
 # Recipe — live-updating docs on a STANDALONE instance
 
 **Read before:** standing up / debugging a standalone instance whose `docs/` is empty or stale.
-**Decision of record:** [ADR 0147](../adr/<redacted>.md) (builds on [ADR 0110](../adr/<redacted>.md) / [ADR 0108](../adr/<redacted>.md)).
+**Decision of record:** [ADR 0147](../adr/0147-standalone-live-docs-regen.md) (builds on [ADR 0110](../adr/0110-untrack-whole-file-generated-nav-docs.md) / [ADR 0108](../adr/0108-instance-composition-configurable-root.md)).
 
 ## The mental model — which doc refreshes where
 

package/docs/recipes/ui-look-before-you-ship.md

@@ -1,6 +1,6 @@
 # Look before you ship — the ui-design kit
 
-> The `ui-design` module's kit (`modules/ui-design/kit/`, [task 1003320](https://cloudbongos.com/builders#/task/1003320), [ADR 0197](../adr/<redacted>.md)): a stub, a renderer/auditor, the interaction probes, the mock checker and the contrast probe any builder points at any surface of any instance. Plain Node; the browser is the system Edge or Chrome (nothing is downloaded). The `/design` playbook sends you here.
+> The `ui-design` module's kit (`modules/ui-design/kit/`, [task 1003320](https://cloudbongos.com/builders#/task/1003320), [ADR 0197](../adr/0197-the-ui-design-module.md)): a stub, a renderer/auditor, the interaction probes, the mock checker and the contrast probe any builder points at any surface of any instance. Plain Node; the browser is the system Edge or Chrome (nothing is downloaded). The `/design` playbook sends you here.
 
 The loop is five commands and one habit: **stub → render → probe → read the shots → fix in one batch → re-run once.** A surface describes itself in two small JSON files beside it; the kit never hardcodes a page.
 

package/docs/recipes/upgrading-the-core.md

@@ -2,7 +2,7 @@
 
 > **This is one leg of three.** For the whole path from a change on core `main` to a live instance — including how to tell whether *this* instance takes a vendored tarball or a registry version — start at [the core release pipeline](core-release-pipeline.md).
 >
-> The R86 update-consumption channel ([ADR 0100](../adr/<redacted>.md) §2, [ADR 0103](../adr/<redacted>.md) §4, task [#1690](https://example.com/builders#/task/1690)). How a **two-repo consumer instance** — one that installs `@bongos/core` as a vendored-tarball dependency — pulls the core from version N → N+1. Tooling: [`scripts/gds/upgrade.js`](../../scripts/gds/upgrade.js) (`bongos upgrade`). First proven live on emersonian-circles 1.15.0 → 1.16.0 (task [#1976](https://example.com/builders#/task/1976)).
+> The R86 update-consumption channel ([ADR 0100](../adr/0100-two-repo-instance-model.md) §2, [ADR 0103](../adr/0103-core-first-extraction-cloud-bongos-trunk.md) §4, task [#1690](https://example.com/builders#/task/1690)). How a **two-repo consumer instance** — one that installs `@bongos/core` as a vendored-tarball dependency — pulls the core from version N → N+1. Tooling: [`scripts/gds/upgrade.js`](../../scripts/gds/upgrade.js) (`bongos upgrade`). First proven live on emersonian-circles 1.15.0 → 1.16.0 (task [#1976](https://example.com/builders#/task/1976)).
 
 ## What the channel does
 
@@ -76,7 +76,7 @@ By default (`--rollback-on-failure`, ON unless `--no-rollback-on-failure`) the c
 
 ## Subscribing to updates — unattended patch-only auto-upgrade (task 2150 / ADR 0136)
 
-The sections above are the *manual* `bongos upgrade`. The **subscription** runs it for you, on a cadence, safely — the "subscribe to regular updates" experience. Policy: **patch-only by default, health-gated with auto-rollback, opt-in, autonomy-gated** (full rationale in [ADR 0136](../adr/<redacted>.md)).
+The sections above are the *manual* `bongos upgrade`. The **subscription** runs it for you, on a cadence, safely — the "subscribe to regular updates" experience. Policy: **patch-only by default, health-gated with auto-rollback, opt-in, autonomy-gated** (full rationale in [ADR 0136](../adr/0136-update-channel-subscription-policy.md)).
 
 **Per-instance channel** bounds how far an unattended upgrade may jump:
 

package/docs/recipes/work-on-a-task-from-your-dev-box.md

@@ -2,11 +2,11 @@
 
 > Your dev box serves your **rank scope**: Metic+ boxes carry the **whole repo**;
 > newcomer (starter) boxes carry the safe starter surface. Task-scoped slices are
-> **paused** per [ADR 0193](../adr/<redacted>.md) (the
-> machinery from [ADR 0148](../adr/<redacted>.md) remains;
+> **paused** per [ADR 0193](../adr/0193-pause-task-scoped-box-slices.md) (the
+> machinery from [ADR 0148](../adr/0148-task-scoped-box-source-access.md) remains;
 > `BOX_TASK_SCOPE=on` re-enables it). Your GitHub token never leaves the server —
 > see "How git works on a box" below, and
-> [ADR 0150](../adr/<redacted>.md) for how the
+> [ADR 0150](../adr/0150-box-first-boot-bringup-vendored-instances.md) for how the
 > box comes up.
 
 ## TL;DR
@@ -27,7 +27,7 @@ waiting for the box's ~10-minute refresh.
 ## How git works on a box — read this BEFORE diagnosing "stuck"
 
 The box holds **no stored git credential, ever** — and that is the design, not a
-fault ([ADR 0055](../adr/<redacted>.md)):
+fault ([ADR 0055](../adr/0055-server-mediated-branch-publish.md)):
 
 - **Reads are server-mediated, per request.** Every remote git operation goes
   through `/usr/local/bin/otb-git-credential`, which asks the control plane
@@ -57,7 +57,7 @@ box-written — don't edit it).
   `.claude/`), build tooling (`scripts/`, `src/bongos/`), `docs/`, `infra/`,
   `tests/`, and the sandbox-runnable product code. Rank, checked live by the
   server, is what bounds a box — not the task you claimed
-  ([ADR 0193](../adr/<redacted>.md)).
+  ([ADR 0193](../adr/0193-pause-task-scoped-box-slices.md)).
 
 ## Step by step
 
@@ -118,5 +118,5 @@ one-claim-per-session). To move to a different task:
   the cron does on its schedule.
 - **A fresh box comes up with the code already cloned.** If a box ever comes up
   *bare* (no code, no terminal), that's the packaging bug
-  [ADR 0150](../adr/<redacted>.md) fixed on the
+  [ADR 0150](../adr/0150-box-first-boot-bringup-vendored-instances.md) fixed on the
   control plane — flag it rather than working around it.

package/docs/research/cursor-competitive-analysis.md

@@ -175,8 +175,8 @@ And the reframe that matters most: **Cloud Bongos is free and non-profit, so it
 
 | Cloud Bongos's defensible axis | Why Cursor structurally can't match it |
 |---|---|
-| **Open / AGPL-3.0, no lock-in** ([ADR 0065](../adr/<redacted>.md)) | A $29B+ venture co. *sells* lock-in; AGPL §13 anti-capture is antithetical to its model |
-| **Self-host + full data control** ([ADR 0062](../adr/<redacted>.md) instance model) | SaaS multi-tenant is how it gets margin + telemetry; self-host canonical is the opposite |
+| **Open / AGPL-3.0, no lock-in** ([ADR 0065](../adr/0065-agpl-nonprofit-ai-first-governance.md)) | A $29B+ venture co. *sells* lock-in; AGPL §13 anti-capture is antithetical to its model |
+| **Self-host + full data control** ([ADR 0062](../adr/0062-medusa-instance-model-decoupling.md) instance model) | SaaS multi-tenant is how it gets margin + telemetry; self-host canonical is the opposite |
 | **Model-agnostic / BYO-key, zero markup** | Its economics *depend* on the inference relationship; BYO-key removes the revenue and the supplier risk |
 | **Governance / methodology layer** (claim→ship→grade, multi-builder, trust boundary) | Cursor 3 is *starting* on team governance — but for closed, per-seat, supervised use, not agent-authored multi-builder accountability |
 | **Non-profit** | Investors require the opposite; it can't credibly be "not monetizing you" |
@@ -248,7 +248,7 @@ For an AI-first **orchestration** platform, rank threats by *"does it manage aut
 - "$60B valuation / SpaceX-xAI acquisition (2026)" — **excluded as not credible** (low-quality sources). The credible April-2026 datapoint is the TechCrunch "$2B at ~$50B, in talks" line.
 - "$200/mo plan ≈ $5,000 in real compute" — abstained; directionally consistent with negative-margin reporting, specific figure unverified.
 
-**Internal (our positioning, read 2026-06-22):** [ADR 0065](../adr/<redacted>.md) (AGPL / non-profit / AI-first), [ADR 0062](../adr/<redacted>.md) (instance model, core↔host split), [`GOVERNANCE.md`](../../GOVERNANCE.md) (anti-capture principles); companion deep-research doc `component-based-dev-research.md` (uncommitted, module-system research, 2026-06-21).
+**Internal (our positioning, read 2026-06-22):** [ADR 0065](../adr/0065-agpl-nonprofit-ai-first-governance.md) (AGPL / non-profit / AI-first), [ADR 0062](../adr/0062-medusa-instance-model-decoupling.md) (instance model, core↔host split), [`GOVERNANCE.md`](../../GOVERNANCE.md) (anti-capture principles); companion deep-research doc `component-based-dev-research.md` (uncommitted, module-system research, 2026-06-21).
 
 ---
 

package/docs/research/llm-model-agnostic-and-cheaper-grader.md

@@ -12,7 +12,7 @@ This is a **doc-only research spike** — no code, migration, or config changed
 - **Phase 1 — Tools/coupling audit.** A concrete inventory of *where* the platform is hard-wired to Anthropic/Claude today, file by file, so a build cluster knows exactly what to touch.
 - **Phase 2 — Architecture path.** A recommended sequence to (a) a `ModelProvider` abstraction layer and (b) a cheaper grader, with trade-offs.
 
-**Relationship to [ADR 0089](../adr/<redacted>.md).** The *direction* for both goals was already decided with the owner on 2026-06-26 and recorded in ADR 0089 (Accepted; build task-pending): a central work-type-parameterized grading engine, a cross-family ensemble (Claude + hosted open-weight judges), a `ModelProvider` adapter, and a hosted pay-per-call API for the open leg. **This spike does not re-decide any of that** — it supplies the missing input ADR 0089's "Implementation (task-pending)" section presumes: the *grounded coupling map* of the current codebase. Where this doc and ADR 0089 touch the same ground, ADR 0089 is the decision and this doc is the implementation reconnaissance feeding it.
+**Relationship to [ADR 0089](../adr/0089-modular-multi-model-adversarial-grader.md).** The *direction* for both goals was already decided with the owner on 2026-06-26 and recorded in ADR 0089 (Accepted; build task-pending): a central work-type-parameterized grading engine, a cross-family ensemble (Claude + hosted open-weight judges), a `ModelProvider` adapter, and a hosted pay-per-call API for the open leg. **This spike does not re-decide any of that** — it supplies the missing input ADR 0089's "Implementation (task-pending)" section presumes: the *grounded coupling map* of the current codebase. Where this doc and ADR 0089 touch the same ground, ADR 0089 is the decision and this doc is the implementation reconnaissance feeding it.
 
 > **Confidence marks:** ✅ verified against the live file this session · 🔧 my synthesis / recommendation · ⚠️ caveat or open question for the owner/build cluster.
 
@@ -27,9 +27,9 @@ This is a **doc-only research spike** — no code, migration, or config changed
 
 The good news for the build: **there is one chokepoint.** Almost every platform LLM call funnels through `grader.runSubagent({prompt, opts})` (and its cached sibling `runSubagentCached`). Architect-audit and the routine runner reuse it; the only spawns that *don't* go through it are a couple of CLI scripts that call `spawn('claude', …)` directly. So a `ModelProvider` port introduced **at `runSubagent`** captures the overwhelming majority of the surface in one place. ✅
 
-**The cheaper grader is the same lever pulled differently.** Grading is purely *additive* spend (we pay Claude to write the code, then pay Claude again — Opus/Sonnet — to grade it). The grader prompt is mostly a **fixed rubric sent every call**, which makes it the ideal candidate for (a) a cheaper open-weight judge via the same `openai-compatible` adapter and (b) prompt-cache amortization (already partly handled by the content-addressed LLM cache, [ADR 0077](../adr/<redacted>.md)). 🔧
+**The cheaper grader is the same lever pulled differently.** Grading is purely *additive* spend (we pay Claude to write the code, then pay Claude again — Opus/Sonnet — to grade it). The grader prompt is mostly a **fixed rubric sent every call**, which makes it the ideal candidate for (a) a cheaper open-weight judge via the same `openai-compatible` adapter and (b) prompt-cache amortization (already partly handled by the content-addressed LLM cache, [ADR 0077](../adr/0077-content-addressed-llm-cache.md)). 🔧
 
-**Recommended sequence (detail in §6):** introduce the `ModelProvider` port at `runSubagent` with the existing Claude path as the only registered provider (zero behavior change) → add an `openai-compatible` adapter (DeepInfra/OpenRouter, BYOK, owner spend approval) → generalize `selectGraderModel` into a provider+model registry → run one open judge **advisory-only** (logs, does not gate) → promote to voting once the error-correlation audit ([ADR 0089](../adr/<redacted>.md) §5) shows agreement. This is exactly ADR 0089's staging; this doc just pins each stage to the real files.
+**Recommended sequence (detail in §6):** introduce the `ModelProvider` port at `runSubagent` with the existing Claude path as the only registered provider (zero behavior change) → add an `openai-compatible` adapter (DeepInfra/OpenRouter, BYOK, owner spend approval) → generalize `selectGraderModel` into a provider+model registry → run one open judge **advisory-only** (logs, does not gate) → promote to voting once the error-correlation audit ([ADR 0089](../adr/0089-modular-multi-model-adversarial-grader.md) §5) shows agreement. This is exactly ADR 0089's staging; this doc just pins each stage to the real files.
 
 ---
 
@@ -82,7 +82,7 @@ The main builder session runs inside the **Claude Code CLI harness** itself, whi
 
 ### 2.5 What is NOT coupled (already abstracted, leave alone)
 
-- **The content-addressed LLM cache** ([ADR 0077](../adr/<redacted>.md), `api.llmCache`) — provider-agnostic by shape; memoizes any `{prompt, model}` call. No change needed; it's a free win for the open leg. ✅
+- **The content-addressed LLM cache** ([ADR 0077](../adr/0077-content-addressed-llm-cache.md), `api.llmCache`) — provider-agnostic by shape; memoizes any `{prompt, model}` call. No change needed; it's a free win for the open leg. ✅
 - **The worker contract** (`buildPrompt`/`extractJson`/`computeVerdict` in `modules/grading/grader-workers/`) — model-independent; it builds a prompt and parses JSON. A different model that returns the same JSON schema slots in with no worker change. ✅
 - **The deterministic pre-passes** (route-rank, permission-path — `routeRankCheck`/`permissionPathCheck`) — zero-LLM, no model coupling, and per ADR 0089 §6 they **must stay** the authoritative security gate regardless of which model grades quality. ✅
 - **The art/vision pipeline** (`modules/art-pipeline/`, Gemini) — a *separate* provider coupling (Google, not Anthropic). ADR 0089 §7 folds it into the same work-type seam later; out of scope for *this* spike's Anthropic-focused audit but flagged so the build cluster knows the second provider exists. ⚠️
@@ -153,7 +153,7 @@ This matches ADR 0089 §3's `ModelProvider` decision exactly. The cost field abs
 
 ### 4.4 Trust boundary (non-negotiable, from ADR 0089 §6)
 
-An open-model verdict that gates a ship is a **content-injection surface** ([ADR 0080](../adr/<redacted>.md)). The abstraction must preserve:
+An open-model verdict that gates a ship is a **content-injection surface** ([ADR 0080](../adr/0080-llm-cache-api-transport-and-trust-model.md)). The abstraction must preserve:
 
 - **Deterministic pre-passes stay authoritative + zero-LLM.** No LLM verdict (Claude or open) can upgrade a route-rank / permission-path fail to pass. The provider port grades *quality* only. ✅
 - **Server-side guards (`serverSideGuards`) stay downgrade-only.** The existing envelope (re-run deterministic checks server-side, implausible-pass plausibility bound) is provider-independent and must wrap an open judge's verdict identically. ✅
@@ -223,5 +223,5 @@ Per the task's instruction, this doc lists recommended follow-ups rather than cr
 ## 9. Sources
 
 - The live repo, read 2026-06-28: `modules/grading/grader.js`, `modules/grading/grader-workers/index.js`, `modules/grading/CLAUDE.md`, `src/bongos/llm-pricing.js`, `src/bongos/cascade-dispatch.js`, `modules/builder-settings/skill-prefs.js`, `scripts/gds/ci-grade.js`, `scripts/gds/architect-audit.js`, `scripts/gds/session-cost.js`, `scripts/gds/run-routine.js`.
-- [ADR 0089 — Modular, multi-model adversarial grader](../adr/<redacted>.md) (the accepted direction this spike grounds; includes the external literature + market sweep — self-preference, PoLL, *Nine Judges*, open-weight model licenses, hosting math).
-- [ADR 0028 — Honest LLM spend accounting](../adr/<redacted>.md), [ADR 0077 — Content-addressed LLM cache](../adr/<redacted>.md), [ADR 0080 — LLM cache API transport & trust model](../adr/<redacted>.md), [ADR 0062 — Instance-model decoupling](../adr/<redacted>.md), [ADR 0021 — Per-builder skill model preferences](../adr/<redacted>.md).
+- [ADR 0089 — Modular, multi-model adversarial grader](../adr/0089-modular-multi-model-adversarial-grader.md) (the accepted direction this spike grounds; includes the external literature + market sweep — self-preference, PoLL, *Nine Judges*, open-weight model licenses, hosting math).
+- [ADR 0028 — Honest LLM spend accounting](../adr/0028-honest-llm-spend-accounting.md), [ADR 0077 — Content-addressed LLM cache](../adr/0077-content-addressed-llm-cache.md), [ADR 0080 — LLM cache API transport & trust model](../adr/0080-llm-cache-api-transport-and-trust-model.md), [ADR 0062 — Instance-model decoupling](../adr/0062-medusa-instance-model-decoupling.md), [ADR 0021 — Per-builder skill model preferences](../adr/0021-per-builder-skill-model-preferences.md).

package/migrations/core_240_artist_gate_indexes.sql

@@ -0,0 +1,48 @@
+-- core_240 — index the two reads the artist gate rides on (task 1003575, ADR 0241).
+--
+-- A CORE migration, not a lifecycle one: both `tasks` and `task_override_requests`
+-- are core tables, and ADR 0083 §5 lets a module migration touch only its own
+-- `lifecycle_`-namespaced tables. (fitness.js enforces that, and caught this.)
+--
+-- WHY NOW. Two reads key on this pair and neither had an index behind it:
+--
+--   findTaskBySourceRef  the create-vector idempotency read (task 386) — every
+--                        POST /tasks, every capture re-run, every cascade filing.
+--   listOpenArtistReviews  the artist gate's state read (task 1003575) — a route
+--                        any builder can call AND one every go-live calls, on a
+--                        table that only grows.
+--
+-- Without it both are sequential scans of `tasks`. The gate one is the sharper
+-- edge: a deploy should not get slower because the board got bigger.
+--
+-- NOT UNIQUE, deliberately, and this is the same reasoning findTaskBySourceRef's
+-- own comment records: `tasks` already carries historical (source, source_ref)
+-- duplicates, so a UNIQUE index would fail to BUILD on deploy and take the
+-- migration with it. Application-level idempotency stays the mechanism; this is
+-- only about how the row is found.
+--
+-- PARTIAL on `source IS NOT NULL`: the overwhelming majority of tasks are
+-- hand-filed with no source at all, and indexing those rows buys nothing — both
+-- queries always bind a source.
+--
+-- IF NOT EXISTS so a re-run is a no-op (the migration runner's contract). No
+-- CONCURRENTLY: the runner wraps each migration in a transaction, and this index
+-- is small enough that the brief lock is not worth leaving the transaction for.
+
+-- PLAIN BTREE, not text_pattern_ops, and that is a decision rather than an
+-- oversight. Under a non-C collation Postgres cannot turn `source_ref LIKE
+-- 'prefix%'` into a range bound on that column by itself — but both queries bind
+-- `source` by EQUALITY first, so the scan is already bounded to one source's rows
+-- and the LIKE is a cheap filter within it. A text_pattern_ops index would help
+-- only a caller that matched a prefix WITHOUT naming a source, which neither
+-- query does and which would be the wrong query anyway. Revisit if one appears.
+CREATE INDEX IF NOT EXISTS idx_tasks_source_ref
+  ON tasks (source, source_ref)
+  WHERE source IS NOT NULL;
+
+-- The gate's other leg: "does this task have an approved override request?",
+-- asked as a NOT EXISTS for every candidate review. The open-request uniqueness
+-- index is keyed on (task_id) WHERE status='open', so it cannot serve a lookup
+-- for 'approved' rows.
+CREATE INDEX IF NOT EXISTS idx_task_override_requests_task_status
+  ON task_override_requests (task_id, status);

package/migrations/core_240_goal_members_drop_legacy_role.sql

@@ -0,0 +1,79 @@
+-- core_240_goal_members_drop_legacy_role.sql — THE CONTRACT PHASE of the fourth
+-- "role" rename (task 1003089). core_220 was the expand phase; ADR 0177 records
+-- the two-step, ADR 0174 reserves the word `role` for the three crafts.
+--
+-- forward-unsafe: drop-column + set-not-null on goal_members — safe because core 1.19.238 (task 1003013) stopped reading the dropped column and live serves 1.19.689.
+--
+--   The pragma's first line is the whole claim on purpose: the acknowledgement
+--   regex in scripts/gds/lint-migrations.js captures ONE line, so a reason spread
+--   over a paragraph records nothing a reader of the lint output can check.
+--   Both operations are INTENTIONAL and gated, and this is the step core_220
+--   wrote down in advance. `bongos upgrade` auto-rollback
+--   reverts the CODE PIN but NOT the DB, so the question a pragma has to answer
+--   is "what is the oldest release a rollback could restore, and does it read
+--   the dropped column?". The release that stopped reading `goal_members.role`
+--   is core 1.19.238 (task 1003013, merged as 4738e3dd); cloudbongos.com serves
+--   1.19.689 — ~450 releases past it — verified at claim time with
+--   `curl -s https://cloudbongos.com/version` and
+--   `node scripts/gds/deploy-divergence.js`. There is no live reader of `role`
+--   left to strand. Ships with a fresh backup (`node scripts/gds/backup.js
+--   trigger`) and its own deploy window, same risk class as government_001.
+--
+-- THE FRESH-INSTALL HALF, which is not obvious from the column alone: the last
+-- writer of `role` was not application code at all but a MODULE migration —
+-- modules/lifecycle/migrations/lifecycle_001_goal_first_leads.sql, which runs
+-- AFTER the core migrations on every fresh install and named the old column in
+-- both its INSERT list and its ON CONFLICT arm. A DROP here without that edit
+-- would not have shown up on this instance (the module migration is already in
+-- `schema_migrations`, so it never re-runs) and would have broken `cloudbongos
+-- init` for every NEW instance instead. It is renamed in the same change, and
+-- tests/membership_kind_lockstep.mjs pins that no writer of the old name is left.
+--
+-- Idempotent: safe to re-run, including after the column is already gone.
+
+BEGIN;
+
+-- 1. The lockstep goes FIRST. The function body names NEW.role, and Postgres does
+--    not dependency-track plpgsql bodies — a trigger left behind would not block
+--    the DROP, it would fail at the next write to the table instead.
+DROP TRIGGER IF EXISTS goal_members_membership_kind_lockstep ON goal_members;
+DROP FUNCTION IF EXISTS goal_members_membership_kind_lockstep();
+
+-- 2. The last backfill, guarded on the column still being there so a re-run after
+--    the DROP is a no-op rather than an error. core_220 backfilled at expand time
+--    and the trigger has held the pair in step since, so this is expected to touch
+--    zero rows; it runs because "expected zero" is not "provably zero" on an
+--    instance that spent a release accepting writes from two code paths.
+DO $$
+BEGIN
+  IF EXISTS (
+    SELECT 1 FROM pg_attribute
+     WHERE attrelid = 'goal_members'::regclass
+       AND attname = 'role'
+       AND NOT attisdropped
+  ) THEN
+    EXECUTE 'UPDATE goal_members SET membership_kind = role WHERE membership_kind IS NULL';
+  END IF;
+END $$;
+
+-- 3. Any row the trigger never saw (there should be none) resolves to the same
+--    default the old column carried since migration 160, so step 5 cannot fail
+--    the whole migration on a single stray NULL.
+UPDATE goal_members SET membership_kind = 'member' WHERE membership_kind IS NULL;
+
+-- 4. The old noun leaves the schema. Its CHECK constraint and column default go
+--    with it; core_220's goal_members_membership_kind_check already carries the
+--    same ('lead','member') rule on the new column.
+ALTER TABLE goal_members DROP COLUMN IF EXISTS role;
+
+-- 5. The two guarantees core_220 deliberately deferred to this step. They were
+--    unsafe to state while an older release could still write only `role`; now
+--    that nothing does, the column can carry them itself instead of resting on a
+--    trigger surviving.
+ALTER TABLE goal_members ALTER COLUMN membership_kind SET NOT NULL;
+ALTER TABLE goal_members ALTER COLUMN membership_kind SET DEFAULT 'member';
+
+INSERT INTO schema_migrations (version) VALUES ('core_240_goal_members_drop_legacy_role')
+  ON CONFLICT DO NOTHING;
+
+COMMIT;

package/modules/dev-box/app/src/vendor/bongos-client.cjs

@@ -125,6 +125,10 @@ function createClient(opts = {}) {
       // GET /analytics/builder/{id} — rank: any-builder — GET /analytics/builder/:id
       getAnalyticsBuilderId: (args) => request("GET", "/analytics/builder/{id}", { hasBody: false }, args),
     },
+    "artistGate": {
+      // GET /artist-gate — rank: any-builder — GET /artist-gate
+      getArtistGate: (args) => request("GET", "/artist-gate", { hasBody: false }, args),
+    },
     "auditLog": {
       // GET /audit-log — rank: metic+archon — GET /audit-log
       getAuditLog: (args) => request("GET", "/audit-log", { hasBody: false }, args),

package/modules/lifecycle/cascade.js

@@ -73,9 +73,13 @@
 //               'engineer'). This is the whole point of the mechanism: the
 //               discipline of the generated task is not the discipline of the
 //               ship that caused it.
-//   when(task)  a predicate over the shipped task row. Must be pure and total —
-//               a throw is caught and treated as "no match", because a broken
-//               predicate must not stop the other rules.
+//   when(task, ctx)  a predicate over the shipped task row and the run CONTEXT.
+//               Must be pure and total — a throw is caught and treated as "no
+//               match", because a broken predicate must not stop the other
+//               rules. `ctx` is the per-run policy the runner resolved (today:
+//               `{ artistGate }`), injected rather than read, so this file keeps
+//               its "importable with nothing behind it" property. A rule that
+//               does not care about policy simply ignores the second argument.
 //   title(task) / body(task)  the generated task's title and description.
 //   kind        optional task kind; must be one the classifier knows
 //               (task-classifier.VALID_KINDS). Defaults to 'unclassified' —
@@ -151,7 +155,14 @@ const CASCADES = Object.freeze([
     kind: 'unclassified',
     // The anti-recursion guard (source !== CASCADE_SOURCE) is FIRST so a
     // cascade-generated task is rejected before any other test runs.
-    when: (t) => t.source !== CASCADE_SOURCE && hasCopyOrVisualWork(t),
+    //
+    // The project's artist_gate at 'off' means "not generated" (ADR 0241 §2's
+    // table, task 1003575) — the one level at which this rule files nothing. It
+    // is read from ctx, never from branding, so the predicate stays pure; an
+    // absent ctx (a caller that resolved no policy) files, because the gate's
+    // default is 'strict' and silence must not be read as an opt-out.
+    when: (t, ctx) => (ctx || {}).artistGate !== 'off'
+      && t.source !== CASCADE_SOURCE && hasCopyOrVisualWork(t),
     title: (t) => `Artist review: the copy and visuals that shipped in task ${t.id}`,
     body: artistReviewBody,
   }),
@@ -201,13 +212,13 @@ function validateCascades(rules = CASCADES) {
 // ---------------------------------------------------------------------------
 
 // The task rows a shipped task cascades into. Pure: no database, no clock, no
-// side effect — hand it a task-shaped object and a rule table and it returns
-// the specs that would be filed.
+// side effect — hand it a task-shaped object, a rule table and the run's policy
+// context and it returns the specs that would be filed.
 //
 // A rule whose `when` THROWS is treated as no-match and reported in `errors`,
 // never propagated: one broken predicate must not cost the other rules their
 // tasks, and it certainly must not reach the ship.
-function cascadesFor(task, rules = CASCADES) {
+function cascadesFor(task, rules = CASCADES, ctx = {}) {
   const matched = [];
   const errors = [];
   if (!task || task.id == null) return { matched, errors: ['no task'] };
@@ -216,7 +227,7 @@ function cascadesFor(task, rules = CASCADES) {
     if (shape.length) { errors.push(`cascade "${rule && rule.key}": ${shape.join('; ')}`); continue; }
     let hit = false;
     try {
-      hit = rule.when(task) === true;
+      hit = rule.when(task, ctx) === true;
     } catch (e) {
       errors.push(`cascade "${rule.key}": when() threw (${e && e.message}) — treated as no match`);
       continue;
@@ -281,6 +292,14 @@ function cascadeTaskSpec(rule, task) {
 //                                       goal_id / version_id / discipline)
 //   deps.findTaskBySourceRef({...})  -> an existing row or null
 //   deps.createTask(spec)            -> the created row
+//   deps.artistGateMode()            -> 'off' | 'advisory' | 'strict' — the
+//                                       project's artist gate (ADR 0241). Injected
+//                                       so this file reads no branding pack; a
+//                                       reader that throws leaves the context key
+//                                       undefined, which FILES (the gate's own
+//                                       default is 'strict', and a policy read
+//                                       that failed must not silently behave like
+//                                       'off').
 //   deps.log                         -> optional { info, error }
 async function runCascadesForShip(shipped, deps = {}) {
   const report = { created: [], skipped: [], errors: [] };
@@ -292,7 +311,16 @@ async function runCascadesForShip(shipped, deps = {}) {
     const task = deps.getTask ? await deps.getTask(id) : null;
     if (!task) { report.errors.push(`cascade: task ${id} not readable after ship`); return report; }
 
-    const { matched, errors } = cascadesFor(task, deps.rules || CASCADES);
+    // The per-run policy context. Resolved once, outside the rule loop, and
+    // never allowed to cost the run: a reader that throws is reported and leaves
+    // the key undefined rather than suppressing every rule that consults it.
+    const ctx = {};
+    if (typeof deps.artistGateMode === 'function') {
+      try { ctx.artistGate = deps.artistGateMode(); }
+      catch (e) { report.errors.push(`cascade: artistGateMode() threw (${e && e.message}) — policy unread`); }
+    }
+
+    const { matched, errors } = cascadesFor(task, deps.rules || CASCADES, ctx);
     report.errors.push(...errors);
 
     for (const { rule, spec } of matched) {

package/modules/lifecycle/db-claims.js

@@ -94,8 +94,11 @@ async function claimTask({ taskId, builderId, worktreeName, headSha, creatorSess
 
     // ADR 0120 part 3: the needs_rebase claim gate. A builder who owes a rebase
     // on any un-landed confirmed task (flagged by the reconciler, part 2) is
-    // blocked from taking on NEW work until they LAND it (rebase the branch +
-    // re-ship → reconciler) or RELEASE it — both clear the flag. Their
+    // blocked from taking on NEW work until they LAND it (`git merge origin/main`
+    // + re-ship — task 1002788: MERGE, never rebase, because the branch is already
+    // published and server-mediated publish is append-only, so rewriting it makes
+    // the task permanently un-landable while the gate keeps their queue shut)
+    // or RELEASE it — both clear the flag. Their
     // already-active claims are untouched (we only refuse fresh claims, never
     // freeze in-flight work). Since the reward now lands only on ship (part 1),
     // the builder is motivated to clear it; since it gates their queue, they

package/modules/lifecycle/db-goals.js

@@ -527,9 +527,10 @@ async function achieveGoalIfComplete({ goalId }, deps = {}) {
 // precedent). membershipKind defaults to 'member'.
 
 // THE COLUMN IS `membership_kind` (task 1003013, ADR 0177 — ADR 0174 reserves the
-// other word for the three crafts). The legacy column still EXISTS for one
-// release, kept in lockstep by core_220's trigger so a rolled-back deploy still
-// reads a schema it understands: write the new name only, step 2 drops the old.
+// other word for the three crafts). The rename is COMPLETE: core_240 (task
+// 1003089) dropped the legacy column and its lockstep trigger, and the new column
+// now carries NOT NULL + DEFAULT 'member' itself rather than resting on that
+// trigger. There is no second spelling left to keep in step.
 //
 // ARRIVING AS A MEMBER CLOSES ANY PENDING ASK (task 1002888 / idea 1000688).
 // The membership write used to be a bare upsert that never looked at