@bongos/core 1.19.714 → 1.19.724

package/clients/bongos-client/README.md

@@ -5,7 +5,7 @@ A **generated**, zero-dependency typed client for the Bongos API — produced fr
 by hand; it regenerates when the spec changes, so it can never drift from the routes.
 
 - API version: **v1** (served at `/api/bongos/v1`)
-- 372 operations across 57 resource groups
+- 373 operations across 58 resource groups
 
 ## Use it from your project
 

package/clients/bongos-client/bongos-client.global.js

@@ -126,6 +126,10 @@ function createClient(opts = {}) {
       // GET /analytics/builder/{id} — rank: any-builder — GET /analytics/builder/:id
       getAnalyticsBuilderId: (args) => request("GET", "/analytics/builder/{id}", { hasBody: false }, args),
     },
+    "artistGate": {
+      // GET /artist-gate — rank: any-builder — GET /artist-gate
+      getArtistGate: (args) => request("GET", "/artist-gate", { hasBody: false }, args),
+    },
     "auditLog": {
       // GET /audit-log — rank: metic+archon — GET /audit-log
       getAuditLog: (args) => request("GET", "/audit-log", { hasBody: false }, args),

package/clients/bongos-client/index.cjs

@@ -125,6 +125,10 @@ function createClient(opts = {}) {
       // GET /analytics/builder/{id} — rank: any-builder — GET /analytics/builder/:id
       getAnalyticsBuilderId: (args) => request("GET", "/analytics/builder/{id}", { hasBody: false }, args),
     },
+    "artistGate": {
+      // GET /artist-gate — rank: any-builder — GET /artist-gate
+      getArtistGate: (args) => request("GET", "/artist-gate", { hasBody: false }, args),
+    },
     "auditLog": {
       // GET /audit-log — rank: metic+archon — GET /audit-log
       getAuditLog: (args) => request("GET", "/audit-log", { hasBody: false }, args),

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

@@ -23,6 +23,7 @@ export interface GetAchievementsResponse { achievements: unknown }
 export interface GetAgentRunsIdResponse { ok: boolean; run: unknown }
 export interface GetAgentsNameResponse { ok: boolean; agent: unknown }
 export interface GetAgentsResponse { ok: boolean; agents: unknown; counts: unknown; vocabulary: unknown }
+export interface GetArtistGateResponse { ok: boolean; mode: unknown; since: unknown; holds: boolean; truncated: unknown; reviews: unknown; halt: unknown }
 export interface GetAuditLogResponse { rows: unknown; page: unknown }
 export interface GetAuthAppPairInfoResponse { pair_code: unknown; device_name: unknown; platform: unknown; status: unknown }
 export interface GetAuthWebAdmissionStatusResponse { admitted: boolean }
@@ -470,6 +471,10 @@ export interface BongosClient {
     /** GET /analytics/builder/{id} — rank: any-builder */
     getAnalyticsBuilderId(args?: RequestArgs): Promise<ApiResponse>;
   };
+  "artistGate": {
+    /** GET /artist-gate — rank: any-builder */
+    getArtistGate(args?: RequestArgs): Promise<GetArtistGateResponse>;
+  };
   "auditLog": {
     /** GET /audit-log — rank: metic+archon */
     getAuditLog(args?: RequestArgs): Promise<GetAuditLogResponse>;

package/clients/bongos-client/index.mjs

@@ -122,6 +122,10 @@ export function createClient(opts = {}) {
       // GET /analytics/builder/{id} — rank: any-builder — GET /analytics/builder/:id
       getAnalyticsBuilderId: (args) => request("GET", "/analytics/builder/{id}", { hasBody: false }, args),
     },
+    "artistGate": {
+      // GET /artist-gate — rank: any-builder — GET /artist-gate
+      getArtistGate: (args) => request("GET", "/artist-gate", { hasBody: false }, args),
+    },
     "auditLog": {
       // GET /audit-log — rank: metic+archon — GET /audit-log
       getAuditLog: (args) => request("GET", "/audit-log", { hasBody: false }, args),

package/config/branding.neutral.json

@@ -27,11 +27,13 @@
     "idp": false
   },
   "project": {
-    "_note": "Per-project policy the PLATFORM decides and this instance OBEYS (task 1003139, goal 1000058). Stored on the platform's provisioning_instances.settings; written here as <PREFIX>_PLATFORM_VISIBILITY / <PREFIX>_JOINABILITY / <PREFIX>_VISIBILITY by the provisioning runner, which re-writes web.env and restarts the service when the owner changes one. The defaults are TODAY's behavior, so an instance that never receives a push — a self-hosted one, or one provisioned before this channel — keeps behaving exactly as it does now. platformVisibility (who may READ this instance's own pages): public | gated. joinability (HOW someone becomes a member): open | apply | invite_only. visibility (the join door, ADR 0182 D1 — how this project stands on the platform's map): public | private | stealth; it does NOT decide whether the project is on the map, publishability does. joinGrant (what a PUBLIC join GRANTS): view | apply | full — the ceiling joinability may only narrow (ADR 0182 D6 / ADR 0245); `full` narrows nothing, which is why it is the default.",
+    "_note": "Per-project policy the PLATFORM decides and this instance OBEYS (task 1003139, goal 1000058). Stored on the platform's provisioning_instances.settings; written here as <PREFIX>_PLATFORM_VISIBILITY / <PREFIX>_JOINABILITY / <PREFIX>_VISIBILITY by the provisioning runner, which re-writes web.env and restarts the service when the owner changes one. The defaults are TODAY's behavior, so an instance that never receives a push — a self-hosted one, or one provisioned before this channel — keeps behaving exactly as it does now. platformVisibility (who may READ this instance's own pages): public | gated. joinability (HOW someone becomes a member): open | apply | invite_only. visibility (the join door, ADR 0182 D1 — how this project stands on the platform's map): public | private | stealth; it does NOT decide whether the project is on the map, publishability does. joinGrant (what a PUBLIC join GRANTS): view | apply | full — the ceiling joinability may only narrow (ADR 0182 D6 / ADR 0245); `full` narrows nothing, which is why it is the default. artistGate (ADR 0241 — how hard this project's artist reviews bite): off | advisory | strict, written as <PREFIX>_ARTIST_GATE. off files no artist review tasks at all; advisory files them and blocks nothing; strict files them and lets an unresolved one hold the DEPLOY — this instance's core pin may not move while one is open. It never holds a builder's ship, which is what keeps it compatible with ADR 0162. It is the one key here whose default is NOT today's behaviour: `strict` is the owner's ruling (ADR 0241 §4), safe as a default because the worst case is a pin that waits, never a stranded builder, and the project owner holds the release valve. artistGateSince (<PREFIX>_ARTIST_GATE_SINCE) is its companion stamp — the moment the gate was last RAISED to strict, so the hold is not retroactive (ADR 0241 §5); empty means no cutoff, which is the right answer for a project that has been strict since it stood up.",
     "platformVisibility": "public",
     "joinability": "apply",
     "visibility": "public",
-    "joinGrant": "full"
+    "joinGrant": "full",
+    "artistGate": "strict",
+    "artistGateSince": ""
   },
   "repo": {
     "owner": "",

package/docs/adr/0001-stack-choice-single-vps.md

@@ -19,8 +19,8 @@ We needed an architecture that:
 
 We will run the entire V1 stack on a **single VPS** with the following components:
 
-- **Hosting:** DigitalOcean droplet, Ubuntu 24.04 LTS (see [0002](./<redacted>.md))
-- **Reverse proxy / TLS:** Caddy (originally for Let's Encrypt; superseded by [0003](./<redacted>.md))
+- **Hosting:** DigitalOcean droplet, Ubuntu 24.04 LTS (see [0002](./0002-digitalocean-over-hetzner.md))
+- **Reverse proxy / TLS:** Caddy (originally for Let's Encrypt; superseded by [0003](./0003-cloudflare-origin-cert-over-letsencrypt.md))
 - **Runtime:** Node.js 22 LTS
 - **Database:** PostgreSQL 16 (system package)
 - **Game server:** Colyseus 0.16 — open-source authoritative-server framework over WebSockets

package/docs/adr/0002-digitalocean-over-hetzner.md

@@ -6,7 +6,7 @@
 
 ## Context
 
-After locking in the [single-VPS stack](./<redacted>.md), we needed a hosting provider. Hetzner was the initial pick on cost (~$5/mo for an equivalent VPS). Setup was blocked at Hetzner's KYC step, which requires identity verification documents and a turnaround period before the account is provisioned.
+After locking in the [single-VPS stack](./0001-stack-choice-single-vps.md), we needed a hosting provider. Hetzner was the initial pick on cost (~$5/mo for an equivalent VPS). Setup was blocked at Hetzner's KYC step, which requires identity verification documents and a turnaround period before the account is provisioned.
 
 ## Decision
 

package/docs/adr/0008-google-chat-oauth-user-auth.md

@@ -1,6 +1,6 @@
 # 0008 — Google Chat integration auth model: OAuth as the operator user
 
-- **Status:** Superseded by [ADR 0032](0032-discord-mirror-of-gds.md) (outbound) and [ADR 0033](<redacted>.md) (bot/inbound) — Google Chat fully retired 2026-06-05, replaced by Discord
+- **Status:** Superseded by [ADR 0032](0032-discord-mirror-of-gds.md) (outbound) and [ADR 0033](0033-discord-bot-service-principal.md) (bot/inbound) — Google Chat fully retired 2026-06-05, replaced by Discord
 - **Date:** 2026-05-09
 - **Deciders:** Lars
 

package/docs/adr/0009-autotile-architecture.md

@@ -8,7 +8,7 @@
 
 V1 needs to render coherent terrain boundaries: grass islands within sand, sand
 beaches against shallow sea, marble flagstone paths through grass, cliffs.
-Earlier work in [ADR 0008](./<redacted>.md) established
+Earlier work in [ADR 0008](./0008-family-based-tile-generation.md) established
 the family pipeline and produced beautiful single illustrations for continuous
 objects (containers, houses), but that pipeline could not produce a true
 autotile family — a set of tiles where every cell is a different topology

package/docs/adr/0011-terrain-id-rendering-model.md

@@ -1,10 +1,10 @@
 # 0011 — Terrain-id world map + dispatched render strategies (Phase D)
 
-- **Status:** Accepted; cell data model extended by [ADR 0012](./<redacted>.md)
+- **Status:** Accepted; cell data model extended by [ADR 0012](./0012-ground-object-cell-split.md)
 - **Date:** 2026-05-09
 - **Deciders:** Lars
 
-> **Update (same day):** [ADR 0012](./<redacted>.md)
+> **Update (same day):** [ADR 0012](./0012-ground-object-cell-split.md)
 > splits the cell from one terrain id into two layers — ground (always
 > defined) + object (optional overlay). The dispatched render
 > strategies (`single` / `blob47` / `path16`) and the autotile cross-
@@ -13,7 +13,7 @@
 
 ## Context
 
-[ADR 0008](./<redacted>.md) and
+[ADR 0008](./0008-family-based-tile-generation.md) and
 [ADR 0009](./0009-autotile-architecture.md) established two new asset
 pipelines (family + autotile) but stopped at the asset boundary. The
 runtime renderer still treated the world as a flat 2D grid of tile-id

package/docs/adr/0013-paths-as-object-overlays-with-autotile-dispatch.md

@@ -3,7 +3,7 @@
 - **Status:** Accepted
 - **Date:** 2026-05-10
 - **Deciders:** Lars
-- **Extends:** [ADR 0012](./<redacted>.md) (cell model), [ADR 0011](./0011-terrain-id-rendering-model.md) (render dispatch), [ADR 0009](./0009-autotile-architecture.md) (autotile families)
+- **Extends:** [ADR 0012](./0012-ground-object-cell-split.md) (cell model), [ADR 0011](./0011-terrain-id-rendering-model.md) (render dispatch), [ADR 0009](./0009-autotile-architecture.md) (autotile families)
 
 ## Context
 

package/docs/adr/0014-families-canonical-over-vocabulary.md

@@ -4,7 +4,7 @@
 - **Date:** 2026-05-11
 - **Deciders:** Lars
 - **Track:** `internal` (art pipeline)
-- **Extends:** [ADR 0008-a](./<redacted>.md) (family-based tile generation), [ADR 0009](./0009-autotile-architecture.md) (autotile architecture)
+- **Extends:** [ADR 0008-a](./0008-family-based-tile-generation.md) (family-based tile generation), [ADR 0009](./0009-autotile-architecture.md) (autotile architecture)
 
 ## Context
 

package/docs/adr/0015-task-dependencies-and-auto-promotion.md

@@ -122,4 +122,4 @@ Rejected because that's the system that was failing Lars in the first place. Man
 **Operationally:**
 - `/builder-start` filters by `status='ready'`, so a builder never sees a dep-blocked task in their menu. Good UX.
 - `/builder-claim` returns `DEPS_NOT_SHIPPED` if a manually-promoted task is claimed before its deps land. CLI prints the blockers. Good UX.
-- The `[ADR 0014](../adr/<redacted>.md)` ADR number was taken by the families work; this one is **0015**.
+- The `[ADR 0014](../adr/0014-families-canonical-over-vocabulary.md)` ADR number was taken by the families work; this one is **0015**.

package/docs/adr/0016-trust-boundary-server-enforced-permissions.md

@@ -125,7 +125,7 @@ Tokens stay authority-free. `builder_sessions` issuance is unchanged by the rank
 **Costs:**
 - Every privileged route must remember to call `requireRank`. A forgotten check is a silent hole — mitigated by the auditor task ([#266](https://example.com/builders#/task/266)/V3.R44) which fails loudly when a privileged route lacks a rank gate.
 - Rank read on every privileged request (one extra column on an existing join). Accepted.
-- The two-rank V3 scope (Archon + Thetes) is deliberately minimal; the full ladder in [#106](https://example.com/builders#/task/106)'s enum is reserved but unimplemented, so promoting anyone to a middle rank is a no-op until those ranks gain route grants. Documented, not a bug. **(Superseded by [ADR 0018](<redacted>.md), task [#360](https://example.com/builders#/task/360): the three-rank `xenos`/`metic`/`archon` model went live — `xenos` is now the default entry rank and `metic` the approved working rank, both wired with route grants. The trust-boundary mechanism in this ADR is unchanged; only the set of live ranks widened.)**
+- The two-rank V3 scope (Archon + Thetes) is deliberately minimal; the full ladder in [#106](https://example.com/builders#/task/106)'s enum is reserved but unimplemented, so promoting anyone to a middle rank is a no-op until those ranks gain route grants. Documented, not a bug. **(Superseded by [ADR 0018](0018-three-rank-model-goes-live.md), task [#360](https://example.com/builders#/task/360): the three-rank `xenos`/`metic`/`archon` model went live — `xenos` is now the default entry rank and `metic` the approved working rank, both wired with route grants. The trust-boundary mechanism in this ADR is unchanged; only the set of live ranks widened.)**
 
 **Operationally:**
 - When adding any new write/privileged route, the default is `requireRank('archon')` until a lower rank is explicitly granted — fail closed, not open.

package/docs/adr/0018-three-rank-model-goes-live.md

@@ -2,7 +2,7 @@
 
 **Date:** 2026-05-27
 **Context:** Task [#360](https://example.com/builders#/task/360), follow-up to the V3.R86 ([#305](https://example.com/builders#/task/305)) CLAUDE.md audit. Advances GDS-V3 criterion
-C2 (`three-ranks-gate-everything`). Builds on (and partially supersedes) [ADR 0016](<redacted>.md).
+C2 (`three-ranks-gate-everything`). Builds on (and partially supersedes) [ADR 0016](0016-trust-boundary-server-enforced-permissions.md).
 **Status:** Accepted.
 
 ## Problem
@@ -47,7 +47,7 @@ change, not an enum migration.
 | Create / promote / edit tasks, deps, confirm, done-when scope | ❌ | ❌ | ✅ |
 | Grant/revoke rank, offboard, version close, infra | ❌ | ❌ | ✅ |
 
-> **Update (2026-06-26, [ADR 0090](<redacted>.md)):** the *"Create / promote / edit tasks, deps"* part of row 7 moved to **✅ for Metic** — a Metic may now author + shape tasks (`POST /tasks`, `PATCH /tasks/:id`, `POST /tasks/:id/promote`, and the `tasks/:id/{dependencies,criteria}` CRUD). `confirm` (grader-bypass), `done-when` *scope*-setting, abandon, rank, and version-close stay Archon-only (row 8 is unchanged). The table above is preserved as the 2026 record; ADR 0090 is the current authority.
+> **Update (2026-06-26, [ADR 0090](0090-metic-task-authoring.md)):** the *"Create / promote / edit tasks, deps"* part of row 7 moved to **✅ for Metic** — a Metic may now author + shape tasks (`POST /tasks`, `PATCH /tasks/:id`, `POST /tasks/:id/promote`, and the `tasks/:id/{dependencies,criteria}` CRUD). `confirm` (grader-bypass), `done-when` *scope*-setting, abandon, rank, and version-close stay Archon-only (row 8 is unchanged). The table above is preserved as the 2026 record; ADR 0090 is the current authority.
 
 ### Mechanisms
 
@@ -92,6 +92,6 @@ they reference real.
 ## Supersedes
 
 The "two-rank V3 scope (Archon + Thetes) is deliberately minimal" bullet in
-[ADR 0016 §Consequences](<redacted>.md#consequences) is
+[ADR 0016 §Consequences](0016-trust-boundary-server-enforced-permissions.md#consequences) is
 superseded: the middle/entry ranks are no longer all reserved-and-unwired — `metic` and `xenos` are
 live as of this ADR.

package/docs/adr/0020-security-model-public-stub.md

@@ -1,7 +1,7 @@
 # ADR 0020 — Security model — public stub (full ADR is server-side)
 
 **Date:** 2026-05-28
-**Context:** Task [#287](https://example.com/builders#/task/287) (V3.R68), GDS-V3 criterion C9. Companion to [ADR 0019](<redacted>.md) (bounty table), [ADR 0018](<redacted>.md) (rank model), [ADR 0016](<redacted>.md) (server-enforced trust boundary).
+**Context:** Task [#287](https://example.com/builders#/task/287) (V3.R68), GDS-V3 criterion C9. Companion to [ADR 0019](0019-red-team-bounty-payout-table.md) (bounty table), [ADR 0018](0018-three-rank-model-goes-live.md) (rank model), [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (server-enforced trust boundary).
 **Status:** Accepted.
 
 ## Problem
@@ -10,7 +10,7 @@ A security ADR worth writing is a security ADR worth attacking. The threat model
 
 But we *also* need this document to exist and be readable by trusted builders (Archon, Metic) — otherwise the system has no shared model of how it defends itself, and every new privileged route ends up reinventing the threat-list ad hoc. The red-team bounty (criterion C9) only makes sense if Metics know roughly where the surface is.
 
-We've already adopted [ADR 0016](<redacted>.md): authority lives on the server, not in the repo. The same logic applies to the security ADR itself — its content should live where its enforcement does.
+We've already adopted [ADR 0016](0016-trust-boundary-server-enforced-permissions.md): authority lives on the server, not in the repo. The same logic applies to the security ADR itself — its content should live where its enforcement does.
 
 ## Decision
 
@@ -30,21 +30,21 @@ The **full security ADR is server-side**, served by a Metic+-gated endpoint and
 
 The full ADR is structured as:
 
-1. **Trust boundary mechanics** — the actual implementation of [ADR 0016](<redacted>.md) per route: which routes are gated, by what rank, where the rank read lives in the request lifecycle, and what fails closed.
+1. **Trust boundary mechanics** — the actual implementation of [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) per route: which routes are gated, by what rank, where the rank read lives in the request lifecycle, and what fails closed.
 2. **Threat model** — the set of attackers we model (sandboxed builder, malicious Metic, leaked GitHub OAuth, supply-chain compromise, lost laptop) and what each can and cannot do under the current design.
 3. **Defense-in-depth inventory** — per privileged surface, the specific layers in front of it (rank check + audit log + rate limit + input validation + content TTL + …) and why each layer was chosen. This is the section that would most directly aid an attacker.
 4. **Known weaknesses** — the specific places where a defense is thinner than we'd like, with the reasons we haven't fixed them yet (deferred to a later version, cost/benefit, etc.). Highest sensitivity.
-5. **Red-team bounty alignment** — how a confirmed vulnerability_report maps onto the table in [ADR 0019](<redacted>.md), where the auto-confirmation path lives (R67/R68), and which surfaces are explicit invitations vs. out-of-scope (e.g. droplet-host vulns vs. application vulns).
+5. **Red-team bounty alignment** — how a confirmed vulnerability_report maps onto the table in [ADR 0019](0019-red-team-bounty-payout-table.md), where the auto-confirmation path lives (R67/R68), and which surfaces are explicit invitations vs. out-of-scope (e.g. droplet-host vulns vs. application vulns).
 
 Each section is updated when the underlying mechanism changes. The full ADR is the *living* document; this stub is the *pointer*.
 
 ### Why not just chmod the repo file?
 
-The Example repo is on GitHub. Marking a single file private is awkward (git history exposes it; collaborators see everything). The cleanest available primitive is "the file is on the droplet, the server reads it, the API gates access." That collapses to the same trust boundary [ADR 0016](<redacted>.md) already enforces for everything else.
+The Example repo is on GitHub. Marking a single file private is awkward (git history exposes it; collaborators see everything). The cleanest available primitive is "the file is on the droplet, the server reads it, the API gates access." That collapses to the same trust boundary [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) already enforces for everything else.
 
 ### This is not security-through-obscurity
 
-The defense doesn't depend on the ADR's secrecy. Every protection mentioned in the full ADR is independently enforced in code (rank middleware, audit log, input validation, etc.). Withholding the document raises the cost of an attacker's reconnaissance — it doesn't *create* the defense. The bounty table ([ADR 0019](<redacted>.md)) names the gain for the attacker who reverse-engineers it anyway: a high-severity finding pays out 1000 example. The system *wants* serious red-teamers; what it doesn't want is to hand them the map for free.
+The defense doesn't depend on the ADR's secrecy. Every protection mentioned in the full ADR is independently enforced in code (rank middleware, audit log, input validation, etc.). Withholding the document raises the cost of an attacker's reconnaissance — it doesn't *create* the defense. The bounty table ([ADR 0019](0019-red-team-bounty-payout-table.md)) names the gain for the attacker who reverse-engineers it anyway: a high-severity finding pays out 1000 example. The system *wants* serious red-teamers; what it doesn't want is to hand them the map for free.
 
 ## Alternatives considered
 
@@ -63,8 +63,8 @@ The defense doesn't depend on the ADR's secrecy. Every protection mentioned in t
 
 ## Cross-references
 
-- [ADR 0016](<redacted>.md) — the server-enforced trust boundary the security model rests on.
-- [ADR 0018](<redacted>.md) — the three-rank model whose gates the security ADR documents.
-- [ADR 0019](<redacted>.md) — the payout table a confirmed vulnerability_report maps onto.
+- [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) — the server-enforced trust boundary the security model rests on.
+- [ADR 0018](0018-three-rank-model-goes-live.md) — the three-rank model whose gates the security ADR documents.
+- [ADR 0019](0019-red-team-bounty-payout-table.md) — the payout table a confirmed vulnerability_report maps onto.
 - Migration [<redacted>.sql](../../migrations/<redacted>.sql) — the report intake table (R63).
 - Migration [033_audit_log.sql](../../migrations/033_audit_log.sql) — the audit ledger every privileged write lands in (R35).

package/docs/adr/0021-per-builder-skill-model-preferences.md

@@ -92,8 +92,8 @@ If V4 retires per-skill defaults in favor of per-skill-*kind* defaults (the broa
 
 ## Cross-references
 
-- [Migration 037](../../migrations/<redacted>.sql) — the schema change.
+- [Migration 037](../../migrations/037_builder_skill_model_prefs.sql) — the schema change.
 - [`src/bongos/skill-prefs.js`](../../src/bongos/skill-prefs.js) — the helper module and source of truth for defaults.
 - [`tests/skill_prefs.mjs`](../../tests/skill_prefs.mjs) — unit coverage for the pure helpers.
-- [ADR 0017](<redacted>.md) — same spirit: keep judgment work intentional, mechanism work cheap.
+- [ADR 0017](0017-code-simplification-and-repo-cleanliness.md) — same spirit: keep judgment work intentional, mechanism work cheap.
 - CLAUDE.md §2 — the project-wide subagent routing policy this ADR sits beside (not replaces — the policy is the default the matrix opens with).

package/docs/adr/0022-secrets-policy.md

@@ -1,7 +1,7 @@
 # ADR 0022 — Secrets policy
 
 **Date:** 2026-05-28
-**Context:** Task [#279](https://example.com/builders#/task/279) (V3.R60), GDS-V3 criterion C8. Originally built on a pre-commit hook + CI scan (task [#257](https://example.com/builders#/task/257), V3.R36); those surfaces were lost in the core extraction and rebuilt as the prevent/gate/patrol layers under goal 1000076 (task 1003131). Pairs with [ADR 0020](<redacted>.md) (security model — public stub) and [ADR 0016](<redacted>.md) (trust boundary).
+**Context:** Task [#279](https://example.com/builders#/task/279) (V3.R60), GDS-V3 criterion C8. Originally built on a pre-commit hook + CI scan (task [#257](https://example.com/builders#/task/257), V3.R36); those surfaces were lost in the core extraction and rebuilt as the prevent/gate/patrol layers under goal 1000076 (task 1003131). Pairs with [ADR 0020](0020-security-model-public-stub.md) (security model — public stub) and [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (trust boundary).
 **Enforcement rebuilt:** 2026-08-19 (task 1003131, goal 1000076) — see the Problem section's box.
 **Status:** Accepted.
 
@@ -46,7 +46,7 @@ A "secret" for the purposes of this policy is any string that, if disclosed, wou
 - Stripe live + test secret keys (`sk_live_`, `sk_test_`)
 - Any RSA / EC / DSA / Ed25519 private key (`-----BEGIN … PRIVATE KEY-----`)
 - TLS private keys (`-----BEGIN PRIVATE KEY-----`)
-- Cloudflare Origin Certificate private halves (lives on droplet only — see [ADR 0003](<redacted>.md))
+- Cloudflare Origin Certificate private halves (lives on droplet only — see [ADR 0003](0003-cloudflare-origin-cert-over-letsencrypt.md))
 - Postgres passwords (if peer-auth ever gets replaced with password auth — see [`docs/recipes/ops-gotchas.md`](../recipes/ops-gotchas.md) for the current peer-auth setup)
 - GDS session bearer tokens (any value of `gds_session` / `pms_session`)
 
@@ -67,7 +67,7 @@ Three lanes, each with explicit access controls. **Nothing else** is sanctioned;
 | Droplet rotating | `/etc/example/secrets/<name>` (chmod 600, per-secret file) | no | only the `lars` user + root | individual services that read one file at startup |
 | Builder laptop | `~/.config/otb/env` AND `.env.local` (gitignored, lives at the repo root in the main checkout and copies into worktrees on session start) | no — explicitly gitignored | the builder's macOS user account | `art/pipeline/gen_api.py` reads `~/.config/otb/env`; everything else reads `.env.local` |
 
-> **Multi-line secrets (e.g. a GitHub App private key, PEM).** Store in the droplet long-lived lane as a single line with literal `\n` escapes — `GITHUB_APP_PRIVATE_KEY="<redacted>"` — and the reader restores the newlines (`src/bongos/github-push.js normalizePem`). The GitHub App credential for server-mediated publish (`GITHUB_APP_ID` + `GITHUB_APP_INSTALLATION_ID` + `GITHUB_APP_PRIVATE_KEY`, [ADR 0055](<redacted>.md) / task 1028) lives here alongside the `GITHUB_PUSH_TOKEN` PAT it replaces.
+> **Multi-line secrets (e.g. a GitHub App private key, PEM).** Store in the droplet long-lived lane as a single line with literal `\n` escapes — `GITHUB_APP_PRIVATE_KEY="<redacted>"` — and the reader restores the newlines (`src/bongos/github-push.js normalizePem`). The GitHub App credential for server-mediated publish (`GITHUB_APP_ID` + `GITHUB_APP_INSTALLATION_ID` + `GITHUB_APP_PRIVATE_KEY`, [ADR 0055](0055-server-mediated-branch-publish.md) / task 1028) lives here alongside the `GITHUB_PUSH_TOKEN` PAT it replaces.
 
 Notably **not allowed**:
 
@@ -86,7 +86,7 @@ When a credential is rotated — either because we found a leak or because the c
 4. **Revoke the old credential** at the issuing service. Do this AFTER step 2; the brief overlap is intentional so a slow-rolling service catches both keys.
 5. **Log the rotation** — a one-line entry to [`docs/recipes/ops-gotchas.md`](../recipes/ops-gotchas.md) (date + which credential + why), so the next builder spinning up knows what changed when.
 
-GDS session tokens rotate automatically — they're 30-day-TTL, refresh-on-use, revocable per session or per builder (migration `<redacted>.sql`, ADR-aligned with [ADR 0016](<redacted>.md)). No manual rotation needed for those except in a leak scenario, which falls under "What to do on a hit" below.
+GDS session tokens rotate automatically — they're 30-day-TTL, refresh-on-use, revocable per session or per builder (migration `<redacted>.sql`, ADR-aligned with [ADR 0016](0016-trust-boundary-server-enforced-permissions.md)). No manual rotation needed for those except in a leak scenario, which falls under "What to do on a hit" below.
 
 ## What to do when the scan finds a hit
 
@@ -109,7 +109,7 @@ If a future audit *does* find a hit, follow "What to do when the scan finds a hi
 
 ## Scrubbing secrets OUT of session uploads (the BFG corpus)
 
-The enforcement above keeps secrets out of the **repo**. A second egress exists: the BFG session-inefficiency evaluator ([ADR 0027](<redacted>.md)) uploads a digest of each Claude Code session to the GDS `sessions` corpus. A transcript contains every file read, command output, and pasted value — so the upload path is scrubbed by **the same policy, applied client-side at upload time**, in `scrubSecrets()` (`scripts/gds/ship.js`, used by both `ship.js` and `session-digest.js`).
+The enforcement above keeps secrets out of the **repo**. A second egress exists: the BFG session-inefficiency evaluator ([ADR 0027](0027-bfg-session-inefficiency-evaluator.md)) uploads a digest of each Claude Code session to the GDS `sessions` corpus. A transcript contains every file read, command output, and pasted value — so the upload path is scrubbed by **the same policy, applied client-side at upload time**, in `scrubSecrets()` (`scripts/gds/ship.js`, used by both `ship.js` and `session-digest.js`).
 
 This scrubber is **transcript-grade** and **recall-first** (task 1003, which also completed the open token-redaction of task 723): a missed secret is a credential compromise, while over-redacting a non-secret in a BFG digest is merely cosmetic, so when in doubt it redacts. Five layers: (1) literal dynamic values — this run's GDS session token + every secret-shaped **env value** (`collectEnvSecrets()`, e.g. the `MAC_*`/`APPLE_*` signing creds, a baked GDS/DO token); (2) multi-line PEM private-key blocks; (3) the in-scope known shapes from this ADR (provider key prefixes, Stripe `sk_`/`rk_`/`whsec_`, our `gds_`/`pms_` tokens, `Authorization`/`Bearer` headers, JWTs, credentialed DSNs, Apple app-specific passwords); (4) recognised-key `key=value` / JSON-field assignments; (5) a **high-entropy catch-all** (`looksHighEntropySecret()`) over base64url/hex runs ≥20 chars — the net for an *unknown* secret shape. The accepted cost of layer 5 is that high-entropy non-secrets (git SHAs, UUIDs, a 40-hex value shape-identical to a GitHub OAuth client secret) are redacted too; the structured BFG metrics that matter (token/turn counts, tool names, error flags) are separate fields and untouched. The planted-secret corpus in `tests/scrubber_corpus.mjs` is the regression gate — every planted secret must be fully redacted, every benign line must survive — and **gates the full-transcript capture task**: capture must not ship until this passes.
 

package/docs/adr/0024-cloneable-repo-local-first-memory.md

@@ -1,7 +1,7 @@
 # ADR 0024 — Cloneable repo + local-first memory with server-canonical sync
 
 **Date:** 2026-05-29
-**Context:** GDS-V3, spike [#230](https://example.com/builders#/task/230) (V3.R04 — Architecture spike: cloneability + local-first memory with server sync). Satisfies done-when criterion C8 (`cloneable-local-memory-server-sync`). Companion to [ADR 0016](<redacted>.md) (trust boundary — same enforcement boundary applies here) and [ADR 0022](0022-secrets-policy.md) (no secrets in repo — a precondition for "cloneable").
+**Context:** GDS-V3, spike [#230](https://example.com/builders#/task/230) (V3.R04 — Architecture spike: cloneability + local-first memory with server sync). Satisfies done-when criterion C8 (`cloneable-local-memory-server-sync`). Companion to [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (trust boundary — same enforcement boundary applies here) and [ADR 0022](0022-secrets-policy.md) (no secrets in repo — a precondition for "cloneable").
 **Status:** Accepted.
 
 > Numbering note: the spike's done-when named this ADR `<redacted>.md`, but `0016` was already taken by the trust-boundary ADR before this spike was opened. This ADR is **0024**. Same correction the R03 spike (ADR 0016) made for itself.
@@ -84,7 +84,7 @@ Two-builders-different-builder-id on the same file is impossible by construction
 
 ### 4. Isolation — server enforces `req.builder.id === path_owner.builder_id`
 
-All memory endpoints (`POST /memory/sync`, `GET /memory/since`, `GET /memory/files`, `GET /memory/files/:path`) check that the requester's `req.builder.id` matches the row's `builder_id` before reading or writing. Mismatch returns `403 memory_forbidden`. The check happens in the route handler, after `requireBuilder`, before any DB work. Same trust-boundary posture as [ADR 0016](<redacted>.md): the server enforces; nothing the builder can edit locally can grant cross-builder access.
+All memory endpoints (`POST /memory/sync`, `GET /memory/since`, `GET /memory/files`, `GET /memory/files/:path`) check that the requester's `req.builder.id` matches the row's `builder_id` before reading or writing. Mismatch returns `403 memory_forbidden`. The check happens in the route handler, after `requireBuilder`, before any DB work. Same trust-boundary posture as [ADR 0016](0016-trust-boundary-server-enforced-permissions.md): the server enforces; nothing the builder can edit locally can grant cross-builder access.
 
 **Archon forensic exception — read-only.** An Archon-only endpoint `GET /memory/builders/:id/files` exists for restore + forensics use cases (e.g. a builder offboards, Archon needs to inspect their memory; a corrupt file needs restoration). Every Archon read is logged to `audit_log` with `actor_builder_id`, `target_builder_id`, `path`, `reason`. **There is no Archon write endpoint.** Restores happen via `pg_restore` into a sandbox schema, never live. Read-only is the V3 posture; cross-builder *reads* are likely to be relaxed in a later version (e.g. Metics seeing each other's memory for collaboration), but cross-builder *writes* through the API are not on the roadmap. Any future relaxation requires a superseding ADR.
 
@@ -259,7 +259,7 @@ Lars (or a stand-in) runs the full flow with a stopwatch, on a fresh laptop / VM
 - No new infra cost. Rides Postgres + existing `pg_dump`.
 - Memory follows the builder across machines and across worktrees on the same machine.
 - A wiped laptop is recoverable in two commands (`git clone` + `/builder-start`).
-- Trust boundary is the same one [ADR 0016](<redacted>.md) already established — no new authority concept to reason about.
+- Trust boundary is the same one [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) already established — no new authority concept to reason about.
 - Forensic access exists (for Archon) but is audit-logged, so misuse is visible.
 
 **Costs:**

package/docs/adr/0024-multi-agent-system-architecture.md

@@ -4,7 +4,7 @@
 - **Date:** 2026-05-29 (Phases 1–3); 2026-05-30 (Phases 4–5); Phase 6 + C7 followed.
 - **Deciders:** Lars Kristensen (Archon), Claude
 - **Track:** `internal` (GDS)
-- **Supersedes:** none. Extends [ADR 0010](0010-pms-architecture.md) (GDS architecture), [ADR 0016](<redacted>.md) (trust boundary), [ADR 0017](<redacted>.md) (economy lens — the first piece of the Grader's worker decomposition).
+- **Supersedes:** none. Extends [ADR 0010](0010-pms-architecture.md) (GDS architecture), [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (trust boundary), [ADR 0017](0017-code-simplification-and-repo-cleanliness.md) (economy lens — the first piece of the Grader's worker decomposition).
 
 ## Context
 
@@ -45,13 +45,13 @@ red-team  completion MONGER
                     cost/perf
 ```
 
-**One persistent agent: the Conductor.** Implemented as a `UserPromptSubmit` hook in `.claude/settings.json`. Runs per builder turn. Inherits the builder's rank — no new authority. Output is advisory: it suggests `/builder-redteam` on security-sensitive edits, suggests Grader pre-flight before `/builder-ship`, dispatches BFG after doc edits, and so on. **Conductor proposes; the builder confirms.** Anything that touches a rank-gated route still goes through the existing DB-enforced check ([ADR 0016](<redacted>.md)) — the Conductor cannot grant or bypass authority.
+**One persistent agent: the Conductor.** Implemented as a `UserPromptSubmit` hook in `.claude/settings.json`. Runs per builder turn. Inherits the builder's rank — no new authority. Output is advisory: it suggests `/builder-redteam` on security-sensitive edits, suggests Grader pre-flight before `/builder-ship`, dispatches BFG after doc edits, and so on. **Conductor proposes; the builder confirms.** Anything that touches a rank-gated route still goes through the existing DB-enforced check ([ADR 0016](0016-trust-boundary-server-enforced-permissions.md)) — the Conductor cannot grant or bypass authority.
 
 **Three invoked roles, summoned by trigger, not persistent:**
 
 - **Grader** (on `/builder-ship`). The ship-time gate. Phase 1 makes it strict (default-fail framing + cross-family Sonnet grading Opus's work + 3-shot unanimous-PASS); Phase 2 decomposes it into a worker panel: *Narc* (semantic completion — task description vs diff), *Quality* (code quality + advisory economy), *Hacker* (security red-team — wraps `/builder-redteam` as a CI gate), *Efficiency Monger* (runtime cost / hot-path performance). Unanimous-PASS gate; non-unanimous falls through to the manual-confirm release valve. Plus a deterministic route-rank pre-pass (C7).
 - **Architect** (quarterly cadence + Conductor nudge). Bounded-scope audits feed `docs/audits/<scope>-<date>.md` + `idea_inbox` seeds. Each quarterly audit becomes the foundational input for the next version's planning session. *No workers yet* — the Architect does its own work flexibly per the user's "delegators without workers do the work themselves" rule.
-- **BFG** (post-ship + pre-cron). Memory + index hygiene at its root — audits CLAUDE.md claims against DB reality, prunes stale references, verifies `[[links]]` resolve. **Widened in [ADR 0026](<redacted>.md) and now shipped (Phase 6 complete):** it also adds DB counter-vs-ledger drift checks (6A.2), scores builders + propagates transferable practice (6B), and operates the audited cross-builder memory WRITE path for dreams + transparent corrections (6C). *No grader-style workers — it does its own work (the "delegators without workers do the work themselves" rule).* Vector-store retrieval still deferred — the MEMORY.md graph + frontmatter suffices.
+- **BFG** (post-ship + pre-cron). Memory + index hygiene at its root — audits CLAUDE.md claims against DB reality, prunes stale references, verifies `[[links]]` resolve. **Widened in [ADR 0026](0026-bfg-memory-hygiene-and-cross-builder-learning.md) and now shipped (Phase 6 complete):** it also adds DB counter-vs-ledger drift checks (6A.2), scores builders + propagates transferable practice (6B), and operates the audited cross-builder memory WRITE path for dreams + transparent corrections (6C). *No grader-style workers — it does its own work (the "delegators without workers do the work themselves" rule).* Vector-store retrieval still deferred — the MEMORY.md graph + frontmatter suffices.
 
 ### Why 2 tiers, not 3
 
@@ -73,7 +73,7 @@ Musk's 5-step engineering algorithm: (1) make requirements less dumb, (2) delete
 
 Reduced cast: **4 agents, not 6** (1 persistent + 3 invoked).
 
-**Grader strictness — strict-first, loosen-later.** The grader is the load-bearing first change (its output is consumed by every shipped task). It does not relax during calibration; if it stalls genuine work we tune the prompt, not the gate, with the manual-confirm endpoint (`POST /tasks/:id/confirm`) as the emergency release valve. New grader signals (`shots[]`, `grader_model`, per-worker scores) land in the jsonb `task_grades.signals` column with no migration; top-level `rubric_scores` get the median across shots. This mirrors how the economy lens earned its teeth ([ADR 0017](<redacted>.md)): advisory → calibrate → gate.
+**Grader strictness — strict-first, loosen-later.** The grader is the load-bearing first change (its output is consumed by every shipped task). It does not relax during calibration; if it stalls genuine work we tune the prompt, not the gate, with the manual-confirm endpoint (`POST /tasks/:id/confirm`) as the emergency release valve. New grader signals (`shots[]`, `grader_model`, per-worker scores) land in the jsonb `task_grades.signals` column with no migration; top-level `rubric_scores` get the median across shots. This mirrors how the economy lens earned its teeth ([ADR 0017](0017-code-simplification-and-repo-cleanliness.md)): advisory → calibrate → gate.
 
 ## Phase plan & implementation history
 
@@ -85,7 +85,7 @@ Built incrementally over six phases, each independently shippable and required t
 - **4** — Conductor **session-mediated** dispatch (`scripts/gds/conductor-dispatch.js` runs any specialist on the working diff, reusing the grader-workers machinery).
 - **4.5** — Conductor **autonomous background** dispatch (`conductor-dispatch.js auto-dispatch`): selects the next claimable autonomous task *without a human prompt* and emits its `/builder-claim` directive for a runner to execute. It **proposes, never disposes** in the autonomous path too — the selector emits the directive; the runner + ship pipeline (where ADR 0016's DB gates and the grader still bite) is what claims, builds, and lands. Gated by the same `scripts/gds/autonomy-gate.js` precheck the nightly routines use (master kill-switch + MTD spend brake + no-signal skip), so it is **INERT until `OTB_AUTONOMY_ENABLED=1`**. The candidate feed is the protected-path-filtered `fit:'autonomous'` view (SR-12) — the permission/methodology/deploy core can never be auto-selected.
 - **5** — Architect role + first audit (`scripts/gds/architect-audit.js --scope` → `docs/audits/` + idea_inbox seeds; on-demand, not cron'd).
-- **6** — BFG built out well past bootstrap (doc/index + per-builder memory hygiene, DB counter-vs-ledger drift, cross-builder read + interaction-quality scoring, and the first audited cross-builder memory WRITE path — identity-gated, kill-switched, builder-reversible). Charter: [ADR 0026](<redacted>.md); session-inefficiency evaluator (cluster 6D): [ADR 0027](<redacted>.md).
+- **6** — BFG built out well past bootstrap (doc/index + per-builder memory hygiene, DB counter-vs-ledger drift, cross-builder read + interaction-quality scoring, and the first audited cross-builder memory WRITE path — identity-gated, kill-switched, builder-reversible). Charter: [ADR 0026](0026-bfg-memory-hygiene-and-cross-builder-learning.md); session-inefficiency evaluator (cluster 6D): [ADR 0027](0027-bfg-session-inefficiency-evaluator.md).
 - **C7** — the grader's deterministic **route-rank pre-pass** (`src/bongos/route-rank-check.js`, shared via `grader.routeRankPrePass()` by the ship-time panel and `conductor-dispatch.js`): every route must classify to a known rank; write-route `unknown` → hard fail. The deterministic-first → LLM-on-demand pattern; C7's periodic auditor, in-context at ship time.
 
 Per-phase scope, rationale, "out of scope", and ship detail (incl. the Phase-1 first-ship calibration data + the `Number(null)=0` self-ship learning) live in the shipping tasks + the session logs — this ADR is the decision record, not the changelog. Phase tasks: [#395](https://example.com/builders#/task/395) (1) · [#410](https://example.com/builders#/task/410)/[#413](https://example.com/builders#/task/413)/[#416](https://example.com/builders#/task/416)/[#421](https://example.com/builders#/task/421)/[#423](https://example.com/builders#/task/423) (2) · [#427](https://example.com/builders#/task/427) (3) · [#439](https://example.com/builders#/task/439) (4) · [#459](https://example.com/builders#/task/459) (5) · [#442](https://example.com/builders#/task/442)–[#448](https://example.com/builders#/task/448) (6) · [#475](https://example.com/builders#/task/475) (C7) · [#458](https://example.com/builders#/task/458) (4.5).
@@ -96,8 +96,8 @@ Per-phase scope, rationale, "out of scope", and ship detail (incl. the Phase-1 f
 
 - The trust gate at `/builder-ship` actually bites. Calibration data — not vibes — drives future tightening.
 - Cost is ~neutral: 3× Sonnet ≈ 1× Opus (prior). Grader cost-per-shipped-task does not balloon.
-- Architecture-ready for per-builder model preferences ([ADR 0021](<redacted>.md)): when GDS-V4 ships builder-configurable model allocation, the `selectGraderModel(builderModel)` function becomes the obvious extension point.
-- Trust boundary preserved: nothing here grants new permissions; the Conductor (Phase 3+) inherits builder rank and proposes, never disposes ([ADR 0016](<redacted>.md) stays load-bearing).
+- Architecture-ready for per-builder model preferences ([ADR 0021](0021-per-builder-skill-model-preferences.md)): when GDS-V4 ships builder-configurable model allocation, the `selectGraderModel(builderModel)` function becomes the obvious extension point.
+- Trust boundary preserved: nothing here grants new permissions; the Conductor (Phase 3+) inherits builder rank and proposes, never disposes ([ADR 0016](0016-trust-boundary-server-enforced-permissions.md) stays load-bearing).
 - The original Delegators (Project Manager, Janitor) are *deleted* rather than built — the Musk rule applied to ourselves.
 
 **Bad / accepted:**
@@ -115,9 +115,9 @@ Per-phase scope, rationale, "out of scope", and ship detail (incl. the Phase-1 f
 ## References
 
 - [ADR 0010](0010-pms-architecture.md) — GDS (then PMS) architecture
-- [ADR 0016](<redacted>.md) — trust boundary (Conductor must not bypass)
-- [ADR 0017](<redacted>.md) — economy lens (first Grader worker, retroactively)
-- [ADR 0021](<redacted>.md) — per-builder model preferences (Phase 1's hardcoded Sonnet generalizes here)
+- [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) — trust boundary (Conductor must not bypass)
+- [ADR 0017](0017-code-simplification-and-repo-cleanliness.md) — economy lens (first Grader worker, retroactively)
+- [ADR 0021](0021-per-builder-skill-model-preferences.md) — per-builder model preferences (Phase 1's hardcoded Sonnet generalizes here)
 - Anthropic, "Building Effective Agents" (Schluntz & Zhang, Dec 2024) — orchestrator-workers and evaluator-optimizer patterns
 - Anthropic, "How we built our multi-agent research system" (Engineering blog, 2025) — empirical 2-tier orchestration, ~15× token cost
 - Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" (NeurIPS 2023) — same-family judge inflation

package/docs/adr/0025-offsite-backup-vendor-digitalocean-spaces.md

@@ -1,7 +1,7 @@
 # ADR 0025 — Offsite backup vendor: DigitalOcean Spaces
 
 **Date:** 2026-05-30
-**Context:** Task [#415](https://example.com/builders#/task/415) (V3.R62-offsite), claim `#338`, GDS-V3 criterion C8 ("memory is local-first, server-canonical on ship" — which depends on the GDS DB surviving whole-droplet loss). Companion to the local nightly backup filed by [#412](https://example.com/builders#/task/412) (V3.R62-precondition, [`docs/recipes/gds-db-backup.md`](../recipes/gds-db-backup.md)) and the secrets policy in [ADR 0022](0022-secrets-policy.md). Sits under [ADR 0024 §5](<redacted>.md) (backup cadence).
+**Context:** Task [#415](https://example.com/builders#/task/415) (V3.R62-offsite), claim `#338`, GDS-V3 criterion C8 ("memory is local-first, server-canonical on ship" — which depends on the GDS DB surviving whole-droplet loss). Companion to the local nightly backup filed by [#412](https://example.com/builders#/task/412) (V3.R62-precondition, [`docs/recipes/gds-db-backup.md`](../recipes/gds-db-backup.md)) and the secrets policy in [ADR 0022](0022-secrets-policy.md). Sits under [ADR 0024 §5](0024-cloneable-repo-local-first-memory.md) (backup cadence).
 **Status:** Accepted.
 
 ## Problem

package/docs/adr/0025-structured-criterion-task-link.md

@@ -39,6 +39,6 @@ This positional decode is brittle — reorder the criteria and old prose referen
 ## Consequences
 
 - **One-call status.** `/status C8` answers in a single request what previously took ~10. The public dashboard can adopt the same endpoint.
-- **The Conductor stays advisory + zero-cost.** It gains one regex trigger that *routes* status-intent prompts to `/status` (proposes, never disposes; no LLM call) — it does not answer questions itself. Consistent with [ADR 0024 (MAS)](<redacted>.md) Phase 3.
+- **The Conductor stays advisory + zero-cost.** It gains one regex trigger that *routes* status-intent prompts to `/status` (proposes, never disposes; no LLM call) — it does not answer questions itself. Consistent with [ADR 0024 (MAS)](0024-multi-agent-system-architecture.md) Phase 3.
 - **Follow-up needed:** task creation does not yet populate `task_criteria`, so tasks created after the backfill are unlinked until a manage endpoint / planning-flow wire-up lands. Filed as a follow-up task at ship time. Until then `/status` under-counts new work, which `unattributed_tasks` makes visible.
 - **No authority change.** The endpoint is public read-only (same posture as `/versions/:id/done-when`); the join table carries no permission semantics. ADR 0016 trust boundary is untouched.

package/docs/adr/0026-bfg-memory-hygiene-and-cross-builder-learning.md

@@ -6,12 +6,12 @@
 - **Track:** `internal` (GDS)
 - **Context task:** GDS-V3 [#441](https://example.com/builders#/task/441) (this design task — ADR + task breakdown only; no implementation).
 
-> **Numbering note:** this ADR was authored as `0025` but renumbered to **0026** on the same day, after a merge from `main` surfaced an already-shipped [`0025` — Offsite backup vendor](<redacted>.md) (task [#415](https://example.com/builders#/task/415)). The shipped ADR keeps `0025`; this one moves. The backlog implementation tasks **[#442](https://example.com/builders#/task/442)–[#448](https://example.com/builders#/task/448)** were filed *before* the renumber and so reference this ADR as "ADR 0025" in their descriptions (the GDS has no description-edit endpoint and there was no DB access to correct them in-session). The sub-phase labels (**6A.1 … 6C.3**) are stable and unambiguous — when a task says "ADR 0025 section 6A.1", read **this** ADR (0026), section 6A.1.
-- **Extends:** [ADR 0024 — Multi-Agent System architecture](<redacted>.md) (the BFG is its Phase 6); [ADR 0024 — Cloneable repo + local-first memory](<redacted>.md) (the `builder_memory` store this operates on); [ADR 0016 — Trust boundary](<redacted>.md) (this ADR deliberately and narrowly *punctures* the no-cross-builder-write rule — recorded here as a conscious exception). Touches the karma model ([migration 040](../../migrations/040_builder_karma.sql)) and the memory schema ([migration 054](../../migrations/054_builder_memory.sql)).
+> **Numbering note:** this ADR was authored as `0025` but renumbered to **0026** on the same day, after a merge from `main` surfaced an already-shipped [`0025` — Offsite backup vendor](0025-offsite-backup-vendor-digitalocean-spaces.md) (task [#415](https://example.com/builders#/task/415)). The shipped ADR keeps `0025`; this one moves. The backlog implementation tasks **[#442](https://example.com/builders#/task/442)–[#448](https://example.com/builders#/task/448)** were filed *before* the renumber and so reference this ADR as "ADR 0025" in their descriptions (the GDS has no description-edit endpoint and there was no DB access to correct them in-session). The sub-phase labels (**6A.1 … 6C.3**) are stable and unambiguous — when a task says "ADR 0025 section 6A.1", read **this** ADR (0026), section 6A.1.
+- **Extends:** [ADR 0024 — Multi-Agent System architecture](0024-multi-agent-system-architecture.md) (the BFG is its Phase 6); [ADR 0024 — Cloneable repo + local-first memory](0024-cloneable-repo-local-first-memory.md) (the `builder_memory` store this operates on); [ADR 0016 — Trust boundary](0016-trust-boundary-server-enforced-permissions.md) (this ADR deliberately and narrowly *punctures* the no-cross-builder-write rule — recorded here as a conscious exception). Touches the karma model ([migration 040](../../migrations/040_builder_karma.sql)) and the memory schema ([migration 054](../../migrations/054_builder_memory.sql)).
 
 ## Context
 
-The **BFG** is the post-ship / pre-cron role in the MAS ([ADR 0024-mas](<redacted>.md)). Its Phase-6 charter there was deliberately narrow: *"memory hygiene — audit CLAUDE.md claims against DB reality, prune stale references, verify `[[links]]` resolve."* No code has been written yet.
+The **BFG** is the post-ship / pre-cron role in the MAS ([ADR 0024-mas](0024-multi-agent-system-architecture.md)). Its Phase-6 charter there was deliberately narrow: *"memory hygiene — audit CLAUDE.md claims against DB reality, prune stale references, verify `[[links]]` resolve."* No code has been written yet.
 
 On 2026-05-30 Lars expanded the BFG's remit to **two standing objectives**:
 
@@ -22,7 +22,7 @@ This ADR records the architecture and, critically, the **boundaries** that turn
 
 ### What the substrate already gives us
 
-- **Builder memory is server-canonical and per-builder isolated** — [`builder_memory`](../../src/bongos/routes/memory.js), `PRIMARY KEY (builder_id, path)`. The *only* cross-builder access that exists today is an **Archon-only, audit-logged, read-only** forensic path. **There is no cross-builder *write* path at all** — that was a conscious decision ([ADR 0016](<redacted>.md), [ADR 0024-memory](<redacted>.md) §4).
+- **Builder memory is server-canonical and per-builder isolated** — [`builder_memory`](../../src/bongos/routes/memory.js), `PRIMARY KEY (builder_id, path)`. The *only* cross-builder access that exists today is an **Archon-only, audit-logged, read-only** forensic path. **There is no cross-builder *write* path at all** — that was a conscious decision ([ADR 0016](0016-trust-boundary-server-enforced-permissions.md), [ADR 0024-memory](0024-cloneable-repo-local-first-memory.md) §4).
 - **Karma** ([`karma_log`](../../migrations/040_builder_karma.sql)) is the existing good-citizenship reputation ledger (append-only, `granted_by` records who drove a delta, `NULL` = system).
 - **Cron roles** live as `SKILL.md` files under [`.claude/scheduled-tasks/`](../../.claude/scheduled-tasks/); the read-only `overnight-code-review` routine is the closest existing pattern.
 
@@ -50,7 +50,7 @@ Read-only auditor. Findings land as `idea_inbox` rows (one per finding, like `ov
 
 ### 6C — Dreams & correction (the write path — the load-bearing part)
 
-This sub-phase creates the **first cross-builder memory write capability** in the system. It is the deliberate, bounded exception to [ADR 0016](<redacted>.md).
+This sub-phase creates the **first cross-builder memory write capability** in the system. It is the deliberate, bounded exception to [ADR 0016](0016-trust-boundary-server-enforced-permissions.md).
 
 **Dreams (beneficial writes).** Lars chose **direct write** (audited + visible) over propose-only, for immediacy. The BFG writes the entry directly into the target builder's memory, constrained by:
 - a dedicated, clearly-marked location — e.g. `bfg/dream-<slug>.md` (or a fenced `## BFG dreams` block) — never overwriting a builder's own files;
@@ -78,19 +78,19 @@ The BFG runs as a `SKILL.md` scheduled routine (post-ship / pre-cron cadence) an
 | **6B.2** | Transferable-pattern extraction from top performers + adoption-suggestion generation. | Good practice propagates; the "most creative experience" objective gets teeth. |
 | **6C.1** | Migration: BFG service principal (system builder, no-claim/no-example) + cross-builder memory **write** endpoint (audited, namespaced, attributed) + `karma_log` reason `bfg_correction`. | The write substrate + trust-boundary exception land in one reviewable unit. |
 | **6C.2** | Wire dream-writes + transparent corrections into the BFG routine; kill-switch; builder-visible attribution; delete affordance. | Dreams + correction work end-to-end, safely. |
-| **6C.3** | Update [ADR 0024-mas](<redacted>.md) Phase-6 row + CLAUDE.md MAS index line. (Deferred out of [#441](https://example.com/builders#/task/441) — `CLAUDE.md` / `0024` are held by the active Phase-4 claim `#439`.) | The index reflects the shipped BFG. |
+| **6C.3** | Update [ADR 0024-mas](0024-multi-agent-system-architecture.md) Phase-6 row + CLAUDE.md MAS index line. (Deferred out of [#441](https://example.com/builders#/task/441) — `CLAUDE.md` / `0024` are held by the active Phase-4 claim `#439`.) | The index reflects the shipped BFG. |
 
-Each sub-phase must answer "is this earning its tokens?" before the next is built — the Musk gate, same as [ADR 0024-mas](<redacted>.md).
+Each sub-phase must answer "is this earning its tokens?" before the next is built — the Musk gate, same as [ADR 0024-mas](0024-multi-agent-system-architecture.md).
 
-> **Sibling capability cluster — 6D (session-inefficiency evaluator), recorded in [ADR 0027](<redacted>.md).** The 6A/6B/6C clusters above cover the BFG's *hygiene* and *cross-builder memory learning* objectives. A later, separately-chartered cluster — **6D** — serves the same "best building experience" objective from a different angle: it ingests uploaded session transcripts and auto-runs the #506-style post-mortem across all sessions to surface systemic build-process waste (and mine top performers for good practice). It reuses this charter's §6C transparent-note path to deliver per-builder findings. See [ADR 0027](<redacted>.md); build tasks GDS-V4 [#540](https://example.com/builders#/task/540)–[#545](https://example.com/builders#/task/545).
+> **Sibling capability cluster — 6D (session-inefficiency evaluator), recorded in [ADR 0027](0027-bfg-session-inefficiency-evaluator.md).** The 6A/6B/6C clusters above cover the BFG's *hygiene* and *cross-builder memory learning* objectives. A later, separately-chartered cluster — **6D** — serves the same "best building experience" objective from a different angle: it ingests uploaded session transcripts and auto-runs the #506-style post-mortem across all sessions to surface systemic build-process waste (and mine top performers for good practice). It reuses this charter's §6C transparent-note path to deliver per-builder findings. See [ADR 0027](0027-bfg-session-inefficiency-evaluator.md); build tasks GDS-V4 [#540](https://example.com/builders#/task/540)–[#545](https://example.com/builders#/task/545).
 
 ## Alternatives considered
 
 - **Covert "nightmares" (rejected).** The original ask imagined planting *false or harmful* memories to covertly worsen a misbehaving builder. Rejected outright: it is deception that causes real harm (wasted work, decisions seeded by lies), it has no consent, and an audit trail does not redeem it. Transparent correction (a visible, attributed note + a karma dock) achieves the same steering with none of that. This is the load-bearing rejection of this ADR.
 - **Propose-only writes vs direct writes.** Propose-only (the BFG drops a clearly-marked *suggestion* the builder must accept) best preserves the isolation/consent spirit. Lars chose **direct write** for immediacy on "obvious improvements." We keep the consent spirit alive through visible attribution + namespaced files + delete-ability + per-write audit, and accept the residual risk (memory changing between sessions) in §Consequences.
 - **Karma-only correction (no memory write).** Considered: never touch a misbehaving builder's memory, only dock karma + flag for Archon. Rejected as the *default* because a karma delta alone doesn't tell the builder *what* to change; the visible corrective note carries the actionable feedback. (Karma-only remains the right move when there's nothing constructive to write.)
-- **Amend ADR 0024 vs a standalone ADR.** The BFG is Phase 6 of [ADR 0024-mas](<redacted>.md), so amending it was the obvious option. Chosen instead to write a standalone ADR because the new **cross-builder write path is a trust-boundary decision** that extends [ADR 0016](<redacted>.md) — significant enough to deserve its own record rather than a table-row footnote.
-- **Vector store / semantic memory for hygiene + 6B scoring.** Deferred, consistent with [ADR 0024-mas](<redacted>.md)'s own "vector-store implementation deferred" call. The current markdown `MEMORY.md` graph + frontmatter is sufficient for 6A/6B; revisit only if manual + heuristic analysis proves insufficient.
+- **Amend ADR 0024 vs a standalone ADR.** The BFG is Phase 6 of [ADR 0024-mas](0024-multi-agent-system-architecture.md), so amending it was the obvious option. Chosen instead to write a standalone ADR because the new **cross-builder write path is a trust-boundary decision** that extends [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) — significant enough to deserve its own record rather than a table-row footnote.
+- **Vector store / semantic memory for hygiene + 6B scoring.** Deferred, consistent with [ADR 0024-mas](0024-multi-agent-system-architecture.md)'s own "vector-store implementation deferred" call. The current markdown `MEMORY.md` graph + frontmatter is sufficient for 6A/6B; revisit only if manual + heuristic analysis proves insufficient.
 
 ## Consequences
 
@@ -110,8 +110,8 @@ Each sub-phase must answer "is this earning its tokens?" before the next is buil
 
 ## References
 
-- [ADR 0024 — Multi-Agent System architecture](<redacted>.md) — the BFG is Phase 6
-- [ADR 0024 — Cloneable repo + local-first memory](<redacted>.md) — the `builder_memory` store + §4 isolation
-- [ADR 0016 — Trust boundary](<redacted>.md) — the rule this ADR narrowly excepts
+- [ADR 0024 — Multi-Agent System architecture](0024-multi-agent-system-architecture.md) — the BFG is Phase 6
+- [ADR 0024 — Cloneable repo + local-first memory](0024-cloneable-repo-local-first-memory.md) — the `builder_memory` store + §4 isolation
+- [ADR 0016 — Trust boundary](0016-trust-boundary-server-enforced-permissions.md) — the rule this ADR narrowly excepts
 - [migration 040](../../migrations/040_builder_karma.sql) — karma ledger (correction deltas)
 - [migration 054](../../migrations/054_builder_memory.sql) — memory schema (read + write target)