@bongos/core 1.19.155 → 1.19.157

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

@@ -5,7 +5,7 @@ description: Gracefully offboard (or reactivate) a builder. Deactivating release
 
 **Script skill (authoritative).** The core action is the `PATCH /api/gds/builders/:id/status` API call via `cli-lib.js`. Once intent is confirmed, run it and print the response verbatim — do not summarize or editorialize the claims-released list.
 
-You are gracefully offboarding a builder from the Game Development System, or reactivating one who has returned. This is a robustness operation — what happens when someone quits — and it must be **lossless**: nothing the builder earned or shipped is ever deleted.
+You are gracefully offboarding a builder from Bongos, or reactivating one who has returned. This is a robustness operation — what happens when someone quits — and it must be **lossless**: nothing the builder earned or shipped is ever deleted.
 
 ## First: is this an offboarding, or do you just want to close out your session?
 

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

@@ -1,9 +1,9 @@
 ---
 name: builder-reauth
-description: Refresh an expired or invalid GDS CLI session the fast, UI-first way — no terminal Device Flow. Triggers when the user says "/builder-reauth", "re-auth", "refresh my session", "my GDS session expired", "re-issue my CLI token", or when any /builder-* command fails with "GDS CLI session is no longer valid". Opens the builder's Settings page in the browser, the user clicks "Re-issue CLI token" under "CLI Access" and copies the one-liner, and this skill runs it to write the new session.
+description: Refresh an expired or invalid Bongos CLI session the fast, UI-first way — no terminal Device Flow. Triggers when the user says "/builder-reauth", "re-auth", "refresh my session", "my Bongos session expired", "re-issue my CLI token", or when any /builder-* command fails with "Bongos CLI session is no longer valid". Opens the builder's Settings page in the browser, the user clicks "Re-issue CLI token" under "CLI Access" and copies the one-liner, and this skill runs it to write the new session.
 ---
 
-You are refreshing the current builder's GDS CLI session. CLI bearer tokens carry a 24h idle TTL (they refresh on every use), so an actively-used session stays alive — but an idle one expires, and a revoked one dies immediately. This skill is the **fast path back in**: browser clicks plus a single copy/paste, instead of the slower terminal Device Flow.
+You are refreshing the current builder's Bongos CLI session. CLI bearer tokens carry a 24h idle TTL (they refresh on every use), so an actively-used session stays alive — but an idle one expires, and a revoked one dies immediately. This skill is the **fast path back in**: browser clicks plus a single copy/paste, instead of the slower terminal Device Flow.
 
 ## Why expiry exists (so you can explain it if asked)
 

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

@@ -3,7 +3,7 @@ name: builder-redteam
 description: File a red-team / vulnerability report against the city. Walks the builder through severity, target, title, repro, expected vs. actual, then POSTs to /api/gds/security/reports so the Archon view picks it up. Optionally drafts a follow-up idea_inbox entry for the fix. Triggers when the user says "/builder-redteam", "I found a security issue", "redteam report", "file a vuln", or describes a flaw in the system's own walls. Metic+ only — Xenos see a polite refusal.
 ---
 
-You are filing a vulnerability report on the Example project. The reporter is a trusted builder who has found a flaw — in the GDS, the game server, the chat broadcast, the deploy chain, the auth model — and wants the red-team bounty surface to pick it up.
+You are filing a vulnerability report on the Example project. The reporter is a trusted builder who has found a flaw — in Bongos, the game server, the chat broadcast, the deploy chain, the auth model — and wants the red-team bounty surface to pick it up.
 
 This is the **bounty intake** side of V3.R63/R64/R67. Once the report is filed:
 
