@bongos/core 1.19.714 → 1.19.724

package/.claude/skills/backlog-review/SKILL.md

@@ -12,7 +12,7 @@ forever.
 
 `backlog` is the **pre-workable** state: a task lands there when the system will
 not put it in the claimable queue without a human saying go. `routing.js` says it
-plainly — *"'backlog' means a human still says go"* — and [ADR 0234](../../../docs/adr/<redacted>.md) §2
+plainly — *"'backlog' means a human still says go"* — and [ADR 0234](../../../docs/adr/0234-idea-routing-capture-time-promotion-landing-matrix-homeless-inbox.md) §2
 records why: a feature/cleanup/refactor filing *"reshape[s] what gets built and a
 filer should not be able to set the queue's agenda alone."*
 
@@ -23,7 +23,7 @@ surfaces were:
 
 - the **nod queue** (`GET /inbox/awaiting-nod`), scoped `WHERE origin='route'` —
   so it sees only filings that arrived through the idea inbox, and
-- the **30-day rot timer** (`GET /inbox/rotting`, [ADR 0232](../../../docs/adr/<redacted>.md)).
+- the **30-day rot timer** (`GET /inbox/rotting`, [ADR 0232](../../../docs/adr/0232-rot-is-derived-not-swept-and-water-is-the-only-new-verb.md)).
 
 Neither is a review of the backlog. This skill is that missing walk.
 
@@ -89,7 +89,7 @@ already at the bottom. This walk offers:
 | **skip** | — | no write; it surfaces again next review |
 
 Every one is an **existing** route, so this skill adds no new authority — the
-[ADR 0232](../../../docs/adr/<redacted>.md)
+[ADR 0232](../../../docs/adr/0232-rot-is-derived-not-swept-and-water-is-the-only-new-verb.md)
 precedent (*"a verb that reuses a route also reuses its permission"*).
 
 ## How to use

package/.claude/skills/blocker-review/SKILL.md

@@ -12,7 +12,7 @@ This is the structural cure for the old "task #3 sat in `blocked` for days becau
 
 This skill is **gated to Metic and above** (Metic, Archon). It is **not** available to Xenos, the lowest rank. Resolving a blocker auto-promotes every linked task from `blocked` → `ready` via the BEFORE-UPDATE trigger — that's a write that reshapes what the whole team can claim next, so it's a trusted-builder operation. A Xenos can still **file** a blocker (`POST /api/gds/blockers`) — that path stays open to any authenticated builder — they just can't resolve or link them.
 
-This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`), which names "blocker review" explicitly as a Metic privilege alongside full claim/ship, idea triage, and planning/priority sessions (see [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md) and [ADR 0018](../../../docs/adr/<redacted>.md)).
+This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`), which names "blocker review" explicitly as a Metic privilege alongside full claim/ship, idea triage, and planning/priority sessions (see [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md) and [ADR 0018](../../../docs/adr/0018-three-rank-model-goes-live.md)).
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 

package/.claude/skills/blocker-solve/SKILL.md

@@ -21,7 +21,7 @@ Resolving a blocker auto-promotes every task linked to it — a write that resha
 3. **If `rank` lowercases to `metic` or `archon`** → proceed.
 4. **If `rank` is absent** (pre-rank deployment) → proceed in passthrough mode, exactly as `/blocker-review` does, and note it.
 
-> Belt-and-braces only: the server already rejects `/blockers/:id/resolve` with `403` for non-Metic+ ([ADR 0018](../../../docs/adr/<redacted>.md), [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md)). Markdown never grants authority (criterion C7) — this check just stops a Xenos before they walk a whole solve only to 403 on the resolve.
+> Belt-and-braces only: the server already rejects `/blockers/:id/resolve` with `403` for non-Metic+ ([ADR 0018](../../../docs/adr/0018-three-rank-model-goes-live.md), [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md)). Markdown never grants authority (criterion C7) — this check just stops a Xenos before they walk a whole solve only to 403 on the resolve.
 
 ## Guardrails — read before you touch anything
 
@@ -92,6 +92,6 @@ Lars is the prompter (CLAUDE.md §2). Frame around the outcome, not the plumbing
 
 This skill is the **reusable core** of the blocker-solve idea. Future entry points call into this same flow rather than reinventing it:
 - a hall **"Solve this"** button on the Archon blocker card (records an intent), and
-- a **cloud / autonomous runner** that spins the session up server-side (mirroring the `box_intents` control-plane pattern, [ADR 0031](../../../docs/adr/<redacted>.md)), pinging the owner only for the **[needs you]** steps.
+- a **cloud / autonomous runner** that spins the session up server-side (mirroring the `box_intents` control-plane pattern, [ADR 0031](../../../docs/adr/0031-cloud-dev-environments-for-builders.md)), pinging the owner only for the **[needs you]** steps.
 
 Both reuse the gather → do/guide → verify → auto-resolve loop above. (Filed under GDS-V4; see the task that shipped this skill.)

package/.claude/skills/builder-reauth/SKILL.md

@@ -8,7 +8,7 @@ You are refreshing the current builder's Bongos CLI session. CLI bearer tokens c
 
 ## Why expiry exists (so you can explain it if asked)
 
-The idle TTL is auth-token hygiene (GDS-V3 criterion **C9**): the CLI token lives in a plaintext file (`~/.config/otb/gds-session.json`, mode 0600), so bounding the lifetime of a leaked or abandoned token matters. It is **not** what enforces rank changes — demotion calls `revokeAllSessionsForBuilder` synchronously and rank is read fresh from the DB on every request ([ADR 0016](../../../docs/adr/<redacted>.md)). So expiry stays; the friction is what this skill removes.
+The idle TTL is auth-token hygiene (GDS-V3 criterion **C9**): the CLI token lives in a plaintext file (`~/.config/otb/gds-session.json`, mode 0600), so bounding the lifetime of a leaked or abandoned token matters. It is **not** what enforces rank changes — demotion calls `revokeAllSessionsForBuilder` synchronously and rank is read fresh from the DB on every request ([ADR 0016](../../../docs/adr/0016-trust-boundary-server-enforced-permissions.md)). So expiry stays; the friction is what this skill removes.
 
 ## The flow (guided paste)
 

package/.claude/skills/builder-redteam/SKILL.md

@@ -101,7 +101,7 @@ This is optional because some findings are "the system is fine, my mental model
 ## What this skill does NOT do
 
 - Does NOT post anything to the team chat space — the bounty surface is intentionally Archon-private until adjudicated.
-- Does NOT create a `tasks` row directly — a vuln routes through the security-report surface (`/security/reports`) and the optional idea_inbox path above, which then becomes a fix-task via `/idea-triage`. (Authoring a task is Metic+ as of [ADR 0090](../../../docs/adr/<redacted>.md), but red-team reports deliberately use the report/idea flow, not a self-authored task.)
+- Does NOT create a `tasks` row directly — a vuln routes through the security-report surface (`/security/reports`) and the optional idea_inbox path above, which then becomes a fix-task via `/idea-triage`. (Authoring a task is Metic+ as of [ADR 0090](../../../docs/adr/0090-metic-task-authoring.md), but red-team reports deliberately use the report/idea flow, not a self-authored task.)
 - Does NOT ping the Archon. The Archon view auto-refreshes; pinging would defeat the queue's batching purpose.
 - Does NOT score or grade the report. That's R68 (auto-repro) + Archon adjudication.
 

package/.claude/skills/builder-ship/SKILL.md

