@bongos/core 1.19.804 → 1.19.806

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

@@ -10,11 +10,11 @@ You are running the **goal-create** session for this Cloud Bongos instance. You
 
 ## Rank gate — Metic+ only
 
-**Gated to Metic+ (Metic, Archon); not Xenos.** Creating a goal sets a **scope wall** — the module keys its members may author inside — and seeds the criteria a slice of the version will be judged against. That is a trusted-builder operation (ADR 0086 §3/§4). The server enforces it: `POST /api/gds/goals` is `requireRank('metic','archon')`, and `POST /api/gds/versions/:id/done-when` is `requireRank('metic','archon')` **plus a goal-ownership wall** (ADR 0154) — both pinned in `route-rank-check.MODULE_EXPECTED_RANKS.lifecycle`. This check just stops a Xenos early instead of after a wall of 403s. Markdown never grants authority ([`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0016](../../../docs/adr/0016-trust-boundary-server-enforced-permissions.md)).
+**Gated to Metic+ (Metic, Archon); not Xenos.** Creating a goal sets a **scope wall** — the module keys its members may author inside — and seeds the criteria a slice of the version will be judged against. That is a trusted-builder operation (ADR 0086 §3/§4). The server enforces it: `POST /api/bongos/goals` is `requireRank('metic','archon')`, and `POST /api/bongos/versions/:id/done-when` is `requireRank('metic','archon')` **plus a goal-ownership wall** (ADR 0154) — both pinned in `route-rank-check.MODULE_EXPECTED_RANKS.lifecycle`. This check just stops a Xenos early instead of after a wall of 403s. Markdown never grants authority ([`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0016](../../../docs/adr/0016-trust-boundary-server-enforced-permissions.md)).
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 
-1. Call `node scripts/gds/api.js GET /api/gds/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
+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.
 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.
@@ -32,9 +32,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/gds/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/gds/goals?version=<ver>&status=open"`, then `GET /api/gds/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/gds/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/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 module roster — LIVE, never from memory and never from this file:**
 
   ```
@@ -43,7 +43,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/gds/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/gds/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)
 
@@ -52,7 +52,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/gds/tasks/<task_id> --body '{"goal_id":<gid>}'   # ids only — safe inline
+node scripts/gds/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.
@@ -64,7 +64,7 @@ Everything here is your call. It is presented in Phase 4 as a proposal, not as q
 - **Title** — the outcome the goal owns, not a task list. One line.
 - **`description`** — 2–4 sentences: what is true when this goal is achieved, and what it explicitly does not cover.
 - **`scope_modules`** — infer from the planned work's file paths, then **verify every key against `moduleKeys()`**. An unknown key is a hard `400 unknown_module` (the response helpfully returns the full valid roster). Keep it tight: the wall is set here and only here. **No covering key?** Do not invent one — file a `kind='refactor'` prep task scoped to `kernel` to extend `MODULE_GLOBS`, and make this goal's tasks depend on it.
-- **`category_id`** — the goal's HUMAN category (task 1003277; ADR 0192 — advisory, it gates nothing). Read the live set with `GET /api/gds/work-categories` (never hard-code the labels), infer the best fit from the goal's outcome and its `scope_modules`, and state your pick in the Phase-4 approval round like every other drafted field. **When nothing in the set fits, that is a designed prompt, not an error**: do NOT silently pick the nearest, and do NOT leave it null and move on — surface the gap in the gray-area round and offer to create a new category (`POST /api/gds/work-categories` with `{"label":"..."}`; a duplicate slug converges on the existing row), then use it. Creating uncategorised stays legal — if the user declines to name one, POST the goal without `category_id` and note that the 201 body will carry a `category_advisory` reminding whoever looks next.
+- **`category_id`** — the goal's HUMAN category (task 1003277; ADR 0192 — advisory, it gates nothing). Read the live set with `GET /api/bongos/work-categories` (never hard-code the labels), infer the best fit from the goal's outcome and its `scope_modules`, and state your pick in the Phase-4 approval round like every other drafted field. **When nothing in the set fits, that is a designed prompt, not an error**: do NOT silently pick the nearest, and do NOT leave it null and move on — surface the gap in the gray-area round and offer to create a new category (`POST /api/bongos/work-categories` with `{"label":"..."}`; a duplicate slug converges on the existing row), then use it. Creating uncategorised stays legal — if the user declines to name one, POST the goal without `category_id` and note that the 201 body will carry a `category_advisory` reminding whoever looks next.
 - **`succeeds_goal_id`** — set it when carrying an achieved goal forward. `POST /goals` validates the predecessor exists *before* creating, so a bad ref can't orphan a goal; it then stamps the predecessor's `succeeded_by_goal_id`. Archiving the predecessor is a **separate** call.
 - **Criteria — 2 to 4.** A goal's criteria are narrower than a version's: each should plausibly anchor 2–5 tasks. Draft `criterion_id` as a stable kebab slug (position-independent, and what `criterion_ids` on `POST /tasks` should reference); `criterion_md` is the outcome prose.
 - **Seed tasks — 3 to 8.** Per criterion, with `kind`, a one-line done-when, `criterion_ids: ["<slug>"]`, and dependency edges. Omit `touches[]` (advisory, ADR 0049 — backfilled from the real diff at ship). Never hand-set `requires_rank`: it auto-derives (ADR 0084) from `needs_migration` and the goal's own scope wall, neither of which needs a prediction (ADR 0270). **Do set `needs_migration: true` on any task that will alter the live database** — it is the input that floors such a task at Metic, and omitting it is how a schema change lands in the open queue. Proof tasks use `kind='verify'`; exploration uses `kind='spike'` (and spikes are deliberately left in backlog).
@@ -87,24 +87,24 @@ The order is forced: a criterion needs `goal_id`, a task needs both `goal_id` an
 #      (version_id*, title*, subtitle, description, scope_modules[], succeeds_goal_id, category_id).
 #      ANY other key is a 400 unknown_field — do NOT pass criteria, tasks, lead or visibility.
 #   goal.json: {"version_id":"<ver>","title":"...","description":"...","scope_modules":["<key>"],"category_id":<id>}
-#   category_id comes from GET /api/gds/work-categories (task 1003277); omitting it is
+#   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/gds/goals --body-file <path-to-goal.json>
+node scripts/gds/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/gds/versions/<ver>/done-when --body-file <path-to-criterion.json>
+node scripts/gds/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/gds/tasks --body-file <path-to-task.json>
+node scripts/gds/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##"}
@@ -114,16 +114,16 @@ node scripts/gds/api.js POST /api/gds/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/gds/tasks/<id>/dependencies --body '{"depends_on_task_id":<id>}'  # ids only
+node scripts/gds/api.js POST /api/bongos/tasks/<id>/dependencies --body '{"depends_on_task_id":<id>}'  # ids only
 
 # 5e — promote the zero-dependency layer. Every new task lands status='backlog', and
 #      auto-promotion only fires when a DEPENDENCY ships — so a task with no deps would
 #      sit unclaimable forever. Leave spikes in backlog.
