@bongos/core 1.19.714 → 1.19.724

package/docs/adr/0135-module-upstream-submission-interim-queue.md

@@ -3,7 +3,7 @@
 - **Status:** Accepted
 - **Date:** 2026-07-08
 - **Task:** [#1770](https://example.com/builders#/task/1770) (BONGOS-V1) — `bongos module submit` + `POST /modules/:key/submit`.
-- **Builds on:** [ADR 0107](<redacted>.md) (the upstreaming decision — submit → review → accept), [ADR 0103](<redacted>.md) (the core extracted to `github.com/example-owner/cloud-bongos`, private), [ADR 0100](<redacted>.md) §3 (per-repo GDS — each project runs its own DB).
+- **Builds on:** [ADR 0107](0107-module-upstreaming-contribution-to-core-catalog.md) (the upstreaming decision — submit → review → accept), [ADR 0103](0103-core-first-extraction-cloud-bongos-trunk.md) (the core extracted to `github.com/example-owner/cloud-bongos`, private), [ADR 0100](0100-two-repo-instance-model.md) §3 (per-repo GDS — each project runs its own DB).
 
 ## Context
 

package/docs/adr/0136-update-channel-subscription-policy.md

@@ -2,7 +2,7 @@
 
 **Date:** 2026-07-10
 **Status:** Accepted.
-**Context:** [task 2150](https://example.com/builders#/task/2150) (BONGOS-V1, goal 26). The last piece of the update-consumption workstream: [ADR 0100](<redacted>.md) §2 / [task 1690](https://example.com/builders#/task/1690) gave a consumer the manual `bongos upgrade` channel; [ADR 0134](<redacted>.md) / [task 2090](https://example.com/builders#/task/2090) added the private-registry source; [task 2149](https://example.com/builders#/task/2149) added auto-rollback; [task 2157](https://example.com/builders#/task/2157) proved rollback live on the demo instance. What was missing is the **subscription** — how a consumer instance takes new releases *on a cadence, unattended*, rather than a human running `bongos upgrade` each time. Builds on the scheduled-routines portability contract ([ADR 0115](<redacted>.md)).
+**Context:** [task 2150](https://example.com/builders#/task/2150) (BONGOS-V1, goal 26). The last piece of the update-consumption workstream: [ADR 0100](0100-two-repo-instance-model.md) §2 / [task 1690](https://example.com/builders#/task/1690) gave a consumer the manual `bongos upgrade` channel; [ADR 0134](0134-private-first-npm-distribution.md) / [task 2090](https://example.com/builders#/task/2090) added the private-registry source; [task 2149](https://example.com/builders#/task/2149) added auto-rollback; [task 2157](https://example.com/builders#/task/2157) proved rollback live on the demo instance. What was missing is the **subscription** — how a consumer instance takes new releases *on a cadence, unattended*, rather than a human running `bongos upgrade` each time. Builds on the scheduled-routines portability contract ([ADR 0115](0115-scheduled-routines-portability.md)).
 
 ## Problem
 
@@ -30,7 +30,7 @@ A **major** bump is never automatic under any channel — a breaking change want
 - **Opt-in** — the roster [`config/update-subscriptions.json`](../../config/update-subscriptions.json) ships **empty**; an instance is touched only after an operator lists it (with its dir, systemd unit, health URL, channel, and an optional `env` map so `migrate` hits the right DB).
 - **Health-gated** — per (3).
 
-The routine is `mode: deterministic` (System 4, [ADR 0078](<redacted>.md)) — it runs as plain `node` with no model session — and **instance-wide** (ADR 0115): one run per instance iterating the roster, not one cron per instance-being-watched.
+The routine is `mode: deterministic` (System 4, [ADR 0078](0078-deterministic-first-cron.md)) — it runs as plain `node` with no model session — and **instance-wide** (ADR 0115): one run per instance iterating the roster, not one cron per instance-being-watched.
 
 **5. Upstream auto-publish is explicitly split out, not decided here.** For a subscription to deliver anything, new patches must be *published*. Today that is a gated owner step (`package-core.js --publish --live`, ADR 0134). This ADR deliberately scopes the subscription to **consume whatever the owner has published** and does **not** decide whether merges to `main` auto-publish a patch. That is its own decision (publishing cadence, provenance, who holds the token) and is filed as [task 2158](https://example.com/builders#/task/2158). Splitting it lets goal 26 close on the consumption half, which is what the switchover needs.
 

package/docs/adr/0137-upstream-publish-policy-manual-owner-gated.md

@@ -1,16 +1,16 @@
 # 0137 — Upstream publish policy: `@bongos/core` patches are published manually (owner-gated), not auto-published on merge
 
-- **Status:** Superseded by [ADR 0161](<redacted>.md) (2026-08-08) — after two measured stale-production incidents (171 commits/10 days, 104 commits/5 days), the owner chose publish-on-merge; the "When to revisit" clause below fired.
+- **Status:** Superseded by [ADR 0161](0161-publish-on-merge.md) (2026-08-08) — after two measured stale-production incidents (171 commits/10 days, 104 commits/5 days), the owner chose publish-on-merge; the "When to revisit" clause below fired.
 - **Date:** 2026-07-10
 - **Deciders:** example-owner (owner/Archon), Claude. Presented the manual-vs-auto fork; the owner chose to keep publishing a manual, owner-triggered step.
-- **Task:** [#2158](https://example.com/builders#/task/2158) (BONGOS-V1, goal 26) — the **supply** half split out of [ADR 0136](<redacted>.md) §5 / [#2150](https://example.com/builders#/task/2150).
-- **Builds on:** [ADR 0134](<redacted>.md) (private-first npm, tokenless tooling), [ADR 0136](<redacted>.md) (subscription consumption policy). **Relates to:** the deferred managed-fleet-control-plane epic ([#1948](https://example.com/builders#/task/1948)).
+- **Task:** [#2158](https://example.com/builders#/task/2158) (BONGOS-V1, goal 26) — the **supply** half split out of [ADR 0136](0136-update-channel-subscription-policy.md) §5 / [#2150](https://example.com/builders#/task/2150).
+- **Builds on:** [ADR 0134](0134-private-first-npm-distribution.md) (private-first npm, tokenless tooling), [ADR 0136](0136-update-channel-subscription-policy.md) (subscription consumption policy). **Relates to:** the deferred managed-fleet-control-plane epic ([#1948](https://example.com/builders#/task/1948)).
 
 ## Context
 
-[ADR 0136](<redacted>.md) (task 2150) built the **consumption** half of the `@bongos/core` update subscription — the channel math (`pinned`/`patch`/`minor`, never `major`/prerelease unattended) and the auto-upgrade routine that consumes published releases on a cadence. It explicitly deferred (§5) the **supply** half: *"does not decide whether merges to `main` auto-publish a patch. That is its own decision (publishing cadence, provenance, who holds the token)."* This ADR is that decision.
+[ADR 0136](0136-update-channel-subscription-policy.md) (task 2150) built the **consumption** half of the `@bongos/core` update subscription — the channel math (`pinned`/`patch`/`minor`, never `major`/prerelease unattended) and the auto-upgrade routine that consumes published releases on a cadence. It explicitly deferred (§5) the **supply** half: *"does not decide whether merges to `main` auto-publish a patch. That is its own decision (publishing cadence, provenance, who holds the token)."* This ADR is that decision.
 
-Today, per [ADR 0134](<redacted>.md), publishing is a **gated owner step**: `node scripts/gds/package-core.js --publish --live` requires the owner's `npm login` + 2FA, and *the repo/tooling holds no token* ("npm owns auth — this repo never stores a token"). Consumers install with a **read-only** token via an env-fed `.npmrc`. For a subscription to deliver anything, new patches must be published — so the open question was whether to **automate** that publish (on-merge, using a CI-stored write token) or keep it **manual**.
+Today, per [ADR 0134](0134-private-first-npm-distribution.md), publishing is a **gated owner step**: `node scripts/gds/package-core.js --publish --live` requires the owner's `npm login` + 2FA, and *the repo/tooling holds no token* ("npm owns auth — this repo never stores a token"). Consumers install with a **read-only** token via an env-fed `.npmrc`. For a subscription to deliver anything, new patches must be published — so the open question was whether to **automate** that publish (on-merge, using a CI-stored write token) or keep it **manual**.
 
 ## Decision
 
@@ -20,7 +20,7 @@ Today, per [ADR 0134](<redacted>.md), publishing is a **gated owner step**: `nod
 2. **Version-bump provenance — deliberate, in-task.** `CORE_VERSION` (`src/module-api.js`) is bumped by hand as part of a task, with a changelog line in the same file (the existing discipline — e.g. task 2148 bumped `1.17.1 → 1.17.2` with a changelog entry). It is **not** auto-bumped. A release publishes whatever `CORE_VERSION` currently is; a stale (un-bumped) version collides with the already-published npm version and npm rejects the duplicate — a natural guard against an accidental no-op republish.
 3. **Token custody — no write-token at rest.** No npm **write** token is stored in CI or the repo. The owner authenticates at publish time (a Classic Automation token bypasses the interactive 2FA-OTP prompt when scripting locally; interactive `npm login` + 2FA otherwise). This preserves ADR 0134's tokenless-tooling posture. Only the **read** token (for consumer / CI installs, env-fed `NPM_TOKEN`) exists.
 4. **No-leak / mirror-redact gate — already fail-closed.** `package-core.js` builds the artifact *through* the no-leak gate (docs genericized + secret-scrubbed; functional files scanned for a live-credential leak) and **produces nothing** if anything leaks, so `--publish` structurally cannot upload a leaking artifact. No extra gate is needed for the manual path — and any future automated path inherits the same fail-closed gate because it runs the same build.
-5. **The subscription is unchanged.** The [ADR 0136](<redacted>.md) routine consumes whatever the owner has published. Its freshness is bounded by the owner's release cadence — intended and acceptable at current scale.
+5. **The subscription is unchanged.** The [ADR 0136](0136-update-channel-subscription-policy.md) routine consumes whatever the owner has published. Its freshness is bounded by the owner's release cadence — intended and acceptable at current scale.
 
 ## Why manual over auto (the trade-off)
 

package/docs/adr/0138-bundled-module-deps-declared-per-module.md

@@ -4,11 +4,11 @@
 - **Date:** 2026-07-10
 - **Deciders:** example-owner (owner/Archon), Claude. Presented the fork (keep core lean + declare per-module vs. hoist the dep into `@bongos/core`); the owner chose to keep core lean.
 - **Task:** [#2160](https://example.com/builders#/task/2160) (BONGOS-V1, goal 26) — rehearsal finding **F2** from the R89 cutover rehearsal ([`docs/reviews/<redacted>.md`](../reviews/<redacted>.md)).
-- **Builds on:** [ADR 0108](<redacted>.md) (core consumed as a pinned npm dep; core deps = express+pg), [ADR 0083](<redacted>.md) (the module manifest contract).
+- **Builds on:** [ADR 0108](0108-instance-composition-configurable-root.md) (core consumed as a pinned npm dep; core deps = express+pg), [ADR 0083](0083-modular-architecture-strangler-build-plan.md) (the module manifest contract).
 
 ## Context
 
-The R89 cutover rehearsal converted the example monolith into a `@bongos/core` consumer and surfaced **F2**: with `dependencies: { "@bongos/core" }` alone the consumer boots and then crashes on `Cannot find module 'colyseus'` — and, more subtly, on `Cannot find module 'discord.js'`. The game/art deps (`colyseus`, `phaser`, `sharp`) are obviously the host's. But `discord.js` is different: the **discord module ships INSIDE `@bongos/core`** (it's one of the ~15 bundled core modules), yet `package-core.js` synthesizes only `express` + `pg` as the core's `dependencies` ([ADR 0108](<redacted>.md) §Context). So the core ships the discord module's *code* but declares none of its *runtime dep* — the consumer is silently expected to provide `discord.js`, with a boot crash as the only feedback.
+The R89 cutover rehearsal converted the example monolith into a `@bongos/core` consumer and surfaced **F2**: with `dependencies: { "@bongos/core" }` alone the consumer boots and then crashes on `Cannot find module 'colyseus'` — and, more subtly, on `Cannot find module 'discord.js'`. The game/art deps (`colyseus`, `phaser`, `sharp`) are obviously the host's. But `discord.js` is different: the **discord module ships INSIDE `@bongos/core`** (it's one of the ~15 bundled core modules), yet `package-core.js` synthesizes only `express` + `pg` as the core's `dependencies` ([ADR 0108](0108-instance-composition-configurable-root.md) §Context). So the core ships the discord module's *code* but declares none of its *runtime dep* — the consumer is silently expected to provide `discord.js`, with a boot crash as the only feedback.
 
 Two facts frame the decision:
 
@@ -28,14 +28,14 @@ So the open question (rehearsal F2, "separately decide"): should `@bongos/core`
 
 ## Why lean-core over hoisting (the trade-off)
 
-- **Hoisting bloats the common case.** `optionalDependencies` still install by default, so declaring `discord.js` in core makes **every** consumer download it (and its transitive `undici`, WebSocket stack, …) for a module that is **off by default**. That directly cuts against [ADR 0108](<redacted>.md)'s deliberate lean-core choice.
+- **Hoisting bloats the common case.** `optionalDependencies` still install by default, so declaring `discord.js` in core makes **every** consumer download it (and its transitive `undici`, WebSocket stack, …) for a module that is **off by default**. That directly cuts against [ADR 0108](0108-instance-composition-configurable-root.md)'s deliberate lean-core choice.
 - **`peerDependencies` don't fix the crash.** An *optional* peer dep is not auto-installed by npm, so the boot crash would remain; a *required* peer dep is just hoisting with extra warnings.
 - **Per-module declaration is honest and scales.** The dep lives with the code that needs it, the manifest stays the single source of truth for "what this module is," and the pattern generalizes to any future module without re-touching core.
 - **`--omit=optional` is opt-out, not opt-in.** Relying on consumers to prune an unwanted dep is the wrong default; composing only enabled modules' deps is opt-in by construction.
 
 ## Consequences
 
-- **`@bongos/core`'s dependency surface stays minimal + auditable** — the property [ADR 0108](<redacted>.md) and `package_core.mjs` (`dependencies == { express, pg }`) already lock in.
+- **`@bongos/core`'s dependency surface stays minimal + auditable** — the property [ADR 0108](0108-instance-composition-configurable-root.md) and `package_core.mjs` (`dependencies == { express, pg }`) already lock in.
 - **A bundled module with an external dep MUST declare it** in `module.json` `dependencies`, or a consumer that enables it crashes at boot. Documented in [`docs/modules-contract.md`](../modules-contract.md).
 - **Greenfield/adopt** instances that enable a module get its deps automatically; the **R89 cutover** stays a preserve-existing-closure step.
 - **No new standing credential or CI machinery** — this is authoring-time composition, not an install-time core change.

package/docs/adr/0142-project-context-is-prose-only.md

@@ -4,7 +4,7 @@
 - **Date:** 2026-07-13
 - **Deciders:** Claude (acting builder, autonomous session under goal 1000042); owner to ratify. Presented the fork the audit named — build a structured neutral+instance+resolver for project context (mirroring branding), or keep project context prose-only — and chose prose-only.
 - **Task:** [#1002224](https://example.com/builders#/task/1002224) (BONGOS-V1, goal 1000042 — *Harden the Cloud Bongos update pipeline*). Closes hardening item **H11** / finding **F7** of [`docs/audits/update-pipeline-audit.md`](../audits/update-pipeline-audit.md).
-- **Builds on:** [ADR 0062](<redacted>.md) §7 (the core↔host split — CLAUDE.md is portable methodology; host identity lives beside it), the branding contract ([`docs/branding-contract.md`](../branding-contract.md), [`src/branding.js`](../../src/branding.js)), and the agent-doc stub (task 2121).
+- **Builds on:** [ADR 0062](0062-medusa-instance-model-decoupling.md) §7 (the core↔host split — CLAUDE.md is portable methodology; host identity lives beside it), the branding contract ([`docs/branding-contract.md`](../branding-contract.md), [`src/branding.js`](../../src/branding.js)), and the agent-doc stub (task 2121).
 
 ## Context
 
@@ -25,7 +25,7 @@ Concretely, the contract is:
 ## Why prose-only over a structured resolver (the trade-off)
 
 - **No consumer → YAGNI.** A structured resolver earns its keep only when *code* must read merged, validated fields with env precedence — exactly branding's job, which already exists. Nothing in the platform reads a "project-context object": it is documentation. Building a second resolver, schema, and validation layer for a thing only agents read is speculative infrastructure against the bootstrapped posture ([CLAUDE.md §4](../../CLAUDE.md)).
-- **It matches the core↔host split as already drawn** ([ADR 0062](<redacted>.md) §7): CLAUDE.md is portable methodology; the host authors identity beside it — the *strings code reads* in branding (structured), the *prose agents read* in project-context (narrative). F7 is not a gap in that split; it is the split working as designed.
+- **It matches the core↔host split as already drawn** ([ADR 0062](0062-medusa-instance-model-decoupling.md) §7): CLAUDE.md is portable methodology; the host authors identity beside it — the *strings code reads* in branding (structured), the *prose agents read* in project-context (narrative). F7 is not a gap in that split; it is the split working as designed.
 - **Redaction stays simple + correct.** Project-context prose flows through the same doc-redaction + publish-exclusion path as every other doc. A structured project-context file would add another schema the no-leak gate and the `init` flow must understand, for no functional gain.
 - **One place to add a host string.** "Where does a new instance-identity value go?" has a single answer — branding — instead of a judgment call between two parallel contracts.
 

package/docs/adr/0143-onboarding-repo-picker-oauth-scope.md

@@ -14,7 +14,7 @@ Blocker: the wizard's GitHub sign-in requests only `read:user` ([auth.js `SCOPE`
 - **(A) Broaden the OAuth scope** and act as the user via their own token.
 - **(B) A central "Cloud Bongos" GitHub App** the user installs (fine-grained `Administration:write` to create, `Metadata:read` to list).
 
-The existing per-instance GitHub **App-manifest** flow ([ADR 0133](<redacted>.md)) is *not* reusable here — it builds a sign-in-only App with `default_permissions:{}`, one per provisioned instance, not a central repo-acting App.
+The existing per-instance GitHub **App-manifest** flow ([ADR 0133](0133-github-app-manifest-onboarding-signin.md)) is *not* reusable here — it builds a sign-in-only App with `default_permissions:{}`, one per provisioned instance, not a central repo-acting App.
 
 ## Decision
 
@@ -23,7 +23,7 @@ The existing per-instance GitHub **App-manifest** flow ([ADR 0133](<redacted>.md
 1. **Scope = `public_repo`, not `repo`.** There is no OAuth scope for "create a repo only"; `repo` grants read/write to *all* the user's code (public **and** private) — a serious liability for a token we now persist on an internet-facing tier. `public_repo` lists/creates **public** repos with a much gentler consent screen and a far smaller blast radius. Cloud Bongos instances are open-source / capture-resistant by design, so public is the norm. **Accepted limitation:** private repos can't be listed/adopted or created; revisit to `repo` only if private support is needed.
 2. **Opt-in per sign-in.** The scope is requested **only** by the wizard, via `?repos=1` on `/auth/web/start` (a `gds_oauth_repos` intent cookie carried to the callback). The builders'-hall web sign-in and the CLI Device Flow stay `read:user`. A single pure `scopeForWebFlow({repos})` is the one place the scope string is decided (unit-tested).
 3. **Lazy consent.** The step-0 gate sign-in stays identity-only; repo access is requested at **step 2**, when the user reaches the picker/creator — more private, and the "grant access" path is the well-exercised normal path.
-4. **Token persistence, contained.** The captured `public_repo` token is stored **encrypted** (secret-box, master key in server env only) in `github_oauth_tokens` (migration `core_192`), keyed to the builder, with a **short TTL (1h = one wizard sitting)** and a lazy expiry sweep on read. This lives in **core auth**, not the provisioning module: it is the auth system's *own* handshake token, not a feature's third-party API key (contrast the art module's Gemini key, [ADR 0102](<redacted>.md)), and the provisioning module's charter forbids holding tokens / calling cloud APIs ([ADR 0111](<redacted>.md) §2 / [ADR 0016](<redacted>.md)). Endpoints `GET/POST /github/repos` ([src/bongos/routes/github.js](../../src/bongos/routes/github.js)) read it back, `requireBuilder` + router-wide rate-limited.
+4. **Token persistence, contained.** The captured `public_repo` token is stored **encrypted** (secret-box, master key in server env only) in `github_oauth_tokens` (migration `core_192`), keyed to the builder, with a **short TTL (1h = one wizard sitting)** and a lazy expiry sweep on read. This lives in **core auth**, not the provisioning module: it is the auth system's *own* handshake token, not a feature's third-party API key (contrast the art module's Gemini key, [ADR 0102](0102-finish-bounding-the-kernel.md)), and the provisioning module's charter forbids holding tokens / calling cloud APIs ([ADR 0111](0111-instance-hosting-provisioning-module.md) §2 / [ADR 0016](0016-trust-boundary-server-enforced-permissions.md)). Endpoints `GET/POST /github/repos` ([src/bongos/routes/github.js](../../src/bongos/routes/github.js)) read it back, `requireBuilder` + router-wide rate-limited.
 5. **v1 = the user's own personal repos** (`affiliation=owner`), so `full_name` is unambiguously `login/repo` and org OAuth-policy complexity (an org can restrict/approve OAuth apps; repos silently omitted) is out of scope. Org/collaborator repos are a later enhancement.
 6. **Progressive enhancement / graceful degrade.** If secret-box is **unconfigured** (`BUILDER_SECRET_KEY` unset), no token is ever stored: `GET /github/repos` returns `503 github_repos_unavailable` and the wizard **keeps the manual owner/repo inputs + the manual create-repo done-step** as the fallback. Onboarding never regresses.
 

package/docs/adr/0144-devbox-rehome-onto-cloudbongos-plane.md

@@ -10,7 +10,7 @@
 "Get the dev box up and running again for cloud bongos" surfaced a split that was invisible from the platform:
 
 - **The dev-box feature was disabled on cloudbongos.com** — `config/modules.json` listed only `provisioning` + `platform-identity`, so `/api/gds/box/*` 404'd. The instance note said dev-box stays off "until box infra is confirmed present."
-- **The live dev-box data plane was the *legacy* `example` Postgres** (on the co-hosting box), drained by the cloudbongos control plane's `cohost-box-*` systemd runners over an SSH DB tunnel ([ADR 0132](<redacted>.md)). Builder identities even diverged: `example-owner` is builder **1** in the example DB, **3** on cloudbongos.com.
+- **The live dev-box data plane was the *legacy* `example` Postgres** (on the co-hosting box), drained by the cloudbongos control plane's `cohost-box-*` systemd runners over an SSH DB tunnel ([ADR 0132](0132-cohost-fleet-control-plane-migration.md)). Builder identities even diverged: `example-owner` is builder **1** in the example DB, **3** on cloudbongos.com.
 - **The fleet was dormant** — all 9 boxes `destroyed`, control-plane timers green but idle (`ran=0`). So nothing was *broken*; the box capability simply lived on the old plane and was never brought onto the platform after the [ADR 0139] work-history migration.
 
 The owner chose to **re-home the box feature onto the cloudbongos.com plane** (its own DB, its own domains) rather than revive a box on the legacy `example` infra. Feasibility was high: the box tables already exist in the cloudbongos DB, `cloudbongos.com` is a live Cloudflare zone on the same account the control plane already uses, the DO/CF tokens are already on the control plane, and box domains are branding-driven (`domains.devBoxBase`/`sshBoxBase`) — not hardcoded.
@@ -35,7 +35,7 @@ Stand up a **cloudbongos-native box plane** alongside (not replacing) the legacy
 
 ## Follow-ups (open)
 
-1. **Box first-boot convergence — ROOT-CAUSED + CLOSED (proper fix landed; [ADR 0150](<redacted>.md), task 1002386).** Symptom: provisioned boxes reached `active` but `cloudflared`/terminal never came up (`term-…` = CF 530) and SSH keys weren't applied. Root cause: **`box.js` provisioned droplets with EMPTY user-data** (`/var/lib/cloud/instance/user-data.txt` = 0 bytes; cloud-init logged "No user-data found"). `box.js` renders the box cloud-init from `<REPO_ROOT>/infra/` (the 26 KB `builder-box-cloud-init.yaml` + ~12 gz+b64-inlined scripts), and `fileGzB64` **silently returns `''` on a missing file**, so a missing `infra/` yields empty user-data with no error. The R89 split moved `scripts/gds/` into the `@bongos/core` package but **kept `infra/` in the instance repo** — yet `box.js` still resolves `infra/` relative to *its own* location (the vendored core), where `infra/` **isn't shipped at all** (0 files). So every box on any vendored/installed instance booted with only DigitalOcean's default user-data. **Workaround applied (temporary):** populated the vendored core's `infra/` from the instance's `infra/` (`/home/lars/cloudbongos/node_modules/@bongos/core/infra/`); re-provision then rendered a 62 KB user-data and the box converged — `cloudflared` active, `term-example-owner.cloudbongos.com` → 200 (authed), builder SSH key baked + working. **Proper fix — LANDED (spike task 1002385 → [ADR 0150](<redacted>.md); build task 1002386, "R98").** `box.js` gained `boxInfraCandidates()`/`resolveBoxInfraDir()` (an ordered instance-root-first search, including the `node_modules` walk-up) plus `BOX_INFRA_TEMPLATE`; `readCloudInit` now routes every `infra/` read through the resolved dir and **throws** on a missing/incomplete `infra/` instead of silently emitting empty user-data, and `cmdProvision` refuses to provision on empty user-data. Pinned by [`tests/box_infra_resolve.mjs`](../../tests/box_infra_resolve.mjs). The temporary `node_modules` workaround described above is therefore no longer load-bearing. *(Superseded task 1002243 was closed as part of task 1002557.)*
+1. **Box first-boot convergence — ROOT-CAUSED + CLOSED (proper fix landed; [ADR 0150](0150-box-first-boot-bringup-vendored-instances.md), task 1002386).** Symptom: provisioned boxes reached `active` but `cloudflared`/terminal never came up (`term-…` = CF 530) and SSH keys weren't applied. Root cause: **`box.js` provisioned droplets with EMPTY user-data** (`/var/lib/cloud/instance/user-data.txt` = 0 bytes; cloud-init logged "No user-data found"). `box.js` renders the box cloud-init from `<REPO_ROOT>/infra/` (the 26 KB `builder-box-cloud-init.yaml` + ~12 gz+b64-inlined scripts), and `fileGzB64` **silently returns `''` on a missing file**, so a missing `infra/` yields empty user-data with no error. The R89 split moved `scripts/gds/` into the `@bongos/core` package but **kept `infra/` in the instance repo** — yet `box.js` still resolves `infra/` relative to *its own* location (the vendored core), where `infra/` **isn't shipped at all** (0 files). So every box on any vendored/installed instance booted with only DigitalOcean's default user-data. **Workaround applied (temporary):** populated the vendored core's `infra/` from the instance's `infra/` (`/home/lars/cloudbongos/node_modules/@bongos/core/infra/`); re-provision then rendered a 62 KB user-data and the box converged — `cloudflared` active, `term-example-owner.cloudbongos.com` → 200 (authed), builder SSH key baked + working. **Proper fix — LANDED (spike task 1002385 → [ADR 0150](0150-box-first-boot-bringup-vendored-instances.md); build task 1002386, "R98").** `box.js` gained `boxInfraCandidates()`/`resolveBoxInfraDir()` (an ordered instance-root-first search, including the `node_modules` walk-up) plus `BOX_INFRA_TEMPLATE`; `readCloudInit` now routes every `infra/` read through the resolved dir and **throws** on a missing/incomplete `infra/` instead of silently emitting empty user-data, and `cmdProvision` refuses to provision on empty user-data. Pinned by [`tests/box_infra_resolve.mjs`](../../tests/box_infra_resolve.mjs). The temporary `node_modules` workaround described above is therefore no longer load-bearing. *(Superseded task 1002243 was closed as part of task 1002557.)*
 2. **Cloudflare token scope.** Provision warned the ADR 0053 cookie-strip Transform Rule was **not** applied — `CLOUDFLARE_API_TOKEN` lacks "Transform Rules" edit scope on the cloudbongos.com zone. Add the scope (or apply the rule once in the dashboard) **before** other builders get boxes on `*.cloudbongos.com`, so platform cookies (`cookieDomain=<redacted> aren't sent to box subdomains.
 3. **Cosmetic `otb-` prefix.** Tunnel names (`otb-term-<login>`) and the droplet name (`otb-box-<login>`) are still hardcoded in `box-onboard.js`/`box.js`. Harmless (fleet separation is by tag, and DNS is per-zone), but a branding leak worth parameterizing.
 4. **Phase 4 — retire the legacy example plane** (owner decision) — **part (a) DONE in task 1002248 (2026-07-15).** Pre-checked read-only that the legacy fleet was empty (0 `otb-builder-box` droplets on DigitalOcean; cohost intent queue `ran=0`), then `systemctl disable --now` on the four `cohost-box-*` timers (intent-runner / idle-suspend / drift-reconcile / dormant-reclaim) on the control-plane host — now `disabled`/`inactive`; the native `cloudbongos-box-*` timers were left `enabled`/`active`. **Part (b) — disabling the dev-box module on example.com itself — NOT reachable from the control plane, flagged to owner:** example's web app + instance checkout are not co-located on the cloudbongos droplet (no local checkout, no ssh alias) and the local example GDS token is expired, so a durable module-disable needs owner access to example's own config/host. Harmless meanwhile: with the runners stopped there is no cost/security impact — worst case is a box request on the legacy instance that now hangs unfulfilled.

package/docs/adr/0145-free-hosted-project-tier-isolation-and-domain-separation.md

@@ -3,7 +3,7 @@
 - **Status:** Accepted — owner decided 2026-07-15: **keep `cloudbongos.com`** (no separate domain), **container** isolation, **all-free** for now. Choosing the literal same domain makes hardening core sign-in a required prerequisite (see "Decisions" + "Required build sequence"). Build unblocked ([task 1002251](https://cloudbongos.com/builders#/task/1002251)); blocker 1000080 resolved.
 - **Date:** 2026-07-15
 - **Deciders:** Lars (owner/Archon) chose the direction after a security review; Claude ran the review + designed.
-- **Task:** [task 1002249](https://cloudbongos.com/builders#/task/1002249) · **Follow-up to** [ADR 0141](<redacted>.md) (federated hub IdP) and [ADR 0143](<redacted>.md) (the `/create` wizard).
+- **Task:** [task 1002249](https://cloudbongos.com/builders#/task/1002249) · **Follow-up to** [ADR 0141](<redacted>.md) (federated hub IdP) and [ADR 0143](0143-onboarding-repo-picker-oauth-scope.md) (the `/create` wizard).
 
 ## Context
 
@@ -21,7 +21,7 @@ The co-tenant instances that federate on cloudbongos.com subdomains today (e.g.
 
 A `standalone` runs **on the hub box** ([scripts/gds/provision.js](../../scripts/gds/provision.js): `standaloneBase`, control-plane-local IP) as the **same UID as the hub** (`serviceUnit` hardcodes `User=lars`), and its deploy runs `npm ci` (not `--ignore-scripts`) in a **passwordless-sudo-capable** runner context. A malicious owner could ship a `postinstall` and get code execution as `lars` with sudo on the hub box → the hub's signing key, every instance's secrets, the hub DB. This is a pre-existing property of running owner code on the hub box at all, independent of federation, but any free "run your code for you" tier would expose it at scale.
 
-> **Amended 2026-09-12 ([ADR 0281](<redacted>.md), task [1003369](https://cloudbongos.com/builders#/task/1003369)):** `serviceUnit` no longer hardcodes `User=lars` — each provisioned instance now runs as its own unix account with its own password-authed PG role, so the *running* instance is no longer the same UID as the hub. **Finding 2 stands regardless:** the exposure it names is the DEPLOY, not the steady state — `npm ci` still runs owner `postinstall` code in the passwordless-sudo-capable runner context, before the per-instance account is ever involved. The decision below is unchanged.
+> **Amended 2026-09-12 ([ADR 0281](0281-an-instance-identity-is-its-own-unix-account-and-pg-role.md), task [1003369](https://cloudbongos.com/builders#/task/1003369)):** `serviceUnit` no longer hardcodes `User=lars` — each provisioned instance now runs as its own unix account with its own password-authed PG role, so the *running* instance is no longer the same UID as the hub. **Finding 2 stands regardless:** the exposure it names is the DEPLOY, not the steady state — `npm ci` still runs owner `postinstall` code in the passwordless-sudo-capable runner context, before the per-instance account is ever involved. The decision below is unchanged.
 
 The federation protocol itself is sound: the hub binds the minted audience to the instance's exact origin (the `#1002108` fix; asymmetric Ed25519 so one instance can't forge for another). A leaked per-instance client secret is contained to its own origin. The weakness is **placement** (shared cookie domain) and **execution** (owner code on the hub box), not the protocol.
 

package/docs/adr/0146-configurable-reward-mode-cost-plus-only.md

@@ -9,10 +9,10 @@
 
 A shipped task pays a builder from **two reward streams that land on the same balance**:
 
-1. **The per-task ESTIMATE** — `credits_reward × kind multiplier` ([ADR 0023](<redacted>.md)). A **unitless author estimate** set when the task is authored (or auto-assigned by the no-zero-reward backstop, ADR 0096). It is what a builder sees advertised at claim time, and — since [ADR 0120](<redacted>.md) — it books at ship as `credit_log.reason = 'task.shipped'`, plus a 25% idea-promotion slice ([ADR 0023](<redacted>.md)) to the idea's original capturer.
-2. **The cost-plus SESSION reward** — `round(true_cost_usd × 1.20)`, 1 drachma = $1 ([ADR 0054](<redacted>.md)). Grounded in the session's **real API spend**, booked as `session.token_reward`.
+1. **The per-task ESTIMATE** — `credits_reward × kind multiplier` ([ADR 0023](0023-kind-multipliers-and-idea-bonus.md)). A **unitless author estimate** set when the task is authored (or auto-assigned by the no-zero-reward backstop, ADR 0096). It is what a builder sees advertised at claim time, and — since [ADR 0120](0120-pay-on-land-and-builder-owned-rebase-gate.md) — it books at ship as `credit_log.reason = 'task.shipped'`, plus a 25% idea-promotion slice ([ADR 0023](0023-kind-multipliers-and-idea-bonus.md)) to the idea's original capturer.
+2. **The cost-plus SESSION reward** — `round(true_cost_usd × 1.20)`, 1 drachma = $1 ([ADR 0054](0054-session-token-reward-cost-plus.md)). Grounded in the session's **real API spend**, booked as `session.token_reward`.
 
-[ADR 0054](<redacted>.md) named this the **"two drachma conventions, one ledger"** tension and explicitly flagged reconciling them as a deferred future-review trigger: one stream is unitless bounty points, the other is dollars, and they are summed into one `total_credits`. Goal 1000037 changed only *when* both pay (on land), never *whether* both pay.
+[ADR 0054](0054-session-token-reward-cost-plus.md) named this the **"two drachma conventions, one ledger"** tension and explicitly flagged reconciling them as a deferred future-review trigger: one stream is unitless bounty points, the other is dollars, and they are summed into one `total_credits`. Goal 1000037 changed only *when* both pay (on land), never *whether* both pay.
 
 The owner's stated intent for Cloud Bongos is that **a credit means one dollar of cost-plus value and nothing else**. Under the two-stream model that is not true — roughly half of a shipped task's payout is the arbitrary estimate. The owner asked to make the cost-plus reward the **sole** equity reward for Cloud Bongos, and for that choice to be **configurable in the economy module** (so other instances are unaffected and can choose differently).
 
@@ -41,7 +41,7 @@ Add a per-instance reward **mode** to the existing reward policy, resolved by th
 ## Consequences
 
 - **Backward-compatible by construction.** Absence of `mode` ⇒ default ⇒ current behavior. No migration, no data change.
-- **Reversible.** Flipping `mode` back to the default resumes per-task payouts from the next ship; nothing is destroyed. (Historical rows are untouched — this is not a clawback; see [ADR 0120](<redacted>.md) part 4 for the separate one-time backlog re-gate.)
+- **Reversible.** Flipping `mode` back to the default resumes per-task payouts from the next ship; nothing is destroyed. (Historical rows are untouched — this is not a clawback; see [ADR 0120](0120-pay-on-land-and-builder-owned-rebase-gate.md) part 4 for the separate one-time backlog re-gate.)
 - **Builder-facing expectation gap (follow-up).** ~~In `cost-plus-only` mode the "Est." shown at claim time is a *guide*, not a promise — the builder is actually paid the cost-plus amount. Surfacing "this instance pays cost-plus only" in the hall / claim UI is a captured follow-up idea, not part of this task.~~ **Resolved by task [#1002469](https://cloudbongos.com/builders#/task/1002469).** The gap was not theoretical: it cost a real session on 2026-07-26, where a correct `Credits +0` was diagnosed as a broken reward gate. The resolved policy is now exposed on the `reward` port (`rewardConfig`), projected onto `clientBranding()` for the hall and returned on `GET /me` + `POST /claims` for the CLI — **the CLI must take it from the server**, since an instance's `config/branding.json` is not in a builder's checkout and a local read always reports the paying default. Claim, `/builder-start`, the ship card, and the hall now label the estimate as an estimate and name the real payer. The hall fix also closed a live misread: `taskCreditValue` falls back to the estimate when a settled task has `credits_awarded === 0` — which under `cost-plus-only` is *every* shipped task — so the plain label was presenting an unpaid estimate as the actual ledger payout.
 - **The two-conventions tension is resolved for `cost-plus-only` instances** (one dollar-denominated stream) and left intact for default instances — the ADR 0054 trigger is addressed by *config*, not by forcing one model on everyone.
 

package/docs/adr/0147-standalone-live-docs-regen.md

@@ -3,7 +3,7 @@
 - **Status:** Accepted
 - **Date:** 2026-07-17
 - **Track:** internal
-- **Builds on:** [ADR 0110](<redacted>.md) (untrack + deploy-regen the whole-file nav docs), [ADR 0108](<redacted>.md) (standalone instance = own repo + pinned `@bongos/core`), [ADR 0062](<redacted>.md) §8 (`gen-session-index.js`), [ADR 0063](<redacted>.md) (`gen-repo-map.js`)
+- **Builds on:** [ADR 0110](0110-untrack-whole-file-generated-nav-docs.md) (untrack + deploy-regen the whole-file nav docs), [ADR 0108](0108-instance-composition-configurable-root.md) (standalone instance = own repo + pinned `@bongos/core`), [ADR 0062](0062-medusa-instance-model-decoupling.md) §8 (`gen-session-index.js`), [ADR 0063](0063-generated-repo-map-symbol-skeleton.md) (`gen-repo-map.js`)
 - **Task:** [#1002314](https://cloudbongos.com/builders#/task/1002314)
 
 ## Context

package/docs/adr/0149-bongos-dev-local-launcher.md

@@ -3,7 +3,7 @@
 - **Status:** Accepted (owner decision — "we need a better option to stand up the local host").
 - **Date:** 2026-07-19
 - **Deciders:** Lars (owner) — chose a one-command local launcher over a cloud dev box or a recipe-only fix.
-- **Extends:** [ADR 0108](<redacted>.md) (a standalone instance repo pins the core as a dependency), [ADR 0062 §5](<redacted>.md) (the core owns its own pool + branding). Sibling of `local-preview-lib.js` (task 1056 — the game-only local sandbox) and `onboard`/`provision.js` (the *cloud* standup path).
+- **Extends:** [ADR 0108](0108-instance-composition-configurable-root.md) (a standalone instance repo pins the core as a dependency), [ADR 0062 §5](0062-medusa-instance-model-decoupling.md) (the core owns its own pool + branding). Sibling of `local-preview-lib.js` (task 1056 — the game-only local sandbox) and `onboard`/`provision.js` (the *cloud* standup path).
 
 ## Context
 

package/docs/adr/0150-box-first-boot-bringup-vendored-instances.md

@@ -3,7 +3,7 @@
 - **Status:** Accepted (spike BV1.R97 / task 1002385 — the C2 diagnosis for goal 1000051 / 1000052). Confirms the build shape of R98 (task 1002386) + R99 (task 1002387).
 - **Date:** 2026-07-19
 - **Deciders:** Lars (owner) — "continue with C2" (make cloudbongos boxes stop coming up bare). Claude diagnosed + designed the fix.
-- **Extends:** [ADR 0144](<redacted>.md) (its first follow-up item root-caused this), [ADR 0108](<redacted>.md) (the `resolveCoreRoot()`/`resolveInstanceRoot()` split this fix rides), [ADR 0031](<redacted>.md) (box lifecycle), [ADR 0148](<redacted>.md) (task-scoped source access — which only matters once a box actually boots).
+- **Extends:** [ADR 0144](0144-devbox-rehome-onto-cloudbongos-plane.md) (its first follow-up item root-caused this), [ADR 0108](0108-instance-composition-configurable-root.md) (the `resolveCoreRoot()`/`resolveInstanceRoot()` split this fix rides), [ADR 0031](0031-cloud-dev-environments-for-builders.md) (box lifecycle), [ADR 0148](0148-task-scoped-box-source-access.md) (task-scoped source access — which only matters once a box actually boots).
 
 ## Context
 
@@ -12,7 +12,7 @@
 There are two provisioning paths in the fleet's history:
 
 - **The reference (example) path** — `scripts/gds/box.js` renders a DigitalOcean cloud-init from `infra/builder-box-cloud-init.yaml` (+ ~12 gz+b64-inlined scripts: `box-source-fetch.sh`, the cloudflared/ttyd units, `box-heartbeat.sh`, …). The cloud-init is what clones the source, installs the toolchain, and starts the terminal. A box is "non-bare" **because** its user-data ran.
-- **The cloudbongos path** ([ADR 0144](<redacted>.md)) — native `cloudbongos-box-*` runners against the local DB, but the **same `box.js`** renders the same cloud-init.
+- **The cloudbongos path** ([ADR 0144](0144-devbox-rehome-onto-cloudbongos-plane.md)) — native `cloudbongos-box-*` runners against the local DB, but the **same `box.js`** renders the same cloud-init.
 
 ## Root cause (code-grounded + live-confirmed)
 
@@ -37,7 +37,7 @@ So the failure is a **packaging-locality bug**, not a logic bug: `box.js` looks
 
 ### R98 — make the box clone the base instance on boot
 
-**Prong A — resolve `infra/` from the instance root** (ride [ADR 0108](<redacted>.md), exactly like [`scripts/migrate.sh:35`](../../scripts/migrate.sh) resolves its roots). A new `resolveBoxInfraDir()` in `box.js` returns the first candidate that actually contains `builder-box-cloud-init.yaml`, in order:
+**Prong A — resolve `infra/` from the instance root** (ride [ADR 0108](0108-instance-composition-configurable-root.md), exactly like [`scripts/migrate.sh:35`](../../scripts/migrate.sh) resolves its roots). A new `resolveBoxInfraDir()` in `box.js` returns the first candidate that actually contains `builder-box-cloud-init.yaml`, in order:
 
 1. an explicit `<PREFIX>_BOX_INFRA_DIR` env override (escape hatch);
 2. `resolveInstanceRootExplicit()/infra` — the env / `bongos.config.json` pointer (cloudbongos: `{"instanceRoot":"."}` → `/home/lars/cloudbongos/infra`);

package/docs/adr/0151-governance-permissions-as-atom-ranks-as-roles.md

@@ -5,13 +5,13 @@
 - **Deciders:** Lars (owner / Archon), Claude
 - **Track:** `internal` (GDS / methodology — a Cloud Bongos platform capability)
 - **Task:** BV1.R90 ([#1001838](https://cloudbongos.com/builders#/task/1001838)) — the foundation of the BONGOS-V1 **Governance** goal ([#1000030](https://cloudbongos.com/builders#/goal/1000030)); settles the model in an ADR before any of R93–R114 build against it.
-- **Builds on:** [ADR 0016](<redacted>.md) (the server-enforced HTTP trust boundary — **preserved untouched**), [ADR 0043](<redacted>.md) (the out-of-band git/ssh substrate + protected-path rank floor), [ADR 0062](<redacted>.md) (core ↔ host split), [ADR 0083](<redacted>.md) (modules), [ADR 0084](<redacted>.md) (auto-derived per-task rank floor), [ADR 0086](<redacted>.md) (goal-scoped hierarchy + cross-tier edges), [ADR 0090](<redacted>.md) (Metic authoring powers), [ADR 0106](<redacted>.md) (ownership authority).
+- **Builds on:** [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (the server-enforced HTTP trust boundary — **preserved untouched**), [ADR 0043](0043-git-ssh-trust-boundary-and-rank-floor-on-permission-paths.md) (the out-of-band git/ssh substrate + protected-path rank floor), [ADR 0062](0062-medusa-instance-model-decoupling.md) (core ↔ host split), [ADR 0083](0083-modular-architecture-strangler-build-plan.md) (modules), [ADR 0084](0084-auto-derived-per-task-rank-floor.md) (auto-derived per-task rank floor), [ADR 0086](0086-goal-scoped-work-hierarchy.md) (goal-scoped hierarchy + cross-tier edges), [ADR 0090](0090-metic-task-authoring.md) (Metic authoring powers), [ADR 0106](0106-goal-owner-manager-authority.md) (ownership authority).
 - **Gates:** R91 (module key) · R93/R94 (tables + catalog code) · R95 (resolver) · R97 (`requirePermission`) · R98–R101 (principals / session-scopes / ownership / registry) · R96/R102 (core-host split) · R104–R109 (gate migration) · R110/R111/R113 (the tab) · R103/R112/R114 (proofs). This ADR is the decision those tasks implement.
 
 ---
 
 
-> **⚠ VOCABULARY AMENDED by [ADR 0174](<redacted>.md) (owner directive, 2026-08-16) — the DECISION below is unchanged.**
+> **⚠ VOCABULARY AMENDED by [ADR 0174](0174-government-terminology-ranks-not-roles.md) (owner directive, 2026-08-16) — the DECISION below is unchanged.**
 > What this ADR calls *governance* is now the **government**; what it calls *seeded roles* / *rank-roles* are now simply **ranks**. The word *role* is reserved for the three Cloud Bongos crafts — Artist, Ideator, Builder — and appears nowhere on the government side.
 > Concretely: `governance_roles` → `government_ranks`, `governance_builder_roles` → `government_builder_ranks`, `governance_role_permissions` → `government_rank_permissions`, `role_key` → `rank_key`, `governance.manage` → `government.manage`, `page.view.governance` → `page.view.government`, `/governance/roles/*` → `/government/ranks/*`, and `modules/governance/` → `modules/government/`.
 > **The body below is deliberately left in the old vocabulary.** An ADR records what was decided and why at a point in time; rewriting it to match today's words would erase the evidence that the words changed — which is the one thing a reader who hits "rank-role" in an old session log actually needs. Every decision it makes still holds; only the nouns moved. A `fitness.js` check now enforces the new vocabulary, and excludes this file by construction.
@@ -19,9 +19,9 @@
 
 ## Context
 
-Authority in Cloud Bongos is a **single rank threshold** today. [ADR 0016](<redacted>.md) put authority in one DB column (`builders.rank`), checked server-side per request with no caching; [ADR 0018](<redacted>.md) / [ADR 0034](<redacted>.md) wired the four live ranks into the ordered tier `xenos (1) < thetes (2) < metic (3) < archon (4)`. Every privileged route calls `requireRank(...allowed)`, which admits a builder whose rank sits **at or above** the lowest-authority rank named (a threshold, [#591](https://cloudbongos.com/builders#/task/591)). That design is sound and is **not** being replaced — it is the substrate this ADR builds *on top of*.
+Authority in Cloud Bongos is a **single rank threshold** today. [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) put authority in one DB column (`builders.rank`), checked server-side per request with no caching; [ADR 0018](0018-three-rank-model-goes-live.md) / [ADR 0034](0034-thetes-graduated-newcomer-rank.md) wired the four live ranks into the ordered tier `xenos (1) < thetes (2) < metic (3) < archon (4)`. Every privileged route calls `requireRank(...allowed)`, which admits a builder whose rank sits **at or above** the lowest-authority rank named (a threshold, [#591](https://cloudbongos.com/builders#/task/591)). That design is sound and is **not** being replaced — it is the substrate this ADR builds *on top of*.
 
-But a rank is an **all-or-nothing bundle**. There is no way to say "this builder may triage ideas but not author tasks," or to stand up a trusted reviewer who is not a full Metic, without inventing a new rank and threading it through a dozen-plus hand-copied tier maps (§Decision 2 counts 13). The owner wants a **Discord-style roles-and-permissions system**: configurable roles, assignable to builders, composed from granular permissions — where **permissions are the atomic primitive and ranks become seeded roles** — delivered with **zero day-one behavior change** and **without weakening the trust boundary** that is Cloud Bongos's one hard-to-copy moat ([ADR 0087](<redacted>.md): *compete on governance, not tooling*).
+But a rank is an **all-or-nothing bundle**. There is no way to say "this builder may triage ideas but not author tasks," or to stand up a trusted reviewer who is not a full Metic, without inventing a new rank and threading it through a dozen-plus hand-copied tier maps (§Decision 2 counts 13). The owner wants a **Discord-style roles-and-permissions system**: configurable roles, assignable to builders, composed from granular permissions — where **permissions are the atomic primitive and ranks become seeded roles** — delivered with **zero day-one behavior change** and **without weakening the trust boundary** that is Cloud Bongos's one hard-to-copy moat ([ADR 0087](0087-compete-on-governance-not-tooling-cursor.md): *compete on governance, not tooling*).
 
 The 2026-07-03 governance planning session ([goal 1000030](https://cloudbongos.com/builders#/goal/1000030)) locked the shape and seeded the R90–R114 task chain against six done-when criteria (C1–C6). This ADR records the decision so those tasks build against **one** settled model instead of re-litigating it fourteen times, and it enumerates the **full permission catalog** (the appendix) grounded in the 2026-07-24 authority sweep of every server-side gate in the tree.
 
@@ -30,7 +30,7 @@ The 2026-07-03 governance planning session ([goal 1000030](https://cloudbongos.c
 1. **Rank-derived power** — `requireRank('metic')` and friends. The bulk. Maps cleanly to roles.
 2. **Machine principals** — the BFG session-eval uploader and the Discord bot are gated on their **exact `system_role`** (`requireBfgPrincipal`, `requireDiscordBot` in `src/bongos/auth.js`), *not* rank: an Archon token is rejected because it carries `system_role = NULL`. A governance axis roles don't cover.
 3. **Session-scopes** — a dev-box token (`session.source = 'box'`) is **deny-by-default**: it may reach only the routes that opted in via `allowBoxScope`, *regardless of how senior its builder is*. Capability attached to the session, orthogonal to the builder's rank.
-4. **Ownership-scoped authority** — "act on **own** X" and "act on a goal you **own/manage**." Enforced today by in-handler pure gates (`authorizeMemberRoleChange`, [ADR 0106](<redacted>.md)) and by row-level ownership checks, not by `requireRank`.
+4. **Ownership-scoped authority** — "act on **own** X" and "act on a goal you **own/manage**." Enforced today by in-handler pure gates (`authorizeMemberRoleChange`, [ADR 0106](0106-goal-owner-manager-authority.md)) and by row-level ownership checks, not by `requireRank`.
 
 A model that claims to be "the complete authority model" (criterion C3) has to represent all four.
 
@@ -59,7 +59,7 @@ Once the primitive exists, the gates migrate off rank:
 - **Core routes** (`src/bongos/routes/`) and the **~60 module route gates** (`modules/*/routes/*`) move `requireRank(...)` → `requirePermission(<key>)` with the catalog key that names each route's capability, behavior verified identical against the parity intent (R104, R105).
 - **Claim eligibility** — today rank-driven (`xenosClaimAllowed` / the per-task `requires_rank` floor) — is re-expressed as permissions (`task.claim.newcomer` vs `task.claim.any`), with the per-task floor still honored and the abuse cases still blocked (R106).
 - **HTML page gates** (`requireArchonPage` / `requireNonXenosPage` / `requireBuilderPage`) and the **wandering-prefs rank-default/ceiling clamp** resolve via permissions / role metadata (R107).
-- The **duplicated rank-ladder / tier / order maps** collapse behind the resolver, with a fitness guard forbidding a new parallel map (R108). The 2026-07-24 sweep found **13 definition sites across 5 families** — `RANKS` (the full 16-value ladder, ×2 "twinned"), `LIVE_RANK_LADDER` (×2), `REQUIRES_RANK_TIER`/`RANK_TIER` (×3, one a deliberately-local copy in `permission-path-check.js`), `RANK_ORDER` (×4, one **0-indexed** while the tier maps are 1-indexed), and four one-off rank `Set`s — several commented as hand-kept copies. This is the exact drift class that *caused the Builder 25 incident* (a tier map that forgot `thetes` — [ADR 0043](<redacted>.md)); centralizing it is a security win, not just tidiness.
+- The **duplicated rank-ladder / tier / order maps** collapse behind the resolver, with a fitness guard forbidding a new parallel map (R108). The 2026-07-24 sweep found **13 definition sites across 5 families** — `RANKS` (the full 16-value ladder, ×2 "twinned"), `LIVE_RANK_LADDER` (×2), `REQUIRES_RANK_TIER`/`RANK_TIER` (×3, one a deliberately-local copy in `permission-path-check.js`), `RANK_ORDER` (×4, one **0-indexed** while the tier maps are 1-indexed), and four one-off rank `Set`s — several commented as hand-kept copies. This is the exact drift class that *caused the Builder 25 incident* (a tier map that forgot `thetes` — [ADR 0043](0043-git-ssh-trust-boundary-and-rank-floor-on-permission-paths.md)); centralizing it is a security win, not just tidiness.
 - The **route-rank-check fitness gate** learns to read `requirePermission`, re-expresses its EXPECTED pins in permission terms, and still hard-fails the build on an ungated or under-gated write route (R109).
 
 ### 3. The complete authority model — roles + principals + session-scopes + ownership-scoped permissions (C3)
@@ -69,7 +69,7 @@ The model represents all four axes from §Context as **first-class types**, not
 - **Roles** — the rank-seeded and custom bundles of §1. The common case.
 - **Principals** (R98) — a **machine identity** is a first-class principal type, its capability keyed on `system_role` (the existing `bfg` / `discord_bot` gate), **provisioned out-of-band and never UI-grantable**. The resolver treats a principal's capability distinctly from a builder's roles; the governance tab *shows* principals but cannot *grant* to them. (A human token can never acquire a principal capability — that is the point of gating on exact identity.)
 - **Session-scopes** (R99) — a **session-scope** is a first-class capability the resolver honors: a box-scoped session's effective permissions are its **deny-by-default allow-list**, intersected with (never widening) its builder's role permissions — so a box session is limited even when its builder is an Archon. This models the current ad-hoc `allowBoxScope` flag explicitly.
-- **Ownership-scoped permissions** (R100) — "act on **own** X" is a **parameterized** permission distinct from the global grant: `box.manage.own` ≠ `box.manage.any`, `claim.act.own` ≠ `claim.act.any`, likewise own-memory / own-credential, and the goal owner/manager authority of [ADR 0106](<redacted>.md). A route requires the scoped form; the resolver + an ownership predicate (the in-handler pure-gate pattern) decide it against the target row. Existing own-scoped routes migrate to it.
+- **Ownership-scoped permissions** (R100) — "act on **own** X" is a **parameterized** permission distinct from the global grant: `box.manage.own` ≠ `box.manage.any`, `claim.act.own` ≠ `claim.act.any`, likewise own-memory / own-credential, and the goal owner/manager authority of [ADR 0106](0106-goal-owner-manager-authority.md). A route requires the scoped form; the resolver + an ownership predicate (the in-handler pure-gate pattern) decide it against the target row. Existing own-scoped routes migrate to it.
 
 ### 4. Policy owns / substrate enforces — the protected-surface registry + the system-permission wall (C6 / R101)
 
@@ -77,9 +77,9 @@ This is the pillar that keeps configurability from becoming a foot-gun, and it h
 
 **The `system` flag.** Every permission in the catalog is flagged **`system: true`** (trust-boundary, **non-grantable**) or **`system: false`** (operational, grantable). A `system` permission — deploy, protected-path modification, rank-setting, version disposition, grade-bypass, cross-tier structural edges — **cannot be added to a custom role**; the governance API rejects the grant server-side and the tab renders it **LOCKED** (visible, so the model is legible; not togglable). `system: false` permissions are the ones an Archon may compose into custom roles freely. The rule for the flag: *a permission is `system` iff granting it to a non-Archon would breach the trust boundary or a scope/quality gate* (privilege management, scope disposition, quality-gate bypass, cross-tier structural edges, and everything the out-of-band substrate enforces).
 
-**The protected-surface registry.** Today's rank→surface map — `PROTECTED_GLOBS` + the per-tier `EXPECTED_RANKS` — is baked into code (`src/bongos/permission-path-check.js`). Governance takes ownership of it **as data**: which paths are protected, and at what floor, becomes a governance-owned registry. The **out-of-band substrate stays the enforcer** — the pre-push hook, the grader pre-pass, `main-audit.js`, `gate-review.js`, and the goal-scope check *read the registry* instead of a hardcoded list, but enforcement never moves into the app. The Metic floor and the `system`-permission mapping *flow from* the registry. The registry (R101) is also the moment to **close the [ADR 0087](<redacted>.md) §3 path-matching gap** the sweep confirmed: `permission-path-check.js`'s `normalize()` does backslash→slash + strip-`./` only — **no case-folding and no Unicode normalization** — so a case-varied or homoglyph path evades the protected-glob match (Linux-deployed, so latent today, but it is the Cursor-class `.cursorignore`/case-bypass CVE shape). The registry matcher should normalize (case-fold + Unicode NFC) and gate file **creation** as strictly as edits.
+**The protected-surface registry.** Today's rank→surface map — `PROTECTED_GLOBS` + the per-tier `EXPECTED_RANKS` — is baked into code (`src/bongos/permission-path-check.js`). Governance takes ownership of it **as data**: which paths are protected, and at what floor, becomes a governance-owned registry. The **out-of-band substrate stays the enforcer** — the pre-push hook, the grader pre-pass, `main-audit.js`, `gate-review.js`, and the goal-scope check *read the registry* instead of a hardcoded list, but enforcement never moves into the app. The Metic floor and the `system`-permission mapping *flow from* the registry. The registry (R101) is also the moment to **close the [ADR 0087](0087-compete-on-governance-not-tooling-cursor.md) §3 path-matching gap** the sweep confirmed: `permission-path-check.js`'s `normalize()` does backslash→slash + strip-`./` only — **no case-folding and no Unicode normalization** — so a case-varied or homoglyph path evades the protected-glob match (Linux-deployed, so latent today, but it is the Cursor-class `.cursorignore`/case-bypass CVE shape). The registry matcher should normalize (case-fold + Unicode NFC) and gate file **creation** as strictly as edits.
 
-The invariant this buys, stated as a testable promise (R112, R114): **the tab can re-map which surfaces are protected and at what floor (policy), but it cannot move enforcement into the request path (substrate).** An Archon can create a custom role and grant it every `system: false` permission in the catalog, assign it to a `xenos`, and that builder gains exactly those operational powers — **while a `system` permission the role "has" stays enforced by the substrate**: the deploy / protected-path / SSH attempt is still blocked, because [ADR 0043](<redacted>.md)'s layer-3 audit reads the real git history and the real registry, independent of anything the app grants. Config owns policy; the substrate owns enforcement; a forced grant cannot cross that line. (Note: `main` on this repo still has **no** GitHub branch protection — re-verified 2026-07-24, [ADR 0043](<redacted>.md) §"Branch-protection status" — so `main-audit.js` remains the *authoritative* substrate layer, not a redundant net. The registry does not change that; it only makes the protected list data instead of a constant.)
+The invariant this buys, stated as a testable promise (R112, R114): **the tab can re-map which surfaces are protected and at what floor (policy), but it cannot move enforcement into the request path (substrate).** An Archon can create a custom role and grant it every `system: false` permission in the catalog, assign it to a `xenos`, and that builder gains exactly those operational powers — **while a `system` permission the role "has" stays enforced by the substrate**: the deploy / protected-path / SSH attempt is still blocked, because [ADR 0043](0043-git-ssh-trust-boundary-and-rank-floor-on-permission-paths.md)'s layer-3 audit reads the real git history and the real registry, independent of anything the app grants. Config owns policy; the substrate owns enforcement; a forced grant cannot cross that line. (Note: `main` on this repo still has **no** GitHub branch protection — re-verified 2026-07-24, [ADR 0043](0043-git-ssh-trust-boundary-and-rank-floor-on-permission-paths.md) §"Branch-protection status" — so `main-audit.js` remains the *authoritative* substrate layer, not a redundant net. The registry does not change that; it only makes the protected list data instead of a constant.)
 
 ### 5. Capability in core, settings per project (C4)
 
@@ -127,19 +127,19 @@ Enumerated from the **2026-07-24 authority sweep** ([`docs/governance/<redacted>
 | `builder.rank.set` | `PATCH /builders/:id/rank` — the single rank writer; one-rung, upward | HTTP (`requireRank('archon')`) | ✔ |
 | `version.close` | version close disposition (never delegated below Archon — canonical) | HTTP | ✔ |
 | `task.confirm.grade_bypass` | `POST /tasks/:id/confirm` — ratify past a failed grade (env-relaxable; see note) | HTTP + grader | ✔ |
-| `dependency.cross_tier.manage` | `POST\|DELETE /dependencies` — cross-tier structural edges ([ADR 0086](<redacted>.md)) | HTTP | ✔ |
-| `goal.scope.manage` | cross-tier goal-scope edges + protected-scope admission ([ADR 0086](<redacted>.md)) | HTTP + goal-scope-check | ✔ |
+| `dependency.cross_tier.manage` | `POST\|DELETE /dependencies` — cross-tier structural edges ([ADR 0086](0086-goal-scoped-work-hierarchy.md)) | HTTP | ✔ |
+| `goal.scope.manage` | cross-tier goal-scope edges + protected-scope admission ([ADR 0086](0086-goal-scoped-work-hierarchy.md)) | HTTP + goal-scope-check | ✔ |
 | `governance.manage` | the governance tab's write routes (roles/perms/assignments) — meta-escalation | HTTP (`requireRank('archon')`) | ✔ |
 | `gate_approval.decide` | `POST /gate-approvals/:pr/approve` — CI deploy-gate override | HTTP + gate-review substrate | ✔ |
 | `deploy.push_main` | `git push origin main` / the deploy | **substrate** (pre-push, main-audit, deploy gate) | ✔ |
-| `path.protected.modify` | modifying a `PROTECTED_GLOBS` path below the Metic floor | **substrate** (3 layers, [ADR 0043](<redacted>.md)) | ✔ |
+| `path.protected.modify` | modifying a `PROTECTED_GLOBS` path below the Metic floor | **substrate** (3 layers, [ADR 0043](0043-git-ssh-trust-boundary-and-rank-floor-on-permission-paths.md)) | ✔ |
 | `infra.ssh` | `ssh` to the droplet / operator surface | **substrate** (credential placement, not app) | ✔ |
 | `principal.bfg` | `/memory/bfg/*` — `requireBfgPrincipal` (exact `system_role='bfg'`) | HTTP (identity, not rank) | ✔ |
 | `principal.discord_bot` | Discord bot routes — `requireDiscordBot` (exact `system_role`; dormant) | HTTP (identity, not rank) | ✔ |
 
 The `system` set is deliberately **tight** — only gates whose delegation would *compromise the platform* (escalate rank, bypass the grader/deploy gate, touch protected paths/infra, or re-grant permissions). Every other authority — including many currently archon-gated **admin** ops (offboard, abandon, onboarding review, fleet teardown) — is **operational** and therefore *delegable*, which is the whole value of the model: an Archon can stand up a "moderator" or "onboarder" role without handing out deploy. (The exact system/operational line for a couple of scope-disposition ops is R94's to finalize; this ADR sets the rule and the default.)
 
-> **Env-relaxable exception (flagged for R94/R106):** `POST /tasks/:id/confirm` is archon-only *unless* `GRADER_BYPASS_ENABLED=1` (read live per request, [ADR 0041](<redacted>.md)), which relaxes the middleware to any-builder — then the handler re-narrows in-code via `gateTaskOwnership` (claim holder or Archon only). The permission model represents this as `task.confirm.grade_bypass` (system) with a documented env override on the *substrate* side; the grant is never widened by config, only by the operator env flag.
+> **Env-relaxable exception (flagged for R94/R106):** `POST /tasks/:id/confirm` is archon-only *unless* `GRADER_BYPASS_ENABLED=1` (read live per request, [ADR 0041](0041-temporary-grader-bypass-killswitch.md)), which relaxes the middleware to any-builder — then the handler re-narrows in-code via `gateTaskOwnership` (claim holder or Archon only). The permission model represents this as `task.confirm.grade_bypass` (system) with a documented env override on the *substrate* side; the grant is never widened by config, only by the operator env flag.
 
 ### Operational permissions (`system: false` — grantable to custom roles)
 
@@ -179,27 +179,27 @@ The `system` set is deliberately **tight** — only gates whose delegation would
 |---|---|
 | `idea.triage` | `PATCH /inbox/:id` |
 | `blocker.review` | `POST /blockers/:id/{resolve,link}` |
-| `task.create` / `task.edit` / `task.promote` / `task.demote` | `POST /tasks`, `PATCH /tasks/:id`, `/promote`, `/demote` ([ADR 0090](<redacted>.md)) |
+| `task.create` / `task.edit` / `task.promote` / `task.demote` | `POST /tasks`, `PATCH /tasks/:id`, `/promote`, `/demote` ([ADR 0090](0090-metic-task-authoring.md)) |
 | `task.dependency.manage` / `task.criterion.manage` | `/tasks/:id/dependencies` + `/criteria` CRUD (same-tier) |
 | `task.vote` | `POST /tasks/:id/vote` |
 | `criterion.satisfy` / `criterion.review` | `POST /done-when/:id/satisfy`, `GET /done-when/pending-review` |
-| `criterion.create` | `POST /versions/:id/done-when` — floor `metic` but **qualified**: a non-Archon must name a `goal_id`, on a `building` version, in an `open` goal they own or manage ([ADR 0154](<redacted>.md)). A floor alone does not describe this permission. *(Was bundled into the `criterion.review` row above while the route was still Archon-only — a transcription slip against the sweep; see ADR 0154 §5.)* |
+| `criterion.create` | `POST /versions/:id/done-when` — floor `metic` but **qualified**: a non-Archon must name a `goal_id`, on a `building` version, in an `open` goal they own or manage ([ADR 0154](0154-goal-owner-criterion-authoring.md)). A floor alone does not describe this permission. *(Was bundled into the `criterion.review` row above while the route was still Archon-only — a transcription slip against the sweep; see ADR 0154 §5.)* |
 | `planning.run` / `priority.run` | planning- / priority-session surface |
-| `goal.create` | `POST /goals` (protected scope → archon in-handler; [ADR 0086](<redacted>.md)) |
+| `goal.create` | `POST /goals` (protected scope → archon in-handler; [ADR 0086](0086-goal-scoped-work-hierarchy.md)) |
 | `goal.archive` | `POST /goals/:id/{archive,reopen}` |
 | `goal.scope.widen` | `POST /goals/:id/scope` (same-tier; cross-tier = `goal.scope.manage`, system) |
 | `module.enable` / `module.submit` | `POST /modules/:key/{enable,submit}`, `GET /modules/submissions` |
 | `security.report.file` | `POST /security/reports`, `GET /security/adr` |
 | `llm_cache.use` | `POST /llm-cache/{lookup,store}` |
 | `backup.manage` | `GET /backup/status`, `POST /backup/trigger` |
-| `source.clone.local` | Metic+ local clone / collaborator invite ([ADR 0035](<redacted>.md)) |
+| `source.clone.local` | Metic+ local clone / collaborator invite ([ADR 0035](0035-builder-onboarding-three-paths.md)) |
 | `box.source.full` | `GET /box/source-access` → `full` (vs `starter`); `boxScopeForRank` |
 
 **Ownership-scoped (`own` ≠ `any`) + baseline — floor `thetes` / `xenos` / any builder / `own`:**
 
 | Key | Guards (route / surface) | Floor |
 |---|---|---|
-| `goal.manage.own` | `PATCH /goals/:id/members/:b`, `POST /goals/:id/transfer` — owner/manager, in-handler ([ADR 0106](<redacted>.md)) | owner/manager |
+| `goal.manage.own` | `PATCH /goals/:id/members/:b`, `POST /goals/:id/transfer` — owner/manager, in-handler ([ADR 0106](0106-goal-owner-manager-authority.md)) | owner/manager |
 | `task.act.own` | act on **own** active claim (release, cost, notes) | own |
 | `box.manage.own` | own dev-box lifecycle | own |
 | `memory.manage.own` | own builder memory | own |
@@ -223,7 +223,7 @@ The `system` set is deliberately **tight** — only gates whose delegation would
 - **Keep ranks; add more of them.** Rejected. Every new rank threads through the 13 hand-copied tier/ladder maps (the exact drift that caused the Builder 25 incident) and still can't express "triage but not author," principals, session-scopes, or ownership. Ranks-as-roles subsumes ranks without losing them.
 - **Permissions replace ranks entirely (drop the rank column).** Rejected for the cut-over. `builders.rank` anchors auto-graduation, the promotion ladder, and the per-task `requires_rank` floor; ripping it out forfeits the zero-day-one-change guarantee. Ranks become *seeded roles* and the column stays as identity/graduation — a strangler, not a rewrite.
 - **Make every permission grantable (no `system` flag).** Rejected — it is the whole risk. A configurable role that could be granted `deploy` or `path.protected.modify` would let an Archon (or a compromised Archon token) hand the crown jewels to a `xenos`. The `system` flag + "substrate enforces" is what makes the tab safe; the abuse-matrix test (R112) exists to prove it.
-- **Enforce the protected-surface floor in the app (move the substrate in-process).** Rejected — it re-opens exactly the gap [ADR 0043](<redacted>.md) closed. Git/SSH sit *outside* the HTTP boundary; the authoritative audit must read real git history + real ranks/registry independent of the request path. Governance owns the *data* (policy); the out-of-band substrate stays the *enforcer*.
+- **Enforce the protected-surface floor in the app (move the substrate in-process).** Rejected — it re-opens exactly the gap [ADR 0043](0043-git-ssh-trust-boundary-and-rank-floor-on-permission-paths.md) closed. Git/SSH sit *outside* the HTTP boundary; the authoritative audit must read real git history + real ranks/registry independent of the request path. Governance owns the *data* (policy); the out-of-band substrate stays the *enforcer*.
 - **Cache the resolved permission set per token/TTL.** Rejected, same reasoning as ADR 0016 rejected caching rank: a cache is a stale-authority window on a demotion. The resolver is per-request and uncached; the cost is one more query on a join we already do, bought for instant revocation.
 - **Store roles/permissions as free-form UI data.** Rejected. Permissions map to real routes, so the catalog is **code** — a permission no route consumes is meaningless. The UI assigns and toggles; it never invents a key.
 
@@ -236,4 +236,4 @@ The `system` set is deliberately **tight** — only gates whose delegation would
 - **The trust boundary strengthens.** The 13 duplicated tier/ladder maps — a proven incident source — collapse to one resolver behind a fitness guard; the protected-surface list becomes auditable data with case/Unicode-normalized matching and a mechanical abuse-matrix proof; principals and session-scopes stop being ad-hoc special-cases and become modeled, testable types.
 - **Configurability is bounded by design.** An Archon can compose any `system: false` permission into a custom role, but the `system` set is non-grantable and substrate-enforced, so no configuration can hand out deploy / protected-path / rank-setting power. This is the C6 safety guarantee, proven not asserted.
 - **Zero day-one behavior change.** The compat seed reproduces every current builder's exact powers; the one divergence (unwired divine ranks fail closed instead of latently inheriting Archon) is a fail-closed improvement no live builder touches.
-- **Portable, and the moat.** Governance ships as a `default: true` core module with a neutral config every instance inherits; it is precisely the "governance / audit / org-memory" substrate [ADR 0087](<redacted>.md) named as the hard-to-copy asset. No new recurring cost — tables + code + a config file.
+- **Portable, and the moat.** Governance ships as a `default: true` core module with a neutral config every instance inherits; it is precisely the "governance / audit / org-memory" substrate [ADR 0087](0087-compete-on-governance-not-tooling-cursor.md) named as the hard-to-copy asset. No new recurring cost — tables + code + a config file.

package/docs/adr/0152-landing-gate-served-by-the-core-app.md

@@ -5,7 +5,7 @@
 - **Deciders:** Lars (owner / Archon), Claude
 - **Track:** `internal` (platform serving / instance infra)
 - **Task:** <redacted> ([#1002411](https://example.com/builders#/task/1002411)) — the cutover step of the landing-migration chain L01→L07 under the **Project creation flow** goal ([#1000035](https://example.com/builders#/goal/1000035)).
-- **Builds on:** [ADR 0062](<redacted>.md) (core ↔ host split), [ADR 0108](<redacted>.md) (instance composition / pinned vendored core), [ADR 0111](<redacted>.md) (per-instance Caddy snippets), [ADR 0003](<redacted>.md) (origin certs).
+- **Builds on:** [ADR 0062](0062-medusa-instance-model-decoupling.md) (core ↔ host split), [ADR 0108](0108-instance-composition-configurable-root.md) (instance composition / pinned vendored core), [ADR 0111](0111-instance-hosting-provisioning-module.md) (per-instance Caddy snippets), [ADR 0003](0003-cloudflare-origin-cert-over-letsencrypt.md) (origin certs).
 - **Supersedes in practice:** the "give the landing its own Caddy config + its own deploy script" plan that L05 was scoped around. See §Decision.
 
 ---
@@ -69,7 +69,7 @@ Generalised for any instance: the pre-launch lock and the apex redirect are **on
 
 Three consequences follow, and they are the actual decision:
 
-**1. There is no separate Caddy config to "give" the landing.** The block above is the *generic* instance block — the same pure-proxy shape `provision.js`'s `caddyBlock()` already writes for every provisioned instance ([ADR 0111](<redacted>.md) §4). The landing stopped being a special case in the proxy the moment the app could serve it. Host-specific values (hostnames, cert paths, whether a lock exists) stay on the host, per [ADR 0062](<redacted>.md) §7 — the core ships the *shape*, not an instance's hostnames.
+**1. There is no separate Caddy config to "give" the landing.** The block above is the *generic* instance block — the same pure-proxy shape `provision.js`'s `caddyBlock()` already writes for every provisioned instance ([ADR 0111](0111-instance-hosting-provisioning-module.md) §4). The landing stopped being a special case in the proxy the moment the app could serve it. Host-specific values (hostnames, cert paths, whether a lock exists) stay on the host, per [ADR 0062](0062-medusa-instance-model-decoupling.md) §7 — the core ships the *shape*, not an instance's hostnames.
 
 **2. There is no separate deploy script to write.** The landing ships **inside the pinned core package**, so it rides the instance's existing deploy: bump the core pin in the instance repo → the box's pull-deploy picks it up → the new landing is live. One artifact, one version number, one deploy path. A landing change is now a normal core change (edit `public-landing/`, ship, release), not an out-of-band push to a foreign repo.
 

package/docs/adr/0152-metic-task-abandonment.md

@@ -4,7 +4,7 @@
 - **Date:** 2026-07-27
 - **Deciders:** Lars (Archon), Claude
 
-**Builds on / amends:** [ADR 0090](<redacted>.md) (Metic task authoring — this ADR reverses one line of its "what stays Archon-only" list), [ADR 0016](<redacted>.md) (server-enforced rank boundary — unchanged), [ADR 0151](<redacted>.md) (permissions-as-atom — the `task.abandon` floor moves with the gate).
+**Builds on / amends:** [ADR 0090](0090-metic-task-authoring.md) (Metic task authoring — this ADR reverses one line of its "what stays Archon-only" list), [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (server-enforced rank boundary — unchanged), [ADR 0151](0151-governance-permissions-as-atom-ranks-as-roles.md) (permissions-as-atom — the `task.abandon` floor moves with the gate).
 
 **Track:** `internal` (GDS / methodology — a Cloud Bongos platform capability). Task [1002476](https://cloudbongos.com/builders#/task/1002476).
 
@@ -12,7 +12,7 @@
 
 ## Context
 
-[ADR 0090](<redacted>.md) moved task **authoring** down to the trusted working rank: a Metic can create a task, edit it, promote it backlog→ready, and wire its dependencies and criterion links. Its "what stays Archon-only" list kept one lifecycle transition behind: `POST /tasks/:id/abandon`, described there as "terminal scope removal — the inverse of promote; a destructive lifecycle kill."
+[ADR 0090](0090-metic-task-authoring.md) moved task **authoring** down to the trusted working rank: a Metic can create a task, edit it, promote it backlog→ready, and wire its dependencies and criterion links. Its "what stays Archon-only" list kept one lifecycle transition behind: `POST /tasks/:id/abandon`, described there as "terminal scope removal — the inverse of promote; a destructive lifecycle kill."
 
 A year of using that split showed the asymmetry costs more than it protects. A Metic runs `/idea-triage`, decides which ideas become work, seeds the tasks, and shapes them — and then hits a wall on the one operation that cleans up after all of it. Duplicates they created, chores that a parallel session already shipped, and tasks their own re-scoping made moot all had to be handed back to the owner to retire. The Archon was not adjudicating anything in those hand-backs; they were doing janitorial work on a queue they had already delegated.
 
@@ -22,7 +22,7 @@ Lars's directive (2026-07-27): **"Metics should also be able to abandon tasks."*
 
 Abandoning is a one-way door *through the API*: `/promote` accepted only `backlog`/`blocked`, `PATCH /tasks/:id` refuses `status` outright ([#514](https://cloudbongos.com/builders#/task/514)), and nothing else writes `status='abandoned'` back to a live value. Restoring a wrongly-retired task meant hand-SQL on prod — an Archon-with-ssh operation.
 
-That was tolerable while abandon *was* Archon-only (the person who could break it could fix it). Handing the kill switch to Metic without an undo would not have removed the owner-cleanup burden; it would have swapped "please retire this" requests for "please un-retire this" requests, with a worse failure mode — a wrongly-abandoned task is invisible in every claimable list and every version rollup ([migration 017](../../migrations/<redacted>.sql) deliberately excludes abandoned from `version_progress`), so nobody notices the mistake until the work silently doesn't happen.
+That was tolerable while abandon *was* Archon-only (the person who could break it could fix it). Handing the kill switch to Metic without an undo would not have removed the owner-cleanup burden; it would have swapped "please retire this" requests for "please un-retire this" requests, with a worse failure mode — a wrongly-abandoned task is invisible in every claimable list and every version rollup ([migration 017](../../migrations/017_version_progress_exclude_abandoned.sql) deliberately excludes abandoned from `version_progress`), so nobody notices the mistake until the work silently doesn't happen.
 
 ## Decision
 
@@ -35,7 +35,7 @@ That was tolerable while abandon *was* Archon-only (the person who could break i
 | `POST /tasks/:id/abandon` | archon | **metic+** |
 | `POST /tasks/:id/promote` | backlog\|blocked → ready | **+ abandoned → backlog** (metic+, unchanged rank) |
 
-Restore lands in `backlog`, never straight to `ready`. The task was retired deliberately; bringing it back should re-enter it as un-workable and require a second, explicit promote to become claimable. The restore branch returns before the reward gate ([ADR 0096](<redacted>.md)) — that is a promote-to-*workable* concern, and `backlog` is the pre-workable state, the same reasoning `/demote` already uses.
+Restore lands in `backlog`, never straight to `ready`. The task was retired deliberately; bringing it back should re-enter it as un-workable and require a second, explicit promote to become claimable. The restore branch returns before the reward gate ([ADR 0096](0096-require-reward-before-workable.md)) — that is a promote-to-*workable* concern, and `backlog` is the pre-workable state, the same reasoning `/demote` already uses.
 
 The backing `db.restoreTask` is the mirror of `db.abandonTask`: `SELECT … FOR UPDATE`, guard, single `UPDATE`, commit, with `TASK_NOT_FOUND` / `TASK_NOT_ABANDONED` as its refusals. It clears the `value_summary = 'Abandoned: <reason>'` stamp abandon writes — and *only* that stamp (`CASE WHEN value_summary LIKE 'Abandoned: %'`) — so a restored task never carries a retire note into a later ship card or `#ship-news` broadcast, while an unrelated summary survives.
 
@@ -48,15 +48,15 @@ The backing `db.restoreTask` is the mirror of `db.abandonTask`: `SELECT … FOR
 ### Downgrade protection + the permission catalog
 
 - `EXPECTED_RANKS`'s lifecycle pin (`src/bongos/route-rank-check.js`, `MODULE_EXPECTED_RANKS.lifecycle`) moves to `metic+archon` in lockstep, so a *further* silent downgrade (to `any-builder`) is still a hard CI fail, and the route's `// rank:` annotation matches the middleware.
-- Under [ADR 0151](<redacted>.md) the `task.abandon` permission's `floor` moves `archon` → `metic`. Because `RANK_ROLE_SEED` is *derived* from floors, that one edit re-derives the seed; the live grant arrives as `modules/governance/migrations/<redacted>.sql`, since the compat seed (002) is run-once and editing it would leave every already-migrated database on the old grant. The floor change is purely **additive** (archon already holds the permission — the seeded roles are cumulative supersets), so nothing is revoked. `tests/governance_seed.mjs` was generalized to compare the **union** of all grant migrations against the catalog, and now fails loudly if a future migration ever *revokes*, which the union model could not represent.
+- Under [ADR 0151](0151-governance-permissions-as-atom-ranks-as-roles.md) the `task.abandon` permission's `floor` moves `archon` → `metic`. Because `RANK_ROLE_SEED` is *derived* from floors, that one edit re-derives the seed; the live grant arrives as `modules/governance/migrations/governance_003_task_abandon_metic.sql`, since the compat seed (002) is run-once and editing it would leave every already-migrated database on the old grant. The floor change is purely **additive** (archon already holds the permission — the seeded roles are cumulative supersets), so nothing is revoked. `tests/governance_seed.mjs` was generalized to compare the **union** of all grant migrations against the catalog, and now fails loudly if a future migration ever *revokes*, which the union model could not represent.
 
 ## Consequences
 
 - **The triage→author→retire loop closes for Metic.** The owner is out of the janitorial path for the queue they already delegated; the remaining owner-only lifecycle powers are ratification and scope-closing, which is where ADR 0090 wanted the line.
 - **A mis-retire is now self-service to fix, at the rank that caused it** — and, notably, this also removes an Archon-with-ssh chore that existed *before* this grant.
 - **Restore is deliberately not idempotent-friendly the way abandon is.** Calling `/promote` on a non-abandoned task still 409s `cannot_promote` with the current status; the restore path refuses rather than guessing. That keeps `/promote`'s contract honest — it is one route with two explicit source states, not a "make this task alive somehow" verb.
-- **Larger trusted surface, same shape as ADR 0090's.** A Metic can now retire any non-shipped, unclaimed task in any open version, with no per-version/per-module fence. That is the same accepted "tighten later" debt: if Metic authority is ever folded into the goal-scope model ([ADR 0086](<redacted>.md)), abandon travels with it.
-- **Trust boundary intact** ([ADR 0016](<redacted>.md)): enforcement stays server-side, per request, uncached. Editing a doc or `CLAUDE.md` grants nothing; `requireRank('metic','archon')` on the route is the authority.
+- **Larger trusted surface, same shape as ADR 0090's.** A Metic can now retire any non-shipped, unclaimed task in any open version, with no per-version/per-module fence. That is the same accepted "tighten later" debt: if Metic authority is ever folded into the goal-scope model ([ADR 0086](0086-goal-scoped-work-hierarchy.md)), abandon travels with it.
+- **Trust boundary intact** ([ADR 0016](0016-trust-boundary-server-enforced-permissions.md)): enforcement stays server-side, per request, uncached. Editing a doc or `CLAUDE.md` grants nothing; `requireRank('metic','archon')` on the route is the authority.
 
 ## Alternatives considered
 

package/docs/adr/0153-sequential-chain-runner.md

@@ -3,7 +3,7 @@
 - **Status:** accepted
 - **Date:** 2026-07-28
 - **Task:** 1002484
-- **Relates to:** [ADR 0015](<redacted>.md) (dependencies + auto-promotion), [ADR 0049](<redacted>.md) (the split parallel-safety contract), [ADR 0086](<redacted>.md) §5 (polymorphic dependency edges)
+- **Relates to:** [ADR 0015](0015-task-dependencies-and-auto-promotion.md) (dependencies + auto-promotion), [ADR 0049](0049-split-parallel-safety-contract.md) (the split parallel-safety contract), [ADR 0086](0086-goal-scoped-work-hierarchy.md) §5 (polymorphic dependency edges)
 
 ## Context