@@ -13,7 +13,7 @@ Runs `node scripts/gds/ship.js <task-id> --notes-file notes.md --summary-file su
 The CLI drives a **three-state lifecycle** with a subagent grader between states (Phase 5, 2026-05-10):
 
 1. **`completed`** — the builder declared the work done. Always reached. Sets the task's `value_summary` (used on `status.example.com`) and the handoff notes.
-2. **`confirmed`** — smoke green + the subagent grader passed. **Verified, but not yet paid** — no credits land here ([ADR 0120](../../../docs/adr/<redacted>.md) pays on land, not on confirm). If the grade fails, the task stays at `completed` for human follow-up.
+2. **`confirmed`** — smoke green + the subagent grader passed. **Verified, but not yet paid** — no credits land here ([ADR 0120](../../../docs/adr/0120-pay-on-land-and-builder-owned-rebase-gate.md) pays on land, not on confirm). If the grade fails, the task stays at `completed` for human follow-up.
 3. **`shipped`** — the branch is merged into `main` + deployed (visible in production). The claim is released and the task is stamped `shipped_at` + `shipped_by`. **Credits land here**, as `credit_log.reason = 'task.shipped'` (a trigger updates `builders.total_credits`). If this step fails (conflicts, smoke red), the task stays at `confirmed` for `/merge-mode` to land later.
 
    > **What actually pays depends on the instance's reward mode** ([ADR 0146](../../../docs/adr/<redacted><redacted>.md)). The default `cost-plus-and-estimate` books both the per-task estimate and the cost-plus session reward. **Cloud Bongos runs `cost-plus-only`**, so the per-task `credits_reward` estimate is *never* paid here — it is an advertised guide only, and the cost-plus session reward (`round(true_cost_usd × 1.20)`) is the sole equity stream. A `Credits +0` on the ship card is expected on this instance, not a bug.

package/.claude/skills/builder-start/SKILL.md

@@ -10,7 +10,7 @@ You are starting a working session on the Example project. Before any other work
 
 ## Background
 
-Bongos keeps a database of tasks tagged with `touches[]` — file/folder fingerprints that determine parallel-safety. The API computes "claimable for me right now" as: tasks in `ready` status, not blocked, with no `touches[]` overlap with any currently-active claim by any builder. `ready` itself is gated by **dependencies** ([ADR 0015](../../../docs/adr/<redacted>.md)): a task enters `ready` only once every task in its `dependencies[]` is `shipped`. So if a task you want isn't listed, the usual reason is "its deps haven't shipped yet" — surface that, don't offer to override.
+Bongos keeps a database of tasks tagged with `touches[]` — file/folder fingerprints that determine parallel-safety. The API computes "claimable for me right now" as: tasks in `ready` status, not blocked, with no `touches[]` overlap with any currently-active claim by any builder. `ready` itself is gated by **dependencies** ([ADR 0015](../../../docs/adr/0015-task-dependencies-and-auto-promotion.md)): a task enters `ready` only once every task in its `dependencies[]` is `shipped`. So if a task you want isn't listed, the usual reason is "its deps haven't shipped yet" — surface that, don't offer to override.
 
 `start.js` produces a deterministic **card** (identity → quiet status line → holdings → a clean claimable table → next step), the same shape every session. It comes in two forms from the same data: an HTML widget (`--widget`) and a markdown fallback (default). Your job is to render it — not to rebuild or re-summarize it.
 

package/.claude/skills/design/SKILL.md

@@ -8,7 +8,7 @@ You are running a **UI design session**. Two things make it different from the E
 
 ## Step 0 — the tools, then the mode
 
-- **The skills named below have to be ON THE MACHINE.** Claiming a `ui` task lands them as part of the claim (`scripts/gds/claim.js`, the `materializeModuleSkills` flag in `scripts/gds/discipline-modes.json`); opening `/design` without one does not. If `.claude/skills/` has no `impeccable`, run `node scripts/gds/claude-materialize.js --module-skills-only` — it copies every enabled module's `skills/` into this checkout as untracked, self-ignored dirs ([ADR 0224](../../../docs/adr/<redacted>.md)), so `git status` stays clean and `--clean` takes them away again. A scaffolded instance already received them at `bongos init`. A skill of the same name in your own `~/.claude/skills` is **not** the module's — it carries no platform preamble and was never scanned ([ADR 0220](../../../docs/adr/<redacted>.md)).
+- **The skills named below have to be ON THE MACHINE.** Claiming a `ui` task lands them as part of the claim (`scripts/gds/claim.js`, the `materializeModuleSkills` flag in `scripts/gds/discipline-modes.json`); opening `/design` without one does not. If `.claude/skills/` has no `impeccable`, run `node scripts/gds/claude-materialize.js --module-skills-only` — it copies every enabled module's `skills/` into this checkout as untracked, self-ignored dirs ([ADR 0224](../../../docs/adr/0224-module-skills-reach-the-core-checkout-as-untracked-self-ignored-copies.md)), so `git status` stays clean and `--clean` takes them away again. A scaffolded instance already received them at `bongos init`. A skill of the same name in your own `~/.claude/skills` is **not** the module's — it carries no platform preamble and was never scanned ([ADR 0220](../../../docs/adr/0220-an-in-house-rebuilt-skill-is-a-first-party-skill.md)).
 - **Interactive** (someone is here to look and react): show, let them steer, iterate. One or two lines per step, then a screen.
 - **Autonomous** (no one will look): build inside the contract, prove it in both modes, stage or park the screens for review, and **never ship an interface change blind** — a task that cannot be verified visually gets a release with a reason, not a guess.
 
@@ -63,7 +63,7 @@ Third-party design skills reach a builder only through the module's vendoring po
 
 - *None vendored (2026-08-28).* Both origins scanned for the scoped set — `pbakaus/impeccable`, and the eleven `Leonxlnx/taste-skill` skills (`minimalist-ui`, `industrial-brutalist-ui`, `gpt-taste`, `stitch-design-taste`, `image-to-code`, `imagegen-frontend-web`, `imagegen-frontend-mobile`, `brandkit`, and the rest of the roster below) — reduced to `dangerous` at the scanner's deterministic floor and landed as rebuild specs (GDS tasks). The roster, the verdicts and the way to land one are in the README; vendoring one anyway is an owner override recorded in an ADR, not a session's call.
 
-**Rebuilt in-house from the specs** ([ADR 0220](../../../docs/adr/<redacted>.md), task 1003325; [ADR 0221](../../../docs/adr/<redacted>.md), task 1003326; [ADR 0222](../../../docs/adr/<redacted>.md), task 1003328; [ADR 0230](../../../docs/adr/<redacted>.md), task 1003327): first-party skills at `modules/ui-design/skills/<name>/`, each opening with the same preamble, each naming its spec and what changed in translation. They run INSIDE the loop above: the world first, the style library as the palette source for a variant, images as hero plates only, every motion rule inside the Kill Switch, the kit as the pre-flight.
+**Rebuilt in-house from the specs** ([ADR 0220](../../../docs/adr/0220-an-in-house-rebuilt-skill-is-a-first-party-skill.md), task 1003325; [ADR 0221](../../../docs/adr/0221-the-impeccable-method-is-one-skill-with-sub-command-playbooks.md), task 1003326; [ADR 0222](../../../docs/adr/0222-the-image-family-under-the-hero-only-rule.md), task 1003328; [ADR 0230](../../../docs/adr/0230-a-look-skill-is-a-composition-grammar-the-palette-is-the-pack.md), task 1003327): first-party skills at `modules/ui-design/skills/<name>/`, each opening with the same preamble, each naming its spec and what changed in translation. They run INSIDE the loop above: the world first, the style library as the palette source for a variant, images as hero plates only, every motion rule inside the Kill Switch, the kit as the pre-flight.
 
 - **design-taste-frontend** — the default taste skill for a landing page, a portfolio or a marketing surface: the brief read in one line, three dials from presets, one world locked for the page, hero and layout discipline, rationed decoration, a pre-flight the kit measures. Declines dashboards, tables, wizards and editors.
 - **design-taste-frontend-v1** — the earlier generation, kept distinct: a fixed baseline triple adapted in conversation, stack conventions for a served surface, the layout bans, full interaction cycles, the named vocabulary of premium patterns and the tile-grid archetypes.

package/.claude/skills/feedback/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Pull the latest Bongos feedback bundle into this session — the walkthrough transcript and screenshots, by absolute path. Local and read-only. Triggers: "/feedback", "pull in my latest feedback", "load my bongos feedback", "I just recorded a walkthrough", "grab the latest feedback bundle", "act on my screen recording".
 ---
 
-You are pulling in the **latest Bongos feedback bundle** — a self-contained capture the user just recorded with the Bongos desktop app (BV1.R13 / [ADR 0087](../../../docs/adr/<redacted>.md)). The app turns a spoken screen walkthrough into a model-agnostic `prompt.md` (a timestamped transcript + an ask) plus a handful of screenshots, all under `~/CloudBongos/feedback/`. This skill loads that bundle so you can act on it directly — no copy-paste, no clipboard-image fiddling.
+You are pulling in the **latest Bongos feedback bundle** — a self-contained capture the user just recorded with the Bongos desktop app (BV1.R13 / [ADR 0087](../../../docs/adr/0087-bongos-app-architecture-and-handoff-contract.md)). The app turns a spoken screen walkthrough into a model-agnostic `prompt.md` (a timestamped transcript + an ask) plus a handful of screenshots, all under `~/CloudBongos/feedback/`. This skill loads that bundle so you can act on it directly — no copy-paste, no clipboard-image fiddling.
 
 ## Steps
 

package/.claude/skills/goal-create/SKILL.md

@@ -10,7 +10,7 @@ You are running the **goal-create** session for this Cloud Bongos instance. You
 
 ## Rank gate — Metic+ only
 
-**Gated to Metic+ (Metic, Archon); not Xenos.** Creating a goal sets a **scope wall** — the module keys its members may author inside — and seeds the criteria a slice of the version will be judged against. That is a trusted-builder operation (ADR 0086 §3/§4). The server enforces it: `POST /api/gds/goals` is `requireRank('metic','archon')`, and `POST /api/gds/versions/:id/done-when` is `requireRank('metic','archon')` **plus a goal-ownership wall** (ADR 0154) — both pinned in `route-rank-check.MODULE_EXPECTED_RANKS.lifecycle`. This check just stops a Xenos early instead of after a wall of 403s. Markdown never grants authority ([`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0016](../../../docs/adr/<redacted>.md)).
+**Gated to Metic+ (Metic, Archon); not Xenos.** Creating a goal sets a **scope wall** — the module keys its members may author inside — and seeds the criteria a slice of the version will be judged against. That is a trusted-builder operation (ADR 0086 §3/§4). The server enforces it: `POST /api/gds/goals` is `requireRank('metic','archon')`, and `POST /api/gds/versions/:id/done-when` is `requireRank('metic','archon')` **plus a goal-ownership wall** (ADR 0154) — both pinned in `route-rank-check.MODULE_EXPECTED_RANKS.lifecycle`. This check just stops a Xenos early instead of after a wall of 403s. Markdown never grants authority ([`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0016](../../../docs/adr/0016-trust-boundary-server-enforced-permissions.md)).
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 

package/.claude/skills/goal-review/SKILL.md

@@ -10,7 +10,7 @@ You are running the **goal-review** session for this Cloud Bongos instance. It m
 
 **The auto-flag is derived, not stored.** When every task linked to a criterion has shipped — and the criterion has not yet been confirmed — the server flags it `pending_review` (deterministic from `task_criteria` + ship status; no manual propose step). Confirming sets the criterion `satisfied=true`; confirming a goal's **last** unsatisfied criterion auto-flips the goal `open → achieved`.
 
-## ⚠ This skill is no longer a GATE (task 1002069 / [ADR 0183](../../../docs/adr/<redacted>.md))
+## ⚠ This skill is no longer a GATE (task 1002069 / [ADR 0183](../../../docs/adr/0183-criteria-close-themselves.md))
 
 **A criterion now closes itself.** `doneWhen.autoSatisfyShippedCriteria` runs inside `shipTask`'s transaction (immediately, for the ship that completed it) and unscoped on every `publish-reconciler` tick (draining the backlog and self-healing). A goal whose criteria are all satisfied achieves itself the same way. Nobody has to run this skill for finished work to close — that dependence was producing a **lying board** (goal 1000072 measured `6/9 shipped, 0/5 criteria`).
 
@@ -25,7 +25,7 @@ A criterion sitting here with shipped tasks and no explanation means the sweep h
 
 ## Rank gate — Metic+ only
 
-**Gated to Metic+ (Metic, Archon); not Xenos.** Confirming a criterion sets `satisfied=true` and can auto-achieve a goal — a trusted-builder operation that closes out a slice of a version (the "who confirms" resolution in ADR 0086 §6: the planner, not only the Archon). The server enforces this — `POST /api/gds/done-when/:criterionId/satisfy` is `requireRank('metic','archon')` and pinned in `route-rank-check.MODULE_EXPECTED_RANKS.lifecycle` — so this check just stops a Xenos early instead of after a wall of 403s. Markdown never grants authority ([`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0016](../../../docs/adr/<redacted>.md)).
+**Gated to Metic+ (Metic, Archon); not Xenos.** Confirming a criterion sets `satisfied=true` and can auto-achieve a goal — a trusted-builder operation that closes out a slice of a version (the "who confirms" resolution in ADR 0086 §6: the planner, not only the Archon). The server enforces this — `POST /api/gds/done-when/:criterionId/satisfy` is `requireRank('metic','archon')` and pinned in `route-rank-check.MODULE_EXPECTED_RANKS.lifecycle` — so this check just stops a Xenos early instead of after a wall of 403s. Markdown never grants authority ([`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0016](../../../docs/adr/0016-trust-boundary-server-enforced-permissions.md)).
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 

package/.claude/skills/idea-triage/SKILL.md

@@ -14,7 +14,7 @@ here. The inbox is therefore no longer "everything anyone filed"; it holds only
 **work with no home yet**. Expect it to be smaller, and read what IS in it as
 work that genuinely needs a decision rather than a queue to clear.
 
-**Bugs (task 1003691, [ADR 0262](../../../docs/adr/<redacted>.md)).**
+**Bugs (task 1003691, [ADR 0262](../../../docs/adr/0262-a-bug-never-lands-in-the-inbox.md)).**
 A `kind='bug'` now routes even with NO goal named: the system files it into the
 version's maintenance goal rather than making the reporter know the goal map. So a
 bug should not appear in this queue — with **one deliberate exception**. Routing is
@@ -36,7 +36,7 @@ Bug reports from Discord have their own channel, `#bugs`, which does route.
    it. Opting out is legal but rarely right: a promote with no goal is **not**
    goal-less — the server files it under the version's catch-all `<version> —
    general` goal — and that bucket carries no done-when criteria, so since
-   [ADR 0183](../../../docs/adr/<redacted>.md) made criteria
+   [ADR 0183](../../../docs/adr/0183-criteria-close-themselves.md) made criteria
    close themselves off LINKED tasks, work parked there can never advance
    anything. The general bucket used to be the silent default; it is now a choice
    you type.
@@ -55,7 +55,7 @@ capture-time suggester (R08/R09/R11 surfaces) is where the fix belongs.
 
 ## Rank gate — Metic+ only
 
-**Gated to Metic+ (Metic, Archon); not Xenos.** Triage verdicts (promote, discard, merge) reshape the team's backlog — a trusted-builder operation (GDS-V3 criterion C2, `three-ranks-gate-everything`; [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0018](../../../docs/adr/<redacted>.md)). A Xenos can still **file** an idea (`POST /api/gds/inbox`); they just can't verdict them.
+**Gated to Metic+ (Metic, Archon); not Xenos.** Triage verdicts (promote, discard, merge) reshape the team's backlog — a trusted-builder operation (GDS-V3 criterion C2, `three-ranks-gate-everything`; [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0018](../../../docs/adr/0018-three-rank-model-goes-live.md)). A Xenos can still **file** an idea (`POST /api/gds/inbox`); they just can't verdict them.
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 
@@ -149,7 +149,7 @@ node scripts/gds/triage.js --development "${TMPDIR:-/tmp}/otb-idea-development.j
 
 `triage.js` prints each idea's developed block above its verdict prompt, and runs its own batch-cluster pass (Step 1.5a) automatically first. It never *generates* the analysis (that's this skill's job); it only displays what the cache holds, and runs exactly as before when no cache is present.
 
-> **Not in this cut (follow-up leg).** The next step is to let the Archon push the developed `open_questions` *back to the submitter* — a round-trip in the Discord `#ideas` thread / DM before promotion — so the submitter says how they'd want it integrated. That needs the Discord bot interaction + idea↔thread linking (idea `#216` / [ADR 0033](../../../docs/adr/<redacted>.md)) and is tracked separately. For now the open questions are answered by the Archon in-session.
+> **Not in this cut (follow-up leg).** The next step is to let the Archon push the developed `open_questions` *back to the submitter* — a round-trip in the Discord `#ideas` thread / DM before promotion — so the submitter says how they'd want it integrated. That needs the Discord bot interaction + idea↔thread linking (idea `#216` / [ADR 0033](../../../docs/adr/0033-discord-bot-service-principal.md)) and is tracked separately. For now the open questions are answered by the Archon in-session.
 
 **Step 2 — walk the list, idea by idea.**
 
@@ -216,7 +216,7 @@ at the triage end, where the judgement is.)
 
 **Promote → pick the tier (BV1.R64 / ADR 0086).** An idea no longer only becomes a *task* — it can promote into any tier of the work hierarchy: a **goal** (a whole module-scoped workspace), a **criterion** (a new done-when test), or a **task** (a single unit of work). Choose by the idea's size: a broad objective → goal; a "we should also require X to be done" → criterion; a concrete piece of work → task. Frame the choice to the user in those terms, then create the right record and mark the idea promoted.
 
-- **Promote → task** (the common case). Ask for version, title, est_minutes, priority, credits_reward (`touches[]` optional — [ADR 0049](../../../docs/adr/<redacted>.md)). `POST /api/gds/tasks` lands the new task in `backlog`, **not** `active` — it still needs `POST /tasks/:id/promote` (Metic+) before it's claimable. **Pass `goal_id` on the create** so the task lands in a real goal rather than the version's `"<version> — general"` catch-all — `POST /tasks` has accepted it since task 1763, and the 201 now returns a `goal_advisory` when the task ends up with no proper home. If no existing goal fits, run [`/goal-create`](../goal-create/SKILL.md) instead of filing it loose.
+- **Promote → task** (the common case). Ask for version, title, est_minutes, priority, credits_reward (`touches[]` optional — [ADR 0049](../../../docs/adr/0049-split-parallel-safety-contract.md)). `POST /api/gds/tasks` lands the new task in `backlog`, **not** `active` — it still needs `POST /tasks/:id/promote` (Metic+) before it's claimable. **Pass `goal_id` on the create** so the task lands in a real goal rather than the version's `"<version> — general"` catch-all — `POST /tasks` has accepted it since task 1763, and the 201 now returns a `goal_advisory` when the task ends up with no proper home. If no existing goal fits, run [`/goal-create`](../goal-create/SKILL.md) instead of filing it loose.
 
   ```
   # 1. Create the task (--body-file avoids shell-quoting the touches[]/description).

package/.claude/skills/merge-mode/SKILL.md

@@ -5,9 +5,9 @@ description: >-
 requires: [main-checkout, push-credential, gh, droplet-ssh]
 ---
 
-You are running the manual merge-mode session for Example. **`/merge-mode` is a rare last resort, not a routine sweep — and not something to push on other builders.** The server lands merges on its own: `/builder-ship` chains into auto-merge, green PRs auto-merge, a 5-min reconciler flips `confirmed → shipped`, and the [ADR 0082](../../../docs/adr/<redacted>.md) resolver self-heals generated-file conflicts. **Before running this skill, confirm the task is genuinely stuck** — still at `confirmed` more than ~5 minutes after its ship because of a conflict or regression the server couldn't auto-resolve. If you haven't waited for the sweep yet, stop and wait. This skill is for the strand that survives all of that — usually a cross-branch / non-generated-file conflict, a smoke regression, or a `--no-merge` ship.
+You are running the manual merge-mode session for Example. **`/merge-mode` is a rare last resort, not a routine sweep — and not something to push on other builders.** The server lands merges on its own: `/builder-ship` chains into auto-merge, green PRs auto-merge, a 5-min reconciler flips `confirmed → shipped`, and the [ADR 0082](../../../docs/adr/0082-server-side-merge-conflict-auto-resolution.md) resolver self-heals generated-file conflicts. **Before running this skill, confirm the task is genuinely stuck** — still at `confirmed` more than ~5 minutes after its ship because of a conflict or regression the server couldn't auto-resolve. If you haven't waited for the sweep yet, stop and wait. This skill is for the strand that survives all of that — usually a cross-branch / non-generated-file conflict, a smoke regression, or a `--no-merge` ship.
 
-The queue this skill works against is **tasks at status='confirmed'**. Those are tasks where the builder declared done, verification passed, and the only thing missing is the merge to main + deploy. **They are not yet paid** — [ADR 0120](../../../docs/adr/<redacted>.md) books the reward on land, so landing the queue is what releases those builders' credits.
+The queue this skill works against is **tasks at status='confirmed'**. Those are tasks where the builder declared done, verification passed, and the only thing missing is the merge to main + deploy. **They are not yet paid** — [ADR 0120](../../../docs/adr/0120-pay-on-land-and-builder-owned-rebase-gate.md) books the reward on land, so landing the queue is what releases those builders' credits.
 
 ## What this skill does
 
@@ -118,7 +118,7 @@ This mirrors what `ship.js` does automatically; it's here because /merge-mode de
 
 **Step 5 — smoke tests, push, deploy.**
 
-> **Deploy mode (#679 / [ADR 0042](../../../docs/adr/<redacted>.md)).** `config/deploy.json` is now `mode: ci` (CI cutover landed 2026-06-13), so the **`ci`** path is current: there is no laptop merge and no SSH at all — landing happens via PR auto-merge and [`.github/workflows/deploy-prod.yml`](../../../.github/workflows/deploy-prod.yml) deploys `main`→prod from Actions. In `ci` mode, do NOT run the `git push origin main` + `ssh … ~/deploy.sh` lines below — instead confirm the PR auto-merged and the `deploy-prod` Actions run went green. The block below is the **legacy `laptop`** deploy mode (the operator's machine pushes `main` and SSHes the droplet) — it is the fallback path and only applies if `config/deploy.json` is reverted to `mode: laptop`. Check the active mode with `node scripts/gds/ship.js --print-deploy-mode`.
+> **Deploy mode (#679 / [ADR 0042](../../../docs/adr/0042-builder-self-deploy-ci-auto-merge.md)).** `config/deploy.json` is now `mode: ci` (CI cutover landed 2026-06-13), so the **`ci`** path is current: there is no laptop merge and no SSH at all — landing happens via PR auto-merge and [`.github/workflows/deploy-prod.yml`](../../../.github/workflows/deploy-prod.yml) deploys `main`→prod from Actions. In `ci` mode, do NOT run the `git push origin main` + `ssh … ~/deploy.sh` lines below — instead confirm the PR auto-merged and the `deploy-prod` Actions run went green. The block below is the **legacy `laptop`** deploy mode (the operator's machine pushes `main` and SSHes the droplet) — it is the fallback path and only applies if `config/deploy.json` is reverted to `mode: laptop`. Check the active mode with `node scripts/gds/ship.js --print-deploy-mode`.
 
 > **Do NOT probe `parseDeployMode` directly (task 1003221).** It reads only the env var and `config/deploy.json`, and **defaults to `laptop`** when neither is present — and `config/` is not in the dev-box sparse checkout (`BASE_SPARSE_PATHS`, ADR 0148), so on a box that probe answers `laptop` every time. It sent a builder down the laptop merge path — local merge, `push-main.js`, SSH deploy — on a machine with none of those credentials (2026-08-21, 163 minutes). `effectiveDeployMode` is the credential-aware answer and reroutes to `ci` when the machine cannot push locally; the flag above prints that one.
 
@@ -163,7 +163,7 @@ For each task that successfully merged + deployed:
 node scripts/gds/api.js POST /api/gds/tasks/<task-id>/ship
 ```
 
-The `POST /tasks/:id/ship` endpoint flips the task to `shipped`, stamps `shipped_at`. **This is the credit moment** — [ADR 0120](../../../docs/adr/<redacted>.md) books the reward on land, so this call is what pays the builder (on a `cost-plus-only` instance like Cloud Bongos that is the cost-plus session reward only — the per-task estimate is never paid; [ADR 0146](../../../docs/adr/<redacted><redacted>.md)).
+The `POST /tasks/:id/ship` endpoint flips the task to `shipped`, stamps `shipped_at`. **This is the credit moment** — [ADR 0120](../../../docs/adr/0120-pay-on-land-and-builder-owned-rebase-gate.md) books the reward on land, so this call is what pays the builder (on a `cost-plus-only` instance like Cloud Bongos that is the cost-plus session reward only — the per-task estimate is never paid; [ADR 0146](../../../docs/adr/<redacted><redacted>.md)).
 
 **Step 7 — surface a summary.**
 

package/.claude/skills/new-project/SKILL.md

@@ -24,9 +24,9 @@ Interview the owner for: product name, world name, company; the **GitHub repo**
 
 Ask three things, and offer the skip in the same breath — a "you can leave this blank" that arrives *after* the question reads as a test:
 
-- **What are you building?** A sentence or two. This is the project's **description**, and it is half of the publish gate ([ADR 0182](../../../docs/adr/<redacted>.md) D4: a project is on the public map iff it has a name AND a description).
+- **What are you building?** A sentence or two. This is the project's **description**, and it is half of the publish gate ([ADR 0182](../../../docs/adr/0182-project-visibility-two-axes.md) D4: a project is on the public map iff it has a name AND a description).
 - **Who's building it?** `solo` / `small-team` / `community`. This is what the platform's setup recommendations read.
-- **What kind of project is it?** `game` / `research` / `business` / `non-profit` / `not-sure` — the declared **type**, and the one answer that does real work downstream: it keys the starter bundle the next step preselects ([ADR 0237](../../../docs/adr/<redacted>.md)). `not-sure` is a real answer, not a missing one.
+- **What kind of project is it?** `game` / `research` / `business` / `non-profit` / `not-sure` — the declared **type**, and the one answer that does real work downstream: it keys the starter bundle the next step preselects ([ADR 0237](../../../docs/adr/0237-a-starter-bundle-is-a-preset-over-the-always-on-core-keyed-by-declared-type.md)). `not-sure` is a real answer, not a missing one.
 
 All three ride the provisioning request — `description`, `detail: { team_shape }`, and `type` — and each is independently skippable. **Skipping is a supported default, not a failure:** the project stands up exactly the same, it just stays *dark matter* — off the public map and un-joinable — until a description exists. Say that plainly when the owner skips, and say the way back with it: `PATCH /provisioning/instances/:id/detail` takes `description`, `detail` and `modules` later, and publishes the project the moment the description lands.
 
@@ -38,11 +38,11 @@ Never gate the standup on this step, and never invent an answer the owner didn't
 
 ### 3. Pick its extras — OPTIONAL, and the skip is the recommendation (task 1002339)
 
-Every project runs the **always-on core** whatever you do here; this step is only about the **optional** modules on top. Read the preselection out of the server, never a list you carry: `GET /provisioning/starter-bundles` returns the always-on core once, then one resolved bundle per type — and the bundle for the type answered in step 2 is what the picker shows ticked ([ADR 0237](../../../docs/adr/<redacted>.md)). Show the owner what is already ticked and why, then let them add or remove.
+Every project runs the **always-on core** whatever you do here; this step is only about the **optional** modules on top. Read the preselection out of the server, never a list you carry: `GET /provisioning/starter-bundles` returns the always-on core once, then one resolved bundle per type — and the bundle for the type answered in step 2 is what the picker shows ticked ([ADR 0237](../../../docs/adr/0237-a-starter-bundle-is-a-preset-over-the-always-on-core-keyed-by-declared-type.md)). Show the owner what is already ticked and why, then let them add or remove.
 
-The type is not the only input: the **team shape** from step 2 adjusts the bundle too, and the server reports each adjustment that actually changed something, with its reason. Those belong to the bundle itself, not to a note beside it — render them as part of what is ticked, so cause and effect arrive together ([ADR 0243](../../../docs/adr/<redacted>.md)). A rule whose module the bundle already carries records nothing, so an empty adjustment list means the shape changed nothing, not that it was ignored.
+The type is not the only input: the **team shape** from step 2 adjusts the bundle too, and the server reports each adjustment that actually changed something, with its reason. Those belong to the bundle itself, not to a note beside it — render them as part of what is ticked, so cause and effect arrive together ([ADR 0243](../../../docs/adr/0243-a-bundle-adjustment-belongs-to-the-bundle-not-the-advice-about-it.md)). A rule whose module the bundle already carries records nothing, so an empty adjustment list means the shape changed nothing, not that it was ignored.
 
-**Skipping means "take the bundle", and that is a real default, not a deferral** ([ADR 0240](../../../docs/adr/<redacted>.md)). Three answers, three different meanings — say them apart, because two of them look alike and are not:
+**Skipping means "take the bundle", and that is a real default, not a deferral** ([ADR 0240](../../../docs/adr/0240-a-skipped-module-picker-stores-nothing-and-resolves-the-bundle-on-read.md)). Three answers, three different meanings — say them apart, because two of them look alike and are not:
 
 - **Skip** — send no `modules` key at all. The row stores nothing and the bundle is resolved **on read**, so the project ends up with exactly the set the picker had ticked. A later change to the bundle for that type reaches this project too.
 - **An explicit list** — `modules: ["…"]`, the opt-in keys only, never the always-on core. This is now the project's own answer and it stops tracking the bundle.
@@ -137,13 +137,13 @@ Fill the instance **look** — theme / palette / fonts in `config/branding.json`
 The hall is the point of everything above — end there, not at brand (task 1002703):
 
 - **With a domain:** open `https://<domain>/builders` — that's the project's home.
-- **No domain yet:** run `bongos dev` in the repo checkout — it stands the instance up locally and serves the hall on the owner's machine ([ADR 0149](../../../docs/adr/<redacted>.md)).
+- **No domain yet:** run `bongos dev` in the repo checkout — it stands the instance up locally and serves the hall on the owner's machine ([ADR 0149](../../../docs/adr/0149-bongos-dev-local-launcher.md)).
 
 ### 12. Decide how the project stands — the four axes (BV1.R05/R10/R12, ADR 0182)
 
 **These are not asked during creation, and that is deliberate.** A new project starts on today's behaviour — `platform_visibility: public`, `joinability: apply`, `visibility: public`, `join_grant: full` — and the owner changes them afterwards from the project's own page, each card PATCHing `…/instances/:id/settings` with its own key. Do not invent a visibility question in the creation flow; walk the owner through these once they are in, when the project is real enough for the answers to mean something.
 
-Four axes, four different questions — they are **not** synonyms, and an owner may set them independently ([ADR 0182](../../../docs/adr/<redacted>.md)):
+Four axes, four different questions — they are **not** synonyms, and an owner may set them independently ([ADR 0182](../../../docs/adr/0182-project-visibility-two-axes.md)):
 
 | Key | Asks | Values |
 |---|---|---|
@@ -154,18 +154,18 @@ Four axes, four different questions — they are **not** synonyms, and an owner
 
 Four things worth saying plainly, each of which has already confused someone:
 
-- **`visibility` does not put the project on the map — publishability does.** A project is on the public map iff it has a name AND a description ([ADR 0182](../../../docs/adr/<redacted>.md) D4); that is derived, never stored, and no value of `visibility` puts a husk on the map. Read the server's `publish: { publishable, missing, missing_phrase }` back verbatim rather than computing it (step 2's rule, and it applies here too).
-- **`gated` is enforced on the instance, not by the hub** — a middleware ahead of every surface refuses a session-less stranger with a door that carries the way in ([ADR 0192](../../../docs/adr/<redacted>.md)). It grants nothing; every rank check behind it still runs.
-- **Gated and apply-to-join compose, and a stranger can still apply** ([ADR 0278](../../../docs/adr/<redacted>.md)): the member door exempts the application write and the applicant's own status poll, each scoped to one verb, so the owner's applicant queue keeps the door in front of it. Before that fix the two settings silently composed into "nobody can apply".
-- **The door is one composed answer, and a refusal never names which knob closed it** ([ADR 0247](../../../docs/adr/<redacted>.md)). `join_grant` is the ceiling on the visibility axis that `joinability` may only narrow, and it governs the `public` state alone.
+- **`visibility` does not put the project on the map — publishability does.** A project is on the public map iff it has a name AND a description ([ADR 0182](../../../docs/adr/0182-project-visibility-two-axes.md) D4); that is derived, never stored, and no value of `visibility` puts a husk on the map. Read the server's `publish: { publishable, missing, missing_phrase }` back verbatim rather than computing it (step 2's rule, and it applies here too).
+- **`gated` is enforced on the instance, not by the hub** — a middleware ahead of every surface refuses a session-less stranger with a door that carries the way in ([ADR 0192](../../../docs/adr/0192-platform-visibility-member-door.md)). It grants nothing; every rank check behind it still runs.
+- **Gated and apply-to-join compose, and a stranger can still apply** ([ADR 0278](../../../docs/adr/0278-a-gated-project-still-takes-applications.md)): the member door exempts the application write and the applicant's own status poll, each scoped to one verb, so the owner's applicant queue keeps the door in front of it. Before that fix the two settings silently composed into "nobody can apply".
+- **The door is one composed answer, and a refusal never names which knob closed it** ([ADR 0247](../../../docs/adr/0247-the-join-door-is-one-composed-answer-and-dark-matter-has-no-live-verdict-yet.md)). `join_grant` is the ceiling on the visibility axis that `joinability` may only narrow, and it governs the `public` state alone.
 
