@bongos/core 1.21.175 → 1.21.176

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

@@ -14,7 +14,7 @@ You are shipping a task on behalf of the current builder. Shipping is the moment
 
 ## What this skill does
 
-Runs `node scripts/gds/ship.js <task-id> --notes-file notes.md --summary-file summary.txt`.
+Runs `node scripts/bongos/ship.js <task-id> --notes-file notes.md --summary-file summary.txt`.
 
 The CLI drives a **three-state lifecycle** with a subagent grader between states (Phase 5, 2026-05-10):
 
@@ -28,8 +28,8 @@ The CLI drives a **three-state lifecycle** with a subagent grader between states
 
 **Two non-pass grade shapes — tell them apart before reacting:**
 
-- **`GRADER UNAVAILABLE`** (`panel_outcome='unavailable'`) — the grading panel could not run (worker infra outage or a pre-spawn bypass). This is **not a quality rejection**: no quality signal was produced, there are no findings to fix, and the task parks at `completed` ungraded (aggregates exclude these rounds as `n_unavailable` — an outage never counts as a zero). Recovery: when the grader is reachable again, re-run just the grade step — `node scripts/gds/ship.js <id> --regrade`.
-- **A genuine `FAIL`** — the panel ran and returned findings. Fix the real issues, commit on the claim branch (the grader reads committed history, not the working tree), then re-grade with the same command: `node scripts/gds/ship.js <id> --regrade`.
+- **`GRADER UNAVAILABLE`** (`panel_outcome='unavailable'`) — the grading panel could not run (worker infra outage or a pre-spawn bypass). This is **not a quality rejection**: no quality signal was produced, there are no findings to fix, and the task parks at `completed` ungraded (aggregates exclude these rounds as `n_unavailable` — an outage never counts as a zero). Recovery: when the grader is reachable again, re-run just the grade step — `node scripts/bongos/ship.js <id> --regrade`.
+- **A genuine `FAIL`** — the panel ran and returned findings. Fix the real issues, commit on the claim branch (the grader reads committed history, not the working tree), then re-grade with the same command: `node scripts/bongos/ship.js <id> --regrade`.
 
 **Every way a ship can stall closes with an `[otb-plain]` card** (task 1003989) — both shapes above, an authorization refusal, a red pull request, a failed push, a land still pending, a land the server could not prove. When the builder's interaction profile is not `engineer`, that card is what you tell them: what happened, what you are doing about it, and whether they need to ask anyone. Its `By design` line decides your next move — `Yes` is a rule to respect (a pending land needs nothing; a protected path cannot be re-graded past), `No` is a fault to go and fix. Do not answer a stall by running the ship again unchanged.
 
@@ -41,7 +41,7 @@ The CLI drives a **three-state lifecycle** with a subagent grader between states
 
    **With game-surface changes, stage first (#927, ADR 0046 + #1048).** If the diff touches the game (`public/`, `src/world/`, `src/rooms/`, `server.js`), the flow is: stage → the builder reviews the change on their local sandbox preview → approve → ship. `ship.js` enforces this before the claim resolves: un-staged game work gets staged and the ship **aborts with a `🔍 REVIEW REQUIRED` block** carrying the URL (claim intact, nothing lost).
 
-   **When you see that block, position the sandbox link prominently for the builder.** `ship.js` also emits the deterministic lifecycle card for the `review` stage (an `[otb-card-html] <path>` marker) — if an in-feed visualization tool is available, render that card (its primary action is **Open in sandbox ↗**, the URL); it's the cleanest way to make the link impossible to miss. Either way, surface the URL as its own standalone, clickable line in chat — a clear callout, NOT buried inside a paragraph of command output — and say in one line what to look at. This is the moment the change is ready to review; the link must be impossible to miss. Let the builder open it, review, and suggest changes; iterate if needed. **Only once the builder explicitly approves, re-run with `node scripts/gds/ship.js <id> --approved`** — that records their sign-off as a durable `sandbox_review` fact on the task (who, when, and the content stamp of exactly what was reviewed). Never pass `--approved` yourself without a real human go; the pause + sign-off IS the feature. `--skip-stage` is the escape hatch (use sparingly — the gate exists so unreviewed game changes don't ride straight to prod). Non-game diffs are unaffected.
+   **When you see that block, position the sandbox link prominently for the builder.** `ship.js` also emits the deterministic lifecycle card for the `review` stage (an `[otb-card-html] <path>` marker) — if an in-feed visualization tool is available, render that card (its primary action is **Open in sandbox ↗**, the URL); it's the cleanest way to make the link impossible to miss. Either way, surface the URL as its own standalone, clickable line in chat — a clear callout, NOT buried inside a paragraph of command output — and say in one line what to look at. This is the moment the change is ready to review; the link must be impossible to miss. Let the builder open it, review, and suggest changes; iterate if needed. **Only once the builder explicitly approves, re-run with `node scripts/bongos/ship.js <id> --approved`** — that records their sign-off as a durable `sandbox_review` fact on the task (who, when, and the content stamp of exactly what was reviewed). Never pass `--approved` yourself without a real human go; the pause + sign-off IS the feature. `--skip-stage` is the escape hatch (use sparingly — the gate exists so unreviewed game changes don't ride straight to prod). Non-game diffs are unaffected.
 
 2. **Compose the handoff notes (`--notes-file`)** following the structure in `docs/handoff-template.md`:
    - What shipped (with confidence tags: verified-prod | verified-smoke | implemented-not-verified)
@@ -64,7 +64,7 @@ The CLI drives a **three-state lifecycle** with a subagent grader between states
 4. **Run** — write the prose to files and pass the file (task 1003168):
    ```bash
    # write notes.md and summary.txt with your editor/Write tool first
-   node scripts/gds/ship.js <task-id> --notes-file notes.md --summary-file summary.txt
+   node scripts/bongos/ship.js <task-id> --notes-file notes.md --summary-file summary.txt
    ```
 
    **Use the `-file` forms.** Handoff notes are technical prose, so they contain
@@ -101,12 +101,12 @@ The CLI drives a **three-state lifecycle** with a subagent grader between states
    - If no visualization tool is available at all (headless / cron / a session without it), the **monospace card already printed IS the summary** — relay the `[otb-confirm]` line and stop there.
    - **Beyond that one line: do NOT add a free-form recap** of what shipped, credits, files, cost, or next steps. The card already carries all of it, and its built-in action ("Start next task" / "Land it" / "Fix & re-grade") is the next-step prompt — you don't need to restate it. This replaces the old per-ship prose summary the owner asked us to retire. (The `[otb-confirm]` line is the deliberate exception, and it is *one line* — that is what keeps the redundancy trivial when the card does paint.)
    - The ONLY thing you may add is a single **required** action the card can't express — e.g. a sandbox `🔍 REVIEW REQUIRED` URL from a review pause (see step 1), or a blocker that needs the owner. One line, then stop.
