@bongos/core 1.24.78 → 1.24.80

package/.claude/skills/ask-for-help/SKILL.md

@@ -36,7 +36,7 @@ They are **complementary, not alternatives.** An owner-only task (a credential r
    ```
    Match the `github_login` or `display_name` the user named. A name with no match is a question for the user, not a guess — a wrong `needs_builder_id` sends the ask to a stranger.
 
-   Addressing a **craft** instead of a person is the alternative: `needs_craft` is one of `artist`, `builder`, `ideator`, `ui`. It reaches only builders who declared that discipline in their profile, so a craft nobody has declared reaches nobody.
+   Addressing a **craft** instead of a person is the alternative: `needs_craft` is one of `artisan`, `artist`, `ui` (the old spellings `builder`, `engineer` and `ideator` are still accepted and read as `artisan`/`artist`, task 1005141). It reaches only builders who declared that discipline in their profile, so a craft nobody has declared reaches nobody.
 
    **Exactly one addressee.** Both fields is a 400 `two_addressees`; neither is `no_addressee`. The refusal body carries the valid `crafts`.
 

package/.claude/skills/builder-sequence/SKILL.md

@@ -38,7 +38,7 @@ This skill owns the **loop and the halt discipline**. It does not re-derive how
 
 3. **Claim it** — `/builder-claim <id>`, or `node scripts/bongos/claim.js <id>`.
 
-4. **Build it** — follow the claimed task's role pack (`docs/packs/engineer.md` for engineer work). Stay strictly inside the task's `touches[]`. Everything the normal task loop requires still applies: read the acceptance criteria, work test-first, commit before shipping.
+4. **Build it** — follow the claimed task's role pack (`docs/packs/artisan.md` for engineer work). Stay strictly inside the task's `touches[]`. Everything the normal task loop requires still applies: read the acceptance criteria, work test-first, commit before shipping.
 
 5. **Ship it** — `/builder-ship`. The task must reach `shipped`, not stall at `completed` or `confirmed`. A ship that does not land has not unblocked anything, so the chain cannot advance; treat it as a halt (see `ship_failed` below).
 

package/.claude/skills/design/SKILL.md

@@ -10,7 +10,7 @@ cost: >-
   Uses your session. You see the changes on a preview before anything goes live.
 ---
 
-You are running a **UI design session**. Two things make it different from the Engineer pack (`docs/packs/engineer.md`): the work is judged **by looking at it** (so every step ends in a rendered screen, not a paragraph), and it is done **inside a world that is not yours** — the instance's, which you read first and never override. The `ui-design` module's [CLAUDE.md](../../../modules/ui-design/CLAUDE.md) is the reference; this file is the loop.
+You are running a **UI design session**. Two things make it different from the Engineer pack (`docs/packs/artisan.md`): the work is judged **by looking at it** (so every step ends in a rendered screen, not a paragraph), and it is done **inside a world that is not yours** — the instance's, which you read first and never override. The `ui-design` module's [CLAUDE.md](../../../modules/ui-design/CLAUDE.md) is the reference; this file is the loop.
 
 ## Step 0 — the tools, then the mode
 

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

@@ -114,7 +114,7 @@ node scripts/bongos/api.js POST /api/bongos/versions/<ver>/done-when --body-file
 # 5c — the seed tasks, one call each. --body-file avoids shell-quoting description/arrays.
 node scripts/bongos/api.js POST /api/bongos/tasks --body-file <path-to-task.json>
 #   {"version_id":"<ver>","goal_id":<gid>,"title":"...","description":"...",
-#    "kind":"feature|refactor|infra|spike|verify|decision","discipline":"engineer|artist|ideator|ui",
+#    "kind":"feature|refactor|infra|spike|verify|decision","discipline":"artisan|artist|ui",
 #    "priority":N,"est_minutes":N,
 #    "criterion_ids":["<slug>"],"source":"goal-create","source_ref":"goal-<gid>-R##"}
 # No needs_migration here — the create rejects it as unknown; PATCH it afterwards if the

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

@@ -23,7 +23,7 @@ The first planning session — V3 Planning Session #1, 2026-05-12 — is the tem
 - A previous planning session left proposals in `idea_inbox` tagged `kind='criterion-proposal'` that need ratification
 - **A big design-driven ask arrives — route it here BEFORE any task is seeded (task 1004675).** The tell: the owner has a design in mind (a mockup, a named model, "it should feel like…"), and the work would span several tasks. Seeding those tasks straight from chat — through `/goal-create`, `/idea-triage`, or a hand-written `POST /tasks` — skips the spec, the interview and the design binding in Phase 2, which is exactly how a build drifts from what was agreed. A single small task, or a goal whose shape is already settled and has no design to honour, does not need this.
 
-**Run an ideation pass first when the goal's SHAPE is not yet settled.** An ideator session (the [Ideator pack](../../../docs/packs/ideator.md)) inverts this skill's stance: there the human drives and you are the sounding board, so *their* framing sets the shape of the thing. Carry its output into Phase 1 and the Phase-4 interview is left with genuine residue instead of first-pass design.
+**Run an ideation pass first when the goal's SHAPE is not yet settled.** An ideation session (the ideas half of the [Artist pack](../../../docs/packs/artist.md)) inverts this skill's stance: there the human drives and you are the sounding board, so *their* framing sets the shape of the thing. Carry its output into Phase 1 and the Phase-4 interview is left with genuine residue instead of first-pass design.
 
 Not a gate — a session for work whose shape is already settled should open directly. But **Phase 4 is a poor instrument for a first pass**: an `AskUserQuestion` round must author its options before the owner has said anything, so every option encodes *your* framing, and a proposal you believe is correct never becomes a question at all. The 2026-08-16 Board Room session is the evidence — three agent proposals (a role-based voting chamber, a tiered standard-of-review override ledger, Discord reaction-voting) died in the ideation half that would otherwise have been baked into the spec as defaults, none of which would have surfaced as an interview question.
 

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`)
-- 690 operations across 85 resource groups
+- 694 operations across 85 resource groups
 
 ## Use it from your project
 

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

