443 Commits

Author	SHA1	Message	Date
gsxdsm	dc50425e98	docs: correct 104 future-dated FNXC timestamps across 61 files (#2680) ... ## What The FNXC convention exists so a reader can place a note against the change that motivated it. A stamp dated *after* the edit landed defeats exactly that. This is program-wide drift, not one author's slip — I contributed to it in my own commits this week, which is how I noticed it. ## Measured, on this tree **104 stamps across 61 files** dated later than the day they were written, from one day ahead to **2026-10-19 (81 days)**: | count | date | count | date | count | date | |---|---|---|---|---|---| | 50 | 2026-07-31 | 6 | 2026-08-05 | 3 | 2026-08-13 | | 17 | 2026-08-01 | 1 | 2026-08-07 | 1 | 2026-08-19 | | 7 | 2026-08-02 | 1 | 2026-08-12 | 2 | 2026-08-26 | | 11 | 2026-08-03 | | | 3 | 2026-10-19 | An earlier number I circulated was ~70. That came from a narrower pathspec and was wrong; **104** is the measurement. ## How Each stamp is rewritten to the date of the commit that introduced **that line**, via per-line `git blame` — deliberately *not* stamped uniformly with today's date. A uniform stamp swaps a wrong date for a different wrong date and flattens the ordering that makes these comments navigable; blame preserves it. Times of day are untouched, and a blame date in the future is clamped rather than trusted. ## Why the verification is listed A docs sweep across 61 files is precisely where a stray edit hides, so the safety claims are mechanical rather than asserted: - every changed line begins with a comment marker — **no code touched**; - **no test asserts an FNXC date later than today**, so no `toContain` assertion on embedded source text can be silently invalidated (several such assertions do exist); - CSS files, which carry several of those assertions, are outside the pathspec. ## Verified lint clean · merge gate green (487 + 158 + 10 + 71) · `census --strict` exit 0 · tsc clean for core, engine, and dashboard (`tsconfig.app.json`). **No behavior change.** Comment text only. ## Not done here A guard preventing recurrence. A check that rejects an FNXC stamp dated after the commit would stop this returning, but it needs a decision about where it runs (lint rule vs. gate) and it is a behavior change to CI — it does not belong riding inside the sweep it would police.	2026-07-30 02:38:58 -07:00
gsxdsm	543f4a556c	Tell an already-converted fallback literal from an unconverted guard — 19 of 19 dashboard scan hits were the former (#2677) ... The batch phase is about to hand per-file guard lists to cheap workers, and the census currently cannot distinguish **"not yet converted"** from **"converted, with a documented degradation."** ## The measurement that makes this a class, not a preference A proximity scan for *"legacy literal near a role-resolved call"* — the heuristic that produced #2670 and #2672 from the engine — returned **19 hits across the dashboard and zero defects.** Every one was: ```ts if (flags) return flags.hold === true || flags.countsTowardWip === true; return column === "todo" || column === "in-progress"; // reachable only without traits ``` That literal is **correct**: it answers for callers with no resolved column metadata, which is the case `resolveLifecycleColumns` returns `undefined`-for-the-whole-struct to preserve. A worker told to "convert" it would delete the only answer available when traits are absent. ## And the difference is structural, so the parser can see it In **both** engine defects the literal sat in a **separate statement beside resolved data**, not in a fallback branch. Proximity cannot tell those apart; an AST can. `traitFallback` flags the ternary form and the **early-return** form (which is how most are actually written), and deliberately does **not** flag a fallback whose test is itself a column-*name* check — otherwise any `if/else` over column names would launder itself. ## Reported beside the backlog, not subtracted from it ``` COLUMN guards (the backlog): 746 of the column guards, 9 are trait-fallback branches (already converted) ``` A fallback literal is still a literal and should go when the trait path becomes unconditional. This only says which **kind** of work it is. **Advisory, and structurally so:** `traitFallback` never changes `kind`, and the count lives *outside* `totals`. My first attempt put it in `totals` and broke two existing suites that correctly deep-equal that shape — an advisory number does not belong in the structure that defines the bar. ## Revert proof Forcing `traitFallback: false` fails **3 of 33** (both fallback forms, plus the kind-unchanged case). The two *negative* cases pass under the revert — which is the point: they assert what must **not** be flagged, and a classifier that flags nothing satisfies them trivially. Worth stating, because a revert proof that only counts failures would look stronger than it is. ## Baseline Re-recorded: `executor.ts` 87 → 85 was **main's own drift** from #2568 landing, so `--strict` was red on main again. #2668 made the re-record possible; the auto-tighten (coordinator item 2) is still open, and this is the third time in this program that a legitimate merge has left the gate red for everyone else. ## Verification 62/62 across both census suites, `pnpm test:gate` **71/71**, `--strict` exits 0, `pnpm lint` clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added reporting for legacy column comparisons found in trait-fallback branches. * Census results now include a separate count for these fallback-related column guards. * Human-readable reports display the new metric alongside the existing backlog totals. * **Tests** * Added coverage for fallback detection across ternary, early-return, and conditional patterns. * Added safeguards to prevent false positives in resolved-data and column-name checks. * **Maintenance** * Updated baseline census metrics to reflect revised classifications. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 02:33:19 -07:00
gsxdsm	bc782d8d92	U12: resolve the move-path compatibility flag — trait hooks unconditional, legacy branch deleted (#2655) ... U12's headline goal. The raw `experimentalFeatures.workflowColumns` flag gated **every task move**; its six seams are now unconditional and the flag, its last two readers, and the 124-line inline legacy branch are deleted. ## Deleted, not converted The flag-OFF branch goes with the gate. Converting a branch we intended to delete would have left a second definition of every column side effect alive to drift — the defect this program has spent its length removing. Both readers flip in **one commit** because they are not separable: the preflight in `workflow-task-create-ops.ts` computes the `movePolicyPreflight` that `moves.ts` consumes and validates. Un-gating either alone either evaluates workflow move policies — with their plugin-gate side effects — whose result is ignored, or validates against a preflight that was never computed. ## Evidence, not assertion **Equivalence (precondition 1).** `moves-flag-equivalence.test.ts` (commit 1) ran the same journey under both flag states against live PostgreSQL and diffed the persisted row: **identical across 128 fields** plus an equal timing shape, over `todo → in-progress → in-review → todo → in-progress`. Mutation-verified both ways — stamping the flag-ON branch, and diverging the reopen hook, each fail it. **And there was stronger evidence already on main that isn't mine.** U2b's `move-path-equivalence.pg.test.ts` ran *every* scenario once per path and has been green across ~10 of them: `preserveStatus`, `preservePause`, timing accounting, `preserveProgress`, `preserveWorktree`, engine-source rehome, `in-progress → todo`. Two independently built harnesses agreeing is the best evidence this question has had. **The flag was read by nothing in production.** `experimentalFeatures` is global-only and no module writes it, so this path had never run for any project without a stale persisted value. That is also why a green suite was never evidence on its own — both paths were individually valid and only one was live. ## Two claims of mine this PR corrects **1. Seam 2 does not introduce new rejections.** I said in #2639 and in the census that with the flag off there is *no* target validation, so flipping would add refusals. Reproduced the opposite: a move to an undeclared column already rejects on the legacy path with `Invalid transition: … Valid targets: …`. I found it because the discriminator I wrote to prove "the flag is the cause" failed. **2. My first equivalence test proved nothing.** It used `updateSettings`; `experimentalFeatures` is **global-only**, so `getSettingsFast()` filtered the write out and `useWorkflow` was false in *both* runs. Caught by stamping the flag-ON branch and watching the test stay green. It now writes via `updateGlobalSettings` and **asserts the flag took effect** before the journey. U2b's harness carries the same warning independently — `MUST be updateGlobalSettings, NOT updateSettings`. ## The user-visible change Move rejections now report **workflow-resolved** targets instead of the hardcoded legacy adjacency table. Concretely: `Valid targets: in-progress, triage, archived` becomes `Valid targets: archived, in-progress`. That is the fix, not a regression — the legacy table still advertised `triage`, a column the default lineage stopped declaring at #2515, so an operator following the old message was told to move somewhere impossible. Likewise a move *into* `triage` is now refused rather than stranding the card in a column with no trait flags, invisible to every trait-driven sweep until reconciliation re-homes it. `live-move-path-undeclared-target.test.ts` characterised exactly that defect and carried `it.todo("should REFUSE a move into a column the task's workflow does not declare (U2b)")` — **this fulfils it.** ## Test migration | file | change | |---|---| | `move-path-equivalence.pg.test.ts` | deleted — every scenario ran once per path; purpose fully discharged | | `workflow-capacity-invariant.pg.test.ts` | `setPath("inline"\|"hooks")` → `assertMovePathLive()`; the probe is **kept** so capacity cannot pass because moves were broken for an unrelated reason | | `store-movement.pg.test.ts` | asserts the refusal **and** that the legitimate backward move still works, so it reads as a narrowing | | `raw-workflow-columns-flag-census.test.ts` | deleted per its own instructions — it was built to fail in both directions and fired exactly as designed: `expected [] to deeply equal [3 readers]` | | `moves-workflow-flag-seams.test.ts` | deleted — it pinned the six seams this removes | ## Verification Full core suite: **33 failed / 10 files — byte-identical to main's baseline**, with **zero** files failing exclusively on this branch. I measured the baseline by checking out `origin/main` and running the same command, because the first comparison I made was by count alone and would have blamed the flip for 8 files that were already red. `pnpm lint` clean. `pnpm test:gate` green (10 / 132 / 482 / 71). `tsc -p packages/core/tsconfig.json` clean. Core builds. ## Left in place deliberately The `workflowColumns` settings key stays schema-tolerated and is already in `HIDDEN_EXPERIMENTAL_FEATURE_KEYS`, so an upgraded project carrying a stale value renders nothing and loads cleanly. Removing it from the schema would risk rejecting those projects for no benefit now that nothing reads it. --- ## Rebased onto current main — and `triage` reaches ZERO | metric | before | after | |---|---:|---:| | `moves.ts` column guards | 39 | **15** | | repo column total | 745 | **741** | | **`triage` column guards** | 1 | **ABSENT (0)** | `triage` is now absent from `byColumnId` entirely: no unconverted `triage` guard remains anywhere in production source. Combined with #2664 (the last one, in `TaskContextMenu`) this closes bar item 1. The census behaved exactly as designed on the rebase: the flip *deletes* guards, so `--strict` reported `moves.ts: allows 39, tree has 15` rather than leaving a stale allowance, and the re-record lands in this PR's diff. ## Verification on the rebased tree - Full core suite: **33 failed / 10 files — identical to main's baseline**, zero files failing exclusively on this branch (measured by checking out `origin/main` and diffing the failing-file sets, not by comparing counts). - `pnpm test:gate` green (10 / 158 / 487 / 71). - `pnpm check:lifecycle-columns` exits 0. - `pnpm lint` clean, `@fusion/core` builds. ## Two review fixes carried in this PR **P1 — optionless engine moves lost their bypass.** `resolveWorkflowBypassGuardsImpl` did `void moveSource;` — it discarded the resolved parameter and re-read `options?.moveSource`, so `moveTask(id, target)` resolved to `"engine"` at the call site and computed `bypassGuards === false`. Latent while the flag gated validation; with the gate gone, an internal executor/merger/recovery move made without an options object would be judged as a user move. **P2 — the absence signal.** Emitting `workflowId` unconditionally would have stamped `builtin:coding` onto every task with no explicit selection, reporting a fallback as authoritative. Now emits the selection directly, so absent still means "not resolved here". <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Bug Fixes** - Task moves are now validated against the task’s declared workflow. - Invalid destinations are rejected with a clear error, and tasks remain in their original column. - Valid backward moves continue to work as expected. - Move behavior and lifecycle updates are now handled consistently across workflows. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 02:19:32 -07:00
gsxdsm	a099813e94	fix(test): decouple the audit-emitter assertion from log formatting (last of the 4 red PG suites) (#2675) ... Last of the four long-red live-PG suites. **This one is a stale test — the only one of the four that is.** ## The cause `withSeverityMarker` (`logger.ts:31`) deliberately wraps every message in a machine-readable severity marker so the TUI log pane can colour by level. The emitted string carries a `fnlvl=warn` marker and a `[core-async-secrets-store]` subsystem tag ahead of the real text. The assertion pinned the raw message with `toHaveBeenCalledWith`, so it broke when that convention landed. It was coupled to log **formatting**, not to the behaviour it exists to check. ## The fix Rewritten to assert what it actually cares about: exactly one warning, whose message **contains** the subsystem-tagged text, carrying the underlying cause. Both halves of the behaviour stay pinned — the `resolves.toMatchObject` above proves the secret is still created when the audit emitter fails, and this proves the failure is surfaced rather than swallowed. **Mutation-verified rather than assumed green:** deleting the `severityAuditLog.warn` call in `async-secrets-store.ts` fails with `expected "warn" to be called 1 times, but got 0 times`. A `stringContaining` assertion that passes because it matches nothing would be worse than the brittle one it replaces. ## The four, complete | suite | verdict | |---|---| | `store-wedge-resolution` | **product bug** — `42P18`, total runtime failure of wedge resolution in PG (#2669) | | `workflow-settings-project-identity` | **stale docs** — resolver contradicted its own documented order (#2671) | | `agent-logs-and-monitor` | **real defect** — funnel mis-bucketing from the U11 merge; half fixed in #2674, half needs a product call | | `central-archive-secrets` | **stale test** — this PR | **Three of four were real problems**, sitting behind "pre-existing, fails on main too". That phrase answers *whose* problem it is, not *what* is wrong. ## Census, again `check:lifecycle-columns` is **still** exiting 1 on `origin/main` — `executor.ts: allows 87, tree has 85` — the same staleness flagged on #2674. Re-recorded here too, because the blocking check stays red for every open PR until some PR carries it, and I do not know which of #2674 / this one lands first. ## Verification `pnpm test:gate` green (10 / 158 / 487 / 71). Suite **14/15 → 15/15**. `pnpm check:lifecycle-columns` exits 0 after the re-record. `pnpm lint` clean. No changeset: test-only plus an internal baseline. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 01:59:53 -07:00
gsxdsm	e711fbab15	The ratchet's baseline could not be re-recorded once a file rose — the one state that blocks a correct conversion (#2668) ... Unowned (no open PR touches the census CLI — only its baseline JSON) and **live**, since #2654 gates CI on `--strict`. ## The problem `--update-baseline` sat **behind** the rise exit, so the only supported way to re-record was unavailable in exactly the situation that needs it. That matters because **a conversion legitimately adds a literal.** The correct shape for a caller that may have no traits is `flags ? flags.x : columnId === "legacy"`, and each one raises a file's count by one. Measured on current main: `columnRoles.ts` went **0 → 1** from precisely that shape (added by #2647, documented at the site, correct code). So a worker doing the right thing meets a red gate whose only escape is hand-editing the JSON. That is how a ratchet becomes something people route around rather than run — and then it guards nothing. This is the same failure mode as a guard that cannot fire, arrived at from the other side. ## The change `--update-baseline` is an explicit operator action, so it re-records **unconditionally** and prints what it accepted under `ACCEPTED RISES`. Swallowing a rise silently is the real danger; refusing to let anyone re-record is the same danger one step later, wearing a red check nobody trusts. **The rise check is unchanged** and still exits 1 without the flag. **One writer now.** The old second `writeFileSync` behind the rise exit is deleted rather than left unreachable — two writers for one artifact is how they drift. The `!deliberateTracked && updateBaseline` special case went with it, since the unconditional block covers the legacy-shape migration too. ## Exercised end to end On a real rise injected into `live-agent-count.ts`: ``` rise + plain --strict exit 1 (the ratchet still bites) rise + --strict --update-baseline exit 0 "ACCEPTED RISES live-agent-count.ts: 6 -> 7" ``` Four cases assert the CLI's own source, because exit codes are the contract and the pure summarizer cannot express them: the write precedes the rise check, the branches exit 0 and 1 respectively, accepted rises are **named**, and there is exactly **one** writer. ## A note on the revert proof, because it caught me twice My first attempt to move the block back was a **no-op**: the marker I sliced on (`if (regressions.length > 0) {`) also appears *inside* the update block, so the "revert" reassembled the file unchanged and the suite stayed green. **A revert proof that does not go red can mean the guard is vacuous *or* that the revert did not land** — and the second is easy to miss when you are expecting the first. The real revert fails **2 of 27**, and the assertions now verify marker *uniqueness* before slicing on it. ## Verification - 27/27 census suites; `--strict` exits 0; `pnpm test:gate` **71/71**; `pnpm lint` clean - census on this tree: 748 column guards, **4 triage** (all in `moves.ts`'s flag-OFF block, deletion-scheduled with #2655) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 01:46:36 -07:00
gsxdsm	a6138abeff	U12: DELIBERATE-LITERAL counts key on file AND column — closing the P1 left on merged #2661 (#2666) ... Closes the P1 that was still open when #2661 merged. ## The hole A per-file integer is offset **within a single file**: remove one reviewed `todo` exemption, add an `in-review` one beside it, and the number never moves. The fresh guard is invisible to the column counts too, because deliberate findings are excluded from them — so `--strict` goes green with a new lifecycle-column guard hiding inside an existing marker. Now keyed on **file AND column id**. **Proven with the exact scenario:** swapping a marked `triage` for `done` inside `TaskCard.tsx` leaves the per-file total unchanged and now fails with ``` packages/dashboard/app/components/TaskCard.tsx (DELIBERATE-LITERAL: done): 0 -> 1 ``` ## The pattern worth naming This is the **third** time this instrument has been defeated by an aggregate: | version | defeated by | |---|---| | repo-wide `totals.deliberate` | an addition in file A offset by a removal in file B | | per-file integer | an addition offset by a removal **in the same file** | | per-file per-column | — | Each step narrows what can offset silently, and I walked into the next one twice by fixing the *reported case* rather than the *shape*. Writing it down because the same reflex will produce a fourth if someone adds another aggregate here. **The residual is deliberate, not an oversight:** a same-file **same-column** swap still offsets. Two `todo` exemptions in one file are interchangeable by definition, so there is nothing a reviewer could act on. That is recorded at the site so the next person doesn't rediscover it as a bug. ## Migration, again The key **shape** changed (`file` → `file\0columnId`), which is the same hazard as a missing field: comparing new keys against old reports every existing marker as a fresh rise and pushes people to convert already-reviewed literals. I hit it on the first run here — `TaskCard (DELIBERATE-LITERAL: triage): 0 -> 2` — exactly as I did one shape earlier in #2661. Detected by the delimiter rather than a version field, since old keys have none, and re-seeded on the next `--update-baseline`. 15 file+column entries recorded. ## Verification `pnpm lint` clean. `pnpm test:gate` green (10 / 158 / 487 / 71). `pnpm check:lifecycle-columns` exits 0. Independent of #2655; either order merges. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 01:02:25 -07:00
gsxdsm	dca20496f4	consolidate/u7: plugins to zero + 8 executor rebound guards + resume lanes (supersedes #2607, #2635, #2640) (#2644) ... Consolidation branch for U7, per the new one-branch working mode. **Supersedes #2607, #2635, #2640** — the three of my PRs that were stuck on review threads. My other seven (#2602, #2605, #2606, #2611, #2621, #2628, #2633) are green with **zero unresolved threads** and are deliberately left alone for the merge sweep. ## What is in here, file by file | file | change | guards before → after | |---|---|---| | `plugins/…/glasses/src/agent-actions.ts` | gates, destinations and degraded-resolution refusal all resolve from the task's own workflow | 2 → 0 | | `plugins/…/glasses/src/quick-capture.ts` | accepted capture columns come from the board; default no longer names the deleted column | 1 → 0 | | `plugins/…/glasses/src/settings.ts` | quick-capture default was `triage`, the column #2515 removed | (assignment, uncounted) | | `plugins/…/dependency-graph/src/GraphTaskNode.tsx` | redundant column condition deleted | 1 → 0 | | `packages/engine/src/executor.ts` | 8 rebound guards compare the resolved column; 4 resume-eligibility literals share one resolver | 151 → 143 (+4 off-bar) | | `packages/engine/src/__tests__/` | 4 new suites, 26 cases | — | `plugins/` reaches **zero** column guards with this branch. ## The three threads it closes **#2607 — five findings, all mine, all the same rule.** I kept *qualifying* a legacy-id fallback instead of removing it: | attempt | rule | hole review found | |---|---|---| | 1 | fall back to `todo` when the role is missing | moved cards to phantom columns | | 2 | …only if the workflow **declares** `todo` | aliased **review** lane named `todo` | | 3 | …and only if no other role is assigned to it | **traitless** parking column named `todo` | The qualifications were the mistake. Once `resolveLanes` returns a lane set the workflow *has* a column vocabulary, so "no column carries the hold trait" is a complete answer — refuse. `destination()` is two lines now, with no aliasing surface left to qualify. Plus a sixth, which is a genuinely different state: **degraded resolution is indistinguishable from the default board.** `resolveWorkflowIrForTask` is total by design — a missing definition silently returns the *default* coding IR — so a card on a custom board whose definition could not be read resolved to `todo`/`in-progress`. `undefined` lanes cannot express that (it means "no workflow at all", where the legacy ids *are* the answer). The actions now refuse with 409. #2618 would replace this check with resolver provenance; it is not merged, so this does not depend on it. **#2635 — "seven rebound sites remain untested."** Fair; my "same shape" note was an assertion, not coverage. Seven of the eight need a live graph run to reach, so the *shape* is pinned instead: a static check that no guard in front of a rebound move compares against a column literal, with a vacuity case (the same detection run against the original shape) and a match-count floor (≥8), because a guard reporting success on zero matches is worse than no guard. **#2640 — duplicate workflow resolution.** Framed as I/O; it is also a correctness bug. Eligibility and re-entry are two halves of one decision and resolved the workflow separately, so a workflow edit landing between them has the halves reading *different boards*. Now one caller-owned memo per decision — caller-owned because a process-lifetime cache would have to guess when a mid-flight workflow edit invalidates it. ## Behavioural findings, not tidying - **The last-resort recovery for completed-but-stranded work did not exist off the default lineage.** `promotedFromPlannerColumn` was false on a renamed board, so finished work resting in planning was never promoted; the code fell through to a review handoff that role adjacency rejects, and the card stayed stuck with its work complete. - **Rebound guards could not see the column their own move targeted.** U5b converted the move target; the eight `column !== "todo"` checks in front of it were left literal, so on a renamed board the engine moved a card into the column it was already in — and `moveTaskInternal` runs reset-on-entry on every real move, so at the `preserveProgress: false` site it reset step progress a second time. - **The FN-1404 `task:move` audit row was lying**, recording `to: "todo"` while the move target was resolved. A run-audit trail that disagrees with the move it describes is worse than none. Not a comparison, so no census counts it. - **A task interrupted by an engine pause never resumed on a renamed board** (off-bar, `in-review`/`in-progress` literals): four comparisons decided one question and had to agree; two of them disagreed on a renamed board, so re-entry silently never fired. ## Revert proofs, isolated per site | reverted | result | |---|---| | `destination()` back to attempt 3 | 3 of 38 fail | | degraded-resolution refusals removed | 2 of 42 fail | | capture set back to the legacy five | 2 of 3 fail (renamed-board suite) | | forward exclusions → literals | 1 of 14 fails | | missing-wip refusal removed | 2 of 14 fail | | `promotedFromPlannerColumn` → literals | 3 of 7 fail | | promotion target → `"in-progress"` | 3 of 7 fail | | one rebound guard → `!== "todo"` | 1 of 3 fails (static shape) | | resume lanes → legacy trio | 1 of 5 fails | Every conversion is paired with a negative — a forward move, a not-a-planner-lane card, a default-lineage card, an unresolvable workflow — so neither "always fire" nor "never fire" can pass for "resolve the role". ## Commit discipline Twelve commits, each one thing: the code move (`resolvePlannerLanes` out of `triage.ts`) is separate from every behavior change, and each review fix is its own commit with its own revert proof. ## Verification - `pnpm test:gate` **71/71** - 162/162 across the glasses plugin's 19 files; 26/26 across the four new engine suites - engine + glasses typecheck clean; `pnpm lint` clean 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Engine recovery and retries now work correctly with renamed or customized workflow columns. * Tasks in manual-intake columns are no longer automatically planned. * Agent actions and quick capture now respect each board’s declared columns and lifecycle stages. * Awaiting-approval tasks are recognized regardless of their current column. * Command Center SDLC funnel stages now accurately reflect customized workflows. * **Documentation** * Added guidance for safely changing workflow-column logic and interpreting lifecycle-column checks. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:52:55 -07:00
gsxdsm	cef1b08af3	U12: the census baseline follows the count down — and goes in the merge gate (#2661) ... Coordinator item 2. The census had the right mechanism and no teeth. ## The gap `--strict` already fails on a rise **and** on an unrecorded drop — that logic was correct. But nothing blocking ran it, so the baseline drifted to **854 while the tree held 787**. That is **67 guards of regression that would have merged silently**: a high-water mark wearing a ratchet's name. This is the same shape as the ceilings I tightened in #2647, one level up. Worth saying plainly: I fixed the vitest ratchet's slack by hand and did not check whether the *authoritative* instrument had the same problem. It did, and by a much larger margin. ## Three changes 1. **`--strict` runs in `test:gate`.** The baseline cannot go stale again without a red gate. 2. **Baseline re-recorded: 854 → 785** across 14 files (`triage` 38 → 9). 3. The single RISE is resolved honestly rather than absorbed. ## The +3 investigation One file rose: `register-task-workflow-routes.ts` **22 → 23**. #2621 replaced one `task.column === "todo"` with `task.column === "triage" || task.column === "todo"` — a net **+1** that also reintroduced a `triage` literal, while the PR title reported *"count 0 → 0"*. Not an accusation. There was no gate for the author to check against, and a hand-counted claim in a PR title is exactly the thing that goes wrong without one. Change 1 is the fix. **The literal is justified and stays**, marked `DELIBERATE-LITERAL` rather than converted. It is the **v1-IR arm**: a v1 workflow yields no role assignments, so `resolveLifecycleColumns` returns nothing and the legacy pre-implementation ids are the only pre-WIP signal available. The `else` branch directly below already resolves intake/hold for every v2 workflow. Converting this arm would not finish anything — it would delete the only answer v1 boards have and admit `in-progress`/`in-review` cards into a rebound that clears worktree, branch and retry counters, which is the regression #2621 was fixing. ## Both directions proven | direction | probe | result | |---|---|---| | rise | add `t.column === 'in-review'` | `live-agent-count.ts: 6 -> 7`, exit 1 | | drop | convert one guard | `self-healing.ts: allows 111, tree has 110`, exit 1 | **The drop probe took three attempts to test honestly, and the first two "passed" while proving nothing:** 1. I renamed a receiver (`task.column` → `Probe`) — the classifier is **fail-closed**, so an unknown receiver is still counted and the number never moved. 2. I targeted a site in `hold-release.ts` that carries a `DELIBERATE-LITERAL` marker — not counted as a column guard at all, so removing it changed nothing. Only removing a counted comparison outright moved the number. Both false negatives came from me assuming the probe worked because the command exited the way I expected. ## On auto-rewrite vs fail-and-instruct You offered either. The script already does **fail-and-instruct**, with `--update-baseline` as the explicit re-record, and I kept it that way rather than making the test rewrite the baseline during a run. Reason: a silent downward rewrite means a conversion PR's own diff never shows the number moving, so "census before/after in the PR body" becomes unverifiable — the reviewer would have to re-derive it. Failing with the new number in the message puts it in the diff where a human sees it, and it costs one command. ## Verification `pnpm lint` clean. `pnpm test:gate` green with the census in it — `every file matches its baseline exactly` (10 / 132 / 487 / 71). Note for the fleet launch: with `--strict` gating, **every** conversion PR must now re-record the baseline in the same PR. That is the intended cost, and it makes the fleet's "baseline must shrink by exactly the converted count" rule mechanically enforced instead of a review instruction. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:47:31 -07:00
gsxdsm	efbbc45eb0	U12: the LAST triage guard — Plan was offered on executing cards named triage (#2664) ... The final `column === "triage"` in production source, and it was a live defect rather than dead vocabulary. ## The defect `isPreExecutionHoldColumn` ORed the legacy id with the traits **unconditionally**: ```ts return column === "triage" || flags?.intake === true || flags?.hold === true; ``` That is not a fallback. A resolved column merely *named* `triage` answered true even when its own traits said work was underway — so the context menu offered **Plan**, which re-plans, on a card that is already executing. Now flags-first, with the id as the documented no-metadata answer. ## Why the file's earlier conversion missed it Every existing case in `TaskContextMenu.test.tsx` passes a column with **no flags**, or with `hold`/`intake` set. All of them agree under both forms, so the suite could not distinguish them. Nothing exercised a column whose **name and traits disagree**, which is the only shape that separates an OR from a fallback. Three new cases cover it. Revert check: restoring the OR form fails the first one — Plan reappears on a mid-flight card. ## The asymmetry is preserved, and now tested The degraded set stays `{triage}` **alone**, deliberately not the `{todo, triage}` used by `isPreImplementationColumnRole`. That helper drives the preserve-progress prompt, where a flagless `todo` *should* prompt because losing steps is unrecoverable. This drives Plan, where a flagless `todo` must **not** offer to re-plan a card that may already be planned. The file documented that difference; nothing asserted it. Now a test does. ## On reaching zero honestly The surviving literal is marked `DELIBERATE-LITERAL`. It is the degraded answer, not an unconverted guard — there is no trait to read when `flags` is `undefined`, which happens during first paint and for a card in a column its workflow no longer declares. Deleting it would silently withdraw Plan from exactly the stranded cards that most need re-planning. So **`triage → 0` means "no unconverted guards remain", not "the string is gone"**, and I would rather say that than move a number by deleting a fallback. | branch | triage | |---|---:| | `origin/main` | 5 | | this PR | **4** | | #2655 (flag resolution, removes 4 in `moves.ts`) | 1 → **0** combined | I found it with the census's own AST classifier rather than grep — my grep of the same tree returned only comment prose and would have had me report the bar as met while a real defect sat in `TaskContextMenu.tsx:179`. ## Verification `pnpm lint` clean. `pnpm test:gate` green (10 / 158 / 487 / 71). `pnpm check:lifecycle-columns` exits 0 with the baseline re-recorded in this PR (column 769 → 768, deliberate 12 → 13). `tsc -p tsconfig.app.json` clean. `TaskContextMenu.test.tsx` 18/18. Depends on nothing; stacks cleanly with #2655 and #2661. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:37:08 -07:00
gsxdsm	20878e9d5f	census: count column: "<legacy>" query filters as a separate, separately-pinned instrument (backlog unchanged at 784) (#2650) ... Pre-launch input for the 779-guard fleet. **The backlog number does not move: 784 before, 784 after.** This adds a second number beside it. ## The problem it measures A guard is not the only way a legacy column id decides behaviour: ```ts const todo = await this.store.listTasks({ column: "todo", slim: true }); ``` That is a **source query** — it selects the rows a sweep considers *at all*. On a renamed or merged board it returns nothing, so a sweep whose per-task predicate was correctly converted still does nothing, while looking converted. `self-healing.ts:2849` names the pairing in prose, and #2560 had to repair exactly that combination after a converted predicate was left with a literal query. The census walks comparison `BinaryExpression`s. A `PropertyAssignment` is not one, so this class was invisible to the instrument **and to its ratchet** — it could grow silently. Measured: **83 query filters, 43 IR node definitions.** I proved one live consequence earlier on #2648: `recoverStuckMergeDeadlocks` cannot see a renamed board at all — the renamed rows exist and none appear in its three-literal union (`renamedInsideUnion=0`, on a live PG store). ## Why this matters *before* the fleet is briefed The fleet rule is *"the baseline ratchet must shrink by exactly the converted count."* In `self-healing.ts` — the largest batch at 111 — both classes sit in the same functions, so today a worker either: - converts only the comparisons → arithmetic is clean, and sweeps whose source query still filters a dead literal stay blind; or - converts the query too → the count does **not** move by the converted amount, and a more-correct PR looks like a miscount. The second punishes the better worker. With a second pinned number, converting a query becomes visible work instead of an apparent error. ## Counted separately, deliberately `totals.column` is a published shape — the baseline, the reporter, and other workers' in-flight PRs read it, and the completion bar is defined against it. Growing it would move a number the program is actively driving to zero. So the new counts live in `summary.properties` / `queryByFile`, under their own baseline keys, with their own both-directions ratchet (same rule as #2633's, including the stale-allowance half). `totals` keeps its **exact** shape — two existing tests assert it with `toEqual`, and breaking a contract others depend on mid-flight to add a number is not worth it. ## Definitions are not queries Workflow IR graph nodes carry `column:` to declare where a node lives — `{ id: "review", kind: "...", column: "in-review" }`. That is the lineage describing itself: not a lookup, not convertible, and ~43 of the raw matches. They are told apart **structurally** (an `id`/`kind` sibling in the same object literal), not by filename, so a definition written anywhere classifies the same way. ## Baseline seeding, stated plainly `--update-baseline` could not pin a **new** category: the regression check runs before the write, and with no prior key every file reads as a rise. I seeded the three new keys once, directly, leaving every guard field byte-identical. The diff is purely additive — no removals. ## Finding, not caused by this change **`--strict` is already red on clean main**: `register-task-workflow-routes.ts` is **23** against a baseline of **22**. Verified by stashing this branch and re-running on an unmodified tree. Until that is reconciled the guard ratchet is passing nothing — worth fixing before the fleet starts relying on it as the work order. ## Verification - census suites **44 green**, 6 new cases: counted; kept out of the backlog; definition-not-query; both instruments independent (a bug routing comparisons into the query bucket would otherwise look clean on both); `DELIBERATE-LITERAL` honoured; non-legacy id ignored - `node scripts/lifecycle-column-census.mjs` → backlog still 784 - `pnpm lint` exit 0, `pnpm test:gate` exit 0 (695) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:27:18 -07:00
gsxdsm	2771408bba	ci: enforce the lifecycle-column ratchet — it has never actually run (#2654) ... **The ratchet was advisory.** `scripts/lifecycle-column-census.mjs` existed only as `pnpm census:lifecycle-columns` — without `--strict` — and **no workflow invoked it**. Nothing has ever compared the tree to the baseline. Every "the baseline ratchet holds them" assumption in this program rested on a check that does not run. That explains both classes of hole: **1. Three PRs lowered counts without re-recording,** leaving allowances the deleted guards could return through while every check stayed green. I've tightened them across #2593 and earlier PRs, but nothing stops the next one. **2. #2621 GREW the count while its own title claimed "count 0 → 0".** It added `column === "triage"` and `column === "todo"` at `register-task-workflow-routes.ts:2681`, taking that file to **23 against an allowance of 22**. It landed unchallenged. This is the failure mode the ratchet exists to prevent, and it happened *inside this program*, in a PR that asserted the opposite. ## The change Adds `check:lifecycle-columns` (the census with `--strict`) to the `pr-checks.yml` lint job, next to `check:changesets` and `check:routes-modular` — the established pattern. **~1.8s over ~1950 files**, so this is not a slow-test addition. ## Proven to fail, in both directions A guard that reports success without checking anything is worse than no guard, so: | injected defect | result | |---|---| | `const __probe = (c: string) => c === "triage"` added to `moves.ts` | `count ROSE — moves.ts: 39 -> 40`, exit 1 | | run against main's current baseline | exit 1 on `mission-feature-sync.ts: allows 5, tree has 0` | Both reverted; exit 0 restored. Note the second row: **this check is RED on main right now**, which is the point. ## Merge order **Stacked on #2593**, which carries the `DELIBERATE-LITERAL` marker for the #2621 site (a v1 IR declares no roles, so no trait can answer that question) plus the baseline re-record. Standalone on main this PR is red — correctly. **Merge #2593 first**, then this. I stacked rather than duplicating those two edits because I already caused one conflict today by appending related content from two branches, and #2651 merged a correction ahead of the section it corrected. Same-content edits in two PRs is the same mistake. ## Census Unchanged by this PR: **776 total, triage 5, reviewed 16** — it adds no guards and converts none. It only makes the numbers enforceable. ## For the fleet This should land before the 776-guard fleet launches. The brief says "the baseline ratchet must shrink by exactly the converted count" — until now nothing verified that claim, so a batch worker could report a shrink that did not happen, or grow the count while converting, and CI would agree. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:20:31 -07:00
gsxdsm	8e211d1870	TAKING scripts/: parse instead of grep — an AST classifier for the lifecycle-column bar, cross-checked by a second implementation (#2633) ... The program's completion bar is "`column === "triage"` reaches zero". This measures what that bar actually covers, and checks the measurement in so it cannot drift. ## The number, measured by the checked-in tool ``` lifecycle-column-census: scanned 1956 source files COLUMN guards (the backlog): 1031 ROLE comparisons (not guards): 10 DELIBERATE-LITERAL (reviewed): 4 by column id: 313 done 217 in-review 201 in-progress 177 archived 83 todo 40 triage top files: 151 packages/engine/src/executor.ts 136 packages/engine/src/self-healing.ts 50 packages/dashboard/app/components/TaskCard.tsx 44 packages/core/src/task-store/moves.ts 34 packages/dashboard/app/components/TaskDetailModal.tsx ``` **`triage` is under 4% of the class.** Every one of those 1031 sites is the same defect: a lifecycle decision made by column NAME, which stops matching the moment a board renames a column. The bar can be met in full while 991 identical guards remain — and two files hold a quarter of them. ## The tracked count is wrong in three directions at once Each of these cost real work this week, which is why this is a PR and not a comment. 1. **Vocabulary.** It measures one of six legacy ids. 2. **Receiver.** It is anchored on locals named `column`/`toColumn`/`fromColumn`, so it never saw the three real guards in `executor.ts` written against `from` and `originColumn`. One of those meant completed-but-stranded work was never recovered on a renamed board, with nothing else owning that state (converted in #2628). 3. **Collision.** `role === "triage"`, `agentType === "triage"`, `entry.agent === "triage"` compare an **AGENT ROLE**. The planner *lane* is named `triage` and keeps that name — U11 removed the *column*. Ten such sites were counted as backlog, and the "obvious" fix (renaming the role) silently empties the planner's prompt template and mis-binds its model markers. A count that is too high and too low simultaneously sends work to the wrong files while hiding the files that need it. So the census reports **three separate numbers** and never nets them. ## Proven to fail on the original defect Not asserted — exercised: ``` $ # reintroduce `task.column === "triage" || task.column === "todo"` into live-agent-count.ts $ node scripts/lifecycle-column-census.mjs --strict; echo "exit=$?" packages/core/src/live-agent-count.ts: 10 -> 12 exit=1 $ # restore the file $ node scripts/lifecycle-column-census.mjs --strict >/dev/null; echo "exit=$?" exit=0 ``` The CLI also exits 1 when its own file list comes back empty — a guard that reports success without checking anything is worse than no guard. ## 12 regression cases, split by what they defend Must catch: all six ids; a guard on a local named `from`/`originColumn` (verbatim the executor.ts shape); single quotes; negation; several comparisons on one line. Must **not** catch: role comparisons; comment prose (two tracked "guards" in `replan-target.ts` were prose about a filter that lives in another file); a trailing `// … === "triage"` on a code line; sites carrying a `DELIBERATE-LITERAL` marker. Plus: **one marker cannot launder a distant guard in the same file** — that is how allowlists rot. ## Report-only, deliberately `--strict` compares per-file counts against `scripts/lib/lifecycle-column-census-baseline.json` and fails when any file's count **rises**. It is **not** wired into the merge gate: a thousand-site backlog cannot be a blocking check the day it is first measured, and a guard nobody can pass is a guard everyone disables. Owners tightening their own area re-record the baseline in the PR that lowers it. This is the ratchet shape the `DELIBERATE-LITERAL` markers scattered through the program already anticipate. ## Stated limitation Classification is by receiver **name**, so a future field named `agent` that holds a column would be misclassified as a role comparison. Recorded at the site, and it is precisely why the two classes are reported separately instead of netted into one figure. ## Verification - 12/12 new cases (`packages/engine/src/__tests__/lifecycle-column-census.test.ts`) - `pnpm test:gate` **71/71**; `pnpm lint` clean - `pnpm census:lifecycle-columns`, `--json`, and `--strict` all exercised end to end - documented in `docs/testing.md`; no production code touched 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:52:18 -07:00
gsxdsm	7871b28766	fix(core): bind the in-transaction capacity gate — one shared pool-id convention (NOT user-visible yet — see R2) (#2488) ... ## The bug `moves.ts` asked `countActiveInCapacitySlotAsync` for occupants of pool `"builtin:coding"`, while the counter buckets selection-less rows under `DEFAULT_WORKFLOW_POOL_ID` (`"__default-workflow__"`). Nothing ever landed in the pool being asked about, so the count came back **0** and a finite limit could never bind. ## Root fix, not a literal swap A shared *constant* would not have prevented this: **`DEFAULT_WORKFLOW_ID` was already imported in `moves.ts` and the code still wrote a literal.** So both sides now call a shared **function**, `resolveCapacityPoolId` — "which pool does a selection-less task belong to" has exactly one answer and no call site is in a position to disagree with it. The one variable serving two masters is split: a capacity **pool key** (a bucketing sentinel that must not collide with a workflow id) and a **workflow id** (telemetry, must stay a real id). The emitted `TaskTransitioned` payload is byte-identical. ## Checked, not assumed: no second copy `scheduler.ts:2514` and `:2536` do carry `?? "builtin:coding"` — but as an **IR resolution key** (`resolveWorkflowIrById`), where a real workflow id is required and the pool sentinel would not resolve at all. Same literal, different concept, correctly used. A blanket replace would have broken it. ## Something did depend on the gate being dead — exactly one thing `move-path-equivalence.pg.test.ts` → *"UNPROVEN: in-transaction column capacity did NOT reject on EITHER path in this fixture"*. It left the cause open — > something further in (`resolveColumnCapacity`'s limit resolution, or what `countActiveInCapacitySlotAsync` counts as an occupant — a task with no session/agent may not count) keeps the check from firing … This suite does not establish which. — and predicted its own obsolescence (*"if a future change makes this reject, that is the capacity gate coming alive"*). **Neither guess was right; it was the pool id.** Updated to assert the divergence with the answer recorded — **not weakened**. Its fixture also had to start each phase from an empty wip column: once the gate binds, the inline phase's leftovers trip the cap on the *holder* move before the contended move under test runs. `schema-applier.test.ts` failed only in the full-suite run and passes in isolation both with and without the fix — cross-file contamination, not mine. ## Before / after — measured, both directions `maxConcurrent: 1`, real PG store, real `moveTask`: | | flagOFF / no selection | flagOFF / selection | flagON / no selection | flagON / selection | |---|---|---|---|---| | **before** | ADMITTED | ADMITTED | **ADMITTED** ← the bug | REJECTED | | **after** | ADMITTED | ADMITTED | **REJECTED** | REJECTED | The E2E acceptance row asserts **held at cap 1 and admitted at cap 2 on the same fixture**, so it cannot pass by simply never admitting anything. **With the fix reverted that row fails**; the `admitted` case still passes, as it should. The Phase A3 ratchet's two flipped assertions also fail with the fix reverted. Ratchet flipped exactly as its author specified: `DEFECT (R1)` becomes a rejection, and `it.fails` on the invariant becomes a plain `it`. ## ⚠️ This is NOT user-visible yet — please read before merging The premise this was approved on ("once it binds, cards that currently slip through will start being held") **does not hold for this change alone.** The whole capacity block sits inside `if (useWorkflow && workflowIr && fromColumn !== toColumn)`, and `useWorkflow` is `experimentalFeatures.workflowColumns === true` — absent from `DEFAULT_GLOBAL_SETTINGS`, with **no writer anywhere outside tests**. That is Phase A3's R2, still live and now retitled `DEFECT (R2, STILL LIVE)` with the measured matrix recorded in it. So on merge: nothing changes for any real project. Making it actually bind means **also** removing the `useWorkflow` condition — a materially larger, genuinely user-visible change that I have not made unilaterally. Escalated for a decision; if that lands, the changeset here should be re-categorised. ## Review follow-up (48e79ffd9): the convention was still duplicated — swept and ratcheted The first pass added the resolver and routed the transactional gate + counters, but **hold-release still derived the pool independently**. Swept the repo: six sites name the sentinel, **five derive the convention** and now call `resolveCapacityPoolId` (`hold-release.ts:116/118/442/576`, `task-store-helpers.ts:290`). The sixth, `scheduler.ts:1558`, names the default pool as a literal in a capacity *diagnostic* — no selection input, nothing to disagree with — so it keeps the constant. **Does this change hold-release behavior? No, and it was never releasing against the wrong pool.** hold-release computed `x ?? DEFAULT_WORKFLOW_POOL_ID`, which is exactly what the counter buckets under; `moves.ts` (`?? "builtin:coding"`) was the sole disagreeing site, and the first commit moved *it* into agreement with hold-release, not the reverse. `resolveCapacityPoolId(x)` **is** `x ?? DEFAULT_WORKFLOW_POOL_ID`, so every routed site computes an identical value for every input. **No second user-visible change rides along with this PR** — the only behavior delta remains the gate binding on the flag-ON path, which per R2 is still not the path production takes. Evidence: hold-release + capacity suites **43/43 identical before and after**. **The resolver is now the only way to compute a pool id, not merely the newest way.** `scripts/check-capacity-pool-id.mjs` fails on any inline `?? DEFAULT_WORKFLOW_POOL_ID` outside `workflow-capacity.ts`, wired into **both `pretest` and the blocking `test:gate`**. A review note would not have sufficed: the original defect landed in a file that *already imported* the canonical constant. Verified both ways — clean run scans 1124 files and passes; reintroducing the old hold-release expression exits 1 and names the line. ## Review follow-up (a5b675503): the ratchet was rebuilt because it would not have caught the bug The first ratchet matched one spelling (`?? DEFAULT_WORKFLOW_POOL_ID`) and the real defect used another (`?? "builtin:coding"`). **Verified: reintroducing the original defect and running the old checker exits 0.** A guard that reports success without checking is worse than no guard — it stops anyone looking. Rebuilt on the TypeScript AST with two rules. **Rule 1 (sink):** a value reaching a capacity counter's `workflowId` must come from `resolveCapacityPoolId`, or a local initialized from it — so it fires on the original defect regardless of which literal was used, on one line or twenty. **Rule 2 (sentinel):** no `??` onto the sentinel at any qualification depth or as its raw value; multiline is one AST node and caught by construction. `?? "builtin:coding"` is deliberately *not* banned outright — it is the legitimate default for a *workflow* id in ~8 places, and is only a bug when it reaches a capacity pool. **Fails closed three ways** that previously reported success without inspecting: unreadable file, unparseable file, and an empty file listing (the old script would have printed a green tick off a broken glob). **Acceptance was not "passes on main".** Each form was reintroduced into the real source and confirmed to fail: the original defect in `moves.ts`, a multiline fallback, and a deeply qualified sentinel. All are pinned in `capacity-pool-id-check.test.ts` (12 cases: 7 must-catch starting with the reduced actual pre-fix `moves.ts`, 4 must-not-flag, 1 fail-closed) so the guard cannot silently narrow again. Also added to `pretest:full`, which had omitted it. ### Follow-up (0be8df6ea): a dead rule found by fixing a test title Splitting the mislabelled fail-closed test surfaced more than a mislabel: **`ts.createSourceFile` is error-tolerant and does not throw on malformed syntax**, so the `try/catch` behind the `unparseable` rule was unreachable and that rule could never fire. The earlier "fails closed three ways" claim was overstated — the guard advertised a capability it did not have. Detection now reads `sf.parseDiagnostics`; a partial AST can silently lack the `??` nodes and sink calls the rules look for, so "did not parse" must not read as "inspected and clean". Mutation-verified: reverting the detection fails that case and only that case. Test-file exclusion also moved to the repo's `{test,spec}.{ts,tsx}` guideline shape — a `.spec.ts` under `packages/<pkg>/src/` was being scanned as production source. Verified both ways: the `.spec.ts` is skipped, and the identical content in a non-test file is still caught, so the exclusion is scoped rather than a hole. ## Verification - engine + core `tsc --noEmit` clean - `pnpm test:gate` green (299 + 10 + 71) - E2E 20/20; capacity + move-path suites 14/14 - full core PG: **1037 passed / 3 failed** — all three reproduce with the fix stashed (pre-existing) - engine-default: **279 failed** vs **280 at baseline** with the fix stashed — pre-existing red lane, no regression - hold-release + capacity suites: **43/43 identical before and after** the resolver routing - `check-capacity-pool-id` ratchet: 14/14 regression cases; clean over 1124 files; exits 1 on the original defect, a multiline fallback, and a deeply qualified sentinel reintroduced into real source 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Fixed capacity-limit accounting when workflow selection is missing by consistently deriving the correct capacity pool id. * Made capacity enforcement align across move and hold/release paths, rejecting over-limit moves with `capacity-exhausted`. * **Tests** * Updated PostgreSQL and added an E2E scenario to verify the corrected in-transaction gating behavior at `maxConcurrent` limits of 1 and 2. * **Chores** * Added an automated guard to detect inconsistent capacity pool id fallback patterns in code. * **Public API** * Exposed `resolveCapacityPoolId` for consistent capacity pool id derivation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 21:09:51 -07:00
gsxdsm	8b039a543e	fix(desktop): advance Pi runtime pin to 0.82.1 for packaging PR lane (#2465) ... ## Summary - Advance the matched Pi runtime pin (`pi-ai`, `pi-coding-agent`, `pi-agent-core`, `pi-tui`) from **0.82.0 → 0.82.1** so electron-builder's production-dependency walk accepts `pi-agent-core`'s `pi-ai@^0.82.1` requirement. - Fixes the Desktop packaging PR-lane failure: `Production dependency @earendil-works/pi-ai not found for package @earendil-works/pi-agent-core` (required `^0.82.1`). - Keep the workspace override guard; update pin-policy fixtures and CLI package-config expectations. - Tighten the advisory packaging step-order test so it asserts against the real `electron-builder --dir` step (not a missing release-only step name that previously passed via `indexOf === -1`). - Run `pnpm dedupe` so the packaging lane's lockfile dedupe early-warning is clean. ## Context #2439 pinned the full Pi closure at 0.82.0 and made recent main-based packaging runs green. This advances to the current upstream patch so deploy + electron-builder stay aligned with `pi-agent-core@0.82.1`'s declared dependency range. ## Test plan - [x] `node scripts/check-pi-versions-pinned.mjs` - [x] `node --test scripts/__tests__/check-pi-versions-pinned.test.mjs` - [x] `pnpm --filter @runfusion/fusion exec vitest run src/__tests__/package-config.test.ts` - [x] `pnpm --filter @fusion/desktop exec vitest run src/__tests__/release-workflow.test.ts` - [x] `pnpm dedupe --check` - [ ] GitHub: Desktop packaging (should run full packaging walk — lockfile/package.json touched) - [ ] GitHub: PR Checks (Lint, Typecheck, Build, Gate)	2026-07-26 23:47:49 -07:00
gsxdsm	f1a2d9ae1f	FN-8626: validate committed test timing snapshot ... Add an automated guard that keeps CI test-sharding timings usable. - Validate snapshot structure, freshness, and recorded test-file paths. - Confirm planning loads the snapshot and shard dry-runs use it without stale warnings. Files changed: scripts/__tests__/ci-test-shard-timings.test.mjs | 50 +++++++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-) Fusion-Task-Id: FN-8626 Fusion-Task-Lineage: ada6525f-8dcc-4494-8586-3aa2e41618f3 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-26 20:42:30 -07:00
gsxdsm	034827f251	FN-8623: restore CDP touch geometry test lane ... Restore a dedicated Chromium CDP lane for dashboard touch-geometry coverage. - Add an opt-in touch-geometry test command and isolated Vitest project. - Keep the browser-dependent spec out of deep and quality backfill collection. - Document browser discovery, port, and single-collection requirements. Files changed: docs/testing.md | 10 ++- packages/dashboard/package.json | 1 + .../__tests__/dashboard-test-config-guard.test.ts | 71 +++++++++++++++++++++- .../task-modal-touch-resize-browser.test.ts | 5 ++ packages/dashboard/vitest.config.ts | 28 ++++++++- scripts/lib/test-inventory-spec.json | 3 +- 6 files changed, 114 insertions(+), 4 deletions(-) Fusion-Task-Id: FN-8623 Fusion-Task-Lineage: eafd7497-9302-49a4-8e9e-aa93c9f56a6f Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-26 18:04:28 -07:00
gsxdsm	93a403af67	fix(dashboard): import delete-attribution constants via browser-safe subpath ... The client bundle aliases `@fusion/core` to the leaf `core/src/types.ts` to keep Node-only dependencies out of the browser, so a package-root import of `FUSION_CLIENT_HEADER`/`FUSION_DASHBOARD_UI_CLIENT` typechecked but failed `vite build`: "FUSION_CLIENT_HEADER" is not exported by "../core/src/types.ts" Follow the documented pattern instead of widening the root alias: declare a `./task-delete-attribution` subpath export, add the matching Vite alias ahead of the broader `@fusion/core` key (Vite matches in order), register the module in the browser-safe-core allowlist, and import the subpath from the client. `task-delete-attribution.ts` has no imports at all, so it is a safe leaf. `app/utils/detectContentLanguage.ts` already warned about exactly this trap; the miss was mine for verifying with typecheck, lint and test:gate but not `pnpm build`, which is one of the four checks CI blocks on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 13:22:18 -07:00
gsxdsm	c7fa02f370	FN-8597: restore executor task-done invariant coverage ... Restore the quarantined executor graph-completion invariant suite with real foreach projections. - Exercise complete and partial expanded workflow-step projections at the merge boundary. - Remove the rescued invariant suite from Vitest quarantine and clear its ledger entry. - Extend the shared executor logger mock with the debug method required by the integration tip. Files changed: .../__tests__/executor-task-done-invariant.test.ts | 267 +++++++++++++++++++-- .../engine/src/__tests__/executor-test-helpers.ts | 7 + packages/engine/vitest.config.ts | 7 - scripts/lib/test-quarantine.json | 8 +- 4 files changed, 254 insertions(+), 35 deletions(-) Fusion-Task-Id: FN-8597 Fusion-Task-Lineage: 05a08e31-7da0-4c93-86a0-9baf8db7ce52 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-26 10:04:36 -07:00
Phil Larson	0643a64f0d	fix(desktop): pin complete Pi runtime closure (#2439) ... ## Summary - pin `pi-agent-core`, `pi-ai`, `pi-coding-agent`, and `pi-tui` to one exact 0.82.0 workspace override set - extend the Pi version policy guard to reject missing, ranged, or mismatched desktop runtime closure overrides - add a patch changeset for the legacy desktop packaging fix ## Test plan - `node --test scripts/__tests__/check-pi-versions-pinned.test.mjs` (5 passed) - `node scripts/check-pi-versions-pinned.mjs` - `corepack pnpm check:changesets --strict` - focused engine fixtures: 4 files / 47 tests passed - GitHub: Desktop packaging, Lint, Typecheck, Build, Gate, and Greptile Review passed	2026-07-26 07:34:50 -07:00
gsxdsm	99b80ad748	feat(dashboard): add opt-in auto-update and harden restart supervision ... Add the `autoUpdateAndRestart` global setting (default off, Settings -> General next to Release channel). When enabled, the dashboard host installs available updates on the selected channel by itself and requests the supervised in-place restart. Supervised hosts only: without a parent to respawn, installing would leave a running process whose code no longer matches its own install. Fix two ways the restart affordance could silently do nothing: - The supervisor now stamps FUSION_SUPERVISOR_PID and supervision is only counted when that pid is the real parent. FUSION_RESTART_SUPERVISED is inherited by every process Fusion spawns, so `fn dashboard` launched from an agent terminal skipped its own supervisor while still advertising restart support -- a restart request then killed it for good. - Settings and the update banner probe /system/info on mount and treat capability as advisory: the button always issues the request and shows the server's actual refusal instead of sitting disabled after a failed probe. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 22:52:53 -07:00
gsxdsm	2a2b157cb9	FN-8585: fix dashboard composer test source reads ... Stabilize dashboard composer tests when Vitest launches from the workspace root. - Resolve dashboard test source fixtures relative to the app directory. - Migrate affected component tests away from cwd-relative CSS reads. - Enforce the fixture convention in test hooks and document it. Files changed: docs/testing.md | 4 +++ package.json | 6 ++-- .../__tests__/AuthTokenRecoveryDialog.test.tsx | 3 +- .../components/__tests__/ChatView.mobile.test.tsx | 5 +-- .../__tests__/EngineControlMenu.test.tsx | 11 ++---- .../components/__tests__/FloatingWindow.test.tsx | 5 +-- .../app/components/__tests__/ListView.test.tsx | 5 +-- .../__tests__/MissionInterviewModal.test.tsx | 3 +- .../app/components/__tests__/MobileNavBar.test.tsx | 3 +- .../app/components/__tests__/NewTaskModal.test.tsx | 3 +- .../__tests__/PlanningModeModal.initial.test.tsx | 3 +- .../PlanningModeModal.ui-interactions.test.tsx | 7 ++-- .../components/__tests__/PrCreateModal.test.tsx | 3 +- .../__tests__/QuickChat.persist.test.tsx | 3 +- .../components/__tests__/QuickEntryBox.test.tsx | 3 +- .../components/__tests__/ReportActionMenu.test.tsx | 9 ++--- .../app/components/__tests__/ReportModal.test.tsx | 3 +- .../__tests__/ShadcnColorPicker.test.tsx | 3 +- .../components/__tests__/TerminalModal.test.tsx | 3 +- .../components/__tests__/ThemeDropdown.test.tsx | 9 ++--- .../__tests__/WorkflowNodeEditor.test.tsx | 5 +-- .../WorkflowOptionalStepsDropdown.test.tsx | 3 +- .../components/__tests__/WorkflowSwitcher.test.tsx | 5 +-- .../app/components/__tests__/board-mobile.test.tsx | 4 +-- .../__tests__/CommandCenterControls.test.tsx | 6 ++-- .../__tests__/SystemControlsArea.test.tsx | 5 +-- .../__tests__/SystemStatsArea.test.tsx | 3 +- .../command-center/areas/__tests__/areas.test.tsx | 3 +- .../__tests__/KeyboardShortcutsSection.test.tsx | 3 +- .../app/test/__tests__/cssFixture.test.ts | 35 +++++++++++++++++++ packages/dashboard/app/test/cssFixture.ts | 12 +++++++ .../check-no-cwd-relative-dashboard-test-reads.mjs | 39 ++++++++++++++++++++++ 32 files changed, 162 insertions(+), 55 deletions(-) Fusion-Task-Id: FN-8585 Fusion-Task-Lineage: 83a35fb6-a29d-4e97-b282-1054c68b8cc9 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-25 06:22:23 -07:00
gsxdsm	084dd76d64	feat(release): write release copy with opus and draft tweets for betas too ... - distillation runs on opus (env-overridable) with a 4-minute budget - highlights must name the surface and outcome; vague filler is banned - tweets target 200-280 chars with concrete changes and varied structure - betas get their own tester-facing draft carrying `fn update --channel beta` - prerelease openers read as "Fusion 0.74 beta:" instead of "Fusion 0.74-beta.0"	2026-07-24 23:15:36 -07:00
gsxdsm	330e4970f0	refactor(release): move the version-anchor package.json rewrite into the shared lib ... Makes the re-anchor file mutation unit-testable alongside the anchor decision.	2026-07-24 23:01:11 -07:00
gsxdsm	dba9746287	fix(release): base the next beta on the shipped stable version ... After a stable release, main stayed inside the old pre-mode cycle, so the next beta numbered below the published stable (v0.73.0-beta.7 after v0.73.0) and the dev checkout kept reporting the last beta. - beta releases re-anchor a stale pre-mode cycle on the newest stable tag - both channels refuse a version at or below the newest published stable - stable promotion now back-merges release into main automatically (fail-soft on conflict) so the local dev version is the stable version	2026-07-24 22:59:19 -07:00
gsxdsm	e3dba364d1	FN-8564: update bundled Pi runtime to 0.82.0 ... Update Fusion's matched Pi dependencies and compatibility coverage for version 0.82.0. - Pin Pi AI and coding-agent packages to the exact 0.82.0 release pair. - Refresh provider catalog, supplemental model, auth storage, and Droid thinking coverage. - Add the published CLI patch changeset. Files changed: .changeset/fn-8564-pi-082.md | 7 + packages/cli/package.json | 4 +- packages/cli/src/__tests__/package-config.test.ts | 2 +- packages/core/package.json | 2 +- packages/dashboard/package.json | 2 +- ...ister-model-routes-kimi-k3-supplemental.test.ts | 6 +- packages/engine/package.json | 4 +- .../src/__tests__/provider-registration.test.ts | 4 +- packages/engine/src/auth-storage.ts | 11 +- packages/engine/src/pi.ts | 6 + packages/pi-claude-cli/package.json | 8 +- .../src/thinking-config.ts | 10 +- pnpm-lock.yaml | 176 +++++++++++---------- pnpm-workspace.yaml | 6 +- .../__tests__/check-pi-versions-pinned.test.mjs | 8 +- 15 files changed, 142 insertions(+), 114 deletions(-) Fusion-Task-Id: FN-8564 Fusion-Task-Lineage: 543c5e17-4cb2-446f-9a1c-ec7ec8b8117a Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-24 19:06:14 -07:00
gsxdsm	6166b496e4	FN-8559: refresh test timing snapshots ... Refresh timing data and keep velocity reports aligned with the current snapshot. - Attribute CI timing reports from absolute checkout paths - Render report-only slowest tests from the latest timing snapshot - Update timing snapshot data and regression coverage Files changed: scripts/__tests__/ci-test-shard-timings.test.mjs | 9 + scripts/__tests__/test-velocity-baseline.test.mjs | 38 + scripts/ci-test-shard.mjs | 13 + scripts/test-timings.json | 2522 +++++++++++++-------- scripts/test-velocity-baseline.mjs | 33 +- 5 files changed, 1616 insertions(+), 999 deletions(-) Fusion-Task-Id: FN-8559 Fusion-Task-Lineage: 09ed6b78-f82f-4732-a5e3-1066efe385b3 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-24 06:21:53 -07:00
gsxdsm	c5a8421533	FN-8560: forward desktop test telemetry flags ... Desktop test execution now preserves CI reporter and JSON output flags. - Forward caller-selected Vitest reporters and output files through the desktop test wrapper. - Add coverage for reporter syntax and shard timing command forwarding. - Document desktop timing artifact requirements. Files changed: docs/testing.md | 7 ++++- packages/desktop/scripts/__tests__/test-args.test.ts | 36 ++++++++++++++++++++++ packages/desktop/scripts/test-args.ts | 13 ++++++++ packages/desktop/scripts/test.ts | 3 +- scripts/__tests__/ci-test-shard.test.mjs | 9 ++++++ 5 files changed, 66 insertions(+), 2 deletions(-) Fusion-Task-Id: FN-8560 Fusion-Task-Lineage: 2a89b28d-39f6-4949-aec2-1123c36126cf Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-24 05:30:45 -07:00
gsxdsm	c5e9a7956a	fix(ci): stop watchdog false-kills of the grown core slice; actually upload timing artifacts ... - Shard watchdog floor 25min (was 15): the July PG-cutover test growth pushed @fusion/core past 900s on contended CI runners; run 30075604930 killed a healthy core run at exactly the floor because the 27-day-old (still "fresh") undercounting timings snapshot tightened the budget to it — the same false-kill class as the 5->15min raise. Floor pin + in-band example updated. - full-suite.yml timing upload: include-hidden-files — the .timings/ dot-dirs were silently excluded by upload-artifact@v4, so the step has uploaded nothing since it was added and the snapshot could never be refreshed from CI. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 00:55:38 -07:00
gsxdsm	ff165ecb5a	fix: scope beta release notes to that beta's changesets; stable keeps full-cycle rollup ... Pre-mode preserves consumed changeset .md files, so every beta's distilled notes and GitHub prerelease body aggregated the entire cycle since the last stable (v0.73.0-beta.4 shipped the full 0.72.0→0.73.0 aggregate). Betas now distill only changesets not yet recorded in pre.json's consumed ledger, and fail loudly when a beta would ship nothing new. Stable promotion still feeds the full preserved set, keeping its notes an explicit rollup of every beta in the cycle. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 12:18:24 -07:00
gsxdsm	42fe154abe	FN-8533: add mobile planning comment actions ... Make contextual plan comments reachable from the mobile action rail and restore focus after editing. - Add responsive desktop and mobile comment triggers with contextual styling and documentation. - Preserve the selected quote and restore the remounted trigger after canceling or adding a comment. - Cover action placement, focus restoration, and browser interaction behavior. Files changed: .changeset/fn-8533-mobile-planning-comments.md | 7 ++ docs/dashboard-guide.md | 2 +- .../dashboard/app/components/PlanningModeModal.css | 20 ++++ .../dashboard/app/components/PlanningModeModal.tsx | 44 ++++++- .../__tests__/PlanningModeModal.css.test.ts | 10 ++ .../PlanningModeModal.planning-flow.test.tsx | 40 +++++-- .../PlanningModeModal.ui-interactions.test.tsx | 5 + .../dashboard/app/planning-browser-e2e-fixture.tsx | 3 +- .../src/__tests__/planning-browser-e2e.test.ts | 133 +++++++++++++++++++-- packages/dashboard/vitest.config.ts | 11 +- scripts/lib/test-quarantine.json | 5 - 11 files changed, 242 insertions(+), 38 deletions(-) Fusion-Task-Id: FN-8533 Fusion-Task-Lineage: e0d561be-ecc8-456e-807e-a1dc677b5d9c Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-23 09:33:25 -07:00
gsxdsm	616653588c	refactor: package code organization wave 15 (#2394) ... ## Summary Wave 15 of package code organization. ### Peels - `types/settings-scope.ts` — global/project settings (~2.2k lines) - `types/archive-planning.ts` — archive, mesh/multi-project, planning sessions - `task-store/project-store-ops.ts` — rename of `remaining-ops-1` (last numbered ops module) ### LOC - `types.ts` ~5872 → ~3074 ## Test plan - [x] `@fusion/core` typecheck - [ ] CI merge gate **Stack:** this PR → #2397 → #2398 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Reorganized and expanded the core public type surface into dedicated modules for settings, archive/planning, board, tasks, todo lists, plugin activation, and multi-project setup. * Improved the browser-safe type exports to keep the public contracts consistent. * Updated internal project-level operation wiring to use the correct project implementations. * **Bug Fixes** * Fixed a workflow creation test hook to inject the correct pre-insert behavior for workflow-definition collision/allocator scenarios. * **Chores** * Refreshed internal headers and updated line-count baselines. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-23 00:01:24 -07:00
gsxdsm	28e8c0abc9	FN-8524: cover workspace manifests in Docker builds ... Ensure the builder install layer includes every selected workspace manifest. - Copy the five omitted plugin manifests before frozen installation. - Validate pre-install Dockerfile coverage against pnpm workspace entries. - Document the manifest coverage requirement and focused test command. Files changed: Dockerfile | 8 +- docs/docker.md | 3 +- .../dockerfile-workspace-manifests.test.mjs | 111 +++++++++++++-------- 3 files changed, 78 insertions(+), 44 deletions(-) Fusion-Task-Id: FN-8524 Fusion-Task-Lineage: 16a4d9df-ff08-4051-9e53-0da414ef6a85 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-22 22:04:32 -07:00
gsxdsm	f120e6c879	FN-8506: run static checks in verify:fast ... Run canonical pretest validators before test-free verification work. - Derive read-only static check steps from the root pretest script. - Test fail-fast static-check planning and execution. - Document the expanded verify:fast gate and correct changeset metadata. Files changed: .changeset/mobile-board-pointercancel-settle.md | 2 +- docs/testing.md | 5 +- scripts/__tests__/verify-fast.test.mjs | 105 ++++++++++++++++++++++-- scripts/verify-fast.mjs | 86 ++++++++++++++++--- 4 files changed, 174 insertions(+), 24 deletions(-) Fusion-Task-Id: FN-8506 Fusion-Task-Lineage: 87f74fda-1fd0-4e08-9bfe-51e0c4c9a31d Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-22 18:26:33 -07:00
gsxdsm	9002fca9de	FN-8497: reduce merge gate wall time ... Keep merge-gate coverage focused while running its independent test lanes concurrently. - Limit PostgreSQL gate coverage to lifecycle and transactional-handoff canaries. - Run engine and PostgreSQL gate lanes concurrently while preserving failure propagation. - Enforce canary coverage policy and refresh velocity documentation and history. Files changed: docs/test-velocity-baseline.md | 16 +-- docs/testing.md | 5 +- package.json | 2 +- packages/core/package.json | 2 +- .../__tests__/engine-vitest-gate-policy.test.mjs | 79 +++++++++++++- scripts/test-velocity-history.json | 115 +++++++++++++++++++++ 6 files changed, 204 insertions(+), 15 deletions(-) Fusion-Task-Id: FN-8497 Fusion-Task-Lineage: 8777959c-6d8c-4686-a975-d91af2c169ea Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-22 15:47:24 -07:00
gsxdsm	875d057d16	FN-8495: refresh W29 test velocity baseline ... Refresh the weekly test velocity publication with the latest measurements. - Record updated gate, boot smoke, and changed-only test timings. - Append the W29 velocity history entry and update the published summary. - Point testing guidance to the canonical weekly velocity workflow. Files changed: docs/test-velocity-baseline.md | 16 +++--- docs/testing.md | 10 +--- scripts/test-velocity-history.json | 115 +++++++++++++++++++++++++++++++++++++ 3 files changed, 124 insertions(+), 17 deletions(-) Fusion-Task-Id: FN-8495 Fusion-Task-Lineage: db432471-13a2-41b1-a951-f735c96456e9 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-22 15:14:34 -07:00
gsxdsm	4419bdbd04	Update baseline	2026-07-22 14:32:07 -07:00
gsxdsm	d5df6fc635	docs(FN-6612): refresh test velocity baseline ... Record the W30 measurements, quarantine count, and stale timing-snapshot warning for the weekly velocity report.	2026-07-22 13:47:58 -07:00
gsxdsm	241a5c94ea	chore: bump @earendil-works/pi to 0.81.1 (#2399) ... ## Summary - Bump `@earendil-works/pi-ai` and `@earendil-works/pi-coding-agent` from **0.80.10 → 0.81.1** (exact matched pins). - Update `pnpm-workspace.yaml` overrides so floating `*` consumers (`droid-cli`, `pi-llama-cpp`, runtime plugins) stay on the same ModelRuntime surface. - Refresh pin-guard tests, package-config assertions, and FNXC notes for the new pin. ## What's new in pi 0.81.x - Qwen Token Plan providers - Expanded usage accounting (tools/compaction/branch summaries) - Resilient compaction retries + retry lifecycle events - Full provider-extension registration API - Built-in llama.cpp router management - Provider/catalog fixes (Bedrock env credentials, OpenAI Responses early-stream retry, Codex 272K defaults, extension stream-fallback restore) ## Test plan - [x] `scripts/check-pi-versions-pinned` (4/4) - [x] Typecheck: core, engine, dashboard, cli, pi-claude-cli - [x] `package-config.test.ts` (35) - [x] `provider-registration.test.ts` (14) - [x] `auth-storage-concurrency` + `model-registry-refresh` (15) - [x] `register-model-routes-kimi-k3-supplemental` (1) - [ ] CI gate green - [ ] Spot-check Anthropic OAuth + API key session - [ ] Spot-check openai-codex model picker / supplemental models <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Updated the bundled Pi runtime to version 0.81.1. * Added support for newer models and providers, including Qwen Token Plan. * Improved usage accounting and session reliability. * Strengthened compaction retry handling and provider catalog accuracy. * Added support for the expanded maximum thinking level. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-22 01:32:14 -07:00
gsxdsm	ceaf0cc996	refactor: package code organization wave 14 (#2391) ... ## Summary Wave 14 of package code organization (stacks on #2367 / wave 13). ### Peels | New module | Parent | |---|---| | `types/task-review.ts` | task review + PR review surface types | | `types/documents-artifacts.ts` | documents, artifacts, review-artifact helpers, goal citations | | `task-store/workflow-task-create-ops.ts` | rename of `remaining-ops-4` | | `task-store/task-mutation-ops.ts` | rename of `remaining-ops-2` | Public paths stay stable via `types.ts` / `store.ts` re-exports. ### LOC - `types.ts` ~6264 → ~5871 ### Shims - `types.ts` → peels above (delete-when: consumers import domain modules) - `remaining-ops-4` → `workflow-task-create-ops` (rename complete) - `remaining-ops-2` → `task-mutation-ops` (rename complete) Only `remaining-ops-1.ts` remains of the numbered ops series. ## Test plan - [x] `@fusion/core` typecheck - [x] `review-artifacts` unit tests - [x] `pnpm check:line-count` (baseline updated) - [ ] CI merge gate <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Refactor** - Split task review, document, artifact, and goal-citation type definitions into dedicated shared modules. - Updated task-operation wiring to use the newer task-create/mutation operation surfaces (no API changes intended). - **Documentation** - Corrected inline references and refreshed module headers to match the current task-operation structure and domain naming. - **Tests** - Updated a test import to point to the current duplicate-auto-archive backend implementation source. - **Chores** - Refreshed line-count baseline values to reflect the latest code layout. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-21 23:33:05 -07:00
gsxdsm	3a7684b90e	refactor: package code organization wave 12 (#2362) ... ## Summary Behavior-preserving package code organization (wave 12), continuing after wave 11 (#2333). - **Dashboard client API peels** from `app/api/legacy.ts` into focused modules with stable re-exports: - `git.ts` — remotes, PR management, terminal sessions, git management (`withRepoPath` preserved) - `workspace-files.ts` — file browser + workspace file ops - `provider-status.ts` — auth/CLI and runtime provider status - `github-import.ts` / `gitlab-import.ts` — issue/PR import clients - `run-audit.ts` — run-audit, timeline, org tree, task review - `task-diff.ts` — task diffs and commit associations - `agent-import-generation.ts` — agent import catalog + generation - **Core types peels** from `types.ts`: - `types/run-audit.ts` - `types/planner-intervention.ts` - **Domain rename**: `task-store/remaining-ops-5.ts` → `task-store/task-id-integrity.ts` (call sites updated) - **Line-count ratchet**: `legacy.ts` ceiling ~5665 → ~3339; baseline refreshed No intentional behavior changes; public import paths via `app/api` / `@fusion/core` remain stable. ## Test plan - [x] `@fusion/core` typecheck - [x] Dashboard `tsconfig.app` typecheck (wave12-related errors cleared; pre-existing playwright/plugin env noise unchanged vs main) - [x] ESLint on peeled API modules - [x] `pnpm check:line-count` (baseline updated) - [ ] CI: Lint / Typecheck / Build / Gate <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added dashboard client support for Git remotes/PR workflows, GitHub/GitLab importing, terminals (HTTP/SSE) and PTY sessions, workspace file browsing/editing/search, and task diff viewing with file/ZIP download helpers. - Added new dashboard APIs for planning/onboarding streaming, mission interview flows, provider/auth status, dev server sessions, run-audit/timelines & task review, agent import/generation, and AI title summarization. - Added backup and settings export/import helpers, plus model discovery/usage reporting and task steering actions. - **Refactor** - Modularized dashboard API clients into focused modules while preserving the existing integration style. - **Tests** - Updated a backend-mode SQLite guidance regression test to exercise the intended implementations. - **Chores** - Refreshed internal line-count baselines. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-21 23:10:08 -07:00
gsxdsm	1e05793876	fix(ci): green full-suite bookkeeping after origin/main cutover (#2392) ... ## Summary Restores green merge-gate and package-default suites after repeated `origin/main` merges brought workflow-graph ownership cutover drift into CI. - Align engine/dashboard/core tests with post-cutover contracts (`moveTaskIf`/`deleteTaskIf`, graph handoff, worktree-pool reclaim via `removeWorktree` + `RemovalReason`, multi-step RESUMING parse, soft-pause merge requester, graph-terminal failure surfaces). - Small product fixes needed for real regressions uncovered by the suite: soft-delete refuse before graph routing, skip DUPLICATE step-heading withhold when an explicit marker is present, PG schema applier guards, and related bookkeeping (research promote tool inventory / migration seed, stop shell `psql` in PG admin DDL). - Quarantine/ledger hygiene only where required by standing rules; no timeout/worker appeasement. ## Verification - `pnpm test:gate` ×2 green - `@fusion/engine` full package suite green (~9083 tests) - Targeted core/dashboard clusters green (schema applier, agent-runs UI, settings descriptions, mobile close) ## Test plan - [x] `pnpm test:gate` (twice) - [x] `pnpm --filter @fusion/engine test` - [ ] CI full suite / PR checks on this branch - [ ] Confirm no unrelated product behavior changes beyond the listed regression fixes <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added support for `roadmap-item` native structure kinds, including native structure embeds and metadata validation. * Added Stable and Beta release channel options in General settings. * Added per-action reporting target configuration with clearer “unset” guidance. * **Bug Fixes** * Improved heartbeat/prompt behavior when patrol is disabled. * Prevented deleted tasks from continuing through execution. * Made recovery for explicit duplicate redirects more permissive. * Hardened database migration and test database cleanup to reduce flaky failures. * **Documentation** * Updated settings text for release channels, reporting targets, and inheritance/unset behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-21 23:09:30 -07:00
gsxdsm	7911fdb9b1	fix(release): preserve distilled changelog summaries across releases ... syncRootChangelog rewrote every prior release from raw package notes, so only the latest distilled Highlights view survived. Re-emit already-distilled bodies on sync, keep the archive pointer outside version sections, and restore wiped summaries from release history.	2026-07-21 20:29:46 -07:00
gsxdsm	eef5eb751e	FN-8453: unify concurrency accounting and indicators ... Unify live-agent capacity accounting across engine and dashboard. - Derive Running and Waiting from workflow traits and durable agent liveness. - Apply unified limits to planner, executor, and merge admission while updating dashboard indicators. - Remove duplicate concurrency controls and document the unified operator model. Files changed: .changeset/fn-8453-unified-concurrency.md | 7 + docs/agent-tool-surface-full-loop.md | 4 +- docs/architecture.md | 2 +- docs/dashboard-guide.md | 4 +- docs/settings-reference.md | 4 +- .../skill/fusion/references/fusion-capabilities.md | 4 +- .../core/src/__tests__/live-agent-count.test.ts | 91 ++++---- packages/core/src/index.gate.ts | 6 + packages/core/src/index.ts | 6 + packages/core/src/live-agent-count.ts | 107 ++++++--- packages/dashboard/app/App.tsx | 28 ++- packages/dashboard/app/api/board-workflows.ts | 2 + packages/dashboard/app/components/Column.tsx | 6 +- .../dashboard/app/components/EngineControlMenu.tsx | 26 --- .../dashboard/app/components/ExecutorStatusBar.tsx | 38 ++- .../dashboard/app/components/SettingsModal.tsx | 1 - .../app/components/__tests__/Column.test.tsx | 6 +- .../__tests__/EngineControlMenu.test.tsx | 10 +- .../__tests__/ExecutorStatusBar.test.tsx | 32 ++- .../command-center/CommandCenterControls.tsx | 26 --- .../settings/sections/SchedulingSection.search.ts | 9 - .../settings/sections/SchedulingSection.tsx | 13 -- .../app/hooks/__tests__/useExecutorStats.test.ts | 12 +- packages/dashboard/app/hooks/useExecutorStats.ts | 50 ++-- .../src/__tests__/project-store-resolver.test.ts | 11 +- packages/dashboard/src/project-store-resolver.ts | 14 +- .../register-config-mcp-pi-settings-routes.ts | 3 +- packages/engine/src/__tests__/concurrency.test.ts | 123 +++++++++- .../engine/src/__tests__/project-engine.test.ts | 34 +++ packages/engine/src/__tests__/triage.test.ts | 7 +- packages/engine/src/concurrency.ts | 207 ++++++++++++++++- packages/engine/src/project-engine.ts | 151 ++++++++++-- packages/engine/src/scheduler.ts | 82 ++++++- packages/engine/src/triage.ts | 254 +++++++++++++-------- .../lib/dashboard-browser-safe-core-modules.json | 5 + 35 files changed, 991 insertions(+), 394 deletions(-) Fusion-Task-Id: FN-8453 Fusion-Task-Lineage: 12cfa5df-675d-4fce-b17e-932376544239 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-21 15:30:31 -07:00
gsxdsm	634295c72f	fix(planning): keep questions out of mailbox ... Keep planning questions in their dedicated surface while preserving ntfy alerts, and tighten the desktop planning panes without changing compact or shared layouts.	2026-07-21 10:04:19 -07:00
gsxdsm	860533eff2	FN-8402: extract config, MCP, and Pi settings routes ... Extract config, MCP, and Pi-settings handlers into a dedicated dashboard route registrar. - Move seven configuration and MCP endpoint handlers out of the API-route orchestrator. - Preserve registrar mount precedence and document the expanded route map. - Add registrar coverage and update the inline-route modularity baseline. Files changed: .../src/__tests__/mcp-documentation.test.ts | 2 +- packages/dashboard/src/routes.ts | 303 +-------------------- packages/dashboard/src/routes/README.md | 84 +++--- .../register-config-mcp-pi-settings-routes.test.ts | 61 +++++ .../src/routes/create-api-routes-mount-sequence.ts | 2 +- .../register-config-mcp-pi-settings-routes.ts | 275 +++++++++++++++++++ scripts/lib/routes-modular-baseline.json | 2 +- 7 files changed, 385 insertions(+), 344 deletions(-) Fusion-Task-Id: FN-8402 Fusion-Task-Lineage: f5f71f64-03cf-41cf-9fb2-33046b0c04bf Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-20 09:35:55 -07:00
gsxdsm	e1dddcbfae	FN-8404: extract dashboard domain route registrars ... Move maintenance, AI text assistant, and setup/activity endpoints into focused dashboard route registrars. - Register the extracted domains in the API mount sequence. - Preserve route precedence and document registrar responsibilities. - Add registrar coverage and refresh the modular-route baseline. Files changed: packages/dashboard/src/routes.ts | 948 +-------------------- packages/dashboard/src/routes/README.md | 82 +- .../register-ai-text-assistant-routes.test.ts | 49 ++ .../register-setup-activity-routes.test.ts | 54 ++ .../register-system-maintenance-routes.test.ts | 48 ++ .../src/routes/create-api-routes-mount-sequence.ts | 8 +- .../routes/register-ai-text-assistant-routes.ts | 327 +++++++ .../src/routes/register-setup-activity-routes.ts | 320 +++++++ .../routes/register-system-maintenance-routes.ts | 320 +++++++ scripts/lib/routes-modular-baseline.json | 2 +- 10 files changed, 1176 insertions(+), 982 deletions(-) Fusion-Task-Id: FN-8404 Fusion-Task-Lineage: d6b5be1f-e011-47fc-a7f8-5df89893766f Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-20 00:46:14 -07:00
Phil Larson	fe9269b57b	fix(i18n): restore Chinese roadmap duplicate labels (#2358) ... ## Summary - restores the missing Simplified Chinese duplicate-roadmap report label - restores the missing Traditional Chinese duplicate-roadmap report label - adds a patch changeset for the catalog correction ## Test plan - `pnpm --filter @fusion/i18n test` (5 files, 29 tests) - `pnpm build` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Restored Simplified and Traditional Chinese translations for duplicate roadmap report titles. * Updated the roadmap reporting UI text to clarify when a report is already in the roadmap and ask whether to add the user’s data point. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-20 00:18:53 -07:00
gsxdsm	5c67b19cb2	FN-8394: rescue deterministic quarantined tests ... Restore reliable test coverage and delete quarantined tests that could not be rescued. - Replace process- and database-dependent tests with bounded dependency seams - Restore stabilized CLI, dashboard, and plugin test coverage - Remove unrescuable bundle and merge-worktree test suites and clear the quarantine ledger Files changed: packages/cli/src/__tests__/bundle-output.test.ts | 519 ------------ .../src/commands/__tests__/task-lock-retry.test.ts | 10 + packages/cli/vitest.config.ts | 8 - .../TaskDetailModal.tab-persistence.test.tsx | 2 +- .../__tests__/TaskDetailModal.test-helpers.ts | 7 + .../src/__tests__/dev-server-process.test.ts | 391 ++++----- packages/dashboard/src/dev-server-process.ts | 22 +- packages/dashboard/vitest.config.ts | 21 +- .../merge-reuse-task-worktree.slow.test.ts | 876 --------------------- packages/engine/vitest.config.ts | 7 - .../src/__tests__/process-lifecycle.test.ts | 21 +- .../fusion-plugin-grok-runtime/vitest.config.ts | 2 - .../src/__tests__/async-quality-store.pg.test.ts | 148 +++- plugins/fusion-plugin-quality/vitest.config.ts | 3 +- scripts/lib/test-quarantine.json | 43 +- 15 files changed, 323 insertions(+), 1757 deletions(-) Fusion-Task-Id: FN-8394 Fusion-Task-Lineage: e949b33e-b8d5-4f73-a002-e550b97ee125 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-19 18:59:36 -07:00
gsxdsm	b07f207b00	FN-8403: extract automation and plugin route registrars ... Move automation and plugin HTTP handlers out of the routes aggregator into focused domain modules. - Extract live automation streaming and step-execution helpers - Register automation, routine, webhook, and plugin handlers through the domain registrar - Document plugin route ordering and update modular-route baselines Files changed: packages/dashboard/src/routes.ts | 2779 ++------------------ packages/dashboard/src/routes/README.md | 3 +- .../dashboard/src/routes/automation-live-run.ts | 322 +++ .../src/routes/automation-step-execution.ts | 445 ++++ .../src/routes/plugin-bundled-runtimes.ts | 88 + .../src/routes/register-plugins-automation.ts | 1540 ++++++++++- scripts/lib/routes-modular-baseline.json | 2 +- scripts/line-count-baseline.json | 2 +- 8 files changed, 2604 insertions(+), 2577 deletions(-) Fusion-Task-Id: FN-8403 Fusion-Task-Lineage: 2072d39b-6335-4163-a56a-7d418edc9095 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-19 17:25:02 -07:00
gsxdsm	e0e395a715	FN-8365: enforce dashboard route registrar mount order ... Keep dashboard API registration modular while preserving Express route precedence. - Route all top-level dashboard registrars through a runtime-checked canonical mount sequence - Add mount-order and inline-route-ratchet coverage with CI enforcement - Document registrar ownership and mount-order conventions Files changed: .github/workflows/pr-checks.yml | 3 + AGENTS.md | 2 + package.json | 5 +- packages/dashboard/src/routes.ts | 136 +++++----- packages/dashboard/src/routes/README.md | 276 ++++++++++----------- packages/dashboard/src/routes/__tests__/create-api-routes-mount-order.test.ts | 66 +++++ packages/dashboard/src/routes/create-api-routes-mount-sequence.ts | 54 ++++ scripts/__tests__/check-routes-modular.test.mjs | 28 +++ scripts/check-routes-modular.mjs | 65 +++++ scripts/lib/routes-modular-baseline.json | 3 + 10 files changed, 433 insertions(+), 205 deletions(-) Fusion-Task-Id: FN-8365 Fusion-Task-Lineage: 9c36a263-ed5e-4524-8ea5-71ed3f3e34d9 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>	2026-07-19 15:53:07 -07:00