@bongos/core 1.21.174 → 1.21.176

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

@@ -32,7 +32,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/bongos/builders/directory
+   node scripts/bongos/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.
 
@@ -42,7 +42,7 @@ They are **complementary, not alternatives.** An owner-only task (a credential r
 
 2. **Attach at most one context.** `task_id` **or** `goal_id`, never both (400 `two_contexts`). Neither is allowed — a general "who knows about X" has no context row.
 
-3. **Open `what_is_stuck` with the ask, then the detail.** The first lines are the card as `node scripts/gds/ask.js check <file>` prints it — one question, two or three answers, your pick, who it waits on, what happens if nobody answers — so the person can answer at a glance (agents ask like humans, task 1004704). Below it, write the detail so it is answerable without this session (≤ 4000 chars in all). The recipient has none of your context. Cover:
+3. **Open `what_is_stuck` with the ask, then the detail.** The first lines are the card as `node scripts/bongos/ask.js check <file>` prints it — one question, two or three answers, your pick, who it waits on, what happens if nobody answers — so the person can answer at a glance (agents ask like humans, task 1004704). Below it, write the detail so it is answerable without this session (≤ 4000 chars in all). The recipient has none of your context. Cover:
    - what is stuck, in plain words;
    - why it needs *this* person (rank, access, a call only they can make) — being asked without a reason reads as work being dumped;
    - the concrete steps, so the ask is actionable rather than a summons;
@@ -53,7 +53,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/bongos/help-requests --body-file <path>.json
+   node scripts/bongos/api.js POST /api/bongos/help-requests --body-file <path>.json
    ```
    ```json
    { "needs_builder_id": 3, "task_id": 1002068, "what_is_stuck": "..." }
@@ -64,7 +64,7 @@ They are **complementary, not alternatives.** An owner-only task (a credential r
 
 6. **Settle it when it resolves** — an unsettled pile is noise. The person you asked may also mark it resolved (ADR 0330); withdrawing is yours alone:
    ```bash
-   node scripts/gds/api.js PATCH /api/bongos/help-requests/<id> --body-file <path>.json
+   node scripts/bongos/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/bongos/help-requests/mine` (open) and `GET /api/bongos/help-requests/archive` (settled — your asks are under `asked_of_others`).
 

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

@@ -104,7 +104,7 @@ precedent (*"a verb that reuses a route also reuses its permission"*).
 **Step 1 — run the walk.**
 
 ```bash
-node scripts/gds/backlog-review.js
+node scripts/bongos/backlog-review.js
 ```
 
 It reads `GET /tasks?status=backlog&include=deps&limit=1000`, prints the four

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

@@ -40,7 +40,7 @@ This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`), which names "b
 **Step 1 — fetch open blockers.**
 
 ```
-node scripts/gds/api.js GET /api/bongos/blockers
+node scripts/bongos/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.)
@@ -65,7 +65,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/bongos/blockers/<id>/resolve --body '{"resolution_note":"<one-line summary>"}'
+node scripts/bongos/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

@@ -22,7 +22,7 @@ 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/bongos/me` and read `builder.rank`. Lowercase before testing.
+1. Call `node scripts/bongos/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.
@@ -44,13 +44,13 @@ 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/bongos/blockers/<id>
+node scripts/bongos/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/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.
+- Pull project knowledge so you're not re-deriving: `node scripts/bongos/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.
 
@@ -83,7 +83,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/bongos/blockers/<id>/resolve --body-file <path-to-note.json>
+node scripts/bongos/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/bongos-feedback/SKILL.md

@@ -28,4 +28,4 @@ Add `--idea` for a wish. The command prints one line — relay it, then carry on
 
 ## Files this skill touches
 
-- Runs: `bongos feedback` → `scripts/gds/feedback-send.js` → a receipt from this project (`POST /api/bongos/feedback/receipt`, `src/bongos/routes/feedback.js`) → the hub's `POST /api/bongos/sso/feedback/direct` (`modules/platform-identity/instance-feedback.js`), which redeems the receipt before filing.
+- Runs: `bongos feedback` → `scripts/bongos/feedback-send.js` → a receipt from this project (`POST /api/bongos/feedback/receipt`, `src/bongos/routes/feedback.js`) → the hub's `POST /api/bongos/sso/feedback/direct` (`modules/platform-identity/instance-feedback.js`), which redeems the receipt before filing.

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

@@ -68,7 +68,7 @@ verdict the queue.
    `blocked`, `completed`, `confirmed` — never `shipped` or `abandoned`,
    the latter of which already includes merged-away duplicates).
 2. **Batches near-duplicate bug tasks** into one verdict per cluster