-   - **Something the person must decide or confirm is an ask, never a prose list** (task 1004704): write the card, run `node scripts/gds/ask.js check <file>`, and paste the card it prints — one per decision.
+   - **Something the person must decide or confirm is an ask, never a prose list** (task 1004704): write the card, run `node scripts/bongos/ask.js check <file>`, and paste the card it prints — one per decision.
    - A Hero sound + Discord broadcast may still fire on a milestone (CLAUDE.md §2); that's automatic — no need to narrate it.
 
 ## Constraints
 
-- **Check the ship mode before you ship** (`node scripts/gds/shipping-mode.js`, task 1004631, [ADR 0369](../../../docs/adr/0369-ship-mode-decides-who-starts-a-ship-not-how-it-lands.md)). In **Auto** you run the ship yourself — never hand the person `cd …` and a ship command to type; a permission refusal on the ship command is a missing allow-rule to fix (the project's next core upgrade writes them), not a reason to hand it over. In **Manual** ask first; if the ship stops with `[otb-ask-ship-approval]` (exit 5), ask the person "Ship it, or not yet?" and re-run with `--person-approved` only after a real yes.
+- **Check the ship mode before you ship** (`node scripts/bongos/shipping-mode.js`, task 1004631, [ADR 0369](../../../docs/adr/0369-ship-mode-decides-who-starts-a-ship-not-how-it-lands.md)). In **Auto** you run the ship yourself — never hand the person `cd …` and a ship command to type; a permission refusal on the ship command is a missing allow-rule to fix (the project's next core upgrade writes them), not a reason to hand it over. In **Manual** ask first; if the ship stops with `[otb-ask-ship-approval]` (exit 5), ask the person "Ship it, or not yet?" and re-run with `--person-approved` only after a real yes.
 - **Never ship a task you don't have an active claim on.** The API will reject it (`NOT_YOUR_CLAIM`); surface clearly and run `/builder-start` to find the right state.
 - **Don't fabricate the value summary.** If you can't summarize the value in non-jargon English, the work is probably not actually shippable yet — release instead and surface the gap to the user.
 - **Be honest in handoff notes.** Use `[verified-prod]` only when a real human exercised the feature on the live site. Otherwise `[verified-smoke]` or `[implemented-not-verified]`. The whole project relies on this honesty.

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

@@ -14,39 +14,39 @@ 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/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)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/bongos/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
 
 1. **Run the stage command** from your clone root:
    ```bash
-   node scripts/gds/sandbox-stage.js
+   node scripts/bongos/sandbox-stage.js
    ```
    It (re)starts the preview, waits until the game answers, writes the staged marker, and prints the review URL (`http://localhost:<port>`).
 
-   > **First-time setup:** the preview needs the game's dependencies, so run `npm install` once in your clone. You can also drive the preview directly: `npm run preview` (start), `node scripts/gds/local-preview.js {status|restart|stop|logs}`. Reviewing via the Claude Code preview tools? A `local-sandbox` server is pre-wired in `.claude/launch.json`.
+   > **First-time setup:** the preview needs the game's dependencies, so run `npm install` once in your clone. You can also drive the preview directly: `npm run preview` (start), `node scripts/bongos/local-preview.js {status|restart|stop|logs}`. Reviewing via the Claude Code preview tools? A `local-sandbox` server is pre-wired in `.claude/launch.json`.
 
 2. **Hand the builder the URL** and tell them plainly: this is *their* private copy of the game running on *their own machine* — nothing has shipped. Ask them to open it, walk around, and check the change.
 
    > **Generated art?** If the change was a pixel-art tile, the builder can also see it at the **`/art`** path of the same sandbox URL (`…/art`) — the generated-art gallery (#1262), which shows every tile they've made *even when it isn't placed in the game world yet*. Point them there when the work is "I made a tile" rather than "I changed the map."
 
 3. **Collect their reaction:**
-   - **Change requests** → make the edits, then re-run `node scripts/gds/sandbox-stage.js` and have them refresh the browser tab. Loop until they're happy.
+   - **Change requests** → make the edits, then re-run `node scripts/bongos/sandbox-stage.js` and have them refresh the browser tab. Loop until they're happy.
    - **Looks right** → proceed to `/builder-ship`. The ship gate sees the fresh staged marker and carries on to the main game. (If the marker went stale — the game files changed after staging — the ship stages again and pauses with the review URL; show it to the builder, then re-run.)
 
 4. **Useful sub-commands:**
-   - `node scripts/gds/sandbox-stage.js status` — is the sandbox current with the working tree, when was it last staged?
-   - `node scripts/gds/sandbox-stage.js url` — just the URL.
+   - `node scripts/bongos/sandbox-stage.js status` — is the sandbox current with the working tree, when was it last staged?
+   - `node scripts/bongos/sandbox-stage.js url` — just the URL.
 
 ## Constraints
 
 - **A full local clone.** The ONLY machine with no sandbox is a partial clone that lacks the game (`src/preview-server.js`) — there the script says so and exits.
 - **Never present the sandbox as prod.** No credits, no broadcast, nothing shipped — staging is review, `/builder-ship` is the decision. The preview is private to the builder's own machine (not shareable).
-- If the preview won't come up healthy, point the builder at the logs — `node scripts/gds/local-preview.js logs` — rather than guessing.
+- If the preview won't come up healthy, point the builder at the logs — `node scripts/bongos/local-preview.js logs` — rather than guessing.
 
 ## Files this skill touches
 
-- Runs: `scripts/gds/sandbox-stage.js`, which drives `scripts/gds/local-preview.js` + `local-preview-lib.js` to (re)start `node src/preview-server.js`
+- Runs: `scripts/bongos/sandbox-stage.js`, which drives `scripts/bongos/local-preview.js` + `local-preview-lib.js` to (re)start `node src/preview-server.js`
 - Reads: `$OTB_PREVIEW_PORT` (local port, default 3100)
 - Writes: the staged marker in the OS temp dir (`otb-sandbox-staged.json`); locally, the preview pid/log in the OS temp dir (`otb-local-preview.{pid,log}`)

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

@@ -10,7 +10,7 @@ cost: >-
   Free, and it changes nothing. It only reads the task list.
 ---
 
-**Script skill (authoritative).** The core action is `node scripts/gds/start.js [--widget]`. Run it and render its output verbatim — do not rebuild the table, reorder rows, or add a recap. The card is the summary.
+**Script skill (authoritative).** The core action is `node scripts/bongos/start.js [--widget]`. Run it and render its output verbatim — do not rebuild the table, reorder rows, or add a recap. The card is the summary.
 
 You are starting a working session on the Example project. Before any other work, you check Bongos to see what's claimable.
 
@@ -27,8 +27,8 @@ Delivery is now deterministic (task 1288). The **card-delivery hook** (`.claude/
 1. **Normal path — follow the injected directive.** If that `[otb /builder-start …]` block is in your context this turn, just do what it says: call `show_widget` with the fenced HTML if you have the `mcp__visualize` tool (calling `mcp__visualize__read_me` once first, silently), otherwise output the fenced markdown **verbatim**. Render **once** — don't run `start.js` yourself, don't rebuild the table, don't add a recommendation or recap. That sameness is the feature (task 1273).
 
 2. **Fallback — no directive present** (hook disabled, an older checkout, or it failed silently). Run the script yourself, exactly as the hook would have:
-   - **If you have `show_widget`** (mcp__visualize): `node scripts/gds/start.js --widget`. Call `mcp__visualize__read_me` once this session (modules `["interactive","mockup"]`) if you haven't — silently. Then branch on stdout's **first non-whitespace character**: starts with `<` (HTML) → `show_widget` with `title: "builder_start_card"` and the stdout HTML **verbatim**; doesn't start with `<` (widgets OFF) → print stdout **verbatim** as a normal message (NOT a code fence — the feed needs to render the table).
-   - **No widget renderer** (raw terminal, cron, another client) → `node scripts/gds/start.js` and print its stdout **verbatim**.
+   - **If you have `show_widget`** (mcp__visualize): `node scripts/bongos/start.js --widget`. Call `mcp__visualize__read_me` once this session (modules `["interactive","mockup"]`) if you haven't — silently. Then branch on stdout's **first non-whitespace character**: starts with `<` (HTML) → `show_widget` with `title: "builder_start_card"` and the stdout HTML **verbatim**; doesn't start with `<` (widgets OFF) → print stdout **verbatim** as a normal message (NOT a code fence — the feed needs to render the table).
+   - **No widget renderer** (raw terminal, cron, another client) → `node scripts/bongos/start.js` and print its stdout **verbatim**.
    - Either way, stderr may carry an `[otb-card]` **directive for you** (restates the verbatim rule) — follow it, **never** relay it; plus private one-liners (budget / next-stage) — relay *those* as a short note after the card.
 
 - If `start.js` prints **"no Bongos session"**, the builder isn't signed in — route them by scenario: a **first-timer** on the project runs `/builder-setup` (one-time GitHub sign-in that also registers them); a **returning builder whose session went stale** runs `/builder-reauth` (the fast UI re-issue). `start.js` now prints both options; relay the one that fits, then retry.
@@ -40,7 +40,7 @@ Delivery is now deterministic (task 1288). The **card-delivery hook** (`.claude/
 
 > **FIRST, read WHERE THIS INSTANCE'S BOARD LIVES — `config/branding.json` → `domains.buildersOrigin`.** Every route below branches on it, and getting it wrong is worse than an error. A **remote `https://` origin** means the board is **HOSTED**: it is a running website with the builder's real tasks in it. A **`localhost`** origin means the instance is genuinely local and has to be brought up. Prescribing the local cure on a hosted instance walks the builder through three obedient steps to a board that is not theirs.
 
-- **`bongos: command not found`, a "cannot find module" from `node scripts/gds/start.js`, or you can otherwise tell this is a fresh checkout** (a scaffolded instance whose `node_modules` is absent). The `bongos` CLI ships *inside* the not-yet-installed `@bongos/core` package, so nothing runs until deps are installed — this is the #1 fresh-clone wall. Note before prescribing anything: **`@bongos/core` is a PUBLIC npm package** ([ADR 0283](../../../docs/adr/0283-the-core-publishes-publicly-because-access-was-never-the-thing-protecting-it.md), since 2026-09-13), so a bare `npm install` needs **no `NPM_TOKEN`** and no npm login. A 404 on `@bongos/core` is therefore **not** a normal outcome: it means the dependency in `package.json` names something the registry does not have (a version that was never published, a mistyped name). A local `file:` tarball that is missing fails differently (ENOENT, not a 404). Read the exact spec, tell the builder what it points at, and do not quietly repoint it at a different version. Route by `buildersOrigin`:
+- **`bongos: command not found`, a "cannot find module" from `node scripts/bongos/start.js`, or you can otherwise tell this is a fresh checkout** (a scaffolded instance whose `node_modules` is absent). The `bongos` CLI ships *inside* the not-yet-installed `@bongos/core` package, so nothing runs until deps are installed — this is the #1 fresh-clone wall. Note before prescribing anything: **`@bongos/core` is a PUBLIC npm package** ([ADR 0283](../../../docs/adr/0283-the-core-publishes-publicly-because-access-was-never-the-thing-protecting-it.md), since 2026-09-13), so a bare `npm install` needs **no `NPM_TOKEN`** and no npm login. A 404 on `@bongos/core` is therefore **not** a normal outcome: it means the dependency in `package.json` names something the registry does not have (a version that was never published, a mistyped name). A local `file:` tarball that is missing fails differently (ENOENT, not a 404). Read the exact spec, tell the builder what it points at, and do not quietly repoint it at a different version. Route by `buildersOrigin`:
   - **Hosted (remote origin)** — lead with the fact that **nothing needs installing**: the board is a website, so open `<buildersOrigin>/builders` to see and claim work right now. The CLI is an optional second client and needs a token. **Never route to `bongos dev` here** — it stands up a *local* instance with its *own empty database*, so it cannot show the hosted board and quietly answers a different question than the one asked.
   - **Local (`localhost` origin)** — the instance really is local: `npm install`, then `bongos dev` (one-command local bring-up), then re-run `/builder-start`.
   Either way, don't hand-run internal scripts; the package isn't unpacked yet.

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

@@ -30,8 +30,8 @@ There is a skill for *asking* (`/ask-for-help`) and this is the one for *answeri
 **Step 1 — pull the queue.**
 
 ```bash
-node scripts/gds/api.js GET /api/bongos/help-requests/for-me
-node scripts/gds/api.js GET /api/bongos/task-recommendations/for-me
+node scripts/bongos/api.js GET /api/bongos/help-requests/for-me
+node scripts/bongos/api.js GET /api/bongos/task-recommendations/for-me
 ```
 
 `for-me` derives the reader's crafts from their own profile server-side. **Never send a `?craft=`** you did not first read back from `crafts` in the response — a craft param that widened rather than narrowed was the privacy hole this surface's grader found.
@@ -41,7 +41,7 @@ Empty both ways → say "nothing is waiting on you" and stop. Otherwise sort **o
 **Step 2 — read the ask, then read what it is about.** For each row, fetch the context it names rather than trusting the summary of it:
 
 ```bash
-node scripts/gds/api.js GET /api/bongos/tasks/<task_id>
+node scripts/bongos/api.js GET /api/bongos/tasks/<task_id>
 ```
 
 **Step 3 — VERIFY BEFORE YOU BELIEVE.** This is the step that earns the skill its cost. An ask is a careful argument written by someone who had the context weeks ago; parts of it go stale and parts were wrong when written. Check, at minimum:
@@ -84,7 +84,7 @@ Writes go through `--body-file`; `api.js` silently drops an inline positional bo
 **Step 6 — answer the ask, on the ask.** Post a reply (ADR 0330):
 
 ```bash
-node scripts/gds/api.js POST /api/bongos/help-requests/<id>/replies --body-file <path>.json
+node scripts/bongos/api.js POST /api/bongos/help-requests/<id>/replies --body-file <path>.json
 ```
 ```json
 { "body": "Answered: ... . What I checked: ... . What was done: task N abandoned. What was NOT done: ... ." }
@@ -97,7 +97,7 @@ Say what was decided, what was done (with ids), and what was **not** done. Write
 **Resolve only when told to.** You may be able to (the addressee can, ADR 0330), and by default you do not: the reader has not read your answer yet, and an ask closed on words nobody checked is the thing this skill exists to prevent. Hand them the id. When the reader **does** say to resolve it — typically "reply X and resolve it" — post the reply first, then:
 
 ```bash
-node scripts/gds/api.js PATCH /api/bongos/help-requests/<id> --body-file <path>.json   # {"status":"answered"}
+node scripts/bongos/api.js PATCH /api/bongos/help-requests/<id> --body-file <path>.json   # {"status":"answered"}
 ```
 
 Read the row back. Resolving is not final: the **asker** can reopen it (`{"status":"open"}`, task 1004458), ticket style, and it lands back in your queue. That is the asker's move — never reopen an ask on someone else's behalf. The Collab page does the same in one press: **Post & resolve** under the reply box, **Mark resolved** on the row, **Reopen** on the asker's archived ask.

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

@@ -14,7 +14,7 @@ You are running a **UI design session**. Two things make it different from the E
 
 ## Step 0 — the tools, then the mode
 
-- **The skills named below have to be ON THE MACHINE.** Claiming a `ui` task lands them as part of the claim (`scripts/gds/claim.js`, the `materializeModuleSkills` flag in `scripts/gds/discipline-modes.json`); opening `/design` without one does not. If `.claude/skills/` has no `impeccable`, first check that the `design-styles` module is on — the style skills below are opt-in since task 1004470, so with it off, say in one plain sentence that the design styles are off on this project and carry on with the loop, the kit and the style library, which stay. Turning them on is the instance's choice, one line in `config/modules.json` (`"design-styles": true`). With it on, run `node scripts/gds/claude-materialize.js --module-skills-only` — it copies every enabled module's `skills/` into this checkout as untracked, self-ignored dirs ([ADR 0224](../../../docs/adr/0224-module-skills-reach-the-core-checkout-as-untracked-self-ignored-copies.md)), so `git status` stays clean and `--clean` takes them away again. A scaffolded instance already received them at `bongos init`. A skill of the same name in your own `~/.claude/skills` is **not** the module's — it carries no platform preamble and was never scanned ([ADR 0220](../../../docs/adr/0220-an-in-house-rebuilt-skill-is-a-first-party-skill.md)).
+- **The skills named below have to be ON THE MACHINE.** Claiming a `ui` task lands them as part of the claim (`scripts/bongos/claim.js`, the `materializeModuleSkills` flag in `scripts/bongos/discipline-modes.json`); opening `/design` without one does not. If `.claude/skills/` has no `impeccable`, first check that the `design-styles` module is on — the style skills below are opt-in since task 1004470, so with it off, say in one plain sentence that the design styles are off on this project and carry on with the loop, the kit and the style library, which stay. Turning them on is the instance's choice, one line in `config/modules.json` (`"design-styles": true`). With it on, run `node scripts/bongos/claude-materialize.js --module-skills-only` — it copies every enabled module's `skills/` into this checkout as untracked, self-ignored dirs ([ADR 0224](../../../docs/adr/0224-module-skills-reach-the-core-checkout-as-untracked-self-ignored-copies.md)), so `git status` stays clean and `--clean` takes them away again. A scaffolded instance already received them at `bongos init`. A skill of the same name in your own `~/.claude/skills` is **not** the module's — it carries no platform preamble and was never scanned ([ADR 0220](../../../docs/adr/0220-an-in-house-rebuilt-skill-is-a-first-party-skill.md)).
 - **Interactive** (someone is here to look and react): show, let them steer, iterate. One or two lines per step, then a screen.
 - **Autonomous** (no one will look): build inside the contract, prove it in both modes, stage or park the screens for review, and **never ship an interface change blind** — a task that cannot be verified visually gets a release with a reason, not a guess.
 
@@ -47,15 +47,17 @@ These hold on every instance; a `DESIGN.md` may tighten them, never loosen them:
 - **The 24px floor** — every control clears 24px on both sides; primary pills 46–48px.
 - **AA in both modes** — 4.5:1 body text, 3:1 large text and non-text, light *and* dark, measured from the real stylesheet.
 - **The Kill Switch** — `prefers-reduced-motion: reduce` at the foot of the token layer kills every animation and transition; no motion in JavaScript; the rest frame is a complete composition.
+- **No top block on a page** (owner, 2026-10-23) — the nav already highlights the page and the top bar names it, so a page draws nothing above its first section: no title, no tagline, no little cluster of buttons or links. Keep one visually hidden `<h1>` for screen readers; put every control inside the page body, where it belongs in the layout. The hall enforces it in `style.css` (Home keeps its greeting band).
+- **An ask card only for a real decision** (owner, 2026-10-23) — the shared ask card (`hall-ask.js`) goes only where the page asks the reader to decide something about the project (a vote, a blocker, a join request, accepting work), and only for a viewer with the authority to act on it. Navigation, filters and claim buttons stay plain.
 
 Generated code uses the `--dt-*` variables; adapters write only `src/ui/<surface>/`, `assets/ui/<surface>/` and `config/design-sources.json`.
 
 ## Step 4 — prove it, then ship the tests with the UI
 
-- `node scripts/gds/validate-design.js --strict` after touching adapters, tokens or `design-sources.json` (fitness runs it on every PR).
+- `node scripts/bongos/validate-design.js --strict` after touching adapters, tokens or `design-sources.json` (fitness runs it on every PR).
 - **New interactive code gets a pin in the page's own test file in the same diff** — the grader's Quality worker fails a chrome change that arrives with no test. Contrast pairs are measured in CI, not eyeballed.
 - The task's DONE WHEN is read literally — "both pages" means both pages. Deliberate deviations from a mock stay minor if the ship notes say why.
-- **The person you're working with OKs it before it ships** — the project default for every builder (owner, 2026-09-23). Open the before/after shots in their browser with `node scripts/gds/review-sheet.js --title … --shot "<caption>=<png>"` (a terminal shows no images, so a screenshot you only read yourself never reached them), and wait. Autonomous: no one to ask, so list the shots in the notes and ship; the change files a visual review that holds the deploy (ADR 0241), never the ship.
+- **The person you're working with OKs it before it ships** — the project default for every builder (owner, 2026-09-23). Open the before/after shots in their browser with `node scripts/bongos/review-sheet.js --title … --shot "<caption>=<png>"` (a terminal shows no images, so a screenshot you only read yourself never reached them), and wait. Autonomous: no one to ask, so list the shots in the notes and ship; the change files a visual review that holds the deploy (ADR 0241), never the ship.
 - `/builder-ship` with real `--notes` (what changed, which screens you looked at, in which modes, and who OKed them) and a plain-language `--summary`.
 
 ## Round-tripping with a design tool
@@ -111,4 +113,4 @@ A look that is not listed here is not in the library. Adding one is the README's
 ## How sessions reach this skill
 
 - **Standalone:** invoke `/design` to have the loop in front of you.
-- **From a claim:** a `ui`-discipline task makes `claim.js` print the `/design` directive from `scripts/gds/discipline-modes.json` — one carrier, one lookup, the same registry the three core crafts ride to their role packs under `docs/packs/` (task 1002990).
+- **From a claim:** a `ui`-discipline task makes `claim.js` print the `/design` directive from `scripts/bongos/discipline-modes.json` — one carrier, one lookup, the same registry the three core crafts ride to their role packs under `docs/packs/` (task 1002990).

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

@@ -15,7 +15,7 @@ You are helping the builder run the Claude Design sync loop: export the repo's d
 
 ## What this skill does
 
-1. **Import** — `node scripts/gds/design-sync.js` (a thin shim over `modules/ui-design/scripts/design-sync.js`, the module home — ADR 0197) builds a token-preview bundle (HTML color/typography/spacing/radii cards, `tokens.css`, `tokens.json`, `surfaces.json`) in a temp directory and prints a JSON manifest.
+1. **Import** — `node scripts/bongos/design-sync.js` (a thin shim over `modules/ui-design/scripts/design-sync.js`, the module home — ADR 0197) builds a token-preview bundle (HTML color/typography/spacing/radii cards, `tokens.css`, `tokens.json`, `surfaces.json`) in a temp directory and prints a JSON manifest.
 2. **Push** — the DesignSync MCP tool (`list_projects` → `finalize_plan` → `write_files`) uploads the bundle to a Claude Design project.
 3. **Export (handoff)** — when Claude Design generates UI code, the handoff lands it under a claimed Bongos task via `adapter.export()`.
 
@@ -24,14 +24,14 @@ You are helping the builder run the Claude Design sync loop: export the repo's d
 ### Step 1 — Build the bundle
 
 ```bash
-node scripts/gds/design-sync.js
+node scripts/bongos/design-sync.js
 ```
 
 Prints JSON to stdout: `{ bundlePath, files, surfaceIds, summary }`.
 
 To limit to one surface:
 ```bash
-node scripts/gds/design-sync.js --surface <id>
+node scripts/bongos/design-sync.js --surface <id>
 ```
 
 ### Step 2 — Push to Claude Design

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

@@ -15,7 +15,7 @@ You are helping the builder run the Figma round-trip loop for the `ui` disciplin
 
 ## What this skill does
 
-1. **Import (push)** — `node scripts/gds/figma-design-sync.js` (a thin shim over `modules/ui-design/scripts/figma-design-sync.js`, the module home — ADR 0197) builds a push plan (`figma-plan.json`: color-swatch frame, typography-specimen frame, one reference frame per surface) in a temp directory and prints a JSON manifest.
+1. **Import (push)** — `node scripts/bongos/figma-design-sync.js` (a thin shim over `modules/ui-design/scripts/figma-design-sync.js`, the module home — ADR 0197) builds a push plan (`figma-plan.json`: color-swatch frame, typography-specimen frame, one reference frame per surface) in a temp directory and prints a JSON manifest.
 2. **Push** — the live Figma MCP tool (`mcp__figma__*` write capability, or `use_figma`) creates/updates the frames described in the plan inside the target Figma file. If write capability isn't available in this session, stop and surface the gap — do not fake the push.
 3. **Export (handoff)** — when a designer finishes a Figma edit, hand its output to `adapter.export()`.
 
@@ -24,12 +24,12 @@ You are helping the builder run the Figma round-trip loop for the `ui` disciplin
 ### Step 1 — Build the push plan
 
 ```bash
-node scripts/gds/figma-design-sync.js
+node scripts/bongos/figma-design-sync.js
 ```
 
 To limit to one surface:
 ```bash
-node scripts/gds/figma-design-sync.js --surface <id>
+node scripts/bongos/figma-design-sync.js --surface <id>
 ```
 
 ### Step 2 — Push to Figma
@@ -78,5 +78,5 @@ The export step enforces path safety: no file (or translated snapshot node) may
 ## After using this skill
 
 - New `config/design-sources.json` entries from `export()` should be committed alongside any generated UI code.
-- Run `node scripts/gds/validate-design.js` after touching adapters or design-sources — it's wired into `scripts/gds/fitness.js` as a hard-fail once any adapter is present.
+- Run `node scripts/bongos/validate-design.js` after touching adapters or design-sources — it's wired into `scripts/bongos/fitness.js` as a hard-fail once any adapter is present.
 - This is the UI-surface loop (ADR 0081). For pixel-art tile review in the example Figma file, use `otb-figma-sync` instead — the two skills never touch the same Figma file or the same directories.

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

@@ -19,44 +19,44 @@ 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/bongos/tasks/<id>
+   node scripts/bongos/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/bongos/tasks/<id>/promote --body '{}'
+   node scripts/bongos/api.js POST /api/bongos/tasks/<id>/promote --body '{}'
    ```
    Skip this step if the task is already `ready`.
 
 3. **Claim it** — see `/builder-claim` for the full mechanics (dedicated worktree, one-claim-per-session, and its error codes). In short:
    ```
-   node scripts/gds/claim.js <id> --worktree <worktree-name>
+   node scripts/bongos/claim.js <id> --worktree <worktree-name>
    ```
 
 4. **Write a failing test FIRST, then fix.** Add the case to the relevant `tests/*.mjs` file (or create one if none covers the surface) that reproduces the bug/gap the task describes. Run it and confirm it fails for the reason you expect — THEN implement the fix — THEN confirm the same test passes.
 
 5. **Run the full verification the ship gate expects, not just the one new test:**
    - the whole touched `tests/*.mjs` file (every case, not just the new one)
-   - `node scripts/gds/fitness.js` (the architecture fitness gate — core/host boundary, CLAUDE.md budget, rank-guard)
+   - `node scripts/bongos/fitness.js` (the architecture fitness gate — core/host boundary, CLAUDE.md budget, rank-guard)
    - any other suite CLAUDE.md/CONTRIBUTING.md calls out for the surface you touched (e.g. a module's own nested CLAUDE.md test pointer)
 
    A throwaway verification script or a one-off Playwright probe does **not** satisfy this — the grader only trusts a checked-in `tests/*.mjs` case (see `/builder-ship`).
 
 6. **Ship from the claim branch** — see `/builder-ship` for handoff notes, the value summary, and the completion-card rendering contract. In short:
    ```
-   node scripts/gds/ship.js <id> --notes-file notes.md --summary-file summary.txt
+   node scripts/bongos/ship.js <id> --notes-file notes.md --summary-file summary.txt
    ```
    **Never merge the claim branch into `main` before running `ship.js`.** `ship.js` diffs the branch against `main`; a pre-merged branch yields an empty diff, and the only way out is `--allow-empty` (dead-ends the task at `completed`, needing an Archon-only confirm) or reverting the merge. Ship from the branch and let `ship.js` land it — the same trap `/builder-ship` calls out.
 
 7. **Confirm the outcome — don't assume the ship landed.**
    ```
-   node scripts/gds/api.js GET /api/bongos/tasks/<id>
+   node scripts/bongos/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:
-     - **`GRADER UNAVAILABLE`** (`panel_outcome='unavailable'`) — the panel could not run (infra outage/bypass). **Not a quality rejection**: there are no findings to fix. Re-run the grade when the grader is reachable: `node scripts/gds/ship.js <id> --regrade`.
-     - **A genuine `FAIL`** — the grader bounced it with findings. **Surface its feedback verbatim** — don't paraphrase or summarize away the specifics — then loop back to step 4 with that feedback in hand; fix, commit, and re-grade: `node scripts/gds/ship.js <id> --regrade`.
+     - **`GRADER UNAVAILABLE`** (`panel_outcome='unavailable'`) — the panel could not run (infra outage/bypass). **Not a quality rejection**: there are no findings to fix. Re-run the grade when the grader is reachable: `node scripts/bongos/ship.js <id> --regrade`.
+     - **A genuine `FAIL`** — the grader bounced it with findings. **Surface its feedback verbatim** — don't paraphrase or summarize away the specifics — then loop back to step 4 with that feedback in hand; fix, commit, and re-grade: `node scripts/bongos/ship.js <id> --regrade`.
 
 ## Constraints
 

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

@@ -26,7 +26,7 @@ Signing off rides `criterion.review`, and an override rides `POST /api/bongos/do
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 
-1. Call `node scripts/gds/api.js GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
+1. Call `node scripts/bongos/api.js GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
 2. **If `rank` lowercases to `xenos` or `thetes`** → stop immediately. Tell the builder: *"Closing a goal's criteria is a Metic+ step — signing one off or overriding it closes out a slice of a version and can auto-achieve a goal. Ask an Archon to promote you, or ask a Metic to run it."* Do not list either queue.
 3. **If `rank` lowercases to `metic` or `archon`** → proceed.
 4. **If `rank` is absent** (a deployment where the three-rank model hasn't shipped) → treat the session as available, exactly as `/idea-triage` does in its pre-rank passthrough mode, and note that in the session log.
@@ -52,14 +52,14 @@ A criterion marked **backend-only** (set when it was written, visible on the cri
 ### Step 1: the queue
 
 ```
-node scripts/gds/uat.js --queue
+node scripts/bongos/uat.js --queue
 ```
 
 (Add `--version <id>` to scope it.) If nothing is awaiting UAT, say so and move on to Part 2 (or stop, if only Part 1 was asked for).
 
 ### Step 2: one criterion at a time
 
-For each, run `node scripts/gds/uat.js <criterion-id>` and present, in plain words:
+For each, run `node scripts/bongos/uat.js <criterion-id>` and present, in plain words:
 
 - the criterion's text, in full;
 - its goal, and whether it is the goal's **last** open criterion (then signing it off achieves the goal);
@@ -73,13 +73,13 @@ Then tell the tester exactly what to do **on the live site**, derived from the c
 The tester records their screen doing the script (any screen recorder that saves **mp4 or webm**, up to **100 MB**; Windows: Win+Alt+R with Xbox Game Bar, or the Snipping Tool's record button; macOS: Cmd+Shift+5). Then:
 
 ```
-node scripts/gds/uat.js <criterion-id> --recording <path-to-file> --note "<one line: what was checked>"
+node scripts/bongos/uat.js <criterion-id> --recording <path-to-file> --note "<one line: what was checked>"
 ```
 
 For a backend-only criterion, after the tester has checked it by whatever means proves it (a log line, an API read, a test run against live):
 
 ```
-node scripts/gds/uat.js <criterion-id> --backend-signoff --note "<how it was checked>"
+node scripts/bongos/uat.js <criterion-id> --backend-signoff --note "<how it was checked>"
 ```
 
 Add `--live-attested` only when the server says this site cannot tell whether the work is live, and only if the tester really did it on the live site.
@@ -119,7 +119,7 @@ This part mirrors `/idea-triage`, for the *closing* end of the work hierarchy (A
 ### Step 1 — fetch the review queue
 
 ```
-node scripts/gds/api.js GET /api/bongos/done-when/pending-review
+node scripts/bongos/api.js GET /api/bongos/done-when/pending-review
 ```
 
 (Add `?version=BONGOS-V1` to scope to one version. `api.js` is the cross-platform Bongos API helper — it signs the request with your session token.)
@@ -143,12 +143,12 @@ Then ask the user (concise; frame in product/outcome terms):
 **Override** (only for a criterion met some other way, never for one awaiting UAT) → it closes WITHOUT a UAT, so the server requires the reason and records it; the criterion reads "Satisfied (override)" from then on:
 
 ```
-node scripts/gds/api.js POST /api/bongos/done-when/<criterion_id>/satisfy --body '{"override_reason":"<why this is met without a UAT>"}'
+node scripts/bongos/api.js POST /api/bongos/done-when/<criterion_id>/satisfy --body '{"override_reason":"<why this is met without a UAT>"}'
 ```
 
 The response is `{ criterion, goal_achieved, goal }`. **If `goal_achieved` is true**, announce it: *"Goal '{goal.title}' is now achieved — all its criteria are closed."* (That goal now awaits disposition — see Step 4.)
 
-**Reject** → on review it is **not actually met** (the work missed something, or "done" was mis-scoped). There is no "unsatisfy the flag" — the durable fix is to **add the missing work**: capture what's still needed (a follow-up task linked to this criterion, or an idea via `node scripts/gds/capture.js "..."`), and note the rejection in the session log. Once an unshipped task is linked to the criterion, it drops out of `pending_review` on its own. If no follow-up is filed, the criterion simply stays flagged and resurfaces next session — an honest signal that a human said "not done" but nothing was queued to close the gap. **Do not close a criterion you would not stake the version on.**
+**Reject** → on review it is **not actually met** (the work missed something, or "done" was mis-scoped). There is no "unsatisfy the flag" — the durable fix is to **add the missing work**: capture what's still needed (a follow-up task linked to this criterion, or an idea via `node scripts/bongos/capture.js "..."`), and note the rejection in the session log. Once an unshipped task is linked to the criterion, it drops out of `pending_review` on its own. If no follow-up is filed, the criterion simply stays flagged and resurfaces next session — an honest signal that a human said "not done" but nothing was queued to close the gap. **Do not close a criterion you would not stake the version on.**
 
 **Note / defer** is implicit — leave the criterion open by not POSTing. It stays in the queue and surfaces again next session (same as `/idea-triage`'s defer).
 
@@ -163,7 +163,7 @@ Any goal that flipped to `achieved` this session (or is already `achieved`) awai
 A cheap housekeeping pass over the same corpus this session already has open: run the likely-missing-dependency detector and surface any `high`-confidence candidate for a human to triage.
 
 ```
-node scripts/gds/audit-deps.js --min high
+node scripts/bongos/audit-deps.js --min high
 ```
 
 Each line names an open task and an unshipped task whose files it overlaps with no declared dependency between them. **Read both task descriptions before backfilling an edge** — most overlap is parallel work on a shared file, not a build order; a wrong edge gates the dependent (`POST /claims` → 409 `DEPS_NOT_SHIPPED`) until the named blocker ships. Report the count in the summary; zero is the common case and needs no further comment. This is advisory only — it never blocks the review, and skipping it on a rushed pass is fine (it resurfaces next session, same as a deferred criterion).

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

@@ -20,8 +20,8 @@ You are running the **goal-create** session for this Cloud Bongos instance. You
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 
-1. Call `node scripts/gds/api.js GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
-2. **If `rank` lowercases to `xenos`** → stop immediately. Tell the builder: *"Creating a goal sets a scope wall and seeds a version's done-when criteria — a Metic+ operation. You're currently Xenos. You can still **file** the proposal as an idea (`node scripts/gds/capture.js "…"`) for a Metic+ builder to promote at triage; ask an Archon for promotion if you need to create goals directly."* Do not read the goal board, do not draft criteria.
+1. Call `node scripts/bongos/api.js GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
+2. **If `rank` lowercases to `xenos`** → stop immediately. Tell the builder: *"Creating a goal sets a scope wall and seeds a version's done-when criteria — a Metic+ operation. You're currently Xenos. You can still **file** the proposal as an idea (`node scripts/bongos/capture.js "…"`) for a Metic+ builder to promote at triage; ask an Archon for promotion if you need to create goals directly."* Do not read the goal board, do not draft criteria.
 3. **If `rank` lowercases to `metic` or `archon`** → proceed with the phases below.
 4. **If `rank` is absent** (a deployment where the three-rank model hasn't shipped) → treat the session as available, exactly as `/idea-triage` does in its pre-rank passthrough mode, and note that in the session log.
 5. **The protected-scope branch is a SECOND gate, decided in Phase 3 — not here.** A goal whose `scope_modules` includes a **protected** key is Archon-only to create (`403 archon_required_for_protected_scope`) and Archon-mediated to join. You do not know the scope at gate time. Draft it in Phase 3, then take one of the off-ramps in Phase 5 if you are a Metic and the drafted scope is protected.
@@ -38,9 +38,9 @@ You are running the **goal-create** session for this Cloud Bongos instance. You
 
 Determine without asking:
 
-- **The version.** `node scripts/gds/api.js GET /api/bongos/public/versions`. If exactly one is `building` or `planning`, take it. Ask only when two or more are open *and* the work doesn't obviously belong to one.
-- **The existing goals.** `node scripts/gds/api.js GET "/api/bongos/goals?version=<ver>&status=open"`, then `GET /api/bongos/goals/<id>` on each plausible candidate — the detail response is `{goal, members, criteria, dependencies}`, which is what tells you whether a candidate already owns criteria in this space.
-- **The version's criteria.** `node scripts/gds/api.js GET "/api/bongos/versions/<ver>/done-when"` → `{version_id, criteria, goals}`. Use it to avoid a `criterion_id` collision and to pick the next `sort_order` (max + 1).
+- **The version.** `node scripts/bongos/api.js GET /api/bongos/public/versions`. If exactly one is `building` or `planning`, take it. Ask only when two or more are open *and* the work doesn't obviously belong to one.
+- **The existing goals.** `node scripts/bongos/api.js GET "/api/bongos/goals?version=<ver>&status=open"`, then `GET /api/bongos/goals/<id>` on each plausible candidate — the detail response is `{goal, members, criteria, dependencies}`, which is what tells you whether a candidate already owns criteria in this space.
+- **The version's criteria.** `node scripts/bongos/api.js GET "/api/bongos/versions/<ver>/done-when"` → `{version_id, criteria, goals}`. Use it to avoid a `criterion_id` collision and to pick the next `sort_order` (max + 1).
 - **The module roster — LIVE, never from memory and never from this file:**
 
   ```
@@ -49,7 +49,7 @@ Determine without asking:
 
   > **Run the line. Do not paste a roster anywhere, including into this file.** `protected` is *derived* from glob overlap with the trust core, so it changes when the globs change. The snapshot in `/planning-session`'s Phase 2.5 rotted within one release and now omits a key — that is the failure mode this rule exists to prevent.
 
-- **Lineage**, only when this goal continues a prior version's work: `node scripts/gds/api.js GET "/api/bongos/goals?version=<prev>&status=achieved"` and pick the predecessor for `succeeds_goal_id`.
+- **Lineage**, only when this goal continues a prior version's work: `node scripts/bongos/api.js GET "/api/bongos/goals?version=<prev>&status=achieved"` and pick the predecessor for `succeeds_goal_id`.
 
 ## Phase 2 — Reuse or create (autonomous; one question only on a genuine tie)
 
@@ -58,7 +58,7 @@ Determine without asking:
 If the answer is reuse, **stop creating.** Report the goal id, and if an orphan task triggered this session, move it:
 
 ```
-node scripts/gds/api.js PATCH /api/bongos/tasks/<task_id> --body '{"goal_id":<gid>}'   # ids only — safe inline
+node scripts/bongos/api.js PATCH /api/bongos/tasks/<task_id> --body '{"goal_id":<gid>}'   # ids only — safe inline
 ```
 
 Only a real tie between two candidates earns an AskUserQuestion.
@@ -86,7 +86,7 @@ Two rounds at most, both via **AskUserQuestion**.
 
 The order is forced: a criterion needs `goal_id`, a task needs both `goal_id` and the criterion slugs.
 
-> **Always `--body-file`, never inline `--body`, for anything carrying a title, description or criterion prose.** Those strings are authored in this session and routinely contain an apostrophe ("the builder's hall"), which terminates a single-quoted shell argument and corrupts the JSON — or, with a hostile string, runs whatever follows on the builder's machine. Write the body to a temp `.json` file and pass its path. On Windows also heed `scripts/gds/CLAUDE.md`: do **not** create that file with `Out-File`/`>` (the UTF-8 BOM breaks `JSON.parse`), and never pipe `api.js` through `2>&1` (its banner goes to stderr by design).
+> **Always `--body-file`, never inline `--body`, for anything carrying a title, description or criterion prose.** Those strings are authored in this session and routinely contain an apostrophe ("the builder's hall"), which terminates a single-quoted shell argument and corrupts the JSON — or, with a hostile string, runs whatever follows on the builder's machine. Write the body to a temp `.json` file and pass its path. On Windows also heed `scripts/bongos/CLAUDE.md`: do **not** create that file with `Out-File`/`>` (the UTF-8 BOM breaks `JSON.parse`), and never pipe `api.js` through `2>&1` (its banner goes to stderr by design).
 
 ```
 # 5a — the goal. STRICT validation: exactly these fields are accepted
@@ -98,21 +98,21 @@ The order is forced: a criterion needs `goal_id`, a task needs both `goal_id` an
 #   category_id comes from GET /api/bongos/work-categories (task 1003277); omitting it is
 #   legal — the 201 body then carries a category_advisory, never a refusal.
 #   carry-forward: add "succeeds_goal_id":<prior_goal_id>
-node scripts/gds/api.js POST /api/bongos/goals --body-file <path-to-goal.json>
+node scripts/bongos/api.js POST /api/bongos/goals --body-file <path-to-goal.json>
 # → 201 {ok, goal, succeeds_goal_id}. CAPTURE goal.id.
 # You are now the goal's OWNER and its 'lead' member — the membership row is inserted
 # in the SAME statement, so there is NO join step. Don't POST /goals/<id>/join after.
 
 # 5b — the criteria, one call each, in presentation order.
 #   criterion.json: {"criterion_id":"<slug>","criterion_md":"...","goal_id":<gid>,"sort_order":<n>}
-node scripts/gds/api.js POST /api/bongos/versions/<ver>/done-when --body-file <path-to-criterion.json>
+node scripts/bongos/api.js POST /api/bongos/versions/<ver>/done-when --body-file <path-to-criterion.json>
 # You may write these because you OWN the goal (ADR 0154), not merely because you are
 # a Metic. Refusals: 409 criterion_exists (slug already on this version — reuse it,
 # don't rename around the collision) · 409 goal_not_open · 409 version_closed ·
 # 400 bad_goal_id (which ALSO masks "you don't own this goal" — see below).
 
 # 5c — the seed tasks, one call each. --body-file avoids shell-quoting description/arrays.
-node scripts/gds/api.js POST /api/bongos/tasks --body-file <path-to-task.json>
+node scripts/bongos/api.js POST /api/bongos/tasks --body-file <path-to-task.json>
 #   {"version_id":"<ver>","goal_id":<gid>,"title":"...","description":"...",
 #    "kind":"feature|refactor|infra|spike|verify|decision","priority":N,"est_minutes":N,
 #    "criterion_ids":["<slug>"],"source":"goal-create","source_ref":"goal-<gid>-R##"}
@@ -122,7 +122,7 @@ node scripts/gds/api.js POST /api/bongos/tasks --body-file <path-to-task.json>
 # Throttle between calls and honour 429 retry_after.
 
 # 5d — dependency edges, only where a real gate exists.
-node scripts/gds/api.js POST /api/bongos/tasks/<id>/dependencies --body '{"depends_on_task_id":<id>}'  # ids only
+node scripts/bongos/api.js POST /api/bongos/tasks/<id>/dependencies --body '{"depends_on_task_id":<id>}'  # ids only
 
 # 5e — check, then promote only what is still waiting. POST /tasks answers 'backlog',
 #      but the reconciler's backlog sweep moves a task with no unshipped dependency to
@@ -131,12 +131,12 @@ node scripts/gds/api.js POST /api/bongos/tasks/<id>/dependencies --body '{"depen
 #      answers 409 cannot_promote). 'ready' is not 'claimable': the claim-time
 #      dependency gate refuses a task whose dependency is unshipped, whatever its status
 #      (task 1004668). Leave spikes in backlog.
-node scripts/gds/api.js GET "/api/bongos/tasks?goal_id=<gid>"
-node scripts/gds/api.js POST /api/bongos/tasks/<id>/promote
+node scripts/bongos/api.js GET "/api/bongos/tasks?goal_id=<gid>"
+node scripts/bongos/api.js POST /api/bongos/tasks/<id>/promote
 
 # 6 — verify + report.
-node scripts/gds/api.js GET /api/bongos/goals/<gid>            # {goal, members, criteria, dependencies}
-node scripts/gds/api.js GET "/api/bongos/tasks?goal_id=<gid>"
+node scripts/bongos/api.js GET /api/bongos/goals/<gid>            # {goal, members, criteria, dependencies}
+node scripts/bongos/api.js GET "/api/bongos/tasks?goal_id=<gid>"
 ```
 
 ### Protected scope — the Archon off-ramps
@@ -144,7 +144,7 @@ node scripts/gds/api.js GET "/api/bongos/tasks?goal_id=<gid>"
 > **If the drafted `scope_modules` contains a protected key and you are a Metic, do not POST.** `POST /goals` returns `403 archon_required_for_protected_scope`, and a protected-scope goal is Archon-mediated to join in any case. Say so plainly and offer three routes:
 > 1. **Narrow the wall.** Usually only *part* of the work needs the protected module. Create the goal scoped to the unprotected keys, and file the protected-core piece as a task under an existing Archon-owned goal.
 > 2. **Hand an Archon the drafted body.** They create it, then admit you via `POST /goals/:id/members` (Archon-only for protected scope, and the target must be Metic+).
-> 3. **File it as an idea** — `node scripts/gds/capture.js "<the goal proposal>"` — for an Archon to promote at `/idea-triage`.
+> 3. **File it as an idea** — `node scripts/bongos/capture.js "<the goal proposal>"` — for an Archon to promote at `/idea-triage`.
 >
 > **Do not** create the goal narrow intending to widen it later. Widening into a protected key is Archon-gated too. Scope is never self-granted (ADR 0086 §4).
 
@@ -185,7 +185,7 @@ A goal created from the hall's form has only a name, a description, a version an
 
 ## The sibling advisory: `dependency_advisory` (task 1002827)
 
-The same `POST /tasks` response can also carry a non-null **`dependency_advisory`** — a *different* check, unrelated to which goal the task landed in: it names OPEN tasks in the same version whose `touches[]` overlap this one's, with no declared dependency between them (`scripts/gds/audit-deps.js`'s detector, run live for the first time).
+The same `POST /tasks` response can also carry a non-null **`dependency_advisory`** — a *different* check, unrelated to which goal the task landed in: it names OPEN tasks in the same version whose `touches[]` overlap this one's, with no declared dependency between them (`scripts/bongos/audit-deps.js`'s detector, run live for the first time).
 
 - `dependency_advisory.candidates` is sorted by confidence (`high`/`medium`/`low`) — read each candidate's title before acting; most overlap is parallel work on a shared file, not a real build-order dependency.
 - Only backfill a **high**-confidence candidate, and only after reading both task descriptions. Add the edge with `POST /tasks/<id>/dependencies --body '{"depends_on_task_id":<dep_id>}'`.