585 Commits

Author	SHA1	Message	Date
gsxdsm	dca67a79a3	fix(census): a DELIBERATE-LITERAL marker on a ternary arm was invisible (#3099) ... ## The gap The marker works above a statement or a function. It does **not** work in the position people actually use it — on the fallback arm itself, right beside the literal it excuses: ```ts flags ? flags.hold === true /* DELIBERATE-LITERAL — the no-metadata fallback. */ : column === "in-progress"; ``` That comment sits **before the `:` token**, so it's the colon's leading trivia rather than the arm expression's — `getLeadingCommentRanges` at the arm's full start never sees it. The ancestor walk doesn't rescue it either: the next ancestor is the `ConditionalExpression`, whose own leading comments are somewhere else entirely. ## Measured, not hypothesised `in-review-stall.ts` carried a marker in exactly this position **and stayed on the backlog**. The only way I could clear it was to restructure the code into a named set (#3064). That's the tool dictating shape rather than reading intent — and a marker that silently does nothing trains people to stop marking. Given this fleet phase has had several workers reach for `DELIBERATE-LITERAL` (#3056 used it successfully at statement level), the failure mode is one worker's marker working and another's not, for reasons neither can see. ## Scope and controls Scoped to the span between the previous arm (or the condition) and this one, so it can't pick up a comment belonging to anything else. Verified both directions with a probe: | case | before | after | |---|---|---| | marker above the statement | `deliberate` | `deliberate` | | marker on the ternary arm | **`column`** | `deliberate` | | unrelated marker on a neighbouring statement | `column` | `column` (unchanged) | **The real tree's count is unchanged at 51** — nothing is silently reclassified, because the one site that had an arm marker was already converted away. This is forward-looking. ## Not fixed here — pre-existing red on `main` `lifecycle-column-census.test.ts` has two failures (`expected 22 to be 26`, `expected +0 to be 1`) whose fixture arithmetic drifts with real tree counts as fleet conversions land. **Verified identical on `origin/main`** before and after this change, so it isn't mine — but someone should decide whether that fixture ought to be derived rather than pinned, since every fleet merge moves it. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 04:19:11 -07:00
gsxdsm	a7b2a757fa	fix(engine): serialise wedge handling per task, then convert the lane guards it was blocking (5 → 1) (#3087) ... The largest unclaimed census cluster, and the one two earlier fleet passes explicitly declined. ## The standing blocker, taken on Both passes converted these four ids and reverted, each time after the same test went red: ``` task-wedge-notification.test.ts > sends one actionable push and mailbox message per active terminal episode expected 2 calls, got 1 ``` Their diagnosis was right and I have kept it: this branch **resolves** a wedge episode, `handleTaskUpdated` starts it fire-and-forget from a synchronous `(task) => void` listener, and **any** await introduced before the resolve lets a re-wedge arriving close behind reach `claim` while the previous episode is still active — `claimed: false`, second operator notification silently dropped. Column resolution needs an await, so the conversion could not be made safe from inside the branch. Both notes named the fix and left it for "whoever owns the wedge episode contract": *serialise wedge handling per task*. This PR does that, then takes the conversion. ## 1. Serialisation `enqueueWedgeHandling` chains handling per task id, so resolve-then-claim keeps its order however many awaits either branch acquires. Details that matter: - **Keyed by task, not global** — different tasks stay concurrent, so this is not a throughput regression on a busy board. - **The map entry is dropped when its chain drains**, and only if no later link was appended while it ran, so it does not grow with the task table. - **Links never reject.** `maybeNotifyTaskWedge` already owns its error handling; a rejected link would poison every later notification for that task. ## 2. The conversion it was blocking The four ids are an enumeration of *"every lane except review"* — the lanes whose occupancy proves a wedged card's lifecycle has visibly resumed. On a renamed board none of them matched, so a recovered card's episode never resolved. Two consequences, and the second is worse than the first: 1. the operator keeps an open "needs operator action" alert for work that has moved on; 2. an active episode **suppresses re-claim**, so the *next* genuine wedge on that task is never delivered. Membership over the four roles, legacy-seeded, so an unconverted board resolves exactly the four ids it used to compare. ## Measured **The acceptance test the earlier notes named is the gate on both halves.** With the conversion and *without* the serialisation, "sends one actionable push and mailbox message per active terminal episode" fails exactly as they reported. With the serialisation, green. I reproduced their finding rather than taking it on trust — it is the evidence that the serialisation is load-bearing and not incidental refactoring. | | result | |---|---| | `task-wedge-notification.test.ts` | **15/15** (2 new) | | notification suites | **11 files / 234 tests pass** | | `tsc --noEmit -p packages/engine` | clean | | census `--strict`, `check-lane-wiring`, `check-inert-sync-lane-conversions`, `check-fnxc-future-dates` | clean | **MUTATION**: restoring the four literals fails the renamed-recovery case and leaves its paired negative green. **A vacuity I caught and fixed, worth stating plainly.** My first version of the renamed case recovered the card with `status: "queued"`. `hasProgressed` is an OR whose other arm is *"status is a non-failed string"* — so that arm answered true and the column comparison never ran. The mutation did not fail it. The case now clears `status` and `error` together, which makes column membership the only thing that can resolve the episode, and the paired negative uses the identical shape so only the lane differs. ## Census | | before | after | |---|---|---| | `notification-service.ts` | 5 | **1** | | repo backlog | 71 | **67** | ## The remaining 1, flagged not guessed `isManualMergeHold` (`task.column !== "in-review"`) is sync, and so is its only caller `classifyWorkflowTransitionNotification`, reached from the same `handleTaskUpdated` listener. Converting it means making that whole chain async — a change to notification *classification ordering* against every other `task:updated` handler, which is a different contract from the episode one this PR owns. The serialisation added here does not cover it: it wraps wedge handling, not transition classification. Threading a pre-resolved `LifecycleColumns` in as a parameter is the likely fix, and it wants the same gate-placement judgement applied deliberately rather than swept in behind this. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 04:10:03 -07:00
gsxdsm	6949f22ef8	fleet: resolve the same-column handoff review target (census 84 → 83) (#3076) ... ## Census | | column guards | |---|---| | before | **84** | | after | **83** | `moves.ts`: 2 → 1. One of its two sites converts; the other **must not**, and that difference is the useful part of this PR. ## Converted — the move target at the same-column handoff ```ts if (internal.fromHandoff && toColumn === "in-review") ``` Against the literal this **never fired on a renamed board**, so a same-column handoff into a renamed review lane silently took the *other* branch — the sync-SQLite path, which throws under PostgreSQL. It now asks `moveReviewColumns`: the broad membership set (`mergeOrchestration ∪ mergeBlocker ∪ humanReview`) already resolved **three lines above** for the merge-queue pair. Same value, so this branch cannot disagree with the enqueue/dequeue calls that receive it. ## Not converted — the archived fallback arm I named it, and `archived-column-gate-parity.test.ts` went red on **`TypeScript encoding changed`**. That guard's argument holds: the archived gate is enforced in three encodings, the SQL halves still compare the raw string, and moving the TypeScript half alone is the split brain it exists to prevent. Restored inline **with a note recording the measurement**, so the next person doesn't retry it and rediscover the same red. This is the second time that guard has stopped me this session. It's doing exactly what it was built for. ## On the pre-existing red That suite is red on `origin/main` for an unrelated raw-SQL drift (#3072 fixes it — the drift is from my own merged #3042/#3046). I verified this branch produces the **identical** failure and no other, so it doesn't compound it. ## Measured | check | result | |---|---| | moves / handoff / merge-queue suites | green | | four gates + strict census | green | | core `tsc` | clean | | parity suite | same single raw-SQL failure as `origin/main`, nothing added | Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 03:57:51 -07:00
gsxdsm	9e242ea294	fix(engine): backlog pressure called every dependency unfinished on a renamed board (#3081) ... ## The third lane question This reporter had **three** lane questions. Two were resolved when the file's query-blindness was fixed — hold and wip, both through `resolveProjectColumnsForRoles`. The third sat one method down and was never touched: ```ts if (dependency.column !== "done") return false; ``` One board, two lane answers. ## What it cost On a renamed board every dependency reads unfinished, so `isRunnableCandidate` rejects every card that has one. The backlog-pressure alert then names **only dependency-free cards** as the runnable ones. The failure mode is the quiet kind: the report still renders, the counts are right, and the candidate list looks plausible. The operator is told the queue is blocked on nothing in particular. No default-board test can see it — which is exactly why the earlier conversion of this same file, which fixed its reads, left this behind. ## Fix `finishedColumns` (complete ∪ archived) resolved once by the async caller alongside hold and wip, then passed into the sync predicate. - **Required parameter, not optional-with-a-literal-default.** An optional parameter leaves `done` in the file as a silent fallback and the next caller gets pre-conversion behaviour by writing nothing. - **Archived is included** because a dependency that has been archived is finished too — and this reporter already reads with `includeArchived: true` precisely so archived blockers resolve. - **Async resolution.** `resolveProjectColumnsForRoles`' only store read is `listWorkflowDefinitions()`, a project-wide async read that works under PostgreSQL. That is the line between a real conversion and the inert sync-IR kind (#3058), and the new test supplies its board through that same reader so it exercises the production path. ## Census | | before | after | |---|---|---| | `backlog-pressure-reporter.ts` | 1 | **0** | ## Measured - One new case; file **11/11 pass**. - **MUTATION**: restoring `dependency.column !== "done"` fails it. - The case asserts **both directions in one test** — a dependency resting in the board's own complete lane makes its card runnable, *and* a dependency still in the hold lane still blocks it. Asserting only the first would pass against a predicate that had simply stopped checking dependencies. - The file already had a `RENAMED_IR` scoped to its second describe; mine is a distinct `RENAMED_DEPENDENCY_IR` with different lane names. I hit the shadowing first and the test failed as `under-threshold` — worth noting because a same-named fixture that silently resolves to the *other* board is precisely how a renamed-lane test goes vacuous. - `tsc --noEmit -p packages/engine` clean; census `--strict`, `check-lane-wiring`, `check-inert-sync-lane-conversions`, `check-fnxc-future-dates` clean. ## Flagged, not guessed Adjacent census entries I looked at and deliberately left: - **`executor.ts` (4)** — all inside a sync `task:moved` listener. Converting via `resolveTaskWorkflowIrSync` would be inert for #3058's reason, and making the listener async reorders it against every other subscriber. Correctly out of scope, as #3048 judged. - **`triage.ts:724`** — half-converted in the same shape: `disposeLanes.hold`/`.intake` come from a sync resolver, so the resolved arms are themselves inert and "finishing" the guard would add a third inert comparison. - **`auto-merge-finalization.ts` (2)** — one is the resolver's documented degraded fallback (the live arm calls `columnHasFlag`), the other is already recorded as a deferred signature-widening whose cost exceeds the error string it sharpens. - **`in-review-stall.ts:196`** — an explicitly marked DELIBERATE-LITERAL no-metadata fallback. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 03:51:43 -07:00
gsxdsm	3c531d984c	fix(engine): self-healing lane cluster round 2 — 38 → 26 (two sweeps could disturb live work) (#3078) ... The largest census cluster became **unclaimed again** when #3055 closed conflicting. I had closed my own #3050 an hour earlier expecting #3055 to land, so this re-applies the conversions #3047 and #3049 did not cover. **Re-applied from current main rather than rebasing the closed branch.** The conversions are small; the conflict archaeology is what went wrong last time — nine conflicts against #3049, several on variable names identical to mine, and my mechanical fixup corrupted the file badly enough that I aborted. Starting from main cost less than resolving that and carries no risk of resurrecting a stale line. ## Census | | before | after | |---|---|---| | `packages/engine/src/self-healing.ts` | **38** | **26** | | repo-wide column guards | 84 | **72** | ## Three sweeps, existing role helpers only | sweep | roles | what it did on a renamed board | |---|---|---| | worktree metadata | terminal + wip + review | rebound finished cards every pass, **and the FN-5256 liveness guard went silent** | | orphaned pending step results | wip | **could rewrite `pending` results under a live executor run** | | agent-link drift | wip + review + terminal | evaluated agents whose task was plainly still executing | Two of these disturb **live** work, which is why they were worth redoing now rather than leaving for the next fleet round: - The worktree-metadata sweep clears `worktree`/`branch` metadata. Its liveness guard is the thing standing between that and a running shell (FN-5256). Keyed on ids, it matched nothing on a renamed board. The scope-override safety condition beside it now reads the **same resolved sets**, so the two cannot disagree about which lanes are live — previously they were two independent literal lists. - The orphaned-step-results sweep's own header says it must never touch an executor-owned row. The id-keyed skip made it do exactly that. Resolved once per sweep, outside the paging loop, so a large board still pays one resolve. ## Flagged, not guessed — the 26 that remain Unchanged from my earlier audit and re-verified on this base: - **Sync predicates** (`isWorkspaceOwnerLive`, the pause-abort classifier, the phantom-binding check, the `task:moved` listener guards). No store handle; converting means a signature change or making a synchronous event listener async, which reorders handlers against a synchronous emitter. - **Already-converted fallbacks** — `own.length > 0 ? own.includes(...) : task.column === "in-review"`. The resolved answer wins; the literal is the documented no-metadata path. - **The notification-route `fresh.column === "todo"` sites** — measured previously: any `await` before the wedge resolve drops an operator notification. Needs the wedge-episode contract, not a column pass. ## Verification self-healing suites **204 passed** · agent-link-drift + query-filter-blindness **83 passed** · `pnpm test:gate` 161 + 13 + 487 + 71 · lint · census `--strict` · lane-wiring — green.	2026-07-31 03:48:44 -07:00
gsxdsm	98aac40ca8	fleet: reads.ts 2 → 0 lifecycle-column guards (#3057) ... > **Rebased.** Main landed another worker's conversion of the review gate while this was open — the overlap was a whole rewritten function, so I reset to main and rebuilt only my remaining delta on top of their work rather than resolving hunks. Their conversion is kept as-is. ## Census | | column guards | |---|---| | before | **104** | | after | **102** | `reads.ts`: **2 → 0**. ## Two changes **1. `includeColdStorage`** asks whether the *caller* is filtering to the archive lane. Against the literal, a caller filtering to a renamed archive lane took the false branch — cold storage was skipped and the filtered view returned only whatever archived rows still sat in `project.tasks`, **a short list presented as the whole archive**. Still literal on main; converted here. **2. Both fallbacks become named sets** instead of inline arms — including the one on the just-landed review gate. ## The second point is the one worth the fleet's attention This is bookkeeping correctness, not style. The census counts an inline comparison **whether or not it sits in a fallback branch**, because its `traitFallback` hint is advisory and never changes `kind`. So a correctly-converted guard with an inline legacy arm **stays on the backlog permanently**, and the number stops distinguishing real debt from documented degraded answers. Concretely: converting with an inline fallback is correct work that scores **zero**. My own first pass at this file did exactly that. There are roughly **12 such sites** across the tree — `github-tracking-state`, `planner-overseer`, `async-mission-store-queries`, `register-task-workflow-routes`, `restart-recovery-coordinator` — and I have that cluster converted and ready to open next. ## Measured | check | result | |---|---| | reads / get-task / stall suites | 5 files, **87 tests green** | | renamed-archive PG suite | green | | strict census | green; `tsc` clean | | unconverted boards | byte-identical — the named sets hold the previous ids | <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Review and archive checks now work correctly with resolved workflow columns while retaining legacy compatibility. * Fresh agent activity is detected in resolved review lanes. * Lists filtered by a resolved archive lane now include archived items stored in cold storage. * **Chores** * Updated internal lifecycle tracking baselines. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 03:43:03 -07:00
gsxdsm	3c12a51627	fix(core): the merge result reported a column the finaliser did not write (merge-queue-ops 3 → 0) (#3071) ... Largest unclaimed census cluster in `packages/core` — three `done` literals in `mergeTaskImpl`. Two of them produced **wrong state**, not merely a guard that stopped firing. ## 1. The result overrode the writer `moveToDoneImpl` resolves the board's completion lane and writes it onto the task object: ```ts task.column = completeColumn; // task-artifacts-ops.ts ``` Both merge call sites then did: ```ts result.task = { ...task, column: "done" }; ``` putting the literal back over what the writer had just set. Every `task:merged` listener — GitHub tracking, the auto-merge handoff — was told the card landed in `done` while the persisted row said `shipped`. The row was right and the event was wrong, which is the worse direction: the listeners act on the event, not the row. Fixed by reading back what the writer set (`{ ...task }`). Deliberately **not** a second resolution — that would only be a second chance to disagree with the finaliser. ## 2. The guard disagreed with the writer The already-complete short-circuit asked `task.column === "done"`, while the finaliser it guards short-circuits on the resolved `task.column === completeColumn`. On a renamed board those two answers differ, so a card already resting in the board's completion lane fell through and the merge ran again against a branch that was already landed and deleted. Converted with the **same resolution and the same shape** — a single first-match column, not membership — because the whole point is that these two answers cannot differ. A workflow declaring no complete lane resolves to `undefined`, which matches no column; the finaliser refuses such a board explicitly one function later. ## Census | | before | after | |---|---|---| | `merge-queue-ops.ts` | 3 | **0** | ## Measured - Two new cases added to `merge-blocker-renamed-review-lane.test.ts` (same renamed-board fixture, same PG harness) — file **5/5 pass**. - **MUTATION**: restoring either literal fails **both** new cases and leaves the three pre-existing ones green. - Reached with **no git fixture**: with no branch present, `git rev-parse --verify` fails and the function takes its own documented *"branch not found — moving to done without merge"* path — which is exactly the path that calls `moveToDone` and then builds the result. No repo setup, no flake surface. - `packages/core` targeted run: **38 tests pass**. - `tsc --noEmit -p packages/core` clean; census `--strict`, `check-lane-wiring` ("none added"), `check-fnxc-future-dates` clean. ## Not done here (flagged, not guessed) The other `done`/`archived` literals still in the core census are each blocked for a *different* documented reason, so sweeping them into this PR would have meant guessing: - `agent-store.ts:236` — a pure formatter over `Pick<Task,"column">` that prints the column for a human; degrades gracefully and has no store to resolve from. - `async-mission-store-queries.ts` — already converted with caller-threaded lane sets. - `taskRevert.ts:119` — classifies a **neighbour** task; the only flags in scope describe the modal's own task, so wiring them would answer the question for the wrong row. Needs per-neighbour flags. - `moves.ts:310` — a **refusal**, where a legacy-seeded superset is the documented hazard rather than the safe direction. Wants its own change with its own test. - `mission-store.ts:2332` — a sync SQLite path with no async seam. Each is real debt; none is a mechanical conversion. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 03:40:11 -07:00
gsxdsm	8eef8852a0	fleet: 4 long-tail fallback arms become named sets (census 101 → 97) (#3064) ... ## Census | | column guards | |---|---| | before | **101** | | after | **97** | The single-guard long tail is **19 files**. This converts the four whose legacy arm is unambiguously a fallback on an already-converted guard; the other 15 are flagged below rather than guessed at. ## Two shapes **`in-review-stall.ts`, `stalled-review-detector.ts`** — the resolved answer with an inline legacy arm: ```ts reviewColumns ? reviewColumns.has(col) : col === "in-review" → (reviewColumns ?? LEGACY_REVIEW_LANES).has(col) ``` **`merger.ts`, `in-process-runtime.ts`** — belt-and-braces: ```ts col !== (lifecycle?.complete ?? "done") && col !== "done" ``` That accepted the resolved lane **or** the legacy id, stated twice. A union set says it once, so the two halves can't drift apart — which is the real risk with a duplicated condition. ## A finding for anyone else marking fallbacks `in-review-stall.ts` **already carried a `DELIBERATE-LITERAL` marker** on that arm and was counted anyway. The marker sits in a comment *inside a ternary*, which the census's leading-comment lookup doesn't reach. So: **naming the set works, marking it does not.** Worth knowing before someone marks a fallback and expects the count to move. ## No behaviour change `new Set(["in-review"]).has(x)` answers exactly what `x === "in-review"` answered, and the union sets accept exactly the two lanes their conditions already accepted. ## Flagged, not converted The remaining 15 single-guard sites need individual judgement, not a mechanical pass: - **plain unconverted guards with no resolution in scope** — `audit-ops`, `lifecycle-ops`, `merge-queue-ops`, `task-id-integrity`, `backlog-pressure-reporter`, `ephemeral-worker-manager`, `ResearchTaskActionModal` - **sites where the literal IS the answer** — `eval-signal-collector` maps a column to an archive-vs-done *label*; `TaskCard` reads a completion timestamp - **already resolved on their line** — `triage.ts`, `restart-recovery-coordinator.ts`, both covered by open PRs ## Measured | check | result | |---|---| | core stall suites | 4 files, **85 tests green** | | engine merger/runtime suites | **1044 tests green** | | five gates + strict census | green | | `tsc` (core, engine) | clean | Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 03:37:18 -07:00
gsxdsm	c220455e3a	fleet: 10 inline fallback arms become named sets (census 102 → 92) (#3061) ... ## Census | | column guards | |---|---| | before | **102** | | after | **92** | Five files drop to **0** guards each. Baseline re-recorded in the same commit. ## A cluster the census could not distinguish from real debt **Every site here is already converted.** Each reads resolved lanes when it has them and falls back to a legacy id when it doesn't: ```ts reviewColumns ? reviewColumns.has(task.column) : task.column === "in-review" ``` The census counts an inline comparison **whether or not it sits in a fallback branch** — its `traitFallback` hint is advisory and never changes `kind`. So ten correctly-converted guards sat on the backlog permanently, and the number stopped distinguishing *work still to do* from *documented degraded answers*. Naming the fallback set fixes the bookkeeping without touching behaviour: `new Set(["in-review"]).has(x)` answers exactly what `x === "in-review"` answered. ## Files | file | sites | what they gate | |---|---|---| | `restart-recovery-coordinator.ts` | 4 | three shared review gates + one `??` default | | `github-tracking-state.ts` | 2 | complete / archived lane predicates | | `planner-overseer.ts` | 2 | wip / review classification | | `async-mission-store-queries.ts` | 2 | terminal complete / archived | | `register-task-workflow-routes.ts` | 2 | wip promotion target, archived respecify guard | **No behaviour change is claimed and none is intended** — that's the point. These were already right; only the accounting was wrong. ## Worth the fleet's attention Converting a guard while leaving an inline fallback is **correct work that scores zero** on the census. My own first pass at `reads.ts` did exactly that — behaviourally correct, census unmoved. Anyone converting this way is doing real work the number won't credit, and the backlog will look stuck. ## Measured | check | result | |---|---| | engine suites | **173 tests green** | | core mission suites | **70 tests green** | | dashboard route suites | **211 tests green** | | five gates + strict census | green | | `tsc` (core, engine, dashboard) | clean | <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Standardized fallback handling for workflow stages, including in-progress, review, completed, and archived states. * Preserved existing behavior when explicit workflow column settings are available or unavailable. * Improved consistency across task tracking, planning, and recovery workflows. * **Chores** * Updated lifecycle tracking baselines to reflect current source-file coverage. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 03:34:27 -07:00
gsxdsm	18fab9b8e5	fleet: name the WIP half of an existing fallback (census 88 → 87) (#3070) ... ## Census | | column guards | |---|---| | before | **88** | | after | **87** | ## What `ephemeral-worker-manager.ts` answers its unresolvable-workflow default two ways, two lines apart: ```ts if (TERMINAL_TASK_COLUMNS.has(task.column)) return true; // named set — not counted return task.column !== "in-progress"; // inline — counted ``` Both are the **same documented fallback** — the block carries one `DELIBERATE-LITERAL` marker covering both — but only the inline one was on the backlog, because the census reads comparisons regardless of which branch they sit in while a set is a definition. Naming it makes the pair consistent and stops the site reading as unconverted debt. ## Correction to my own flag in #3064 I listed `ephemeral-worker-manager`, `backlog-pressure-reporter`, `merge-queue-ops` and `lifecycle-ops` as *"plain unconverted guards with no resolution in scope."* **That was wrong for all four.** Each already imports the resolvers — 7, 4, 3 and 2 references respectively. I wrote the flag without checking, which is the same mistake as an untested deferral rationale, just inside a PR body instead of an issue. Re-examined, the other three are genuinely harder rather than unresolved — and these are the real reasons: - **`backlog-pressure-reporter:197`** classifies a **dependency**, a different row from the one the caller resolved. Per-dependency resolution is needed or it repeats the wrong-row shape that `taskRevert` is blocked on. - **`lifecycle-ops:655`** guards an emit whose **target** is also a literal (`to: "archived"`). Converting the guard alone leaves the pair inconsistent — the move-target half is invisible to this census. - **`merge-queue-ops:352`** is an early return on an already-complete task inside a merge path that resolves lanes elsewhere; the placement needs its own judgement about which resolution it should share. They stay flagged, now with the real reason rather than an unchecked one. ## Measured | check | result | |---|---| | ephemeral-worker suites | green | | four gates + strict census | green | | engine `tsc` | clean | Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 03:31:03 -07:00
gsxdsm	141f54e51d	chore(core): mark the agent-store status formatter DELIBERATE-LITERAL (census 101→99) (#3063) ... Fleet phase. `packages/core/src/agent-store.ts` was the **last** census file with no branch, worktree, or open PR against it. Claim published by pushing the branch before starting. ## Census before / after | | total | this file | |---|---|---| | before | **101** | 2 | | after | **99** | 0 | `--strict` exits 0, baseline re-recorded. **Reclassification, not conversion** — the line is unchanged. ## Already decided, in prose the census cannot read The site was flagged earlier today by another pass, as `FLAGGED AND LEFT COUNTED`: a pure formatter over `Pick<Task, "column">` with no store and no task id, whose output is a human-readable status line. On a renamed board it falls through to `(<column>)` — still accurate, just less specific. Converting it would mean threading a lane resolution into a string builder. That reasoning is right and I did not revisit it. The only gap was mechanical: a prose note is invisible to the tool, so the site kept reading as backlog. ## This completes the sweep of unclaimed files Third and last of these. Together with #3056 (fallback arms) and #3060 (dead sync path), **every census file that was unclaimed this phase has now been examined, and not one of them needed a conversion.** Each was either a three-state fallback arm — where the legacy id is the answer when resolution fails, and removing it would break the caller — or a site a previous pass had already reviewed and deliberately kept. That is the finding worth carrying forward. The remaining **99** is not a work queue: a meaningful share is correct code the tool cannot distinguish from owed work, and every fleet pass pays to re-derive it. Since all workers rank by the same `byFile` output, we also converge on the same top file — which is how `self-healing.ts` drew three parallel conversions, two of which are now unmergeable. Two cheap changes would fix both symptoms: 1. **Mark reviewed-and-kept sites** so the count means *conversions owed*. Two lines each. 2. **Push the branch at claim time** so `git ls-remote` is authoritative before work starts. Costs nothing; I did it for all three of these. ## Verification - `census --strict` exit 0; `tsc --noEmit` **0 errors** - `check:fnxc-future-dates`, `check:lane-wiring` — exit 0 - Comment-only diff; no behaviour change Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 03:16:16 -07:00
gsxdsm	581e6fba43	chore(core): mark the async-mission fallback arms DELIBERATE-LITERAL (census 108→106) (#3056) ... Fleet phase. Claimed `packages/core/src/async-mission-store-queries.ts` — **the only census file with no branch, no worktree, and no open PR against it.** Claim published by pushing the branch before doing any work. ## Census before / after | | total | this file | deliberate | |---|---|---|---| | before | **108** | 2 | 128 | | after | **106** | 0 | **130** | `--strict` exits 0, baseline re-recorded in the same commit. **This is a reclassification, not a conversion.** The same two lines are still there. A reader comparing 108 → 106 against my #3047's 126 → 121 should know only the latter changed behaviour. ## Why marking is the right answer here Both sites are the **fallback arm** of the three-state rule: ```ts terminalColumns?.complete ? terminalColumns.complete.has(column) : column === "done"; ``` `terminalColumns` undefined means the caller could not resolve lanes. The legacy id is then the only answer that keeps the query working at all — converting it would delete the fallback and make an unresolvable caller return nothing. The census counts the literal, but **the literal is the design**. The file's own comment shows a previous worker already reached this conclusion. Nothing recorded it in a form the tool reads, so it stayed in `byFile` as apparent backlog for the next pass to re-derive. ## The finding this makes concrete I checked five unclaimed files this phase (`agent-store`, `github-tracking-state`, `planner-overseer`, `auto-merge-finalization`, this one). **Every site in them was either a fallback arm or an already-documented deliberate leave** — `agent-store.ts:236` carries a comment from today's fleet phase explaining why it stays. So the remaining count is not a work queue. A meaningful share is correct code the tool cannot distinguish from owed work, and each fleet pass pays to re-derive that. Marking them is cheap, mechanical, and makes the number mean "conversions owed" — which is what every worker reads it as when picking a cluster. I marked only the file I claimed. The others belong to whoever holds them. ## Verification - `census --strict` exit 0; `tsc --noEmit` **0 errors** - `check:fnxc-future-dates`, `check:lane-wiring`, `check:sql-column-literals`, `check:inert-flag-seams` — all exit 0 - No behaviour change: the two expressions are byte-identical, only comments added ## Note on the marker's granularity The first marker covered only `isComplete` — the census attaches markers by *preceding comment*, so the sibling `isArchived` needed its own. Caught by re-running the census (2 → 1, not 2 → 0) rather than by reading. Worth knowing before marking a group of related literals. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 03:13:09 -07:00
gsxdsm	b16318d3e3	gate: the inert-sync-lane check missed the Set-membership spelling (#3068) ... ## The check I shipped in #3062 has a hole, and there is an open PR standing in it #3062 counts `to === parked.complete`. **#3065 rewrites exactly that into `parked.terminal.has(to)`.** #3065's change is **correct and should merge** — a board may declare more than one complete-trait column, so a single `parked.complete` was genuinely wrong, and the PR fixes a red main. But the answer still comes from `resolveTaskParkedColumnsSync`, which resolves through `store.resolveTaskWorkflowIrSync` and therefore always describes the default board. The guard is exactly as inert; it simply stopped being a comparison node, and my check only counted comparisons. ## Measured, both ways Applying #3065's rewrite shape to `scheduler.ts`: | | result | |---|---| | check as shipped in #3062 | **20 → 15**, exit 0, prints *"total fell — re-record with `--update-baseline`"* | | this PR | **20 → 18**, the three `.has()` guards stay counted | The shipped behaviour is the bad half: it does not merely miss them, it invites re-recording a smaller baseline, permanently retiring sites that are still inert. And on the case the ratchet actually exists for — a **fresh literal** converted via the Set spelling: | | result | |---|---| | check as shipped | **exit 0** — missed | | this PR | **exit 1** — caught, `20 → 21` | ## What changed - `terminal` (plus `lanes`, `columns`) added to the role-field vocabulary — Set-valued roles, not single ids. - Membership calls counted alongside comparisons: `X.<role>.has(...)` / `.includes(...)` where `X` is sync-resolved, inline or via a local. Neither exit code changes on current main: still 20, still exit 0. ## The pattern, stated plainly This is the **second** evasion of this check, found the same way as the first. #3062's own body records the first: the initial draft matched only the local-variable spelling and a mutation run proved the inline `resolveX(...).review` walked straight past it. Both times the guard was correct about the shape in front of it and blind to a trivially different spelling of the same defect. Worth generalising rather than patching a third time — the durable fix is to key on **the source** (any value derived from `resolveTaskWorkflowIrSync`) rather than enumerate the syntax that consumes it. That is a dataflow question and a larger change than this; recording it here as the known limit rather than claiming this version is complete. Related and unresolved: the same "a rewrite makes the counter drop without the guard changing" shape is live in the census itself — see my comment on #3057 about `LEGACY_*` named sets, and #3058, where ten guards left the census for zero behaviour change. ## Census before / after ``` before: COLUMN guards (the backlog): 88 after: COLUMN guards (the backlog): 88 ``` Unchanged — this converts nothing. It stops a counter from falling for the wrong reason. ## Verification `pnpm check:inert-sync-lanes` exit 0 · `test:gate` exit 0 · lifecycle-column census exit 0 · `pnpm lint` clean. Gate-script only; no production file touched (`scheduler.ts` restored clean after every mutation run).	2026-07-31 03:03:41 -07:00
gsxdsm	bdedb6cf1a	gate: fail the build on a NEW inert sync-lane conversion (#3062) ... ## Claim, and why it turned into a gate I claimed the largest unclaimed unflagged cluster, `executor.ts` (4 guards at 3557/3581/3632/3642). All four are conditions of a **synchronous** `store.on("task:moved", …)` listener — the same class as `scheduler.ts`. Converting them needs either an `await` in a sync prologue or the sync resolver, and the sync resolver is inert. `executor.ts` already says so, at line 10459, dated 2026-07-30: > **THE SYNCHRONOUS RESOLVER IS A NO-OP IN PRODUCTION.** … every sync-resolved conversion resolves the DEFAULT workflow and answers with the legacy ids no matter what board the task is on. That makes a sync conversion cosmetic: the census counts it as converted, `--strict` goes down by one, and the guard behaves exactly as the literal did. **Worse than leaving the literal, because the number says the site is done.** The next day, #3051 did exactly that to ten `scheduler.ts` arms. Census fell by ten; nothing changed on any board (refuted live in #3058). So the finding was already written down, in the file a converter would be reading, in capitals — and the fleet phase produced the defect anyway. **A comment cannot fail a build.** Converting `executor.ts`'s four the only available way would have made me the third instance. I flagged them and built the guard instead. ## What the check does Per file: finds functions reaching `resolveTaskWorkflowIrSync`, the locals assigned from them, and the `===`/`!==` guards consuming those roles. Baselined per file; **fails on a rise.** Not zero, deliberately. The existing sync guards are real and documented — the scheduler's listeners genuinely cannot `await` today and their authors said so. Demanding zero forces a revert or a day-one exemption marker. What must not happen is *more* literals quietly becoming inert-resolved. Complements `check-inert-flag-seams.mjs`, which catches the opposite shape (a lane parameter **no** caller supplies). This catches a parameter that **is** supplied, from a source that always answers the same thing — which passes that check cleanly. ## Why the shape is invisible The obvious reading is wrong, and it is what makes this survive review. The helper does **not** receive `undefined` and fall through to `?? "in-review"`. It receives a **real IR that resolves real traits** — the default board's — so it answers with full confidence and the `??` arms beside it are dead code. ``` tsc passes the value is a string, correctly typed tests pass on the default board the constant answer IS the right answer the census DROPS it counts comparisons against literals, and the literal really is gone ``` ## Mutation evidence — including one against this check itself | Mutant | Result | |---|---| | baseline | exit 0, 20 guards in `scheduler.ts` | | convert one more literal to a sync-resolved lane (the #3051 move) | **exit 1, 20 → 21** | | convert the same literal to an **async**-resolved lane | exit 0 — correctly silent | The first draft **failed its own mutation test**: it matched only the local-variable spelling (`const parked = resolveX(...)` then `parked.review`), which is what #3051 used, and the inline spelling `resolveX(store, id).review` walked straight past it while being exactly as inert. A ratchet one rewrite evades is worse than none, because the green result reads as proof. Both spellings now count. ## Limits, stated so nobody over-trusts it Sources are matched **within a file by function name**, so a helper imported from another module is not followed — this finds the dominant local-helper shape and will miss a cross-module one (`resolvePlannerLanes`, consumed in `executor.ts`/`triage.ts`, is currently outside its reach). It proves a guard consumes a sync-resolved answer, not that the answer is wrong for every caller. Tests are excluded. Treat a report as a pointer to investigate. ## Census before / after ``` before: COLUMN guards (the backlog): 104 after: COLUMN guards (the backlog): 104 ``` Unchanged by design — this converts nothing. It stops the count from moving for the wrong reason. Worth recording alongside it, measured across the current backlog: **21 of 104 already carry an explicit flag note**, **51 are `self-healing.ts`** (concurrently claimed by **#3055, #3050 and #3049** — three PRs, one file, still worth de-conflicting), and **28 are genuinely unclaimed and unflagged**, the largest being these `executor.ts` four. The cluster-sized work is close to exhausted; what is left is scattered and mostly blocked, which is the pressure that produced #3051. ## Verification `test:gate` exit 0 · `pnpm lint` clean · lifecycle-column census exit 0 · `pnpm check:inert-sync-lanes` exit 0. No production file touched.	2026-07-31 02:57:32 -07:00
gsxdsm	af470f7c05	convert(engine): self-healing lane cluster 56 -> 38 guards (repo 126 -> 108) (#3049) ... ## Census before / after ``` before after self-healing.ts column guards 56 38 repo-wide COLUMN guards (backlog) 126 108 ``` `self-healing.ts` was the largest single cluster by a wide margin — 56 guards against 12 in the next file. Baseline re-recorded in the same commit; `--strict` green. ## Converted: 15 guards across 11 sweeps Existing helpers only — `resolveProjectColumnsForRoles` with `TERMINAL_ROLES` / `REVIEW_ROLES` / `countsTowardWip` / `hold` / `archived`, the same shape this file already uses. No new helper, no new resolution pattern. What each was silently doing on a renamed board: | sweep | behaviour before | | --- | --- | | `archiveStaleDoneTasks` | **both** guards inert, so every card counted as an active dependent and the sweep archived **nothing at all** | | `reconcileDependencyBlockingLeases` | no holder matched, so a stale file-scope lease blocking an unmet dependency was never cleared | | `reconcileCompletedBlockedTasks` | work whose blocker had cleared stayed parked instead of advancing | | `reconcileInReviewUnmetDependencies` | a card sat in review with unmet dependencies and no rebound | | `reclaimStaleActiveBranches` | archived cards were eligible for branch reclaim | | `reconcileInReviewBranchRebind` | the rebind list was empty | | `autoReboundPausedScopeDecayDetailed` | no card was ever seen as executing | | `detectStalledCards` | finished cards counted as stall candidates | | `recoverApprovedStrandedAiMergeCommit`, `recoverDriftedAgentTaskLinks`, `cleanupStaleTempMergeWorktrees` | same shape | **Reused rather than duplicated:** `recoverWedgedActiveMerge` already resolves `wedgedReviewColumns` via `resolveReviewColumnsFor` three lines above the site I was converting, so the site now uses it instead of a second resolution of the same question. ## One site I converted and then reverted `clearStaleBlockedBy`'s memo closure carries an FNXC note stating the literal is **deliberate**: the closure only decides whether to re-log an already-logged blocker, so a renamed board costs a duplicate log line — not a wrong lifecycle decision — and restructuring a sweep's control flow to convert a logging decision is the wrong trade. I read that note *after* editing the line. Restored. Worth flagging separately: **it has the reasoning but no `DELIBERATE-LITERAL` marker**, so the census keeps counting it and it re-appears in the backlog as if unexamined. That is a marker gap, not a conversion gap — the next person will make the same mistake I did. ## Not converted — flagged, not guessed Ten of the twenty-four remaining sites are in **sync predicates with no resolution seam**: - `classifyPausedAbortWorkflowRecovery` (3) - the `start()` task-moved listener (5) — compares event `from`/`to` columns inside a sync callback - `isWorkspaceOwnerLive` (1) - `isPhantomExecutorBinding` (1) Converting these means threading a flags parameter down from every caller — precisely the unwired-optional-parameter shape this program keeps finding inert (five were live on `main` at once per `unwired-lane-parameter-guard`). They need a decision about *where the resolution lives*, not a guess from me. The other **14** are in async sweeps with a seam available and are ordinary follow-on work in this same file. ## Verification (measured) - self-healing suites — **816 passed / 41 files** - `tsc --noEmit`, `eslint` — clean - `pnpm test:gate` — green - `lifecycle-column-census --strict`, `check-lane-wiring`, `check-sql-column-literals`, `check-inert-flag-seams`, `check-fnxc-future-dates` — green No changeset: `@fusion/engine` is private. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Self-healing workflows now continue functioning when workflow columns are renamed. * Improved recovery for stalled, blocked, paused, or disconnected workflow states while preserving existing filters and actions. * Temporary merge worktrees and drifted agent links are cleaned up more reliably. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-31 02:54:39 -07:00
gsxdsm	06717ac3fa	refactor(engine): resolve replan-target's advancement test by role (fleet, 4 sites) (#3052) ... ## Census | | column guards | |---|---| | before | **126** | | after | **122** | `replan-target.ts`: **4 → 0**, and it drops out of the top-files list. Baseline re-recorded in the same PR, as the ratchet requires. ## What changed `hasAdvancedPastPlanning` asked "has this card moved past planning" as four literal comparisons — `in-progress`, `in-review`, `done`, `archived`. It now asks the same question in roles, from lanes the **caller** resolves. ## Caller-resolved is the whole point The module's sync twin `resolvePlannerLanes` reads `store.resolveTaskWorkflowIrSync`, which returns the **default workflow IR for every task under PostgreSQL**. Converting through it would have improved the census while answering about a board the card isn't on — the second failure shape in the learnings doc, already proven at this exact seam by `workflow-planner-lanes-sync-vs-async-live-e2e.pg.test.ts`. The only production caller is `async`, so it uses `resolvePlannerLanesForTaskAsync`. **The caller's own inert resolution is fixed too**, not just the four arms: `releasedToTodo` compared against `resolvePlannerLanes(...).hold` — the sync twin — so it read `todo` on every board regardless of vocabulary. One async resolution now supplies the planner column, the merged-planning column and the forward lanes. ## Flagged, not guessed The archive lane is a **separate argument** rather than a fifth `PlannerLanes` role. Adding the field surfaced a genuine divergence between the sync and async twins — `_workflow-vocabulary-fixture` models no archive lane, so they disagree there — and that fixture backs **37 test files**. That divergence deserves its own change with its own evidence; forcing it through a conversion PR would have meant editing a 37-file fixture to make my own change pass. ## Two larger clusters I did NOT claim, with reasons I went by census size first and verified before writing: - **`self-healing.ts` (56 guards, 44% of the backlog)** — already claimed. Three branches hold it, one checked out in another worktree (`convert/self-healing-lane-cluster-u7`). I'd drafted four sibling role helpers before checking; reverted rather than collide. - **`scheduler.ts` (12 guards)** — blocked by design and already documented at line 907 by a prior fleet worker. The `task:moved` handler is `async` but its **prologue is not**: no `await` between entry and the terminal-blocker branch ~55 lines down, so hoisting a resolution turns the prologue into a microtask and reorders this listener against every other synchronous subscriber ("verified, not assumed"). Lazy resolution doesn't help — the *condition* needs the lanes. Unblocking needs the emitter to carry resolved lanes on the payload, which is a design change rather than a conversion. `restart-recovery-coordinator.ts`'s 4 sites are the trait-fallback arms the census already counts as converted — converting those would delete the legacy fallback, not add resolution. ## Measured | check | result | |---|---| | replan + planner-lane suites | 11 files, **102 tests green** | | triage suites | **374 tests green** | | five gates + strict census | green; `tsc` clean | | unconverted callers | byte-identical — absent lanes fall back to `LEGACY_PLANNER_LANES`, absent `archivedColumn` keeps the legacy id | --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 02:39:45 -07:00
gsxdsm	c9516dbd09	fix(engine): resolve archiveStaleDoneTasks lane guards by role (fleet: self-healing 56→51) (#3047) ... Fleet phase. Claimed **`packages/engine/src/self-healing.ts`** — the largest cluster at **56 of 126** total sites. Verified unclaimed first: no open PR touches the file and no active worktree held a branch on it. ## Census before / after | | total | self-healing.ts | |---|---|---| | before | **126** | **56** | | after | **121** | **51** | `census --strict` exits 0; baseline re-recorded in this commit so the retired allowances cannot be regrown into. ## What converted, and why each role `archiveStaleDoneTasks` asked "has this card finished?" by comparing column ids, so on a renamed board it treated every finished card as live and archived nothing — the sweep was inert on exactly the boards this program exists to support. - **active-dependents scan** and **temp-worktree age gate** → `TERMINAL_ROLES` (complete ∪ archived): both ask "is this card done with, in any sense?" - **staleness filter** → `complete` **alone**: this sweep *archives* finished cards, so an already-archived card is not a candidate. Using the terminal pair here would have made the sweep consider its own output. **Union, not per-task, deliberately.** Over-inclusion is free at these sites because the per-card check still discards, and the union needs no per-task workflow selection — the failure mode `resolveWorkflowIrForTask` has, where a card with no recorded selection silently resolves to the built-in board. Recorded in `docs/solutions/workflow-learnings/project-union-versus-per-task-lanes.md`. ## The half-converted state is the interesting part Converting only the first two guards made `archiveStaleDoneTasks` **register as a converted sweep** — the existing ratchet suite grew from **36 to 38 tests** — and it then failed for still carrying `t.column !== "done"`. That is the failure mode worth naming: a partial conversion is worse than none, because the function now *looks* converted (it calls the resolver, it reads as role-aware) while one guard still pins it to the legacy vocabulary. Finishing the function turned it green. I would not have caught it from the diff. ## Verification - `self-healing` suites — **807 pass** (41 files) - `tsc --noEmit` — **0 errors** - `census --strict`, `check:lane-wiring`, `check:fnxc-future-dates`, `check:inert-flag-seams`, `check:sql-column-literals` — all exit 0 ## Flagged, not guessed — the remaining 51 Deliberately left, each for a stated reason rather than an omission: 1. **Move-transition matrices** (~1489–1504): `from`/`to` pairs encoding a legal-transition graph (`in-progress → todo|in-review|done|archived`). These are the *shape* of the lifecycle, not a lane lookup; converting them needs a transition-role model that does not exist yet. Guessing here would encode a wrong graph. 2. **`getLiveTaskColumn` comparisons** (~1398, 5313–5342): compared against a normalizing accessor that manufactures `"archived"` for soft-deleted rows. Those are protocol values, not column ids — converting them changes what the sentinel means. 3. **Sites without store access** in scope (several module-level predicates): need the resolved set threaded in as a parameter, which is a seam change per call site, not a substitution. 4. **`todo` requeue targets** (1927, 6181, 6303, 12060–12064): these pick a destination, so they want the single `intake`/`hold` answer from `resolveLifecycleColumns`, not a set — different arity, and several are inside sweeps whose rebound semantics I would be changing rather than preserving. Each is a real conversion; none is a one-line substitution, and doing them blind is how a guard count drops while behaviour gets worse. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 02:28:01 -07:00
gsxdsm	4878bda197	fix(core): the mission bootstrap duplicate was archived into a lane the board does not declare (#3046) ... ## Invisible to both censuses `archiveDefinedFeatureBootstrapDuplicate` writes `tasks.column` **directly** rather than through `moveTask`: ```ts .set({ column: "archived", updatedAt: … }) ``` - the **lifecycle census** reads comparisons — an assignment isn't one - the **move-target census** reads `moveTask` call arguments — this never calls it So on a board whose archive lane is renamed, the duplicate landed in a column that workflow doesn't declare: a card in a lane the board can't render, from a path that runs during ordinary feature bootstrap. ## Reuses the helper this class already has `archivedLanesFor(taskId)` was added for the guards further up the same file. It returns the legacy id when the task has no resolvable workflow, so an **unconverted board is byte-identical**. No new resolution machinery — the two `<> 'archived'` guards become `notInArray(column, [...lanes])` and the write targets the resolved lane. A board declaring several archive lanes is arbitrated by taking the first, the same choice `resolveLifecycleColumns` makes. Multiple archive lanes aren't a shape the builtin lineages produce. ## Measured | check | result | |---|---| | mission-store PG suite | **36 → 38**, all green | | new pair | differential — `filed` collides with no legacy id, and the default-lineage control still lands in `archived` | | mutation (hardcode the target back) | fails the renamed case | | SQL literal gate · `tsc` | green | ## How this was found Measuring the literal-column-**write** population for #2839: 51 raw sites, of which 20 are the four builtin workflow IRs declaring their own columns (correct by definition) and several more are archive-*entry record* fields rather than board columns. This is the one I verified is a real board write on a live path. Worth noting the measurement itself was wrong twice first — my glob was `packages/*/src/**/*.ts`, which requires a subdirectory and silently skipped every top-level file in `src/` (including this one), and my script printed only the first 14 findings so the grouping was over a truncated list. Same scope-blindness class as #3000 and #3002, this time in a throwaway scanner. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 02:22:27 -07:00
gsxdsm	53aef245f9	test(release): the dry-run safety probe matched a prompt that no longer exists (#3045) ... ## A release-safety alarm that was firing on wording ``` AssertionError: dry-run must exit before proceed confirmation ``` The probe searched for ``await confirm(`Proceed with release``. The prompt has since become: ```js await confirm(`Proceed with ${CHANNEL} release v${chosenVersion} (build, publish to npm tag '${NPM_DIST_TAG}', tag)?`) ``` so `indexOf` returned **-1**, `dryRunExitIndex < -1` was false, and this has been red on `main` ever since. ## The property itself holds — verified directly, not inferred from a green suite | | offset | | --- | --- | | first `if (DRY_RUN) {` guard, calling `process.exit(0)` | **28808** | | the sole `await confirm(` call site | **44503** | Two dry-run exit guards, one confirmation, exit first. **`pnpm release --dry-run` cannot reach the proceed prompt.** This was never a real safety failure. The probe is narrowed to the stable prefix `await confirm(\`Proceed with `, which still names the one confirmation in the file while surviving the interpolated channel and version. The sentence was never the safety property. ## Why this one mattered more than an ordinary stale probe A stale probe on a *safety* test spends the alarm on cosmetics. Everyone learns the assertion is red for no reason — so a genuine reordering later arrives at an alarm nobody reads. That is a worse outcome than the test not existing. ## Proven to still catch the real regression I injected a `confirm(` call **above** the first dry-run exit in `release.mjs`: ``` confirm injected before the dry-run exit → ℹ pass 5 ℹ fail 1 (dry-run must exit before proceed confirmation) reverted → ℹ pass 6 ℹ fail 0 ``` **No release command was run.** The mutation was local to a scratch copy of `release.mjs`, reverted immediately, and the working tree verified clean — `release.mjs` is untouched by this commit, and the diff is the test file only. ## Fifth and last of the mechanically-fixable suites That closes the mechanical half of the seven red `scripts/__tests__` suites I found: `plugin-authoring-docs` (#3036), `verify-fast` (#3038), `ci-test-shard-timings` (#3040), `engine-vitest-gate-policy` (#3044), and this. **`workflow-reliability-release-check` is the one that is not mechanical** and I am still not touching it: its acceptance map cites 13 test files with **8 missing** and **2 of 5 rows carrying zero surviving evidence**. That needs its owner to decide, per row, whether the coverage moved or was deleted — a repoint would launder the gap (diagnosed on #3036). Five of six looked identical from the failure line. Only that one is unsafe to fix without owning the subject. ## Verification (measured) - this suite — **6 passed / 0 failed** (was 1 failed) - `eslint` — clean Test-only. No changeset.	2026-07-31 02:17:09 -07:00
gsxdsm	8b82e77fbf	chore(core): delete liveParentFilter — no caller, and it carried a legacy lane literal (#3042) ... Found while enumerating archive-exclusion sites for #3041. ## Unambiguously dead `liveParentFilter` has exactly **one** reference in the repo: its own definition. - not exported from `index.ts` or `index.gate.ts` - no test imports it - no production code calls it It nonetheless contained `column != 'archived'`, so it was one of the 22 sites the SQL column-literal gate tracks. ## Why delete rather than convert Converting it would mean adding lane resolution to code nothing runs — risk with no behaviour. That's the same argument #3041 makes for *not* converting the other two dead sites; deleting is the version of it that also removes the literal. ## The gate it documents is not being deleted Its docblock describes the document/artifact visibility gate (VAL-CROSS-015). That gate is real and still enforced — by the inline conditions inside `listLiveTaskDocuments` and `listLiveArtifacts`, which is presumably why this helper was never wired up in the first place. Only the unused composition goes. ## Measured | check | result | |---|---| | SQL literal population | **22 → 21**; the gate ratcheted its own baseline down and asked for the commit, included here | | `taskstore-remaining.test.ts` (archive-lineage suite) | **27 tests green** | | six gates + `tsc` | green | ## Not deleted, deliberately `listLiveTaskDocuments` and `listLiveArtifacts` are referenced **only** by that test file. That's a weaker signal than zero references — someone may have written them ahead of a consumer. Their literals stay counted, which is the honest state for code whose intent I can't read from the repo. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 02:11:54 -07:00
gsxdsm	b01a2026a0	test(ci): record the third PG gate canary — the policy ledger has been red since #2759 (#3044) ... ## The PG gate ledger has been red since #2759 ``` AssertionError: the PG gate must stay a narrow, explicit canary list + 'src/__tests__/postgres/sync-workflow-ir-is-always-default.pg.test.ts' ``` #2759 (`ae4ff9c111`) added that test **and** its entry in `packages/core`'s `test:pg-gate` script in one commit, without updating the ledger this assertion compares against. ## Recorded, not approved — and that distinction is why I touched it carefully My first instinct was to leave it: ratifying someone else's gate admission is exactly the "make it green" move I have refused elsewhere in this sweep. What changed my mind is that **a red policy test protects nothing**. While it fails, the *next* gate admission is invisible too — which is the opposite of what a narrow-canary ledger exists for. The admission is already live; the gate runs three tests today whatever this file says. Restoring the ledger re-arms the guard for everything after it. And the admission does carry the evidence of value AGENTS.md requires, so recording it is not a rubber stamp. The test pins that `resolveTaskWorkflowIrSync` returns the **default** IR for every task in production, which means a guard written as: ```ts resolveLifecycleColumns(store.resolveTaskWorkflowIrSync(id))?.hold ``` reads as converted, counts as census progress, and is **silently wrong for every custom workflow** — the non-optional return type hides the substitution from every caller. Ten call sites depend on that fact today. Catching that class at the gate is cheaper than catching it in review; I would have argued for admission had I been asked. **If the gate's owner disagrees with a third canary, the fix is to remove it from `test:pg-gate` and shorten this ledger again — not to leave the assertion red.** I have said so in the code comment too, so the next reader gets the choice rather than the fait accompli. ## The guard is bidirectional — verified against the gate, not the ledger A ledger synced to whatever the gate currently says would be worthless, so I mutated the **gate script**: ``` removed a canary from packages/core test:pg-gate → ℹ pass 3 ℹ fail 1 restored → ℹ pass 4 ℹ fail 0 ``` So it still catches silent gate **shrinkage** as well as growth — a canary quietly dropping out of the merge gate would fail here. `package.json` is restored; the diff is the test file only. ## One thing worth passing on That test names a *class*, not a single bug: ten call sites resolve lanes through the sync resolver and read as converted while always getting the default IR. I checked where they live — **all in `packages/core` and `packages/engine`, none in `packages/cli` or `plugins`** — so my own territory is clear of it, but whoever owns those two packages may want the list. ## Verification (measured) - this suite — **4 passed / 0 failed** (was 1 failed) - `eslint` — clean Fourth of the red `scripts/__tests__` suites. Test-only. No changeset.	2026-07-31 02:11:31 -07:00
gsxdsm	0b10f6ccd3	test(docs): validate nested TOC anchors, and fix the slugify that hid one (#3039) ... **Stacked on #3036** (its commit is the parent). That PR fixes a guard that had been red on `main`; this closes the gap it leaves and, in doing so, turned up a second defect in the helper. ## 1. Nested anchors were accepted but never resolved #3036 makes the parser recognise sub-entries — correct, and it fixes the red. But it validates only their link *shape*. Measured on that branch: | corruption | result | |---|---| | **nested** entry → `#kb-nonexistent-anchor` | **passes** | | **top-level** entry → `#kb-nonexistent-anchor` | fails | A TOC guard exists so links resolve. Checking that for one class of entry and not the other leaves a dead sub-link to be found by a reader clicking it. ## 2. Resolving them exposed the slugify bug Adding the check failed immediately — on the **real document**, against a heading that exists: ``` Nested TOC anchor #theming--overlay-layering-for-dashboard-views matches no heading ``` The document is right; the helper was wrong. `slugifyHeading` collapsed whitespace **runs**: ```js .replace(/\s+/g, "-") // theming-overlay-layering-... .replace(/\s/g, "-") // theming--overlay-layering-... ← GitHub, and the doc's own link ``` GitHub emits one hyphen **per space**. `### Theming & Overlay Layering for Dashboard Views` loses the `&` and keeps both spaces, so the true anchor carries a double hyphen. **This was latent, not dormant-and-harmless:** the two spellings differ only when punctuation is stripped from *between* words, and all eighteen numbered section titles are punctuation-free — so every existing use of the helper agreed. The first heading with an `&` in it would have produced a false failure against a correct document, which is the shape most likely to get a guard edited rather than believed. ## Mutations (all four) | mutation | result | |---|---| | clean | 4/4 pass | | nested anchor broken | **fails** ← was green before this PR | | top-level anchor broken | fails | | malformed top-level line | fails | | `slugify` reverted to collapsing | **fails** — the helper fix is load-bearing | Lint clean, FNXC gate exit 0. Test-only. ## Note This is the fifth guard in this batch to ship with a hole found by mutating it rather than reading it, and the second where fixing one class of input revealed the checker had been quietly wrong about another. The pattern is consistent enough to be worth expecting: **when a guard starts examining something it previously skipped, the first thing it finds is usually its own bug.** If #3036 lands first this rebases to a single commit; if taken together the stack applies as-is. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved heading links to match GitHub-style anchors when punctuation separates words. * Enhanced nested table-of-contents validation to confirm links point to headings in the document. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 02:06:03 -07:00
gsxdsm	49fb39e644	fix(ci): prune six phantom paths from the shard-timing snapshot, red on main since their features died (#3040) ... ## Six phantom paths in the shard-timing snapshot ``` AssertionError: timing snapshot references missing test files: packages/core/src/__tests__/dependency-blocked-todo-report.test.ts packages/core/src/__tests__/workflow-parity.test.ts packages/engine/src/__tests__/dependency-blocked-todo-reporter.test.ts packages/engine/src/__tests__/reliability-interactions/meta-archive-guard-composition.test.ts packages/engine/src/__tests__/reliability-interactions/meta-chain-auto-close.test.ts packages/engine/src/__tests__/self-healing-meta-archive-guards.test.ts ``` The guard's own note says why this matters past the red assertion: *"stale or phantom-path entries silently degrade CI shard balancing and can hide merge-gate regressions."* **The balancing cost is not academic.** `self-healing-meta-archive-guards` carried **20700 ms**. A shard has been budgeting 20.7 seconds for a file that cannot run, plus five more. ## Deleted, not moved — checked one at a time A moved test should be **repointed** to keep its measurement; only a deleted one should be dropped. So I resolved each rather than assuming: | file | deleted by | | --- | --- | | `dependency-blocked-todo-report` / `-reporter` | `710d56b2db` — U4 trim, the feature deletion | | `workflow-parity` | `4158cf1ab7` — Phase A workflow-owned lifecycle | | `meta-archive-guard-composition`, `meta-chain-auto-close`, `self-healing-meta-archive-guards` | `0e3d2a2265` — meta-task auto-archive/auto-close deletion | All six died with their features. None has a surviving equivalent anywhere in `packages/`. ## Pruned, not regenerated Regenerating means a full measured suite run and rewrites all 2499 entries — burying six deletions inside a wholesale diff nobody can review. `capturedAt` is **6.8 days old against a 30-day budget**, so the snapshot is otherwise current and the other **2493 measurements are untouched**. The diff is exactly six deleted lines, `capturedAt` unchanged. ## Revert proof Pruning a list is worthless if the assertion cannot fail afterwards, so I re-introduced a phantom entry: ``` with a fake path → ℹ pass 11 ℹ fail 1 (references missing test files) removed → ℹ pass 12 ℹ fail 0 ``` ## Third of the red suites, and still not a sweep Mechanical, like `verify-fast` (#3038). Unlike `workflow-reliability-release-check`, whose acceptance map cites 13 test files with **8 missing** and **2 of 5 rows carrying zero surviving evidence** — that one needs its owner, and a repoint would launder the gap (diagnosed on #3036). Same failure phrasing, opposite safety. That is why these are going one at a time. ## Verification (measured) - this suite — **12 passed / 0 failed** (was 1 failed) - snapshot integrity — 2493 files retained, `capturedAt` unchanged, no reformatting No changeset: CI tooling data.	2026-07-31 02:05:51 -07:00
gsxdsm	19b97e9f09	test(verify-fast): the pretest-validator mirror is stale by two, and has been red on main (#3038) ... ## The pretest-validator mirror is stale by two ``` assert.deepEqual(PRETEST_STATIC_CHECK_SCRIPTS, PRETEST_CHECKS); + 'scripts/check-no-cwd-relative-dashboard-test-reads.mjs', + 'scripts/check-capacity-pool-id.mjs', ``` Production found ten validators; the test's mirror listed eight. **The world was right and the assertion was stale** — the good direction. `PRETEST_STATIC_CHECK_SCRIPTS` is *derived* from `package.json`'s pretest chain, so `verify:fast` picked both new validators up automatically when they were added. They are real scripts, they run in pretest, and verify:fast was already running them. Only the mirror needed telling. Added in production order, since the assertion is a `deepEqual` and order is part of it. Plain strings for these two — the surrounding entries are split and re-joined to keep banned phrases (the port-kill and nohup literals) off a single source line for the policy scanner, and neither new name contains one. ## The guard is load-bearing — verified against the source of truth, not the mirror Syncing a mirror is worthless if the assertion can no longer fail, so I mutated `package.json`'s pretest chain rather than the test: ``` dropped check-capacity-pool-id from pretest → ℹ pass 16 ℹ fail 1 restored → ℹ pass 17 ℹ fail 0 ``` So it still catches a validator silently leaving `verify:fast`, which is the regression that actually matters. `package.json` is restored; the diff here is the test file only. ## Second of seven, and the contrast is the point This is the second of the seven red `scripts/__tests__` suites I found on clean `main` (after #3036). It was genuinely mechanical. `workflow-reliability-release-check` was not, and I did **not** fix it — diagnosed on #3036 instead: `docs/custom-workflow-reliability-acceptance-map.md` cites 13 test files of which **8 are missing**, and **2 of 5 rows have zero surviving evidence**, including *"a custom workflow can be authored/imported, rejected on invalid IR, saved, discovered, selected, and reloaded"*. The obvious repoint would have turned it green while the behaviour stayed unverified. That contrast is why I am taking these one at a time rather than sweeping them green: two of seven look identical from the failure line, and only one of them is safe to fix without owning the subject. ## Verification (measured) - this suite — **17 passed / 0 failed** (was 1 failed) - `eslint` — clean Test-only. No changeset.	2026-07-31 01:57:59 -07:00
gsxdsm	35729699b8	fix(dashboard): Lane and ListView sorted every column with the LEGACY role defaults (wrong card order on renamed boards) (#3016) ... `sortTasksForDisplayColumn` takes four role answers and defaults each to the legacy id. Its own header names the callers that never supplied them: > *"defaults to the legacy id so the callers that do not resolve flags (Lane, ListView) keep today's behaviour exactly."* On a renamed board, today's behaviour is the **wrong order**, silently: | lane | what is lost | |---|---| | hold | priority-then-FIFO queue order — an urgent card is no longer visibly next | | complete | completion-date ordering | | review | the merging card no longer floats to the top | Nothing throws, nothing logs. The cards are simply in the wrong order — which is exactly why this survived every existing test in these files: their fixtures use the built-in ids, where the defaults happen to be right. `Board.tsx` already resolves these from `column.flags`. Mirrored here rather than answered a second way, including its `complete && !archived` done-like rule. ## Reverted All **3** new `Lane` cases fail. Each picks inputs where the role order and the generic fallback **disagree**: - hold — equal priority, so role order is created-at and the fallback is task-id - complete — `columnMovedAt` DESC vs task-id ascending - review — a `merging` card, which the fallback ignores entirely **My first draft asserted urgent-first and passed with the fix reverted.** The generic sort also puts urgent first, so the assertion discriminated nothing. Recording that because it is the second time this shape has caught me: an assertion that is *true* is not the same as an assertion that is *load-bearing*. ## Coverage I do not have `ListView`'s identical wiring has **no component test**. Its harness stubs `fetchBoardWorkflows` with a never-resolving promise, and `listColumns` derives from the resolved workflow — so a renamed board is not drivable there without reworking that stub, which several other tests in the file depend on. The call site is covered structurally by the lane-wiring ratchet (baseline 19 → 17) and by the helper's own unit tests, but that is a structural guarantee, not a behavioural one. I would rather say so than imply the two callers are equally proven. ## Verification Lane + ListView + taskSorting + Board **357 passed** · `pnpm test:gate` 161 + 13 + 487 + 71 · lint · lifecycle census `--strict` · lane-wiring · fnxc-dates (TZ=UTC) · changesets — green. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Fixed task sorting in lanes and list views after workflow columns are renamed. * Preserved correct ordering for completed, on-hold, archived, merge-blocked, and review tasks. * Ensured task ordering reflects each column’s configured role rather than its previous identifier. * Maintained consistent ordering across board and list views. * **Tests** * Added coverage for renamed workflow columns and their expected task ordering. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-31 01:55:08 -07:00
gsxdsm	6a5bd7a86f	chore(gate): drop the stale inert-seam exemption — the seam it covered is wired (#3037) ... The gate reports this itself: ``` [check-inert-flag-seams] STALE allow-list entries — supplied now, or no longer declared: plugins/fusion-plugin-dependency-graph/src/GraphTaskNode.tsx::isTaskStuck — no unsupplied call site remains; remove its ALLOWED_OMISSIONS entry ``` #3029 wired that call site. The entry now claims to tolerate something that doesn't exist. The gate **warns rather than fails** here by design — failing would punish whoever fixed the seam — which is precisely why a stale entry has to be deleted deliberately instead of waiting for a red build to force it. ## The text is worth losing on its own account That exemption justified the omission as needing *"a published-API change."* I later revised it to *"build plumbing."* **Both were wrong**: the blocker was a hand-maintained interop declaration frozen at the pre-conversion three-argument signature (#3003 → #3029). An exemption whose stated reason has been disproven twice is worse than no exemption — it's a confident note that stops anyone re-deriving the answer. Same failure mode as the stale "do not re-probe" doc entry corrected in #3018, and the untested deferral rationales recorded in #3026. ## Measured | check | result | |---|---| | inert-seam gate | **23 seams, all supplied**, exit 0 **with no waiver** | | gate's own suite | 18/18 | | lane-wiring · plugin-interop-drift · FNXC | green; lint clean | <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved validation of task status handling by removing an exception that could allow an incomplete call site to go undetected. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 01:54:57 -07:00
gsxdsm	f411d55591	test(docs): the PLUGIN_AUTHORING TOC guard rejected legal nested entries, and has been red on main (#3036) ... ## A legal Markdown sub-entry turned this guard red ``` AssertionError: Invalid TOC line: - [Theming & Overlay Layering for Dashboard Views](#theming--overlay-layering-for-dashboard-views) ``` That line is an ordinary nested TOC entry, indented under item 8 of `docs/PLUGIN_AUTHORING.md`. The parser did `.map(line => line.trim())` **first** and then required every line to match the top-level `N. [title](#anchor)` shape — so indentation, the one thing distinguishing a sub-entry from a malformed top-level one, was destroyed before it could be used. **The doc was never wrong.** Only the parser was, and it has been red on `main` since the entry was added. Indentation is now read before trimming. Sub-entries are still required to be well-formed links; they just do not participate in the numbering or the count. ## Both guard directions verified by breaking them A looser parser that skipped anything unrecognised would have made the failure go away while quietly ending the guard's usefulness — so I checked it still fails in both directions: | mutation | result | | --- | --- | | top-level `9.` rewritten as a bullet | still fails (`Invalid TOC line`) | | nested entry replaced with un-linked prose | still fails (`Invalid nested TOC line`) | ## The wider finding, which matters more than this fix I found it by sweeping `scripts/__tests__` against clean `main`: **688 passing, 7 failing test files.** | suite | failing assertion | | --- | --- | | `ci-test-shard-timings` | committed timing snapshot references live test files | | `dependency-security-floor` | pnpm overrides pin transitive protobufjs to a safe floor | | `engine-vitest-gate-policy` | pg gate canaries remain a subset of the enabled suite | | `plugin-authoring-docs` | **this PR** | | `release-prompt-gate` | release dry-run exits before proceed confirmation | | `verify-fast` | defaults to every canonical pretest validator | | `workflow-reliability-release-check` | manifest references existing seam files | All sit **outside the merge gate**. That is now the third instance of this pattern I have hit — #2969's 15 red agent-action tests and #3033's stale ratchet list were the others — and it is clearly systemic rather than incidental. I fixed only the one in plugin territory. The rest span CI sharding, **dependency security** (that protobufjs floor is a security assertion currently not holding), release gating and workflow manifests. Each needs its owner's judgement about whether the assertion or the world is wrong, and a drive-by "make it green" is exactly how a real signal gets erased — `dependency-security-floor` especially. ## Verification (measured) - this suite — **4 passed / 0 failed** (was 1 failed) - `eslint` — clean Test-only; the doc is untouched. No changeset.	2026-07-31 01:52:13 -07:00
gsxdsm	83294a6958	fix(test): the protobufjs security floor was asserted against an empty object (reads like a deleted pin; it moved) (#3035) ... `scripts/__tests__` has **seven** files failing on main. None are in the merge gate, so nobody is blocked — which is exactly how this survived. This fixes the one that names a real risk. ## It reads like a deleted security pin. It isn't. ``` AssertionError: package.json pnpm.overrides: protobufjs range undefined must include an explicit semver version ``` #2220 moved pnpm overrides from `package.json` to `pnpm-workspace.yaml` for pnpm 11 readiness. The assertion kept reading `package.json`, where `pnpm.overrides` is now `{}`. **Nothing was ever exposed**: `pnpm-workspace.yaml` still pins `protobufjs: ^7.5.8` and the lockfile resolves `7.6.5`, comfortably above the 7.5.5 floor. The sibling assertion that checks lockfile resolutions has been passing the whole time — which is the only reason this was survivable. But no reader could distinguish this message from a genuinely removed pin without doing the archaeology, and a guard that is permanently red while naming a real risk teaches its readers that red means nothing here. That is worse than no guard: it launders a real removal into background noise. ## Measured both ways | change to `pnpm-workspace.yaml` | result | |---|---| | pin removed | **fails** — `protobufjs range undefined must include an explicit semver version` | | pin lowered to `^7.4.0` | **fails** — `range ^7.4.0 is below required floor 7.5.5` | | unchanged | passes | ## Second assertion `package.json` must declare **no** `pnpm.overrides`. If overrides move again — or come back — that fails and points at the next reader, instead of letting the floor go silently unchecked. That is precisely the failure mode #2220 produced, and nothing would otherwise catch a second occurrence. ## The other six Left alone deliberately; each needs its own diagnosis and they are unrelated to one another (I checked — the "seven files, one failure each" pattern looked like a common cause and is not): - `workflow-reliability-release-check` — manifest references `workflow-definition-store.test.ts`, which no longer exists. **Likely a real signal**: a release check pointing at a deleted seam file covers nothing. Best next one to pick up. - `ci-test-shard-timings` — snapshot references missing test files; affects shard balancing. - `verify-fast`, `engine-vitest-gate-policy` — validator/canary list drift. - `plugin-authoring-docs` — a TOC anchor for a heading containing `&`. - `release-prompt-gate` — dry-run no longer exits before the proceed confirmation. ## Verification `node --test scripts/__tests__/dependency-security-floor.test.mjs` **4 passed** · `pnpm test:gate` 161 + 13 + 487 + 71 · lint · changesets — green. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Updated security validation to correctly read protobufjs version overrides from the workspace configuration. * Added safeguards to detect outdated override locations and help prevent future security-check regressions. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-31 01:46:56 -07:00
gsxdsm	ccf562f178	gate: compare mirrored INTERFACES too, and delete the dead prop that found (#3034) ... > **Re-landing the second half of #3031.** That PR merged into #3029's branch and only its first commit reached `main` — the arity rule shipped, the interface rule and its finding did not. Verified on `main`: the gate reports *"7 mirrored function(s)"* with no interface count, and the dead prop below is still there. ## What The arity rule covers exported functions. The same files also mirror **interfaces**, which is the larger surface — six copies of `PluginDashboardViewContext` alone. **One direction only.** A mirror may declare *fewer* properties, and all six do (6, 8, 7, 7, 3, 6 against the real nine) because a plugin mirrors the fields it uses. Demanding equality would fail every plugin for not using everything — which is how a check gets ignored and then deleted. A property the real type **doesn't have** is the drift that matters: a rename nobody propagated, where the plugin keeps compiling and reads a field the host never sends. ## Its first interface run found a live one ``` dashboard-interop.d.ts:67 TaskCardProps.workflowStepNameLookup is not a property of the real TaskCardProps ``` Git history says it **was** one when FN-2466 and FN-7039 added this threading. The dashboard removed it later; nothing propagated that to the plugin's hand-written declaration. So the plugin built a lookup map from `context.workflowSteps` on every render, threaded it through two components, and handed it to a `TaskCard` with no such prop. Deleted rather than exempted — a new gate shouldn't ship with a waiver for its own first finding. Behaviour-preserving: the value never reached anything. ## Measured on `main` | check | result | |---|---| | population | **7 functions + 10 interfaces across 6 plugins**, all matching after the deletion | | control probe | phantom property **caught**; clean tree exits 0 | | anti-vacuity | now also requires a non-zero *interface* comparison | | gate's own suite | **5 → 8** | | dependency-graph suite | 179 green; `tsc` clean | | other five gates · census | green | ## Running total for this check Three real drifts, none of which any other instrument reported: 1. `isTaskStuck` stuck at three parameters through the whole lane conversion (#3003) 2. `taskStuckTimeoutMs?: number` vs the required `number | undefined` — in **two independent authors'** declarations 3. `workflowStepNameLookup` outliving its removal from `TaskCard` Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 01:43:58 -07:00
gsxdsm	e9b24b69e8	fix(dashboard): the duplicate banner judged the canonical by legacy lane ids (#3032) ... Found by applying the check I proposed on #3028: **re-test each `ALLOWED_OMISSIONS` entry — does the omission still fail once the excuse is removed?** It found a stale excuse on its first run. ## The entry's blocker was never tested ``` "…TaskDetailModal.tsx::isNearDuplicateCanonicalInactive" reason: "…Correct supply needs a fetch — a data change. See the note at the site." ``` The reasoning gets the hard part right: passing `detailColumnFlags` would answer about the **modal's** task, not the canonical, and would type-check while reading as a conversion. Rejecting that is correct. Then it concludes the seam needs a fetch — without checking what is in scope. - `columnFlagsByTaskId` is **already a prop of this component** (declared `:367`, destructured `:727`, used for the fan-out map at `:3718`), keyed by task id. - The canonical is `tasks.find((c) => c.id === nearDuplicateOf)` — drawn from the same loaded set the map covers. If the banner can render at all, the canonical is in `tasks`. So `columnFlagsByTaskId?.get(canonical.id)` is the canonical's own flags, no fetch. **`Column.tsx:307` already does exactly this**, with a comment making the same point about not reusing the row's flags — a sibling call site of the same function, solved. ## What was broken The banner's "this duplicates X" warning stayed up when the canonical had landed in a **renamed** complete lane, because `isNearDuplicateCanonicalInactive` fell back to the legacy ids and never saw it as finished. Same user-visible symptom #2997 fixed for the card chip; this is the modal. ## Verification | state | result | |---|---| | clean | seams gate exit 0; 123/123 across `TaskDetailModal.rendering` + `Column.neardup-flags-arrival` | | revert the supply | **gate exit 1** — `isNearDuplicateCanonicalInactive() — supplied by 10/11 call sites; omitted at TaskDetailModal.tsx:1 (of 2)` | That mutation is the point: with the allow-list entry present, this exact omission passed silently. It is now defended by the gate rather than excused by it. `tsc -p tsconfig.app.json` 0 errors in the file, lint clean, FNXC gate exit 0. ## The general point This is the second allow-list entry in two PRs whose stated blocker was wrong — #3028 removed the other one (*"needs a published-API change"*; the SDK is `private: true` and every consumer was in-repo). An `ALLOWED_OMISSIONS` entry is a deferral **carrying a gate's authority**. It reads as settled, it lives inside the checker, and it turns "nobody tested this" into "someone tested it and concluded no". A stale baseline *number* invites a recount; a stale *paragraph* invites agreement. Both entries this gate carried were stale, and the note at this call site had even been revised once — the revision corrected which flags were wrong to pass, and left the untested "needs a fetch" conclusion standing. Worth a periodic sweep of the remaining entries as they accumulate; with these two gone the list is empty, so the cheapest time to institutionalise it is now. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 01:41:13 -07:00
gsxdsm	a460a9bbc0	fix(plugins,dashboard): the dependency graph drew every card with the LEGACY lane vocabulary (#3029) ... ## The third producer of unflagged cards — the one a host-side fix could not reach #3025 fixed the two producers that go through `renderTaskCard`. `GraphTaskNode` is a third: it imports `TaskCard` **directly** through the plugin's interop shim, so that fix bypassed it and every role helper inside a graph card kept reading the legacy ids. The same component also called the stuck predicate without its flags: ```ts const isStuck = isTaskStuck(task, taskStuckTimeoutMs, lastFetchTimeMs); // no columnFlags ``` so `isWipColumnRole` fell back to the literal and **no card in the graph could ever be stuck on a renamed board**. Because `isStuck` gates `isActive`, a wedged card rendered with the **active** styling — the graph reported *"running"* about a task that had not moved in hours, while the main board showed the same card as stuck. That asymmetry between two views of one task is the defect, and it is what the new test pins. ## One cause, so one fix Both symptoms came from the same gap: `PluginDashboardViewContext` exposed `tasks` and nothing about the board's vocabulary. It now carries `columnFlagsByTaskId` — the same per-task map `renderTaskCard` already uses, **two lines away in the same object literal**. ## I filed this twice as blocked on a public-API change. It was not. ``` packages/dashboard @fusion/dashboard private: true packages/plugin-sdk @fusion/plugin-sdk private: true plugins/fusion-plugin-dependency-graph @fusion-plugin-examples/dependency-graph private: true ``` No published surface anywhere in the path — three in-repo private packages and a hand-written `.d.ts`. **#3026 landed the general form of that mistake while I was still making it**: a deferral's stated blocker is a claim, and mine decayed unchecked until I finally measured it. ## Two type decisions worth reviewing - **`Partial<TraitFlags>`** in the plugin-facing type, not the dashboard's `ExecutorColumnFlags` — that module's own header restricts it to `@fusion/core` and `react` imports so external plugin builds can consume it. Same runtime object either way. - **`MainContentProps.columnFlagsByTaskId` widened** from `{complete, archived, intake, hold}` to the flags the map really carries. It is built from `workflow.columns.find(...).flags`, so the four-flag declaration was a narrower view than the value — and `countsTowardWip`, which every wip predicate needs, was invisible through it. That narrow type is why threading this looked impossible at first. Absent still means legacy, matching how the host treats remote rows and off-board columns: the degraded answer is the documented literal, never *"this board has no wip lane"*. ## Revert proof Dropping the 4th argument: ``` AssertionError: expected 'graph-task-node graph-task-node--acti…' not to contain 'graph-task-node--active' Tests 1 failed | 26 passed (27) ``` The paired case (a fresh legacy `in-progress` card still reads active) passes both ways by design — it guards against over-detection, so I am not counting it as coverage. The gate agrees independently: `plugins/fusion-plugin-dependency-graph/src/GraphTaskNode.tsx: 1 -> 0`, baseline re-recorded 16 → 15 in the same commit. ## Verification (measured) - plugin suite — **185 passed / 20 files** - dashboard `dashboard/` + `plugins/` suites — **48 passed / 6 files** - `tsc --noEmit` clean in both packages; `pnpm lint` clean - `lifecycle-column-census --strict`, `check-lane-wiring` (15, none added), `check-sql-column-literals`, `check-inert-flag-seams`, `check-fnxc-future-dates` — green No changeset: all three packages are `private: true`. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 01:30:47 -07:00
gsxdsm	5897d87e95	fix(gate): the lane census judged a call against a signature it never had (the false positive #3013's merge introduced) (#3021) ... #3013's merge of same-named declarations fixed a false **negative** and introduced a false **positive**. `ModelSelectorTab` declares its own two-parameter `resolveEffectiveExecutor(task, settings)` — a pass-through with nothing lane-related — while an unrelated exported function of the same name in `effective-model-resolution.ts` takes `columnFlags`. Both local calls were reported unwired against a signature they have never had. Only **exported** declarations enter the accepting map, so the rule is exact: if the calling file declares the name itself and the map entry came from a different file, the call resolves to the local declaration and is not a lane call here. ## The version I did not ship My first attempt re-ran the detector over the single calling file and used that result. It scored *better* on this tree — **19 → 16** instead of 19 → 17, also clearing `bucket-mapping.ts` — and I threw it away. A single-file pass cannot resolve an **imported** options interface. A locally-declared function with an imported context type would quietly stop being lane-accepting, and every call to it would stop being checked. That is a false negative, which is the one failure a ratchet must not have; the better-looking number came from the gate seeing less. The global pass still does all type resolution here — only the *choice* of declaration is local. ## Measured | | | |---|---| | new tests | 3 | | against the old census | **1 of 3 fails** — the positive | | baseline | **19 → 17**, exactly the two `ModelSelectorTab` sites | Both negatives pass either way and they are the ones that matter: a file declaring its **own** exported lane function is not shadowed by itself, and a file declaring nothing is judged normally. Shadowing must not become a way to disappear a genuine unwired call. ## Still flagged, honestly `bucket-mapping.ts:75` stays in the baseline. `bucketForTask(task: TaskItem)` is only lane-accepting because `TaskItem` *declares* `columnFlags` — the lane data rides on the domain object, so passing `task` forwards it inherently. That is a different limitation (options-bag vs domain-entity parameters) and I have not tried to fix it here; it accounts for 2 of the remaining 17 along with `otherBucketSecondaryLabel`. ## Verification `node --test scripts/__tests__/check-lane-wiring.test.mjs` **19 passed** · `pnpm test:gate` 13 + 161 + 487 + 71 · lint · lifecycle census `--strict` · lane-wiring · fnxc-dates (TZ=UTC) · changesets — green.	2026-07-31 01:03:24 -07:00
gsxdsm	6f936f2de7	fix(cli): the node-override guard never fired on a renamed board, so mid-flight changes were allowed (#3019) ... ## The node-override guard never fired on a renamed board `fn_task_update` called the guard with no options: ```ts const validation = validateNodeOverrideChange(task, normalizedNodeId ?? null); ``` so `wipColumns` fell back to its documented default of `{"in-progress"}`. On a board whose WIP lane is named anything else, `wipColumns.has(task.column)` is false, the mid-flight check passes, and **an operator can change the node override on a running task** — precisely what that guard exists to refuse, in its own words: > "Is this task executing right now?" — keyed on the literal, a renamed board let an operator change the node override MID-FLIGHT on a running task, which is exactly what this guard exists to refuse. That note is attached to the `wipColumns` option added for this purpose. The CLI simply never passed it. ## Two assumptions in the guard's own docs that did not hold ``` Both callers supply them. An omitted set keeps the legacy id, which is what a caller without cheap IR access (a CLI tool, a route with only a task row) still gets. ``` 1. **"Both callers"** — this is a *third* one, and it was in `check-lane-wiring`'s known-unwired baseline the whole time. 2. **"a CLI tool … without cheap IR access"** — this handler is async and has already awaited `store.getTask`, so one more resolve costs exactly what `resolveTaskLifecycleColumns` already costs elsewhere **in this same file** (the linked-lineage label at ~1239). The assumption was reasonable in general and wrong here. Passed present-but-conditionally-valued rather than as a conditional argument: an omitted set still keeps the documented legacy default, and only that shape is visible to `lane-wiring-census`, which matches an object-literal argument and cannot see a ternary. ## Coverage — stated rather than implied **There is no new unit test.** The regression guard is the ratchet itself, and it is a real revert-proof: with the wiring removed, ``` [check-lane-wiring] call sites not passing a resolved lane argument INCREASED: packages/cli/src/extension.ts: 1 unwired now, baseline allows 0 ``` Verified by actually reverting it, not by assuming. Baseline re-recorded 19 → 18 in the same commit, so the allowance cannot be regrown into. A behavioural test would need a custom workflow definition persisted *and* selected inside the integration harness to get a card resting in a renamed WIP lane. That is worth doing and I would take it as follow-up harness work — but it is not part of this fix, and I would rather name the gap than let "85 passed" imply coverage I did not write. ## Verification (measured) - **85 passed** across `extension.test.ts`, `extension-experiment-finalize.test.ts`, `task-list-board-columns.test.ts` - `tsc --noEmit`, `eslint` — clean - `check-lane-wiring` (18, none added), `lifecycle-column-census --strict`, `check-inert-flag-seams`, `check-fnxc-future-dates`, `check:changesets` — green Changeset included (`patch`): `packages/cli` is the published `@runfusion/fusion` and this changes guard behaviour operators rely on.	2026-07-31 00:52:50 -07:00
gsxdsm	9ad3a2a93a	fix(gate): name the offending FNXC stamp and which rule it broke (#3009) ... **`main` is currently red**, so every open PR shows a failing Lint job that is not its own fault. #3004 is how I found it — its gates all pass in isolation and fail against main. ## Cause: an hour that does not exist ``` FNXC:OperatorScriptLaneAssumptions 2026-07-30-26:10 ^^ hour 26 ``` Four of them, across three files, from #2994. ## The part worth fixing is the message, not the stamps This gate counts **two** defects — a date after today, and an impossible clock time — but the failure text only ever explained the first: ``` scripts/reconcile-task-state-consistency.mjs: 2 future-dated FNXC stamp(s), baseline allows 0 A stamp dated after today (2026-07-31) records the change as happening in the future... ``` Every stamp in that file is dated `2026-07-30` or earlier — all valid past dates. So the message sends you to inspect stamps that are fine, and the natural conclusion is *the gate is broken*, not *the stamp is*. I spent several minutes reproducing the regex by hand and getting `future count = 0` before instrumenting the real script and finding `hits += impossibleClockTimes(source)`. A gate that detects the right defect and describes a different one is worse than a slightly less sensitive gate, because it spends the reader's trust. Now: ``` scripts/reconcile-task-state-consistency.mjs FNXC:OperatorScriptLaneAssumptions 2026-07-30-26:10 (impossible clock time) ``` **Mutation-verified**: restoring one `26:10` stamp reproduces the failure, and the message names it. ## The stamps: `2026-07-31-02:10`, not `23:59` Hour 26 on the 30th is the informal spelling of 02:10 the next day. Clamping to `23:59` would keep the file's stamps in a plausible order but silently move the event; this preserves what the author meant. Reversible either way — say the word if you would rather they were clamped. ## The 176-file baseline drop is unrelated `475 -> 183 known`. The clock crossed midnight, so yesterday's stamps are no longer future-dated, and the ratchet auto-lowers on drops by design. It rides along because the gate must leave a baseline matching reality — an allowance nothing occupies is somewhere a real regression can hide. It is not part of the fix. ## Verification - `check:fnxc-future-dates` — exit 0 (was **exit 1 on main**) - `check:lifecycle-columns`, `check:sql-column-literals`, `check:inert-flag-seams`, `check:lane-wiring` — all exit 0 - eslint clean ## Worth someone's attention beyond this PR `#2994` landed four impossible timestamps. The gate caught them, but only after the clock crossed midnight changed which files it reported — meaning the impossible-time check was live but effectively invisible until it collided with an unrelated drop. It is worth asking whether that check has ever produced a message anyone acted on before today. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 00:39:05 -07:00
gsxdsm	3a016b1f17	fix(scripts): four FNXC stamps carried hour 26, and main has been red on them (#3010) ... ## `main` is currently red on `check-fnxc-future-dates` Four stamps read `2026-07-30-26:10` — an hour that cannot exist. They're exactly what #2995 taught this gate to catch. That PR landed the hour validation (`00-23`) *after* #2999 had already merged these four, so the gate started reporting a defect that was already sitting there rather than one introduced afterwards. **The guard is working**; nothing was checking before it. ``` scripts/lib/backend-db.mjs:41 scripts/reconcile-task-state-consistency.mjs:8, :51 scripts/__tests__/reconcile-task-state-consistency.test.mjs:109 ``` Corrected by **literal normalisation** — 26:10 on the 30th *is* 02:10 on the 31st — rather than flattening them to an arbitrary in-range hour. AGENTS.md specifies `yyyy-MM-dd-hh:mm`, and the stamp exists to give a readable why-does-this-exist trail, so the ordering is the part worth preserving. ## The baseline tightening rides along, and it's a date rollover Stamps written yesterday as `2026-07-31` were future *then* and were baselined as such. Today they're past, so **176 files ratchet to zero**. Nobody did anything. The gate rewrites the baseline as a side effect and exits 0, so leaving it uncommitted dirties the tree on every subsequent run **for everyone** — which is why it belongs in this commit rather than a later one. Re-recording on a decrease is the rule this gate and its siblings already state. Worth knowing about the design, since I wrote it: this churn recurs whenever a day boundary passes with future-dated stamps in the baseline, and it shrinks only as people stop writing them — which is the behaviour the gate exists to produce. **93 files still carry a non-zero allowance**, so the drain isn't finished. If it stays noisy once those clear, the gate's fail-on-tighten contract is the thing to revisit, not the stamps. ## Measured | check | result | |---|---| | gate | red before, **exit 0 after**, stable across two consecutive runs | | baseline | −176/+25 entries, all date-rollover | | inert-seam · sql-literal · lane-wiring · census | all green | | reconciler's own suite | green | ## One correction to a claim I made earlier this session While investigating I reported the gate as hanging for 600s. It wasn't — the harness killed the process (exit 144) and the empty output made it look like a stall. The gate completes in seconds. Noting it because I nearly filed a performance bug against a healthy script. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 00:36:21 -07:00
gsxdsm	ffe9898710	fix(gate): the lane-wiring census could not see three of the shapes it asks for (incl. a false positive it started reporting) (#3013) ... **The gate could not see three of the shapes it exists to check** — including the wiring I landed this week in #2990 and #3004. Found by using it: the baseline still listed `useBlockerFanout.ts`, `ExecutorStatusBar.tsx`, and `TaskDetailModal.tsx` as unwired *after* those PRs merged. ### 1. Conditional shapes Passing lanes only when they resolved is the **correct** way to write these — an empty trait index means "not loaded yet", not "nothing is terminal", so the caller must fall through to the documented legacy default rather than fabricate one. Both idioms that produces were invisible: ```ts computeBlockerFanoutMap(tasks, flags ? { columnFlagsByTaskId: flags } : {}) // ConditionalExpression computeBlockerFanoutMapCore(tasks, N, { ...(flags ? { classify } : {}) }) // SpreadAssignment, name === undefined ``` Either branch supplying the lane now counts. **Neither branch supplying it is still unwired** — that negative is tested. ### 2. Vocabulary `columnFlagsByTaskId`, the per-task trait index the dashboard threads, was never added. It answers every lane question at once, so a call site dropping it reverts to the legacy vocabulary wholesale — and the gate would have stayed silent. ### 3. Name collisions — the false positive Declarations were `set` by name, so the **last one parsed won**. Core's `computeBlockerFanoutMap(tasks, n, opts)` and the dashboard wrapper `computeBlockerFanoutMap(tasks, opts)` put their lane options at **different argument indices**, so core's callers were checked against the wrapper's signature: `task-priority.ts:141` passes `terminalColumns` at index 2 and was reported unwired. I caught this because adding the vocabulary entry in (2) made it appear. A ratchet that reports a correctly-wired site is worse than one that misses it — the first person to open one learns the number is noise. Both shapes are now merged; a call satisfying either counts. ### Measured | | | |---|---| | new tests | **6** — every positive paired with its negative | | against the old census | **3 of 6 fail** — exactly the three positives; the negatives pass either way, which is why they exist | | baseline | **23 → 19** — four sites recognized as *already* wired; no site newly excused | | new flags | none | ### Verification `node --test scripts/__tests__/check-lane-wiring.test.mjs` **16 passed** · `pnpm test:gate` 161 + 13 + 487 + 71 · lint · lifecycle census `--strict` · fnxc-dates (TZ=UTC) · changesets — green. Seven other `scripts/__tests__` files fail on main independently of this change (`verify-fast`, `dependency-security-floor`, `engine-vitest-gate-policy`, `plugin-authoring-docs`, `release-prompt-gate`, `ci-test-shard-timings`, `workflow-reliability-release-check`). None are in the merge gate and none are touched here — noting them because I looked, not because this PR affects them.	2026-07-31 00:33:13 -07:00
gsxdsm	f10261f424	fix(scripts): the contamination audit scanned four legacy lanes and claimed it had (#3005) ... ## An audit that scanned four legacy lanes — and claimed it had Two halves of the same wrong answer. **The query allowlisted the lanes:** ```sql WHERE deleted_at IS NULL AND "column" IN ('triage','todo','in-progress','in-review') ``` On a board whose lanes are named anything else that matches **nothing**, so the audit scans zero rows and reports zero contamination — a clean bill of health from a scan that never happened. `triage` is in that list too, a lane U11 (#2515) deleted. **And the report asserted the coverage it did not have:** ```js scannedColumns: ["triage", "todo", "in-progress", "in-review"], ``` printed regardless of what the query returned. When I first surveyed this script I called that field "the one thing keeping it from being fully silent" — it turns out it was a **claim, not an observation**, so it was not keeping it honest at all. It is now derived from the rows that came back. ## Fix: exclude finished lanes instead of allowlisting active ones Inverted so the default is the safe one — an unrecognised lane is active work by assumption and **is** audited; only lanes that genuinely mean finished drop out. An allowlist fails **closed** (skip everything unknown), a denylist fails **open** (look at it), and for an audit one extra finished branch is a far smaller error than auditing nothing. Filtered in JS rather than by building a dynamic SQL exclusion: it keeps **one** place deciding what "finished" means, and removes the last raw-SQL lane literal from this file. ## Revert proof ``` ✖ scannedColumns reports the board's real lanes, not a fixed legacy claim ✖ reports each scanned lane once, and nothing at all for an empty board ℹ pass 1 ℹ fail 2 ``` ## A demonstration of #3000, for free This PR removes a 4-literal raw-SQL clause, and `check-sql-column-literals` here reports **22, unchanged and green** — because this branch predates #3000 and the gate still walks `packages/` only. That is precisely the blind spot #3000 closes, reproduced a second time. ## Merge order This removes the 4 literals #3000 baselines. Landing this **after** #3000 drops that count and its gate fails on DECREASE — that gate auto-rewrites the baseline and asks for the commit, unlike `check-lane-wiring` which needs an explicit `--update-baseline`. Either order works; one of them needs a re-record, and I am happy to push it. ## Verification (measured) - `node --test` — **3 passed / 0 failed** (1 pre-existing + 2 new) - `node --check`, `eslint` — clean - `lifecycle-column-census --strict`, `check-lane-wiring`, `check-fnxc-future-dates` — green No changeset: root `scripts/` is repo tooling, not part of the published package. ## Territory status This was the last item I know of in `scripts/`. The four operator scripts holding lane assumptions — `recover-stale-blocked-by` (#2992), `reconcile-task-state-consistency` (#2994), `reconcile-leaked-soft-deletes` (#2999) and this one — are now either resolved or, where a script genuinely cannot resolve lanes, made loud rather than silent.	2026-07-31 00:27:41 -07:00
gsxdsm	52a66297fc	fix(gate): main is red — normalize #2994's four impossible-hour stamps (#3006) ... **`main` is currently red on the FNXC gate.** ``` $ node scripts/check-fnxc-future-dates.mjs # on origin/main scripts/reconcile-task-state-consistency.mjs: 2 future-dated FNXC stamp(s), baseline allows 0 scripts/lib/backend-db.mjs: 1 scripts/__tests__/reconcile-task-state-consistency.test.mjs: 1 exit 1 ``` #2994 carried four `2026-07-30-26:10` stamps. I flagged them on that PR before it merged; #2995 (the hour check) landed first, so the merge order turned the warning into a red gate rather than a red PR. Clamped to `23:10` — same rule as the nine before it: hour to `23`, minutes preserved, so ordering within each file survives. This is a normalization with a stated rule, not a claim about the true minute. **Verified:** FNXC gate exit 0, `reconcile-task-state-consistency` 8 pass / 0 fail. Comment-text only. ### Worth fixing at the source Thirteen impossible-hour stamps across six PRs in two days, and the hours climb — `24:40` → `25:30` → `26:10`. They are being written as a continuing sequence past midnight rather than read off a clock, which is a reasonable instinct and produces an invalid stamp every time. The trap is that the honest spelling does not work either: a genuine post-midnight stamp needs *tomorrow's* date, and the gate compares against the **local** calendar — so `2026-07-31-00:40` written from UTC-7 is future-dated and fails for a different reason. Clamping to `23:xx` is currently the only spelling that satisfies both, which is not obvious and is why this keeps recurring. If it recurs again, the fix is probably in the error message rather than more normalization PRs: the gate could name the valid range and the timezone it compares against, so the next author sees the constraint at the moment they hit it. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 00:16:39 -07:00
gsxdsm	cd237ae760	gate: the SQL column-literal ratchet never scanned scripts/, where the raw SQL actually is (#3000) ... ## The gate could not see the one place raw SQL is actually written by hand `check-sql-column-literals` walked `packages/` only and took `.tsx?`. Every operator script is a repo-root `.mjs`. I found it by removing a raw-SQL lane literal in #2999 and watching this gate report: ``` [check-sql-column-literals] 22 known SQL column literal(s), none added. ``` Unchanged, and green. Its own header promises the opposite — *"a LOWER count fails too so the baseline is ratcheted down"* — so the silence was the tell. **Two changes, and either alone still sees nothing:** the root and the extension. Adding one without the other scans nothing new and reports a reassuring zero — the same trap #2978 hit when widening the lane-wiring census. ## Newly visible: 6 sites, audited not blind-baselined | site | verdict | | --- | --- | | `audit-branch-cross-contamination.mjs:182` — `"column" IN ('triage','todo','in-progress','in-review')` | **real** — the contamination audit scans only the legacy active lanes, so on a renamed board it scans nothing and reports no contamination. Read-only, and it does print its `scannedColumns`, which is the one thing keeping that from being fully silent. | | `reconcile-leaked-soft-deletes.mjs:53, :73` | already fixed by **#2999** — the PR that exposed this gap | ## Proven able to fail, not just to count A guard that has only ever printed a number is a number. A temporary `.mjs` holding one forbidden comparison: ``` scripts/zz-probe-tmp.mjs: 1 SQL column literal(s), baseline allows 0 ``` and the gate returned to green once removed. ## One claim I withdrew I initially wrote that the `ScriptKind` move to `JS` for `.mjs` was needed because *"TSX treats `<` as JSX and would misparse an ordinary comparison"*. I could not demonstrate it. I tried three JSX-ambiguous shapes — `x <div> y`, `f<b, c>(d)`, and a literal sandwiched between `<` and `>` comparisons — and TSX recovered from all three with counts identical to JS. So `JS` is used because it is the correct kind for the file, **not** because a miss was observed, and the code now says exactly that. The opposite claim would have been easy to make and wrong, and this gate's whole value is that its statements about its own coverage are true. ## Merge order **#2999 removes both literals in `reconcile-leaked-soft-deletes.mjs`.** Landing it *after* this PR drops the count, and this gate fails on DECREASE (by design), needing a re-record. Merge #2999 first, or say the word and I will re-record here. Note the widening is self-protecting afterwards: if someone narrows the walk back to `packages/`, the recorded `scripts/` entries vanish from the scan and the gate goes red on decrease. ## Verification (measured) - gate — green, **28 known / none added** (was 22 across `packages/` only) - its own suite — **32 passed** - `eslint` — clean - `lifecycle-column-census --strict`, `check-lane-wiring`, `check-fnxc-future-dates` — green Gate/tooling only; no product file touched.	2026-07-31 00:13:55 -07:00
gsxdsm	1de0141ab8	fix(dashboard): Task Detail's blocking count read the LEGACY lanes (last of the three fan-out surfaces) (#3004) ... Third and last of the three surfaces calling the blocker fan-out wrapper, completing the sweep started in #2990 (Board + Executor bar). ## What was wrong, precisely The dependent **list** is lane-independent — core pushes `dependentIds` without consulting lanes — so this section looked broadly right. Two things beside it are not: - `overlapBlockedTodoCount`, rendered as **"FN-X is blocking N todo task(s) via blockedBy overlap"** — counted against the literal `todo`, so on a renamed board it read **0 while cards were genuinely blocked**. - the `stale` marker on each blocking dependent — decided against `terminal`/`review` lanes the operator does not use. A wrong number sitting beside a right list is the easiest kind to miss, which is why I checked what the modal actually consumes before deciding this was worth a PR rather than assuming the whole section was broken. ## Why a prop and not a hook This was the surface I deferred in #2990 because it had no trait index in scope. Two options: - `useBoardWorkflows` inside the modal — rejected. The hook documents that it does **not** dedupe across consumers: each call installs its own visibilitychange/focus listeners and its own SSE subscription. That is a new fetch and subscription per modal open, to answer a question the app has already answered. - **Thread the index that already exists** — `App` builds `footerColumnFlagsByTaskId` for the footer; this forwards it through `AppModals` as an optional prop. Chosen. Optional throughout: a card with no entry keeps the documented legacy fallback, so the remote-node case (where local workflow metadata must never be applied to foreign ids) and the pre-load window stay byte-identical. ## Reverted The new case fails on the rendered text — the modal cannot find `"FN-B is blocking 2 todo task(s) via blockedBy overlap"`. The pre-existing legacy-column case above it passes either way, because `todo` satisfies the literal default; that is exactly why it never caught this. ## Verification TaskDetailModal.rendering + ExecutorStatusBar + useBlockerFanout **206 passed** · dashboard app suite 11986 passed / 5 skipped (581 files) · `pnpm test:gate` 161 + 13 + 487 + 71 · lint · census `--strict` · lane-wiring · fnxc-dates · changesets — green. ## One note for whoever owns the FNXC gate `check-fnxc-future-dates.mjs` **rewrites its baseline as a side effect and still exits 0**. Today's date roll dropped 183 stamps out of "future", so any run dirties `scripts/lib/fnxc-future-dates-baseline.json` in the working tree. It cost me a stash conflict before I noticed. Not bundled here — it is repo-wide midnight drift, not this change — but a check that mutates tracked state on a read is worth a look.	2026-07-31 00:13:43 -07:00
gsxdsm	d861923355	fix(gate): the inert-seam ratchet never scanned plugins/, where real lane logic lives (#3002) ... #3000 showed this gate never scanned `scripts/`. I went auditing my own instrument after that, and the roots have a **second** hole: the walk was rooted at `packages/` alone, so every lane parameter a plugin declares or calls sat outside the ratchet entirely. ## Measured with a control | probe | before | after | |---|---|---| | unwired seam under `packages/` | caught | caught | | **identical** seam under `plugins/` | **missed** | caught | | clean tree | exit 0 | exit 0 | ## The sibling gate already knew `check-lane-wiring` lists `plugins` in its roots, and its header records the incident that put it there: an unwired `completeColumnsByTaskId` sat on `main` unreported because the glasses plugin wasn't scanned. This gate re-opened the same hole rather than inheriting the lesson. Two scope holes in one instrument is the actual finding — **the roots deserve the same scrutiny as the matcher, and until now they had none.** Every blind spot found in this gate so far has been in the matcher; nobody, me included, thought to probe what it walks. ## Newly visible — audited, not blind-baselined `plugins/fusion-plugin-dependency-graph/src/GraphTaskNode.tsx` calls `isTaskStuck()` without the resolved flags, while **six of the seven** other call sites supply them. That's exactly the partial-supply shape this gate exists to catch, hidden purely by scope. It's exempted rather than wired, and the reason is the interesting part. The plugin has **no lane-trait source anywhere**: it's mounted as a dashboard view through `PluginDashboardViewContext`, and `DependencyGraph` receives `tasks: Task[]` and nothing else. Passing the argument here would pass `undefined` — an unsupplied optional parameter, which the learnings doc's first failure shape calls strictly worse than the literal it replaces, because it reads as converted and answers legacy forever. Correct supply needs the plugin **view context** to carry per-task flags: a published-API change. That's the same "needs a data change" category as the existing `TaskDetailModal` entry, not the "awkward means wire it" case the exemption rule refuses. I checked that distinction against my own rule before taking the exemption, because the rule exists to stop exactly this kind of convenient reading. Filed for the plugin-API owner rather than bodged here. ## Measured - seam population **22 → 23** with plugins in scope - gate's own suite: **18/18 green** - lint and the FNXC gate green Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 00:08:21 -07:00
gsxdsm	72f5f8e51a	fix(gate): the FNXC stamp gate never validated the hour, so 25:30 passed (#2995) ... `check-fnxc-future-dates.mjs` validates the **date** portion of a stamp and never looks at the clock time: ```js const STAMP = /FNXC:[A-Za-z0-9_-]+\s+(\d{4}-\d{2}-\d{2})/g; … for (const match of source.matchAll(STAMP)) if (match[1] > today) hits += 1; ``` The capture stops before the hour, so a stamp may carry **any** `hh:mm` and pass. Found while pre-flighting #2992, whose new comments read `2026-07-30-25:30`. ## It is not one typo Four stamps **already on `main`** carry a clock time that cannot exist: ``` packages/cli/src/__tests__/task-list-board-columns.test.ts:2 -24:40 packages/cli/src/commands/task.ts:29 -24:40 packages/cli/src/commands/task.ts:636 -24:40 scripts/check-lane-wiring.mjs:18 -24:00 ``` Three separate authors, so this is the gate's blind spot rather than one person's slip — and #2992 adds two more, which is how I noticed. AGENTS.md specifies `yyyy-MM-dd-hh:mm`. The stamp's whole purpose is to make the FNXC record a readable chronology of *why* code exists; a timestamp that cannot exist quietly costs it that, and nothing was going to catch it. ## The fix Hours `00-23`, minutes `00-59`, counted per file **alongside** the future-dated population rather than as a separate gate — same defect class (a stamp that does not describe a real moment), and one ratchet is cheaper to keep honest than two. **Mutations, both directions:** | stamp | result | |---|---| | `2026-07-30-25:00` | **flagged** | | `2026-07-30-23:75` | **flagged** | | clean tree | `475 known future-dated stamp(s), none added`, exit 0 | ## On the four existing stamps Normalized by clamping the impossible hour to `23`, minutes preserved, so relative ordering within each file survives. **That is a normalization with a stated rule, not a claim about the true minute** — `-24:40` most plausibly meant "just past midnight", but writing `2026-07-31-00:40` would be future-dated against today's local calendar and fail the very gate this PR extends. Clamping keeps every stamp real, ordered, and non-future; the exact minute was already unrecoverable. **Verified:** FNXC gate exit 0, lane-wiring gate exit 0, `task-list-board-columns` 5/5, lint clean. Comment-only changes to the CLI files (stamp text inside FNXC blocks), so no behaviour change and no changeset. Noted separately on #2992 so its two new stamps get corrected there rather than landing and immediately failing this gate. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 00:03:02 -07:00
gsxdsm	5adf0d955a	fix(scripts): the soft-delete reconciler wrote a literal archived into boards that do not have one (#2999) ... ## A repair script that wrote a column the board does not have Under `--apply`, against an operator's live database: ```js await tx.execute(sql`UPDATE project."tasks" SET "column" = 'archived' WHERE id = ${row.id}`); ``` On a board that does not declare `archived`, that is not a mislabel — it parks the row in a column the workflow does not have, **manufacturing exactly the undeclared-column state this migration keeps repairing elsewhere**. The selection was wrong in the same direction, which made the write far worse. "Leaked" meant `column !== "archived"`, so on a renamed board **every** soft-deleted row looked leaked — including the ones resting correctly in that board's own archived lane. The repair then rewrote them. The tool's fix *was* the damage. ## Three changes, because fixing one would have left the others deciding **The SQL pre-filter carried the same literal** (`AND "column" != 'archived'`), so the query and the planner each imposed the legacy vocabulary independently. Dropped it — soft-deleted rows are a small set, so selecting them all and filtering in the pure planner costs nothing and leaves **one** place that decides what "archived" means. **The filter takes the set**; a row resting in *any* of the board's archived lanes is not leaked. **The write resolves per task**, because the destination must be that card's own lane, not a board-wide pick. A row whose archived lane cannot be resolved is **skipped and reported**, never written with a guessed id. A recovery script that declines to act on rows it does not understand is recoverable; one that writes a plausible wrong value is not. Verified rather than assumed — a store that answers nothing resolves to the default lifecycle: ``` lifecycle from unanswering store: {"intake":"todo",…,"archived":"archived"} ``` so a legacy board repairs exactly as before. ## Correcting myself On #2994 I wrote that this follow-up "needs the same `importCore` seam". It doesn't: `openBackend` already returns `{ core, store, … }` and this script already destructures `core`. No new plumbing was required. I posted that correction on #2994 too, since acting on it would have wasted someone's time. ## Revert proof ``` ✖ a soft-deleted row already in the board's RENAMED archived lane is not leaked ✖ a board with several archived lanes treats all of them as resting places ℹ pass 5 ℹ fail 2 ``` The other two new cases pass both ways by design — they guard the legacy meaning and the still-catches-a-real-leak direction — so I am not counting them as coverage of the defect. ## Verification (measured) - `node --test` across all three script suites — **17 passed / 0 failed** - `node --check`, `eslint` — clean - `check-sql-column-literals`, `lifecycle-column-census --strict`, `check-lane-wiring`, `check-fnxc-future-dates` — green No changeset: root `scripts/` is repo tooling, not part of the published package. ## Gate blind spot found while verifying this, NOT fixed here I removed a raw-SQL lane literal and expected `check-sql-column-literals` to drop from 22 — its own header says *"a LOWER count fails too so the baseline is ratcheted down"*. It stayed at **22 and green**, because it walks `PACKAGES` only and **never scans `scripts/`**. That is the same shape as the lane-wiring gap #2978 closed (it scanned neither `plugins` nor `dashboard/app`). `scripts/audit-branch-cross-contamination.mjs:185` still holds `WHERE … "column" IN ('triage','todo','in-progress','in-review')`, invisible to the gate. Left as a separate follow-up rather than bundled into a product fix.	2026-07-30 23:59:54 -07:00
gsxdsm	ac67b8d585	fix(scripts): the FN-4000 consistency reconciler failed in BOTH directions on a renamed board (#2994) ... ## The FN-4000 consistency reconciler failed in *both* directions `findTaskStateInconsistencies` keyed both checks on legacy lane literals, and they break in opposite ways: ```js const hasDoneTransient = task.column === "done" && (status failed || error || worktree || blockedBy || …); if (task.status === "failed" && task.column !== "in-review") { … } ``` | check | on a renamed board | effect | | --- | --- | --- | | `hasDoneTransient` | **never fires** | a finished card still holding `status:"failed"`, a worktree, a blockedBy or live recovery counters is never reported and never normalized — precisely the stale state FN-4000 exists to clear | | `failed-status-outside-in-review` | **fires for every failed card** | no column equals the literal, so the report lists the whole board | The second is the more dangerous of the two: a tool that reports nothing looks broken, but a tool that reports everything looks like it is working. ## Wiring, and why the resolver is injected rather than built inline Lanes are resolved **per task** (a board can span workflows) and passed in. Resolving inside the loop would drag `importCore()` — and therefore a built `packages/core/dist` — into every unit test of a pure reconciliation loop. `main` wires the real resolver whenever it opened a real backend, so this is **not** the inert optional-parameter shape this migration keeps finding. A caller injecting its own store (tests) has no staged dist and falls back to the documented legacy literals, which is exactly today's behaviour. `importCore` is now exported from `scripts/lib/backend-db.mjs` so operator scripts reach core helpers through the **same staged-dist seam `openBackend` already uses**, rather than each growing its own dist path — `@fusion/core` is not resolvable from repo-root `scripts/`, which is what made the obvious import fail. The normalization move now targets the card's **own** column: naming `"done"` was only ever a way of spelling *"where it already is"*, since the move exists to trigger the store's done-normalization. ## One of my test expectations was wrong before the code was My first version asserted that a card in a renamed complete lane with `status:"failed"` yields only the transient-state finding. It yields **both** — and that is correct, because a failed card outside the review lane genuinely is flagged. I isolated the case (dropping `status:"failed"`, keeping the worktree) so it pins one behaviour instead of blurring two, rather than "fixing" the expectation to match whatever came out. ## Revert proof Restoring the four literals: ``` ✖ reports stale transient state in a RENAMED complete lane ✖ does NOT flag a failed card that is sitting in the board's own review lane ✖ runReconciliation normalizes a renamed complete lane by moving the card to its OWN column ℹ pass 5 ℹ fail 3 ``` The remaining two new cases pass both ways by design — "still flags a failed card outside the resolved review lane" and "unresolved lanes keep exactly the legacy behaviour" guard against over-correction, so I am not counting them as coverage of the defect. ## Verification (measured) - `node --test` — **8 passed / 0 failed** (3 pre-existing + 5 new) - sibling script suites (`recover-stale-blocked-by`, `reconcile-leaked-soft-deletes`) — **7 passed**, unaffected by the shared-lib export - `node --check`, `eslint` — clean - `lifecycle-column-census --strict`, `check-sql-column-literals`, `check-lane-wiring`, `check-fnxc-future-dates` — green No changeset: root `scripts/` is repo tooling, not part of the published package. ## Still not addressed in this territory `reconcile-leaked-soft-deletes.mjs` carries a raw `UPDATE project."tasks" SET "column" = 'archived'` — on a renamed board that writes a column the workflow does not declare, creating the undeclared-column state this migration keeps repairing elsewhere. It holds a raw backend rather than a store, so it needs the same `importCore` seam this PR exports; left for a follow-up rather than bundled here.	2026-07-30 23:49:05 -07:00
gsxdsm	65f4e8533e	fix(dashboard): blocker fan-out classified every board against the LEGACY lanes (finished cards shown as blockers; escalation never fired) (#2990) ... The dashboard's `computeBlockerFanoutMap` wrapper called core with **no lane answers at all**: ```ts return computeBlockerFanoutMapCore(tasks, MAX_AUTO_MERGE_RETRIES, { staleHighFanoutAgeThresholdMs: options.staleHighFanoutAgeThresholdMs, }); // no terminalColumns, no reviewColumns, no holdColumn, no classify ``` So every fan-out surface classified against `todo` / `in-review` / `done` regardless of what the operator named their columns. Core defines **active by exclusion — not terminal** — so on a renamed board a **finished** card never became terminal and stayed an active blocker forever. The Executor bar's highest-overlap blocker and the task modal's blocking-dependents list both kept naming work that had already landed. **Escalation was worse.** `shouldEscalate` requires the blocker to sit in an escalation lane (wip ∪ review), which unresolved means `in-progress`/`in-review` only — so a stale blocker holding up many cards **never escalated**. The fan-out numbers themselves stayed correct, which is what makes it easy to miss: the metric says there is a problem and the mechanism that acts on it is switched off. ## Shape **Per task, not a board-wide union** — the reason `blocker-fanout.ts` documents on `classify`: an id means something only relative to its own workflow, and this board renders several at once. `Board` builds the index exactly as `App.tsx` already does for the footer (`footerColumnFlagsByTaskId`): task → its own workflow → that workflow's entry for the column the card rests in. **Escalation = wip ∪ review**, mirroring `scheduler.ts`'s own construction. The two must agree — the scheduler decides a blocker escalates and the dashboard is where an operator sees it. **An empty trait map means "not resolved yet", not "nothing is terminal."** The pre-load window and the remote-node case keep the documented legacy default rather than fabricated lifecycle state. ## Reverted | case | reverted | |---|---| | a finished card in a renamed completion lane is not an active blocker | **fails** | | a stale high-fan-out blocker in a renamed wip lane escalates | **fails** | | unresolved traits stay byte-identical | passes either way — that is why it is there | ## Two notes - The hook call had to move below `useBoardWorkflows` in `Board` (it was at line 206, the workflows at ~390). `blockerFanoutMap` is consumed only in JSX, so the hook order change is unconditional and stable. - The unresolved-card fallbacks are hoisted into three named helpers with `DELIBERATE-LITERAL` markers on the **declarations** — the census reads markers from leading comments, so an inline one attaches to the wrong node and is silently ignored. Census baseline re-recorded in the same commit (debt did not increase; markers moved 5 sites out of the guard count). ## Not done `ExecutorStatusBar` and `TaskDetailModal` call the wrapper directly and still pass no traits. `ExecutorStatusBar` already receives `columnFlagsByTaskId` so it is a one-liner; `TaskDetailModal` has no trait index in scope and needs one threaded. Left out to keep this reviewable — the ratchet keeps both visible. ## Verification dashboard app suite **1919 passed (140 files)** · `pnpm test:gate` 161 + 13 + 487 + 71 · lint · census `--strict` · lane-wiring · fnxc-dates · changesets — green. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 23:41:14 -07:00
gsxdsm	bb6c08d9d6	fix(scripts): the blocked-by recovery reported "Repairs: 0" on a board it never examined (#2992) ... ## A recovery tool that reports "Repairs: 0" without having examined anything Every lane test in `recover-stale-blocked-by.mjs` is a legacy id: ```js function isTerminalColumn(column) { return column === "done" || column === "archived"; } const isActive = row.column === "in-progress" || (row.column === "in-review" && row.worktree && !row.paused); if (row.column !== "todo" || !row.blockedBy) continue; // ← the candidate gate ``` On a board whose lanes are named anything else, that gate matches **nothing**. The planner returns no findings and the script prints `Repairs: 0`. An operator running a recovery reads that as *"the board is fine"* when the tool never examined a single card. **A silently empty answer from a recovery tool is the worst shape available** — indistinguishable from success, and consulted precisely during an incident. This is not dead code: `docs/soft-delete-verification-matrix.md` cites it as the GREEN backstop for FN-5528, and it has its own test file. ## Detection only — and why I did not "fix" the classification Correct classification needs the board's resolved trait vocabulary. This script holds a **raw backend** (`openBackend` → `asyncLayer` + `sql`), not a `TaskStore`, so resolving lanes here would mean reimplementing IR trait resolution inside a `.mjs` script — a worse bug than the one it fixes, and precisely the kind of second, drifting copy this migration keeps deleting. So the assumptions are not repaired; they are made **loud**. That is the same principle the lane-wiring gate applies to itself: > a gate whose errors land on "nothing to report" is the one failure mode a ratchet must not have The unknown-lane list rides on the returned array as a **non-enumerable** property rather than widening the return type — `recoverBlockedBy` is consumed as `findings[]` by the entry point and by tests, and an operator may be scripting around that shape. ## The first test pins the gap rather than papering over it ```js assert.deepEqual(unrecognisedLanes(rows), ["backlog", "checking"]); // The gap this warns about, pinned rather than claimed fixed: the planner still sees nothing. assert.deepEqual(planRecoverBlockedBy({ rows, tasksDir }), []); ``` I would rather the next reader find that assertion than discover it themselves during an incident. ## Revert proof With `unrecognisedLanes` returning `[]` (the pre-fix behaviour): ``` ✖ names lanes the planner does not understand, so an empty result cannot read as healthy ✔ stays quiet on a legacy board, so the warning means something when it appears ✖ reports each unknown lane once, ignoring rows with no column at all ℹ pass 5 ℹ fail 2 ``` The legacy-board case passes **both ways by design** — it guards against the warning firing spuriously, so I am not counting it as coverage of the defect. ## Verification (measured) - `node --test` — **7 passed** (4 pre-existing + 3 new), 0 failed - `node --check`, `eslint` — clean - `check-sql-column-literals`, `lifecycle-column-census --strict`, `check-lane-wiring`, `check-fnxc-future-dates` — green No changeset: root `scripts/` is repo tooling, not part of the published package. ## How this was found, since the method matters more than the fix My batch is "cli + plugins + anything left", and I had been reading *"anything left"* as nothing. Eight packages and all of `scripts/` sit outside the four named batches. This is the first thing I found there; sibling one-shot scripts (`reconcile-task-state-consistency.mjs`, `reconcile-leaked-soft-deletes.mjs` — which contains a raw `UPDATE … SET "column" = 'archived'`) carry the same hardcoded assumptions and are **not** addressed here.	2026-07-30 23:41:03 -07:00
gsxdsm	cfe47b3754	chore(plugins): delete the superseded fusion-plugin-even-cards (#2790) (#2988) ... Closes #2790 by finishing a decision that was already made and written down. ## The issue's premise was wrong, including as I filed it I raised this as "a package accidentally missing from `pnpm-workspace.yaml`." It wasn't. `CHANGELOG-archive.md:9596`: > Consolidate Even Realities plugin support into `fusion-plugin-even-realities-glasses` and **remove `fusion-plugin-even-cards` from the active workspace package list to avoid duplicate user-facing integrations.** The removal was deliberate, for a stated reason. The directory is what got left behind. That also rules out the option I had been weighting first — adding it back would undo a shipped consolidation and re-create the duplicate integration it was removed to prevent. ## Unreachable by every path | check | result | |---|---| | `pnpm-workspace.yaml` globs | no — never installed or built | | CLI bundle list (`packages/cli/tsup.config.ts`) | no — 0 mentions, while seven other plugins are named | | runtime `plugins/*` directory-scan discovery | none exists — plugins are enumerated explicitly | | `package.json` | `private: true` — never published | | imports outside its own directory | none | | kept as a docs/authoring example | no — zero references in `docs/` or any root `*.md` | | successor in the workspace | yes — `fusion-plugin-even-realities-glasses` | ## It was also polluting two ratchets Dead code in a scanned tree is worse than dead code: both censuses are **source-text scanners**, so they counted debt in files no build or typecheck covers. Nobody could retire those entries through a normally-verified refactor, and they inflated how much of the remaining debt looked actionable. Both baselines regenerated, and I checked each diff rather than trusting the totals: | baseline | change | |---|---| | `lane-wiring` | 26 → 23 sites, 21 → 20 files — **one entry removed**, `board-routes.ts: 3` | | `lifecycle-column-census` | exactly its two `board-cards.ts` entries | Neither regeneration tightened anything unrelated — worth confirming explicitly, because `lifecycle-column-census.mjs --strict` **writes** its baseline as a side effect and could have folded an unrelated drop into this commit. **Verified:** lane-wiring, SQL-literal and FNXC gates all exit 0 after the deletion; lint clean. 15 files removed. ## Why I went ahead I said twice I would not delete this unilaterally. What changed is that the trade-off dissolved — once the consolidation decision turned out to be documented and the "is it a teaching example?" question answered by a docs grep, there was nothing left to decide, only to execute. The deletion is git-reversible and the standing guidance is that reversible calls are mine to make. Fourth time today a thing I filed as "needs someone else's judgement" turned out to have its answer already in the repository. Cheap habit worth keeping: before deferring, grep for whether the judgement has already been made. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 23:35:25 -07:00
gsxdsm	684c324084	fix(gate): the lane-wiring census counted { reviewColumns: undefined } as wired (#2984) ... ## What Follow-up to the finding @gsxdsm left on #2981, taking the direction offered there. Both arms of this census asked whether the lane argument was **present**, not whether it carried anything: ```ts isThing(task, { reviewColumns: undefined }); // property present -> counted as wired isThing(task, undefined); // arity satisfied -> counted as wired ``` The callee receives exactly what it received before: nothing. The seam is still inert, the board still reads the legacy vocabulary — the census just stops saying so, which is the one failure mode a ratchet must not have. Same defect as the positional one #2981 fixes in `check-inert-flag-seams`, one level in. The two gates are complementary by design — this one owns the options-object and default-valued shapes the other is structurally blind to — so the hole had to be closed in **both**. Neither covered it, confirmed by probing each with a control shape. ## The direction I took, since the review raised it as a contract question > *tightening just relocates the dishonesty into whichever spelling survives... especially as I have already spent three attempts learning that heuristic tightening here trades false positives for worse false negatives.* Agreed, which is why this is the narrowest possible reading rather than a heuristic: **Only a literal `undefined` / `void 0` counts as empty.** Shorthand `{ reviewColumns }` forwards a variable whose value is not knowable from syntax, and treating it as unwired would flag every correct forwarding wrapper in the tree — exactly the false-positive wave that trains readers to skip a gate. Same for a call expression, a conditional, or anything else with a value at runtime. That keeps the rule provable from syntax alone. It doesn't relocate the dishonesty so much as remove the one spelling that is *demonstrably* empty; anything ambiguous still counts as wired, so the gate stays conservative in the direction that matters. ## No tests existed for this census `check-lane-wiring` and `lane-wiring-census.mjs` had no unit coverage on `main`, so both rules ship with tests rather than resting on the probe that found them. ## Measured | check | result | |---|---| | clean `main` | exit 0, unchanged — all five gates green | | now caught | property spelled `undefined` · property spelled `void 0` | | correctly **not** flagged | a real value · shorthand forwarding · a call-expression value · a middle `undefined` with a real argument after it | | new suite | **8 tests**; reverting both rules fails **exactly** the 3 positives, negatives hold | ## Not done here, deliberately The second finding on #2981 — `computeBlockerFanoutMap`'s dashboard wrapper dropping all four lane options, so the fanout display reads legacy literals on a renamed board — is **not** in this PR. Confirming the diagnosis: `useBlockerFanout.ts`'s `UseBlockerFanoutOptions` declares only `staleHighFanoutAgeThresholdMs` and forwards only that, and all three dashboard call sites (`Board`, `TaskDetailModal`, `ExecutorStatusBar`) have the same gap. One correction to how it's framed, though: core already has the right seam for it. `classify` and `escalationClassify` are documented there as *"the only correct option on a multi-workflow board"*, precisely because the set-shaped options assume a column id means the same thing everywhere. So the fix should thread **per-task classifiers**, not resolved column-flag sets — otherwise it reproduces the union read that this program's own learnings doc lists as the fourth failure shape. What's genuinely undecided is where a per-task role answer comes from in a sync render path: `Board` holds `columnDef.flags` for the *selected* workflow only, and the dashboard has no per-task resolver hook. That's the design call, and it's dashboard-batch work rather than a mechanical edit — so I've left it for whoever owns that batch rather than guessing at it inside a gate PR. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 23:30:07 -07:00
gsxdsm	16921fc518	fix(engine,core): role resolution was half-done in two shared lifecycle predicates (surfacing family + file-scope leases) (#2975) ... The three surfacing sweeps stopped reporting anything for a card resting in a board's **second** review or hold column. A lifecycle role is a **trait**, and any number of columns may carry it. The shared runner resolved it with `resolveLifecycleColumns()[role]` — **first match** — then gated on it: ```ts const roleColumn = lifecycle?.[spec.role]; // FIRST column carrying the trait if (task.column !== resolved.roleColumn) continue; // everything else dropped ``` A workflow that splits human sign-off from the merge lane has two review columns; one that parks dependency-blocked cards separately has two hold columns. Cards in the second got **no stale-paused-todo, no stale-paused-review, no in-review-stalled** diagnostic — silently, with no error, on all three sweeps at once. ## The second bug hiding inside the fix for the first Resolving membership but still reading `roleColumns[0]`'s declared `recovery` applies the **merge lane's** threshold to a card sitting in the **sign-off** lane. Each card's policy now comes from its own column, and one of the new cases fails if it doesn't: the first role column declares a policy that suppresses the signal, the card's own column declares one that fires. ## Reverted | | | |---|---| | **6 of 12** new cases fail | `fires for a card in the SECOND column carrying its role` and `reads the recovery policy of the card's OWN role column` — × 3 sweeps | | the other 6 pass either way | non-regression halves: still fires for the FIRST role column, still does **not** fire for a card outside every role column. Membership must widen the gate, not move it. | The pre-existing 45 cases were all green throughout — the single-role-column fixture could not express the case, which is why the table-driven file that exists to stop these three sweeps drifting apart never caught it. ## Verification `pnpm test:gate` 161 + 13 + 487 + 71 · surfacing family 57 · core stale-paused 20 · lint · census `--strict` · sql-literals · fnxc-dates · lane-wiring · changesets — all green. ## Note `holdColumns` was missing from the lane-wiring vocabulary, so the gate could not see that argument dropped. Added in the same commit. While reviewing, I found and measured **two problems in #2974** (comment posted there): six of its newly-visible sites are `satisfies`-wrapped false positives, and baselining them means deleting a real `reviewColumns` argument keeps the count unchanged and the gate green; and its baseline predates #2970, re-opening the slot that PR closed. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved stale-card detection across all applicable review and hold columns. * Cards are now surfaced using the policies configured for their specific lifecycle column. * Cards outside matching lifecycle columns are no longer incorrectly surfaced. * Preserved existing fallback behavior when no lifecycle columns are configured. * **Tests** * Added coverage for workflows with split review and hold columns. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --- ## Second commit: the same predicate, half-converted (`shouldHoldActiveFileScopeLease`) Folded in here rather than stacked — same file, same class, and a stacked PR on an unmerged base is not mergeable. Reversible; say the word and I'll split it. `shouldHoldActiveFileScopeLease` is the **scheduler's** lease predicate, shared with the self-healing repair paths deliberately so the two cannot disagree about who holds a file-scope lease. Its two role answers are optional parameters defaulting to the legacy ids. The scheduler's own call sites were converted to pass resolved answers; self-healing's two were not: ```ts const isWipColumn = options?.isWipColumn ?? task.column === "in-progress"; const isReviewColumn = options?.isReviewColumn ?? task.column === "in-review"; ``` On a renamed board neither branch matches, so the predicate returns `false` for every card. The scheduler kept the lease; self-healing saw none, cleared `overlapBlockedBy`, and **released a dependent to edit files another agent still holds** — the outcome `groupOverlappingFiles` exists to prevent. Membership comes from the wip/review sets each sweep already resolved a few lines above, so this adds no reads. **Reverted:** both new cases fail with `overlapBlockedBy` = `null` — the release itself, not a proxy. The pre-existing legacy-column case in the same file passes either way, because `in-progress` satisfies the literal default; that is exactly why it never caught this. Lane-wiring baseline re-recorded `9 -> 7` in the same commit (the ratchet refused a stale allowance, as intended). **Verification:** gate 161 + 13 + 487 + 71 · surfacing 57 · overlap-seam + scheduler-lease + query-blindness 79 · core stale-paused 20 · lint · census `--strict` · sql-literals · fnxc-dates · changesets — green.	2026-07-30 23:13:34 -07:00
gsxdsm	2411699756	fix(gate): passing undefined for the lane answer read as supplying it (#2981) ... ## What Continuing the #2979 discipline — probe a ratchet with shapes its author did *not* have in mind — applied to my own inert-seam gate. Four probes, three got through. Two turned out to be the sibling gate's job. This is the one that's nobody's: ```ts resolveSomething("KB-1", undefined) ``` The seam is a trailing optional parameter, so the gate asked how many **arguments** a call site passes. Spelling the omission out satisfies that count while the callee receives exactly what it received before: nothing. The parameter is still inert, the board still reads the legacy vocabulary — the gate just stops saying so. Not an exotic spelling. It's what a partial wiring-up produces when flags are threaded through an intermediate that has none to pass, and what a mechanical positional edit produces when it fills argument slots. ## Missed by both gates — checked before touching anything `check-lane-wiring` (#2966) covers the default-valued and options-object shapes this gate is structurally blind to. I probed it first, and it caught **both**, so the two remain genuinely complementary rather than overlapping. But it counts arguments the same way here, so this shape was uncovered by either. | probe | inert-seam (before) | lane-wiring | |---|---|---| | omitted entirely | caught | — | | default-valued param | missed | **caught** | | options-object flags | missed | **caught** | | explicit `undefined` | missed | **missed** ← this PR | ## The trim is trailing-only A **middle** `undefined` still positions the arguments after it, so those are real answers. That's the case that keeps the trim honest, and it's pinned as a test. ## Measured | check | result | |---|---| | clean `main` | exit 0, unchanged | | now caught | explicit `undefined` · `void 0` · several trailing undefineds | | correctly **not** flagged | a real trailing value · a middle `undefined` with a real value after it | | gate's own suite | **12 → 18 tests**, all green | | reverting to the raw argument count | fails **exactly** the 3 positives; the negatives hold | ## One note on the fourth gate `check-fnxc-future-dates` went red on this branch — on my own comments. I'd stamped them `2026-07-31`, which is tomorrow. Fixed by correcting the stamps to today, not by re-recording the baseline; the baseline already tolerates some pre-existing future stamps and adding mine to it would have been appeasement. Worth noting that the gate earned its keep against the person who has been writing the other gates. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 23:08:08 -07:00