@bongos/core 1.19.921 → 1.19.923

package/modules/ideas/trail.js

@@ -42,6 +42,16 @@ const { skillFrictionHiddenClause } = require('./skill-friction');
 // first. Both are returned: the lineage array is the complete answer, the legacy
 // column is the only answer for promotions that predate the lineage table. The
 // LATERAL is bounded by the page window, so this stays one query, not an N+1.
+//
+// `goal_id` RIDES ALONG ON BOTH TASK JOINS (task 1004103 / BV2.R17) because it
+// is what tells a protostar in a WELL from one in OPEN SPACE — the distinction
+// the design makes position carry, and the reason the nod queue is a thing a
+// person can see rather than a list someone must remember to open
+// (docs/design/ideator-surface-direction.md). It is the BINDING home for "which
+// goal"; `idea_inbox.suggested_goal_id`, already on the row, is a HINT about a
+// filing that did not convert and is deliberately not what ./idea-state.js
+// reads. Two nullable columns on joins the query already makes, so this costs
+// no round trip.
 const IDEA_TRAIL_DEFAULT_LIMIT = 20;
 const IDEA_TRAIL_MAX_LIMIT = 100;
 
@@ -68,6 +78,7 @@ async function listIdeaTrailForBuilder(builderId, { limit = IDEA_TRAIL_DEFAULT_L
     `SELECT ${IDEA_COLS_Q}, ${GRADE_COLS_Q},
             pt.title  AS promoted_task_title,
             pt.status AS promoted_task_status,
+            pt.goal_id AS promoted_task_goal_id,
             mi.title  AS merged_into_idea_title,
             mi.status AS merged_into_idea_status,
             COALESCE(lin.tasks, '[]'::json) AS lineage_tasks
@@ -78,7 +89,8 @@ async function listIdeaTrailForBuilder(builderId, { limit = IDEA_TRAIL_DEFAULT_L
        LEFT JOIN LATERAL (
          SELECT json_agg(json_build_object(
                   'task_id', l.task_id, 'origin', l.origin,
-                  'title', lt.title, 'status', lt.status
+                  'title', lt.title, 'status', lt.status,
+                  'goal_id', lt.goal_id
                 ) ORDER BY l.task_id) AS tasks
            FROM ideas_task_lineage l
            JOIN tasks lt ON lt.id = l.task_id

package/modules/lifecycle/cascade.js

@@ -565,6 +565,42 @@ async function runCascadesForShip(shipped, deps = {}) {
     report.errors.push(...errors);
 
     await fileMatches({ matched, deps: { ...deps, log }, report, trigger: TRIGGERS.ship, subject: task });
+
+    // WHOSE WORK THE PROPOSAL IS ABOUT (task 1004099 / BV2.R16 brightness).
+    //
+    // The proposal's body renders `ctx.removals` as prose for a person; this
+    // stores the same objects as rows, because brightness needs the attribution
+    // structured and removal-proposals.js is right to refuse to parse a body
+    // back. One derivation, two renderings — they cannot disagree.
+    //
+    // WRITTEN HERE AND NOT AT VERDICT TIME because `ctx.removals` only exists
+    // while the cascade runs: it came from capped, rate-limited GitHub
+    // commit-history reads, and re-deriving it when a person clicks confirm
+    // would spend that budget again against a history that has moved.
+    //
+    // ON THE SKIPPED ROW TOO, not only the created one. A re-ship finds the
+    // proposal already filed and reports it as `skipped`, and that is exactly
+    // the run that must be able to fill in an attribution the first run missed
+    // (a derivation outage files the question with no targets). The writer is
+    // idempotent, so doing it on every run costs a no-op and buys the repair.
+    //
+    // NOT WIDENING THE RUNNER (ADR 0242): the removal rule still files exactly
+    // one task. This records a side fact about that one task, the same shape as
+    // the verdict row its answer writes.
+    if (typeof deps.recordRemovalTargets === 'function' && Array.isArray(ctx.removals) && ctx.removals.length) {
+      const filed = [...report.created, ...report.skipped].find((r) => r.key === REMOVAL_RULE_KEY);
+      if (filed && filed.taskId != null) {
+        try {
+          await deps.recordRemovalTargets({ proposalTaskId: filed.taskId, removals: ctx.removals });
+        } catch (e) {
+          // Reported, never thrown. The ship is landed, graded and paid before
+          // any of this runs; an attribution that cannot be stored leaves the
+          // proposal answerable and brightness unable to attribute it, which
+          // countUnattributedConfirmed() is there to make visible.
+          report.errors.push(`cascade: recordRemovalTargets() threw (${e && e.message}) — proposal ${filed.taskId} has no stored targets`);
+        }
+      }
+    }
   } catch (e) {
     report.errors.push(`cascade: ${e && e.message}`);
   }

package/modules/lifecycle/migrations/lifecycle_010_removal_targets.sql

@@ -0,0 +1,116 @@
+-- lifecycle_010_removal_targets.sql — WHOSE WORK a removal proposal is about
+-- (task 1004099 / BV2.R16 brightness, goal 1000095; ADR 0321, under ADR 0313 +
+-- ADR 0319).
+--
+-- THE GAP THIS FILLS, IN ONE SENTENCE. lifecycle_009 records the VERDICT on a
+-- removal proposal and the SHIP that did the deleting, and says in as many words
+-- that the list of tasks whose work was removed is "deliberately not here" —
+-- "brightness designs its own storage for targets when it needs one". This is
+-- brightness needing one.
+--
+-- WHY THE VERDICT ROW IS NOT ENOUGH. `lifecycle_removal_verdicts.ship_task_id` is
+-- the task whose merge deleted the files. Brightness is the live share of an
+-- IDEA'S DESCENT, so what it has to know is the opposite direction: which
+-- previously-shipped tasks stopped counting. The ship that deleted them is almost
+-- never in the descent it dims — a later, unrelated piece of work tore out an
+-- earlier one. Reading `ship_task_id` as the removed task would dim the wrong
+-- star, and would dim it for the ship's own idea rather than for the idea whose
+-- work actually died.
+--
+-- WHY NOT PARSE THE PROPOSAL BODY. The attribution already exists in prose:
+-- `cascade.js:removalProposalBody` writes `  - task <id> — <title>` under a
+-- "Removed work attributed to:" heading, from the derivation's structured output.
+-- removal-proposals.js refuses to read it and is right to — "a body is written for
+-- a person to read, and a reader that silently depends on its line shape breaks
+-- the day somebody improves the wording". That refusal only holds if something
+-- else carries the fact, which is this table. The derivation produces
+-- `{ taskId, title, paths }` objects (removal-derivation.js); the body renders
+-- them and this stores them, so the prose and the rows have ONE source and cannot
+-- disagree.
+--
+-- WRITTEN AT PROPOSAL TIME, NOT AT VERDICT TIME. The attribution is a fact about
+-- the diff, and the diff is only in hand while the cascade is running — it comes
+-- from GitHub commit-history reads that are capped at eight paths per ship and run
+-- on the server's shared push credential (removal-derivation.js
+-- MAX_ATTRIBUTED_PATHS). Re-deriving it when a person clicks confirm, days later,
+-- would spend that budget again against a history that has moved on. So the rows
+-- land with the question and the verdict arrives beside them later.
+--
+-- THIS IS NOT THE CASCADE RUNNER FANNING OUT. ADR 0242 forbids widening the runner
+-- to file more than one task per rule per ship, and that is untouched: the removal
+-- rule still files exactly one proposal. This records a side fact ABOUT that one
+-- task, which is the same shape as the verdict row the answer writes.
+--
+-- A PROPOSAL WITH NO ROWS IS A REAL STATE, not a bug, and brightness must read it
+-- as "cannot attribute" rather than "nothing was removed". Three ways it happens:
+-- a proposal filed before this migration; an attribution that found nothing
+-- because every deletion predates `claims.published_head_sha`; a derivation
+-- outage. In all three the honest answer is that the targets are unknown, and
+-- idea-brightness.js treats an unattributed confirmed removal as exactly that —
+-- it dims nothing and says the count out loud, rather than guessing in either
+-- direction.
+--
+-- MODULE-OWNED and `lifecycle_`-prefixed so fitness check 11 permits it (ADR 0083
+-- §Decision #5) — the lifecycle_004..009 convention. It only REFERENCES the core
+-- `tasks` table; a module migration may not ALTER one.
+--
+-- Module migrations are ADDITIVE and NAMESPACED: no down-migration, idempotent
+-- (safe to re-run).
+
+BEGIN;
+
+CREATE TABLE IF NOT EXISTS lifecycle_removal_targets (
+  -- The PROPOSAL task — the question these targets belong to. The join key to
+  -- lifecycle_removal_verdicts, whose primary key is the same column, which is
+  -- what makes "confirmed removals and what they removed" one join and not a
+  -- correlated lookup.
+  proposal_task_id bigint NOT NULL REFERENCES tasks(id) ON DELETE CASCADE,
+
+  -- The task whose shipped work the deletion was attributed to. THIS is what
+  -- brightness intersects with a descent.
+  removed_task_id  bigint NOT NULL REFERENCES tasks(id) ON DELETE CASCADE,
+
+  -- The deleted paths attributed to that task, as the derivation found them.
+  -- Stored because the proposal's prose is not a record: once a person confirms,
+  -- "what exactly went" is the only evidence of what the verdict covered, and a
+  -- later reader asking why a star dimmed has nothing else to look at. An empty
+  -- array is legal — the attribution is the load-bearing half, the paths are the
+  -- receipt.
+  paths            text[] NOT NULL DEFAULT '{}',
+
+  -- One row per (proposal, removed task). The derivation already groups its paths
+  -- by task, so a second row for the same pair would be a double count of the
+  -- same removal — and since the cascade is idempotent (a re-ship re-files
+  -- nothing and re-runs this writer), the constraint is what makes re-running
+  -- safe rather than additive.
+  PRIMARY KEY (proposal_task_id, removed_task_id)
+);
+
+-- Brightness reads in the removed_task_id direction: "of these descent tasks,
+-- which are named by a confirmed removal". The primary key leads with
+-- proposal_task_id and cannot serve that, so the reverse index is the one the hot
+-- query needs.
+CREATE INDEX IF NOT EXISTS idx_lifecycle_removal_targets_removed
+  ON lifecycle_removal_targets (removed_task_id);
+
+-- SAFETY NET — a migration that cannot prove its own effect must not report
+-- success (the lifecycle_007 / ideas_007 / lifecycle_009 precedent). Read-only,
+-- no DDL. If the composite primary key came back wrong, one proposal could carry
+-- the same removed task twice and brightness would count that work as dying
+-- twice — dimming a star further than the removal warrants.
+DO $$
+DECLARE pk_cols text;
+BEGIN
+  SELECT string_agg(a.attname, ',' ORDER BY a.attname) INTO pk_cols
+    FROM pg_constraint c
+    JOIN unnest(c.conkey) AS k(attnum) ON true
+    JOIN pg_attribute a ON a.attrelid = c.conrelid AND a.attnum = k.attnum
+   WHERE c.conrelid = 'lifecycle_removal_targets'::regclass
+     AND c.contype  = 'p';
+  IF pk_cols IS DISTINCT FROM 'proposal_task_id,removed_task_id' THEN
+    RAISE EXCEPTION
+      'lifecycle_010: lifecycle_removal_targets primary key is (%) — expected (proposal_task_id, removed_task_id), so one proposal names one removed task once.', COALESCE(pk_cols, 'none');
+  END IF;
+END $$;
+
+COMMIT;

package/modules/lifecycle/module.json

@@ -35,7 +35,8 @@
   },
   "provides": [
     "lifecycle",
-    "lifecycle.kickoffSeed"
+    "lifecycle.kickoffSeed",
+    "lifecycle.removals"
   ],
   "consumes": []
 }

package/modules/lifecycle/removal-targets.js

@@ -0,0 +1,217 @@
+'use strict';
+
+// modules/lifecycle/removal-targets.js — WHOSE WORK a removal proposal is about
+// (task 1004099 / BV2.R16 brightness, goal 1000095; ADR 0321, under ADR 0313 +
+// ADR 0319).
+//
+// THE ONE FACT THIS FILE CARRIES. lifecycle_009 stores the VERDICT on a removal
+// proposal and the SHIP that deleted the files, and says outright that the list
+// of tasks whose work was removed is "deliberately not here — brightness designs
+// its own storage for targets when it needs one". Brightness needs one, because
+// the direction it reads is the opposite of the one the verdict row holds: it
+// asks "which previously-shipped tasks stopped counting", and `ship_task_id`
+// answers "which ship did the deleting". Those are different tasks, usually under
+// different ideas, and confusing them dims the wrong star.
+//
+// THE PROSE IS NOT THE RECORD. `cascade.js:removalProposalBody` already renders
+// the attribution for a person to read. removal-proposals.js refuses to parse it
+// back — "a body is written for a person to read, and a reader that silently
+// depends on its line shape breaks the day somebody improves the wording" — and
+// that refusal is only safe because of this table. Both the prose and these rows
+// are rendered from the SAME derivation output (`{ taskId, title, paths }` off
+// removal-derivation.js), so there is one source and they cannot disagree.
+//
+// WRITTEN WITH THE QUESTION, READ AFTER THE ANSWER. The attribution is only
+// available while the cascade runs: it comes from GitHub commit-history reads,
+// capped at eight paths per ship, on the server's shared push credential. Storing
+// it at proposal time and joining the verdict later is what keeps `confirm` a
+// pure database write instead of a second trip to GitHub against a history that
+// has since moved.
+//
+// MODULE BOUNDARY: reaches core only through the published doorway
+// `../../src/module-api`. Nothing here imports another module; the economy module
+// reads it through the `lifecycle.removals` port, never by require (ADR 0083
+// rule 1).
+
+const api = require('../../src/module-api');
+
+const { pool } = api;
+
+// A positive integer id as it arrives off a row, a caller or a derivation —
+// where it may be a bigint serialised to a string. Anything else is dropped
+// rather than sent to the database, and never coerced with Number(), which
+// loses bigint precision. The same guard idea-size.js uses, for the same reason.
+function idOf(v) {
+  return /^[1-9]\d*$/.test(String(v)) ? String(v) : null;
+}
+
+// Paths as the derivation hands them: an array of non-empty strings. Anything
+// else becomes an empty array rather than a null, because the column is NOT NULL
+// and because the paths are the receipt, not the load-bearing half — a malformed
+// path list must not cost us the attribution it came with.
+function pathsOf(v) {
+  if (!Array.isArray(v)) return [];
+  return v.filter((p) => typeof p === 'string' && p.length > 0).map(String);
+}
+
+// recordRemovalTargets — store the attribution for ONE proposal.
+//
+//   proposalTaskId  the task the removal cascade filed
+//   removals        the derivation's output: [{ taskId, title, paths }]
+//
+// Returns the number of rows written (0 when there was nothing to attribute).
+//
+// IDEMPOTENT, because its caller is. The cascade re-runs on a re-ship and on a
+// reconciler sweep, and `createTask`'s (source, source_ref) idempotency hands
+// back the ORIGINAL proposal row rather than minting a second one — so this
+// writer is called again with the same proposal id. ON CONFLICT DO NOTHING makes
+// that a no-op instead of a duplicate-key throw that would surface as a cascade
+// error on every re-ship.
+//
+// DO NOTHING, NOT DO UPDATE, and that is a decision rather than a shortcut. A
+// second derivation of the same ship can legitimately find FEWER paths — the
+// commit-history walk is capped and rate-limited, and an exhausted page yields
+// no attribution at all. Overwriting would let a degraded second read erase a
+// good first one. The first attribution is the one taken while the diff was
+// freshest; it stands.
+//
+// A `title` in the derivation output is deliberately NOT stored: it is the
+// task's own title, which lives on `tasks` and can be joined for. Copying it
+// here would be a second copy that goes stale the first time a title is edited.
+//
+// NEVER THROWS INTO THE SHIP. The cascade runner catches everything and turns it
+// into a report, and this is called from inside that guard — but the ship has
+// already landed, been graded and been paid before any of this runs, so an
+// attribution that cannot be stored must cost the ship nothing. The caller
+// reports; it does not fail.
+async function recordRemovalTargets({ proposalTaskId, removals } = {}, { client = null } = {}) {
+  const proposal = idOf(proposalTaskId);
+  if (!proposal) return 0;
+
+  // De-duplicated on the way in. The derivation groups paths by task, so a
+  // repeat is not expected — but the primary key would reject the whole
+  // statement rather than the offending row, and a doubled pair inside ONE
+  // insert is not something ON CONFLICT rescues.
+  const byTask = new Map();
+  for (const r of Array.isArray(removals) ? removals : []) {
+    const taskId = idOf(r && r.taskId);
+    if (!taskId) continue;
+    if (byTask.has(taskId)) {
+      // Merge rather than drop: two entries for one task means the derivation
+      // split its paths, and losing half of them loses half the receipt.
+      const merged = new Set([...byTask.get(taskId), ...pathsOf(r.paths)]);
+      byTask.set(taskId, [...merged]);
+      continue;
+    }
+    byTask.set(taskId, pathsOf(r && r.paths));
+  }
+  if (byTask.size === 0) return 0;
+
+  const q = client || pool;
+  const payload = [...byTask.entries()].map(([taskId, paths]) => ({ taskId, paths }));
+
+  // ONE jsonb parameter, not two parallel arrays — and the reason is a trap
+  // worth naming. The obvious shape is `unnest($2::bigint[])` joined by
+  // ORDINALITY to `unnest($3::text[][])`, and it is wrong: a Postgres
+  // multidimensional array is rectangular and `unnest` FLATTENS it completely,
+  // so a task with two paths and a task with one do not even produce the same
+  // number of rows as their ids, and the ordinality join silently pairs the
+  // wrong path with the wrong task. jsonb keeps each task's paths nested where
+  // they belong, and it costs the same single round trip.
+  const { rowCount } = await q.query(
+    `INSERT INTO lifecycle_removal_targets (proposal_task_id, removed_task_id, paths)
+     SELECT $1::bigint,
+            (e->>'taskId')::bigint,
+            COALESCE(ARRAY(SELECT jsonb_array_elements_text(e->'paths')), '{}')
+       FROM jsonb_array_elements($2::jsonb) AS e
+     ON CONFLICT (proposal_task_id, removed_task_id) DO NOTHING`,
+    [proposal, JSON.stringify(payload)]
+  );
+  return rowCount || 0;
+}
+
+// confirmedRemovalsForTasks — of these tasks, which are named by a CONFIRMED
+// removal, and by which proposal.
+//
+// This is the read brightness is built on. Returns
+// Map<removedTaskIdString, { proposalTaskId, shipTaskId, paths, decidedAt }>;
+// a task absent from the map is alive. Only 'confirmed' rows join — a dismissed
+// proposal is a refactor or a move and must dim nothing, which is the entire
+// reason the verdict is a person's answer rather than a derived signal
+// (ADR 0313).
+//
+// ONE QUERY FOR THE WHOLE SET, not one per task: this runs behind a page of
+// ideas, each with a descent, and a per-task lookup would be a round trip per
+// node of every descent on screen.
+//
+// A task named by SEVERAL confirmed proposals collapses to the EARLIEST verdict.
+// Work can be deleted, re-added and deleted again, and the question brightness
+// asks is binary — is this alive — so the count of times it died is not the
+// fact. The earliest is kept because it is the one whose paths describe the
+// original removal rather than a later re-removal of something restored in
+// between, and because a stable pick makes the read deterministic.
+async function confirmedRemovalsForTasks(taskIds, { client = null } = {}) {
+  const ids = [...new Set((Array.isArray(taskIds) ? taskIds : []).map(idOf).filter(Boolean))];
+  const out = new Map();
+  if (ids.length === 0) return out;
+
+  const q = client || pool;
+  const { rows } = await q.query(
+    `SELECT tg.removed_task_id,
+            tg.proposal_task_id,
+            tg.paths,
+            v.ship_task_id,
+            v.decided_at
+       FROM lifecycle_removal_targets tg
+       JOIN lifecycle_removal_verdicts v ON v.proposal_task_id = tg.proposal_task_id
+      WHERE v.verdict = 'confirmed'
+        AND tg.removed_task_id = ANY($1::bigint[])
+      ORDER BY tg.removed_task_id, v.decided_at ASC, tg.proposal_task_id ASC`,
+    [ids]
+  );
+  for (const row of rows) {
+    const key = idOf(row.removed_task_id);
+    if (!key || out.has(key)) continue;   // ORDER BY put the earliest first
+    out.set(key, {
+      proposalTaskId: String(row.proposal_task_id),
+      shipTaskId: row.ship_task_id == null ? null : String(row.ship_task_id),
+      paths: Array.isArray(row.paths) ? row.paths : [],
+      decidedAt: row.decided_at || null,
+    });
+  }
+  return out;
+}
+
+// countUnattributedConfirmed — how many CONFIRMED removals name no target at all.
+//
+// The number nothing else can tell you, and the reason it is exported rather
+// than left implicit. A confirmed removal with no target rows is invisible to
+// brightness by construction: the work is genuinely gone, and no star dims for
+// it. That happens for proposals filed before lifecycle_010, for attributions
+// where every deletion predates `claims.published_head_sha`, and for a
+// derivation outage.
+//
+// Brightness cannot fix that — it does not know which idea to dim, and guessing
+// is worse than not dimming. What it can do is refuse to let the gap be silent.
+// A surface over the sky (BV2.R17/R18) can say "the sky may read brighter than
+// the truth by up to N confirmed removals", which is an honest caveat, where a
+// silently-optimistic picture is the quiet lie the spec names.
+async function countUnattributedConfirmed({ client = null } = {}) {
+  const q = client || pool;
+  const { rows } = await q.query(
+    `SELECT COUNT(*)::int AS n
+       FROM lifecycle_removal_verdicts v
+      WHERE v.verdict = 'confirmed'
+        AND NOT EXISTS (
+          SELECT 1 FROM lifecycle_removal_targets tg
+           WHERE tg.proposal_task_id = v.proposal_task_id
+        )`
+  );
+  return (rows[0] && rows[0].n) || 0;
+}
+
+module.exports = {
+  recordRemovalTargets,
+  confirmedRemovalsForTasks,
+  countUnattributedConfirmed,
+};

package/modules/lifecycle/routes/lifecycle.js

@@ -29,6 +29,7 @@ const lifecycle = require('../lifecycle');
 const db = require('../db');
 const cascade = require('../cascade');
 const removalDerivation = require('../removal-derivation');
+const removalTargets = require('../removal-targets');
 
 // task 1003549 — the cross-role cascade listener. `task.shipped` already exists
 // as a kernel event (emitted post-commit by the publish reconciler and the ship
@@ -102,6 +103,14 @@ function registerSeams() {
     removalCandidates: (task) => removalDerivation.removalCandidatesForTask(task, {
       shippedTasksByPublishedSha: (shas) => db.shippedTasksByPublishedSha(shas),
     }),
+    // WHOSE WORK IT WAS, stored (task 1004099 / BV2.R16 brightness). The
+    // derivation above already computed the attribution and the proposal body
+    // renders it as prose; this persists the same objects so brightness can
+    // read them structured. Passed as the NAMED function rather than wrapped in
+    // a closure, for the reason the note above gives: a closure here is not
+    // reachable from a test, and that is how the `number`/`pr_number` bug lived
+    // in production with a green suite.
+    recordRemovalTargets: removalTargets.recordRemovalTargets,
     log: api.logger ? api.logger('lifecycle') : null,
   }));
 }

package/modules/lifecycle/routes/removal-proposals.js

@@ -32,9 +32,34 @@
 const express = require('express');
 const api = require('../../../src/module-api');
 const proposals = require('../removal-proposals');
+const removalTargets = require('../removal-targets');
 
 const log = api.logger('lifecycle');
 
+// THE `lifecycle.removals` PORT (task 1004099 / BV2.R16 brightness).
+//
+// Brightness is the live share of an idea's descent, and it lives in the ECONOMY
+// module beside size — because it is a share of the same payouts, and putting it
+// in lifecycle would mean economy asking lifecycle for money arithmetic. That
+// makes "which of these tasks were removed" a cross-module read, and the one-way
+// rule (ADR 0083 rule 1) says it crosses through a kernel-mediated port, never a
+// require. This is the same shape as `ideas.descent`, which economy already
+// resolves for the descent walk itself.
+//
+// REGISTERED HERE, in a route file, because that is where a module's ports are
+// registered (the `ideas.capture` / `lifecycle.kickoffSeed` precedent) — the
+// registration runs when the module mounts, so nothing resolves a port from a
+// module that is switched off.
+//
+// RESOLVED OPTIONALLY on the far side. Economy degrades to "cannot attribute"
+// when lifecycle is absent rather than failing the read, so this is not declared
+// in economy's `consumes` — the same treatment `ideas.descent` gets, and the
+// reason `consumes` there is still `[]`.
+const removalsPort = Object.freeze({
+  confirmedRemovalsForTasks: removalTargets.confirmedRemovalsForTasks,
+  countUnattributedConfirmed: removalTargets.countUnattributedConfirmed,
+});
+
 // The floor: `task.promote` is Metic+ and is the atom the nod already carries,
 // which is what makes 'the same floor as the nod' a fact about the gate rather
 // than a claim in a comment.
@@ -48,6 +73,14 @@ const log = api.logger('lifecycle');
 module.exports = function buildRemovalProposalsRouter() {
   const router = express.Router();
 
+  // Guarded, because the router factory runs again every time a test rebuilds
+  // it and registerProvider THROWS on a duplicate — a port is single-provider by
+  // design. The `lifecycle` port's own registration in routes/lifecycle.js uses
+  // the identical guard for the identical reason.
+  if (!api.hasProvider('lifecycle.removals')) {
+    api.registerProvider('lifecycle.removals', removalsPort);
+  }
+
   // GET /removal-proposals — the removal questions nobody has answered yet.
   //
   // rank: metic+archon (task.promote). No client-side rank gate is needed or wanted in the

package/package-lock.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.921",
+  "version": "1.19.923",
   "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

@@ -30,7 +30,7 @@
 
 const path = require('path');
 const { CONFIG, MANIFEST_VERIFY_INTERVAL_MS, MANIFEST_VERIFY_TRIES, REPO_ROOT } = require('./provision-config.js');
-const { standaloneRoot } = require('./provision-repo.js');
+const { APP_USER, dbName, instanceUser, standaloneRoot } = require('./provision-repo.js');
 const { isValidSlug } = require('../../modules/provisioning/provisioning.js');
 
 // The shapes whose box this runner can actually reach. Mirrors UPGRADE_SHAPES in the
@@ -186,7 +186,31 @@ async function coreUpgradeInstance(inst, deps, intent) {
   // the silent thirteen-release revert upgrade.js's own header records.
   const healthUrl = `http://127.0.0.1:${inst.port}/healthz`;
   const versionUrl = `http://127.0.0.1:${inst.port}/version`;
-  const sudoP = privileged ? 'sudo ' : '';
+  // WHO THE UPGRADE RUNS AS, AND WHICH DATABASE IT NAMES (task 1004119).
+  //
+  // A bare `sudo` runs as ROOT, and both halves of the upgrade resolve against the
+  // CURRENT OS USER rather than a flag:
+  //
+  //   • migrate.sh peer-auths over the local socket as whoever invoked it, and `root`
+  //     is almost never a Postgres role — pre-flight refuses with "Postgres has no
+  //     role root" before the pin moves (correctly; the pin must not move for a
+  //     migrate that cannot run).
+  //   • with no PGDATABASE, resolveInstanceDb() has to FIND the database by loading
+  //     node_modules/@bongos/core/src/bongos/pool from the instance root. An adopted
+  //     repo that installs its workspaces rather than its root has no core there, so
+  //     the name cannot be resolved at all.
+  //
+  // Both were live on 2026-09-20: four presses of the owner's Upgrade button, four
+  // pre-flight refusals, no instance ever moved. The helpers to fix it already sat in
+  // provision-repo.js — this leg simply never used them.
+  //
+  // The account is the instance's own (`bongos-<slug>`), which is ALSO the name of its
+  // Postgres login role (instanceDbRole), so peer auth lands on a role that owns
+  // exactly that instance's database. The control plane is the exception: it is not a
+  // provisioned tenant and has no `bongos-` account — it runs as APP_USER, the operator
+  // the recipe's gate-3 invocation names.
+  const runAs = inst.hosting_shape === 'control-plane' ? APP_USER : instanceUser(inst);
+  const sudoP = privileged ? `sudo -u ${runAs} env PGDATABASE=${dbName(inst)} ` : '';
   // WHERE THE CLI LIVES AND WHERE THE TARGET LIVES ARE DIFFERENT PLACES (task 1004053).
   //
   // `scripts/gds/upgrade.js` ships in the CORE checkout. A provisioned instance root holds

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.921'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.923'; // 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/core_upgrade_runner.mjs

@@ -415,5 +415,61 @@ await t('the snapshot NEVER fails a tick — a registry hiccup leaves the old re
   assert.equal(r.skipped, true);
 });
 
+console.log('\nWHO the upgrade runs as, and WHICH database it names (task 1004119):');
+
+// The bug: `sudo ` with no -u, and no PGDATABASE. Both halves of upgrade.js resolve
+// against the CURRENT OS USER rather than a flag, so root got a "Postgres has no role
+// root" refusal and an adopted repo could not resolve its database name at all. Four
+// live presses on 2026-09-20, four pre-flight refusals, nothing ever upgraded.
+//
+// Asserting on the ASSEMBLED command rather than on the helpers, because the helpers
+// were already correct and already exported — the defect was that this leg did not
+// call them.
+
+const upgradeCall = (d) => (d.ranWith.find((c) => /upgrade\.js/.test(c.cmd)) || {}).cmd || '';
+
+await t('the control plane upgrades as the operator account, never as root', async () => {
+  const d = { ...makeDeps({ served: '1.19.762' }), privileged: true };
+  await R.coreUpgradeInstance(inst({ hosting_shape: 'control-plane', slug: 'cloudbongos', port: 3002 }), d, intent());
+  const cmd = upgradeCall(d);
+  assert.match(cmd, /sudo -u lars /, 'runs as the operator account');
+  assert.doesNotMatch(cmd, /sudo node /, 'a bare `sudo node` is the bug — it lands on root');
+});
+
+await t('a tenant upgrades as its OWN account, which is also its Postgres login role', async () => {
+  const d = { ...makeDeps({ served: '1.19.762' }), privileged: true };
+  await R.coreUpgradeInstance(inst({ hosting_shape: 'standalone', slug: 'test4', port: 3006 }), d, intent());
+  const cmd = upgradeCall(d);
+  assert.match(cmd, /sudo -u bongos-test4 /, 'the instance account, not the operator and not root');
+  assert.doesNotMatch(cmd, /sudo -u lars /, 'one tenant must never be upgraded under another account');
+});
+
+await t('the database is NAMED, not discovered — an adopted repo has no core at its root to ask', async () => {
+  // hermeslines-marketing installs its workspaces rather than its root, so
+  // resolveInstanceDb() could not load node_modules/@bongos/core/.../pool and the
+  // upgrade died with "cannot determine which database to migrate".
+  const d = { ...makeDeps({ served: '1.19.762' }), privileged: true };
+  await R.coreUpgradeInstance(
+    inst({ hosting_shape: 'standalone', slug: 'hermeslines-marketing', db_name: 'hermeslines-marketing', port: 3011 }), d, intent());
+  assert.match(upgradeCall(d), /env PGDATABASE=hermeslines-marketing /, 'the runner passes the name the control plane already holds');
+});
+
+await t('the database name comes from the ROW, falling back to the slug', async () => {
+  const d = { ...makeDeps({ served: '1.19.762' }), privileged: true };
+  await R.coreUpgradeInstance(inst({ hosting_shape: 'control-plane', slug: 'cloudbongos', db_name: null, port: 3002 }), d, intent());
+  assert.match(upgradeCall(d), /env PGDATABASE=cloudbongos /, 'a row with no db_name uses its slug');
+});
+
+await t('an UNPRIVILEGED runner still adds no sudo and no env at all', async () => {
+  // The self-hosted / dev shape: already the right user, nothing to escalate. Guarding
+  // it so the fix above cannot quietly start requiring sudo where there is none.
+  const d = makeDeps({ served: '1.19.762' });
+  d.privileged = false;
+  await R.coreUpgradeInstance(inst({ hosting_shape: 'standalone', slug: 'test4', port: 3006 }), d, intent());
+  const cmd = upgradeCall(d);
+  assert.doesNotMatch(cmd, /sudo/, 'no escalation when the runner is not privileged');
+  assert.match(cmd, /^node \S*scripts\/gds\/upgrade\.js /, 'it still invokes the CLI directly');
+});
+
 console.log(`\ncore_upgrade_runner: ${passed} passed, ${failed} failed`);
 if (failed) process.exit(1);