@bongos/core 1.23.21 → 1.24.1

package/docs/adr/0394-market-watch-searches-through-the-messages-api-on-the-projects-key-and-runs-from-its-own-poller.md

@@ -0,0 +1,102 @@
+# 0394 — Market Watch searches the web through the Messages API on the project's own key, and runs from its own clock-anchored poller
+
+- **Status:** Accepted
+- **Date:** 2026-10-29
+- **Task:** [task 1004934](https://cloudbongos.com/builders#/task/1004934) (goal 1000137, the R01 spike)
+- **Deciders:** Claude investigated and chose; the owner set the constraints (on/off per project, a monthly AI cap, paid by the project, fail closed)
+- **Related:** ADR 0016 (trust boundary), 0054 (credits), 0073 (keys in Settings, secret box), 0083 (modules), 0089 §3 (ModelProvider port), **0385 (Bongos holds no money)**, **0392 (AI generation and own keys)**
+
+## Context
+
+Market Watch (goal 1000137) is an opt-in, weekly, AI-run watch on a project's competitors, partners and topics. Each tracked item gets a dated log of sourced findings and a score history. The owner's rules: it is switched on per project, paid for by the project, capped monthly, and it fails closed. Before R04 ([task 1004937](https://cloudbongos.com/builders#/task/1004937)) builds the weekly run, two questions need an answer: **how does a run reach the web**, and **what fires it each week**.
+
+"Per project" means per instance. Every project is its own instance, with its own database and server process (`modules/provisioning`; the hub is one of them). A run that lives in a project's server process cannot write to another project, because it holds no connection to one.
+
+### What exists today (read from the code, 2026-10-29)
+
+**The grade port, `runSubagentCached`** (`modules/grading/grader-subagent.js`). It spawns the `claude` CLI: `claude -p --tools <opts.tools ?? 'Read'> --strict-mcp-config --permission-mode bypassPermissions`. The tool list is a passthrough string (task 1001691), so a caller *could* ask for `WebSearch,WebFetch`. Three things stop that from being the answer:
+- **The server image has no `claude` CLI.** The `Dockerfile` installs `postgresql-client bash tini curl ca-certificates git` and `npm ci --omit=dev`. `package.json` carries `@anthropic-ai/sdk`, not the CLI. On a deployed instance the spawn fails with `SUBAGENT_SPAWN_FAILED` unless an operator adds the binary, sets `CLAUDE_BIN`, and signs it in. The port works where `ship.js` runs it: on a builder's machine.
+- **The agents module never passes tools.** `modules/agents/spawn.js` sends `opts: { model }` only. Its header says v1 agents are "read-only by plumbing", and a write- or web-capable spawn needs a change in `grading`, which is protected.
+- **The port's cache is wrong for news.** `runSubagentCached` replays a stored answer at $0 on a key hit. A watch that replays last week's search has found nothing.
+
+**The agents module and the cron trigger.** `agents_005_cron_trigger.sql` made `'cron'` storable on `agents_definitions` and `agents_runs`, with a required `trigger_spec.cadence` (`weekly` among the allowed values). Nothing selects cron agents yet. Also, `spawn.js plannedRow` maps every trigger that is not `'on-demand'` to `'event'`. A cron fire through today's spawn path would be recorded in the ledger as an event fire. The agents module is `default: false`, and on the hub `GET /api/bongos/agents` answers **404**: it is not enabled there (checked 2026-10-29). Its spend guards (`lib/spend-ceiling.js`: per payer and per definition, both fail closed) bound agent fires. They do not express "this project's Market Watch budget".
+
+**Why the cron-router poller was abandoned.** Task 1002498 (`modules/agents/pollers/cron-router.js`, one timer per cadence bucket) is `abandoned` with the note "WA6 review 2026-09-28: not necessary now (owner call)". There was no technical blocker. Its enabling bug (task 1004008, no `'cron'` type) shipped afterwards as agents_005, so the poller would select real rows today. But it would fire them through the grade port, which has no CLI on the server.
+
+**The autonomy module's timers** (`modules/autonomy/pollers/`). Two patterns sit side by side:
+- `routine-timers.js` uses a **boot-anchored** `setInterval` (peer-vote-tally, weekly). It first fires about 90 s after each boot. The hub redeploys on every merge, so in practice it runs once per deploy and almost never completes a 7-day interval. That is harmless for an idempotent tally and wrong for a paid run, which would be charged once per deploy.
+- `daily-checks.js` uses a **clock-anchored** timer: an hourly unref'd tick asks the ledger whether the last run is due ("DAILY BY THE CLOCK, NOT BY THE BOOT"), with a 30-minute slack so runs do not drift. It is kill-switched by `ROUTINE_TIMERS_DISABLED=1` and never throws into the server.
+
+Any module can contribute a poller of its own: `contributes.pollers` in `module.json`, started by the loader at boot (docs/modules-contract.md §Start pollers).
+
+**How the server calls an LLM with tools today.** It doesn't. `modules/discord/discord-support.js` makes the one server-side Messages API call, through `@anthropic-ai/sdk`, with **no tools**, on an env-only, namespaced key (`DISCORD_SUPPORT_ANTHROPIC_API_KEY`). `modules/ai-studio` calls OpenRouter and Gemini over HTTPS.
+
+**Keys in Settings.** Task 1004919 shipped `ai_studio_provider_keys`: **per-builder** keys for `openrouter` and `gemini` only (a CHECK constraint), encrypted with `api.secretBox`, never returned. There is no project-level key, no Anthropic key, and no search-API key in Settings.
+
+### Cost measurements
+
+**Measured (n=2, 2026-10-29), the tool-enabled CLI path.** I ran the grade port's exact spawn shape (`claude -p --model claude-sonnet-5 --output-format json --tools WebSearch,WebFetch --strict-mcp-config`) on one real watch item each: "find this week's news on X, at most 2 searches and 2 fetches, answer as JSON entries with a source URL and a confidence level". The CLI's own `total_cost_usd` envelope:
+
+| Item | Cost | Wall time | Searches | Sourced entries |
+|---|---|---|---|---|
+| Linear | $0.1156 | 41 s | 2 | 2 |
+| Replit | $0.0964 | 23 s | 2 | 3+ |
+
+Mean **$0.106 per item**, so **≈ $4.24 for a 40-item run**. About half of each item's cost is the CLI's own overhead: 34–43k cache-read tokens of its system prompt, plus a Haiku 4.5 sub-call that reads the search results.
+
+**Estimated, the direct Messages API path chosen below.** These are the repo's own rates (`src/bongos/llm-pricing.js`: sonnet = Claude Sonnet 5, $2 in / $10 out per million tokens) and Anthropic's published web-search price, **$10 per 1,000 searches**, with web fetch billed as tokens only (from the claude-api reference, cached 2026-10-06; re-verify before R04 prices a cap). Per item: 2 searches = $0.020. About 25k tokens of search and page content read by Sonnet 5 = $0.050. About 2k tokens out, thinking included = $0.020. The watch rules, about 3k tokens, are cached across the run and cost close to nothing. That comes to **≈ $0.09 per item, ≈ $3.60 for 40 items**. This is not measured. The token volumes come from the two runs above, where the search content was 23k and 35k tokens.
+
+**The planning figure is $4–5 per weekly 40-item run, about $17–22 a month.** The measured and estimated paths land within 20% of each other. **Cost does not decide between them; deployability does.**
+
+## Decision
+
+### 1. Web access: the Anthropic Messages API with server-side web tools, on the project's own key
+
+R04 calls `@anthropic-ai/sdk` (already a dependency) **from the market-watch module's own code**, one request per tracked item. The request uses model `claude-sonnet-5`, the tools `web_search_20260209` (`max_uses: 3`) and `web_fetch_20260209` (`max_uses: 2`), a bounded `max_tokens`, and structured output for the entries. The watch rules come first, in the system prompt, under `cache_control`. A `refusal`, a `max_tokens` stop, or a tool error block (these arrive with HTTP 200 and do not raise) ends that item with a recorded error. It never becomes an entry.
+
+**Not through the grade port.** That port spawns a CLI the server does not have, caches answers, and is tied to grading. This is a new LLM caller, the second server-side one after discord-support. Its model id stays a single constant in the module, so the ModelProvider port (ADR 0089 §3) can take it over later.
+
+**The key is the project's, set in Settings.** The project owner pastes an Anthropic API key into Market Watch settings (R03, [task 1004938](https://cloudbongos.com/builders#/task/1004938)). It is stored with `api.secretBox`, shown only as its last four characters, never returned or logged, and decrypted only inside a run (the ai-studio rules). Because the key is the project's own account, the project pays the provider directly. Bongos holds no money (ADR 0385) and charges no markup (ADR 0392's multiplier applies to *our* key, and Market Watch has none). **No key means no run**: the run is recorded as skipped with reason `no_key`, and the page shows it.
+
+### 2. Scheduling: Market Watch's own clock-anchored poller, on the daily-checks pattern
+
+The market-watch module declares `contributes.pollers: ["weekly-run"]`. That poller is a copy of the `autonomy/pollers/daily-checks.js` shape, not an import of it:
+- one unref'd **hourly** tick (env-overridable), first tick a few minutes after boot plus jitter, kill-switched by `ROUTINE_TIMERS_DISABLED=1`, never throws into the server;
+- **due by the ledger, not by the boot**: a run starts when Market Watch is on and the newest `market_watch_runs` row is at least 7 days old minus a 30-minute slack. A deploy restarts the timer and changes nothing about when the next run is due;
+- **resumable**: the hub redeploys on every merge, so a 20–30-minute run will sometimes be cut off. Each item's result is written as it finishes. A run left `running` for longer than its timeout is picked up by the next tick, which does only the items it has not done, and never charges twice for an item;
+- **one run at a time**: a row-level claim on the run (e.g. `UPDATE … WHERE status = 'queued' RETURNING`) so a second process on the same database cannot start a duplicate.
+
+### 3. Money: capped, recorded, fail closed
+
+- Before a run, and again **before each item**, the poller reads this calendar month's Market Watch spend. If `spent + one item's ceiling > cap`, it stops. A run that cannot start is recorded as `skipped / cap_reached`. A run that stops partway is recorded as `partial / cap_reached`, with the items it did not reach. **If the spend cannot be read, nothing runs** (`spend_unreadable`), as in `agents/lib/spend-ceiling.js`.
+- **An item's ceiling** is fixed by its bounds: 3 searches ($0.03), plus input bounded by `max_content_tokens` on the fetches, plus `max_tokens` out. R04 computes it from those numbers and states it in code, about $0.25 at the bounds above. **No item can cost more than its ceiling**, and no item starts unless its whole ceiling fits under the cap, so the cap is never overshot.
+- **The real cost** of each item is priced from the response's `usage` (tokens through `llm-pricing.priceUsage`, plus `usage.server_tool_use.web_search_requests` × the search price). Each item is written to `cost_log` under source `market-watch:<run id>` with `category: 'api'` through the economy port, keyed so a retry cannot post twice. It is the same projection rule `agents/spawn.js mirrorCostToLedger` follows.
+
+## Rejected options
+
+| Option | Why not |
+|---|---|
+| **Grade port with `tools: 'WebSearch,WebFetch'`** (the tool-enabled run) | Measured at a similar cost ($0.106/item), so there is nothing to gain. The server image has no `claude` CLI, so a deployed project would need a CLI install, `CLAUDE_BIN` and a signed-in CLI on every instance. The spawn runs under `bypassPermissions`. Opening the agents spawn path to tools means editing the protected `grading` module. The port's cache replays old answers. |
+| **Revive the cron-router poller (task 1002498) and run Market Watch as a cron agent** | The owner set it aside ("not necessary now"). It would fire through the same grade port with no CLI on the server. The agents module is off on the hub. Its ledger would record the fire as `event` (`plannedRow`). Its ceilings are per payer and per definition, not the per-project monthly cap the owner asked for. Reviving it means building four things to use one. |
+| **Autonomy's boot-anchored `routine-timers` pattern** | On an instance that redeploys on every merge it fires on each boot, so a paid run would be charged once per deploy. |
+| **A separate search API (Brave, Tavily, Exa, or OpenRouter's web plugin) plus an LLM call** | Two vendors, two keys and two bills for one run, plus a fetch-and-clean step we would have to write. Search fees are about a fifth of the per-item cost, so a cheaper search API saves at most about $0.01 an item. Their prices were not checked for this ADR. The existing OpenRouter key is **per builder**, so using it would bill a person, not the project. |
+| **The builder's own Claude Code session** (a local scheduled task) | Not unattended: a closed laptop is a missed week. It bills a builder, not the project, and its spend never reaches the project's cap or `cost_log`. |
+| **Haiku as the research model** | Cheaper per token, but the dynamic-filtering web tools (`_20260209`) need Sonnet 4.6+ or Opus 4.6+. Also, `llm-pricing.js` prices the haiku family at Haiku 4.5's rate, so a newer Haiku would be mispriced until a task adds its row. |
+
+## What R04 ([task 1004937](https://cloudbongos.com/builders#/task/1004937)) must build
+
+1. `modules/market-watch/research.js`: one Messages API call per item, with the tools, bounds and structured output above. It is pure apart from an injected client, so tests run with no network. Entries without a `source_url` that appeared in a search or fetch result are dropped. That check runs in code, not in the prompt.
+2. `modules/market-watch/pollers/weekly-run.js`: the hourly, ledger-due, resumable, single-flight poller in Decision §2, with the cap checks in §3 before the run and before each item.
+3. Cost: price each item from `usage`. **Add the web-search price to `src/bongos/llm-pricing.js`** (it has no tool fees today) as the single place it is spelled. Write to `cost_log` as `market-watch:<run id>` through the economy port.
+4. Visible outcomes for every run: `done`, `partial`, or `skipped` with `no_key`, `cap_reached`, `spend_unreadable` or `off`. These are rows in the run table (R02, [task 1004936](https://cloudbongos.com/builders#/task/1004936)), never only log lines.
+5. The key: a project-scoped, owner-set, secret-boxed key read only inside a run. R03 builds the Settings surface, and R04 reads it through one accessor.
+6. Tests: a run on seed data produces sourced entries and score snapshots. A run over the cap is skipped and visible. A spend read that throws runs nothing. A cut-off run resumes without charging an item twice. The cost appears in the roll-up.
+
+R04 must **not** touch `.github/workflows/`, the grading module, or the agents spawn path.
+
+## Consequences
+
+- A project owner turns Market Watch on with their own Anthropic key and a cap. A 40-item watch costs about $4–5 a week on that key. Bongos never touches the money.
+- The server gains a second direct LLM caller. If a third appears, the shared shape (key from Settings, bounded tools, usage priced into `cost_log`) should become a kernel helper, not a third copy.
+- The cron-router poller stays abandoned. If agents ever need a weekly cadence, they should reuse this clock-anchored pattern and first fix `plannedRow`'s mapping of `cron` to `event`.
+- **Unverified:** the direct-API figure is an estimate built from two CLI-measured items, and the web-search price is from a cached reference. R04's first real run on the hub (R09, [task 1004942](https://cloudbongos.com/builders#/task/1004942)) is the measurement that replaces both.

package/docs/adr/0395-a-task-says-what-it-needs-and-lists-show-only-what-you-can-do.md

@@ -0,0 +1,36 @@
+# 0395 — A task says what it needs, and each person's lists show only what they can do
+
+- **Status:** Accepted
+- **Date:** 2026-10-29
+- **Deciders:** The owner (direction of 2026-10-29: "what someone sees should be something they can actually do"; on this project everyone still sees everything).
+- **Task:** [task 1004950](https://cloudbongos.com/builders#/task/1004950)
+- **Related:** [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (authority read fresh, server-side), [ADR 0351](0351-a-criterion-closes-on-a-uat.md) (how the owner seat is read), the claim refusal ladder in `modules/lifecycle/CLAUDE.md`.
+
+## Context
+
+On 2026-10-29 most of the 21 claimable maintenance tasks needed the live server, a signed-in browser or an owner decision. An agent on a builder machine picked one up, read it and stopped. The lists that recommend work offered tasks the reader could not finish.
+
+The tasks table already had two session-fit fields: `automation_tag` (`overnight-safe`, `live-only`, `needs-input`) and `manual_degree`. Both answer *can this run unattended?* and feed the session-fit projection. Neither answers *who can do this at all?*
+
+## Decision
+
+**1. `tasks.needs` is its own set, not a new `automation_tag` value.** A subset of `owner` (a decision, account or permission only the project owner holds) and `server` (hands-on work on the live host: DNS, secrets, the database by hand). Empty for most tasks. A task can need both. Overloading `automation_tag` would make one field answer two questions, and a task can be overnight-safe *and* need the server. A CHECK constraint holds the vocabulary; `src/bongos/task-needs.js` holds the same list and a test pins the two equal.
+
+**2. Capabilities are resolved on the server, per request, uncached — like rank.** `owner` comes from the government owner seat (`positionsFor`), with the founding builder as the fallback, exactly as the criterion UAT sign-off reads it. `server` comes from `builders.capability_grants`, which only the person in the owner seat sets (`PATCH /builders/:id/capabilities`, also behind `builder.status.set`). Default off. Holding the owner seat does not imply server access: the owner's own agent runs on a builder machine too. Nothing in a request body can assert a capability.
+
+**3. Only the lists that RECOMMEND work narrow.** The claimable feed (`/builder-start`, the work board's ready queue, Home's Next up, the autonomous runner) and the session optimizer leave out a task whose needs are not a subset of the viewer's capabilities. The autonomous and parallel runner never holds `owner`, whoever it runs as: an agent cannot make the owner's decision.
+
+**4. The claim refuses only `server`.** A builder without the grant gets `NEEDS_SERVER_ACCESS` (403) with a plain sentence, on all three claim surfaces (`claimTask`, `claimTasksBatch`, `validateClaimBatch`, through the one extracted check `task-needs-gate.js`). Owner work stays claimable: the owner claims it, often through their own agent session, and refusing it would refuse them.
+
+**5. Visibility is unchanged.** `GET /tasks`, the board, goal pages, search and the AI's context still show every task wherever project settings allow. The board gains a *Needs* filter, and `?needs=owner` on the claimable feed is the owner's "waiting on you" queue.
+
+## Consequences
+
+- A builder without server access runs `/builder-start` and sees no server task. The owner sees owner tasks in their own list.
+- Tagging is a person's call. The create routes (`POST /tasks`, `POST /goals/:id/tasks`) and `PATCH /tasks/:id` accept `needs`, and `/goal-create` tells the planner when to set it. Existing tasks are tagged by hand once this is live: [task 1005001](https://cloudbongos.com/builders#/task/1005001) carries the 2026-10-29 first-pass list; the migration tags nothing, because task ids differ between projects.
+- `claimable_tasks` was rebuilt in the same migration so its `t.*` carries the column.
+
+## Not decided here
+
+- A third need for a signed-in browser. The 2026-10-29 list had such tasks; they are tagged `owner` for now (the owner's browser), and a separate need can be added later by extending the list and the CHECK together.
+- A settings screen for the grant. The route exists; a control in the hall can follow.

package/docs/adr/0396-google-sign-in-a-stand-in-login-and-a-browser-approved-cli-sign-in.md

@@ -0,0 +1,41 @@
+# 0396 — Google sign-in: a stand-in login, one chooser, and a CLI sign-in approved in the browser
+
+- **Status:** Accepted
+- **Date:** 2026-10-29
+- **Task:** [task 1004993](https://cloudbongos.com/builders#/task/1004993) (goal 1000095, work area 6)
+- **Deciders:** the owner (Google is the only new way in: no email codes, no passwords; never join accounts on a matching email; a stand-in name the person chooses); Claude designed
+- **Related:** **0393 (an account is a person; GitHub is one way in)**, 0016 (trust boundary), 0050 (one admission gate for web and CLI), 0141 (the hub is an identity provider), 0217 D3 (the hub sign-in records the terms), 0294 (CLI tokens do not expire)
+
+## Context
+
+ADR 0393 made a platform account a person with ways in, and minted negative person keys for people who arrive without GitHub. Nothing yet let anyone arrive that way. The owner asked for "Continue with Google" beside "Continue with GitHub" on every sign-in and sign-up screen of the hub, with the command-line sign-in working for a Google account too.
+
+Three things stood in the way:
+
+1. **Core's `builders.github_login` is `NOT NULL`.** Every hub session belongs to a builder row, and a Google-only person has no GitHub login. Making the column nullable is a core migration that every screen reading a login would have to follow.
+2. **About twenty sign-in links** on the hub's pages, plus the hall's, each go straight to GitHub.
+3. **The CLI's sign-in is GitHub's own device flow**: the terminal shows a code to type at github.com, which a person with no GitHub account cannot do.
+
+## Decision
+
+1. **A stand-in login for the builder row, never a GitHub-shaped one** (the owner's pick, 2026-10-29: a stand-in, and the person decides it). A person with no GitHub linked gets `~<handle>` as `builders.github_login`, where the handle is the one they choose on their account page; a first Google sign-in lands on `/account?welcome=google` to choose it. `~` never appears in a GitHub login, so no admission rule, first-admin seat, invite or GitHub API call keyed on a login can ever reach a real GitHub user through it. The stand-in is refreshed at each sign-in. Once GitHub is linked (task 1004995), the real login is used instead: the hub answers it with the person.
+2. **The stand-in never reaches the hub's own record.** `upsertAccount` ignores any login a caller passes for a minted (negative) key, on insert and on update, so `platform_identity_accounts.github_login` stays NULL until linking sets it (ADR 0393 §4). This also covers the hub routes that pass `req.builder.github_login` along.
+3. **The person is found by Google's own id, through the hub.** Core asks the `platform-identity.hub` port's `signInWithGoogle`, which finds the person by `(google, sub)` or creates them (`createAccountForLogin`). Emails are stored for display and never looked up. So Google sign-in exists only where the hub module runs and the owner's Google app is configured (`<PREFIX>_GOOGLE_CLIENT_ID` / `_SECRET`); every other instance is unchanged.
+4. **The ID token is checked, not trusted.** It is fetched from Google's token endpoint over TLS with our client secret, so its signature is not re-verified (OpenID Connect Core §REDACTED_IP). Its issuer, audience (and `azp` with several audiences), expiry and a per-sign-in `nonce` held in a host-only cookie beside the `state` are checked.
+5. **One chooser instead of twenty buttons.** When Google is offered, `/auth/web/start` shows a small page with both buttons rather than jumping to GitHub, so every existing link, the hall's included, gains Google at once. `via=github` is the GitHub button, and it is also used by doors that need GitHub itself: creating a project, and "New account", which names a GitHub account.
+6. **The CLI is approved in the browser.** When Google is offered, `/auth/device/start` answers in GitHub's device-flow shape, but the `verification_uri` is this site's own `/auth/device?code=…`. There the person signs in with either way, checks the code against their terminal, and presses Approve. That posts from their browser cookie only (a bearer cannot mint a bearer, as for `/auth/cli-token/issue`), same-site only, and mints a CLI session for whoever approved. The terminal's next poll receives it exactly once. The CLI needs no change. GitHub users on the hub use this page too. It is one click when they are already signed in.
+7. **Admission is the GitHub web flow's gate.** A first-time Google person is admitted only under open enrollment (they have no GitHub login an Archon could have invited), an existing one always passes, and a switched-off builder gets no session. The hub runs open enrollment.
+8. **Projects cannot take a Google-only person yet.** ADR 0393 says an older core must not be sent a minted key. `/sso/authorize` refuses one with a plain page, and "join a project" refuses before relaying. Task 1004994 opens both doors.
+
+## Consequences
+
+- A Google-only person can sign up, sign in on the hub's web pages and its hall, use the CLI, and edit their account. They cannot join another project's hall until task 1004994.
+- The stand-in shows wherever core shows a login (`~ana` in the hall). Task 1004994, which teaches halls about Google-only builders, should prefer the handle when showing one. A handle renamed on the account page reaches the builder row at the next sign-in.
+- The hub's CLI sign-in now runs through the browser approval page for everyone, GitHub users included. It shares GitHub's device-code phishing risk, and the page says the same thing GitHub's does: approve only a sign-in you just started, and cancel a link someone sent you.
+- Pending CLI approvals live in memory, like GitHub's device flows here. A restart drops one, and the person runs the sign-in again.
+- The terms page still says people sign in with GitHub. Changing it is the owner's call because it changes the agreed text and its version.
+- **Still owed before linking ships (task 1004995, the ADR 0393 carry-over):** every GitHub sign-in must find the person through `findPersonByLogin` first.
+
+## What this does not do
+
+It adds no other provider, no email codes and no passwords. It does not link accounts, show a Link GitHub chip, or guide anyone to GitHub (tasks 1004995–1004997).

package/docs/adr/README.md

@@ -147,7 +147,7 @@ These 20 numbers are each shared by exactly two files. They are **accepted histo
 | 0051 | [Full session transcripts in the BFG corpus (with transcript-grade scrubbing)](0051-full-session-transcript-corpus.md) | GDS / BFG |
 | 0052 | [Sandbox for everyone: a game-only preview entrypoint + the game in the starter clone](0052-sandbox-for-everyone-game-only-preview.md) | GDS / dev boxes |
 | 0053 | [Scoped, short-lived dev-box session + apex-cookie strip at the tunnel (SR#2/#11)](0053-scoped-dev-box-session.md) | GDS / dev boxes + security |
-| 0054 | [Flat cost-plus session token reward (example as equity): reward = round(true_cost_usd × 1.20 × 100), server-priced from per-model tokens, idempotent per session_id](0054-session-token-reward-cost-plus.md) | GDS / economy |
+| 0054 | [Flat cost-plus session token reward (example as equity): reward = round(true_cost_usd × 1.20 × 100), server-priced from per-model tokens, idempotent per session_id](0054-session-token-reward-cost-plus.md) _(credits-as-equity framing and "1 drachma = $1" superseded by ADR 0385 / ADR 0387)_ | GDS / economy |
 | 0055 | [Server-mediated branch publish (the dev box holds no GitHub credential): box uploads a thin bundle, the GDS pushes + opens the PR + auto-merges with a server-side PAT](0055-server-mediated-branch-publish.md) | GDS / dev boxes + ship pipeline |
 | 0056 | [Version-control the prod deploy script as a reviewable mirror (`scripts/deploy/deploy-prod.sh`), and retry the post-restart `/healthz` so a slow service bind no longer false-fails a successful deploy](0056-prod-deploy-script-mirror-and-healthcheck-retry.md) | GDS / deploy pipeline |
 | 0057-a | [Approve new members and first dev boxes from Discord: two Archon-only channels where a 👍/👎 fires the existing admit (`access_requests`) / first-box (`box_intents`) approve action, re-checked against the reactor's live rank](0057-discord-archon-approval-channels.md) _(box half superseded by ADR 0059)_ | GDS / Discord + onboarding |
@@ -503,3 +503,12 @@ These 20 numbers are each shared by exactly two files. They are **accepted histo
 | 0382 | [**A hardware card is a passkey step-up check, switched on per builder by an Archon** ([task 1004676](https://cloudbongos.com/builders#/task/1004676), proposed). No WebAuthn exists today; sign-in is GitHub OAuth or the hub IdP. **D1:** WebAuthn via a vetted library. **D2:** the card is a second factor, a server-recorded step-up, never the first. **D3:** register first; the requirement needs a registered card. **D4:** an Archon switches it on per builder, default off. **D5:** guards rank changes, deploy, session revoke, payouts. No PC/SC reader needed. Rejected: PC/SC middleware, card as sole login.](0382-a-hardware-card-is-a-passkey-step-up-an-archon-switches-on-per-builder.md) | auth / security |
 | 0383 | [**Sessions end after ten idle days, CLI included** ([task 1004830](https://cloudbongos.com/builders#/task/1004830)). Supersedes ADR 0294. Any session unused for 10 days stops authenticating and drops off the Active sessions list; measured on last_used_at, so it is an idle limit, not a ceiling. Rejected: hiding old sessions while they stay live; browser-only.](0383-sessions-end-after-ten-idle-days.md) | auth / security |
 | 0384 | [**The /raise investor page is a hub module that builders edit in place** ([task 1004847](https://cloudbongos.com/builders#/task/1004847)). A `raise` module, enabled only on the hub: every write is an audited `/api/bongos/raise/*` route, the page itself a GET-only `raise.web` port core mounts at /raise; team editing rides the ordinary builder session (any active builder, owner 2026-10-25); investors get a hashed-token session; /raise is exempt from the pre-launch gate. Everything, copy included, publishes with the core (owner's call); only the password hash stays in env.](0384-the-raise-page-is-a-hub-module-builders-edit-in-place.md) | modules / pages |
+| 0385 | [**Money lives with a licensed processor, credits stay a project-scoped meter, and each project sets its own pay** ([task 1004905](https://cloudbongos.com/builders#/task/1004905) · goal 1000092; also records tasks 1003180, 1003181 and 1004909). Bongos holds no user money and never redeems credits for cash; projects choose pay form and funding rule; payouts run under a project-signed rule; module sales carry a buyer-paid platform fee (processing cost plus 1 percent, per ADR 0392); crypto stays out. Six legal items are held for counsel and block the money-moving tasks.](0385-money-lives-with-a-processor-credits-stay-a-project-meter.md) | economy / legal |
+| 0386 | [**The funding wall is a per-project rule: hold at claim, refuse at completion, or carry on and record the shortfall** ([task 1003181](https://cloudbongos.com/builders#/task/1003181) · goal 1000092). Bongos sets no wall of its own; a project that sets nothing gets the claim-time hold, which refuses before any work is spent and holds the estimate so claims cannot over-commit the balance.](0386-the-funding-wall-is-a-per-project-rule-claim-time-hold-by-default.md) | economy |
+| 0387 | [**Two ledgers: credits measure work, money stays with the processor** ([task 1003180](https://cloudbongos.com/builders#/task/1003180) · goal 1000092). Resolves ADR 0054's double denomination by splitting, not by re-denominating credits into cents: `credit_log` stays a work meter with no money column, money gets its own cents record tied to the processor, no dollar value is read off a credit, and historic rows are neither rewritten nor classified.](0387-two-ledgers-credits-measure-work-money-stays-with-the-processor.md) | economy |
+| 0388 | [**A module sale is split by the project's own rule, and the buyer pays the platform fee on top** ([task 1004909](https://cloudbongos.com/builders#/task/1004909) · goal 1000092). The platform fee is the processor's cost plus 1 percent of the price, collected for Cloud Bongos LLC and never deducted from contributors; the project sets the seller share and contributor pool, the pool is divided by recorded contribution, and no paid module lists without a split rule.](0388-a-module-sale-is-split-by-the-project-the-buyer-pays-the-platform-fee.md) | economy / marketplace |
+| 0392 | [**AI generation runs on a processor-held balance or the builder's own key** ([task 1004916](https://cloudbongos.com/builders#/task/1004916)). A new `ai-studio` module: price = provider cost x one named multiplier (1.08), the processor's fee added at top-up, the full price held on the processor-held balance before any run and released on failure (Bongos keeps no balance, ADR 0385), every movement in one append-only ledger in micro-dollars; the builder's own key is entered only in Settings, encrypted, never returned or logged, and runs at no charge.](0392-ai-generation-runs-on-a-processor-held-balance-and-the-builders-own-keys.md) |
+| 0393 | [**A platform account is a person, and GitHub is one way in** ([task 1004992](https://cloudbongos.com/builders#/task/1004992)). An account's ways in (GitHub, Google) are rows the database keeps one owner for; `github_id` keeps its name and becomes the person key, positive for a GitHub-born person and minted negative for one who arrived without GitHub, so no wire format changes; `github_login` is NULL with no GitHub linked; an email is shown, never looked up.](0393-a-platform-account-is-a-person-and-github-is-one-way-in.md) |
+| 0396 | [**Google sign-in: a stand-in login, one chooser, and a CLI sign-in approved in the browser** ([task 1004993](https://cloudbongos.com/builders#/task/1004993)). A Google-only person gets `~<handle>` as the core builder login, a value no GitHub login can be, and never on the hub record; they are found by Google's own id through the hub, never an email. Every sign-in link shows Continue with GitHub / Continue with Google; the CLI sign-in is approved on this site's own page from the browser cookie. Projects cannot take a Google-only person until task 1004994.](0396-google-sign-in-a-stand-in-login-and-a-browser-approved-cli-sign-in.md) | identity / sign-in |
+| 0394 | [**Market Watch searches the web through the Messages API on the project's own key, and runs from its own clock-anchored poller** ([task 1004934](https://cloudbongos.com/builders#/task/1004934) · goal 1000137). Not the grade port: the server image has no `claude` CLI, and a measured tool-enabled run costs the same ($0.106 per item). One Sonnet 5 call per item with bounded web search and fetch, on an owner-set key in Settings (the project pays the provider; Bongos holds no money); an hourly, ledger-due, resumable poller on the daily-checks pattern, not the abandoned cron-router; capped per item before it starts and fail closed; about $4–5 per weekly 40-item run.](0394-market-watch-searches-through-the-messages-api-on-the-projects-key-and-runs-from-its-own-poller.md) | modules / economy |
+| 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 |