@bongos/core 1.19.804 → 1.19.805

package/.claude/skills/ask-for-help/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Ask a named builder or a craft for help on a task, as a filed collab help request. Triggers: "ask <builder> to help with task N", "get <name> on this", "who can help with N", "I'm stuck on task N", "/ask-for-help".
 ---
 
-**Route skill (authoritative).** The core action is `POST /api/gds/help-requests`. Once the addressee and the context are settled, file it and report the id — do not narrate the API.
+**Route skill (authoritative).** The core action is `POST /api/bongos/help-requests`. Once the addressee and the context are settled, file it and report the id — do not narrate the API.
 
 You are asking a *person* for help on behalf of the current builder. Being asked assigns them nothing: the collab surfaces recommend, they never transfer a claim (ADR 0187 §3). Declining costs them nothing.
 
@@ -26,7 +26,7 @@ They are **complementary, not alternatives.** An owner-only task (a credential r
 
 1. **Resolve the addressee to an id — never guess one.**
    ```bash
-   node scripts/gds/api.js GET /api/gds/builders/directory
+   node scripts/gds/api.js GET /api/bongos/builders/directory
    ```
    Match the `github_login` or `display_name` the user named. A name with no match is a question for the user, not a guess — a wrong `needs_builder_id` sends the ask to a stranger.
 
@@ -47,7 +47,7 @@ They are **complementary, not alternatives.** An owner-only task (a credential r
 
 4. **File it.** Write the body to a file first — `api.js` silently drops a positional JSON body:
    ```bash
-   node scripts/gds/api.js POST /api/gds/help-requests --body-file <path>.json
+   node scripts/gds/api.js POST /api/bongos/help-requests --body-file <path>.json
    ```
    ```json
    { "needs_builder_id": 3, "task_id": 1002068, "what_is_stuck": "..." }
@@ -58,9 +58,9 @@ They are **complementary, not alternatives.** An owner-only task (a credential r
 
 6. **Settle it when it resolves** — only the asker can, and an unsettled pile is noise:
    ```bash
-   node scripts/gds/api.js PATCH /api/gds/help-requests/<id> --body-file <path>.json
+   node scripts/gds/api.js PATCH /api/bongos/help-requests/<id> --body-file <path>.json
    ```
-   `{"status": "answered"}` when someone helped, `{"status": "withdrawn"}` when it is no longer needed. Check yours with `GET /api/gds/help-requests/mine`.
+   `{"status": "answered"}` when someone helped, `{"status": "withdrawn"}` when it is no longer needed. Check yours with `GET /api/bongos/help-requests/mine`.
 
 ## Constraints
 
@@ -70,5 +70,5 @@ They are **complementary, not alternatives.** An owner-only task (a credential r
 
 ## Files this skill touches
 
-- Calls: `GET /api/gds/builders/directory`, `POST /api/gds/help-requests`, `GET /api/gds/help-requests/{for-me,mine}`, `PATCH /api/gds/help-requests/:id`
+- Calls: `GET /api/bongos/builders/directory`, `POST /api/bongos/help-requests`, `GET /api/bongos/help-requests/{for-me,mine}`, `PATCH /api/bongos/help-requests/:id`
 - Reads: `modules/lifecycle/routes/help-requests.js` (the four routes), `modules/lifecycle/help-requests.js` (the validation rules), ADR 0187 §3 (recommend, never transfer)

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

@@ -38,7 +38,7 @@ just can't say go on it.
 
 **Enforce the gate at the top of the session, before reading the queue:**
 
-1. Call `GET /api/gds/me` and read `builder.rank`. Compare case-insensitively.
+1. Call `GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively.
 2. **If `rank` lowercases to `xenos` or `thetes`** → stop immediately. Tell the
    builder: *"Backlog review is a Metic+ operation — promoting a task puts it in
    the claimable queue for everyone and sets its price. You can still file work;

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

@@ -10,14 +10,14 @@ This is the structural cure for the old "task #3 sat in `blocked` for days becau
 
 ## Rank gate — Metic+ only
 
-This skill is **gated to Metic and above** (Metic, Archon). It is **not** available to Xenos, the lowest rank. Resolving a blocker auto-promotes every linked task from `blocked` → `ready` via the BEFORE-UPDATE trigger — that's a write that reshapes what the whole team can claim next, so it's a trusted-builder operation. A Xenos can still **file** a blocker (`POST /api/gds/blockers`) — that path stays open to any authenticated builder — they just can't resolve or link them.
+This skill is **gated to Metic and above** (Metic, Archon). It is **not** available to Xenos, the lowest rank. Resolving a blocker auto-promotes every linked task from `blocked` → `ready` via the BEFORE-UPDATE trigger — that's a write that reshapes what the whole team can claim next, so it's a trusted-builder operation. A Xenos can still **file** a blocker (`POST /api/bongos/blockers`) — that path stays open to any authenticated builder — they just can't resolve or link them.
 
 This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`), which names "blocker review" explicitly as a Metic privilege alongside full claim/ship, idea triage, and planning/priority sessions (see [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md) and [ADR 0018](../../../docs/adr/0018-three-rank-model-goes-live.md)).
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 
-1. Call `GET /api/gds/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
-2. **If `rank` is present and lowercases to `xenos`** → stop immediately. Tell the builder: *"Blocker review is a Metic+ operation — resolving a blocker auto-promotes every task linked to it, which reshapes the whole team's ready queue. You're currently Xenos. You can still file a new blocker via `POST /api/gds/blockers`; ask an Archon to promote you if you need to resolve them."* Do not list open blockers, do not propose resolutions.
+1. Call `GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
+2. **If `rank` is present and lowercases to `xenos`** → stop immediately. Tell the builder: *"Blocker review is a Metic+ operation — resolving a blocker auto-promotes every task linked to it, which reshapes the whole team's ready queue. You're currently Xenos. You can still file a new blocker via `POST /api/bongos/blockers`; ask an Archon to promote you if you need to resolve them."* Do not list open blockers, do not propose resolutions.
 3. **If `rank` lowercases to `metic` or `archon`** → proceed with the steps below.
 4. **If `rank` is absent** (the GET /me response has no `rank` field — only possible against a deployment where the three-rank model hasn't shipped yet): treat the session as available, exactly as `/planning-session` and `/priority-session` do in their pre-rank passthrough mode. Note in the session log that the gate ran in pre-rank passthrough mode.
 
@@ -25,16 +25,16 @@ This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`), which names "b
 
 ## What this skill does
 
-1. Lists open blockers via `GET /api/gds/blockers`.
+1. Lists open blockers via `GET /api/bongos/blockers`.
 2. For each, prompts: **resolved**, **still blocked** (with brief status update), or **escalate** (surface to Lars or generate an external ask).
-3. Resolves accordingly via `POST /api/gds/blockers/:id/resolve`. The trigger handles the linked-task flip.
+3. Resolves accordingly via `POST /api/bongos/blockers/:id/resolve`. The trigger handles the linked-task flip.
 
 ## How to use
 
 **Step 1 — fetch open blockers.**
 
 ```
-node scripts/gds/api.js GET /api/gds/blockers
+node scripts/gds/api.js GET /api/bongos/blockers
 ```
 
 (No auth needed — `/blockers` is read-public so the build dashboard can show what's stuck on Lars. `api.js` is the cross-platform Bongos API helper — runs on Windows/macOS/Linux, unlike the old `curl | python3` form.)
@@ -59,7 +59,7 @@ Then ask the user (concise, plain-language; Lars is the prompter — frame aroun
 (api.js signs the request with your session token automatically):
 
 ```
-node scripts/gds/api.js POST /api/gds/blockers/<id>/resolve --body '{"resolution_note":"<one-line summary>"}'
+node scripts/gds/api.js POST /api/bongos/blockers/<id>/resolve --body '{"resolution_note":"<one-line summary>"}'
 ```
 
 (If the note has characters awkward to quote in your shell, write the JSON to a temp file and use `--body-file <path>` instead.)

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

@@ -16,8 +16,8 @@ A blocker that "needs the owner's hands" (a Cloudflare login, a billing change,
 
 Resolving a blocker auto-promotes every task linked to it — a write that reshapes the whole team's `ready` queue — so this is a trusted-builder operation, gated to **Metic and Archon** (not Xenos). Enforce it at the very top, before reading anything else:
 
-1. Call `node scripts/gds/api.js GET /api/gds/me` and read `builder.rank`. Lowercase before testing.
-2. **If `rank` lowercases to `xenos`** → stop immediately: *"Blocker-solve is a Metic+ operation — resolving a blocker auto-promotes every task linked to it. You're currently Xenos. You can still **file** a blocker (`POST /api/gds/blockers`); ask an Archon to promote you if you need to solve them."* Do not read the blocker or propose a fix.
+1. Call `node scripts/gds/api.js GET /api/bongos/me` and read `builder.rank`. Lowercase before testing.
+2. **If `rank` lowercases to `xenos`** → stop immediately: *"Blocker-solve is a Metic+ operation — resolving a blocker auto-promotes every task linked to it. You're currently Xenos. You can still **file** a blocker (`POST /api/bongos/blockers`); ask an Archon to promote you if you need to solve them."* Do not read the blocker or propose a fix.
 3. **If `rank` lowercases to `metic` or `archon`** → proceed.
 4. **If `rank` is absent** (pre-rank deployment) → proceed in passthrough mode, exactly as `/blocker-review` does, and note it.
 
@@ -38,12 +38,12 @@ These are what keep a "solve" honest. Violating them turns a helpful session int
 Read the blocker fully, then enrich it:
 
 ```
-node scripts/gds/api.js GET /api/gds/blockers/<id>
+node scripts/gds/api.js GET /api/bongos/blockers/<id>
 ```
 
 Fields: `title`, `body_md` (often already contains a numbered "Steps (owner): …" plan — lean on it), `source`, `source_ref`, `status`, plus `blocking_task_ids` (task 1002459 — the detail route now hydrates the same array the list view returns). These linked tasks are exactly what will auto-promote when you resolve.
 
-- Read any linked task's notes (`GET /api/gds/tasks/<task-id>`) — the source task usually explains what "done" means.
+- Read any linked task's notes (`GET /api/bongos/tasks/<task-id>`) — the source task usually explains what "done" means.
 - Pull project knowledge so you're not re-deriving: `node scripts/gds/recall.js "<the blocker's topic>"` (add `--kind doc` for ADRs/recipes). This surfaces the ADR, recipe, or past session that already documents how to do this thing.
 
 If the blocker is already `status: resolved`, stop — there's nothing to solve; tell the user and exit.
@@ -77,7 +77,7 @@ If verification **fails or is impossible and the owner won't attest**, do **not*
 Once verified, resolve it. Write the note as *what unblocked it + how you verified* — that's the durable audit trail. Use a temp file to dodge shell-quoting:
 
 ```
-node scripts/gds/api.js POST /api/gds/blockers/<id>/resolve --body-file <path-to-note.json>
+node scripts/gds/api.js POST /api/bongos/blockers/<id>/resolve --body-file <path-to-note.json>
 ```
 
 where the file is `{ "resolution_note": "<what was done> — verified via <how>." }`.

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

@@ -40,7 +40,7 @@ verdict the queue.
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 
-1. Call `GET /api/gds/me` and read `builder.rank`. Compare case-insensitively.
+1. Call `GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively.
 2. **If `rank` lowercases to `xenos` or `thetes`** → stop immediately. Tell the
    builder: *"Bug triage is a Metic+ operation — merging or dismissing a bug
    report reshapes the team's backlog. File new bugs via Discord `#bugs`;
@@ -56,7 +56,7 @@ verdict the queue.
 
 ## What this skill does
 
-1. Lists open `kind=bug` tasks via `GET /api/gds/tasks?kind=bug&limit=1000`,
+1. Lists open `kind=bug` tasks via `GET /api/bongos/tasks?kind=bug&limit=1000`,
    filtered to the still-open statuses (`backlog`, `ready`, `active`,
    `blocked`, `completed`, `confirmed` — never `shipped` or `abandoned`,
    the latter of which already includes merged-away duplicates).
@@ -70,8 +70,8 @@ verdict the queue.
 3. For each remaining bug, prompts the user with: **merge** (this is the same
    report as task N) or **won't-fix** (not a bug / already fixed / can't
    reproduce — closes the report itself, folds into nothing).
-4. Applies each verdict via `POST /api/gds/tasks/:id/merge` or
-   `POST /api/gds/tasks/:id/abandon`.
+4. Applies each verdict via `POST /api/bongos/tasks/:id/merge` or
+   `POST /api/bongos/tasks/:id/abandon`.
 
 **No "promote" step, unlike `/idea-triage`.** A bug report is already a task —
 there is no shape question (goal vs criterion vs task) to work out, because
@@ -84,7 +84,7 @@ report" and "should this report be closed at all".
 **Step 1 — fetch open bug tasks.**
 
 ```
-node scripts/gds/api.js GET "/api/gds/tasks?kind=bug&limit=1000"
+node scripts/gds/api.js GET "/api/bongos/tasks?kind=bug&limit=1000"
 ```
 
 Filter client-side to the open statuses above. If nothing remains, print "bug
@@ -140,7 +140,7 @@ implementation):
 report into it:
 
 ```
-node scripts/gds/api.js POST /api/gds/tasks/<id>/merge --body '{"into_task_id":<N>,"reason":"same report as #N"}'
+node scripts/gds/api.js POST /api/bongos/tasks/<id>/merge --body '{"into_task_id":<N>,"reason":"same report as #N"}'
 ```
 
 The server refuses a self-merge (`merge_self`), a shipped source
@@ -154,7 +154,7 @@ instead of re-merging).
 reproduce):
 
 ```
-node scripts/gds/api.js POST /api/gds/tasks/<id>/abandon --body '{"reason":"cannot reproduce on current build"}'
+node scripts/gds/api.js POST /api/bongos/tasks/<id>/abandon --body '{"reason":"cannot reproduce on current build"}'
 ```
 
 **Keep open** is implicit — leave the task un-patched by not calling either

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

