@bongos/core 1.19.469 → 1.19.471

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.469",
-  "core_contract": "1.19.469",
-  "source_commit": "4ebfd4f9703e666d920948608912e842cf3bbd8a",
+  "core_version": "1.19.471",
+  "core_contract": "1.19.471",
+  "source_commit": "d001dec252ae168f7579878b56235836287043b2",
   "source_ref": "HEAD",
-  "built_at": "2026-09-02T14:39:17.041Z",
+  "built_at": "2026-09-02T14:57:21.318Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 410,
+    "docs_redacted": 411,
     "agent_docs_stubbed": 24,
-    "functional_verbatim": 1830,
+    "functional_verbatim": 1833,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2264,
-  "tree_sha256": "5de5a57136ff2ae1d72ee1185ba98ddb524ca2748250f3acef9feba01a967668",
+  "file_count": 2268,
+  "tree_sha256": "c11bd5934d037a6d54010a5392df908dcc5965abd13817a89fd5a14ced8be5f6",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -382,7 +382,7 @@
     {
       "path": "clients/bongos-client/index.d.ts",
       "mode": "0000644",
-      "sha256": "2bce52b8070cda294371da71931bc7edde4fe431d99f06221d31c23d083e74d7"
+      "sha256": "6e1ae5c410c8796df7efcdcd9cbd0ccebe1075da8bc18d503c50196d0e7db683"
     },
     {
       "path": "clients/bongos-client/index.mjs",
@@ -1634,6 +1634,11 @@
       "mode": "0000644",
       "sha256": "f9f3a0b8ebe2d161e17e1c632bbbda71842c9476958294330420f28c6301f7db"
     },
