@bongos/core 1.21.174 → 1.21.176

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

@@ -17,7 +17,7 @@ You are recovering a task whose ship parked at `completed` because of its grade.
 Reads the persisted grade, branches on `panel_outcome` FIRST, then walks exactly one of three recovery branches. The re-grade command every branch eventually reaches is:
 
 ```bash
-node scripts/gds/ship.js <id> --regrade
+node scripts/bongos/ship.js <id> --regrade
 ```
 
 `--regrade` re-runs ONLY the grade step (no smoke/scanner re-run), reads **committed history, not the working tree**, applies only to a task at `completed`, is gated to the task's most-recent claim holder or an Archon, and has no attempt cap.
@@ -25,11 +25,11 @@ node scripts/gds/ship.js <id> --regrade
 ## Step 1 — Read the grade
 
 ```bash
-node scripts/gds/api.js GET "/api/bongos/tasks/<id>?include=grade,last_claim"
+node scripts/bongos/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.
-- **A page tweak whose grade PASSED** (`task.source` is `page-tweak`, `grade.passed` is `true`) → stop; it is **waiting for the artist**, not a failed grade (ADR 0341 D7). Its pass is held at `completed` on purpose until the artist approves the applied page. Do not re-grade it and do not ask for an override. If its branch never published, a plain `node scripts/gds/ship.js <id>` re-publishes it without re-grading.
+- **A page tweak whose grade PASSED** (`task.source` is `page-tweak`, `grade.passed` is `true`) → stop; it is **waiting for the artist**, not a failed grade (ADR 0341 D7). Its pass is held at `completed` on purpose until the artist approves the applied page. Do not re-grade it and do not ask for an override. If its branch never published, a plain `node scripts/bongos/ship.js <id>` re-publishes it without re-grading.
 - `grade: null` → the ship never reached the grade step; re-run `/builder-ship`, not `--regrade`.
 - Otherwise diagnose from the grade row: `signals.panel_outcome`, `signals.server_guard`, `passed`, `rubric_scores`, `issues[]`.
 
@@ -41,20 +41,20 @@ The panel could not run (worker infra outage or a pre-spawn bypass). This is **n
 
 1. Do NOT edit code. There is nothing to fix.
 2. Check the grader can run now: the panel spawns `claude -p` subprocesses locally, so confirm the CLI is present and authenticated, and the instance API is reachable (`signals.grader_unavailable_reason` usually names the leg that died).
-3. Re-grade: `node scripts/gds/ship.js <id> --regrade`.
+3. Re-grade: `node scripts/bongos/ship.js <id> --regrade`.
 
 ### Branch B — fabricated / server-shape fail: the guard tripped or an axis was forged by an error
 
 Three known sub-shapes, all recognizable because the "fail" carries **no substantive findings**. First make sure it really carries none: read the top-level `issues[]` — the API has lifted the stored findings there since task 1003488 (2026-09-02). Before that, a grade READ BACK showed no `issues` at all even when the panel had filed some, which is how task 1002721's real (and wrong) Quality blocker was taken for an empty fail.
 
-- **Server-guard trip** (`signals.server_guard.tripped` non-empty, e.g. `implausible_pass`): the server downgraded a client-asserted pass it found implausible — historically this guard has fired on genuinely clean, unanimous zero-issue passes. Explain the downgrade honestly, then re-grade: `node scripts/gds/ship.js <id> --regrade`.
+- **Server-guard trip** (`signals.server_guard.tripped` non-empty, e.g. `implausible_pass`): the server downgraded a client-asserted pass it found implausible — historically this guard has fired on genuinely clean, unanimous zero-issue passes. Explain the downgrade honestly, then re-grade: `node scripts/bongos/ship.js <id> --regrade`.
 - **An unbacked low score** (`signals.unbacked_scores` lists it; the card reads `UNBACKED LOW SCORE`): a reviewer scored below threshold without a major/blocker finding, so the severity gate downgraded it to manual-confirm instead of a hard fail (task 1002903). There is nothing to fix. Re-grade once; if it repeats on a diff you can defend, take the override path below with your evidence.
 - **A FAIL scored around 4.5/10 with zero issues and a null/zero axis** (the errored-worker class): a worker error was forwarded as a real axis score. Same response — re-grade; the panel rerun replaces the forged shape with a real verdict. Since task 1003318 a Quality worker that never ran (a `Prompt is too long` window overflow, `error: PROMPT_TOO_LONG`) no longer forges a 0: the server records `signals.cq_lens_unavailable` with a json-null axis and the card reads `QUALITY LENS UNAVAILABLE` — re-grade or manual-confirm; a 4.5 with a 0 axis now only comes from a server predating it.
 
 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/bongos/tasks/<id>/override-request --body '{"rationale":"<why this grade is wrong, specifically>"}'
+node scripts/bongos/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.
@@ -69,7 +69,7 @@ The panel ran and rejected the work. Recover by fixing, not by re-rolling:
 4. Commit on the claim branch — the grader reads committed history — then re-grade, saying how each finding was answered:
 
 ```bash