-A settings change rides web.env and is applied by a **restart**, so the project's own manifest is the only honest source for what it currently runs — the saved choice and the running value differ for the whole life of a push, and a surface that collapses them is lying in one direction or the other ([ADR 0190](../../../docs/adr/<redacted>.md)).
+A settings change rides web.env and is applied by a **restart**, so the project's own manifest is the only honest source for what it currently runs — the saved choice and the running value differ for the whole life of a push, and a surface that collapses them is lying in one direction or the other ([ADR 0190](../../../docs/adr/0190-settings-apply-in-place-env-patch.md)).
 
 ### 13. Invite the first builder — the done panel's first act, not a rail step (ADR 0249)
 
-Deliberately **outside** the numbered rail above: a step that can only run once the project exists is not a step in creating it, and putting it in the rail would buy a renumbering coupling and still have to be reordered to sit after Create ([ADR 0249](../../../docs/adr/<redacted>.md)). It appears the moment the created record has an id and a slug, it is skippable there, and **the same widget is the way back** — the project's own page carries it beside *Its extras*, one implementation mounted twice, so an owner who skipped is never stuck.
+Deliberately **outside** the numbered rail above: a step that can only run once the project exists is not a step in creating it, and putting it in the rail would buy a renumbering coupling and still have to be reordered to sit after Create ([ADR 0249](../../../docs/adr/0249-the-invite-step-is-the-done-panel-s-first-act-not-a-rail-step.md)). It appears the moment the created record has an id and a slug, it is skippable there, and **the same widget is the way back** — the project's own page carries it beside *Its extras*, one implementation mounted twice, so an owner who skipped is never stuck.
 