-   (`node scripts/gds/bug-triage.js`'s reuse of `triage.js`'s `clusterRecords`
+   (`node scripts/bongos/bug-triage.js`'s reuse of `triage.js`'s `clusterRecords`
    — the same union-find/Jaccard core `/idea-triage`'s `clusterIdeas` uses,
    generalized in task 1001478 so the algorithm is written once). Partitioned
    by `goal_id`, not `kind` — every row here is already `kind='bug'`, so a
@@ -91,19 +91,19 @@ report" and "should this report be closed at all".
 **Step 1 — fetch open bug tasks.**
 
 ```
-node scripts/gds/api.js GET "/api/bongos/tasks?kind=bug&limit=1000"
+node scripts/bongos/api.js GET "/api/bongos/tasks?kind=bug&limit=1000"
 ```
 
 Filter client-side to the open statuses above. If nothing remains, print "bug
 queue empty — nothing to triage today" and stop.
 
-For a human at a terminal, `node scripts/gds/bug-triage.js` runs the whole
+For a human at a terminal, `node scripts/bongos/bug-triage.js` runs the whole
 walk interactively instead — batching, per-task prompts, and the summary all
-in one command, same shape as `node scripts/gds/triage.js`.
+in one command, same shape as `node scripts/bongos/triage.js`.
 
 **Step 1.5 — batch near-duplicate bug reports BEFORE walking individually.**
 
-Run `clusterRecords` (`scripts/gds/triage.js`, pure, no I/O) with
+Run `clusterRecords` (`scripts/bongos/triage.js`, pure, no I/O) with
 `textOf: t => t.title + ' ' + t.description`, `kindOf: t => t.goal_id`,
 `timeOf: t => new Date(t.created_at)`. For each cluster it returns, offer the
 user ONE decision covering the whole group:
@@ -122,7 +122,7 @@ user ONE decision covering the whole group:
   returns to the normal walk.
 - **Skip** → leave the whole cluster open; it clusters again next triage.
 
-`node scripts/gds/bug-triage.js` already runs this pass automatically before
+`node scripts/bongos/bug-triage.js` already runs this pass automatically before
 its interactive walk — a human running the deterministic walker gets it for
 free with no flag.
 
@@ -147,7 +147,7 @@ implementation):
 report into it:
 
 ```
-node scripts/gds/api.js POST /api/bongos/tasks/<id>/merge --body '{"into_task_id":<N>,"reason":"same report as #N"}'
+node scripts/bongos/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
@@ -161,7 +161,7 @@ instead of re-merging).
 reproduce):
 
 ```
-node scripts/gds/api.js POST /api/bongos/tasks/<id>/abandon --body '{"reason":"cannot reproduce on current build"}'
+node scripts/bongos/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-backup/SKILL.md

@@ -15,7 +15,7 @@ You are helping the builder interact with the Bongos database backup system.
 
 ## What this skill does
 