-node scripts/gds/api.js POST /api/gds/tasks/<id>/promote
+node scripts/gds/api.js POST /api/bongos/tasks/<id>/promote
 
 # 6 — verify + report.
-node scripts/gds/api.js GET /api/gds/goals/<gid>            # {goal, members, criteria, dependencies}
-node scripts/gds/api.js GET "/api/gds/tasks?goal_id=<gid>"
+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>"
 ```
 
 ### Protected scope — the Archon off-ramps
@@ -148,8 +148,8 @@ When `POST /tasks` came back with a non-null **`goal_advisory`**, you were invok
 
 Run the phases above **with the orphan task as the seed** — its title, description and touches are your best evidence for the goal's title and `scope_modules`. Two shortcuts:
 
-- **Prefer reuse.** `goal_advisory.candidate_goals` already lists the version's open goals with the catch-all excluded. Check each with `GET "/api/gds/goals/<id>/suggest-criteria?title=<t>&description=<d>"` — a strong criterion match means the task belongs there and no new goal is needed. Move it with `PATCH /tasks/<id> {"goal_id":<gid>}`.
-- **If you do create a goal, re-home the orphan into it** (same PATCH) and link the criterion: `POST /api/gds/tasks/<task_id>/criteria --body '{"criterion_ids":["<slug>"]}'` (slugs are kebab-case, so inline is safe). Do **not** delete and recreate the task — you would lose its id, `source_ref` and any votes.
+- **Prefer reuse.** `goal_advisory.candidate_goals` already lists the version's open goals with the catch-all excluded. Check each with `GET "/api/bongos/goals/<id>/suggest-criteria?title=<t>&description=<d>"` — a strong criterion match means the task belongs there and no new goal is needed. Move it with `PATCH /tasks/<id> {"goal_id":<gid>}`.
+- **If you do create a goal, re-home the orphan into it** (same PATCH) and link the criterion: `POST /api/bongos/tasks/<task_id>/criteria --body '{"criterion_ids":["<slug>"]}'` (slugs are kebab-case, so inline is safe). Do **not** delete and recreate the task — you would lose its id, `source_ref` and any votes.
 
 **A goal-less task is not an error and was never blocked.** `goal_advisory` is advice on a request that already succeeded. Never fail a build, refuse work, or badger the builder over it — if they say "later", file the idea and move on.
 

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

@@ -25,27 +25,27 @@ A criterion sitting here with shipped tasks and no explanation means the sweep h
 
 ## Rank gate — Metic+ only
 
-**Gated to Metic+ (Metic, Archon); not Xenos.** Confirming a criterion sets `satisfied=true` and can auto-achieve a goal — a trusted-builder operation that closes out a slice of a version (the "who confirms" resolution in ADR 0086 §6: the planner, not only the Archon). The server enforces this — `POST /api/gds/done-when/:criterionId/satisfy` is `requireRank('metic','archon')` and pinned in `route-rank-check.MODULE_EXPECTED_RANKS.lifecycle` — so this check just stops a Xenos early instead of after a wall of 403s. Markdown never grants authority ([`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0016](../../../docs/adr/0016-trust-boundary-server-enforced-permissions.md)).
+**Gated to Metic+ (Metic, Archon); not Xenos.** Confirming a criterion sets `satisfied=true` and can auto-achieve a goal — a trusted-builder operation that closes out a slice of a version (the "who confirms" resolution in ADR 0086 §6: the planner, not only the Archon). The server enforces this — `POST /api/bongos/done-when/:criterionId/satisfy` is `requireRank('metic','archon')` and pinned in `route-rank-check.MODULE_EXPECTED_RANKS.lifecycle` — so this check just stops a Xenos early instead of after a wall of 403s. Markdown never grants authority ([`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0016](../../../docs/adr/0016-trust-boundary-server-enforced-permissions.md)).
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 
-1. Call `node scripts/gds/api.js GET /api/gds/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
+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: *"Goal review is a Metic+ operation — confirming a criterion closes out a slice of a version and can auto-achieve a goal. You're currently Xenos. Ask an Archon to promote you if you need to confirm criteria."* Do not list the queue, do not propose verdicts.
 3. **If `rank` lowercases to `metic` or `archon`** → proceed with the steps 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.
 
 ## What this skill does
 
-1. Lists flagged criteria via `GET /api/gds/done-when/pending-review` (optionally `?version=<id>`).
+1. Lists flagged criteria via `GET /api/bongos/done-when/pending-review` (optionally `?version=<id>`).
 2. For each, prompts the user with: **confirm** (the criterion is genuinely met → mark satisfied), **reject** (the tasks shipped but the criterion is NOT actually met → leave it open and capture why), or **note / defer** (leave it flagged; it resurfaces next session).
-3. Applies confirm via `POST /api/gds/done-when/:criterionId/satisfy` — and reports any goal that auto-achieved as a result.
+3. Applies confirm via `POST /api/bongos/done-when/:criterionId/satisfy` — and reports any goal that auto-achieved as a result.
 
 ## How to use
 
 **Step 1 — fetch the review queue.**
 
 ```
-node scripts/gds/api.js GET /api/gds/done-when/pending-review
+node scripts/gds/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.)
@@ -69,9 +69,9 @@ Then ask the user (concise; frame in product/outcome terms — Lars is an EE, no
 **Confirm** → mark it satisfied. Optionally pass the ship-task that fulfilled it:
 
 ```
-node scripts/gds/api.js POST /api/gds/done-when/<criterion_id>/satisfy --body '{}'
+node scripts/gds/api.js POST /api/bongos/done-when/<criterion_id>/satisfy --body '{}'
 # or, to record which task fulfilled it:
-node scripts/gds/api.js POST /api/gds/done-when/<criterion_id>/satisfy --body '{"satisfied_by_task_id":<task_id>}'
+node scripts/gds/api.js POST /api/bongos/done-when/<criterion_id>/satisfy --body '{"satisfied_by_task_id":<task_id>}'
 ```
 
 The response is `{ criterion, goal_achieved, goal }`. **If `goal_achieved` is true**, announce it: *"🎯 Goal '{goal.title}' is now achieved — all its criteria are confirmed."* (That goal now awaits disposition — see Step 4.)

package/.claude/skills/grade-audit/SKILL.md

@@ -9,13 +9,13 @@ You are auditing the last week of grades for accountability gaps: work that ship
 ## The sweep window
 
 ```bash
-node scripts/gds/api.js GET "/api/gds/public/recent-shipped?days=7"
+node scripts/gds/api.js GET "/api/bongos/public/recent-shipped?days=7"
 ```
 
 For each shipped task in the window, read its persisted grade:
 
 ```bash
-node scripts/gds/api.js GET "/api/gds/tasks/<id>?include=grade"
+node scripts/gds/api.js GET "/api/bongos/tasks/<id>?include=grade"
 ```
 
 Bucket by grade shape: `passed`, failed, `signals.panel_outcome='unavailable'` (outage — no quality signal existed), or no grade row at all.
@@ -25,7 +25,7 @@ Bucket by grade shape: `passed`, failed, `signals.panel_outcome='unavailable'` (
 For every shipped task whose grade **failed** (or is absent), the land needed an override. Cross-reference the ledger (Archon — `override_request.decide`):
 
 ```bash
-node scripts/gds/api.js GET "/api/gds/override-requests?status=approved"
+node scripts/gds/api.js GET "/api/bongos/override-requests?status=approved"
 ```
 
 - Split **infra vs real** first: a fail that is actually `panel_outcome='unavailable'` (or the errored-worker zero-issue shape) is an outage artifact, not an overridden quality verdict — route those to the Leg 4 roll-up.
@@ -37,7 +37,7 @@ node scripts/gds/api.js GET "/api/gds/override-requests?status=approved"
 A pass with `blocker`/`major` entries in `issues[]` shipped real findings that no process ever picks up (the evaluation counted 274 findings on passing ships with zero conversion paths). For each:
 
 - **Worker-attribution filter:** findings attributed to the advisory **Narc** are the known noise class — triage them by hand (read the finding, decide), never auto-trust them into the queue. Findings from the gating workers (Quality, Hacker, Efficiency) or the deterministic pre-passes are higher-confidence — queue them unless plainly stale.
-- **Queueing rule (idempotent):** first read the open inbox (`node scripts/gds/api.js GET /api/gds/inbox`) and skip any finding already queued — the marker is the deterministic title prefix. Then:
+- **Queueing rule (idempotent):** first read the open inbox (`node scripts/gds/api.js GET /api/bongos/inbox`) and skip any finding already queued — the marker is the deterministic title prefix. Then:
 
 ```bash
 node scripts/gds/capture.js "[grade-audit] task <id>: <finding summary>" --kind bug
@@ -73,6 +73,6 @@ A clean week is four one-liners.
 
 ## Files this skill touches
 
-- Reads: `GET /api/gds/public/recent-shipped`, `GET /api/gds/tasks/:id?include=grade`, `GET /api/gds/override-requests?status=approved` (Archon), `GET /api/gds/inbox`.
+- Reads: `GET /api/bongos/public/recent-shipped`, `GET /api/bongos/tasks/:id?include=grade`, `GET /api/bongos/override-requests?status=approved` (Archon), `GET /api/bongos/inbox`.
 - Writes: `idea_inbox` rows via `node scripts/gds/capture.js` (queued follow-ups only).
 - Never calls: any confirm, status, grade, or regrade endpoint.

package/.claude/skills/grade-recover/SKILL.md

@@ -19,7 +19,7 @@ node scripts/gds/ship.js <id> --regrade
 ## Step 1 — Read the grade
 
 ```bash
-node scripts/gds/api.js GET "/api/gds/tasks/<id>?include=grade,last_claim"
+node scripts/gds/api.js GET "/api/bongos/tasks/<id>?include=grade,last_claim"
 ```
 
 - Task not at `completed` → stop; there is nothing to recover. `confirmed`/`shipped` means the grade passed (a `confirmed` strand lands via the ~5-min reconciler; `/merge-mode` is the rare manual fallback). `active` means ship first.
@@ -46,7 +46,7 @@ Two known sub-shapes, both recognizable because the "fail" carries **no substant
 If an honest re-grade re-trips the guard on a diff you can defend, use the **auditable override path** — file an override-request with a real rationale (≥20 chars; only the task's most-recent claim holder or an Archon may file; an Archon then decides it):
 
 ```bash
-node scripts/gds/api.js POST /api/gds/tasks/<id>/override-request --body '{"rationale":"<why this grade is wrong, specifically>"}'
+node scripts/gds/api.js POST /api/bongos/tasks/<id>/override-request --body '{"rationale":"<why this grade is wrong, specifically>"}'
 ```
 
 **Never volunteer the raw Archon confirm curl.** The override-request is the sanctioned exit precisely because it records who asked, why, and who decided — the raw confirm records none of that.
@@ -79,6 +79,6 @@ A grade block naming protected surfaces above your rank is an authorization wall
 
 ## Files this skill touches
 
-- Reads: `GET /api/gds/tasks/:id?include=grade,last_claim` (the persisted grade row + regrade eligibility).
+- Reads: `GET /api/bongos/tasks/:id?include=grade,last_claim` (the persisted grade row + regrade eligibility).
 - Runs: `node scripts/gds/ship.js <id> --regrade` (the grade step only).
-- Writes (Branch B escalation only): `POST /api/gds/tasks/:id/override-request`.
+- Writes (Branch B escalation only): `POST /api/bongos/tasks/:id/override-request`.

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

@@ -12,9 +12,9 @@ You are running a health check over the grading panel. Everything here is **read
 
 A grader outage used to be recorded as a 0.0 "quality failure": one builder accumulated **21 zero-score rows** over a month before anyone noticed, and the public tile showed a phantom 5-day 0%-pass crater. Since the outage-as-zero fix, aggregates exclude outage rounds and bucket them as `n_unavailable` — so the streak is now directly readable.
 
-1. Read the public trend: `node scripts/gds/api.js GET "/api/gds/public/grades?days=30"` — scan `trend[]` for days where the average is 0 (or null) with passes 0 and n ≥ 2, and for any nonzero `n_unavailable` streak.
-2. (Archon) Read the per-builder split: `node scripts/gds/api.js GET "/api/gds/grades/by-builder?days=30"` — a single builder with pass_rate 0.000 or a large `n_unavailable` bucket is the 21×0.0 shape localized to one machine or one environment.
-3. **Confirm outage vs rejection before alarming anyone.** For each task in a suspect window: `node scripts/gds/api.js GET "/api/gds/tasks/<id>?include=grade"` — `signals.panel_outcome='unavailable'` (with `grader_unavailable_reason` and per-worker errors in `signals.workers`) is an outage, **not a quality rejection**; a real FAIL carries findings in `issues[]`.
+1. Read the public trend: `node scripts/gds/api.js GET "/api/bongos/public/grades?days=30"` — scan `trend[]` for days where the average is 0 (or null) with passes 0 and n ≥ 2, and for any nonzero `n_unavailable` streak.
+2. (Archon) Read the per-builder split: `node scripts/gds/api.js GET "/api/bongos/grades/by-builder?days=30"` — a single builder with pass_rate 0.000 or a large `n_unavailable` bucket is the 21×0.0 shape localized to one machine or one environment.
+3. **Confirm outage vs rejection before alarming anyone.** For each task in a suspect window: `node scripts/gds/api.js GET "/api/bongos/tasks/<id>?include=grade"` — `signals.panel_outcome='unavailable'` (with `grader_unavailable_reason` and per-worker errors in `signals.workers`) is an outage, **not a quality rejection**; a real FAIL carries findings in `issues[]`.
 4. For every task parked at `completed` by a confirmed outage, emit the exact remediation line, one per task:
 
 ```bash
@@ -25,7 +25,7 @@ node scripts/gds/ship.js <id> --regrade
 
 ### 2 — Pass-rate drift
 
-Baselines: the 14-agent evaluation window measured a **90.6%** pass rate, already above the 87% that ADR 0024 called "suspiciously high" and built the adversarial panel to fix. From `/api/gds/public/grades` compute the rolling pass rate and compare:
+Baselines: the 14-agent evaluation window measured a **90.6%** pass rate, already above the 87% that ADR 0024 called "suspiciously high" and built the adversarial panel to fix. From `/api/bongos/public/grades` compute the rolling pass rate and compare:
 
 - **Creeping up** past the baseline → grade inflation; the panel is rubber-stamping (report; candidate causes: score compression, reused grades, trivial-path overuse).
 - **Collapsing** far below it → either a real quality regression or an unconfirmed outage window — axis 1 disambiguates.
@@ -35,7 +35,7 @@ Baselines: the 14-agent evaluation window measured a **90.6%** pass rate, alread
 Benchmark: mean panel cost **$2.14** per grade, and ~90% of it is **fixed** re-exploration cost, independent of diff size. (Measured with Quality on the haiku tier; since task 1003318 Quality runs on claude-sonnet-5, so a mean sitting somewhat above $2.14 is the new normal until re-baselined — a rise alone is not an anomaly.) Read grader spend and divide by the grade count from axis 2's window:
 
 ```
-node scripts/gds/api.js GET "/api/gds/public/cost-summary?source=grader&days=30" --quiet \
+node scripts/gds/api.js GET "/api/bongos/public/cost-summary?source=grader&days=30" --quiet \
   | node -e "let s='';process.stdin.on('data',d=>s+=d).on('end',()=>{const j=JSON.parse(s);
       if(j.applied_filters?.source!=='grader'){console.error('FILTER DROPPED — do not divide');process.exit(1)}
       console.log('grader 30d:', j.filtered_total_usd)})"
@@ -66,6 +66,6 @@ End with a compact findings list, most severe first: axis, evidence (the numbers
 
 ## Files this skill touches
 
-- Reads: `GET /api/gds/public/grades`, `GET /api/gds/grades/by-builder` (Archon), `GET /api/gds/public/cost-summary?source=grader` (the `filtered_total_usd` key), `GET /api/gds/tasks/:id?include=grade`, `modules/grading/grader.js`, `modules/grading/grader-rubric.json`.
+- Reads: `GET /api/bongos/public/grades`, `GET /api/bongos/grades/by-builder` (Archon), `GET /api/bongos/public/cost-summary?source=grader` (the `filtered_total_usd` key), `GET /api/bongos/tasks/:id?include=grade`, `modules/grading/grader.js`, `modules/grading/grader-rubric.json`.
 - Runs (read-only): `node scripts/gds/doctor.js`; with `--probe` only: `node scripts/gds/grade-smoke.js`.
 - Writes: nothing.

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

@@ -55,12 +55,12 @@ capture-time suggester (R08/R09/R11 surfaces) is where the fix belongs.
 
 ## Rank gate — Metic+ only
 
-**Gated to Metic+ (Metic, Archon); not Xenos.** Triage verdicts (promote, discard, merge) reshape the team's backlog — a trusted-builder operation (GDS-V3 criterion C2, `three-ranks-gate-everything`; [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0018](../../../docs/adr/0018-three-rank-model-goes-live.md)). A Xenos can still **file** an idea (`POST /api/gds/inbox`); they just can't verdict them.
+**Gated to Metic+ (Metic, Archon); not Xenos.** Triage verdicts (promote, discard, merge) reshape the team's backlog — a trusted-builder operation (GDS-V3 criterion C2, `three-ranks-gate-everything`; [`docs/canonical-permissions.md`](../../../docs/canonical-permissions.md), [ADR 0018](../../../docs/adr/0018-three-rank-model-goes-live.md)). A Xenos can still **file** an idea (`POST /api/bongos/inbox`); they just can't verdict them.
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 
-1. Call `GET /api/gds/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
-2. **If `rank` is present and lowercases to `xenos`** → stop immediately. Tell the builder: *"Idea triage is a Metic+ operation — promoting, discarding, or merging an idea reshapes the team's backlog. You're currently Xenos. You can still file a new idea via `POST /api/gds/inbox`; ask an Archon to promote you if you need to triage them."* Do not list open ideas, do not propose verdicts.
+1. Call `GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
+2. **If `rank` is present and lowercases to `xenos`** → stop immediately. Tell the builder: *"Idea triage is a Metic+ operation — promoting, discarding, or merging an idea reshapes the team's backlog. You're currently Xenos. You can still file a new idea via `POST /api/bongos/inbox`; ask an Archon to promote you if you need to triage them."* Do not list open ideas, do not propose verdicts.
 3. **If `rank` lowercases to `metic` or `archon`** → proceed with the steps below.
 4. **If `rank` is absent** (the GET /me response has no `rank` field — only possible against a deployment where the three-rank model hasn't shipped yet): treat the session as available, exactly as `/planning-session` and `/priority-session` do in their pre-rank passthrough mode. Note in the session log that the gate ran in pre-rank passthrough mode.
 
@@ -68,18 +68,18 @@ capture-time suggester (R08/R09/R11 surfaces) is where the fix belongs.
 
 ## What this skill does
 
-1. Lists open ideas via `GET /api/gds/inbox`.
+1. Lists open ideas via `GET /api/bongos/inbox`.
 2. **Batches near-duplicate ideas** into one verdict per cluster (`node scripts/gds/triage.js`'s `clusterIdeas`), so a backlog of similar asks doesn't cost one decision each (task 1001465).
 3. **Develops what's left with a LEAN inline pass by default** — reasoning from context already in the session, no subagent spend — and escalates to a FEW targeted subagents only where repo grounding would actually flip the verdict (task 1001465; the old unconditional 12-subagent fan-out is now opt-in, task 930's original mechanism).
 4. For each, prompts the user with: **promote** (create a task and link it), **discard** (closed, no action), or **merge** (this duplicates idea N, mark merged into N).
-5. Updates each idea via `PATCH /api/gds/inbox/:id` with the verdict.
+5. Updates each idea via `PATCH /api/bongos/inbox/:id` with the verdict.
 
 ## How to use
 
 **Step 1 — fetch the open inbox.**
 
 ```
-node scripts/gds/api.js GET /api/gds/inbox
+node scripts/gds/api.js GET /api/bongos/inbox
 ```
 
 (`api.js` is the cross-platform Bongos API helper — it signs the request with your
@@ -216,28 +216,28 @@ at the triage end, where the judgement is.)
 
 **Promote → pick the tier (BV1.R64 / ADR 0086).** An idea no longer only becomes a *task* — it can promote into any tier of the work hierarchy: a **goal** (a whole module-scoped workspace), a **criterion** (a new done-when test), or a **task** (a single unit of work). Choose by the idea's size: a broad objective → goal; a "we should also require X to be done" → criterion; a concrete piece of work → task. Frame the choice to the user in those terms, then create the right record and mark the idea promoted.
 
-- **Promote → task** (the common case). Ask for version, title, est_minutes, priority, credits_reward (`touches[]` optional — [ADR 0049](../../../docs/adr/0049-split-parallel-safety-contract.md)). `POST /api/gds/tasks` lands the new task in `backlog`, **not** `active` — it still needs `POST /tasks/:id/promote` (Metic+) before it's claimable. **Pass `goal_id` on the create** so the task lands in a real goal rather than the version's `"<version> — general"` catch-all — `POST /tasks` has accepted it since task 1763, and the 201 now returns a `goal_advisory` when the task ends up with no proper home. If no existing goal fits, run [`/goal-create`](../goal-create/SKILL.md) instead of filing it loose.
+- **Promote → task** (the common case). Ask for version, title, est_minutes, priority, credits_reward (`touches[]` optional — [ADR 0049](../../../docs/adr/0049-split-parallel-safety-contract.md)). `POST /api/bongos/tasks` lands the new task in `backlog`, **not** `active` — it still needs `POST /tasks/:id/promote` (Metic+) before it's claimable. **Pass `goal_id` on the create** so the task lands in a real goal rather than the version's `"<version> — general"` catch-all — `POST /tasks` has accepted it since task 1763, and the 201 now returns a `goal_advisory` when the task ends up with no proper home. If no existing goal fits, run [`/goal-create`](../goal-create/SKILL.md) instead of filing it loose.
 
   ```
   # 1. Create the task (--body-file avoids shell-quoting the touches[]/description).
-  node scripts/gds/api.js POST /api/gds/tasks --body-file <path-to-task.json>
+  node scripts/gds/api.js POST /api/bongos/tasks --body-file <path-to-task.json>
   #    task.json: {"version_id":"...","title":"...","description":"...","touches":[...],
   #    "est_minutes":N,"priority":N,"credits_reward":N,"source":"idea_inbox","source_ref":"idea:<idea_id>"}
   # 2. Mark the idea promoted, pointing promoted_to_task_id at the new task id.
-  node scripts/gds/api.js PATCH /api/gds/inbox/<idea_id> --body '{"status":"promoted","promoted_to_task_id":<new_task_id>}'
+  node scripts/gds/api.js PATCH /api/bongos/inbox/<idea_id> --body '{"status":"promoted","promoted_to_task_id":<new_task_id>}'
   ```
 
 - **Promote → goal** (Metic+; Archon if the scope includes a `protected` module). For anything needing criteria and seed tasks, run [`/goal-create`](../goal-create/SKILL.md) — it does the reuse-vs-new check, the scope wall and the sign-off. The bare one-liner below is fine only for a goal you are deliberately leaving empty. Create the goal, then mark the idea promoted — `promoted_to_task_id` stays NULL (a goal isn't a task; note the new goal id in the session log, mirroring how criterion-promotion records its link).
 
   ```
-  node scripts/gds/api.js POST /api/gds/goals --body '{"version_id":"<ver>","title":"...","description":"from idea #<idea_id>","scope_modules":["<module-key>", ...]}'
-  node scripts/gds/api.js PATCH /api/gds/inbox/<idea_id> --body '{"status":"promoted"}'
+  node scripts/gds/api.js POST /api/bongos/goals --body '{"version_id":"<ver>","title":"...","description":"from idea #<idea_id>","scope_modules":["<module-key>", ...]}'
+  node scripts/gds/api.js PATCH /api/bongos/inbox/<idea_id> --body '{"status":"promoted"}'
   ```
 
 - **Promote → criterion** (Metic+ — `idea.ratify`, metic-floored since ADR 0157; done-when writes are scope-shaping, criterion C2). This reuses the existing ratify path: the idea must be `kind='criterion-proposal'` with a `body_md` JSON of `{target_version, criterion_md, sort_order_hint}` (the `/planning-session` shape). One atomic call both inserts the criterion and marks the idea promoted:
 
   ```
-  node scripts/gds/api.js POST /api/gds/inbox/<idea_id>/ratify --body '{"notes_md":"ratified via idea-triage"}'
+  node scripts/gds/api.js POST /api/bongos/inbox/<idea_id>/ratify --body '{"notes_md":"ratified via idea-triage"}'
   ```
 
   If the idea isn't already criterion-proposal-shaped, either re-file it in that shape or promote it to a task/goal instead — don't hand-write a `done_when_criteria` row.
@@ -245,13 +245,13 @@ at the triage end, where the judgement is.)
 **Discard** → mark it closed, with the reason (`triage_note`, task 1002447 / migration core_195 — a discard with no reason is a verdict nobody can audit):
 
 ```
-node scripts/gds/api.js PATCH /api/gds/inbox/<idea_id> --body '{"status":"discarded","triage_note":"superseded by the new gate"}'
+node scripts/gds/api.js PATCH /api/bongos/inbox/<idea_id> --body '{"status":"discarded","triage_note":"superseded by the new gate"}'
 ```
 
 **Merge** → ask the user which other idea N is the canonical one, then fold this one into it:
 
 ```
-node scripts/gds/api.js PATCH /api/gds/inbox/<idea_id> --body '{"status":"merged","merged_into_idea_id":<canonical_idea_id>,"triage_note":"same ask as #N"}'
+node scripts/gds/api.js PATCH /api/bongos/inbox/<idea_id> --body '{"status":"merged","merged_into_idea_id":<canonical_idea_id>,"triage_note":"same ask as #N"}'
 ```
 
 > **`merged_into_idea_id`, NOT `promoted_to_task_id`.** This skill used to document the latter; that column is `REFERENCES tasks(id)`, so an idea id written there either trips the FK (a 500) or silently points at an unrelated task that happens to share the number. Task 1002447 added the real column. The server refuses a self-merge (`MERGE_SELF`), a target that doesn't exist (`MERGE_TARGET_NOT_FOUND`), and a target that is itself merged (`MERGE_TARGET_MERGED` — it names where the chain ends, so retarget there).

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

@@ -15,7 +15,7 @@ The queue this skill works against is **tasks at status='confirmed'**. Those are
 2. For each, finds the branch (`claude/<worktree_name>` from the claim).
 3. Merges in order (independent first, then conflict-prone), resolves conflicts manually with the user. **The `git merge` is itself the collision detector** — the predictive touches[] drift scanner was deleted (touches[] cleanup [4/8], task 879); a real conflict surfaces here, at the authoritative moment, not as an up-front prediction.
 4. After all merges: smoke + push + deploy.
-5. For each merged task, calls `POST /api/gds/tasks/:id/ship` to flip the task from `confirmed` → `shipped`.
+5. For each merged task, calls `POST /api/bongos/tasks/:id/ship` to flip the task from `confirmed` → `shipped`.
 
 ## How to use
 
@@ -44,7 +44,7 @@ stopped the run (task 1003167).
 **Step 1 — list the queue: tasks at confirmed.**
 
 ```
-node scripts/gds/api.js GET "/api/gds/tasks?status=confirmed"
+node scripts/gds/api.js GET "/api/bongos/tasks?status=confirmed"
 ```
 
 If the list is empty, print "no tasks at confirmed — auto-merge in /builder-ship handled them all" and exit.
@@ -160,7 +160,7 @@ This is mandatory on every exit path — including aborts and conflicts you deci
 For each task that successfully merged + deployed:
 
 ```
-node scripts/gds/api.js POST /api/gds/tasks/<task-id>/ship
+node scripts/gds/api.js POST /api/bongos/tasks/<task-id>/ship
 ```
 
 The `POST /tasks/:id/ship` endpoint flips the task to `shipped`, stamps `shipped_at`. **This is the credit moment** — [ADR 0120](../../../docs/adr/0120-pay-on-land-and-builder-owned-rebase-gate.md) books the reward on land, so this call is what pays the builder (on a `cost-plus-only` instance like Cloud Bongos that is the cost-plus session reward only — the per-task estimate is never paid; [ADR 0146](../../../docs/adr/<redacted><redacted>.md)).

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

@@ -33,11 +33,11 @@ This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`) and matches the
 
 **Enforce the gate at the very top of the session, before reading anything else:**
 
-1. Call `GET /api/gds/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
-2. **If `rank` is present and lowercases to `xenos`** → stop immediately. Tell the builder: *"Planning sessions set the scope-truth of a version — they're a Metic+ operation. You're currently Xenos. You can still **file** a criterion proposal or task idea via `POST /api/gds/inbox` (which lands in idea_inbox for a Metic+ builder to ratify at the next planning session); ask an Archon for promotion if you need to run sessions directly."* Do not pull state, do not present criteria, do not propose tasks.
+1. Call `GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing).
+2. **If `rank` is present and lowercases to `xenos`** → stop immediately. Tell the builder: *"Planning sessions set the scope-truth of a version — they're a Metic+ operation. You're currently Xenos. You can still **file** a criterion proposal or task idea via `POST /api/bongos/inbox` (which lands in idea_inbox for a Metic+ builder to ratify at the next planning session); ask an Archon for promotion if you need to run sessions directly."* Do not pull state, do not present criteria, do not propose tasks.
 3. **If `rank` lowercases to `metic`** → proceed in **Metic-mode**: run the five-phase structure below conversationally, but in Phase 5 write proposals to `idea_inbox` (kind=`criterion-proposal` for criteria, kind=`feature` for tasks) tagged with the target version. Any Metic+ builder ratifies them (`idea.ratify`, metic-floored since ADR 0157) — typically at the next planning session. Since [ADR 0090](../../../docs/adr/0090-metic-task-authoring.md) a Metic MAY `POST /tasks` directly, and since [ADR 0154](../../../docs/adr/0154-goal-owner-criterion-authoring.md) a Metic MAY write a `done_when_criteria` row for a goal they own or manage. What needs an Archon is a VERSION-level criterion (no `goal_id`), one in a goal you don't hold, and — since [ADR 0250](../../../docs/adr/0250-strict-versioning-the-version-boundary-is-the-scope-gate.md) §6 (task 1003608) — **creating a version at all**: `version.create` returned to the Archon floor, because once the version boundary carries the scope gate, cutting a version is the way around it rather than authoring. ADR 0157 had briefly delegated it to Metic; it no longer is. The spec-draft (Phase 3) and the in-depth interview (Phase 4) run identically in Metic-mode — the only difference is the Phase-5 write (you file proposals, you don't seed tasks directly).
 
-   **For each criterion proposal**, write `body_md` as a JSON object with this exact shape so the `POST /api/gds/inbox/:id/ratify` endpoint (V3.R31 / #252) can parse it cleanly:
+   **For each criterion proposal**, write `body_md` as a JSON object with this exact shape so the `POST /api/bongos/inbox/:id/ratify` endpoint (V3.R31 / #252) can parse it cleanly:
 
    ```json
    {
@@ -52,24 +52,24 @@ This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`) and matches the
    **Net-new version (idea 425).** The Metic-mode path above assumes the target version *already exists* — its criterion proposals carry `suggested_version` (an FK to a `versions` row) and a `target_version` that must match `versions.id`. **A Metic cannot create one:** `version.create` is **Archon-floored** ([ADR 0250](../../../docs/adr/0250-strict-versioning-the-version-boundary-is-the-scope-gate.md) §6, task 1003608 — ADR 0157 had briefly lowered it to Metic and that is reversed). So `POST /versions` returns `403` and the Metic has no valid FK to point at. Ask an Archon to cut the version — or, when that is not available, run the session in Metic-mode as usual through Phases 1–4 and in Phase 5 file the proposals like this instead:
 
    1. **OMIT `suggested_version` on every proposal row.** It is an FK to a version row that doesn't exist yet; leaving it set would fail the constraint (or worse, attach the proposal to the wrong existing version). Leave it `null`/absent.
-   2. **Keep `target_version` INSIDE the criterion-proposal `body_md` JSON as plain text** (the version's intended id/slug, e.g. `"V4"`). It is *not* validated as an FK there — it's a label the Archon reads at ratify time. Once the Archon creates the real version row, the proposal is ratifiable as-is: `POST /api/gds/inbox/:id/ratify` resolves `target_version` against the now-existing `versions.id`.
+   2. **Keep `target_version` INSIDE the criterion-proposal `body_md` JSON as plain text** (the version's intended id/slug, e.g. `"V4"`). It is *not* validated as an FK there — it's a label the Archon reads at ratify time. Once the Archon creates the real version row, the proposal is ratifiable as-is: `POST /api/bongos/inbox/:id/ratify` resolves `target_version` against the now-existing `versions.id`.
    3. **File ONE umbrella feature idea** (`kind='feature'`) that captures the whole net-new version in a single inbox row: the proposed version (id/slug + one-line theme), its goals, and a seed spec (the agreed criteria + the brainstormed task list). This is the thing an Archon picks up to actually create the version, then ratify the criterion proposals against it. One umbrella idea — not one idea per task — keeps the net-new version reviewable as a single unit.
 
    Tell the Metic plainly: *"This deployment still gates version creation above Metic, so I've filed your criteria as proposals (with the version name kept as text inside each) plus one umbrella idea describing the whole version. Once someone who clears that gate creates the version row, any Metic+ builder ratifies these against it — your karma and attribution carry through."*
 4. **If `rank` lowercases to `archon`** → proceed in **Archon-mode**: full session, Phase 5 writes the migration + tasks + dependencies + done_when_criteria atomically. This is the flow described below.
 5. **If `rank` is absent** (the `/me` response has no `rank` field — only possible against a deployment where the three-rank model hasn't shipped yet): treat the session as Archon-mode, exactly as `/idea-triage` does in its pre-rank passthrough mode. Note in the session log that the gate ran in pre-rank passthrough mode.
 
-> The gate is **belt-and-braces**: the server already rejects `POST /api/gds/tasks`, `POST /tasks/:id/dependencies`, and `POST /done-when/:id/satisfy` with `403 permission_forbidden` for sub-Metic callers (all three are metic-floored — `task.create`, `task.dependency.manage`, `criterion.satisfy` — so a Metic makes these writes directly, as the Metic-mode step above says), and `POST /api/gds/inbox` with `kind='criterion-proposal'` is gated to Metic+ (so a Xenos can't slip a criterion proposal in via raw curl). This frontmatter + check is the *intent surfaced to the operator*; the server is the *enforcement*. The skill stops early so a Xenos doesn't walk through a whole session only to hit 403s on every write in Phase 5.
+> The gate is **belt-and-braces**: the server already rejects `POST /api/bongos/tasks`, `POST /tasks/:id/dependencies`, and `POST /done-when/:id/satisfy` with `403 permission_forbidden` for sub-Metic callers (all three are metic-floored — `task.create`, `task.dependency.manage`, `criterion.satisfy` — so a Metic makes these writes directly, as the Metic-mode step above says), and `POST /api/bongos/inbox` with `kind='criterion-proposal'` is gated to Metic+ (so a Xenos can't slip a criterion proposal in via raw curl). This frontmatter + check is the *intent surfaced to the operator*; the server is the *enforcement*. The skill stops early so a Xenos doesn't walk through a whole session only to hit 403s on every write in Phase 5.
 
 ## The session — five phases
 
 ### Phase 1 — Set the table
 
-1. **Confirm the target version.** Pull `GET /api/gds/public/versions`. If the user didn't name one, list versions in `status='planning'` and ask which.
+1. **Confirm the target version.** Pull `GET /api/bongos/public/versions`. If the user didn't name one, list versions in `status='planning'` and ask which.
 2. **Pull what's already queued for that version:**
-   - `GET /api/gds/tasks?version=<id>` — every task already bound to the version
-   - `GET /api/gds/inbox` (filter `suggested_version=<id>` or `status=open` if no suggested-version filter is supported by the route)
-   - `GET /api/gds/versions/<id>/done-when` — any criteria already seeded
+   - `GET /api/bongos/tasks?version=<id>` — every task already bound to the version
+   - `GET /api/bongos/inbox` (filter `suggested_version=<id>` or `status=open` if no suggested-version filter is supported by the route)
+   - `GET /api/bongos/versions/<id>/done-when` — any criteria already seeded
 3. **Surface the signal back to the user** as a compact summary:
    - N tasks already queued, grouped by kind
    - M open ideas tagged for this version
@@ -81,7 +81,7 @@ This is where the user sees what they're shaping. Do not skip this — criteria
 4. **Rescope — carry achieved goals forward (ADR 0086 §6 / BV1.R64).** If this version succeeds a prior one, pull the prior version's **achieved** goals and decide, per goal, "previous or new":
 
    ```
-   node scripts/gds/api.js GET "/api/gds/goals?version=<prev>&status=achieved"
+   node scripts/gds/api.js GET "/api/bongos/goals?version=<prev>&status=achieved"
    ```
 
    - **Carry forward** — the goal's objective continues into this version. Create the successor goal in Phase 5 with `succeeds_goal_id` pointing at the prior goal (`POST /goals` stamps the predecessor's `succeeded_by_goal_id`), then **archive the prior goal** (`POST /goals/:id/archive`). The lineage stays queryable.
@@ -270,13 +270,13 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
 2. **Create the version's goals, then write the criteria migration.** Goals come first (ADR 0086) so the criteria can be parented under them:
    - **Goals** (via API — `POST /goals`; Archon-only when the scope includes a `protected` module). One per goal from Phase 2.5; **capture each returned goal id**.
      ```
-     node scripts/gds/api.js POST /api/gds/goals --body '{"version_id":"<ver>","title":"...","scope_modules":["<key>", ...]}'
+     node scripts/gds/api.js POST /api/bongos/goals --body '{"version_id":"<ver>","title":"...","scope_modules":["<key>", ...]}'
      # carry-forward goal: add "succeeds_goal_id":<prior_goal_id>
      ```
    - **Criteria — the vector depends on whether the instance is LIVE ([ADR 0105](../../../docs/adr/0105-instance-seed-migrations-out-of-core.md)):**
-     - **On a RUNNING instance (the normal case — planning a new goal/version on prod):** create each criterion via the **`POST /api/gds/versions/:id/done-when`** API (**Metic+ for a goal you own or manage — [ADR 0154](../../../docs/adr/0154-goal-owner-criterion-authoring.md); Archon for a version-level criterion, someone else's goal, or a shipped/frozen version**), passing `criterion_id` (a stable slug), `criterion_md`, `goal_id` (the goal from above), and optional `sort_order`. This is the ONLY vector that actually lands a NEW criterion on a live DB — a `done_when_criteria` INSERT in a CORE migration **fails the `selfhost-boot` gate** (scope-truth pollution), and one in `migrations/instance/` **silently no-ops on a normal deploy** (ADR 0105 applies instance seeds only under the owner opt-in `GDS_APPLY_INSTANCE_SEEDS=1`, a DR step). A duplicate `criterion_id` returns 409 — treat as "already seeded."
+     - **On a RUNNING instance (the normal case — planning a new goal/version on prod):** create each criterion via the **`POST /api/bongos/versions/:id/done-when`** API (**Metic+ for a goal you own or manage — [ADR 0154](../../../docs/adr/0154-goal-owner-criterion-authoring.md); Archon for a version-level criterion, someone else's goal, or a shipped/frozen version**), passing `criterion_id` (a stable slug), `criterion_md`, `goal_id` (the goal from above), and optional `sort_order`. This is the ONLY vector that actually lands a NEW criterion on a live DB — a `done_when_criteria` INSERT in a CORE migration **fails the `selfhost-boot` gate** (scope-truth pollution), and one in `migrations/instance/` **silently no-ops on a normal deploy** (ADR 0105 applies instance seeds only under the owner opt-in `GDS_APPLY_INSTANCE_SEEDS=1`, a DR step). A duplicate `criterion_id` returns 409 — treat as "already seeded."
        ```
-       node scripts/gds/api.js POST /api/gds/versions/<ver>/done-when --body '{"criterion_id":"<slug>","criterion_md":"...","goal_id":<gid>}'
+       node scripts/gds/api.js POST /api/bongos/versions/<ver>/done-when --body '{"criterion_id":"<slug>","criterion_md":"...","goal_id":<gid>}'
        ```
      - **For a brand-new version scaffolded from scratch (DR / a fresh instance):** put the `INSERT INTO done_when_criteria` (with `goal_id`, `ON CONFLICT ... DO UPDATE`) in **`migrations/instance/<NN>_<ver_slug>_planning_seed.sql`** — and recreate the goal idempotently in the same file (the goal is a runtime row a replay won't have). Applies only under `GDS_APPLY_INSTANCE_SEEDS=1`.
    - **Migration** at `migrations/<NN>_<ver_slug>_planning_seed.sql` (CORE — platform-universal, non-scope-truth changes only): `UPDATE versions SET done_when = ...` and `UPDATE tasks` for existing-task priority + V##.R## title prefix (guarded by `WHERE title NOT LIKE 'V<ver>.R%'`). **Do NOT put versions/goals/`done_when_criteria` INSERTs here** — that's scope-truth and fails the `selfhost-boot` gate (ADR 0105).
@@ -290,11 +290,11 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
 
 > **Seeding contract — validated on goal 1000045 (2026-07-16):** proof-tasks use `kind='verify'` (a deliverable that IS a verification; can't be prematurely confirmed), spikes `kind='spike'`; `POST /tasks` accepts `criterion_ids` + `goal_id` inline and disciplines include `ui`; there is **no `promoted_idea_id`** field on `POST /tasks` — mark a promoted idea via `PATCH /inbox/:id`; **descoping a criterion has no API** (done-when is create/satisfy/unsatisfy only) — remove the row via a direct DB delete (`ssh … "sudo -u postgres psql -d <db> -c \"DELETE FROM done_when_criteria WHERE id=…\""`) under the meta-task claim, capturing the SQL in its notes; and a seed script **must throttle + honor `429` `retry_after`** (per-IP rate limit) — add a base delay between calls and back off on 429, or a large seed dies halfway. A completed reference seed: `scripts/gds/<redacted>.js`.
 >
-> **Every seed script verifies its own criterion links — fail loudly on any mismatch, zero included (task 1003076, retro on goal 1000071).** The goal-1000071 seeder linked all 15 tasks to the WRONG criteria (a positional `"Cn"` token resolved against the whole VERSION's criterion order, not the goal's — learning 1000188) and still printed success; only a manual `GET /goals` rollup caught it, after the fact. Every seed script's `main()` must end by tallying the `criterion_ids` it actually POSTed per task, then calling `verifySeedCriteriaLinks` from [`scripts/gds/seed-verify-criteria.js`](../../../scripts/gds/seed-verify-criteria.js) — it fetches `GET /api/gds/goals/<id>`, diffs the returned `criteria[].linked_tasks` against that plan, and `exit(1)`s with a loud per-criterion diff on any mismatch (see `expectedCriterionCounts` + `verifySeedCriteriaLinks`). Reference implementation: `scripts/gds/<redacted>.js`. This is a script-level check, independent of whatever caused the mislink — it catches the *symptom* (a criterion silently under- or over-linked) whichever bug produces it.
+> **Every seed script verifies its own criterion links — fail loudly on any mismatch, zero included (task 1003076, retro on goal 1000071).** The goal-1000071 seeder linked all 15 tasks to the WRONG criteria (a positional `"Cn"` token resolved against the whole VERSION's criterion order, not the goal's — learning 1000188) and still printed success; only a manual `GET /goals` rollup caught it, after the fact. Every seed script's `main()` must end by tallying the `criterion_ids` it actually POSTed per task, then calling `verifySeedCriteriaLinks` from [`scripts/gds/seed-verify-criteria.js`](../../../scripts/gds/seed-verify-criteria.js) — it fetches `GET /api/bongos/goals/<id>`, diffs the returned `criteria[].linked_tasks` against that plan, and `exit(1)`s with a loud per-criterion diff on any mismatch (see `expectedCriterionCounts` + `verifySeedCriteriaLinks`). Reference implementation: `scripts/gds/<redacted>.js`. This is a script-level check, independent of whatever caused the mislink — it catches the *symptom* (a criterion silently under- or over-linked) whichever bug produces it.
 
 4. **Apply the migration** (commit + push + deploy, or direct psql via SSH for hot-fix style).
 
-5. **Run the seed script.** Verify exit code 0 — the seed's own final step (the Seeding contract's `verifySeedCriteriaLinks` call, above) already fails loudly if any criterion's linked task count doesn't match the plan, so a 0 exit means the links landed correctly, not just that the POSTs didn't error. Also spot-check totals via `GET /api/gds/public/progress` and `GET /api/gds/versions/<ver>/done-when`.
+5. **Run the seed script.** Verify exit code 0 — the seed's own final step (the Seeding contract's `verifySeedCriteriaLinks` call, above) already fails loudly if any criterion's linked task count doesn't match the plan, so a 0 exit means the links landed correctly, not just that the POSTs didn't error. Also spot-check totals via `GET /api/bongos/public/progress` and `GET /api/bongos/versions/<ver>/done-when`.
 
 6. **Promote the zero-dep layer to `ready` — scoped to the tasks you just seeded.** Every newly-seeded task lands `status='backlog'`. The auto-promotion trigger only fires when a *dependency* ships — so a task with zero deps has nothing to wait for and would sit unclaimable forever.
 
@@ -349,7 +349,7 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
 
    If the query returns rows, surface them to the user verbatim:
 
-   > "Heads up — these spikes sit at priority ≥ the top of your ready queue. They don't auto-promote (kind='spike', [ADR 0015](../../../docs/adr/0015-task-dependencies-and-auto-promotion.md)). If any gates downstream work, open it manually: `POST /api/gds/tasks/<id>/promote`"
+   > "Heads up — these spikes sit at priority ≥ the top of your ready queue. They don't auto-promote (kind='spike', [ADR 0015](../../../docs/adr/0015-task-dependencies-and-auto-promotion.md)). If any gates downstream work, open it manually: `POST /api/bongos/tasks/<id>/promote`"
 
    If the query returns nothing, stay silent. Don't volunteer info about lower-priority spikes — the next planning session or `/idea-triage` walk will handle those at the right moment.
 
@@ -365,10 +365,10 @@ runs on Windows/macOS/Linux.
 
 ```
 # Phase 1 — pull state
-node scripts/gds/api.js GET /api/gds/public/versions
-node scripts/gds/api.js GET "/api/gds/tasks?version=<id>"
-node scripts/gds/api.js GET /api/gds/inbox
-node scripts/gds/api.js GET /api/gds/versions/<id>/done-when
+node scripts/gds/api.js GET /api/bongos/public/versions
+node scripts/gds/api.js GET "/api/bongos/tasks?version=<id>"
+node scripts/gds/api.js GET /api/bongos/inbox
+node scripts/gds/api.js GET /api/bongos/versions/<id>/done-when
 ```
 
 Phase 5 writes use the same `POST /tasks`, `PATCH /inbox/:id` shape as `idea-triage` and `seed-v3-tasks.js`. Mirror those patterns rather than inventing new ones.