npm - @bongos/core - Versions diffs - 1.19.715 → 1.19.724 - Mend

@bongos/core 1.19.715 → 1.19.724

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (414) hide show

package/docs/design/landing-page-direction-v2.md CHANGED Viewed

@@ -60,7 +60,7 @@ What the pick settles: the settled constraint (dark-first with a real, tested li
 **2026-08-28, the second note (task 1003334).** Seeing the before/after of task 1003333, the owner found the chrome bongo pair sitting on the top-right sweeping form did not fit ("the random bongos on the blobs background"). Offered three treatments (remove it from the hero; keep it off the blob on plain black or paper; phones only), the owner picked **remove it from the hero**. The pair is no longer a hero object: `.mark`, its arrival and its tokens leave; it stays as the closing figure, the second project orb and the bar's mark. The sweeping form stays as a bare backdrop. Under 900 the masthead is the big blob alone, with the words keeping the 56vw the pair used to hold above them.
-**2026-08-28, the third note — dark only (task 1003336, [ADR 0204](../adr/<redacted>.md)).** Reviewing the planets (task 1003319) with both grounds in front of them, the owner took option 4 of §5 after all, widened to the whole apex: "only black or only white is a bit bland, frankly I am leaning towards only dark mode for this page and keep the dark/light mode to be solely for the builder hall … we could invest into a cool space themed backdrop for the blobs." Built: `data-mode="dark"` fixed on `<html>` of every apex page, the pre-paint script and the persisted `cb-color-mode` gone, the moon/sun glyph and its wiring out of both bars, the kit rendering dark only. What the 2026-08-27 pick settled about light — the cutouts on paper under a contact shadow, the toggle staying on the landing — no longer describes the apex; the cutouts remain the closing figure and the planets' masks. The light tier of `world.css` stays until its own removal. The space backdrop is the next task (1003337).
+**2026-08-28, the third note — dark only (task 1003336, [ADR 0204](../adr/0204-the-apex-is-dark-only.md)).** Reviewing the planets (task 1003319) with both grounds in front of them, the owner took option 4 of §5 after all, widened to the whole apex: "only black or only white is a bit bland, frankly I am leaning towards only dark mode for this page and keep the dark/light mode to be solely for the builder hall … we could invest into a cool space themed backdrop for the blobs." Built: `data-mode="dark"` fixed on `<html>` of every apex page, the pre-paint script and the persisted `cb-color-mode` gone, the moon/sun glyph and its wiring out of both bars, the kit rendering dark only. What the 2026-08-27 pick settled about light — the cutouts on paper under a contact shadow, the toggle staying on the landing — no longer describes the apex; the cutouts remain the closing figure and the planets' masks. The light tier of `world.css` stays until its own removal. The space backdrop is the next task (1003337).
 ## 7. Shot list: real imagery still owed

package/docs/design/projects-hub-direction-v2.md CHANGED Viewed

@@ -173,7 +173,7 @@ Three mastheads, rendered dark and light at 1440 / 390 / 320 (ALL CLEAN) and mea
 ## 12. Dark only (task 1003336)
-**Date:** 2026-08-28 (decided), 2026-08-29 (built) · the owner's call on the planets review (§11): the apex renders dark only and the light/dark switch is the builders' hall's alone — [ADR 0204](../adr/<redacted>.md). On `/projects`: `data-mode="dark"` is fixed on `<html>`, the pre-paint script is gone, the `#modeToggle` glyph and its `resolvedMode` / `paintModeToggle` wiring leave the bar (Projects, then the chip), the `.modeBtn` rules and the icon-swap twins leave `cosmos.css`, the mode-toggle probe leaves `projects.probes.json`, and `projects.states.json` declares `"modes": ["dark"]` so the kit renders the hub's twelve states at three widths in one mode (48 shots, ALL CLEAN; probes 31/31). The light tier of `cosmos.css` stays until its own removal. Why first: the space backdrop for the field (task 1003337) is a black-ground plate; one mode is what lets the field commit to it.
+**Date:** 2026-08-28 (decided), 2026-08-29 (built) · the owner's call on the planets review (§11): the apex renders dark only and the light/dark switch is the builders' hall's alone — [ADR 0204](../adr/0204-the-apex-is-dark-only.md). On `/projects`: `data-mode="dark"` is fixed on `<html>`, the pre-paint script is gone, the `#modeToggle` glyph and its `resolvedMode` / `paintModeToggle` wiring leave the bar (Projects, then the chip), the `.modeBtn` rules and the icon-swap twins leave `cosmos.css`, the mode-toggle probe leaves `projects.probes.json`, and `projects.states.json` declares `"modes": ["dark"]` so the kit renders the hub's twelve states at three widths in one mode (48 shots, ALL CLEAN; probes 31/31). The light tier of `cosmos.css` stays until its own removal. Why first: the space backdrop for the field (task 1003337) is a black-ground plate; one mode is what lets the field commit to it.
 ## 13. The space and the materials (task 1003337)

package/docs/file-map.md CHANGED Viewed

@@ -1,7 +1,7 @@
 # File Map — Where Things Live
 > Split out of `CLAUDE.md` §11 in V3.R86 ([#305](https://example.com/builders#/task/305)) to keep the agent index lean. `CLAUDE.md` §11 now
-> carries a one-paragraph orientation and points here. Paths below are relative to the repo root — **today** one checkout. [ADR 0108](adr/<redacted>.md) (configurable-root) means that stops being universally true once a consumer installs the core as a `node_modules` dependency: `resolveCoreRoot()` and `resolveInstanceRoot()` ([`src/instance-config.js`](../src/instance-config.js)) can diverge, and this single tree below splits into a **core-package tree** (everything `isPublishable()` selects — see [`docs/modules-contract.md`](modules-contract.md) and [ADR 0098](adr/<redacted>.md)) and an **instance tree** (`config/`, instance `modules/`, `migrations/instance/`, `.claude/` once materialized — ADR 0108 §3). Both resolvers return this repo's root today, so the tree below is still accurate for the live instance; this note is the marker for when that stops being true (ADR 0108 §6 lands the split on Mercury, R85, before Example).
+> carries a one-paragraph orientation and points here. Paths below are relative to the repo root — **today** one checkout. [ADR 0108](adr/0108-instance-composition-configurable-root.md) (configurable-root) means that stops being universally true once a consumer installs the core as a `node_modules` dependency: `resolveCoreRoot()` and `resolveInstanceRoot()` ([`src/instance-config.js`](../src/instance-config.js)) can diverge, and this single tree below splits into a **core-package tree** (everything `isPublishable()` selects — see [`docs/modules-contract.md`](modules-contract.md) and [ADR 0098](adr/0098-public-mirror-publish-manifest.md)) and an **instance tree** (`config/`, instance `modules/`, `migrations/instance/`, `.claude/` once materialized — ADR 0108 §3). Both resolvers return this repo's root today, so the tree below is still accurate for the live instance; this note is the marker for when that stops being true (ADR 0108 §6 lands the split on Mercury, R85, before Example).
 **Project root:**
@@ -255,6 +255,7 @@
 │   │   ├── cascade-dispatch.js  ← (dormant System 3, ADR 0079) the model-tier escalation ladder for autonomous dispatch
 │   │   ├── goal-scope-check.js / hierarchy-config.js / module-scope-map.js ← goal-scope protected-path checks, the configurable work-hierarchy tiers, and the module→file-glob map
 │   │   ├── project-door.js      ← the project's COMPOSED join/apply door — visibility × join_grant × joinability → open | apply | invite_only | locked (BV1.R12 / task 1002331, ADR 0182 D6 + ADR 0247). PURE + kernel; published as api.projectJoinDoor() so the public POST /access-requests, the hall landing form, the CLI and the hub's join relay cannot answer one stranger differently — and since task 1003579 (ADR 0256) the SIGN-IN gate reads it too (openEnrollmentEnabled), which is why joinabilityMode() lives here rather than in auth-admission.js
+│   │   ├── artist-gate.js       ← the project's ARTIST GATE — off | advisory | strict (task 1003575, ADR 0241). PURE + kernel; published as api.artistGate so the lifecycle cascade ("file this review?") and the pin move ("does an open one hold?") resolve the same knob through one reader. It reads a STATE (is a cascade-filed artist review still open?), never a verdict, and what it can hold is the DEPLOY, never a builder's ship — that boundary is the whole reconciliation with ADR 0162
 │   │   ├── path-match.js / repo-info.js / metrics.js / uptime-poller.js / app-pair.js ← touches[] overlap matcher, git-remote parser, Prometheus metrics endpoint, uptime poller, Claude-Desktop pairing store
 │   └── world/
 │       ├── terrain.js           ← (Phase D + ADR 0012, CJS): TERRAIN + OBJECT enums + BLOCKING_TERRAINS + BLOCKING_OBJECTS (server twin of public/game/world/terrain.js)
@@ -456,6 +457,7 @@ tests/
 ├── overnight-builder/SKILL.md         ← autonomous overnight session-runner — claims the highest-priority safe task, works it end-to-end and ships it; autonomy-gated and OFF by default (restored in task 1003365; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)
 ├── overnight-code-review/SKILL.md     ← nightly autonomous code-quality review; each finding lands as its own idea_inbox row so it survives triage; autonomy-gated and OFF by default (restored in task 1003365; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)
 ├── peer-vote-tally/SKILL.md           ← deterministic tally (`tally.js`) folding builder-on-builder peer votes at least 7 days old into karma_log rows (criterion C2) (restored in task 1003365; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)
+├── rank-roles-audit/SKILL.md          ← nightly deterministic check that every builder holds one of the four live ranks, so none silently resolves to zero permissions under the governance_002 backfill's INNER JOIN; detect-only, files one idea_inbox row and never repairs, and never fatal at boot (task 1002873; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)
 ├── redteam-weekly/SKILL.md            ← weekly deterministic red-team patrol (task 1003128): full-history gitleaks scan + dependency drift review (audit delta, cooldown, young pkgs, stale overrides) + action-pin check → files security reports (advisory, ADR 0162). FIRED BY .github/workflows/redteam-patrol.yml, Mondays 06:17 UTC — `cadence: weekly` here and that cron must agree or fitness Check 25 (scripts/gds/routine-schedule.js) fails the gate (task 1003209, ADR 0188)
 ├── repo-simplify-sweep/SKILL.md       ← weekly repo-cleanliness janitor — runs repo-metrics, files dead-code findings to idea_inbox, and auto-fixes only the narrow safe class (restored in task 1003365; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)
 ├── security-review-weekly/SKILL.md    ← weekly security-state review — stale vulnerability_reports, ageing security-tagged tasks, recent high/critical dependency alerts; one Archon broadcast when anything is stale, silent otherwise (restored in task 1003365; unscheduled in core — only redteam-weekly has a firing workflow; config/scheduled-routines.json records the intended cadence)

package/docs/module-api-changelog.md CHANGED Viewed

@@ -7,7 +7,7 @@ The release ledger for `CORE_VERSION`, the semver of the published module doorwa
 `src/module-api.js` and is still the single literal every release reads. Only the
 history lives here.
-**Why the history moved** ([ADR 0203](adr/<redacted>.md)):
+**Why the history moved** ([ADR 0203](adr/0203-doorway-changelog-out-of-module-api.md)):
 the CI auto-patch carrier (ADR 0161) appends a two-line entry on *every* release and
 pushes straight to `main`, bypassing the `unit` gate. As a comment block inside
 `src/module-api.js` that growth pushed the file past the 1500-line
@@ -1889,5 +1889,38 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.713 with no explicit bump. run 34746102135. (task 1002620)
   1.19.715 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.714 with no explicit bump. run 34747181910. (task 1002620)
+  1.19.716 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.715 with no explicit bump. run 34750496516. (task 1002620)
+  (next carrier) — artistGate + getFoundingBuilder re-exported (task 1003575,
+        goal 1000074; ADR 0241). The project ARTIST GATE — off | advisory | strict —
+        and the pure verdict helpers over it. Two modules ask it two different
+        questions: the lifecycle cascade asks "should this artist review be filed at
+        all?" (off files none), and the deploy asks "does an open one hold the pin?"
+        (strict holds it). Both must resolve the knob through THIS one reader rather
+        than branding().project, because the fail-closed default and ADR 0241
+        section 5 non-retroactivity cutoff live in it, and a second reader is how the
+        level that FILES and the level that HOLDS start disagreeing.
+        getFoundingBuilder rides with it as kernel identity beside getBuilderById:
+        ADR 0241 section 3 gives the gate's one escape hatch to the PROJECT OWNER
+        alone, and a module cannot enforce that without being able to ask who that
+        is. Additive — a MINOR by the 1.19.0 precedent, but a hand-bumped version
+        cannot pass the publish lane LIVE test (tests/bump_version.mjs), so it rides
+        the next CI patch, exactly as projectJoinDoor did.
+  1.19.717 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.716 with no explicit bump. run 34751690435. (task 1002620)
+  1.19.718 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.717 with no explicit bump. run 34753530801. (task 1002620)
+  1.19.719 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.718 with no explicit bump. run 34754578762. (task 1002620)
+  1.19.720 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.719 with no explicit bump. run 34755367817. (task 1002620)
+  1.19.721 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.720 with no explicit bump. run 34756186426. (task 1002620)
+  1.19.722 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.721 with no explicit bump. run 34757838186. (task 1002620)
+  1.19.723 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.722 with no explicit bump. run 34758720786. (task 1002620)
+  1.19.724 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.723 with no explicit bump. run 34759302425. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/docs/modules-contract.md CHANGED Viewed

@@ -1,7 +1,7 @@
 # The module plugin-API contract (`src/module-api.js` + `modules/*/`)
-> **Decision record:** [ADR 0083](adr/<redacted>.md) — the build plan.
-> **Live state:** the shipped modules under `modules/` are the four feature modules `dev-box`, `game`, `discord`, `art-pipeline` (+ `character-anim`, declaration-only; ADR 0088) and the carved core-domain modules `memory` (R72), `grading` (R73), `economy` (R77), `ideas` (R78), `security` (R79), `builder-settings` (R80), `onboarding` (R81), and `sessions` (R82) — see [ADR 0093](adr/<redacted>.md) for the remaining carve sequence.
+> **Decision record:** [ADR 0083](adr/0083-modular-architecture-strangler-build-plan.md) — the build plan.
+> **Live state:** the shipped modules under `modules/` are the four feature modules `dev-box`, `game`, `discord`, `art-pipeline` (+ `character-anim`, declaration-only; ADR 0088) and the carved core-domain modules `memory` (R72), `grading` (R73), `economy` (R77), `ideas` (R78), `security` (R79), `builder-settings` (R80), `onboarding` (R81), and `sessions` (R82) — see [ADR 0093](adr/0093-tranche-2-core-carve-sequence.md) for the remaining carve sequence.
 > **Author a new module:** jump to [the module-author recipe](#module-author-recipe).
 The module system turns optional features into self-contained directories. Adding a feature is "drop `modules/<key>/`"; the loader discovers, validates, and mounts it — no core file changes. The **one-way rule** is the load-bearing invariant:
@@ -18,7 +18,7 @@ Two fitness checks enforce it on every build — a violation is a red CI gate, n
 ## The cut: core vs modules
-- **Core** is the trust kernel + the lifecycle state machine + the domains not yet carved: auth/identity/audit/rank (the kernel, [ADR 0091](adr/<redacted>.md) §1), the lifecycle (tasks, claims, versions, done-when, ship — never split), and the still-core domains (autonomy/MAS, the two web UIs) plus always-on infra (analytics, audit-log, gate-approvals, healthz, public). The remaining tranche-2 domains carve out per [ADR 0093](adr/<redacted>.md) §1; the lifecycle stays core. (Sessions/BFG — the `session_records` corpus + data plane + the BFG scorer + session-pulse — carved to `modules/sessions/` at R82; like `memory` it registers no port and core never calls back in. The per-claim `session_logs` ship LOG + `builder_sessions` auth tokens stay core.)
+- **Core** is the trust kernel + the lifecycle state machine + the domains not yet carved: auth/identity/audit/rank (the kernel, [ADR 0091](adr/0091-bounding-the-kernel-and-db-carve.md) §1), the lifecycle (tasks, claims, versions, done-when, ship — never split), and the still-core domains (autonomy/MAS, the two web UIs) plus always-on infra (analytics, audit-log, gate-approvals, healthz, public). The remaining tranche-2 domains carve out per [ADR 0093](adr/0093-tranche-2-core-carve-sequence.md) §1; the lifecycle stays core. (Sessions/BFG — the `session_records` corpus + data plane + the BFG scorer + session-pulse — carved to `modules/sessions/` at R82; like `memory` it registers no port and core never calls back in. The per-claim `session_logs` ship LOG + `builder_sessions` auth tokens stay core.)
 - **Modules** are optional features an instance turns on via `config/modules.json` or env (the feature modules `dev-box`, `game`, `discord`, `art-pipeline`, `character-anim`), plus the **core-domain modules** that are `default: true` (always on unless disabled): `memory` (R72), `grading` (R73), `economy` — credits/cost/streaks/achievements/leaderboard (R77), `ideas` — inbox/capture/triage/blockers (R78), `security` — red-team reports + bounty (R79), `builder-settings` — wandering/skill/sound/render prefs + builder-needs (R80), `onboarding` — admission/onboarding-state/newcomer-restock (R81), and `sessions` — session_records corpus + BFG + session-pulse (R82). Each is a self-contained directory under `modules/<key>/`.
 ---
@@ -54,7 +54,7 @@ A module's `module.json` declares `"coreVersion": "^1.4.0"` (a semver range). Th
 **Current `CORE_VERSION`:** `1.8.0`
-> The table below is a hand-maintained summary of the MINOR bumps only, and it lags. The authoritative, complete release ledger — every version, including the CI carrier patches — is [`docs/module-api-changelog.md`](module-api-changelog.md) ([ADR 0203](adr/<redacted>.md) moved it out of `src/module-api.js`); the live value is the `const CORE_VERSION` literal in `src/module-api.js`.
+> The table below is a hand-maintained summary of the MINOR bumps only, and it lags. The authoritative, complete release ledger — every version, including the CI carrier patches — is [`docs/module-api-changelog.md`](module-api-changelog.md) ([ADR 0203](adr/0203-doorway-changelog-out-of-module-api.md) moved it out of `src/module-api.js`); the live value is the `const CORE_VERSION` literal in `src/module-api.js`.
 | Bump | What it added |
 |---|---|
@@ -113,19 +113,19 @@ Every module must have a `module.json` at its root (`modules/<key>/module.json`)
 An unknown key throws at validate time — typos fail loud (top-level attribution fields have no closed allowlist; only `contributes` sub-keys do).
-### `dependencies` — a module's own npm deps ([ADR 0138](adr/<redacted>.md))
+### `dependencies` — a module's own npm deps ([ADR 0138](adr/0138-bundled-module-deps-declared-per-module.md))
-`@bongos/core` ships lean — its synthesized `package.json` declares only `express` + `pg` ([ADR 0108](adr/<redacted>.md)). A bundled module that needs an external npm package at runtime (e.g. `discord` → `discord.js`) declares it in its own `module.json` `dependencies` (`{ "<npm-name>": "<semver-range>" }`, schema-validated). **Core does not carry it**, so the *consumer* must — greenfield `bongos init` composes the ENABLED modules' declared deps into the instance `package.json` (`enabledModuleDeps` → `buildInstancePackageJson`; an explicit pre-existing pin wins, `@bongos/core` is always set), and the R89 cutover preserves the monolith's existing dependency closure. If a module needs a dep and neither declares it nor is it in the consumer's closure, an instance that enables the module crashes at boot — so **declare it here**.
+`@bongos/core` ships lean — its synthesized `package.json` declares only `express` + `pg` ([ADR 0108](adr/0108-instance-composition-configurable-root.md)). A bundled module that needs an external npm package at runtime (e.g. `discord` → `discord.js`) declares it in its own `module.json` `dependencies` (`{ "<npm-name>": "<semver-range>" }`, schema-validated). **Core does not carry it**, so the *consumer* must — greenfield `bongos init` composes the ENABLED modules' declared deps into the instance `package.json` (`enabledModuleDeps` → `buildInstancePackageJson`; an explicit pre-existing pin wins, `@bongos/core` is always set), and the R89 cutover preserves the monolith's existing dependency closure. If a module needs a dep and neither declares it nor is it in the consumer's closure, an instance that enables the module crashes at boot — so **declare it here**.
-**Attribution (`author`/`origin`/`license`/`maintainer`) is portable metadata, not a cross-Bongos link** — each repo runs its own Bongos with its own builder identities ([ADR 0100](adr/<redacted>.md) §3), so credit travels *with the module* rather than through a foreign key ([ADR 0107](adr/<redacted>.md) §2). `bongos module new` stamps all four as TODO placeholders (license defaults to `AGPL-3.0`) so a module carries its authorship from the day it's scaffolded, not bolted on later at upstream-submit time.
+**Attribution (`author`/`origin`/`license`/`maintainer`) is portable metadata, not a cross-Bongos link** — each repo runs its own Bongos with its own builder identities ([ADR 0100](adr/0100-two-repo-instance-model.md) §3), so credit travels *with the module* rather than through a foreign key ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §2). `bongos module new` stamps all four as TODO placeholders (license defaults to `AGPL-3.0`) so a module carries its authorship from the day it's scaffolded, not bolted on later at upstream-submit time.
-**`bongos module list [--catalog] [--search <text>] [--json]`** ([ADR 0107](adr/<redacted>.md) §2/§3, [ADR 0167](adr/<redacted>.md)) is the browsable catalog from the terminal: every module on disk with its enabled state, its author + origin credit, and its upkeep posture. `--catalog` narrows to the **core-shipped** modules — the shared catalog an instance opts into (§6, default-off). Two axes travel on each row and they are *not* the same question: **`source`** (which tree ships it — the core package or this instance's own repo, read structurally from the loader's discovery root, [ADR 0108](adr/<redacted>.md) §1) and **`provenance`** (who built it, derived from the declared `origin`). A core module that declares no attribution is credited to the platform and the credit is **marked inferred** (`*`) rather than left blank or silently invented. The hall's Modules tab renders the same model (`src/module-loader/catalog.js`) via `GET /modules`, so the two surfaces cannot drift.
+**`bongos module list [--catalog] [--search <text>] [--json]`** ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §2/§3, [ADR 0167](adr/0167-module-catalog-source-vs-provenance.md)) is the browsable catalog from the terminal: every module on disk with its enabled state, its author + origin credit, and its upkeep posture. `--catalog` narrows to the **core-shipped** modules — the shared catalog an instance opts into (§6, default-off). Two axes travel on each row and they are *not* the same question: **`source`** (which tree ships it — the core package or this instance's own repo, read structurally from the loader's discovery root, [ADR 0108](adr/0108-instance-composition-configurable-root.md) §1) and **`provenance`** (who built it, derived from the declared `origin`). A core module that declares no attribution is credited to the platform and the credit is **marked inferred** (`*`) rather than left blank or silently invented. The hall's Modules tab renders the same model (`src/module-loader/catalog.js`) via `GET /modules`, so the two surfaces cannot drift.
-**`bongos module check <key> [--sign-off "Name <email>"]`** ([ADR 0107](adr/<redacted>.md) §4) is the submit-time pre-check a module must clear before it can be upstreamed. It reuses (never re-types) the public-mirror publish denylist (`scripts/gds/publish-manifest.js`'s `matchesDeny`) to reject content that cannot ship under AGPL (game content, pixel art, copyrighted reference material) — deliberately the DENY half only, since a brand-new module is never on the publish ALLOWLIST until it's accepted into core (§6). It also requires `module.json`'s `license` to be AGPL-3.0 (inbound = outbound) and a declared `maintenance` posture — acceptance is a commitment to upkeep, so a module with no `maintenance.status`, or one already `deprecated`/`orphaned`, is refused ([ADR 0166](adr/<redacted>.md); see below). On a pass, `--sign-off` records a lightweight DCO-style affirmation (own work, licensed AGPL-3.0 — never a copyright-assignment CLA) to `modules/<key>/.upstream-signoff.json`.
+**`bongos module check <key> [--sign-off "Name <email>"]`** ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §4) is the submit-time pre-check a module must clear before it can be upstreamed. It reuses (never re-types) the public-mirror publish denylist (`scripts/gds/publish-manifest.js`'s `matchesDeny`) to reject content that cannot ship under AGPL (game content, pixel art, copyrighted reference material) — deliberately the DENY half only, since a brand-new module is never on the publish ALLOWLIST until it's accepted into core (§6). It also requires `module.json`'s `license` to be AGPL-3.0 (inbound = outbound) and a declared `maintenance` posture — acceptance is a commitment to upkeep, so a module with no `maintenance.status`, or one already `deprecated`/`orphaned`, is refused ([ADR 0166](adr/0166-module-maintenance-and-deprecation-policy.md); see below). On a pass, `--sign-off` records a lightweight DCO-style affirmation (own work, licensed AGPL-3.0 — never a copyright-assignment CLA) to `modules/<key>/.upstream-signoff.json`.
-### `maintenance` — who keeps this module true as the core advances ([ADR 0166](adr/<redacted>.md))
+### `maintenance` — who keeps this module true as the core advances ([ADR 0166](adr/0166-module-maintenance-and-deprecation-policy.md))
-A module pinned to an old `coreVersion` rots as the core advances ([ADR 0107](adr/<redacted>.md) §7). The `maintenance` block is where a module states, in a place the upgrade pre-check can read, **who owns that upkeep** — and what happens if nobody does. It is optional in the schema (pre-policy manifests keep validating) but **required to be upstreamed**.
+A module pinned to an old `coreVersion` rots as the core advances ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §7). The `maintenance` block is where a module states, in a place the upgrade pre-check can read, **who owns that upkeep** — and what happens if nobody does. It is optional in the schema (pre-policy manifests keep validating) but **required to be upstreamed**.
 | `status` | Means | What it owes |
 |---|---|---|
@@ -136,15 +136,15 @@ A module pinned to an old `coreVersion` rots as the core advances ([ADR 0107](ad
 `orphaned` is a first-class, declarable state on purpose: a policy that only permits happy statuses gets satisfied by lying. `removeAfter` is rejected on a non-sunset status, and is **declarative** — nothing deletes a module automatically; `bongos upgrade` only reports that the core has advanced past the date.
-**What surfaces it.** `bongos upgrade` appends a maintenance hint to every `coreVersion` mismatch row and rolls up deprecations, modules past `removeAfter`, and modules with no declared upkeep. A **real** bump (`bongos upgrade --to <version>`) does the same via `preflightModules` → `reportModulePreflight`, printed before the blocking check returns so a refused bump reports them too. The asymmetry is deliberate: an incompatible **enabled** module refuses the bump; an incompatible **disabled** one never blocks but is always reported with its owner named — accepted catalog modules ship `default: false` ([ADR 0107](adr/<redacted>.md) §6), so *every* rotted catalog entry is disabled by construction, and silence there is exactly how the catalog fills with broken entries. `GET /modules` and the hall Modules tab show an `upkeep:` chip, including `upkeep: undeclared`.
+**What surfaces it.** `bongos upgrade` appends a maintenance hint to every `coreVersion` mismatch row and rolls up deprecations, modules past `removeAfter`, and modules with no declared upkeep. A **real** bump (`bongos upgrade --to <version>`) does the same via `preflightModules` → `reportModulePreflight`, printed before the blocking check returns so a refused bump reports them too. The asymmetry is deliberate: an incompatible **enabled** module refuses the bump; an incompatible **disabled** one never blocks but is always reported with its owner named — accepted catalog modules ship `default: false` ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §6), so *every* rotted catalog entry is disabled by construction, and silence there is exactly how the catalog fills with broken entries. `GET /modules` and the hall Modules tab show an `upkeep:` chip, including `upkeep: undeclared`.
-**`bongos module submit <key> [--sign-off "Name <email>"]`** ([ADR 0107](adr/<redacted>.md) §1) re-runs the §4 pre-check + requires a sign-off, then packages the module (manifest + a full file snapshot + the sign-off) and files it into the rank-gated (metic+archon) upstreaming review queue via `POST /modules/:key/submit` — the same route the hall "Modules" tab's submit button calls. Refuses (exit 1) if the pre-check fails or no sign-off can be found/recorded. The queue currently lives in **this instance's own DB**, not a live call to the extracted core repo — see [ADR 0135](adr/<redacted>.md) for why, and `GET /modules/submissions` to read it back.
+**`bongos module submit <key> [--sign-off "Name <email>"]`** ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §1) re-runs the §4 pre-check + requires a sign-off, then packages the module (manifest + a full file snapshot + the sign-off) and files it into the rank-gated (metic+archon) upstreaming review queue via `POST /modules/:key/submit` — the same route the hall "Modules" tab's submit button calls. Refuses (exit 1) if the pre-check fails or no sign-off can be found/recorded. The queue currently lives in **this instance's own DB**, not a live call to the extracted core repo — see [ADR 0135](adr/0135-module-upstream-submission-interim-queue.md) for why, and `GET /modules/submissions` to read it back.
 ---
 ## The loader — `src/module-loader/loader.js`
-> **Two-root discovery ([ADR 0108](adr/<redacted>.md) §1, task 1881/W1 shipped):** `DEFAULT_ROOTS` resolves `modules/` off `resolveCoreRoot()` ([`src/instance-config.js`](../src/instance-config.js)), not a hardcoded `__dirname`-relative path. Today `resolveCoreRoot() === resolveInstanceRoot()` (both the repo root), so discovery is unchanged. Once a consumer installs the core as a package, an **instance-owned** `modules/` directory (host-authored modules, living in the instance repo, not the core package) becomes possible — the loader would then discover across both roots via `opts.roots`, same mechanism as below, no core-file change. That instance-root modules directory does not exist yet; this is the seam it will attach to.
+> **Two-root discovery ([ADR 0108](adr/0108-instance-composition-configurable-root.md) §1, task 1881/W1 shipped):** `DEFAULT_ROOTS` resolves `modules/` off `resolveCoreRoot()` ([`src/instance-config.js`](../src/instance-config.js)), not a hardcoded `__dirname`-relative path. Today `resolveCoreRoot() === resolveInstanceRoot()` (both the repo root), so discovery is unchanged. Once a consumer installs the core as a package, an **instance-owned** `modules/` directory (host-authored modules, living in the instance repo, not the core package) becomes possible — the loader would then discover across both roots via `opts.roots`, same mechanism as below, no core-file change. That instance-root modules directory does not exist yet; this is the seam it will attach to.
 At boot the loader (called from `src/modules.js` and the route mounter) runs:
@@ -154,7 +154,7 @@ At boot the loader (called from `src/modules.js` and the route mounter) runs:
 4. **Enablement filter** — check `isModuleEnabled(key)` (env override → `config/modules.json` → `config/modules.neutral.json` → `manifest.default`); disabled modules are skipped.
 5. **Mount routes** — for each `contributes.routes` key, `require(`modules/<key>/routes/<routeKey>.js`)` and call the factory. Audit is already composed at the kernel level (routes.js runs `auditMiddleware` before the loader mounts anything); each route self-gates at the appropriate rank via `api.requireBuilder` / `api.requireRank`. The fitness check (`BV1.R44`) ensures every write route is rank-gated.
 6. **Start pollers** — call each `contributes.pollers` file's `start()` on successful mount.
-7. **Serve web surfaces** — a `contributes.webSurfaces` entry says WHERE the surface answers in exactly one of two ways, never both and never neither ([ADR 0218](adr/<redacted>.md)):
+7. **Serve web surfaces** — a `contributes.webSurfaces` entry says WHERE the surface answers in exactly one of two ways, never both and never neither ([ADR 0218](adr/0218-the-apex-root-web-surface.md)):
    - `{ host: "status.", dir: "public" }` — a **Host-header prefix**. `serve-internal.js` (via `loader.moduleWebSurfaces`) serves `modules/<key>/<dir>/` on the matching host, with the content-hash-stamped index + branding injection the status page always used. This is how the status dashboard (`status-ui`) reaches `status.<apex>` with no core edit (BV1.R84).
    - `{ apexRoot: true, dir: "public" }` — the **apex root**: whatever host is left once the subdomains are taken (`isApexHost` = `!isStatusHost && !isBuildersHost`). Declared by `public-landing`, the front door, and served by `platform-server.js`'s dedicated block. **`host: ""` is rejected, not read as "the root"** — the routers match with `host.startsWith(s.host)` and every string starts with `""`, so an empty prefix would answer on `builders.`/`status.` too and make `isModuleSurfaceHost()` true for every request, silently un-serving the hall.
@@ -197,12 +197,12 @@ A module calls `api.seams.emit(eventName, payload)` to broadcast. Any module tha
 | Port: `game.precreateWorldRoom` | `game` | `server.js` pre-create step | `(matchMaker) → Promise<void>` — pre-creates the singleton room. |
 | Port: `discord.isLinked` | `discord` | core `routes/me.js` | `(builderId) → Promise<bool>` — whether the builder has linked their Discord account. |
 | Port: `art.sharedKeyConfigured` | `art-pipeline` | core `routes/me.js` | `() → Promise<bool>` — whether a shared Gemini key is configured for the instance. |
-| Port: `grade` | `grading` (R73) | the lifecycle (`routes/tasks.js`, `routes/public.js`) | the quality-gate capability the ship path resolves instead of importing `grader.js` ([ADR 0091](adr/<redacted>.md) §4). |
-| Port: `reward` | `economy` (R77) | the lifecycle (`db.applyGrade`/`confirmTask`/…) + read routes (`me.js`/`public.js`/`builders.js`/`sessions.js`) | a **transaction-participant** port — credit/achievement writes take the caller's tx `client` ([ADR 0093](adr/<redacted>.md) §2). |
-| Port: `ideas.capture` | `ideas` (R78) | the `discord` module (`discord-inbound.js`) | `(idea) → Promise<row>` — file an `idea_inbox` row. The **first module→module port** (every other is consumed by core); retired the `captureIdea` doorway leak ([ADR 0093](adr/<redacted>.md) §5). |
-| Port: `security` | `security` (R79) | core `routes/public.js` (`/public/bounty-table`) | `{ bountyTableDetailed(), bountyTable() }` — the env-aware red-team bounty payout schedule. Core reads via `resolveOptional('security').bountyTableDetailed()` instead of importing the module (security is default-on; only <redacted> moved — [ADR 0093](adr/<redacted>.md) §1, [02-module-map §5](design/modular-architecture/02-module-map.md)). |
-| Port: `builder-settings` | `builder-settings` (R80) | core `routes/me.js` (`GET /me`) + `cascade-dispatch.js` | `{ getBuilderBehaviorPrefs, describeWandering, describeRender, computeNeeds, skillCeiling }` — the per-builder prefs read surface. The `GET /me` aggregator resolves it for its wandering/render/needs slices; the dormant cascade router for the skill ceiling. Default-on; degrades gracefully when off ([ADR 0093](adr/<redacted>.md) §1, [02-module-map §2](design/modular-architecture/02-module-map.md)). |
-| Port: `onboarding` | `onboarding` (R81) | the lifecycle (`db.js` claim/ship — transaction-participant `markStage`) + `auth.js` + `routes/me.js`/`builders.js`/`tasks.js`/`claims.js` | `{ getState, shapeForApi, safeMarkStage, markStage, broadcastGraduation, restockForClaim, restockAll, SOURCE_TAG }` — the onboarding state-machine + newcomer-restock surface. The FIRST core→module port the lifecycle ticks inside its own txn (alongside `reward`). Default-on; degrades to best-effort no-ops when off ([ADR 0093](adr/<redacted>.md) §1). |
+| Port: `grade` | `grading` (R73) | the lifecycle (`routes/tasks.js`, `routes/public.js`) | the quality-gate capability the ship path resolves instead of importing `grader.js` ([ADR 0091](adr/0091-bounding-the-kernel-and-db-carve.md) §4). |
+| Port: `reward` | `economy` (R77) | the lifecycle (`db.applyGrade`/`confirmTask`/…) + read routes (`me.js`/`public.js`/`builders.js`/`sessions.js`) | a **transaction-participant** port — credit/achievement writes take the caller's tx `client` ([ADR 0093](adr/0093-tranche-2-core-carve-sequence.md) §2). |
+| Port: `ideas.capture` | `ideas` (R78) | the `discord` module (`discord-inbound.js`) | `(idea) → Promise<row>` — file an `idea_inbox` row. The **first module→module port** (every other is consumed by core); retired the `captureIdea` doorway leak ([ADR 0093](adr/0093-tranche-2-core-carve-sequence.md) §5). |
+| Port: `security` | `security` (R79) | core `routes/public.js` (`/public/bounty-table`) | `{ bountyTableDetailed(), bountyTable() }` — the env-aware red-team bounty payout schedule. Core reads via `resolveOptional('security').bountyTableDetailed()` instead of importing the module (security is default-on; only <redacted> moved — [ADR 0093](adr/0093-tranche-2-core-carve-sequence.md) §1, [02-module-map §5](design/modular-architecture/02-module-map.md)). |
+| Port: `builder-settings` | `builder-settings` (R80) | core `routes/me.js` (`GET /me`) + `cascade-dispatch.js` | `{ getBuilderBehaviorPrefs, describeWandering, describeRender, computeNeeds, skillCeiling }` — the per-builder prefs read surface. The `GET /me` aggregator resolves it for its wandering/render/needs slices; the dormant cascade router for the skill ceiling. Default-on; degrades gracefully when off ([ADR 0093](adr/0093-tranche-2-core-carve-sequence.md) §1, [02-module-map §2](design/modular-architecture/02-module-map.md)). |
+| Port: `onboarding` | `onboarding` (R81) | the lifecycle (`db.js` claim/ship — transaction-participant `markStage`) + `auth.js` + `routes/me.js`/`builders.js`/`tasks.js`/`claims.js` | `{ getState, shapeForApi, safeMarkStage, markStage, broadcastGraduation, restockForClaim, restockAll, SOURCE_TAG }` — the onboarding state-machine + newcomer-restock surface. The FIRST core→module port the lifecycle ticks inside its own txn (alongside `reward`). Default-on; degrades to best-effort no-ops when off ([ADR 0093](adr/0093-tranche-2-core-carve-sequence.md) §1). |
 | Event: `builder.box-reconcile-needed` | core `db.js` (on rank change / deactivate / auto-graduation) | `dev-box` | `{ builderId, rank, status, actor }` — flags the box for reconciliation. |
 ---
@@ -254,14 +254,14 @@ Rules (enforced by the `BV1.R45` fitness check):
 | **`hall-ui`** *(core-domain web surface, default-on; R85)* | webSurfaces: `{ host: "builders.", dir: "public" }` (the authenticated builders' hall) | — (registers NO port; keeps a DEDICATED serving block in `serve-internal.js`, unlike `status-ui`) | `^1.11.0` |
 | **`public-landing`** *(core-domain web surface, default-on; task 1003322 / ADR 0218)* | webSurfaces: `{ apexRoot: true, dir: "public" }` (the front door at the apex root: `/`, `/projects`, `/create`, `/privacy`, `/terms`, `/contact`) | — (registers NO port; the first surface that is not a subdomain, and like `hall-ui` it keeps a DEDICATED serving block — in `platform-server.js`) | `^1.19.0` |
 | **`lifecycle`** *(core-domain, default-on; R86)* | routes: `tasks`, `claims`, `versions`, `done-when`, `goals`, `dependencies`, `gate-approvals`, `analytics` | provides `lifecycle` (createTask, classifyTaskKind, tallyPeerVotes, work-tracking reads); resolves `reward`, `onboarding` | `^1.12.0` |
-| **`provisioning`** *(default-off; [ADR 0111](adr/<redacted>.md))* | routes: `provisioning` (own+Archon rank-gated) | provides `provisioning.instanceState` | `^1.14.0` |
-| **`ui-design`** *(core-domain, default-on; [ADR 0197](adr/<redacted>.md))* | skills: `design`, `design-sync`, `figma-design-sync` (the /design playbook + the two tool round-trips); the ADR 0081 adapters, sync CLIs and validator live in the module dir | — (registers NO port, NO routes; declaration-only — disabling it withdraws the skills and touches no served surface) | `^1.19.0` |
+| **`provisioning`** *(default-off; [ADR 0111](adr/0111-instance-hosting-provisioning-module.md))* | routes: `provisioning` (own+Archon rank-gated) | provides `provisioning.instanceState` | `^1.14.0` |
+| **`ui-design`** *(core-domain, default-on; [ADR 0197](adr/0197-the-ui-design-module.md))* | skills: `design`, `design-sync`, `figma-design-sync` (the /design playbook + the two tool round-trips); the ADR 0081 adapters, sync CLIs and validator live in the module dir | — (registers NO port, NO routes; declaration-only — disabling it withdraws the skills and touches no served surface) | `^1.19.0` |
 Each module's `modules/<key>/CLAUDE.md` is the authoritative per-module reference (files, seams, tests, what is NOT in the module).
-> **Only <redacted> is the `security` module** ([ADR 0093](adr/<redacted>.md) §1, [02-module-map §5](design/modular-architecture/02-module-map.md)): the red-team / vulnerability reports + bounty (rank-gated Metic+). <redacted> — the `permission-path-check`/`route-rank-check` authz machinery AND the `/security/adr` threat-model reader + Archon-only `/security/docs` exploit-detail store (`src/bongos/routes/security.js`, backed by the core `db.js` `security_docs` queries) — stays kernel.
+> **Only <redacted> is the `security` module** ([ADR 0093](adr/0093-tranche-2-core-carve-sequence.md) §1, [02-module-map §5](design/modular-architecture/02-module-map.md)): the red-team / vulnerability reports + bounty (rank-gated Metic+). <redacted> — the `permission-path-check`/`route-rank-check` authz machinery AND the `/security/adr` threat-model reader + Archon-only `/security/docs` exploit-detail store (`src/bongos/routes/security.js`, backed by the core `db.js` `security_docs` queries) — stays kernel.
-> **`character-anim` is a declaration-only module** ([ADR 0088](adr/<redacted>.md)): consistent-character generative animation. Its manifest contributes the `otb-character-review` skill and declares the `art-pipeline` prerequisite; it has no routes/seams/migrations. The runtime — the contract entry point `art/pipeline/character_anim_module.py` (`animate(model-sheet + action-spec) → graded registered frame set + manifest`), with a config-driven rubric (a `character_anim` family) and a pluggable generator backend — lives under `art/` like the rest of the art pipeline, the same way `art-pipeline` keeps `art/` at the repo root.
+> **`character-anim` is a declaration-only module** ([ADR 0088](adr/0088-consistent-character-generative-animation.md)): consistent-character generative animation. Its manifest contributes the `otb-character-review` skill and declares the `art-pipeline` prerequisite; it has no routes/seams/migrations. The runtime — the contract entry point `art/pipeline/character_anim_module.py` (`animate(model-sheet + action-spec) → graded registered frame set + manifest`), with a config-driven rubric (a `character_anim` family) and a pluggable generator backend — lives under `art/` like the rest of the art pipeline, the same way `art-pipeline` keeps `art/` at the repo root.
 ---

package/docs/onboarding/browser-terminal-guide.md CHANGED Viewed

@@ -70,4 +70,4 @@ It prints a **pairing link**. Open that link and you can now drive your box stra
 ---
-*Deeper detail (the systemd units, the Cloudflare tunnel, operator setup, and end-to-end verification) lives in the operator recipe [`docs/recipes/managed-settings-remote-control.md`](../recipes/managed-settings-remote-control.md) (Part 2) and [ADR 0038](../adr/<redacted>.md) / [ADR 0040](../adr/<redacted>.md). This page is the builder-facing summary of that flow.*
+*Deeper detail (the systemd units, the Cloudflare tunnel, operator setup, and end-to-end verification) lives in the operator recipe [`docs/recipes/managed-settings-remote-control.md`](../recipes/managed-settings-remote-control.md) (Part 2) and [ADR 0038](../adr/0038-chromebook-ttyd-cloudflare-tunnel.md) / [ADR 0040](../adr/0040-remote-control-default-browser-onramp.md). This page is the builder-facing summary of that flow.*

package/docs/onboarding/diagrams/README.md CHANGED Viewed

@@ -35,21 +35,21 @@ How a task moves from creation to production, and the exact edge where **credits
 Source: [`01-task-lifecycle.mmd`](01-task-lifecycle.mmd)
 ### 2. Builder rank ladder
-The 16-value reserved rank enum (migration 023) in three Greek bands, which ranks are **live today** (`archon` + `thetes`, plus `xenos` on exit), the GDS-V3 target of three write-gating ranks (Xenos / Metic / Archon), and the server-enforced permissions per rank ([ADR 0016](../../adr/<redacted>.md)).
+The 16-value reserved rank enum (migration 023) in three Greek bands, which ranks are **live today** (`archon` + `thetes`, plus `xenos` on exit), the GDS-V3 target of three write-gating ranks (Xenos / Metic / Archon), and the server-enforced permissions per rank ([ADR 0016](../../adr/0016-trust-boundary-server-enforced-permissions.md)).
 ![Rank ladder](02-rank-ladder.png)
 Source: [`02-rank-ladder.mmd`](02-rank-ladder.mmd)
 ### 3. Example & karma — sourcing and spending
-Where each comes from and where each goes. Key facts: **example = credits** (same thing, in-world name), they are **equity, not a spendable currency**, and the **primary source is now a cost-plus reward on each shipped session** — `round(true_cost × 1.20)` ([ADR 0054](../../adr/<redacted>.md)) — alongside per-task `credits_reward × kind multiplier` ([ADR 0023](../../adr/<redacted>.md)), achievements, and the (rate-card-live) security bounty. Karma is a separate peer-trust signal that does **not** gate rank promotions; its LIVE/PLANNED state tracks its backing tasks (R25/R32/R26). The full write-up is [`docs/onboarding/example-and-karma.md`](../example-and-karma.md).
+Where each comes from and where each goes. Key facts: **example = credits** (same thing, in-world name), they are **equity, not a spendable currency**, and the **primary source is now a cost-plus reward on each shipped session** — `round(true_cost × 1.20)` ([ADR 0054](../../adr/0054-session-token-reward-cost-plus.md)) — alongside per-task `credits_reward × kind multiplier` ([ADR 0023](../../adr/0023-kind-multipliers-and-idea-bonus.md)), achievements, and the (rate-card-live) security bounty. Karma is a separate peer-trust signal that does **not** gate rank promotions; its LIVE/PLANNED state tracks its backing tasks (R25/R32/R26). The full write-up is [`docs/onboarding/example-and-karma.md`](../example-and-karma.md).
 ![Example and karma](03-example-karma.png)
 Source: [`03-example-karma.mmd`](03-example-karma.mmd)
 ### 4. The complete architecture — where your work runs and how code reaches production
-One map of the whole system, merging the old "server ↔ repo ↔ memory" three-layer view with the dev-box → production ship flow. The four places Claude Code splits across — your **device** (screen only) · the **dev box** (the worker, the code, *and* your local memory dir) · the **server/droplet** (authority *and* production: Postgres, the server-side memory store, the push credential) · **GitHub** (branch-protected main + Actions) — plus two flows woven through it: the **per-builder memory layer** (ADR 0024 — local ↔ server, sync-on-ship / pull-on-start) and the **box → prod ship path** (a credential-less box re-auths and uploads its branch as a git bundle; the server pushes it with a GitHub App credential; the PR auto-merges and GitHub Actions deploys — no droplet key on any box). Every feature-piece + flow edge is LIVE/solid iff its backing task is `shipped`. Backing tasks: memory chain [#273](https://example.com/builders#/task/273)–[#276](https://example.com/builders#/task/276); dev box [#904](https://example.com/builders#/task/904)/[#774](https://example.com/builders#/task/774)/[#897](https://example.com/builders#/task/897)/[#919](https://example.com/builders#/task/919); box→prod [#1025](https://example.com/builders#/task/1025)/[#859](https://example.com/builders#/task/859)/[#1028](https://example.com/builders#/task/1028)/[#1027](https://example.com/builders#/task/1027) (all shipped → the map reads all-LIVE today). See [ADR 0024](../../adr/<redacted>.md) (cloneable memory), [ADR 0055](../../adr/<redacted>.md) (server-mediated publish), [ADR 0053](../../adr/0053-scoped-dev-box-session.md) (scoped box token), [ADR 0042](../../adr/<redacted>.md) (CI self-deploy), [ADR 0016](../../adr/<redacted>.md) (trust boundary).
+One map of the whole system, merging the old "server ↔ repo ↔ memory" three-layer view with the dev-box → production ship flow. The four places Claude Code splits across — your **device** (screen only) · the **dev box** (the worker, the code, *and* your local memory dir) · the **server/droplet** (authority *and* production: Postgres, the server-side memory store, the push credential) · **GitHub** (branch-protected main + Actions) — plus two flows woven through it: the **per-builder memory layer** (ADR 0024 — local ↔ server, sync-on-ship / pull-on-start) and the **box → prod ship path** (a credential-less box re-auths and uploads its branch as a git bundle; the server pushes it with a GitHub App credential; the PR auto-merges and GitHub Actions deploys — no droplet key on any box). Every feature-piece + flow edge is LIVE/solid iff its backing task is `shipped`. Backing tasks: memory chain [#273](https://example.com/builders#/task/273)–[#276](https://example.com/builders#/task/276); dev box [#904](https://example.com/builders#/task/904)/[#774](https://example.com/builders#/task/774)/[#897](https://example.com/builders#/task/897)/[#919](https://example.com/builders#/task/919); box→prod [#1025](https://example.com/builders#/task/1025)/[#859](https://example.com/builders#/task/859)/[#1028](https://example.com/builders#/task/1028)/[#1027](https://example.com/builders#/task/1027) (all shipped → the map reads all-LIVE today). See [ADR 0024](../../adr/0024-cloneable-repo-local-first-memory.md) (cloneable memory), [ADR 0055](../../adr/0055-server-mediated-branch-publish.md) (server-mediated publish), [ADR 0053](../../adr/0053-scoped-dev-box-session.md) (scoped box token), [ADR 0042](../../adr/0042-builder-self-deploy-ci-auto-merge.md) (CI self-deploy), [ADR 0016](../../adr/0016-trust-boundary-server-enforced-permissions.md) (trust boundary).
 ![The complete architecture](04-architecture.png)

package/docs/onboarding/drachmae-and-karma.md CHANGED Viewed

@@ -19,7 +19,7 @@
 ### What they are
-Example are the in-world name for the `total_credits` counter on your builder row. The owner's framing ([ADR 0054](../adr/<redacted>.md)) is that **example are equity** — units of ownership in the thing you're helping build. Practically, today, they are:
+Example are the in-world name for the `total_credits` counter on your builder row. The owner's framing ([ADR 0054](../adr/0054-session-token-reward-cost-plus.md)) is that **example are equity** — units of ownership in the thing you're helping build. Practically, today, they are:
 - **Append-only.** Every award is a row in `credit_log`; the `total_credits` counter is maintained by a database trigger. History is never rewritten — a correction is a new (sometimes negative) row, never an edit.
 - **Persistent across exit.** If you leave and come back, your example are still there (migration 025). They are reputation, not a session balance.
@@ -30,7 +30,7 @@ Example are the in-world name for the `total_credits` counter on your builder ro
 There are several sources. They all land in the same `credit_log` and roll up into one `total_credits` number.
-#### 1. The cost-plus session reward — *the main one* ([ADR 0054](../adr/<redacted>.md))
+#### 1. The cost-plus session reward — *the main one* ([ADR 0054](../adr/0054-session-token-reward-cost-plus.md))
 When you **ship** a session, the server looks at the LLM tokens that session actually burned, prices them, and pays you:
@@ -47,9 +47,9 @@ The important details, because they're designed to be fair *and* un-gameable:
 - **Idempotent per session.** Re-shipping or retrying the same session is a true no-op — keyed on `session_id`, you can't get paid twice.
 - **Reversible.** A bad award is undone with a compensating negative `credit_log` row; the trigger nets it out. History stays intact.
-> **Why pay for cost at all — doesn't that reward waste?** It can, and that was accepted on purpose ([ADR 0054](../adr/<redacted>.md)). The guardrails are: you only get paid for sessions that *ship*; example are *equity*, so padding your own cost dilutes a pool you hold (early builders self-police); and the [BFG session-inefficiency evaluator](../adr/<redacted>.md) already flags wasteful sessions, so a future version can discount the reward by an efficiency factor. The stated direction is to move toward market/bidding pricing once there's a real multi-builder pool.
+> **Why pay for cost at all — doesn't that reward waste?** It can, and that was accepted on purpose ([ADR 0054](../adr/0054-session-token-reward-cost-plus.md)). The guardrails are: you only get paid for sessions that *ship*; example are *equity*, so padding your own cost dilutes a pool you hold (early builders self-police); and the [BFG session-inefficiency evaluator](../adr/0027-bfg-session-inefficiency-evaluator.md) already flags wasteful sessions, so a future version can discount the reward by an efficiency factor. The stated direction is to move toward market/bidding pricing once there's a real multi-builder pool.
-#### 2. Per-task credits, adjusted by *kind* ([ADR 0023](../adr/<redacted>.md))
+#### 2. Per-task credits, adjusted by *kind* ([ADR 0023](../adr/0023-kind-multipliers-and-idea-bonus.md))
 Every task carries a `credits_reward` an author set when scoping it. When the task is **confirmed** (verification passes — see the [lifecycle](#where-in-the-lifecycle-credits-land)), you're paid that reward **times a multiplier for the kind of work**:
@@ -66,7 +66,7 @@ Every task carries a `credits_reward` an author set when scoping it. When the ta
 The math is written inline into the `credit_log` row (e.g. `40c × 1.5 = 60c (learning-capture)`) so an auditor can reconstruct any payout. The multipliers live in a *frozen constant* in `src/bongos/db.js` on purpose — changing them takes a code review and commit, not a quiet DB edit.
-#### 3. The idea-promotion bonus ([ADR 0023](../adr/<redacted>.md))
+#### 3. The idea-promotion bonus ([ADR 0023](../adr/0023-kind-multipliers-and-idea-bonus.md))
 If you **captured an idea** that later became a task, and **someone else ships it**, you get **25% of that task's (multiplier-adjusted) reward** — paid as a separate `idea_promotion_bonus` row, *on top of* what the shipper earns (it isn't deducted from them). No bonus if you ship your own idea (you already got the full reward). Capturing good ideas is real, paid work.
@@ -84,7 +84,7 @@ There's a published payout rate-card by severity for red-team / security finding
 ### Where in the lifecycle credits land
-Example are awarded at the **`confirmed → shipped`** edge — when the code actually lands on `main` and deploys — **not** when verification passes. Passing the grader gets you to `confirmed`, which is verified but *unpaid*; a task that strands there without landing earns nothing until it does ([ADR 0120](../adr/<redacted>.md), "pay on land"). Releasing a task with `/builder-release` pays nothing.
+Example are awarded at the **`confirmed → shipped`** edge — when the code actually lands on `main` and deploys — **not** when verification passes. Passing the grader gets you to `confirmed`, which is verified but *unpaid*; a task that strands there without landing earns nothing until it does ([ADR 0120](../adr/0120-pay-on-land-and-builder-owned-rebase-gate.md), "pay on land"). Releasing a task with `/builder-release` pays nothing.
 ```
 active ──▶ completed ──▶ confirmed ──▶ shipped
@@ -93,11 +93,11 @@ active ──▶ completed ──▶ confirmed ──▶ shipped
             smoke)          paid)          CREDITS LAND HERE)
 ```
-> **Note:** the old up-front `touches[]` *drift scanner* that used to run at ship time is **gone** (task [#879](https://example.com/builders#/task/879), [ADR 0049](../adr/<redacted>.md)). The ship gate is **smoke tests only**; `git merge` at land time is the real collision detector.
+> **Note:** the old up-front `touches[]` *drift scanner* that used to run at ship time is **gone** (task [#879](https://example.com/builders#/task/879), [ADR 0049](../adr/0049-split-parallel-safety-contract.md)). The ship gate is **smoke tests only**; `git merge` at land time is the real collision detector.
 ### One honest caveat: a drachma means two things
-We knowingly run two conventions on the same ledger ([ADR 0054](../adr/<redacted>.md)): a *unitless author estimate* (the per-task path) and a *whole-dollar drachma of real cost + 20%* (the session-reward path). That inconsistency is a deliberate MVP trade-off, recorded so it's a known decision and not a latent bug. A future version may reconcile them.
+We knowingly run two conventions on the same ledger ([ADR 0054](../adr/0054-session-token-reward-cost-plus.md)): a *unitless author estimate* (the per-task path) and a *whole-dollar drachma of real cost + 20%* (the session-reward path). That inconsistency is a deliberate MVP trade-off, recorded so it's a known decision and not a latent bug. A future version may reconcile them.
 ---
@@ -107,7 +107,7 @@ Example are what you *earn*; the budget cap limits what you *spend*. They're lin
 Defined in `src/bongos/cost.js` (criterion C3, [#302](https://example.com/builders#/task/302)):
-Builders are **uncapped by default** ([ADR 0085](../adr/<redacted>.md)) — your month-to-date spend is tracked and shown, but it never blocks you. An Archon can set a per-builder cap as a manual brake; **when a cap is set**, these levels apply:
+Builders are **uncapped by default** ([ADR 0085](../adr/0085-remove-default-per-builder-spend-cap.md)) — your month-to-date spend is tracked and shown, but it never blocks you. An Archon can set a per-builder cap as a manual brake; **when a cap is set**, these levels apply:
 | Month-to-date spend | Level | What happens |
 |---|---|---|
@@ -117,7 +117,7 @@ Builders are **uncapped by default** ([ADR 0085](../adr/<redacted>.md)) — your
 | **≥ 100%** | `over` | **hard refuse** — `/builder-ship` and the art pipeline stop |
 - **No default cap.** `monthly_budget_usd` is unset for most builders, which means uncapped. The MTD figure still resets at the start of each calendar month.
-- A cap, when set, is there to **catch a runaway**, not to ration normal work — the **$50 default was removed** ([ADR 0085](../adr/<redacted>.md)) because a new builder's own session cost crossed it within a day or two, freezing the very work it was meant to enable.
+- A cap, when set, is there to **catch a runaway**, not to ration normal work — the **$50 default was removed** ([ADR 0085](../adr/0085-remove-default-per-builder-spend-cap.md)) because a new builder's own session cost crossed it within a day or two, freezing the very work it was meant to enable.
 - An **Archon** can set or clear a specific builder's ceiling (`PATCH /api/gds/builders/:id/budget`); clearing it (`null`) returns the builder to uncapped.
 If a cap is set and you hit `over`, you're not in trouble — you've just reached the month's ceiling. Ask an Archon to raise or clear it if the work justifies it.
@@ -133,9 +133,9 @@ Karma (added in migration 040) is a **completely separate** counter from example
 - **Peer votes on confirmed work.** Builders upvote/downvote each other's confirmed tasks. Only **Metic-and-above** can cast a vote (`POST /api/gds/tasks/:id/vote` is rank-gated). Votes are **tallied weekly** into one net `peer_vote_weekly` karma entry per builder. There's an **anti-self-vote** guard and an anti-retaliation rule (a downvote can't dent your karma within the same week).
 - **Proposal ratification.** When a criterion-proposal you made is ratified, you get **+3 karma** (`proposal_ratified`).
 - **Idea promotion.** Promoting an idea into a real task awards karma to the capturer.
-- **It can go down.** The [BFG](../adr/<redacted>.md) good-citizenship corrections can apply a *non-positive* karma delta. Karma is a slower, more reflective signal than example — you can ship fast and still lose karma if you break things.
+- **It can go down.** The [BFG](../adr/0026-bfg-memory-hygiene-and-cross-builder-learning.md) good-citizenship corrections can apply a *non-positive* karma delta. Karma is a slower, more reflective signal than example — you can ship fast and still lose karma if you break things.
-> Discord cheers don't count. Reaction "applause" in Discord is cosmetic and **never** mints karma — only rank-gated peer votes do ([ADR 0033](../adr/<redacted>.md)). Unranked enthusiasm can't manufacture trust.
+> Discord cheers don't count. Reaction "applause" in Discord is cosmetic and **never** mints karma — only rank-gated peer votes do ([ADR 0033](../adr/0033-discord-bot-service-principal.md)). Unranked enthusiasm can't manufacture trust.
 ### Where karma shows up
@@ -174,5 +174,5 @@ Both are reputation. Neither is a spendable currency today. You don't have to *d
 - **Your numbers:** [builders' hall](https://example.com/builders) (profile card + leaderboard), or `/builder-start` (shows your credit total).
 - **The diagram:** [`diagrams/03-example-karma.png`](diagrams/03-example-karma.png) — sources and sinks at a glance.
-- **The decisions:** [ADR 0054](../adr/<redacted>.md) (cost-plus reward), [ADR 0023](../adr/<redacted>.md) (kind multipliers + idea bonus), [ADR 0028](../adr/<redacted>.md) (token→USD pricing).
+- **The decisions:** [ADR 0054](../adr/0054-session-token-reward-cost-plus.md) (cost-plus reward), [ADR 0023](../adr/0023-kind-multipliers-and-idea-bonus.md) (kind multipliers + idea bonus), [ADR 0028](../adr/0028-honest-llm-spend-accounting.md) (token→USD pricing).
 - **The code:** `src/bongos/db.js` (`REWARD_MARGIN_PCT`, `KIND_MULTIPLIERS`, `computeSessionTokenReward`), `src/bongos/llm-pricing.js` (pricing), `src/bongos/cost.js` (budget cap), `src/bongos/bfg.js` (builder strength).

package/docs/onboarding/primer.md CHANGED Viewed

@@ -37,13 +37,13 @@ You drive the middle three states. The system handles the rest.
 **One claim at a time** while you're a Xenos. New builders hold a single active claim — ship it (or release it) before opening another, so the first work gets carried through. The limit is keyed to your rank: it lifts automatically when you graduate to **Thetes** (after your third shipped task), after which you can hold parallel claims if you want.
-When you ship, `ship.js` runs the project's **smoke tests** and the quality grader. If they pass, the task auto-confirms — verified, but **not yet paid**. **Credits land at the final `confirmed → shipped` hop**, when your code actually merges to `main` and deploys ([ADR 0120](../adr/<redacted>.md) — you're paid for landed code, so a branch that never lands never pays). That hop is handled for you, but *what it takes to land* depends on your rank and what you changed; the next section covers it. (There used to be an up-front `touches[]` "drift scanner" here too; it was retired — `git merge` at land time is the real collision detector. See [ADR 0049](../adr/<redacted>.md).)
+When you ship, `ship.js` runs the project's **smoke tests** and the quality grader. If they pass, the task auto-confirms — verified, but **not yet paid**. **Credits land at the final `confirmed → shipped` hop**, when your code actually merges to `main` and deploys ([ADR 0120](../adr/0120-pay-on-land-and-builder-owned-rebase-gate.md) — you're paid for landed code, so a branch that never lands never pays). That hop is handled for you, but *what it takes to land* depends on your rank and what you changed; the next section covers it. (There used to be an up-front `touches[]` "drift scanner" here too; it was retired — `git merge` at land time is the real collision detector. See [ADR 0049](../adr/0049-split-parallel-safety-contract.md).)
 ## How work lands — and what auto-ships
 `confirmed → shipped` is not a person clicking "merge". When you ship, `ship.js` opens a pull request and the project lands it for you — **nobody pushes to `main` by hand**. The PR has to go green on the automated checks (the test suite, a secret scan, and the **gate-review** classifier); the server then auto-merges it and `main` deploys to production. If a green PR ever stalls, a server sweep lands it within about five minutes, and `/merge-mode` is the manual fallback.
-The one thing that decides whether your ship is **instant** or **waits for an Archon** is *what your change touches*, weighed against your rank by the **gate-review** step ([ADR 0058](../adr/<redacted>.md)):
+The one thing that decides whether your ship is **instant** or **waits for an Archon** is *what your change touches*, weighed against your rank by the **gate-review** step ([ADR 0058](../adr/0058-automatic-gate-surface-gatekeeper.md)):
 | What your change touches | What happens |
 |---|---|
@@ -51,7 +51,7 @@ The one thing that decides whether your ship is **instant** or **waits for an Ar
 | **A protected "gate surface"** — migrations, server routes, the ship / deploy plumbing | Auto-merges **only if you are Metic or above** (rank trust). A Xenos or Thetes ship here **waits for an Archon** to approve. |
 | **The safety core** — the gate's own machinery, the deploy switch, the rank / permission enforcement | **Always** waits for an Archon, whatever your rank. |
-So your first tasks **ship with no approval**: the newcomer chores — a tile, a doc fix, a unit test, a batch of ideas — all sit on the safe side of that line, and a clean ship merges and deploys on its own. You only meet the Archon gate if your change reaches into the project's own safety machinery, which builders below Metic are asked to stay clear of anyway ([ADR 0043](../adr/<redacted>.md)). Landing is always Bongos's job: you never run `git push origin main`, `ssh` to the server, or deploy by hand — `/builder-ship` opens the PR and the server does the rest ([ADR 0042](../adr/<redacted>.md)).
+So your first tasks **ship with no approval**: the newcomer chores — a tile, a doc fix, a unit test, a batch of ideas — all sit on the safe side of that line, and a clean ship merges and deploys on its own. You only meet the Archon gate if your change reaches into the project's own safety machinery, which builders below Metic are asked to stay clear of anyway ([ADR 0043](../adr/0043-git-ssh-trust-boundary-and-rank-floor-on-permission-paths.md)). Landing is always Bongos's job: you never run `git push origin main`, `ssh` to the server, or deploy by hand — `/builder-ship` opens the PR and the server does the rest ([ADR 0042](../adr/0042-builder-self-deploy-ci-auto-merge.md)).
 ## The rank ladder
@@ -64,17 +64,17 @@ Four ranks, in ancient-Greek-civilization order:
 | **Metic**  | Approved working rank. The "real builders."                            | Claim any ready task. Idea triage, blocker review. Most of the work happens here. |
 | **Archon** | Project keeper.                                                        | Scope mutations, rank changes, infra-level operations.                            |
-So the sandbox is short: ship three small `newcomer_friendly` tasks and the city opens the whole queue to you on its own (the jump to **Metic** — with its triage/trust powers — is still a deliberate Archon promotion). Rank lives on the `builders.rank` column in the production database and is checked server-side on every privileged request — **with no caching**. A demotion takes effect on your next request. You cannot escalate your own rank by editing local files; the server is the source of truth. See [ADR 0016](../adr/<redacted>.md) and [ADR 0034](../adr/<redacted>.md) for the full trust model.
+So the sandbox is short: ship three small `newcomer_friendly` tasks and the city opens the whole queue to you on its own (the jump to **Metic** — with its triage/trust powers — is still a deliberate Archon promotion). Rank lives on the `builders.rank` column in the production database and is checked server-side on every privileged request — **with no caching**. A demotion takes effect on your next request. You cannot escalate your own rank by editing local files; the server is the source of truth. See [ADR 0016](../adr/0016-trust-boundary-server-enforced-permissions.md) and [ADR 0034](../adr/0034-thetes-graduated-newcomer-rank.md) for the full trust model.
 ## Example and karma
 Two parallel reputation tracks. You don't need to *do* anything special to earn either — claim a task, do good work, ship it, and the system tracks both. The full mechanics (formulas, the kind table, the budget cap, every karma source) live in **[Example & karma — how you get paid](drachmae-and-karma.md)**; here's the shape of it.
-- **Example** (called "credits" in code) are your **equity** in the project — a score and a stake, *not* a currency you spend on anything. They only go up, and they persist if you leave and come back. Most of your example now come from a **cost-plus reward on each shipped session**: the server prices the LLM tokens your work actually burned and pays you that real cost **plus 20%** ([ADR 0054](../adr/<redacted>.md)). On top of that, each task pays its `credits_reward` adjusted by the *kind* of work (a captured learning or a resolved blocker is worth 1.5×; cleanup 0.8×), and capturing an idea that someone else then ships earns you a 25% bonus ([ADR 0023](../adr/<redacted>.md)). Credits land at the `confirmed → shipped` edge — when your code actually merges and deploys, not when verification passes ([ADR 0120](../adr/<redacted>.md)). Which of those two streams actually pays is per-instance config ([ADR 0146](../adr/<redacted><redacted>.md)): the default pays both, while a `cost-plus-only` instance pays the session reward alone and treats each task's `credits_reward` as an advertised estimate only. See the standings on [/builders](https://example.com/builders).
+- **Example** (called "credits" in code) are your **equity** in the project — a score and a stake, *not* a currency you spend on anything. They only go up, and they persist if you leave and come back. Most of your example now come from a **cost-plus reward on each shipped session**: the server prices the LLM tokens your work actually burned and pays you that real cost **plus 20%** ([ADR 0054](../adr/0054-session-token-reward-cost-plus.md)). On top of that, each task pays its `credits_reward` adjusted by the *kind* of work (a captured learning or a resolved blocker is worth 1.5×; cleanup 0.8×), and capturing an idea that someone else then ships earns you a 25% bonus ([ADR 0023](../adr/0023-kind-multipliers-and-idea-bonus.md)). Credits land at the `confirmed → shipped` edge — when your code actually merges and deploys, not when verification passes ([ADR 0120](../adr/0120-pay-on-land-and-builder-owned-rebase-gate.md)). Which of those two streams actually pays is per-instance config ([ADR 0146](../adr/<redacted><redacted>.md)): the default pays both, while a `cost-plus-only` instance pays the session reward alone and treats each task's `credits_reward` as an advertised estimate only. See the standings on [/builders](https://example.com/builders).
 - **Karma** is a *separate* signal that measures **peer trust** — how other builders rate the *way* you work, not how much you ship. It's earned when Metic-and-above builders upvote your confirmed work (tallied weekly), when a proposal of yours is ratified, and when you capture ideas; it can also go *down* if you break things. Karma shows up on your profile (with a 30-day trend) and as a sortable column on the leaderboard, and it feeds your "builder strength" score. **It does not gate rank promotions** — those happen automatically by ship count (Xenos → Thetes after three ships) or by an Archon's deliberate decision. A builder who ships fast but breaks things gains example and loses karma; a builder who ships thoughtfully gains both.
-One more thing worth knowing: builders are **uncapped by default** — your spend is tracked (it's the cost side of the same coin the reward is computed from) but never blocks you. There's no default budget. An Archon *can* set a per-builder **monthly budget cap** as a manual brake on a runaway; if one is set for you, you get a warning at 80% and `/builder-ship` pauses at 100% until it's raised ([ADR 0085](../adr/<redacted>.md)).
+One more thing worth knowing: builders are **uncapped by default** — your spend is tracked (it's the cost side of the same coin the reward is computed from) but never blocks you. There's no default budget. An Archon *can* set a per-builder **monthly budget cap** as a manual brake on a runaway; if one is set for you, you get a warning at 80% and `/builder-ship` pauses at 100% until it's raised ([ADR 0085](../adr/0085-remove-default-per-builder-spend-cap.md)).
 ## How to ask Claude about anything
@@ -100,7 +100,7 @@ As you work, Claude writes down durable facts — your standing preferences, a g
 - **The map** (`MEMORY.md`) — a short index loaded at the **start of every session**: one line per memory, just enough to know *what* is known and where the detail lives. Kept deliberately small.
 - **The drawer** — the full notes themselves. They live on your machine, sync to the server (so your memory follows you across machines and boxes), and are searchable with `/recall`. They cost nothing until something fetches them.
-The map stays light on its own: a session-start guard warns if it's drifting large, and an auto-tidy moves the oldest, least-relevant notes off the map into the drawer when it crosses a threshold — **nothing is deleted**, it's just no longer loaded every session (a `/recall` away when a task needs it). Your standing rules, and anything pinned, always stay on the map. Full picture: [ADR 0074](../adr/<redacted>.md) and [diagram 4 — the architecture](diagrams/).
+The map stays light on its own: a session-start guard warns if it's drifting large, and an auto-tidy moves the oldest, least-relevant notes off the map into the drawer when it crosses a threshold — **nothing is deleted**, it's just no longer loaded every session (a `/recall` away when a task needs it). Your standing rules, and anything pinned, always stay on the map. Full picture: [ADR 0074](../adr/0074-memory-map-stays-light.md) and [diagram 4 — the architecture](diagrams/).
 ## Where to find more depth

package/docs/packs/artist.md CHANGED Viewed

@@ -2,7 +2,7 @@
 > **The role pack for `discipline = artist`.** The kernel ([`CLAUDE.md`](../../CLAUDE.md)) is what every session reads whatever its craft; this file is the half that is only true for artists. Read the whole thing before acting — it changes how you *communicate* for the rest of the session. Registered in [`scripts/gds/discipline-modes.json`](../../scripts/gds/discipline-modes.json), which `claim.js` prints on a claim.
-An art session is not the engineer's text-heavy build loop. The artist's subject is how the project **looks and reads** — its visuals, its copy, its voice, the feeling of the thing. A craft is an identity, not a toolchain ([ADR 0272](../adr/<redacted>.md)): an instance has artists whether or not it ships an art pipeline.
+An art session is not the engineer's text-heavy build loop. The artist's subject is how the project **looks and reads** — its visuals, its copy, its voice, the feeling of the thing. A craft is an identity, not a toolchain ([ADR 0272](../adr/0272-a-craft-is-an-identity-not-a-toolchain.md)): an instance has artists whether or not it ships an art pipeline.
 ---

package/docs/packs/ideator.md CHANGED Viewed

@@ -17,7 +17,7 @@ In every other craft, Claude does the work and asks the human to approve it. **H
 ## The second rule: be quiet about the machinery
-The behaviour above inverts for this role — and so does the **surface** ([ADR 0271](../adr/<redacted>.md)). Someone came here to think about an idea, not to watch a build. **Report outcomes, not mechanism.**
+The behaviour above inverts for this role — and so does the **surface** ([ADR 0271](../adr/0271-the-ideator-surface-is-two-halves.md)). Someone came here to think about an idea, not to watch a build. **Report outcomes, not mechanism.**
 - **Don't narrate the plumbing.** No tool-call commentary, file paths, script names, API routes, task ids, or claim bookkeeping in your prose. You still *use* all of it — you just don't make the ideator read about it.
 - **Speak in the language of the idea.** "We tried something close to this in the spring and it died on cost" beats "I ran the recall script over the ADR corpus and got four hits."

package/docs/project-context.template.md CHANGED Viewed

@@ -1,9 +1,9 @@
 # &lt;Product Name&gt; — Project Identity (host instance context)
-> **Neutral template — the skeleton a new Cloud Bongos instance fills in.** This is the project-context *template* Cloud Bongos ships ([ADR 0062](adr/<redacted>.md) §7, task [#1205](https://example.com/builders#/task/1205)); `cloudbongos init` ([#1204](https://example.com/builders#/task/1204)) copies it to `docs/project-context.md` and an owner's own LLM fills the placeholders. It is the prose counterpart to the neutral branding starter [`config/branding.neutral.json`](../config/branding.neutral.json). **Instance 1's filled version is [`docs/project-context.md`](project-context.md).** Do not edit this template per-instance — edit your copy.
+> **Neutral template — the skeleton a new Cloud Bongos instance fills in.** This is the project-context *template* Cloud Bongos ships ([ADR 0062](adr/0062-medusa-instance-model-decoupling.md) §7, task [#1205](https://example.com/builders#/task/1205)); `cloudbongos init` ([#1204](https://example.com/builders#/task/1204)) copies it to `docs/project-context.md` and an owner's own LLM fills the placeholders. It is the prose counterpart to the neutral branding starter [`config/branding.neutral.json`](../config/branding.neutral.json). **Instance 1's filled version is [`docs/project-context.md`](project-context.md).** Do not edit this template per-instance — edit your copy.
 >
 > **Relationship to the rest of the project:**
-> - [`CLAUDE.md`](../CLAUDE.md) is the **portable methodology core** Cloud Bongos ships — working rules, session protocol, claim→ship lifecycle, the [ADR 0061](adr/<redacted>.md) content charter, the nested-`CLAUDE.md` pattern. Instance-agnostic; you do not author it.
+> - [`CLAUDE.md`](../CLAUDE.md) is the **portable methodology core** Cloud Bongos ships — working rules, session protocol, claim→ship lifecycle, the [ADR 0061](adr/0061-context-layer-decomposition.md) content charter, the nested-`CLAUDE.md` pattern. Instance-agnostic; you do not author it.
 > - **This file is the *prose* identity** — lore, vision, the why. The **machine-readable** identity (exact strings code reads: product/world/company names, domains, cookie/OAuth origins, currency label, palette, repo binding) lives in the branding contract [`config/branding.json`](../config/branding.json) ([`docs/branding-contract.md`](branding-contract.md)). **Where a name must be exact for code, the branding contract wins** — never re-hardcode a contract-owned string here.
 <!--
@@ -51,7 +51,7 @@ the experience permanent / distinctive / worth building.&gt;
 > ⚠️ **Naming / trademark posture:** &lt;any protected marks or naming risks, and the contingency.&gt; **Operating rule:** any
 > rebrand-sensitive name must live as a single string in [`config/branding.json`](../config/branding.json) — never baked into
-> class names, file names, DB schema, or asset filenames — so a forced rebrand is a one-line change ([ADR 0062](adr/<redacted>.md) §3).
+> class names, file names, DB schema, or asset filenames — so a forced rebrand is a one-line change ([ADR 0062](adr/0062-medusa-instance-model-decoupling.md) §3).
 ---