@bongos/core 1.21.107 → 1.21.109

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.21.107",
-  "core_contract": "1.21.107",
-  "source_commit": "66864d4729f78666ac0d3cc86772672dad49d007",
+  "core_version": "1.21.109",
+  "core_contract": "1.21.109",
+  "source_commit": "99f3c48f4295f02d3a12c5f222ca33ca04453406",
   "source_ref": "HEAD",
-  "built_at": "2026-10-09T16:17:03.848Z",
+  "built_at": "2026-10-09T16:52:03.016Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
     "docs_redacted": 592,
     "agent_docs_stubbed": 28,
-    "functional_verbatim": 3027,
+    "functional_verbatim": 3028,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 3648,
-  "tree_sha256": "7b88f76244577f7ff0ed046eef50822d8f34efad63453b8257040b942df1708a",
+  "file_count": 3649,
+  "tree_sha256": "92bfdb3234394f28d268e4115634d136414a6c4b45fab928376b1ee741b62fcc",
   "files": [
     {
       "path": ".claude/skills/ask-for-help/SKILL.md",
@@ -152,7 +152,7 @@
     {
       "path": ".claude/skills/goal-create/SKILL.md",
       "mode": "0000644",
-      "sha256": "db1878c912e45baea9bffef3e920ad95d7f9b4f0bc5d185805e9ab2d53a818e0"
+      "sha256": "11f9e820c5e37818de14b701945f8606562572c4381ba90ded31364005edf0fb"
     },
     {
       "path": ".claude/skills/goal-review/SKILL.md",
@@ -187,7 +187,7 @@
     {
       "path": ".claude/skills/idea-triage/SKILL.md",
       "mode": "0000644",
-      "sha256": "628a9880309ba370151becbebd7497972006716ec955d06bb51a79d335dbd54f"
+      "sha256": "c5698c6c3dbfed91186afde9297a165445269e9c9862f2b5c1908a0e2d6df5a1"
     },
     {
       "path": ".claude/skills/merge-mode/SKILL.md",
@@ -207,7 +207,7 @@
     {
       "path": ".claude/skills/planning-session/SKILL.md",
       "mode": "0000644",
-      "sha256": "0447f0526aaf9735f47cb52fe7423914f8aba4cfbeb0f9b56fa49e0d4e5073fd"
+      "sha256": "0d3ad6a9a7f3d0ee4bbdc0a8539705bdc5e9ab492151f3886120c15e102758a6"
     },
     {
       "path": ".claude/skills/priority-session/SKILL.md",
@@ -2357,12 +2357,12 @@
     {
       "path": "docs/copy-inventory.md",
       "mode": "0000644",
-      "sha256": "1c30d65d8133fa310b628a8749ee52746eefa37918c7ef6303202c9a67a8a941"
+      "sha256": "1d38789dcf8ea53dfc188e72896d346c1324494ab9f80aec4fc2aeef3907766e"
     },
     {
       "path": "docs/copy-registry.json",
       "mode": "0000644",
-      "sha256": "b39bb4b05ed4bb5b4bca66e0f558849dcc7b9bca4c47b758f9ad81d05f368349"
+      "sha256": "a93000df72e34c83bdf0ab43817a754f7db6f4d7dcdd6f436422426a2cc57a1f"
     },
     {
       "path": "docs/design/apex-pass-2-direction.md",
@@ -2872,7 +2872,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "e04eba1f8d62cb1ae1251c701aad1d4108cf1c48c2bd7a71eade2c29d419e80e"
+      "sha256": "a35307c4313c8d7e32ad065d3713213ecb0a99990d5996f1e1221a0ea05b24fa"
     },
     {
       "path": "docs/modules-contract.md",
@@ -2962,7 +2962,7 @@
     {
       "path": "docs/page-readings.json",
       "mode": "0000644",
-      "sha256": "88302070d897c9a1745a99fd0a99e30ec16cdceb08db33dd7340a4bb6a157a27"
+      "sha256": "b23bcbca4f4689129a3c589c867c7f9b6191ca855d9b458f34155f41531f47ce"
     },
     {
       "path": "docs/project-context.template.md",
@@ -4367,7 +4367,7 @@
     {
       "path": "modules/copy-desk/docx.js",
       "mode": "0000644",
-      "sha256": "9b65f9fb493e63d86010f4a955a14a0b86e11dbfdb152f744aba8dcc37f870bd"
+      "sha256": "06457c960bbb0e498990a6886a50c80df834c0829c2259023bdfa350e95ef18b"
     },
     {
       "path": "modules/copy-desk/flags.js",
@@ -4402,12 +4402,12 @@
     {
       "path": "modules/copy-desk/page-status.js",
       "mode": "0000644",
-      "sha256": "b31f8c94a4768bb690dd2e983b404c8bf022c33c343ee0d15747953359df9d36"
+      "sha256": "b963858bb03b92e283ecc3fe7eae02caafeeac873edc1ff464dbc886695712b5"
     },
     {
       "path": "modules/copy-desk/pages.js",
       "mode": "0000644",
-      "sha256": "8653c26ad951f831163cb2b8db4b424c76959cdfcd27ebda5af5d13193361ad0"
+      "sha256": "412dbbf26ccdaa3034f013ecace5e79fdb2adcdb2e0ab72148a2587329dc85b3"
     },
     {
       "path": "modules/copy-desk/proposals.js",
@@ -4427,7 +4427,7 @@
     {
       "path": "modules/copy-desk/routes/copy-desk.js",
       "mode": "0000644",
-      "sha256": "b54ec33524894db892f81aa57d6feec568af3feea2d06b6dd85df0a1894ae256"
+      "sha256": "ad80a629d5f65dd9d0f01d5bb144a7eac6cff907ee00906a79b9f364c014b51d"
     },
     {
       "path": "modules/copy-desk/skills/tweak/SKILL.md",
@@ -4437,7 +4437,7 @@
     {
       "path": "modules/copy-desk/tests/copy_docx.mjs",
       "mode": "0000644",
-      "sha256": "79b0ec372109f3f484f02b0bf3d6d9323eb06262c57c3270cd5396404ea1ee27"
+      "sha256": "8fbbf4fb118eb0d2422a3073cb7b5bffcfbf41e308ac293b0e8770cf349f2e50"
     },
     {
       "path": "modules/copy-desk/tests/copy_flags.mjs",
@@ -4452,7 +4452,7 @@
     {
       "path": "modules/copy-desk/tests/copy_page_draft.mjs",
       "mode": "0000644",
-      "sha256": "7bae773b6f8e3c4d5dced4d689237f59d421fc34f9d6c809d50e81f610e9eafb"
+      "sha256": "7dfd56688ebd3611b88dacd35da58bc34db9329670937a7da1d64b4e19a9d979"
     },
     {
       "path": "modules/copy-desk/tests/copy_page_next.mjs",
@@ -5977,7 +5977,7 @@
     {
       "path": "modules/hall-ui/public/paintbrush.js",
       "mode": "0000644",
-      "sha256": "da8f7ff290647b1b50ee6e7061c01fa03d3be2883f3054add6fb2aa9767179a7"
+      "sha256": "6b55647a30b321705a5ef932bdc68175262c0e891d9239615617aa8a9c3d5c99"
     },
     {
       "path": "modules/hall-ui/public/palette.js",
@@ -6342,7 +6342,7 @@
     {
       "path": "modules/hall-ui/public/studio.js",
       "mode": "0000644",
-      "sha256": "f3a9fa920f732bddf245148c4faff10a52e88724b33800ae440b37e9aa1cd1da"
+      "sha256": "3b3ce62f0d41d21be2cf073f03f8d3e860fb025d1b1a286589405df9b233106e"
     },
     {
       "path": "modules/hall-ui/public/studio.states.json",
@@ -6352,7 +6352,7 @@
     {
       "path": "modules/hall-ui/public/style.css",
       "mode": "0000644",
-      "sha256": "a06426f48327bfabe9222ed24fcd55eb0897473cb578c30e10cbd53a069f98c9"
+      "sha256": "ed3c2a242d279e61bfe11e8c4218f72fac2227ced9b5bdc1211b21e2720d860f"
     },
     {
       "path": "modules/hall-ui/public/task-detail.js",
@@ -6412,7 +6412,7 @@
     {
       "path": "modules/hall-ui/public/tweak-editor-lib.js",
       "mode": "0000644",
-      "sha256": "0cc42c06e988b9d54d4443023d92c56b2fef8779823560735265c1e0f1a45ab7"
+      "sha256": "2edf90d8c1664bdc774d2af9758d5e504621d244a35194e8b8d1a367bf85f244"
     },
     {
       "path": "modules/hall-ui/public/tweak-editor.css",
@@ -6512,7 +6512,7 @@
     {
       "path": "modules/hall-ui/records/craft-mode.md",
       "mode": "0000644",
-      "sha256": "e8a9cae9a79fd1ec44d0d66e4fe9f31dab25497acbfa863e68f1a6b52f68ba64"
+      "sha256": "1d4499e1dde2b7f4d88e621a47b164e913ab99878ccf73c7d3398f231cf70bfe"
     },
     {
       "path": "modules/hall-ui/records/filter-views.md",
@@ -6607,7 +6607,7 @@
     {
       "path": "modules/hall-ui/records/tweak-editor.md",
       "mode": "0000644",
-      "sha256": "6667b86da5c9e9259c047254866ee69f4b281ba3a941117eab7106a9f4aec513"
+      "sha256": "0f991a75a272d533911072acb4cc87d618c352eb39b4d14307257db041b66ec3"
     },
     {
       "path": "modules/ideas/CLAUDE.md",
@@ -10157,12 +10157,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "c16dedbb2b09e052499c6ab3e729d3b6398b070d283e5fcd459a722330a9bcd3"
+      "sha256": "b52f46812f60f0c96bead621c93cd5d916561ab4f37ea94ce28e7c46198ba985"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "e2deb79f00c230babbea2ba21005f4dcd2d6f2208638c44d2f6b38ba01416fcc"
+      "sha256": "9c36d2b1a974a7a7ef2af11f87f498e6fc26f4d6b40056952514db8252689769"
     },
     {
       "path": "public-docs/index.html",
@@ -10182,7 +10182,7 @@
     {
       "path": "release-notes.json",
       "mode": "0000644",
-      "sha256": "6182edd848be32362494da2bc94f8a4c33bca78bf2c6b9a253834d65531853b4"
+      "sha256": "3dbd02da56539f0d9fa96b2bc3ec5c586bde41a3242f2d1d86cc0fd644fb8592"
     },
     {
       "path": "scripts/cron/style_guide_audit.sh",
@@ -11532,7 +11532,7 @@
     {
       "path": "scripts/gds/seed-bv2-ideator-surface-tasks.js",
       "mode": "0000644",
-      "sha256": "1e74a2b1582922bbab8be30e62f8276f9d22e69d42210783940abcfcb618c603"
+      "sha256": "e85983f4c59b88674758ea6dc3b074ddbb900c86734038989dfea6b53b46a18d"
     },
     {
       "path": "scripts/gds/seed-bv2-tweak-mode-tasks.js",
@@ -11592,7 +11592,7 @@
     {
       "path": "scripts/gds/seed-verify-criteria.js",
       "mode": "0000644",
-      "sha256": "928c4c9b9c6e6925b9870baebc86328f9cb66d2cc3385b01bd46942b786ba0d8"
+      "sha256": "d6300f04b48fcb3abfe1c7b102a3f3180b0afd7eb0bac44b31d503514611542e"
     },
     {
       "path": "scripts/gds/sequence.js",
@@ -11982,7 +11982,7 @@
     {
       "path": "scripts/hall-preview/server.js",
       "mode": "0000644",
-      "sha256": "73f90a45a8dbe04de03bdca1ad42f61c6dfe6e75982c3df8f311c8f1fa9eeed9"
+      "sha256": "5819bcbb67a9940a05ee7d874d29edbad366d2bdae64f40d0f9d5a4ea8e32376"
     },
     {
       "path": "scripts/hall-preview/task-visual.js",
@@ -12457,7 +12457,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "468b26045e9d63b3a8f75572e5bccb37517ad08719c7828048c80e4ec40e15dc"
+      "sha256": "d741e7462f49f3e622275d1901613d0e716de10361aa9e8ee1bc0b195fe134df"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -13437,7 +13437,7 @@
     {
       "path": "tests/copy_desk_page_submit.mjs",
       "mode": "0000644",
-      "sha256": "c77d8c60449bad805d048ec78e43169b5ec87283a3f91e29edba9e88352f4c51"
+      "sha256": "5c1267b5426a49b453039cd4e02a9d5acda823dde58a4116398d44a644e69653"
     },
     {
       "path": "tests/copy_inventory.mjs",
@@ -14894,6 +14894,11 @@
       "mode": "0000644",
       "sha256": "14e0bfda70dac75dc29bd784739ade11fe2cb986214bd0a1e8859f398b52dafb"
     },
+    {
+      "path": "tests/hall_preview_encoded_paths.mjs",
+      "mode": "0000644",
+      "sha256": "a4a0141c0743557d2344e2fbb0c573112b6c787e41332fdd04d5b656b17b65ba"
+    },
     {
       "path": "tests/hall_preview_governor_fixtures.mjs",
       "mode": "0000644",
@@ -15007,7 +15012,7 @@
     {
       "path": "tests/hall_tweak_editor.mjs",
       "mode": "0000644",
-      "sha256": "32164a5039c5989e25ff1c6dac77a9cb2d55daa3879fb638aa9b991e9cce5a84"
+      "sha256": "98adbded73abf08ac1a0267f38e668c0bcccc55c35c90161f480754ed8d43a22"
     },
     {
       "path": "tests/handle_machinery.mjs",
@@ -16182,7 +16187,7 @@
     {
       "path": "tests/paintbrush.mjs",
       "mode": "0000644",
-      "sha256": "62e61d65d297b32168a3c7a11eff496c2c1ecab55ed29a7ae8b27f5cae53ccb8"
+      "sha256": "0d5f6cfcdd842e90a0b258e49b12d722ddf9df186d741846ac8d3c964bfd448a"
     },
     {
       "path": "tests/parallel-load.mjs",
@@ -16252,7 +16257,7 @@
     {
       "path": "tests/planning_session_skill.mjs",
       "mode": "0000644",
-      "sha256": "8116334efbc40954c00137f5945f0eab89178b24bd6bb8f49e88381223b9a17f"
+      "sha256": "5fa3820f0c2a9b718cc3bcb513264ffae24c25c91d1a7039f0459a2befb36a6b"
     },
     {
       "path": "tests/platform_boot.mjs",
@@ -17177,7 +17182,7 @@
     {
       "path": "tests/seed_verify_criteria.mjs",
       "mode": "0000644",
-      "sha256": "3e0cc665466d81bf51477b5461ea1e4b9f4d8d992fc36222fba76f4b96041ce8"
+      "sha256": "b23270ac3c7d530a781337e49c0871cbd4ba6fde584774ef65435527edca48de"
     },
     {
       "path": "tests/sequence.mjs",

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

@@ -12,7 +12,7 @@ cost: >-
 
 You are running the **goal-create** session for this Cloud Bongos instance. You produce **one goal**: a title, a scope wall, two to four done-when criteria, and a handful of seed tasks — written to Bongos in one sitting.
 
-> **Not `/planning-session`, not `/goal-review`.** `/planning-session` scopes a whole **version**: 5–9 criteria, a written spec under `docs/specs/`, a multi-round interview, a seed script, a migration. This skill produces **one goal**, with no spec file and no migration. `/goal-review` is the other end of the same lifecycle — it *confirms* criteria and auto-achieves goals. If the ask is "plan the next version", stop and run `/planning-session` instead.
+> **Not `/planning-session`, not `/goal-review`.** `/planning-session` scopes a whole **version**: 5–9 criteria, a written spec under `docs/specs/`, a multi-round interview, a seed script, a migration. This skill produces **one goal**, with no spec file and no migration. `/goal-review` is the other end of the same lifecycle — it *confirms* criteria and auto-achieves goals. If the ask is "plan the next version", stop and run `/planning-session` instead. **The same goes for a big design-driven ask** — the owner has a design in mind (a mockup, a named model, "it should feel like…") and it would take several tasks to build: route it to `/planning-session` before seeding anything, because only there is each criterion tied to the agreed design and each task told where that design lives (task 1004675). Seeding it here skips that binding, and the grader — which never reads the design — cannot notice the build drifting from it.
 
 ## Rank gate — Metic+ only
 
@@ -124,9 +124,14 @@ node scripts/gds/api.js POST /api/bongos/tasks --body-file <path-to-task.json>
 # 5d — dependency edges, only where a real gate exists.
 node scripts/gds/api.js POST /api/bongos/tasks/<id>/dependencies --body '{"depends_on_task_id":<id>}'  # ids only
 
-# 5e — promote the zero-dependency layer. Every new task lands status='backlog', and
-#      auto-promotion only fires when a DEPENDENCY ships — so a task with no deps would
-#      sit unclaimable forever. Leave spikes in backlog.
+# 5e — check, then promote only what is still waiting. POST /tasks answers 'backlog',
+#      but the reconciler's backlog sweep moves a task with no unshipped dependency to
+#      'ready' within about a minute (task 1003932), so most are already there. Re-read
+#      the statuses; promote only a non-spike still at 'backlog' (an already-ready one
+#      answers 409 cannot_promote). 'ready' is not 'claimable': the claim-time
+#      dependency gate refuses a task whose dependency is unshipped, whatever its status
+#      (task 1004668). Leave spikes in backlog.
+node scripts/gds/api.js GET "/api/bongos/tasks?goal_id=<gid>"
 node scripts/gds/api.js POST /api/bongos/tasks/<id>/promote
 
 # 6 — verify + report.

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

@@ -223,7 +223,7 @@ at the triage end, where the judgement is.)
 
 **Promote → pick the tier (BV1.R64 / ADR 0086).** An idea no longer only becomes a *task* — it can promote into any tier of the work hierarchy: a **goal** (a whole module-scoped workspace), a **criterion** (a new done-when test), or a **task** (a single unit of work). Choose by the idea's size: a broad objective → goal; a "we should also require X to be done" → criterion; a concrete piece of work → task. Frame the choice to the user in those terms, then create the right record and mark the idea promoted.
 
-- **Promote → task** (the common case). Ask for version, title, est_minutes, priority, credits_reward (`touches[]` optional — [ADR 0049](../../../docs/adr/0049-split-parallel-safety-contract.md)). `POST /api/bongos/tasks` lands the new task in `backlog`, **not** `active` — it still needs `POST /tasks/:id/promote` (Metic+) before it's claimable. **Pass `goal_id` on the create** so the task lands in a real goal rather than the version's `"<version> — general"` catch-all — `POST /tasks` has accepted it since task 1763, and the 201 now returns a `goal_advisory` when the task ends up with no proper home. If no existing goal fits, run [`/goal-create`](../goal-create/SKILL.md) instead of filing it loose.
+- **Promote → task** (the common case). Ask for version, title, est_minutes, priority, credits_reward (`touches[]` optional — [ADR 0049](../../../docs/adr/0049-split-parallel-safety-contract.md)). `POST /api/bongos/tasks` answers `backlog`, but a new task with no unshipped dependency and no open blocker is **auto-promoted to `ready` within about a minute** by the reconciler's backlog sweep (task 1003932) — so do not tell the owner it is waiting for their go. **Re-read its status after creating** (`GET /tasks/<id>`) and `POST /tasks/:id/promote` (Metic+) only the ones still at `backlog`; promoting one already at `ready` answers `409 cannot_promote` (task 1004668: all 15 tasks from one triage hit that). **Pass `goal_id` on the create** so the task lands in a real goal rather than the version's `"<version> — general"` catch-all — `POST /tasks` has accepted it since task 1763, and the 201 now returns a `goal_advisory` when the task ends up with no proper home. If no existing goal fits, run [`/goal-create`](../goal-create/SKILL.md) instead of filing it loose.
 
   ```
   # 1. Create the task (--body-file avoids shell-quoting the touches[]/description).

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

@@ -21,6 +21,7 @@ The first planning session — V3 Planning Session #1, 2026-05-12 — is the tem
 - The user says "let's plan V4" / "plan the next version" / "open a planning session"
 - A version is in `status='planning'` and needs scope locked before tasks start landing in earnest
 - A previous planning session left proposals in `idea_inbox` tagged `kind='criterion-proposal'` that need ratification
+- **A big design-driven ask arrives — route it here BEFORE any task is seeded (task 1004675).** The tell: the owner has a design in mind (a mockup, a named model, "it should feel like…"), and the work would span several tasks. Seeding those tasks straight from chat — through `/goal-create`, `/idea-triage`, or a hand-written `POST /tasks` — skips the spec, the interview and the design binding in Phase 2, which is exactly how a build drifts from what was agreed. A single small task, or a goal whose shape is already settled and has no design to honour, does not need this.
 
 **Run an ideation pass first when the goal's SHAPE is not yet settled.** An ideator session (the [Ideator pack](../../../docs/packs/ideator.md)) inverts this skill's stance: there the human drives and you are the sounding board, so *their* framing sets the shape of the thing. Carry its output into Phase 1 and the Phase-4 interview is left with genuine residue instead of first-pass design.
 
@@ -106,12 +107,14 @@ This is where the user sees what they're shaping. Do not skip this — criteria
 
    **A row WITHOUT the pointer still needs its description read**, because the marker only exists from the day someone used merge instead of abandon-with-a-note, and the older rows are exactly the ones a rescope trips over. **Verify against the repo, not the row.** On 2026-08-16 a session read task 1003005 ("Rename modules/governance to modules/government") as `abandoned` and nearly put a false edge in a new goal's graph — the folder move had shipped under task 1003004, and only the prose said so. One `git log` over the paths the task named would have settled it.
 
-### Phase 1.5 — Map the mechanism (process-change sessions only) — task 1003075
+### Phase 1.5 — Map the mechanism (the default whenever an existing surface is touched) — task 1003075, task 1004675
 
-**Run this phase when the session is scoped to CHANGING how an existing mechanism already works** (a redesign, not a net-new feature with nothing live to replace) — skip it for a purely additive version with no prior mechanism in play. The precedent is the 2026-08-17 idea-routing session (goal 1000071): a subagent mapping the LIVE capture→triage→promote path before Phase 2 turned "route bugs to goals" into the capture-time-promotion design and resolved the bugs-vs-features question almost by itself — the session's own retro named it the highest-value step, and until now the skill only implied it.
+**Run this phase by default for any session that touches an existing surface** — a process-change redesign, an extension of a live feature, a new view over data that already exists. **Skipping it is the thing that needs a stated reason**, written into the spec's *Design decisions*: e.g. "purely additive, no live mechanism in play — nothing to map". Do not skip it because the owner arrived with a confident model; that is exactly the case where an unmapped assumption costs the most.
+
+The precedent is the 2026-08-17 idea-routing session (goal 1000071): a subagent mapping the LIVE capture→triage→promote path before Phase 2 turned "route bugs to goals" into the capture-time-promotion design and resolved the bugs-vs-features question almost by itself — the session's own retro named it the highest-value step. The 2026-09-19 ideator-surface session (meta task 1004076) was the second in a row: mapping moved the scope three times before any criterion was written — the owner's "size = karma" was not computable (karma rows carry no task or idea key), task parentage could not carry a descent (one level, no cross-version parents), and nothing recorded that shipped work was later removed, so half the design rested on a signal that did not exist.
 
 1. **Input.** Name the subsystem(s) the version is about to change, and the entry points you already know (a route file, a CLI script, a module's public function) as the subagent's starting point.
-2. **Spawn a read-only mapping subagent** (`Explore` or `general-purpose`, `model: sonnet` or higher per CLAUDE.md's subagent routing — this feeds a design decision, not plumbing) with a prompt asking it to trace the CURRENT live mechanism end-to-end: every entry point that touches it, the chokepoint(s) data already funnels through, and any function/route already doing part of what the new design needs. Ask for file:line references, not prose summaries — the output has to be citable in the spec.
+2. **Spawn a read-only mapping subagent** (`Explore` or `general-purpose`, `model: sonnet` or higher per CLAUDE.md's subagent routing — this feeds a design decision, not plumbing) with a prompt asking it to trace the CURRENT live mechanism end-to-end: every entry point that touches it, the chokepoint(s) data already funnels through, and any function/route already doing part of what the new design needs. Ask for file:line references, not prose summaries — the output has to be citable in the spec. **Always ask it one standard question as well: "Name any quantity this design assumes is computable, and say whether it actually is — which table or column carries it, or why nothing does."**
 3. **Output artifact — the mechanics map.** A short structured list: each chokepoint or reusable function/route, with a file:line and a one-line note on what it does today. Write it down (in the session, or straight into the spec draft) rather than letting it live only in the subagent's reply.
 4. **Consumed by:**
    - **Phase 2 (Criteria)** — a chokepoint the map surfaces (e.g. "every capture vector funnels through one function") often turns directly into a criterion, or reframes one that would otherwise be written as a task list.
@@ -129,6 +132,12 @@ For each criterion:
 
 **Apply the strength test BEFORE presenting each criterion.** A criterion passes the test if it plausibly anchors at least 5 tasks across multiple `kind` values (feature + bug + infra, not just feature). If it only anchors 1-3 specific tasks, or reads like an implementation step, rewrite it as the resulting outcome before showing it to the user.
 
+**Tie every criterion to the agreed design — outcomes alone let the build stray (task 1004675).** An outcome criterion is right, but it is only half the job. The grader reads the **task description and the diff**; it does **not** read `docs/specs/`. So an outcome criterion ("a thought is never lost") plus a vague task ("make the outcome persist") can be satisfied by a build that has nothing to do with the design the owner agreed, and nothing in the pipeline objects — the spec is the design of record and sits outside the loop that judges the work. The owner caught this in the 2026-09-19 ideator-surface session: "none of this criteria is easily indicative of the initial scope and designs we made". Close the gap three ways:
+
+1. **Split the settled design into MODEL and RENDERING.** The model is the durable decision — the named states, the independent channels, the rules (that session: five named states, two independent channels, a decay rule). It goes **into the criterion text**. The rendering — how it is drawn (that session: as a sky) — stays in the spec, free to change. A criterion that names the rendering breaks the day the look changes; a criterion that omits the model lets any build pass.
+2. **Give each criterion a proof whose scenario a wrong build fails.** Not "the page renders" but "a thought that caused 180 credits of work, since removed, displays at full size and zero brightness". Write that scenario into the proof task's **description** (Phase 3), because the description is where the grader actually looks.
+3. **Cite the design of record in every task description, and make sure the builder can open it.** Name the spec path (`docs/specs/<ver>-<goal-slug>.md`, committed in Phase 5) and the section the task implements. A private artifact link or a chat-only mockup as the design of record is decorative — whoever builds cannot open it.
+
 **Number every criterion** (`1.`, `2.`, …) in the presented list. The user will reference them by number when editing — e.g. "edit 4, remove 5, add a new one about X" — so they don't have to copy/paste the criterion titles.
 
 **Ask "what's missing?" before finalizing.** Once you've presented N criteria and worked through edits, explicitly prompt: "What concerns you that I haven't named? What's missing from this list?"
@@ -179,9 +188,9 @@ Don't tunnel-vision. Surface lateral options the user might not have thought of:
 
 **Proactively propose needs-exploration tasks** for any criterion where the implementation path isn't clear. Don't wait for the user to flag it. Frame them as "this one needs an architecture pass first — output an ADR + sub-task list before we build."
 
-**For each criterion, explicitly propose a proof-task** — the single live demonstration that proves the criterion is met. Examples: "Builder #2 onboards in ≤2h" for an onboarding criterion, "five concurrent builders shipping without collisions on staging" for a parallel-safety criterion. Without a proof-task, the criterion may technically ship without anyone knowing it works.
+**For each criterion, explicitly propose a proof-task** — the single live demonstration that proves the criterion is met. Examples: "Builder #2 onboards in ≤2h" for an onboarding criterion, "five concurrent builders shipping without collisions on staging" for a parallel-safety criterion. Without a proof-task, the criterion may technically ship without anyone knowing it works. **The proof's scenario must be one a wrong build fails** — state the concrete input and the exact observable result the agreed MODEL implies (Phase 2), so a build that ignored the design cannot pass it.
 
-**Encourage short task descriptions with cross-refs.** Each task's description should focus on done-when + touches; reference dependency tasks by their R## rather than restating context. Long standalone descriptions are content-debt at scale (80 tasks × 200 words = a lot of redundant context).
+**Encourage short task descriptions with cross-refs.** Each task's description should focus on done-when + touches; reference dependency tasks by their R## rather than restating context. **But every description cites the design of record** — the spec path and section it implements (Phase 2, "Tie every criterion to the agreed design") — because the grader never opens the spec on its own. Long standalone descriptions are content-debt at scale (80 tasks × 200 words = a lot of redundant context).
 
 > **`touches[]` is an advisory hint, not a hard fence ([ADR 0049](../../../docs/adr/0049-split-parallel-safety-contract.md)).** Parallel-safety is a *split contract*: for interactive single-human work, `git merge` is the authoritative collision detector and the claim-time overlap signal only warns; only the autonomous `--parallel` runner treats footprint overlap as a hard gate. So don't agonize over predicting every file at planning time — a rough blast-radius is enough, and a wrong prediction is no longer ship-blocking. (Step 7/8 — task [#882](https://example.com/builders#/task/882) — makes the per-task `touches` field optional and backfills it from the committed diff at ship.)
 
@@ -213,6 +222,8 @@ Tell the user the spec is written and where, then move straight to the interview
 
 **Ask only NON-OBVIOUS questions.** A question earns its place only if: the spec is genuinely underspecified on it, reasonable experts would disagree, AND the answer changes what gets built or how it's broken into tasks. Span dimensions across rounds — **data model & schema, API surface & contracts, UI/UX & information architecture, permissions/authz, privacy/consent, performance & scale, failure modes & edge cases, migration/rollout/backfill, naming the user will see, and scope boundaries.**
 
+**Naming questions: show the options side by side before recommending one (task 1004675).** A name the user will see — a page, a state, a role, a button — is a question where a lone recommendation anchors the owner before they have compared anything. Lay out three or four candidates together, each with a one-line note on how it reads to the person who will see it, and only then say which you would pick and why. In an AskUserQuestion round, that means each candidate is its own option (use the option `preview` for the side-by-side), with your pick listed first and marked recommended — never one name with "or something else?".
+
 **Do NOT ask** anything answerable by reading the codebase, anything the criteria already settle, yes/no rubber-stamps, or "do you want it to be good?" filler. If you catch yourself about to ask something with one obvious answer, decide it yourself and record it in *Design decisions* instead.
 
 > **This interview is the deliberate exception to the usual "decide implementation details yourself" default (see Tone, and CLAUDE.md §2).** The owner has explicitly asked to be consulted in depth here — so probe technical implementation, UX, tradeoffs, and concerns, not just outcomes.
@@ -301,13 +312,15 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
 
 > **Seeding contract — validated on goal 1000045 (2026-07-16):** proof-tasks use `kind='verify'` (a deliverable that IS a verification; can't be prematurely confirmed), spikes `kind='spike'`; `POST /tasks` accepts `criterion_ids` + `goal_id` inline and disciplines include `ui`; there is **no `promoted_idea_id`** field on `POST /tasks` — mark a promoted idea via `PATCH /inbox/:id`; **descoping a criterion has no API** (done-when is create/satisfy/unsatisfy only) — remove the row via a direct DB delete (`ssh … "sudo -u postgres psql -d <db> -c \"DELETE FROM done_when_criteria WHERE id=…\""`) under the meta-task claim, capturing the SQL in its notes; and a seed script **must throttle + honor `429` `retry_after`** (per-IP rate limit) — add a base delay between calls and back off on 429, or a large seed dies halfway. A completed reference seed: `scripts/gds/<redacted>.js`.
 >
-> **Every seed script verifies its own criterion links — fail loudly on any mismatch, zero included (task 1003076, retro on goal 1000071).** The goal-1000071 seeder linked all 15 tasks to the WRONG criteria (a positional `"Cn"` token resolved against the whole VERSION's criterion order, not the goal's — learning 1000188) and still printed success; only a manual `GET /goals` rollup caught it, after the fact. Every seed script's `main()` must end by tallying the `criterion_ids` it actually POSTed per task, then calling `verifySeedCriteriaLinks` from [`scripts/gds/seed-verify-criteria.js`](../../../scripts/gds/seed-verify-criteria.js) — it fetches `GET /api/bongos/goals/<id>`, diffs the returned `criteria[].linked_tasks` against that plan, and `exit(1)`s with a loud per-criterion diff on any mismatch (see `expectedCriterionCounts` + `verifySeedCriteriaLinks`). Reference implementation: `scripts/gds/<redacted>.js`. This is a script-level check, independent of whatever caused the mislink — it catches the *symptom* (a criterion silently under- or over-linked) whichever bug produces it.
+> **Every seed script verifies its own criterion links — fail loudly on any mismatch, zero included (task 1003076, retro on goal 1000071).** The goal-1000071 seeder linked all 15 tasks to the WRONG criteria (a positional `"Cn"` token resolved against the whole VERSION's criterion order, not the goal's — learning 1000188) and still printed success; only a manual `GET /goals` rollup caught it, after the fact. Every seed script's `main()` must end by tallying the `criterion_ids` it actually POSTed per task, then calling `verifySeedCriteriaLinks` from [`scripts/gds/seed-verify-criteria.js`](../../../scripts/gds/seed-verify-criteria.js) — it fetches `GET /api/bongos/goals/<id>`, diffs the returned `criteria[].linked_tasks` against that plan, and `exit(1)`s with a loud per-criterion diff on any mismatch (see `expectedCriterionCounts` + `verifySeedCriteriaLinks`). Reference implementation: `scripts/gds/<redacted>.js`. **Seeding into a goal that already has linked tasks?** Call `baselineSeedCriteria` BEFORE the first write and pass its result as `baseline` to the verify (task 1004668; reference: `scripts/gds/<redacted>.js`) — the check then covers every criterion on the goal, pre-existing counts included, and still catches a stray link on one the seed never meant to touch. With a baseline, tally only the tasks this run CREATED — skip any create that answers `idempotent: true`, since a re-run's replayed task is already inside the baseline and counting it again expects its links twice. Without a baseline only the plan's own criteria are checked. This is a script-level check, independent of whatever caused the mislink — it catches the *symptom* (a criterion silently under- or over-linked) whichever bug produces it.
 
 4. **Apply the migration** (commit + push + deploy, or direct psql via SSH for hot-fix style).
 
 5. **Run the seed script.** Verify exit code 0 — the seed's own final step (the Seeding contract's `verifySeedCriteriaLinks` call, above) already fails loudly if any criterion's linked task count doesn't match the plan, so a 0 exit means the links landed correctly, not just that the POSTs didn't error. Also spot-check totals via `GET /api/bongos/public/progress` and `GET /api/bongos/versions/<ver>/done-when`.
 
-6. **Promote the zero-dep layer to `ready` — scoped to the tasks you just seeded.** Every newly-seeded task lands `status='backlog'`. The auto-promotion trigger only fires when a *dependency* ships — so a task with zero deps has nothing to wait for and would sit unclaimable forever.
+6. **Promote the zero-dep layer to `ready` — scoped to the tasks you just seeded, and only what is still at `backlog`.** Do **not** assume the seed landed at `backlog`: read the seeded rows' statuses and report them (task 1004668). `POST /tasks` answers `backlog`, but the reconciler's backlog sweep (`PROMOTABLE_BACKLOG_WHERE` in `modules/lifecycle/db-tasks.js`, task 1003932) promotes any task with no unmet dependency and no open blocker within about a minute — seeding 27 tasks into goal 1000095 found 24 already at `ready`, spikes included, and the promote below had almost nothing to do. A zero-dep task the sweep has not reached yet is the only thing this step is for.
+
+   **`ready` is not "claimable".** The sweep can reach a task before the seed wires its dependency edges (the seed creates every task first, then the edges), so a task that should wait can read `ready`. The **claim-time dependency gate** (`DEPS_NOT_SHIPPED`) is the enforcement, not the status — it refuses a claim while any dependency is unshipped, whatever the row says. Check the edges landed (`GET /api/bongos/goals/<id>` → `dependencies`), not the statuses.
 
    **Scope this to your own seed, and never to the whole version** (task 1001438). `version_id + status='backlog' + kind<>'spike' + no dep edge` also describes rows that are sitting at `backlog` **on purpose**, and promoting those is a silent, unlogged override of another subsystem's decision:
    - **cascade-filed tasks** — `cascade.js` files generated work at `backlog`, **never** `ready`, as one of its four pinned properties (`modules/lifecycle/CLAUDE.md`; task 1003549). A cascade task has no dependency edge, so an unscoped promote flips exactly the rows that guarantee says it never will.
@@ -328,7 +341,7 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
      AND id NOT IN (SELECT task_id FROM task_dependencies);
    ```
 
-   The count must match the zero-dep tasks your seed script just created. If it is larger, your `source_ref` prefix is catching an earlier seed — narrow it (or fall back to the explicit list, `AND id = ANY('{<seeded ids>}')`) before writing anything. Then re-run it as the UPDATE:
+   The count is the zero-dep tasks the sweep has not promoted yet — often zero, which is not an error. It can never exceed the zero-dep tasks your seed just created; if it does, your `source_ref` prefix is catching an earlier seed — narrow it (or fall back to the explicit list, `AND id = ANY('{<seeded ids>}')`) before writing anything. Then re-run it as the UPDATE:
 
    ```sql
    UPDATE tasks
@@ -342,7 +355,7 @@ Once the spec is finalized (Phase 4), **read `docs/specs/<ver>-<goal-slug>.md` a
    RETURNING id, title, priority, kind;
    ```
 
-   Capture the `RETURNING` rows — the max `priority` value is the input for step 7. Spikes are intentionally excluded; they never auto-promote (kind='spike' convention, [ADR 0015](../../../docs/adr/0015-task-dependencies-and-auto-promotion.md)).
+   Capture the `RETURNING` rows, plus the seeded rows the sweep had already promoted — the max `priority` across both is the input for step 7. Spikes are intentionally excluded; they never auto-promote (kind='spike' convention, [ADR 0015](../../../docs/adr/0015-task-dependencies-and-auto-promotion.md)).
 
 7. **Surface higher-priority spikes still in backlog.** Spikes don't auto-flow because their output reshapes downstream work — that's a feature, not a bug. But the planning session just decided the priority order, so a high-priority spike sitting unstarted while lower-priority non-spike work flows to `ready` is a coordination smell worth one explicit mention. Query: