@bongos/core 1.19.468 → 1.19.469

package/docs/copy-registry.json

@@ -3,17 +3,17 @@
   "generator": "scripts/gds/copy-inventory.js",
   "goal": 1000074,
   "counts": {
-    "strings": 1591,
+    "strings": 1586,
     "unique_ids": 1376,
-    "certain": 1591,
+    "certain": 1586,
     "heuristic": 0,
-    "duplicate_ids": 154
+    "duplicate_ids": 151
   },
   "surfaces": {
     "builders-hall": {
       "at": "modules/hall-ui/public",
-      "files": 73,
-      "strings": 1148
+      "files": 72,
+      "strings": 1143
     },
     "status-dashboard": {
       "at": "modules/status-ui/public",
@@ -168,18 +168,6 @@
         "modules/public-landing/public/projects.html:1042"
       ]
     },
-    {
-      "id": "b95918d421ae",
-      "surface": "builders-hall",
-      "text": "People — {{worldName}}",
-      "occurrences": 4,
-      "at": [
-        "modules/hall-ui/public/people.html:6",
-        "modules/hall-ui/public/people.html:6",
-        "modules/hall-ui/public/scouting.html:6",
-        "modules/hall-ui/public/scouting.html:6"
-      ]
-    },
     {
       "id": "3eb67b892dea",
       "surface": "landing",
@@ -499,16 +487,6 @@
         "modules/hall-ui/public/watch.js:315"
       ]
     },
-    {
-      "id": "29bd516ad17e",
-      "surface": "builders-hall",
-      "text": "Builder directory",
-      "occurrences": 2,
-      "at": [
-        "modules/hall-ui/public/people.html:37",
-        "modules/hall-ui/public/scouting.html:42"
-      ]
-    },
     {
       "id": "563d29ed86d8",
       "surface": "builders-hall",
@@ -709,16 +687,6 @@
         "modules/hall-ui/public/drachmae.html:6"
       ]
     },
-    {
-      "id": "ddebbccd4b37",
-      "surface": "builders-hall",
-      "text": "Everyone building across hosted projects, ranked by track record. Descriptive only — cross-project numbers never carry authority here.",
-      "occurrences": 2,
-      "at": [
-        "modules/hall-ui/public/people.html:29",
-        "modules/hall-ui/public/scouting.html:34"
-      ]
-    },
     {
       "id": "f70f217504ce",
       "surface": "status-dashboard",
@@ -879,16 +847,6 @@
         "modules/status-ui/public/index.html:312"
       ]
     },
-    {
-      "id": "2bde9c630fd2",
-      "surface": "builders-hall",
-      "text": "Loading the directory…",
-      "occurrences": 2,
-      "at": [
-        "modules/hall-ui/public/people.html:40",
-        "modules/hall-ui/public/scouting.html:45"
-      ]
-    },
     {
       "id": "ceec2218efe3",
       "surface": "builders-hall",
@@ -1049,6 +1007,16 @@
         "modules/hall-ui/public/goals.html:187"
       ]
     },
+    {
+      "id": "b95918d421ae",
+      "surface": "builders-hall",
+      "text": "People — {{worldName}}",
+      "occurrences": 2,
+      "at": [
+        "modules/hall-ui/public/people.html:6",
+        "modules/hall-ui/public/people.html:6"
+      ]
+    },
     {
       "id": "ed8edd684547",
       "surface": "builders-hall",
@@ -2478,15 +2446,6 @@
       "origin": "html-text",
       "confidence": "certain"
     },
-    {
-      "id": "29bd516ad17e",
-      "surface": "builders-hall",
-      "text": "Builder directory",
-      "file": "modules/hall-ui/public/scouting.html",
-      "line": 42,
-      "origin": "html-text",
-      "confidence": "certain"
-    },
     {
       "id": "08bfcc9198ba",
       "surface": "builders-hall",
@@ -4431,15 +4390,6 @@
       "origin": "html-text",
       "confidence": "certain"
     },
-    {
-      "id": "ddebbccd4b37",
-      "surface": "builders-hall",
-      "text": "Everyone building across hosted projects, ranked by track record. Descriptive only — cross-project numbers never carry authority here.",
-      "file": "modules/hall-ui/public/scouting.html",
-      "line": 34,
-      "origin": "html-text",
-      "confidence": "certain"
-    },
     {
       "id": "4750e12477e7",
       "surface": "builders-hall",
@@ -5583,15 +5533,6 @@
       "origin": "html-text",
       "confidence": "certain"
     },