+    {
+      "path": "docs/adr/0226-one-stale-timer-reporting-degrades-enforcement-refuses.md",
+      "mode": "0000644",
+      "sha256": "a3a854a3d04095c04abbe31239aa9931a482a6720d4a04077481e08d6deb6845"
+    },
     {
       "path": "docs/adr/0227-a-task-network-map-is-refused-the-goal-graph-is-the-map.md",
       "mode": "0000644",
@@ -1642,7 +1647,7 @@
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "4c6f66d10d34f4c1c1e0ab6376868281b87e28a9f3b16ccfb75fafc004dcf8e2"
+      "sha256": "93a49ca61bb1ea3e3bf9c3325bcae8b174278c8504fb1cc993c03d87bb6ba2f5"
     },
     {
       "path": "docs/api-reference.md",
@@ -1652,7 +1657,7 @@
     {
       "path": "docs/api/openapi.json",
       "mode": "0000644",
-      "sha256": "1e2b837a69669de3f76f189b3b868dbfc67c41cb7a5bbd773b465fa82a4e0cb2"
+      "sha256": "fa675542b54c8bbd96530ecaac630deaf9873cc9091714eb9fde660e5af2ad4e"
     },
     {
       "path": "docs/architecture.md",
@@ -1677,12 +1682,12 @@
     {
       "path": "docs/copy-inventory.md",
       "mode": "0000644",
-      "sha256": "c8fef1f6767e30c55da1c2cc229ad13358468d663e55135c78dae0f2dd19d9ec"
+      "sha256": "7726b8ee862ebd75d1a95fafa9a5fb13993b4ad79bacba17f6e401e950082be4"
     },
     {
       "path": "docs/copy-registry.json",
       "mode": "0000644",
-      "sha256": "fac4ade86832f3b7a047946da16c5c185b5aa2d0cfe784a93de1c70add5882ce"
+      "sha256": "34b21e7e0c7135f4a20cc821174fc2e05ccfee4aa3691855197aa3356356e308"
     },
     {
       "path": "docs/design/apex-pass-2-direction.md",
@@ -2132,7 +2137,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "107a6f32f688e387ec1d51d929df4bbadcb897e9993ed647171dc6c0aa4525e9"
+      "sha256": "8ce1c73b94d8342cc8b9eadfab359c9feea250b74587b58b70055e671a29388c"
     },
     {
       "path": "docs/modules-contract.md",
@@ -3992,22 +3997,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",
@@ -4322,22 +4327,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",
@@ -4547,7 +4552,7 @@
     {
       "path": "modules/hall-ui/public/style.css",
       "mode": "0000644",
-      "sha256": "06be0a11ea5573e28c6baf25d38e7eb6b7a9f054942dfc0ebc7a2ac125376bba"
+      "sha256": "9bb44b2d5ad45342ebee328430c793d0e48ce921362e87501002a5c73fbe71c9"
     },
     {
       "path": "modules/hall-ui/public/task-detail.js",
@@ -4557,7 +4562,7 @@
     {
       "path": "modules/hall-ui/public/task-lib.js",
       "mode": "0000644",
-      "sha256": "dde9fe5cc1d80829c45aa6ef4f486697345a122cf0a7054991b7c7ebc390754f"
+      "sha256": "3efb1199b1fc3c979b1c3aaa23d817241b48104dd1dfd40cbc20ed80b1a971cc"
     },
     {
       "path": "modules/hall-ui/public/task.css",
@@ -4782,7 +4787,7 @@
     {
       "path": "modules/lifecycle/db-ship.js",
       "mode": "0000644",
-      "sha256": "0a313d9c20cc0da5952e3a5acbca83cd1fd3df7ecccbbd109701d865b4dd2fe6"
+      "sha256": "d300392b7bf802d00ae79c55ad3b0d9413dc9bb56e7e1105f49656b39abb874a"
     },
     {
       "path": "modules/lifecycle/db-tasks.js",
@@ -6227,7 +6232,7 @@
     {
       "path": "modules/sessions/pulse.js",
       "mode": "0000644",
-      "sha256": "0f9f0a412b4560dd20bc3e15d8160d991b276f5e3a6e2ba3b752a322bef78e4c"
+      "sha256": "50e7009581961fc1c29cfead85f8d4278e948bfc2a43d5c6b3eaf4e7821ca1af"
     },
     {
       "path": "modules/sessions/routes/sessions.js",
@@ -6662,12 +6667,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "78b081005f7f38ddfd05d2f6f045ea3d9a7a74b43f91985819cc4e4989bca548"
+      "sha256": "df5e2bd3061c2af6b8838339eb4deddc9704c971486718b28b95ebe50d57e9e6"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "562c6f06e56963c7e49bc2b2c0d56c76d5129d471805e87732e21f7f58d4dae5"
+      "sha256": "ec979bb66bae8d6426a0dfe844c4e7b5e623970a8a0fddf86dcf1f6585f56a35"
     },
     {
       "path": "public-docs/index.html",
@@ -7097,7 +7102,7 @@
     {
       "path": "scripts/gds/fitness.js",
       "mode": "0000644",
-      "sha256": "ec823ee34e55318a1bee8008658fe44c24158e43a3736065312ae931d0bab796"
+      "sha256": "a7322e6d2510bee2780ca76c68a1c46e7d771cd6675b5f4c223adcf8e001a6c5"
     },
     {
       "path": "scripts/gds/gate-review.js",
@@ -7447,7 +7452,7 @@
     {
       "path": "scripts/gds/pulse.js",
       "mode": "0000644",
-      "sha256": "0165d2b4c0f48e59f506e43ea0c8252fed81f2799aa14df0c4624097322dd636"
+      "sha256": "21cf8741c5e046f61fbe94164d348d476f41bd45cac62c72609580032b1244ba"
     },
     {
       "path": "scripts/gds/push-main.js",
@@ -8217,7 +8222,7 @@
     {
       "path": "src/bongos/routes/builders.js",
       "mode": "0000644",
-      "sha256": "dc71324e4a1357f86b7e5a66c64ca5b38a2c79ef58c6d7a6f7337a23cfa1ee60"
+      "sha256": "0d27bd6e4db13e9aae324efab98829480fed43abe615c5c56d8e707c6a3465d3"
     },
     {
       "path": "src/bongos/routes/github.js",
@@ -8322,7 +8327,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "e9d0e0cc580123c2f593e84c39889bb08bcc88407ac5cd4ab3a546b6ceaf02a5"
+      "sha256": "abdfc62aa930c361942dfa5aeb9cc8172a20a14ef3ac575bff5d1891f34f96e4"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -8364,6 +8369,11 @@
       "mode": "0000644",
       "sha256": "4ba8c3b2e17c2faa38a872fe679e0dc7d032e79e05eb7277d76736201311dcdd"
     },
+    {
+      "path": "src/stale-timer.js",
+      "mode": "0000644",
+      "sha256": "2e46d071e5c61d302f34507215dd0a5f20a0887841ae0f7b033be865c2cb8af5"
+    },
     {
       "path": "tests/abandon_task.mjs",
       "mode": "0000644",
@@ -9694,6 +9704,11 @@
       "mode": "0000644",
       "sha256": "bb66cec6b745cd6e50efd8828d05a75aa68fbc50ed43d8a49988c1246bfd3324"
     },
+    {
+      "path": "tests/hall_catalog_world.mjs",
+      "mode": "0000644",
+      "sha256": "79c8759cbb0d17477139acae6e0057caa70021ff0edfeba9c419c14ad729a1ac"
+    },
     {
       "path": "tests/hall_collab_world.mjs",
       "mode": "0000644",
@@ -10187,7 +10202,7 @@
     {
       "path": "tests/module_api.mjs",
       "mode": "0000644",
-      "sha256": "9b2394ce72e74a96460c6d9ef1cc2ee280dded85523fae2979d56a49fb514b85"
+      "sha256": "a4980667646d3a3dda1a67906d0735d8acf462989de937e3d342461b275e74eb"
     },
     {
       "path": "tests/module_catalog.mjs",
@@ -10297,7 +10312,7 @@
     {
       "path": "tests/onboarding_observability.mjs",
       "mode": "0000644",
-      "sha256": "2423b4de9df54cfe2d127d8b3983b05f8e5ec7c15f7b325b6e81931d31a51061"
+      "sha256": "973847bd475916e1418a8c70ff9c0f2a1186d55c31e0e8ba4f8b24fabb4c35dc"
     },
     {
       "path": "tests/onboarding_route_signals.mjs",
@@ -11074,6 +11089,11 @@
       "mode": "0000644",
       "sha256": "27bd2a87e001eec2bc58e13cfa58e53f88c73ebe7504b944c718182247d98ca7"
     },
+    {
+      "path": "tests/stale_timer.mjs",
+      "mode": "0000644",
+      "sha256": "770fb94ecdb37da2f7cf74b95d734b789cbbbd5414a97ae5275089302064a71d"
+    },
     {
       "path": "tests/stale_worktrees.mjs",
       "mode": "0000644",

package/clients/bongos-client/index.d.ts

@@ -31,12 +31,12 @@ export interface GetBoxSshKeyResponse { keys: unknown }
 export interface GetBoxTerminalResponse { state: unknown; url: unknown; credential: unknown; hint: unknown; warming_up?: boolean; terminal_at?: unknown }
 export interface GetBoxesResponse { boxes: unknown }
 export interface GetBuildersDirectoryResponse { builders: unknown }
-export interface GetBuildersIdActiveClaimsResponse { builder_id: unknown; claims: unknown; stale_hours: unknown }
+export interface GetBuildersIdActiveClaimsResponse { builder_id: unknown; claims: unknown; stale_hours: unknown; stale_hours_source: unknown }
 export interface GetBuildersIdActivityResponse { builder_id: unknown; section: unknown; role: unknown; rows: unknown; total: unknown }
 export interface GetBuildersIdOnboardingResponse { builder_id: unknown; onboarding: unknown }
 export interface GetBuildersIdProfileResponse { builder: unknown; shipped_count: unknown; recent_ships: unknown; achievements: unknown; cross_project?: unknown; handle?: unknown }
 export interface GetBuildersMePendingRankChangeResponse { change: unknown; greeting?: unknown }
-export interface GetBuildersRosterResponse { builders: unknown; stale_hours: unknown }
+export interface GetBuildersRosterResponse { builders: unknown; stale_hours: unknown; stale_hours_source: unknown }
 export interface GetClosenessForMeResponse { closeness: unknown; count: unknown }
 export interface GetClosenessWeightsResponse { weights: unknown; window_days: unknown; note: unknown }
 export interface GetClosenessWithBuilderIdResponse { closeness: unknown; why: unknown }

package/docs/adr/0226-one-stale-timer-reporting-degrades-enforcement-refuses.md

@@ -0,0 +1,121 @@
+# 0226 — One stale-claim timer; reporting degrades where enforcement refuses
+
+- **Status:** Accepted
+- **Date:** 2026-08-28
+- **Tasks:** [#1003476](https://cloudbongos.com/builders#/task/1003476)
+- **Goal:** [#1000072](https://cloudbongos.com/builders#/goal/1000072) — Human legibility, criterion `legibility-sort-and-staleness`.
+- **Builds on:** [#1003278](https://cloudbongos.com/builders#/task/1003278), which gave both work boards a shared *task* staleness vocabulary and left this one — the *claim* timer — named in a comment as the thing still to wire.
+- **Split out of:** [#1003279](https://cloudbongos.com/builders#/task/1003279) on 2026-09-02. This work was authored under that task’s claim, but it answers a different question than that task’s DONE WHEN: 1003279 is the needs-attention **inbox item** a stale *goal or task* raises (with the verbs prune / kill / prioritise / water), and §4 below records that the *task* staleness buckets and a settings knob were deliberately **rejected** as out of scope here. It ships under its own task so the ledger says what the diff does; 1003279 stays open for its inbox half.
+
+## 1. The problem: one question, four answers, none of them the project's
+
+"How long may a claim go silent before this project calls it abandoned" was
+answered independently in four places:
+
+| Surface | Number | Where it came from | What it does |
+|---|---|---|---|
+| `scripts/gds/pulse.js --release-stale` | **6h** | `GDS_STALE_CLAIM_HOURS`, else a literal `6` | **acts** — releases the claim, stamps the session log `[auto-released:stale]`, returns the task to `ready`, pings the builder |
+| `GET /builders/roster` → `getBuildersRoster` | **24h** | a literal, twice (route and db helper) | **reports** — the `stale_claim` flag on the Archon roster |
+| `GET /builders/:id/active-claims` → `<redacted>` | **24h** | a second, byte-identical literal | **reports** — which claim to target for release |
+| `sweepStaleClaims` / `getStaleClaimsForBuilder` | **30 min** | a default parameter | whatever an argument-less caller wanted |
+
+The 6-vs-24 pair is the one that hurt. The roster is the screen an Archon opens
+to decide whether to intervene, and for **eighteen hours** after the sweeper had
+already released a claim, tagged it and handed the task back to the queue, that
+screen still showed it healthy. Neither file is wrong when read alone — the
+roster's own comment even says it "mirrors the threshold the stale-claim-release
+sweeper uses", which was true of the *definition* and false of the *number*. A
+mirror that copies the shape and not the value is worse than no mirror: it reads
+as a guarantee.
+
+This is the shape goal 1000072 exists to close. A person steering an AI-run
+project is steering by what the surfaces tell them, so a surface that reports a
+different rule from the one the machine enforces is not a cosmetic defect.
+
+## 2. Decision
+
+**One resolver owns the timer, and every surface that reports or enforces
+staleness reads it.** `src/stale-timer.js` — a KERNEL file, in the same category
+as `instance-config.js` and `branding.js`: host configuration a module reads
+rather than hardcodes. Exposed to modules through the doorway
+(`api.resolveStaleClaimHours`), required directly by core routes and by the CLI.
+
+Precedence, widest scope last:
+
+1. **An explicit override** — `--threshold-hours`, `?stale_hours=N`. A *lens*, not
+   a reconfiguration: an Archon asking "what would 48h show me?" must not change
+   what the project does, and the response labels the answer `query` so the
+   distinction survives into the payload.
+2. **`<PREFIX>_STALE_CLAIM_HOURS`** — the project's configured timer, resolved
+   through `instance-config.resolveEnv`, whose legacy prefix chain still honours
+   the `GDS_STALE_CLAIM_HOURS` the live sweeper has always read. **Nothing in a
+   running deployment has to change for this to resolve to what it resolves to
+   today.** This is also the channel a platform-managed project already has: the
+   provisioning runner patches `web.env` in place and restarts ([ADR 0190](<redacted>.md)).
+3. **`6`** — the default. Deliberately the *sweeper's* historical number and not
+   the roster's 24: the sweeper is the surface that acts, and adopting 24 would
+   have quietly made every project three times more patient with a dead claim
+   while looking like a tidy-up.
+
+The bound is **1..720 hours** — not taste: `GET /builders/roster` has published
+`1..720` as its `stale_hours` contract since V3.R14, and one timer means one
+bound. (Sub-hour values were previously accepted by that route despite the
+published range; they are now rejected, consistent with what it always claimed.)
+
+**Every surface that prints the timer prints where it came from.** The sweep
+header and the auto-release note carry the source; both roster reads return
+`stale_hours_source`. A number with no provenance is precisely what let 6 and 24
+sit side by side in the ops log for a year.
+
+## 3. The part that is not obvious: the fail posture is asymmetric
+
+A misconfigured timer must not silently become a different policy. But the two
+kinds of caller cannot want the same thing from a bad value, so the resolver
+**reports** rather than throws, and each caller states its own posture:
+
+- **Reporting degrades.** A read-only surface takes the default and labels the
+  source `default (invalid <VAR>="…": …)`. A 500 here would take down the roster
+  an Archon opened *to find the problem*, and hide the typo behind an error page;
+  answering with the default and naming the bad value puts it on the screen of
+  the one person who can fix it.
+- **Enforcement refuses.** The sweep declines to run at all. It releases other
+  people's claims and stamps their session logs, and no reload undoes that — so
+  "probably 6" is not an answer it is allowed to give. An explicit
+  `--threshold-hours` that is unusable is likewise a usage error, as before.
+
+Stated as a rule: **a surface that only reads may guess and say so; a surface
+that acts may not guess.**
+
+## 4. What was rejected
+
+- **A new `config/stale.json` pair.** The env route already *is* the per-project
+  channel (the runner writes `web.env`), and a config file would have added a
+  fourth tier to a precedence whose whole point is that there is one place to
+  look.
+- **Making the roster's 24 the shared default.** It is the number nothing acted
+  on. Unifying on it changes real behaviour under cover of a refactor.
+- **Throwing from the resolver.** It would have forced the roster to either 500
+  or re-implement the fallback, which is a second reader — the original bug.
+- **Folding in the boards' 14/30/60-day task buckets.** A different question:
+  those are *days*, about a *task* going untouched, and they are a browsing lens
+  with no enforcement behind them. Two questions may have two vocabularies; only
+  one of them may be a number typed twice.
+- **A DB row + settings UI for the timer.** A reasonable next step, and out of
+  scope here: the defect was four numbers, not the absence of a knob. Adding a
+  row before the readers agreed would have produced a fifth.
+
+## 5. Consequences
+
+- `GET /builders/roster` and `GET /builders/:id/active-claims` gain
+  `stale_hours_source`; their default `stale_hours` changes from `24` to the
+  project timer (`6` unless configured). Additive to the payload; the default is
+  a **deliberate** behaviour change — it is the fix.
+- Both routes now share one `staleHoursFor(req, res)` helper. Two copies of a
+  literal is how the drift happened twice in one file.
+- `sweepStaleClaims` / `getStaleClaimsForBuilder` no longer have a number of
+  their own; an argument-less call means the project's timer, resolved per call
+  so an env change lands on the next sweep and not the next restart.
+- Pinned by `tests/stale_timer.mjs` (the resolver executed, the sameness of every
+  surface asserted, and both fail postures) plus the updated roster assertions in
+  `tests/onboarding_observability.mjs` — whose old `stale_hours === 24` line *was*
+  the eighteen-hour lie, written down as an expectation.

package/docs/adr/README.md

@@ -313,5 +313,6 @@ This keeps the decision history honest and traceable.
 | 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 |
+| 0226 | [**One stale-claim timer; reporting degrades where enforcement refuses** ([task 1003476](https://cloudbongos.com/builders#/task/1003476), goal 1000072, criterion `legibility-sort-and-staleness`). "How long may a claim go silent" had FOUR answers and none of them was the project's: the sweeper that actually releases a claim read `GDS_STALE_CLAIM_HOURS` (else 6h); `GET /builders/roster` and `GET /builders/:id/active-claims` each hardcoded 24h in byte-identical blocks; and the two `session_pulses` helpers defaulted to 30 minutes. The 6-vs-24 pair is the harm: the roster is the screen an Archon opens to decide whether to intervene, and for **eighteen hours** after the sweeper had released a claim, stamped its session log `[auto-released:stale]` and returned the task to `ready`, that screen still showed it healthy — while the roster's own comment claimed to "mirror" the sweeper, true of the definition and false of the number. Decision: ONE resolver, `src/stale-timer.js` (a KERNEL file, the `instance-config.js`/`branding.js` category — host config a module reads, never hardcodes), reached by modules through the doorway and by core routes and the CLI directly. Precedence: explicit override (`--threshold-hours`, `?stale_hours=` — a LENS, labelled `query`, never a reconfiguration) → `<PREFIX>_STALE_CLAIM_HOURS` via `instance-config.resolveEnv`, whose legacy prefix chain still honours the live `GDS_STALE_CLAIM_HOURS` so **nothing in a running deployment has to change** (and which is the channel ADR 0190's runner already patches into `web.env`) → **6**, the SWEEP's historical number and deliberately not the roster's 24, because the sweep is the surface that acts and unifying on 24 would have made every project three times more patient with a dead claim under cover of a refactor. Bound 1..720h — the range `/builders/roster` has published since V3.R14; one timer, one bound. Every surface that prints the timer prints its PROVENANCE (`stale_hours_source`, the sweep header, the auto-release note): a number without it is exactly what let 6 and 24 coexist unnoticed. **The fail posture is asymmetric and that is the decision**: the resolver reports an unusable value rather than throwing, then a surface that only READS degrades to the default and names the bad var (500-ing the roster an Archon opened to find the problem would hide the problem), while the SWEEP refuses to run at all (it releases other people's claims and stamps their logs; no reload undoes that) — a surface that only reads may guess and say so, a surface that acts may not guess. Both routes now share one `staleHoursFor(req, res)`; two copies of a literal is how the drift happened twice inside one file. Rejected: a new `config/stale.json` tier (the env route already IS the per-project channel); making 24 the shared default; throwing from the resolver (forces a second reader — the original bug); folding in the boards' 14/30/60-DAY task buckets (a different question — days, about a task, a browsing lens with no enforcement behind it); a DB row + settings UI (a reasonable next step, but the defect was four numbers, not a missing knob — a row added before the readers agreed would have been a fifth).](<redacted>.md) | GDS / claims + ops |
 
 > ⚠️ **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.

package/docs/api/openapi.json

@@ -2591,7 +2591,7 @@
           "builders"
         ],
         "summary": "GET /builders/roster",
-        "description": "GET /builders/roster — V3.R14 (task 238) onboarding observability. Archon-only roster of every builder with their identity + onboarding signals + active-claim posture. Powers the management panel in the /builders hall so the Archon can promote / demote / release-stale-claim without dropping into psql. Optional query param: ?stale_hours=N (default 24). Defines what counts as \"stale\" for the per-row stale_claim flag — mirrors the threshold the stale-claim-release sweeper uses but exposed as a roster knob so the Archon can dial it in if needed. rank: archon — surfaces every builder's onboarding state. Gate: requirePermission('builder.roster.read') — BV1.R104; the same atom /grades/by-builder and /builders/:id/active-claims already gate on (ADR 0151).\n\n**Rank:** `metic+archon` — Metic or Archon rank (review/triage powers).\n\n**Permissions:** `builder.roster.read` (all required).",
+        "description": "GET /builders/roster — V3.R14 (task 238) onboarding observability. Archon-only roster of every builder with their identity + onboarding signals + active-claim posture. Powers the management panel in the /builders hall so the Archon can promote / demote / release-stale-claim without dropping into psql. Optional query param: ?stale_hours=N. Defines what counts as \"stale\" for the per-row stale_claim flag. The DEFAULT is the project's configured stale-claim timer (task 1003476, goal 1000072) — literally the number the sweeper releases on, not a lookalike: this route defaulted to a hardcoded 24 while the sweeper acted at 6, so the Archon's screen called a claim healthy for eighteen hours after the machine had already taken it away. The param stays as a LENS (\"what would 48h show me?\"), and the response reports both the number and where it came from so the two can never quietly diverge again. rank: archon — surfaces every builder's onboarding state. Gate: requirePermission('builder.roster.read') — BV1.R104; the same atom /grades/by-builder and /builders/:id/active-claims already gate on (ADR 0151).\n\n**Rank:** `metic+archon` — Metic or Archon rank (review/triage powers).\n\n**Permissions:** `builder.roster.read` (all required).",
         "x-rank": "metic+archon",
         "x-source": "src/bongos/routes/builders.js",
         "x-permissions": [
@@ -15830,12 +15830,14 @@
         "properties": {
           "builder_id": {},
           "claims": {},
-          "stale_hours": {}
+          "stale_hours": {},
+          "stale_hours_source": {}
         },
         "required": [
           "builder_id",
           "claims",
-          "stale_hours"
+          "stale_hours",
+          "stale_hours_source"
         ]
       },
       "GetBuildersIdActivityResponse": {
@@ -15897,11 +15899,13 @@
         "type": "object",
         "properties": {
           "builders": {},
-          "stale_hours": {}
+          "stale_hours": {},
+          "stale_hours_source": {}
         },
         "required": [
           "builders",
-          "stale_hours"
+          "stale_hours",
+          "stale_hours_source"
         ]
       },
       "GetClosenessForMeResponse": {