-node scripts/gds/ship.js <id> --regrade --response-file response.md
+node scripts/bongos/ship.js <id> --regrade --response-file response.md
 ```
 
 **`--response` is how you answer a finding; `--notes` is not** (task 1003702). The panel is given the task, your value summary, the changed files and the diff — it never reads ship notes, on a re-grade or on the first ship. `--response` rides to the panel fenced as the prior round's answer, so an already-answered finding cannot re-veto on re-wording alone. Passing `--notes` used to be accepted and silently dropped; it is now refused with this same guidance. Evidence itself still belongs in the **diff** — a committed test is what makes a fix real (step 2), and the panel can read every changed file.
@@ -88,5 +88,5 @@ A grade block naming protected surfaces above your rank is an authorization wall
 ## Files this skill touches
 
 - 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).
+- Runs: `node scripts/bongos/ship.js <id> --regrade` (the grade step only).
 - Writes (Branch B escalation only): `POST /api/bongos/tasks/:id/override-request`.

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

@@ -32,16 +32,16 @@ You read live surfaces, compare against known baselines, and emit findings + exa
 
 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/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[]`.
+1. Read the public trend: `node scripts/bongos/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/bongos/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/bongos/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
-node scripts/gds/ship.js <id> --regrade
+node scripts/bongos/ship.js <id> --regrade
 ```
 
-5. Check the local spawn leg: the panel spawns `claude -p` subprocesses, so verify the CLI is present and authenticated, and run `node scripts/gds/doctor.js` for the hooks/worktree leg.
+5. Check the local spawn leg: the panel spawns `claude -p` subprocesses, so verify the CLI is present and authenticated, and run `node scripts/bongos/doctor.js` for the hooks/worktree leg.
 
 #### 2 — Pass-rate drift
 
@@ -55,7 +55,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/bongos/public/cost-summary?source=grader&days=30" --quiet \
+node scripts/bongos/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)})"
@@ -72,11 +72,11 @@ The evaluation found every grade ran on a generation-stale pin. Read the live pi
 
 ### Optional: `--probe` (live calibration, spends real money)
 
-With `--probe`, run the live panel calibration: `node scripts/gds/grade-smoke.js`. It grades known-good and known-bad fixtures against the real panel and reports miscalibration. **Costs ~$0.30–0.90 per run; Metic+ only.** Never run it implicitly — only when the user passed `--probe` or asked for a live calibration.
+With `--probe`, run the live panel calibration: `node scripts/bongos/grade-smoke.js`. It grades known-good and known-bad fixtures against the real panel and reports miscalibration. **Costs ~$0.30–0.90 per run; Metic+ only.** Never run it implicitly — only when the user passed `--probe` or asked for a live calibration.
 
 ### Related: do the workers fail differently?
 
