@bongos/core 1.19.861 → 1.19.862

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.861",
-  "core_contract": "1.19.861",
-  "source_commit": "4e1d31227bc0a2db3534bfbaa9fedd102870074e",
+  "core_version": "1.19.862",
+  "core_contract": "1.19.862",
+  "source_commit": "ce0983547b33999b6262c9c586d0b7f9fe970689",
   "source_ref": "HEAD",
-  "built_at": "2026-09-17T22:42:20.133Z",
+  "built_at": "2026-09-18T00:41:20.268Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 498,
+    "docs_redacted": 500,
     "agent_docs_stubbed": 26,
     "functional_verbatim": 2280,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2804,
-  "tree_sha256": "49fc880b51d9733acfbdbedf53c6d696191648b163cb0e702bc44b1722384f41",
+  "file_count": 2806,
+  "tree_sha256": "3c3f933893a61cda70824e5d11211bd2d7483c501eb5a5a2e17bfea72de33382",
   "files": [
     {
       "path": ".claude/skills/ask-for-help/SKILL.md",
@@ -1812,7 +1812,7 @@
     {
       "path": "docs/adr/0264-the-ten-working-areas.md",
       "mode": "0000644",
-      "sha256": "d6b48c120cd4427de5c5ba7fa332f4f15c55f8b593acd7c43771be73e98788a3"
+      "sha256": "a958e59b3cbcc35a0aa2a89151f8af00cc4fd32f5f65335ef102310fe84cfac6"
     },
     {
       "path": "docs/adr/0265-work-with-no-goal-and-the-order-the-cut-needs.md",
@@ -2024,10 +2024,20 @@
       "mode": "0000644",
       "sha256": "00d74b19e9574186fbe354e410f6acd9e84db60f11a550905e95ac9071b89aa6"
     },
+    {
+      "path": "docs/adr/0307-autobongos-a-deterministic-supervisor-and-agentic-workers.md",
+      "mode": "0000644",
+      "sha256": "12159ae1337eec3d86f847104d9fa75eea7683cedd0fd5d8c0e3f8c4cdf63da5"
+    },
+    {
+      "path": "docs/adr/0308-an-eleventh-working-area.md",
+      "mode": "0000644",
+      "sha256": "feab2773d4b8954874ed42bf922bc74d1b9c37e7d5ffef13c5c3cf58fd36507a"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "d65a10ca2341a236fb6397a84907ed3cc250f0ea72ea5ec4c3e9bfca6a9d6cb2"
+      "sha256": "f19111877404016a28176ac0375e28713dad9d8895b5d637622497b3f461546c"
     },
     {
       "path": "docs/api-reference.md",
@@ -2592,7 +2602,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "5ad4d4175cf1bdfd1fc4d58946722c87309a07ff9d6146658ae7bbe32a93af51"
+      "sha256": "191ec7b680ce527f312660fc8cc1505803adb992febf7deac050d43abdc987dd"
     },
     {
       "path": "docs/modules-contract.md",
@@ -2867,7 +2877,7 @@
     {
       "path": "docs/research/cursor-competitive-analysis.md",
       "mode": "0000644",
-      "sha256": "bc2e01b959b5cf36f848dd57a1635d1a9e0a4ae3439610e936bc709ebfc01f96"
+      "sha256": "9dc5f219a1b1f114705eb31ac18926cfe98126197bbb5974e34ab931ce45819d"
     },
     {
       "path": "docs/research/llm-model-agnostic-and-cheaper-grader.md",
@@ -3669,11 +3679,6 @@
       "mode": "0000644",
       "sha256": "7cc5e9681fd62486d445a80f8ac4f0a8cc7fbe4a8ffacba7d7ffcfd262e8440c"
     },
-    {
-      "path": "migrations/core_242_core_version_snapshot.sql",
-      "mode": "0000644",
-      "sha256": "e52821124b99bd844c8323f2de0221db3fafd92c0c6e2227838cadf7d987676a"
-    },
     {
       "path": "migrations/core_243_cli_sessions_never_expire.sql",
       "mode": "0000644",
@@ -5677,7 +5682,7 @@
     {
       "path": "modules/lifecycle/db-ship.js",
       "mode": "0000644",
-      "sha256": "02b7d3ca2ec138b1ffd8509e48702a68f79faab3a16dfdc3f223ce807fdf9e90"
+      "sha256": "fc65aa01818dcd8c74d013e074ff9b6c71c34537230fc844e6a23b69cc93e22f"
     },
     {
       "path": "modules/lifecycle/db-tasks.js",
@@ -6422,7 +6427,7 @@
     {
       "path": "modules/provisioning/core-upgrade.js",
       "mode": "0000644",
-      "sha256": "dbe57cec7dd94613e9f2d23f396838ba77411c8fe3f9dca858cfd2af956ae43f"
+      "sha256": "b66e81df0685777b9c6f92260d372fab3b37a81d39dbbf5d9183537634ec3e2b"
     },
     {
       "path": "modules/provisioning/credential-preflight.js",
@@ -6524,6 +6529,11 @@
       "mode": "0000644",
       "sha256": "0fec45fe6188b76d625127ed60dabeda90dc02389709b3d2274c4477b33bb33d"
     },
+    {
+      "path": "modules/provisioning/migrations/provisioning_019_core_version_snapshot.sql",
+      "mode": "0000644",
+      "sha256": "9d530c724f49392e5eed301b498631be5bfa096eca344cd7b26b88b5fc9210d3"
+    },
     {
       "path": "modules/provisioning/module.json",
       "mode": "0000644",
@@ -7917,12 +7927,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "a3caf19c193288a64f26ef67883b6924563861d286aaa8dc102826081692f66c"
+      "sha256": "669729fd3145c8a17880f92490b18fa7e76d6416c780e1420808be4f8c583bab"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "321bdc4e8a5d0a857eb37f0bcb3410dc16bc50f32f3f9b9fec7e28e90991c10b"
+      "sha256": "0a41309fd1fc04ef03267da5ba55d9580489ab6f598b34ef4a14d9dd79906404"
     },
     {
       "path": "public-docs/index.html",
@@ -8827,7 +8837,7 @@
     {
       "path": "scripts/gds/provision-core-upgrade.js",
       "mode": "0000644",
-      "sha256": "48f41b0d45f26f188585245ef918bd626f2242fdb641f3a11a0a27a83b34d3ca"
+      "sha256": "fef10e02d3b1d605c1b30fd553b1cf8069159d8c2cbf6b0e4b48ec32359562a9"
     },
     {
       "path": "scripts/gds/provision-disconnect.js",
@@ -9867,7 +9877,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "e9b79cddc8f92f9cd1f7b1aa22ffd661af52a68f08f469f43879d1f9cf6df545"
+      "sha256": "b16a023fc2c2dcf233402a8e3b72214d9c8217f5df7d6f5b0925f064a6c172e5"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -10572,7 +10582,7 @@
     {
       "path": "tests/claim_resolve_worktree_lock.mjs",
       "mode": "0000644",
-      "sha256": "6e5ff3acb835fd6219136ee2a5e144841076a82733915cc7111688f707464442"
+      "sha256": "063794948bb45c600781bdce3f31d590991c4628824fd57c15f916f9e0b49fc2"
     },
     {
       "path": "tests/claimable_blocker_status.mjs",
@@ -10727,7 +10737,7 @@
     {
       "path": "tests/core_upgrade_runner.mjs",
       "mode": "0000644",
-      "sha256": "c6d600c92654d54897d457162bf6aad3a8ba46d7d1fe4e94673900025a867fa6"
+      "sha256": "5f9ae4144ab85ee197f417003a71df1d78398ca11b6c8bd3dc96de9b4cd5e1fb"
     },
     {
       "path": "tests/cosmos_token_contrast.mjs",

package/docs/adr/0264-the-ten-working-areas.md

@@ -6,6 +6,7 @@
 - **Goal:** [#1000086](https://cloudbongos.com/builders#/goal/1000086) — Strict versioning, criterion `sv-cutover-proven-live`.
 - **Decided by:** the owner and the full team, in a manual goal review on 2026-09-07.
 - **Builds on:** [ADR 0250](0250-strict-versioning-the-version-boundary-is-the-scope-gate.md) (the version boundary is the scope gate — this is the scope that boundary will hold), [ADR 0086](0086-goal-scoped-work-hierarchy.md) (the goal tier).
+- **Amended by:** [ADR 0308](0308-an-eleventh-working-area.md) — an **eleventh** area (Autobongos, [goal 1000119](https://cloudbongos.com/builders#/goal/1000119)) was admitted on 2026-09-17. The table in §1 is ten of eleven; read 0308 beside it.
 
 ## 1. The decision
 
@@ -26,6 +27,7 @@ these ten.
 | 8 | **Platform credit economy** | Scott | Real money reaches users for completed work, without fail. Users hold platform balances, fund projects and pay each other with no fees. Bongos banks project funds and delivers them on cash-out. |
 | 9 | **Platform analytics** | Lars | Bongos gathers as much user data as it can to improve itself — session transcripts as an efficiency signal, plus every user action and work delivery across the ecosystem through the Bongos API. |
 | 10 | **Security** | all except Nils and Scott | Ranks are enforced. The Bongos server is not hackable by Claude's latest model. Red-teaming is consistent. |
+| 11 | **Autobongos** | Lars | *Added 2026-09-17 by [ADR 0308](0308-an-eleventh-working-area.md).* A project owner points idle compute at goals they have allowlisted, and it builds unattended inside their subscription limits — stopping rather than guessing whenever a human is needed, and reporting what it did without being asked. |
 
 ## 2. Why ten, and why now
 

package/docs/adr/0307-autobongos-a-deterministic-supervisor-and-agentic-workers.md

@@ -0,0 +1,178 @@
+# ADR 0307 — Autobongos: a deterministic supervisor, agentic workers
+
+**Status:** accepted · **Date:** 2026-09-17 · **Task:** [task 1003900](https://cloudbongos.com/builders#/task/1003900) (goal 1000119 — BONGOS-V2)
+
+**Related:** [ADR 0153](0153-sequential-chain-runner.md) (the halt matrix and the halt-don't-skip rule this reuses wholesale) · [ADR 0024](0024-multi-agent-system-architecture.md) (the MAS the autonomy gate belongs to) · [ADR 0055](0055-server-mediated-branch-publish.md) (server-mediated publish — why the machine holds no push credential) · [ADR 0043](0043-git-ssh-trust-boundary-and-rank-floor-on-permission-paths.md) (the protected-path set the fence reuses) · [ADR 0308](0308-an-eleventh-working-area.md) (the working area this work lives in)
+
+## Context
+
+The owner has an always-on Windows PC and a Claude subscription whose capacity
+is mostly unused overnight. The ask was an orchestration loop that works the task
+queue unattended inside goals the owner has allowlisted.
+
+Most of that loop already exists, wired to the wrong trigger:
+
+- **`scripts/gds/sequence.js`** resolves a chain and evaluates a ten-reason halt
+  matrix — entirely from facts on the task row, no model judgement (ADR 0153).
+- **An open blocker linked to a task makes `claimTask` throw `OPEN_BLOCKER`**
+  (`modules/lifecycle/db-claims.js`). That is already a "put this work on hold"
+  state, and `/blocker-review` is already the owner's morning queue.
+- **`modules/grading/grader-subagent.js`** is a proven headless `claude` spawn
+  seam, already Windows-aware (it routes through `cmd.exe` and hides the console).
+- **`.claude/scheduled-tasks/overnight-builder/`** runs this loop today.
+
+Two things are genuinely missing. The trigger is a cron schedule rather than the
+subscription's own capacity, so a run either wastes a fresh window or dies
+half-way through a spent one. And the **supervisor is itself a Claude session**,
+which spends a full context boot per night on work that is entirely mechanical.
+
+## The decision
+
+### 1. The supervisor is a program; only the worker is a session
+
+Picking, claiming, metering, verifying and recording are deterministic and stay
+in code. One task at a time is handed to one headless session. This is the whole
+architectural difference from `overnight-builder`, and it is what makes the loop
+auditable: every branch the supervisor takes is a branch someone can read.
+
+### 2. The gauge is the statusline's `rate_limits`, and it cannot be read cold
+
+Claude Code feeds a statusLine hook `rate_limits.five_hour.{used_percentage,
+resets_at}` and `rate_limits.seven_day.{…}` — the only structured read of
+remaining subscription capacity. Anthropic's own note on the field says it is
+*"only present for subscribers after first API response"*, so there is no way to
+ask "how much is left" before starting. The mechanism is therefore a statusline
+script that **persists both windows on every session**, and a reader the
+supervisor consults between tasks. A gauge file older than its freshness window
+is *unknown*, never *headroom*.
+
+The reserve is time-aware, because the runner and the owner draw on the **same**
+five-hour window: near zero overnight, a real floor during the owner's working
+hours. The seven-day window is the binding one across a heavy week, and is paced
+against rather than spent greedily.
+
+### 3. One session per task, not a batch
+
+The original sketch pulled "a string of sequential tasks estimated to fit the
+remaining limits". Rejected, for three reasons. The estimate does not exist —
+tasks carry human-minutes, not token spend. A successor cannot be claimed until
+its predecessor ships (ADR 0153 §2), so "walk a string" and "take the next one"
+produce the identical order anyway. And because each ship merges to main, a
+**fresh session per task is also more correct** than a long one holding a
+checkout that goes stale behind main.
+
+So v1 **meters rather than estimates**: work one task, re-read the gauge, decide
+again. The estimate becomes a learned number once the ledger has data.
+
+### 4. Completion is read from the ledger, never from the session
+
+A session exiting is not a task shipping, and the result envelope makes the
+confusion easy: a worker that stopped dead needing a decision returns
+`subtype: "success"`, structurally identical to one that finished. This project's
+worst incidents are all this shape — branches never pushed, tasks parked at
+`confirmed` with no code, a ship that timed out *after* its merge landed.
+
+After every worker the supervisor reads the task's status back from Bongos and
+confirms the artifact. Anything not actually shipped releases the claim and files
+a blocker, which also removes the task from the claimable pool so the loop does
+not pick it straight back up.
+
+### 5. There is no terminal stop — only speeds
+
+On an always-on machine a stopped daemon is silently worthless. Three straight
+failures drop the runner to a **probing** state: no new work, a growing wait,
+then exactly one task; a success returns it to full speed. Failures are
+classified, because the right response differs — transient (instance
+unreachable, grader outage, rejected push) heals by waiting; systemic (expired
+token, full disk) will not, but cheap probing means it resumes the moment someone
+fixes the cause; and a queue where *every* task halts is not a runner failure at
+all, and is reported as an unworkable queue. A new signal — main moved, a blocker
+resolved, the allowlist changed — jumps the remaining wait.
+
+The only true stop is the **server-side** kill switch.
+
+### 6. The fence, and where it is enforced
+
+The allowlist of goals lives in the database and is edited from the hall, never
+in a file on the machine — a file there is editable by anything running there,
+and the premise is a machine nobody is watching. It combines with the existing
+protected-path exclusion (ADR 0043), so permission, migration, infrastructure and
+deploy-pipeline work never reaches an unattended worker.
+
+The machine holds **no push credential at all** (the dev boxes were built this
+way deliberately — ADR 0055), so the only road to main is the server-mediated
+ship pipeline and its server-side grade. That grade is the *only* review between
+an unattended worker and main, so **a grader outage stops the runner** rather
+than downgrading it to shipping unreviewed.
+
+### 7. Workers run with blanket `bypassPermissions`
+
+`--permission-prompt-tool` exists and is print-mode only, so routing every
+permission request back to the supervisor was available and was **rejected**: it
+round-trips every tool call through one process, so a slow or crashed supervisor
+stalls every worker, and it buys a thousand weak gates in place of the one that
+matters. The boundary that matters is the push to main, and §6 already holds it.
+
+### 8. Gate before, record after — and no conversation in between
+
+This is the posture the owner chose, and it is the one part that was **tested
+before it was decided**.
+
+A worker was given an ambiguous task and told, in plain terms, to stop and ask
+rather than guess. It did not. It settled the retry count, the backoff base,
+which status codes to retry and whether to retry network errors — four genuine
+judgement calls — and wrote them into the file. That is not misbehaviour; it is
+what a competent engineer does without interrupting anyone. But it means **a
+design that waits for workers to raise their hands will see very few hands, while
+the decisions still get made.**
+
+So:
+
+- **Before** — the halt matrix refuses ambiguous work at *pick* time, mechanically
+  (thin spec, protected path, `kind='decision'`, needs a migration). Those tasks
+  never reach a worker.
+- **After** — the worker's structured verdict must include the calls it made that
+  its task description did not determine. They land in the morning digest, where
+  the owner reviews them sitting on a branch behind a grader.
+- **In between** — nothing. Mid-flight injection is the exception path for hard
+  blocks, not the main road.
+
+Handing a decision back to a live worker *does* work and was verified — pinning
+the session id at spawn and resuming it later returns the session with its
+context intact, and cheaply, because the context comes back from cache. That
+capability is kept for hard blocks and deliberately not built into a
+question-answering apparatus.
+
+## What this deliberately does not build
+
+- **Mid-flight question answering** — no question tiering, no citation-enforced
+  answering agent, no resume caps. Removed on the owner's instruction as
+  unneeded complexity, and §8 is why it is not load-bearing.
+- **Portability.** v1 targets one machine and one instance. Designing for hosts
+  we do not have, against numbers nobody has measured, would fix the metering
+  design before there is data to fix it with.
+- **Per-task cost estimation.** See §3 — metering first, estimates later.
+
+## Alternatives rejected
+
+- **A budget-capped worker** (`--max-budget-usd`). Caps API dollars, which on a
+  subscription is not the constraint. The real runaway risk is a session spending
+  the whole window on one task, so the bound is **wall-clock**.
+- **Extending `overnight-builder`.** It walks the whole backlog by priority on a
+  cron, supervised by a model. This is limit-triggered, allowlist-scoped and
+  supervised by a program. Different trigger, different scope, different cost.
+- **A terminal stop after N failures.** The first draft of this loop had one; on
+  an always-on host it is indistinguishable from the machine being off. §5.
+
+## Consequences
+
+- The supervisor is testable the way a program is testable. Its decisions are not
+  a transcript.
+- The runner competes with the owner for the same five-hour window, so the
+  reserve is a product decision, not a politeness.
+- Every declared decision in the digest is a sentence the task description should
+  have contained. The list is a spec-quality signal, and acting on it lowers
+  future halts.
+- The Windows host has **no precedent in this repo** — all prior autonomy ran on
+  Linux droplets, and that infrastructure is being torn down under goal 1000091.
+  It is the bucket most likely to overrun.

package/docs/adr/0308-an-eleventh-working-area.md

@@ -0,0 +1,89 @@
+# ADR 0308 — An eleventh working area: Autobongos
+
+**Status:** accepted · **Date:** 2026-09-17 · **Task:** [task 1003900](https://cloudbongos.com/builders#/task/1003900) (goal 1000119 — BONGOS-V2)
+
+**Amends:** [ADR 0264](0264-the-ten-working-areas.md) (the ten working areas, held until 5,000 builders)
+
+**Related:** [ADR 0307](0307-autobongos-a-deterministic-supervisor-and-agentic-workers.md) (what the area actually builds) · [ADR 0250](0250-strict-versioning-the-version-boundary-is-the-scope-gate.md) (the version boundary that had to be reopened to admit it) · [ADR 0086](0086-goal-scoped-work-hierarchy.md) (the goal tier)
+
+## Context
+
+[ADR 0264](0264-the-ten-working-areas.md) collapsed thirty-eight open goals into
+**ten working areas, one goal each, held until the platform has 5,000 builders**.
+Ten was chosen so that every area has a single owner who can hold its whole shape
+in their head, and the horizon is a scale question rather than a calendar one.
+
+That ADR is nine days old. Adding to it needs a better argument than "here is
+something else we want to build", because a scope that grows by exception is the
+failure ADR 0264 exists to stop.
+
+## The decision
+
+**Autobongos becomes working area 11** — [goal 1000119](https://cloudbongos.com/builders#/goal/1000119) on BONGOS-V2.
+
+> **11 · Autobongos** — *owner: Lars.* At 5,000 builders: a project owner points
+> idle compute at goals they have allowlisted, and it builds unattended inside
+> their subscription limits — stopping rather than guessing whenever a human is
+> needed, and reporting what it did without being asked.
+
+## Why this is an axis and not a feature of an existing area
+
+The obvious home was **area 6** (Governor / Builder / Artist / Ideator
+experience), whose 5,000-builder state already says *"Agents are designed to aid
+all these roles."* It was considered and rejected, for one reason:
+
+**Area 6 is about a human's experience of the platform. This area has no human in
+it.** Its whole subject is what the system does across the hours when nobody is
+watching — which limits it may spend, which fences hold without supervision, how
+it recovers from failure with nobody at the keyboard, and what it owes the owner
+the next morning. Those questions do not get better answers by being asked
+alongside "how do we keep the Artist's surface from breaking into the Ideator's".
+They get less attention, because they compete with work that has a user in front
+of it.
+
+Area 4 (core distribution) was the other candidate and is a worse fit still — it
+would file autonomous building as a shipping-cadence tool, under a goal about how
+core updates reach instances.
+
+## It reopens a closed goal rather than inventing a new one
+
+[Goal 1000028 — *Autonomy groundwork*](https://cloudbongos.com/builders#/goal/1000028)
+(*"safe unattended routines — guardrails first, then arm the safe set"*, criteria
+`gcarry-auto-guardrails` and `gcarry-auto-armed`) was archived in the 38→10 cut
+**with no successor**. Goal 1000119 carries `succeeds_goal_id: 1000028`, so the
+lineage is in the ledger rather than in this prose: the eleventh area is a
+reopening, not a new axis nobody had thought of.
+
+That is also the honest reading of what happened. ADR 0264 §3 left three goals
+*"not covered by the review"*, one of them explicitly marked **"needs an owner
+decision: fold, keep as an eleventh, or close."** The eleventh slot was a live
+question in the ADR itself, not a door this one forces.
+
+## What it cost to admit, and why that is recorded
+
+BONGOS-V2 is `building`, so its goal set is **closed** ([ADR 0250](0250-strict-versioning-the-version-boundary-is-the-scope-gate.md)):
+`POST /goals` refuses with `version_not_planning`. An Archon may reopen it, but
+only by writing an `admit_reason`, which is stored against the goal with who
+admitted it and when.
+
+Goal 1000119 therefore carries a permanent admission record. This is the gate
+working, and it is the answer to "does an eleventh area mean the cut did not
+hold": the cut held well enough that adding to it left evidence.
+
+## What this does not decide
+
+- **The ten-area discipline stands.** This is one exception with a written
+  reason, not a return to a board that grows on request. The 5,000-builder
+  horizon is unchanged, and areas 1–10 are untouched.
+- **It does not settle ADR 0264 §3's other two open rows** — goal 1000065
+  (community surface) and goal 1000088 (repo cleanup) are still open questions.
+- **It does not give the area a second goal.** One goal per area is the rule that
+  makes ten legible, and eleven is only legible under the same rule.
+
+## Consequences
+
+- The board is twelve rows: eleven areas plus maintenance.
+- ADR 0264's §1 table is now incomplete on its own, so it links forward to this
+  record. A reader who finds 0264 first is not left with a stale ten.
+- The next area proposed has a precedent to argue against, which is the point of
+  writing the reasoning down rather than just the outcome.

package/docs/adr/README.md

@@ -398,3 +398,5 @@ This keeps the decision history honest and traceable.
 | 0304 | [**Routine reads run without a prompt; anything a flag can turn into a write is exact-form** ([task 1003992](https://cloudbongos.com/builders#/task/1003992), goal 1000095). The shipped `.claude/settings.json` pre-allowed six commands, so every `gh pr view` or `git fetch` asked a non-technical builder to approve a command they cannot evaluate. The read-only subset is now pre-allowed — `git status`, `gh pr view/checks/list`, `gh run view/list` and the gds CLIs audited read-only under every flag as prefix rules; `git branch` and `git fetch` as exact forms only, because a flag turns either into a write or an exec — and the instance starter mirrors it rule for rule. `git diff/log/show` get NO rule: the harness already runs their read-only forms unprompted with a flag check, and a prefix rule switched that check off (`--output=<path>` writes anywhere, `diff --no-index` reads deny-listed files — both reproduced in review). A test pins the whole allow-list, that no rule covers a command git-guard blocks, and that no rule covers a write dressed as a read. Rejected: `Bash(git:*)`, prefix-plus-`ask` for diff/log/show (argument patterns are evaded by quoting), prefix rules for fetch/branch, `bypassPermissions` everywhere.](0304-routine-reads-run-without-a-prompt-and-anything-a-flag-can-turn-into-a-write-is-exact-form.md) | GDS / sessions / permissions |
 | 0305 | [**A recipe lives with what it documents** ([task 1002156](https://cloudbongos.com/builders#/task/1002156), goal 1000091, from idea 536 / idea 537). Part A of the 2026-07-10 architecture review, held until the owner confirmed direction. The binary core-vs-instance split in `isPublishable()` has collapsed to one side: all **36** files in `docs/recipes/` and all **4** in `docs/research/` publish, and the denylist rows that once held the instance-local half name files that no longer exist. Worse, it is producing wrong docs — four published recipes document the dev-box that goal 1000091 is deleting, and none of the nine removal tasks covers them ([task 1004013](https://cloudbongos.com/builders#/task/1004013)). The cause is not neglect: **nothing structurally ties a recipe to what it documents**. So the rule is ownership, not portability — a recipe lives in the same deletable unit as its subject. Three classes: core methodology stays in `docs/recipes/`; feature-coupled moves to `modules/<key>/recipes/` and dies with its module; instance-operational stays behind the publish gate. `scripts/` is unchanged (it is the CLI, not documentation with a portability question); `docs/research/` becomes instance-local (situated artifacts, and the likeliest brand-name leak). **The thesis is rejected in its literal form**: a shared recipe is not a NEW asset class parallel to modules but a directory *inside* one, reusing the manifest attribution, submit→review→accept, security accept-gate, default-off enablement and orphaning policy that ADR 0107/0135 already ship — `modules/ui-design/docs/design-contract.md` is the undesigned precedent. Rejected: a parallel registry (a second manifest, queue, attribution model and orphaning policy, to distribute Markdown; Supermarket/Galaxy distribute executables with dependency resolution, which is what a module already is); classify-and-keep-the-binary-split (treats the symptom, restores the local half only until the next module ships a recipe); per-recipe portability front-matter (no build step reads it, no deletion touches it); deleting `docs/research/` (live inputs to open goals). Decides direction only — no file moves; the sweep and a fitness check for a recipe outliving its module are follow-on.](0305-a-recipe-lives-with-what-it-documents.md) | modules / upstreaming |
 | 0306 | [**Instance supervision is a seam, with systemd as the default** ([task 1003997](https://cloudbongos.com/builders#/task/1003997), goal 1000106, F13 from the task-1002718 QA walk). `provision-units.js` hardcoded `/etc/systemd/system` in three path functions and the runner reached for `systemctl` inline at fifteen call sites, so a standup was impossible on any plane without systemd — the self-host image runs `USER node`, installs no `sudo` and boots no systemd. **A directory knob does not fix this**: pointing the unit path somewhere writable still emits `daemon-reload` into a namespace where systemd is not PID 1. What varies is not where the unit file goes, it is what supervises the process. Chosen: four operations (install+enable, install backup schedule, restart, remove) move behind `scripts/gds/provision-process.js`, taking the `{ exec, writeFile, sudoP, log }` io the runbook already threads, so dry-run, remote-ssh and logging behaviour carry over untouched (ADR 0130). Selection is explicit (`PROVISION_PROCESS_MANAGER`, an unknown value throws) → probed (`/run/systemd/system`, the `sd_booted(3)` check) → supervisord. **The live box is unchanged by construction** — it boots systemd, and the systemd implementation emits byte-identical commands; the untouched composition assertions in `tests/provision.mjs` are the proof. Rejected: systemd `--user` units (fix an unprivileged VM we do not have, while a plain container has no user bus either). Consequences: isolation is restated per manager (systemd `User=` → supervisord `user=`, ADR 0281) or it silently drops; supervisord has no timers, so it installs no backup schedule and prints the `crontab` line instead of re-implementing cron; the seam is two implementations wide, not speculatively N. **This removes one of four container blockers** — ingress ([task 1004017](https://cloudbongos.com/builders#/task/1004017)), per-instance identity ([task 1004018](https://cloudbongos.com/builders#/task/1004018)) and the hardcoded backup-dir owner ([task 1002719](https://cloudbongos.com/builders#/task/1002719)) remain, so task 1003997's done-when was narrowed to the seam rather than claiming a self-host story that is not there.](0306-instance-supervision-is-a-seam-with-systemd-as-the-default.md) | infra / provisioning |
+| 0307 | [**Autobongos: a deterministic supervisor, agentic workers** ([task 1003900](https://cloudbongos.com/builders#/task/1003900), goal 1000119). An always-on machine works the queue unattended inside owner-allowlisted goals. Most of the loop already existed wired to the wrong trigger — `sequence.js`'s ten-reason halt matrix (ADR 0153), an open blocker as the hold state, the Windows-aware headless spawn seam, `overnight-builder` — but the trigger was cron rather than capacity, and the **supervisor was itself a Claude session**. Decided: the supervisor is a **program**, only the worker is a session; the gauge is the statusLine's `rate_limits.five_hour`/`seven_day`, which per Anthropic's own note is absent until a session's first API response and so **cannot be read cold** (a statusline script persists it, a stale file is *unknown*, never *headroom*); **one session per task, metering not estimating** (a successor cannot be claimed until its predecessor ships, so a batch produces the same order while risking a half-done window, and a fresh session avoids a checkout going stale behind main); **completion is read from the ledger, never the session** (a worker that stopped needing a decision returns `subtype: success`, identical to one that finished); **no terminal stop, only speeds** (three failures → a probing state that self-heals; the only true stop is the server-side kill switch); the machine holds **no push credential**, so a grader outage stops the run rather than shipping unreviewed. The load-bearing finding was **tested before it was decided**: a worker told plainly to stop and ask instead settled four judgement calls and wrote them to disk — competent, and fatal to any design that waits for raised hands. Hence **gate before, record after, nothing in between**: the halt matrix refuses ambiguous work at pick time, and the worker's verdict must declare what the spec did not determine. Rejected: per-call `--permission-prompt-tool` (a thousand weak gates, and one slow supervisor stalls every worker), `--max-budget-usd` (caps dollars; on a subscription the constraint is capacity, so the bound is wall-clock), extending `overnight-builder`, and a terminal stop. Deliberately not built: mid-flight question answering, portability, per-task estimation.](0307-autobongos-a-deterministic-supervisor-and-agentic-workers.md) | autonomy / sessions |
+| 0308 | [**An eleventh working area: Autobongos** ([task 1003900](https://cloudbongos.com/builders#/task/1003900), goal 1000119). Amends [ADR 0264](0264-the-ten-working-areas.md), which nine days earlier collapsed 38 goals into **ten** areas held until 5,000 builders. Area 11 is Autobongos ([goal 1000119](https://cloudbongos.com/builders#/goal/1000119), owner Lars). **Area 6 was the obvious home and was rejected**: area 6 is about a human's experience of the platform, and this area has no human in it — which limits to spend, which fences hold unsupervised, how it recovers with nobody at the keyboard. Those get less attention next to work with a user in front of it, not better answers. It **reopens** goal 1000028 (*Autonomy groundwork*), archived in the 38→10 cut with no successor and carried as `succeeds_goal_id`, so the lineage is in the ledger rather than the prose — and ADR 0264 §3 had already left "fold, keep as an eleventh, or close" as a live owner question. Admitting it cost something recorded: BONGOS-V2 is `building`, so its goal set is closed (ADR 0250) and `POST /goals` refuses `version_not_planning` — an Archon reopened it with a stored `admit_reason`, which is the cut holding well enough that adding to it left evidence. Does not decide: the ten-area discipline stands (one exception, written reason, 5,000-builder horizon unchanged), 0264 §3's other two open rows, or a second goal for the area.](0308-an-eleventh-working-area.md) | methodology / goals |

package/docs/module-api-changelog.md

@@ -2195,6 +2195,8 @@ is load-bearing: the script throws rather than guess if it is missing, and
   1.19.860 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.859 with no explicit bump. run 35281454119. (task 1002620)
   1.19.861 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
-        landed since 1.19.860 with no explicit bump. run 35283293619. (task 1002620)
+        landed since 1.19.860 with no explicit bump. run 35290990147. (task 1002620)
+  1.19.862 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.861 with no explicit bump. run 35292190396. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/docs/research/cursor-competitive-analysis.md

@@ -79,9 +79,9 @@ Full bibliography in [§10](#10-bibliography). Our positioning is from a direct
 This is the most important section for understanding why Cursor does what it does. The picture is now well-sourced (no longer contested):
 
 - **Inference is largely a pass-through.** When a user selects a specific frontier model, "usage is drawn from the API pool at that model's API rate" ([cursor.com/docs](https://cursor.com/docs/models-and-pricing), ✅ 2-1) — so the $20 Pro sub roughly *buys $20 of model usage*. Margin can't come from reselling tokens.
-- **Cursor ran negative gross margins.** Through 2025 it spent an estimated **$0.40–$0.70 of model-inference cost per $1 of revenue** (Anthropic + OpenAI API costs), making structural gross margin **~30–50% vs the 80%+ of normal software** — the "token tax" that "locks AI-agent gross margins ~30 points below the SaaS baseline" ([Contrary Research](https://research.contrary.com/company/cursor); [TechTimes](https://www.techtimes.com/articles/317542/20260601/<redacted>.htm); [Yahoo Finance — "high costs and thin margins threatening AI coding startups"](https://finance.yahoo.com/news/<redacted>.html)). Contrary quotes the criticism directly: Cursor charges "lower or equivalent pricing to Anysphere's own costs of accessing foundation models."
+- **Cursor ran negative gross margins.** Through 2025 it spent an estimated **$0.40–$0.70 of model-inference cost per $1 of revenue** (Anthropic + OpenAI API costs), making structural gross margin **~30–50% vs the 80%+ of normal software** — the "token tax" that "locks AI-agent gross margins ~30 points below the SaaS baseline" ([Contrary Research](https://research.contrary.com/company/cursor); TechTimes (2026-06-01, article 317542 — link lost); Yahoo Finance — "high costs and thin margins threatening AI coding startups" (link lost)). Contrary quotes the criticism directly: Cursor charges "lower or equivalent pricing to Anysphere's own costs of accessing foundation models."
 - **The owned model is the margin fix — and it's partly working.** Composer (Nov 2025) + cheaper models like Kimi moved Cursor to **slight gross-margin profitability — positive on large enterprise, but still losing money on individual developer accounts** ([market reporting via search, 2026](https://mktclarity.com/blogs/news/is-cursor-profitable)). Internal telemetry reportedly showed Composer handling **~half of autocomplete requests** while matching Claude Sonnet on common tasks. 📄
-- **Forward pressure:** Cursor reportedly forecasts ending **2026 at a >$6B annualized run-rate** ([letsdatascience](https://letsdatascience.com/blog/<redacted>)) — i.e., it expects to roughly triple again. 📄 (forecast; treat as a target, not a fact.)
+- **Forward pressure:** Cursor reportedly forecasts ending **2026 at a >$6B annualized run-rate** (letsdatascience — link lost) — i.e., it expects to roughly triple again. 📄 (forecast; treat as a target, not a fact.)
 
 ### Revenue & ARR trajectory ✅
 
@@ -189,7 +189,7 @@ For an AI-first **orchestration** platform, rank threats by *"does it manage aut
 
 | Competitor | What it is | Threat to an *orchestration* platform vs Cursor |
 |---|---|---|
-| **GitHub Copilot coding agent** | Issue→PR autonomous agent inside the dominant SCM ([docs](https://docs.github.com/copilot/concepts/agents/coding-agent/about-coding-agent), [noqta.tn](https://noqta.tn/en/blog/<redacted>)) | **MORE.** Autonomous, task-scoped, lands a PR through review gates — orchestration-shaped *and* riding GitHub's distribution + enterprise relationships. |
+| **GitHub Copilot coding agent** | Issue→PR autonomous agent inside the dominant SCM ([docs](https://docs.github.com/copilot/concepts/agents/coding-agent/about-coding-agent), noqta.tn — link lost) | **MORE.** Autonomous, task-scoped, lands a PR through review gates — orchestration-shaped *and* riding GitHub's distribution + enterprise relationships. |
 | **Anthropic Claude Code** | Terminal-native autonomous coding agent ([mindstudio](https://www.mindstudio.ai/blog/claude-code-vs-openai-codex-comparison)) | **MORE — and special.** Closest to "agents author the code," *and it is Cloud Bongos's own substrate.* The most-competitive system is the one you're built on. It also showed (Jan 2026) it will police who resells its access. |
 | **OpenAI Codex** | Cloud autonomous agent, parallel tasks | **MORE / EQUAL.** Same orchestration encroachment from the other frontier lab. |
 | **Devin / Cognition** | Autonomous "AI software engineer" + agent-management UI | **MORE.** The most direct *conceptual* competitor to "agents own tasks end-to-end," with its own session/management layer. |
@@ -217,6 +217,12 @@ For an AI-first **orchestration** platform, rank threats by *"does it manage aut
 
 ## 10. Bibliography
 
+> **On the "link lost" markers below.** A public-mirror scrubbing pass overwrote the URL
+> paths of several sources in this file's source text. Where the article could be
+> re-identified with confidence against the claim it supports, the link has been restored;
+> where it could not, the citation text is kept and the bare URL dropped rather than
+> replaced with a plausible-looking guess.
+
 **Verified (✅ — adversarially confirmed in-harness and/or confirmed against a named source in the 2026-06-22 main-loop round):**
 - Cursor — Models & Pricing (primary): https://cursor.com/docs/models-and-pricing
 - Cursor — Series D announcement (primary): https://cursor.com/blog/series-d
@@ -231,15 +237,15 @@ For an AI-first **orchestration** platform, rank threats by *"does it manage aut
 - TechCrunch — Cursor in talks to raise $2B at $50B as enterprise growth surges (2026-04-17): https://techcrunch.com/2026/04/17/<redacted>/
 
 **Sourced (📄 — reputable, single-pass; cite with care):**
-- TechTimes — AI-agent economics / token-tax 30 points below SaaS: https://www.techtimes.com/articles/317542/20260601/<redacted>.htm
-- Yahoo Finance — high costs and thin margins threatening AI coding startups: https://finance.yahoo.com/news/<redacted>.html
+- TechTimes — AI-agent economics / token-tax 30 points below SaaS (2026-06-01, article 317542) — link lost
+- Yahoo Finance — high costs and thin margins threatening AI coding startups — link lost
 - Market Clarity — is Cursor profitable (enterprise-positive / individual-negative margins): https://mktclarity.com/blogs/news/is-cursor-profitable
-- TheRouter — Cursor Bugbot, Composer 2.5, model block-list governance: https://therouter.ai/news/<redacted>/
-- ValueAdd VC — how a code editor became a $9B company: https://valueaddvc.com/blog/<redacted>
+- TheRouter — Cursor Bugbot, Composer 2.5, model block-list governance — link lost
+- ValueAdd VC — how a code editor became a $9B company — link lost
 - GetPanto — Cursor AI statistics 2026: https://www.getpanto.ai/blog/cursor-ai-statistics
 - Wikipedia — Anysphere / Cursor (company): https://en.wikipedia.org/wiki/Anysphere · https://en.wikipedia.org/wiki/Cursor_(company)
 - MindStudio — Claude Code vs OpenAI Codex: https://www.mindstudio.ai/blog/claude-code-vs-openai-codex-comparison
-- GitHub — About Copilot coding agent: https://docs.github.com/copilot/concepts/agents/coding-agent/about-coding-agent · noqta.tn (autonomous PR): https://noqta.tn/en/blog/<redacted>
+- GitHub — About Copilot coding agent: https://docs.github.com/copilot/concepts/agents/coding-agent/about-coding-agent · noqta.tn (autonomous PR) — link lost
 - Coder — Compare Cursor / "is the IDE dead": https://coder.com/solutions/agents/compare-cursor · https://coder.com/blog/is-the-ide-dead-the-rise-of-agentic-ai-in-software-development
 - MarkTechPost — AI coding agents & dev platforms 2026: https://www.marktechpost.com/2026/06/10/<redacted>/
 

package/modules/lifecycle/db-ship.js

@@ -53,6 +53,24 @@ const { mostRecentClaimHolderId, sealSessionLog, staleClaimHourPredicate } = req
 // creator_session_id (a web/unbound claim per #616, or one pre-dating the column),
 // and a resolver with no session context at all.
 //
+// claimTreeIdentity — WHICH of a claim row's two worktree names identifies the
+// working TREE (task 1004031). Pure + exported for the same reason the decision
+// below is: the bug was never in the comparison, it was in which field reached
+// it, so that choice has to be testable on its own.
+//
+//   requested_worktree_name — what the caller asked for. The tree's identity,
+//     and what `detectWorktreeName()` sends back at resolve time.
+//   worktree_name           — the DISAMBIGUATED name. V3.R51 appends `-2` when
+//     another ACTIVE claim holds the requested one, so it is unique across live
+//     claims but names no directory on disk.
+//
+// Comparing the disambiguated name refuses every ship from a tree whose name
+// ever collided. Falls back for rows written before requested_worktree_name
+// existed, where the stored name is the only one there is.
+function claimTreeIdentity(claim = {}) {
+  return claim.requested_worktree_name ?? claim.worktree_name ?? null;
+}
+
 // Pure + exported so the decision is unit-testable with no DB and no route —
 // the same shape as shouldRefuseSessionClaim. Returns { refuse, reason }.
 function shouldRefuseClaimResolve({
@@ -109,7 +127,7 @@ async function resolveClaim({ claimId, builderId, outcome, notesMd, valueSummary
   return withTx(async (client) => {
     const { rows: claimRows } = await client.query(
       `SELECT c.id, c.task_id, c.builder_id, c.released_at, c.claimed_at,
-              c.worktree_name, c.creator_session_id,
+              c.worktree_name, c.requested_worktree_name, c.creator_session_id,
               t.credits_reward, t.title
          FROM claims c JOIN tasks t ON t.id = c.task_id
         WHERE c.id = $1 FOR UPDATE`,
@@ -125,10 +143,26 @@ async function resolveClaim({ claimId, builderId, outcome, notesMd, valueSummary
     // session, is the hazard boundary. Skips: force=true, an unbound/web claim,
     // or a resolver with no session context. `reason` distinguishes the two
     // refusal shapes so the CLI can say which one happened.
+    //
+    // WHICH NAME (task 1004031). The row stores two, and they answer different
+    // questions (the same distinction db-claims.js draws at the insert):
+    // `worktree_name` is the DISAMBIGUATED name — V3.R51 appends a `-2` when
+    // another ACTIVE claim already holds the requested one, so it is unique
+    // across live claims but is NOT the name of any directory on disk.
+    // `requested_worktree_name` is what the caller asked for: the identity of
+    // the working TREE. The resolver sends `detectWorktreeName()`, the real
+    // directory basename — so comparing against the disambiguated name refuses
+    // every ship from a tree whose name ever collided, and names a `<tree>-2`
+    // directory that has never existed. Reproduced live on task 1003900.
+    // db-claims.js already records this exact hazard for the one-claim-per-tree
+    // guard ("keying on the STORED name was the hole"); this is the same hole,
+    // one check over. Fall back to `worktree_name` for rows written before
+    // `requested_worktree_name` existed, where it is the only name there is.
+    const claimTree = claimTreeIdentity(claim);
     const resolveLock = shouldRefuseClaimResolve({
       claimSessionId: claim.creator_session_id,
       resolverSessionId,
-      claimWorktree: claim.worktree_name,
+      claimWorktree: claimTree,
       resolverWorktree,
       force,
     });
@@ -136,7 +170,9 @@ async function resolveClaim({ claimId, builderId, outcome, notesMd, valueSummary
       throw {
         code: 'CLAIM_SESSION_MISMATCH',
         reason: resolveLock.reason,
-        claimWorktree: claim.worktree_name ?? null,
+        // Name the tree the builder can actually `cd` into, not the suffixed
+        // label — the old text sent them to a directory that cannot exist.
+        claimWorktree: claimTree,
       };
     }
 
@@ -1349,6 +1385,7 @@ async function mergeTask({ taskId, intoTaskId, reason }, deps = {}) {
 }
 
 module.exports = {
+  claimTreeIdentity,
   mergeTask,
   abandonTask,
   confirmTask,

package/modules/provisioning/core-upgrade.js

@@ -200,7 +200,8 @@ function makeCoreUpgradeHandler({ provisioning, pool, parseId, validateOrRespond
 /**
  * What the control shows BEFORE anything is pressed — step one of the two-step (D4).
  *
- * Reads the snapshot the control-plane runner writes (migration core_242), because
+ * Reads the snapshot the control-plane runner writes (migration provisioning_019),
+ * because
  * neither fact is reachable from here: the served version lives on the box's loopback
  * and the available versions need a blocking `npm view`. The web tier asks; it does not
  * go and look.
@@ -234,7 +235,7 @@ function previewFromSnapshot(inst, snap, openIntent) {
 }
 
 async function loadPreview(pool, provisioning, inst) {
-  const { rows } = await pool.query('SELECT * FROM core_version_snapshot WHERE instance_id = $1', [inst.id]);
+  const { rows } = await pool.query('SELECT * FROM provisioning_core_version_snapshot WHERE instance_id = $1', [inst.id]);
   const openIntent = provisioning.getOpenIntent ? await provisioning.getOpenIntent(pool, inst.id) : null;
   return previewFromSnapshot(inst, rows[0], openIntent);
 }

package/{migrations/core_242_core_version_snapshot.sql → modules/provisioning/migrations/provisioning_019_core_version_snapshot.sql}

@@ -1,5 +1,32 @@
--- core_242_core_version_snapshot.sql — what the box serves and what it could take
--- (task 1003159, ADR 0293 D3 + D6).
+-- provisioning_019_core_version_snapshot.sql — what the box serves and what it could
+-- take (task 1003159, ADR 0293 D3 + D6; MOVED here from core by task 1004030).
+--
+-- WHY THIS LIVES IN THE MODULE NOW. It arrived as migrations/core_242_core_version_snapshot.sql
+-- and took a foreign key on provisioning_instances — a CORE table depending on a MODULE
+-- one, which ADR 0083's one-way rule forbids. That is not only a layering complaint: it
+-- BROKE every fresh database. scripts/migrate.sh applies the merged set sorted by
+-- BASENAME, so every `core_*` file runs before every `provisioning_*` one; core_242
+-- therefore always reached a database where provisioning_instances did not exist yet,
+-- errored, and took migrate.sh out with exit 3 at migration 147 of ~242. Deterministic,
+-- and invisible on any database that already had the table — which is why production
+-- never saw it and a new contributor's first `bongos dev` did.
+--
+-- Owning it here fixes both halves at once: the dependency is now module→module, and
+-- provisioning_001_tables.sql sorts before this file, so the table it references exists
+-- by the time this runs. The FK and its ON DELETE CASCADE are kept deliberately —
+-- disconnect.js deletes the instance row and documents that its children go with it.
+--
+-- RENAMED to the provisioning_ prefix because a module may only create objects inside
+-- its own namespace (fitness.js check 11, ADR 0083 §Decision #5). The old
+-- core_version_snapshot table is left untouched on databases that already applied
+-- core_242: it is a CACHE, nothing reads it after this lands, and core migrations here
+-- have no DROP TABLE precedent worth inventing for one small table.
+--
+-- NO DATA IS CARRIED OVER, on purpose. Every field is an observation the control-plane
+-- runner rewrites on its next tick, and a missing row is a first-class state the reader
+-- already handles: loadPreview passes rows[0] === undefined straight through and
+-- previewFromSnapshot reports reading:'no_answer' rather than rendering "up to date"
+-- over a reading it does not have.
 --
 -- THE PROBLEM THIS SOLVES IS A LAYERING ONE, not a storage one. The deploy control has
 -- to show the owner two facts before they press anything: the version the box is
@@ -32,7 +59,7 @@
 
 BEGIN;
 
-CREATE TABLE IF NOT EXISTS core_version_snapshot (
+CREATE TABLE IF NOT EXISTS provisioning_core_version_snapshot (
   instance_id      bigint PRIMARY KEY REFERENCES provisioning_instances(id) ON DELETE CASCADE,
   -- What 127.0.0.1/version answered. NULL means the box did not answer — a real and
   -- different state from "answered with an old version", and the control must not
@@ -48,7 +75,4 @@ CREATE TABLE IF NOT EXISTS core_version_snapshot (
   observed_at      timestamptz NOT NULL DEFAULT now()
 );
 
-INSERT INTO schema_migrations (version) VALUES ('core_242_core_version_snapshot')
-  ON CONFLICT (version) DO NOTHING;
-
 COMMIT;

package/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.861",
+  "version": "1.19.862",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.861",
+      "version": "1.19.862",
       "license": "AGPL-3.0-or-later",
       "dependencies": {
         "express": "^4.21.2",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.861",
+  "version": "1.19.862",
   "description": "Cloud Bongos — the AI-first build platform core (GDS + platform surfaces + module system), installed as a versioned dependency (ADR 0108).",
   "license": "AGPL-3.0-or-later",
   "main": "src/platform-server.js",

package/scripts/gds/provision-core-upgrade.js

@@ -251,7 +251,7 @@ async function coreUpgradeInstance(inst, deps, intent) {
  *
  * Runs on every drain tick for each upgradable instance. Both facts it records are ones
  * the web tier cannot reach for itself — the served version lives on loopback, the
- * available versions need a blocking `npm view` (migration core_242 says why at length)
+ * available versions need a blocking `npm view` (migration provisioning_019 says why at length)
  * — so this is the runner reporting on behalf of a process that may only ask.
  *
  * BEST-EFFORT, ALWAYS. A registry hiccup or a box that will not answer must never fail a
@@ -280,7 +280,7 @@ async function snapshotCoreVersions(inst, deps) {
       ? channelMod.resolveChannelTarget({ installed: served, channel: channelMod.DEFAULT_CHANNEL, available })
       : null;
     await db.query(
-      `INSERT INTO core_version_snapshot (instance_id, served_version, available, recommended, observed_at)
+      `INSERT INTO provisioning_core_version_snapshot (instance_id, served_version, available, recommended, observed_at)
        VALUES ($1, $2, $3::jsonb, $4, now())
        ON CONFLICT (instance_id) DO UPDATE
          SET served_version = EXCLUDED.served_version, available = EXCLUDED.available,

package/src/module-api.js

@@ -71,7 +71,7 @@ const { responsibilityFor, ROLE_RESPONSIBILITIES } = require('./role-responsibil
 // there. scripts/gds/bump-version.js still rewrites the literal below; it appends
 // the entry to that file. Look for a version's history there, not here.
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.861'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.862'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
 
 // A namespaced logger so a module's log lines are attributable + consistent.
 // Usage: const log = api.logger('dev-box'); log.info('mounted');

package/tests/claim_resolve_worktree_lock.mjs

@@ -33,7 +33,7 @@ import { test } from 'node:test';
 import { createRequire } from 'node:module';
 
 const require = createRequire(import.meta.url);
-const { shouldRefuseClaimResolve } = require('../modules/lifecycle/db-ship.js');
+const { shouldRefuseClaimResolve, claimTreeIdentity } = require('../modules/lifecycle/db-ship.js');
 
 // ── 1) the bug this task exists to fix ──────────────────────────────────────────
 test('re-auth mid-claim: same worktree, NEW session → allowed', () => {
@@ -255,3 +255,59 @@ test('an empty or malformed details payload does not trigger the retry', () => {
   assert.equal(isUnknownFieldRejection(400, null, 'resolver_worktree'), false);
   assert.equal(isUnknownFieldRejection(400, { error: 'flat_string_error' }, 'resolver_worktree'), false);
 });
+
+// ── 4) task 1004031: WHICH of the two stored names reaches the comparison ───────
+//
+// The guard above was never wrong. The caller was: it passed the DISAMBIGUATED
+// `worktree_name` (V3.R51 appends `-2` when another ACTIVE claim already holds
+// the requested name) while the resolver sends the real directory basename. A
+// tree whose name had ever collided could therefore never ship, and the refusal
+// named a `<tree>-2` directory that has never existed on disk. Reproduced live
+// on task 1003900, where two full grader panels were spent against the wall.
+
+test('a disambiguated claim resolves against the tree the builder is actually in', () => {
+  const claim = { requested_worktree_name: 'goal-1000086-completion', worktree_name: 'goal-1000086-completion-2' };
+  assert.equal(claimTreeIdentity(claim), 'goal-1000086-completion',
+    'the -2 suffix names no directory; the requested name is the tree identity');
+
+  const d = shouldRefuseClaimResolve({
+    claimSessionId: 'sess-1',
+    resolverSessionId: 'sess-1',
+    claimWorktree: claimTreeIdentity(claim),
+    resolverWorktree: 'goal-1000086-completion',
+    });
+  assert.equal(d.refuse, false, 'a name collision with someone else must not strand this ship');
+});
+
+test('the pre-fix behaviour is what it refused — proving the regression is real', () => {
+  const d = shouldRefuseClaimResolve({
+    claimSessionId: 'sess-1',
+    resolverSessionId: 'sess-1',
+    claimWorktree: 'goal-1000086-completion-2',   // the disambiguated name, as passed before the fix
+    resolverWorktree: 'goal-1000086-completion',
+  });
+  assert.equal(d.refuse, true, 'guard rails: this is the comparison that produced the live strand');
+  assert.equal(d.reason, 'worktree_mismatch');
+});
+
+test('a row written before requested_worktree_name existed still uses its stored name', () => {
+  assert.equal(claimTreeIdentity({ worktree_name: 'legacy-tree' }), 'legacy-tree');
+  assert.equal(claimTreeIdentity({ requested_worktree_name: null, worktree_name: 'legacy-tree' }), 'legacy-tree');
+});
+
+test('a web/unbound claim names no tree at all', () => {
+  assert.equal(claimTreeIdentity({}), null);
+  assert.equal(claimTreeIdentity({ requested_worktree_name: null, worktree_name: null }), null);
+  assert.equal(claimTreeIdentity(), null, 'called with nothing must not throw');
+});
+
+test('two genuinely different trees are STILL refused after the fix', () => {
+  const d = shouldRefuseClaimResolve({
+    claimSessionId: 'sess-1',
+    resolverSessionId: 'sess-1',
+    claimWorktree: claimTreeIdentity({ requested_worktree_name: 'tree-a', worktree_name: 'tree-a-2' }),
+    resolverWorktree: 'tree-b',
+  });
+  assert.equal(d.refuse, true, 'the fix must not widen the guard into letting the wrong branch ship');
+  assert.equal(d.reason, 'worktree_mismatch');
+});

package/tests/core_upgrade_runner.mjs

@@ -341,7 +341,7 @@ await t('the snapshot records the served version, the registry list and what the
   const queries = [];
   const d = makeDeps({ served: '1.19.760', available: ['1.19.758', '1.19.760', '1.19.762'], queries });
   await R.snapshotCoreVersions(inst(), d);
-  const w = queries.find((q) => /core_version_snapshot/.test(q.sql));
+  const w = queries.find((q) => /provisioning_core_version_snapshot/.test(q.sql));
   assert.ok(w, 'it wrote the snapshot');
   assert.equal(w.params[1], '1.19.760', 'the served version');
   assert.deepEqual(JSON.parse(w.params[2]), ['1.19.758', '1.19.760', '1.19.762']);
@@ -352,7 +352,7 @@ await t('a box that does not answer still writes a snapshot — a NULL reading i
   const queries = [];
   const d = makeDeps({ served: null, queries });
   await R.snapshotCoreVersions(inst(), d);
-  const w = queries.find((q) => /core_version_snapshot/.test(q.sql));
+  const w = queries.find((q) => /provisioning_core_version_snapshot/.test(q.sql));
   assert.ok(w);
   assert.equal(w.params[1], null);
   assert.equal(w.params[3], null, 'and nothing is recommended against a version we could not read');