@bongos/core 1.19.626 → 1.19.627

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.626",
-  "core_contract": "1.19.626",
-  "source_commit": "15d768a9fe3239e170150c8d2efb98e6de8d98da",
+  "core_version": "1.19.627",
+  "core_contract": "1.19.627",
+  "source_commit": "9132daa97509f28f38b53cf54a6311f0a43f788d",
   "source_ref": "HEAD",
-  "built_at": "2026-09-09T14:24:41.469Z",
+  "built_at": "2026-09-09T18:37:19.003Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 464,
+    "docs_redacted": 465,
     "agent_docs_stubbed": 24,
-    "functional_verbatim": 2096,
+    "functional_verbatim": 2098,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2584,
-  "tree_sha256": "1fbadd48214869e3a766dde80f634c74c81a7ee96bf480937417526afe50a27b",
+  "file_count": 2587,
+  "tree_sha256": "6f56a454e970eef9adac1d969b0e28f75d79cdc9843f666de389fd2766607e55",
   "files": [
     {
       "path": ".claude/skills/backlog-review/SKILL.md",
@@ -162,7 +162,7 @@
     {
       "path": ".claude/skills/goal-create/SKILL.md",
       "mode": "0000644",
-      "sha256": "2df2c9d9ea817c52c47c074ada7aa725a96ea47db90d6d78acd2f986790edc6f"
+      "sha256": "535eb9fd7d3effdc2df7e003bb227c65600055b49dc98bc6f832d3198ba417a0"
     },
     {
       "path": ".claude/skills/goal-review/SKILL.md",
@@ -1869,10 +1869,15 @@
       "mode": "0000644",
       "sha256": "cc44045ea59f76dabc62fe43993ffab6004add88c7f6142bfe9215f7f2c33c99"
     },
+    {
+      "path": "docs/adr/0270-rank-floor-derives-without-a-prediction.md",
+      "mode": "0000644",
+      "sha256": "a16ee8bb0d163fec8ffce252e165de4010954e45a7f61bc205163c70077451ee"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "6b90114abfa5e891a8f2ea16c547c960c982030d6228d43c2a833840123a3f69"
+      "sha256": "26757599a787417d621bd760d61f156f41b12dc73a195d82b912cc6e956d5642"
     },
     {
       "path": "docs/api-reference.md",
@@ -2757,7 +2762,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "19d4d61c3cd024932aeb068335ef1d9d69e37a59a0e7d653a5e6136bb4972c19"
+      "sha256": "ccefe35e8bc2cd1de16f6164b9d2782d9dbd6c5c8660ab75e7a0bf198078d2dc"
     },
     {
       "path": "docs/modules-contract.md",
@@ -3779,6 +3784,11 @@
       "mode": "0000644",
       "sha256": "c10c4bbbead4a3bafde336f3433a1432818880751f7a21436a6162f0dbde1abf"
     },
+    {
+      "path": "migrations/core_236_rank_floor_backfill.sql",
+      "mode": "0000644",
+      "sha256": "06b53d66e710dfbf602011459ec8d69adce8e281632927daea0735f8078b2f86"
+    },
     {
       "path": "modules/agents/lib/validate.js",
       "mode": "0000644",
@@ -5602,7 +5612,7 @@
     {
       "path": "modules/lifecycle/db-rank-authz.js",
       "mode": "0000644",
-      "sha256": "c93780ea71bb2f8f3d2b21f042c21d029f1ed5336a3aaf178fb3e14925dcc19b"
+      "sha256": "ac33825a705a0d541fc7fe94858f967ef8ef9713a2b7a1f1a03ce268494bb317"
     },
     {
       "path": "modules/lifecycle/db-shared.js",
@@ -5617,7 +5627,7 @@
     {
       "path": "modules/lifecycle/db-tasks.js",
       "mode": "0000644",
-      "sha256": "65558689ccfcea8f71b98cd51eaf1fb45d39267f7e6f6cf8fc35814da2752a34"
+      "sha256": "d8cce5b44106009987d3d32b711a114e4505b4e504bbc6fdfc84f161024ee0cd"
     },
     {
       "path": "modules/lifecycle/db-versions.js",
@@ -7682,12 +7692,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "008a893c7efba51a8e8b7feff7b0569454c3b85670369ad736c28ba25b331c75"
+      "sha256": "72fea99ed1a6a192978e5b257da8b6c819a649e210da1395d7fdace85b35cd4d"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "a8f88df15fae0f2566f18b0d78985e82d8d6ab5c72ee35cdf1598130ac2e8ce3"
+      "sha256": "22510ead9bfe323615390297a28fab238a3a053defb3849e071f7ad66b84aa0d"
     },
     {
       "path": "public-docs/index.html",
@@ -9427,7 +9437,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "13157fd8a1bf1a5d1b892a3deed40c9fc1a85c7daf5db9bf5283837e261a6081"
+      "sha256": "a28b94a91c283d898bed5fe0810e029e31b3ab33760b2c132a320058d3692bff"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -12049,10 +12059,15 @@
       "mode": "0000644",
       "sha256": "aea6f9ec053bd9477288025b58ed76c166c2d59a24d7ea3481edadba90113887"
     },
+    {
+      "path": "tests/rank_floor_wiring.mjs",
+      "mode": "0000644",
+      "sha256": "f81f559b5428497b2246580c7921ecd1ba5a2f1034cf29eb5e5c21b04675f216"
+    },
     {
       "path": "tests/rank_gate.mjs",
       "mode": "0000644",
-      "sha256": "d8fff57f5fee95bf11a5c1df3e2c0e342d39ef5b22c5e87f47a61dd9a3d2a8cb"
+      "sha256": "78626dc42e6d31685352e43e1e8e094a904f59d9d0562caf6b6e126934df973f"
     },
     {
       "path": "tests/rank_tier_single_source.mjs",

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

@@ -67,7 +67,7 @@ Everything here is your call. It is presented in Phase 4 as a proposal, not as q
 - **`category_id`** — the goal's HUMAN category (task 1003277; ADR 0192 — advisory, it gates nothing). Read the live set with `GET /api/gds/work-categories` (never hard-code the labels), infer the best fit from the goal's outcome and its `scope_modules`, and state your pick in the Phase-4 approval round like every other drafted field. **When nothing in the set fits, that is a designed prompt, not an error**: do NOT silently pick the nearest, and do NOT leave it null and move on — surface the gap in the gray-area round and offer to create a new category (`POST /api/gds/work-categories` with `{"label":"..."}`; a duplicate slug converges on the existing row), then use it. Creating uncategorised stays legal — if the user declines to name one, POST the goal without `category_id` and note that the 201 body will carry a `category_advisory` reminding whoever looks next.
 - **`succeeds_goal_id`** — set it when carrying an achieved goal forward. `POST /goals` validates the predecessor exists *before* creating, so a bad ref can't orphan a goal; it then stamps the predecessor's `succeeded_by_goal_id`. Archiving the predecessor is a **separate** call.
 - **Criteria — 2 to 4.** A goal's criteria are narrower than a version's: each should plausibly anchor 2–5 tasks. Draft `criterion_id` as a stable kebab slug (position-independent, and what `criterion_ids` on `POST /tasks` should reference); `criterion_md` is the outcome prose.
-- **Seed tasks — 3 to 8.** Per criterion, with `kind`, a one-line done-when, `criterion_ids: ["<slug>"]`, and dependency edges. Omit `touches[]` (advisory, ADR 0049 — backfilled from the real diff at ship). Never hand-set `requires_rank` (auto-derives, ADR 0084). Proof tasks use `kind='verify'`; exploration uses `kind='spike'` (and spikes are deliberately left in backlog).
+- **Seed tasks — 3 to 8.** Per criterion, with `kind`, a one-line done-when, `criterion_ids: ["<slug>"]`, and dependency edges. Omit `touches[]` (advisory, ADR 0049 — backfilled from the real diff at ship). Never hand-set `requires_rank`: it auto-derives (ADR 0084) from `needs_migration` and the goal's own scope wall, neither of which needs a prediction (ADR 0270). **Do set `needs_migration: true` on any task that will alter the live database** — it is the input that floors such a task at Metic, and omitting it is how a schema change lands in the open queue. Proof tasks use `kind='verify'`; exploration uses `kind='spike'` (and spikes are deliberately left in backlog).
 
 ## Phase 4 — Ask, then get sign-off
 

package/docs/adr/0270-rank-floor-derives-without-a-prediction.md

@@ -0,0 +1,59 @@
+# ADR 0270 — The rank floor derives from facts, not from a prediction
+
+**Date:** 2026-09-09
+**Context:** BONGOS-V2, goal [1000111](https://cloudbongos.com/builders#/task/1003663) (Working area 7 — Government), task [1003663](https://cloudbongos.com/builders#/task/1003663). Repairs an interaction between [ADR 0084](<redacted>.md) (the per-task `requires_rank` floor) and [ADR 0049](<redacted>.md) (the split parallel-safety contract, which retired predictive `touches[]`). Generalises the protected-scope floor task 1003066 (BV1.R05) shipped for the ideas vector.
+**Status:** Accepted.
+
+## Problem
+
+ADR 0084 gave every task a `requires_rank` floor, derived at create time by `deriveRequiredRank(touches, securitySensitive)`: a task touching the rank/authz/ship-grade/deploy/migration core floors at `metic`, everything else stays `xenos`. The floor is enforced at claim time, as the `INSUFFICIENT_RANK` rung of the claim refusal ladder.
+
+ADR 0049 then retired **predictive** `touches[]`. It is no longer declared up front; it is backfilled from the real committed diff **at ship** — which is *after* the claim the floor exists to gate. So on every create vector that omits it, `matchProtected()` saw an empty array and the floor could not rise. The derivation did not fail loudly; it silently returned `xenos` forever, because it is computed once at creation and never recomputed when `touches` is later backfilled.
+
+Measured on this instance before the fix:
+
+- **88 tasks declared `needs_migration: true`; 68 of them (77%) sat at `requires_rank: 'xenos'`.**
+- Among them, task 1003372 — *"Hash `builder_sessions.token` at rest"* — was `status: ready`, claimable by any Xenos. A newcomer could claim a rewrite of the auth token store.
+- Goal 1000111 alone (scope wall: `kernel`, `lifecycle`, `government`, `hall-ui`) held 20 claimable tasks at `xenos`, including two that drop columns from the goal-membership authz tables.
+
+Two mechanisms kept it invisible:
+
+1. **The authoring routes disagree.** `POST /goals/:id/tasks` makes `touches[]` **required** — it is the blast radius its scope wall checks — so the floor does derive there, and the route comment correctly promises "a protected/sensitive task floors to Metic and a sub-Metic author cannot claim it". Its sibling `POST /tasks` treats `touches[]` as optional, and that is the route `/goal-create` actually files seed tasks through.
+2. **The skill told authors to disable both inputs.** `goal-create/SKILL.md` said, in one line: *omit `touches[]`* … *never hand-set `requires_rank`*. Omit the only input and never set the output — together those guarantee `xenos`.
+
+The task that raised this asked for "an Archon-level review of how the floor should now be derived". Its premise — *every* task since ADR 0049 — turned out to be overstated (August 2026: 83 tasks, 56 `xenos`; September: 11 and 9), because other vectors still pass `touches[]`. The gap is vector-specific. That distinction is what makes the fix cheap.
+
+## Decision
+
+**The floor derives from facts a task already carries at create time, never from a prediction.** `deriveRequiredRank` gains a third argument, `opts`, with two touches-free inputs. Any one of four conditions floors a task at `metic`:
+
+| Input | Why it is a fact, not a prediction |
+|---|---|
+| `security_sensitive` | Author-declared, unchanged since ADR 0084. |
+| `needs_migration` | The direct successor to the `'migrations/'` entry `POST /tasks` used to fold into `touches[]` before it became a dedicated boolean. A task altering the live database **is** the migration core. |
+| `scopeProtected` | The owning goal's `scope_modules` wall reaches protected territory. Always available — `goal_id` is required on every task since BV1.R60 — and read through the same `scopeIncludesProtected` primitive the pre-push hook, the grader and main-audit use, so it cannot drift from them. |
+| `matchProtected(touches)` | Retained. Still correct on the vectors that *do* declare touches; simply inert on the ones that don't. |
+
+`metic` remains the ceiling. `archon` is never auto-assigned — "only the Archon may claim this" stays a deliberate manual override.
+
+Three properties travel with the decision:
+
+- **Derived at the lowest create layer.** In `db-tasks.createTask`, after `goalIdEffective` resolves — not in each route. This is the argument ADR 0096 already made for creation-time reward assignment: every vector (`POST /tasks`, `POST /goals/:id/tasks`, idea-promotion, capture, newcomer-restock, copy-desk, kickoff-seed, seed scripts) inherits the floor, and a vector added next year cannot forget it. Patching the two authoring routes separately is precisely how they came to disagree.
+- **Raise-only, everywhere.** `highestRank` still clamps upward only, so an explicit `requires_rank` can raise the bar and never drop below the derived floor. `updateTaskRequiresRank` re-derives with the **same four inputs**; without that, an Archon setting a migration task to `xenos` would have succeeded, silently undoing the create-time protection.
+- **Every setter of a floor input ratchets.** A floor derived only at creation is a floor with a back door: `needs_migration` is PATCH-able (task 1002648, to correct the create-time heuristic), so a Metic could have flipped it true on an existing `xenos` task and left the floor untouched — reopening on the PATCH path exactly the gap this ADR closes on the create path. `updateTaskNeedsMigration` is therefore now the exact sibling of `updateTaskSecuritySensitive`: the same `CASE WHEN … requires_rank IN ('xenos','thetes') THEN 'metic'` ratchet, raising only. `tests/rank_floor_wiring.mjs` asserts the ratchet appears in **exactly two** setters, so a third boolean that starts feeding `deriveRequiredRank` cannot quietly ship without one.
+- **Opt-in on a strict `=== true`.** A stray truthy value cannot wall off the open queue.
+
+## What was rejected
+
+- **Re-requiring predictive `touches[]` at create.** This is the obvious fix and it is wrong: it re-litigates ADR 0049, whose whole finding was that a wrong up-front prediction blocked or de-credited correct work. The floor is not worth reviving the thing that was deliberately deleted.
+- **Recomputing the floor when `touches` is backfilled at ship.** Too late by construction. The claim it gates has already happened; the recompute would only relabel history.
+- **Deriving from `module_key`.** More precise than the goal wall in principle, but it is null on most tasks (including the one that reported this), so it would leave the same hole.
+- **A new gate or approval step.** Nothing here adds a rung to the claim refusal ladder; the existing `INSUFFICIENT_RANK` rung simply starts receiving the correct input.
+
+## Consequences
+
+- **A protected goal wall is blunt, and that is accepted.** `scopeIncludesProtected` is true when *any* module in the wall is protected, so a purely `hall-ui` task inside goal 1000111 (`hall-ui` + `kernel` + `lifecycle` + `government`) also floors at `metic`. This is the same semantics the ideas vector has enforced since task 1003066, it fails in the safe direction, and `metic` is the first *trusted working* rank rather than a rare one. The cost is a smaller Xenos queue in mixed-scope goals. The remedy, when it bites, is to narrow the goal's wall — which is the honest fix anyway.
+- **The newcomer queue is unaffected today** — there are currently **zero** claimable `newcomer_friendly` tasks, in protected-scope goals or otherwise. Worth re-checking if the beginner queue is ever restocked inside a protected-scope goal; a `newcomer_friendly` carve-out was deliberately **not** added, because an exception that lowers a safety floor is exactly the kind of thing that should require a decision rather than exist by default.
+- **A one-time backfill**, `migrations/<redacted>.sql`, raises still-claimable (`backlog`/`ready`) `xenos` rows that meet either new condition. It is scoped to claimable work because the floor is a claim-time gate — rewriting shipped or abandoned rows would change no decision that has not already been made. It raises only, and there is no down-migration, for the reason ADR 0084 gave: lowering a safety floor is never automatic.
+- **The protected-module list is spelled once in that migration**, as a point-in-time snapshot. A migration cannot call into JS, and a historical backfill should record the roster as it stood the day it ran. The live authority remains `module-scope-map.scopeIncludesProtected` over `PROTECTED_GLOBS`.
+- **`goal-create/SKILL.md` now tells authors to set `needs_migration: true`** on any task that will alter the live database. It is the input that floors such a task, and omitting it is how a schema change reaches the open queue.

package/docs/adr/README.md

@@ -361,3 +361,4 @@ This keeps the decision history honest and traceable.
 | 0267 | [**Unanimity, and the revise-and-re-sit loop** ([task 1003733](https://cloudbongos.com/builders#/task/1003733) · goal 1000111 — *Government*, owner decision 2026-09-08). A Full Idea is ratified by **unanimous** agreement from round one; a sitting that does not carry RETURNS to its author, who revises and re-sits it, unbounded, until the board is unanimous. `unanimous` joins `PASS_RULES` as a fourth answer on the axis these rules actually differ on — **what silence means**: it is two conditions, not one, because "nobody objected" is true of an empty room. Everyone who spoke must have said yes AND somebody must have spoken, so an unvoted sitting RETURNS, which is exactly what makes the clock the owner asked for safe under it ([ADR 0191](<redacted>.md) §4: a deadline may only be given to a rule whose expiry means return). **There is deliberately no membership denominator** — that is the whole difference from `majority`, and it is the owner's "silence does not block" as code: an absent member is not in the reckoning, so one yes out of four carries. The stated cost is that an attentive minority can ratify on a distracted board; the alternative is one person on holiday stopping the pipeline. Trigger changes follow from the rule: a single yes does NOT close it (a later member must still be able to object — the sitting runs its clock, full turnout closes early), while a reasoned objection closes it AT ONCE (no vote-changing in v1 fixes the outcome, and the author needs the feedback to revise). ADR 0191 §3's author rule rides both unchanged. **`BOARD_DEFAULTS` is NOT moved**: a fresh instance stays the day-one monarchy, because under any non-author-yes rule a solo founder can never ratify their own ideas (0191 §5) — adoption is a board amendment, and no env var can change a constitution. The revise-and-re-sit loop already existed (`POST /inbox/:id/resubmit` re-grades and re-fires the window hook); what the board owes it is now pinned by test — a return CLOSES the item so the next window may open, and pays nothing. Named limits: a zero-vote return carries no human objection (the author gets the mechanical weakest-section flag), and this changes nothing live until the separate defect where a ratified amendment does not survive to the next read is fixed.](<redacted>.md) | government / board room |
 | 0268 | [**The constitution comes from two roots, and a decision that did not take must say so** ([task 1003739](https://cloudbongos.com/builders#/task/1003739) · goal 1000111 — *Government*). On 2026-08-25 cloudbongos.com's board RATIFIED an amendment (rank:metic+ · consent · a 1440-minute sitting) and the constitution never changed — for two weeks `GET /government/constitution` answered the day-one monarchy with the passed amendment sitting in its own `history` array directly beneath the contradicting `board` block. Every sitting since was decided under a rule the board had voted to replace, and it silently un-shipped [ADR 0191](<redacted>.md) (majority) and would have un-shipped [ADR 0267](<redacted>.md) the same way. **Cause:** `modules/government/config.js` resolved BOTH its neutral starter and its instance pack from one `path.resolve(__dirname, '..', '..')`, under a comment saying the roots coincided *today* — true in a single checkout, false on a STANDALONE instance ([ADR 0108](<redacted>.md) §1), where the server runs `node_modules/@cloudbongos/core` with `WorkingDirectory=<instance repo>`. The neutral path stayed right (it really is core content); the INSTANCE path resolved inside the core package, so the host's own `config/government.json` was never read and `applyBoardAmendment` wrote the ratified amendment into `node_modules`, where the nightly core upgrade ([ADR 0161](<redacted>.md) cuts a release per merge) erased it within a day. **Nothing threw and nothing could have** — both paths exist, both are writable, and an absent instance pack is a legal state, so the read fell through to the neutral monarchy exactly as designed. `src/branding.js` had the pattern right three files away. **Fix:** neutral from `resolveCoreRoot()`, instance from `resolveInstanceRoot()`, reached through `src/module-api` — which had exposed NEITHER resolver, and that absence is precisely why the module re-derived the wrong one ([ADR 0083](<redacted>.md) forbids requiring a core internal). Resolved at load, not per call, because `resolveInstanceRoot()` falls back to `process.cwd()` and a lazy resolve would let a `chdir` move the constitution; `applyBoardAmendment` now mkdirs, since the write targets a directory the core does not own. Single-checkout behaviour is byte-identical, asserted rather than claimed. **The detector, which is the durable half:** `constitutionView` carries a `divergence` block comparing the newest PASSED amendment (sanitized as an apply would write it) field-by-field against what is in force, rendered above the hall's dials in words rather than config keys. It REPORTS and never HEALS — the instance pack is also the file a human editing the constitution touches, so a silent re-apply would revert a legitimate hand edit with no way to tell the two apart. A RETURNED amendment is never compared (that is what *returned* means). Does NOT put the 2026-08-25 amendment back in force — that is a board act. Sibling sweep RUN, not promised: one real hit filed as [task 1003745](https://cloudbongos.com/builders#/task/1003745) (quarantine.js's repo-containment refusal is blind to the instance repo).](<redacted>.md) | government / instance roots |
 | 0269 | [**The CLI session store is host-keyed at a fixed anchor; the per-brand file stays the active pointer** ([task 1003741](https://cloudbongos.com/builders#/task/1003741) · goal 1000090 — *Working area 4, Bongos Core distribution*). The CLI resolved its session path from the BRANDING PACK, read out of whatever checkout the process stood in — one slot, that moved. Standalone (the public CLI's whole situation) no checkout means no brand, so every instance shared `~/.config/cloudbongos/gds-session.json` and signing into a second DESTROYED the first; in-repo it landed in `~/.config/<slug>/` where the standalone CLI could never find it (`npx … api GET /me` from a bare dir returned the cloudbongos builder while a valid hermeslines session sat on the same machine). Not theoretical — the owner's config dir carries a hand-made `gds-session.<redacted>.bak.json` and four more of the same shape. **Decision: one file per instance keyed by HOST at a FIXED anchor (`~/.config/<FALLBACK_DIR>/instances/<host>.json`), with the per-brand `gds-session.json` left exactly where it is as the ACTIVE pointer.** Four load-bearing parts. (1) The anchor must never read `configHome()`/`configDirName()`/the pack — a test asserts the function body names none, since routing it back through the brand silently reinstates the split. (2) The active pointer does NOT move: every existing reader (in-repo skills, the card hook, the dev box, `readSessionToken`) looks there, and the store is purely additive. (3) The OUTGOING session is archived BEFORE the incoming one lands — a session written before the store existed is not in it, so without this the first login after upgrading still loses it, the bug surviving its own fix. (4) A stored token is VERIFIED against `/api/gds/me` before being reinstated; unverified falls through to the real device flow, `--force` signs in as somebody else. `login` also names the other instances and how to switch, since sessions are now kept rather than overwritten. Files 0600 in a 0700 dir; an `api_base` naming no host is not stored rather than stored under a guess, so nothing can write outside the store. The dir is `instances/` NOT `sessions/` — `sessions` is a live module key and [ADR 0083](<redacted>.md) §Decision #4 forbids kernel machinery naming one; the fitness gate caught it. Rejected: moving the active pointer (breaks every reader for no visible gain); one file holding a map (changes a format hooks and the dev box parse today); keying under `configHome()` (the bug); restoring without verifying (hands over a dead session that looks live); a new `bongos switch` verb (login is the command already reached for, and the public CLI's surface is deliberately small).](<redacted>.md) | cli / auth / distribution |
+| 0270 | [**The rank floor derives from facts, not from a prediction** ([task 1003663](https://cloudbongos.com/builders#/task/1003663) · goal 1000111 — *Working area 7, Government*). [ADR 0084](<redacted>.md) derives every task’s claim-time `requires_rank` floor from `touches[]` + `security_sensitive`; [ADR 0049](<redacted>.md) then retired PREDICTIVE `touches[]`, which is now backfilled from the real committed diff at SHIP — after the claim the floor exists to gate. So on every create vector that omits it the matcher saw an empty array, and because the floor is computed ONCE at creation and never recomputed, it returned `xenos` forever. Nothing threw: an empty `touches[]` is a legal state. **Measured before the fix: 88 tasks declared `needs_migration` and 68 of them (77%) sat at `xenos`** — including [task 1003372](https://cloudbongos.com/builders#/task/1003372), a READY task to hash the `builder_sessions` token store at rest, claimable by any newcomer; goal 1000111 alone held 20 such rows. Two mechanisms hid it: the authoring routes DISAGREE (`POST /goals/:id/tasks` REQUIRES `touches[]` as its scope-wall blast radius, so the floor derives there, while its sibling `POST /tasks` — the route `/goal-create` actually files seed tasks through — treats it as optional), and `goal-create/SKILL.md` told authors in ONE line to *omit `touches[]`* and *never hand-set `requires_rank`*: omit the only input, never set the output. **Decision:** the floor derives from facts a task already carries at create time, never from a prediction — `deriveRequiredRank` gains `opts` with two touches-free inputs, `needs_migration` (the direct successor to the `migrations/` entry `POST /tasks` used to fold into `touches[]`) and `scopeProtected` (the owning goal’s `scope_modules` wall, ALWAYS available since `goal_id` is required, read through the same `scopeIncludesProtected` primitive the pre-push hook, grader and main-audit use, so it cannot drift). Derived at the LOWEST create layer in `createTask` after `goalIdEffective` resolves — the ADR 0096 argument — so every vector inherits it and patching the two routes separately (which is how they came to disagree) is not repeated. `updateTaskRequiresRank` re-derives with the same four inputs, else an Archon setting a migration task to `xenos` would silently undo the create-time floor; raise-only throughout; `archon` still never auto-assigned; a strict `=== true` so a stray truthy value cannot wall off the open queue. One-time backfill `core_236` raises still-CLAIMABLE rows only (the floor is a claim-time gate; rewriting shipped rows changes no live decision) and never lowers. **Accepted cost:** a protected goal wall is blunt — any protected module in the wall floors the whole goal, so a `hall-ui` task in a mixed goal floors at Metic too; same semantics the ideas vector has enforced since task 1003066, fails safe, and the remedy is to narrow the wall. Zero claimable `newcomer_friendly` tasks exist today, and no carve-out was added for them on purpose. Rejected: re-requiring predictive `touches[]` (re-litigates ADR 0049); recomputing at ship (too late by construction); deriving from `module_key` (null on most tasks, including the reporter).](<redacted>.md) | permissions / task lifecycle |

package/docs/module-api-changelog.md

@@ -1701,5 +1701,7 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.624 with no explicit bump. run 34328603214. (task 1002620)
   1.19.626 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.625 with no explicit bump. run 34363350286. (task 1002620)
+  1.19.627 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.626 with no explicit bump. run 34390069410. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/migrations/core_236_rank_floor_backfill.sql

@@ -0,0 +1,56 @@
+-- core_236_rank_floor_backfill.sql — raise the requires_rank floor on work that
+-- was created while the derivation was inert (task 1003663, goal 1000111,
+-- ADR 0270).
+--
+-- WHY THERE IS ANYTHING TO BACK FILL. deriveRequiredRank has always derived the
+-- per-task floor from touches[] + security_sensitive (task 1498, ADR 0085). ADR
+-- 0049 then retired PREDICTIVE touches[] — it is backfilled from the real
+-- committed diff at SHIP, which is after the claim this floor exists to gate —
+-- so on every create vector that omits it the matcher saw an empty array and the
+-- floor never rose. Measured on this instance before the fix: 88 tasks declared
+-- needs_migration and 68 of them (77%) sat at requires_rank='xenos', including
+-- task 1003372, a READY task to rewrite the auth token store at rest.
+--
+-- ADR 0270 gives the derivation two touches-free inputs at create time
+-- (needs_migration, and whether the owning goal's scope wall reaches protected
+-- territory). That fixes every task created from now on. This migration is the
+-- one-time pass over the rows that already exist.
+--
+-- SCOPED TO STILL-CLAIMABLE WORK, on purpose. Only 'backlog' and 'ready' rows are
+-- touched. The floor is enforced at CLAIM time (the INSUFFICIENT_RANK rung of the
+-- claim refusal ladder), so raising it on an already-claimed, shipped or
+-- abandoned row changes no decision that has not already been made — it would
+-- only rewrite history and dirty updated_at across the ledger.
+--
+-- RAISES ONLY, like every other path that writes this column. The WHERE clause
+-- selects requires_rank='xenos', so a row an Archon has already lifted to 'metic'
+-- or 'archon' is left exactly as it is. There is no down-migration for the same
+-- reason ADR 0085 gave: lowering a safety floor is never automatic.
+--
+-- THE MODULE LIST BELOW IS A POINT-IN-TIME SNAPSHOT, not a second source of
+-- truth. The live authority is src/bongos/module-scope-map.scopeIncludesProtected
+-- over PROTECTED_GLOBS (permission-path-check.js) — the same roster the pre-push
+-- hook, the grader and main-audit read, and what the running code calls. A
+-- migration cannot call into JS, and a historical backfill SHOULD record the
+-- roster as it stood the day it ran rather than drift with a later one, so the
+-- nine protected keys are spelled here once and never read again.
+
+UPDATE tasks t
+SET requires_rank = 'metic',
+    updated_at    = now()
+WHERE t.requires_rank = 'xenos'
+  AND t.status IN ('backlog', 'ready')
+  AND (
+    -- The migration core, by the task's own declaration.
+    t.needs_migration = true
+    -- Or the owning goal's scope wall reaches protected territory.
+    OR EXISTS (
+      SELECT 1
+      FROM goals g
+      WHERE g.id = t.goal_id
+        AND g.scope_modules && ARRAY[
+          'kernel', 'lifecycle', 'grading', 'onboarding', 'builder-settings',
+          'autonomy', 'government', 'dev-box', 'devsecops'
+        ]::text[]
+    )
+  );

package/modules/lifecycle/db-rank-authz.js

@@ -146,7 +146,7 @@ function rankAllowsTask(builderRank, requiredRank) {
   return have >= needed;
 }
 
-// deriveRequiredRank — task 1498 / ADR 0085. The per-task requires_rank floor
+// deriveRequiredRank — task 1498 / ADR 0084. The per-task requires_rank floor
 // (V3.R82 #301) shipped INERT: no create/edit path ever set it, so every task
 // sat at the 'xenos' default and the claim gate never bit. We now DERIVE a floor
 // from what a task touches + its sensitivity, reusing the SAME protected-path
@@ -157,10 +157,35 @@ function rankAllowsTask(builderRank, requiredRank) {
 // sub-Metic builder already cannot push to). Everything else stays 'xenos' (the
 // open general queue). NEVER auto-assigns 'archon': "only the Archon may claim
 // this" is a deliberate manual override, not something to infer.
+//
+// task 1003663 / ADR 0270 — WHY THERE ARE NOW FOUR INPUTS, NOT TWO. The floor
+// above derived from touches[] alone, and ADR 0049 then retired PREDICTIVE
+// touches[]: it is backfilled from the real committed diff at SHIP, which is
+// after the claim this floor exists to gate. So the derivation quietly went
+// inert on the vectors that omit it — 68 of the 88 tasks declaring
+// needs_migration sat at 'xenos', including a live-DB migration rewriting the
+// auth token store. The fix is NOT to bring prediction back; it is to derive
+// from facts a task already carries at create time. `opts` takes those:
+// { needsMigration, scopeProtected }.
 // Pure + exported so tests/rank_gate.mjs can exercise it without a DB.
 
-function deriveRequiredRank(touches, securitySensitive) {
+function deriveRequiredRank(touches, securitySensitive, opts = {}) {
   if (securitySensitive === true) return 'metic';
+  // task 1003663 / ADR 0270 — the two touches-FREE inputs. ADR 0049 retired
+  // PREDICTIVE touches[]: it is backfilled from the real diff at ship, so at
+  // CREATE time the matchProtected() arm below sees an empty array on most
+  // vectors and the floor never rises. These arms restore it from facts a task
+  // already carries at create time.
+  //
+  // needsMigration — the direct successor to the 'migrations/' entry POST /tasks
+  // used to fold into touches[] before it became a dedicated boolean. A task
+  // that alters the LIVE database is the migration core by definition.
+  if (opts.needsMigration === true) return 'metic';
+  // scopeProtected — the owning goal's scope wall reaches protected territory.
+  // Unlike touches[] this is ALWAYS available (goal_id is required on every task
+  // since BV1.R60), and it is computed from the SAME protected roster the
+  // pre-push hook, the grader and main-audit read, so it cannot drift from them.
+  if (opts.scopeProtected === true) return 'metic';
   const files = Array.isArray(touches) ? touches : [];
   if (files.length > 0 && matchProtected(files).length > 0) return 'metic';
   return 'xenos';

package/modules/lifecycle/db-tasks.js

@@ -23,6 +23,31 @@ const { deriveRequiredRank, highestRank } = require('./db-rank-authz.js');
 // -------------------------------------------------------------------------
 
 
+// goalScopeProtected — does this task's owning goal reach protected territory
+// (the permission / ship-grade / deploy / migration core)? The touches-free half
+// of the create-time rank floor (task 1003663, ADR 0270).
+//
+// It reads the goal's `scope_modules` wall through the SAME published primitive
+// modules/ideas/inbox.js already uses for routed filings (task 1003066, BV1.R05)
+// and that the pre-push hook, the grader and main-audit read — so this floor
+// cannot drift from the roster they enforce.
+//
+// Runs on the CALLER'S client when there is one, so it sees the same
+// transaction snapshot as the INSERT it feeds — a goal rescoped mid-transaction
+// cannot land between the check and the row. FAILS CLOSED-ish by omission: an
+// absent goal or a non-array wall yields false, which is the honest answer
+// ("no protected scope declared"), and the other three arms of deriveRequiredRank
+// still apply.
+async function goalScopeProtected(goalId, client) {
+  if (goalId == null) return false;
+  const { rows } = await (client || pool).query(
+    'SELECT scope_modules FROM goals WHERE id = $1',
+    [goalId]
+  );
+  const scope = rows.length ? rows[0].scope_modules : null;
+  return Array.isArray(scope) && api.moduleScopeMap.scopeIncludesProtected(scope);
+}
+
 // The version statuses that can still receive new work. 'shipped' and 'frozen' are
 // closed: a version whose scope is sealed cannot be told about a bug found afterwards.
 // Mirrors the CHECK constraint on versions.status (migrations/003_pms.sql).
@@ -124,15 +149,6 @@ async function createTask({
   // to name a goal instead.
   allowCatchAll = false,
 }, deps = {}) { // deps.client enlists this INSERT in the CALLER'S transaction (task 1003065, BV1.R01); the argument for it is at modules/ideas/inbox.js routeIdeaToGoal
-  // task 1498 / ADR 0085: every task carries a deliberate rank floor. Derive it
-  // from touches + sensitivity, then let an explicit requiresRank override only
-  // UPWARD (highestRank) — a requested rank below the derived floor is clamped
-  // up to the floor (fail-closed; the floor mirrors the trust-boundary paths a
-  // sub-Metic builder cannot push to anyway).
-  const requiresRankEffective = highestRank(
-    deriveRequiredRank(touches, securitySensitive),
-    requiresRank ?? 'xenos'
-  );
   // task 1677 / ADR 0096 (2026-06-28): creation is now the PRIMARY reward-assignment
   // point — every task is born with a fair drachmae value, not just at promote/claim.
   // When the caller supplies NO positive credits_reward (null/undefined/0), auto-assign
@@ -181,6 +197,26 @@ async function createTask({
     }
     goalIdEffective = await generalGoalIdForVersion(versionId);
   }
+  // task 1498 / ADR 0084: every task carries a deliberate rank floor. Derive it,
+  // then let an explicit requiresRank override only UPWARD (highestRank) — a
+  // requested rank below the derived floor is clamped up to the floor
+  // (fail-closed; the floor mirrors the trust-boundary paths a sub-Metic builder
+  // cannot push to anyway).
+  //
+  // task 1003663 / ADR 0270: derived HERE, at the lowest create layer and AFTER
+  // goalIdEffective resolves, rather than in each route — the same argument the
+  // reward auto-assignment above makes. Every create vector (POST /tasks,
+  // POST /goals/:id/tasks, idea-promotion, capture, newcomer-restock, copy-desk,
+  // kickoff-seed, seed scripts) inherits the floor, and a vector added next year
+  // cannot forget it. Patching the two authoring routes instead is how
+  // POST /tasks and POST /goals/:id/tasks came to disagree in the first place.
+  const requiresRankEffective = highestRank(
+    deriveRequiredRank(touches, securitySensitive, {
+      needsMigration,
+      scopeProtected: await goalScopeProtected(goalIdEffective, deps.client),
+    }),
+    requiresRank ?? 'xenos'
+  );
   const { rows } = await (deps.client || pool).query(
     `INSERT INTO tasks (version_id, title, description, status, touches,
                         est_minutes, est_cost_usd, manual_degree, priority,
@@ -366,7 +402,7 @@ async function updateTaskNewcomerFriendly(id, newcomerFriendly) { return updateT
 // (the === true coercion below preserves the boolean-only contract).
 
 async function updateTaskSecuritySensitive(id, securitySensitive) {
-  // task 1498 / ADR 0085: flagging a task security_sensitive RAISES its rank
+  // task 1498 / ADR 0084: flagging a task security_sensitive RAISES its rank
   // floor (a now-sensitive task must require Metic+). Recompute and ratchet
   // requires_rank UP in the same atomic UPDATE so the two columns can't diverge;
   // never lower it (an existing 'metic'/'archon' may be a protected-touch floor
@@ -386,7 +422,7 @@ async function updateTaskSecuritySensitive(id, securitySensitive) {
   return rows[0] ?? null;
 }
 
-// task 1498 / ADR 0085: set a task's rank floor explicitly (the Archon override).
+// task 1498 / ADR 0084: set a task's rank floor explicitly (the Archon override).
 // The DERIVED floor (touches + security_sensitive) is a HARD minimum — a request
 // below it is clamped UP via highestRank, so an override can only RAISE the bar,
 // never open a sensitive task to a lower rank. `requiresRank` is one live rank
@@ -396,7 +432,15 @@ async function updateTaskSecuritySensitive(id, securitySensitive) {
 async function updateTaskRequiresRank(id, requiresRank) {
   const task = await getTask(id);
   if (!task) return null;
-  const floor = deriveRequiredRank(task.touches, task.security_sensitive);
+  // task 1003663 / ADR 0270: the override re-derives with the SAME four inputs as
+  // creation. Without needsMigration/scopeProtected here, an Archon setting a
+  // migration task to 'xenos' would succeed — the floor would compute 'xenos'
+  // from an empty touches[] and clamp nothing, silently undoing the create-time
+  // protection. An override may still only RAISE.
+  const floor = deriveRequiredRank(task.touches, task.security_sensitive, {
+    needsMigration: task.needs_migration === true,
+    scopeProtected: await goalScopeProtected(task.goal_id, null),
+  });
   const effective = highestRank(floor, requiresRank ?? 'xenos');
   const { rows } = await pool.query(
     `UPDATE tasks SET requires_rank = $1, updated_at = now() WHERE id = $2 RETURNING *`,
@@ -508,7 +552,32 @@ async function updateTaskAutomationTag(id, automationTag) { return updateTaskCol
 // task 1002648: correct the create-time migration heuristic's verdict — a false
 // flag makes claiming reserve a migration number that goes unused (task 1002614
 // burned 213 that way). Boolean only; the route validates.
-async function updateTaskNeedsMigration(id, needsMigration) { return updateTaskColumn(id, 'needs_migration', needsMigration === true); }
+//
+// task 1003663 / ADR 0270: needs_migration is now a rank-floor INPUT, so this
+// stopped being a bare column write and became the exact sibling of
+// updateTaskSecuritySensitive above — same CASE, same ratchet, same reasoning.
+// The correction this setter exists for runs BOTH ways: task 1002648 names the
+// true→false direction, but false→true is the one that matters here, and without
+// the ratchet a Metic could PATCH needs_migration onto an existing xenos task and
+// leave the floor at xenos — reopening on the PATCH path exactly the gap ADR 0270
+// closes on the create path. RAISES ONLY: flipping the flag back off never drops
+// the gate, because an existing 'metic'/'archon' may be a protected-scope floor or
+// a deliberate override. An Archon lowers it explicitly via updateTaskRequiresRank,
+// which re-derives from all four inputs.
+async function updateTaskNeedsMigration(id, needsMigration) {
+  const mig = needsMigration === true;
+  const { rows } = await pool.query(
+    `UPDATE tasks
+        SET needs_migration = $1,
+            requires_rank = CASE WHEN $1 AND requires_rank IN ('xenos', 'thetes')
+                                 THEN 'metic' ELSE requires_rank END,
+            updated_at = now()
+      WHERE id = $2
+      RETURNING *`,
+    [mig, id]
+  );
+  return rows[0] ?? null;
+}
 
 // BV1.R53 (task 1422): assign (or clear) the module_key that declares which
 // module this task's work belongs to. Drives module-disjointness at claim time

package/package-lock.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.626",
+  "version": "1.19.627",
   "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/src/module-api.js

@@ -55,7 +55,7 @@ const { buildInfo } = require('./build-info');
 // 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.626'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.627'; // 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/rank_floor_wiring.mjs

@@ -0,0 +1,135 @@
+// tests/rank_floor_wiring.mjs — the rank floor is WIRED, not merely derivable
+// (task 1003663, goal 1000111, ADR 0270).
+//
+// WHY THIS FILE EXISTS SEPARATELY FROM tests/rank_gate.mjs. That file pins the
+// PURE helpers — `deriveRequiredRank` / `highestRank` — by handing them opts it
+// builds itself. That is necessary and it is not sufficient: the whole defect
+// ADR 0270 repairs was a derivation that was perfectly correct and never
+// REACHED, because the input it needed (`touches[]`) stopped arriving at the
+// call site. A test that constructs the inputs by hand cannot catch that class
+// of bug a second time — it asserts the calculator, not the plumbing.
+//
+// So this file drives the real `createTask` against a SQL-aware client and reads
+// the `requires_rank` actually bound into the INSERT, plus the two PATCH setters
+// that can move a floor input after creation.
+//
+// Run:  node --test tests/rank_floor_wiring.mjs
+
+import assert from 'node:assert/strict';
+import { test } from 'node:test';
+import { createRequire } from 'node:module';
+import { makeSqlAwareClient, lifecycleDbSource } from './helpers.mjs';
+
+process.env.NODE_ENV = 'test';
+const require = createRequire(import.meta.url);
+const { createTask } = require('../modules/lifecycle/db.js');
+
+// The INSERT binds ~25 columns positionally, so a hardcoded params[20] would be a
+// silent lie the first time somebody inserts a column. Read the column list out of
+// the statement under test and resolve the index by NAME.
+function boundValue(sql, params, column) {
+  const cols = String(sql).slice(sql.indexOf('(') + 1, sql.indexOf(')'))
+    .split(',').map((c) => c.trim());
+  const i = cols.indexOf(column);
+  assert.notEqual(i, -1, `INSERT INTO tasks no longer binds a '${column}' column — update this test`);
+  return params[i];
+}
+
+// One create against a fake goal row; returns the requires_rank the INSERT bound.
+async function createdFloor({ scopeModules, needsMigration = false, requiresRank = null }) {
+  let insert = null;
+  const { _client } = makeSqlAwareClient(async (sql, params) => {
+    if (/^SELECT scope_modules FROM goals/i.test(sql)) {
+      return { rows: [{ scope_modules: scopeModules }] };
+    }
+    if (/^INSERT INTO tasks/i.test(sql)) {
+      insert = { sql, params };
+      return { rows: [{ id: '9001' }] };
+    }
+    return { rows: [] };
+  });
+
+  await createTask({
+    versionId: 'BONGOS-V2',
+    title: 'a task',
+    goalId: '1000111',
+    needsMigration,
+    requiresRank,
+  }, { client: _client });
+
+  assert.ok(insert, 'createTask never reached its INSERT');
+  return boundValue(insert.sql, insert.params, 'requires_rank');
+}
+
+// ---------------------------------------------------------------------------
+// createTask — the create path actually reads the goal wall
+// ---------------------------------------------------------------------------
+
+test('a goal whose wall reaches protected territory floors the task at metic', async () => {
+  // No touches[], not security_sensitive, not a migration — every pre-0270 input
+  // is absent, which is precisely the shape that used to come out 'xenos'.
+  assert.equal(await createdFloor({ scopeModules: ['hall-ui', 'kernel'] }), 'metic');
+});
+
+test('an unprotected wall leaves the task in the open queue', async () => {
+  assert.equal(await createdFloor({ scopeModules: ['hall-ui'] }), 'xenos');
+});
+
+test('needs_migration floors at metic even under an unprotected wall', async () => {
+  assert.equal(await createdFloor({ scopeModules: ['hall-ui'], needsMigration: true }), 'metic');
+});
+
+test('THE REGRESSION: the create path reads the wall, it does not just own a helper', async () => {
+  // Mutation guard. If someone drops the goalScopeProtected call from createTask
+  // — the exact way this bug happened the first time, by a caller ceasing to
+  // supply an input — the pure tests in rank_gate.mjs all still pass and this one
+  // fails. That asymmetry is the point of the file.
+  assert.equal(await createdFloor({ scopeModules: ['lifecycle'] }), 'metic');
+  assert.equal(await createdFloor({ scopeModules: ['government'] }), 'metic');
+});
+
+test('an explicit requires_rank still only RAISES, never lowers the derived floor', async () => {
+  assert.equal(await createdFloor({ scopeModules: ['kernel'], requiresRank: 'xenos' }), 'metic');
+  assert.equal(await createdFloor({ scopeModules: ['hall-ui'], requiresRank: 'archon' }), 'archon');
+});
+
+test('a missing goal row is the honest false, not a throw', async () => {
+  // scope_modules is NOT NULL DEFAULT '{}', but a goal deleted mid-transaction
+  // returns no row at all. That must fall through to the other arms, not crash a
+  // create.
+  assert.equal(await createdFloor({ scopeModules: undefined }), 'xenos');
+  assert.equal(await createdFloor({ scopeModules: undefined, needsMigration: true }), 'metic');
+});
+
+// ---------------------------------------------------------------------------
+// The PATCH setters — a floor INPUT may be flipped after creation
+// ---------------------------------------------------------------------------
+// These two write through the module-level pool rather than an injectable client,
+// so they are pinned at the source. The assertion is narrow on purpose: it is the
+// RATCHET that matters (raise on true, never lower), not the surrounding SQL.
+
+test('updateTaskNeedsMigration ratchets requires_rank UP, exactly like its security_sensitive sibling', () => {
+  const src = lifecycleDbSource();
+  const setter = src.slice(src.indexOf('async function updateTaskNeedsMigration'));
+  const body = setter.slice(0, setter.indexOf('\n}\n') + 1);
+
+  assert.match(
+    body.replace(/\s+/g, ' '),
+    /requires_rank = CASE WHEN \$1 AND requires_rank IN \('xenos', 'thetes'\) THEN 'metic' ELSE requires_rank END/,
+    'PATCHing needs_migration=true must raise the floor — otherwise ADR 0270 is closed on the create path and open on the PATCH path'
+  );
+  // Raise-only: nothing in the setter may write a rank BACK DOWN when the flag
+  // clears. An existing metic may be a protected-scope floor or an Archon override.
+  assert.doesNotMatch(body, /ELSE 'xenos'/, 'the setter must never lower an existing floor');
+});
+
+test('both floor-input setters share one ratchet — neither may drift from the other', () => {
+  const src = lifecycleDbSource();
+  const ratchet = /requires_rank = CASE WHEN \$1 AND requires_rank IN \('xenos', 'thetes'\)\s+THEN 'metic' ELSE requires_rank END/g;
+  const hits = src.match(ratchet) || [];
+  assert.equal(
+    hits.length, 2,
+    `expected the ratchet in exactly 2 setters (security_sensitive + needs_migration), found ${hits.length} — ` +
+    'a new boolean that feeds deriveRequiredRank needs one too, and a removed one is a reopened gap'
+  );
+});

package/tests/rank_gate.mjs

@@ -399,6 +399,51 @@ t('empty / null / undefined touches with no sensitivity => xenos (no throw)', ()
   assert.equal(db.deriveRequiredRank(undefined, undefined), 'xenos');
 });
 
+// ---------------------------------------------------------------------------
+// task 1003663 / ADR 0270 — the two touches-FREE inputs. ADR 0049 retired
+// predictive touches[], so at CREATE time the arms above see an empty array on
+// most vectors and the floor never rose: 68 of 88 needs_migration tasks sat at
+// xenos, one of them a ready task to rewrite the auth token store. These pin the
+// replacement, which derives from facts a task carries WITHOUT a prediction.
+// ---------------------------------------------------------------------------
+console.log('\nderiveRequiredRank (the touches-free floors — task 1003663):');
+
+t('needs_migration floors at metic with NO touches at all', () => {
+  assert.equal(db.deriveRequiredRank([], false, { needsMigration: true }), 'metic');
+  assert.equal(db.deriveRequiredRank(null, false, { needsMigration: true }), 'metic');
+});
+
+t('a protected goal scope floors at metic with NO touches at all', () => {
+  assert.equal(db.deriveRequiredRank([], false, { scopeProtected: true }), 'metic');
+  assert.equal(db.deriveRequiredRank(null, false, { scopeProtected: true }), 'metic');
+});
+
+t('THE REGRESSION: the exact shape of task 1003372 (ready, migration, no touches)', () => {
+  // Before ADR 0270 this returned 'xenos' — a Xenos could claim a task to hash
+  // the builder_sessions token store at rest. It must never do so again.
+  assert.equal(
+    db.deriveRequiredRank([], false, { needsMigration: true, scopeProtected: false }),
+    'metic'
+  );
+});
+
+t('the flags are opt-in: false / absent / non-boolean never RAISE the floor', () => {
+  // Only a strict === true raises, so a stray truthy value cannot quietly wall
+  // off the open queue (the fail-closed direction here is "stay open").
+  assert.equal(db.deriveRequiredRank([], false, {}), 'xenos');
+  assert.equal(db.deriveRequiredRank([], false, { needsMigration: false, scopeProtected: false }), 'xenos');
+  assert.equal(db.deriveRequiredRank([], false, { needsMigration: 'yes' }), 'xenos');
+  assert.equal(db.deriveRequiredRank([], false, { needsMigration: 1 }), 'xenos');
+});
+
+t('omitting opts entirely is the pre-0270 two-argument behaviour, unchanged', () => {
+  // Every existing call site passes two arguments; none may change meaning.
+  assert.equal(db.deriveRequiredRank([], false), 'xenos');
+  assert.equal(db.deriveRequiredRank(['public/game/main.js'], false), 'xenos');
+  assert.equal(db.deriveRequiredRank(['migrations/145_x.sql'], false), 'metic');
+  assert.equal(db.deriveRequiredRank([], true), 'metic');
+});
+
 console.log('\nhighestRank (compose floor with an override; raise-only):');
 
 t('picks the higher-authority rank either way', () => {