@bongos/core 1.19.316 → 1.19.318

package/modules/lifecycle/db-claim-reads.js

@@ -0,0 +1,165 @@
+// modules/lifecycle/db-claim-reads.js — read-only claim + grade lookups (no state transitions).
+//
+// Carved out of modules/lifecycle/db.js by task 1003204 (goal 1000079, the R03
+// de-monolith plan) — a STRUCTURAL move, not a rewrite: the code below is the
+// original db.js lines 4774-4915 unchanged. db.js remains the facade that
+// re-exports every name, so every existing db call site is unchanged.
+//
+// THE BOUNDARY (ADR 0093 §1): this file reaches core ONLY through the published
+// doorway ../../src/module-api.js — never a core internal, never a sibling module.
+
+'use strict';
+
+const api = require('../../src/module-api');
+const { pool } = api;
+
+async function getActiveClaimsForBuilder(builderId) {
+  // release_requested_* (task 1736): a goal owner/manager's flag-for-release
+  // nudge rides on the holder's own claim read so /me (and the surfaces built
+  // on it) can show "someone asked you to wrap this up".
+  const { rows } = await pool.query(
+    `SELECT c.id AS claim_id, c.task_id, c.worktree_name, c.claimed_at,
+            c.head_sha, c.reserved_migration_number,
+            c.release_requested_by, c.release_requested_at, c.release_requested_note,
+            t.title, t.touches, t.priority, t.credits_reward, t.version_id, t.module_key
+       FROM claims c JOIN tasks t ON t.id = c.task_id
+      WHERE c.builder_id = $1 AND c.released_at IS NULL
+      ORDER BY c.claimed_at`,
+    [builderId]
+  );
+  return rows;
+}
+
+// Task-scoped dev box (goal 1000051 / R92, ADR 0148 §2). The set-union of the
+// module KEYS a builder's active claims put in scope: each active claim's task →
+// its goal → goal.scope_modules (the ADR 0086 scope wall), unioned + deduped
+// across all the builder's active claims. This is the "what code does this
+// builder's current work need" signal the dev-box source-access resolver
+// (modules/dev-box/box-access.js, wired in R93/R94) maps to git sparse-checkout
+// globs via the doorway `moduleScopeMap`. Returns [] when the builder holds no
+// active claim, or when every claimed task carries no goal / an empty
+// scope_modules — the box then falls back to BASE-only (the pre-existing Bongos
+// instance). KEYS only; glob resolution is the box module's job (it reaches
+// moduleScopeMap through the doorway, never a core-internal require — the
+// R90/ADR-0148 boundary). Honours the #538 deps.pool test seam
+// (NODE_ENV==='test' only), like the goals reads above.
+async function moduleScopeForActiveClaims(builderId, deps = {}) {
+  const activePool = (deps.pool && process.env.NODE_ENV === 'test') ? deps.pool : pool;
+  const id = Number(builderId);
+  if (!Number.isInteger(id)) {
+    throw new Error('moduleScopeForActiveClaims: builderId must be numeric');
+  }
+  const { rows } = await activePool.query(
+    `SELECT DISTINCT m AS module_key
+       FROM claims c
+       JOIN tasks t ON t.id = c.task_id
+       JOIN goals g ON g.id = t.goal_id
+       CROSS JOIN LATERAL unnest(g.scope_modules) AS m
+      WHERE c.builder_id = $1 AND c.released_at IS NULL
+      ORDER BY m`,
+    [id]
+  );
+  return rows.map((r) => r.module_key);
+}
+
+// Task 1002729 — the companion signal moduleScopeForActiveClaims cannot carry.
+// That query INNER JOINs goals and unnests scope_modules, so it returns [] for
+// BOTH "this builder holds no claim" and "this builder holds claims whose goals
+// declare no scope_modules". Those must not be treated alike: the first is a
+// genuinely unscoped box (BASE-only is right), the second is a builder actively
+// working who would be handed a box with no modules/ at all. Live evidence for
+// why this matters: 247 of 248 source grants on the cloudbongos fleet resolved to
+// BASE, including an Archon holding 7 active claims — every one of those claims
+// sat on a goal with scope_modules = {}. Counts CLAIMS, deliberately not joining
+// goals, so it stays true regardless of how the goal wall is (or isn't) declared.
+async function activeClaimCountForBuilder(builderId, deps = {}) {
+  const activePool = (deps.pool && process.env.NODE_ENV === 'test') ? deps.pool : pool;
+  const id = Number(builderId);
+  if (!Number.isInteger(id)) {
+    throw new Error('activeClaimCountForBuilder: builderId must be numeric');
+  }
+  const { rows } = await activePool.query(
+    `SELECT count(*)::int AS n FROM claims WHERE builder_id = $1 AND released_at IS NULL`,
+    [id]
+  );
+  return rows.length ? Number(rows[0].n) : 0;
+}
+
+// task 1642 — every active claim bound to a given CLI session. "Active" is the
+// claims-table convention (released_at IS NULL); there is NO `status` column on
+// claims (a common misread — the task's status lives on `tasks`). Keyed on
+// creator_session_id (the auth-token session shared across a builder's worktrees),
+// NOT builder_id. This backs the one-active-claim guard (shouldRefuseSessionClaim),
+// which further discriminates by `worktree_name` — the real commingle boundary —
+// so two claims can coexist for one auth session as long as they land in different
+// worktrees. NULL-session callers must never reach this — they are session-UNBOUND
+// web claims (bind_session=false) that any CLI session may adopt; the route
+// short-circuits before calling here.
+async function getActiveClaimsForSession(creatorSessionId) {
+  if (!creatorSessionId) return [];
+  const { rows } = await pool.query(
+    // task 1002709: requested_worktree_name rides along because the guard keys on
+    // it — comparing the incoming REQUESTED name against a stored DISAMBIGUATED
+    // one is what let a second same-tree claim through. worktree_name stays
+    // selected: callers still render the on-disk name.
+    `SELECT c.id AS claim_id, c.task_id, c.creator_session_id, c.worktree_name,
+            c.requested_worktree_name, c.claimed_at,
+            t.title
+       FROM claims c JOIN tasks t ON t.id = c.task_id
+      WHERE c.creator_session_id = $1 AND c.released_at IS NULL
+      ORDER BY c.claimed_at`,
+    [creatorSessionId]
+  );
+  return rows;
+}
+
+// The builder who most recently held a claim on this task — active OR resolved.
+// Used by the `--regrade` ownership guard (#678): when a ship lands at
+// `completed` but the subagent grader fails, the claim is already consumed, so
+// the only record of "whose work this is" lives in the claims ledger. Returns
+// the latest claim row by claim time (id is the tiebreak, monotonic), joined to
+// the builder for github_login, plus the claim's head_sha (the grader's
+// last-resort baseline), or null if the task was never claimed. Deliberately
+// does NOT return the holder's rank — the regrade gate keys off the CALLER's
+// rank (from /me), and rank is sensitive metadata not previously on this read
+// surface (grader hacker finding, #678). Pure read, builder-agnostic.
+
+async function getLastClaimHolder(taskId) {
+  const { rows } = await pool.query(
+    `SELECT c.builder_id, c.head_sha, c.released_at, c.outcome, c.claimed_at,
+            b.github_login
+       FROM claims c
+       JOIN builders b ON b.id = c.builder_id
+      WHERE c.task_id = $1
+      ORDER BY c.claimed_at DESC, c.id DESC
+      LIMIT 1`,
+    [taskId]
+  );
+  return rows[0] ?? null;
+}
+
+// getTaskGrade — fetch the current grade row for a task (V4.R08 diff-hash
+// reuse). Returns { diff_hash, passed, score, threshold, grader_kind,
+// grader_version, rubric_scores, signals, notes_md } or null when no grade
+// exists yet. Used by ship.js before the grade step to detect "same diff →
+// skip the panel".
+async function getTaskGrade(taskId) {
+  const { rows } = await pool.query(
+    `SELECT diff_hash, passed, score, threshold, grader_kind, grader_version,
+            rubric_scores, signals, notes_md
+       FROM task_grades
+      WHERE task_id = $1
+      LIMIT 1`,
+    [taskId]
+  );
+  return rows[0] ?? null;
+}
+
+module.exports = {
+  activeClaimCountForBuilder,
+  getActiveClaimsForBuilder,
+  getActiveClaimsForSession,
+  getLastClaimHolder,
+  getTaskGrade,
+  moduleScopeForActiveClaims,
+};