@nanobpm/nano-workforce 0.138.2 → 0.138.3

package/CHANGELOG.md

@@ -1,3 +1,9 @@
+## [0.138.3](https://github.com/nanobpm/nano-workforce/compare/v0.138.2...v0.138.3) (2026-08-24)
+
+### Bug Fixes
+
+* **epic-detail:** derive plan_wave_tasks.status=merged so a landed slice isn't stranded at "opened" ([#530](https://github.com/nanobpm/nano-workforce/issues/530)) ([#531](https://github.com/nanobpm/nano-workforce/issues/531)) ([3893f7f](https://github.com/nanobpm/nano-workforce/commit/3893f7fe5534a1510b53a489a0aa83630c6207b9))
+
 ## [0.138.2](https://github.com/nanobpm/nano-workforce/compare/v0.138.1...v0.138.2) (2026-08-24)
 
 ### Documentation

package/app/planReadModel.test.ts

@@ -49,6 +49,7 @@ const MIGRATION_CHAIN = [
   "080_plan_read_model_derive_terminal.sql",
   ROLLUPS_MIGRATION,
   READ_MODEL_MIGRATION,
+  "084_plan_wave_tasks_effective_status.sql",
 ];
 
 // The base `plans` / `plan_tasks` / `pull_requests` shapes the VIEWs read, plus a stand-in for the
@@ -430,6 +431,28 @@ test("plan_wave_tasks carries each task's PR url + process_key link targets (unc
   assertEquals({ pr_url: rows[1].pr_url, process_key: rows[1].process_key }, { pr_url: null, process_key: null });
 });
 
+test("plan_wave_tasks derives status=merged from the PR (never strands a landed slice at 'opened') — matching the summary bar", () => {
+  // The reported defect (#530): a slice whose PR converged + merged kept reading Status "opened" in
+  // the wave-state grid, because nothing writes `plan_tasks.status='merged'` on merge and the VIEW
+  // exposed the raw task status. The fix DERIVES the displayed status the SAME way the count VIEWs
+  // bucket `merged` — `pull_requests__tracking.derived_status = 'merged'` overrides the raw status —
+  // so the per-task grid and the per-wave summary bar agree.
+  const db = viewDb();
+  addPlan(db, "o/r#eff", { status: "done" });
+  addTask(db, "o/r#eff", { status: "opened", wave: 0, prStatus: "merged" }); // landed slice, task row frozen at "opened"
+  addTask(db, "o/r#eff", { status: "opened", wave: 0, prStatus: "converging" }); // still converging → stays "opened"
+  addTask(db, "o/r#eff", { status: "blocked", wave: 0 }); // no PR → raw status untouched
+  // A DERIVE-ONLY merged edge (base PR status frozen, tracking recomputes to `merged`) also reads merged.
+  addTask(db, "o/r#eff", { status: "opened", wave: 1, prStatus: "converging", prDerivedOverride: "merged" });
+  const byWaveIdx = db
+    .prepare("SELECT wave, task_index, status FROM plan_wave_tasks WHERE plan_key = ? ORDER BY task_index")
+    .all("o/r#eff") as Array<Record<string, unknown>>;
+  assertEquals(byWaveIdx.map((r) => r.status), ["merged", "opened", "blocked", "merged"]);
+  // The count VIEW and the per-task grid now agree on the merged tally for wave 0 (3 slices, 1 merged).
+  const c = db.prepare("SELECT merged, total FROM plan_wave_counts WHERE plan_key = ? AND wave = 0").get("o/r#eff") as Record<string, unknown>;
+  assertEquals({ merged: Number(c.merged), total: Number(c.total) }, { merged: 1, total: 3 });
+});
+
 test("the operator pages bind the derived plan-family VIEWs (never the raw plans table)", () => {
   // Overview + Epic index + Epic detail all read the composite `plan_read_model`; the epic-detail
   // per-wave summary reads `plan_wave_summary` (the bar), and the wave-state grid `plan_wave_tasks`.

package/db/migrations/084_plan_wave_tasks_effective_status.sql

@@ -0,0 +1,51 @@
+-- Epic-detail wave-state: a merged slice must not read "opened" (drift with the summary bar).
+--
+-- `plan_wave_tasks` (059) is the per-task display VIEW the Epic-detail "Wave state" grid binds
+-- (pages/epic-detail.page.json → `wave-state`). Its `status` column exposed the RAW
+-- `plan_tasks.status` verbatim — but nothing writes `plan_tasks.status = 'merged'` when a slice's PR
+-- lands: the merge write-path flips `pull_requests.status` (and, for a close-without-merge, the
+-- `abandonClosedPr` self-heal flips the task terminal), yet a *merged* PR leaves its `plan_tasks` row
+-- frozen at `opened`. So a converged-and-merged slice kept showing Status "opened" in the grid, even
+-- as its sibling summary VIEWs (`plan_wave_counts`/`plan_wave_summary`) already counted it `merged`
+-- via the PR join. That is exactly the drift AGENTS.md forbids: two sibling VIEWs over the same join
+-- disagreeing on whether a slice is merged.
+--
+-- Fix by DERIVING the displayed status the SAME way the count VIEWs bucket `merged` (082): a task is
+-- `merged` iff its PR reached `pull_requests__tracking.derived_status = 'merged'` (the terminal-folded
+-- status the canonical runtime reads, ADR-0065), otherwise it falls through to its own
+-- `plan_tasks.status`. This keeps the per-task grid and the per-wave summary bar in exact agreement —
+-- a single notion of "effective task status", still fully DERIVED with no write-path. `pr_url` /
+-- `process_key` link targets are re-exported by the `pull_requests__tracking` VIEW (`p.*`), so the
+-- single join now sources both the effective status and the link targets. The "Active" tab filter
+-- (`status IN (pending,opened,escalated,waiting-for-lane,blocked)`) therefore drops a merged slice as
+-- intended instead of stranding it under "opened".
+--
+-- Forward-only VIEW redefinition (DROP then CREATE); a merged VIEW is not editable in place. The
+-- runner wraps each file in its own transaction, so this file must NOT contain BEGIN/COMMIT. Kept a
+-- plain `CREATE VIEW … AS SELECT … FROM …` (no CTE / no select-list subquery) so the static
+-- pages↔schema contract guard (scripts/pages-contract.test.ts) still parses it. Numbered after 083.
+
+DROP VIEW IF EXISTS plan_wave_tasks;
+
+CREATE VIEW plan_wave_tasks AS
+SELECT
+  t.id AS id,
+  t.plan_key AS plan_key,
+  t.task_index AS task_index,
+  t.task_id AS task_id,
+  t.title AS title,
+  t.prompt AS prompt,
+  CASE WHEN p.derived_status = 'merged' THEN 'merged' ELSE t.status END AS status,
+  t.pr_key AS pr_key,
+  t.summary AS summary,
+  t.created_at AS created_at,
+  t.updated_at AS updated_at,
+  t.wave AS wave,
+  t.open_question AS open_question,
+  t.answer AS answer,
+  t.draft_pr_key AS draft_pr_key,
+  t.corr_key AS corr_key,
+  p.url AS pr_url,
+  p.process_key AS process_key
+FROM plan_tasks t
+LEFT JOIN pull_requests__tracking p ON p.pr_key = t.pr_key;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nanobpm/nano-workforce",
-  "version": "0.138.2",
+  "version": "0.138.3",
   "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",