@@ -10,7 +10,7 @@ You are claiming a task on behalf of the current builder. The claim is atomic
 
 ## What this skill does
 
-Runs `node scripts/gds/claim.js <task-id> [--worktree NAME]`. Before it hits the API at all, the CLI enforces **worktree-per-claim locally** (task 1002579 — see below). Then it hits `POST /api/gds/claims`, which transactionally:
+Runs `node scripts/gds/claim.js <task-id> [--worktree NAME]`. Before it hits the API at all, the CLI enforces **worktree-per-claim locally** (task 1002579 — see below). Then it hits `POST /api/bongos/claims`, which transactionally:
 
 1. Verifies the task exists and is `ready`.
 2. Verifies all declared `dependencies[]` are in `shipped` status (V3.R02 / migration 020).
@@ -24,7 +24,7 @@ Any failure mode comes back as a JSON error code (`TASK_NOT_FOUND`, `TASK_NOT_RE
 
 A CLI session may hold **at most one active claim at a time**, and that claim should run in its **own dedicated worktree**. This is structural, not a style preference: working two tasks from one worktree lands every commit on the single branch that worktree owns, so `/builder-ship` publishes the whole branch and drags the other task's commits into the wrong ship (a *commingled ship*). One claim → one worktree → one clean branch keeps every ship isolated.
 
-The server now **enforces** the one-claim half (task 1642): `POST /api/gds/claims` refuses a second claim when the **same session** already holds an active one, returning `409 session_already_has_active_claim` (the body names the in-flight task id + title). This is session-scoped (a builder may still run several sessions in parallel, each with its own worktree and its own single claim) and fail-closed. So the **default claim flow must put the task in a fresh worktree** — never reuse a worktree that already owns a claim.
+The server now **enforces** the one-claim half (task 1642): `POST /api/bongos/claims` refuses a second claim when the **same session** already holds an active one, returning `409 session_already_has_active_claim` (the body names the in-flight task id + title). This is session-scoped (a builder may still run several sessions in parallel, each with its own worktree and its own single claim) and fail-closed. So the **default claim flow must put the task in a fresh worktree** — never reuse a worktree that already owns a claim.
 
 **One-claim-per-session is NOT "only one task at a time."** To work several tasks in parallel you have two supported paths, and the CLI refusal now names both (task 1476): (a) open a **separate worktree/session per task** — each holds its own single claim and ships its own clean branch; or (b) use the **hall work board's multi-select bulk-claim** to claim a set at once. Over-claiming is still discouraged — a pile of slow, unfinished claims blocks others and the stale-claim sweep auto-releases idle ones — but the limit is one claim *per session*, not one task *per builder*.
 
@@ -87,4 +87,4 @@ The server now **enforces** the one-claim half (task 1642): `POST /api/gds/claim
 ## Files this skill touches
 
 - Reads: `~/.config/otb/gds-session.json`
-- Calls: `POST /api/gds/claims`
+- Calls: `POST /api/bongos/claims`

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

@@ -12,7 +12,7 @@ You are logging a cost entry on behalf of the current builder. Bongos keeps a ru
 
 Runs `node scripts/gds/cost.js <amount-usd> <category> [--task-id N] [--description "..."] [--source "..."] [--skill <name>]`.
 
-The CLI hits `POST /api/gds/cost`, which inserts a `cost_log` row.
+The CLI hits `POST /api/bongos/cost`, which inserts a `cost_log` row.
 
 ## How to use
 
@@ -45,4 +45,4 @@ The CLI hits `POST /api/gds/cost`, which inserts a `cost_log` row.
 ## Files this skill touches
 
 - Reads: `~/.config/otb/gds-session.json`
-- Calls: `POST /api/gds/cost`
+- Calls: `POST /api/bongos/cost`

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

@@ -22,7 +22,7 @@ It never pushes to `main`, never `ssh`-es, never runs a deploy — landing is `/
 
 ### 0. Snapshot the session state — read, don't mutate yet
 
-- **Held claim(s):** `node scripts/gds/api.js GET /api/gds/me` → `active_claims`. (A builder can hold parallel claims across sessions; resolve only the one this session worked.)
+- **Held claim(s):** `node scripts/gds/api.js GET /api/bongos/me` → `active_claims`. (A builder can hold parallel claims across sessions; resolve only the one this session worked.)
 - **Are we in a linked worktree?** `git rev-parse --git-dir` differs from `git rev-parse --git-common-dir` ⇒ yes (`--git-dir` is the per-worktree `<main>/.git/worktrees/<name>`; `--git-common-dir` is the shared `<main>/.git`); they're equal ⇒ main checkout (skip step 3). Test `--git-dir`, **not** `--git-common-dir` — the latter always returns the shared `<main>/.git` even inside a worktree, so checking *it* for `/worktrees/` never matches.
 - **Working-tree state:** `git status --porcelain`.
 - **Commits ahead of main:** `git rev-list --count main..HEAD` (fall back to `origin/main..HEAD`). Real commits ⇒ likely shippable; zero ⇒ likely a release.
@@ -65,4 +65,4 @@ Removing this session's worktree ends its filesystem — do it last, and tell th
 ## Files this skill touches
 
 - Reads: `~/.config/otb/gds-session.json`
-- Runs: the `builder-ship` / `builder-release` skills (`scripts/gds/ship.js` · `release.js`), `node scripts/gds/api.js GET /api/gds/me`, and local `git worktree` / `git status` / `git branch` commands. It makes no API writes of its own.
+- Runs: the `builder-ship` / `builder-release` skills (`scripts/gds/ship.js` · `release.js`), `node scripts/gds/api.js GET /api/bongos/me`, and local `git worktree` / `git status` / `git branch` commands. It makes no API writes of its own.

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

@@ -4,7 +4,7 @@ description: >-
   Offboard or reactivate a builder: release claims, seal each with a session log, drop rank to sandboxed Xenos, archive local memory — keeping attribution and credits. Archon-only; for your own session use /builder-end. Triggers: "/builder-exit N", "offboard builder N", "builder X is leaving", "reactivate builder N".
 ---
 
-**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.
+**Script skill (authoritative).** The core action is the `PATCH /api/bongos/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 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.
 
@@ -20,7 +20,7 @@ Never run the destructive offboard just because someone wanted to log off — th
 
 ## What graceful exit does (V3.R88 #307)
 
-Deactivating a builder via `PATCH /api/gds/builders/:id/status { status: 'inactive', reason }` transactionally:
+Deactivating a builder via `PATCH /api/bongos/builders/:id/status { status: 'inactive', reason }` transactionally:
 
 1. **Releases every active claim** they hold (`released_at = now`, outcome `abandoned`) and bounces each in-flight task back to `ready` so the work isn't stranded.
 2. **Seals an outstanding session log** for each released claim (a closing `abandoned`-on-exit row — the audit trail shows the work was handed back, not silently dropped).
@@ -28,7 +28,7 @@ Deactivating a builder via `PATCH /api/gds/builders/:id/status { status: 'inacti
 4. **Preserves everything else**: example (`total_credits`), the full `credit_log`, their shipped tasks, and historical session logs all stay, attributed to them, indefinitely.
 5. Writes an interim audit row to `credit_log` (`delta=0`, reason carries the actor) until the dedicated `audit_log` lands (R36).
 
-Reactivation (`{ status: 'active' }`) flips them back to active. **Rank is not auto-restored** — it stays `xenos`, and an Archon re-promotes deliberately via `/builder-exit`'s sibling rank endpoint (`PATCH /api/gds/builders/:id/rank`).
+Reactivation (`{ status: 'active' }`) flips them back to active. **Rank is not auto-restored** — it stays `xenos`, and an Archon re-promotes deliberately via `/builder-exit`'s sibling rank endpoint (`PATCH /api/bongos/builders/:id/rank`).
 
 ## Authority
 
@@ -53,7 +53,7 @@ So memory archival is a **local** step, done on the exiting builder's machine
 
 ## How to use
 
-1. **Resolve the target builder id.** `/builder-exit 5` → builder #5. If given a name/login, look it up via the leaderboard or `GET /api/gds/me` patterns. Confirm the right person with the user.
+1. **Resolve the target builder id.** `/builder-exit 5` → builder #5. If given a name/login, look it up via the leaderboard or `GET /api/bongos/me` patterns. Confirm the right person with the user.
 
 2. **Confirm intent.** Offboarding is significant and Archon-gated — restate what will happen ("this releases their N active claims, drops them to Xenos, and blocks new claims; their credits and shipped work are preserved") and get a clear go-ahead.
 
@@ -62,9 +62,9 @@ So memory archival is a **local** step, done on the exiting builder's machine
 4. **Call the endpoint** (uses the current Archon's session token):
    ```bash
    # Deactivate
-   node -e "require('./scripts/gds/cli-lib.js').apiCall('PATCH','/api/gds/builders/<id>/status',{status:'inactive',reason:'<why>'}).then(r=>console.log(r.status, JSON.stringify(r.data,null,2)))"
+   node -e "require('./scripts/gds/cli-lib.js').apiCall('PATCH','/api/bongos/builders/<id>/status',{status:'inactive',reason:'<why>'}).then(r=>console.log(r.status, JSON.stringify(r.data,null,2)))"
    # Reactivate
-   node -e "require('./scripts/gds/cli-lib.js').apiCall('PATCH','/api/gds/builders/<id>/status',{status:'active'}).then(r=>console.log(r.status, JSON.stringify(r.data,null,2)))"
+   node -e "require('./scripts/gds/cli-lib.js').apiCall('PATCH','/api/bongos/builders/<id>/status',{status:'active'}).then(r=>console.log(r.status, JSON.stringify(r.data,null,2)))"
    ```
 
 5. **Print the API response verbatim.** The JSON shows claims released and new rank/status. If reactivating, note (from the response) that rank stays `xenos` until a `/builder-rank` promotion.
@@ -86,4 +86,4 @@ So memory archival is a **local** step, done on the exiting builder's machine
 
 - Reads: `~/.config/otb/gds-session.json`, the exiting builder's local memory dir
 - Writes: `<memory>-archive/` (local snapshot, on the builder's machine)
-- Calls: `PATCH /api/gds/builders/:id/status`
+- Calls: `PATCH /api/bongos/builders/:id/status`

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

@@ -18,7 +18,7 @@ A key is **never** pasted into chat, and **never** accepted as a CLI argument. T
 
 ## How to use
 
-1. **List status.** Run `node scripts/gds/key-status.js` and relay its output verbatim (the monospace list). It hits `GET /api/gds/me/art-key` for each known key.
+1. **List status.** Run `node scripts/gds/key-status.js` and relay its output verbatim (the monospace list). It hits `GET /api/bongos/me/art-key` for each known key.
 
 2. **Missing key → the visual callout fires automatically.** When a key is unset, the script calls `scripts/gds/key-card.js` itself and prints `[otb-key-card-html] <path>` — the same marker the `.claude/hooks/lifecycle-card.js` PostToolUse hook scans for on ANY Bash output. The hook injects a render directive right after the tool result:
    - If you have `mcp__visualize__show_widget`: call `mcp__visualize__read_me` once this session (modules `["interactive","mockup"]`) if you haven't, then render the HTML exactly as directed — **once**, no prose recap.
@@ -37,5 +37,5 @@ A key is **never** pasted into chat, and **never** accepted as a CLI argument. T
 ## Files this skill touches
 
 - Reads: `~/.config/otb/gds-session.json`
-- Calls: `GET /api/gds/me/art-key`, `GET /api/gds/me` (widgets knob)
+- Calls: `GET /api/bongos/me/art-key`, `GET /api/bongos/me` (widgets knob)
 - Runs: `scripts/gds/key-status.js`, `scripts/gds/key-card.js` (via the status script), `scripts/gds/fetch-art-key.js` (via `--recheck`)

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

@@ -28,7 +28,7 @@ What actually bounds a leaked token is **revocation**, and it is faster than any
    - Click **"Copy"** — it copies a one-line command of the form `bongos paste-token <token>`.
    - Ask them to **paste that one line back into the chat**.
 
-3. **Run the pasted command.** When the user pastes `bongos paste-token <token>`, run it exactly as given. `paste-token.js` verifies the token against `/api/gds/me` **before** touching the session file (a bad paste leaves the existing session intact) and preserves any `gemini_api_key`. On success it prints the builder login, rank, and confirms the session file was written.
+3. **Run the pasted command.** When the user pastes `bongos paste-token <token>`, run it exactly as given. `paste-token.js` verifies the token against `/api/bongos/me` **before** touching the session file (a bad paste leaves the existing session intact) and preserves any `gemini_api_key`. On success it prints the builder login, rank, and confirms the session file was written.
 
 4. **Confirm.** Relay the authenticated identity + rank back to the user, and tell them they can now re-run whatever `/builder-*` command they were trying.
 
@@ -50,4 +50,4 @@ What actually bounds a leaked token is **revocation**, and it is faster than any
 - Runs: `node scripts/gds/reauth.js` (detect + open browser + print click-path)
 - Runs: `bongos paste-token <token>` (verify + write the new session)
 - Reads/Writes (via paste-token.js): `~/.config/otb/gds-session.json`
-- Calls: `GET /api/gds/me`; the Settings page (CLI Access) calls `POST /api/gds/auth/cli-token/issue`
+- Calls: `GET /api/bongos/me`; the Settings page (CLI Access) calls `POST /api/bongos/auth/cli-token/issue`

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

@@ -25,9 +25,9 @@ The reporter does NOT need Archon attention to file. The Archon comes to the que
 ## What this skill does
 
 1. Reads `~/.config/otb/gds-session.json` for the bearer token.
-2. Hits `GET /api/gds/me` to confirm rank ≥ Metic. Refuses with a friendly message if Xenos.
+2. Hits `GET /api/bongos/me` to confirm rank ≥ Metic. Refuses with a friendly message if Xenos.
 3. Walks the user through five questions (see below).
-4. POSTs to `/api/gds/security/reports`.
+4. POSTs to `/api/bongos/security/reports`.
 5. Echoes the report id back + a note that the auto-repro subagent will attempt reproduction within the hour.
 6. (Optional) Offers to file an `idea_inbox` entry with `kind='bug'` pointing back at the report id, so the fix can be triaged into a normal task on the next `/idea-triage` pass.
 
@@ -35,8 +35,8 @@ The reporter does NOT need Archon attention to file. The Archon comes to the que
 
 Ask one at a time. Don't batch — the answers feed each other.
 
-1. **Severity.** One of `low`, `medium`, `high`, `critical`. Show the bounty schedule from `GET /api/gds/public/bounty-table` if the user is unsure. Critical means "this could let an attacker forge writes as another builder or read data they're not entitled to"; high means a real attack vector with a workaround; medium is a defense-in-depth gap; low is a hardening recommendation.
-2. **Target.** One short line — the route, file, endpoint, or surface. Examples: `POST /api/gds/tasks/:id/override-request`, `src/bongos/auth.js#verifyToken`, `caddy: example.com:443`. Goes into the `target` column verbatim.
+1. **Severity.** One of `low`, `medium`, `high`, `critical`. Show the bounty schedule from `GET /api/bongos/public/bounty-table` if the user is unsure. Critical means "this could let an attacker forge writes as another builder or read data they're not entitled to"; high means a real attack vector with a workaround; medium is a defense-in-depth gap; low is a hardening recommendation.
+2. **Target.** One short line — the route, file, endpoint, or surface. Examples: `POST /api/bongos/tasks/:id/override-request`, `src/bongos/auth.js#verifyToken`, `caddy: example.com:443`. Goes into the `target` column verbatim.
 3. **Title.** One sentence summarizing the flaw. Reads in the Archon queue first, so make it scan-friendly. Example: "OAuth state cookie has no SameSite=strict — CSRF window during auth handshake."
 4. **Description.** What's the impact? Who would notice? Why does it matter? A few sentences. Free-form Markdown.
 5. **Repro steps.** Numbered list of what an attacker (or auditor) does to demonstrate the issue. The auto-repro subagent (R68, when wired) will try to follow these exactly, so be precise. Use `<TOKEN>` or `<COOKIE>` placeholders for any sensitive values.
@@ -50,7 +50,7 @@ your file-write tool (NOT a shell heredoc — heredocs aren't portable), then PO
 it with the cross-platform Bongos API helper:
 
 ```
-node scripts/gds/api.js POST /api/gds/security/reports --body-file <path-to-report.json>
+node scripts/gds/api.js POST /api/bongos/security/reports --body-file <path-to-report.json>
 ```
 
 where `report.json` is:
@@ -87,7 +87,7 @@ After the report is filed, offer:
 If yes — write the idea JSON to a temp file, then:
 
 ```
-node scripts/gds/api.js POST /api/gds/inbox --body-file <path-to-idea.json>
+node scripts/gds/api.js POST /api/bongos/inbox --body-file <path-to-idea.json>
 ```
 
 where `idea.json` is:
@@ -107,4 +107,4 @@ This is optional because some findings are "the system is fine, my mental model
 
 ## When the API is unreachable
 
-If the POST fails (network, droplet down, route 5xx), do NOT silently swallow. Print the full response body and tell the user the report was NOT filed. Offer to re-try once they confirm the droplet is up — `node scripts/gds/api.js GET /api/gds/healthz` is the fastest probe (cross-platform; prints the status).
+If the POST fails (network, droplet down, route 5xx), do NOT silently swallow. Print the full response body and tell the user the report was NOT filed. Offer to re-try once they confirm the droplet is up — `node scripts/gds/api.js GET /api/bongos/healthz` is the fastest probe (cross-platform; prints the status).

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

@@ -12,7 +12,7 @@ You are releasing a task on behalf of the current builder. Releasing is the hone
 
 Runs `node scripts/gds/release.js <task-id> --reason "..."`.
 
-The CLI hits `POST /api/gds/claims/:id/resolve` with `outcome: 'abandoned'`, which transactionally:
+The CLI hits `POST /api/bongos/claims/:id/resolve` with `outcome: 'abandoned'`, which transactionally:
 1. Marks the claim `released_at = now`, outcome `abandoned`.
 2. Flips the task status back to `ready`.
 3. Inserts a `session_logs` row with the reason and timestamps.
@@ -39,4 +39,4 @@ The task is immediately claimable by another session.
 ## Files this skill touches
 
 - Reads: `~/.config/otb/gds-session.json`
-- Calls: `GET /api/gds/me`, `POST /api/gds/claims/:id/resolve`
+- Calls: `GET /api/bongos/me`, `POST /api/bongos/claims/:id/resolve`

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

@@ -109,5 +109,5 @@ node scripts/gds/sequence.js --check <task-id>
 ## Files this skill touches
 
 - Runs: `scripts/gds/sequence.js` (planning + next + check), then `scripts/gds/claim.js` and `scripts/gds/ship.js` per pass.
-- Reads: `GET /api/gds/tasks/:id` (for `dependencies[]`/`dependents[]`), `GET /api/gds/tasks/claimable`, `GET /api/gds/me`.
+- Reads: `GET /api/bongos/tasks/:id` (for `dependencies[]`/`dependents[]`), `GET /api/bongos/tasks/claimable`, `GET /api/bongos/me`.
 - Writes nothing itself — every state change goes through the claim and ship paths that already own it.

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

@@ -19,9 +19,9 @@ Before running this skill, **two things must be true**:
 
 Runs `node scripts/gds/setup.js`. The script:
 
-1. POSTs `/api/gds/auth/device/start` → gets `user_code` + `verification_uri` from GitHub via the server.
+1. POSTs `/api/bongos/auth/device/start` → gets `user_code` + `verification_uri` from GitHub via the server.
 2. Prints a clear "open this URL, enter this code" prompt to the user.
-3. Polls `/api/gds/auth/device/poll` every few seconds until the user approves (or denies, or expires).
+3. Polls `/api/bongos/auth/device/poll` every few seconds until the user approves (or denies, or expires).
 4. On success, writes `~/.config/otb/gds-session.json` (resolved from the current user's `$HOME`) with the bearer token and builder profile.
 5. Prints the builder's profile.
 
@@ -62,4 +62,4 @@ Runs `node scripts/gds/setup.js`. The script:
 
 - Reads (potentially): `~/.config/otb/gds-session.json` (only to check if already authenticated)
 - Writes: `~/.config/otb/gds-session.json`
-- Calls: production `/api/gds/auth/device/start` and `/api/gds/auth/device/poll`
+- Calls: production `/api/bongos/auth/device/start` and `/api/bongos/auth/device/poll`

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

@@ -102,4 +102,4 @@ The CLI drives a **three-state lifecycle** with a subagent grader between states
 ## Files this skill touches
 
 - Reads: `~/.config/otb/gds-session.json`
-- Calls: `GET /api/gds/me`, `POST /api/gds/claims/:id/resolve`
+- Calls: `GET /api/bongos/me`, `POST /api/bongos/claims/:id/resolve`

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

@@ -8,7 +8,7 @@ You are staging a builder's in-progress work on **their own** sandbox — the li
 
 ## Background
 
-Staging (re)starts the preview, which serves the **game-only** entry (`src/preview-server.js`, ADR 0052), degraded-DB (fully playable, no saved state, isolated from prod, no `/api/gds`): a private detached process at `http://localhost:<port>` (default 3100, `$OTB_PREVIEW_PORT` to override), managed by `scripts/gds/local-preview.js` (task 1056). No tunnel, no public URL — it never leaves your machine.
+Staging (re)starts the preview, which serves the **game-only** entry (`src/preview-server.js`, ADR 0052), degraded-DB (fully playable, no saved state, isolated from prod, no `/api/bongos`): a private detached process at `http://localhost:<port>` (default 3100, `$OTB_PREVIEW_PORT` to override), managed by `scripts/gds/local-preview.js` (task 1056). No tunnel, no public URL — it never leaves your machine.
 Staging = (re)start the preview, health-check it, and record a marker of exactly what tree state was staged. `/builder-ship` checks that marker: a game-surface diff that wasn't staged at its current state triggers the sandbox review gate before the claim resolves.
 
 ## How to use

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

@@ -60,4 +60,4 @@ Emit one guided next step, not a wall of options. These are the same fixes `bong
 ## Files this skill touches
 
 - Reads: `~/.config/otb/gds-session.json`
-- Calls: `/api/gds/me`, `/api/gds/tasks/claimable` (+ public progress/cost/recent/inbox/blockers for the status line)
+- Calls: `/api/bongos/me`, `/api/bongos/tasks/claimable` (+ public progress/cost/recent/inbox/blockers for the status line)

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

@@ -13,13 +13,13 @@ Runs the recurring "claim, fix, and ship task NNNN" macro end to end. Its own va
 
 1. **Read the task and verify it BEFORE claiming.**
    ```
-   node scripts/gds/api.js GET /api/gds/tasks/<id>
+   node scripts/gds/api.js GET /api/bongos/tasks/<id>
    ```
    If the task names a root cause, open the actual code it points at and confirm that root cause is real — don't take the task's own diagnosis on faith. If the description doesn't match what the code does, say so before writing anything; a task built on a wrong premise needs a corrected task, not a fix for the wrong bug.
 
 2. **If the task is in `backlog`, promote it to `ready` first** (Metic+ only — `POST /tasks/:id/promote` is rank-gated):
    ```
-   node scripts/gds/api.js POST /api/gds/tasks/<id>/promote --body '{}'
+   node scripts/gds/api.js POST /api/bongos/tasks/<id>/promote --body '{}'
    ```
    Skip this step if the task is already `ready`.
 
@@ -45,7 +45,7 @@ Runs the recurring "claim, fix, and ship task NNNN" macro end to end. Its own va
 
 7. **Confirm the outcome — don't assume the ship landed.**
    ```
-   node scripts/gds/api.js GET /api/gds/tasks/<id>
+   node scripts/gds/api.js GET /api/bongos/tasks/<id>
    ```
    - `shipped` (or `confirmed`, awaiting `/merge-mode`) → done; relay the completion card per `/builder-ship`.
    - Still `completed` → read the grade shape before reacting; two distinct outcomes park a task here:
@@ -61,6 +61,6 @@ Runs the recurring "claim, fix, and ship task NNNN" macro end to end. Its own va
 
 ## Files this skill touches
 
-- Calls: `GET /api/gds/tasks/:id`, `POST /api/gds/tasks/:id/promote`, plus whatever `/builder-claim` and `/builder-ship` call for claiming and shipping.
+- Calls: `GET /api/bongos/tasks/:id`, `POST /api/bongos/tasks/:id/promote`, plus whatever `/builder-claim` and `/builder-ship` call for claiming and shipping.
 - Reads: `~/.config/otb/gds-session.json`
 - Writes: the fix itself, plus a new or extended `tests/*.mjs` case.