-    {
-      "id": "2bde9c630fd2",
-      "surface": "builders-hall",
-      "text": "Loading the directory…",
-      "file": "modules/hall-ui/public/scouting.html",
-      "line": 45,
-      "origin": "html-text",
-      "confidence": "certain"
-    },
     {
       "id": "fcd755e8dd30",
       "surface": "builders-hall",
@@ -6789,24 +6730,6 @@
       "origin": "html-title",
       "confidence": "certain"
     },
-    {
-      "id": "b95918d421ae",
-      "surface": "builders-hall",
-      "text": "People — {{worldName}}",
-      "file": "modules/hall-ui/public/scouting.html",
-      "line": 6,
-      "origin": "html-text",
-      "confidence": "certain"
-    },
-    {
-      "id": "b95918d421ae",
-      "surface": "builders-hall",
-      "text": "People — {{worldName}}",
-      "file": "modules/hall-ui/public/scouting.html",
-      "line": 6,
-      "origin": "html-title",
-      "confidence": "certain"
-    },
     {
       "id": "4a46b478edaf",
       "surface": "builders-hall",

package/docs/file-map.md

@@ -68,6 +68,9 @@
 │   │   ├── overnight-builder.md ← (#358) operator runbook for the autonomous overnight session-runner
 │   │   ├── builder-box-lifecycle.md ← (#598/ADR 0031) operator runbook: provision/park/wake/deprovision dev boxes, the two sweeps, config env, going-live steps
 │   │   └── managed-settings-remote-control.md ← (#599/ADR 0031 §1, #760/ADR 0038) operator+builder guide: distribute the locked Claude Desktop SSH config; the browser web-terminal (ttyd + Cloudflare Tunnel) on-ramp
+│   ├── research/                ← investigations that answer a question rather than record a decision (an ADR) or a procedure (a recipe)
+│   │   ├── task-network-map-readability.md ← (task 1003282, goal 1000072) the spike verdict: a node-link map of ~1,357 tasks is unreadable at every dependency density — 59–97% isolated dots, and the dense fix overplots 84% of them into the 40-node goal graph. Build the goal graph + a per-goal dependency forest; measure the real density with `--from` first
+│   │   └── task-network-map/    ← the figures that verdict argues from, rendered by scripts/gds/spike-task-map.js — regenerate, never hand-edit
 │   ├── reviews/                 ← temporary audit/review docs (e.g. claude-md-audit-V3.R86.md)
 │   ├── session-logs/            ← one file per session, named YYYY-MM-DD-<slug>.md (CLAUDE.md §13 indexes them)
 │   └── session-log-archive.md   ← compressed older session-log prose
@@ -127,7 +130,7 @@
 │   ├── sessions/                ← CORE-DOMAIN carve (BV1.R82, default-on): the session_records corpus + data plane (upload, cross-builder search/deep-dive), the BFG read-the-room scorer, session-pulse/stale-claim helpers. Registers no port — reached via HTTP POST to its own /sessions route; resolves the economy `reward` port for the cost-plus token reward. CLAUDE.md, module.json, routes/sessions.js, bfg.js, pulse.js.
 │   ├── autonomy/                ← CORE-DOMAIN carve (BV1.R83, default-on): the MAS autonomy surfaces — the $0 deterministic autonomy gate (System 3, inert until armed), the conductor/architect CLIs, and the in-process routine timers (incl. the weekly peer-vote-tally poller). Registers no port; resolves the lifecycle `tallyPeerVotes` doorway. CLAUDE.md, module.json, routes/autonomy.js, autonomy.js.
 │   ├── status-ui/              ← CORE-DOMAIN WEB-SURFACE carve (BV1.R84, default-on): the public status dashboard at status.<apex>, moved from public-status/. NO routes/db/port — declares contributes.webSurfaces:[{host:"status.",dir:"public"}], served by the loader web-surface seam (moduleWebSurfaces → serve-internal). CLAUDE.md, module.json, public/{index.html,status.js,style.css,cursors/,snapshots/}.
-│   ├── hall-ui/                ← CORE-DOMAIN WEB-SURFACE carve (BV1.R85, default-on): the authenticated builders' hall at builders.<apex>, moved from public-builders/ (~13k LOC, the largest). NO routes/db/port — declares contributes.webSurfaces:[{host:"builders.",dir:"public"}] for discovery, but UNLIKE status-ui keeps its DEDICATED serving block in serve-internal (the /builders shim + canonical redirects + citizen/Archon page gates + asset-stamping + hall-widget injection), partitioned out of the generic web-surface loop and served from BUILDERS_DIR. CLAUDE.md, module.json, public/{index.html,builders.js,style.css,work,watch,harbor,gate,pair,settings,ranks,sessions,primer,diagrams,atlas,...}.{html,js},cursors/,chime.wav. Three ARCHETYPE sheets sit beside the per-page ones: `record.css` (the task + idea records, task 1003305), `room.css` (the READING ROOMS — the primer + the diagrams index, task 1003306: the reading measure and rhythm, the table of contents, the progress hairline and the framed figure diagram-viewer.js upgrades on both pages) and `oversight.css` (the OVERSIGHT family — government, watch, harbor, gate, task 1003469: the row, the figure band inside a panel, the group head, the inline form, the grant toggle and the shared confirm modal; named oversight because the vocabulary wall bans "governance" on the government surface). A page sheet then holds only what one page has and the others do not — `primer.css` the acknowledge gate, `diagrams.css` the legend strip, `gate.css` the hold reasons and file chips, `watch.css` the severities, the report reader and the grade trend, `people.css` the directory's identity cell (task 1003470: `/scouting` is the LEGACY DOOR to `/people` and ships the same body and script — `scouting.html` loads `people.js`; there is no `scouting.js`).
+│   ├── hall-ui/                ← CORE-DOMAIN WEB-SURFACE carve (BV1.R85, default-on): the authenticated builders' hall at builders.<apex>, moved from public-builders/ (~13k LOC, the largest). NO routes/db/port — declares contributes.webSurfaces:[{host:"builders.",dir:"public"}] for discovery, but UNLIKE status-ui keeps its DEDICATED serving block in serve-internal (the /builders shim + canonical redirects + citizen/Archon page gates + asset-stamping + hall-widget injection), partitioned out of the generic web-surface loop and served from BUILDERS_DIR. CLAUDE.md, module.json, public/{index.html,builders.js,style.css,work,watch,harbor,gate,pair,settings,ranks,sessions,primer,diagrams,atlas,...}.{html,js},cursors/,chime.wav. Three ARCHETYPE sheets sit beside the per-page ones: `record.css` (the task + idea records, task 1003305), `room.css` (the READING ROOMS — the primer + the diagrams index, task 1003306: the reading measure and rhythm, the table of contents, the progress hairline and the framed figure diagram-viewer.js upgrades on both pages) and `oversight.css` (the OVERSIGHT family — government, watch, harbor, gate, task 1003469: the row, the figure band inside a panel, the group head, the inline form, the grant toggle and the shared confirm modal; named oversight because the vocabulary wall bans "governance" on the government surface). A page sheet then holds only what one page has and the others do not — `primer.css` the acknowledge gate, `diagrams.css` the legend strip, `gate.css` the hold reasons and file chips, `watch.css` the severities, the report reader and the grade trend, `people.css` the directory's identity cell (task 1003470 made the legacy door `/scouting` ship the same body and script as `/people`; task 1003440 then deleted the door — `scouting.html` and `scouting.states.json` are gone and the URL 301s to `/people`).
 │   ├── lifecycle/               ← CORE-DOMAIN carve (BV1.R86, default-on): the build state machine — tasks · claims · versions · done-when · goals · dependencies · claim→ship→grade→credit · github-push + merge-lock + conflict-resolve + publish-reconciler. The LAST, most-coupled carve; registers the `lifecycle` kernel port (createTask, classifyTaskKind, tallyPeerVotes, work-tracking reads). CLAUDE.md, module.json, routes/{tasks,claims,versions,done-when,goals,dependencies,gate-approvals,analytics}.js, lifecycle.js, github-push.js, merge-lock.js, conflict-resolve.js, publish-reconciler.js, task-visuals.js + task-visual-db.js + routes/visuals.js (the optional ship-time visual, task 1003109 — the route file is NOT named task-*.js on purpose; see the module CLAUDE.md).
 │   ├── copy-desk/               ← CORE-DOMAIN module (task 1003113 / R02 of goal 1000074, default-on): the COPY half of the design contract — ADR 0081 gave design TOKENS a repo-owned source of truth, text had none. Owns the FLAG (anyone in any role marks a string or a whole surface as needing an artist's attention, with a reason required in BOTH the route and a CHECK constraint) and the QUEUE an artist reads it from. READS R01's committed registry (docs/copy-registry.json, generated by scripts/gds/copy-inventory.js) and never writes it. NO LIVE CMS is the hard non-goal: no column here could hold replacement text, and copy_no_cms.mjs pins that. Key is `copy-desk`, not `copy` — the branding contract already owns a `copy` block, so the bare word reds the "core carries no module code" fitness check. CLAUDE.md, module.json, registry.js, flags.js, routes/copy-desk.js, migrations/copy_desk_001_flags.sql, tests/{copy_flags,copy_queue,copy_no_cms}.mjs. Its hall surface lives with hall-ui (public/copy-desk.{html,js,css}), per the one-key-per-web-surface precedent.
 │   ├── ui-design/               ← CORE-DOMAIN module (task 1003324 / ADR 0197, default-on): the design capability every builder on every instance gets — ships METHOD, never a world. Absorbs ADR 0081's layer: adapters/{claude-design,figma}/index.js (moved from src/ui/adapters/), scripts/{design-sync,figma-design-sync,validate-design}.js (moved from scripts/gds/, which keeps thin shims), docs/design-contract.md (moved from docs/). Declaration-only: contributes.skills design (the /design playbook, new) + design-sync + figma-design-sync; no routes/port/migrations, so disabling it touches no served surface. CLAUDE.md separates the platform FLOORS (the Fifteen Rule, the dark twins, no page :root, the 24px floor, AA in both modes, the kill switch) from the instance's WORLD (its packs + DESIGN.md). kit/ (task 1003320) is the look-before-you-ship kit: lib.js (the floors, the states/probes contracts, the action + expectation vocabularies, the WCAG maths, the stub spawner), serve.js (any surface through the doorway's real transforms + fixtures/), render.js (states × 1440/390/320 × dark/light, audited), probe.js (PASS/FAIL contracts), check-mock.js (platform rules + the instance's DESIGN.md taste bans, then the detector), tells.js (task 1003329 / ADR 0223: the anti-pattern detector as two tiers — floors FAIL, craft tells WARN, kit-ignore waivers per file; the rendered twins live in lib.js factsInPage), contrast.js + png.js; a page's <page>.states.json / <page>.probes.json sit BESIDE the surface (modules/public-landing/public/, modules/hall-ui/public/). Recipe: docs/recipes/ui-look-before-you-ship.md. skills/ (task 1003321 / ADR 0198) is the vendoring policy: policy.json (licence allowlist, verdicts that may land, sidecar fields, preamble markers), PREAMBLE.md (the platform preamble every vendored SKILL.md opens with), README.md (the roster — both origins scanned dangerous on 2026-08-28, landed as rebuild specs; nothing vendored — and the landing recipe); a landable copy goes under skills/vendor/<name>/ with PROVENANCE.md + LICENSE and is materialised into an instance's .claude/skills/ by claude-materialize.js step 1b. skills/<name>/ (task 1003325 / ADR 0220) are the in-house rebuilds from the specs, first-party and counted: design-taste-frontend (the default taste skill), design-taste-frontend-v1 (the earlier generation, kept distinct), high-end-visual-design (the polish pass), redesign-existing-projects (the in-place upgrade); each opens with the same preamble and carries a "Rebuilt from" section instead of a sidecar. impeccable/ (task 1003326 / ADR 0221) is the design-craft method as ONE skill with sub-commands: SKILL.md (the router, the menu, the craft floor, the bounded finish) + reference/<sub-command>.md (eighteen playbooks, one loaded per request); no hooks, no bypass agent, no telemetry, no live server. image-to-code/, imagegen-frontend-web/, imagegen-frontend-mobile/, brandkit/ (task 1003328 / ADR 0222) are the image family under the hero-only rule: plates and hero objects only, the pair (JPEG dark plate + WebP alpha cutout) with a <file>.json sidecar beside each, through the instance's art pipeline key; the grove specimen's styles/grove/assets/ is the worked example. styles/ (task 1003323 / ADR 0219) is the style library: <name>/pack.json (the theme.ui overlay, exactly the fifteen) + DESIGN.md (the look's derived recipes, thirteen in lockstep with the pack) + mock.html (the specimen); chrome-world (pinned to the neutral pack), expedition, grove; STYLE=<name> on the kit lays a look over the instance's pack through GDS_BRANDING_FILE; tests/ui_design_styles.mjs runs the world/cosmos/hall token suites once per alternate (UI_DESIGN_PACK). config/design-tokens.* + design-sources.json STAY in config/ as the host boundary; public-landing keeps its own key (first customer, not owner).
@@ -159,6 +162,7 @@
 │       ├── next-number.js       ← deterministic next-free ADR + migration number from origin/main ∪ local working tree; supersedes the drift-prone claim-time DB counter (V4.R26, [#964](https://example.com/builders#/task/964)). `node scripts/gds/next-number.js [--json]`
 │       ├── gen-repo-map.js      ← Path B (ADR 0063, [#1224](https://example.com/builders#/task/1224)): zero-dep, deterministic symbol-skeleton generator → docs/repo-map.md + the generated factual block in each nested CLAUDE.md; ranks exported symbols by reference frequency. `--check` = CI gate; regenerated on deploy by ship.js regenerateRepoMap()
 │       ├── gen-file-map.js      ← ADR 0066 ([#1276](https://example.com/builders#/task/1276)): generates the `.claude/skills/` + `.claude/scheduled-tasks/` sections of docs/file-map.md from disk; per-entry notes come from docs/file-map.notes.json; `--check` fails on drift OR a skill/routine with no note (CI gate via fitness.js); regenerated on deploy by ship.js regenerateFileMap()
+│       ├── spike-task-map.js    ← (task 1003282, goal 1000072) the task-network-map spike harness: builds a ~1,357-task graph across a swept dependency density, lays it out for real (<redacted> + Barnes-Hut), counts what decides readability (isolated nodes, components, distinguishable marks / overplot, crossings, ink budget, payload) and renders PNGs with a hand-rolled encoder. Zero deps, no DB. `--from <tasks.json>` measures the REAL corpus instead of the model. Verdict: docs/research/task-network-map-readability.md
 │       ├── fitness.js           ← Path C (ADR 0062 §9, [#1225](https://example.com/builders#/task/1225)): architecture fitness functions — core↔host import boundary (zero grandfathered exceptions as of R52/#1191), CLAUDE.md budget + nested-doc presence (ADR 0061), no route bypasses rank checks (reuses route-rank-check), repo-map freshness. Enforced in CI via tests/fitness.mjs (the `unit` gate). `node scripts/gds/fitness.js`
 │       ├── ship.js              ← resolve claim as shipped, award credits (`/builder-ship`); also uploads a secret-scrubbed session digest to the corpus (6D.1, ADR 0027); on a dev box runs the sandbox-first review gate before resolving (#927, ADR 0046)
 │       ├── ship-visual.js       ← the OPTIONAL `--visual <image> [--visual-alt "…"]` leg of a ship (task 1003109): screens the file BEFORE the claim resolves (bad input costs no claim), uploads it AFTER (a failed picture never fails a ship)

package/docs/module-api-changelog.md

@@ -1373,5 +1373,7 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.466 with no explicit bump. run 33638703282. (task 1002620)
   1.19.468 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.467 with no explicit bump. run 33640370009. (task 1002620)
+  1.19.469 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.468 with no explicit bump. run 33643388774. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/docs/research/task-network-map-readability.md

@@ -0,0 +1,191 @@
+# Can a network map of ~1,357 tasks be read? — the spike
+
+- **Task:** [1003282](https://cloudbongos.com/builders#/task/1003282) · goal 1000072 (Human legibility)
+- **Date:** 2026-08-28
+- **Harness:** [`scripts/gds/spike-task-map.js`](../../scripts/gds/spike-task-map.js) — no dependencies, no network, no DB. Re-run with `node scripts/gds/spike-task-map.js`.
+- **Figures:** [`docs/research/task-network-map/`](task-network-map/) — rendered by the harness, not drawn by hand.
+
+## The answer
+
+**No — not as a map of tasks, at any dependency density, and the obvious fix makes it
+worse.** What *is* readable is the forty-node **goal** graph as the entry point, with a
+per-goal **dependency forest** as the drill-down. That second view is 3–40% of the
+corpus, never 100%, and that is the finding rather than a compromise: the tasks it
+leaves out are the ones with nothing to connect them to.
+
+The map worth building is therefore **not** "the task graph, zoomed out". It is the
+goal graph, drawn once, with a task-level view that opens *inside* a goal.
+
+## How it was measured
+
+The house rule for questions of this shape was set by this goal's own shipped criterion
+`legibility-sort-and-staleness`: *"~1,357 tasks on BONGOS-V1 alone. A view that does not
+survive that number is not a solution"* — answered in `tests/goal_sort_staleness.mjs` by
+**executing** the board pipeline over a corpus that size. A network map is the same
+question one dimension harder, so it got the same treatment: build the graph, lay it out
+with a real Fruchterman–Reingold pass (Barnes–Hut quadtree, θ=0.8 — the approximation
+d3-force uses), draw it to a real raster, and count.
+
+**The dependency density is swept, not guessed.** How many tasks actually declare a
+`task_dependencies` row is a fact of the live DB, which this environment cannot reach.
+Rather than assume one number, the harness sweeps p ∈ {2, 5, 10, 20, 40}% — the share of
+tasks declaring at least one dependency — and reports where each conclusion would flip.
+Every conclusion below holds across the whole range, which is why the missing fact does
+not change the verdict. Point the harness at a real dump to replace every number here
+with a measured one:
+
+```
+node scripts/gds/spike-task-map.js --from tasks.json     # a GET /tasks?include=deps dump
+```
+
+Four views of the same corpus, all at 1280×720 (a laptop viewport with the hall's chrome
+removed — quoting a 4K desktop would flatter the result for a screen most readers do not
+have):
+
+| | view | what it is |
+|---|---|---|
+| **A** | every task | the literal reading of "a network map of 1,300 tasks" |
+| **B** | tasks with a dependency | A with the unconnected nodes swept off |
+| **C** | goals | one node per goal, cross-goal dependencies aggregated |
+| **D** | tasks joined by goal | the obvious second attempt, once A turns out to be sparse |
+
+## The numbers
+
+```
+density   view                        nodes  edges  isol%  comps  marks  lost%     cross   pitch  label?     ms      KB
+------------------------------------------------------------------------------------------------------------------------
+p=2%      every task                   1357     21   97.2   1336   1355    0.1         0  26.1px      NO    861       6
+p=2%      tasks with a dependency        38     21      0     17     38      0         0 155.7px     yes     34       0
+p=2%      goals                          40      5     80     35     40      0         0 151.8px     yes     54       0
+any       tasks joined by goal         1357  22341      0     40    222   83.6  1492927~  26.1px      NO   1003     232
+p=5%      every task                   1357     44   94.1   1313   1352    0.4         1  26.1px      NO    855       6
+p=5%      tasks with a dependency        80     44      0     36     80      0         1 107.3px     yes     24       1
+p=5%      goals                          40      7   72.5     33     40      0         2 151.8px     yes      8       0
+p=10%     every task                   1357     81   89.7   1277   1351    0.4         2  26.1px      NO    818       6
+p=10%     tasks with a dependency       140     81      0     60    140      0         2  81.1px     yes     54       1
+p=10%     goals                          40     13   52.5     27     40      0         2 151.8px     yes      9       0
+p=20%     every task                   1357    168   79.2   1189   1336    1.5         5  26.1px      NO    884       7
+p=20%     tasks with a dependency       282    168      0    114    282      0         8  57.2px     yes    143       3
+p=20%     goals                          40     31   22.5     12     40      0        12 151.8px     yes      9       0
+p=40%     every task                   1357    351   59.5   1006   1320    2.7        33  26.1px      NO    897       9
+p=40%     tasks with a dependency       549    351      0    198    549      0        30    41px      NO    325       6
+p=40%     goals                          40     50    2.5      2     40      0        44 151.8px     yes     10       0
+```
+
+`marks` = distinct 7px cells any node lands in — what a reader can actually tell apart.
+`lost%` = share of nodes overplotting a mark another node already owns.
+`pitch` = √(canvas area ÷ nodes), the square each node owns. `label?` asks whether that
+square is as wide as a six-character label (48px).
+
+## What each row says
+
+### A — "every task" is confetti, not a hairball
+
+This is the surprise, and it is the whole result. A 1,357-node graph is *expected* to
+fail as a tangle: too many edges, too many crossings, one illegible ball of yarn. It
+fails the other way. **59.5% to 97.2% of tasks have no dependency at all**, so the
+picture is 1,006–1,336 separate components — overwhelmingly single dots — and **33
+crossings at the densest end**, which is nothing.
+
+![Every task, dependency edges, p=40% — the densest case measured](task-network-map/a-every-task-p40.png)
+
+That disc of 1,320 distinguishable dots with a few three-node chains in the middle is
+the *best* case in the sweep. Two things follow, and neither is fixable by drawing
+better:
+
+- **A force layout is arranging nothing.** It has no opinion about where a thousand
+  unconnected islands go, so their positions carry no information. Every dot's location
+  is an accident of the seed. A reader who infers anything from proximity here is being
+  misled by the renderer.
+- **Labels never fit.** 26.1px of pitch against the 48px a six-character label needs —
+  and that is the *average*, before clustering. So the map cannot say which task any dot
+  is, which means the only way to read it is to hover 1,357 times.
+
+Sparse-and-disconnected is a *different failure* from dense-and-tangled, and it needs a
+different answer. You cannot declutter your way out of it; there is no clutter.
+
+### D — making it dense draws the goal graph, badly
+
+The natural next move once A turns out sparse: connect tasks by something that actually
+relates them. Shared goal is the obvious candidate, and it is the one a "task network"
+would reach for.
+
+![Tasks joined by goal — 1,357 nodes and 22,341 edges](task-network-map/d-joined-by-goal.png)
+
+Forty dots. **22,341 edges, ~1.49 million crossings, 232 KB of graph, a full second of
+layout — and 83.6% of the nodes overplot, leaving 222 marks that read as forty.** Each
+goal is a clique, so each clique contracts to a blob smaller than the dot used to draw
+it, and every edge inside it is sub-pixel.
+
+The dense view spends three orders of magnitude more edges to draw, illegibly, the
+picture that view C draws legibly with fifty. That is not a tuning problem. It is the
+data saying that at this scale the only structure the eye can extract from 1,357 tasks
+**is** the forty goals.
+
+### C — the goal graph is readable, everywhere in the sweep
+
+![Goals, p=40%](task-network-map/c-goals-p40.png)
+
+Forty nodes, 5–50 edges, zero overplot, 151.8px of pitch — three times what a label
+needs — and it stays readable at every density measured. It is also the view the system
+already computes: `modules/lifecycle/goal-rollup.js` produces one row per goal in
+Postgres precisely because the browser could not hold the task corpus (5,229,455 bytes
+for ~1,400 tasks, measured 2026-08-25). **The readable map is the one whose data layer
+already exists.**
+
+At low density it has its own honest weakness — 80% of goals are isolated at p=2%,
+because cross-goal dependencies are what draw its edges. A goal graph with no edges is a
+legend, not a map. Which side of that line the live corpus falls on is the one number
+worth measuring before building.
+
+### B — the dependency forest is the drill-down
+
+![Tasks with a dependency, p=40% — 549 nodes](task-network-map/<redacted>.png)
+
+Sweeping the isolated nodes off A leaves 38–549 nodes and zero overplot, readable with
+labels up to p=20% and as unlabelled dots beyond. This is the task-level view that
+works, and it works *because* it does not try to show every task.
+
+Note what it costs: at p=40% it still fails the label test (41px pitch), so even the
+forest wants scoping. Per goal it is 1–14 nodes — comfortably readable, and the natural
+thing to open when someone clicks a goal in C.
+
+## What to build, if anything
+
+1. **The goal graph (C) as the map.** Forty nodes, edges = cross-goal dependencies,
+   weight = task count, colour = the ADR 0192 category the goals already carry. Its data
+   is one `goalRollups` query plus a cross-goal dependency count; the payload is bytes,
+   not megabytes.
+2. **The dependency forest (B), scoped to one goal, as the drill-down.** Not a zoom of a
+   global map — a separate, small query answered when a goal is opened.
+3. **Never view A, and never view D.** Not as a default, not as an "advanced" toggle.
+   A shows a thousand dots whose positions are noise; D shows forty dots and calls it a
+   thousand. Both invite a reader to believe they are seeing structure that is not there,
+   which is a worse outcome than no map — this goal is about legibility, and a confident
+   picture of nothing is the opposite of it.
+
+**Before any of it is built, measure the real density**, with `--from`. Two numbers
+decide the shape: the share of tasks carrying a dependency (does B have anything in it?)
+and the share of dependencies that cross a goal boundary (does C have any edges?). If
+cross-goal dependencies are near zero, C is forty disconnected dots and the honest
+deliverable is a grid of goal cards, not a graph — which the hall's Goals page already
+is. **That is a real possible outcome of this spike, and it would mean the right amount
+of new map to build is none.**
+
+## Caveats, stated plainly
+
+- **The corpus is synthetic.** The live DB is unreachable from the environment this ran
+  in, so the harness sweeps a plausible range instead of measuring 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. Re-run with `--from`.
+- **The goal count (40) and the 85% within-goal edge preference are modelled**, from the
+  repo's own record of ~38 open goals on BONGOS-V1 (`scripts/gds/goal-names.js`) and from
+  how dependencies are declared in practice. A very different real distribution would
+  change C's edge count — not A's isolation, which is bounded by p by construction.
+- **`marks` is a proxy for legibility, not legibility.** It counts what is
+  *distinguishable*, not what is *understandable*; a map can clear it and still say
+  nothing. It is used here only to make overplotting a number, which is the one thing
+  looking at a picture reliably fails to do.
+- **The layout is one algorithm.** A hierarchical or Sugiyama-style layout would draw
+  view B's chains better than a force pass does. It would not change A (there is nothing
+  to lay out) or D (the overplotting is arithmetic, not layout).

package/modules/hall-ui/public/people.css

@@ -1,6 +1,7 @@
 /* people.css — page-local styles for the cross-project builder directory
-   (task 1003470, goal 1000081), served at /people and at its legacy door
-   /scouting, which loads the same page. Only the identity cell lives here: the
+   (task 1003470, goal 1000081), served at /people — its legacy door /scouting
+   was deleted in task 1003440 and now 301s here. Only the identity cell lives
+   here: the
    ledger, the filter bar, the pager, the chips and the empty state are the
    shell's and the kit's. Tokens are the world's real names — no compat alias. */
 

package/modules/hall-ui/public/people.html

@@ -30,8 +30,8 @@
       </div>
 
       <main id="hall-main">
-        <!-- task 1003470: ONE directory. /people and its legacy door /scouting
-             render this same page from the same script — the same
+        <!-- task 1003470: ONE directory. Its legacy door /scouting rendered this
+             same page from the same script, and task 1003440 deleted it — the same
              /api/gds/scouting rollup used to be drawn three different ways. -->
         <section class="scroll" id="people-scroll" aria-labelledby="people-h">
           <h2 id="people-h" class="scroll__h">Builder directory<span class="count-pill" id="people-count" hidden></span></h2>

package/modules/hall-ui/public/people.js

@@ -1,10 +1,11 @@
 // people.js — the People page: the cross-project builder directory (task
-// 1002577; ADR 0141 §4 is the data's design of record), served at /people and
-// at its legacy door /scouting — task 1003470 made the two ONE page, this
-// script, because the same /api/gds/scouting rollup was being drawn three
+// 1002577; ADR 0141 §4 is the data's design of record), served at /people —
+// task 1003470 first made its legacy door /scouting render this same script,
+// and task 1003440 deleted that door (the URL 301s here), because the
+// same /api/gds/scouting rollup was being drawn three
 // different ways (a kit ledger here, a hand-built table there, and the same
 // columns in a different order). The endpoint is gated server-side on
-// 'project.curate' OR being a project owner (R14, ADR 0210); both pages are
+// 'project.curate' OR being a project owner (R14, ADR 0210); this page is
 // gated in serve-internal.js on that same pair, so a visitor who is neither
 // never sees this shell.
 //

package/modules/hall-ui/public/people.states.json

@@ -1,5 +1,5 @@
 {
-  "_": "People — the cross-project directory behind requireProjectCuratePage (metic+ via project.curate, or a project owner). Descriptive only; it grants no authority, and the page says so above the fold. Written with the re-skin (task 1003307); the redesign (task 1003470) added the identity cell, the sort and craft lenses, and the `search` state. /scouting is the legacy door to this same page (scouting.states.json measures it separately). Populated look: the hall-preview harness (scripts/hall-preview/fixtures/scouting.json carries five builders, three with avatars).",
+  "_": "People — the cross-project directory behind requireProjectCuratePage (metic+ via project.curate, or a project owner). Descriptive only; it grants no authority, and the page says so above the fold. Written with the re-skin (task 1003307); the redesign (task 1003470) added the identity cell, the sort and craft lenses, and the `search` state. Its legacy door /scouting was deleted in task 1003440; the URL 301s here. Populated look: the hall-preview harness (scripts/hall-preview/fixtures/scouting.json carries five builders, three with avatars).",
   "page": "/builders/people",
   "surface": "hall-ui",
   "stub": {

package/modules/hall-ui/public/settings.js

@@ -555,7 +555,7 @@
   // GET/PATCH /api/bongos/me/cross-project (platform-identity module — hub only).
   // One on/off toggle: "show my cross-project record on my public profile".
   // Enforcement is server-side in the module's read functions, so flipping it
-  // takes effect immediately on the profile, /people, and /scouting. The section
+  // takes effect immediately on the profile and /people. The section
   // reveals ONLY when the module's endpoint answers (404 on a vanilla instance →
   // stays hidden, no error state). P04 later re-homes this in the Profile rail
   // group; storage is account-global on the hub (not behavior_prefs).

package/modules/hall-ui/public/style.css

@@ -2859,9 +2859,10 @@ main [id] { scroll-margin-top: calc(var(--topbar-h) + 16px); }
    does not exist, so "Someone helped" rendered full-size on every row. */
 .btn--sm { min-height: 26px; padding: 0 11px; font-size: 12.5px; }
 
-/* people.js:45 — the builder's name cell. The only definition in the hall lives
-   in scouting.html's inline <style>, so the same data read bold on Scouting and
-   plain on People. One definition, both pages. */
+/* people.js:45 — the builder's name cell. The hall's only definition used to
+   live in scouting.html's inline <style>, so the same data read bold on
+   Scouting and plain on People. It lives here now, and scouting.html itself
+   went with task 1003440. */
 .who { font-weight: 600; }
 
 /* people.js:105 — notice() sets body.className='note'. .note lives in

package/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.468",
+  "version": "1.19.469",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.468",
+      "version": "1.19.469",
       "license": "AGPL-3.0-or-later",
       "dependencies": {
         "express": "^4.21.2",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.468",
+  "version": "1.19.469",
   "description": "Cloud Bongos — the AI-first build platform core (GDS + platform surfaces + module system), installed as a versioned dependency (ADR 0108).",
   "license": "AGPL-3.0-or-later",
   "main": "src/platform-server.js",