@bongos/core 1.18.3 → 1.18.18

package/docs/adr/0152-metic-task-abandonment.md

@@ -0,0 +1,67 @@
+# 0152 — Metic gains task abandonment, paired with an un-abandon at the same rank
+
+- **Status:** Accepted
+- **Date:** 2026-07-27
+- **Deciders:** Lars (Archon), Claude
+
+**Builds on / amends:** [ADR 0090](<redacted>.md) (Metic task authoring — this ADR reverses one line of its "what stays Archon-only" list), [ADR 0016](<redacted>.md) (server-enforced rank boundary — unchanged), [ADR 0151](<redacted>.md) (permissions-as-atom — the `task.abandon` floor moves with the gate).
+
+**Track:** `internal` (GDS / methodology — a Cloud Bongos platform capability). Task [1002476](https://cloudbongos.com/builders#/task/1002476).
+
+---
+
+## Context
+
+[ADR 0090](<redacted>.md) moved task **authoring** down to the trusted working rank: a Metic can create a task, edit it, promote it backlog→ready, and wire its dependencies and criterion links. Its "what stays Archon-only" list kept one lifecycle transition behind: `POST /tasks/:id/abandon`, described there as "terminal scope removal — the inverse of promote; a destructive lifecycle kill."
+
+A year of using that split showed the asymmetry costs more than it protects. A Metic runs `/idea-triage`, decides which ideas become work, seeds the tasks, and shapes them — and then hits a wall on the one operation that cleans up after all of it. Duplicates they created, chores that a parallel session already shipped, and tasks their own re-scoping made moot all had to be handed back to the owner to retire. The Archon was not adjudicating anything in those hand-backs; they were doing janitorial work on a queue they had already delegated.
+
+Lars's directive (2026-07-27): **"Metics should also be able to abandon tasks."**
+
+### The real risk was not the grant — it was that abandon had no undo
+
+Abandoning is a one-way door *through the API*: `/promote` accepted only `backlog`/`blocked`, `PATCH /tasks/:id` refuses `status` outright ([#514](https://cloudbongos.com/builders#/task/514)), and nothing else writes `status='abandoned'` back to a live value. Restoring a wrongly-retired task meant hand-SQL on prod — an Archon-with-ssh operation.
+
+That was tolerable while abandon *was* Archon-only (the person who could break it could fix it). Handing the kill switch to Metic without an undo would not have removed the owner-cleanup burden; it would have swapped "please retire this" requests for "please un-retire this" requests, with a worse failure mode — a wrongly-abandoned task is invisible in every claimable list and every version rollup ([migration 017](../../migrations/<redacted>.sql) deliberately excludes abandoned from `version_progress`), so nobody notices the mistake until the work silently doesn't happen.
+
+## Decision
+
+**1. Re-rank the gate.** `POST /tasks/:id/abandon` moves from `requireRank('archon')` to `requireRank('metic', 'archon')` — the same threshold ADR 0090 gave create/edit/promote. A rank trusted to seed and shape work is trusted to retire it.
+
+**2. Add the undo at the same rank.** `POST /tasks/:id/promote` now also accepts `abandoned`, restoring the task to **`backlog`**:
+
+| Route | Was | Now |
+|---|---|---|
+| `POST /tasks/:id/abandon` | archon | **metic+** |
+| `POST /tasks/:id/promote` | backlog\|blocked → ready | **+ abandoned → backlog** (metic+, unchanged rank) |
+
+Restore lands in `backlog`, never straight to `ready`. The task was retired deliberately; bringing it back should re-enter it as un-workable and require a second, explicit promote to become claimable. The restore branch returns before the reward gate ([ADR 0096](<redacted>.md)) — that is a promote-to-*workable* concern, and `backlog` is the pre-workable state, the same reasoning `/demote` already uses.
+
+The backing `db.restoreTask` is the mirror of `db.abandonTask`: `SELECT … FOR UPDATE`, guard, single `UPDATE`, commit, with `TASK_NOT_FOUND` / `TASK_NOT_ABANDONED` as its refusals. It clears the `value_summary = 'Abandoned: <reason>'` stamp abandon writes — and *only* that stamp (`CASE WHEN value_summary LIKE 'Abandoned: %'`) — so a restored task never carries a retire note into a later ship card or `#ship-news` broadcast, while an unrelated summary survives.
+
+### What is unchanged
+
+- **The abandon guards.** A `shipped` task is still refused (immutable history — retiring it would corrupt the ledger and the version rollups); a task with an **active claim** is still refused (release it first, so an abandon can never race a ship in flight); an already-abandoned task is still an idempotent no-op.
+- **The audit trail.** Both the abandon and the restore are `POST`s through the writing middleware, so `audit_log` records who retired what, with the `reason`, and who brought it back.
+- **Everything else on ADR 0090's Archon-only list** — setting rank, closing versions, grader-bypass confirm, cross-tier `POST|DELETE /dependencies` and goal-scope edges, `done-when` unsatisfy, newcomer-restock, peer-vote tally, override adjudication. This ADR moves exactly one row.
+
+### Downgrade protection + the permission catalog
+
+- `EXPECTED_RANKS`'s lifecycle pin (`src/bongos/route-rank-check.js`, `MODULE_EXPECTED_RANKS.lifecycle`) moves to `metic+archon` in lockstep, so a *further* silent downgrade (to `any-builder`) is still a hard CI fail, and the route's `// rank:` annotation matches the middleware.
+- Under [ADR 0151](<redacted>.md) the `task.abandon` permission's `floor` moves `archon` → `metic`. Because `RANK_ROLE_SEED` is *derived* from floors, that one edit re-derives the seed; the live grant arrives as `modules/governance/migrations/<redacted>.sql`, since the compat seed (002) is run-once and editing it would leave every already-migrated database on the old grant. The floor change is purely **additive** (archon already holds the permission — the seeded roles are cumulative supersets), so nothing is revoked. `tests/governance_seed.mjs` was generalized to compare the **union** of all grant migrations against the catalog, and now fails loudly if a future migration ever *revokes*, which the union model could not represent.
+
+## Consequences
+
+- **The triage→author→retire loop closes for Metic.** The owner is out of the janitorial path for the queue they already delegated; the remaining owner-only lifecycle powers are ratification and scope-closing, which is where ADR 0090 wanted the line.
+- **A mis-retire is now self-service to fix, at the rank that caused it** — and, notably, this also removes an Archon-with-ssh chore that existed *before* this grant.
+- **Restore is deliberately not idempotent-friendly the way abandon is.** Calling `/promote` on a non-abandoned task still 409s `cannot_promote` with the current status; the restore path refuses rather than guessing. That keeps `/promote`'s contract honest — it is one route with two explicit source states, not a "make this task alive somehow" verb.
+- **Larger trusted surface, same shape as ADR 0090's.** A Metic can now retire any non-shipped, unclaimed task in any open version, with no per-version/per-module fence. That is the same accepted "tighten later" debt: if Metic authority is ever folded into the goal-scope model ([ADR 0086](<redacted>.md)), abandon travels with it.
+- **Trust boundary intact** ([ADR 0016](<redacted>.md)): enforcement stays server-side, per request, uncached. Editing a doc or `CLAUDE.md` grants nothing; `requireRank('metic','archon')` on the route is the authority.
+
+## Alternatives considered
+
+- **Re-rank abandon with no undo.** Rejected: it relocates the owner-cleanup burden instead of removing it, and the failure mode (a silently-invisible task) is worse than the one it fixes. The undo is ~40 lines including its guards.
+- **A dedicated `POST /tasks/:id/restore` route.** Rejected as surface for its own sake: `/promote` already *is* the "move this task toward workable" verb at exactly the right rank, and the restore is a third source state on it. A separate route would need its own gate, its own pin, its own catalog permission, and its own docs row — all to express the same transition.
+- **Restore straight to `ready`.** Rejected: it would make a two-keystroke mistake (abandon → restore) leave the task claimable again with no human re-read of *why* it was retired. Landing in `backlog` costs one deliberate extra call and puts the scope decision back in front of someone.
+- **Fence the grant (only tasks the Metic authored, or only non-`security_sensitive` ones).** Rejected as a rule builders have to learn for a threat that isn't real here: a Metic can already `PATCH` and re-scope any task, so "abandon only your own" fences nothing they couldn't achieve by editing. ADR 0090 made the same call for authoring.
+- **Promote the affected builders to Archon.** Rejected for the reason ADR 0090 gave: Archon also carries rank-setting, version-close, grader-bypass, and infra — far more than "clean up the task queue."

package/docs/adr/0153-sequential-chain-runner.md

@@ -0,0 +1,51 @@
+# ADR 0153 — Sequential chain execution: one kickoff walks a dependency chain
+
+- **Status:** accepted
+- **Date:** 2026-07-28
+- **Task:** 1002484
+- **Relates to:** [ADR 0015](<redacted>.md) (dependencies + auto-promotion), [ADR 0049](<redacted>.md) (the split parallel-safety contract), [ADR 0086](<redacted>.md) §5 (polymorphic dependency edges)
+
+## Context
+
+ADR 0015 made `dependencies[]` load-bearing: a task cannot be claimed until its predecessors ship, and shipping a task auto-promotes its now-unblocked dependents `backlog`→`ready` (the `promote_dependents_on_ship` trigger, migrations 020/163). That machinery works. What it does not do is **pick the newly-unblocked task up**.
+
+The result, measured on the live instance on 2026-07-28: **146 of 303 open tasks sit behind a predecessor, and only ~79 are `ready`** at any moment. A single planning seed like goal 1000045 fronts a 24-task chain worth 1,440 credits and ~62 hours. Working it meant 24 separate human kickoffs — each one a fresh session that had to re-derive what was now claimable.
+
+The only "sequential" affordance was `<redacted>` in `modules/hall-ui/public/work.js`: a clipboard template listing manually multi-selected tasks in topological order. Two problems. It is *text*, not execution. And the tasks a chain most needs to queue — the dependency-gated successors — are not selectable on the board at all, because they are still `backlog`.
+
+Two builders asked for this independently: idea 1000461 (jaxri — workflows that run tasks "in parallel or sequentially") and idea 1000398 (IAMMASTERQUA — chains as the claimable unit, priced by total chain value).
+
+## Decision
+
+Ship a **chain runner**: one kickoff walks a dependency chain end to end.
+
+**1. No schema change.** The ordering already exists in the polymorphic `dependencies` table, the `task_is_fully_unblocked` predicate, and the promote-on-ship trigger. `GET /tasks/:id` already returns `dependencies[]` and `dependents[]`. Adding a `queue`, `chain_id`, or `next_task` column would create a second, drift-prone source of truth for an order the graph already encodes. The runner derives the chain on demand and stays stateless.
+
+**2. No new claim guard.** One-active-claim-per-session is keyed on the *working tree* (`shouldRefuseSessionClaim`, `modules/lifecycle/routes/claims.js`), so ship-before-next-claim is already enforced — which is exactly the sequential shape. The chain therefore claims **one task at a time**, and a task is always fully `shipped` before the next is claimed. Batch-claiming a chain is not merely discouraged, it is impossible: successors fail `DEPS_NOT_SHIPPED` by construction, because their predecessor has not shipped yet. The ship *is* the thing that unblocks the next step.
+
+**3. Split deterministic plumbing from judgement.** `scripts/gds/sequence.js` resolves scope, orders it, and evaluates a halt matrix — all from facts on the task row, no model judgement. `.claude/skills/builder-sequence/SKILL.md` owns the loop and defers to `/builder-claim`, `/dev`, and `/builder-ship` for their existing mechanics. A halt is a named reason with a non-zero exit code, not a narrative.
+
+**4. Halt, do not skip** (owner decision, 2026-07-28). When the next task is something the runner should not decide alone, it **stops and reports**, leaving that task claimed. It does not ship a half-finished task, and it does not skip ahead to the next unblocked sibling.
+
+The halt matrix: `needs_migration`, `security_sensitive`, `protected_path` (touches[] ∩ `PROTECTED_GLOBS`), `rank_floor`, `thin_spec`, `judgement_kind` (`decision`/`spike`), `not_claimable`, `deps_unmet`, `in_flight`, `cycle`. The skill adds two it must detect itself: `ship_failed` and `scope_surprise`.
+
+## Why halt rather than skip
+
+Skipping looks like the higher-throughput option and is not. In a dependency graph, a skipped task is a *predecessor* — skipping it strands everything behind it, so the run continues while quietly guaranteeing that the rest of the chain cannot complete. The apparent progress is the dangerous part: a run that skipped three tasks and shipped nine reads as a success until someone asks why the chain never finished.
+
+Halting also makes unattended running safe, which is the whole point of one kickoff. The owner can start a chain and walk away knowing the failure mode is "stopped early with a reason", not "made twelve judgement calls you have not seen yet".
+
+## Consequences
+
+- A chain of N mechanical tasks now costs one kickoff instead of N.
+- Chains stop silently stranding: a halt names what a human must do, so the queue does not just quietly stop advancing.
+- The halt matrix is deliberately conservative. Tasks with thin specs will halt runs, which is a **feature** — it turns "the runner stopped" into pressure to write acceptance criteria at planning time.
+- `not_claimable` defers to the server's own claimable feed rather than re-deriving its filter client-side. If that endpoint is unreadable the runner stays quiet rather than halting on everything — an early bug where the envelope key was misread (`tasks` vs `claimable`) turned an empty result into a universal halt, and the null-vs-empty distinction is now covered by a test.
+- **Not built:** chains as a priced, claimable unit on the Tasks board (idea 1000398). The runner is the capability; surfacing chains with their total value is a separate, additive change.
+
+## Alternatives rejected
+
+- **A `chain_id` / queue table.** A second source of truth for an order the dependency graph already encodes, and one that drifts the moment an edge is added.
+- **Batch-claim the whole chain up front.** Impossible under the dep gate, and it would defeat the isolation that makes each ship safe.
+- **Let the runner use judgement and keep shipping** (the third option the owner was offered). Faster, but it moves review after the fact — the owner would be auditing decisions that had already landed.
+- **Extend `overnight-builder`.** That routine walks the claimable queue by priority across the whole backlog; this walks one bounded chain the user pointed at. Different scope, and the routine is instance-only (absent from the portable core).

package/docs/adr/0154-goal-owner-criterion-authoring.md

@@ -0,0 +1,86 @@
+# 0154 — A goal's done-when criteria are authored by that goal's owner or managers
+
+- **Status:** Accepted
+- **Date:** 2026-07-29
+- **Deciders:** Lars (owner / Archon), Claude
+
+**Builds on / amends:** [ADR 0086](<redacted>.md) (the goal tier — this ADR extends its owner/manager authority to the goal's criteria), [ADR 0090](<redacted>.md) (Metic task authoring), [ADR 0106](<redacted>.md) (owner vs manager), [ADR 0105](<redacted>.md) (why this route exists at all), [ADR 0016](<redacted>.md) (server-enforced rank boundary — unchanged), [ADR 0151](<redacted>.md) (permissions-as-atom — and see §5, which corrects one of its rows).
+
+**Track:** `internal` (GDS / methodology). Task [1002538](https://cloudbongos.com/builders#/task/1002538), under the **Builder experience** goal [1000025](https://cloudbongos.com/builders#/goal/1000025).
+
+---
+
+## Context
+
+The Metic planning loop is complete except in one place. A Metic may create a goal ([ADR 0086](<redacted>.md): `POST /goals` is `requireRank('metic','archon')`), author the tasks under it ([ADR 0090](<redacted>.md)), wire their dependencies and criterion links, and **confirm** a criterion when the work lands ([ADR 0086](<redacted>.md) §6 re-ranked `POST /done-when/:criterionId/satisfy` to Metic+ "so the planner — not only the Archon — closes the criterion/goal loop").
+
+But they could not **create** the criteria those tasks are measured against: `POST /versions/:id/done-when` was `requireRank('archon')`. So a Metic could stand up a goal, fill it with work, and close its criteria out — but had to ask an Archon to write them in the first place. That is the one Archon-shaped hole in an otherwise Metic-complete loop, and it is what blocked `/goal-create` ([1002540](https://cloudbongos.com/builders#/task/1002540)) from being a skill a Metic can actually run end to end.
+
+### Why the obvious fix — a flat re-rank — is wrong
+
+The tempting move is symmetry: a Metic may confirm a criterion, so let them create one. That argument does not survive contact with what a criterion *does*.
+
+**Creating an unsatisfied criterion is a backward ratchet, and there is no undo.** Every "is this done" aggregate counts unsatisfied rows:
+
+- `modules/lifecycle/version-close.js` gates on `criteria.satisfied === criteria.total`, counted **per version regardless of goal**. One unsatisfied row parks the version's close suggestion indefinitely — and that suggestion is served on the **unauthenticated** `GET /versions/close-suggestions`, so it is publicly visible.
+- `db.achieveGoalIfComplete` refuses while `unsatisfied > 0`, so the goal never auto-achieves, and `promote_dependents_on_goal_achieve` never releases the tasks waiting on it.
+
+That is operationally the same effect as `POST /done-when/:criterionId/unsatisfy` — which is Archon-only, and which `docs/governance/<redacted>.md` lists in the same Archon "Lifecycle disposition" line as this route. And there is **no DELETE route for a criterion**: descoping is direct SQL under a claim. A mistake is not correctable through the API by anyone.
+
+**The create path also had no ownership check whatsoever.** Its entire authorization surface was `requireBuilder` → `requireRank` → version exists → (if `goal_id` given) the goal belongs to that version. That last one is referential integrity, not authority. Every *other* goal-touching write in the module runs `authorizeGoalManagement` (owner | manager | Archon) or `authorizeGoalTaskCreate` (membership + scope wall). A flat re-rank would therefore have let any Metic attach a permanent, un-deletable criterion to **any goal on any version**, including goals they had never joined and private goals ([ADR 0112](<redacted>.md)) — published to the anonymous status feed.
+
+`docs/canonical-permissions.md` named "set version scope (`done-when`)" as Archon-exclusive. A flat re-rank contradicts that flatly; the decision below narrows it instead.
+
+## Decision
+
+**Authority over a goal's criteria follows goal ownership, not global rank.**
+
+`POST /versions/:id/done-when` becomes `requireRank('metic','archon')`, plus an **ordered, fail-closed in-handler wall** for any non-Archon:
+
+| Step | Refusal |
+|---|---|
+| a `goal_id` must be named | `403 goal_id_required` |
+| the caller must be the goal's **owner or a manager** | `400 bad_goal_id` — **masked**, see below |
+| the goal must be `open` | `409 goal_not_open` |
+| the version must be open (`planning` or `building`) | `409 version_closed` |
+
+An Archon short-circuits all four: version-level (goal-less) criteria, goals in any state, and versions in any state stay theirs.
+
+The authority predicate is `isGoalOwnerOrManager` — the **same** owner-or-manager test behind visibility changes, invitations, join-request responses, member roles and conflict resolution. It moved from `modules/lifecycle/routes/goals.js` to a module sibling, `modules/lifecycle/goal-authz.js`, so both routes share one definition of "who holds this goal"; `authorizeGoalManagement` is rebuilt on it and re-exported from `routes/goals.js`, so its existing DB-free tests are untouched. No route requires another route.
+
+### Authority is checked before state, and the refusal is masked
+
+Ordering matters here in a way it does not for the sibling goal routes. Those are reached by callers who already know the goal exists (they are looking at it); this one takes an arbitrary integer `goal_id` from any Metic.
+
+If the refusals were distinguishable — `400 bad_goal_id` (no such goal) vs `403 not_owner_or_manager` (exists, not yours) vs `409 goal_not_open` (exists, settled) — the route would be an **existence oracle**: a Metic could enumerate `goal_id`s and learn which exist on a version, including **private goals** ([ADR 0112](<redacted>.md)). That surface did not exist while the route was Archon-only, because an Archon can already read every goal. Re-ranking it creates the surface, so the re-rank has to close it.
+
+So the ownership test runs **ahead of** both state checks, and a caller who fails it gets byte-identical `400 bad_goal_id` to one naming a goal that does not exist — same code, same message, same envelope, rendered by the same `badGoalId()` helper the genuine-absence branch uses. Only someone who already holds the goal learns anything further about it. This mirrors the O1 no-leak ordering the goal abuse matrix already pins (`not_a_member` is returned before any scope hint).
+
+**What does not move.** `POST /done-when/:criterionId/unsatisfy` stays Archon — un-flipping a *confirmed* criterion rewrites shipped scope-truth, and keeping the backward ratchet at the top rank is the safety this grant is paired with. It was previously **unpinned** in `route-rank-check`; this ADR pins it at `archon` so a silent downgrade reds the build.
+
+### Why this is the right boundary
+
+Creating a criterion inside a goal you own is not scope-*truth* authorship in the sense the Archon gate was protecting — it is describing the finish line of a workspace you are already accountable for. The blast radius is bounded by something the actor already holds. Creating a criterion at the *version* level, or inside someone else's goal, still shapes the project's scope for other people, and that stays Archon.
+
+## Consequences
+
+- `/goal-create` becomes genuinely Metic-runnable: create the goal → write its criteria → seed its tasks, in one session, without an Archon in the loop.
+- A Metic can still park **their own** goal by adding a criterion they never satisfy. That is a self-inflicted wound inside their own workspace, visible in `/goal-review`, not an attack on anyone else's.
+- The proposal → ratify queue (`kind='criterion-proposal'` → `POST /inbox/:id/ratify`, Archon-only) remains the path for **version-level** criteria and for anyone who is not the goal's owner. It is no longer the only path for a goal owner describing their own goal. Note the direct path writes one row and awards no `proposal_ratified` karma and no `criterion_proposal_audit` provenance — proposals remain the richer, attributable route, and the one an Archon adjudicates.
+- Five generated artifacts regenerate (`docs/api/openapi.json`, `docs/api-reference.md`, `docs/routes-permissions.md`, `clients/bongos-client/*`), because the rank flows into the published contract via the `// rank:` annotation.
+
+## §5 — A correction to ADR 0151's catalog
+
+[ADR 0151](<redacted>.md)'s "floor `metic` today" table bundles three routes into one row:
+
+> `criterion.satisfy` / `criterion.review` | `POST /done-when/:id/satisfy`, `GET /done-when/pending-review`, `POST /versions/:id/done-when`
+
+Two of those were Metic; the third (`POST /versions/:id/done-when`) was **Archon** at the time that table was written. 0151's own cited source — the exhaustive `docs/governance/<redacted>.md` — lists it correctly under Archon. The bundled row was a transcription slip, and it was latent-dangerous: 0151's R94 compat seed grants "exactly today's powers," so seeding from that row would have handed the `metic` role an Archon route, and R103's parity test would either have gone red or, worse, ratified the escalation.
+
+This ADR makes the row's *outcome* correct but for a different reason, so the row is split anyway: `criterion.create` is its own atom, floor `metic`, **qualified by the goal-ownership wall above** — a floor alone does not describe this permission.
+
+## Alternatives considered
+
+- **Leave it Archon; use the proposal queue.** Rejected: it keeps the Archon in the loop for a Metic describing a goal they own, which is the janitorial-delegation problem [ADR 0152](<redacted>.md) already named. The queue survives for the cases that genuinely need adjudication.
+- **Flat re-rank to Metic+.** Rejected — §Context.
+- **Add a DELETE for criteria so the ratchet has an undo** (the [ADR 0152](<redacted>.md) "pair the grant with its inverse" pattern). Deferred, not rejected: it is the honest completion of "manage," and it would neutralise the no-undo objection directly. It is a new capability nobody has today — including Archons — and deleting a criterion with linked `task_criteria` rows needs its own cascade decision. Worth its own task.

package/docs/adr/README.md

@@ -214,5 +214,15 @@ This keeps the decision history honest and traceable.
 | 0140 | [cloudbongos.com re-provisioned to the ADR 0108 standalone model, DB-PRESERVING — closing ADR 0139's skipped WS-0 (executed 2026-07-12). The site was a lift-and-shift clone of the `example` repo frozen on stale code — every `/builders/*` asset 404'd — because its pull-deploy silently no-op'd against the unchanged game repo (`origin` was `example-owner/example`, not a cloudbongos instance); it had never run the restored code. WS-0's original fresh-DB re-provision would now WIPE the migrated history/balances, so a build-alongside-then-flip variant was used: a dedicated private `cloudbongos/cloudbongos-instance` repo (lean config over the neutral brand + a pinned `@bongos/core@1.17.3`), materialized beside the untouched old checkout, proven on a spare port against the live DB (migrate = clean no-op; leaderboard read migrated balances), then `cloudbongos.service` flipped to the instance + engine and the ADR 0129 pull-timer repointed at the instance repo. Engine source stays authoritative at `example-owner/cloud-bongos` (not relocated); verified DB backup + retained old checkout/unit/deploy-script give instant rollback. Enabled org-wide deploy keys on the `cloudbongos` org so the box's read-only deploy key could attach.](<redacted>.md) | infra / Cloud Bongos |
 | 0141 | [Cross-site identity — cloudbongos.com becomes a federated identity provider (the "hub") so one platform account reaches any hosted project's builders hall, browser AND CLI, with no second GitHub sign-in (Goal 41 design of record; task [#1002082](https://cloudbongos.com/builders#/task/1002082); implemented across [#1002106](https://cloudbongos.com/builders#/task/1002106)–[#1002115](https://cloudbongos.com/builders#/task/1002115)). Core principle: **identity is federated, authority is not** — the hub carries identity ONLY (github_id, login, display name, avatar), never rank/credits/admission, so [ADR 0016](<redacted>.md)'s self-owned-authority boundary is preserved by construction. Federation is opt-in + reversible via a config switch (`auth.idp`): a hosted instance provisioned with `auth.idp` + `<PREFIX>_HUB_*` routes web sign-in through the hub's `/sso/authorize`→`/sso/token` (OAuth authorization-code, single-use 60s codes, server-to-server client-secret redemption) and CLI sign-in through the hub's device flow + an audience-scoped Ed25519-signed assertion verified offline at a new `/auth/device/exchange`; a self-hosted instance leaves `auth.idp` unset and keeps owning its own GitHub app (the direct-GitHub path, unchanged fallback). Adds a hub `platform-identity` module (accounts / sso_clients / sso_authorization_codes / projects / project_memberships / builder_project_activity), a project→hub membership check-in inside upsertBuilder (coarse role, never rank), a My Projects view with project-executed join/leave, a curated public Explore showcase, per-builder cross-project activity rollups, and an Archon-only cross-project scouting view (upgrading the coarse [ADR 0127](<redacted>.md) fleet gauges to a github_id-keyed store). Two credential types by design: per-client hashed secret (instance→hub server-to-server auth) + a hub Ed25519 keypair (CLI assertions, asymmetric so one instance can't forge for another). Was scoped as "ADR 0135"; that number was reassigned, so it lands here as 0141.](<redacted>.md) | auth / Cloud Bongos identity |
 | 0142 | [Project context is prose-only; the structured host-identity contract is branding (audit H11 / finding F7; task [#1002224](https://example.com/builders#/task/1002224), goal 1000042). Branding flows as a structured neutral⊕instance→validated-resolver contract because CODE reads those strings; project context (vision/world/visual-style in `docs/project-context.md`, scaffolded from the shipped `docs/project-context.template.md`) is deliberately narrative — read by AI agents, never parsed by code — so it stays prose-only with no parallel resolver/schema/env layer (YAGNI: no consumer; branding already covers code-read strings; the publish boundary + the CLAUDE.md/AGENTS.md stub already enforce the split at the file level per [ADR 0062](<redacted>.md) §7). A new host value that code must read goes in branding, not a new project-context resolver. Revisit only when code (not agents) must read project context as validated, structured data.](<redacted>.md) | core / host-split |
+| 0144 | [Federated single-logout: hub-initiated back-channel session revocation (task [#1002238](https://cloudbongos.com/builders#/task/1002238), goal 41; follow-up to [ADR 0141](<redacted>.md)). ADR 0141 gave single sign-ON but not sign-OFF — a federated instance mints its own local session after the SSO handshake, so hub logout left every project still signed in. Owner chose **back-channel** (server-to-server) over front-channel (browser-driven, breaks under third-party-cookie blocking, incomplete if the tab closes) and soft-sessions (per-request hub re-check — too heavy, hard hub dependency). Core `POST /auth/logout` emits a `builder.logout` seam EVENT (no-op unless a module listens); the hub `platform-identity` module reacts by minting a **hub-signed EdDSA logout token** (`mintHubLogoutToken` — same envelope/key/~120s-TTL/aud-binding as the login assertion) per entered project and POSTing it to each `{origin}/api/gds/auth/backchannel-logout`; that core endpoint (dormant unless `idpConfigured()`, else 404) verifies via `verifyHubLogoutToken` against the hub pubkey and calls `revokeAllSessionsForBuilder`. The token carries only `{sub, purpose:"backchannel-logout"}` — **never** identity/rank (ADR 0016 boundary holds); the **`purpose` marker makes login assertions and logout tokens mutually non-interchangeable** (a login assertion lacks purpose → rejected as logout; a logout token lacks github_login → rejected as login). Entered-instance list = existing `<redacted>` (over-notify is safe — revoke is idempotent); fan-out is best-effort, per-instance 4s timeout, `Promise.allSettled`-isolated, never blocks/fails the logout (hub session revoked synchronously). No new schema, no doorway change; core `1.18.5→1.18.7`; re-vendors BOTH hub + federated instances. V1 = hub-initiated only (instance→hub propagation + a precise per-session ledger + unreachable-instance retry are follow-ups).](<redacted>.md) | auth / Cloud Bongos identity |
+| 0145 | [A free "own-repo" hosted project tier can NOT be a bare `cloudbongos.com` subdomain running the owner's code — a pre-build security review found it unsafe two ways (owner design review, [task 1002249](https://cloudbongos.com/builders#/task/1002249); follow-up to [ADR 0141](<redacted>.md)/[0143](<redacted>.md)). (1) The hub `gds_session` cookie is `Domain=.cloudbongos.com`-scoped (so `builders.`/`status.` share one sign-in), so an owner-controlled `<slug>.cloudbongos.com` instance would receive every signed-in visitor's live hub token → account takeover; `httpOnly`/`sameSite:lax` don't help (same registrable domain = same site). The co-tenant instances that safely federate on cloudbongos.com subdomains (e.g. `demo.`) do so only because they run PLATFORM code, not owner code — so the precedent doesn't extend. (2) A control-plane-local `standalone` runs owner code on the hub box as `lars` with passwordless sudo in its `npm ci` deploy → root-on-hub (pre-existing, independent of federation). The federation protocol itself is sound (origin-bound, asymmetric Ed25519); the weakness is PLACEMENT + EXECUTION. **Decision:** a free own-repo tier is delivered ONLY behind (a) domain separation — free instances under a different registrable domain than the hub, so they never get the cookie — AND (b) per-project isolation (own droplet / container, distinct UID, `--ignore-scripts`, no passwordless sudo); only then is federation safe to extend. Owner chose this direction over the co-tenant free tier (safe/$0 but no own repo) and the honest-copy status quo. Build blocked on owner decisions: which separate domain, droplet-vs-container isolation, and the cost model (paid tier vs capped subsidy — [§4](../../CLAUDE.md)). Points 1&2 of the review (repo-step polish) were unrelated + already shipped ([task 1002247](https://cloudbongos.com/builders#/task/1002247)).](<redacted>.md) | auth / provisioning / Cloud Bongos identity |
+| 0147 | [Carry ADR 0110's deploy-regen of generated docs to STANDALONE instances ([task 1002314](https://cloudbongos.com/builders#/task/1002314); the owner's "docs didn't transfer from primea"). The monorepo keeps its generated nav docs live because ADR 0110's regen is wired into `deploy-prod.sh`; standalone instances ([ADR 0108](<redacted>.md)) never got it — their bespoke pull-deploy regenerated nothing and `init`/`upgrade` only did the API docs, so cloudbongos.com's `docs/` was frozen with just the 3 API files. Two defects: (1) `gen-session-index.js` hardcoded the CORE root (`path.resolve(__dirname,'..','..')`) so on a standalone box it indexed `node_modules/@bongos/core`, not the instance — now `resolveInstanceRoot()`; (2) no standalone regen path. Fix: `upgrade.regenerateNavDocs()` + a `regen-instance-docs.js` CLI, wired at every refresh point (init seed, `bongos upgrade`, `provision.js` standalone deploy, and a bespoke `deploy.sh` one-liner); `INSTANCE_GITIGNORE` ignores the whole-file docs. Scope is `session-index` ONLY — the one gitignored, whole-file, instance-content nav doc; `repo-map` is core-scoped (empty for a code-less standalone; brownfield map = task 1001655), `file-map` + API docs are tracked/committed (file-map seeding at standup = follow-up), diagrams are the headless-browser exception.](<redacted>.md) | docs pipeline / Cloud Bongos |
+| 0146 | [Configurable reward mode — an instance chooses whether a shipped task pays BOTH reward streams or ONLY the cost-plus one ([task 1002270](https://cloudbongos.com/builders#/task/1002270), goal 1000037; follow-up to [ADR 0120](<redacted>.md)). A shipped task pays two streams onto one balance (the [ADR 0054](<redacted>.md) "two conventions, one ledger" tension): the per-task author ESTIMATE (`credits_reward` × kind multiplier — unitless, [ADR 0023](<redacted>.md)) AND the cost-plus SESSION reward (`round(true_cost_usd × 1.20)`, 1 credit = $1 — ADR 0054). New `branding.reward.mode`: `"cost-plus-and-estimate"` (DEFAULT — pay both, exactly today's behavior; every existing instance unchanged on upgrade) or `"cost-plus-only"` (the cost-plus reward is the SOLE equity reward; the per-task estimate PAYOUT is withheld and its idea-promotion slice cascades to 0). Resolved by a pure `rewardPolicy()`; gated in the single per-task credit writer (`insertMultipliedConfirmCredit`) — entirely inside the economy module, ZERO lifecycle changes. `credits_reward` still rides the task row for display + the no-zero-reward claim gate; only the payout is suppressed. Unknown mode → default (a typo can't silently zero rewards). Cloud Bongos selects `cost-plus-only`; achievements + the net-negative +1 bonus are out of scope. Backward-compatible + reversible — no clawback, no migration.](<redacted><redacted>.md) | GDS / economy |
+| 0149 | [`bongos dev` — a one-command LOCAL launcher for a standalone instance repo (owner ask, 2026-07-19: "we need a better option to stand up the local host"). A freshly-created project's `config/branding.json` points at `http://localhost:<port>` — configured to run on the owner's machine — but the platform shipped no command to START it there; `bongos onboard` provisions a CLOUD server and Docker serves a vanilla brand on `:3000`. Standing it up by hand was a six-part assembly (Postgres → createdb → migrate → PORT/PGDATABASE/PGHOST/OAuth env → server → login) with three silent mismatches: the server reads PORT from env not branding (platform-server.js:44); the pool DB name collapses to the OS user while migrate.sh defaults to `example` (pool.js:47 vs migrate.sh:52) unless PGDATABASE is set for BOTH; and node-pg defaults to the Linux peer socket `/var/run/postgresql` (pool.js:46), absent under Homebrew on a Mac. `bongos dev` does the whole thing idempotently from one source of truth (branding): ensures Postgres, createdb, migrate (`MEDUSA_GDS_ONLY=1`), starts the server on the branding port, and signs in. The background server is MANAGED (pid/log per instance) with `bongos dev stop`/`status` — the fix for the orphaned-server accident (a stale `:3005` answering a new project's login). Pure resolution + process mgmt in `scripts/gds/dev-lib.js` (unit-tested `tests/dev_lib.mjs`); orchestration in `scripts/gds/dev.js`. Alternatives rejected: cloud dev box (needs hosting + cost — kept for remote work), Docker (vanilla brand/wrong port — kept for Windows), recipe-only (leaves the six steps). Not bundled into the standalone on-ramp binary (needs a real checkout).](<redacted>.md) | Cloud Bongos / dev experience |
+| 0150 | [Box first-boot bring-up on vendored instances — resolve `infra/` from the instance root + fail loud on empty user-data (spike BV1.R97, [task 1002385](https://cloudbongos.com/builders#/task/1002385); C2 of goals 1000051/1000052, "make cloudbongos boxes stop coming up bare"). Root cause: `box.js` sets `REPO_ROOT` two dirs up from itself, which on a VENDORED instance is the `@bongos/core` package — but the R89 packaging split kept `infra/` (the DO cloud-init template + inlined `box-source-fetch.sh`/cloudflared/ttyd/heartbeat scripts) as INSTANCE content, not in the core publish-manifest. So `readCloudInit` reads a missing template, its `try/catch` returns `null`, and the caller's only guard (`0 > 64KiB`) passes → the box is created with EMPTY user-data and boots bare Ubuntu (no clone, no toolchain, no terminal); `fileGzB64` is likewise fail-soft (warns, returns `''`) so a partial `infra/` half-wires. Live re-confirmed 2026-07-19: instance-root `infra/` present, vendored-core `infra/` gone (the [ADR 0144](<redacted>.md) node_modules workaround wiped by a reinstall), fleet idle so the bug is latent-but-live (next provision boots bare). Fix (R98, [task 1002386](https://cloudbongos.com/builders#/task/1002386)): a `resolveBoxInfraDir()` locating `infra/` via [ADR 0108](<redacted>.md)'s `resolveInstanceRootExplicit()` (cloudbongos `bongos.config.json` = `{"instanceRoot":"."}`) + an env override + a walk-up-out-of-`node_modules` fallback, AND fail-loud backstops (throw on missing template; abort provision on empty user-data). R99 ([task 1002387](https://cloudbongos.com/builders#/task/1002387)) then ensures the toolchain builds on the box. Reinstall-proof + portable; core-only, no migration/doorway change.](<redacted>.md) | GDS / dev boxes |
+| 0151 | [Governance: **permissions are the atom, ranks become seeded roles** — the foundation of the BONGOS-V1 Governance goal (1000030), spike BV1.R90 ([task 1001838](https://cloudbongos.com/builders#/task/1001838)); settles the model in an ADR before R93–R114 build. Authority stops being an all-or-nothing rank threshold ([ADR 0016](<redacted>.md)/0018/0034) and becomes granular **permissions** (code constants that map 1:1 to real routes/surfaces — a permission no route consumes doesn't exist), bundled into assignable **roles**; the four live ranks become four seeded roles whose grants reproduce today's thresholds EXACTLY (the compat seed — cumulative nested supersets, so the resolver's UNION preserves the at-or-above threshold), and `builders.rank` stays as the identity/graduation column. A per-request **uncached** `resolveBuilderPermissions()` (kernel port, preserving ADR 0016's instant-demotion) + a `requirePermission()` gate that coexists with `requireRank` via the seed → gates migrate route-by-route, no flag day. The **complete authority model** (C3) represents four axes as first-class types, not rank special-cases: rank-seeded roles, machine **principals** (`system_role`=bfg/discord_bot, exact-identity gate, never UI-grantable), **session-scopes** (box tokens, deny-by-default allow-list intersected with the builder's roles), and **ownership-scoped** perms (`X.manage.own` ≠ `.any`; goal owner/manager per [ADR 0106](<redacted>.md)). The safety keystone (C6): every permission carries a **`system` flag** — `system:true` (deploy, protected-path, rank-set, version-close, grade-bypass, cross-tier edges) is **non-grantable** and LOCKED in the tab, so no configurable role can hand out the crown jewels; and the today-hardcoded `PROTECTED_GLOBS`/`EXPECTED_RANKS` map becomes a **governance-owned protected-surface registry** that the OUT-OF-BAND substrate (pre-push hook, grader pre-pass, `main-audit.js`, gate-review — [ADR 0043](<redacted>.md)) READS but never moves in-process: **policy owns / substrate enforces** — the tab can re-map the floor but a forced `system` grant still can't deploy (abuse-matrix + live-demo proofs, R112/R114). Capability in **core** (`modules/governance/`, default:true); role templates are per-instance **config** (`config/governance.json` over `config/governance.neutral.json` over env, mirroring `src/branding.js`), live assignments in the DB. Collapses the ~6 duplicated numeric rank-tier maps (the Builder-25-incident drift class) behind the resolver. Zero day-one behavior change (parity test R103); one deliberate fail-closed divergence (unwired divine ranks map to no role instead of latently inheriting Archon). Includes the full enumerated permission catalog (every key + `system` flag) grounded in the 2026-07-24 authority sweep. No new recurring cost.](<redacted>.md) | governance / permissions / Cloud Bongos |
+| 0152 | [The landing gate is served by the **core app**, not by the front proxy — the cutover step of the landing migration ([task 1002411](https://example.com/builders#/task/1002411), L05 of goal 1000035). The reference instance's orb-gate front page was `file_server`'d by Caddy straight out of a checkout of an UNRELATED product repo (`root * <checkout>/brand/cloud-bongos`), so the landing had two sources of truth, no deploy path of its own, and a cross-product coupling the core could not express. [L01](https://example.com/builders#/task/1002407) had already ported the bundle into the core as `public-landing/` and [L02](https://example.com/builders#/task/1002408) had already taught `platform-server.js` to serve it (`/` -> 302 `/gate/`, `/gate/` serves the index raw, `express.static` covers the assets) — so by the time L05 came up, BOTH halves of its original plan ("give the landing (a) its own Caddy config and (b) its own deploy script") had dissolved. **Decision:** the app owns the landing end to end; the proxy drops `root` + `file_server` and keeps exactly three jobs on that surface — TLS, an optional pre-launch `basic_auth` lock, and the `@hidden` guard that keeps `gate/README.md` unreachable. No separate Caddy config to write (the resulting block IS the generic pure-proxy shape `provision.js`'s `caddyBlock()` already emits per instance, [ADR 0111](<redacted>.md) §4; host-specific hostnames/certs stay on the host per [ADR 0062](<redacted>.md) §7) and no separate deploy script to write (the landing ships INSIDE the pinned core package, so it rides the instance's existing pull-deploy — one artifact, one version, one path). Keeps `redir / /gate/ 302` because Caddy orders `redir` before `basic_auth`, so "/" behaves identically before and after, and the app issues the same 302 once the lock is lifted. Cost accepted: the landing now sits in the app's request path (a dead app = a dead front page — but the gate's whole purpose is to reach the app), and a landing tweak now needs a core release. Verified on the live instance: identical status codes across the apex and both vanity doors before/after, relative redirects (no origin leak), and a **severance test** — with the foreign repo's landing folder moved aside entirely the site still served the byte-identical gate, proving the dependency is cut rather than merely unused. Retiring the foreign copy is L06 ([task 1002412](https://example.com/builders#/task/1002412)).](<redacted>.md) | platform serving / instance infra |
+| 0152 | [**Metic gains task abandonment, paired with an un-abandon at the same rank** (owner directive 2026-07-27: "Metics should also be able to abandon tasks"; [task 1002476](https://cloudbongos.com/builders#/task/1002476)). [ADR 0090](<redacted>.md) moved task authoring (create/edit/promote/deps/criteria) down to the trusted working rank but kept `POST /tasks/:id/abandon` Archon-only as "terminal scope removal" — so the rank that runs idea-triage, seeds the tasks, and shapes them still had to hand every duplicate/moot/superseded chore back to the owner to retire. That hand-back is janitorial, not adjudication. The real hazard was never the grant: abandon was **one-way through the API** (`/promote` took only backlog/blocked, `PATCH` refuses `status`), so a mis-retire needed hand-SQL on prod, and an abandoned task is invisible in every claimable list and every version rollup (migration 017 excludes it from `version_progress`) — nobody notices until the work silently doesn't happen. So the gate moves to `requireRank('metic','archon')` **and** `/promote` gains a third source state, `abandoned → backlog` (never straight to ready — a retired task re-enters un-workable and takes a second deliberate promote), backed by `db.restoreTask`, the mirror of `abandonTask`, which clears the `'Abandoned: <reason>'` stamp and only that. Unchanged: the shipped-task and active-claim refusals, idempotency, and the `audit_log` record of who retired what and who brought it back. The `EXPECTED_RANKS` lifecycle pin moves in lockstep (a *further* downgrade stays a hard CI fail); under [ADR 0151](<redacted>.md) the `task.abandon` floor moves archon→metic, landing as `governance_003` because the compat seed is run-once — purely additive, and the drift guard now compares the **union** of grant migrations to the catalog and fails loudly on a future revocation.](<redacted>.md) | GDS / permissions |
+| 0153 | [**Sequential chain execution — one kickoff walks a dependency chain** ([task 1002484](https://cloudbongos.com/builders#/task/1002484)). [ADR 0015](<redacted>.md) made `dependencies[]` load-bearing and auto-promotes a task's dependents `backlog`→`ready` on ship — but nothing *picks the unblocked task up*, so on the live instance **146 of 303 open tasks sit behind a predecessor** and a 24-task planning seed needed 24 separate human kickoffs. The only "sequential" affordance was a clipboard prompt on the Tasks board (`<redacted>`), which is text rather than execution and cannot even select the gated successors, because they are still `backlog`. Requested independently by two builders (ideas 1000461, 1000398). **Decision:** a chain runner with **no schema change** (the polymorphic `dependencies` table + `task_is_fully_unblocked` + the promote-on-ship trigger already encode the order; a `chain_id`/queue column would be a second, drift-prone source of truth) and **no new claim guard** (one-active-claim-per-session is keyed on the *working tree*, so ship-before-next-claim is already the enforced shape — and batch-claiming a chain is impossible anyway, since successors fail `DEPS_NOT_SHIPPED` until their predecessor ships; the ship IS what unblocks the next step). Deterministic plumbing (`scripts/gds/sequence.js` — scope, topological order, halt matrix, all read off the task row) is split from judgement (`.claude/skills/builder-sequence/`, which defers to `/builder-claim` + `/dev` + `/builder-ship`). **Halt, do not skip** (owner decision): on `needs_migration`, `security_sensitive`, `protected_path`, `rank_floor`, `thin_spec`, `judgement_kind`, `not_claimable`, `deps_unmet`, `in_flight`, or `cycle`, the runner stops and reports with the task still claimed — because in a dependency graph a skipped task is a *predecessor*, so skipping strands everything behind it while the run keeps posting apparent progress. Not built: chains as a priced claimable unit on the board (idea 1000398), which is additive.](<redacted>.md) | GDS / methodology |
 
 > ⚠️ **Numbering collision (known):** two ADRs share `0008`. The numbers were assigned in parallel sessions before the lock could be enforced. The files are kept under their existing filenames to preserve git history, but the table disambiguates them as `0008-a` / `0008-b`. New ADRs should resume at `0040` to avoid further collisions. (`0024` is also a real on-disk duplicate: the cloneable-repo/local-first-memory ADR and the multi-agent-system-architecture ADR were both numbered `0024` in parallel; both keep their filenames, disambiguated as `0024-a` / `0024-b` like `0008`. Likewise `0025` ended up with two on-disk files — the offsite-backup ADR and the structured-criterion↔task-link ADR — both kept under their existing filenames and disambiguated as `0025-a` / `0025-b`; separately, the BFG ADR had also claimed `0025` on 2026-05-30 and yielded to `0026`. A third happened 2026-06-06: `0036` was claimed in parallel by the builders-subdomain ADR ([#726](https://example.com/builders#/task/726)) and this Discord-channels ADR ([#727](https://example.com/builders#/task/727)); the Discord-channels ADR yielded to `0037`. A fourth landed 2026-06-10: `0044` was claimed in parallel by the palette-replacement ADR and the per-box game-preview ADR ([#897](https://example.com/builders#/task/897)); both keep their filenames, disambiguated as `0044-a` / `0044-b` like `0008`. A fifth was caught pre-land 2026-06-13: `0050` was claimed in parallel by the device-flow-admission ADR ([#1000](https://example.com/builders#/task/1000)) and the sandbox-for-everyone ADR ([#1001](https://example.com/builders#/task/1001)); the latter yielded to `0052` before merging, so there is no `0050` duplicate. A sixth was caught pre-land 2026-06-21: the tool-agnostic-design-layer ADR ([#1375](https://example.com/builders#/task/1375)) first collided at `0079` with the value-gated-autonomous-engagement ADR, then at `0080` with the llm-cache-api-transport ADR (both part of the 0075–0080 LLM-cost-reduction series, landed on `main` in parallel); it yielded to `0081` before merging, so there is no `0079`/`0080` design-layer duplicate. A seventh landed 2026-06-23: `0084` was claimed in parallel by the auto-derived-per-task-rank-floor ADR and the remove-default-spend-cap ADR (task 1499); the rank-floor ADR landed on `main` first, so the spend-cap ADR yielded to `0085`, leaving no `0084` duplicate. An eighth landed 2026-06-27: `0095` was claimed in parallel by the borrowed-memory-and-retrieval-concepts ADR (PR #459, landed first) and the cross-agent-context-management ADR ([#1651](https://example.com/builders#/task/1651), PR #460); both keep their filenames, disambiguated as `0095-a` / `0095-b` like `0008`. These two are companions — `0095-a` adopts the memory/retrieval concepts and explicitly defers the grep-vs-semantic question to `0095-b`.)