@bongos/core 1.19.468 → 1.19.470

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.468",
-  "core_contract": "1.19.468",
-  "source_commit": "46a154331618a8c57ed0d178e7bfe13e180b7559",
+  "core_version": "1.19.470",
+  "core_contract": "1.19.470",
+  "source_commit": "dd9b08fd3b05ca54600d1cd9beaa771be0d8568d",
   "source_ref": "HEAD",
-  "built_at": "2026-09-02T14:11:23.358Z",
+  "built_at": "2026-09-02T14:48:18.482Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 408,
+    "docs_redacted": 410,
     "agent_docs_stubbed": 24,
-    "functional_verbatim": 1823,
+    "functional_verbatim": 1831,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2255,
-  "tree_sha256": "96abcd9bb3bfd8f8bfc4930c27fe91aa04b9f59717743a5b059f768854c865c3",
+  "file_count": 2265,
+  "tree_sha256": "669cadea9cb3ee85a8d995e4fd24179814f5b8475b753e228d71446493c85800",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -1634,10 +1634,15 @@
       "mode": "0000644",
       "sha256": "f9f3a0b8ebe2d161e17e1c632bbbda71842c9476958294330420f28c6301f7db"
     },
+    {
+      "path": "docs/adr/0227-a-task-network-map-is-refused-the-goal-graph-is-the-map.md",
+      "mode": "0000644",
+      "sha256": "19a6e49700fa63ef781c3fa9b96d868785995c4037b078543b354e45c6db823f"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "7b353237a164c704ac247646b93c419b26cc5fd8e53ac81e63b553146df76c85"
+      "sha256": "4c6f66d10d34f4c1c1e0ab6376868281b87e28a9f3b16ccfb75fafc004dcf8e2"
     },
     {
       "path": "docs/api-reference.md",
@@ -1672,12 +1677,12 @@
     {
       "path": "docs/copy-inventory.md",
       "mode": "0000644",
-      "sha256": "c90d1a197950bc627f1a44ae32a476703029be688997aa7ad5e00ba4e4f8a692"
+      "sha256": "7726b8ee862ebd75d1a95fafa9a5fb13993b4ad79bacba17f6e401e950082be4"
     },
     {
       "path": "docs/copy-registry.json",
       "mode": "0000644",
-      "sha256": "5a86bf71ba2d6f83943464ee676241bec655892c52c4d5742cb259971a66a591"
+      "sha256": "34b21e7e0c7135f4a20cc821174fc2e05ccfee4aa3691855197aa3356356e308"
     },
     {
       "path": "docs/design/apex-pass-2-direction.md",
@@ -2117,7 +2122,7 @@
     {
       "path": "docs/file-map.md",
       "mode": "0000644",
-      "sha256": "6aa7d3d13404a55afe9ab461eb404d86a4072b70e1565dd89e9d71b5e636364f"
+      "sha256": "ad3830c5ce7650d78c18dbd03c03c0544cbdc9f0dc018c4e09da1cf5bdf67d21"
     },
     {
       "path": "docs/handoff-template.md",
@@ -2127,7 +2132,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "b0ee40d833a5f28cba9450cc355d4b2b922def1e95fed5725ebee8796f2918a6"
+      "sha256": "8149596860cbbf60448d12ec3c229ee62cd7eb63524235a3464f68cb260b3c15"
     },
     {
       "path": "docs/modules-contract.md",
@@ -2384,6 +2389,46 @@
       "mode": "0000644",
       "sha256": "b8eb5d248cf36a95c5d72a683d056cea80ded13a9fc79504e4865da91cc01a1a"
     },
+    {
+      "path": "docs/research/task-network-map-readability.md",
+      "mode": "0000644",
+      "sha256": "335d8013fce50dd8e6905fffa02017714442bb19ce8a95e00706a4d99c4243b9"
+    },
+    {
+      "path": "docs/research/task-network-map/a-every-task-p2.png",
+      "mode": "0000644",
+      "sha256": "a8244dc72e654510116b6862a9d45df4236f98d22122cf7f7cb10ad556ee205d"
+    },
+    {
+      "path": "docs/research/task-network-map/a-every-task-p40.png",
+      "mode": "0000644",
+      "sha256": "a6a3e4bde72c2786318dc40d1dc2ebe211931d6270eed9d805ad501cafb2cefc"
+    },
+    {
+      "path": "docs/research/task-network-map/b-dependency-forest-p2.png",
+      "mode": "0000644",
+      "sha256": "ba46c265ce9d63dd861f51e5abccf908fbfccc85da5e54a0c0bcefa233b71099"
+    },
+    {
+      "path": "docs/research/task-network-map/b-dependency-forest-p40.png",
+      "mode": "0000644",
+      "sha256": "9e80f7462576cf5d6e7e5b8cca4d119c014bb3a1b7424f046077e7ef5bb4473c"
+    },
+    {
+      "path": "docs/research/task-network-map/c-goals-p2.png",
+      "mode": "0000644",
+      "sha256": "86d66eaf7c215548f8372e264b031519e72b3492992c0daefd7fd38f409b759e"
+    },
+    {
+      "path": "docs/research/task-network-map/c-goals-p40.png",
+      "mode": "0000644",
+      "sha256": "daa6b17253f3c55e5ca40536aa2b26730b935d50b502b2589478755da56fd5f2"
+    },
+    {
+      "path": "docs/research/task-network-map/d-joined-by-goal.png",
+      "mode": "0000644",
+      "sha256": "df987e84d3a031c680d8248fcc2be649277c475a8e315a4df04f46b7709d8dd6"
+    },
     {
       "path": "migrations/003_pms.sql",
       "mode": "0000644",
@@ -3947,22 +3992,22 @@
     {
       "path": "modules/hall-ui/public/atlas.css",
       "mode": "0000644",
-      "sha256": "bb259840c49ce76946cf5a3ff3cec5377a2adeb5f6524315f5073ce16fb32a03"
+      "sha256": "135d4554ff853a52ce5536fe8e3a39864055301457afd3d30eb726686df7795a"
     },
     {
       "path": "modules/hall-ui/public/atlas.html",
       "mode": "0000644",
-      "sha256": "2491b68f866cb45256bdeedba2e1fecd8644b06c4258ea6c3008b9ca3e5b20cc"
+      "sha256": "5be54f6e574fd171cfccad405e006873ff110206777c95bd6f482befe0e9c600"
     },
     {
       "path": "modules/hall-ui/public/atlas.js",
       "mode": "0000644",
-      "sha256": "d367353d85dc31861e348bb7864be2cb44872e5142d5293e06c62ecc4c16443b"
+      "sha256": "c94e2c4f04cdaaff36185f5e6b572c0716185cc615c03ccd4dbef63ca9f14577"
     },
     {
       "path": "modules/hall-ui/public/atlas.states.json",
       "mode": "0000644",
-      "sha256": "cdf792b51a0df53944e6ce48318403114ae54b6ca6ec8839113fd73e47bf5bb8"
+      "sha256": "cad620c960fb6bb8533d40a1e1e9b841b998b30ff073dabaca8623ee183d142c"
     },
     {
       "path": "modules/hall-ui/public/box-panel.js",
@@ -4277,22 +4322,22 @@
     {
       "path": "modules/hall-ui/public/modules.css",
       "mode": "0000644",
-      "sha256": "c7bab8979f1634b00a0e3720388409d034b5cd4b32c75f493e2f5cc5e7d1491d"
+      "sha256": "9a00c3965acc3defb8d711950ee9a15e941bbd9cc005a48babfa9b0f31a5068d"
     },
     {
       "path": "modules/hall-ui/public/modules.html",
       "mode": "0000644",
-      "sha256": "d05bde169e93fb5f86f536372c91eee2fe8c89a8e1efafd0fdb83352079a871e"
+      "sha256": "493de4531267d2b0b0ce268cc5998e33d54481442af619771f05dc27182e6f18"
     },
     {
       "path": "modules/hall-ui/public/modules.js",
       "mode": "0000644",
-      "sha256": "9df48fd541deabb6765cb622fc00f829edc4d6605c746f28a6d76cbfc07e22ad"
+      "sha256": "b2f8498403c739fb39e2391da13e3df3fdcbc52b4365f1c1faf7cfd83e602ff5"
     },
     {
       "path": "modules/hall-ui/public/modules.states.json",
       "mode": "0000644",
-      "sha256": "ba6cf9fd3e6adb5ec335610b0f53e6c2534da6d2054bc2d61460c4daefca2834"
+      "sha256": "80931a71335a98bdc435d37a2feaeae039e933db69d50d37307e66a252d5d285"
     },
     {
       "path": "modules/hall-ui/public/my-projects.css",
@@ -4342,22 +4387,22 @@
     {
       "path": "modules/hall-ui/public/people.css",
       "mode": "0000644",
-      "sha256": "b3462a0363dec36994e3760f3382cbd810c9ca3b6dc0bc8ae4ba29131ce4adf8"
+      "sha256": "2965667df5cf982295fcf2b58135aa84452b9d45c5f082c73bf26ede17736091"
     },
     {
       "path": "modules/hall-ui/public/people.html",
       "mode": "0000644",
-      "sha256": "8990aff8d4ffbad5fc81dc747aa3cda14c61aba24db52ad97cf025c0e87c1709"
+      "sha256": "5e5c99eab08f89feb05ab4db5015d6db3a78324777ffad245aa03c91a633032e"
     },
     {
       "path": "modules/hall-ui/public/people.js",
       "mode": "0000644",
-      "sha256": "3945369a9afe93b377ec5297f5bbd3b67cb3a702efa60e388c2a9e81b502cd3c"
+      "sha256": "145f767f473b11c222bde97e5de519c9eb0a9be0ddb2f75969d35dff086b3e01"
     },
     {
       "path": "modules/hall-ui/public/people.states.json",
       "mode": "0000644",
-      "sha256": "9c38735e4f4489d7de5bf15e175b2d39f936e7a0788ab169d343b0e83c038b3b"
+      "sha256": "6f7612bf9ef7da53e2f66337921ee30a13f8a28bde61044f9263bc45a8074edc"
     },
     {
       "path": "modules/hall-ui/public/primer.css",
@@ -4449,16 +4494,6 @@
       "mode": "0000644",
       "sha256": "ae7f02a8145e6e6f98f5428dcb48a1a82caec227af95a8c3a0c32e662af8167b"
     },
-    {
-      "path": "modules/hall-ui/public/scouting.html",
-      "mode": "0000644",
-      "sha256": "3eb3f73fe668fdd99031f71e2a761b3d3584873728960f116e45845ad5d12d76"
-    },
-    {
-      "path": "modules/hall-ui/public/scouting.states.json",
-      "mode": "0000644",
-      "sha256": "80efccfcf2963bc360853ded4618f59ca50ee055249e37891310c11dea1c55cf"
-    },
     {
       "path": "modules/hall-ui/public/sessions.css",
       "mode": "0000644",
@@ -4497,7 +4532,7 @@
     {
       "path": "modules/hall-ui/public/settings.js",
       "mode": "0000644",
-      "sha256": "3d5881896057de05daba30382b7ebf5aeb9f61cba55aae75916594ed3dc1a80f"
+      "sha256": "d8dd818d13e8efe11aa6b92870c44499d8510f22df1a3af5fad48d5f9a5c7b9d"
     },
     {
       "path": "modules/hall-ui/public/shell.js",
@@ -4512,7 +4547,7 @@
     {
       "path": "modules/hall-ui/public/style.css",
       "mode": "0000644",
-      "sha256": "07dbe7bdedfa0c3264682a1d51180a5da475c9328418a46378d459e66d982560"
+      "sha256": "9bb44b2d5ad45342ebee328430c793d0e48ce921362e87501002a5c73fbe71c9"
     },
     {
       "path": "modules/hall-ui/public/task-detail.js",
@@ -6627,12 +6662,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "775fa829d773f6c39be8c93c544e77c005304ff78a3c879778292fd5dc806ee8"
+      "sha256": "d31730b3e97acb3c865e52501b03d403acfb927f3107e3f605323e17945e0bf0"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "0d5b71ad68cce7afe9f0d4b35f8f4105fad5f00f46e91f60659ebf064f288f62"
+      "sha256": "533ce05335a427241e42414979e9c01c7c7df1f446959ffe2a70beae4f8089a7"
     },
     {
       "path": "public-docs/index.html",
@@ -7814,6 +7849,11 @@
       "mode": "0000755",
       "sha256": "dfd5aa72caa26eb2c8cf3063e1b4f51e1f4bcd7fddcdd93d243279c130850628"
     },
+    {
+      "path": "scripts/gds/spike-task-map.js",
+      "mode": "0000644",
+      "sha256": "cd09675638143232121d028f2ba55dcdde47c9d8d5d2466f52d09bc2cb650cc9"
+    },
     {
       "path": "scripts/gds/stale-worktrees.js",
       "mode": "0000644",
@@ -8247,7 +8287,7 @@
     {
       "path": "src/bongos/serve-internal.js",
       "mode": "0000644",
-      "sha256": "4a047000f4de21a464fe590c85f9e0ab1d7f653392a0eae4f59c11e94b4bc5ad"
+      "sha256": "d914b8304d5de3b325ef5996d30ca47c8ae91db26f561646271f11f77c3c37f0"
     },
     {
       "path": "src/bongos/stealth-gate.js",
@@ -8282,7 +8322,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "97199ab275115c07426ca83be7b0c618b3aebdb4b1e9349ab90ea989f8d625b4"
+      "sha256": "a5108ff620f06bbc05b7db97722319170c3fe6d5ce379524fe53b03ad0a137fb"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -9654,6 +9694,11 @@
       "mode": "0000644",
       "sha256": "bb66cec6b745cd6e50efd8828d05a75aa68fbc50ed43d8a49988c1246bfd3324"
     },
+    {
+      "path": "tests/hall_catalog_world.mjs",
+      "mode": "0000644",
+      "sha256": "79c8759cbb0d17477139acae6e0057caa70021ff0edfeba9c419c14ad729a1ac"
+    },
     {
       "path": "tests/hall_collab_world.mjs",
       "mode": "0000644",
@@ -9677,7 +9722,7 @@
     {
       "path": "tests/hall_page_gate_map.mjs",
       "mode": "0000644",
-      "sha256": "6e20f87284374b3f70ad09128ad8368cf77b0d29787fdb897494180ce6e239c0"
+      "sha256": "a66273f4a3e376d0055afb0e41fac308e84eb30b2f468f8e36831f3aad662f98"
     },
     {
       "path": "tests/hall_palette.mjs",
@@ -9692,7 +9737,7 @@
     {
       "path": "tests/hall_reading_world.mjs",
       "mode": "0000644",
-      "sha256": "e03ff52ec428e27e30632019565999634e9a428b1d0423c6ebe11b8438da0b87"
+      "sha256": "0639e14742626f0f75400a5dd462418ff4dba9ab9f28aa517a165f63c65046c3"
     },
     {
       "path": "tests/hall_record_world.mjs",
@@ -9702,7 +9747,7 @@
     {
       "path": "tests/hall_roster_world.mjs",
       "mode": "0000644",
-      "sha256": "1791571b220385664394e77546cdf7359147c3f3d32b56938290bec4294c6020"
+      "sha256": "66ce52ea8ff217a089a420792322bc322fe1e332458779f8c6da6c57f74b4bf2"
     },
     {
       "path": "tests/hall_signout.mjs",
@@ -11024,6 +11069,11 @@
       "mode": "0000644",
       "sha256": "70228aa4be345cc09664b3b725e30c3a1e0eacf4c39573db1304fb219d3245e7"
     },
+    {
+      "path": "tests/spike_task_map.mjs",
+      "mode": "0000644",
+      "sha256": "714d7a3c6d3247bcd4412c12db7a905a4c7a351ed8d835c606a4d43b9d7249b3"
+    },
     {
       "path": "tests/sso_checkin_identity_spoof.mjs",
       "mode": "0000644",

package/docs/adr/0227-a-task-network-map-is-refused-the-goal-graph-is-the-map.md

@@ -0,0 +1,169 @@
+# 0227 — A task network map is refused; the goal graph is the map, and search answers findability
+
+- **Status:** Accepted
+- **Date:** 2026-09-02
+- **Tasks:** [#1003282](https://cloudbongos.com/builders#/task/1003282)
+- **Goal:** [#1000072](https://cloudbongos.com/builders#/goal/1000072) — Human legibility, criterion `legibility-project-map`, which gates itself on this spike.
+- **Evidence:** [`docs/research/task-network-map-readability.md`](../research/task-network-map-readability.md) and the figures in [`docs/research/task-network-map/`](../research/task-network-map/), rendered by [`scripts/gds/spike-task-map.js`](../../scripts/gds/spike-task-map.js).
+- **Sibling goal:** [#1000027](https://cloudbongos.com/builders#/goal/1000027) — Findability, "the grep path" (ADR 0095, ADR 0060).
+
+## 1. The decision
+
+**No whole-corpus task map, at any dependency density.** The measured verdict holds
+across a swept range (p=2% to p=40% of tasks carrying a dependency): a node-link view of
+~1,357 tasks is confetti, not structure, and the obvious fix — drawing it denser — draws
+forty goals badly while claiming to show a thousand tasks. A confident picture of nothing
+is the opposite of legibility, which is the goal this criterion serves.
+
+What is readable is **the ~40-node goal graph as the entry point**, with a **per-goal
+dependency forest as the drill-down**, queried when a goal is opened rather than zoomed
+out of a global map.
+
+**This is a negative result, and it is the deliverable.** The criterion said so in
+advance: a network view that becomes unreadable at 1,300 tasks is not a solution, and the
+spike's output is an ADR plus a task list, not a prototype.
+
+## 2. What the edges are, and which already exist in the DB
+
+Every edge a map could draw is already stored. None needs a new table.
+
+| Edge | Storage | Notes |
+|---|---|---|
+| task → task dependency | `task_dependencies` (migration 020) | The load-bearing one; gates claims (`409 DEPS_NOT_SHIPPED`, ADR 0015). This is view B. |
+| task → subtask | `tasks.parent_task_id` | Tree, not graph. Cheap. |
+| task → goal | `tasks.goal_id` → `goals` | The aggregation key for view C's node weights. |
+| task → criterion → goal | `task_criteria` → `done_when_criteria` | The done-when rollup `/status` already walks (ADR 0025). |
+| idea → task (promotion) | `idea_inbox.promoted_to_task_id` → `tasks` | Triage lineage, forward direction. |
+| idea → idea (merge) | `idea_inbox.merged_into_idea_id` (`migrations/<redacted>.sql`) | The merge target; chain-free by CHECK constraint. |
+| task → version | `tasks.version_id` → `versions` | Membership, not connection — a filter, never an edge to draw. |
+
+The triage-lineage edges (the last three) are the ones the owner's question actually
+reaches for — what became of the thing I was brainstorming — and they form **short
+chains, not a network**. That distinction drives §4.
+
+## 3. How it survives the number
+
+- **View C is aggregated at the query.** One `goalRollups` query plus a cross-goal
+  dependency count. ~40 nodes; the payload is bytes.
+- **View B is lazy and scoped.** A separate small query per opened goal. It covers 3–40%
+  of the corpus and never 100% — and the tasks it omits are precisely those with nothing
+  to connect them to, so the omission is the finding rather than a gap.
+- **Views A (every task) and D (densified) are never drawn** — not as a default, not
+  behind an "advanced" toggle.
+- **Density is measured before anything is built.** Two numbers decide the shape: the
+  share of tasks carrying a dependency, and the share of dependencies crossing a goal
+  boundary. If cross-goal dependencies are near zero, view C is forty disconnected dots
+  and the honest deliverable is a grid of goal cards — which the hall's Goals page
+  already is. **That outcome would mean the right amount of new map is none**, and it is
+  why the first task in §6 is a measurement, not a build.
+
+## 4. Findability (goal 1000027) answers the owner's question more cheaply than a map
+
+Read first, as the criterion required. Goal 1000027 is the grep path: a repo navigated by
+literal search, with meaning written into the source (ADR 0095), plus the rank-scoped
+lexical search over repo docs and indexed DB prose that `/recall` serves (ADR 0060).
+
+The owner's question splits in two, and only one half is a map:
+
+- **Find what I was brainstorming.** This is search, and it already exists. `/recall`
+  plus the lineage columns in §2 answers it end to end: find the idea, follow
+  `promoted_to_task_id` / `merged_into_idea_id` to what became of it. What is missing is
+  not a picture but a **lineage trail** — one thing and its ancestry, rendered as an
+  ordered list. That is a text surface, cheap, accessible for free, and it does not
+  degrade at 1,357 rows because it never shows more than one chain.
+- **See the shape of the portfolio.** Search cannot answer this, and this is the only
+  half a graph earns. It is view C, and it is about ~40 goals — not about tasks.
+
+**Therefore the lineage trail outranks the map.** It is the cheaper answer to the question
+actually asked, and it is sequenced first in §6. A whole-corpus picture was never the
+cheap way to find a thing.
+
+## 5. Accessibility and the no-sideways-scroll rule
+
+Whatever ships lands in the hall, so it inherits the hall's rules, and a node-link graph
+is the hardest surface to make accessible.
+
+1. **The table is the primary surface; the graph is the enhancement.** Every graph view
+   ships with a semantic equivalent (goal name, task count, category, dependency count) —
+   not an `aria-label` bolted onto an SVG blob, and not a "view as table" toggle that
+   hides the accessible path behind a click. A keyboard-only or screen-reader user gets
+   the same facts by default.
+2. **No sideways scroll on the page.** A graph that cannot fit the width scrolls inside
+   its own `overflow-x: auto` container; the page body never scrolls horizontally.
+3. **Colour is never the only channel.** View C encodes category as colour; category must
+   also be text on the node or in the row, since the ADR 0192 category set is not
+   colour-distinguishable at forty nodes.
+4. **The lineage trail has none of these problems**, which is a further reason it is
+   sequenced first.
+
+## 6. The ranked task list
+
+Ranked, and deliberately front-loaded with the cheap text surfaces so the graph is built
+only if the measurement says it would carry anything.
+
+1. **Measure the real density** — [#1003477](https://cloudbongos.com/builders#/task/1003477) — against the live DB (`--from`), recording the two
+   numbers from §3. Gates items 3 and 4; may cancel them outright.
+2. **The lineage trail** — [#1003478](https://cloudbongos.com/builders#/task/1003478) — an idea's ancestry and what became of it, as an ordered text
+   surface on the existing search path (§4). Independent of the graph, and the answer to
+   the owner's actual question.
+3. **The goal graph (view C)** — [#1003479](https://cloudbongos.com/builders#/task/1003479) — ~40 nodes, cross-goal dependency edges, task-count
+   weight, category as colour *and* text, table equivalent shipped with it. Only if
+   item 1 finds cross-goal edges.
+4. **The per-goal dependency forest (view B)** — [#1003480](https://cloudbongos.com/builders#/task/1003480) — the drill-down, queried per goal. Only
+   if item 1 finds a meaningful share of tasks carrying dependencies.
+
+## 7. What was rejected
+
+- **The task graph, zoomed out (view A).** A thousand dots whose positions are noise.
+- **Densifying to make it look structured (view D).** Forty dots presented as a thousand;
+  it invites belief in structure that is not there.
+- **A prototype as this spike's output.** The criterion forbade it. `spike-task-map.js` is
+  a measuring instrument that renders figures from a synthetic sweep — it ships as
+  evidence under `docs/research/`, is wired to no route and no page, and nothing in the
+  hall imports it.
+- **Building the map before measuring.** The two numbers in §3 can cancel items 3 and 4,
+  and discovering that after building would be the expensive order.
+
+## 8. The honest limit
+
+**The measured corpus is synthetic.** The live DB was unreachable from the environment the
+harness ran in, so it sweeps a plausible range instead of observing one truth. The sweep
+is what makes the *verdict* robust — every conclusion above holds from p=2% to p=40% —
+but the specific numbers are model output, not observation, and the ~40 goal count and the
+85% within-goal edge preference are modelled from the repo's own record. This is exactly
+why item 1 of §6 is a measurement against the real DB and why it gates the rest. A
+negative result that saves building an unreadable graph is a successful spike; a negative
+result that also names the one query that could overturn it is a finished one.
+
+## 9. Conceded: the harness over-built for the question
+
+The adversarial review of this work made a point worth keeping rather than arguing with,
+so it is recorded here instead of in a session log that nobody re-reads.
+
+**The verdict above rests on arithmetic, not on the renderer.** The two load-bearing
+findings — the share of nodes with degree 0, and the ink budget (screen area ÷ nodes
+against a minimum dot pitch and label width) — are division. They need no force
+simulation and no PNG. Yet `spike-task-map.js` carries a Barnes-Hut layout and a
+hand-rolled PNG encoder (CRC32, zlib framing, canvas primitives), and the write-up itself
+concedes that in view A "every dot's location is an accident of the seed". Building an
+accurate physics simulation to place points whose positions are then declared
+meaningless is disproportionate to a decision document.
+
+**What the renderer does still earn:** the figures are what make overplotting legible to
+a human reader, which a table of `marks` counts genuinely does not do — and item 1 of §6
+re-runs this same harness against the live DB, so it is the instrument that closes the
+spike, not dead weight. That is why it is kept rather than deleted.
+
+**What was fixed rather than argued:** the encoder had no test coverage at all, which is
+the sharper version of the same criticism — the figures are cited as evidence, so a
+stride, CRC or alpha-blend bug would have corrupted the evidence *silently*. `crc32`,
+`chunk`, `writePng`, `canvas`, `goalColor` and `render` are now exported and pinned by
+`tests/spike_task_map.mjs` (canonical CRC-32 vectors plus a cross-check against
+`zlib.crc32`, chunk framing, stride correctness, out-of-bounds clipping, alpha blending,
+disc radius, line endpoints, and a full inflate-and-locate round trip). The stride
+assertion was mutation-tested: changing `y * w` to `y * h` fails two tests.
+
+**The transferable rule:** *a spike may build only what its verdict actually rests on;
+anything further is a prototype wearing a harness's name.* Had the arithmetic been run
+first, the figures would have been a nice-to-have and the physics would never have been
+written.

package/docs/adr/README.md

@@ -312,5 +312,6 @@ This keeps the decision history honest and traceable.
 | 0223 | [**The anti-pattern detector is two tiers inside the kit: mechanical floors fail, craft tells warn, a false positive is waived in the file with its reason, and nothing new is installed** ([task 1003329](https://cloudbongos.com/builders#/task/1003329) · goal 1000083). The [detector] group of impeccable's rebuild spec (about sixty rules, a CLI plus a browser bundle wired to hooks, per-project ignores, in-file waivers, "a clean scan is a floor and never proof") lands as RULES in the kit that already exists, per the task body: no second tool, no bundle, no hook. Decisions: **D1** `kit/tells.js` carries the static rules and `check-mock.js` runs them after the platform rules and taste bans; `lib.js`'s `factsInPage` collects the computed-value twins as `tells` and `render.js` prints them as `~ tell:` lines per render, recorded in `report.json`, never counted as problems. Two tiers: floors FAIL (a bounce easing; a card nested in a card) and tells WARN (the icon-heading-text grid, hero metrics, section numbering, a kicker above the h1, a side stripe, a hard offset shadow, a coloured halo, decorative blur, a default typeface, a wide measure, a long headline, the same entrance everywhere, a geometric mask on a plate, glyphs as icons, a rainbow gradient, the browser surfaces nobody themed, proportional numerals, tiny type; rendered: measure, tiny text, numerals in cells, headline lines, an overshooting curve). **D2** the world decides which tells are floors: a kicker above the h1 is a FAIL where the instance's `DESIGN.md` bans the eyebrow (a new `eyebrow` taste key), a WARN elsewhere. **D3** a false positive is waived in the file with its reason (`kit-ignore: <rule prefix> (reason)` → a WAIVE row), `--raw` runs with none, `--no-tells` runs the platform rules only, `--json` prints rows with `fails` / `warns` counts; no per-project ignore config. **D4** not ported: the purple-to-blue tell (a literal colour already fails; hue is unresolvable under the fifteen), an injected overlay, the screenshot sampler (`contrast.js --url` is that pass), a cascade resolver (the browser is the resolver), native code, every hook. **D5** the pins: a clean fixture passes every rule, every rule class trips at its tier with the case count equal to the rule count, the promotion, the waiver / raw / json paths through the real CLI, `craftTells` as warnings; the hub mock and the three specimens still pass, `/projects` and the grove specimen still render ALL CLEAN. Rejected: a second CLI; every tell as a floor (the kit as the taste and the instance as the exception); a project-wide ignore config; an edit-time hook.](0223-the-detector-is-two-tiers-in-the-kit.md) | ui-design / kit |
 | 0224 | [**Module-owned skills reach the core checkout as untracked, self-ignored copies with a manifest: the self-copy guard stays, the dev path is a flag, and the file map skips what the module documents** ([task 1003330](https://cloudbongos.com/builders#/task/1003330) · goal 1000083). `materializeClaude`'s self-copy guard is right (a core copying itself is a no-op at best), but Claude Code discovers only `.claude/skills/` at the project root, so a builder IN the core checkout could not invoke any of the nine ui-design skills written there. Decisions: **D1** `node scripts/gds/claude-materialize.js --module-skills-only [--dry-run] [--clean]` calls `materializeModuleSkillsIntoCore`: the same roster, gate and slug rule as step 1b, verbatim copies (no bongosify: the checkout runs `node scripts/gds/…`), a core-owned name kept, a disabled module's excluded; the guard untouched. **D2** untracked and self-ignored: a generated `.claude/skills/.module-skills.json` manifest and a `.gitignore` that ignores itself, the manifest and every materialised dir; each run removes what the last manifest named then lands the current set (byte-identical on repeat; a dropped declaration disappears); `--clean` stops after the removal. **D3** `gen-file-map.js` and `tests/file_map.mjs` skip materialised names by the manifest (a module skill is documented by its module's README, not by the notes sidecar). **D4** init from a checkout that carries the copies still lands them through step 1b, transformed, and never the dotfiles. **D5** pinned end to end in `tests/claude_materialize.mjs`. Rejected: dropping the guard; committing the copies; symlinks or junctions; notes for dirs not in the repository.](<redacted>.md) | materialiser / skills |
 | 0225 | [**Privacy suppresses cross-project surfaces only: a private builder still appears on their own project's roster** ([task 1003443](https://cloudbongos.com/builders#/task/1003443) · goal 1000075). The accepted privacy spec defined its two flags inconsistently for one case: `hide_stats` suppresses "everything derived from the CROSS-PROJECT rollup" (qualified, so an in-project leaderboard is out of scope) while `account_visibility: private` said "absent from search, LEADERBOARDS, sitemap" (unqualified, so it read as covering the in-project one too) — and PV2 demands "ONE shared predicate used by every public read: … leaderboards …" while `modules/economy/credits.js`'s `leaderboard()` is a bare `SELECT … FROM builders` with no join and no predicate. Read one way that is an unshipped PV2 violation in main; read the other it is correct, and nothing settled which. **Owner decision (2026-08-30): privacy suppresses CROSS-PROJECT surfaces only.** A `private` builder is absent from `/u/<handle>`, platform search, the sitemap, Explore and the recruiting reach, and still appears on the roster of a project they build on — a project's record of its own work is the project's business. Two consequences are the point of recording it: `credits.leaderboard()` is **correct as written** (adding a predicate there would be a regression, not a fix — exactly what a literal PV2 reading would have done), and PV2's "leaderboards" means the cross-project ones. The spec was amended rather than annotated: the D1 row and both `active · public` matrix rows now say *cross-project*, the two `active · private` rows drop "absent everywhere" (the file's most misreadable phrase) for "absent from every cross-project surface", PV2's ship-table row is qualified, and the boundary lands as the **third rule** under D2 beside "`hide_stats` beats everything". Rejected: making `private` hide a builder from projects they build on (it reads as more protective and breaks the ledger — a roster that omits contributors cannot show who built the thing, and credits would accrue to someone invisible on the surface explaining them); and leaving it as a dated spec note (it pins shipped code as deliberately predicate-free, which is an ADR's job).](<redacted>.md) | privacy / spec |
+| 0227 | [**A task network map is refused; the goal graph is the map, and search answers findability** ([task 1003282](https://cloudbongos.com/builders#/task/1003282) · goal 1000072, criterion `legibility-project-map`, which gates itself on this spike). Measured across a swept density range (p=2%–40% of tasks carrying a dependency): a node-link view of ~1,357 tasks is confetti, not structure, and densifying it draws forty goals badly while claiming to show a thousand tasks — a confident picture of nothing is the opposite of the legibility this goal serves. Decision: NO whole-corpus task map at any density; the readable surface is the ~40-node GOAL graph as the entry point with a per-goal DEPENDENCY FOREST as the drill-down, queried when a goal is opened rather than zoomed out of a global map. Every edge a map could draw already exists in the DB and none needs a new table — `task_dependencies` (020), `tasks.parent_task_id`, `tasks.goal_id`, `task_criteria`→`done_when_criteria`, `idea_inbox.promoted_to_task_id`, `idea_inbox.merged_into_idea_id` (`core_195`), `tasks.version_id` (membership, never an edge). **Findability (goal 1000027) answers the owner’s question more cheaply than a map**: the ask splits into “find what I was brainstorming”, which `/recall` (ADR 0060) plus the two lineage columns already answers end to end and which wants a text LINEAGE TRAIL — one thing and its ancestry — not a picture; and “see the shape of the portfolio”, the only half a graph earns, which is about ~40 goals and not about tasks. So the trail outranks the map and is sequenced first. Accessibility: the TABLE is the primary surface and the graph the enhancement (not an `aria-label` on an SVG blob, not a toggle hiding the accessible path), no sideways scroll on the page (the graph scrolls inside its own container), and category is text as well as colour since the ADR 0192 set is not colour-distinguishable at forty nodes. Ranked list: (1) measure the real density against the live DB — it GATES and may cancel the rest, (2) the lineage trail, (3) the goal graph, (4) the per-goal forest. Rejected: view A (every task); view D (densified); a prototype as the output (the criterion forbade it — `spike-task-map.js` is a measuring instrument under `docs/research/`, wired to no route); and building before measuring. Honest limit: the corpus is SYNTHETIC (the live DB was unreachable), so the verdict is robust across the sweep but the specific numbers are model output — which is why item 1 is a measurement against the real DB.](<redacted>.md) | GDS / legibility + hall |
 
 > ⚠️ **Numbering collisions are now machine-enforced, not narrated.** Twenty numbers are shared by two ADRs each — assigned in parallel sessions before anything checked. The files keep their filenames (renumbering would break every existing citation, and a number once assigned is never reused), and this table disambiguates each pair as `NNNN-a` / `NNNN-b`. The authoritative list is `LEGACY_DUPLICATE_ADRS` in [`scripts/gds/adr-namespace.js`](../../scripts/gds/adr-namespace.js), frozen by exact filename: a **new** collision — or a third file joining a legacy number, or a rename of either half — hard-fails the `unit` CI gate, as does an index row that points at no file or an ADR with no row. The list may only shrink. This paragraph used to narrate the collisions one by one and had fallen eight behind reality; see [ADR 0195](<redacted>.md) for why the check exists and why the pairs are grandfathered rather than renumbered.