@bongos/core 1.17.0

package/docs/adr/0096-require-reward-before-workable.md

@@ -0,0 +1,209 @@
+# ADR 0096 — Require a `credits_reward` (drachmae) value before a task is workable
+
+**Date:** 2026-06-28
+**Status:** Accepted
+**Track:** `internal` (GDS / economy + lifecycle)
+**Task:** [#1670](https://example.com/builders#/task/1670) (GDS-V4)
+
+## Context — the problem
+
+Every task carries a `credits_reward` integer — the in-world drachmae payout when it
+ships ([ADR 0023](<redacted>.md), [ADR 0054](<redacted>.md)).
+That column was created with `NOT NULL DEFAULT 0` (migration `003_pms.sql`). Nothing in
+the lifecycle ever required it to be set, so the default path was:
+
+> create a task (reward = 0) → promote it to `ready` → claim → ship → **pay 0 drachmae**.
+
+A task could travel the whole claim→ship→credit pipeline paying nothing. The credit
+ledger then records a real shipped task with a zero payout — the reward economy is
+silently unfunded for every task whose author never set a value. At the time of this
+change there were ~57 tasks sitting in `ready` with `credits_reward = 0`.
+
+The fix is to make a present, positive reward a **precondition for a task becoming
+workable** — without stranding any of the existing zero-reward work.
+
+## Decision — three enforcement points
+
+The reward requirement is enforced at the two transitions that make a task *workable*,
+plus the predicate that auto-promotes tasks:
+
+1. **Promote-to-ready (`POST /tasks/:id/promote`).** Refuses to flip a task to `ready`
+   when `credits_reward` is NULL or `<= 0`, returning `409 { error: 'REWARD_REQUIRED' }`
+   with an actionable message that *suggests* a value derived from `kind` + `est_minutes`
+   and names the `PATCH /tasks/:id` call to set it. (`modules/lifecycle/routes/tasks.js`.)
+
+2. **Auto-promote predicate (`task_is_fully_unblocked`, migration 177).** This SQL
+   predicate is the single condition shared by all three auto-promotion triggers
+   (`promote_dependents_on_ship` / `_criterion_satisfy` / `_goal_achieve`, migration 163).
+   It now requires `(reward_gate_exempt OR credits_reward > 0)` **in addition to** the
+   dependency-doneness check. A deps-shipped task with no reward therefore stays `backlog`
+   when its last dependency ships — it does not auto-promote until an author sets a reward.
+
+3. **Claim-time backstop (`db.claimTask`).** Refuses a claim on a 0/NULL-reward task with
+   the same `REWARD_REQUIRED` error (mapped to `409` in `modules/lifecycle/routes/claims.js`).
+   This catches the residual case where a row reached `ready` by some path other than the
+   promote route, or had its reward zeroed after promotion. It mirrors the existing
+   `DEPS_NOT_SHIPPED` claim backstop (second line of defence behind the promote gate).
+
+All three resolve through one shared pure helper, `db.rewardGateError(task, { grandfathered })`,
+so the route, the claim path, and the unit tests can never disagree (the
+`deriveRequiredRank` / `highestRank` precedent).
+
+## Grandfathering — never strand existing work
+
+The critical constraint: this change must **not** make any currently-claimable task
+unclaimable, and must **not** retro-demote any `ready` task to `backlog`. We grandfather
+explicitly with a dedicated flag rather than a fragile timestamp cutoff (`promoted_at` is
+not reliably stamped — `updateTaskStatus` doesn't set it):
+
+- Migration 177 adds `tasks.reward_gate_exempt boolean NOT NULL DEFAULT false` and sets it
+  `true` for **every task already at or past `ready`** (`status IN ('ready','active',
+  'completed','confirmed','shipped')`). Those ~57 zero-reward `ready` tasks — and any
+  in-flight work — are permanently exempt: `rewardGateError` returns `null` for them, so
+  the claim backstop lets them through.
+- **New** tasks default `reward_gate_exempt = false`, so the gate applies only to
+  transitions happening *after* this change.
+- The predicate change is **forward-only by construction**: the auto-promotion triggers
+  fire on later ship/satisfy/achieve events and only ever flip `backlog → ready`. They
+  never re-evaluate a row already in `ready`, so no demotion can occur. (And the exempt
+  rows would pass the predicate's reward clause anyway.)
+
+Net effect: existing claimable + in-flight work is untouched; the gate bites only on the
+next promotion or claim of an unrewarded task.
+
+## Anti-gaming — the reward stays author-set
+
+[ADR 0023](<redacted>.md) makes `credits_reward` an author-set,
+review-gated value on purpose (auto-deriving it from `est_minutes` would be trivially
+gameable — inflate the estimate, inflate the payout). This ADR preserves that stance:
+
+- We do **not** auto-derive or auto-apply `credits_reward`. The refusal MAY *suggest* a
+  value (`suggestCreditsReward` — ~1 drachma per estimated minute, weighted by a coarse
+  per-kind factor, floored at 5), but a human must confirm it via `PATCH /tasks/:id`.
+- Setting the reward is the existing `PATCH /tasks/:id` path — no new write surface. The
+  gate only requires the value to be *present and positive*, never that it match the
+  suggestion.
+
+## Coordination — backfilling the existing zero-reward tasks
+
+The grandfathered ~57 tasks remain claimable at 0 reward by design (so we don't strand
+them), but they still *should* be valued. That backfill is tracked separately as
+**<redacted>** (task 1672) — it walks the grandfathered
+zero-reward tasks and assigns each an author-set value. Once a task is backfilled to a
+positive reward it no longer depends on its exempt flag to be claimable. The
+`reward_gate_exempt` column can be retired in a later migration once the backfill is
+complete and no zero-reward `ready` tasks remain.
+
+## Consequences
+
+- No task created/promoted/claimed after this change can be worked while paying 0 drachmae.
+- Existing `ready` + in-flight zero-reward tasks stay fully workable (grandfathered).
+- The promote/claim refusals name the way forward (suggested value + the `PATCH` call),
+  matching the `TASK_NOT_READY` actionable-hint precedent ([#952](https://example.com/builders#/task/952)).
+- One new column (`reward_gate_exempt`), one `CREATE OR REPLACE` of an existing predicate,
+  no data loss; the migration is idempotent and a clean no-op on replay.
+
+---
+
+## Amendment — 2026-06-28 (task [#1673](https://example.com/builders#/task/1673)): AUTO-ASSIGN at the gate, don't BLOCK
+
+The original decision above made a missing reward **block** the two workable transitions
+(promote returned `409 REWARD_REQUIRED`; the claim backstop threw the same). In practice
+that turned a missing-value into a hard wall: a perfectly good task with a deps-met,
+ready-to-work footprint could not be promoted or claimed until someone hand-set a value
+first. That is friction the methodology doesn't want — the goal is "no task is worked for
+0 drachmae", not "stop work until a human types a number."
+
+**The shift: the gate now AUTO-ASSIGNS a fair, capped value and PROCEEDS.**
+
+- **Promote-to-ready (`POST /tasks/:id/promote`).** When `credits_reward` is 0/NULL it
+  assigns `suggestCreditsReward(task)` (persisted via `db.setCreditsReward`), then flips to
+  `ready` and returns `{ ok: true, assigned_credits_reward: N }`. No refusal. The shared
+  decision is `db.rewardGateAssignment(task)` (returns `{ assign: N }` or `null`).
+
+- **Claim (`db.claimTask`).** Same — if 0/NULL at claim time it assigns the capped
+  suggestion **inside the existing `FOR UPDATE` transaction**, so the assignment and the
+  claim commit atomically, then proceeds. This also gives the ~27 grandfathered
+  `reward_gate_exempt` zero-reward tasks a real payout the moment they're claimed.
+
+- **Auto-promote predicate (migration 178).** The reward clause migration 177 added to
+  `task_is_fully_unblocked` — `(reward_gate_exempt OR credits_reward > 0)` — is **reverted**:
+  the predicate returns to the migration-163 dependency-doneness check **only**. Auto-promotion
+  no longer blocks on reward, because claim-time auto-assign covers every task before any work
+  starts. A deps-shipped task auto-promotes `backlog → ready` even at 0 reward; it gets valued at claim.
+
+- **`reward_gate_exempt` is now inert.** Nothing reads it anymore (the gate auto-assigns
+  regardless of the flag). The column is left in place; a later migration may drop it once the
+  task-1672 backfill is complete (same retirement plan as the original "Coordination" section).
+
+### Anti-gaming — the cap + the audit (this reverses ADR 0023's strict author-set stance, narrowly)
+
+[ADR 0023](<redacted>.md) made `credits_reward` strictly
+author-set precisely because auto-deriving it from `est_minutes` is gameable (inflate the
+estimate → inflate the pay). Auto-assigning at the gate crosses that line — so two guards
+contain the blast radius:
+
+1. **CAP.** `suggestCreditsReward` is capped at `REWARD_SUGGESTION_CAP = 60` drachmae. The
+   formula stays modest (~1 drachma/estimated-minute, weighted by a coarse per-kind factor,
+   floored at 5), and the cap bounds how far an inflated estimate can push the *auto-assigned*
+   value. Anyone who genuinely needs more sets `credits_reward` by hand via `PATCH /tasks/:id`
+   — the ADR 0023 author-set, review-gated path is untouched for explicit values.
+
+2. **AUDIT.** Every auto-assignment logs a `[reward-gate] AUTO-ASSIGN task N credits_reward
+   -> V` line (with the actor: `[promote]` or `[claim by builder B]`), and the `credits_reward`
+   change is itself visible on the task. The assignment is never silent.
+
+3. **The PRIMARY pay driver is unchanged and ungameable.** Builder earnings are driven by the
+   **cost-plus session reward** ([ADR 0054](<redacted>.md)) —
+   `round(true_cost_usd × 1.20)` per shipped session, derived from real token cost, not from
+   any author-set or auto-derived per-task number. The per-task `credits_reward` is a modest,
+   capped floor on top of that; capping it keeps the gameable lever small.
+
+### Net effect
+
+No task is ever worked for 0 drachmae **and** no promote/claim is ever blocked for a missing
+value. The friction is gone; the economy stays funded; the gameable surface is a capped,
+audited floor sitting under the ungameable cost-plus primary reward.
+
+## Amendment — 2026-06-28 (task [#1677](https://example.com/builders#/task/1677)): assign at CREATION — the PRIMARY point; promote/claim is the BACKSTOP
+
+The first amendment moved assignment to the two *workable* transitions (promote, claim). That
+still left a window: a freshly **created** `backlog` task read `credits_reward = 0` until it was
+later promoted or claimed. The owner's intent is stronger — **every task should carry a fair
+drachmae value from the moment it is born**, so anyone reading the backlog sees real numbers, not
+zeros waiting to be filled in.
+
+**The shift: creation is now the PRIMARY assignment point; promote/claim becomes the backstop.**
+
+- **`db.createTask` (the lowest create layer).** When the caller supplies no positive
+  `credits_reward` (null/undefined/0), `createTask` auto-assigns `suggestCreditsReward({ kind,
+  est_minutes })` — the same capped (`<= REWARD_SUGGESTION_CAP`) helper — **before the INSERT**, so
+  the row is born with a value. An explicitly-provided **positive** value is respected, never
+  overridden (the author-set path stays intact). Putting the default here means **every**
+  create-vector inherits creation-time assignment automatically: `POST /tasks`, idea-promotion,
+  newcomer-restock, the Discord `#bugs → task` flow, and any seed script — all call `createTask`.
+
+- **`POST /tasks` route.** Its `credits_reward: body.credits_reward ?? 0` default flows a 0/absent
+  value into `createTask` as "unset" (so the creation default fires), and the `201` response now
+  surfaces the assigned `credits_reward` so the creator immediately sees the value the task was
+  born with.
+
+- **Audit.** `createTask` logs `[reward-gate] AUTO-ASSIGN task N credits_reward -> V (cap …)
+  [creation]` on each creation-time fill; the visible `credits_reward` on the row is the other half
+  of the trail.
+
+- **The promote/claim auto-assign (the first amendment) is KEPT as a BACKSTOP.** It now fires
+  rarely — new tasks already carry a value — but it still covers any legacy row created before this
+  change, or any edge path that somehow births a 0-reward task. Defence in depth: creation is the
+  primary point, promote/claim the safety net.
+
+The **cap + anti-gaming reasoning is unchanged** — the same `REWARD_SUGGESTION_CAP` bounds the
+auto-assigned floor, and the ungameable cost-plus session reward ([ADR 0054](<redacted>.md))
+remains the **primary** pay driver. This per-task value stays a modest, capped, audited floor; it
+just now lands at birth instead of at first-work.
+
+### Net effect (post-1677)
+
+Every task is born with a fair, capped drachmae value. The backlog never shows a placeholder zero;
+promote/claim no longer carries the assignment weight (it's a backstop); the economy stays funded
+end-to-end with the same anti-gaming ceiling.

package/docs/adr/0097-one-active-claim-per-session-and-worktree-binding.md

@@ -0,0 +1,46 @@
+# ADR 0097 — One active claim per session + a claim binds to a dedicated worktree
+
+**Date:** 2026-06-29
+**Status:** Accepted
+**Track:** `internal` (development system / lifecycle)
+**Task:** [#1642](https://example.com/builders#/task/1642) (GDS-V4)
+**Amends:** [ADR 0049](<redacted>.md) (the parallel-safety contract). 0049 fixed *cross-claim* parallel safety (two claims colliding); this adds the missing *within-session* invariant.
+
+## Context — the commingled-ship hole
+
+ADR 0049 made cross-claim safety honest: `git merge` is the authoritative collision detector for interactive builders, and `uniq_active_claim_per_task` guarantees two sessions can't both claim the same task. But it left one invariant unstated, and a real failure mode followed from it.
+
+A single Claude Code session works inside **one git worktree**, and that worktree owns **one branch**. If a builder claims a second task from the *same* worktree, both tasks' commits land on that one branch. `/builder-ship` publishes the whole branch — so shipping the first task drags the second task's (unfinished, ungraded) commits along with it. The ship is *commingled*: two tasks' work ride out under one task's ship, the grader reads a diff that mixes scopes, and the second task's ledger is now a lie.
+
+The only pre-existing "one claim" guard was `gateNewcomerClaim`: **Xenos-only**, **builder-scoped**, and **fail-open**. It kept a brand-new builder focused, but did nothing for a Metic/Archon (or even a graduated Thetes) running two claims from one worktree, and it keyed on the builder, not the worktree — so it couldn't express "one claim *per worktree*" at all.
+
+## Decision
+
+Two new rules, both at the lifecycle layer:
+
+### 1. One active claim per session
+
+`POST /api/gds/claims` refuses a new claim when the **same `creator_session_id`** already holds an active claim, returning `409 session_already_has_active_claim` whose body names the in-flight task (`active_task_id` + `active_task_title`) and the remedy. This generalizes `gateNewcomerClaim` from Xenos-only to **all ranks** and from builder-scoped to **session-scoped**.
+
+- **Session-scoped, NOT builder-scoped — the load-bearing choice.** A builder legitimately runs many sessions in parallel, each in its own worktree with its own single claim (the `feedback_parallel_sessions_not_anomaly` memory; one human builder, many sessions, is the *norm* at current scale). Keying on the builder would break that norm — it would cap a builder at one claim across all their worktrees. Keying on `creator_session_id` (already on the claim row, set per-CLI-session) caps each *worktree* at one claim, which is exactly the branch-isolation invariant we need and nothing more.
+- **Fail-CLOSED.** Unlike `gateNewcomerClaim` (fail-open — onboarding plumbing must never brick a claim), this is a *correctness* guard against commingled ships. If the session-active-claim lookup throws, the route REFUSES (`409 session_claim_check_failed`) rather than silently allowing a second claim through. The deliberate asymmetry: a flaky onboarding read should not block work, but a flaky concurrency read must not let a commingling claim slip past.
+- **NULL-session handling.** A web claim (`bind_session=false`, [#616](https://example.com/builders#/task/616)) stores `creator_session_id = NULL` and is adoptable by any of the builder's CLI sessions. The guard **skips NULL sessions**: an incoming NULL-session claim is allowed (there is nothing to scope to), and a pile of existing NULL-session web claims never counts against any CLI session (the DB lookup filters to the same non-null session, and the pure decision double-checks `creator_session_id != null`). So web-claim-then-ship-from-any-terminal keeps working untouched.
+- **The decision is a pure, exported function.** `shouldRefuseSessionClaim({ activeClaimsForSession, creatorSessionId })` lives in `modules/lifecycle/routes/claims.js` and is unit-tested DB-free (`tests/one_active_claim_per_session.mjs`). The route middleware (`gateOneActiveClaimPerSession`) is thin: resolve the session, look up its active claims, call the pure fn, translate refuse→409.
+
+### 2. A claim binds to a dedicated worktree
+
+The default claim flow (`.claude/skills/builder-claim/SKILL.md`) ensures the task runs in its **own** worktree (e.g. `EnterWorktree task-N`) so a builder never reuses a worktree that already owns a claim. This is the harness's job — the GDS cannot create worktrees — so it is enforced as skill guidance plus the server guard above: if the harness reuses a busy worktree, the server refusal is the backstop, and the documented remedy is a fresh worktree/session.
+
+### DB defence-in-depth
+
+`migrations/<redacted>.sql` adds a **partial unique index** `uniq_active_claim_per_session ON claims (creator_session_id) WHERE released_at IS NULL AND creator_session_id IS NOT NULL`.
+
+- **Predicate divergence from the task spec, on purpose.** The spec cited `WHERE status='active'`, but `claims` has **no `status` column** — "active" is the table's `released_at IS NULL` convention (the row's lifecycle status lives on `tasks`). The index uses the real column.
+- **Migration safety.** A unique index *fails to create* if existing rows already violate it, which would block deploy. The migration first heals any current violation (keep the earliest active bound claim per session, close the rest — the same shape as migration 174), so the `CREATE` always succeeds; it is idempotent. The **app-layer guard is authoritative**; the index is belt-and-braces and must not break deploy.
+
+## Consequences
+
+- A session can hold at most one active claim — commingled ships are structurally prevented, not just discouraged.
+- The many-sessions-per-builder norm (ADR 0049's `feedback_parallel_sessions_not_anomaly`) is preserved exactly: each worktree/session still gets its own claim.
+- Web claims (NULL session) are unaffected — claim-in-browser, ship-from-any-terminal still works.
+- This composes with, and does not alter, ADR 0049's split cross-claim contract: the per-task index, the advisory `touches[]` warning, and the autonomous-runner footprint gate are all untouched. This ADR only adds the within-session invariant 0049 left implicit.

package/docs/adr/0097-retroactive-reward-backfill.md

@@ -0,0 +1,124 @@
+# ADR 0097 — Retroactive drachmae backfill for shipped 0-reward tasks
+
+- **Date:** 2026-06-28
+- **Status:** Accepted
+- **Track:** `internal` (GDS / economy)
+- **Task:** [#1672](https://example.com/builders#/task/1672)
+- **Relates to:** [ADR 0023](<redacted>.md) (per-task kind multipliers), [ADR 0054](<redacted>.md) (cost-plus session reward)
+
+## Context — the gap
+
+A task's `credits_reward` column **defaults to 0**. The per-task ship credit is
+minted by `modules/economy/credits.js insertMultipliedConfirmCredit`, which
+computes `applyKindMultiplier(credits_reward, kind)` — so a task that shipped
+with `credits_reward = 0` (or NULL) paid `0 × multiplier = 0` drachmae. Many
+early ships, and most dev-box / CI agent ships, never had a fair per-task reward
+set, so the builders who did real, shipped work earned nothing for it on the
+per-task stream.
+
+There are **two reward streams** a builder accrues to `builders.total_credits`:
+
+1. **Per-task** — `reason='task.confirmed'`, the kind-multiplied `credits_reward`
+   ([ADR 0023](<redacted>.md)). This is the stream
+   that paid 0 for the affected tasks.
+2. **Cost-plus session** — `reason='session.token_reward'`,
+   `round(true_cost_usd × 1.20)` per shipped session ([ADR 0054](<redacted>.md)).
+   This was supposed to backstop the per-task gap, but it pays **~0 for dev-box /
+   CI agent ships**: those sessions upload no priced model usage, so
+   `priceModelUsage` returns ~$0 and the reward rounds to 0. So for exactly the
+   ships that missed the per-task reward, the cost-plus stream *also* paid nothing.
+
+The net effect: a real backlog of shipped work that minted no drachmae for its
+builders. This ADR records the decision (and the tool) to remediate that **once,
+fairly, and safely** — with an Archon authorizing the amounts.
+
+## Decision
+
+Ship a **one-time backfill SCRIPT** — `scripts/gds/backfill-task-rewards.js` —
+that lets an Archon retroactively mint a fair, reviewed per-task reward for
+shipped 0-reward tasks. The script is the deliverable; the **live run is a
+separate, deliberate Archon action**, out of scope for the shipping session.
+
+### The two reward streams + the netting rule
+
+Backfill must not **double-pay**. For each builder, the script:
+
+1. Computes the **would-be per-task total**: for each of that builder's shipped
+   0-reward tasks, `applyKindMultiplier(reviewedRaw, kind).effective` — i.e. the
+   exact amount the per-task stream *would* have paid had a fair `credits_reward`
+   been set. The "reviewed raw" value is a per-task input from an Archon-reviewed
+   mapping (`--rewards <file.json>`), **not** an auto-formula from `estimate`
+   (re-deriving from `estimate` would just reproduce the un-reviewed numbers that
+   caused the gap).
+2. Sums what the **cost-plus stream already paid** that builder
+   (`SUM(delta) WHERE reason='session.token_reward'`).
+3. Mints only the **net**: `max(0, wouldBeTotal − costPlusAlreadyPaid)`. Floored
+   at 0 — if the cost-plus stream over-paid for some sessions, backfill never
+   claws back; it only ever **tops up** toward the fair task total.
+
+The dry-run report shows, per builder: tasks, would-be per-task total, cost-plus
+already paid, and the net to mint — so the Archon can **see whether the cost-plus
+stream actually fired** (the audit confirms it pays ~0 for dev-box/CI ships) before
+authorizing anything.
+
+> **Why net at the builder level.** `session.token_reward` rows are session-level
+> (`task_id` is NULL), so there is no clean per-task join back to a session reward.
+> The honest audit question is "did the cost-plus stream already compensate this
+> builder for the work these tasks represent" — a builder-level question — so the
+> netting is builder-level.
+
+### Idempotency key
+
+Every minted row is keyed on **`(task_id, reason='reward.backfill')`**. The apply
+path SELECTs existing keys first (and re-checks inside the write transaction) and
+skips any task already backfilled — so a re-run can never double-mint. This
+mirrors the existing idempotency guards in `maybeAwardIdeaPromotionBonus`
+(`(task_id, reason='idea_promotion_bonus')`) and `awardNetNegativeBonus`
+(`(task_id, reason='ship.net_negative')`). The inline `description` records the
+math (`"backfill: 40c × 1.2 = 48c (bug) [reward.backfill task #N]"`), matching the
+self-describing convention of the other credit_log writers (migration 031).
+
+### Safety model — dry-run first, Archon-gated, never on import
+
+- **Dry-run by default.** With no flags the script prints the full plan + grand
+  total and **writes nothing**. The whole reason a tool that mints currency is
+  safe to ship inert.
+- **`--apply` requires ALL of:** the explicit `--apply` flag; an **Archon rank**
+  verified server-side via `GET /api/gds/me` (the script refuses for any other
+  rank — markdown/local edits cannot grant authority, [ADR 0016](<redacted>.md));
+  and an **interactive y/N confirmation** at the terminal.
+- **Never acts on import/require.** All work is inside `main()`, gated on
+  `require.main === module`. Importing the file (the unit test does) touches no DB
+  and mints nothing.
+- **Graceful with no DB.** On a builder box with no prod credentials, `--help`
+  and the dry-run report a clean message and exit non-zero — no stack trace, no
+  mint.
+- **One transaction.** The apply path inserts all credit_log rows and updates
+  `builders.total_credits` in a single `BEGIN…COMMIT`, rolling back on any error.
+
+## NOT a migration
+
+This is a **one-time, OTB-specific remediation**, deliberately **not** a
+`migrations/` file. Migrations run on **every instance**, including
+`cloudbongos.com` — and a fresh instance has no 0-reward backlog to fix. Putting
+this in `migrations/` would re-run a currency-minting operation against every new
+instance's empty ledger, which is exactly wrong. It lives under `scripts/gds/` as
+an Archon-invoked tool, like the other backfill scripts (`backfill-cost.js`,
+`backfill-sessions.js`).
+
+## Consequences
+
+- An Archon can fairly compensate the 0-reward backlog with a reviewed,
+  netted, auditable, idempotent run.
+- The fix is gated behind rank + interactive confirmation + dry-run-first, so it
+  cannot mint by accident or from a non-Archon machine.
+- The **forward fix** (stop tasks shipping with `credits_reward = 0`) is a
+  separate concern — this ADR remediates the existing backlog only; it does not
+  change the default or the ship-time reward path.
+
+## Tests
+
+`tests/backfill_task_rewards.mjs` unit-tests the **pure logic only** (no DB):
+the idempotency-key construction, the kind-multiplied per-task would-be amounts
+(reusing the real `applyKindMultiplier`), the cost-plus netting (floored at 0),
+and the per-builder plan assembly (already-backfilled exclusion, 0-mapping skip).

package/docs/adr/0098-public-mirror-publish-manifest.md

@@ -0,0 +1,92 @@
+# ADR 0098 — The Cloud Bongos public-mirror publish manifest (the R71 carve-out)
+
+- **Status:** Accepted
+- **Date:** 2026-06-30
+- **Track:** internal
+- **Task:** [#1210](https://example.com/builders#/task/1210) (V4.R71) — the publishable-subtree carve-out + the public mirror repo.
+- **Builds on:** [ADR 0065](<redacted>.md) §4 (the AGPL decision + the prose publish boundary this task makes executable), [ADR 0062](<redacted>.md) §1 (the portable-core / host-instance / feature-module cut-line), [ADR 0043](<redacted>.md) (`PROTECTED_GLOBS`), [ADR 0058](<redacted>.md) (the gate-review "no allow-by-omission" doctrine this borrows).
+- **Gates:** [#1211](https://example.com/builders#/task/1211) (R72 — the delayed export pipeline, which *consumes* this manifest) and [#1212](https://example.com/builders#/task/1212) (R73 — the lineage + no-leak proof, which *asserts against* it).
+- **Referenced by:** [ADR 0108](<redacted>.md) §2 — `isPublishable()` stays the single definition of "the core," now read as "the core npm package's contents," not just the mirror/package-core tarball subtree.
+
+## Context
+
+[ADR 0065](<redacted>.md) §4 defined the public-mirror boundary in **prose**: publish the portable methodology core + the platform + the neutral (customer-0) branding + sanitized docs; never publish secrets, instance identity literals, prod infra, or the customer-1 (Example) game/art content. That prose is the policy. But R72 (the generated, redacted, 6-month-delayed export) and R73 (the no-leak proof) need the boundary as an **executable, drift-proof artifact** — not a paragraph a future builder has to re-interpret per file.
+
+The task instructs reusing the existing `PROTECTED_GLOBS` / `SENSITIVE_DOC_GLOBS` inventories. The catch: **those inventories are necessary but not sufficient, and `PROTECTED_GLOBS` is emphatically not a denylist.**
+
+- `PROTECTED_GLOBS` (`src/bongos/permission-path-check.js`) is *write*-protection over the trust/pipeline/infra code. ADR 0065 §4 **publishes** most of it — the rank/permission machinery, the grader, and the ship pipeline **are** the open-source methodology. Only its *topology* subset (prod infra, deploy, CI, the local gate hooks) is excluded.
+- `SENSITIVE_DOC_GLOBS` (`scripts/gds/search-ingest-md.js`) is *read*-gating; its security/audit corpus is excluded, but `docs/canonical-permissions.md` and the trust-boundary ADRs are methodology and publish (sanitized).
+- Neither list mentions the **game, the art pipeline, or the instance's identity config** — which are the single largest exclusions, excluded for content/copyright/instance reasons, not trust reasons. (The art subtree additionally carries the 83 ripped Pokémon FireRed reference maps in `modules/art-pipeline/references/` — an independent, hard copyright reason never to ship it under an AGPL mirror.)
+
+## Decision
+
+### 1. One machine-readable manifest is the source of truth
+
+The boundary is `scripts/gds/publish-manifest.js`, exporting `isPublishable(repoRelativePath) → boolean` (plus `partitionPaths`, the lists, and a `--list` CLI). R72 imports `isPublishable` to select what it exports; R73 asserts no path it forbids ever reached the mirror. The exact globs live **only** in that module — this ADR documents the *model* and *categories* so the two can't drift (the gen-repo-map pattern). Run `node scripts/gds/publish-manifest.js --list` to print the current boundary.
+
+### 2. Default-deny, two layers
+
+```
+isPublishable(p)  ==  matchesDeny(p) ? false : matchesAllow(p)
+```
+
+The **allowlist is the primary gate**: a path in no allowlisted subtree is silently *not* published, so a new, unclassified surface never leaks by omission. The **denylist is a hard override applied first** (defense-in-depth): even a path inside an allowlisted subtree is dropped if denied — e.g. `scripts/` is broadly allowed but `scripts/deploy/` is denied and wins.
+
+### 3. Reuse the trust inventories; never re-type them
+
+The manifest `require()`s `PROTECTED_GLOBS`, `HARD_FLOOR_GLOBS`, and `SENSITIVE_DOC_GLOBS` from their homes — never copies them (the gate-review.js "imported, never hand-retyped" rule). It **partitions** `PROTECTED_GLOBS` into a small `PROTECTED_TOPOLOGY_EXCLUDE` list (infra, deploy, CI, `.husky/`, the local `.claude/hooks/` + `.claude/settings.json`) versus the remainder, which publishes as the methodology core. `tests/publish_manifest.mjs` asserts the partition is consistent with the live inventory — every topology-exclude entry is a verbatim `PROTECTED_GLOB`, and every non-topology protected surface stays publishable. If `PROTECTED_GLOBS` changes incompatibly, the test fails and the carve-out must be re-decided. **No allow-by-omission**, applied to publishing.
+
+### 4. The boundary, by category
+
+The enforced globs are in the manifest; this is the rationale-bearing summary.
+
+| Publishable (allowlist) | Why |
+|---|---|
+| `src/` (engine + GDS), `scripts/`, `bin/`, `server.js` | the platform + the instance-model engine (game/art residue denied below) |
+| `migrations/`, `tests/` | the build system's own schema + tests |
+| platform-core `modules/`: lifecycle, grading, economy, memory, onboarding, ideas, builder-settings, sessions, autonomy, security, hall-ui, status-ui, dev-box, discord | the engine; instance flavor comes from the brand pack, not the code |
+| `config/*.neutral.json`, `config/design-tokens.schema.json` | the customer-0 neutral starters + the generic contract schema |
+| `CLAUDE.md`, `README`, `LICENSE`, `GOVERNANCE`, `CONTRIBUTING`, `CODE_OF_CONDUCT` | the portable methodology core + governance (R69/R70) |
+| `docs/adr/`, `docs/recipes/`, `docs/design/`, `docs/architecture.md`, `docs/*-contract.md`, `docs/canonical-permissions.md`, `docs/handoff-template.md`, `docs/project-context.template.md` | sanitized methodology docs + the neutral project-context scaffold |
+| `.claude/skills/` | the methodology slash-commands (hooks + settings denied) |
+| Docker + repo scaffolding, `.env.local.example` | self-host scaffolding; examples only |
+
+| Permanently excluded (denylist) | Why |
+|---|---|
+| `modules/game/`, `public/`, `src/world/`, `src/rooms/`, `src/preview-server.js` | customer-1 game content |
+| `modules/art-pipeline/`, `modules/character-anim/`, `art/`, `scripts/art/`, `scripts/tile-*.js` | OTB art + **the ripped Pokémon FireRed reference corpus (copyright)** |
+| `config/branding.json`, `config/modules.json`, `config/deploy.json`, `config/devbox-app.json`, `config/hierarchy.json`, `CODEOWNERS` | this host's identity + ops config (the `*.neutral.*` twins publish) |
+| `docs/project-context.md`, `docs/lore/`, `docs/TRACKS.md`, `docs/session-logs/`, `docs/handoffs/`, `docs/reviews/`, `docs/discord/`, `blockers/`, `limitations/`, `generative-ideas.md` | instance build history + roadmap prose |
+| `docs/security/`, `docs/audits/`, `docs/security-baseline.md`, `docs/routes-permissions.md` | the security/audit corpus (read-gated; attack-surface intel) |
+| `infra/`, `scripts/deploy/`, `.github/`, `.husky/`, `.claude/hooks/`, `.claude/settings.json` | prod topology, deploy, CI, local gate automation (the topology subset of `PROTECTED_GLOBS`) |
+| `.env`, `.env.local`, `.claude/settings.local.json`, `.claude/worktrees/` | secrets + throwaway local state |
+
+### 5. Deferred — excluded by default until R72 / the owner decides
+
+Default-deny keeps these safely out of the mirror until a deliberate call is made; none is needed for the boundary to be correct:
+
+- **The customer-0 brand pack** — `brand/cloud-bongos/` (the Bongo Buddha mascot + sky-whale art) and `config/branding.cloudbongos.json`. ADR 0065 §4 publishes `config/branding.neutral.json` as the vanilla identity; whether the Cloud Bongos *visual* brand also ships (vs. a neutral install) is a separate owner decision (large binary art + a trademark-vs-AGPL question).
+- **The desktop clients** — `bongos-app/` and `devbox-app/` source (their installers already publish off-repo to a separate releases repo).
+- **`modules/demo/`** — a sample module that could ship as an example.
+
+### 6. Granularity — subtree boundary now, file-level redaction in R72
+
+This task draws the boundary at the **subtree** level. The *generated* export (R72) does the file-level work ADR 0065 §4 assigns it: redacting instance literals (droplet IP, `*.example.com`, the owner login, OAuth/repo bindings) from *inside* published files, and relocating module-owned tests. Known file-level follow-ups for R72: the game/art tests still under top-level `tests/` should travel with their (excluded) modules, and `.devcontainer/` + `public-landing/` need literal-redaction. R73's no-leak + lineage proof is the backstop that catches any straggler.
+
+### 7. The mirror repo
+
+The public mirror is created **empty** — a `README` plus the AGPL-3.0 `LICENSE` — and is populated only by R72's delayed, redacted export. It does **not** carry source until R73 proves no-leak. The owner created it as **`cloudbongos/bongos`** in a dedicated `cloudbongos` GitHub org — brand-named (not `example-`-prefixed like the status/devbox off-repo mirrors, and not the pre-rename `medusa`) — **private for now**, to be flipped public once R73's no-leak proof lands. It is seeded with the README + the AGPL-3.0 `LICENSE` and nothing else.
+
+## Alternatives considered (rejected)
+
+- **A prose-only carve-out** (just this doc, no manifest). Satisfies the literal "done when" but forces R72 to re-derive globs from prose and gives R73 nothing to assert against. The whole value of reusing `PROTECTED_GLOBS` is an executable boundary. Rejected.
+- **Dump `PROTECTED_GLOBS` into the denylist.** Wrong: it would exclude the rank/permission/ship machinery that ADR 0065 §4 explicitly publishes as the methodology. The partition (topology-excluded vs methodology-published) is the necessary nuance. Rejected.
+- **Denylist-first (publish everything except a blocklist).** One forgotten entry leaks a secret or the game. A publish boundary must fail safe — default-deny. Rejected.
+- **A DB-stored manifest (hence the planning `needs_migration` flag).** The boundary is over *files* (globs), consumed by file-level tooling (R72/R73); there is no live state to store. No migration is needed — the reserved number goes unused.
+
+## Consequences
+
+- **R72 and R73 build against one executable artifact**, not a paragraph. R72 imports `isPublishable`; R73 asserts no denied path leaked + that private↔public lineage stays consistent.
+- **The carve-out cannot silently drift** from the live trust inventory — `tests/publish_manifest.mjs` (in the unit gate) fails if the partition stops covering `PROTECTED_GLOBS`.
+- **No migration, no recurring cost.** This is a manifest + a doc + a test. The export pipeline's cost is evaluated under R72.
+- **The deferred items (§5) remain owner decisions.** They are excluded until then, so the mirror is never *less* safe for the deferral.

package/docs/adr/0099-delayed-redacted-mirror-export.md

@@ -0,0 +1,55 @@
+# ADR 0099 — The time-delayed, redacted public-mirror export pipeline (R72)
+
+- **Status:** Accepted — **retirement trigger fired 2026-07-03, deferred to the public-flip.** ADR 0103 §4 / R88 ([#1727](https://example.com/builders#/task/1727)) physically extracted the core into [github.com/example-owner/cloud-bongos](https://github.com/example-owner/cloud-bongos), the designated canonical public artifact. That repo is **private for now**, so this generated mirror **remains the public surface** and is **not retired**; retire (or repoint) it when `cloud-bongos` is flipped public.
+- **Date:** 2026-06-30
+- **Track:** internal
+- **Task:** [#1211](https://example.com/builders#/task/1211) (V4.R72) — the delayed export pipeline + source-level redaction. The XL long-pole of GDS-V4 criterion **C9** (Cloud Bongos is open, free, and protected from capture).
+- **Builds on:** [ADR 0098](<redacted>.md) (the publishable-subtree manifest this pipeline *consumes*), [ADR 0065](<redacted>.md) §4 (the publish boundary + the "redact instance literals" mandate), [ADR 0022](0022-secrets-policy.md) (the secret scrubber this reuses), [ADR 0029](<redacted>.md) / [#741](https://example.com/builders#/task/741) (the scoped-deploy-key mirror-push precedent).
+- **Gates:** [#1212](https://example.com/builders#/task/1212) (R73 — the lineage + no-leak proof) reuses this pipeline's `findLeaks` + `.mirror-provenance.json`.
+
+## Context
+
+ADR 0098 made the publish boundary executable (`scripts/gds/publish-manifest.js`, `isPublishable()`) but drew it at the **subtree** level and explicitly deferred to R72 the *file-level* work: publish a **~6-month-lagged snapshot** and **redact instance literals from inside published files**. The delay alone is not a security control — a droplet IP or domain committed seven months ago is exactly as sensitive today (§0098-6). Redaction is mandatory; the delay only shrinks the value of anything that ever slips.
+
+The redaction surface is real, not theoretical: at build time **23** published files named the droplet IPv4, **1** named its IPv6, **~230** named the instance domain, **~50** named the owner login. Subtree exclusion cannot catch literals *inside* files the platform legitimately publishes (e.g. `docs/architecture.md`).
+
+## Decision
+
+`scripts/public-mirror-export.js` (orchestration) + `scripts/gds/mirror-redact.js` (redaction library) + `.github/workflows/sync-public-mirror.yml` (schedule/transport). Seven decisions carry the weight:
+
+### 1. Snapshot, not history replay
+Each run picks the **newest commit whose committer date is ≥ 180 days old** (`pickSnapshotCommit`) and exports that single tree. The mirror accumulates one lagged snapshot commit per run — always ~6 months behind. Rejected replaying/redacting full history: far more code + risk (rewrite every commit) for no gain the "done-when" asks for. Matches the status-mirror precedent (sync current state as commits).
+
+### 2. The manifest is the only allow-list
+The exporter enumerates the snapshot tree (`git ls-tree -r`) and partitions it through `isPublishable()` (ADR 0098) — **no second list**. A file dropping out of the publishable set (or out of the lagged tree) disappears from the mirror on the next run.
+
+### 3. Two-layer redaction; the scrubber is reused, not re-typed
+Instance-literal redaction (`redactText`: domain+subdomains → `example.com`, repo/db/world/company token → `example`, owner login+aliases → `example-owner`, public IPv4 **and** IPv6 → `REDACTED_IP`; localhost/RFC-1918/RFC-5737/link-local/ULA kept) **then** the ADR-0022 secret scrubber as a backstop. To reuse the proven scrubber without importing the heavyweight `ship.js`, its pure functions were extracted to `modules/security/secret-scrub.js` (`ship.js` re-exports them; `tests/scrubber_corpus.mjs` unchanged). One copy of the secret shapes, two consumers — the "imported, never re-typed" doctrine.
+
+### 4. Self-leak invariant
+`mirror-redact.js` is itself published (under `scripts/`), so it contains **no instance literal**. Every literal is derived at runtime from `config/branding.json` (excluded from the mirror) plus caller-supplied extras. A vanilla clone redacts *its own* instance's literals with the same code. `tests/mirror_redact.mjs` reads branding at test time and asserts the redactor source contains none of this instance's literals.
+
+### 5. The no-leak gate is STRICTER than, and decoupled from, redaction
+`findLeaks` scans for each raw sensitive literal as a **case-insensitive substring** + the IPv4/IPv6 floors — it does **not** reuse the redaction regexes. This was learned the hard way: a first cut shared a word-bounded owner rule (`\bexample-owner\b`) for both redact and detect; it silently missed `example-owner` inside a regex-literal string (`(\bexample-owner\b)` in `audit-authorship.sh`) *and the detector was blind to the miss because it used the same pattern.* Redaction may be smart (avoid over-mangling); the gate must be dumb and strict (any raw literal anywhere = fail). Owner redaction is therefore **unbounded substring** (a login is unique enough), which also covers `/Users/<login>` home paths.
+
+### 6. Fail-closed, atomic
+All files are redacted **in memory**; `findLeaks` + `findSecretLeak` run over every redacted blob; **only if the entire set is clean** does the exporter touch the mirror filesystem (clear → write → commit → push). Any residual → publish nothing, exit non-zero, name the file+label (never the secret value), mirror untouched. Binary files are kept verbatim but still leak-scanned — a secret in a binary fails closed rather than corrupting it. An empty publishable set aborts (never wipes the mirror).
+
+### 7. Topology/owner extras live only in excluded files
+The exact droplet IP (`DROPLET_IP`) and owner aliases beyond the GitHub login (`OWNER_ALIASES`, e.g. the real-name/home-dir username) are sourced from env set in the **workflow yaml — which `.github/` excludes from the mirror** — so they never appear in a published file. The generic public-IP floors already catch the droplet IP without knowing it; the exact value is belt-and-suspenders so the gate can assert *that* value is gone.
+
+Transport reuses the ADR-0029/[#741](https://example.com/builders#/task/741) pattern: check out `cloudbongos/bongos` via a write-scoped deploy key (`PUBLIC_MIRROR_DEPLOY_KEY`), run the exporter with `--push`. Scheduled weekly + `workflow_dispatch`. `.mirror-provenance.json` (source SHA + committed-at + lag) is the lineage anchor R73 asserts against.
+
+## Consequences
+
+- **Dormant-until-mature = a safety property.** This repo's history is < 180 days old, so the pipeline is a **no-op** ("nothing to publish yet") until ~2026-11. That keeps the mirror empty until R73's independent no-leak proof lands and the owner flips the mirror public (ADR 0098 §7) — three layers of safety: the gate must pass to push at all; the repo stays private meanwhile; R73 must pass before the public flip.
+- **R73 is cheap to build.** It reuses `findLeaks` (assert no leak on the pushed tree) and `.mirror-provenance.json` (assert `source_commit` is an ancestor of private `main`; diff the mirror's `migrations/` numbering + enum values against that commit in the private repo).
+- **Owner setup is required before the first real publish** — the `PUBLIC_MIRROR_DEPLOY_KEY` secret (and optional `DROPLET_IP`). Tracked as a blocker; not urgent (dormant until history matures).
+- **Redaction over-redacts conservatively** (recall-first for topology): a coined instance token or a public IP that appears in generic prose is redacted. Acceptable — the mirror is meant to read as the neutral platform.
+
+## Alternatives considered (rejected)
+
+- **Delay-only, no redaction.** Fails the "does NOT scrub secrets" reality; a 7-month-old droplet IP still pins prod. Rejected.
+- **Share one regex set for redact + detect.** The blind-spot bug above: the gate can't catch what its own bounded rule missed. Rejected — the detector is a separate, stricter substring scan.
+- **TruffleHog as the only secret check.** Strong but network-dependent and verify-only (no transform); can't run in the exporter's own deterministic self-check or the unit tests. Kept the reusable in-process scrubber as the authoritative gate; TruffleHog may layer on later.
+- **Write then scan the mirror on disk.** A failed run would leave a dirty (unpushed) tree and risk a partial state. In-memory-then-write makes abort atomic. Rejected.

package/docs/adr/0100-two-repo-instance-model.md

@@ -0,0 +1,60 @@
+# ADR 0100 — Two-repo instance model: a project consumes Cloud Bongos as a versioned platform
+
+- **Status:** Accepted — **§§1–2 superseded by [ADR 0103](<redacted>.md)** (2026-07-02 owner review: core-first extraction, and Example *does* split rather than staying coupled). §3 (per-repo GDS) and §4 (conditional mirror) remain in force.
+- **Date:** 2026-07-01
+- **Track:** internal
+- **Task:** [#1607](https://example.com/builders#/task/1607) (BV1.R77) — the decision gate this ADR resolves.
+- **Decides:** the physical-repo topology that [ADR 0062](<redacted>.md) §10 left open and [ADR 0065](<redacted>.md) §4 answered for the *open-source* surface only.
+- **Builds on:** [ADR 0062](<redacted>.md) §1 (portable-core / host-instance / feature-module cut-line), [ADR 0064](<redacted>.md) (the Cloud Bongos rename), [ADR 0083](<redacted>.md) + [ADR 0093](<redacted>.md) (the module boundary + completed core-carve that make the split mechanical), [ADR 0098](<redacted>.md) (`isPublishable()` — the executable definition of "what is the core"), [ADR 0099](<redacted>.md) (the delayed mirror), [ADR 0015](<redacted>.md) (dependencies).
+- **Amends:** ADR 0062 §10 (chooses a physical topology it left open); ADR 0065 §4 (puts the generated mirror on a *conditional* retirement path — §4 below).
+- **Seeds:** GDS-V4 R84 → R85 → R86 (package the core → stand Mercury up on a pinned core → make `bongos upgrade` a real update channel).
+- **Amended by:** [ADR 0108](<redacted>.md) — resolves §1's mechanism-neutral "installs a pinned core + layers its own content on top" into configurable-root (the core as a `node_modules` dependency + an injected instance-root), not clone-and-layer.
+
+## Context
+
+ADR 0062 drew the **logical** cut-line — portable core / host instance / gated feature-modules — and deliberately left the **physical** repo topology open. cloudbongos.com ([#1206](https://example.com/builders#/task/1206)) then proved a second, non-game branded instance ships from the **same checkout** (a second process + second DB), so one repo was enough to prove the boundary. For the *open-source* release, ADR 0065 §4 chose a **generated one-way mirror** of the single private repo (delayed + redacted), explicitly *not* a fork.
+
+Two owner priorities now push past the single-repo model:
+
+- **Mercury** — Example' internal platform — should be "its own Cloud Bongos project": not code living inside the Off the Boats repo, and not merely another reskin of one checkout.
+- **Core improvements should flow to future projects** on each project's own schedule — an explicit "update to the latest platform" capability.
+
+The 2026-06-26 gap analysis (planning [#1604](https://example.com/builders#/task/1604)) found the logical boundary ~70% built and CI-enforced. Since then the load-bearing pieces landed: the bounded kernel ([#1570](https://example.com/builders#/task/1570)), the completed Config-B core-carve ([#1578](https://example.com/builders#/task/1578) + ADR 0093 — BONGOS-V1 C7 now satisfied), the hall-widget registry ([#1612](https://example.com/builders#/task/1612)), and core de-branding ([#1613](https://example.com/builders#/task/1613)). The boundary now holds, so a split is **mechanical, not a leap** — which is exactly the precondition this gate ([#1607](https://example.com/builders#/task/1607)) was told to wait for.
+
+The single-repo model's one genuine virtue is **free updates**: with one copy of the code, every instance gets platform fixes the moment they land, no upgrade step. Splitting removes that property and requires new machinery — packaging the core as an installable unit, an update-consumption channel (the `bongos upgrade` CLI is a stub today, [#1203](https://example.com/builders#/task/1203)), and a GDS-topology decision across repos.
+
+## Decision
+
+### 1. The destination is two repos — a project installs Cloud Bongos as a versioned platform dependency.
+
+A Cloud Bongos *instance* may be a **separate repository** that installs a **pinned version** of the Cloud Bongos **core** — the portable methodology + platform + neutral branding, exactly the subtree `isPublishable()` already defines (ADR 0098) — and layers its own project content, branding, and modules on top. This is the *physical* realization of ADR 0062 §1's *logical* cut-line. The single-checkout instance model (cloudbongos.com) is **not** deprecated: it stays a supported shape, and the cheaper one for a quick reskin.
+
+### 2. Sequenced — Mercury is the forcing function; do not design the channel up front.
+
+We build the smallest slice that stands **Mercury up as customer 2** in its own repo on a *pinned* core, and let that first real consumer's needs define the update channel, rather than guessing. Order: package the core (R84) → stand Mercury up on a pinned core (R85) → make `bongos upgrade` a real update-consumption channel, driven by Mercury's first core bump (R86).
+
+**Example is not split in this sequence.** It stays the single-checkout reference instance and keeps getting core updates for free, until a later, separate decision — moving a working product before the channel is proven on a greenfield one buys risk for no gain.
+
+### 3. GDS topology: per-repo.
+
+Each project runs its **own** GDS — its own database, tasks, builders, versions, and credits. Mercury's builders never see Cloud Bongos platform tasks and vice versa; that separation of work is the point. A single shared GDS across repos is **rejected**: it re-couples exactly what the split exists to separate, and widens the trust/identity surface (ADR 0062 §5, [ADR 0016](<redacted>.md)). The cost — more than one GDS database to operate — is accepted as the price of clean separation.
+
+### 4. The generated mirror (ADR 0065 §4) is retained now, retired conditionally.
+
+The delayed redacted mirror (ADR 0099) stays the public open-source surface **until** the Cloud Bongos core is physically extracted into its own repo. At that point the core repo becomes the canonical public artifact (secrets scrubbed, AGPL intact), and the mirror is re-evaluated for retirement or repointing — a decision deferred to *that* task, not made here. Until then ADR 0065 §4 is unchanged and in force. The AGPL-3.0 license, the non-profit/AI-first governance, and the 6-month delay window (ADR 0065 §§1–3) are **unaffected** by repo topology.
+
+## Alternatives considered (rejected)
+
+- **A — stay single-repo + generated mirror (the seeded plan).** Cheapest, already built, free instant updates. Rejected as the *destination*: it structurally cannot deliver <redacted> or an update channel — a project would have to live inside the OTB repo or be a reskin, and there is nothing to "update" while everything shares one checkout. **Retained** as the model for cheap reskins and as the interim public-release mechanism (§4).
+- **Two repos, one shared GDS.** Rejected — re-couples the work-tracking plane the split means to separate (§3).
+- **Split Example out immediately, alongside Mercury.** Rejected — moving a live product before the channel is proven adds risk for no gain; greenfield Mercury is the safer first consumer (§2).
+- **Fork / hand-maintained downstream.** Rejected in ADR 0065 §4 and still rejected — a divergent fork loses the free flow of core fixes without the discipline of a versioned dependency.
+
+## Consequences
+
+- **P4 and P5 become buildable.** The R84 → R85 → R86 spine delivers Mercury (P5) and the update channel (P4). R84 auto-promotes to `ready` when this gate ([#1607](https://example.com/builders#/task/1607)) ships (ADR 0015).
+- **A permanent per-project upgrade step** replaces free updates — the recurring cost the single-repo model avoided, now explicit and owned per project.
+- **A larger operational footprint** (more repos, CI, at least one more GDS database) — weighed against the $5k budget and mitigated by building incrementally, driven by Mercury, not ahead of it.
+- **The module boundary is now load-bearing across a repo gap.** A two-repo consumer amplifies any core↔host leak into a cross-repo break, so the ADR 0062 Path-C fitness functions ([ADR 0061](<redacted>.md)) matter more, not less.
+- **Example is unaffected today** — single-checkout reference instance, free core updates, until a separate future decision.
+- **No new criterion is minted by this ADR.** The seeded tasks are a distinct "done-when" from GDS-V4 C8 (single-checkout configurable instance); whether to track them under a new criterion is left to the owner (see the shipping task's notes).