@bongos/core 1.17.0 → 1.17.2

package/clients/bongos-client/index.cjs

@@ -1,6 +1,9 @@
-// @cloudbongos/client (CommonJS build) — GENERATED from index.mjs by
+// @bongos/client (CommonJS build) — GENERATED from index.mjs by
 // scripts/gds/gen-api-client.js. DO NOT EDIT BY HAND. Same behavior as the ESM
 // build; only the module bindings differ. For require()-based consumers.
+// @bongos/client — GENERATED from the OpenAPI spec by
+// scripts/gds/gen-api-client.js (task 1995 / ADR 0118). DO NOT EDIT BY HAND —
+// regenerate on spec change. Zero deps; uses the platform fetch.
 'use strict';
 
 const API_VERSION = "v1";
@@ -303,10 +306,14 @@ function createClient(opts = {}) {
       patchGoalsIdMembersBuilderId: (args) => request("PATCH", "/goals/{id}/members/{builderId}", { hasBody: true }, args),
       // POST /goals/{id}/reopen — rank: metic+archon — POST /goals/:id/reopen
       postGoalsIdReopen: (args) => request("POST", "/goals/{id}/reopen", { hasBody: true }, args),
+      // GET /goals/{id}/requests — rank: any-builder — GET /goals/:id/requests
+      getGoalsIdRequests: (args) => request("GET", "/goals/{id}/requests", { hasBody: false }, args),
       // POST /goals/{id}/requests — rank: any-builder — POST /goals/:id/requests
       postGoalsIdRequests: (args) => request("POST", "/goals/{id}/requests", { hasBody: true }, args),
       // POST /goals/{id}/requests/{reqId}/respond — rank: any-builder — POST /goals/:id/requests/:reqId/respond
       postGoalsIdRequestsReqIdRespond: (args) => request("POST", "/goals/{id}/requests/{reqId}/respond", { hasBody: true }, args),
+      // POST /goals/{id}/requests/{reqId}/withdraw — rank: any-builder — POST /goals/:id/requests/:reqId/withdraw
+      postGoalsIdRequestsReqIdWithdraw: (args) => request("POST", "/goals/{id}/requests/{reqId}/withdraw", { hasBody: true }, args),
       // POST /goals/{id}/scope — rank: metic+archon — POST /goals/:id/scope
       postGoalsIdScope: (args) => request("POST", "/goals/{id}/scope", { hasBody: true }, args),
       // POST /goals/{id}/tasks — rank: any-builder — POST /goals/:id/tasks
@@ -439,6 +446,8 @@ function createClient(opts = {}) {
       postModulesKeyEnable: (args) => request("POST", "/modules/{key}/enable", { hasBody: true }, args),
       // POST /modules/{key}/submit — rank: metic+archon — POST /modules/:key/submit
       postModulesKeySubmit: (args) => request("POST", "/modules/{key}/submit", { hasBody: true }, args),
+      // GET /modules/submissions — rank: metic+archon — GET /modules/submissions
+      getModulesSubmissions: (args) => request("GET", "/modules/submissions", { hasBody: false }, args),
     },
     "overrideRequests": {
       // GET /override-requests — rank: archon — GET /override-requests
@@ -453,6 +462,8 @@ function createClient(opts = {}) {
       getProvisioningFleetCostLedger: (args) => request("GET", "/provisioning/fleet/cost-ledger", { hasBody: false }, args),
       // GET /provisioning/github-app/callback — rank: public — GET /provisioning/github-app/callback
       getProvisioningGithubAppCallback: (args) => request("GET", "/provisioning/github-app/callback", { hasBody: false }, args),
+      // GET /provisioning/github-app/status — rank: public — GET /provisioning/github-app/status
+      getProvisioningGithubAppStatus: (args) => request("GET", "/provisioning/github-app/status", { hasBody: false }, args),
       // GET /provisioning/health — rank: public — GET /provisioning/health
       getProvisioningHealth: (args) => request("GET", "/provisioning/health", { hasBody: false }, args),
       // GET /provisioning/instances — rank: any-builder — GET /provisioning/instances
@@ -467,6 +478,8 @@ function createClient(opts = {}) {
       postProvisioningInstancesIdGithubApp: (args) => request("POST", "/provisioning/instances/{id}/github-app", { hasBody: true }, args),
       // POST /provisioning/instances/{id}/teardown — rank: any-builder — POST /provisioning/instances/:id/teardown
       postProvisioningInstancesIdTeardown: (args) => request("POST", "/provisioning/instances/{id}/teardown", { hasBody: true }, args),
+      // GET /provisioning/onboard-plan — rank: public — GET /provisioning/onboard-plan
+      getProvisioningOnboardPlan: (args) => request("GET", "/provisioning/onboard-plan", { hasBody: false }, args),
       // GET /provisioning/tls-check — rank: public — GET /provisioning/tls-check
       getProvisioningTlsCheck: (args) => request("GET", "/provisioning/tls-check", { hasBody: false }, args),
     },

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

@@ -1,4 +1,4 @@
-// GENERATED — TypeScript types for @cloudbongos/client (task 1995; field-level
+// GENERATED — TypeScript types for @bongos/client (task 1995; field-level
 // request typing added in task 2050 / ADR 0118). DO NOT EDIT BY HAND.
 export declare const API_VERSION: string;
 export declare const DEFAULT_BASE_URL: string;
@@ -34,6 +34,7 @@ export interface GetDemoHealthResponse { module: unknown; ok: boolean; coreVersi
 export interface GetDiscordChannelsPlanResponse { ok: boolean; guild_id: unknown; op_count: unknown; ops: unknown; warnings: unknown }
 export interface GetDoneWhenPendingReviewResponse { criteria: unknown; count: unknown }
 export interface GetGoalsIdConflictsResponse { ok: boolean; goal_id: unknown; conflicts: unknown; cross_goals_considered: unknown }
+export interface GetGoalsIdRequestsResponse { requests: unknown }
 export interface GetGoalsIdResponse { goal: unknown; members: unknown; criteria: unknown; dependencies: unknown }
 export interface GetGoalsResponse { goals: unknown }
 export interface GetGradesByBuilderResponse { window_days: unknown; builders: unknown }
@@ -54,11 +55,14 @@ export interface GetMemoryBfgBuildersBuilderIdFilesResponse { builder_id: unknow
 export interface GetMemoryFileResponse { builder_id: unknown; path: unknown; content: unknown; sha256: unknown; byte_len: unknown; mtime: unknown; updated_at: unknown; created_at: unknown }
 export interface GetMemoryFilesResponse { builder_id: unknown; count: unknown; files: unknown }
 export interface GetModulesResponse { modules: unknown; own_built: unknown; core_loaded: unknown; submit_pipeline_live: boolean }
+export interface GetModulesSubmissionsResponse { submissions: unknown }
 export interface GetOverrideRequestsResponse { requests: unknown }
 export interface GetProvisioningFleetResponse { instances: unknown }
+export interface GetProvisioningGithubAppStatusResponse { ok: boolean; status: unknown; ready: unknown; terminal: unknown; domain: unknown; instance_status: unknown }
 export interface GetProvisioningHealthResponse { module: unknown; ok: boolean; coreVersion: unknown }
 export interface GetProvisioningInstancesIdResponse { instance: unknown; open_intent: unknown }
 export interface GetProvisioningInstancesResponse { instances: unknown }
+export interface GetProvisioningOnboardPlanResponse { mode: unknown; steps: unknown }
 export interface GetPublicBlockersIdResponse { blocker: unknown }
 export interface GetPublicBountyTableResponse { table: unknown; currency: unknown }
 export interface GetPublicGradesResponse { window_days: unknown; rolling: unknown; trend: unknown; threshold: unknown; grader_version: unknown }
@@ -177,6 +181,7 @@ export interface PostGoalsIdMembersResponse { ok: boolean; member: unknown }
 export interface PostGoalsIdReopenResponse { ok: boolean; goal: unknown }
 export interface PostGoalsIdRequestsReqIdRespondRequest { action: string }
 export interface PostGoalsIdRequestsReqIdRespondResponse { ok: boolean; action: unknown; request: unknown; member?: unknown }
+export interface PostGoalsIdRequestsReqIdWithdrawResponse { ok: boolean; request: unknown }
 export interface PostGoalsIdRequestsRequest { note?: string }
 export interface PostGoalsIdRequestsResponse { ok: boolean; request: unknown }
 export interface PostGoalsIdScopeRequest { add: string[] }
@@ -205,6 +210,8 @@ export interface PostMemoryBuildersBuilderIdBfgWriteResponse { ok: boolean; buil
 export interface PostMemorySyncRequest { files?: unknown[] }
 export interface PostModulesKeyEnableRequest { enabled?: unknown }
 export interface PostModulesKeyEnableResponse { ok: boolean; key: unknown; enabled: unknown; note: unknown }
+export interface PostModulesKeySubmitRequest { signed_by?: string }
+export interface PostModulesKeySubmitResponse { ok: boolean; submission: unknown }
 export interface PostOverrideRequestsIdDecideRequest { decision: string; note?: string }
 export interface PostProvisioningInstancesIdForceTeardownResponse { ok: boolean; queued: unknown; action: unknown; status: unknown; message: unknown }
 export interface PostProvisioningInstancesIdGithubAppRequest { account?: string }
@@ -483,10 +490,14 @@ export interface BongosClient {
     patchGoalsIdMembersBuilderId(args: RequestArgs & { body: PatchGoalsIdMembersBuilderIdRequest }): Promise<PatchGoalsIdMembersBuilderIdResponse>;
     /** POST /goals/{id}/reopen — rank: metic+archon */
     postGoalsIdReopen(args?: RequestArgs): Promise<PostGoalsIdReopenResponse>;
+    /** GET /goals/{id}/requests — rank: any-builder */
+    getGoalsIdRequests(args?: RequestArgs): Promise<GetGoalsIdRequestsResponse>;
     /** POST /goals/{id}/requests — rank: any-builder */
     postGoalsIdRequests(args?: RequestArgs & { body?: PostGoalsIdRequestsRequest }): Promise<PostGoalsIdRequestsResponse>;
     /** POST /goals/{id}/requests/{reqId}/respond — rank: any-builder */
     postGoalsIdRequestsReqIdRespond(args: RequestArgs & { body: PostGoalsIdRequestsReqIdRespondRequest }): Promise<PostGoalsIdRequestsReqIdRespondResponse>;
+    /** POST /goals/{id}/requests/{reqId}/withdraw — rank: any-builder */
+    postGoalsIdRequestsReqIdWithdraw(args?: RequestArgs): Promise<PostGoalsIdRequestsReqIdWithdrawResponse>;
     /** POST /goals/{id}/scope — rank: metic+archon */
     postGoalsIdScope(args: RequestArgs & { body: PostGoalsIdScopeRequest }): Promise<PostGoalsIdScopeResponse>;
     /** POST /goals/{id}/tasks — rank: any-builder */
@@ -618,7 +629,9 @@ export interface BongosClient {
     /** POST /modules/{key}/enable — rank: metic+archon */
     postModulesKeyEnable(args?: RequestArgs & { body?: PostModulesKeyEnableRequest }): Promise<PostModulesKeyEnableResponse>;
     /** POST /modules/{key}/submit — rank: metic+archon */
-    postModulesKeySubmit(args?: RequestArgs): Promise<ApiResponse>;
+    postModulesKeySubmit(args?: RequestArgs & { body?: PostModulesKeySubmitRequest }): Promise<PostModulesKeySubmitResponse>;
+    /** GET /modules/submissions — rank: metic+archon */
+    getModulesSubmissions(args?: RequestArgs): Promise<GetModulesSubmissionsResponse>;
   };
   "overrideRequests": {
     /** GET /override-requests — rank: archon */
@@ -633,6 +646,8 @@ export interface BongosClient {
     getProvisioningFleetCostLedger(args?: RequestArgs): Promise<ApiResponse>;
     /** GET /provisioning/github-app/callback — rank: public */
     getProvisioningGithubAppCallback(args?: RequestArgs): Promise<ApiResponse>;
+    /** GET /provisioning/github-app/status — rank: public */
+    getProvisioningGithubAppStatus(args?: RequestArgs): Promise<GetProvisioningGithubAppStatusResponse>;
     /** GET /provisioning/health — rank: public */
     getProvisioningHealth(args?: RequestArgs): Promise<GetProvisioningHealthResponse>;
     /** GET /provisioning/instances — rank: any-builder */
@@ -647,6 +662,8 @@ export interface BongosClient {
     postProvisioningInstancesIdGithubApp(args?: RequestArgs & { body?: PostProvisioningInstancesIdGithubAppRequest }): Promise<PostProvisioningInstancesIdGithubAppResponse>;
     /** POST /provisioning/instances/{id}/teardown — rank: any-builder */
     postProvisioningInstancesIdTeardown(args?: RequestArgs): Promise<PostProvisioningInstancesIdTeardownResponse>;
+    /** GET /provisioning/onboard-plan — rank: public */
+    getProvisioningOnboardPlan(args?: RequestArgs): Promise<GetProvisioningOnboardPlanResponse>;
     /** GET /provisioning/tls-check — rank: public */
     getProvisioningTlsCheck(args?: RequestArgs): Promise<ApiResponse>;
   };

package/clients/bongos-client/index.mjs

@@ -1,4 +1,4 @@
-// @cloudbongos/client — GENERATED from the OpenAPI spec by
+// @bongos/client — GENERATED from the OpenAPI spec by
 // scripts/gds/gen-api-client.js (task 1995 / ADR 0118). DO NOT EDIT BY HAND —
 // regenerate on spec change. Zero deps; uses the platform fetch.
 'use strict';
@@ -303,10 +303,14 @@ export function createClient(opts = {}) {
       patchGoalsIdMembersBuilderId: (args) => request("PATCH", "/goals/{id}/members/{builderId}", { hasBody: true }, args),
       // POST /goals/{id}/reopen — rank: metic+archon — POST /goals/:id/reopen
       postGoalsIdReopen: (args) => request("POST", "/goals/{id}/reopen", { hasBody: true }, args),
+      // GET /goals/{id}/requests — rank: any-builder — GET /goals/:id/requests
+      getGoalsIdRequests: (args) => request("GET", "/goals/{id}/requests", { hasBody: false }, args),
       // POST /goals/{id}/requests — rank: any-builder — POST /goals/:id/requests
       postGoalsIdRequests: (args) => request("POST", "/goals/{id}/requests", { hasBody: true }, args),
       // POST /goals/{id}/requests/{reqId}/respond — rank: any-builder — POST /goals/:id/requests/:reqId/respond
       postGoalsIdRequestsReqIdRespond: (args) => request("POST", "/goals/{id}/requests/{reqId}/respond", { hasBody: true }, args),
+      // POST /goals/{id}/requests/{reqId}/withdraw — rank: any-builder — POST /goals/:id/requests/:reqId/withdraw
+      postGoalsIdRequestsReqIdWithdraw: (args) => request("POST", "/goals/{id}/requests/{reqId}/withdraw", { hasBody: true }, args),
       // POST /goals/{id}/scope — rank: metic+archon — POST /goals/:id/scope
       postGoalsIdScope: (args) => request("POST", "/goals/{id}/scope", { hasBody: true }, args),
       // POST /goals/{id}/tasks — rank: any-builder — POST /goals/:id/tasks
@@ -439,6 +443,8 @@ export function createClient(opts = {}) {
       postModulesKeyEnable: (args) => request("POST", "/modules/{key}/enable", { hasBody: true }, args),
       // POST /modules/{key}/submit — rank: metic+archon — POST /modules/:key/submit
       postModulesKeySubmit: (args) => request("POST", "/modules/{key}/submit", { hasBody: true }, args),
+      // GET /modules/submissions — rank: metic+archon — GET /modules/submissions
+      getModulesSubmissions: (args) => request("GET", "/modules/submissions", { hasBody: false }, args),
     },
     "overrideRequests": {
       // GET /override-requests — rank: archon — GET /override-requests
@@ -453,6 +459,8 @@ export function createClient(opts = {}) {
       getProvisioningFleetCostLedger: (args) => request("GET", "/provisioning/fleet/cost-ledger", { hasBody: false }, args),
       // GET /provisioning/github-app/callback — rank: public — GET /provisioning/github-app/callback
       getProvisioningGithubAppCallback: (args) => request("GET", "/provisioning/github-app/callback", { hasBody: false }, args),
+      // GET /provisioning/github-app/status — rank: public — GET /provisioning/github-app/status
+      getProvisioningGithubAppStatus: (args) => request("GET", "/provisioning/github-app/status", { hasBody: false }, args),
       // GET /provisioning/health — rank: public — GET /provisioning/health
       getProvisioningHealth: (args) => request("GET", "/provisioning/health", { hasBody: false }, args),
       // GET /provisioning/instances — rank: any-builder — GET /provisioning/instances
@@ -467,6 +475,8 @@ export function createClient(opts = {}) {
       postProvisioningInstancesIdGithubApp: (args) => request("POST", "/provisioning/instances/{id}/github-app", { hasBody: true }, args),
       // POST /provisioning/instances/{id}/teardown — rank: any-builder — POST /provisioning/instances/:id/teardown
       postProvisioningInstancesIdTeardown: (args) => request("POST", "/provisioning/instances/{id}/teardown", { hasBody: true }, args),
+      // GET /provisioning/onboard-plan — rank: public — GET /provisioning/onboard-plan
+      getProvisioningOnboardPlan: (args) => request("GET", "/provisioning/onboard-plan", { hasBody: false }, args),
       // GET /provisioning/tls-check — rank: public — GET /provisioning/tls-check
       getProvisioningTlsCheck: (args) => request("GET", "/provisioning/tls-check", { hasBody: false }, args),
     },

package/clients/bongos-client/package.json

@@ -1,5 +1,5 @@
 {
-  "name": "@cloudbongos/client",
+  "name": "@bongos/client",
   "version": "0.0.2",
   "description": "Generated typed client for the Bongos API (ADR 0118). Do not edit by hand.",
   "type": "module",

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

@@ -6,7 +6,7 @@
 
 ## Context
 
-Off the Boats V1 needs a persistent shared world for up to 100 concurrent players, browser-played, tile-based, with real-money purchases. The total budget for build + first year is $5,000. Monthly recurring cost must stay low and bootstrap-friendly.
+Example V1 needs a persistent shared world for up to 100 concurrent players, browser-played, tile-based, with real-money purchases. The total budget for build + first year is $5,000. Monthly recurring cost must stay low and bootstrap-friendly.
 
 We needed an architecture that:
 

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

@@ -24,7 +24,7 @@ We will use **User OAuth (as `lars@example.com`)**.
 
 ## Alternatives considered
 
-- **Service account with Chat App identity.** Cleanest separation (the bot is its own persona, posts under "Off the Boats Build Bot"). Requires registering the Chat App via Google Cloud's Chat API Configuration page, a "deployment ID," and Workspace admin permission to allow the service account into the space. More setup steps; the bot identity feels less personal for a small team chat where everyone knows Lars.
+- **Service account with Chat App identity.** Cleanest separation (the bot is its own persona, posts under "Example Build Bot"). Requires registering the Chat App via Google Cloud's Chat API Configuration page, a "deployment ID," and Workspace admin permission to allow the service account into the space. More setup steps; the bot identity feels less personal for a small team chat where everyone knows Lars.
 - **Incoming webhook only (outbound, no auth dance).** Dramatically simpler — paste a URL, POST to it, message appears. Good enough for outbound milestone posts but **cannot read messages, threads, or reactions**. Rejected because the inbound feedback loop is half the value.
 
 ## Consequences

package/docs/adr/0019-red-team-bounty-payout-table.md

@@ -6,17 +6,17 @@
 
 ## Context
 
-GDS-V3's incentive structure (criterion C9) adds a **red-team bounty**: a builder who finds and reports a security vulnerability against the system earns drachmae for it. The mechanism that *files* a report (`vulnerability_reports`, R63 / [#282](https://example.com/builders#/task/282)) and the mechanism that *auto-confirms and pays* one (R68) both need to agree on a single thing — **how many drachmae a report is worth, given its severity.**
+GDS-V3's incentive structure (criterion C9) adds a **red-team bounty**: a builder who finds and reports a security vulnerability against the system earns example for it. The mechanism that *files* a report (`vulnerability_reports`, R63 / [#282](https://example.com/builders#/task/282)) and the mechanism that *auto-confirms and pays* one (R68) both need to agree on a single thing — **how many example a report is worth, given its severity.**
 
 Without one authoritative table, each consumer would invent its own constants and they would drift. We also need the numbers to be **tunable** by an Archon (the only rank that controls economy levers): if the bounty proves too generous or too stingy in practice, adjusting it should be an environment change, not a code edit and redeploy.
 
-Drachmae are the project's in-world currency, stored as integer `delta` in `credit_log` (migrations/003_pms.sql). A bounty payout is therefore a plain integer count of drachmae in the same unit as a task's `credits_reward`. The "10c / 50c" shorthand in the task spec maps to 10 / 50 drachmae; there is no sub-drachma denomination.
+Example are the project's in-world currency, stored as integer `delta` in `credit_log` (migrations/003_pms.sql). A bounty payout is therefore a plain integer count of example in the same unit as a task's `credits_reward`. The "10c / 50c" shorthand in the task spec maps to 10 / 50 example; there is no sub-drachma denomination.
 
 ## Decision
 
 We will define the bounty payout table in `src/bongos/security.js` as four **default** integer amounts, each overridable by an environment variable:
 
-| Severity | Default drachmae | Env override |
+| Severity | Default example | Env override |
 |---|---|---|
 | low | 10 | `GDS_BOUNTY_LOW` |
 | medium | 50 | `GDS_BOUNTY_MEDIUM` |

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

@@ -44,7 +44,7 @@ The Example repo is on GitHub. Marking a single file private is awkward (git his
 
 ### 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 drachmae. 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](<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.
 
 ## Alternatives considered
 

package/docs/adr/0023-kind-multipliers-and-idea-bonus.md

@@ -6,7 +6,7 @@
 
 ## Problem
 
-Every task in the GDS carries a `credits_reward` value (the in-world "drachmae" payout when the task ships). Before this ADR, that value was paid 1:1 regardless of task kind. A 40-credit `cleanup` ship and a 40-credit `bug` ship both landed exactly 40c. That's a problem for two reasons:
+Every task in the GDS carries a `credits_reward` value (the in-world "example" payout when the task ships). Before this ADR, that value was paid 1:1 regardless of task kind. A 40-credit `cleanup` ship and a 40-credit `bug` ship both landed exactly 40c. That's a problem for two reasons:
 
 1. **It silently disincentivises the work we want more of.** Capturing a learning that prevents a future bug, resolving a blocker that was costing the builder days, or landing a decision/ADR are all *higher leverage* per builder-hour than the average feature. Paying them the same says "we don't care which you do." In practice we care a lot.
 2. **The idea_inbox economy was unfunded.** Anyone could capture an idea, get it triaged into a task, and the task's eventual shipper got 100% of the reward. The capturer earned 0 — even though the idea was the unblocker. Capturing felt like volunteer work.

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

@@ -57,7 +57,7 @@ A new table `builder_memory(builder_id, path, content TEXT, mtime, sha256, byte_
 
 Two trigger points, both transactional boundaries that already exist in the methodology:
 
-- **Push on `/builder-ship`.** After the ship completes successfully (drachmae landed, branch merged or queued), `scripts/gds/ship.js` walks `~/.claude/projects/<project>/memory/*` and calls `POST /api/gds/memory/sync` with each file. If the push fails, ship still succeeds — work is preserved in the GDS row, memory can be resynced next time. Progress visible to the builder ("syncing 3 memory files…"). This is what [#274](https://example.com/builders#/task/274) R55 implements.
+- **Push on `/builder-ship`.** After the ship completes successfully (example landed, branch merged or queued), `scripts/gds/ship.js` walks `~/.claude/projects/<project>/memory/*` and calls `POST /api/gds/memory/sync` with each file. If the push fails, ship still succeeds — work is preserved in the GDS row, memory can be resynced next time. Progress visible to the builder ("syncing 3 memory files…"). This is what [#274](https://example.com/builders#/task/274) R55 implements.
 - **Pull on `SessionStart` hook + `/builder-start`.** A new hook (or extension of the existing `.claude/hooks/sync-env-local.sh` pattern) calls `GET /api/gds/memory/since?mtime=<local-newest>` and writes any files the server has that are newer than the local copy. This is what [#275](https://example.com/builders#/task/275) R56 implements.
 
 No background polling. No Claude-Code-side daemon. No mid-session sync. The two trigger points are predictable, debuggable, and align with the natural commit/restart boundaries builders already think in.

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

@@ -30,21 +30,21 @@ This ADR records the architecture and, critically, the **boundaries** that turn
 
 The BFG gains three capability clusters (6A / 6B / 6C), built as independently-shippable sub-phases. Two cross-cutting rules govern all of them:
 
-- **The BFG is a privileged *system* agent, not a rank bypass.** Its cross-builder powers are the existing Archon-forensic-read posture, extended to a narrow audited write. They are bound to a dedicated **BFG service principal** (a `builders` row flagged as system: cannot claim work, cannot earn drachmae) and are reachable *only* by that principal — never exposed on a self-serve route. No human or agent builder can ask the system to "read/write another builder's memory." **This is an enforcement requirement, not prose intent:** 6C.1's write endpoint must gate on the *exact principal identity*, not on rank — an Archon token (or any rank-escalated / stolen token) must be rejected at the write endpoint, and that refusal must be covered by a test. "Never exposed on a self-serve route" is a property the implementation has to encode, not a promise the ADR can keep on its own.
+- **The BFG is a privileged *system* agent, not a rank bypass.** Its cross-builder powers are the existing Archon-forensic-read posture, extended to a narrow audited write. They are bound to a dedicated **BFG service principal** (a `builders` row flagged as system: cannot claim work, cannot earn example) and are reachable *only* by that principal — never exposed on a self-serve route. No human or agent builder can ask the system to "read/write another builder's memory." **This is an enforcement requirement, not prose intent:** 6C.1's write endpoint must gate on the *exact principal identity*, not on rank — an Archon token (or any rank-escalated / stolen token) must be rejected at the write endpoint, and that refusal must be covered by a test. "Never exposed on a self-serve route" is a property the implementation has to encode, not a promise the ADR can keep on its own.
 - **Every cross-builder operation — read *and* write — writes an `audit_log` row.** Writes are additionally **namespaced and attributed** so a builder can always see, and delete, exactly what the BFG put there. Nothing the BFG writes ever masquerades as the builder's own note.
 
 ### 6A — Hygiene (the original charter, widened)
 
 Read-only auditor. Findings land as `idea_inbox` rows (one per finding, like `overnight-code-review`) plus a `docs/audits/bfg-<date>.md` report. The BFG **never** auto-mutates code or DB state — it reports.
 
-- **Doc ↔ reality:** CLAUDE.md claims vs DB (`shipped` task IDs cited, version statuses, the rank enum, drachmae/karma model), `[[link]]` resolution, ADR cross-reference integrity + numbering gaps, `docs/file-map.md` vs the actual tree, onboarding-diagram `assertions.json` vs live facts.
+- **Doc ↔ reality:** CLAUDE.md claims vs DB (`shipped` task IDs cited, version statuses, the rank enum, example/karma model), `[[link]]` resolution, ADR cross-reference integrity + numbering gaps, `docs/file-map.md` vs the actual tree, onboarding-diagram `assertions.json` vs live facts.
 - **Memory hygiene:** within each builder's *own* memory dir — dangling `[[links]]`, stale frontmatter, internal contradictions, duplicate facts (the same discipline the `consolidate-memory` skill applies, but agent-driven rather than human-invoked).
 - **DB cleanliness:** cached-counter vs ledger drift (`builders.karma` vs `karma_log`, `total_credits` vs `credit_log`), orphaned rows, long-stale `idea_inbox` / `blockers`. Reported, never silently "fixed."
 
 ### 6B — Cross-builder learning ("read the room")
 
 - **Read all builders' memory** through a BFG-principal-only, per-read audit-logged endpoint (same shape as the Archon forensic read).
-- **Score interaction quality** by blending objective GDS signals (ships, grader pass rate, rework/abandon rate, karma, drachmae, methodology adherence visible in `audit_log` + conductor traces) with memory-quality heuristics.
+- **Score interaction quality** by blending objective GDS signals (ships, grader pass rate, rework/abandon rate, karma, example, methodology adherence visible in `audit_log` + conductor traces) with memory-quality heuristics.
 - **Extract *transferable* patterns** from top performers — working habits and durable lessons, **not** builder-specific secrets, PII, or anything that only makes sense in that builder's context.
 - **Propagate** as adoption suggestions to other builders (delivered via the 6C write path as clearly-marked BFG entries, or surfaced in the audit report).
 
@@ -76,7 +76,7 @@ The BFG runs as a `SKILL.md` scheduled routine (post-ship / pre-cron cadence) an
 | **6A.2** | Extend the auditor with memory-hygiene + DB cached-vs-ledger drift checks (still report-only). | Hygiene covers all three artifact classes. |
 | **6B.1** | BFG-principal-only, audit-logged cross-builder memory **read** endpoint + interaction-quality scorer. | "Read the room" exists; reuses the forensic-read audit pattern. |
 | **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-drachmae) + 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.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. |
 

package/docs/adr/0027-bfg-session-inefficiency-evaluator.md

@@ -5,7 +5,7 @@
 - **Deciders:** Lars Kristensen (Archon), Claude
 - **Track:** `internal` (GDS)
 - **Context tasks:** GDS-V4 **[#515](https://example.com/builders#/task/515)** (the capability umbrella) · **[#539](https://example.com/builders#/task/539)** (this design task — ADR + task breakdown only, no implementation; mirrors the design-only shape of [#441](<redacted>.md)).
-- **Extends:** [ADR 0024 — Multi-Agent System architecture](<redacted>.md) (the BFG is its Phase 6) · [ADR 0026 — The BFG charter](<redacted>.md) (this adds a **new capability cluster, 6D**, to the BFG's "best building experience" objective) · [ADR 0016 — Trust boundary](<redacted>.md) (narrowly extended — session detail now lives server-side and is BFG-readable across builders) · [ADR 0022 — Secrets policy](0022-secrets-policy.md) (scrubbing on upload). Touches `credit_log` (drachmae), `karma_log`, `builders` (rank + tenure), `task_grades` (the upsert-unique gap), `session_logs`.
+- **Extends:** [ADR 0024 — Multi-Agent System architecture](<redacted>.md) (the BFG is its Phase 6) · [ADR 0026 — The BFG charter](<redacted>.md) (this adds a **new capability cluster, 6D**, to the BFG's "best building experience" objective) · [ADR 0016 — Trust boundary](<redacted>.md) (narrowly extended — session detail now lives server-side and is BFG-readable across builders) · [ADR 0022 — Secrets policy](0022-secrets-policy.md) (scrubbing on upload). Touches `credit_log` (example), `karma_log`, `builders` (rank + tenure), `task_grades` (the upsert-unique gap), `session_logs`.
 
 ## Context
 
@@ -39,7 +39,7 @@ When `/builder-ship` lands a task, `ship.js` locates the active Claude Code sess
 | `session_id` | the Claude Code `sessionId` |
 | `builder_id` | the shipping builder |
 | `task_ids[]` | task(s) shipped from this session |
-| `drachmae_earned` | the session's `credit_log` delta |
+| `example_earned` | the session's `credit_log` delta |
 | `total_tokens` | summed transcript `usage` (input + output + cache) |
 | `duration_seconds` | transcript first→last timestamp (or `session_logs`) |
 | `started_at` / `ended_at` / `uploaded_at` | timestamps |
@@ -52,7 +52,7 @@ When `/builder-ship` lands a task, `ship.js` locates the active Claude Code sess
 
 The server stores and serves; it does **no analysis**. Two endpoints over `session_records`:
 
-- **Search/filter** by *session* fields (`drachmae_earned`, `total_tokens`, `duration`, the derived metrics) **and joined `builders` fields** — **tenure** (`now − created_at`), **rank**, **karma**, **drachmae** (`total_credits`). So queries like *"rank = Xenos AND tenure < 7d AND overhead > 0.7"* (onboarding friction) or *"karma top-decile"* (good-practice mining) are expressible against one corpus.
+- **Search/filter** by *session* fields (`example_earned`, `total_tokens`, `duration`, the derived metrics) **and joined `builders` fields** — **tenure** (`now − created_at`), **rank**, **karma**, **example** (`total_credits`). So queries like *"rank = Xenos AND tenure < 7d AND overhead > 0.7"* (onboarding friction) or *"karma top-decile"* (good-practice mining) are expressible against one corpus.
 - **Fetch one session's** full scrubbed detail for deep-dive.
 
 Cross-builder reads are gated to the **BFG service principal** ([ADR 0026](<redacted>.md) §6B posture — the *exact principal identity*, not rank) and write an **`audit_log` row per read**. A builder may always read their *own* sessions self-serve. Filtering is plain SQL/keyword **for now** (semantic/vector deferred, consistent with [ADR 0024](<redacted>.md)/[0026](<redacted>.md)).

package/docs/adr/0030-builders-hall-live-updates.md

@@ -7,7 +7,7 @@
 
 ## Context
 
-The builders hall (`public-builders/`) fetched **every panel exactly once** at `DOMContentLoaded` via `loadAll()` and then never refreshed. Onboarding checklist, standing (drachmae/karma), claimable works, leaderboard, karma feed, bounty table — all frozen until the visitor manually reloaded. The only things that updated without a reload were the two buttons a builder clicks themselves (mark primer read, pick a craft).
+The builders hall (`public-builders/`) fetched **every panel exactly once** at `DOMContentLoaded` via `loadAll()` and then never refreshed. Onboarding checklist, standing (example/karma), claimable works, leaderboard, karma feed, bounty table — all frozen until the visitor manually reloaded. The only things that updated without a reload were the two buttons a builder clicks themselves (mark primer read, pick a craft).
 
 The reported symptom: a builder runs `/builder-ship` in the terminal, the "Ship thy first work" onboarding step clears server-side, but the open hall tab keeps showing the stale checklist. The underlying gap is broader than onboarding — the page had **no live-update mechanism at all**.
 

package/docs/adr/0031-cloud-dev-environments-for-builders.md

@@ -87,10 +87,10 @@ Two rules dissolve the "front every box (linear cost) vs. gate by payment (barri
 | Stage | How they work | Org cost | Builder cost |
 |---|---|---|---|
 | **Newcomer** (Xenos / onboarding) | Org provisions an **auto-suspended starter box** so there is zero payment barrier to begin | A bounded ~$5/active-newcomer (suspends when idle; de-provisioned if dormant) | Just their Claude subscription |
-| **Proven** (graduated → Metic) | Keeps a box | Transitions toward $0 | **Self-funds** (own DO account, or org provisions + rebills via the `costs` table, deducted from drachmae/earnings) |
+| **Proven** (graduated → Metic) | Keeps a box | Transitions toward $0 | **Self-funds** (own DO account, or org provisions + rebills via the `costs` table, deducted from example/earnings) |
 | **Established** | Own box, runs it how they like | **$0** | Self-funds (1099 own-tools) |
 
-The barrier to *start* is zero (org pays the first box, per the decision to **not** use Anthropic's Cloud VM for onboarding). Real cost attaches only to builders who are earning. **Scale math:** naïve 100 builders × $30 always-on ≈ $36k/yr (untenable); this model ≈ $0 ongoing + a small bounded starter-box pool. None of it needs new machinery — it rides the rank ladder, the onboarding funnel, the drachmae/credits system, and the cost-logging we already have.
+The barrier to *start* is zero (org pays the first box, per the decision to **not** use Anthropic's Cloud VM for onboarding). Real cost attaches only to builders who are earning. **Scale math:** naïve 100 builders × $30 always-on ≈ $36k/yr (untenable); this model ≈ $0 ongoing + a small bounded starter-box pool. None of it needs new machinery — it rides the rank ladder, the onboarding funnel, the example/credits system, and the cost-logging we already have.
 
 ### 6. Security — the container is the rank-gated source-access boundary
 
@@ -141,7 +141,7 @@ The repo is **private** (today under a personal account — see §7; a move to a
 
 ## Open questions (flagged, not blocking)
 
-1. **Per-builder box ownership transition.** Mechanics of moving a builder from the org-funded starter box to self-funding — recreate on their own DO account vs. org-provisions-and-rebills via the `costs` table. Lean: rebill-via-drachmae for simplicity; revisit.
+1. **Per-builder box ownership transition.** Mechanics of moving a builder from the org-funded starter box to self-funding — recreate on their own DO account vs. org-provisions-and-rebills via the `costs` table. Lean: rebill-via-example for simplicity; revisit.
 2. **Onboarding repo-access scoping.** ✅ **RESOLVED 2026-06-05 ([#600](https://example.com/builders#/task/600)) — rank-gated, server-issued, fetched-not-baked.** A Xenos box sparse-checks out only the safe surface; full creds arrive at graduation; the box fetches a scoped credential gated on live rank rather than holding a baked one. See the resolution note below.
 3. **Auto-suspend implementation.** ✅ **RESOLVED 2026-06-04 ([#598](https://example.com/builders#/task/598)) — snapshot-and-park, NOT Coder.** See the resolution note below.
 4. **Thin-device on-ramp friction.** ✅ **RESOLVED 2026-06-06 ([#701](https://example.com/builders#/task/701)) — box reports its pairing link UP to the GDS; the builder reads it from the web.** See §9.4 below.
@@ -219,4 +219,4 @@ Not yet created; listed so the build session has a starting decomposition.
 | Managed-settings + Remote Control service | Distribute the locked `sshConfigs`/`sshHostAllowlist`; always-on `claude rc` for thin devices | C1 |
 | Rank-gated source access | Box holds the scoped GitHub credential; access granted/revoked by rank; offboarding clawback | C2 / C7 / C9 |
 | Onboarding primer page ✅ | **Done** — the §"mental model" explainer lives in [`docs/onboarding/primer.md`](../onboarding/primer.md) § "Where your work runs" (extracted in the ADR 0035 rewrite, [#718](https://example.com/builders#/task/718); closed by task 601) | C1 |
-| Cost passthrough wiring | Org-funded starter → self-fund transition via `costs`/drachmae | cost |
+| Cost passthrough wiring | Org-funded starter → self-fund transition via `costs`/example | cost |

package/docs/adr/0032-discord-mirror-of-gds.md

@@ -1,7 +1,7 @@
 # ADR 0032 — Discord as a one-way mirror of the GDS (outbound broadcast moves off Google Chat)
 
 **Date:** 2026-06-04
-**Context:** GDS-V3, task [#607](https://example.com/builders#/task/607) (claim `#482`). Stands up a Discord server for Off the Boats / Example — one server, permission-walled into a player wing and a builder wing — and moves the ship-broadcast off Google Chat. Companion to [ADR 0016](<redacted>.md) (the trust boundary — the load-bearing constraint here), [ADR 0018](<redacted>.md) (Xenos → Metic → Archon, the ranks Discord roles mirror), [ADR 0022](0022-secrets-policy.md) (webhook URLs are secrets, kept out of the repo), and [ADR 0008](0008-google-chat-oauth-user-auth.md) (the Google Chat broadcast this supersedes for outbound).
+**Context:** GDS-V3, task [#607](https://example.com/builders#/task/607) (claim `#482`). Stands up a Discord server for Example / Example — one server, permission-walled into a player wing and a builder wing — and moves the ship-broadcast off Google Chat. Companion to [ADR 0016](<redacted>.md) (the trust boundary — the load-bearing constraint here), [ADR 0018](<redacted>.md) (Xenos → Metic → Archon, the ranks Discord roles mirror), [ADR 0022](0022-secrets-policy.md) (webhook URLs are secrets, kept out of the repo), and [ADR 0008](0008-google-chat-oauth-user-auth.md) (the Google Chat broadcast this supersedes for outbound).
 **Status:** Accepted. Phase 2 (outbound ship broadcast → Discord) implemented in [#607](https://example.com/builders#/task/607). Phases 3+ (interaction bot, inbound retirement, role sync) scoped below, not yet built.
 **Track:** `internal` (dev-system / team communication).
 
@@ -12,7 +12,7 @@ The project is opening to multiple builders (GDS-V3) and will eventually have pl
 Two existing surfaces are relevant:
 
 - The **ship broadcast** posts a plain-language "what shipped" summary to the Example team **Google Chat** space ([ADR 0008](0008-google-chat-oauth-user-auth.md); fired from `scripts/gds/ship.js` on deploy). Google Chat is a closed business space — fine for the Example owners, wrong as a builder+player community hub.
-- The **GDS** already holds all authoritative state: ranks, tasks, karma (`peer_upvote` is an existing reason), idea_inbox, drachmae, the builders' hall.
+- The **GDS** already holds all authoritative state: ranks, tasks, karma (`peer_upvote` is an existing reason), idea_inbox, example, the builders' hall.
 
 The temptation, standing up Discord, is to let it *own* things — roles that grant power, votes that live in Discord, a second scoreboard. That would fracture the source of truth and — for roles — quietly punch a hole in the trust boundary.
 

package/docs/adr/0034-thetes-graduated-newcomer-rank.md

@@ -50,4 +50,4 @@ The promotion reuses the existing rank-change machinery (refactored into a share
 
 - **Just raise the newcomer-queue target / fix supply only.** Treats the symptom. A shared pool of N newcomer tasks is always racing consumption; time-boxing the sandbox removes the dependency entirely for everyone past their 3rd ship.
 - **Auto-promote `xenos` straight to `metic`.** Rejected: Metic carries triage/trust/red-team/infra powers no automatic rule should hand out. The new intermediate rank is exactly the "breadth without trust" tier that makes auto-promotion safe.
-- **Promote by drachmae or karma instead of ship count.** Rejected for v1: ship count is the most legible "you've proven you can land work" signal and is already the credit-landing event. A richer policy can layer on later.
+- **Promote by example or karma instead of ship count.** Rejected for v1: ship count is the most legible "you've proven you can land work" signal and is already the credit-landing event. A richer policy can layer on later.

package/docs/adr/0044-mediterranean-palette-replacement.md

@@ -38,7 +38,7 @@ Rationale (Lars's call, 2026-06-10):
   prompt must reason about *which* palette applies to *which* tile. That branching is exactly
   the kind of pipeline complexity the bootstrapped budget and the single-maintainer reality
   can't carry. One palette = one set of rules everywhere.
-- **The world has one look.** Off the Boats is a single, persistent, coherent world. There is
+- **The world has one look.** Example is a single, persistent, coherent world. There is
   no "Poke Mart interior" context that needs the temperate palette — the FireRed colors were
   only ever scaffolding for the *structure*, never the intended final hues.
 - **The bias rule becomes the palette.** Today the style guide *nudges* generations toward

package/docs/adr/0044-per-box-live-game-preview.md

@@ -7,7 +7,7 @@
 
 ## Problem
 
-A builder working on the **game** (`public/`, `src/world/`, `src/rooms/`, the art tiles) has no way to *see their change running* before it ships. The only live instance of Off the Boats is production at `example.com`. So the loop today is: edit → ship through the grader/merge/deploy pipeline → look at prod. That is slow, it puts unreviewed game changes one mistake away from players, and a browser-only (Chromebook) builder has no local machine to run the game on at all.
+A builder working on the **game** (`public/`, `src/world/`, `src/rooms/`, the art tiles) has no way to *see their change running* before it ships. The only live instance of Example is production at `example.com`. So the loop today is: edit → ship through the grader/merge/deploy pipeline → look at prod. That is slow, it puts unreviewed game changes one mistake away from players, and a browser-only (Chromebook) builder has no local machine to run the game on at all.
 
 What a builder wants is a **sandbox**: run the game live *on their own dev box* and open it in a browser to review the change — never touching the prod server.
 

package/docs/adr/0054-session-token-reward-cost-plus.md

@@ -1,4 +1,4 @@
-# ADR 0054 — Flat cost-plus session token reward (drachmae as equity)
+# ADR 0054 — Flat cost-plus session token reward (example as equity)
 
 **Date:** 2026-06-13
 **Context:** GDS-V4, task [#1005](https://example.com/builders#/task/1005). Builds on [ADR 0023](<redacted>.md) (per-task kind-multiplied credits), [ADR 0028](<redacted>.md) (the `llm-pricing.js` token→USD table + session-cost capture), and [ADR 0027](<redacted>.md) (the `session_records` upload-on-ship path this reward rides). Complements — does **not** replace — the per-task `credits_reward × kind_multiplier` path. Related future work: the full-transcript capture ADR (planned, task [#1004](https://example.com/builders#/task/1004)) will give this reward a more trustworthy raw-usage source, and the token-feed hardening scoped in task [#1005](https://example.com/builders#/task/1005) itself.
@@ -7,13 +7,13 @@
 
 ## Problem
 
-We are about to onboard the first **incentivized** builders. Today the only payout is per-task `credits_reward` — a unitless number an author sets at task-creation time. It rewards declaring a big number, not doing expensive, real work. The owner's decision (2026-06-13) is to pay builders proportionally to the **true economic cost** of the work they did — the API token spend of the session — plus a margin, with drachmae standing in as **equity** in the project. It must go live today, be idempotent and reversible, and be impossible to inflate with a client-sent dollar figure.
+We are about to onboard the first **incentivized** builders. Today the only payout is per-task `credits_reward` — a unitless number an author sets at task-creation time. It rewards declaring a big number, not doing expensive, real work. The owner's decision (2026-06-13) is to pay builders proportionally to the **true economic cost** of the work they did — the API token spend of the session — plus a margin, with example standing in as **equity** in the project. It must go live today, be idempotent and reversible, and be impossible to inflate with a client-sent dollar figure.
 
 ## Decision
 
 Per **shipped session** (the unit; per-task attribution is a later refinement — see the future-review trigger), grant a flat cost-plus reward:
 
-    drachmae = round(true_cost_usd × (1 + REWARD_MARGIN_PCT/100) × 100)   // integer cents
+    example = round(true_cost_usd × (1 + REWARD_MARGIN_PCT/100) × 100)   // integer cents
     REWARD_MARGIN_PCT = 20
 
 - **`true_cost_usd` is computed SERVER-SIDE** from the per-model token counts the ship upload already carries (`session_records.model_usage`), priced via `src/bongos/llm-pricing.js` (the locked API list-price table). The client uploads token *counts*, never a dollar figure — that figure is never trusted from the client.
@@ -21,7 +21,7 @@ Per **shipped session** (the unit; per-task attribution is a later refinement
 - **Margin is a code constant** (`REWARD_MARGIN_PCT` in `src/bongos/db.js`), owner-changed via a commit, not a settings UI — the same review-trail rationale as `KIND_MULTIPLIERS` ([ADR 0023](<redacted>.md)). A future migration can promote it to a per-builder/per-version table if the economics ever need live tuning. No rank above Archon is introduced; the knob is an owner-scoped policy constant.
 - **Idempotent per `session_id`**: a new `credit_log.reason = 'session.token_reward'` row carries a `session_id` column backed by a partial-unique index, plus a SELECT fast-path guard inside the upsert transaction. Re-uploading the same session (re-ship, retry) is a true no-op — no double payout.
 - The existing per-task credit path is untouched. Both the token reward and per-task credits accrue to `builders.total_credits` via the existing `pms_apply_credit` trigger.
-- **Drachmae = equity units** (owner framing). No special code — it is the interpretation of `total_credits`.
+- **Example = equity units** (owner framing). No special code — it is the interpretation of `total_credits`.
 
 ### Two drachma conventions, one ledger (the load-bearing tension)
 
@@ -32,12 +32,12 @@ We knowingly accept that a drachma now means two things on the same ledger: a *u
 A flat cost-plus reward pays **more** for a more expensive session — it can reward token *waste* (thrashing, re-reading, long unproductive loops) as much as productive spend. This was raised and explicitly accepted by the owner, for three reasons:
 
 1. **PASS-gated by construction.** Only a *successful ship* uploads a session record, so a session that burned tokens and shipped nothing earns nothing.
-2. **Drachmae are equity, not cash.** A builder who pads cost dilutes a pool they themselves hold; the incentive to waste is bounded by the fact that the payout currency is ownership in the thing being built. Early builders want their percentage to be worth something, so they self-police. Inflating the denominator hurts the inflator.
+2. **Example are equity, not cash.** A builder who pads cost dilutes a pool they themselves hold; the incentive to waste is bounded by the fact that the payout currency is ownership in the thing being built. Early builders want their percentage to be worth something, so they self-police. Inflating the denominator hurts the inflator.
 3. **The waste signal already exists.** The BFG session-inefficiency evaluator ([ADR 0027](<redacted>.md)) flags wasteful sessions from the same uploaded digest; a later refinement can gate or discount the reward by a quality/efficiency factor, moving from flat cost-plus to cost-plus-adjusted-for-value. The owner's stated direction is to move toward **market dynamics** (bidding) once the builder pool is genuinely multi-party.
 
 ## Consequences
 
-- **Migration 090** adds `session_records.model_usage` + `session_records.token_reward_drachmae`, `credit_log.session_id` + the partial-unique index `uniq_credit_session_token_reward`, and bumps the migration counter.
+- **Migration 090** adds `session_records.model_usage` + `session_records.token_reward_example`, `credit_log.session_id` + the partial-unique index `uniq_credit_session_token_reward`, and bumps the migration counter.
 - `llm-pricing.js` gains pure, tested `priceModelUsage` + `canonicalizeModelId`.
 - `db.js` gains `REWARD_MARGIN_PCT`, `computeSessionTokenReward`, `awardSessionTokenReward`, and the transactional `upsertSessionRecordWithReward` (the route now calls it instead of the bare upsert).
 - `scripts/gds/ship.js` accumulates per-model usage into the digest; `POST /api/gds/sessions` accepts `model_usage`, prices it, and returns `token_reward` on the 201.
@@ -50,14 +50,14 @@ Revisit when: (a) per-task token attribution lands (the unit becomes the task, n
 
 ## Amendment — 2026-06-15 (task [#1138](https://example.com/builders#/task/1138)): 1 drachma = $1
 
-**Trigger (c), partial.** An audit of the first incentivized builder's ledger (owner request) found the cents convention had inflated the balance ~100× (one builder, 31 sessions → 295,218 drachmae ≈ $2,952 of cost-plus) and that summing cents-denominated token rewards with the unitless per-task credits made the total incoherent. The owner's decision: **re-denominate the token reward so 1 drachma = $1**, not 1 cent.
+**Trigger (c), partial.** An audit of the first incentivized builder's ledger (owner request) found the cents convention had inflated the balance ~100× (one builder, 31 sessions → 295,218 example ≈ $2,952 of cost-plus) and that summing cents-denominated token rewards with the unitless per-task credits made the total incoherent. The owner's decision: **re-denominate the token reward so 1 drachma = $1**, not 1 cent.
 
 **Change to the Decision formula** (supersedes the `× 100` in the formula above):
 
-    drachmae = round(true_cost_usd × (1 + REWARD_MARGIN_PCT/100))   // whole drachmae, 1 drachma = $1
+    example = round(true_cost_usd × (1 + REWARD_MARGIN_PCT/100))   // whole example, 1 drachma = $1
     REWARD_MARGIN_PCT = 20   // unchanged
 
-- The trailing `× 100` (cents) is **dropped**. A $100 true-cost session now mints `round(100 × 1.20) = 120` drachmae (was 12,000). A sub-$0.42 session now rounds to 0 (was ~50) — intended.
+- The trailing `× 100` (cents) is **dropped**. A $100 true-cost session now mints `round(100 × 1.20) = 120` example (was 12,000). A sub-$0.42 session now rounds to 0 (was ~50) — intended.
 - `computeSessionTokenReward` in `src/bongos/db.js` changed accordingly; `tests/credit_grant.mjs` updated; `llm-pricing.js` (the token→USD table) is **unchanged** — only the cents→dollars scale factor moved.
-- **History was re-denominated, not left mixed.** Per the "append-only, reversible" rule above, existing `session.token_reward` rows were **not mutated**; a single compensating `credit_log` row (`reason='redenominate.token_reward_dollars'`, `task_id` → [#1138](https://example.com/builders#/task/1138)) restates the running total from cents to dollars, and the `total_credits` trigger nets it automatically. The original cents rows remain as historical record; the `session_records.token_reward_drachmae` display mirror was divided by 100 to match. At amendment time builder `#1` (example-owner) was the only holder of token rewards, so this touched one builder.
+- **History was re-denominated, not left mixed.** Per the "append-only, reversible" rule above, existing `session.token_reward` rows were **not mutated**; a single compensating `credit_log` row (`reason='redenominate.token_reward_dollars'`, `task_id` → [#1138](https://example.com/builders#/task/1138)) restates the running total from cents to dollars, and the `total_credits` trigger nets it automatically. The original cents rows remain as historical record; the `session_records.token_reward_example` display mirror was divided by 100 to match. At amendment time builder `#1` (example-owner) was the only holder of token rewards, so this touched one builder.
 - **The per-task `credits_reward` path (ADR 0023) is untouched** — it stays a unitless author estimate. The two-conventions tension (§"Two drachma conventions, one ledger") is now *narrower* (both paths read on a ~dollar scale) but not formally reconciled; trigger (c) remains open for a full reconciliation.

package/docs/adr/0057-container-cost-ledger.md

@@ -3,11 +3,11 @@
 **Date:** 2026-06-15
 **Status:** Accepted
 **Track:** `internal` (dev-system / cost oversight).
-**Context:** GDS-V3, task [#602](https://example.com/builders#/task/602), criterion C-cost. Implements the ledger half of ADR 0031 §5 (cost passthrough). Companion to [ADR 0031](<redacted>.md) (the dev box) and the early-stage billing policy ("tracked, not settled" — both drachmae earnings and container costs are recorded but not actually paid/charged yet).
+**Context:** GDS-V3, task [#602](https://example.com/builders#/task/602), criterion C-cost. Implements the ledger half of ADR 0031 §5 (cost passthrough). Companion to [ADR 0031](<redacted>.md) (the dev box) and the early-stage billing policy ("tracked, not settled" — both example earnings and container costs are recorded but not actually paid/charged yet).
 
 ## Problem
 
-Builders run org-provisioned DigitalOcean dev boxes (ADR 0031). We want every box cost event recorded per builder — visible to the builder on their own profile and to the Archon for oversight — so the org can see what each box costs *before* any real self-fund/charge mechanism exists. No payment integration, no drachmae deduction yet.
+Builders run org-provisioned DigitalOcean dev boxes (ADR 0031). We want every box cost event recorded per builder — visible to the builder on their own profile and to the Archon for oversight — so the org can see what each box costs *before* any real self-fund/charge mechanism exists. No payment integration, no example deduction yet.
 
 ## Decisions
 
@@ -24,5 +24,5 @@ Builders run org-provisioned DigitalOcean dev boxes (ADR 0031). We want every bo
 ## Consequences
 
 - The "compute" category in the public cost summary now also includes near-$0 spin-up rows; negligible.
-- When a real self-fund/charge mechanism lands (drachmae deduction or DO-account handoff), it reads this ledger — the data is already accruing.
+- When a real self-fund/charge mechanism lands (example deduction or DO-account handoff), it reads this ledger — the data is already accruing.
 - Pure cost math (`storageCostUsd`, `summarizeBoxCost`) is unit-tested (`tests/box_cost.mjs`); the DB writers ride the box-lifecycle integration smoke.

package/docs/adr/0062-medusa-instance-model-decoupling.md

@@ -17,7 +17,7 @@ Today it is one fused codebase. A file-grounded coupling analysis (2026-06-18) f
 
 1. **Process/HTTP** — one Express app + one Colyseus server. The GDS (`/api/gds`, hall, status) mounts host-agnostic *first*; the **game is the fall-through default**, not a module. Good news: `src/rooms/register.js` + `src/preview-server.js` already factor the game-room set out — the cleanest existing seam and the template for the cut.
 2. **DB** — *one shared `pg` Pool*: `src/bongos/db.js` does `require('../db')` and reuses the game's pool. Game tables (`world_events`, `players`, migrations 001/002) and ~78 GDS tables share one pool and one flat migration sequence. `track` is a 2-value `CHECK (track IN ('product','internal'))` column on `versions`, woven into analytics + hall UI — an OTB-specific taxonomy.
-3. **Brand/identity** — leaked, not single-config. "Example" is hardcoded across ~50 hits / 28 files; `example.com` across ~90 (cookie domain `.example.com`, OAuth origin, `*.dev.` SSH allowlist); "drachmae" in 23 files; "Off the Boats"/"Example" baked into **grader/architect/onboarding LLM prompts**. Only `devbox-app/src/brand.js` honors the single-config ideal.
+3. **Brand/identity** — leaked, not single-config. "Example" is hardcoded across ~50 hits / 28 files; `example.com` across ~90 (cookie domain `.example.com`, OAuth origin, `*.dev.` SSH allowlist); "example" in 23 files; "Example"/"Example" baked into **grader/architect/onboarding LLM prompts**. Only `devbox-app/src/brand.js` honors the single-config ideal.
 4. **Methodology/skills** — already clean: `.claude/skills/builder-*` + idea/blocker/planning/status/recall are portable; the four `otb-*` art skills + `stop-sound.js` are host; `art/` is self-contained (no `src/` imports); Discord is already `DISCORD_BOT_ENABLED`-gated.
 
 Why a spike-ADR first: 24 structural tasks (R51–R74) depend on this. They need **one** locked boundary, branding-contract schema, and module mechanism to build against, or they will diverge.
@@ -46,7 +46,7 @@ Why a spike-ADR first: 24 structural tasks (R51–R74) depend on this. They need
 
 - **Engine entrypoint** (R51, [#1190](https://example.com/builders#/task/1190)): boots Express + `buildGdsRouter()` + hall + status, host-agnostic, **no Colyseus, no game/tile mounts** — sibling to `src/preview-server.js`. Today's `server.js` becomes the *OTB instance boot* (engine + game module).
 - **A host instance** = branding pack (§3) + feature-module flags (§4) + owner/repo/OAuth binding (R62, [#1201](https://example.com/builders#/task/1201)) + its own DB (R52).
-- Customer 0 = vanilla brand, no modules (the dogfood); customer 1 = OTB (game + art + discord + dev-box, drachmae, Greek pack).
+- Customer 0 = vanilla brand, no modules (the dogfood); customer 1 = OTB (game + art + discord + dev-box, example, Greek pack).
 
 ### 3. The branding contract (`config/branding.*` — R53 keystone, [#1192](https://example.com/builders#/task/1192))
 
@@ -54,7 +54,7 @@ One per-instance config; **resolution precedence: env var → instance config
 
 - **Identity:** `productName`, `worldName` (the in-world / civilization name), `company` (+ site).
 - **Domains:** `publicOrigin`, `buildersOrigin`, `statusOrigin`, `cookieDomain`, box subdomain pattern (`*.dev.`/`sandbox-`/`term-`). *(Load-bearing security strings — a swap must not widen cookie/SSH scope.)*
-- **Currency label** (R56, [#1195](https://example.com/builders#/task/1195)): "drachmae" → configurable; the cost-plus reward **math is unchanged**.
+- **Currency label** (R56, [#1195](https://example.com/builders#/task/1195)): "example" → configurable; the cost-plus reward **math is unchanged**.
 - **Tracks:** replace the 2-value `product|internal` CHECK with a configurable set (R52, [#1191](https://example.com/builders#/task/1191)).
 - **Theme/palette + copy pack:** hall lore/primer/404 copy, Discord persona, and — critically — the **grader/architect/onboarding prompt brand header** must read the project name from config, or a non-OTB instance grades against the wrong project identity.
 
@@ -103,5 +103,5 @@ R50 (this ADR) → **R51 entrypoint + R52 DB pool** (independent foundations)
 
 - A clear, file-grounded target the 24 epics build against — one boundary, one contract, one module mechanism.
 - The trust boundary + rank enforcement stay core and unchanged; a feature-module must never be able to bypass server-side rank checks (a Path-C assertion).
-- **Hardest knots (called out so the epics plan for them):** (1) shared Pool + flat migrations; (2) the brand-saturated, *not* data-driven hall UI (~50 brand hits, drachmae in 23 files) — the largest mechanical job; (3) inverting game-as-default into a mounted module; (4) domains woven into auth/security — config swaps must not widen cookie/SSH scope; (5) brand inside LLM prompts (grader/architect/onboarding).
+- **Hardest knots (called out so the epics plan for them):** (1) shared Pool + flat migrations; (2) the brand-saturated, *not* data-driven hall UI (~50 brand hits, example in 23 files) — the largest mechanical job; (3) inverting game-as-default into a mounted module; (4) domains woven into auth/security — config swaps must not widen cookie/SSH scope; (5) brand inside LLM prompts (grader/architect/onboarding).
 - **Risk: scope.** Mitigation: R53 keystone first; modules incremental; Path-C enforces no regression; customer-0 dogfood ([#1206](https://example.com/builders#/task/1206)) is the falsifiable proof the cut actually worked.