@bongos/core 1.19.637 → 1.19.638

package/tests/fitness.mjs

@@ -57,6 +57,102 @@ test('CLAUDE.md char budget is ratcheted and ordered (target < ceiling, live fil
   assert.equal(r.hardFail, false, 'the live CLAUDE.md must be under the char ceiling (ratchet locked in)');
 });
 
+// --- the role packs (task 1002990 / ADR 0274) --------------------------------
+//
+// This guard is the ONLY place a broken pack path can surface: claim.js reads the
+// role registry fail-open so it can never break a granted claim, which means an
+// entry pointing at a missing file degrades to silence — the craft's label prints
+// and its playbook never loads. The ADR rests the whole hard-fail argument on that,
+// so an untested guard would undermine its own rationale. Hence both legs, the same
+// pair every sibling guard here carries: the live tree is clean, AND the check
+// actually catches the failure rather than being a no-op.
+const rolePacks = require(path.join(ROOT, 'scripts', 'gds', 'role-pack-guard.js'));
+
+test('role packs: the live registry resolves and every pack is under budget', () => {
+  const r = rolePacks.checkRolePacks();
+  assert.equal(r.hardFail, false, r.violations.join('\n'));
+});
+
+test('role pack budget is ratcheted and ordered (target < ceiling)', () => {
+  assert.ok(rolePacks.PACK_CHAR_TARGET < rolePacks.PACK_CHAR_HARD_MAX, 'target must sit below the hard ceiling');
+});
+
+test('role pack guard actually CATCHES a missing pack, a pointerless entry, and a short roster (not a no-op)', () => {
+  const real = fs;
+  const withRegistry = (modes) => ({
+    readFileSync: (p, e) => (String(p).includes('discipline-modes.json') ? JSON.stringify({ modes }) : real.readFileSync(p, e)),
+    existsSync: (p) => (String(p).includes('__gone__') ? false : real.existsSync(p)),
+  });
+
+  // (1) the silent runtime failure: a pack path that resolves to nothing.
+  const missing = rolePacks.checkRolePacks(withRegistry({
+    engineer: { pack: 'docs/packs/__gone__.md', directive: 'x' },
+    artist: { pack: 'docs/packs/artist.md', directive: 'x' },
+    ideator: { pack: 'docs/packs/ideator.md', directive: 'x' },
+  }));
+  assert.equal(missing.hardFail, true, 'a pack that is not in the tree must hard-fail');
+  assert.ok(missing.violations.some((v) => /__gone__/.test(v) && /not in the tree/.test(v)), 'the violation must name the unresolvable path');
+
+  // (2) an entry routing a claim to no playbook at all.
+  const pointerless = rolePacks.checkRolePacks(withRegistry({
+    engineer: { pack: 'docs/packs/engineer.md', directive: 'x' },
+    artist: { pack: 'docs/packs/artist.md', directive: 'x' },
+    ideator: { pack: 'docs/packs/ideator.md', directive: 'x' },
+    ui: { directive: 'x' },
+  }));
+  assert.equal(pointerless.hardFail, true, 'an entry with neither pack nor skill must hard-fail');
+  assert.ok(pointerless.violations.some((v) => /'ui'/.test(v) && /neither/.test(v)));
+
+  // (3) a craft quietly dropped back into the kernel — the split's own shape.
+  const short = rolePacks.checkRolePacks(withRegistry({
+    engineer: { pack: 'docs/packs/engineer.md', directive: 'x' },
+    artist: { pack: 'docs/packs/artist.md', directive: 'x' },
+    ideator: { skill: 'ideate', directive: 'x' },
+  }));
+  assert.equal(short.hardFail, true, 'fewer than three packs must hard-fail');
+  assert.ok(short.violations.some((v) => /only 2 craft/.test(v)));
+
+  // (4) an over-budget pack — the "CI budgets each pack" half of the criterion.
+  const fat = rolePacks.checkRolePacks({
+    readFileSync: (p, e) => {
+      if (String(p).includes('discipline-modes.json')) {
+        return JSON.stringify({ modes: {
+          engineer: { pack: 'docs/packs/engineer.md', directive: 'x' },
+          artist: { pack: 'docs/packs/artist.md', directive: 'x' },
+          ideator: { pack: 'docs/packs/ideator.md', directive: 'x' },
+        } });
+      }
+      return 'x'.repeat(rolePacks.PACK_CHAR_HARD_MAX + 1);
+    },
+    existsSync: () => true,
+  });
+  assert.equal(fat.hardFail, true, 'a pack over the char ceiling must hard-fail');
+  assert.ok(fat.violations.some((v) => /hard ceiling/.test(v)));
+
+  // …and the guard is not simply always-red: the real tree passes (leg 1 above),
+  // and an unreadable registry is itself the failure rather than a free pass.
+  const unreadable = rolePacks.checkRolePacks({
+    readFileSync: () => { throw new Error('boom'); },
+    existsSync: () => true,
+  });
+  assert.equal(unreadable.hardFail, true, 'an unreadable registry must fail, not fail open like claim.js');
+});
+
+// The ship card mirrors the registry by hand — it cannot require a core script
+// across the module boundary, which is why claim.js and ship-card.js have always
+// carried the map twice (task 1003487 was that duplication drifting). A test is the
+// shared source they cannot have: rename a pack and this fails instead of the hall
+// shipping a button that opens nothing.
+test('ship-card routing agrees with the role registry, entry for entry', () => {
+  const registry = JSON.parse(fs.readFileSync(path.join(ROOT, 'scripts', 'gds', 'discipline-modes.json'), 'utf8')).modes;
+  const card = require(path.join(ROOT, 'modules', 'lifecycle', 'ship-card.js'));
+  for (const [discipline, mode] of Object.entries(registry)) {
+    const cmd = card.buildCardModel({ stage: 'claimed', taskId: 1, discipline, brand: { currency: 'credits' } }).action.cmd;
+    if (mode.pack) assert.ok(cmd.includes(mode.pack), `${discipline}: card says "${cmd}" but the registry names ${mode.pack}`);
+    else if (mode.skill) assert.equal(cmd, `/${mode.skill}`, `${discipline}: card and registry disagree on the skill`);
+  }
+});
+
 test('nested CLAUDE.md present for every high-traffic dir', () => {
   const r = fitness.checkNestedDocsPresent();
   assert.equal(r.hardFail, false, r.violations.join('\n'));

package/tests/idea_ideate_full.mjs

@@ -1,9 +1,15 @@
 // tests/idea_ideate_full.mjs
 //
-// task 1002931 (BV1.R155, goal 1000062) — /ideate authors a Full Idea
-// conversationally.
+// task 1002931 (BV1.R155, goal 1000062) — the ideator's playbook authors a Full
+// Idea conversationally.
 //
-// A skill is a prompt, so the thing to pin is the PROMPT'S CONTRACT. Two
+// WHERE THAT PLAYBOOK LIVES (task 1002990). It used to be the /ideate skill. The
+// kernel/pack split moved it into the Ideator role pack and deleted the skill, so
+// this suite now reads docs/packs/ideator.md. Every contract below is unchanged —
+// the file moved, the promises did not — and pointing the suite at the new home is
+// what stops the split from silently dropping the guard with the skill.
+//
+// A pack is a prompt, so the thing to pin is the PROMPT'S CONTRACT. Two
 // done-when clauses, and both are checkable:
 //
 //   1. "indistinguishable in the database from one authored in the hall" — so the
@@ -30,7 +36,7 @@ import { fileURLToPath } from 'node:url';
 
 const require = createRequire(import.meta.url);
 const ROOT = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..');
-const SKILL = fs.readFileSync(path.join(ROOT, '.claude/skills/ideate/SKILL.md'), 'utf8');
+const SKILL = fs.readFileSync(path.join(ROOT, 'docs/packs/ideator.md'), 'utf8');
 // Prose assertions run against a WHITESPACE-NORMALISED copy. Markdown is hard-
 // wrapped, so any phrase long enough to be worth asserting will eventually
 // straddle a newline — and a regex that does not allow for that fails on a

package/tests/module-scope-map.mjs

@@ -231,9 +231,10 @@ test('methodology joined the roster (task 1002989) — the instruction surfaces
   const covers = (touch) => gsc.scopeSubset(['methodology'], [touch]).ok;
   for (const touch of [
     'CLAUDE.md',                              // the kernel half of the split (1002990)
-    '.claude/skills/dev/SKILL.md',            // one of the three discipline skills it deletes
-    '.claude/skills/ideate/SKILL.md',
-    '.claude/skills/paint/SKILL.md',
+    'docs/packs/engineer.md',                 // the three role packs the split authored (1002990)
+    'docs/packs/artist.md',
+    'docs/packs/ideator.md',
+    '.claude/skills/status/SKILL.md',         // the skills floor no module claims
     '.claude/rules/content-charter.md',       // pre-carved for task 1003687
     'docs/adr/0264-the-ten-working-areas.md', // the ADR library
     'docs/handoff-template.md',

package/tests/publish_manifest.mjs

@@ -77,7 +77,8 @@ const PUBLISH = [
   'docs/handoff-template.md',              // portable session-handoff format
   'docs/project-context.template.md',      // the neutral scaffold (NOT the OTB-filled one)
   'config/design-tokens.schema.json',      // generic contract schema
-  '.claude/skills/dev/SKILL.md',
+  '.claude/skills/status/SKILL.md',
+  'docs/packs/engineer.md',                // the role packs the kernel/pack split moved the methodology into (task 1002990)
   'package.json',
   'Dockerfile',
   '.env.local.example',

package/tests/ship_card.mjs

@@ -201,14 +201,28 @@ test('claimed: neutral tone, scope rows, discipline action, brief in dropdown',
   assert.equal(row(m, 'Estimate'), '~2h');
   assert.equal(row(m, 'Touches'), '4 files');
   assert.equal(row(m, 'Value'), undefined); // no value summary pre-work
-  assert.equal(m.action.cmd, '/dev');
+  assert.equal(m.action.cmd, 'Read docs/packs/engineer.md and start the work');
   const html = card.renderCardHtml(m);
   assert.match(html, /Extend the card to every stage\./); // brief in dropdown
 });
 
-test('claimed action routes by discipline', () => {
-  assert.equal(card.buildCardModel({ stage: 'claimed', taskId: 1, discipline: 'artist', brand: BRAND }).action.cmd, '/paint');
-  assert.equal(card.buildCardModel({ stage: 'claimed', taskId: 1, discipline: 'ideator', brand: BRAND }).action.cmd, '/ideate');
+// The card must open the SAME playbook the claim just named, or it reintroduces the
+// 1003487 divergence. Since task 1002990 the three core crafts have no slash command
+// left to open — /dev, /paint and /ideate were deleted with the kernel/pack split —
+// so the card points at the pack file; a module-contributed discipline still routes
+// to its skill. A '/' prefix on a core craft here means a dead command in the hall.
+test('claimed action routes by discipline — core crafts to their pack, modules to their skill', () => {
+  const cmdFor = (discipline) => card.buildCardModel({ stage: 'claimed', taskId: 1, discipline, brand: BRAND }).action.cmd;
+  assert.equal(cmdFor('artist'), 'Read docs/packs/artist.md and start the work');
+  assert.equal(cmdFor('ideator'), 'Read docs/packs/ideator.md and start the work');
+  assert.equal(cmdFor('ui'), '/design');
+  // An unknown or unset discipline falls back to the Engineer pack, exactly as it
+  // used to fall back to /dev — engineering is the project's default loop.
+  assert.equal(cmdFor('unclassified'), 'Read docs/packs/engineer.md and start the work');
+  assert.equal(cmdFor(undefined), 'Read docs/packs/engineer.md and start the work');
+  for (const d of ['engineer', 'artist', 'ideator']) {
+    assert.ok(!cmdFor(d).startsWith('/'), `${d} must not be routed to a slash command — /dev, /paint and /ideate no longer exist`);
+  }
 });
 
 // ---- review ----

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

@@ -1,49 +0,0 @@
----
-name: dev
-description: The engineering session — the operating playbook for engineer-discipline work (code, infra, Bongos 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 Example. 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 Bongos'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/ideate/SKILL.md

@@ -1,164 +0,0 @@
----
-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 Example. 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.
-
-## The second rule: be quiet about the machinery
-
-The *behavior* above inverts for this role — and so does the **surface**. An ideator came here to think about an idea, not to watch a build. So **report outcomes, not mechanism.**
-
-- **Don't narrate the plumbing.** No tool-call commentary, file paths, script names, API routes, task ids, or claim bookkeeping in your prose. You still *use* all of it — you just don't make the ideator read about it.
-- **Speak in the language of the idea.** "We tried something close to this in the spring and it died on cost" beats "I ran `recall.js` over the ADR corpus and got four hits."
-- **One line out, then the answer.** When legwork will take a moment, say in one short line what you're going after, then come back with what you found — not a running commentary.
-- **Quiet is never hiding.** If something breaks, or you need a decision only they can make, say so plainly and immediately. A quiet surface that swallows a problem is a broken surface.
-
-**What this rule can and cannot reach.** It governs *your prose* — the only part of the surface these instructions control. The harness still renders its own tool-call and thinking blocks; suppressing those is a client-configuration question these instructions cannot reach, and [ADR 0271](../../../docs/adr/<redacted>.md) §4 records the two candidate levers and defers the choice. Don't apologize for it and don't invent workarounds.
-
-## 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`.
-
-## Authoring a FULL IDEA in conversation (task 1002931 / BV1.R155)
-
-A **Full Idea** is the ideator craft's real output: five answered questions that
-are a baseline scope of work someone else can deliver against *without
-re-interviewing the person who had the thought*. Drawing those five answers out
-of a conversation is exactly this skill's dynamic — and it is the path for
-someone who thinks by talking rather than by filling in a form.
-
-**Get the questions from the template, never from memory.** They are declared
-once, as data, and a project can define its own:
-
-```
-node scripts/gds/spark.js --template
-```
-
-That prints each field, its label, and the substance floor the scorer expects.
-Ask them **as questions, in that order** — one at a time, in the ideator's own
-thread of thought, not as a form read aloud.
-
-### The rule that governs this whole section: you write down what they said
-
-You are already "the instrument, not the author". Here that stops being a stance
-and becomes a hard constraint, because **the completeness score is deterministic
-and it feeds credits** (R142 scores substance; ADR 0172 pays on it). If you
-ghost-write a field, the number is fraudulent and the builder is paid for your
-words. So:
-
-- **Never invent field content.** Not a sentence, not a clause.
-- **Never pad a thin answer** to clear the floor. A short answer scores short —
-  that is the scorer working, not a problem to fix.
-- **Never polish an answer into words they did not use.** Tightening *their*
-  phrasing when they ask is help; rewriting it is authorship.
-- **An unanswered question stays empty.** If they do not want to answer "why does
-  it matter", file it without that field and let the score say so. A Full Idea
-  with a gap is honest; a Full Idea you completed for them is not.
-- What you *should* do is what this skill is for: **press on a thin answer.**
-  "That is one line — what is behind it?" is the sounding board doing its job.
-  Their next sentence is theirs. Yours would not be.
-
-Read the answers back before filing and let them correct you. They bless it; you
-file it.
-
-### Filing it
-
-Write their answers to a JSON file keyed by the template's field keys, then:
-
-```
-node scripts/gds/capture.js "<their title>" --full --fields-file <path>
-```
-
-That is the **same route** the hall form uses (`POST /inbox` with `grade='full'`),
-so the record is identical — same validation against the R141 template, same R142
-score, same ideator-credit lane. There is deliberately no separate write path for
-conversational authoring: a second one would drift, and "indistinguishable in the
-database" is this task's done-when.
-
-The command reports what the server **stored**. If it says the idea landed as
-*quick*, say so plainly — capture is fail-open on grading, and telling someone
-they filed a Full Idea when they did not is the one outcome worse than the
-failure itself.
-
-### Developing someone else's spark
-
-The same conversation works on a **Big Idea Spark** — a quick idea whose author
-marked it as needing development. `node scripts/gds/spark.js --list` shows what is
-waiting; develop one with `spark.js --develop <id> --fields-file <path>`. The
-author keeps the credit for having had the thought and the payout splits with
-them (ADR 0185), so the never-invent rule applies with more force, not less:
-those five answers are now going out under two people's names.
-
-## 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.)

package/.claude/skills/paint/SKILL.md

@@ -1,71 +0,0 @@
----
-name: paint
-description: >-
-  The art session — the operating playbook for artist-discipline work. Triggers when the user says "/paint", "let's make art", "I want to work on a tile/sprite", "start an art session", or when a claimed task's discipline routes here (claim.js prints a directive to invoke /paint for artist tasks). Show-first, low-text: Claude communicates in pictures, not prose, and drives the existing pixel-art pipeline underneath.
----
-
-You are running an **art session** for Example. This is not the engineer's text-heavy build loop. Read this whole file before acting — it changes how you *communicate* for the rest of the session.
-
-## The one rule that makes this different: communicate in pictures, not prose
-
-In every other discipline, Claude narrates — diffs, logs, paragraphs of what it's doing. **Here that is the failure mode.** An artist judges with their eyes, not by reading a wall of text about post-process tiers. So:
-
-> **Show, then briefly caption. Never narrate the pipeline at length.** Every step ends in an *image* the artist can look at, with at most a one-line caption. The text-heavy plumbing still runs — it just runs quietly.
-
-Concretely:
-
-- **End every step with something visual.** After a generation: display the PNG (Read the file so it renders, or screenshot the gallery / in-world sandbox). After a rubric check: show the scorecard, not a prose summary. The artist should *see* the result before they read a single word.
-- **Collapse the plumbing to one-liners.** Budget checks, `vocabulary.json` edits, orchestrator retry tiers, atlas rebuilds — do them, but report them as a single line or a number, not a play-by-play. "Generated, rubric 0.91, on-palette, staged ✓" beats three paragraphs.
-- **Verification = look, not read.** Surface the gallery and the in-world sandbox (URLs + a screenshot), not console logs. Logs are for when something *breaks*, not for routine success.
-- **The artist owns the look; you own the rendering.** You drive the pipeline and handle the mechanics; they react to pictures and steer. You are their hands, not their art director.
-
-## Step 0 — detect the mode
-
-**Is an artist present in this session?**
-
-- Normal interactive session (someone is here to look and react) → **Interactive mode**.
-- Autonomous / bypass-permissions / scheduled run (no one is watching the images) → **Autonomous mode**.
-
-If unsure, ask once; if no answer, treat it as autonomous.
-
-## Step 1 (both modes) — load the look before you make anything
-
-Ground every asset in the locked theme so nothing drifts:
-
-- `modules/art-pipeline/template/style_guide.md`, `modules/art-pipeline/template/rubric.json`, `modules/art-pipeline/template/palette.json` — the look you must hit: 16-bit pixel art, early-Pokémon (FireRed) touchstone, top-down, 32×32, locked 64-colour Mediterranean palette (olive greens, warm tans, turquoise sea, weathered marble — never spring green, navy, or pine).
-- `modules/art-pipeline/template/vocabulary.json` + `modules/art-pipeline/template/cluster_overview.png` — what exists and the reference clusters.
-- **The palette and rubric are non-negotiable.** Never edit `palette.json` or `rubric.json` without an ADR — palette drift is whole-world drift.
-
-## Interactive mode — show, react, iterate
-
-1. **Establish the visual target first, not in prose.** Confirm the subject (an existing vocab id, or a new in-world prop/plant/animal/accessory) and, if helpful, show the reference cluster it should sit beside. One or two lines, then move to making.
-2. **Generate via the pipeline — never freelance.** Drive `/otb-tile-generate` (which runs `modules/art-pipeline/pipeline/orchestrator.py`: generate → post-process to 32×32 → score against rubric → retry up to 5 tiers → save to `modules/art-pipeline/generated/tiles/<id>.png`, logging cost). Check the budget first (`python3 modules/art-pipeline/pipeline/cost_ledger.py status`; hard stop at $80) — but report it as one line.
-3. **SHOW the result.** Display the final accepted PNG and its rubric score. The gallery serves every tile (native + zoomed, with score + critique) at `sandbox-<login>.example.com/art` — point them there and/or render the image inline. **Default visibility: show the final accepted asset and any failures. Show the intermediate retry attempts only if the artist asks ("show me the attempts").**
-4. **See it in the world.** When they want it placed, run `node scripts/gds/art-stage.js` (**ships with the `art-pipeline` host module, not the portable core** — on a core-only checkout the file is absent and this step doesn't apply) — it rebuilds the atlas and surfaces the asset live in the game on their sandbox (auto-reloads an open tab). Screenshot/point at the in-world view. (A genuinely new base-tile *type* also needs a `public/game/world/tilePalette.js` mapping edit; an updated existing tile just needs the rebuild.)
-5. **Feedback is visual → a durable rule.** When the artist reacts ("too saturated", "trees too modern", "weather the marble"), don't just tweak once — run `/otb-feedback-capture` to write the note into `modules/art-pipeline/template/style_guide.md` as a dated rule, then regenerate and **show the new result**. The loop is see → react → see again, and the style guide gets smarter each pass.
-6. **Use `/otb-design-review`** when you want a rubric-grounded second opinion on whether an asset truly hits the bar — surface its numbers, not a paragraph.
-
-## Autonomous mode — make it, gate it, park the pictures
-
-No one is watching the images, so do not narrate into the void and do not lower the bar.
-
-1. **Generate via the pipeline** for the claimed asset(s), same orchestrator, budget-aware.
-2. **Rubric-gate hard.** Ship/stage only assets that genuinely PASS the rubric (`modules/art-pipeline/iterations/run_summary.json` status `pass`). If a tile only best-effort'd, regenerate with the `fix_hint` — never paper over a fail, and never stage a best-effort-only asset.
-3. **Stage to the gallery and PARK for human review.** Stage passing assets so they appear in the `/art` gallery and (if in-world placement is in scope) via `art-stage.js`, then leave them for a human to eyeball. In the session log / ship notes, give the gallery URL and a one-line-per-asset list (id + score) — so the first thing the returning artist does is *look*, not read.
-
-## How art TASKS should be framed (target-and-rubric, not prose-and-procedure)
-
-When you scope or present an art task, factor in the visual background:
-
-- **Lead with the visual target**, not paragraphs — the subject, the reference cluster it belongs beside, an example image if one exists. "Make this," shown.
-- **Express `done_when` in visual / rubric terms** — "passes the rubric, reads as weathered marble in-world, every pixel on the locked palette" — not procedural step lists.
-- **Keep procedure out of the task; the skill carries the how.** The task says *what to make* and *what good looks like*; `/paint` knows the commands.
-
-## How sessions reach this skill
-
-- **Standalone:** the user invokes `/paint` directly (e.g. "let's make a tile") — no claimed task required to explore.
-- **From a claim:** when a builder claims an `artist`-discipline task, `claim.js` reads `scripts/gds/discipline-modes.json` and prints a directive to invoke `/paint`. Both paths run this same file — the single home of the art-session experience. (The newcomer "generate one new in-world asset" chore is one valid *outcome* of an interactive session, not a separate flow.)
-
-## Stay clear of (READ-ONLY)
-
-Never modify the locked palette (`modules/art-pipeline/template/palette.json`) or rubric (`modules/art-pipeline/template/rubric.json`) without an ADR. Touch only art assets / `vocabulary.json` under `art/` (and, at most, the `public/game/world/tilePalette.js` wiring for a genuinely new base-tile type). Do not touch permission, pipeline-core, migration, or infra files.