@bongos/core 1.19.156 → 1.19.158

package/docs/file-map.md

@@ -27,12 +27,12 @@
 │   ├── v1-shipped.md            ← V1 game archive (shipped 2026-05-12)
 │   ├── pms-v2-shipped.md        ← PMS-V2 archive (shipped 2026-05-12)
 │   ├── pms-v1-shipped.md        ← PMS-V1 archive (shipped 2026-05-09)
-│   └── backlog.md               ← FROZEN archive after one-time DB import (live tasks in GDS DB)
-├── generative-ideas.md          ← FROZEN archive after Phase 2c DB import (live ideas in GDS idea_inbox table)
+│   └── backlog.md               ← FROZEN archive after one-time DB import (live tasks in Bongos DB)
+├── generative-ideas.md          ← FROZEN archive after Phase 2c DB import (live ideas in Bongos idea_inbox table)
 │                                  (chat-inbox.md removed 2026-06-05 — inbound is now Discord #ideas → idea_inbox, ADR 0033 F6)
 ├── blockers/
 │   ├── README.md
-│   └── blockers.md              ← FROZEN archive after Phase 2a DB import (live blockers in GDS blockers table)
+│   └── blockers.md              ← FROZEN archive after Phase 2a DB import (live blockers in Bongos blockers table)
 │
 ├── brand/                       ← repo-canonical design system (ADR 0081)
 │   └── cloud-bongos/            ← Cloud Bongos brand: README design guide + tokens.json + regen_*.py + assets/ (mascot, 9 animation states, Docker-homage sky-whale, coin logo + Baloo 2 wordmark, painted code-glyph charms). Built under task 1506 (mascot restyle 1529, code glyphs 1527); illustrations generated via Gemini (modules/art-pipeline/pipeline gen_api).
@@ -43,7 +43,7 @@
 │   ├── adr/                     ← Architecture Decision Records
 │   │   ├── README.md            ← full ADR index (authoritative)
 │   │   └── 0001…0120-*.md       ← 133 ADR files (a handful of numbers collide — see README.md's disambiguation note; README.md has the live list)
-│   ├── architecture.md          ← §10 detail: live infra, app stack, DB schema, GDS API (split out V3.R86)
+│   ├── architecture.md          ← §10 detail: live infra, app stack, DB schema, Bongos API (split out V3.R86)
 │   ├── canonical-permissions.md ← rank ladder + trust boundary reference (read-only mirror; DB enforces)
 │   ├── design/                  ← game design docs (V2 visual redesign cluster)
 │   │   ├── container-exterior.md ← (#641) container building exterior: two-storey stacked-container structure, glass facade, deck, rooftop
@@ -81,12 +81,12 @@
 │   ├── box-terminal.service     ← (#760/ADR 0038) always-on ttyd web terminal (127.0.0.1:7681, per-box basic-auth) for thin-device (Chromebook/browser) builders
 │   ├── cloudflared.service      ← (#760/ADR 0038) outbound-only Cloudflare Tunnel exposing the box terminal (no inbound ports); runs cloudflared-run.sh
 │   └── cloudflared-run.sh       ← (#760/ADR 0038) runs ON THE BOX: named tunnel (BOX_TUNNEL_TOKEN) or tokenless quick tunnel; writes the public URL to /run/otb/terminal-url
-├── migrations/                 ← CORE (build-system / GDS) migrations — schema + platform-universal seeds, applied on EVERY instance (migrate.sh `migrations/*.sql`). Game-module migrations moved to modules/game/migrations/ (BV1.R49).
+├── migrations/                 ← CORE (build-system / Bongos) migrations — schema + platform-universal seeds, applied on EVERY instance (migrate.sh `migrations/*.sql`). Game-module migrations moved to modules/game/migrations/ (BV1.R49).
 │   ├── instance/                ← OTB/product SCOPE-TRUTH seeds (versions, goals, done_when_criteria). Applied only on the OWNING instance — `GDS_APPLY_INSTANCE_SEEDS=1`, default OFF — so a vanilla/branded self-host never inherits them (task 1704 / ADR 0105). Merge-sorted with core by basename, so global order is preserved.
 │   ├── game/                    ← LEGACY game-module migrations (moved to modules/game/migrations/ in BV1.R49 — stem-keyed, so they did NOT re-run on prod). Kept here as a frozen archive; migrate.sh still applies them for backward compat.
 │   │   ├── 001_initial.sql      ← schema_migrations + world_events (game)
 │   │   └── 002_players.sql      ← players — persistent identity (game)
-│   ├── 003_pms.sql              ← GDS schema: builders, versions, tasks, claims, costs, credits, sessions
+│   ├── 003_pms.sql              ← Bongos schema: builders, versions, tasks, claims, costs, credits, sessions
 │   ├── 112_drop_track_check.sql ← task 1191: drop the product|internal track CHECK on versions (taxonomy → branding.tracks config); name-independent + idempotent
 │   ├── <redacted>.sql ← cost_log unique (source, source_ref) for idempotent backfill
 │   ├── 005_pms_smoke_filter.sql ← filter __smoke__ tasks from claimable_tasks + version_progress
@@ -128,8 +128,8 @@
 │
 ├── scripts/
 │   ├── migrate.sh               ← idempotent migration runner; applies core `migrations/*.sql` always + `modules/<key>/migrations/*.sql` only when the module is enabled (ADR 0083 §module-owned-migrations); stem-keyed so relocating a migration between dirs never re-runs it on prod
-│   ├── verify-gds-only-schema.sh ← task 1191: throwaway-DB proof that a GDS-only migration run yields the build-system schema with NO game tables (needs local Postgres; not the DB-free unit gate)
-│   ├── setup-builder.js         ← one-command new-builder bootstrap (toolchain + npm ci + .env.local + GDS auth); cross-platform node entry (#673)
+│   ├── verify-gds-only-schema.sh ← task 1191: throwaway-DB proof that a Bongos-only migration run yields the build-system schema with NO game tables (needs local Postgres; not the DB-free unit gate)
+│   ├── setup-builder.js         ← one-command new-builder bootstrap (toolchain + npm ci + .env.local + Bongos auth); cross-platform node entry (#673)
 │   ├── setup-builder.sh         ← thin bash shim → setup-builder.js (Mac/Linux convenience + devcontainer/README refs)
 │   ├── deploy/                  ← deploy scripts that run ON the droplet
 │   │   ├── deploy-prod.sh       ← #1026/ADR 0056: version-controlled MIRROR of the droplet's hand-maintained ~/deploy.sh (byte-faithful). NOT auto-installed — the ci deploy key is forced-command-locked (ADR 0042/0043); reinstall by hand on change. Localhost /healthz retried 15×@1s so a slow bind no longer false-fails a deploy.
@@ -140,7 +140,7 @@
 │   │   ├── README.md
 │   │   ├── lib.js               ← webhook poster (reads ~/.config/otb/discord-webhooks.json, mode 600)
 │   │   └── post.js              ← post a ship summary to a channel (default ship_news)
-│   └── gds/                     ← Game Development System CLI + bootstrap (renamed from `pms/` in V3.R01)
+│   └── gds/                     ← Bongos CLI + bootstrap (renamed from `pms/` in V3.R01)
 │       ├── cli-lib.js           ← shared: session token, apiCall(), formatters
 │       ├── discord-channels.js  ← Archon CLI: plan/apply the Discord channel layout via the API (ADR 0036, #727)
 │       ├── setup.js             ← one-time GitHub Device Flow → ~/.config/otb/gds-session.json
@@ -170,7 +170,7 @@
 │       ├── smoke-gds.js         ← public-surface + 401-check smoke test (asserts /api/pms/* now 404s — removed in V3.R01-followup #308)
 │       ├── box.js               ← (#598/ADR 0031) per-builder dev box lifecycle CLI: provision·park·wake·deprovision·sweep-idle·sweep-dormant·status (dry-run default, --apply to act; rank-gated)
 │       ├── smoke-box.sh         ← (#598) hermetic box-lifecycle smoke (no DB/DO/network): runs tests/boxes.mjs + tests/cf_tunnel.mjs (#771 named tunnel) + route-rank + module-load
-│       ├── recall.js            ← `/recall` CLI: two-call progressive-disclosure search (summary → `--expand <id>`) over the GDS retrieval layer (ADR 0060); `node scripts/gds/recall.js <query>`
+│       ├── recall.js            ← `/recall` CLI: two-call progressive-disclosure search (summary → `--expand <id>`) over Bongos retrieval layer (ADR 0060); `node scripts/gds/recall.js <query>`
 │       ├── capture.js           ← file an idea_inbox row from the CLI (the ideas.capture kernel port); backs the "capture a tangent" flow across skills
 │       ├── worktree.js          ← (task 1002809) junction-safe worktree add/remove/list — outside-repo worktrees get a node_modules junction via node (no shell quoting), removed BEFORE `git worktree remove`
 │       ├── learning-capture.js  ← file a `learnings` row (DB-backed short-form rule capture, replacing hand-edited recipe files for a single gotcha)
@@ -194,7 +194,7 @@
 │   │   ├── provenance.js       ← pure "who BUILT this module" classifier from manifest.origin — the CREDIT axis (ADR 0107 §9). own-built vs core-loaded.
 │   │   ├── catalog.js          ← the browsable module catalog model (ADR 0167 / ADR 0107 §2/§3): `source` (which TREE ships it — core package vs instance, read off the loader's discovery root) + resolved author/origin `credit` with an `inferred` flag. The ONE builder behind both `GET /api/bongos/modules` and `bongos module list --catalog`, so the hall + CLI can't drift.
 │   │   └── semver.js           ← minimal semver `satisfies(version, range)` used by the loader (no npm dep).
-│   ├── platform-server.js       ← GDS-ONLY entrypoint (ADR 0062 R51, task 1190): boots Express + the shared internal surface (API + hall + status) with NO game in the process; the inverse of preview-server.js. `node src/platform-server.js`
+│   ├── platform-server.js       ← BONGOS-ONLY entrypoint (ADR 0062 R51, task 1190): boots Express + the shared internal surface (API + hall + status) with NO game in the process; the inverse of preview-server.js. `node src/platform-server.js`
 │   ├── preview-server.js        ← GAME-ONLY entrypoint for the per-box sandbox (ADR 0052): Phaser/Colyseus + tiles, NO /api/gds
 │   ├── seats.js                 ← in-process seat counter + EventEmitter
 │   ├── rooms/
@@ -404,7 +404,7 @@ To install on a new machine, symlink each routine's directory under `~/.claude/s
 ├── pre-compact.js            ← PreCompact: thin reader around eviction-policy.js — emits an eviction directive (blocks to drop + one-line recovery stubs) at the compaction seam (task 1349)
 ├── eviction-policy.js        ← pure deterministic in-session compaction classifier (transcript turns → eviction set + replacement stubs); no I/O, unit-tested in tests/eviction_policy.mjs; consumed by pre-compact.js (task 1348)
 ├── stop-sound.js             ← Stop: completion sound on macOS (afplay; Glass / Hero on /tmp/otb-celebrate); silent no-op on other OSes
-└── stop-refcheck.js          ← Stop: deterministic backstop that catches a bare `#NNN` GDS ref in live session text (autolinks to a 404 GitHub issue) and asks for the clickable form (follow-on to task 929)
+└── stop-refcheck.js          ← Stop: deterministic backstop that catches a bare `#NNN` Bongos ref in live session text (autolinks to a 404 GitHub issue) and asks for the clickable form (follow-on to task 929)
 ```
 
 (Before [#671](https://example.com/builders#/task/671) these ran via `bash` shims — `sync-env-local.sh`, `conductor.sh`, `onboarding-ship-logs.sh`, `rank-change-greeting.sh`, `pull-memory.sh` — which failed on Windows without Git Bash. The Node entries above replaced them.)

package/docs/modules-contract.md

@@ -79,7 +79,7 @@ Every module must have a `module.json` at its root (`modules/<key>/module.json`)
   "description": "…",                 // REQUIRED. One sentence.
   "coreVersion": "^1.2.0",           // REQUIRED. semver range of CORE_VERSION this module supports.
   "default":     false,               // OPTIONAL (default false). Fail-safe when no config names it.
-  "author":      "…",                 // OPTIONAL. Attribution (ADR 0107 §2) — portable, not a cross-GDS FK.
+  "author":      "…",                 // OPTIONAL. Attribution (ADR 0107 §2) — portable, not a cross-Bongos FK.
   "origin":      "…",                 // OPTIONAL. Origin instance/project this module was built in.
   "license":     "AGPL-3.0",          // OPTIONAL. License this module is offered under.
   "maintainer":  "…",                 // OPTIONAL. Who to credit/contact if this module is upstreamed.
@@ -113,7 +113,7 @@ An unknown key throws at validate time — typos fail loud (top-level attributio
 
 `@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**.
 
-**Attribution (`author`/`origin`/`license`/`maintainer`) is portable metadata, not a cross-GDS link** — each repo runs its own GDS 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/<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.
 
 **`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.
 

package/docs/onboarding/diagrams/README.md

@@ -1,6 +1,6 @@
-# How the GDS works — visual diagrams
+# How Bongos works — visual diagrams
 
-Five flowcharts that explain the Game Development System (GDS) to a new builder at a glance. Each diagram is committed as **Mermaid source** (`.mmd`) plus a rendered **`.svg`** (the crisp, pannable/zoomable asset) and **`.png`** (a static fallback / external-embed image), embedded in the `/builders` hall at `/builders/diagrams` and the builder primer ([V3.R13 / #237](../../../CLAUDE.md)). On those pages the diagrams are **pan-and-zoom canvases** (drag to pan, scroll to zoom, fullscreen) — see [`modules/hall-ui/public/diagram-viewer.js`](../../../modules/hall-ui/public/diagram-viewer.js).
+Five flowcharts that explain Bongos to a new builder at a glance. Each diagram is committed as **Mermaid source** (`.mmd`) plus a rendered **`.svg`** (the crisp, pannable/zoomable asset) and **`.png`** (a static fallback / external-embed image), embedded in the `/builders` hall at `/builders/diagrams` and the builder primer ([V3.R13 / #237](../../../CLAUDE.md)). On those pages the diagrams are **pan-and-zoom canvases** (drag to pan, scroll to zoom, fullscreen) — see [`modules/hall-ui/public/diagram-viewer.js`](../../../modules/hall-ui/public/diagram-viewer.js).
 
 > Built under **V3.R76 ([#295](https://example.com/builders#/task/295))**; auto-regeneration + drift detection added under **[#356](https://example.com/builders#/task/356)/[#357](https://example.com/builders#/task/357)**; conceptual diagrams (03/04) made auto-generated under **[#436](https://example.com/builders#/task/436)**; a dev-box topology diagram (06) added under **[#1031](https://example.com/builders#/task/1031)** and then **merged with 04 into the single `04-architecture` map + SVG pan/zoom viewer under [#1059](https://example.com/builders#/task/1059)**.
 
@@ -11,13 +11,13 @@ Five flowcharts that explain the Game Development System (GDS) to a new builder
 | Diagram | What drives its state |
 |---|---|
 | `01-task-lifecycle` · `02-rank-ladder` · `05-versioning` (**mechanical**) | The task-status set + rank enum/wiring (read from `migrations/` + `src/bongos/`) and the live version set (production API). No auth needed — always regenerate. |
-| `03-example-karma` · `04-architecture` (**conceptual**) | Each feature-piece is **LIVE iff its backing GDS task is `shipped`**, plus 03's "N seeded" count from the achievements seed in `migrations/`. These read the **authenticated** `/tasks/:id` status, so when no GDS session is available (headless run, no creds) the generator **skips** 03/04 and leaves them untouched rather than emit wrong data. (04's device/box/server/GitHub *topology* is structural; only its LIVE/PLANNED markers — the memory chain + the box→prod ship-flow legs — are task-gated.) |
+| `03-example-karma` · `04-architecture` (**conceptual**) | Each feature-piece is **LIVE iff its backing Bongos task is `shipped`**, plus 03's "N seeded" count from the achievements seed in `migrations/`. These read the **authenticated** `/tasks/:id` status, so when no Bongos session is available (headless run, no creds) the generator **skips** 03/04 and leaves them untouched rather than emit wrong data. (04's device/box/server/GitHub *topology* is structural; only its LIVE/PLANNED markers — the memory chain + the box→prod ship-flow legs — are task-gated.) |
 
 The mechanical diagrams regenerate **on every deploy** (`ship.js` / `/merge-mode` run `gen-diagrams.js` before deploying; a changed diagram is committed and shipped automatically). The conceptual diagrams regenerate the same way whenever a session is present (the deploy host has one). The `diagram-drift` routine remains as a belt-and-braces backstop. So `/builders/diagrams` is never more than one deploy behind the live architecture.
 
 ## Reading the diagrams — live vs planned
 
-The GDS is mid-build. These diagrams deliberately distinguish **what exists today** from **what GDS-V3 plans to add**, so they double as a "where are we at" snapshot:
+Bongos is mid-build. These diagrams deliberately distinguish **what exists today** from **what GDS-V3 plans to add**, so they double as a "where are we at" snapshot:
 
 | Marker | Meaning |
 |---|---|

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

@@ -1,6 +1,6 @@
 # Example & karma — how you get paid, and how you earn trust
 
-*The complete reference for the two reputation tracks in the GDS. The [primer](primer.md) gives you the one-paragraph version; this is the full picture, kept honest against the live system. ~8 minutes.*
+*The complete reference for the two reputation tracks in Bongos. The [primer](primer.md) gives you the one-paragraph version; this is the full picture, kept honest against the live system. ~8 minutes.*
 
 > **Source of truth.** The numbers live in the production database (`builders.total_credits`, `builders.karma`) and the rules live in code (`src/bongos/db.js`, `src/bongos/cost.js`). This doc *describes* them; where they disagree, the code wins. The two diagrams that visualize this — [task lifecycle](diagrams/01-task-lifecycle.png) and [example & karma](diagrams/03-example-karma.png) — are auto-generated from the same live facts.
 

package/docs/recipes/README.md

@@ -1,6 +1,6 @@
 # `docs/recipes/` — long-form operational recipes
 
-> **Renamed from `learnings/` in Phase 2b** (2026-05-10). The folder used to hold a mix of long-form guides and short-form rules; the dual-write with the GDS `learnings` table made the split confusing. Now: this folder = long-form recipes (multi-page operational guides); the DB `learnings` table = short-form per-rule learnings (rule + why + how-to-apply).
+> **Renamed from `learnings/` in Phase 2b** (2026-05-10). The folder used to hold a mix of long-form guides and short-form rules; the dual-write with Bongos `learnings` table made the split confusing. Now: this folder = long-form recipes (multi-page operational guides); the DB `learnings` table = short-form per-rule learnings (rule + why + how-to-apply).
 
 This folder holds **things we have already discovered the hard way and need to write up at length**. Read the relevant file before you do similar work, and you will not repeat the discovery.
 

package/docs/recipes/audit-replay.md

@@ -24,7 +24,7 @@ Notably absent — and worth knowing about so you can ask follow-up questions if
 
 - **GET requests** are not in `audit_log` (by design; high volume, low signal). Read patterns aren't part of this replay.
 - **Builder rank changes** show up as `HTTP_PATCH route=/api/gds/builders/:id/rank` rows and as `CREDIT` rows when the rank change carries a example adjustment. The new rank value lives in `audit_log.request_body_redacted`.
-- **Game-server WebSocket events** (movement, world state) live in `world_events` and are NOT included here — this script is GDS-scoped. If a game-side investigation is needed, query `world_events` separately.
+- **Game-server WebSocket events** (movement, world state) live in `world_events` and are NOT included here — this script is Bongos-scoped. If a game-side investigation is needed, query `world_events` separately.
 
 ## Running the script
 

package/docs/recipes/builder-box-lifecycle.md

@@ -26,7 +26,7 @@ none ─provision─▶ active ────────────────
 
 The idle sweep **deprovisions** a box when its `last_activity_at` (else `active_since`) is older than `BOX_IDLE_MINUTES` **and** `claude_active` is not true. Both signals are set by **`infra/box-heartbeat.sh`**, which runs **inside the box** every ~5 min and POSTs `/api/gds/box/heartbeat` *only while the box is in use* — an interactive login session, an established SSH connection, an **open browser terminal** (ttyd websocket, [#1161](https://example.com/builders#/task/1161)), or non-trivial CPU load. Silence = the sweep is free to destroy it.
 
-> ⚠️ **The idle sweep's correctness depends on the box-side heartbeat reaching the server.** If it isn't pinging — no GDS token on the box yet, a pre-[#1161](https://example.com/builders#/task/1161) script that can't see a browser terminal, or the cron not installed — `last_activity_at` never advances and the sweep falls back to `active_since`, i.e. it measures **uptime**, not activity, and will **destroy** a box someone is actively using. Because the idle path is now a full deprovision (no park to wake from), that wrongly-reaped box also loses uncommitted work (spike [#837](https://example.com/builders#/task/837)).
+> ⚠️ **The idle sweep's correctness depends on the box-side heartbeat reaching the server.** If it isn't pinging — no Bongos token on the box yet, a pre-[#1161](https://example.com/builders#/task/1161) script that can't see a browser terminal, or the cron not installed — `last_activity_at` never advances and the sweep falls back to `active_since`, i.e. it measures **uptime**, not activity, and will **destroy** a box someone is actively using. Because the idle path is now a full deprovision (no park to wake from), that wrongly-reaped box also loses uncommitted work (spike [#837](https://example.com/builders#/task/837)).
 >
 > **Live mitigation (2026-06-16):** `BOX_IDLE_MINUTES` is raised to **120** in `/etc/example/box.env` as a soak margin until [#1161](https://example.com/builders#/task/1161)'s browser-terminal heartbeat is verified on a newcomer box; lower it back toward the 10-min default once that's proven.
 
@@ -63,7 +63,7 @@ node scripts/gds/box.js reconcile-drift         # DO⇄DB drift; add --apply to
 
 The teardown is now **confirm-before-destroyed**: `deprovision` only marks a box `destroyed` AFTER DigitalOcean confirms the droplet is deleted (idempotent + retried). A delete that genuinely fails parks the box at `state='error'` with `droplet_id` preserved and **throws** — it never silently leaves a running droplet behind a `destroyed` row (the old "zombie" bug).
 
-`reconcile-drift` is the backstop. It lists the real fleet droplets (a live read — needs `DO_API_TOKEN`, present in `box.env`) and reconciles against the GDS rows **both ways**:
+`reconcile-drift` is the backstop. It lists the real fleet droplets (a live read — needs `DO_API_TOKEN`, present in `box.env`) and reconciles against the Bongos rows **both ways**:
 
 - **Zombie** — a droplet no live box row claims → force-delete the droplet + its tunnel/DNS.
 - **Ghost** — a live row whose `droplet_id` vanished from DO → mark it `destroyed`.

package/docs/recipes/claude-design-loop.md

@@ -12,14 +12,14 @@
 
 - Starting a UI sprint and want Claude Design to prototype from real tokens, not approximations.
 - Tokens or surfaces changed and the Claude Design project is stale.
-- A Claude Design prototype is done and you want to land the generated code as a GDS task.
+- A Claude Design prototype is done and you want to land the generated code as a Bongos task.
 
 ---
 
 ## Prerequisites
 
 - **Rank: Metic+** (design-sync routes are Metic-gated server-side).
-- **Claimed GDS task** — use this for the handoff step. If you're just exporting, no claim is required; a claim is required when you `export()` and commit the generated code.
+- **Claimed Bongos task** — use this for the handoff step. If you're just exporting, no claim is required; a claim is required when you `export()` and commit the generated code.
 - **DesignSync MCP** — the `mcp__DesignSync__*` tools must be available in your session.
 
 ---
@@ -84,11 +84,11 @@ Claude Design can now reference the token cards. Typical workflow:
 
 ---
 
-## 4. Land the handoff as a GDS task
+## 4. Land the handoff as a Bongos task
 
 When Claude Design's output is ready:
 
-**a. Claim a GDS task** (if not already done).
+**a. Claim a Bongos task** (if not already done).
 
 **b. Run the export step** — either via the skill or directly:
 

package/docs/recipes/core-release-pipeline.md

@@ -27,7 +27,7 @@ A change crosses three independent gates. **None of them implies the next**, and
 | **2** | **Released** | a `CORE_VERSION` exists that *contains* the commit, and an artifact was cut from it | a builder bumps + packages; **the owner publishes** | the version is published / a `.tgz` exists |
 | **3** | **Deployed** | a specific instance moved its pin to that version | per instance | that instance's `/version` reports the new `coreVersion` |
 
-The GDS vocabulary collides with gate 1 in a way worth naming: **task status `shipped` means "merged to `main`"** — it does not mean released, and it does not mean live. `ship.js` says so in its own comment and, since task 1002521, prints a divergence warning at the end of every ship.
+Bongos vocabulary collides with gate 1 in a way worth naming: **task status `shipped` means "merged to `main`"** — it does not mean released, and it does not mean live. `ship.js` says so in its own comment and, since task 1002521, prints a divergence warning at the end of every ship.
 
 ---
 

package/docs/recipes/devbox-app-release.md

@@ -46,7 +46,7 @@ releases repo → a one-line config bump re-points the branded
 
 1. Bump `devbox-app/package.json` version (e.g. `1.1.0`) and regenerate
    icons only if they changed (`npm run icons`).
-2. Land the bump on `main` through the normal GDS flow, then wait for
+2. Land the bump on `main` through the normal Bongos flow, then wait for
    `build-devbox-app` to go green **on the `main` run** — that is the run that
    carries the installers.
 3. Download the artifacts (they expire after 3 days — re-run the workflow on
@@ -69,7 +69,7 @@ releases repo → a one-line config bump re-points the branded
 5. Update `config/devbox-app.json`: `version` + the four asset filenames
    (they embed the version — `tests/devbox_downloads.mjs` fails the gate on a
    half-bumped config).
-6. Ship the config change through the normal GDS flow. **Bumping `config/devbox-app.json`
+6. Ship the config change through the normal Bongos flow. **Bumping `config/devbox-app.json`
    `version` is what triggers the in-app update banner in the field ([#924](https://example.com/builders#/task/924))** — running
    apps poll `GET /downloads/devbox/version`, compare it to their own `package.json`
    version with a proper semver compare (`devbox-app/src/updater.js`), and show

package/docs/recipes/devbox-app-windows-test.md

@@ -113,7 +113,7 @@ the Claude Desktop connection file:
 
 ## Recording results
 
-File outcomes against the verification task in the GDS. For any failure
+File outcomes against the verification task in Bongos. For any failure
 grab: the panel state, `%TEMP%`/console output if launched from a terminal
 (`& "$env:LOCALAPPDATA\Programs\OTB Dev Box\OTB Dev Box.exe"` shows logs),
 the relevant PowerShell output from steps 3–4, and a screenshot. The fastest

package/docs/recipes/figma-design-loop.md

@@ -14,14 +14,14 @@
 
 - A designer wants to make a manual edit to a UI surface directly in Figma (the "human escape hatch").
 - Tokens or surfaces changed and the Figma file is stale — push before the designer opens it.
-- A Figma edit is done (via Code Connect or a raw canvas change) and you want to land it as a GDS task.
+- A Figma edit is done (via Code Connect or a raw canvas change) and you want to land it as a Bongos task.
 
 ---
 
 ## Prerequisites
 
 - **Rank: Metic+** for the handoff step (task authoring / commit under a claim).
-- **Claimed GDS task** — required when you `export()` and commit the generated code.
+- **Claimed Bongos task** — required when you `export()` and commit the generated code.
 - **Figma MCP write capability** in your session (`mcp__figma__*` write tools, or `use_figma`). Read-only tools alone are not enough to push. If unavailable, stop and surface the gap rather than faking the push — see `otb-figma-sync`'s own capability check for the same pattern.
 
 ---
@@ -64,9 +64,9 @@ The designer opens the pushed frames (or an existing component) and makes a manu
 
 ---
 
-## 4. Land the edit as a GDS task
+## 4. Land the edit as a Bongos task
 
-**a. Claim a GDS task** (if not already done).
+**a. Claim a Bongos task** (if not already done).
 
 **b. Run the export step.** Figma hands back one of two shapes:
 

package/docs/recipes/gds-db-backup.md

@@ -1,4 +1,4 @@
-# Recipe — GDS DB backup (local nightly + offsite weekly)
+# Recipe — Bongos DB backup (local nightly + offsite weekly)
 
 > **Filed by:** task [#412](https://example.com/builders#/task/412) (V3.R62-precondition, local nightly) + [#415](https://example.com/builders#/task/415) (V3.R62-offsite, weekly offsite archive) — both under [ADR 0024](../adr/<redacted>.md) §5 (backup cadence). Vendor choice for the offsite copy: [ADR 0025](../adr/<redacted>.md) (DigitalOcean Spaces).
 > **Two layers:** a **local daily** `pg_dump` to `/var/backups/gds/` (protects against corruption / bad migration / accidental delete) **plus** a **weekly offsite copy** of the latest local dump to a DigitalOcean Space (protects against whole-droplet loss).
@@ -244,8 +244,8 @@ curl -s https://example.com/api/gds/public/progress | jq '.progress[0]'
 
 ## Limits — what this recipe does NOT cover
 
-1. **Whole-droplet loss window is ~1 week, not zero.** The weekly offsite copy ([#415](https://example.com/builders#/task/415), above) closes the catastrophic-loss gap, but it runs weekly — so in the worst case (droplet dies right before the weekly run) you lose up to ~7 days of writes that made it into the local daily dumps but not yet offsite. Acceptable for the GDS DB's shape; tighten the offsite cadence to daily if that ever stops being true.
-2. **Continuous archiving / PITR is not configured.** A restore brings you back to the most recent nightly snapshot, not the precise moment of failure. Up to 24 hours of writes can be lost in a worst-case restore. That's acceptable for the GDS DB's current shape (work-state ledger, no transactional money flows) but worth revisiting if/when the DB takes on stripe-payment or fulfillment state.
+1. **Whole-droplet loss window is ~1 week, not zero.** The weekly offsite copy ([#415](https://example.com/builders#/task/415), above) closes the catastrophic-loss gap, but it runs weekly — so in the worst case (droplet dies right before the weekly run) you lose up to ~7 days of writes that made it into the local daily dumps but not yet offsite. Acceptable for the Bongos DB's shape; tighten the offsite cadence to daily if that ever stops being true.
+2. **Continuous archiving / PITR is not configured.** A restore brings you back to the most recent nightly snapshot, not the precise moment of failure. Up to 24 hours of writes can be lost in a worst-case restore. That's acceptable for the Bongos DB's current shape (work-state ledger, no transactional money flows) but worth revisiting if/when the DB takes on stripe-payment or fulfillment state.
 3. **No automated alerting on a failed run yet.** The unit emits a non-zero exit on failure, which `systemctl status gds-db-backup.timer` will surface, but nothing pages you. Add a check to the existing `overnight-builder` health surface or the `weekly-security-review` scheduled task if backups silently failing for N days becomes a real concern.
 4. **No automated cadence for the restore drill.** The recipe above is just text until a human (or scheduled task) runs it. [#281](https://example.com/builders#/task/281) R62 is where the formal drill cadence lands.
 

package/docs/recipes/instance-deploy.md

@@ -16,7 +16,7 @@
 1. **`git pull --ff-only origin main`** the *instance* repo — host content only: `config/`, `migrations/instance/`, and the pinned core version in `package.json`.
 2. **`npm ci --omit=dev`** — installs the pinned `@bongos/core` + instance deps. This is what replaces `git reset --hard`: the core is a dependency, so an upgrade is a pin bump + `npm ci`, not a source merge.
 3. **`bash <core>/scripts/migrate.sh`** — the core's **three-root** migrate (W5 / ADR 0108 §5) merges `<core>/migrations` + `<instance>/migrations/instance` + each enabled module's migrations, keyed by namespaced filename stems (`core_NNN_`, `<key>_NNN_`, bare instance) so the two repos never collide. It resolves core-root vs instance-root via `src/instance-config.js`.
-4. **restart the platform** — a systemd unit runs `node <core>/src/platform-server.js` (GDS-only) with `WorkingDirectory` = the instance root (so `resolveInstanceRoot()` resolves to the instance) + `PORT`/`HOST` env; then poll `/healthz`.
+4. **restart the platform** — a systemd unit runs `node <core>/src/platform-server.js` (Bongos-only) with `WorkingDirectory` = the instance root (so `resolveInstanceRoot()` resolves to the instance) + `PORT`/`HOST` env; then poll `/healthz`.
 
 `docker-compose.yml` + `.github/workflows/selfhost-boot.yml` already model this shape (fresh Postgres → `npm ci` → `migrate.sh` → `platform-server`), so the flow is validated end-to-end there.
 

package/docs/recipes/managed-settings-remote-control.md

@@ -69,7 +69,7 @@ Override with `--allow-no-keys` only if you will re-provision once they register
 
 **How the key reaches the box without an operator SSH round-trip:** `box.js` reads the
 builder's registered keys from the DB and **bakes** them into the cloud-init managed
-block at provision (so the first login works before the box has any GDS token). From
+block at provision (so the first login works before the box has any Bongos token). From
 then on, `infra/<redacted>.sh` (a 10-min cron on the box, wired by the
 cloud-init) keeps `authorized_keys` in sync via `GET /box/authorized-keys` — which is
 **gated on the builder's LIVE rank+status** exactly like source access ([#600](https://example.com/builders#/task/600)). A
@@ -178,7 +178,7 @@ The builder opens the tunnel URL in any browser, authenticates at the basic-auth
 
 > **Workspace trust is pre-seeded ([#824](https://example.com/builders#/task/824)).** The cloud-init writes `/root/.claude.json` with `<redacted>` for `/root` + `/workspace`, so the first `claude` launch usually skips the trust dialog entirely. This is **non-load-bearing** (ADR 0040): the seed is best-effort and only written when the file is absent (upstream pre-seeding is flaky, [#9113](https://github.com/anthropics/claude-code/issues/9113)). If it doesn't take, the builder just accepts trust once — the flow works either way.
 
-The cloud-init wires both units automatically (and `infra/box-source-fetch.sh` re-installs them on its post-clone bring-up, so a box provisioned before this shipped picks them up on its next refresh). It copies `infra/box-terminal.service` and `infra/cloudflared.service` to `/etc/systemd/system/`, enables them with `systemctl enable --now`, and wires `infra/box-report-terminal.sh` as a 1-minute cron that publishes the terminal URL + credential **up** to the GDS (`POST /box/terminal`) so the builder's self-serve flow can read them back.
+The cloud-init wires both units automatically (and `infra/box-source-fetch.sh` re-installs them on its post-clone bring-up, so a box provisioned before this shipped picks them up on its next refresh). It copies `infra/box-terminal.service` and `infra/cloudflared.service` to `/etc/systemd/system/`, enables them with `systemctl enable --now`, and wires `infra/box-report-terminal.sh` as a 1-minute cron that publishes the terminal URL + credential **up** to Bongos (`POST /box/terminal`) so the builder's self-serve flow can read them back.
 
 **Tunnel modes:**
 
@@ -210,7 +210,7 @@ Then:
 
 | State | What happens |
 |---|---|
-| Box first boots | `box-terminal.service` (ttyd) + `cloudflared.service` start; `box-report-terminal` cron publishes the URL + credential to the GDS within ~1 min |
+| Box first boots | `box-terminal.service` (ttyd) + `cloudflared.service` start; `box-report-terminal` cron publishes the URL + credential to Bongos within ~1 min |
 | Builder connects (first time) | Opens the tunnel URL, basic-auths as `otb`, runs `claude` (one-time browser `/login`), then `/remote-control` to get a pairing link and drive the box from the Claude app (ADR 0040) |
 | Builder works (each session) | Lives in the Claude web/mobile app via the RC link; the ttyd terminal is only the launchpad they logged in through |
 | Session ends | Builder closes the browser tab; the terminal + tunnel stay up for the next visit |
@@ -229,7 +229,7 @@ journalctl -u cloudflared -n 100         # last 100 lines
 sudo systemctl restart box-terminal cloudflared
 ```
 
-The quick-tunnel hostname is printed in the `cloudflared` journal; the same value is published to the GDS by the `box-report-terminal` cron (verify with `crontab -l | grep box-report-terminal`).
+The quick-tunnel hostname is printed in the `cloudflared` journal; the same value is published to Bongos by the `box-report-terminal` cron (verify with `crontab -l | grep box-report-terminal`).
 
 ### Named-tunnel automation (control plane, [#771](https://example.com/builders#/task/771))
 
@@ -293,7 +293,7 @@ The build is unit- and smoke-covered, but the loop crosses real hardware + a hum
 
 - **Packaged ttyd collision (fixed).** The Ubuntu `ttyd` apt package ships its OWN auto-started `ttyd.service` that binds `127.0.0.1:7681` with **no `--credential`** and runs `login`. It both blocks our `box-terminal.service` (the unit crash-loops on `EADDRINUSE`) and — because the tunnel fronts whatever sits on 7681 — would expose an **unauthenticated** terminal. Cloud-init and the `box-source-fetch` post-clone bring-up now `systemctl mask ttyd` so only our basic-auth ttyd binds the port. On a box provisioned before this fix: `sudo systemctl disable --now ttyd && sudo systemctl mask ttyd && sudo systemctl restart box-terminal`.
 - **IPv4-only Cloudflare calls (fixed).** The CF API token is IP-locked to the droplet's IPv4 (least privilege). The droplet also has IPv6 egress; `cf-tunnel.js` pins IPv4 (undici `Agent{connect:{family:4}}`) or every call 401s — mirroring `box-dns-cloudflare.sh`'s `curl -4`.
-- **⚠ Browser-only bootstrap gap (OPEN — follow-up).** The `ttyd`/`cloudflared` systemd units live in the repo (`/workspace/infra/*.service`), so they only start **after** `box-source-fetch` clones — which needs the **builder's GDS token on the box**. A pure Chromebook builder has no SSH and no terminal yet, so there is **no first-boot path to place that token** → the terminal never comes up for them. Today it only works if the token is seeded another way (SSH, or an operator). The fix (a follow-up) is to bring ttyd up at **first boot independent of the clone** — e.g. cloud-init writes the unit inline rather than copying it from the repo. Until then, the browser on-ramp is verified to work *given a token on the box*, not from a truly bare browser-only device.
+- **⚠ Browser-only bootstrap gap (OPEN — follow-up).** The `ttyd`/`cloudflared` systemd units live in the repo (`/workspace/infra/*.service`), so they only start **after** `box-source-fetch` clones — which needs the **builder's Bongos token on the box**. A pure Chromebook builder has no SSH and no terminal yet, so there is **no first-boot path to place that token** → the terminal never comes up for them. Today it only works if the token is seeded another way (SSH, or an operator). The fix (a follow-up) is to bring ttyd up at **first boot independent of the clone** — e.g. cloud-init writes the unit inline rather than copying it from the repo. Until then, the browser on-ramp is verified to work *given a token on the box*, not from a truly bare browser-only device.
 
 ---
 
@@ -317,13 +317,13 @@ If missing (pre-[#599](https://example.com/builders#/task/599) box):
 ## Part 4 — Rank-gated source access ([#600](https://example.com/builders#/task/600), ADR 0031 §6 / §9.2)
 
 The box holds **no baked credential**. Instead it fetches a rank-scoped clone spec
-from the GDS at boot and on a 10-minute cron, via `infra/box-source-fetch.sh`
+from Bongos at boot and on a 10-minute cron, via `infra/box-source-fetch.sh`
 (carried onto the box as base64 inside the cloud-init `write_files`). The flow:
 
-1. The box reads the builder's GDS session token (it appears after they authenticate
+1. The box reads the builder's Bongos session token (it appears after they authenticate
    Claude Code / run `/builder-reauth` — so the **first clone lands after the builder
    connects**, not at boot).
-2. It calls `GET /api/gds/box/source-access`. The GDS checks the builder's **live**
+2. It calls `GET /api/gds/box/source-access`. Bongos checks the builder's **live**
    rank + status (ADR 0016 — unforgeable from the box):
    - **403 `SOURCE_ACCESS_REVOKED`** — builder demoted below the floor or deactivated.
      The script cuts the credentialed remote (box-side clawback); `box.js reconcile`
@@ -399,7 +399,7 @@ bash infra/gen-managed-settings.sh alice > /tmp/alice-managed-settings.json
 
 # 4. For thin-device (Chromebook) path: the web terminal is ready automatically
 #    (box-terminal.service + cloudflared.service start at boot; box-report-terminal
-#    publishes the URL + credential to the GDS within ~1 min)
+#    publishes the URL + credential to Bongos within ~1 min)
 #    Builder self-serves: POST /api/gds/box/ensure, then poll GET /api/gds/box/terminal
 #    -> open the url, basic-auth as user 'otb' with the returned credential, run: claude
 #    -> then /remote-control to drive the box from the Claude app (ADR 0040)

package/docs/recipes/ops-gotchas.md

@@ -167,7 +167,7 @@ Organized by topic, not chronology. New entries go in the matching section; crea
 
 ---
 
-## GDS build pipeline
+## Bongos build pipeline
 
 ### Two deterministic routines run as in-process server timers, not external cron
 
@@ -221,7 +221,7 @@ Organized by topic, not chronology. New entries go in the matching section; crea
 
 - **Symptom:** the site is down for hours, but The Watch still shows 100% / "standing".
 - **Root cause:** `status.example.com` is served by the same Node process on the same droplet as the game, and the in-process poller (`src/bongos/uptime-poller.js`) probes `127.0.0.1`. When the droplet dies, the page dies with it and the poller writes **zero rows** — the gap renders as green. A monitor that lives inside the monitored thing cannot witness its own death.
-- **Fix:** measure availability from **outside** (the external GitHub-Actions prober — `.github/workflows/status-probe.yml`, task [#565](https://example.com/builders#/task/565)) and host the status page **off-box** (follow-up [#566](https://example.com/builders#/task/566)). See [ADR 0029](../adr/<redacted>.md) + GDS learning `#35`.
+- **Fix:** measure availability from **outside** (the external GitHub-Actions prober — `.github/workflows/status-probe.yml`, task [#565](https://example.com/builders#/task/565)) and host the status page **off-box** (follow-up [#566](https://example.com/builders#/task/566)). See [ADR 0029](../adr/<redacted>.md) + Bongos learning `#35`.
 - **Why it bites:** a status page that lies is worse than none — it actively reassures you while the product is on fire.
 
 ### The live status page is NOT served by the droplet — editing the status surface + deploying does nothing

package/docs/recipes/overnight-builder.md

@@ -4,9 +4,9 @@
 
 ## What it does
 
-Starts one session that works the GDS queue **by priority, on its own**. It claims the highest-priority safe task, works it in a fresh sub-agent, ships it, then re-polls the claimable list — the promote-on-ship DB trigger (migration 020) self-feeds the queue, so as soon as one task ships the next unblocked one is waiting. It loops until nothing claimable remains, the time budget runs out, or the cost cap is hit.
+Starts one session that works the Bongos queue **by priority, on its own**. It claims the highest-priority safe task, works it in a fresh sub-agent, ships it, then re-polls the claimable list — the promote-on-ship DB trigger (migration 020) self-feeds the queue, so as soon as one task ships the next unblocked one is waiting. It loops until nothing claimable remains, the time budget runs out, or the cost cap is hit.
 
-It only ever touches tasks the GDS marks safe to run unattended (`automation_tag = 'overnight-safe'`, `manual_degree <= 2`, unblocked). Nothing broken reaches `main`: the quality grader gates credits and the auto-merge re-runs smoke tests and bails (parking the task) on any conflict or failure.
+It only ever touches tasks Bongos marks safe to run unattended (`automation_tag = 'overnight-safe'`, `manual_degree <= 2`, unblocked). Nothing broken reaches `main`: the quality grader gates credits and the auto-merge re-runs smoke tests and bails (parking the task) on any conflict or failure.
 
 ## Start it (serial — the proven path)
 

package/docs/recipes/packaging-the-core.md

@@ -60,5 +60,5 @@ The manifest's `files[]` carries the same `{ path, mode, sha256 }` triples, so t
 ## Boundaries + relation to the mirror
 
 - **Not the public mirror.** The delayed, redacted, ~6-month-lagged public mirror ([ADR 0099](../adr/<redacted>.md)) is the open-source surface. This artifact is a *current*, versioned unit for **dependency consumption** by a sister repo — no lag. Both reuse the same `isPublishable()` selection and the same redaction; `package-core.js` imports the mirror's `redactBlob` so the redaction logic is defined once.
-- **Per-repo GDS.** Each instance runs its own database, tasks, builders, and credits ([ADR 0100 §3](../adr/<redacted>.md)). Packaging the core moves *code*, never work-tracking state.
+- **Per-repo Bongos.** Each instance runs its own database, tasks, builders, and credits ([ADR 0100 §3](../adr/<redacted>.md)). Packaging the core moves *code*, never work-tracking state.
 - **The single-checkout instance model is not deprecated** — it stays the cheaper shape for a quick reskin (cloudbongos.com). Two-repo is the destination for a project that wants to be its own thing and pull core updates on its own schedule.

package/docs/recipes/search-index-ingestion.md

@@ -1,4 +1,4 @@
-# Recipe — GDS search-index ingestion (repo markdown)
+# Recipe — Bongos search-index ingestion (repo markdown)
 
 How the `search_chunks` index (the recall layer, [ADR 0060](../adr/0060-gds-retrieval-layer.md)) gets populated from repo markdown, and how to operate it. Read before touching `scripts/gds/search-ingest-md.js` or the deploy hook.
 
@@ -26,7 +26,7 @@ node scripts/gds/search-ingest-md.js --dry-run
 
 # Full ingest (writes to search_chunks). Idempotent — safe to re-run; unchanged
 # chunks are skipped. Run on the droplet (DB on the local socket) or anywhere the
-# GDS Postgres env (PGHOST/PGDATABASE) resolves.
+# Bongos Postgres env (PGHOST/PGDATABASE) resolves.
 node scripts/gds/search-ingest-md.js
 
 # Initial backfill after first deploy of the recall layer: just run the full
@@ -62,6 +62,6 @@ journalctl -u search-index-db.service -n 20 --no-pager # check the run
 
 ## Gotchas
 
-- **`node` must be on PATH** in the deploy shell (it is — systemd runs the app via node). The script connects via the shared `src/db.js` pool (the same Postgres the app uses), so it needs the GDS env, not a token.
+- **`node` must be on PATH** in the deploy shell (it is — systemd runs the app via node). The script connects via the shared `src/db.js` pool (the same Postgres the app uses), so it needs Bongos env, not a token.
 - **The index lags the merge by one deploy** for any doc changed in a PR that doesn't itself trigger a deploy — acceptable; the deploy hook re-indexes on every prod deploy, and the [staleness monitor + /watch tile](https://example.com/builders) (`#972`) surfaces a stalled index.
 - **Don't lower the chunk size** without re-checking the eval set ([#939](https://example.com/builders#/task/939)) — chunk granularity affects recall quality and (later) embedding cost.

package/docs/recipes/self-host.md

@@ -10,7 +10,7 @@ Bring up a vanilla Cloud Bongos instance — the build platform + builders' hall
 docker compose up
 ```
 
-That builds the image, starts Postgres, applies the build-system migrations (game-module migrations are skipped — this is a GDS-only instance), and serves the builders' hall at **http://localhost:3000**.
+That builds the image, starts Postgres, applies the build-system migrations (game-module migrations are skipped — this is a Bongos-only instance), and serves the builders' hall at **http://localhost:3000**.
 
 - The instance is **vanilla** by default: the neutral Cloud Bongos brand, every feature module (game, art pipeline, Discord, dev boxes) **off**. `.dockerignore` keeps the host's `config/branding.json` and `config/modules.json` out of the image, so it resolves to `config/branding.neutral.json` + `config/modules.neutral.json`.
 - **No OTB scope-truth is seeded.** OTB/product data (game versions, goals, done-when criteria) lives in opt-in seed migrations under `migrations/instance/` (plus a few guarded blocks in the mixed files 003/006). `scripts/migrate.sh` skips them unless `GDS_APPLY_INSTANCE_SEEDS=1`, so a fresh DB comes up with only the schema and platform-universal defaults (ranks, achievements) — no crash, no foreign-key failures, no leftover versions. Platform system principals (`bfg-system`, `discord-bot-system`) are generic and remain. See task 1704 / [ADR 0105](../adr/<redacted>.md).
@@ -51,7 +51,7 @@ Author `config/branding.json` from the neutral starter — see [the branding con
 
 ## What the image contains
 
-- `node src/platform-server.js` — the GDS-only entrypoint (no Colyseus, no game rooms, no game assets).
+- `node src/platform-server.js` — Bongos-only entrypoint (no Colyseus, no game rooms, no game assets).
 - `postgresql-client` (for `scripts/migrate.sh`) + `tini` as PID 1.
 - Runs as the unprivileged `node` user; a `HEALTHCHECK` polls `/healthz`.
 

package/docs/recipes/work-on-a-task-from-your-dev-box.md

@@ -48,7 +48,7 @@ spec. Lose the claim or a rank, and the next fetch is cut off at the server.
 
 If you haven't yet, run **`/builder-connect`** (or follow the
 [dev-box lifecycle recipe](builder-box-lifecycle.md)) to raise and connect to your
-box, then **`/builder-setup`** once on the box to sign the GDS CLI in. The browser
+box, then **`/builder-setup`** once on the box to sign the Bongos CLI in. The browser
 terminal drops you into `/workspace` — the one working folder.
 
 > **`bongos shell` / `bongos code` re-scope on connect (BV1.R101).** Connecting with

package/docs/research/llm-model-agnostic-and-cheaper-grader.md

@@ -182,7 +182,7 @@ The grader is the **single best place to spend a cheaper model**, for three reas
 
 ## 6. Recommended sequence (what to build, in order)
 
-🔧 This mirrors ADR 0089's "Implementation (task-pending)" staging, pinned to the files this audit found. Each step is a candidate GDS task; each is behind a flag and ships without destabilizing the live gate.
+🔧 This mirrors ADR 0089's "Implementation (task-pending)" staging, pinned to the files this audit found. Each step is a candidate Bongos task; each is behind a flag and ships without destabilizing the live gate.
 
 | # | Step | Primary files | Behavior change | Owner cost ask |
 |---|---|---|---|---|

package/modules/platform-identity/platform-identity.js

@@ -423,21 +423,40 @@ async function upsertActivity({ clientId, githubId, credits = 0, tasksShipped =
 // The scouting rollup: one row PER BUILDER, aggregated across every project they
 // build on. Joined to the account for display. Ranked by total credits then ships —
 // a talent signal, NOT an authority. Powers the Archon-only scouting view (#1002114).
+//
+// The scalar aggregates MUST see exactly one row per (builder, project): joining
+// unnest(disciplines) before GROUP BY multiplied every activity row by the number
+// of disciplines on it, inflating project_count and the credits/ships/karma sums
+// (task 1002911). So scalars aggregate in `agg` over the un-fanned table, and the
+// disciplines union is computed separately in `disc`. Proven against real SQL by
+// tests/scouting_rollup_fanout.mjs.
 async function listScoutingRollup({ limit = 100, pool = defaultPool } = {}) {
   const { rows } = await pool.query(
-    `SELECT a.github_id,
+    `WITH agg AS (
+       SELECT a.github_id,
+              count(*)::int             AS project_count,
+              sum(a.credits)::int       AS total_credits,
+              sum(a.tasks_shipped)::int AS total_tasks_shipped,
+              sum(a.karma)::int         AS total_karma,
+              max(a.last_active)        AS last_active
+         FROM platform_identity_builder_project_activity a
+        GROUP BY a.github_id
+     ), disc AS (
+       SELECT x.github_id, array_agg(DISTINCT x.d) AS disciplines
+         FROM (SELECT a.github_id, unnest(a.disciplines) AS d
+                 FROM platform_identity_builder_project_activity a) x
+        WHERE x.d IS NOT NULL
+        GROUP BY x.github_id
+     )
+     SELECT agg.github_id,
             acc.github_login, acc.display_name, acc.avatar_url,
-            count(*)::int                        AS project_count,
-            sum(a.credits)::int                  AS total_credits,
-            sum(a.tasks_shipped)::int            AS total_tasks_shipped,
-            sum(a.karma)::int                    AS total_karma,
-            max(a.last_active)                   AS last_active,
-            array_agg(DISTINCT d) FILTER (WHERE d IS NOT NULL) AS disciplines
-       FROM platform_identity_builder_project_activity a
-       LEFT JOIN platform_identity_accounts acc ON acc.github_id = a.github_id
-       LEFT JOIN LATERAL unnest(a.disciplines) AS d ON true
-      GROUP BY a.github_id, acc.github_login, acc.display_name, acc.avatar_url
-      ORDER BY total_credits DESC, total_tasks_shipped DESC
+            agg.project_count, agg.total_credits, agg.total_tasks_shipped,
+            agg.total_karma, agg.last_active,
+            disc.disciplines
+       FROM agg
+       LEFT JOIN platform_identity_accounts acc ON acc.github_id = agg.github_id
+       LEFT JOIN disc ON disc.github_id = agg.github_id
+      ORDER BY agg.total_credits DESC, agg.total_tasks_shipped DESC
       LIMIT $1`,
     [limit],
   );