-`GET /provisioning/instances/:id/invite-suggestions` answers who is worth inviting. Treat that list as a **recruiting surface**: it owes the people on it the recruiting opt-out, and an owner who is shown names has to be shown them honestly ([ADR 0251](../../../docs/adr/<redacted>.md)).
+`GET /provisioning/instances/:id/invite-suggestions` answers who is worth inviting. Treat that list as a **recruiting surface**: it owes the people on it the recruiting opt-out, and an owner who is shown names has to be shown them honestly ([ADR 0251](../../../docs/adr/0251-a-suggestion-of-who-to-invite-is-a-recruiting-surface-and-owes-the-opt-out.md)).
 
 ## Done-when
 
@@ -176,8 +176,8 @@ Steps 12 and 13 are **not** part of that criterion and must never gate it. They
 ## Constraints
 
 - **This skill is the source of truth for the sequence.** If a step changes, change it here; `bongos onboard` (task 1982) and the hall wizard (task 1983) must render the same sequence. The machine-readable twin is [`modules/provisioning/onboard-plan.js`](../../../modules/provisioning/onboard-plan.js), served at `GET /provisioning/onboard-plan` — a **rail** step added here gets a step there in the same change, or the two drift and each claims to be canonical.
-- **Steps 12 and 13 are deliberately NOT in that plan**, and that is the distinction to keep: the plan is the creation rail, and both of those run only once the project exists. A step that can only run after the terminal step is not a step in the rail ([ADR 0249](../../../docs/adr/<redacted>.md)) — it belongs to the done panel and the project's own page, each of which carries its own way back.
+- **Steps 12 and 13 are deliberately NOT in that plan**, and that is the distinction to keep: the plan is the creation rail, and both of those run only once the project exists. A step that can only run after the terminal step is not a step in the rail ([ADR 0249](../../../docs/adr/0249-the-invite-step-is-the-done-panel-s-first-act-not-a-rail-step.md)) — it belongs to the done panel and the project's own page, each of which carries its own way back.
 - **Standalone only** (ADR 0108) — do not fall back to editing this monorepo's checkout for a new project.
 - **Never weaken the trust boundary** — the web tier enqueues; only the control-plane runner (`provision.js`) touches cloud tokens (ADR 0016 / 0111 §2).