-Part A checks whether the grader is RUNNING well. Whether its four workers carry independent signal — or are four copies of one opinion — is a different question with its own read-only report: `node scripts/gds/grade-correlation-audit.js` (pairwise agreement + Cohen's kappa between workers, each worker's kappa against the owner's override and manual-confirm decisions, refused below a minimum sample; no model calls, Metic+ for the override read). Point the owner at it when the question is panel composition rather than health.
+Part A checks whether the grader is RUNNING well. Whether its four workers carry independent signal — or are four copies of one opinion — is a different question with its own read-only report: `node scripts/bongos/grade-correlation-audit.js` (pairwise agreement + Cohen's kappa between workers, each worker's kappa against the owner's override and manual-confirm decisions, refused below a minimum sample; no model calls, Metic+ for the override read). Point the owner at it when the question is panel composition rather than health.
 
 ---
 
@@ -87,13 +87,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/bongos/public/recent-shipped?days=7"
+node scripts/bongos/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/bongos/tasks/<id>?include=grade"
+node scripts/bongos/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.
@@ -112,7 +112,7 @@ Note `task_grades.grader_kind` is **not** the discriminator: the server records
 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/bongos/override-requests?status=approved"
+node scripts/bongos/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.
@@ -124,10 +124,10 @@ node scripts/gds/api.js GET "/api/bongos/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/bongos/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/bongos/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
+node scripts/bongos/capture.js "[grade-audit] task <id>: <finding summary>" --kind bug
 ```
 
 One idea per surviving finding, titled exactly `[grade-audit] task <id>: …` so a re-run of this audit files nothing twice. (The marker keeps the old command's name on purpose: rows already in the inbox carry it.)
@@ -169,6 +169,6 @@ A clean week is four one-liners.
 ## Files this skill touches
 
 - 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/public/recent-shipped`, `GET /api/bongos/tasks/:id?include=grade`, `GET /api/bongos/override-requests?status=approved` (Archon), `GET /api/bongos/inbox`, `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: `idea_inbox` rows via `node scripts/gds/capture.js` (Part B's queued follow-ups only).
+- Runs (read-only): `node scripts/bongos/doctor.js`; with `--probe` only: `node scripts/bongos/grade-smoke.js`.
+- Writes: `idea_inbox` rows via `node scripts/bongos/capture.js` (Part B's queued follow-ups only).
 - Never calls: any confirm, status, grade, or regrade endpoint.

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

@@ -76,7 +76,7 @@ capture-time suggester (R08/R09/R11 surfaces) is where the fix belongs.
 ## What this skill does
 
 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).
+2. **Batches near-duplicate ideas** into one verdict per cluster (`node scripts/bongos/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/bongos/inbox/:id` with the verdict.
@@ -86,12 +86,12 @@ capture-time suggester (R08/R09/R11 surfaces) is where the fix belongs.
 **Step 1 — fetch the open inbox.**
 
 ```
-node scripts/gds/api.js GET /api/bongos/inbox
+node scripts/bongos/api.js GET /api/bongos/inbox
 ```
 
 (`api.js` is the cross-platform Bongos API helper — it signs the request with your
 session token and runs on Windows/macOS/Linux, replacing the old `python3`/`curl`
-block. For a human at a terminal, `node scripts/gds/triage.js` runs the whole
+block. For a human at a terminal, `node scripts/bongos/triage.js` runs the whole
 walk interactively instead.)
 
 If `open_count` is 0, print "inbox empty — nothing to triage today" and exit.
@@ -110,7 +110,7 @@ even needs, so it is the first thing to read, not a detail:
 Walk **Full Ideas first, best-formed first (highest completeness), then quick
 ideas and sparks newest-first.** Two runs, not one list sorted by score: a single
 score-sorted list puts every unscored idea after every scored one, and in a long
-inbox nobody reaches them. `node scripts/gds/triage.js` already walks in exactly
+inbox nobody reaches them. `node scripts/bongos/triage.js` already walks in exactly
 this order and prints the grade on each card, and `render-ideas.js` renders the
 same two sections — so the interactive walk, the generated file and this skill all
 show the same idea the same way.
@@ -119,7 +119,7 @@ show the same idea the same way.
 
 **Step 1.5a — batch near-duplicate ideas BEFORE developing anything (task 1001465).**
 
-Run `clusterIdeas` (`scripts/gds/triage.js` — pure, no I/O): it groups open quick ideas (not Full Ideas, not sparks) that share a `kind` and a high title/body word overlap. For each cluster it returns, offer the user ONE decision covering the whole group instead of walking each member — this is the actual fix for "triage costs a ton of credits" (idea 377): a backlog of near-identical asks used to cost one full development + verdict PER idea, and now costs one:
+Run `clusterIdeas` (`scripts/bongos/triage.js` — pure, no I/O): it groups open quick ideas (not Full Ideas, not sparks) that share a `kind` and a high title/body word overlap. For each cluster it returns, offer the user ONE decision covering the whole group instead of walking each member — this is the actual fix for "triage costs a ton of credits" (idea 377): a backlog of near-identical asks used to cost one full development + verdict PER idea, and now costs one:
 
 > Cluster of 3 likely duplicates: #101 "Add dark mode toggle", #145 "Dark mode support", #203 "Support a dark theme". **Keep #101 and merge the rest, discard all, walk them individually, or skip?**
 
@@ -128,7 +128,7 @@ Run `clusterIdeas` (`scripts/gds/triage.js` — pure, no I/O): it groups open qu
 - **Individually** → ignore the grouping for this cluster; each member returns to the normal walk.
 - **Skip** → leave the whole cluster open; it clusters again next triage.
 
-`node scripts/gds/triage.js` already runs this pass automatically before its interactive walk — if a human is running the deterministic walker instead of you, they get it for free with no flag.
+`node scripts/bongos/triage.js` already runs this pass automatically before its interactive walk — if a human is running the deterministic walker instead of you, they get it for free with no flag.
 
 **Step 1.5b — develop what's LEFT with a lean inline pass by default (task 1001465).**
 
@@ -151,7 +151,7 @@ Run `clusterIdeas` (`scripts/gds/triage.js` — pure, no I/O): it groups open qu
 If a human will run the interactive walker instead of the Claude-driven walk below, hand it the cache (works the same whether it came from the lean pass's few subagents or the full deep pass):
 
 ```
-node scripts/gds/triage.js --development "${TMPDIR:-/tmp}/otb-idea-development.json"
+node scripts/bongos/triage.js --development "${TMPDIR:-/tmp}/otb-idea-development.json"
 ```
 
 `triage.js` prints each idea's developed block above its verdict prompt, and runs its own batch-cluster pass (Step 1.5a) automatically first. It never *generates* the analysis (that's this skill's job); it only displays what the cache holds, and runs exactly as before when no cache is present.
@@ -195,7 +195,7 @@ a quarter of work; that is the judgement triage adds.
 **Do the legwork before recommending.** A recommendation with nothing behind it is
 worse than no recommendation, because it looks like an answer. Run
 `/recall <the idea's subject>`, check the goal board
-(`node scripts/gds/goal.js list`), and look for an existing task before proposing
+(`node scripts/bongos/goal.js list`), and look for an existing task before proposing
 anything new — "merge" is the recommendation people skip, and it is often the right
 one.
 
@@ -227,24 +227,24 @@ at the triage end, where the judgement is.)
 
   ```
   # 1. Create the task (--body-file avoids shell-quoting the touches[]/description).
-  node scripts/gds/api.js POST /api/bongos/tasks --body-file <path-to-task.json>
+  node scripts/bongos/api.js POST /api/bongos/tasks --body-file <path-to-task.json>
   #    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/bongos/inbox/<idea_id> --body '{"status":"promoted","promoted_to_task_id":<new_task_id>}'
+  node scripts/bongos/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/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"}'
+  node scripts/bongos/api.js POST /api/bongos/goals --body '{"version_id":"<ver>","title":"...","description":"from idea #<idea_id>","scope_modules":["<module-key>", ...]}'
+  node scripts/bongos/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/bongos/inbox/<idea_id>/ratify --body '{"notes_md":"ratified via idea-triage"}'
+  node scripts/bongos/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.
@@ -252,13 +252,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/bongos/inbox/<idea_id> --body '{"status":"discarded","triage_note":"superseded by the new gate"}'
+node scripts/bongos/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/bongos/inbox/<idea_id> --body '{"status":"merged","merged_into_idea_id":<canonical_idea_id>,"triage_note":"same ask as #N"}'
+node scripts/bongos/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

@@ -28,7 +28,7 @@ The queue this skill works against is **tasks at status='confirmed'**. Those are
 **Step 0 — preflight this machine, before anything else.**
 
 ```bash
-node scripts/gds/skill-preflight.js merge-mode   # exits 1 naming what is MISSING
+node scripts/bongos/skill-preflight.js merge-mode   # exits 1 naming what is MISSING
 ```
 
 If it exits non-zero, **stop**: this machine cannot finish the procedure, and the
@@ -45,12 +45,12 @@ stopped the run (task 1003167).
 > `ssh` / `deploy.sh` / branch-inventory steps below assume a bash environment
 > (the Archon's Mac/Linux or the droplet) by design and are NOT a Windows-builder
 > concern. The Bongos *API* calls, however, go through the cross-platform
-> `node scripts/gds/api.js` helper so they work regardless of shell.
+> `node scripts/bongos/api.js` helper so they work regardless of shell.
 
 **Step 1 — list the queue: tasks at confirmed.**
 
 ```
-node scripts/gds/api.js GET "/api/bongos/tasks?status=confirmed"
+node scripts/bongos/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.
@@ -66,7 +66,7 @@ If the list is empty, print "no tasks at confirmed — auto-merge in /builder-sh
 REPO_ROOT="$(dirname "$(git rev-parse --git-common-dir)")"
 cd "$REPO_ROOT"
 
-node scripts/gds/merge-lock.js acquire   # blocks up to 30s; exit 3 if a ship/merge holds it — then STOP and retry later
+node scripts/bongos/merge-lock.js acquire   # blocks up to 30s; exit 3 if a ship/merge holds it — then STOP and retry later
 # (exit 0 = you hold the lock; proceed. exit 3 = held by another run; do not force past this.)
 
 find .git -name "* 2" -delete   # macOS Finder iCloud duplicates — known recurring snag
@@ -114,7 +114,7 @@ Group branches into:
 After all merges, on `main`, regenerate the 3 mechanical onboarding diagrams from live facts so `/builders/diagrams` stays current. If anything changed, commit it onto main before pushing:
 
 ```bash
-node scripts/gds/gen-diagrams.js                 # regenerate + render (no-op if already current)
+node scripts/bongos/gen-diagrams.js                 # regenerate + render (no-op if already current)
 git -C "$REPO_ROOT" add docs/onboarding/diagrams
 git -C "$REPO_ROOT" diff --cached --quiet || \
   git -C "$REPO_ROOT" commit -m "chore(diagrams): auto-regenerate mechanical diagrams from live facts (task 357)"
@@ -124,18 +124,18 @@ This mirrors what `ship.js` does automatically; it's here because /merge-mode de
 
 **Step 5 — smoke tests, push, deploy.**
 
-> **Deploy mode (#679 / [ADR 0042](../../../docs/adr/0042-builder-self-deploy-ci-auto-merge.md)).** `config/deploy.json` is now `mode: ci` (CI cutover landed 2026-06-13), so the **`ci`** path is current: there is no laptop merge and no SSH at all — landing happens via PR auto-merge and `.github/workflows/deploy-prod.yml` (instance-side) deploys `main`→prod from Actions. In `ci` mode, do NOT run the `git push origin main` + `ssh … ~/deploy.sh` lines below — instead confirm the PR auto-merged and the `deploy-prod` Actions run went green. The block below is the **legacy `laptop`** deploy mode (the operator's machine pushes `main` and SSHes the droplet) — it is the fallback path and only applies if `config/deploy.json` is reverted to `mode: laptop`. Check the active mode with `node scripts/gds/ship.js --print-deploy-mode`.
+> **Deploy mode (#679 / [ADR 0042](../../../docs/adr/0042-builder-self-deploy-ci-auto-merge.md)).** `config/deploy.json` is now `mode: ci` (CI cutover landed 2026-06-13), so the **`ci`** path is current: there is no laptop merge and no SSH at all — landing happens via PR auto-merge and `.github/workflows/deploy-prod.yml` (instance-side) deploys `main`→prod from Actions. In `ci` mode, do NOT run the `git push origin main` + `ssh … ~/deploy.sh` lines below — instead confirm the PR auto-merged and the `deploy-prod` Actions run went green. The block below is the **legacy `laptop`** deploy mode (the operator's machine pushes `main` and SSHes the droplet) — it is the fallback path and only applies if `config/deploy.json` is reverted to `mode: laptop`. Check the active mode with `node scripts/bongos/ship.js --print-deploy-mode`.
 
 > **Do NOT probe `parseDeployMode` directly (task 1003221).** It reads only the env var and `config/deploy.json`, and **defaults to `laptop`** when neither is present — so on any machine whose checkout does not carry `config/`, that probe answers `laptop` every time. It sent a builder down the laptop merge path — local merge, `push-main.js`, SSH deploy — on a machine with none of those credentials (2026-08-21, 163 minutes). `effectiveDeployMode` is the credential-aware answer and reroutes to `ci` when the machine cannot push locally; the flag above prints that one.
 
 ```bash
-node scripts/gds/smoke-gds.js    # 16/16 expected (cross-platform; replaces smoke-gds.sh)
-bash scripts/gds/smoke-write.sh  # 4/4 expected
-node scripts/gds/push-main.js    # SEC #863: the sanctioned gated main-push (NOT raw `git push origin main`)
+node scripts/bongos/smoke-gds.js    # 16/16 expected (cross-platform; replaces smoke-gds.sh)
+bash scripts/bongos/smoke-write.sh  # 4/4 expected
+node scripts/bongos/push-main.js    # SEC #863: the sanctioned gated main-push (NOT raw `git push origin main`)
 ssh -o ConnectTimeout=10 lars@REDACTED_IP "~/deploy.sh"
 ```
 
-> **SEC #863 (ADR 0043):** push `main` only via `node scripts/gds/push-main.js`. A raw `git push origin main` is now blocked by the pre-push permission gate — that block is the friction that stops an ad-hoc bypass like the Builder 25 incident. `push-main.js` carries the `<PREFIX>_ALLOW_MAIN_PUSH` override (`BONGOS_` on a vanilla instance) because /merge-mode only ever lands tasks that already passed the grader + the Archon confirm gate. The post-push main audit (`node scripts/gds/main-audit.js`) re-checks regardless.
+> **SEC #863 (ADR 0043):** push `main` only via `node scripts/bongos/push-main.js`. A raw `git push origin main` is now blocked by the pre-push permission gate — that block is the friction that stops an ad-hoc bypass like the Builder 25 incident. `push-main.js` carries the `<PREFIX>_ALLOW_MAIN_PUSH` override (`BONGOS_` on a vanilla instance) because /merge-mode only ever lands tasks that already passed the grader + the Archon confirm gate. The post-push main audit (`node scripts/bongos/main-audit.js`) re-checks regardless.
 
 The deploy script applies any new migrations, restarts the service, and curls /healthz.
 
@@ -156,7 +156,7 @@ Non-blocking — a "branch already deleted" warning is fine. The local `refs/hea
 Now that the merge + deploy is done (or if you're aborting), release the lock acquired in Step 2 so the next ship/merge can proceed:
 
 ```bash
-node scripts/gds/merge-lock.js release
+node scripts/bongos/merge-lock.js release
 ```
 
 This is mandatory on every exit path — including aborts and conflicts you decide not to resolve. A manual hold left behind is reclaimed automatically after 30 minutes, but releasing promptly keeps the queue flowing.
@@ -166,7 +166,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/bongos/tasks/<task-id>/ship
+node scripts/bongos/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)).
@@ -186,8 +186,8 @@ If anything is blocked or failed, name what specifically needs to happen next (a
 
 - **No tasks at confirmed?** Print "queue clean — auto-merge in /builder-ship handled them all" and exit.
 - **A confirmed task has no matching branch?** Either the branch was already deleted or the worktree_name on the claim doesn't match a real branch. Surface this — usually means the auto-merge in /builder-ship succeeded but the task didn't transition to shipped (look for a stuck state). Manual `POST /tasks/:id/ship` may be needed.
-- **Conflict resolution ambiguous?** Stop and ask the user before guessing — destructive actions like `git reset` or `--no-verify` are NOT allowed without explicit confirmation. **Release the merge lock (`node scripts/gds/merge-lock.js release`) before pausing** so a queued ship isn't blocked while you wait on the user.
-- **Lock held when you try to acquire (exit 3)?** A ship or another merge run is actively mutating main. Do NOT force past it — wait and retry, or run `node scripts/gds/merge-lock.js status` to see the holder's age (it auto-reclaims if stale).
+- **Conflict resolution ambiguous?** Stop and ask the user before guessing — destructive actions like `git reset` or `--no-verify` are NOT allowed without explicit confirmation. **Release the merge lock (`node scripts/bongos/merge-lock.js release`) before pausing** so a queued ship isn't blocked while you wait on the user.
+- **Lock held when you try to acquire (exit 3)?** A ship or another merge run is actively mutating main. Do NOT force past it — wait and retry, or run `node scripts/bongos/merge-lock.js status` to see the holder's age (it auto-reclaims if stale).
 
 ## When to run
 

package/.claude/skills/new-project/SKILL.md

@@ -66,7 +66,7 @@ Nothing here is final: modules can be added after creation from the project's ow
 Before anything is provisioned, verify the control-plane's Cloudflare token can actually manage the domain's zone (a mismatched-zone token is exactly what broke the Emersonian standup mid-flow):
 
 ```bash
-node scripts/gds/provision.js dns-check <domain>
+node scripts/bongos/provision.js dns-check <domain>
 ```
 
 - ✓ reachable → continue.
@@ -96,8 +96,8 @@ Materialize the instance's own repo (ADR 0108): clone the empty GitHub repo to t
 The web tier only **enqueued** the request; the **control-plane runner** does the real work (it alone holds the DO/Cloudflare tokens):
 
 ```bash
-node scripts/gds/provision.js run-intents --apply     # drains the queue
-# or, for one instance:  node scripts/gds/provision.js provision <slug> --apply
+node scripts/bongos/provision.js run-intents --apply     # drains the queue
+# or, for one instance:  node scripts/bongos/provision.js provision <slug> --apply
 ```
 
 For `standalone` this composes: allocate a port → `git pull` + `npm ci --omit=dev` (installs the pinned core) → `createdb` + **instance-root** migrate (`node_modules/@cloudbongos/core/scripts/migrate.sh`) → per-instance `/etc/<slug>/web.env` → a **standalone systemd unit** (runs the core package's `platform-server.js` from the instance repo) → DNS A-record UPSERT → per-instance Caddy snippet (on-demand TLS) → `/healthz`. It is idempotent + dry-run-by-default (omit `--apply` to preview). It **fail-fasts on the step-4 DNS preflight** if that token check was skipped.
@@ -122,7 +122,7 @@ The instance's sign-in code is **unchanged** — a GitHub App's user token hits
 - Copy the **Client ID**; click **Generate a new client secret** and copy it (GitHub shows it **once**). Then place it **VERIFIED, never by hand (task 1979)**:
 
 ```bash
-node scripts/gds/oauth-secret.js place <slug> --client-id <id> --client-secret <secret> --apply
+node scripts/bongos/oauth-secret.js place <slug> --client-id <id> --client-secret <secret> --apply
 ```
 
 > **Guidance the standup learned:** do **NOT** hand-edit `web.env` with a shell `read -s` — during the Emersonian standup that silently left a 26-char truncated secret that broke sign-in with no obvious cause. `oauth-secret` validates the length/format (catching that truncation), rewrites the env line via Node, restarts the service, then **probes `/healthz` for `auth_configured:true`** before it reports success. If it refuses, the creds are wrong — recheck them; do not proceed.
@@ -191,5 +191,5 @@ Steps 12 and 13 are **not** part of that criterion and must never gate it. They
 - **Steps 12 and 13 are deliberately NOT in that plan**, and that is the distinction to keep: the plan is the creation rail, and both of those run only once the project exists. A step that can only run after the terminal step is not a step in the rail ([ADR 0249](../../../docs/adr/0249-the-invite-step-is-the-done-panel-s-first-act-not-a-rail-step.md)) — it belongs to the done panel and the project's own page, each of which carries its own way back.
 - **Standalone only** (ADR 0108) — do not fall back to editing this monorepo's checkout for a new project.
 - **Never weaken the trust boundary** — the web tier enqueues; only the control-plane runner (`provision.js`) touches cloud tokens (ADR 0016 / 0111 §2).
-- **Live docs are automatic** — a standalone instance's session-log index regenerates on deploy (`provision.js` runs `regen-instance-docs.js` after migrate; `bongos init`/`upgrade` seed+refresh it), and the whole-file nav docs are gitignored so `git reset --hard` never wipes them ([ADR 0147](../../../docs/adr/0147-standalone-live-docs-regen.md)). If you wire a **bespoke** deploy script for an instance, it MUST call `node node_modules/@bongos/core/scripts/gds/regen-instance-docs.js` after `git reset` + migrate — see [`docs/recipes/standalone-live-docs.md`](../../../docs/recipes/standalone-live-docs.md).
+- **Live docs are automatic** — a standalone instance's session-log index regenerates on deploy (`provision.js` runs `regen-instance-docs.js` after migrate; `bongos init`/`upgrade` seed+refresh it), and the whole-file nav docs are gitignored so `git reset --hard` never wipes them ([ADR 0147](../../../docs/adr/0147-standalone-live-docs-regen.md)). If you wire a **bespoke** deploy script for an instance, it MUST call `node node_modules/@bongos/core/scripts/bongos/regen-instance-docs.js` after `git reset` + migrate — see [`docs/recipes/standalone-live-docs.md`](../../../docs/recipes/standalone-live-docs.md).
 - **Adopting an EXISTING repo** (brownfield) is the other branch of the scaffold leg (step 5) — `bongos init --adopt` ([ADR 0121](../../../docs/adr/0121-greenfield-vs-brownfield-onboarding-adopt-existing-repo.md)): detect → accept-gated conflict pre-flight → additive layering (never clobbers) → real version/goal + backlog import. Built; the `bongos onboard` CLI and the hall "start a project" wizard offer the same greenfield-vs-adopt choice.

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

@@ -29,7 +29,7 @@ You are running the **owner review**: the one front door to the four queues that
 
 The four step playbooks are **hidden** skills (`disable-model-invocation: true`): a person can still type their old `/name`, but you cannot load them through the Skill tool. So for each step, **Read that step's `SKILL.md` with the Read tool and follow it in full** — its rank gate, its queue read, its one-decision-at-a-time walk, its write rules and its summary. This file adds no rule of its own to any step and overrides none; where they differ, the step's playbook wins.
 
-**The rank gate runs once.** All four steps are Metic+. Check it at the top — `node scripts/gds/api.js GET /api/bongos/me`, lowercase `builder.rank` — and if it is `xenos` or `thetes`, stop before reading any queue: *"The owner review is a Metic+ step — it decides what the whole team works on. Ask an Archon to promote you."* An absent `rank` follows the pre-rank passthrough each step describes.
+**The rank gate runs once.** All four steps are Metic+. Check it at the top — `node scripts/bongos/api.js GET /api/bongos/me`, lowercase `builder.rank` — and if it is `xenos` or `thetes`, stop before reading any queue: *"The owner review is a Metic+ step — it decides what the whole team works on. Ask an Archon to promote you."* An absent `rank` follows the pre-rank passthrough each step describes.
 
 ## Between steps
 

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

@@ -43,7 +43,7 @@ This mirrors GDS-V3 criterion C2 (`three-ranks-gate-everything`) and matches the
 
 1. Call `GET /api/bongos/me` and read `builder.rank`. Compare case-insensitively (lowercase it before testing). **If it answers `401`, or the CLI says the Bongos CLI session is no longer valid**, stop before anything else and tell the builder to run `/builder-reauth` (the fast Settings re-issue), then re-run this skill — there is nothing to lose yet. (A session that is valid here can still expire before Phase 5, which is why Phase 4 spools and Phase 5 probes again; task 1002865.)
 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 — filed with `node scripts/gds/capture.js "…" --via planning` (or `filed_via: 'planning'` on `POST /inbox`), so the sky records the door they came through (task 1004233; every other filing's door is read off the session). 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).
+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 — filed with `node scripts/bongos/capture.js "…" --via planning` (or `filed_via: 'planning'` on `POST /inbox`), so the sky records the door they came through (task 1004233; every other filing's door is read off the session). 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/bongos/inbox/:id/ratify` endpoint (V3.R31 / #252) can parse it cleanly:
 
@@ -89,7 +89,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/bongos/goals?version=<prev>&status=achieved"
+   node scripts/bongos/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.
@@ -243,7 +243,7 @@ a builder-local one (so the bash/`ssh`/`psql` here is server-side by design, not
 a Windows concern):
 
 ```bash
-node scripts/gds/skill-preflight.js planning-session   # stops here if this box has no ssh
+node scripts/bongos/skill-preflight.js planning-session   # stops here if this box has no ssh
 ssh lars@REDACTED_IP "psql -d example -c '\\d tasks' | grep -i check"
 ```
 
@@ -292,27 +292,27 @@ 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/bongos/goals --body '{"version_id":"<ver>","title":"...","scope_modules":["<key>", ...]}'
+     node scripts/bongos/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/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/bongos/versions/<ver>/done-when --body '{"criterion_id":"<slug>","criterion_md":"...","goal_id":<gid>}'
+       node scripts/bongos/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).
 
-3. **Write a seed script** at `scripts/gds/seed-<ver_slug>-tasks.js` modeled on `scripts/gds/seed-v3-tasks.js` containing:
+3. **Write a seed script** at `scripts/bongos/seed-<ver_slug>-tasks.js` modeled on `scripts/bongos/seed-v3-tasks.js` containing:
    - The TASKS array — one entry per net-new task with full description, kind, discipline, priority, est_minutes, manual_degree, credits_reward, **optional** `touches` (see below), optional `promoted_idea_id`, `depends_on_refs: ['R##', ...]` (the dep edges captured during brainstorm), AND **`criterion_ids: ['Cn', ...]`** — the done-when criterion(s) this task gates. The brainstorm in Phase 3 is already grouped by criterion, so this is just transcribing that grouping. **Use the criterion_id SLUG, not a positional `"Cn"` token.** `Cn` ranks over the whole VERSION's criteria, so on a version holding more than one goal it resolves to some other goal's criterion — which is how all 15 tasks of goal 1000071 were mislinked while the seed printed success (learning 1000188). Since task 1003108 the server **refuses** a positional ref on a multi-goal version (`400 ambiguous_criterion_ref`) rather than guessing, so a slug is the only ref that works there. The server resolves it against the task's version at create (ADR 0025 / task 438). **This replaces the old `**Criterion:** Cn` prose** — don't write that line anymore; pass `criterion_ids` instead so the task is linked in `task_criteria` at creation and `/status` counts it with no backfill.
    - **`touches` is now OPTIONAL (task 882 / [ADR 0049](../../../docs/adr/0049-split-parallel-safety-contract.md)).** Omit it (or leave it blank) unless you already know a tight file set and want the advisory overlap signal during the brainstorm. At first `/builder-ship` the server backfills `touches[]` from the real committed diff — the declared set becomes what git actually reported. Don't burn planning effort predicting file lists; a rough or absent prediction is fine and no longer ship-blocking.
    - **`requires_rank` AUTO-DERIVES — you don't hand-set it per task (task [#1498](https://example.com/builders#/task/1498) / [ADR 0084](../../../docs/adr/0084-auto-derived-per-task-rank-floor.md)).** On create the server floors a task at `metic` when it is `security_sensitive` or its `touches` reach the permission / authz / ship-grade / deploy / migration core (the same protected paths a sub-Metic builder can't push to); everything else stays the open `xenos` default. To deliberately gate a task **higher** than the auto-floor (e.g. owner-only work), pass `requires_rank: 'metic' | 'archon'` on the task — it can only RAISE the floor, never drop below it.
    - **Pass `goal_id: <gid>` on each task** so it lands under its goal (not the version's default catch-all). `POST /tasks` now honors `goal_id` (validated to belong to the version); to move an already-created task, `PATCH /tasks/:id` with `{goal_id}` (task 1763). `criterion_ids` accepts a **slug** (the `criterion_id` you set above), a numeric id, or a `"Cn"` position — **but `Cn` is rejected outright once the version holds a second goal**, and a version almost always gains one. Treat the slug as the only form you write.
    - A main() that POSTs each task **with its `criterion_ids`** (idempotent on `source_ref`; the criterion links are inserted at create, idempotent on `(task_id, criterion_id)`), PATCHes `idea_inbox` for promotions, and after all tasks exist, POSTs `task_dependencies` via `POST /tasks/:id/dependencies` (resolving each R## to the just-created task ID). Idempotent on `(task_id, depends_on_task_id)`. (Need to re-attribute an already-seeded task? `POST /tasks/:id/criteria` with `{criterion_ids:['Cn',...]}`; `DELETE /tasks/:id/criteria/:criterionId` to detach — both Metic+ ([ADR 0090](../../../docs/adr/0090-metic-task-authoring.md)), mirroring the dependency endpoints.)
 
-> **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`.
+> **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/bongos/<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/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`. **Seeding into a goal that already has linked tasks?** Call `baselineSeedCriteria` BEFORE the first write and pass its result as `baseline` to the verify (task 1004668; reference: `scripts/gds/<redacted>.js`) — the check then covers every criterion on the goal, pre-existing counts included, and still catches a stray link on one the seed never meant to touch. With a baseline, tally only the tasks this run CREATED — skip any create that answers `idempotent: true`, since a re-run's replayed task is already inside the baseline and counting it again expects its links twice. Without a baseline only the plan's own criteria are checked. 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/bongos/seed-verify-criteria.js`](../../../scripts/bongos/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/bongos/<redacted>.js`. **Seeding into a goal that already has linked tasks?** Call `baselineSeedCriteria` BEFORE the first write and pass its result as `baseline` to the verify (task 1004668; reference: `scripts/bongos/<redacted>.js`) — the check then covers every criterion on the goal, pre-existing counts included, and still catches a stray link on one the seed never meant to touch. With a baseline, tally only the tasks this run CREATED — skip any create that answers `idempotent: true`, since a re-run's replayed task is already inside the baseline and counting it again expects its links twice. Without a baseline only the plan's own criteria are checked. 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).
 
@@ -328,7 +328,7 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
 
    Both are ordinary carry-overs in any version that has been live for a while, so the blast radius grows the longer an instance runs.
 
-   Every seed script POSTs with `source: 'planning-session'` and a per-seed `source_ref` prefix (see `scripts/gds/<redacted>.js`), which is the handle to scope by — it needs no id transcription and cannot drift from what the seed actually created. **Dry-run the SELECT first and read the rows**, in the same psql session as the migration (or via SSH to the droplet):
+   Every seed script POSTs with `source: 'planning-session'` and a per-seed `source_ref` prefix (see `scripts/bongos/<redacted>.js`), which is the handle to scope by — it needs no id transcription and cannot drift from what the seed actually created. **Dry-run the SELECT first and read the rows**, in the same psql session as the migration (or via SSH to the droplet):
 
    ```sql
    SELECT id, title, priority, kind
@@ -383,16 +383,16 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
 
 ## How to use — quick reference
 
-All API calls go through the cross-platform `node scripts/gds/api.js` helper —
+All API calls go through the cross-platform `node scripts/bongos/api.js` helper —
 it signs each request with your session token (no manual token extraction) and
 runs on Windows/macOS/Linux.
 
 ```
 # Phase 1 — pull state
-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
+node scripts/bongos/api.js GET /api/bongos/public/versions
+node scripts/bongos/api.js GET "/api/bongos/tasks?version=<id>"
+node scripts/bongos/api.js GET /api/bongos/inbox
+node scripts/bongos/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.

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

@@ -102,7 +102,7 @@ Leverage is weighted highest because unblocking the team is the strongest team-l
 - The top-ranked idea is only a valid claim suggestion **if it's already a claimable task**. An open idea is *not* claimable — it's an idea. If the top idea hasn't been promoted to a task yet, say so and offer: *"This isn't a task yet — want me to promote it via `/idea-triage`, or claim the highest-ranked thing that's already a task?"*
 - Filter claimable tasks by the ranking's themes and by Q7: if the builder said "quick win," prefer low `est_minutes`; if "deep block," prefer the high-leverage foundational work even if it's bigger.
 - Never suggest something in the builder's `active_claims`.
-- Present **one** primary suggestion with a one-line rationale tying it to their answers, plus 1–2 runners-up. End with the exact command: `node scripts/gds/claim.js <id> --worktree <name>` (or `/builder-claim <id>`).
+- Present **one** primary suggestion with a one-line rationale tying it to their answers, plus 1–2 runners-up. End with the exact command: `node scripts/bongos/claim.js <id> --worktree <name>` (or `/builder-claim <id>`).
 
 **Write the session-log entry.** A priority session is a real decision on the audit trail — record it. Write `docs/session-logs/YYYY-MM-DD-priority-session.md` (append a numeric suffix if one already exists today) containing:
 
@@ -120,19 +120,19 @@ Prepend a one-line link to the CLAUDE.md §13 Session Log index (newest at top),
 # Auth: cli-lib.js resolves the session token (new path gds-session.json,
 # legacy fallback pms-session.json) and signs every request. Prefer driving the
 # API through it rather than re-deriving the token inline.
-node -e "const {apiCall}=require('./scripts/gds/cli-lib.js'); \
+node -e "const {apiCall}=require('./scripts/bongos/cli-lib.js'); \
   apiCall('GET','/api/bongos/me').then(r=>console.log(JSON.stringify(r.data,null,2)))"
 
 # Phase 1 — pull state
-node -e "const {apiCall}=require('./scripts/gds/cli-lib.js'); \
+node -e "const {apiCall}=require('./scripts/bongos/cli-lib.js'); \
   apiCall('GET','/api/bongos/inbox').then(r=>console.log(JSON.stringify(r.data,null,2)))"
-node -e "const {apiCall}=require('./scripts/gds/cli-lib.js'); \
+node -e "const {apiCall}=require('./scripts/bongos/cli-lib.js'); \
   apiCall('GET','/api/bongos/tasks/claimable').then(r=>console.log(JSON.stringify(r.data,null,2)))"
-node -e "const {apiCall}=require('./scripts/gds/cli-lib.js'); \
+node -e "const {apiCall}=require('./scripts/bongos/cli-lib.js'); \
   apiCall('GET','/api/bongos/blockers').then(r=>console.log(JSON.stringify(r.data,null,2)))"   # read-public
 
 # Phase 4 — the suggestion resolves to a real claim command
-node scripts/gds/claim.js <task_id> --worktree <worktree-name>
+node scripts/bongos/claim.js <task_id> --worktree <worktree-name>
 ```
 
 The read shapes (`/inbox` → `{ ideas, open_count }`, `/me` → `{ builder, active_claims }`) are the same ones `/idea-triage` and `/planning-session` use. Mirror those read patterns rather than inventing new ones. There is no priority-session write to the inbox today — see "Persisting the reweighting — not yet wired" above.