@bongos/core 1.17.0

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

@@ -0,0 +1,43 @@
+---
+name: close-box
+description: Tear down the dev box you are working on, from inside the box's terminal. Asks the GDS to deprovision the caller's own box (POST /box/close — the same action as the builders'-hall "Close box" button). Triggers when the user says "/close-box", "close my box", "shut down this box", "I'm done with this box", "tear down my dev box". Own-scoped — it deprovisions only the caller's own box; it never touches another builder's box or any other infrastructure (those live on the operator control plane, node scripts/gds/box.js).
+---
+
+You are closing (deprovisioning) the dev box the builder is currently working on. This is the Claude-side twin of the `close-box` shell command (`infra/close-box.sh`) — same endpoint, for builders who'd rather say "/close-box" inside `claude` than drop to the shell. It is own-scoped and destructive (the box is destroyed), so confirm before firing.
+
+## Background
+
+A per-builder dev box (ADR 0031 §2) is a DigitalOcean droplet. Closing it enqueues a `deprovision` intent that the control-plane runner executes within ~a minute. The box's disk is gone after that — anything in `/workspace` that was not pushed to its remote is lost. The box is cheap to recreate from the builders' hall ("Request dev box" / `/builder-box`), so closing when done is the right cost hygiene; the idle-suspend sweep would otherwise park it automatically after the idle window.
+
+The endpoint:
+- `POST /api/gds/box/close` → enqueues `deprovision` for the **caller's own** box (`auth.requireBuilder`, own resource). Idempotent-ish: if there's no active box it just no-ops.
+
+## What this skill does
+
+Calls `POST /api/gds/box/close` via the cross-platform helper, after confirming with the builder.
+
+## How to use
+
+1. **Confirm intent.** Ask plainly: "Close (deprovision) your dev box? Any work in `/workspace` you haven't pushed will be lost." Proceed only on a clear yes. If the builder only wants to stop *using* it for now (not destroy it), tell them they can just close the tab — with session persistence (#893) their work survives and the box auto-parks when idle — and do NOT close it.
+
+2. **Fire the close:**
+   ```
+   node scripts/gds/api.js POST /api/gds/box/close
+   ```
+   (The helper resolves the GDS session token + API base itself; no manual token handling.)
+
+3. **Relay the outcome.** On success tell the builder:
+   - The box is closing now (a few seconds).
+   - They can close the browser tab — and if the builders'-hall tab is still open in the background, it auto-closes the terminal tab for them when it sees the box shut down (`modules/hall-ui/public/box-panel.js`). This skill cannot close the tab itself (it has no browser control).
+   - They can provision a fresh box anytime from the hall or with `/builder-box`.
+
+## Constraints
+
+- **Own box only.** This never deprovisions another builder's box. Operator-scoped lifecycle (provision / park / wake / destroy-any) lives in `node scripts/gds/box.js`, gated by rank — not here.
+- **Don't auto-close without a yes.** It is destructive.
+- **It cannot close the browser tab.** Be honest about that — see the relay step.
+
+## Files this skill touches
+
+- Reads: `~/.config/otb/gds-session.json`
+- Calls: `POST /api/gds/box/close`

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

@@ -0,0 +1,69 @@
+---
+name: design-sync
+description: Export the repo design system into Claude Design so prototypes start from real tokens and component surfaces, then land Claude Design's generated UI code back as a GDS task. Triggers when the user says "/design-sync", "sync design", "export tokens to Claude Design", "import to Claude Design", or "push design system".
+---
+
+You are helping the builder run the Claude Design sync loop: export the repo's design tokens and surfaces into Claude Design so any prototype starts from real values, not guesses.
+
+## What this skill does
+
+1. **Import** — `node scripts/gds/design-sync.js` builds a token-preview bundle (HTML color/typography/spacing/radii cards, `tokens.css`, `tokens.json`, `surfaces.json`) in a temp directory and prints a JSON manifest.
+2. **Push** — the DesignSync MCP tool (`list_projects` → `finalize_plan` → `write_files`) uploads the bundle to a Claude Design project.
+3. **Export (handoff)** — when Claude Design generates UI code, the handoff lands it under a claimed GDS task via `adapter.export()`.
+
+## How to use
+
+### Step 1 — Build the bundle
+
+```bash
+node scripts/gds/design-sync.js
+```
+
+Prints JSON to stdout: `{ bundlePath, files, surfaceIds, summary }`.
+
+To limit to one surface:
+```bash
+node scripts/gds/design-sync.js --surface <id>
+```
+
+### Step 2 — Push to Claude Design
+
+Use the **DesignSync MCP tool** (`mcp__DesignSync__*`):
+
+1. `list_projects` — pick the target project (or create one).
+2. `finalize_plan` — stage the file list from `manifest.files`, with `bundlePath` as the base.
+3. `write_files` — push the staged files.
+
+HTML files with `<!-- @dsCard group="Tokens" -->` appear as Design System cards in Claude Design.
+
+### Step 3 — Receive Claude Design output (export)
+
+When Claude Design finishes and hands off to Claude Code, call the adapter directly in Node:
+
+```js
+const adapter = require('./src/ui/adapters/claude-design/index.js');
+await adapter.export({
+  repoRoot: process.cwd(),
+  surfaceId: '<surface-id>',       // e.g. "hall-ui"
+  toolOutput: { files: [          // from Claude Design
+    { path: 'components/Card.js', content: '...' },
+  ]},
+  taskId: '<gds-task-id>',        // optional — links the sync back to the claim
+});
+```
+
+Files write to `src/ui/<surfaceId>/`. `config/design-sources.json` is updated with the sync timestamp and tool name.
+
+## Token system
+
+Tokens live in `config/design-tokens.neutral.json` (baseline) + `config/design-tokens.json` (instance override, merged on top). The adapter resolves the merged tree and emits `--dt-<group>-<key>` CSS vars in `tokens.css`. Full recipe: `docs/recipes/claude-design-loop.md`.
+
+## Path safety
+
+The export step enforces path safety: no file from Claude Design may escape `src/ui/<surfaceId>/` or `assets/ui/<surfaceId>/`. A path-escape attempt throws before any write.
+
+## After using this skill
+
+- The generated `tokens.css` is a read-only artefact (regenerated each sync) — do not hand-edit it.
+- New `config/design-sources.json` entries from `export()` should be committed alongside any generated UI code.
+- Full loop recipe (multi-iteration, troubleshooting, Figma coexistence): `docs/recipes/claude-design-loop.md`.

package/.claude/skills/dev/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: dev
+description: The engineering session — the operating playbook for engineer-discipline work (code, infra, the GDS itself, bugs, performance). Triggers when the user says "/dev", "let's build this", "work on this bug/feature", "start a dev session", or when a claimed task's discipline routes here (claim.js prints a directive to invoke /dev for engineer tasks). This is the project's DEFAULT build loop, written down — the baseline the other discipline modes (/ideate, /paint) invert from.
+---
+
+You are running an **engineering session** for Off the Boats. Unlike `/ideate` (which flips *who drives*) and `/paint` (which flips *the medium*), this skill introduces no new dynamic — engineering **is** the default text-and-code loop. Its job is to make the standard explicit and keep you on it. Read it before working; lean on it most when you're new here or running autonomously.
+
+## The loop: understand → scoped change → verify → ship
+
+1. **You hold a claim — keep the work inside it.** Everything you change should serve the claimed task. An out-of-scope fix you spot along the way is a *separate* task or an idea (`node scripts/gds/capture.js`), not a quiet addition to this diff. Scope creep is the most common way an engineering session goes wrong.
+
+2. **Understand before you edit.** Read the code you're about to change and the layer around it first:
+   - The nested `CLAUDE.md` in the directory you're working in (loads on demand — it has the gotchas).
+   - `docs/repo-map.md` (the symbol skeleton) to navigate without reading every file — it's gitignored + regenerated at deploy/box-fetch (ADR 0110), so if it's absent in your tree run `node scripts/gds/gen-repo-map.js`. And `/recall <topic>` to find what's already known/decided so you don't re-solve it.
+   - Match the surrounding code: its naming, its idioms, its comment density. Code you write should read like the code already there.
+
+3. **Make the smallest correct change.** Prefer the change that solves the task and nothing more. Don't refactor adjacent code "while you're here" unless the task is the refactor.
+
+4. **Verify it — never report done on faith.** This is the step engineers most often skip:
+   - Run the smoke tests (`/builder-ship` runs them, but run them yourself while iterating).
+   - If the change is observable in the running app, use the **preview / verification workflow** (preview_start → reload → check console/snapshot → screenshot proof) rather than asking a human to check manually. Verify, then share the proof.
+   - If it's not browser-observable (a different runtime, types, tooling), say so and verify the way that *does* exercise it.
+
+5. **Ship with a real handoff.** `/builder-ship` chains completed → confirmed (credits, smoke) → shipped (grade, merge, deploy). Give it genuine `--notes` (what changed + how you verified) and a non-jargon `--summary` (the business-owner audience reads it in Discord #ship-news). If the grader flags findings, fix them and re-grade — don't reach for an override.
+
+## Supporting discipline (the things that keep the ledger honest)
+
+- **Every change is backed by the claimed task** — no admin/tiny-fix/scaffolding loophole (CLAUDE.md §8). Direct DB writes are work too.
+- **Non-obvious decision → an ADR** in `docs/adr/`, linked from the shipping task's notes.
+- **A discovery that took >10 min to diagnose → a learning** (`node scripts/gds/learning-capture.js`); a multi-page how-to → a recipe under `docs/recipes/`.
+- **Blocked on something only Lars can decide/provide → a blocker** (`POST /api/gds/blockers`), attached to the task.
+- **Touched anything the onboarding diagrams / repo-map describe** → they regenerate on deploy; never hand-edit generated artifacts — edit the source/template and run the generator (`gen-diagrams.js`, `gen-repo-map.js`).
+- **Trust boundary:** a sub-Metic builder (Xenos/Thetes) stays out of the permission/pipeline core (rank/authz machinery, the ship/grade/deploy pipeline, `migrations/`, `infra/`, trust-boundary docs) and never runs raw `git push origin main` / `ssh` / `~/deploy.sh` — landing code is the GDS's job (`/builder-ship`). Metic+ is unaffected.
+
+## Step 0 — detect the mode
+
+**Is a human present?**
+
+- **Interactive** (someone is here to decide): work collaboratively — propose the approach for anything non-obvious, let the human steer the design calls, then execute. You can think out loud; engineers are fine with text.
+- **Autonomous / bypass-permissions** (no human will answer): tighten up.
+  - Be **conservative** — the smallest correct change, the lowest-risk path. No human is here to catch a wandering edit.
+  - **Verify harder**, not less — smoke + preview proof before you call it done, because nobody else will look first.
+  - **Don't invent scope or wander** into adjacent work, refactors, or "improvements" the task didn't ask for. If you spot them, capture them as ideas/tasks and move on.
+  - If the task is **ambiguous or you hit a real blocker**, leave a clear note (blocker / release with a reason) rather than guessing at something large and irreversible.
+
+## How sessions reach this skill
+
+- **Standalone:** invoke `/dev` directly when you want the engineering checklist in front of you.
+- **From a claim:** when a builder claims an `engineer`-discipline task, `claim.js` reads `scripts/gds/discipline-modes.json` and notes that `/dev` is this task's playbook. Engineering is already the default loop, so this is a *reminder of the standard* (and the autonomous-mode guardrails), not a redirect away from how you'd otherwise work. All three disciplines route uniformly through the same map.

package/.claude/skills/feedback/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: feedback
+description: Pull the latest Bongos feedback bundle into this Claude Code session — the prompt.md walkthrough the Bongos app wrote (transcript + the ask) plus the screenshots it captured, loaded by absolute path so the Read tool can see them. Triggers when the user says "/feedback", "pull in my latest feedback", "load my bongos feedback", "I just recorded a walkthrough", "grab the latest feedback bundle", or "act on my screen recording". Local + read-only; no GDS auth needed.
+---
+
+You are pulling in the **latest Bongos feedback bundle** — a self-contained capture the user just recorded with the Bongos desktop app (BV1.R13 / [ADR 0087](../../../docs/adr/<redacted>.md)). The app turns a spoken screen walkthrough into a model-agnostic `prompt.md` (a timestamped transcript + an ask) plus a handful of screenshots, all under `~/CloudBongos/feedback/`. This skill loads that bundle so you can act on it directly — no copy-paste, no clipboard-image fiddling.
+
+## Steps
+
+1. **Resolve + print the latest bundle:**
+
+   ```bash
+   node scripts/gds/feedback-latest.js
+   ```
+
+   This prints the full `prompt.md` body followed by an `attached frames` list — one **absolute image path** per line. (Add `--json` if you want structured output instead.)
+
+2. **If it says "No feedback bundle found"** — tell the user there's nothing to load yet: record a walkthrough in the Bongos app and stop the capture (that writes the bundle), then run `/feedback` again. Stop here.
+
+3. **Read every listed frame.** For each absolute path under `attached frames`, call the **Read** tool on it so the screenshots enter your context as images. The paths are real files on disk — Read them directly; do not ask the user to paste anything.
+
+4. **Act on the bundle.** Treat the transcript in `prompt.md` as the request and the screenshots as ground truth for what the user was looking at (the timestamps line the words up with the images). Work out what they want changed or fixed and do it. Ask a question only if you are genuinely blocked.
+
+## Notes
+
+- **Read-only + local.** The helper only reads files under `~/CloudBongos/feedback/`; it needs no GDS session and no network.
+- **"Latest" = most recently produced.** The Bongos app updates a `latest` pointer every time a capture is stopped, so this always loads the newest walkthrough. To act on an older one, point the user at the specific dir under `~/CloudBongos/feedback/`.
+- **The frames are file paths, never base64** — that's the whole point of the bundle format (it keeps the text prompt tiny and lets your Read tool load the images). See `bongos-app/README.md` for the full bundle contract.
+
+## Files this skill touches
+
+- Runs: `node scripts/gds/feedback-latest.js` (resolves via `bongos-app/src/handoff.js`).

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

@@ -0,0 +1,74 @@
+---
+name: figma-design-sync
+description: Sync the repo's UI design system (tokens + surfaces) with Figma — push current state so a designer never opens a stale file, then land a designer's Figma edit back as committed code. Triggers when the user says "sync design to Figma", "push tokens to Figma", "pull my Figma edit into code", or "figma round-trip". Distinct from otb-figma-sync, which is scoped to pixel-art tile review in the example Figma file only — this skill is the UI-surface round-trip from ADR 0081.
+---
+
+You are helping the builder run the Figma round-trip loop for the `ui` discipline's design surfaces: push the repo's current tokens/surfaces into Figma so a designer always starts from real state, then bring a designer's Figma edit back into the repo as committed-ready code.
+
+## What this skill does
+
+1. **Import (push)** — `node scripts/gds/figma-design-sync.js` builds a push plan (`figma-plan.json`: color-swatch frame, typography-specimen frame, one reference frame per surface) in a temp directory and prints a JSON manifest.
+2. **Push** — the live Figma MCP tool (`mcp__figma__*` write capability, or `use_figma`) creates/updates the frames described in the plan inside the target Figma file. If write capability isn't available in this session, stop and surface the gap — do not fake the push.
+3. **Export (handoff)** — when a designer finishes a Figma edit, hand its output to `adapter.export()`.
+
+## How to use
+
+### Step 1 — Build the push plan
+
+```bash
+node scripts/gds/figma-design-sync.js
+```
+
+To limit to one surface:
+```bash
+node scripts/gds/figma-design-sync.js --surface <id>
+```
+
+### Step 2 — Push to Figma
+
+Use the live Figma MCP tool to realize each frame in `figma-plan.json` as real nodes (rectangles for swatches, text nodes for typography specimens). Confirm the target Figma file with the builder before writing — never assume which file.
+
+### Step 3 — Receive the designer's edit (export)
+
+Figma hands back one of two shapes, depending on whether Code Connect is wired for the component:
+
+**Code Connect output (ready code — the common case):**
+```js
+const adapter = require('./src/ui/adapters/figma/index.js');
+await adapter.export({
+  repoRoot: process.cwd(),
+  surfaceId: '<surface-id>',
+  toolOutput: { files: [{ path: 'Card.js', content: '...' }] },
+  taskId: '<gds-task-id>',
+});
+```
+
+**Raw Figma MCP node snapshot (no Code Connect mapping yet):**
+```js
+await adapter.export({
+  repoRoot: process.cwd(),
+  surfaceId: '<surface-id>',
+  toolOutput: { snapshot: { nodes: [/* Figma node objects */] } },
+  taskId: '<gds-task-id>',
+});
+```
+
+The adapter translates simple frames/text/solid-fill rectangles into code. A node with an image or vector fill (icons, illustrations, freeform art) comes back as a `warnings[]` entry telling you to export it as an asset under `assets/ui/<surfaceId>/` instead — it is never silently dropped, and never forced into code it can't honestly represent.
+
+## Fidelity limit (be upfront about this)
+
+Round-trip fidelity is limited to what Code Connect or the Figma MCP can extract (ADR 0081). Arbitrary canvas art (icons, illustrations, freeform vector work) becomes a committed asset, not round-tripped code — that is the honest cost of the human escape hatch, not a bug.
+
+## Code-canonical vs. Figma-canonical
+
+Code-canonical is the default: the repo is authoritative, Figma is a synced view. A surface may be flagged `"figmaCanonical": true` in `config/design-sources.json` as an explicit exception (docs/design-contract.md §3.4) — only do this when the builder explicitly asks for a surface a designer actively iterates on in Figma.
+
+## Path safety
+
+The export step enforces path safety: no file (or translated snapshot node) may escape `src/ui/<surfaceId>/` or `assets/ui/<surfaceId>/`. A path-escape attempt throws before any write.
+
+## After using this skill
+
+- New `config/design-sources.json` entries from `export()` should be committed alongside any generated UI code.
+- Run `node scripts/gds/validate-design.js` after touching adapters or design-sources — it's wired into `scripts/gds/fitness.js` as a hard-fail once any adapter is present.
+- This is the UI-surface loop (ADR 0081). For pixel-art tile review in the example Figma file, use `otb-figma-sync` instead — the two skills never touch the same Figma file or the same directories.

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

@@ -0,0 +1,89 @@
+---
+name: goal-review
+description: Walk the GDS criterion review queue — for each criterion auto-flagged "met — pending review" (all its tasks shipped, not yet confirmed), prompt to confirm (→ satisfied), reject (not actually met), or note/defer. Confirming a goal's LAST criterion auto-flips the goal open→achieved. Triggers when the user says "/goal-review", "review goals", "review flagged criteria", "what criteria are ready to confirm", "confirm criteria", "walk the goal review queue", or runs as a scheduled daily task. Metic+ rank only (Metic and Archon; not Xenos).
+---
+
+You are running the **goal-review** session for this Cloud Bongos instance. It mirrors `/idea-triage`, but for the *closing* end of the work hierarchy (ADR 0086 §6): criteria that have **auto-flagged "met — pending review"** get walked one-at-a-time and dispositioned, so finished work actually closes out instead of sitting in limbo.
+
+**The auto-flag is derived, not stored.** When every task linked to a criterion has shipped — and the criterion has not yet been confirmed — the server flags it `pending_review` (deterministic from `task_criteria` + ship status; no manual propose step). This skill surfaces that queue and lets a trusted builder confirm or reject each one. Confirming sets the criterion `satisfied=true`; confirming a goal's **last** unsatisfied criterion auto-flips the goal `open → achieved`.
+
+## 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.EXPECTED_RANKS` — 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/<redacted>.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).
+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>`).
+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.
+
+## How to use
+
+**Step 1 — fetch the review queue.**
+
+```
+node scripts/gds/api.js GET /api/gds/done-when/pending-review
+```
+
+(Add `?version=BONGOS-V1` to scope to one version. `api.js` is the cross-platform GDS API helper — it signs the request with your session token.)
+
+If `count` is 0, print "review queue empty — no criteria pending review today" and exit.
+
+Each row carries: `id` (the criterion's numeric id — what you POST to), `criterion_id` (the slug) + `criterion_md` (the prose), `version_id`, `goal_id` + `goal_title` + `goal_status`, `task_total` (how many shipped tasks fulfilled it), and **`is_last_in_goal`** — `true` when this is the goal's only remaining unsatisfied criterion, so **confirming it will auto-achieve the goal**.
+
+**Step 2 — walk the list, criterion by criterion.**
+
+Present each criterion with: its `criterion_md`, its goal (`goal_title`), how many tasks shipped under it (`task_total`), and — when `is_last_in_goal` is true — a clear flag:
+
+> ⚠️ This is the LAST open criterion in **{goal_title}** — confirming it will mark the whole goal **achieved**.
+
+Then ask the user (concise; frame in product/outcome terms — Lars is an EE, not a software engineer):
+
+> Criterion C{n} — "{criterion_md}". {task_total} task(s) shipped under it. **Confirm it's met, reject (not actually done), or defer?**
+
+**Step 3 — apply the verdict.**
+
+**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 '{}'
+# 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>}'
+```
+
+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.)
+
+**Reject** → the criterion's tasks all shipped, but on review it is **not actually met** (the work missed something, or "done" was mis-scoped). There is no "unsatisfy the flag" — the flag is *derived* from shipped tasks, so the durable fix is to **add the missing work**: capture what's still needed (a follow-up task linked to this criterion, or an idea via `node scripts/gds/capture.js "..."`), and note the rejection in the session log. Once an unshipped task is linked to the criterion, it drops out of `pending_review` on its own. If no follow-up is filed, the criterion simply stays flagged and resurfaces next session — an honest signal that a human said "not done" but nothing was queued to close the gap. **Do not confirm a criterion you would not stake the version on.**
+
+**Note / defer** is implicit — leave the criterion un-confirmed by not POSTing. It stays in the queue and surfaces again next session (same as `/idea-triage`'s defer).
+
+**Step 4 — achieved goals (disposition).**
+
+Any goal that flipped to `achieved` this session (or is already `achieved`) awaits a disposition: **archive** it (done, put it to rest) or **carry it forward** into the next version's scope. Surface each newly-achieved goal to the user and record the intended disposition in the session log.
+
+> The archive / reopen / carry-forward **actions** (the routes that mutate goal lifecycle) land in **BV1.R64** ([task 1518](https://example.com/builders#/task/1518)) — they are not wired here. For this session, *report* achieved goals and capture the intent; once R64 ships, this step gains the verbs to execute it.
+
+**Step 5 — surface a summary.**
+
+Report to the user:
+- Total criteria walked
+- Confirmed (count + ids)
+- Goals auto-achieved (count + titles)
+- Rejected (count + ids + what follow-up was filed)
+- Deferred (count + ids — these surface again next session)
+- New queue `count`
+
+## Why we run this
+
+Without a closing cadence, criteria pile up "done but unconfirmed" and goals never flip to achieved — the version looks perpetually in-progress even when the work has shipped. A fast pass keeps the rollup honest. As with `/idea-triage`, the cadence is the discipline; a quick walk with mostly defers beats skipping it.
+
+## Tone for the user
+
+Lars is the prompter (see CLAUDE.md §2). Frame each decision in terms of outcome — "this criterion was 'players see each other'; both tasks shipped — is that actually true in the live game?" not "flip satisfied=true on criterion 45." Decide the mechanics yourself; ask him only about whether the thing is *really* done.

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

@@ -0,0 +1,144 @@
+---
+name: idea-triage
+description: Daily walk through the GDS idea_inbox — for each open idea, prompt to promote (→ task), discard, or merge with another idea. Triggers when the user says "/idea-triage", "triage ideas", "review the inbox", "walk the idea inbox", or runs as a scheduled daily task. Metic+ rank only (Metic and Archon; not Xenos).
+---
+
+You are running the daily idea-triage session for Off the Boats. Open ideas in the GDS `idea_inbox` table get walked one-at-a-time and verdicted, so the inbox doesn't accumulate stale entries.
+
+## 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/<redacted>.md)). A Xenos can still **file** an idea (`POST /api/gds/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.
+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.
+
+> Belt-and-braces: the server already rejects `PATCH /inbox/:id` with `403 rank_forbidden` for non-Metic+ callers (#360 / ADR 0018) — this check just stops a Xenos early instead of after a whole walk of 403s. Markdown never grants authority (criterion C7).
+
+## What this skill does
+
+1. Lists open ideas via `GET /api/gds/inbox`.
+2. **Develops the open ideas in parallel** — spawns one subagent per idea (the Agent tool) that fleshes the one-liner out into a structured *open-questions / challenges / risks* block, so the Archon verdicts on a developed idea instead of a bare title (task 930).
+3. 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).
+4. Updates each idea via `PATCH /api/gds/inbox/:id` with the verdict.
+
+## How to use
+
+**Step 1 — fetch the open inbox.**
+
+```
+node scripts/gds/api.js GET /api/gds/inbox
+```
+
+(`api.js` is the cross-platform GDS 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
+walk interactively instead.)
+
+If `open_count` is 0, print "inbox empty — nothing to triage today" and exit.
+
+**Step 1.5 — develop the open ideas in parallel (task 930).**
+
+Before walking the list, **flesh out each open idea with a subagent** so the verdict lands on a developed idea, not a one-liner. Spawn the subagents **in parallel** (multiple `Agent` tool calls in a single message) — they run while you prepare the walk, so there's no serial wait.
+
+- **Model:** `opus` for every development subagent. This is research / design analysis against the live repo, which per CLAUDE.md §2's routing table is Opus work — never inherit silently, never downgrade to Haiku.
+- **Fan-out cap:** develop up to **12** ideas per session (oldest-first — `captured_at` ascending). If there are more than 12 open, note "developed the 12 oldest; the rest are walked undeveloped" so nothing is silently dropped.
+- **One idea per subagent.** Give each subagent the idea's `id`, `title`, `body_md`, `kind`, and `captured_by`, and this instruction:
+
+  > Flesh out this Off the Boats idea for an Archon triage verdict. Read the relevant code/docs to ground yourself (start from CLAUDE.md and the surfaces the idea touches). Return ONLY a JSON object with these keys: `summary` (one sentence, what integrating it actually means), `integration_surfaces` (array of files/areas it would touch), `open_questions` (array — the decisions a human must make before this can be a task), `challenges` (array — what's hard or unclear), `risks` (array — what could break or regress), `rough_effort` (one of `S`/`M`/`L`), `recommendation` (one of `promote`, `discard`, `merge:#<id>`, `needs-info`). Keep each array item to one line. Do not invent surfaces you didn't verify exist.
+
+- **Collect the results into a development cache** keyed by idea id and write it to a temp file so the deterministic walker can also surface it:
+
+  ```json
+  { "generated_at": "<ISO>", "ideas": { "228": { "summary": "...", "integration_surfaces": ["..."], "open_questions": ["..."], "challenges": ["..."], "risks": ["..."], "rough_effort": "M", "recommendation": "needs-info" } } }
+  ```
+
+  Write it to `${TMPDIR:-/tmp}/otb-idea-development.json` (Windows: `%TEMP%\otb-idea-development.json`). A subagent that fails or returns unparseable JSON is simply omitted from the cache — that idea is walked undeveloped, not blocked.
+
+If a human will run the interactive walker instead of the Claude-driven walk below, hand it the cache:
+
+```
+node scripts/gds/triage.js --development "${TMPDIR:-/tmp}/otb-idea-development.json"
+```
+
+`triage.js` prints each idea's developed block above its verdict prompt. It never *generates* the analysis (that's this skill's subagent fan-out) — it only displays what the cache holds, and runs exactly as before when no cache is present.
+
+> **Not in this cut (follow-up leg).** The next step is to let the Archon push the developed `open_questions` *back to the submitter* — a round-trip in the Discord `#ideas` thread / DM before promotion — so the submitter says how they'd want it integrated. That needs the Discord bot interaction + idea↔thread linking (idea #216 / [ADR 0033](../../../docs/adr/<redacted>.md)) and is tracked separately. For now the open questions are answered by the Archon in-session.
+
+**Step 2 — walk the list, idea by idea.**
+
+Present each idea with:
+- id + kind (auto-classified by B2)
+- title
+- body_md (full)
+- captured_at + captured_by
+- **its developed block** (from Step 1.5): summary, integration surfaces, open questions, challenges, risks, rough effort, and the subagent's recommendation
+
+Then ask the user (concise prompt — Lars is an EE, not a software engineer; frame in product/outcome terms). Lead with the developed open questions, since those are what the Archon actually needs to decide:
+
+> Idea #N: "{title}". {one-sentence developed summary}. **Open questions:** {the subagent's open_questions}. **Promote, discard, or merge with another idea?**
+
+**Step 3 — apply the verdict.**
+
+**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/<redacted>.md)). (Filing a task *under a goal* — stamping `tasks.goal_id` — is the bounded-authoring route's job, R60; until it lands, promote to a task at the version level and link it to a goal's criteria via `criterion_ids`.)
+
+  ```
+  # 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>
+  #    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>}'
+  ```
+
+- **Promote → goal** (Metic+; Archon if the scope includes a `protected` module). 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"}'
+  ```
+
+- **Promote → criterion** (Archon — 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"}'
+  ```
+
+  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.
+
+**Discard** → mark it closed:
+
+```
+node scripts/gds/api.js PATCH /api/gds/inbox/<idea_id> --body '{"status":"discarded"}'
+```
+
+**Merge** → ask the user which other idea N is the canonical one, then mark this one merged:
+
+```
+node scripts/gds/api.js PATCH /api/gds/inbox/<idea_id> --body '{"status":"merged","promoted_to_task_id":<canonical_idea_or_task_id>}'
+```
+
+**Defer** is implicit — leave the idea open by not patching it. Inbox count stays the same; the idea will surface again tomorrow.
+
+**Step 4 — surface a summary.**
+
+Report to the user:
+- Total walked
+- Promoted (count + new task ids)
+- Discarded (count + ids)
+- Merged (count + ids)
+- Deferred (count + ids — these will surface again next session)
+- New inbox open_count
+
+## Why we run this daily
+
+Daily cadence keeps the inbox actionable. If the user is busy, a fast pass with mostly "defer" verdicts beats skipping the session — the cadence is the discipline, not the volume of decisions.
+
+## Tone for the user
+
+Lars is the prompter (see CLAUDE.md §2). Frame promotion decisions in terms of product outcome, not implementation: "this would let the player resume after refresh" not "this would add a localStorage hook." Decide the implementation details yourself when promoting.

package/.claude/skills/ideate/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: ideate
+description: The ideation session — the operating playbook for ideator-discipline work. Triggers when the user says "/ideate", "let's ideate", "I want to brainstorm", "help me think through an idea", "start an ideation session", or when a claimed task's discipline routes here (claim.js prints a directive to invoke /ideate for ideator tasks). Inverts the usual dynamic: the human ideator drives, Claude is the sounding board. Open to any rank for FILING ideas (Xenos+ can capture; only Metic+ can triage).
+---
+
+You are running an **ideation session** for Off the Boats. This is not the build-and-ship loop. Read this whole file before acting — it changes how you behave for the rest of the session.
+
+## The one rule that makes this different: you are the instrument, not the author
+
+In every other discipline, Claude does the work and asks the human to approve it. **Here it is inverted.** The ideator is the creative driver; *you are the sounding board, the research arm, and the devil's advocate they reach for.* Your job is to give them room to think and to be the one they *ask* — not to hand them finished ideas and file them.
+
+Concretely, that means:
+
+- **Do not dump a batch of ideas.** Producing "5-8 ideas" on command is exactly the failure mode this skill exists to kill. Volume is not the goal; a developed, pressure-tested idea is.
+- **Provoke, don't conclude.** Offer directions, tensions, and questions — "here are three ways this could go, which pulls at you?", "what's the version of this that scares you?", "here's why this might be a bad idea — talk me out of it." Let the human choose the thread.
+- **Do the legwork they ask for, on demand.** Search the inbox, run `/recall`, check lore consistency, figure out what an idea would actually touch. You are their research arm; they should never have to do the digging.
+- **The human decides what gets filed.** You only `capture.js` an idea once they've blessed it. The conversation is the product; the filed idea is its residue.
+
+## Step 0 — detect the mode, because it changes everything
+
+**Is a human present in this session?**
+
+- If you are in a normal interactive session (the user is typing to you, you can ask a question and get an answer) → **Interactive mode** (below).
+- If this is an autonomous / bypass-permissions / scheduled run (no human will answer a question — e.g. you were dispatched by the overnight runner, or permission mode skips all prompts) → **Autonomous mode** (further below).
+
+If you are unsure, ask once: *"Are you here to ideate with me, or should I run this autonomously?"* — if no answer comes, treat it as autonomous.
+
+## Step 1 (both modes) — load the ground before you think
+
+Run these first so every idea lands against reality, not in a vacuum:
+
+1. **What's already filed** — `node scripts/gds/api.js GET /api/gds/inbox`. You will not propose near-duplicates of open ideas; if a thread overlaps one, say so and build *on* it instead.
+2. **What we already know** — use `/recall <theme>` (the rank-scoped knowledge search) for any theme you're about to explore, so you're not re-suggesting something already decided or shipped.
+3. **The world's voice** (for product ideas) — CLAUDE.md §3/§6/§7 and `docs/project-context.md`: ancient-Greek Mediterranean coast just south of Athens, mythic "discovered secret" tone, Example / Example. Not modern, not tongue-in-cheek. (For builder-UX / internal ideas, that voice doesn't apply — judge them on the rough edge they smooth.)
+
+## Interactive mode — a real conversation
+
+1. **Find the seed.** Ask what they want to chase, or offer 2-3 themes drawn from the inbox gaps and the world. Let them pick one. Don't pre-write the ideas.
+2. **Develop ONE thread at a time, with them.** Take the chosen direction and pull the *triage development work forward* — together, shape it into: what it actually is (one line of lore or one line of UX), what it would touch, the open questions, the risks, the strongest version. Surface one or two options, react to their steering, go deeper. This deep thinking is the *point* of the role — do not outsource it to a later triage pass.
+3. **Play devil's advocate honestly.** Tell them when an idea is thin, anachronistic, a near-dupe, or unactionable. A good sounding board pushes back.
+4. **File only what they bless.** When they say an idea is worth keeping, capture it (see *Filing* below) with its developed body — surfaces, open questions, the lore/UX line. What lands in the inbox should already be rich, so the Metic's triage is a light verdict on developed material, not archaeology on a bare title.
+5. **There is no quota.** One deeply-developed idea is a great session. So is six sparks if that's where the energy went. Follow the thinking, not a count.
+
+## Autonomous mode — internalize the partnership, don't fake it
+
+No human is here to spark or judge, so you must *simulate* the loop honestly instead of degenerating into a content generator.
+
+1. **Diverge broadly.** Generate a wide field of candidates across the inbox's gaps (don't cluster around one theme).
+2. **Critique adversarially — keep only survivors.** Put each candidate through multiple lenses and discard the ones that fail:
+   - Novel vs. the open inbox and `/recall` results? (kill near-dupes)
+   - Genuinely in-world / on-track? (kill anachronisms and off-track noise)
+   - Actually actionable — could a triager turn it into a task? (kill vague vibes)
+   - Is this its strongest form, or a weak first draft? (sharpen or cut)
+   - *(This is the shape a Workflow does well — fan-out generate → adversarial verify → keep survivors. Use one if the run warrants it; it is an implementation choice, not a requirement.)*
+3. **File honestly, flagged.** For each survivor, capture it with two extra body lines so triage knows it had **no human spark**:
+   - `origin: autonomous`
+   - an `open questions:` block — the decisions you *would have asked a human*, left open rather than silently resolved.
+   Do not pretend an autonomous idea carries human judgment it never got. A smaller set of honestly-flagged, developed ideas beats a big confident dump.
+4. **Leave the thread for a human.** End by noting (in the session log / ship notes) which themes you explored and which open questions a human should weigh in on next.
+
+## Filing — the only write this skill makes
+
+File each blessed/surviving idea with `capture.js` and a body file:
+
+```
+node scripts/gds/capture.js "<title>" --body-file <path>
+```
+
+The body should carry the development, not just a sentence. Use these line-tag conventions (**no schema change**):
+
+- One line of substance: for a product idea, the lore (who/what it is); for an internal/build idea, the rough edge and what "better" looks like.
+- The developed block when you have it: `surfaces:`, `risks:`, `open questions:`.
+- In autonomous mode only: `origin: autonomous`.
+
+## Trust boundary — filing is open, triage is not
+
+Filing into the inbox is open to **any** authenticated builder (Xenos included) — that path stays open here. **Triage** (promote / discard / merge) reshapes the whole team's backlog and is **Metic+ only** (`/idea-triage`). So in this skill you *file*; you never verdict. If an ideator asks to promote their own idea and they're sub-Metic, explain that triage is a trusted-builder step and their idea is now queued for it.
+
+## How sessions reach this skill
+
+- **Standalone:** the user invokes `/ideate` directly — including with no task claimed. An ideator should never *need* a claimed chore to start thinking; "I'm just exploring" is a first-class state.
+- **From a claim:** when a builder claims an `ideator`-discipline task, `claim.js` reads `scripts/gds/discipline-modes.json` and prints a directive to invoke `/ideate`. Both paths run this same file — it is the single home of the experience. (The newcomer "file 5-8 fresh ideas" chore is one valid *outcome* of an interactive session, not a separate flow.)