@@ -473,6 +473,8 @@ function createClient(opts = {}) {
       getFoundingGenesis: (args) => request("GET", "/founding/genesis", { hasBody: false }, args),
       // POST /founding/plan — rank: any-builder — POST /founding/plan
       postFoundingPlan: (args) => request("POST", "/founding/plan", { hasBody: true }, args),
+      // POST /founding/skip — rank: any-builder — POST /founding/skip
+      postFoundingSkip: (args) => request("POST", "/founding/skip", { hasBody: true }, args),
       // POST /founding/stages/{stage}/close — rank: any-builder — POST /founding/stages/:stage/close
       postFoundingStagesStageClose: (args) => request("POST", "/founding/stages/{stage}/close", { hasBody: true }, args),
       // POST /founding/start — rank: any-builder — POST /founding/start
@@ -485,6 +487,10 @@ function createClient(opts = {}) {
       getGithubOrgsOrg: (args) => request("GET", "/github/orgs/{org}", { hasBody: false }, args),
       // GET /github/repo — rank: any-builder — GET /github/repo
       getGithubRepo: (args) => request("GET", "/github/repo", { hasBody: false }, args),
+      // GET /github/repo-invite — rank: archon — GET /github/repo-invite
+      getGithubRepoInvite: (args) => request("GET", "/github/repo-invite", { hasBody: false }, args),
+      // POST /github/repo-invite — rank: archon — POST /github/repo-invite
+      postGithubRepoInvite: (args) => request("POST", "/github/repo-invite", { hasBody: true }, args),
       // POST /github/repo/visibility — rank: any-builder — POST /github/repo/visibility
       postGithubRepoVisibility: (args) => request("POST", "/github/repo/visibility", { hasBody: true }, args),
       // GET /github/repos — rank: any-builder — GET /github/repos
@@ -837,6 +843,8 @@ function createClient(opts = {}) {
       postMeCashOutsIdCancel: (args) => request("POST", "/me/cash-outs/{id}/cancel", { hasBody: true }, args),
       // POST /me/cash-outs/{id}/retry — rank: any-builder — POST /me/cash-outs/:id/retry
       postMeCashOutsIdRetry: (args) => request("POST", "/me/cash-outs/{id}/retry", { hasBody: true }, args),
+      // PUT /me/character — rank: any-builder — PUT /me/character
+      putMeCharacter: (args) => request("PUT", "/me/character", { hasBody: true }, args),
       // PATCH /me/checkout-freshness — rank: any-builder — PATCH /me/checkout-freshness
       patchMeCheckoutFreshness: (args) => request("PATCH", "/me/checkout-freshness", { hasBody: true }, args),
       // PATCH /me/core-move-seen — rank: any-builder — PATCH /me/core-move-seen

package/clients/bongos-client/index.cjs

@@ -472,6 +472,8 @@ function createClient(opts = {}) {
       getFoundingGenesis: (args) => request("GET", "/founding/genesis", { hasBody: false }, args),
       // POST /founding/plan — rank: any-builder — POST /founding/plan
       postFoundingPlan: (args) => request("POST", "/founding/plan", { hasBody: true }, args),
+      // POST /founding/skip — rank: any-builder — POST /founding/skip
+      postFoundingSkip: (args) => request("POST", "/founding/skip", { hasBody: true }, args),
       // POST /founding/stages/{stage}/close — rank: any-builder — POST /founding/stages/:stage/close
       postFoundingStagesStageClose: (args) => request("POST", "/founding/stages/{stage}/close", { hasBody: true }, args),
       // POST /founding/start — rank: any-builder — POST /founding/start
@@ -484,6 +486,10 @@ function createClient(opts = {}) {
       getGithubOrgsOrg: (args) => request("GET", "/github/orgs/{org}", { hasBody: false }, args),
       // GET /github/repo — rank: any-builder — GET /github/repo
       getGithubRepo: (args) => request("GET", "/github/repo", { hasBody: false }, args),
+      // GET /github/repo-invite — rank: archon — GET /github/repo-invite
+      getGithubRepoInvite: (args) => request("GET", "/github/repo-invite", { hasBody: false }, args),
+      // POST /github/repo-invite — rank: archon — POST /github/repo-invite
+      postGithubRepoInvite: (args) => request("POST", "/github/repo-invite", { hasBody: true }, args),
       // POST /github/repo/visibility — rank: any-builder — POST /github/repo/visibility
       postGithubRepoVisibility: (args) => request("POST", "/github/repo/visibility", { hasBody: true }, args),
       // GET /github/repos — rank: any-builder — GET /github/repos
@@ -836,6 +842,8 @@ function createClient(opts = {}) {
       postMeCashOutsIdCancel: (args) => request("POST", "/me/cash-outs/{id}/cancel", { hasBody: true }, args),
       // POST /me/cash-outs/{id}/retry — rank: any-builder — POST /me/cash-outs/:id/retry
       postMeCashOutsIdRetry: (args) => request("POST", "/me/cash-outs/{id}/retry", { hasBody: true }, args),
+      // PUT /me/character — rank: any-builder — PUT /me/character
+      putMeCharacter: (args) => request("PUT", "/me/character", { hasBody: true }, args),
       // PATCH /me/checkout-freshness — rank: any-builder — PATCH /me/checkout-freshness
       patchMeCheckoutFreshness: (args) => request("PATCH", "/me/checkout-freshness", { hasBody: true }, args),
       // PATCH /me/core-move-seen — rank: any-builder — PATCH /me/core-move-seen

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

@@ -385,6 +385,7 @@ export interface PostDoneWhenCriterionIdUnsatisfyResponse { criterion: unknown }
 export interface PostFeedbackReceiptRequest { sha256: string; kind?: "bug" | "idea" }
 export interface PostFeedbackReceiptResponse { ok: boolean; receipt: unknown; hub: unknown }
 export interface PostFoundingPlanRequest { days?: Record<string, unknown>; passes?: number; advisors?: string; government?: string; expected_builders?: number; existing?: boolean }
+export interface PostGithubRepoInviteRequest { github_login: string; permission?: string }
 export interface PostGithubRepoVisibilityRequest { repo: string; visibility: "public" | "private" }
 export interface PostGithubRepoVisibilityResponse { ok: boolean; repo: unknown; private_deployable: boolean }
 export interface PostGithubReposRequest { name: string; org?: string }
@@ -713,6 +714,8 @@ export interface PutGovernmentAsksMatterIdResponse { ok: boolean; matter_id: unk
 export interface PutGovernmentRanksRankKeyPermissionsPermissionKeyResponse { ok: boolean; rank_key: unknown; permission_key: unknown; granted: unknown }
 export interface PutGovernmentTreasuryPotsGoalIdRequest { budget_usd?: unknown }
 export interface PutMarketWatchSettingsKeyRequest { key: string }
+export interface PutMeCharacterRequest { character?: string }
+export interface PutMeCharacterResponse { character: unknown }
 export interface PutMingleOptInRequest { opted_in: boolean }
 export interface PutMingleOptInResponse { opted_in: unknown; updated_at: unknown }
 export interface PutMingleProjectRequest { enabled: boolean }
@@ -1132,6 +1135,8 @@ export interface BongosClient {
     getFoundingGenesis(args?: RequestArgs): Promise<ApiResponse>;
     /** POST /founding/plan — rank: any-builder */
     postFoundingPlan(args?: RequestArgs & { body?: PostFoundingPlanRequest }): Promise<ApiResponse>;
+    /** POST /founding/skip — rank: any-builder */
+    postFoundingSkip(args?: RequestArgs): Promise<ApiResponse>;
     /** POST /founding/stages/{stage}/close — rank: any-builder */
     postFoundingStagesStageClose(args?: RequestArgs): Promise<ApiResponse>;
     /** POST /founding/start — rank: any-builder */
@@ -1144,6 +1149,10 @@ export interface BongosClient {
     getGithubOrgsOrg(args?: RequestArgs): Promise<GetGithubOrgsOrgResponse>;
     /** GET /github/repo — rank: any-builder */
     getGithubRepo(args?: RequestArgs): Promise<GetGithubRepoResponse>;
+    /** GET /github/repo-invite — rank: archon */
+    getGithubRepoInvite(args?: RequestArgs): Promise<ApiResponse>;
+    /** POST /github/repo-invite — rank: archon */
+    postGithubRepoInvite(args: RequestArgs & { body: PostGithubRepoInviteRequest }): Promise<ApiResponse>;
     /** POST /github/repo/visibility — rank: any-builder */
     postGithubRepoVisibility(args: RequestArgs & { body: PostGithubRepoVisibilityRequest }): Promise<PostGithubRepoVisibilityResponse>;
     /** GET /github/repos — rank: any-builder */
@@ -1496,6 +1505,8 @@ export interface BongosClient {
     postMeCashOutsIdCancel(args?: RequestArgs): Promise<ApiResponse>;
     /** POST /me/cash-outs/{id}/retry — rank: any-builder */
     postMeCashOutsIdRetry(args?: RequestArgs): Promise<ApiResponse>;
+    /** PUT /me/character — rank: any-builder */
+    putMeCharacter(args?: RequestArgs & { body?: PutMeCharacterRequest }): Promise<PutMeCharacterResponse>;
     /** PATCH /me/checkout-freshness — rank: any-builder */
     patchMeCheckoutFreshness(args: RequestArgs & { body: PatchMeCheckoutFreshnessRequest }): Promise<PatchMeCheckoutFreshnessResponse>;
     /** PATCH /me/core-move-seen — rank: any-builder */

package/clients/bongos-client/index.mjs

@@ -469,6 +469,8 @@ export function createClient(opts = {}) {
       getFoundingGenesis: (args) => request("GET", "/founding/genesis", { hasBody: false }, args),
       // POST /founding/plan — rank: any-builder — POST /founding/plan
       postFoundingPlan: (args) => request("POST", "/founding/plan", { hasBody: true }, args),
+      // POST /founding/skip — rank: any-builder — POST /founding/skip
+      postFoundingSkip: (args) => request("POST", "/founding/skip", { hasBody: true }, args),
       // POST /founding/stages/{stage}/close — rank: any-builder — POST /founding/stages/:stage/close
       postFoundingStagesStageClose: (args) => request("POST", "/founding/stages/{stage}/close", { hasBody: true }, args),
       // POST /founding/start — rank: any-builder — POST /founding/start
@@ -481,6 +483,10 @@ export function createClient(opts = {}) {
       getGithubOrgsOrg: (args) => request("GET", "/github/orgs/{org}", { hasBody: false }, args),
       // GET /github/repo — rank: any-builder — GET /github/repo
       getGithubRepo: (args) => request("GET", "/github/repo", { hasBody: false }, args),
+      // GET /github/repo-invite — rank: archon — GET /github/repo-invite
+      getGithubRepoInvite: (args) => request("GET", "/github/repo-invite", { hasBody: false }, args),
+      // POST /github/repo-invite — rank: archon — POST /github/repo-invite
+      postGithubRepoInvite: (args) => request("POST", "/github/repo-invite", { hasBody: true }, args),
       // POST /github/repo/visibility — rank: any-builder — POST /github/repo/visibility
       postGithubRepoVisibility: (args) => request("POST", "/github/repo/visibility", { hasBody: true }, args),
       // GET /github/repos — rank: any-builder — GET /github/repos
@@ -833,6 +839,8 @@ export function createClient(opts = {}) {
       postMeCashOutsIdCancel: (args) => request("POST", "/me/cash-outs/{id}/cancel", { hasBody: true }, args),
       // POST /me/cash-outs/{id}/retry — rank: any-builder — POST /me/cash-outs/:id/retry
       postMeCashOutsIdRetry: (args) => request("POST", "/me/cash-outs/{id}/retry", { hasBody: true }, args),
+      // PUT /me/character — rank: any-builder — PUT /me/character
+      putMeCharacter: (args) => request("PUT", "/me/character", { hasBody: true }, args),
       // PATCH /me/checkout-freshness — rank: any-builder — PATCH /me/checkout-freshness
       patchMeCheckoutFreshness: (args) => request("PATCH", "/me/checkout-freshness", { hasBody: true }, args),
       // PATCH /me/core-move-seen — rank: any-builder — PATCH /me/core-move-seen

package/docs/adr/0274-one-kernel-three-role-packs.md

@@ -2,7 +2,7 @@
 
 **Date:** 2026-09-10
 **Context:** BONGOS-V2, goal [1000095](https://cloudbongos.com/builders#/goal/1000095) (Working area 6 — Governor / Builder / Artist / Ideator experience), criterion `wa6-kernel-and-packs`, task [1002990](https://cloudbongos.com/builders#/task/1002990). Builds on [ADR 0061](<redacted>.md) (the CLAUDE.md context budget), [ADR 0062](0062-medusa-instance-model-decoupling.md) §7 (the core ↔ host split), [ADR 0272](0272-a-craft-is-an-identity-not-a-toolchain.md) (a craft is an identity, not a toolchain) and [ADR 0271](0271-the-ideator-surface-is-two-halves.md) (which predicted this move: *"when declaration lands the contract MOVES into the Ideator pack"*). Its dependency, task 1002989, widened the module map to cover the methodology surfaces so this work had a wall to stand in.
-**Status:** Accepted.
+**Status:** Accepted. Amended by task 1005141 (BONGOS-V3, 2026-11-09): the crafts are now Artisan and Artist, with the ideator's pack folded into the artist's — two packs, not three. The kernel/pack split this records is unchanged; the prose below describes the three-pack state it decided.
 
 ## Problem
 
@@ -41,7 +41,7 @@ Three reasons, in order of weight. `docs/` is already owned by the `methodology`
 - **The ledger rule survives the split, and gets more honest.** The kernel keeps it in role-neutral form — *a change to project state is recorded in Bongos before it is made* — and each pack says what recording means for that craft. The engineer holds a claim; the ideator files the idea; the artist claims the work or records the review. The no-loopholes paragraph moves to the Engineer pack intact, where it is true.
 - **The ship card had to move with the claim.** `modules/lifecycle/ship-card.js` routed a claimed task's "Open the work" button to `/dev`, `/paint` or `/ideate`. Left alone it would have shipped a button firing a command that no longer exists — the same divergence task 1003487 fixed in the other direction. It now points at the pack, and `tests/ship_card.mjs` asserts no core craft is routed to a slash command.
 - **The ship card duplicates the registry, and a test is the shared source it cannot have.** `ship-card.js` is a module and may not require a core script across the boundary, which is why it and `claim.js` have always carried the map twice — and task 1003487 was exactly that duplication drifting. Rather than pretend the duplication away, `tests/fitness.mjs` now walks the registry entry for entry and asserts the card agrees, so a pack rename fails a test instead of shipping a hall button that opens nothing.
-- **`tests/idea_ideate_full.mjs` moved with its subject.** Its thirteen assertions pinned the Full-Idea contract in `/ideate`'s prose — the same-route rule, the never-invent rule and its reason, the five-questions-are-not-restated rule. Repointing it at `docs/packs/ideator.md` is what stops the split from deleting a guard along with the file it guarded; all thirteen pass against the pack unchanged.
+- **`tests/idea_ideate_full.mjs` moved with its subject.** Its thirteen assertions pinned the Full-Idea contract in `/ideate`'s prose — the same-route rule, the never-invent rule and its reason, the five-questions-are-not-restated rule. Repointing it at `docs/packs/artist.md` is what stops the split from deleting a guard along with the file it guarded; all thirteen pass against the pack unchanged.
 - **The line target is not yet met.** The kernel is 216 lines against a ~200 target — a `fitness.js` warning, not a failure, and the same warning it carried before at 250. The character target, which is the real per-session cost, is now cleared. Tightening the line count is the context-budget cluster's work (tasks 1003620, 1003687, 1003688), which the goal's audit sequenced explicitly behind this one.
 - **Governor is deliberately absent.** Three packs, not four, until the owner decides. The guard's floor is `>= 3`, so adding a fourth is additive and removing a third is a failure.
 - **What this unblocks.** Task 1002991 (serve composed session context from the server) and 1002992 (inject role context at start and claim) now have something to compose and inject: today the pointer is printed and read, and those tasks replace the reading with injection. Task 1003732 authors the three responsibility statements into the packs' reserved seams — the Artist pack names its own, unwritten, rather than inventing it.

package/docs/adr/0399-the-visor-is-glass-over-the-scene-and-owns-no-camera.md

@@ -0,0 +1,91 @@
+# 0399 — The visor is glass over the scene, owns no camera, and spends Escape in a fixed order
+
+- **Status:** Accepted
+- **Date:** 2026-11-10
+- **Tasks:** [task 1005146](https://cloudbongos.com/builders#/task/1005146) (this spike, BONGOS-V3 R06). It feeds [task 1005148](https://cloudbongos.com/builders#/task/1005148) (the first-person HUD, R08) and [task 1005153](https://cloudbongos.com/builders#/task/1005153) (lift the sky camera onto the city, R13).
+- **Goal:** [goal 1000142](https://cloudbongos.com/builders#/goal/1000142) — criterion `you-are-a-character-in-first-person`.
+- **Spec:** [`docs/specs/bongos-v3-game-conversion.md`](../specs/bongos-v3-game-conversion.md), section "Reuse, do not rebuild".
+- **Builds on:** [ADR 0331](0331-the-sky-is-the-ideators-home.md) (the sky and its camera), [ADR 0272](0272-a-craft-is-an-identity-not-a-toolchain.md) (a craft is identity, not authority).
+
+## 1. The question
+
+The HUD (R08) puts a first-person **visor** over the project. Inside the visor you see the city or the sky ahead, your actions on the glass, and your sprite and credits in a corner. Three scenes already draw what is "ahead", and each has its own camera and its own Escape handling:
+
+| Scene | Page | Drawn as | Camera today | Escape today |
+|---|---|---|---|---|
+| The sky | `/goal-map`, `/thinking` | `<canvas>` (`sky-draw.js`) | `SKY.S.cam` `{x, y, k}`, with `toScreen` / `toWorld` / `flyTo` / `fitAll` (`sky-layout.js:65-80`) and drag, wheel, arrow and `+`/`-`/`0` input (`sky-interaction.js:62-83`) | `sky-interaction.js:82`: tour → menu → pick. Each calls `preventDefault`. |
+| The Governor City | `/city` | SVG and spans, scaled to fit the window (`city.js`) | none. The stage is fitted on resize. | `city.js:700` closes the card. `city-decide.js:676` closes the decide panel. |
+| Home's project city | Home widget | SVG with a viewBox (`home-city.js:104-112`) | none until R13 lifts the sky camera onto it | none |
+
+Two other layers already sit above every scene: the **craft picker** (`craft-mode.js:747`, a capture listener) and the **shared dialog** (`hall-dialog.js:73-99`, a capture listener that closes the top dialog only). The **command palette** (`palette.js:462`) is a third. At the bottom is the shell's own Escape (`shell.js:663-666`). It leaves full screen one tick later, unless something has already called `preventDefault`.
+
+We have to decide two things: how the visor layers over these scenes, and where it sits in that Escape chain.
+
+## 2. The decision
+
+### 2.1 The visor is one DOM layer over the scene. It never draws inside it.
+
+- The visor is **one overlay element** (`#visor`), positioned over the page's stage. Its root has `pointer-events: none` and its controls have `pointer-events: auto`. A drag, a wheel or a click on the world goes through the glass to the scene's own listeners unchanged. The sky's pan and zoom, the city's building buttons and Home's hover all keep working without knowing the visor is there.
+- The visor **never draws inside a scene's canvas or SVG**, and no scene imports it. It is the same glass over the sky, the Governor City and Home's city. This includes the ideator's sky drawn over the city skyline (`home-city-draw.js` `skySvg`).
+- The visor **is an overlay, not layout**. Showing it, hiding it or changing its parts never changes the stage's size. The sky watches `.sky-stage` with a `ResizeObserver` and refits its camera on resize (`sky-layout.js:62-63`), so a visor that took layout space would make the camera jump.
+
+### 2.2 The visor owns no camera.
+
+- The city's camera is the sky's camera, lifted by R13. It is **not a second camera, and it is not the visor's camera.** The visor never writes `cam.x`, `cam.y` or `cam.k`.
+- A visor action that moves the view (for example "back to the centre") calls the scene's own function: `fitAll`, `flyTo`, `fitGoal`. A scene offers these by registering itself once, as `OTBVisor.scene({ name, actions })`. A scene with no camera (the Governor City until R13 reaches it) registers no movement actions, and the glass shows none. It does not show a disabled button.
+- The visor reads nothing from the camera except through those actions. This keeps the one camera API (`toScreen`, `toWorld`, `flyTo`, `fitAll`) the only one, as the spec requires.
+
+### 2.3 The stacking order, bottom to top
+
+1. **The scene**: canvas or SVG.
+2. **The visor's ambient glass**: the actions, the sprite and credits corner, and the hotkey hints. Nothing here hides the world, and it publishes its corners as CSS variables (`--visor-inset-top`, `-right`, `-bottom`, `-left`).
+3. **The scene's own pop-ups**: the sky's panel, menu and tour, the city card, the decide panel and the plates. They sit **above** the glass because they are about one thing in the world that you just touched. They place themselves inside the visor's insets, so they never cover the sprite or the credits.
+4. **The visor's open sheet**: the full action list or the hotkey sheet, when you open it.
+5. **Modals**: the palette, the craft picker and the shared dialog, which uses the browser's top layer.
+
+### 2.4 One Escape press closes exactly one layer, top first
+
+| Order | Who spends it | How it is held back from the layers below |
+|---|---|---|
+| 0 | A text field (input, textarea, select, editable) | Every listener already skips text fields. The sky blurs the field. |
+| 1 | The shared dialog: the top dialog only | capture on `document`, `preventDefault` and `stopPropagation` (existing) |
+| 2 | The craft picker | capture on `document`, `preventDefault` (existing) |
+| 3 | The command palette | `preventDefault` (existing) |
+| 4 | **The visor's open sheet** (new) | **capture on `document`, `preventDefault` and `stopPropagation` while it is open**, the dialog's pattern |
+| 5 | The scene's pop-up. Sky: tour → menu → pick. City: decide panel → card. | bubble listener and `preventDefault` (existing, except the city card, §3) |
+| 6 | **Nothing left open.** In game mode this press is the options menu's (R04). Outside game mode it is the shell's, which leaves full screen. | The options menu calls `preventDefault` so the shell leaves it alone (as the R02 session log asked). The shell reads `defaultPrevented` one tick later (existing). |
+
+There are two rules behind this table.
+
+- **A layer above the scene listens in capture and stops propagation. A scene listens in bubble and calls `preventDefault`.** A capture listener on `document` always runs before a bubble listener, so the order of layers 1 to 4 never depends on which script loaded first. The sky's handler does not check `defaultPrevented`. A visor sheet that only called `preventDefault` would therefore close and *also* unpick the star under it, so the sheet must stop propagation.
+- **The visor's ambient glass never takes an Escape.** It has nothing to close. A last Escape belongs to the options menu in game mode, or to the shell outside it. If the visor took it, Escape would have no way back to the navigation until R04 lands.
+
+### 2.5 What the visor does not do
+
+- It **never writes `hidden`** on nav or anything else. Only the rank gate writes `hidden` (`shell.js` rank gate). A character may only add `[data-craft-off]` (`craft-mode.js:194`). The visor shows the character's actions. It does not remove what rank allows.
+- It **gates nothing**. Its actions call the same routes the pages call today, and the server's rank checks answer (C3, `character-is-identity-not-authority`). An action you lack the rank for is still offered where the page offers it today, and the server refuses it with today's error.
+- It shows **credits, not payout** (`builders.total_credits`). No instance registers a money processor, so a payout readout would read empty (the spec's "What genuinely does not exist").
+- It **adds no hotkey registry**. R09 builds the registry. Until then the visor's hint lines list the scene's existing keys: `L`, `?`, `0` and `/` on the sky, and `1`–`9`, arrows and Tab on the city card. R09 then makes them rebindable.
+
+### 2.6 Where it lives
+
+The visor goes in a new `modules/hall-ui/public/visor.js`, with styles in its own sheet. A page loads it after `shell-game.js` and `shell.js`. It is **not** written into `shell.js`, which has no lines to spare under its line limit (R02 session log), in the same way `shell-game.js` was split out. The visor shows only in game mode (`html[data-game="on"]`). Outside game mode the hall looks exactly as it does today.
+
+## 3. Found while mapping: the city card's Escape also drops the bars
+
+`city.js:700` `cardKey` closes the card on Escape but **does not call `preventDefault`**. The key event goes from the card (`city.js:754`) up to `window`, where the shell's listener (`shell.js:1355`) sees a press nobody spent. One tick later it leaves full screen. On `/city` in full screen, and on every page in game mode, **one Escape closes the card and brings the sidebar back together**. That breaks the hand-off protocol this ADR depends on (§2.4, row 5). The fix is one call: `e.preventDefault()` before `closeCard()`, when a card is open. It is filed as a bug for R08 or earlier. It is not fixed in this spike, which builds nothing (ADR 0227's rule for spikes).
+
+`city-decide.js:676` and the sky (`sky-interaction.js:82`) already follow the protocol. The sky's pick case calls `preventDefault` only when something was picked or the panel was open. That is right: an Escape that closed nothing should fall through.
+
+## 4. Consequences
+
+- R08 builds one `visor.js` with no camera code and no drawing code. Its checks are: the glass passes pointers through, which a drag-pan on the sky with the visor up shows; an open sheet's Escape leaves the star picked; and in game mode the last Escape reaches the options menu, never the shell. `tests/hall_fullscreen.mjs` already drives the shell's half, and the visor's cases go beside it.
+- R13 lifts the sky camera onto Home's city **as the scene's camera**. When it does, the city registers `fitAll` and `flyTo` with the visor as actions. No visor change is needed.
+- Every new pop-up a scene adds follows row 5 (bubble listener, `preventDefault` when it closed something). Every new overlay above the scene follows rows 1 to 4 (capture listener, `stopPropagation`).
+
+## 5. Alternatives refused
+
+- **Draw the HUD into the scene's canvas or SVG.** Refused because it would mean three implementations, one per scene, and because the sky redraws on every frame its state is dirty. HUD text inside a canvas is also unreadable to a screen reader, which the sky's own list rule forbids (ADR 0331).
+- **Give the visor its own camera that drives the scene.** Refused because that is the second camera the spec names a regression.
+- **Make the visor a layout frame (a bordered box the scene shrinks into).** Refused because it changes the stage size, which refits the sky's camera every time the visor changes.
+- **Let the visor take the last Escape (for example to fold the glass away).** Refused because in game mode that press is the only way to the navigation until R04 lands. After R04 it is the options menu's.

package/docs/adr/0400-a-chain-reserves-work-and-each-sub-quest-is-still-claimed-alone.md

@@ -0,0 +1,109 @@
+# ADR 0400 — A chain reserves work; each sub-quest is still claimed on its own
+
+- **Status:** Accepted
+- **Date:** 2026-11-10
+- **Task:** [task 1005158](https://cloudbongos.com/builders#/task/1005158) — spike `V3G.R18`, goal 1000144 (BONGOS-V3, criterion `work-is-claimed-as-a-chain`)
+- **Deciders:** the owner, Lars, in the Phase 4 interview of 2026-11-07 ([`docs/specs/bongos-v3-game-conversion.md`](../specs/bongos-v3-game-conversion.md), *Interview answers*, answer 3 — the task text cites "answer 14"; the spec numbers it 3). This ADR records how that ruling is built.
+- **Builds on:** [ADR 0153](0153-sequential-chain-runner.md) (the chain runner, and its refusal of a stored order), [ADR 0097](0097-one-active-claim-per-session-and-worktree-binding.md) (one active claim per session), [ADR 0015](0015-task-dependencies-and-auto-promotion.md) (dependencies are the order), [ADR 0226](0226-one-stale-timer-reporting-degrades-enforcement-refuses.md) (report before you act).
+- **Gates:** task 1005159 (R19, the migration), task 1005160 (R20, reserve + claim), R21 (raid vs routine), R22 (chains replace the flat list).
+
+## Context
+
+The game conversion's criterion C5 says work is claimed as a chain with sub-quests beneath it, not picked from a flat table. A chain *reserves* the work and *orders* it; each sub-quest is still claimed one at a time through the existing checks. The proof: a raid chain that needs two Artisans refuses a single claimer and admits the second; a routine chain admits one.
+
+Today nothing can hold a group of tasks:
+
+- **Claiming is strictly per task.** `claimTasksBatch` (`modules/lifecycle/db-claims.js`) is N independent claims with N worktrees, and all-or-nothing — a successor fails `DEPS_NOT_SHIPPED` until its predecessor ships, so a dependency chain can never be batch-claimed.
+- **`gateOneActiveClaimPerSession`** (`modules/lifecycle/routes/claims.js`, ADR 0097) refuses a second claim into the same working tree, fail-closed, backed by the unique index `uniq_active_claim_per_session`. It exists so two tasks' commits never ride out under one ship. Holding a chain *as claims* would collide with it by design.
+- **`goal_members`** grants eligibility to claim a goal's tasks forever. It is not a reservation, and a goal is a working area (ten of them, ADR 0264) — far larger than a chain.
+- **`scripts/bongos/sequence.js`** already walks a chain (ADR 0153): it orders a scope topologically and claims each link in turn. It reserves nothing: anyone else can claim the next link first.
+
+ADR 0153 also rejected a `chain_id` or queue column as "a second, drift-prone source of truth" for order. That rejection still holds, and this design keeps it: the new row stores *who holds the work*, never *what order it runs in*.
+
+## Decision
+
+### D1 — Three new tables; none of them is a claim
+
+Built by R19 (task 1005159), in the `lifecycle` module's migrations:
+
+| Table | Columns (sketch) | Purpose |
+|---|---|---|
+| `chains` | `id`, `goal_id NOT NULL → goals`, `title`, `status` (`open` \| `reserved` \| `done` \| `abandoned`), `created_by`, `created_at`, `reserved_at` | The chain itself. Lives inside exactly one goal, so the city's "goal = building" and the goal-membership rung keep working unchanged. |
+| `chain_tasks` | `chain_id`, `task_id`, PK both | Which tasks are its sub-quests. A partial unique index keeps a task in **at most one** non-terminal chain. Every member task must carry the chain's `goal_id` (checked on write). |
+| `chain_party` | `chain_id`, `builder_id`, `craft` (`artisan` \| `artist`), `joined_at`, `left_at` | Who holds the reservation. An open row (`left_at IS NULL`) is a party member. |
+
+There is **no order column, no "current step" column, and no foreign key from `claims`**. The raid/routine policy columns (required Artisans and Artists, compare-or-split) are R21's to add; this ADR only fixes that they live on `chains`.
+
+### D2 — Order is derived, never stored
+
+A chain's sub-quest order is the topological order of `task_dependencies` restricted to the chain's members, ties broken by priority, then calibrated estimate, then id — exactly `topoOrder` in `scripts/bongos/sequence.js` today. R20 moves that function into one shared pure module so the CLI runner, the server's chain read and the hall all compute the same order and cannot disagree.
+
+- **The next sub-quest** is the first one in that order whose status is `ready`. Shipping a sub-quest already promotes its dependents (the `promote_dependents_on_ship` trigger), so the chain advances by itself with no write to the chain row.
+- **A dependency outside the chain still blocks.** The claim gate's `DEPS_NOT_SHIPPED` refuses it as today, and the chain read reports it as waiting on outside work rather than skipping it (ADR 0153's "halt, do not skip").
+- **Re-ordering a chain means editing dependencies**, the one place order already lives.
+
+### D3 — Reserving is not claiming
+
+Reserving a chain writes a `chain_party` row and sets `chains.status = 'reserved'`. It writes no `claims` row, binds no session and creates no worktree. Consequently:
+
+- `gateOneActiveClaimPerSession` and its unique index have nothing new to see. A builder holding a reserved chain and one claimed sub-quest has **one** active claim, in **one** worktree — exactly the shape ADR 0097 enforces.
+- The stale-claim sweeper (ADR 0226) is untouched; it still releases idle *claims*, never reservations.
+- `claimTasksBatch` is not used for chains and does not change.
+
+### D4 — Every sub-quest is claimed through the existing door
+
+A party member claims a sub-quest with the ordinary `POST /api/gds/claims`, from the hall through the shared `claim-action.js` client, or from the CLI through `claim.js`. Every rung of the refusal ladder runs, in the same order, with the same codes and messages: inactive builder, rebase owed, not found, not ready, open blocker, rank, required rank, goal membership, relevance hold, needs, dependencies, overlap, module-disjointness — and, ahead of the route handler, the one-claim-per-session guard and the newcomer gate. A party member at too low a rank for a sub-quest is refused by the rank rung, not by the chain. **Character is not authority** (C3): joining a party never admits a claim the ladder would refuse.
+
+### D5 — The one addition: a reserved chain refuses outsiders, at the end of the ladder
+
+A reservation that anyone can walk around is not a reservation. So R20 adds one check: **a task in a reserved chain refuses a claimer who is not in that chain's party** (`409 CHAIN_RESERVED`, naming the chain and how to ask to join).
+
+It is placed **after the last existing rung**, and built the way the goal-membership, relevance and needs checks are: one extracted function called from both `INSERT INTO claims` sites (`claimTask` and `claimTasksBatch`) and from the dry-run twin, so the batch path cannot bypass it.
+
+This is what "the claim ladder is untouched" means here, stated precisely so a reviewer can check it:
+
+1. **No existing rung moves, changes its code, or changes its message.** Every existing ladder test stays green with no edit.
+2. **The new check can only refuse more, never admit more.** It runs only after every existing rung has said yes.
+3. **Everyone who is refused today is refused with the same answer.** Because it runs last, an outsider who also lacks rank, membership or a shipped dependency still sees *that* refusal, not `CHAIN_RESERVED`.
+4. **A task in no chain, or in an open (unreserved) chain, is not affected at all.**
+
+The claimable feed applies the same rule up front, the way it decorates goal membership: a reserved chain's sub-quests show to outsiders as "held by a party — ask to join", never as claimable.
+
+### D6 — Party size is refused at the chain's door, not the claim's
+
+Joining a chain (`POST /chains/:id/join`, R20) is a separate door with its own refusals, so party rules never reach the claim ladder:
+
+- **Routine** (R21's default): the first joiner reserves it and can work it alone; more may join and work independent sub-quests in parallel, each in their own worktree.
+- **Raid:** the chain declares how many Artisans and Artists it needs. Until the party is full, its sub-quests refuse claims with `CHAIN_RESERVED` (reason `raid_quorum_unmet`) — the single Artisan is refused, the second is admitted, and the raid opens. This is the C5 proof.
+- A member's craft for counting seats is their chosen character, which only decides *which seat they fill*. It is never read by a claim rung.
+
+### D7 — A reservation lapses; it is reported first and acted on second
+
+A reserved chain whose party holds no active claim in it and has shipped nothing in it for a lapse window returns to `open`, and its party rows are closed. It never releases a claim — claims keep their own sweeper. Following ADR 0226, the lapse is shown on the chain (and to its party) before it fires, and the sweep that frees it refuses to run on an unreadable window rather than guess. The window's length is R20's to set; it is measured in days, not the claim timer's hours, because a chain outlives any one sub-quest.
+
+### D8 — One person working a chain is ADR 0153, scoped
+
+`/builder-sequence` gains a `--chain N` scope that reads D2's order. One builder, one worktree, one claim at a time, ship then claim the next — today's runner, now walking a chain they hold so nobody can take the next link from under them.
+
+## Rejected
+
+- **A chain as N claims.** Holding every sub-quest as a claim row breaks ADR 0097 (two tasks' commits in one tree, one commingled ship) and cannot even be built: successors refuse `DEPS_NOT_SHIPPED` until their predecessor ships.
+- **Changing `gateOneActiveClaimPerSession` to let a chain hold several claims.** That guard is fail-closed because a wrong answer ships unreviewed work. Loosening it to buy a feature is the largest risk in the whole conversion; the owner's ruling removes it, and this design never needs it.
+- **A chain as a goal.** Goals are working areas, and goal membership is permanent eligibility. A chain is smaller, temporary and exclusive — three things a goal is not.
+- **A stored order** (`position`, `next_task_id`). ADR 0153's rejection holds: the dependency edges are the order, and a second copy drifts.
+- **Putting the chain check early in the ladder.** It would mask rank, membership and dependency refusals behind `CHAIN_RESERVED`, changing the answer an existing refusal gives. Last place is what keeps every existing answer unchanged.
+- **A feed-only reservation** with no claim-time check. Claim-by-id walks straight past the feed — the exact trap task 1002650 closed for open blockers.
+
+## Consequences
+
+- **R19 (task 1005159)** — the three tables in D1, with the one-open-chain-per-task index. No change to `claims`, its indexes, or any claim function.
+- **R20 (task 1005160)** — reserve and join; the shared order module (D2); the end-of-ladder check (D5) on both insert sites, the dry run and the feed; the lapse sweep (D7); `--chain` on the runner (D8). Its tests must include: every existing ladder test unchanged; an outsider refused `CHAIN_RESERVED` on a reserved chain; an outsider without rank still sees the rank refusal; a party member's one-claim-per-session refusal unchanged.
+- **R21** — raid vs routine columns and the join-door refusals (D6), carrying the C5 proof.
+- **R22** — the hall lists chains, not tasks, reading the feed decoration from D5.
+- **Protected scope.** D5 touches `modules/lifecycle/db-claims.js`, a Metic-floor path; R20 is Metic work.
+
+## Open questions (for R20/R21, not decided here)
+
+1. The lapse window's length (D7).
+2. Whether a goal owner may add sub-quests to a reserved chain (order recomputes either way, so it is a policy question, not a schema one).
+3. What a raid does when a member leaves mid-run: pause the remaining sub-quests behind `raid_quorum_unmet` again, or let in-flight work finish.

package/docs/adr/0401-one-options-menu-opens-every-settings-screen-in-a-frame.md

@@ -0,0 +1,53 @@
+# 0401 — One options menu, which opens every settings screen in a frame
+
+- **Status:** Accepted
+- **Date:** 2026-11-10
+- **Task:** [task 1005144](https://cloudbongos.com/builders#/task/1005144) (BONGOS-V3 R04)
+- **Goal:** [goal 1000141](https://cloudbongos.com/builders#/goal/1000141) — criterion `game-opens-not-navigates`
+- **Spec:** [`docs/specs/bongos-v3-game-conversion.md`](../specs/bongos-v3-game-conversion.md) (R04; "Reuse, do not rebuild": the settings panel seam and the task 1005044 move to My agents)
+- **Builds on:** [ADR 0399](0399-the-visor-is-glass-over-the-scene-and-owns-no-camera.md) §2.4 row 6 (in game mode the last Escape is the options menu's), [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (the routes are the wall)
+
+## 1. The question
+
+The criterion: every setting and configuration is reachable from **one** vertical, grouped menu with a smart search, and no surface that used to be a sidebar link keeps an interface of its own. The owner chose to fold in all seven places a setting lived: Settings itself, My agents, Project settings, Modules, Permissions (with the Constitution), and Market Watch's settings and its rules.
+
+Those six other screens are not small. Permissions alone is two rooms, eight sections and nine gated data routes; each screen has its own script, its own server page gate and its own tests. The question is how they come into one menu without rebuilding them, and without weakening a single gate.
+
+## 2. The decision
+
+### 2.1 The menu is the Settings page
+
+`/settings` is the options menu (`options-menu.js`). Its left rail is a search box over a grouped list. Settings' own panels stay where they were, as the menu's **native** entries (Account, Access and keys, Preferences, Sound, Software update, Extensions). The profile chip already opened `/settings`, every doc and skill already links `/settings#cli` and friends, and all of those keep working.
+
+### 2.2 The other six screens open inside it, in a frame
+
+Each is an **embedded** entry: the menu appends a `<section>` holding an `<iframe>` of the old address with `?embed=1`, the first time that entry opens (so a screen's reads are paid only when someone asks for it). One script every hall page already loads first, `shell-game.js`, reads `?embed=1` **only when the page really is inside a frame** and then:
+
+- stamps `html[data-embed="on"]`, which hides the sidebar, scrim, foot and top bar (`style.css`);
+- turns the full-screen switch off for that page (no corner button, no Escape-to-leave);
+- sends an Escape nobody used to the menu (`parent.OTBOptions.escape()`);
+- opens a link to *another* page in the whole window (`target="_top"`), while a link within the page stays in the frame.
+
+The screens themselves change by nothing, except Market Watch: its owner-only Settings tab (task 1005045) is gone, and in the frame the page shows that panel alone.
+
+### 2.3 Every old address leads into the menu, and every gate stays where it was
+
+`serve-internal.js` `RETIRED_TO_OPTIONS` sends a plain visit to `/my-agents`, `/project-settings`, `/modules`, `/government`, `/market-watch-rules` or `/market-watch-settings` to `/settings?open=<entry>` (302, no gate, like the other retired-page redirects). The Location carries no fragment, so the browser keeps the old `#anchor`: `/my-agents#talk` lands on `/settings?open=my-agents#talk`. The framed request (`?embed=1`) passes through to the page **and its own page gate**: `/government?embed=1` still meets `requireGovernmentPage`, and every data route keeps its own atom. The menu lists an entry only for the rank the sidebar showed its page to (the same keys as `gateAllows`), which is cosmetic, as the sidebar was.
+
+### 2.4 Game mode's last Escape is the menu's
+
+ADR 0399 reserved it. In game mode an Escape no dialog, picker, palette or page used opens the menu (`/settings?from=<where you were>`); on the menu, or inside one of its frames, it closes the menu and goes back to `from`. It is judged after the dispatch and marked used before the shell's own check, so the bars do not flash back. Outside game mode nothing about Escape changed. The corner button is still the way to bring the bars back.
+
+## 3. Consequences
+
+- The sidebar loses My agents, Project settings, Permissions and Modules; the profile chip says "Options". The palette's My agents rows open the menu; its Government rows are gone (the menu's search finds them, for the ranks that may).
+- A new settings screen joins the menu as one `MENU` entry in `options-menu.js` (and, if it was a page, one row in each redirect map — `tests/hall_options_menu.mjs` holds the two maps equal).
+- The frame is a second document: its own dialogs, toasts and scroll live inside it. That is the price of reusing the screens as they are; a screen that needs the whole window can always send a link to `_top`.
+- **Sounds are switched off** (task 1004554), so the criterion's proof "change a sound preference" reaches the Sound entry and its note, not a working toggle, until sounds come back.
+
+## 4. Alternatives refused
+
+- **Move every screen's markup and script into `settings.html`.** Seven pages' scripts on one page, all booting at once, with id collisions to rename (the Watch tabs, task 1005049, paid that for two small pages). Permissions alone would have doubled the page. Refused for size, risk and the boot cost on the one page every builder opens to change a setting.
+- **A new `/options` page beside Settings.** Two homes for settings is the problem being solved; every existing `/settings#…` link would need a second redirect.
+- **Leave Permissions and Market Watch rules as links out of the menu.** Offered; the owner chose all seven, because a link out is still a surface with its own interface.
+- **Load the screens into the menu with `fetch` and inject them.** The pages boot on `DOMContentLoaded`, which has already fired; every script would need a second boot path. The frame gives each its own document for free.

package/docs/adr/README.md

@@ -514,3 +514,6 @@ These 20 numbers are each shared by exactly two files. They are **accepted histo
 | 0395 | [**A task says what it needs, and each person's lists show only what they can do** ([task 1004950](https://cloudbongos.com/builders#/task/1004950)). `tasks.needs` ⊆ {owner, server} is its own set, not an `automation_tag` value (that one says whether work runs unattended). Capabilities are read fresh like rank: `owner` from the owner seat (founding builder fallback, the UAT reading), `server` from `builders.capability_grants`, set only by the owner. The recommend lists (claimable feed, optimizer, autonomous runner) show only tasks whose needs the viewer holds; the runner never holds owner. The claim refuses only `server` (`NEEDS_SERVER_ACCESS`, all three surfaces). Visibility elsewhere is unchanged; the board filters by need.](0395-a-task-says-what-it-needs-and-lists-show-only-what-you-can-do.md) | lifecycle / work tracking |
 | 0397 | [**The payment rail is Stripe Connect, one connected account per project; J.P. Morgan Payments is the fallback** ([task 1004906](https://cloudbongos.com/builders#/task/1004906), goal 1000092). The owner chose Stripe on 2026-10-30. Each project holds its money in its own connected account and each payee has one, so Cloud Bongos holds nothing (ADR 0385). Every flow in the ADR 0385 map is named against a Stripe primitive; a processor adapter module is the only place that names Stripe, so the fallback replaces one adapter. The processor is the party that monitors the money it holds. Test mode first; no live key is created, and counsel items 1 to 4 still gate real money.](0397-the-payment-rail-is-stripe-connect-with-one-connected-account-per-project.md) | economy / payments |
 | 0398 | [**Every hosted project takes its own update, and nobody asks for one** ([task 1005128](https://cloudbongos.com/builders#/task/1005128)). "Ask for this upgrade" is gone from every hall. A hosted hall with no upgrade address still names its hub door, by its own web address (`/deploy?host=`), which the hub resolves among the visitor's own projects; every core move writes the missing address into the project's settings. A self-hosted instance keeps the `bongos upgrade` instruction.](0398-every-hosted-project-takes-its-own-update-and-nobody-asks-for-one.md) | upgrades / hosting |
+| 0399 | [**The visor is glass over the scene, owns no camera, and spends Escape in a fixed order** ([task 1005146](https://cloudbongos.com/builders#/task/1005146), goal 1000142). The first-person HUD is one DOM overlay (`visor.js`, game mode only) over the sky, the Governor City and Home's city. It passes pointers through, never draws inside a scene and never changes the stage's size. It writes no camera: it calls the scene's own `fitAll`/`flyTo`, which the scene registers. Stacking: scene → ambient glass → the scene's pop-ups → the visor's open sheet → modals. One Escape closes one layer, top first: dialog, picker, palette, visor sheet (capture listener, `stopPropagation`), the scene's pop-up (bubble listener, `preventDefault`), then the options menu in game mode or the shell outside it. Found: the city card's Escape does not call `preventDefault`, so it also drops the bars.](0399-the-visor-is-glass-over-the-scene-and-owns-no-camera.md) | hall / game frame |
+| 0401 | [**One options menu opens every settings screen in a frame** ([task 1005144](https://cloudbongos.com/builders#/task/1005144), goal 1000141). `/settings` is the options menu: a search box over a grouped list. Settings' own panels stay native; My agents, Project settings, Modules, Permissions and Market Watch's settings and rules open inside it in an `<iframe>` of the old address with `?embed=1`, which `shell-game.js` reads only inside a frame to drop the page's chrome, send an unused Escape to the menu and open links to other pages in the whole window. A plain visit to an old address 302s to `/settings?open=<entry>` (the old #anchor rides along); the framed request keeps its own page gate and routes. In game mode the last Escape opens the menu and closes it again. Rejected: merging seven pages' scripts into one, a second /options page, links out of the menu.](0401-one-options-menu-opens-every-settings-screen-in-a-frame.md) | hall / game frame |
+| 0400 | [**A chain reserves work; each sub-quest is still claimed on its own** ([task 1005158](https://cloudbongos.com/builders#/task/1005158), spike V3G.R18, goal 1000144). C5 of the game conversion: work is claimed as a chain, not picked from a flat table. Owner ruling (interview answer 3): a chain RESERVES, tasks are still claimed one at a time. **Decision:** three new tables (`chains` inside one goal, `chain_tasks` with a task in at most one open chain, `chain_party`), none of them a claim — no `claims` row, no session binding, no worktree — so `gateOneActiveClaimPerSession` (ADR 0097) and its unique index never see a chain. **Order is derived, never stored** (ADR 0153's rejection holds): the topological order of `task_dependencies` over the chain's members, ties by priority/estimate/id — `sequence.js`'s `topoOrder`, moved into one shared module. Every sub-quest claims through the unchanged `POST /claims` ladder. **The one addition** is a narrowing-only `CHAIN_RESERVED` check placed AFTER the last existing rung on both insert sites + the dry run + the feed: an outsider can't claim a reserved chain's sub-quest, while every existing refusal keeps its code, message and precedence. Party size (raid quorum vs routine) is refused at the chain's own join door, never in the claim ladder; character counts seats and is never read by a claim rung. A reservation lapses after days with no claim or ship, reported before it acts (ADR 0226). Rejected: a chain as N claims, loosening the session guard, chain = goal, a stored order, an early-ladder check (would mask rank/deps refusals), a feed-only reservation.](0400-a-chain-reserves-work-and-each-sub-quest-is-still-claimed-alone.md) | lifecycle / claims / game conversion |