@nanobpm/nano-workforce 0.131.1 → 0.132.0

package/CHANGELOG.md

@@ -1,3 +1,9 @@
+## [0.132.0](https://github.com/nanobpm/nano-workforce/compare/v0.131.1...v0.132.0) (2026-08-24)
+
+### Features
+
+* **lineage:** surface delivery-graph runs as fan-in parent threads ([#504](https://github.com/nanobpm/nano-workforce/issues/504)) ([c62b925](https://github.com/nanobpm/nano-workforce/commit/c62b92556dd8ec21f42bc70ca4eba5455e448343)), closes [#498](https://github.com/nanobpm/nano-workforce/issues/498) [#498](https://github.com/nanobpm/nano-workforce/issues/498)
+
 ## [0.131.1](https://github.com/nanobpm/nano-workforce/compare/v0.131.0...v0.131.1) (2026-08-24)
 
 ### Bug Fixes

package/app/lineage.test.ts

@@ -131,6 +131,91 @@ test("feature/self-rooted threads carry no epic phase label", () => {
   assertEquals(self.epicPhaseLabel, null, "a self-rooted PR is not an epic slice");
 });
 
+// ── delivery-graph fan-in parent (issue #498) ─────────────────────────────────────────────────
+
+test("delivery: a running run with no PR yet is implementing, frontier from its phase", () => {
+  const t = deriveLineage(
+    { kind: "delivery", key: "dg-abc", title: "Ship widget", status: "running", phase: "Running", processKey: "d1" },
+    [],
+  );
+  assertEquals(t.kind, "delivery");
+  assertEquals(t.rootRequestKey, "dg-abc");
+  assertEquals(t.stage, "implementing");
+  assertEquals(t.stageLabel, "Running", "the frontier reflects the run's derived phase");
+  assert(t.active, "a running run is active");
+  assertEquals(t.processKey, "d1");
+  assertEquals(t.title, "Ship widget");
+  assertEquals(t.issueUrl, null, "a delivery run is keyed by run_key, not a GitHub issue");
+  assertEquals(t.epicPhaseLabel, null, "a delivery run's member PRs are not epic slices");
+  assertEquals(t.prCount, 0);
+});
+
+test("delivery: downstream PR convergences nest under the run and temper the frontier to converging", () => {
+  const t = deriveLineage(
+    { kind: "delivery", key: "dg-abc", title: "Ship widget", status: "running", phase: "Parked on human node: publish", processKey: "d1" },
+    [
+      pr({ prKey: "a/b#1", status: "merged" }),
+      pr({ prKey: "c/d#9", status: "converging", processKey: "c9" }),
+    ],
+  );
+  assertEquals(t.kind, "delivery");
+  assertEquals(t.stage, "converging", "a member PR still in flight tempers the frontier to converging");
+  assertEquals(t.stageLabel, "Parked on human node: publish", "the label still prefers the run's stamped phase");
+  assertEquals(t.processKey, "c9", "frontier prefers the in-flight member PR's instance");
+  assertEquals(t.prKeys, ["a/b#1", "c/d#9"], "heterogeneous downstream PRs across repos nest under the run");
+  assert(t.active);
+});
+
+test("delivery: a done run settles as resolved (no active frontier)", () => {
+  const t = deriveLineage(
+    { kind: "delivery", key: "dg-abc", title: "Ship widget", status: "done", phase: "Completed", processKey: "d1" },
+    [pr({ prKey: "a/b#1", status: "merged" })],
+  );
+  assertEquals(t.stage, "resolved");
+  assertEquals(t.stageLabel, "Completed");
+  assert(!t.active, "a completed run has no active frontier");
+});
+
+test("delivery: a failed run settles as abandoned", () => {
+  const t = deriveLineage(
+    { kind: "delivery", key: "dg-abc", title: "Ship widget", status: "failed", phase: "Failed", processKey: "d1" },
+    [],
+  );
+  assertEquals(t.stage, "abandoned");
+  assert(!t.active);
+});
+
+test("delivery: an abandoned run with no phase is labeled 'Abandoned', not 'Failed'", () => {
+  // `deliveryOriginStage` folds both `failed` and `abandoned` statuses onto the `abandoned` stage, so
+  // the label must consult the run status: a genuinely abandoned run reads "Abandoned" (only a failed
+  // one reads "Failed"). Regress with no stamped phase so the status-derived fallback label is used.
+  const t = deriveLineage(
+    { kind: "delivery", key: "dg-abc", title: "Ship widget", status: "abandoned", phase: null, processKey: "d1" },
+    [],
+  );
+  assertEquals(t.stage, "abandoned");
+  assertEquals(t.stageLabel, "Abandoned", "an abandoned run is not mislabeled as failed");
+  assert(!t.active);
+});
+
+test("delivery: a failed run with no phase is labeled 'Failed'", () => {
+  const t = deriveLineage(
+    { kind: "delivery", key: "dg-abc", title: "Ship widget", status: "failed", phase: null, processKey: "d1" },
+    [],
+  );
+  assertEquals(t.stage, "abandoned");
+  assertEquals(t.stageLabel, "Failed");
+});
+
+test("delivery: with no stamped phase, the frontier falls back to a status-derived label", () => {
+  const t = deriveLineage(
+    { kind: "delivery", key: "dg-abc", title: "Ship widget", status: "running", phase: null, processKey: "d1" },
+    [],
+  );
+  assertEquals(t.stage, "implementing");
+  assertEquals(t.stageLabel, "Running", "null phase falls back to the status-derived frontier label");
+});
+
 // ── self-rooted (human/webhook) PR ───────────────────────────────────────────────────────────
 
 test("pr: a human/webhook PR with no origin is its own root", () => {
@@ -237,6 +322,67 @@ test("pollLineage: projects feature, epic, and self-rooted threads onto lineage_
   assertEquals(after, before, "steady-state pass is a no-op");
 });
 
+test("pollLineage: projects a delivery-graph run as a fan-in parent thread with its downstream PRs nested", async () => {
+  // Issue #498: a dispatched delivery-graph run appears as its own thread, and the downstream PR
+  // convergences threaded to it (root_request_key = run_key) across DIFFERENT repos nest under it
+  // rather than appearing as disconnected self-rooted PRs.
+  const { data, stores } = memData();
+  stores.feature_runs = [];
+  stores.plans = [];
+  stores.plan_tasks = [];
+  stores.delivery_graph_runs = [
+    { run_key: "dg-xyz", title: "Ship widget across repos", status: "running", phase: "Running", process_key: "P-dg" },
+  ];
+  stores.pull_requests = [
+    { pr_key: "a/b#1", title: "widget in a/b", url: "x", status: "merged", current_round: 1, process_key: "c1", outcome: null, root_request_key: "dg-xyz" },
+    { pr_key: "c/d#9", title: "widget in c/d", url: "x", status: "converging", current_round: 2, process_key: "c2", outcome: null, root_request_key: "dg-xyz" },
+  ];
+
+  await pollLineage(data);
+
+  const threads: LineageThreadRow[] = stores.lineage_threads;
+  assertEquals(threads.length, 1, "one delivery thread, not two disconnected self-rooted PRs");
+  const dg = threads.find((t) => t.root_request_key === "dg-xyz");
+  assert(dg, "delivery thread present, keyed on run_key");
+  // A member PR still converging tempers the frontier to converging; the label prefers the run phase.
+  assertEquals(dg?.stage, "converging");
+  assertEquals(dg?.stage_label, "Running");
+  assertEquals(dg?.active, 1);
+  assertEquals(dg?.pr_count, 2);
+  assertEquals(JSON.parse(dg?.pr_keys ?? "[]").sort(), ["a/b#1", "c/d#9"]);
+  // A delivery run's member PRs are not epic slices, so no epic phase label is projected onto them.
+  const prById = (k: string) => stores.pull_requests.find((r: any) => r.pr_key === k);
+  assertEquals(prById("a/b#1").epic_phase_label ?? null, null);
+  assertEquals(prById("c/d#9").epic_phase_label ?? null, null);
+});
+
+test("pollLineage: a delivery run_key colliding with a feature key does not overwrite the feature thread", async () => {
+  // The SQL view (migration 079) classifies epic > feature > delivery, so a `delivery_graph_runs.run_key`
+  // that equals an existing `feature_key`/`plan_key` must NOT clobber that earlier thread — otherwise the
+  // poller would stamp delivery-derived frontier columns onto a row the view still classifies feature/epic,
+  // and the two projections drift. The colliding run is skipped; feature precedence is preserved.
+  const { data, stores } = memData();
+  stores.feature_runs = [
+    { feature_key: "o/r#7", title: "Feature seven", issue_url: "u7", status: "converging", process_key: "f7", pr_key: "o/r#700" },
+  ];
+  stores.plans = [];
+  stores.plan_tasks = [];
+  stores.delivery_graph_runs = [
+    { run_key: "o/r#7", title: "Colliding run", status: "running", phase: "Running", process_key: "P-dup" },
+  ];
+  stores.pull_requests = [
+    { pr_key: "o/r#700", title: "Feat PR", url: "x", status: "converging", current_round: 2, process_key: "c1", outcome: null, root_request_key: "o/r#7" },
+  ];
+
+  await pollLineage(data);
+
+  const threads: LineageThreadRow[] = stores.lineage_threads;
+  assertEquals(threads.length, 1, "the colliding run does not create a second row for the same key");
+  const t = threads.find((r) => r.root_request_key === "o/r#7");
+  assert(t, "the single thread for the shared key is the feature thread");
+  assertEquals(t?.stage_label, "Converging (round 2)", "feature frontier wins; the delivery run did not overwrite it");
+});
+
 test("pollLineage: a self-rooted PR row (root_request_key === pr_key) projects exactly one thread keyed on its pr_key", async () => {
   // Regression (#245): submitPr now self-roots a human/webhook PR on its own `pr_key` (rather than
   // NULL) so the Lineage page's `lineage_threads.root_request_key → pull_requests.root_request_key`

package/app/lineage.ts

@@ -20,14 +20,15 @@
 // `pr_key` (kind `pr`), and also tolerates a legacy NULL `root_request_key` the same way.
 import type { DataLayer } from "@nanobpm/urban";
 import { deriveDelivery, TERMINAL_STATUSES } from "./delivery.ts";
+import { type DeliveryGraphRun, deliveryGraphRuns } from "./deliveryGraphRun.ts";
 import { type FeatureRun, featureRuns } from "./feature.ts";
 import { derivedTrackingTable } from "./instanceTracking.ts";
 import { type Plan, type PlanTask, plans, planTasks } from "./plan.ts";
 
 const now = () => new Date().toISOString();
 
-/** The three origin shapes a lineage arc can spring from. */
-export type LineageKind = "feature" | "epic" | "pr";
+/** The origin shapes a lineage arc can spring from. */
+export type LineageKind = "feature" | "epic" | "pr" | "delivery";
 
 /** A member PR of a lineage thread — the subset of `pull_requests` the projection reads. */
 export interface LineagePr {
@@ -66,6 +67,23 @@ export type LineageOrigin =
       // A human/webhook PR with no originating request: its own root.
       kind: "pr";
       key: string;
+    }
+  | {
+      // A delivery-graph run (issue #498): a FAN-IN parent thread. The run is the thread root, and
+      // the heterogeneous downstream tasks it spawns — PR convergences across different repos/issue
+      // numbers, package publishes, human gates — nest under it (they thread `root_request_key =
+      // run_key`, mirroring how `submitPr` threads feature/epic roots). Closer to an epic than a
+      // single-PR arc.
+      kind: "delivery";
+      key: string;
+      title: string | null;
+      status: string;
+      // The run's already-derived display phase (`delivery_graph_runs.phase`, recomputed by
+      // `pollDeliveryGraphPhase` from engine truth — generalised from `epic_phase`), e.g. "Running",
+      // "Parked on human node: manual OTP publish", "Completed". NULL until the poller stamps one; the
+      // thread then falls back to a status-derived frontier label.
+      phase: string | null;
+      processKey: string | null;
     };
 
 /** One stitched arc: `request → implementation → PR(s) → convergence → merge → outcome`. */
@@ -241,6 +259,18 @@ export function deriveLineage(origin: LineageOrigin, prsIn: readonly LineagePr[]
       stageLabel = featureStageLabel(stage);
       processKey = origin.processKey ?? rep?.processKey ?? null;
     }
+  } else if (origin.kind === "delivery") {
+    // Fan-in parent (issue #498): the delivery-graph RUN is the thread root; its heterogeneous
+    // downstream PR convergences (across different repos/issues) nest under it. Unlike an epic's
+    // slice rollup, a run's narrative is "where is the run" — so the frontier reflects the run's OWN
+    // derived phase (`delivery_graph_runs.phase`), with member PRs shown as nested children. The
+    // machine `stage` is derived from the run status (tempered to `converging` while a member PR is
+    // still in flight); the human `stageLabel` prefers the run's stamped phase, else a status label.
+    stage = deliveryOriginStage(origin.status, prs);
+    stageLabel = origin.phase ?? deliveryStageLabel(stage, origin.status);
+    // Active-frontier instance: an in-flight member PR's process, else the run's own.
+    const activePr = prs.find((p) => !TERMINAL_STATUSES.includes(p.status));
+    processKey = activePr?.processKey ?? origin.processKey ?? rep?.processKey ?? null;
   } else {
     // Self-rooted PR (human/webhook): the PR IS the whole arc.
     stage = rep ? prStage(rep.status) : "converging";
@@ -259,7 +289,9 @@ export function deriveLineage(origin: LineageOrigin, prsIn: readonly LineagePr[]
     rootRequestKey: origin.key,
     kind: origin.kind,
     title: origin.kind === "pr" ? (rep?.title ?? null) : origin.title,
-    issueUrl: origin.kind === "pr" ? null : origin.issueUrl,
+    // Only feature/epic threads root on a GitHub issue; a self-rooted PR and a delivery-graph run
+    // (issue #498, keyed by `run_key`) have none.
+    issueUrl: origin.kind === "feature" || origin.kind === "epic" ? origin.issueUrl : null,
     stage,
     stageLabel,
     epicPhaseLabel,
@@ -293,6 +325,45 @@ function featureStageLabel(stage: LineageStage): string {
   }
 }
 
+/** Map a delivery-graph run's lifecycle status onto a frontier stage (issue #498). A `running` run
+ * with a member PR still in flight reads as `converging` (the fan-in is landing PRs); otherwise it is
+ * `implementing`. Terminal run statuses settle: `done` → `resolved` (the run completed), `failed` /
+ * `abandoned` → `abandoned`. `awaiting-approval` (reserved, no longer produced) parks at `planning`. */
+function deliveryOriginStage(status: string, prs: readonly LineagePr[]): LineageStage {
+  switch (status) {
+    case "awaiting-approval":
+      return "planning";
+    case "running":
+      return prs.some((p) => !TERMINAL_STATUSES.includes(p.status)) ? "converging" : "implementing";
+    case "done":
+      return "resolved";
+    case "failed":
+    case "abandoned":
+      return "abandoned";
+    default:
+      return "implementing";
+  }
+}
+
+/** The fallback frontier label for a delivery thread when the run has not stamped a `phase` yet.
+ * `deliveryOriginStage` folds both the `failed` and `abandoned` run statuses onto the terminal
+ * `abandoned` stage, so the stage alone cannot tell them apart — take the run `status` too and label a
+ * genuinely `abandoned` run "Abandoned" (only a `failed` run reads "Failed"). */
+function deliveryStageLabel(stage: LineageStage, status: string): string {
+  switch (stage) {
+    case "planning":
+      return "Awaiting approval";
+    case "converging":
+      return "Converging";
+    case "resolved":
+      return "Completed";
+    case "abandoned":
+      return status === "abandoned" ? "Abandoned" : "Failed";
+    default:
+      return "Running";
+  }
+}
+
 // ── gateway glue ───────────────────────────────────────────────────────────────────────────────
 
 /** The subset of `pull_requests` the lineage projection reads. */
@@ -450,6 +521,21 @@ async function collectThreads(
     threads.set(plan.plan_key, deriveLineage(epicOrigin(plan), prs.map(toLineagePr)));
   }
 
+  // Delivery-graph runs (issue #498): each run is a fan-in parent thread keyed on its `run_key`,
+  // attaching the downstream PRs threaded to it (`pull_requests.root_request_key = run_key`). Mirrors
+  // the feature/epic loops — a run with no PR landed yet still projects a thread (its derived phase).
+  const deliveryRows = await deliveryGraphRuns(data).all();
+  for (const run of deliveryRows) {
+    // Feature/epic precedence: the SQL view's CASE classifies epic > feature > delivery, so a
+    // `run_key` that collides with an existing `plan_key`/`feature_key` must NOT overwrite that
+    // thread — otherwise the poller projection would stamp delivery-derived frontier columns onto a
+    // row the view still classifies epic/feature, and the two drift. Skip the colliding run so the
+    // earlier feature/epic thread (and the view's precedence) stays intact.
+    if (threads.has(run.run_key)) continue;
+    const prs = collectRootPrs(run.run_key, null, prsByRoot, prByKey, claimed);
+    threads.set(run.run_key, deriveLineage(deliveryGraphOrigin(run), prs.map(toLineagePr)));
+  }
+
   // Any PR not claimed by a feature/epic root is its own root: a human/webhook PR, a legacy row
   // predating migration 037's backfill, or a `root_request_key` whose origin row no longer survives.
   // Key each such thread by the root STORED on the PR row (`root_request_key`, falling back to
@@ -532,6 +618,17 @@ function epicOrigin(plan: Plan): LineageOrigin {
   };
 }
 
+function deliveryGraphOrigin(run: DeliveryGraphRun): LineageOrigin {
+  return {
+    kind: "delivery",
+    key: run.run_key,
+    title: run.title,
+    status: run.status,
+    phase: run.phase,
+    processKey: run.process_key,
+  };
+}
+
 /** On-demand: the stitched thread for one origin issue (or self-rooted PR), computed from the live
  * rows. Returns null when the root is unknown. */
 export async function getLineage(

package/app/migration079.test.ts

@@ -0,0 +1,153 @@
+// Read-model guard for migration 079's extended `lineage_thread_view` VIEW (issue #498: surface
+// delivery-graph runs in the Lineage tab as a fan-in parent thread). Mirrors app/migration064.test.ts:
+// apply the migration to a real in-memory SQLite DB and assert the VIEW's output over sample rows —
+// so this exercises the real view, not a re-implementation.
+//
+// The extended view adds a third origin arm: a root that matches a `delivery_graph_runs.run_key`
+// derives `kind = 'delivery'`, `title` from the run, and a NULL `issue_url` (a run is keyed by
+// run_key/digest, not a GitHub issue). The epic/feature/pr arms must keep behaving exactly as 064's
+// view did (precedence unchanged).
+import { readFileSync } from "node:fs";
+import { DatabaseSync } from "node:sqlite";
+import { test } from "node:test";
+import { fileURLToPath } from "node:url";
+import { assertEquals } from "#test-assert";
+
+const MIGRATION_064 = fileURLToPath(new URL("../db/migrations/064_lineage_thread_view.sql", import.meta.url));
+const MIGRATION_079 = fileURLToPath(
+  new URL("../db/migrations/079_lineage_thread_view_delivery.sql", import.meta.url),
+);
+
+/** A DB with the base shapes the view reads (`lineage_threads`, `plans`, `feature_runs`,
+ *  `delivery_graph_runs`) plus 064 then 079 applied in order — so this exercises the real DROP VIEW +
+ *  re-CREATE the migration performs, not just the final definition. */
+function viewDb(): DatabaseSync {
+  const db = new DatabaseSync(":memory:");
+  db.exec(
+    `CREATE TABLE lineage_threads (
+       root_request_key TEXT PRIMARY KEY, title TEXT, stage TEXT,
+       stage_label TEXT, process_key TEXT, pr_keys TEXT, pr_count INTEGER, active INTEGER,
+       created_at TEXT, updated_at TEXT);
+     CREATE TABLE plans (plan_key TEXT PRIMARY KEY, title TEXT, issue_url TEXT);
+     CREATE TABLE feature_runs (feature_key TEXT PRIMARY KEY, title TEXT, issue_url TEXT);
+     CREATE TABLE delivery_graph_runs (run_key TEXT PRIMARY KEY, title TEXT, phase TEXT, status TEXT);`,
+  );
+  db.exec(readFileSync(MIGRATION_064, "utf8"));
+  db.exec(readFileSync(MIGRATION_079, "utf8"));
+  return db;
+}
+
+/** Insert a `lineage_threads` row exactly as `pollLineage` denormalises one (post-072 schema — no
+ *  `kind`/`issue_url` columns; the view derives both from the origin joins). */
+function addThread(
+  db: DatabaseSync,
+  row: {
+    root_request_key: string;
+    title: string | null;
+    stage: string;
+    stage_label: string | null;
+    process_key: string | null;
+    pr_keys: string | null;
+    pr_count: number;
+    active: number;
+  },
+): void {
+  db.prepare(
+    `INSERT INTO lineage_threads (root_request_key, title, stage, stage_label,
+       process_key, pr_keys, pr_count, active, created_at, updated_at)
+     VALUES (@root_request_key, @title, @stage, @stage_label, @process_key,
+       @pr_keys, @pr_count, @active, 't0', 't1')`,
+  ).run(row);
+}
+
+test("lineage_thread_view derives kind/title/NULL issue_url for a delivery-graph thread from the run origin", () => {
+  const db = viewDb();
+  db.prepare(
+    "INSERT INTO delivery_graph_runs (run_key, title, phase, status) VALUES (?, ?, ?, ?)",
+  ).run("dg-abc123", "Ship widget across repos", "Parked on human node: manual OTP publish", "running");
+  // pollLineage wrote the fan-in run's procedural frontier onto lineage_threads, keyed on run_key.
+  addThread(db, {
+    root_request_key: "dg-abc123",
+    title: "Ship widget across repos",
+    stage: "converging",
+    stage_label: "Parked on human node: manual OTP publish",
+    process_key: "P-dg",
+    pr_keys: '["a/b#1","c/d#9"]',
+    pr_count: 2,
+    active: 1,
+  });
+
+  const v = db
+    .prepare("SELECT * FROM lineage_thread_view WHERE root_request_key = ?")
+    .get("dg-abc123") as Record<string, unknown>;
+  // Derived from the delivery_graph_runs join.
+  assertEquals(v.kind, "delivery");
+  assertEquals(v.title, "Ship widget across repos");
+  // A run is keyed by run_key/digest, not a GitHub issue — issue_url is always NULL.
+  assertEquals(v.issue_url, null);
+  // Procedural frontier columns pass through unchanged from lineage_threads (the run's derived phase).
+  assertEquals(v.stage, "converging");
+  assertEquals(v.stage_label, "Parked on human node: manual OTP publish");
+  assertEquals(v.process_key, "P-dg");
+  assertEquals(v.pr_keys, '["a/b#1","c/d#9"]');
+  assertEquals(v.pr_count, 2);
+  assertEquals(v.active, 1);
+});
+
+test("lineage_thread_view renders a delivery thread with no PR landed yet (empty member set, run phase)", () => {
+  const db = viewDb();
+  db.prepare(
+    "INSERT INTO delivery_graph_runs (run_key, title, phase, status) VALUES (?, ?, ?, ?)",
+  ).run("dg-empty", "Fresh run", "Running", "running");
+  addThread(db, {
+    root_request_key: "dg-empty",
+    title: "Fresh run",
+    stage: "implementing",
+    stage_label: "Running",
+    process_key: "P-e",
+    pr_keys: "[]",
+    pr_count: 0,
+    active: 1,
+  });
+
+  const v = db
+    .prepare("SELECT kind, title, issue_url, stage_label, pr_count FROM lineage_thread_view WHERE root_request_key = ?")
+    .get("dg-empty") as Record<string, unknown>;
+  assertEquals(v.kind, "delivery");
+  assertEquals(v.title, "Fresh run");
+  assertEquals(v.issue_url, null);
+  assertEquals(v.stage_label, "Running");
+  assertEquals(v.pr_count, 0);
+});
+
+test("lineage_thread_view keeps the epic/feature/pr arms unchanged after the delivery arm is added", () => {
+  const db = viewDb();
+  db.prepare("INSERT INTO plans (plan_key, title, issue_url) VALUES ('o/r#2', 'Epic', 'u-epic')").run();
+  db.prepare("INSERT INTO feature_runs (feature_key, title, issue_url) VALUES ('o/r#1', 'Feat', 'u-feat')").run();
+  const rows = [
+    { root_request_key: "o/r#2", kind: "epic", title: "Epic", issue_url: "u-epic" },
+    { root_request_key: "o/r#1", kind: "feature", title: "Feat", issue_url: "u-feat" },
+    { root_request_key: "o/r#30", kind: "pr", title: "PR", issue_url: null },
+  ];
+  for (const r of rows) {
+    addThread(db, {
+      root_request_key: r.root_request_key,
+      title: r.title,
+      stage: "opened",
+      stage_label: "Opened",
+      process_key: null,
+      pr_keys: "[]",
+      pr_count: 1,
+      active: 1,
+    });
+  }
+
+  for (const r of rows) {
+    const v = db
+      .prepare("SELECT kind, title, issue_url FROM lineage_thread_view WHERE root_request_key = ?")
+      .get(r.root_request_key) as Record<string, unknown>;
+    assertEquals(v.kind, r.kind);
+    assertEquals(v.title, r.title);
+    assertEquals(v.issue_url, r.issue_url);
+  }
+});

package/db/migrations/079_lineage_thread_view_delivery.sql

@@ -0,0 +1,65 @@
+-- Surface delivery-graph runs in the Lineage read model (issue #498: "surface dynamic delivery
+-- graphs in the Lineage tab as a fan-in parent thread").
+--
+-- 064_lineage_thread_view.sql created `lineage_thread_view`, deriving a thread's view-expressible
+-- identity columns (`kind`, `title`, `issue_url`) from the `plans` / `feature_runs` origin joins and
+-- passing the procedural frontier columns through from `lineage_threads`. It matched a root against
+-- exactly two origin tables (else a self-rooted `'pr'`), so a delivery-graph run — a SEPARATE
+-- aggregate (`delivery_graph_runs`, keyed by `run_key`) — was structurally invisible: its thread fell
+-- through to `'pr'` with a NULL title.
+--
+-- `collectThreads` (app/lineage.ts) now enumerates `delivery_graph_runs` as a fan-in parent thread
+-- keyed on `run_key`, so `pollLineage` writes a `lineage_threads` row for each run. Extend the view
+-- with a third origin arm so it derives that row's identity from the run:
+--   • `kind`      — 'delivery' when the root matches a `delivery_graph_runs.run_key` (after the
+--                   epic/feature arms, mirroring the precedence in `collectThreads` / `deriveLineage`).
+--   • `title`     — the run's `title` (its authored delivery-graph title).
+--   • `issue_url` — NULL: a delivery-graph run is keyed by `run_key`/`digest`, not a GitHub issue,
+--                   exactly as `deriveLineage` sets it (only feature/epic threads root on an issue).
+-- The procedural frontier columns (`stage`/`stage_label`/`process_key`/`pr_keys`/`pr_count`/`active`)
+-- still pass through from `lineage_threads`, so a delivery thread's frontier reflects the run's
+-- derived phase that `pollLineage` wrote.
+--
+-- A VIEW cannot be `ALTER`ed, so DROP the old definition and CREATE the extended one. This is a NEW
+-- forward-only migration — 064 stays immutable. The view remains a plain `CREATE VIEW <name> AS
+-- SELECT … FROM …` (no CTE, no select-list subquery, every column aliased) so the static
+-- pages↔schema contract guard can still introspect its output columns; the added CASE arm and LEFT
+-- JOIN keep the SAME output column set, so the repointed Lineage page renders identically.
+--
+-- Forward-only, additive: no schema change to any base table, no DROP of `lineage_threads`. The
+-- runner wraps each file in its own transaction, so this file must NOT contain BEGIN/COMMIT.
+
+DROP VIEW IF EXISTS lineage_thread_view;
+
+CREATE VIEW lineage_thread_view AS
+SELECT
+  lt.root_request_key AS root_request_key,
+  CASE
+    WHEN pl.plan_key IS NOT NULL THEN 'epic'
+    WHEN fr.feature_key IS NOT NULL THEN 'feature'
+    WHEN dg.run_key IS NOT NULL THEN 'delivery'
+    ELSE 'pr'
+  END AS kind,
+  CASE
+    WHEN pl.plan_key IS NOT NULL THEN pl.title
+    WHEN fr.feature_key IS NOT NULL THEN fr.title
+    WHEN dg.run_key IS NOT NULL THEN dg.title
+    ELSE lt.title
+  END AS title,
+  CASE
+    WHEN pl.plan_key IS NOT NULL THEN pl.issue_url
+    WHEN fr.feature_key IS NOT NULL THEN fr.issue_url
+    ELSE NULL
+  END AS issue_url,
+  lt.stage AS stage,
+  lt.stage_label AS stage_label,
+  lt.process_key AS process_key,
+  lt.pr_keys AS pr_keys,
+  lt.pr_count AS pr_count,
+  lt.active AS active,
+  lt.created_at AS created_at,
+  lt.updated_at AS updated_at
+FROM lineage_threads lt
+LEFT JOIN plans pl ON pl.plan_key = lt.root_request_key
+LEFT JOIN feature_runs fr ON fr.feature_key = lt.root_request_key
+LEFT JOIN delivery_graph_runs dg ON dg.run_key = lt.root_request_key;

package/openapi.yaml

@@ -148,10 +148,10 @@ components:
       properties:
         rootRequestKey:
           type: string
-          description: The origin issue key (feature_key/plan_key), or a self-rooted pr_key.
+          description: The origin issue key (feature_key/plan_key), a self-rooted pr_key, or a delivery-graph run_key.
         kind:
           type: string
-          enum: [feature, epic, pr]
+          enum: [feature, epic, pr, delivery]
         title:
           type: string
           nullable: true

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nanobpm/nano-workforce",
-  "version": "0.131.1",
+  "version": "0.132.0",
   "description": "Nano Workforce — an Agent Graph Orchestration application for Agentic SDLC: durable BPMN processes that coordinate a graph of AI agents across the software delivery lifecycle.",
   "type": "module",
   "main": "main.ts",

package/pages/lineage.page.json

@@ -70,7 +70,7 @@
       "type": "text",
       "id": "subtitle",
       "props": {
-        "text": "One narrative per request, not a card-swap. Each row is a single arc of your intent \u2014 request \u2192 implementing \u2192 PR opened \u2192 converging (round n) \u2192 merged/converged/abandoned \u2014 stitched from the feature/epic that started it, the PR(s) it produced, and their convergence + merge outcome. The Stage column is the active frontier; drill into a row for its member PR(s) and rounds. Epics fan out to N PR sub-threads. A human/webhook PR with no originating request is shown as its own root.",
+        "text": "One narrative per request, not a card-swap. Each row is a single arc of your intent \u2014 request \u2192 implementing \u2192 PR opened \u2192 converging (round n) \u2192 merged/converged/abandoned \u2014 stitched from the feature/epic that started it, the PR(s) it produced, and their convergence + merge outcome. The Stage column is the active frontier; drill into a row for its member PR(s) and rounds. Epics fan out to N PR sub-threads. A delivery-graph run is a fan-in parent thread: the heterogeneous downstream PR convergences it spawns (across different repos/issues) nest under the run, whose frontier reflects its derived phase. A human/webhook PR with no originating request is shown as its own root.",
         "variant": "sub"
       }
     },