@bongos/core 1.19.921 → 1.19.922

package/modules/economy/idea-size-historical.js

@@ -56,7 +56,11 @@ const {
 //   decay       — the resolved per-instance dial (reward-policy ideaDescentDecay)
 //   paidByTask  — Map<taskIdString, creditsPaid> from credit_log, per task
 //
-// Returns { paid, estimated, payments, estimatedPayments }.
+// Returns { paid, estimated, payments, estimatedPayments, byTask }, where
+// `byTask` is Map<taskIdString, credits> — the per-hop breakdown brightness
+// weights a descent by (task 1004099 / BV2.R16). The early return on an
+// unusable decay yields an EMPTY map rather than no map, so a caller never has
+// to test for its absence.
 //
 // ONLY A SHIPPED TASK COUNTS. The payout fires at ship, so a ready or abandoned
 // descendant has earned its origin nothing and estimating for it would credit
@@ -75,7 +79,19 @@ const {
 // what the same descent would have been paid hop by hop, which is the whole
 // thing this function exists to reproduce.
 function priceDescentForIdea({ tasks, grade, completeness, decay, paidByTask } = {}) {
-  const out = { paid: 0, estimated: 0, payments: 0, estimatedPayments: 0 };
+  // `byTask` — the same arithmetic, kept per task instead of only summed
+  // (task 1004099 / BV2.R16). Brightness is the LIVE SHARE of a size, so it has
+  // to weight each descent task by what that task contributed, and the totals
+  // alone cannot be taken apart again afterwards. Added here rather than
+  // recomputed in brightness because a second copy of this loop is a second
+  // answer to "what is this hop worth", and the two would drift the first time
+  // a decay dial or a grade factor moved.
+  //
+  // Map<taskIdString, credits>, carrying BOTH kinds — a paid hop at its ledger
+  // figure and an estimated hop at its priced one. Brightness must use the same
+  // basis as size or the share would be a fraction of a different number than
+  // the one drawn beside it.
+  const out = { paid: 0, estimated: 0, payments: 0, estimatedPayments: 0, byTask: new Map() };
   const list = Array.isArray(tasks) ? tasks : [];
   const paidMap = paidByTask instanceof Map ? paidByTask : new Map();
 
@@ -98,8 +114,10 @@ function priceDescentForIdea({ tasks, grade, completeness, decay, paidByTask } =
     seen.add(key);
 
     if (paidMap.has(key)) {
-      out.paid += Number(paidMap.get(key)) || 0;
+      const banked = Number(paidMap.get(key)) || 0;
+      out.paid += banked;
       out.payments += 1;
+      out.byTask.set(key, banked);
       continue;
     }
 
@@ -113,6 +131,7 @@ function priceDescentForIdea({ tasks, grade, completeness, decay, paidByTask } =
     if (delta <= 0) continue;
     out.estimated += delta;
     out.estimatedPayments += 1;
+    out.byTask.set(key, delta);
   }
   return out;
 }

package/modules/economy/idea-size.js

@@ -152,7 +152,9 @@ function idOf(v) {
 // row is stream 2 — the thought, not the work it caused.
 //
 // Returns Map<ideaIdString, { credits, paid, estimated, payments, scale,
-// historical }>. Every id asked for is present, at zero when it has been paid
+// historical, byTask }>, where `byTask` is Map<taskIdString, credits> summing to
+// `credits` — the per-hop breakdown brightness (./idea-brightness.js, BV2.R16)
+// takes its live share of. Every id asked for is present, at zero when it has been paid
 // nothing: absent and zero are different answers to a renderer, and an idea that
 // caused nothing yet is a real state the surface has to draw, not a gap.
 //
@@ -184,7 +186,10 @@ async function ideaSizes(ideaIds, { client = null, descentByIdea = null } = {})
   const ids = [...new Set((Array.isArray(ideaIds) ? ideaIds : []).map(idOf).filter(Boolean))];
   const out = new Map();
   for (const id of ids) {
-    out.set(id, { credits: 0, paid: 0, estimated: 0, payments: 0, scale: 0, historical: false });
+    // `byTask` empty rather than absent: an idea with no payouts has a real,
+    // established breakdown (nothing), and a caller should not have to tell
+    // that apart from a field that was never filled in.
+    out.set(id, { credits: 0, paid: 0, estimated: 0, payments: 0, scale: 0, historical: false, byTask: new Map() });
   }
   if (ids.length === 0) return out;
 
@@ -235,6 +240,11 @@ async function ideaSizes(ideaIds, { client = null, descentByIdea = null } = {})
       out.set(id, {
         credits: acc.total, paid: acc.total, estimated: null,
         payments: acc.payments, scale: compressIdeaSize(acc.total), historical: null,
+        // The ledger's own per-task figures are still true even with no descent
+        // in hand, and they sum to `credits` here because `credits` IS the
+        // ledger total on this branch. Brightness can therefore still take a
+        // share; it simply cannot see hops that were never paid for.
+        byTask: acc.byTask,
       });
       continue;
     }
@@ -251,6 +261,22 @@ async function ideaSizes(ideaIds, { client = null, descentByIdea = null } = {})
     // edge) is still money this idea was paid, and dropping it would make size
     // fall.
     const credits = acc.total + priced.estimated;
+    // THE PER-TASK BREAKDOWN, for brightness (task 1004099 / BV2.R16), and it
+    // has to SUM TO `credits` or the share taken of it is a fraction of the
+    // wrong number. Two sources, in this order:
+    //
+    //   • `priced.byTask` — every hop the descent reaches, at its ledger figure
+    //     where one was paid and at its priced figure where it was estimated.
+    //   • then any ledger payment for a task the descent NO LONGER REACHES — a
+    //     re-parented task, a deleted edge. Those are in `acc.total` (kept there
+    //     on purpose, a few lines up, so size cannot fall), so leaving them out
+    //     here would make the parts sum to less than the whole and quietly
+    //     overstate brightness. `priced.byTask` wins on a collision because a
+    //     paid hop carries the same banked figure in both.
+    const byTask = new Map(priced.byTask);
+    for (const [taskId, paid] of acc.byTask) {
+      if (!byTask.has(taskId)) byTask.set(taskId, paid);
+    }
     out.set(id, {
       credits,
       paid: acc.total,
@@ -258,6 +284,7 @@ async function ideaSizes(ideaIds, { client = null, descentByIdea = null } = {})
       payments: acc.payments + priced.estimatedPayments,
       scale: compressIdeaSize(credits),
       historical: priced.estimated > 0,
+      byTask,
     });
   }
   return out;
@@ -367,7 +394,7 @@ async function walkDescentForIdeas(ids, { client }) {
 // shape a single-idea panel wants.
 async function ideaSize(ideaId, opts = {}) {
   const key = idOf(ideaId);
-  const zero = { credits: 0, payments: 0, scale: 0 };
+  const zero = { credits: 0, payments: 0, scale: 0, byTask: new Map() };
   if (!key) return zero;
   const sizes = await ideaSizes([key], opts);
   return sizes.get(key) || zero;

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.922",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.921",
+      "version": "1.19.922",
       "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.922",
   "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