@bongos/core 1.19.637 → 1.19.639

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/module_api.mjs

@@ -46,6 +46,7 @@ const PUBLISHED_SURFACE = [
   'contribute', 'contributions', 'collectContributions', 'listContributionPoints',
   'buildInfo', 'validateOrRespond', 'LIMITS', 'parseId', 'asyncHandler', 'corsPublicGet', // parseId added 1.8.0 (BV1.R78); asyncHandler + corsPublicGet added 1.12.0 (BV1.R86; lifecycle routes)
   'parsePagination', 'pageMeta', 'PAGINATION', // R14 (#2001, 1.17.0): shared pagination contract for module list routes (ADR 0119)
+  'responsibilityFor', 'ROLE_RESPONSIBILITIES', // added by task 1003732 (ADR 0275; criterion wa6-written-responsibilities): the ONE source for the sentence each craft is answerable for. It rides the doorway because two modules need the same text — grading judges role-shaped work against it, the hall shows it to the person being judged — and modules never import each other. Declared here deliberately: this list is what makes adding to the doorway a decision rather than a side effect
   'logger',
 ];
 

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/role_responsibilities.mjs

@@ -0,0 +1,187 @@
+// tests/role_responsibilities.mjs
+//
+// task 1003732 (goal 1000095, criterion wa6-written-responsibilities) — the three
+// written role responsibilities land as ONE source with three consumers.
+//
+// WHAT IS WORTH PINNING HERE. The criterion's whole content is "one source, shown
+// on the profile, injected into the pack, referenced by grading". So the failure to
+// guard against is not a typo — it is a SECOND COPY. If the packs, the hall and the
+// grader can each hold their own wording, the project can show a builder one
+// standard and judge them by another, which is the specific unfairness the single
+// source exists to prevent. Every test below is a leg of that.
+//
+// The text itself is the owner's, verbatim (fixed 2026-09-08). It is asserted here
+// character-for-character on purpose: a well-meaning tidy-up of someone else's
+// authored sentence is exactly the drift this task forbids, and a test is the only
+// thing that makes "do not paraphrase" survive contact with a future editor.
+//
+// Run:  node tests/role_responsibilities.mjs
+
+import { strict as assert } from 'node:assert';
+import { createRequire } from 'node:module';
+import fs from 'node:fs';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const require = createRequire(import.meta.url);
+const ROOT = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..');
+const src = require(path.join(ROOT, 'src', 'role-responsibilities.js'));
+const modules = require(path.join(ROOT, 'src', 'modules.js'));
+const api = require(path.join(ROOT, 'src', 'module-api.js'));
+const gen = require(path.join(ROOT, 'scripts', 'gds', 'gen-role-responsibilities.js'));
+
+let passed = 0;
+let failed = 0;
+function test(name, fn) {
+  try { fn(); passed++; console.log(`  ok  ${name}`); }
+  catch (err) { failed++; console.error(`  FAIL ${name}\n    ${err.message}`); }
+}
+
+// --- the source ---------------------------------------------------------
+
+// The owner's sentences, verbatim from criterion wa6-written-responsibilities.
+// Duplicated here deliberately — a test that read the value it is checking would
+// assert nothing. This copy is the fixture; the source file is the subject.
+const OWNER_TEXT = {
+  engineer: 'Running and optimizing the running of Claude nonstop, and ensuring Ideators and Artists can continue to interface with that system effectively.',
+  artist: 'No slop in the appearance and text of the project; the story, emotion and ideology of the project are communicated effectively; project purpose and gravitas are upheld.',
+  ideator: 'Make good ideas; be a philosopher / thought leader for the project; enable Engineers to scope and Artists to create with maximum efficiency — a baseline for creating scopes of work.',
+};
+
+test('the three statements are the owner\'s text, character for character', () => {
+  assert.deepEqual({ ...src.ROLE_RESPONSIBILITIES }, OWNER_TEXT);
+});
+
+test('exactly the three CORE crafts carry a statement — no more, no fewer', () => {
+  assert.deepEqual(Object.keys(src.ROLE_RESPONSIBILITIES), ['engineer', 'artist', 'ideator']);
+  // Governor is deferred (ADR 0274) and `ui` is module-contributed (ADR 0272):
+  // inventing a sentence for either is the paraphrase this task forbids.
+  assert.equal(src.responsibilityFor('ui'), null);
+  assert.equal(src.responsibilityFor('governor'), null);
+});
+
+test('the map is frozen — a consumer cannot edit the standard at runtime', () => {
+  assert.ok(Object.isFrozen(src.ROLE_RESPONSIBILITIES));
+});
+
+test('responsibilityFor: case-insensitive, and absence is null not a placeholder', () => {
+  assert.equal(src.responsibilityFor('ENGINEER'), OWNER_TEXT.engineer);
+  for (const bad of [null, undefined, '', 'unclassified', 42, {}]) {
+    assert.equal(src.responsibilityFor(bad), null, `${JSON.stringify(bad)} must be null`);
+  }
+});
+
+test('responsibilitiesFor scopes to the disciplines an instance offers', () => {
+  assert.deepEqual(src.responsibilitiesFor(['artist', 'ui']), { artist: OWNER_TEXT.artist });
+  assert.deepEqual(src.responsibilitiesFor([]), {});
+  assert.deepEqual(src.responsibilitiesFor(null), {});
+});
+
+// --- consumer 1: the hall (via the injected client projection) ----------
+
+test('clientModules carries the statements for the offered crafts only', () => {
+  const c = modules.clientModules();
+  for (const d of Object.keys(c.responsibilities)) {
+    assert.ok(c.disciplines.includes(d), `${d} is offered a statement but is not an offered discipline`);
+    assert.equal(c.responsibilities[d], OWNER_TEXT[d], `${d}: the projection must not reword the source`);
+  }
+  // `ui` is offered by the ui-design module but has no statement — the projection
+  // must carry the craft without inventing a standard for it.
+  if (c.disciplines.includes('ui')) assert.equal(c.responsibilities.ui, undefined);
+});
+
+// --- consumer 2: the grader (via the module doorway) --------------------
+
+test('the doorway exposes it, so a module never deep-requires the source', () => {
+  assert.equal(api.responsibilityFor('artist'), OWNER_TEXT.artist);
+  assert.deepEqual({ ...api.ROLE_RESPONSIBILITIES }, OWNER_TEXT);
+});
+
+test('the grader prompt states the standard for a craft, and stays silent without one', () => {
+  const { buildPrompt } = require(path.join(ROOT, 'modules', 'grading', 'grader-prompt.js'));
+  const build = (discipline) => buildPrompt({
+    task: { id: 1, title: 't', kind: 'feature', discipline },
+    valueSummary: 'v', changedFiles: ['a.js'], diff: 'x',
+  });
+  assert.ok(build('artist').includes(OWNER_TEXT.artist), 'the artist statement must reach the prompt verbatim');
+  // A craft with no written standard must not get an invented one — a grader told
+  // "this role has no standard" would supply its own.
+  for (const d of ['ui', 'unclassified', undefined]) {
+    assert.ok(!build(d).includes('What this craft is answerable for'), `${d} must add no responsibility line`);
+  }
+});
+
+// --- consumer 3: the packs (generated, so they cannot drift) ------------
+
+test('every pack the registry names carries the block, matching the source', () => {
+  const { writes, warnings } = gen.plan();
+  assert.deepEqual(writes.map((w) => w.rel), [], `a pack block is stale: ${writes.map((w) => w.rel).join(', ')}`);
+  assert.deepEqual(warnings, [], `every registered pack must carry the marker pair: ${warnings.join(' | ')}`);
+});
+
+test('the block carries the statement verbatim and says it is generated', () => {
+  for (const t of gen.packTargets()) {
+    const text = fs.readFileSync(t.abs, 'utf8');
+    const expected = OWNER_TEXT[t.discipline];
+    if (!expected) continue;
+    assert.ok(text.includes(expected), `${t.rel} must quote the ${t.discipline} statement verbatim`);
+    assert.ok(text.includes(gen.BEGIN) && text.includes(gen.END), `${t.rel} must keep the marker pair`);
+    assert.ok(/do not hand-edit/i.test(text), `${t.rel} must warn that the block is generated`);
+  }
+});
+
+test('the generator is idempotent and preserves a CRLF pack\'s line endings', () => {
+  // The packs are .md: CRLF on a Windows checkout, LF in CI. A generator that
+  // always wrote '\n' would make the committed bytes platform-dependent, so the
+  // freshness gate would be red on one checkout and green on the other.
+  const block = gen.blockFor('artist');
+  const crlf = `head\r\n${gen.BEGIN}\r\nstale\r\n${gen.END}\r\ntail\r\n`;
+  const out = gen.inject(crlf, block);
+  assert.ok(!/[^\r]\n/.test(out), 'a CRLF file must stay pure CRLF');
+  assert.equal(gen.inject(out, block), out, 'a second pass must change nothing');
+
+  const lf = `head\n${gen.BEGIN}\nstale\n${gen.END}\ntail\n`;
+  const outLf = gen.inject(lf, block);
+  assert.ok(!outLf.includes('\r'), 'an LF file must stay pure LF');
+  assert.equal(gen.inject(outLf, block), outLf, 'a second pass must change nothing');
+});
+
+test('a pack with no markers is reported, never silently skipped', () => {
+  assert.equal(gen.inject('no markers here', gen.blockFor('artist')), null);
+});
+
+// --- the whole point: there is no second copy ---------------------------
+
+test('no consumer hardcodes a statement — the packs\' generated blocks are the only copies', () => {
+  // Anything that repeats a statement outside the source, its generated blocks, the
+  // criterion record, or this fixture is a second copy that can drift.
+  const ALLOWED = new Set([
+    'src/role-responsibilities.js',   // the source
+    'docs/packs/engineer.md',         // generated blocks
+    'docs/packs/artist.md',
+    'docs/packs/ideator.md',
+    'tests/role_responsibilities.mjs', // this fixture
+  ]);
+  const scan = ['src', 'scripts', 'modules', 'tests', 'docs/packs'];
+  const offenders = [];
+  const walk = (dir) => {
+    let entries = [];
+    try { entries = fs.readdirSync(path.join(ROOT, dir), { withFileTypes: true }); } catch { return; }
+    for (const e of entries) {
+      const rel = `${dir}/${e.name}`;
+      if (e.isDirectory()) { if (e.name !== 'node_modules') walk(rel); continue; }
+      if (!/\.(js|mjs|md|json|html)$/.test(e.name)) continue;
+      if (ALLOWED.has(rel)) continue;
+      let text;
+      try { text = fs.readFileSync(path.join(ROOT, rel), 'utf8'); } catch { continue; }
+      for (const [craft, sentence] of Object.entries(OWNER_TEXT)) {
+        if (text.includes(sentence)) offenders.push(`${rel} repeats the ${craft} statement`);
+      }
+    }
+  };
+  for (const d of scan) walk(d);
+  assert.deepEqual(offenders, [], `a second copy can drift from the source:\n  ${offenders.join('\n  ')}`);
+});
+
+console.log(`\nrole_responsibilities: ${passed} passed, ${failed} failed`);
+if (failed > 0) process.exit(1);

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.)