@@ -46,7 +46,7 @@ After each answer, echo it back. If the user changes their mind, accept the revi
 
 Build the report JSON from the five answers above, write it to a temp file with
 your file-write tool (NOT a shell heredoc — heredocs aren't portable), then POST
-it with the cross-platform GDS API helper:
+it with the cross-platform Bongos API helper:
 
 ```
 node scripts/gds/api.js POST /api/gds/security/reports --body-file <path-to-report.json>

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

@@ -1,13 +1,13 @@
 ---
 name: builder-setup
-description: One-time setup for a new builder on the Example project management system. Triggers when the user says "/builder-setup", "set up builder", "register me", "set up GDS", or when a builder slash command fails with "no GDS session." Authenticates the user against GitHub via Device Flow and stores a session token at ~/.config/otb/gds-session.json so future /builder-* commands work. If a valid session already exists for another account on this machine, setup.js asks whether to continue as that builder or sign in as a different one (multi-builder-on-one-device gate).
+description: One-time setup for a new builder on the Example Bongos instance. Triggers when the user says "/builder-setup", "set up builder", "register me", "set up Bongos", or when a builder slash command fails with "no Bongos session." Authenticates the user against GitHub via Device Flow and stores a session token at ~/.config/otb/gds-session.json so future /builder-* commands work. If a valid session already exists for another account on this machine, setup.js asks whether to continue as that builder or sign in as a different one (multi-builder-on-one-device gate).
 ---
 
-You are running the one-time setup that registers this Claude Code installation as a builder on the Example GDS.
+You are running the one-time setup that registers this Claude Code installation as a builder on the Example Bongos.
 
 ## Background
 
-The GDS authenticates builders against GitHub via OAuth Device Flow. The auth happens inside the terminal: the script prints a code, the user opens a URL, types the code, the script polls until it gets approval. The setup is builder-agnostic — every path is resolved from the current user's home directory, so this works on any developer's machine.
+Bongos authenticates builders against GitHub via OAuth Device Flow. The auth happens inside the terminal: the script prints a code, the user opens a URL, types the code, the script polls until it gets approval. The setup is builder-agnostic — every path is resolved from the current user's home directory, so this works on any developer's machine.
 
 Before running this skill, **two things must be true**:
 
@@ -53,7 +53,7 @@ Runs `node scripts/gds/setup.js`. The script:
 - **Never write the session token to chat or any file other than `~/.config/otb/gds-session.json`.** It's a bearer token equivalent to a GitHub OAuth grant for this user.
 - **If `auth_not_configured` is returned**, do NOT keep polling or trying to recover — explain to the user that an Archon needs to register the GitHub OAuth App and provide credentials on the server. Point them to `blockers/blockers.md#github-oauth-app`.
 - **`GDS_API_BASE` env var** can override the API endpoint. Default is `https://example.com`. For local dev: `GDS_API_BASE=http://localhost:3000`.
-- **`HOME` env var override** — `setup.js` (and the rest of the GDS CLI) resolves every path via `os.homedir()`, which honors `$HOME`. Tests can simulate a fresh-user setup by running the script with `HOME=/tmp/some-dir`. See `tests/setup_smoke.mjs` for the smoke test that exercises this.
+- **`HOME` env var override** — `setup.js` (and the rest of the Bongos CLI) resolves every path via `os.homedir()`, which honors `$HOME`. Tests can simulate a fresh-user setup by running the script with `HOME=/tmp/some-dir`. See `tests/setup_smoke.mjs` for the smoke test that exercises this.
 
 ## Files this skill touches
 

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

@@ -5,11 +5,11 @@ description: Start a Claude Code session by listing what tasks the builder can c
 
 **Script skill (authoritative).** The core action is `node scripts/gds/start.js [--widget]`. Run it and render its output verbatim — do not rebuild the table, reorder rows, or add a recap. The card is the summary.
 
-You are starting a working session on the Example project. Before any other work, you check the GDS to see what's claimable.
+You are starting a working session on the Example project. Before any other work, you check Bongos to see what's claimable.
 
 ## Background
 
-The GDS keeps a database of tasks tagged with `touches[]` — file/folder fingerprints that determine parallel-safety. The API computes "claimable for me right now" as: tasks in `ready` status, not blocked, with no `touches[]` overlap with any currently-active claim by any builder. `ready` itself is gated by **dependencies** ([ADR 0015](../../../docs/adr/<redacted>.md)): a task enters `ready` only once every task in its `dependencies[]` is `shipped`. So if a task you want isn't listed, the usual reason is "its deps haven't shipped yet" — surface that, don't offer to override.
+Bongos keeps a database of tasks tagged with `touches[]` — file/folder fingerprints that determine parallel-safety. The API computes "claimable for me right now" as: tasks in `ready` status, not blocked, with no `touches[]` overlap with any currently-active claim by any builder. `ready` itself is gated by **dependencies** ([ADR 0015](../../../docs/adr/<redacted>.md)): a task enters `ready` only once every task in its `dependencies[]` is `shipped`. So if a task you want isn't listed, the usual reason is "its deps haven't shipped yet" — surface that, don't offer to override.
 
 `start.js` produces a deterministic **card** (identity → quiet status line → holdings → a clean claimable table → next step), the same shape every session. It comes in two forms from the same data: an HTML widget (`--widget`) and a markdown fallback (default). Your job is to render it — not to rebuild or re-summarize it.
 
@@ -24,7 +24,7 @@ Delivery is now deterministic (task 1288). The **card-delivery hook** (`.claude/
    - **No widget renderer** (raw terminal, cron, another client) → `node scripts/gds/start.js` and print its stdout **verbatim**.
    - Either way, stderr may carry an `[otb-card]` **directive for you** (restates the verbatim rule) — follow it, **never** relay it; plus private one-liners (budget / next-stage) — relay *those* as a short note after the card.
 
-- If `start.js` prints **"no GDS session"**, the builder isn't signed in — route them by scenario: a **first-timer** on the project runs `/builder-setup` (one-time GitHub sign-in that also registers them); a **returning builder whose session went stale** runs `/builder-reauth` (the fast UI re-issue). `start.js` now prints both options; relay the one that fits, then retry.
+- If `start.js` prints **"no Bongos session"**, the builder isn't signed in — route them by scenario: a **first-timer** on the project runs `/builder-setup` (one-time GitHub sign-in that also registers them); a **returning builder whose session went stale** runs `/builder-reauth` (the fast UI re-issue). `start.js` now prints both options; relay the one that fits, then retry.
 - (`--full` adds the detailed status widgets + worktree/context block; `--json` is the machine interface; `--hook` is the envelope the hook consumes — don't run these for the user unless asked.)
 
 ## When the environment isn't ready (fresh clone)
@@ -34,7 +34,7 @@ Delivery is now deterministic (task 1288). The **card-delivery hook** (`.claude/
 - **`bongos: command not found`, a "cannot find module" from `node scripts/gds/start.js`, or you can otherwise tell this is a fresh checkout** (a scaffolded instance whose `node_modules` is absent). The `bongos` CLI ships *inside* the not-yet-installed `@bongos/core` package, so nothing runs until deps are installed — this is the #1 fresh-clone wall. Route: run `npm install`, then `bongos dev` (one-command local bring-up), then re-run `/builder-start`. Don't try to hand-run internal scripts; the package isn't unpacked yet.
 - **The card says the instance isn't reachable / running.** The local server was never brought up. Route: `bongos dev`, then re-run. (`start.js` now prints this guided card itself on a connection failure — relay it verbatim.)
 - **Exit code 3 / "Wrong instance — refusing to act".** This machine's signed-in session targets a *different* instance than this project's `config/branding.json`. This is correct-by-design (it prevents writing to the wrong place). Route: run the exact `bongos login <origin>` line the message prints (the origin is right there), then re-run. **Do not** set an env override to force the mismatched instance.
-- **"no GDS session"** — the auth case above (`/builder-setup` for a first-timer, `/builder-reauth` for a stale session).
+- **"no Bongos session"** — the auth case above (`/builder-setup` for a first-timer, `/builder-reauth` for a stale session).
 
 Emit one guided next step, not a wall of options. These are the same fixes `bongos doctor` and the environment preflight (`preflight.js`) describe — this just front-loads them onto the first command so a newcomer isn't diagnosing a crash.
 

package/.claude/skills/close-box/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: close-box
-description: Tear down the dev box you are working on, from inside the box's terminal. Asks the GDS to deprovision the caller's own box (POST /box/close — the same action as the builders'-hall "Close box" button). Triggers when the user says "/close-box", "close my box", "shut down this box", "I'm done with this box", "tear down my dev box". Own-scoped — it deprovisions only the caller's own box; it never touches another builder's box or any other infrastructure (those live on the operator control plane, node scripts/gds/box.js).
+description: Tear down the dev box you are working on, from inside the box's terminal. Asks Bongos to deprovision the caller's own box (POST /box/close — the same action as the builders'-hall "Close box" button). Triggers when the user says "/close-box", "close my box", "shut down this box", "I'm done with this box", "tear down my dev box". Own-scoped — it deprovisions only the caller's own box; it never touches another builder's box or any other infrastructure (those live on the operator control plane, node scripts/gds/box.js).
 ---
 
 You are closing (deprovisioning) the dev box the builder is currently working on. This is the Claude-side twin of the `close-box` shell command (`infra/close-box.sh`) — same endpoint, for builders who'd rather say "/close-box" inside `claude` than drop to the shell. It is own-scoped and destructive (the box is destroyed), so confirm before firing.
@@ -24,7 +24,7 @@ Calls `POST /api/gds/box/close` via the cross-platform helper, after confirming
    ```
    node scripts/gds/api.js POST /api/gds/box/close
    ```
-   (The helper resolves the GDS session token + API base itself; no manual token handling.)
+   (The helper resolves the Bongos session token + API base itself; no manual token handling.)
 
 3. **Relay the outcome.** On success tell the builder:
    - The box is closing now (a few seconds).

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

@@ -1,6 +1,6 @@
 ---
 name: design-sync
-description: Export the repo design system into Claude Design so prototypes start from real tokens and component surfaces, then land Claude Design's generated UI code back as a GDS task. Triggers when the user says "/design-sync", "sync design", "export tokens to Claude Design", "import to Claude Design", or "push design system".
+description: Export the repo design system into Claude Design so prototypes start from real tokens and component surfaces, then land Claude Design's generated UI code back as a Bongos task. Triggers when the user says "/design-sync", "sync design", "export tokens to Claude Design", "import to Claude Design", or "push design system".
 ---
 
 You are helping the builder run the Claude Design sync loop: export the repo's design tokens and surfaces into Claude Design so any prototype starts from real values, not guesses.
@@ -9,7 +9,7 @@ You are helping the builder run the Claude Design sync loop: export the repo's d
 
 1. **Import** — `node scripts/gds/design-sync.js` builds a token-preview bundle (HTML color/typography/spacing/radii cards, `tokens.css`, `tokens.json`, `surfaces.json`) in a temp directory and prints a JSON manifest.
 2. **Push** — the DesignSync MCP tool (`list_projects` → `finalize_plan` → `write_files`) uploads the bundle to a Claude Design project.
-3. **Export (handoff)** — when Claude Design generates UI code, the handoff lands it under a claimed GDS task via `adapter.export()`.
+3. **Export (handoff)** — when Claude Design generates UI code, the handoff lands it under a claimed Bongos task via `adapter.export()`.
 
 ## How to use
 

package/.claude/skills/dev/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dev
-description: The engineering session — the operating playbook for engineer-discipline work (code, infra, the GDS itself, bugs, performance). Triggers when the user says "/dev", "let's build this", "work on this bug/feature", "start a dev session", or when a claimed task's discipline routes here (claim.js prints a directive to invoke /dev for engineer tasks). This is the project's DEFAULT build loop, written down — the baseline the other discipline modes (/ideate, /paint) invert from.
+description: The engineering session — the operating playbook for engineer-discipline work (code, infra, Bongos itself, bugs, performance). Triggers when the user says "/dev", "let's build this", "work on this bug/feature", "start a dev session", or when a claimed task's discipline routes here (claim.js prints a directive to invoke /dev for engineer tasks). This is the project's DEFAULT build loop, written down — the baseline the other discipline modes (/ideate, /paint) invert from.
 ---
 
 You are running an **engineering session** for Example. Unlike `/ideate` (which flips *who drives*) and `/paint` (which flips *the medium*), this skill introduces no new dynamic — engineering **is** the default text-and-code loop. Its job is to make the standard explicit and keep you on it. Read it before working; lean on it most when you're new here or running autonomously.
@@ -30,7 +30,7 @@ You are running an **engineering session** for Example. Unlike `/ideate` (which
 - **A discovery that took >10 min to diagnose → a learning** (`node scripts/gds/learning-capture.js`); a multi-page how-to → a recipe under `docs/recipes/`.
 - **Blocked on something only Lars can decide/provide → a blocker** (`POST /api/gds/blockers`), attached to the task.
 - **Touched anything the onboarding diagrams / repo-map describe** → they regenerate on deploy; never hand-edit generated artifacts — edit the source/template and run the generator (`gen-diagrams.js`, `gen-repo-map.js`).
-- **Trust boundary:** a sub-Metic builder (Xenos/Thetes) stays out of the permission/pipeline core (rank/authz machinery, the ship/grade/deploy pipeline, `migrations/`, `infra/`, trust-boundary docs) and never runs raw `git push origin main` / `ssh` / `~/deploy.sh` — landing code is the GDS's job (`/builder-ship`). Metic+ is unaffected.
+- **Trust boundary:** a sub-Metic builder (Xenos/Thetes) stays out of the permission/pipeline core (rank/authz machinery, the ship/grade/deploy pipeline, `migrations/`, `infra/`, trust-boundary docs) and never runs raw `git push origin main` / `ssh` / `~/deploy.sh` — landing code is Bongos's job (`/builder-ship`). Metic+ is unaffected.
 
 ## Step 0 — detect the mode
 

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

@@ -1,6 +1,6 @@
 ---
 name: feedback
-description: Pull the latest Bongos feedback bundle into this Claude Code session — the prompt.md walkthrough the Bongos app wrote (transcript + the ask) plus the screenshots it captured, loaded by absolute path so the Read tool can see them. Triggers when the user says "/feedback", "pull in my latest feedback", "load my bongos feedback", "I just recorded a walkthrough", "grab the latest feedback bundle", or "act on my screen recording". Local + read-only; no GDS auth needed.
+description: Pull the latest Bongos feedback bundle into this Claude Code session — the prompt.md walkthrough the Bongos app wrote (transcript + the ask) plus the screenshots it captured, loaded by absolute path so the Read tool can see them. Triggers when the user says "/feedback", "pull in my latest feedback", "load my bongos feedback", "I just recorded a walkthrough", "grab the latest feedback bundle", or "act on my screen recording". Local + read-only; no Bongos auth needed.
 ---
 
 You are pulling in the **latest Bongos feedback bundle** — a self-contained capture the user just recorded with the Bongos desktop app (BV1.R13 / [ADR 0087](../../../docs/adr/<redacted>.md)). The app turns a spoken screen walkthrough into a model-agnostic `prompt.md` (a timestamped transcript + an ask) plus a handful of screenshots, all under `~/CloudBongos/feedback/`. This skill loads that bundle so you can act on it directly — no copy-paste, no clipboard-image fiddling.
@@ -23,7 +23,7 @@ You are pulling in the **latest Bongos feedback bundle** — a self-contained ca
 
 ## Notes
 
-- **Read-only + local.** The helper only reads files under `~/CloudBongos/feedback/`; it needs no GDS session and no network.
+- **Read-only + local.** The helper only reads files under `~/CloudBongos/feedback/`; it needs no Bongos session and no network.
 - **"Latest" = most recently produced.** The Bongos app updates a `latest` pointer every time a capture is stopped, so this always loads the newest walkthrough. To act on an older one, point the user at the specific dir under `~/CloudBongos/feedback/`.
 - **The frames are file paths, never base64** — that's the whole point of the bundle format (it keeps the text prompt tiny and lets your Read tool load the images). See `bongos-app/README.md` for the full bundle contract.
 

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

@@ -1,6 +1,6 @@
 ---
 name: fix-task
-description: Claim, fix, verify, and ship a single GDS task by id — the standard cloud-bongos task loop. Use when asked to "claim/fix/ship task NNNN".
+description: Claim, fix, verify, and ship a single Bongos task by id — the standard cloud-bongos task loop. Use when asked to "claim/fix/ship task NNNN".
 ---
 
 You are running the standard task loop for cloud-bongos: read a task, verify its premise, claim it, fix it test-first, then ship it. This skill chains the pieces `/builder-claim` and `/builder-ship` already own — it does not re-derive their mechanics.

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

@@ -1,9 +1,9 @@
 ---
 name: goal-create
-description: Plan and create ONE GDS goal — the module-scoped workspace between a version and its criteria (ADR 0086) — in a single interactive session. Claude reads the goal board, decides reuse-vs-new, infers scope_modules from the LIVE module roster, drafts the goal's done-when criteria and a seed-task outline on its own, then asks only about genuine gray areas and for one sign-off before writing anything. Scoped smaller than /planning-session (one goal in one sitting, no spec file, no migration) and the opening end of /goal-review (which closes goals out). Triggers when the user says "/goal-create", "create a goal", "make a goal for this", "plan a goal", "we need a goal to hold this work", "what goal should this live in", or automatically when a task is created with no goal to live in — a POST /tasks response carrying a `goal_advisory`, or work about to land in a version's "<version> — general" catch-all. Metic+ rank only (Metic and Archon; not Xenos) — Archon for a protected-module scope.
+description: Plan and create ONE Bongos goal — the module-scoped workspace between a version and its criteria (ADR 0086) — in a single interactive session. Claude reads the goal board, decides reuse-vs-new, infers scope_modules from the LIVE module roster, drafts the goal's done-when criteria and a seed-task outline on its own, then asks only about genuine gray areas and for one sign-off before writing anything. Scoped smaller than /planning-session (one goal in one sitting, no spec file, no migration) and the opening end of /goal-review (which closes goals out). Triggers when the user says "/goal-create", "create a goal", "make a goal for this", "plan a goal", "we need a goal to hold this work", "what goal should this live in", or automatically when a task is created with no goal to live in — a POST /tasks response carrying a `goal_advisory`, or work about to land in a version's "<version> — general" catch-all. Metic+ rank only (Metic and Archon; not Xenos) — Archon for a protected-module scope.
 ---
 
-You are running the **goal-create** session for this Cloud Bongos instance. You produce **one goal**: a title, a scope wall, two to four done-when criteria, and a handful of seed tasks — written to the GDS in one sitting.
+You are running the **goal-create** session for this Cloud Bongos instance. You produce **one goal**: a title, a scope wall, two to four done-when criteria, and a handful of seed tasks — written to Bongos in one sitting.
 
 > **Not `/planning-session`, not `/goal-review`.** `/planning-session` scopes a whole **version**: 5–9 criteria, a written spec under `docs/specs/`, a multi-round interview, a seed script, a migration. This skill produces **one goal**, with no spec file and no migration. `/goal-review` is the other end of the same lifecycle — it *confirms* criteria and auto-achieves goals. If the ask is "plan the next version", stop and run `/planning-session` instead.
 

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

@@ -1,6 +1,6 @@
 ---
 name: goal-review
-description: Walk the GDS criterion review queue — for each criterion auto-flagged "met — pending review" (all its tasks shipped, not yet confirmed), prompt to confirm (→ satisfied), reject (not actually met), or note/defer. Confirming a goal's LAST criterion auto-flips the goal open→achieved. Triggers when the user says "/goal-review", "review goals", "review flagged criteria", "what criteria are ready to confirm", "confirm criteria", "walk the goal review queue", or runs as a scheduled daily task. Metic+ rank only (Metic and Archon; not Xenos).
+description: Walk the Bongos criterion review queue — for each criterion auto-flagged "met — pending review" (all its tasks shipped, not yet confirmed), prompt to confirm (→ satisfied), reject (not actually met), or note/defer. Confirming a goal's LAST criterion auto-flips the goal open→achieved. Triggers when the user says "/goal-review", "review goals", "review flagged criteria", "what criteria are ready to confirm", "confirm criteria", "walk the goal review queue", or runs as a scheduled daily task. Metic+ rank only (Metic and Archon; not Xenos).
 ---
 
 You are running the **goal-review** session for this Cloud Bongos instance. It mirrors `/idea-triage`, but for the *closing* end of the work hierarchy (ADR 0086 §6): criteria that have **auto-flagged "met — pending review"** get walked one-at-a-time and dispositioned, so finished work actually closes out instead of sitting in limbo.
@@ -34,7 +34,7 @@ You are running the **goal-review** session for this Cloud Bongos instance. It m
 node scripts/gds/api.js GET /api/gds/done-when/pending-review
 ```
 
-(Add `?version=BONGOS-V1` to scope to one version. `api.js` is the cross-platform GDS API helper — it signs the request with your session token.)
+(Add `?version=BONGOS-V1` to scope to one version. `api.js` is the cross-platform Bongos API helper — it signs the request with your session token.)
 
 If `count` is 0, print "review queue empty — no criteria pending review today" and exit.
 

package/.claude/skills/grader-health/SKILL.md

@@ -46,7 +46,7 @@ With `--probe`, run the live panel calibration: `node scripts/gds/grade-smoke.js
 
 ## Report shape
 
-End with a compact findings list, most severe first: axis, evidence (the numbers you read), verdict (outage / drift / anomaly / stale-pin / healthy), and the exact remediation command or the skill to hand off to (`/grade-recover` for a single stuck task; a GDS task via `capture.js` for systemic fixes). A clean bill of health is one line per axis.
+End with a compact findings list, most severe first: axis, evidence (the numbers you read), verdict (outage / drift / anomaly / stale-pin / healthy), and the exact remediation command or the skill to hand off to (`/grade-recover` for a single stuck task; a Bongos task via `capture.js` for systemic fixes). A clean bill of health is one line per axis.
 
 ## Constraints
 

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

@@ -1,9 +1,9 @@
 ---
 name: idea-triage
-description: Daily walk through the GDS idea_inbox — for each open idea, prompt to promote (→ task), discard, or merge with another idea. Triggers when the user says "/idea-triage", "triage ideas", "review the inbox", "walk the idea inbox", or runs as a scheduled daily task. Metic+ rank only (Metic and Archon; not Xenos).
+description: Daily walk through the Bongos idea_inbox — for each open idea, prompt to promote (→ task), discard, or merge with another idea. Triggers when the user says "/idea-triage", "triage ideas", "review the inbox", "walk the idea inbox", or runs as a scheduled daily task. Metic+ rank only (Metic and Archon; not Xenos).
 ---
 
-You are running the daily idea-triage session for Example. Open ideas in the GDS `idea_inbox` table get walked one-at-a-time and verdicted, so the inbox doesn't accumulate stale entries.
+You are running the daily idea-triage session for Example. Open ideas in the Bongos `idea_inbox` table get walked one-at-a-time and verdicted, so the inbox doesn't accumulate stale entries.
 
 > **This skill is no longer the only way to triage.** Since task 1002447 a Metic+ builder can promote, discard and merge from the **hall** — the Home "Needs your attention" card's idea rows each carry a *Triage* verb that opens the record overlay, where all three forms live. No Claude session involved. What this skill adds over the hall is the **parallel development pass** (Step 1.5) — an idea fleshed out into open questions/risks before the verdict — so reach for it when the queue needs judgment, and use the hall when it just needs clearing.
 
@@ -35,7 +35,7 @@ You are running the daily idea-triage session for Example. Open ideas in the GDS
 node scripts/gds/api.js GET /api/gds/inbox
 ```
 
-(`api.js` is the cross-platform GDS API helper — it signs the request with your
+(`api.js` is the cross-platform Bongos API helper — it signs the request with your
 session token and runs on Windows/macOS/Linux, replacing the old `python3`/`curl`
 block. For a human at a terminal, `node scripts/gds/triage.js` runs the whole
 walk interactively instead.)

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

@@ -21,7 +21,7 @@ The queue this skill works against is **tasks at status='confirmed'**. Those are
 > main worktree and deploys to the Linux droplet (owner-gated SSH). The git /
 > `ssh` / `deploy.sh` / branch-inventory steps below assume a bash environment
 > (the Archon's Mac/Linux or the droplet) by design and are NOT a Windows-builder
-> concern. The GDS *API* calls, however, go through the cross-platform
+> concern. The Bongos *API* calls, however, go through the cross-platform
 > `node scripts/gds/api.js` helper so they work regardless of shell.
 
 **Step 1 — list the queue: tasks at confirmed.**
@@ -76,7 +76,7 @@ For each confirmed task, take its branch name (`claude/<worktree_name>` from the
 #   Merge <branch-name>: <task value_summary>
 # …but first rewrite any "#NNN" in the summary to "task NNN" (task 916): commit
 # messages are GitHub-rendered and a bare "#NNN" autolinks to a dead GitHub
-# issue number, not the GDS task.
+# issue number, not the Bongos task.
 git merge --no-ff <branch-name> -F /tmp/otb-merge-msg.txt
 ```
 

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

@@ -1,9 +1,9 @@
 ---
 name: planning-session
-description: Run a structured planning session for an upcoming GDS version — set scope criteria, draft a written spec, interview the owner in depth to resolve every non-obvious decision, then seed the ranked task list from that spec. Triggers when the user says "/planning-session", "open a planning session", "let's plan V[N]", "plan the next version", or "scope a new version". Metic+ rank only (Metic and Archon; not Xenos).
+description: Run a structured planning session for an upcoming Bongos version — set scope criteria, draft a written spec, interview the owner in depth to resolve every non-obvious decision, then seed the ranked task list from that spec. Triggers when the user says "/planning-session", "open a planning session", "let's plan V[N]", "plan the next version", or "scope a new version". Metic+ rank only (Metic and Archon; not Xenos).
 ---
 
-You are running a planning session for the Game Development System (GDS). The goal is to leave the session with: (a) a clear set of done-when criteria for a version, (b) a **written spec** (`docs/specs/<ver>-<goal-slug>.md`) that an in-depth interview refines until every non-obvious decision is resolved, (c) a ranked task list **seeded from that spec** that lives in the GDS database, and (d) a durable record of the session for the audit trail.
+You are running a planning session for Bongos. The goal is to leave the session with: (a) a clear set of done-when criteria for a version, (b) a **written spec** (`docs/specs/<ver>-<goal-slug>.md`) that an in-depth interview refines until every non-obvious decision is resolved, (c) a ranked task list **seeded from that spec** that lives in the Bongos database, and (d) a durable record of the session for the audit trail.
 
 The first planning session — V3 Planning Session #1, 2026-05-12 — is the template this skill encodes. See `docs/session-logs/<redacted>.md` for the precedent and `tasks/227` (V3.R00) for the meta-task pattern.
 

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

@@ -1,9 +1,9 @@
 ---
 name: priority-session
-description: Run a structured priority session — a trusted builder answers a handful of plain-speech questions, and the answers reweight the GDS idea_inbox and suggest what to claim next. Triggers when the user says "/priority-session", "run a priority session", "what should I work on next", "reprioritize the inbox", "what feels most important right now", or "help me decide what to claim". Metic+ rank only (Metic and Archon; not Xenos).
+description: Run a structured priority session — a trusted builder answers a handful of plain-speech questions, and the answers reweight the Bongos idea_inbox and suggest what to claim next. Triggers when the user says "/priority-session", "run a priority session", "what should I work on next", "reprioritize the inbox", "what feels most important right now", or "help me decide what to claim". Metic+ rank only (Metic and Archon; not Xenos).
 ---
 
-You are running a **priority session** for the Game Development System (GDS). Where a **planning session** sets a *version's* scope (criteria + a fresh ranked task list), a priority session works the *present tense*: it takes the open `idea_inbox` exactly as it stands and reweights it against how the builder actually feels about the work right now — what's stuck, what would unblock the most people, what they're excited to build. The session ends with a **weighted ranking of the open ideas** and a single **"what should I claim next?"** suggestion, and it writes a durable session-log entry so the reweighting is on the audit trail.
+You are running a **priority session** for Bongos. Where a **planning session** sets a *version's* scope (criteria + a fresh ranked task list), a priority session works the *present tense*: it takes the open `idea_inbox` exactly as it stands and reweights it against how the builder actually feels about the work right now — what's stuck, what would unblock the most people, what they're excited to build. The session ends with a **weighted ranking of the open ideas** and a single **"what should I claim next?"** suggestion, and it writes a durable session-log entry so the reweighting is on the audit trail.
 
 This is the live-flight complement to `/planning-session`: planning sessions set a version's scope; priority sessions reweight the present queue when the builder isn't sure where to point their energy.
 

package/.claude/skills/read-session-export/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: read-session-export
-description: Read a Claude Code `/export` zip quickly and consistently — the conversation, the assistant's thinking ("the thoughts"), and what the tools did — so you can answer questions about a past session. Triggers when the user drops a `session-export-*.zip` (or names one) and says "read this session", "what happened in this session", "what was I/you thinking here", "summarize this export", "read the latest session export", or "/read-session-export". This READS the existing export — it does not create a new one. Local + read-only, no GDS auth, no network.
+description: Read a Claude Code `/export` zip quickly and consistently — the conversation, the assistant's thinking ("the thoughts"), and what the tools did — so you can answer questions about a past session. Triggers when the user drops a `session-export-*.zip` (or names one) and says "read this session", "what happened in this session", "what was I/you thinking here", "summarize this export", "read the latest session export", or "/read-session-export". This READS the existing export — it does not create a new one. Local + read-only, no Bongos auth, no network.
 ---
 
 The user already has the zip — Claude Code's built-in `/export` made it. Your job is to **read it well**: a session export is the same shape every time, so don't go spelunking through it by hand or load the megabytes of debug logs. Run the reader, which prints a compact transcript (prompts + thinking + replies + one-line tool calls) to stdout, then answer whatever the user actually asked.
@@ -49,7 +49,7 @@ So if the user exported an Opus session hoping to re-read the literal reasoning,
 ## Constraints
 
 - **Reads, never writes.** Output goes to stdout for you to consume; it creates no files and never modifies the zip.
-- **Local + zero-dependency.** Pure Node stdlib (a small `zlib` ZIP reader) — no GDS session, no network, no install. Works on any builder machine.
+- **Local + zero-dependency.** Pure Node stdlib (a small `zlib` ZIP reader) — no Bongos session, no network, no install. Works on any builder machine.
 - ZIP64 archives (multi-GB) are refused with a clear message; no real session export hits that.
 
 ## Files this skill touches

package/.claude/skills/scan-before-install/SKILL.md

@@ -15,7 +15,7 @@ You are scanning a third-party artifact someone wants to install. The engine liv
 6. **Floor findings are untouchable.** Refuters may uphold or refute PANEL findings only. Nothing a model says can remove what the detectors proved.
 7. **The report lands in the builder's own user config dir** (`~/.config/otb/scan-reports/`), NEVER `docs/`, never anywhere in the repo. A scan report is a timestamped accusation about a named third party; `docs/` is a public AGPL repo indexed by `/recall`.
 8. **Zero new npm dependencies.** The whole pipeline is node builtins + git. A downloaded zip/tar gets a plain refusal (below) — no archive extractor exists here on purpose.
-9. **Every quoted string from the artifact or a lens is scrubbed + capped** before it reaches chat, the report, or the GDS row. Never paste raw artifact text anywhere. The GDS row carries structure only.
+9. **Every quoted string from the artifact or a lens is scrubbed + capped** before it reaches chat, the report, or the Bongos row. Never paste raw artifact text anywhere. The Bongos row carries structure only.
 
 ## Targets — what is scannable
 
@@ -149,7 +149,7 @@ For a dangerous verdict, failed sanitize gates, or a user who just wants the fun
 1. `selectDocFiles(entries)` — the ONLY files a model may read for this landing, via the mirror. Documentation only, never code: the spec describes WHAT to build, derived from the artifact's own docs.
 2. Spawn one doc-reader subagent at those mirror files → it returns one-line functional requirements (JSON array of strings).
 3. `assembleRebuildSpec({ target, docPaths, requirements })` — script-owned framing, every line scrubbed. Write `REBUILD-SPEC.md` next to the scan report in `~/.config/otb/scan-reports/`.
-4. Offer to file it as a GDS task: `POST /api/gds/tasks` (status `backlog`, body = the spec markdown; Metic+) or `node scripts/gds/capture.js` into the idea inbox otherwise. Record `rebuild_spec`.
+4. Offer to file it as a Bongos task: `POST /api/gds/tasks` (status `backlog`, body = the spec markdown; Metic+) or `node scripts/gds/capture.js` into the idea inbox otherwise. Record `rebuild_spec`.
 
 ## What this skill does NOT do
 
@@ -162,4 +162,4 @@ For a dangerous verdict, failed sanitize gates, or a user who just wants the fun
 
 ## When the API is unreachable
 
-The scan itself is fully local — quarantine, floor, panel, report all still work. What fails is the prior-scan lookup (step 3) and the row write (step 7). Say so explicitly, keep the report file, and offer to record the row later; never pretend the row was written, and never skip the scan because the GDS is down.
+The scan itself is fully local — quarantine, floor, panel, report all still work. What fails is the prior-scan lookup (step 3) and the row write (step 7). Say so explicitly, keep the report file, and offer to record the row later; never pretend the row was written, and never skip the scan because Bongos is down.

package/.claude/skills/status/SKILL.md

@@ -3,7 +3,7 @@ name: status
 description: Answer "what's the status of X" / "what's left for criterion Cn" in one call. Triggers when the user says "/status", "what's left for C8", "status of GDS-V3", "how far along is the memory criterion", "what tasks remain to complete X", or asks how a version/criterion is progressing. Read-only — rolls up each done-when criterion → its gating tasks → live statuses → what's blocking.
 ---
 
-You are answering a project-status question. Before this skill existed, doing so meant ~10 sequential GDS calls (grep the seed file for which tasks map to a criterion, eyeball a "Gates R55–R63" sentence, then re-query each task's status). The structured criterion↔task link (`task_criteria`, migration 055) + the `/status` CLI collapse that to one call. See ADR 0025 and task #435.
+You are answering a project-status question. Before this skill existed, doing so meant ~10 sequential Bongos calls (grep the seed file for which tasks map to a criterion, eyeball a "Gates R55–R63" sentence, then re-query each task's status). The structured criterion↔task link (`task_criteria`, migration 055) + the `/status` CLI collapse that to one call. See ADR 0025 and task #435.
 
 ## What this skill does
 

package/config/branding.neutral.json

@@ -51,7 +51,7 @@
   },
   "rankLabels": { "xenos": "Newcomer", "thetes": "Contributor", "metic": "Trusted", "archon": "Owner" },
   "copy": {
-    "tagline": "Building software is laying down a beat.",
+    "tagline": "Building Digitally, as simple as Bongos.",
     "hallName": "Builders' Hall",
     "notFound": "This page skipped a beat.",
     "authError": {

package/docs/architecture.md

@@ -1,11 +1,11 @@
 # Architecture — current state
 
 > Split out of `CLAUDE.md` §10 in V3.R86 ([#305](https://example.com/builders#/task/305)) to keep the agent index lean. `CLAUDE.md` §10 now
-> carries a one-paragraph orientation and points here. This file is **descriptive** — for live GDS
+> carries a one-paragraph orientation and points here. This file is **descriptive** — for live Bongos
 > state (tasks, versions, claims, ranks) the source of truth is the database via `/api/gds/*`, and
 > for permissions specifically see [`docs/canonical-permissions.md`](canonical-permissions.md).
 
-> **For decision rationale (why we chose what), read [`docs/adr/`](adr/). The most relevant: 0001 (stack), 0002 (DigitalOcean), 0003 (Cloudflare cert), 0006 (singleton WorldRoom + queue), 0007 (persistent identity), 0008 (Google Chat OAuth), 0010 (GDS architecture), 0016 (trust boundary).**
+> **For decision rationale (why we chose what), read [`docs/adr/`](adr/). The most relevant: 0001 (stack), 0002 (DigitalOcean), 0003 (Cloudflare cert), 0006 (singleton WorldRoom + queue), 0007 (persistent identity), 0008 (Google Chat OAuth), 0010 (Bongos architecture), 0016 (trust boundary).**
 
 **Live & running:**
 
@@ -84,7 +84,7 @@ players(id text PK, current_grid_x int, current_grid_y int, current_facing text,
   indexes: (last_seen_at)
 ```
 
-GDS tables (migration `003_pms.sql`, see [ADR 0010](adr/0010-pms-architecture.md)):
+Bongos tables (migration `003_pms.sql`, see [ADR 0010](adr/0010-pms-architecture.md)):
 
 ```
 builders(id, github_id UNIQUE, github_login, display_name, avatar_url, total_credits, karma,
@@ -201,9 +201,9 @@ audit_log(id, builder_id, route, method CHECK IN (POST|PATCH|PUT|DELETE),
                -- bfg_dream_write | bfg_correction_write.
 ```
 
-GDS views: `claimable_tasks` (rebuilt in 006 to use SELECT t.*; rebuilt again in 014 so the new `discipline` column flows through), `version_progress` (rebuilt in 006 to count only leaf tasks for forward-compat with task hierarchy), `tasks_session_fit` (new in 006: derives `fits_session_modes[]` and `credits_per_minute`; rebuilt in 014 for the same SELECT t.* refresh), `task_grades_with_context` (new in 016: joins task_grades × tasks × builders × cost_log so the V4 optimizer has quality-per-dollar in one read).
+Bongos views: `claimable_tasks` (rebuilt in 006 to use SELECT t.*; rebuilt again in 014 so the new `discipline` column flows through), `version_progress` (rebuilt in 006 to count only leaf tasks for forward-compat with task hierarchy), `tasks_session_fit` (new in 006: derives `fits_session_modes[]` and `credits_per_minute`; rebuilt in 014 for the same SELECT t.* refresh), `task_grades_with_context` (new in 016: joins task_grades × tasks × builders × cost_log so the V4 optimizer has quality-per-dollar in one read).
 
-**GDS API (`/api/gds/*`, mounted in the same Node process):**
+**Bongos API (`/api/gds/*`, mounted in the same Node process):**
 
 - **Canonical path is `/api/bongos` (task 1919); `/api/gds` is a PERMANENT alias.** The router + the discovery index are dual-mounted at both by `serve-internal.js`, driven by the single `src/bongos/api-prefix.js` constant (`API_PREFIX` + `LEGACY_API_PREFIXES`). The legacy `/api/gds` alias never goes away — shipped Dev Box binaries, the cached status mirror, and live boxes call it. **Exception:** the GitHub OAuth callback stays pinned to `/api/gds/auth/web/callback` (registered on the OAuth app; `src/bongos/routes/auth.js`). Not yet flipped (still ride the permanent alias): `src/**` internal callers + the deeper internal names (folders, `GDS_*` env, `gds_session` cookie) — the deferred internal-rename pass.
 - **Self-describing (task 1918, [ADR 0109](adr/<redacted>.md)).** The whole surface is documented in the standard **OpenAPI 3.1** format at [`docs/api/openapi.json`](api/openapi.json), **generated from the live route files** by `scripts/gds/gen-api-docs.js` (reusing the same `route-rank-check.js` introspection the ship-time rank gate uses — so it can't drift; a fitness `--check` + ship-time regen enforce freshness). A rendered docs site (vendored Redoc) is served at **`/docs`** on the apex of every instance (`cloudbongos.com/docs` canonical); `GET /api/gds` returns a machine-discovery index pointing at it. The generated [`docs/api-reference.md`](api-reference.md) supersedes the old hand-maintained `routes-permissions.md`. The mount prefix is the single `src/bongos/api-prefix.js` constant.
@@ -217,7 +217,7 @@ GDS views: `claimable_tasks` (rebuilt in 006 to use SELECT t.*; rebuilt again in
 - Builder memory (ADR 0024 cloneable memory + ADR 0026 BFG). Self-scoped (owner is always `req.builder.id`, never input): `POST /memory/sync` (push own memory; own 64 MB parser, vs the global 64 KB), `GET /memory/files`, `GET /memory/file`, `DELETE /memory/file` (the BFG delete affordance, 6C.2). Cross-builder (input-owner) endpoints — all privileged + audit-logged fail-closed: `GET /memory/builders/:id/files`+`/file` (**archon forensic** read), `GET /memory/bfg/builders/:id/files`+`/file` (**BFG-principal only**, 6B.1 read), and the one cross-builder WRITE `POST /memory/builders/:id/bfg-write` (**BFG-principal only**, kill-switched `BFG_WRITE_ENABLED` default-OFF, namespaced `bfg/`, attributed `author: BFG`, write+audit in one tx — dreams + transparent corrections, 6C.1/6C.2).
 - Session corpus (BFG evaluator — 6D, ADR 0027): `POST /sessions` (upload own session digest; own **4 MB** json parser — capped, vs the global 64 KB — and the digest is per-turn metadata + short scrubbed snippets, never raw transcript content), `GET /sessions/mine` (self-serve), `GET /sessions/search` (cross-builder, **archon-gated** — the BFG-principal stand-in; the principal now exists (6C.1) and the *memory* cross-reads moved to it (6B.1), but these *session* reads still use the archon stand-in pending a retrofit, + audit_log row per read), `GET /sessions/:id` (own self-serve; cross-builder needs archon + audit; non-owner → 404).
 - Public (no auth, `Cache-Control: max-age=60`): `/public/versions`, `/public/progress`, `/public/cost-summary`, `/public/recent-shipped`, `/public/leaderboard`, `/public/grades[?days=N]`, `/public/tasks/:id` ([#604](https://example.com/builders#/task/604) — single-task resolver for `#NNN` doc deep-links; `title`/`value_summary` returned **only** for `shipped`|`confirmed` work and withheld for in-flight tasks so unshipped/security task names can't leak; the status dashboard renders it at `#/task/:id`), `/public/ref-ids` ([#653](https://example.com/builders#/task/653) — `{tasks:[ids]}`, ids only, token-free; the doc-ref linkifier + its CI gate consult it to decide which bare `#NNN` are real task refs). These power `status.example.com`.
-- Live updates (Server-Sent Events — [#569](https://example.com/builders#/task/569), [ADR 0030](adr/<redacted>.md) signal layer, [ADR 0069](adr/<redacted>.md) transport): an SSE stream at `GET /api/gds/live` ([`src/bongos/routes/live.js`](../src/bongos/routes/live.js)), mounted in both entrypoints (`server.js` + `src/platform-server.js`) so the hall stays live on a game-less boot. This **superseded** the original broadcast-only Colyseus `builders_hall` room (R55 / task 1194 — the room and `src/rooms/BuildersHallRoom.js` were deleted because a GDS-only instance has no Colyseus in the process). The change-signal layer is **unchanged**: a statement-level Postgres `NOTIFY` trigger (migration 066) on `tasks`/`claims`/`builders`/`builder_onboarding_state`/`credit_log`/`karma_log` fires a `gds_live` notification on every write (incl. direct `psql`); one persistent `LISTEN` connection ([`src/bongos/live-channel.js`](../src/bongos/live-channel.js)) relays each notification, and the SSE endpoint emits an **opaque empty nudge** to open hall tabs (the `{table, op}` is kept server-side so internal table names can't leak); the hall re-runs its `loadAll()` (debounced) on any nudge. No row data crosses the channel — access control stays on the per-panel re-fetches.
+- Live updates (Server-Sent Events — [#569](https://example.com/builders#/task/569), [ADR 0030](adr/<redacted>.md) signal layer, [ADR 0069](adr/<redacted>.md) transport): an SSE stream at `GET /api/gds/live` ([`src/bongos/routes/live.js`](../src/bongos/routes/live.js)), mounted in both entrypoints (`server.js` + `src/platform-server.js`) so the hall stays live on a game-less boot. This **superseded** the original broadcast-only Colyseus `builders_hall` room (R55 / task 1194 — the room and `src/rooms/BuildersHallRoom.js` were deleted because a Bongos-only instance has no Colyseus in the process). The change-signal layer is **unchanged**: a statement-level Postgres `NOTIFY` trigger (migration 066) on `tasks`/`claims`/`builders`/`builder_onboarding_state`/`credit_log`/`karma_log` fires a `gds_live` notification on every write (incl. direct `psql`); one persistent `LISTEN` connection ([`src/bongos/live-channel.js`](../src/bongos/live-channel.js)) relays each notification, and the SSE endpoint emits an **opaque empty nudge** to open hall tabs (the `{table, op}` is kept server-side so internal table names can't leak); the hall re-runs its `loadAll()` (debounced) on any nudge. No row data crosses the channel — access control stays on the per-panel re-fetches.
 
 **Builder ranks & the trust boundary:** moved to its own canonical reference —
 [`docs/canonical-permissions.md`](canonical-permissions.md) (rank ladder, live ranks, what's gated,
@@ -225,7 +225,7 @@ failure modes) and [ADR 0016](adr/<redacted>.md) (the decision).
 **Authority lives in `builders.rank` on the prod DB, checked server-side per request with no caching;
 markdown describes, the DB enforces.**
 
-> **Two entrypoints, one serving path (ADR 0062 R51, task 1190).** The host-routing + hall/status serving below is factored into `mountInternalSurfaces(app)` in [`src/bongos/serve-internal.js`](../src/bongos/serve-internal.js), called by **both** the game boot ([`server.js`](../server.js)) and the new **GDS-only boot** ([`src/platform-server.js`](../src/platform-server.js)). The platform boot constructs **no Colyseus, no game rooms, no `/vendor/*`, no `/assets/tiles`, no `public/`** — a game-less Cloud Bongos instance runs it unchanged, and "no game route is reachable" holds by absence (the inverse of `preview-server.js`, which serves only the game). Prod still runs `node server.js`; the GDS-only entrypoint is the seam the instance model (R54/R67) boots on.
+> **Two entrypoints, one serving path (ADR 0062 R51, task 1190).** The host-routing + hall/status serving below is factored into `mountInternalSurfaces(app)` in [`src/bongos/serve-internal.js`](../src/bongos/serve-internal.js), called by **both** the game boot ([`server.js`](../server.js)) and the new **Bongos-only boot** ([`src/platform-server.js`](../src/platform-server.js)). The platform boot constructs **no Colyseus, no game rooms, no `/vendor/*`, no `/assets/tiles`, no `public/`** — a game-less Cloud Bongos instance runs it unchanged, and "no game route is reachable" holds by absence (the inverse of `preview-server.js`, which serves only the game). Prod still runs `node server.js`; Bongos-only entrypoint is the seam the instance model (R54/R67) boots on.
 
 **Multi-host setup (same Node process), routed by `Host` header in [`src/bongos/serve-internal.js`](../src/bongos/serve-internal.js), shared by both entrypoints:**
 

package/docs/branding-contract.md

@@ -34,7 +34,7 @@ env override   →   instance config (config/branding.json)   →   neutral star
 | `domains.instanceBase` | Apex zone new projects get their **auto-assigned** address under (`<slug>.<instanceBase>`, task 1002704 — every project's hall reachable day one; `no_address: true` on the create call opts out). Same one-label-under-apex/edge-TLS constraint as `devBoxBase`. Deliberately NOT derived from `publicOrigin` (on a co-hosting control plane that is the game's domain). Empty ⇒ no auto-assign — creates are domainless unless the caller brings a domain. |
 | `domains.sandboxPrefix` / `termPrefix` | Subdomain prefixes for the sandbox-preview + browser-terminal hosts. |
 | `repo` | `{ owner, name }` GitHub binding. |
-| `db.database` | DB name the GDS pool connects to when neither `DATABASE_URL` nor `PGHOST`/`PGDATABASE` is set (`src/bongos/pool.js`, ADR 0062 §5). `null` in the neutral starter = **fail loud** rather than silently target a host DB. |
+| `db.database` | DB name Bongos pool connects to when neither `DATABASE_URL` nor `PGHOST`/`PGDATABASE` is set (`src/bongos/pool.js`, ADR 0062 §5). `null` in the neutral starter = **fail loud** rather than silently target a host DB. |
 | `currency` | `{ label, symbol }` — the reward unit label (e.g. "example"). Display only. |
 | `reward` | `{ marginPct, usdPeg, mode }` — the per-instance reward POLICY the economy module reads ([ADR 0054](adr/<redacted>.md) + ADR 0146, tasks 2009/1002270): the cost-plus margin percent (default `20`), the example-per-USD peg (default `1`), and `mode` — `"cost-plus-and-estimate"` (default; pay both the per-task author estimate AND the cost-plus session reward) or `"cost-plus-only"` (suppress the per-task estimate payout; the cost-plus session reward is the sole equity reward). A committed, code-reviewed change — not a live UI knob. Omit ⇒ code defaults (20% margin, 1:1 peg, pay both streams). |
 | `models` | `{ main, subagentDefault, subagentRoutine }` — the per-instance subagent model-allocation DEFAULT the builder-settings module reads (task 2011): the tier for the main session, subagent-default work, and routine plumbing (tiers: `haiku`/`sonnet`/`opus`/`fable`). A per-builder override resolves over this. Omit ⇒ code defaults (`opus`/`opus`/`haiku`). |

package/docs/design/modular-architecture/01-architecture.md

@@ -100,7 +100,7 @@ graph LR
 
 - A rewrite **re-derives the parts you'd keep anyway** (auth, rank ladder, tasks/claims/credits, grader, ship pipeline, ~111 migrations) — no modularity win in retyping it; the win is *where code lives + enforced boundaries*, which a reorg delivers.
 - The risk profile is upside-down for a bootstrapped, ship-small, AI-first project: a rewrite is a long no-ship window ending in a big-bang cutover.
-- **Rule of thumb: rewrite when the foundation is wrong; reorganize when the foundation is sound but the filing is wrong.** Your foundation (trust boundary, GDS pipeline, grader) is sound; the filing (fused game/core, a 236 KB `db.js`, flat routes, hardcoded brand strings) is wrong. That's a reorg.
+- **Rule of thumb: rewrite when the foundation is wrong; reorganize when the foundation is sound but the filing is wrong.** Your foundation (trust boundary, Bongos pipeline, grader) is sound; the filing (fused game/core, a 236 KB `db.js`, flat routes, hardcoded brand strings) is wrong. That's a reorg.
 
 ## 6. The migration path
 
@@ -122,4 +122,4 @@ The proof at every step (as in ADR 0062's core/host split): after moving a modul
 
 **Changes (reorganize):** code moves into `modules/<key>/` slices · a real loader replaces hand-wired `if (isModuleEnabled())` lines · `module.json` becomes load-bearing · the 236 KB `db.js` is carved per-module · a task gains a module label; `touches[]` retires · brand strings + stylesheets consolidate.
 
-**Stays (unchanged):** one `package.json` · one Node process (`node server.js`) · no bundler · Postgres, raw ESM client + CJS server · the trust boundary + rank ladder (extended to module routes) · the GDS ship/grade/deploy pipeline.
+**Stays (unchanged):** one `package.json` · one Node process (`node server.js`) · no bundler · Postgres, raw ESM client + CJS server · the trust boundary + rank ladder (extended to module routes) · the Bongos ship/grade/deploy pipeline.

package/docs/design/modular-architecture/02-module-map.md

@@ -69,7 +69,7 @@ graph LR
 
 ## 4. The one warning: don't cut through the lifecycle
 
-The GDS lifecycle — **claim → work → ship → grade → credit** — is the most coupled part, and the graph proves it (`tasks` imports `grader`, `github-push`, `ship-broadcast`). Keep the **state machine** (tasks/claims/versions) as one module; extract the *capabilities it invokes* (grade, reward) as separate modules behind kernel seams ([04](04-module-lifecycle.md)). Forcing the state machine apart with a strict "import the kernel only" rule would break the rule constantly or bloat the kernel.
+Bongos lifecycle — **claim → work → ship → grade → credit** — is the most coupled part, and the graph proves it (`tasks` imports `grader`, `github-push`, `ship-broadcast`). Keep the **state machine** (tasks/claims/versions) as one module; extract the *capabilities it invokes* (grade, reward) as separate modules behind kernel seams ([04](04-module-lifecycle.md)). Forcing the state machine apart with a strict "import the kernel only" rule would break the rule constantly or bloat the kernel.
 
 ## 5. Cross-cutting code (e.g. "security")
 

package/docs/design/modular-architecture/03-builder-flows.md

@@ -67,7 +67,7 @@ graph TD
 - **Parallel** (`--parallel N`): the conductor fans out worker subagents, each `isolation: "worktree"`, each on a different module → they can't collide (different modules).
 - **Sequential**: the conductor `EnterWorktree`s a fresh worktree per task, ships, `ExitWorktree`s, moves on.
 
-The session has full mobility across modules; only each *task's worker* is module-isolated. This is the orchestrator-worker pattern (ADR 0024), and the GDS already assigns a per-claim worktree.
+The session has full mobility across modules; only each *task's worker* is module-isolated. This is the orchestrator-worker pattern (ADR 0024), and Bongos already assigns a per-claim worktree.
 
 ## 7. Limiting what the box holds — the jailbreak blast radius
 

package/docs/design-contract.md

@@ -48,7 +48,7 @@ All color values are CSS color strings (hex, `rgb()`, `hsl()`, `color-mix()`, et
 
 ### 1.5 Extending tokens
 
-An instance may add new tokens inside any group — the schema uses `additionalProperties: false` on the top-level groups to prevent misspellings of the canonical keys, but accepts that an instance may grow additional groups over time. Add a new group by proposing a schema addition via a GDS task before committing it to the instance pack.
+An instance may add new tokens inside any group — the schema uses `additionalProperties: false` on the top-level groups to prevent misspellings of the canonical keys, but accepts that an instance may grow additional groups over time. Add a new group by proposing a schema addition via a Bongos task before committing it to the instance pack.
 
 ---
 
@@ -214,8 +214,8 @@ module.exports = {
   repoRoot: string;         // absolute path to the repo root
   surfaceId: string;        // which surface this export targets
   toolOutput: unknown;      // adapter-specific; see per-adapter docs
-  taskId?: string;          // GDS task to associate the commit with
-  authorName?: string;      // git author name (defaults to GDS builder identity)
+  taskId?: string;          // Bongos task to associate the commit with
+  authorName?: string;      // git author name (defaults to Bongos builder identity)
 }
 ```
 
@@ -318,5 +318,5 @@ The validator is hooked into `scripts/gds/fitness.js` as an opt-in check (enable
 
 1. Create `src/ui/adapters/<id>/index.js` exporting `{ id, import, export }`.
 2. Add a `<surface-id>` entry to `config/design-sources.json` with `"tool": "<id>"`.
-3. Write a task for the adapter (it unblocks from [task 1377](https://example.com/builders#/task/1377)) and ship it under a claimed GDS task.
+3. Write a task for the adapter (it unblocks from [task 1377](https://example.com/builders#/task/1377)) and ship it under a claimed Bongos task.
 4. The validator discovers the adapter automatically on the next run.