-Runs `node scripts/gds/backup.js` (status check) or `node scripts/gds/backup.js --trigger` (fire a fresh dump + wait for it to land).
+Runs `node scripts/bongos/backup.js` (status check) or `node scripts/bongos/backup.js --trigger` (fire a fresh dump + wait for it to land).
 
 The backup infrastructure runs on the production droplet:
 - **Nightly local dump** — `pg_dump` to `/var/backups/gds/` as `<db>-<timestamp>.sql.gz`, 30-day retention (task [#412](https://example.com/builders#/task/412))
@@ -33,7 +33,7 @@ This skill lets a Metic+ builder check on backups and take a fresh one — no SS
 ### Check status (no action, just info)
 
 ```bash
-node scripts/gds/backup.js
+node scripts/bongos/backup.js
 ```
 
 Outputs the latest dump filename, timestamp, size, and count of retained dumps.
@@ -41,7 +41,7 @@ Outputs the latest dump filename, timestamp, size, and count of retained dumps.
 ### Trigger a fresh backup
 
 ```bash
-node scripts/gds/backup.js --trigger
+node scripts/bongos/backup.js --trigger
 ```
 
 Fires a fresh local dump on the server. Polls until the new dump lands (up to ~60 s) and prints its details on success.

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

@@ -10,7 +10,7 @@ cost: >-
   Free. It marks the task as yours until you finish it or give it back.
 ---
 
-**Script skill (authoritative).** The core action is `node scripts/gds/claim.js <task-id> [--worktree NAME]`. Once the args are determined, run it and relay its output verbatim — do not paraphrase error messages or reformat the claimed card.
+**Script skill (authoritative).** The core action is `node scripts/bongos/claim.js <task-id> [--worktree NAME]`. Once the args are determined, run it and relay its output verbatim — do not paraphrase error messages or reformat the claimed card.
 
 **The one exception — a refusal, for a non-technical builder (task 1003989).** Every refusal now ends with an `[otb-plain]` card: what happened, what you will do next, whether a person is needed (and who), and whether this is a rule or a fault. Read the session's interaction profile (the Conductor injects it; with none injected, assume non-technical — CLAUDE.md §2). **Non-technical or mixed:** lead with the card in your own plain words and do what its "What I will do" line says; keep the raw text back unless they ask for it. **Engineer:** relay verbatim, as above. **Any profile:** `By design: Yes` means the refusal is a rule, not breakage — never look for a way round it and never offer one.
 
@@ -18,7 +18,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/bongos/claims`, which transactionally:
+Runs `node scripts/bongos/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).
@@ -48,7 +48,7 @@ The server now **enforces** the one-claim half (task 1642): `POST /api/bongos/cl
 
 2. **Be in a per-claim worktree, not the main checkout.** `claim.js` **refuses** (exit 2) when it is run in the primary worktree — worktree-per-claim is the project default (task 1642) and task 1002579 is the check behind it. Branching in the main checkout parks it off `main`, and `ship.js`'s local auto-merge then has nowhere to merge INTO: the ship strands at `confirmed` until the server reconciler or `/merge-mode` catches it. The refusal names the exact fix; run it and claim from the new tree:
    ```
-   node scripts/gds/worktree.js add <task-id>
+   node scripts/bongos/worktree.js add <task-id>
    ```
    A linked worktree claims normally, and a tree git can't classify is allowed through (the guard never blocks on a guess). The escape hatch — for a builder who genuinely means to work in the main checkout — is `--here`, which downgrades the refusal to a loud warning and accepts the `confirmed`/`/merge-mode` finish.
 
@@ -60,7 +60,7 @@ The server now **enforces** the one-claim half (task 1642): `POST /api/bongos/cl
 
 3. **Run**:
    ```
-   node scripts/gds/claim.js <task-id> --worktree <worktree-name>
+   node scripts/bongos/claim.js <task-id> --worktree <worktree-name>
    ```
 
 4. **On success**, relay the claim id, task title, version, priority, credit reward, and the `touches[]` to the user. Treat `touches[]` as an **advisory hint** at the expected blast radius — NOT an editing fence. Code legitimately wanders into files nobody predicted; that is fine and no longer ship-blocking (the grader reads the real committed diff, and `git merge` is the authoritative collision detector). If the claim returned an `overlap_warning`, relay it too — it just means another active claim declares overlapping files; the user self-serializes only if it's genuinely the same code.
@@ -82,7 +82,7 @@ The server now **enforces** the one-claim half (task 1642): `POST /api/bongos/cl
 11. **On `session_already_has_active_claim`** (task 1642 — applies to **all ranks**): this *session* already holds an active claim, and a session may hold only one (one worktree → one branch → no commingled ships). The body names `active_task_id` + `active_task_title`. Surface them with `what_to_do`: either `/builder-ship N` (or `/builder-release N`) the in-flight task first, **or** open a fresh worktree/session for this new task and claim there. Do not retry in the same worktree — the refusal is the guard working. (`session_claim_check_failed` is the rare fail-closed variant when the server couldn't verify the session state; same remedy — retry, or use a fresh session/worktree.)
 
 12. **On `GOAL_MEMBERSHIP_REQUIRED`** (task 1003137/1003138): the task lives in a goal the builder hasn't joined. The refusal is resolvable **in-session — never send the builder to the hall UI**. The body carries `goal_id`, `visibility`, and the `action` (`join` | `apply`); the CLI already renders the offer and, on a TTY, prompts `[Y/n]` itself. In an agent session (no TTY) the CLI prints the one-command path instead — narrate the same offer to the user:
-    - **`action: join`** (public goal): offer *"Task N lives in goal G ("title", public) — you're not a member. Join and claim?"* On yes, run `node scripts/gds/claim.js <task-id> --join` — it joins the goal and lands the claim in one command. On no, stop: declining leaves no membership row.
+    - **`action: join`** (public goal): offer *"Task N lives in goal G ("title", public) — you're not a member. Join and claim?"* On yes, run `node scripts/bongos/claim.js <task-id> --join` — it joins the goal and lands the claim in one command. On no, stop: declining leaves no membership row.
     - **`action: apply`** (private goal, or a public goal with Archon-mediated protected scope): offer to file the application. On yes, run the same `--join` command — it files exactly one pending request and states plainly that **nothing can be claimed until an owner approves** (do not retry the claim; check the goal inbox later). Re-running reports "already pending", not an error. A private goal's refusal deliberately carries no title or scope — don't guess at them.
     - **Never pass `--join` without the user's yes.** The owner chose the explicit-join model: the offer is a prompt, not a silent side effect.
 

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

@@ -11,13 +11,13 @@ cost: >-
   Free. It only adds an entry to the project's spending record.
 ---
 
-**Script skill (authoritative).** The core action is `node scripts/gds/cost.js <amount-usd> <category> [--task-id N] [--description "..."] [--skill <name>]`. Once the args are determined, run it and print its output verbatim.
+**Script skill (authoritative).** The core action is `node scripts/bongos/cost.js <amount-usd> <category> [--task-id N] [--description "..."] [--skill <name>]`. Once the args are determined, run it and print its output verbatim.
 
 You are logging a cost entry on behalf of the current builder. Bongos keeps a running ledger that powers the cost-vs-value charts on `status.example.com`.
 
 ## What this skill does
 
-Runs `node scripts/gds/cost.js <amount-usd> <category> [--task-id N] [--description "..."] [--source "..."] [--skill <name>]`.
+Runs `node scripts/bongos/cost.js <amount-usd> <category> [--task-id N] [--description "..."] [--source "..."] [--skill <name>]`.
 
 The CLI hits `POST /api/bongos/cost`, which inserts a `cost_log` row.
 
@@ -39,7 +39,7 @@ The CLI hits `POST /api/bongos/cost`, which inserts a `cost_log` row.
 
 5. **Run** and print the output verbatim:
    ```bash
-   node scripts/gds/cost.js 0.42 api --task-id 12 --description "Anthropic API: 4.2k input + 1.1k output"
+   node scripts/bongos/cost.js 0.42 api --task-id 12 --description "Anthropic API: 4.2k input + 1.1k output"
    ```
 
 ## Constraints
@@ -51,9 +51,9 @@ The CLI hits `POST /api/bongos/cost`, which inserts a `cost_log` row.
 
 ## Reading the ledger back
 
-To see what has been spent rather than add to it, run `node scripts/gds/cost-report.js` — total spend plus totals by month, category and source. The endpoint it reads is public, so no rank is needed, but the session still supplies the instance URL. `--source X`, `--category Y` and `--days N` scope the breakdowns (the header total stays project-wide); `--json` prints the raw payload. The newest month is labelled partial — it is spend to date, not a month's worth.
+To see what has been spent rather than add to it, run `node scripts/bongos/cost-report.js` — total spend plus totals by month, category and source. The endpoint it reads is public, so no rank is needed, but the session still supplies the instance URL. `--source X`, `--category Y` and `--days N` scope the breakdowns (the header total stays project-wide); `--json` prints the raw payload. The newest month is labelled partial — it is spend to date, not a month's worth.
 
 ## Files this skill touches
 
 - Reads: `~/.config/otb/gds-session.json`
-- Calls: `POST /api/bongos/cost` (logging), `GET /public/cost-summary` (the read-out, via `scripts/gds/cost-report.js`)
+- Calls: `POST /api/bongos/cost` (logging), `GET /public/cost-summary` (the read-out, via `scripts/bongos/cost-report.js`)

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

@@ -19,8 +19,8 @@ This is **not** `/builder-exit` — that deactivates an entire builder (releases
 Composes operations that already exist, in a safe order, with the destructive ones gated last:
 
 1. **Resolve the claim** — `/builder-ship` when there's committed, shippable work; `/builder-release` when there isn't. (It calls the sibling skills; it does not re-implement shipping.)
-2. **Clean-git verify** — refuse to go further if any *tracked* file is uncommitted. This is the same guard `scripts/gds/ship.js` enforces (`trackedDirty` in [`modules/lifecycle/ship-preflight.js`](../../../modules/lifecycle/ship-preflight.js)): untracked scratch is ignored, but a modified/staged/deleted tracked file means real work isn't committed — stop before anything is lost.
-3. **Worktree teardown** — from the main checkout, remove this session's linked worktree via `node scripts/gds/worktree.js remove` (junction-aware), `prune`, and delete the now-merged `claude/<name>` branch.
+2. **Clean-git verify** — refuse to go further if any *tracked* file is uncommitted. This is the same guard `scripts/bongos/ship.js` enforces (`trackedDirty` in [`modules/lifecycle/ship-preflight.js`](../../../modules/lifecycle/ship-preflight.js)): untracked scratch is ignored, but a modified/staged/deleted tracked file means real work isn't committed — stop before anything is lost.
+3. **Worktree teardown** — from the main checkout, remove this session's linked worktree via `node scripts/bongos/worktree.js remove` (junction-aware), `prune`, and delete the now-merged `claude/<name>` branch.
 
 It never pushes to `main`, never `ssh`-es, never runs a deploy — landing is `/builder-ship`'s job (server-mediated). It only ever touches the caller's **own** claim and **own** worktree.
 
@@ -28,7 +28,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/bongos/me` → `active_claims`. (A builder can hold parallel claims across sessions; resolve only the one this session worked.)
+- **Held claim(s):** `node scripts/bongos/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.
@@ -51,7 +51,7 @@ Proceed only when **all** hold: we're in a linked worktree, the claim is resolve
 You can't remove the worktree you're standing in, so run the removal **from the main checkout** — resolve its path the way `ship.js` does (`findMainWorktree`: parse `git worktree list --porcelain` for the block whose `branch` is `main`). From there:
 
 ```bash
-node scripts/gds/worktree.js remove <this-worktree-path>   # junction-aware wrapper: unlinks a node_modules junction FIRST, then runs `git worktree remove` (which still refuses a dirty tree; do not --force)
+node scripts/bongos/worktree.js remove <this-worktree-path>   # junction-aware wrapper: unlinks a node_modules junction FIRST, then runs `git worktree remove` (which still refuses a dirty tree; do not --force)
 git worktree prune
 git branch -d claude/<worktree-name>        # -d (not -D): git refuses an unmerged branch, by design
 ```
@@ -63,7 +63,7 @@ Removing this session's worktree ends its filesystem — do it last, and tell th
 ## Constraints
 
 - **Own-scoped.** Only this session's claim and this session's worktree — never another builder's claim, never another worktree, never `git worktree remove` a path you didn't create.
-- **Never destroy uncommitted work.** The clean-git verify gates teardown; the dirty-tree refusal in `git worktree remove` and `git branch -d` (not `-D`) are the load-bearing safety nets — keep them as written. But note: that refusal does NOT protect a Windows worktree carrying a `node_modules` junction — node_modules is gitignored, so the clean check passes and `git worktree remove` (even without `--force`) follows the junction and deletes the SHARED node_modules (task 1002809). That is why teardown runs through `node scripts/gds/worktree.js remove`, which unlinks the junction first.
+- **Never destroy uncommitted work.** The clean-git verify gates teardown; the dirty-tree refusal in `git worktree remove` and `git branch -d` (not `-D`) are the load-bearing safety nets — keep them as written. But note: that refusal does NOT protect a Windows worktree carrying a `node_modules` junction — node_modules is gitignored, so the clean check passes and `git worktree remove` (even without `--force`) follows the junction and deletes the SHARED node_modules (task 1002809). That is why teardown runs through `node scripts/bongos/worktree.js remove`, which unlinks the junction first.
 - **Never push / ssh / deploy.** Landing goes through `/builder-ship` (server-mediated); this skill stays local to the builder's machine and makes no API writes of its own.
 - **Teardown never runs unattended without a clear go.** Ship vs. release can be inferred from state (commits ⇒ ship, none ⇒ release) and proceed; removing the worktree ends the session, so wait for an explicit yes before step 3.
 - **Don't tear down a branch that isn't merged.** A released task or a ship stuck at `confirmed` still has an un-landed `claude/*` branch — `git branch -d` will refuse it; respect that and leave the worktree for `/merge-mode`.
@@ -71,4 +71,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/bongos/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/bongos/ship.js` · `release.js`), `node scripts/bongos/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

@@ -69,9 +69,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/bongos/builders/<id>/status',{status:'inactive',reason:'<why>'}).then(r=>console.log(r.status, JSON.stringify(r.data,null,2)))"
+   node -e "require('./scripts/bongos/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/bongos/builders/<id>/status',{status:'active'}).then(r=>console.log(r.status, JSON.stringify(r.data,null,2)))"
+   node -e "require('./scripts/bongos/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.

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

@@ -10,7 +10,7 @@ cost: >-
   Free. It never takes a key in chat; you add keys yourself on the settings page.
 ---
 
-**Script skill (authoritative).** The core action is `node scripts/gds/key-status.js [--recheck]`. Run it and relay its output — the monospace status list, plus the visual callout it emits for any missing key (rendered per the marker convention below).
+**Script skill (authoritative).** The core action is `node scripts/bongos/key-status.js [--recheck]`. Run it and relay its output — the monospace status list, plus the visual callout it emits for any missing key (rendered per the marker convention below).
 
 You are checking the current builder's API-key coverage (today: the art pipeline's Google AI Studio / Gemini key; the script is written to add more keys without new code).
 
@@ -24,15 +24,15 @@ 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/bongos/me/art-key` for each known key.
+1. **List status.** Run `node scripts/bongos/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:
+2. **Missing key → the visual callout fires automatically.** When a key is unset, the script calls `scripts/bongos/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.
    - If you don't have that tool: the monospace card the script already printed IS the summary — relay it as-is.
 
-3. **Drive the UI-first add flow.** Tell the user to click "Add it in Settings ↗" in the card (or open `https://example.com/builders/settings#art-key` themselves). The key syncs to their box automatically at next session start via `scripts/gds/fetch-art-key.js` — no further action needed from you.
+3. **Drive the UI-first add flow.** Tell the user to click "Add it in Settings ↗" in the card (or open `https://example.com/builders/settings#art-key` themselves). The key syncs to their box automatically at next session start via `scripts/bongos/fetch-art-key.js` — no further action needed from you.
 
-4. **Confirm it resolved.** Once the user says they added it, run `node scripts/gds/key-status.js --recheck` — this re-syncs the local session file immediately (rather than waiting for next session start) and re-checks status. Relay the result: resolved (all set) or still missing (point back to step 2/3).
+4. **Confirm it resolved.** Once the user says they added it, run `node scripts/bongos/key-status.js --recheck` — this re-syncs the local session file immediately (rather than waiting for next session start) and re-checks status. Relay the result: resolved (all set) or still missing (point back to step 2/3).
 
 ## Constraints
 
@@ -44,4 +44,4 @@ A key is **never** pasted into chat, and **never** accepted as a CLI argument. T
 
 - Reads: `~/.config/otb/gds-session.json`
 - 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`)
+- Runs: `scripts/bongos/key-status.js`, `scripts/bongos/key-card.js` (via the status script), `scripts/bongos/fetch-art-key.js` (via `--recheck`)

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

@@ -22,7 +22,7 @@ What actually bounds a leaked token is **revocation**, and it is faster than any
 
 1. **Detect.** Run the helper — it checks whether the existing session is still valid and, if not, opens the hall:
    ```bash
-   node scripts/gds/reauth.js
+   node scripts/bongos/reauth.js
    ```
    - **Exit 0** → the session is already valid. Relay who they're signed in as and stop — there is nothing to do. Do NOT re-auth a working session.
    - **Exit 10** → re-auth is needed. The helper has opened (or printed) the builders' hall URL and the click-path. Continue to step 2.
@@ -41,9 +41,9 @@ What actually bounds a leaked token is **revocation**, and it is faster than any
 ## Edge cases
 
 - **"You are not signed in" / `cookie_required`.** The re-issue endpoint mints CLI bearers from a browser *cookie*, not a bearer — a leaked CLI token can't extend its own life. If the Settings page shows them logged out, they sign in at `https://example.com/builders` first, then return to `/builders/settings` and click Re-issue. Once signed in the button works.
-- **No session file at all (fresh machine).** The helper still guides them to the Settings page; if they've never authed on this machine, the hall sign-in + Settings → CLI Access → Re-issue path still works. The terminal Device Flow (`node scripts/gds/setup.js`) remains the fallback for a brand-new builder with no browser session anywhere.
+- **No session file at all (fresh machine).** The helper still guides them to the Settings page; if they've never authed on this machine, the hall sign-in + Settings → CLI Access → Re-issue path still works. The terminal Device Flow (`node scripts/bongos/setup.js`) remains the fallback for a brand-new builder with no browser session anywhere.
 - **Browser can't open automatically** (headless / SSH). The helper prints the URL; relay it so they can open it on whatever machine has their browser, then paste the one-liner back.
-- **Fallback — terminal Device Flow.** If the browser path is unavailable for any reason, `node scripts/gds/setup.js --force` re-auths via GitHub Device Flow (terminal code entry). Slower and not UI-first; use only when the hall route can't be used.
+- **Fallback — terminal Device Flow.** If the browser path is unavailable for any reason, `node scripts/bongos/setup.js --force` re-auths via GitHub Device Flow (terminal code entry). Slower and not UI-first; use only when the hall route can't be used.
 
 ## Constraints
 
@@ -53,7 +53,7 @@ What actually bounds a leaked token is **revocation**, and it is faster than any
 
 ## Files this skill touches
 
-- Runs: `node scripts/gds/reauth.js` (detect + open browser + print click-path)
+- Runs: `node scripts/bongos/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/bongos/me`; the Settings page (CLI Access) calls `POST /api/bongos/auth/cli-token/issue`

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

@@ -56,7 +56,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/bongos/security/reports --body-file <path-to-report.json>
+node scripts/bongos/api.js POST /api/bongos/security/reports --body-file <path-to-report.json>
 ```
 
 where `report.json` is:
@@ -93,7 +93,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/bongos/inbox --body-file <path-to-idea.json>
+node scripts/bongos/api.js POST /api/bongos/inbox --body-file <path-to-idea.json>
 ```
 
 where `idea.json` is:
@@ -113,4 +113,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/bongos/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/bongos/api.js GET /api/bongos/healthz` is the fastest probe (cross-platform; prints the status).

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

@@ -10,13 +10,13 @@ cost: >-
   Free. The task goes back on the list and no credit is paid for it.
 ---
 
-**Script skill (authoritative).** The core action is `node scripts/gds/release.js <task-id> --reason "..."`. Once the task id and reason are determined, run it and print its output verbatim — do not editorialize the result. If the release is refused, the output closes with an `[otb-plain]` card; for a builder whose interaction profile is not `engineer`, tell them what that card says instead of pasting the refusal (the rule is spelled out in `/builder-claim`).
+**Script skill (authoritative).** The core action is `node scripts/bongos/release.js <task-id> --reason "..."`. Once the task id and reason are determined, run it and print its output verbatim — do not editorialize the result. If the release is refused, the output closes with an `[otb-plain]` card; for a builder whose interaction profile is not `engineer`, tell them what that card says instead of pasting the refusal (the rule is spelled out in `/builder-claim`).
 
 You are releasing a task on behalf of the current builder. Releasing is the honest "I started this, but I'm not finishing it right now" exit.
 
 ## What this skill does
 
-Runs `node scripts/gds/release.js <task-id> --reason "..."`.
+Runs `node scripts/bongos/release.js <task-id> --reason "..."`.
 
 The CLI hits `POST /api/bongos/claims/:id/resolve` with `outcome: 'abandoned'`, which transactionally:
 1. Marks the claim `released_at = now`, outcome `abandoned`.
@@ -33,7 +33,7 @@ The task is immediately claimable by another session.
 
 2. **Run**:
    ```bash
-   node scripts/gds/release.js <task-id> --reason "the reason"
+   node scripts/bongos/release.js <task-id> --reason "the reason"
    ```
    Print the output verbatim.
 

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

@@ -23,7 +23,7 @@ This skill owns the **loop and the halt discipline**. It does not re-derive how
 1. **Plan the chain, and show it before starting.**
 
    ```bash
-   node scripts/gds/sequence.js --from <task-id>
+   node scripts/bongos/sequence.js --from <task-id>
    ```
 
    Or `--goal <goal-id>` to scope to a goal's open tasks. This prints the chain in dependency order with total credits and total estimated time. Relay it, and confirm the scope looks right before doing any work — a 24-task chain is not a single sitting, and the user should see the size before you start.
@@ -31,12 +31,12 @@ This skill owns the **loop and the halt discipline**. It does not re-derive how
 2. **Ask for the next task.**
 
    ```bash
-   node scripts/gds/sequence.js --from <head-id> --next
+   node scripts/bongos/sequence.js --from <head-id> --next
    ```
 
    Exit 0 with a task means go. **Exit 1 means halt** — see below. Re-run this each pass rather than working from the step-1 plan: the plan is a snapshot, and shipping changes what is claimable.
 
-3. **Claim it** — `/builder-claim <id>`, or `node scripts/gds/claim.js <id>`.
+3. **Claim it** — `/builder-claim <id>`, or `node scripts/bongos/claim.js <id>`.
 
 4. **Build it** — follow the claimed task's role pack (`docs/packs/engineer.md` for engineer work). Stay strictly inside the task's `touches[]`. Everything the normal task loop requires still applies: read the acceptance criteria, work test-first, commit before shipping.
 
@@ -80,15 +80,15 @@ Between passes, report progress in one line — which task landed, what is next,
 
 Two more halts are yours to detect, not the script's:
 
-- **`ship_failed`** — the ship bounced, the grade failed, or the task did not reach `shipped`. Tell the two non-pass grade shapes apart first: **`GRADER UNAVAILABLE`** (`panel_outcome='unavailable'`) is **not a quality rejection** — the panel could not run, there is nothing to fix, and `node scripts/gds/ship.js <id> --regrade` re-runs the grade once the grader is reachable (a recoverable pause, not a halt). A genuine **`FAIL`** has findings: fix, commit, re-run `node scripts/gds/ship.js <id> --regrade`; if it still will not land, halt and report.
+- **`ship_failed`** — the ship bounced, the grade failed, or the task did not reach `shipped`. Tell the two non-pass grade shapes apart first: **`GRADER UNAVAILABLE`** (`panel_outcome='unavailable'`) is **not a quality rejection** — the panel could not run, there is nothing to fix, and `node scripts/bongos/ship.js <id> --regrade` re-runs the grade once the grader is reachable (a recoverable pause, not a halt). A genuine **`FAIL`** has findings: fix, commit, re-run `node scripts/bongos/ship.js <id> --regrade`; if it still will not land, halt and report.
 - **`scope_surprise`** — the task turns out to need work outside its `touches[]`, or its premise is wrong (the thing it describes is already done, or no longer true). Do not quietly widen the scope; that is a new task.
 
-**On any halt:** leave the current task claimed, stop, and report — what you hit, which task, and what it needs from a human. What it needs from a human is an ask, not prose: write the card, run `node scripts/gds/ask.js check <file>`, paste what it prints (task 1004704). Then say plainly what already landed. Everything shipped stays shipped; a halt costs the rest of the run, not the work done.
+**On any halt:** leave the current task claimed, stop, and report — what you hit, which task, and what it needs from a human. What it needs from a human is an ask, not prose: write the card, run `node scripts/bongos/ask.js check <file>`, paste what it prints (task 1004704). Then say plainly what already landed. Everything shipped stays shipped; a halt costs the rest of the run, not the work done.
 
 To inspect one task without running anything:
 
 ```bash
-node scripts/gds/sequence.js --check <task-id>
+node scripts/bongos/sequence.js --check <task-id>
 ```
 
 ## What NOT to do
@@ -97,7 +97,7 @@ node scripts/gds/sequence.js --check <task-id>
 
 - **Do not skip a halted task and continue down the chain.** The owner chose stop-and-report precisely so a blocked predecessor does not silently strand its dependents.
 - **Do not batch-claim.** See "The one rule".
-- **Do not widen a task's `touches[]`** to make the chain flow. File a new task instead (`node scripts/gds/capture.js`).
+- **Do not widen a task's `touches[]`** to make the chain flow. File a new task instead (`node scripts/bongos/capture.js`).
 - **Do not keep going past the user's stated scope.** `--from` and `--goal` bound the run; when the chain is exhausted, stop and report rather than reaching into the wider backlog.
 - **Do not treat a long chain as a mandate to run unattended forever.** If the remaining estimate is large, say so and let the user decide whether to continue.
 
@@ -114,6 +114,6 @@ 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.
+- Runs: `scripts/bongos/sequence.js` (planning + next + check), then `scripts/bongos/claim.js` and `scripts/bongos/ship.js` per pass.
 - 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

@@ -23,7 +23,7 @@ Before running this skill, **two things must be true**:
 
 ## What this skill does
 
-Runs `node scripts/gds/setup.js`. The script:
+Runs `node scripts/bongos/setup.js`. The script:
 
 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.
@@ -35,13 +35,13 @@ Runs `node scripts/gds/setup.js`. The script:
 
 1. **(Optional) Preview first** with `--dry-run`:
    ```bash
-   node scripts/gds/setup.js --dry-run
+   node scripts/bongos/setup.js --dry-run
    ```
    Prints every step the real run would take — which API endpoints it would hit, where it would write the session file, which TTY prompts it would show — without doing any of them. Recommended for newcomers who want to see what's about to happen before running for real.
 
 2. **Run setup**:
    ```bash
-   node scripts/gds/setup.js
+   node scripts/bongos/setup.js
    ```
    If the user has previously authenticated and just wants to re-auth, add `--force`.
 
@@ -55,7 +55,7 @@ Runs `node scripts/gds/setup.js`. The script:
 
 6. **Suggest next step.** The Xenos path is action-only (#766) — no primer to read first. `setup.js` prints a "Newcomer path" footer (1. choose thy craft · 2. `/builder-start` · 3. `/builder-claim N` → `/builder-ship` · 4. ship three works and you rise to Thetes); relay it verbatim instead of paraphrasing. For a returning builder (rank ≥ Metic), `setup.js` prints no newcomer footer and `/builder-start` is the right immediate next step.
 
-7. **If they will do UI work, name the one extra step.** The design skills `/design` sends a session to use (`impeccable`, the taste and look skills) are module-owned and are not in a fresh core checkout: claiming a `ui` task lands them automatically, or `node scripts/gds/claude-materialize.js --module-skills-only` puts them there now (untracked copies, `--clean` removes them; ADR 0224).
+7. **If they will do UI work, name the one extra step.** The design skills `/design` sends a session to use (`impeccable`, the taste and look skills) are module-owned and are not in a fresh core checkout: claiming a `ui` task lands them automatically, or `node scripts/bongos/claude-materialize.js --module-skills-only` puts them there now (untracked copies, `--clean` removes them; ADR 0224).
 
 ## Constraints