-- **Live docs are automatic** — a standalone instance's session-log index regenerates on deploy (`provision.js` runs `regen-instance-docs.js` after migrate; `bongos init`/`upgrade` seed+refresh it), and the whole-file nav docs are gitignored so `git reset --hard` never wipes them ([ADR 0147](../../../docs/adr/<redacted>.md)). If you wire a **bespoke** deploy script for an instance, it MUST call `node node_modules/@bongos/core/scripts/gds/regen-instance-docs.js` after `git reset` + migrate — see [`docs/recipes/standalone-live-docs.md`](../../../docs/recipes/standalone-live-docs.md).
-- **Adopting an EXISTING repo** (brownfield) is the other branch of the scaffold leg (step 5) — `bongos init --adopt` ([ADR 0121](../../../docs/adr/<redacted>.md)): detect → accept-gated conflict pre-flight → additive layering (never clobbers) → real version/goal + backlog import. Built; the `bongos onboard` CLI and the hall "start a project" wizard offer the same greenfield-vs-adopt choice.
+- **Live docs are automatic** — a standalone instance's session-log index regenerates on deploy (`provision.js` runs `regen-instance-docs.js` after migrate; `bongos init`/`upgrade` seed+refresh it), and the whole-file nav docs are gitignored so `git reset --hard` never wipes them ([ADR 0147](../../../docs/adr/0147-standalone-live-docs-regen.md)). If you wire a **bespoke** deploy script for an instance, it MUST call `node node_modules/@bongos/core/scripts/gds/regen-instance-docs.js` after `git reset` + migrate — see [`docs/recipes/standalone-live-docs.md`](../../../docs/recipes/standalone-live-docs.md).
+- **Adopting an EXISTING repo** (brownfield) is the other branch of the scaffold leg (step 5) — `bongos init --adopt` ([ADR 0121](../../../docs/adr/0121-greenfield-vs-brownfield-onboarding-adopt-existing-repo.md)): detect → accept-gated conflict pre-flight → additive layering (never clobbers) → real version/goal + backlog import. Built; the `bongos onboard` CLI and the hall "start a project" wizard offer the same greenfield-vs-adopt choice.

package/.claude/skills/planning-session/SKILL.md

@@ -25,13 +25,13 @@ The first planning session — V3 Planning Session #1, 2026-05-12 — is the tem
 
 This skill is **gated to Metic and above** (Metic, Archon). It is **not** available to Xenos, the lowest rank. A planning session sets the scope-truth of a version: the criteria all subsequent tasks anchor to, the dependency graph other builders inherit, the rank ordering the queue surfaces. That's a trusted-builder operation, not something a sandboxed Xenos should reshape on their own.
 
-This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`) and matches the gate the sibling skills already enforce (see [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0018](../../../docs/adr/<redacted>.md), and the existing rank-gate frontmatter in [`/idea-triage`](../idea-triage/SKILL.md) and [`/blocker-review`](../blocker-review/SKILL.md)).
+This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`) and matches the gate the sibling skills already enforce (see [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0018](../../../docs/adr/0018-three-rank-model-goes-live.md), and the existing rank-gate frontmatter in [`/idea-triage`](../idea-triage/SKILL.md) and [`/blocker-review`](../blocker-review/SKILL.md)).
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 
 1. Call `GET /api/gds/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
 2. **If `rank` is present and lowercases to `xenos`** → stop immediately. Tell the builder: *"Planning sessions set the scope-truth of a version — they're a Metic+ operation. You're currently Xenos. You can still **file** a criterion proposal or task idea via `POST /api/gds/inbox` (which lands in idea_inbox for a Metic+ builder to ratify at the next planning session); ask an Archon for promotion if you need to run sessions directly."* Do not pull state, do not present criteria, do not propose tasks.
-3. **If `rank` lowercases to `metic`** → proceed in **Metic-mode**: run the five-phase structure below conversationally, but in Phase 5 write proposals to `idea_inbox` (kind=`criterion-proposal` for criteria, kind=`feature` for tasks) tagged with the target version. Any Metic+ builder ratifies them (`idea.ratify`, metic-floored since ADR 0157) — typically at the next planning session. Since [ADR 0090](../../../docs/adr/<redacted>.md) a Metic MAY `POST /tasks` directly, and since [ADR 0154](../../../docs/adr/<redacted>.md) a Metic MAY write a `done_when_criteria` row for a goal they own or manage. What needs an Archon is a VERSION-level criterion (no `goal_id`), one in a goal you don't hold, and — since [ADR 0250](../../../docs/adr/<redacted>.md) §6 (task 1003608) — **creating a version at all**: `version.create` returned to the Archon floor, because once the version boundary carries the scope gate, cutting a version is the way around it rather than authoring. ADR 0157 had briefly delegated it to Metic; it no longer is. The spec-draft (Phase 3) and the in-depth interview (Phase 4) run identically in Metic-mode — the only difference is the Phase-5 write (you file proposals, you don't seed tasks directly).
+3. **If `rank` lowercases to `metic`** → proceed in **Metic-mode**: run the five-phase structure below conversationally, but in Phase 5 write proposals to `idea_inbox` (kind=`criterion-proposal` for criteria, kind=`feature` for tasks) tagged with the target version. Any Metic+ builder ratifies them (`idea.ratify`, metic-floored since ADR 0157) — typically at the next planning session. Since [ADR 0090](../../../docs/adr/0090-metic-task-authoring.md) a Metic MAY `POST /tasks` directly, and since [ADR 0154](../../../docs/adr/0154-goal-owner-criterion-authoring.md) a Metic MAY write a `done_when_criteria` row for a goal they own or manage. What needs an Archon is a VERSION-level criterion (no `goal_id`), one in a goal you don't hold, and — since [ADR 0250](../../../docs/adr/0250-strict-versioning-the-version-boundary-is-the-scope-gate.md) §6 (task 1003608) — **creating a version at all**: `version.create` returned to the Archon floor, because once the version boundary carries the scope gate, cutting a version is the way around it rather than authoring. ADR 0157 had briefly delegated it to Metic; it no longer is. The spec-draft (Phase 3) and the in-depth interview (Phase 4) run identically in Metic-mode — the only difference is the Phase-5 write (you file proposals, you don't seed tasks directly).
 
    **For each criterion proposal**, write `body_md` as a JSON object with this exact shape so the `POST /api/gds/inbox/:id/ratify` endpoint (V3.R31 / #252) can parse it cleanly:
 
@@ -45,7 +45,7 @@ This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`) and matches the
 
    `target_version` is required and must match an existing `versions.id`. `criterion_md` is required and is the user-visible criterion text. `sort_order_hint` is optional — omit or pass `null` to let the ratify endpoint default it to `max(existing sort_order) + 1` on the target version. On ratify, the proposer earns +5 karma (`reason='proposal_ratified'`) and the audit row in `criterion_proposal_audit` captures the full provenance.
 
-   **Net-new version (idea 425).** The Metic-mode path above assumes the target version *already exists* — its criterion proposals carry `suggested_version` (an FK to a `versions` row) and a `target_version` that must match `versions.id`. **A Metic cannot create one:** `version.create` is **Archon-floored** ([ADR 0250](../../../docs/adr/<redacted>.md) §6, task 1003608 — ADR 0157 had briefly lowered it to Metic and that is reversed). So `POST /versions` returns `403` and the Metic has no valid FK to point at. Ask an Archon to cut the version — or, when that is not available, run the session in Metic-mode as usual through Phases 1–4 and in Phase 5 file the proposals like this instead:
+   **Net-new version (idea 425).** The Metic-mode path above assumes the target version *already exists* — its criterion proposals carry `suggested_version` (an FK to a `versions` row) and a `target_version` that must match `versions.id`. **A Metic cannot create one:** `version.create` is **Archon-floored** ([ADR 0250](../../../docs/adr/0250-strict-versioning-the-version-boundary-is-the-scope-gate.md) §6, task 1003608 — ADR 0157 had briefly lowered it to Metic and that is reversed). So `POST /versions` returns `403` and the Metic has no valid FK to point at. Ask an Archon to cut the version — or, when that is not available, run the session in Metic-mode as usual through Phases 1–4 and in Phase 5 file the proposals like this instead:
 
    1. **OMIT `suggested_version` on every proposal row.** It is an FK to a version row that doesn't exist yet; leaving it set would fail the constraint (or worse, attach the proposal to the wrong existing version). Leave it `null`/absent.
    2. **Keep `target_version` INSIDE the criterion-proposal `body_md` JSON as plain text** (the version's intended id/slug, e.g. `"V4"`). It is *not* validated as an FK there — it's a label the Archon reads at ratify time. Once the Archon creates the real version row, the proposal is ratifiable as-is: `POST /api/gds/inbox/:id/ratify` resolves `target_version` against the now-existing `versions.id`.
@@ -159,7 +159,7 @@ Don't tunnel-vision. Surface lateral options the user might not have thought of:
 
 **Encourage short task descriptions with cross-refs.** Each task's description should focus on done-when + touches; reference dependency tasks by their R## rather than restating context. Long standalone descriptions are content-debt at scale (80 tasks × 200 words = a lot of redundant context).
 
-> **`touches[]` is an advisory hint, not a hard fence ([ADR 0049](../../../docs/adr/<redacted>.md)).** Parallel-safety is a *split contract*: for interactive single-human work, `git merge` is the authoritative collision detector and the claim-time overlap signal only warns; only the autonomous `--parallel` runner treats footprint overlap as a hard gate. So don't agonize over predicting every file at planning time — a rough blast-radius is enough, and a wrong prediction is no longer ship-blocking. (Step 7/8 — task [#882](https://example.com/builders#/task/882) — makes the per-task `touches` field optional and backfills it from the committed diff at ship.)
+> **`touches[]` is an advisory hint, not a hard fence ([ADR 0049](../../../docs/adr/0049-split-parallel-safety-contract.md)).** Parallel-safety is a *split contract*: for interactive single-human work, `git merge` is the authoritative collision detector and the claim-time overlap signal only warns; only the autonomous `--parallel` runner treats footprint overlap as a hard gate. So don't agonize over predicting every file at planning time — a rough blast-radius is enough, and a wrong prediction is no longer ship-blocking. (Step 7/8 — task [#882](https://example.com/builders#/task/882) — makes the per-task `touches` field optional and backfills it from the committed diff at ship.)
 
 **Write the brainstorm to a spec file — do NOT present a numbered chat list for e/r/a approval (that step is replaced by the Phase-4 interview).** Write `docs/specs/<ver>-<goal-slug>.md` (create `docs/specs/` if absent; slug = the goal's title kebab-cased). This file is the working document for the rest of the session and is committed in Phase 5. Give it these sections:
 
@@ -256,8 +256,8 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
      node scripts/gds/api.js POST /api/gds/goals --body '{"version_id":"<ver>","title":"...","scope_modules":["<key>", ...]}'
      # carry-forward goal: add "succeeds_goal_id":<prior_goal_id>
      ```
-   - **Criteria — the vector depends on whether the instance is LIVE ([ADR 0105](../../../docs/adr/<redacted>.md)):**
-     - **On a RUNNING instance (the normal case — planning a new goal/version on prod):** create each criterion via the **`POST /api/gds/versions/:id/done-when`** API (**Metic+ for a goal you own or manage — [ADR 0154](../../../docs/adr/<redacted>.md); Archon for a version-level criterion, someone else's goal, or a shipped/frozen version**), passing `criterion_id` (a stable slug), `criterion_md`, `goal_id` (the goal from above), and optional `sort_order`. This is the ONLY vector that actually lands a NEW criterion on a live DB — a `done_when_criteria` INSERT in a CORE migration **fails the `selfhost-boot` gate** (scope-truth pollution), and one in `migrations/instance/` **silently no-ops on a normal deploy** (ADR 0105 applies instance seeds only under the owner opt-in `GDS_APPLY_INSTANCE_SEEDS=1`, a DR step). A duplicate `criterion_id` returns 409 — treat as "already seeded."
+   - **Criteria — the vector depends on whether the instance is LIVE ([ADR 0105](../../../docs/adr/0105-instance-seed-migrations-out-of-core.md)):**
+     - **On a RUNNING instance (the normal case — planning a new goal/version on prod):** create each criterion via the **`POST /api/gds/versions/:id/done-when`** API (**Metic+ for a goal you own or manage — [ADR 0154](../../../docs/adr/0154-goal-owner-criterion-authoring.md); Archon for a version-level criterion, someone else's goal, or a shipped/frozen version**), passing `criterion_id` (a stable slug), `criterion_md`, `goal_id` (the goal from above), and optional `sort_order`. This is the ONLY vector that actually lands a NEW criterion on a live DB — a `done_when_criteria` INSERT in a CORE migration **fails the `selfhost-boot` gate** (scope-truth pollution), and one in `migrations/instance/` **silently no-ops on a normal deploy** (ADR 0105 applies instance seeds only under the owner opt-in `GDS_APPLY_INSTANCE_SEEDS=1`, a DR step). A duplicate `criterion_id` returns 409 — treat as "already seeded."
        ```
        node scripts/gds/api.js POST /api/gds/versions/<ver>/done-when --body '{"criterion_id":"<slug>","criterion_md":"...","goal_id":<gid>}'
        ```
@@ -266,10 +266,10 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
 
 3. **Write a seed script** at `scripts/gds/seed-<ver_slug>-tasks.js` modeled on `scripts/gds/seed-v3-tasks.js` containing:
    - The TASKS array — one entry per net-new task with full description, kind, discipline, priority, est_minutes, manual_degree, credits_reward, **optional** `touches` (see below), optional `promoted_idea_id`, `depends_on_refs: ['R##', ...]` (the dep edges captured during brainstorm), AND **`criterion_ids: ['Cn', ...]`** — the done-when criterion(s) this task gates. The brainstorm in Phase 3 is already grouped by criterion, so this is just transcribing that grouping. Use the positional `"Cn"` token (C1 = the version's first criterion); the server resolves it against the task's version at create (ADR 0025 / task 438). **This replaces the old `**Criterion:** Cn` prose** — don't write that line anymore; pass `criterion_ids` instead so the task is linked in `task_criteria` at creation and `/status` counts it with no backfill.
-   - **`touches` is now OPTIONAL (task 882 / [ADR 0049](../../../docs/adr/<redacted>.md)).** Omit it (or leave it blank) unless you already know a tight file set and want the advisory overlap signal during the brainstorm. At first `/builder-ship` the server backfills `touches[]` from the real committed diff — the declared set becomes what git actually reported. Don't burn planning effort predicting file lists; a rough or absent prediction is fine and no longer ship-blocking.
-   - **`requires_rank` AUTO-DERIVES — you don't hand-set it per task (task [#1498](https://example.com/builders#/task/1498) / [ADR 0084](../../../docs/adr/<redacted>.md)).** On create the server floors a task at `metic` when it is `security_sensitive` or its `touches` reach the permission / authz / ship-grade / deploy / migration core (the same protected paths a sub-Metic builder can't push to); everything else stays the open `xenos` default. To deliberately gate a task **higher** than the auto-floor (e.g. owner-only work), pass `requires_rank: 'metic' | 'archon'` on the task — it can only RAISE the floor, never drop below it.
+   - **`touches` is now OPTIONAL (task 882 / [ADR 0049](../../../docs/adr/0049-split-parallel-safety-contract.md)).** Omit it (or leave it blank) unless you already know a tight file set and want the advisory overlap signal during the brainstorm. At first `/builder-ship` the server backfills `touches[]` from the real committed diff — the declared set becomes what git actually reported. Don't burn planning effort predicting file lists; a rough or absent prediction is fine and no longer ship-blocking.
+   - **`requires_rank` AUTO-DERIVES — you don't hand-set it per task (task [#1498](https://example.com/builders#/task/1498) / [ADR 0084](../../../docs/adr/0084-auto-derived-per-task-rank-floor.md)).** On create the server floors a task at `metic` when it is `security_sensitive` or its `touches` reach the permission / authz / ship-grade / deploy / migration core (the same protected paths a sub-Metic builder can't push to); everything else stays the open `xenos` default. To deliberately gate a task **higher** than the auto-floor (e.g. owner-only work), pass `requires_rank: 'metic' | 'archon'` on the task — it can only RAISE the floor, never drop below it.
    - **Pass `goal_id: <gid>` on each task** so it lands under its goal (not the version's default catch-all). `POST /tasks` now honors `goal_id` (validated to belong to the version); to move an already-created task, `PATCH /tasks/:id` with `{goal_id}` (task 1763). `criterion_ids` accepts a **slug** (the `criterion_id` you set above), a `"Cn"` position, or a numeric id — the slug is position-independent and cleanest.
-   - A main() that POSTs each task **with its `criterion_ids`** (idempotent on `source_ref`; the criterion links are inserted at create, idempotent on `(task_id, criterion_id)`), PATCHes `idea_inbox` for promotions, and after all tasks exist, POSTs `task_dependencies` via `POST /tasks/:id/dependencies` (resolving each R## to the just-created task ID). Idempotent on `(task_id, depends_on_task_id)`. (Need to re-attribute an already-seeded task? `POST /tasks/:id/criteria` with `{criterion_ids:['Cn',...]}`; `DELETE /tasks/:id/criteria/:criterionId` to detach — both Metic+ ([ADR 0090](../../../docs/adr/<redacted>.md)), mirroring the dependency endpoints.)
+   - A main() that POSTs each task **with its `criterion_ids`** (idempotent on `source_ref`; the criterion links are inserted at create, idempotent on `(task_id, criterion_id)`), PATCHes `idea_inbox` for promotions, and after all tasks exist, POSTs `task_dependencies` via `POST /tasks/:id/dependencies` (resolving each R## to the just-created task ID). Idempotent on `(task_id, depends_on_task_id)`. (Need to re-attribute an already-seeded task? `POST /tasks/:id/criteria` with `{criterion_ids:['Cn',...]}`; `DELETE /tasks/:id/criteria/:criterionId` to detach — both Metic+ ([ADR 0090](../../../docs/adr/0090-metic-task-authoring.md)), mirroring the dependency endpoints.)
 
 > **Seeding contract — validated on goal 1000045 (2026-07-16):** proof-tasks use `kind='verify'` (a deliverable that IS a verification; can't be prematurely confirmed), spikes `kind='spike'`; `POST /tasks` accepts `criterion_ids` + `goal_id` inline and disciplines include `ui`; there is **no `promoted_idea_id`** field on `POST /tasks` — mark a promoted idea via `PATCH /inbox/:id`; **descoping a criterion has no API** (done-when is create/satisfy/unsatisfy only) — remove the row via a direct DB delete (`ssh … "sudo -u postgres psql -d <db> -c \"DELETE FROM done_when_criteria WHERE id=…\""`) under the meta-task claim, capturing the SQL in its notes; and a seed script **must throttle + honor `429` `retry_after`** (per-IP rate limit) — add a base delay between calls and back off on 429, or a large seed dies halfway. A completed reference seed: `scripts/gds/<redacted>.js`.
 >
@@ -314,7 +314,7 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
    RETURNING id, title, priority, kind;
    ```
 
-   Capture the `RETURNING` rows — the max `priority` value is the input for step 7. Spikes are intentionally excluded; they never auto-promote (kind='spike' convention, [ADR 0015](../../../docs/adr/<redacted>.md)).
+   Capture the `RETURNING` rows — the max `priority` value is the input for step 7. Spikes are intentionally excluded; they never auto-promote (kind='spike' convention, [ADR 0015](../../../docs/adr/0015-task-dependencies-and-auto-promotion.md)).
 
 7. **Surface higher-priority spikes still in backlog.** Spikes don't auto-flow because their output reshapes downstream work — that's a feature, not a bug. But the planning session just decided the priority order, so a high-priority spike sitting unstarted while lower-priority non-spike work flows to `ready` is a coordination smell worth one explicit mention. Query:
 
@@ -332,7 +332,7 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
 
    If the query returns rows, surface them to the user verbatim:
 
-   > "Heads up — these spikes sit at priority ≥ the top of your ready queue. They don't auto-promote (kind='spike', [ADR 0015](../../../docs/adr/<redacted>.md)). If any gates downstream work, open it manually: `POST /api/gds/tasks/<id>/promote`"
+   > "Heads up — these spikes sit at priority ≥ the top of your ready queue. They don't auto-promote (kind='spike', [ADR 0015](../../../docs/adr/0015-task-dependencies-and-auto-promotion.md)). If any gates downstream work, open it manually: `POST /api/gds/tasks/<id>/promote`"
 
    If the query returns nothing, stay silent. Don't volunteer info about lower-priority spikes — the next planning session or `/idea-triage` walk will handle those at the right moment.
 

package/.claude/skills/recall/SKILL.md

@@ -8,7 +8,7 @@ You are answering "what do we already know about X?" — the GDS-V4 one-call-rec
 
 ## Two-step flow: summary first, then expand (progressive disclosure)
 
-Recall uses **progressive disclosure with token-cost visibility** ([ADR 0095](../../../docs/adr/<redacted>.md) C1). You don't pay for the full corpus in one shot:
+Recall uses **progressive disclosure with token-cost visibility** ([ADR 0095](../../../docs/adr/0095-borrowed-memory-and-retrieval-concepts.md) C1). You don't pay for the full corpus in one shot:
 
 1. **Step 1 — the summary layer.** `recall <query>` returns a *ranked, compact* list: each hit is a title, breadcrumb, snippet, and a **token-cost label** — `~N tok` is what a full read of that hit would cost, and a `~N tokens to expand all` headline totals the whole result set. You see what a deeper read will COST before you pay for it.
 2. **Step 2 — expand the one you want.** `recall --expand <id>` fetches just that hit's full content (the id is the `#NNN` printed at the head of each result line). Spend tokens only on the hit that actually answers the question — typically one, not all ten.
@@ -43,7 +43,7 @@ Each summary result shows the hit id (`#NNN`, the handle for `--expand`), the ti
 
 ## Constraints
 
-- **Read-only + rank-scoped.** Results are filtered server-side to your live rank + your own private chunks ([ADR 0060](../../../docs/adr/0060-gds-retrieval-layer.md) §6 / [ADR 0016](../../../docs/adr/<redacted>.md)) — a sub-Metic session will not see permission-core docs, and you never see another builder's private memory. Don't try to widen scope via flags; there's no such flag.
+- **Read-only + rank-scoped.** Results are filtered server-side to your live rank + your own private chunks ([ADR 0060](../../../docs/adr/0060-gds-retrieval-layer.md) §6 / [ADR 0016](../../../docs/adr/0016-trust-boundary-server-enforced-permissions.md)) — a sub-Metic session will not see permission-core docs, and you never see another builder's private memory. Don't try to widen scope via flags; there's no such flag.
 - **Authenticated.** Recall searches *as you*, so it needs a builder session (`/builder-setup` once). A 401 means "sign in first."
 - Don't paste the raw JSON at the user unless they ask — summarize + cite.
 

package/.claude/skills/strand-fix/SKILL.md

@@ -35,7 +35,7 @@ node scripts/gds/skill-preflight.js strand-fix   # exits 1 naming what is MISSIN
 2. **Pick the ONE matching case.**
    - **A. A main commit carries `(task N` and the post-merge `unit` + `main-audit` on main are green** (`gh run list --branch main --limit 4`): the land happened; only the proof failed. The proof is the claim's recorded tip (`claims.published_head_sha`, task 1547) being an ancestor of main — and a `no_branch_no_tip` claim has none (the work rode in on another branch, e.g. a cloud-agent batch, or a `--here` claim). **Record the tip first**: the owner (Archon) sets that column on the task's latest claim to the full 40-char SHA of the main commit — a direct DB write on the box as the DB owner, so it runs under this task's own ledger with the SQL in the ship note (`UPDATE claims SET published_head_sha = '<sha>' WHERE id = (SELECT id FROM claims WHERE task_id = N ORDER BY claimed_at DESC, id DESC LIMIT 1)`). Then the reconciler proves it within ≤5 min, or flip it yourself: `node scripts/gds/api.js POST /api/gds/tasks/N/ship --body '{}'`. Never `no_artifact: true` here — the artifact exists, and the ledger would record a falsehood. Credits land on the flip (ADR 0120). (Before task 1003434 the manual POST refused even with a tip when the claim had no branch; the reconciler path always worked.)
    - **B. A local branch exists with commits ahead of `origin/main` and no PR**: the ship never pushed. From that worktree: `git push -u origin <branch>` then `gh pr create --base main --head <branch> --fill`. Green `unit` → server auto-merge → the reconciler flips it within ~5 min. If it merges but does not flip, do **A**.
-   - **C. A PR exists but is `CONFLICTING`**: the branch owner rebases it (`git merge origin/main`, resolve, push) — not this skill, and never `--force`. Report the PR URL and stop.
+   - **C. A PR exists but is `CONFLICTING`**: the branch owner brings it up to date — `git merge origin/main`, resolve, push — not this skill, and never `--force`. **Merge, never rebase** (task 1002788): the branch is already published and the server's publish is append-only, so rewriting its history makes every later push non-fast-forward and the task un-landable while the claim gate keeps the owner's queue shut. Report the PR URL and stop.
    - **D. Nothing anywhere** — no branch, no PR, no commit: a codeless confirm. Ask what the task delivered. Work done outside this repo (on the box's instance checkout, a DB-only change captured in the ship note) is legitimately artifact-free → **A** with the reason in the ship body: `--body '{"note":"codeless: <where the work lives>"}'`. If the work was never done, release it instead so it returns to `ready`: `node scripts/gds/release.js N --reason "stranded codeless confirm; nothing delivered"`.
 3. **Verify**: `node scripts/gds/api.js GET /api/gds/tasks/N` → `"status": "shipped"` (or `ready` after a release). Re-run `strand-watch.js --line` — the task must be gone from it. If the claim gate was the symptom, `claim.js` now succeeds.
 

package/.devcontainer/README.md

@@ -1,8 +1,8 @@
 # The Example Dev Box (`.devcontainer/`)
 
-This folder is **the box defined as code** — [ADR 0031 §3](../docs/adr/<redacted>.md). It is the single environment every OTB builder runs Claude Code's *worker* in, whether they reach it from Claude Desktop → SSH, from the web → Remote Control, or locally via Docker Desktop. The same spec builds and runs identically on a DigitalOcean box and on a laptop.
+This folder is **the box defined as code** — [ADR 0031 §3](../docs/adr/0031-cloud-dev-environments-for-builders.md). It is the single environment every OTB builder runs Claude Code's *worker* in, whether they reach it from Claude Desktop → SSH, from the web → Remote Control, or locally via Docker Desktop. The same spec builds and runs identically on a DigitalOcean box and on a laptop.
 
-> Recall the mental model ([ADR 0031 "mental model"](../docs/adr/<redacted>.md), and [the onboarding primer](../docs/onboarding/primer.md)): the **screen** is your device, the **brain** is Anthropic's servers, and this is the **worker** — where the repo lives and the work happens.
+> Recall the mental model ([ADR 0031 "mental model"](../docs/adr/0031-cloud-dev-environments-for-builders.md), and [the onboarding primer](../docs/onboarding/primer.md)): the **screen** is your device, the **brain** is Anthropic's servers, and this is the **worker** — where the repo lives and the work happens.
 
 ## What's here
 

package/CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 Cloud Bongos is an **AI-first build platform**: AI agents write the code. A human owner sets scope, direction, and the hard gates (rank, approval, deploy); the day-to-day building — code, docs, migrations, reviews — is done by AI agents claiming tasks. This guide is written for that reader.
 
-> The governing decisions behind these norms: [ADR 0065](docs/adr/<redacted>.md) (license + non-profit + AI-first) and [GOVERNANCE.md](GOVERNANCE.md).
+> The governing decisions behind these norms: [ADR 0065](docs/adr/0065-agpl-nonprofit-ai-first-governance.md) (license + non-profit + AI-first) and [GOVERNANCE.md](GOVERNANCE.md).
 
 ## License of your contributions
 
@@ -29,7 +29,7 @@ Full methodology and the host-instance specifics live in [`CLAUDE.md`](CLAUDE.md
 
 ## Ranks and what you can touch
 
-Permissions are **server-enforced on the live database, per request, with no caching** — editing local files grants nothing ([ADR 0016](docs/adr/<redacted>.md)). The ladder is **Xenos → Thetes → Metic → Archon** (Newcomer → Contributor → Trusted → Owner); full detail in [`docs/canonical-permissions.md`](docs/canonical-permissions.md).
+Permissions are **server-enforced on the live database, per request, with no caching** — editing local files grants nothing ([ADR 0016](docs/adr/0016-trust-boundary-server-enforced-permissions.md)). The ladder is **Xenos → Thetes → Metic → Archon** (Newcomer → Contributor → Trusted → Owner); full detail in [`docs/canonical-permissions.md`](docs/canonical-permissions.md).
 
 - Newcomers (Xenos/Thetes) claim feature work but **stay out of the permission/methodology core** (rank/authz machinery, the ship/grade/deploy pipeline, `migrations/`, `infra/`, trust-boundary docs) and never run a raw `git push origin main`, `ssh` to prod, or a deploy script — landing code is the platform's job (claim a task and ship).
 - Metic+ may work the build pipeline and gate-surfaces.

package/GOVERNANCE.md

@@ -2,7 +2,7 @@
 
 How Cloud Bongos is governed, and the commitments that keep it a commons.
 
-Cloud Bongos is an **AI-first build platform**: a human owner sets scope and the hard gates; AI agents claim tasks and write the code. This document describes how the project is run and the promises that protect it from capture. The binding decision behind it is [ADR 0065](docs/adr/<redacted>.md).
+Cloud Bongos is an **AI-first build platform**: a human owner sets scope and the hard gates; AI agents claim tasks and write the code. This document describes how the project is run and the promises that protect it from capture. The binding decision behind it is [ADR 0065](docs/adr/0065-agpl-nonprofit-ai-first-governance.md).
 
 ## Principles
 
@@ -16,7 +16,7 @@ Cloud Bongos is an **AI-first build platform**: a human owner sets scope and the
 
 ## Who decides what
 
-Authority is **server-enforced**, not document-granted. A builder editing local files (including this one) gains no authority; the platform re-checks rank on the live database, per request, with no caching ([ADR 0016](docs/adr/<redacted>.md)). The rank ladder (kept as the platform's canonical permission model; full detail in [`docs/canonical-permissions.md`](docs/canonical-permissions.md)):
+Authority is **server-enforced**, not document-granted. A builder editing local files (including this one) gains no authority; the platform re-checks rank on the live database, per request, with no caching ([ADR 0016](docs/adr/0016-trust-boundary-server-enforced-permissions.md)). The rank ladder (kept as the platform's canonical permission model; full detail in [`docs/canonical-permissions.md`](docs/canonical-permissions.md)):
 
 | Rank | Role |
 |---|---|
@@ -37,8 +37,8 @@ Non-obvious decisions are recorded as **ADRs** ([`docs/adr/`](docs/adr/)). Signi
 
 ## Releasing to the public
 
-The public mirror is **generated** from the private instance-1 repository on a deliberate, **~6-month-delayed** cadence, carrying only the publishable subset (the portable core + platform — never a host's identity, secrets, content, or in-window development). The boundary and the delay are defined in [ADR 0065](docs/adr/<redacted>.md) §4 and implemented by the C9 export pipeline (R71/R72), with a lineage/no-leak proof (R73).
+The public mirror is **generated** from the private instance-1 repository on a deliberate, **~6-month-delayed** cadence, carrying only the publishable subset (the portable core + platform — never a host's identity, secrets, content, or in-window development). The boundary and the delay are defined in [ADR 0065](docs/adr/0065-agpl-nonprofit-ai-first-governance.md) §4 and implemented by the C9 export pipeline (R71/R72), with a lineage/no-leak proof (R73).
 
 ## Changing this document
 
-This document and the commitments in it change the way any other governed decision does: a claimed task, an ADR recording the rationale, and the owner's approval. The license and non-profit posture are foundational — changing them would require a new ADR that explicitly supersedes [ADR 0065](docs/adr/<redacted>.md), and they exist precisely to be hard to quietly undo.
+This document and the commitments in it change the way any other governed decision does: a claimed task, an ADR recording the rationale, and the owner's approval. The license and non-profit posture are foundational — changing them would require a new ADR that explicitly supersedes [ADR 0065](docs/adr/0065-agpl-nonprofit-ai-first-governance.md), and they exist precisely to be hard to quietly undo.