Files

gsxdsm ba40942a10 batch-dashboard-app: 75 → 2 across packages/dashboard/app — the last two are deliberate, not missed (#2772 )

**Batch branch is live: `batch-dashboard-app`.** Push conversions here
as commits rather than opening per-file PRs — that is the CI-run
bottleneck this model removes.

**One-line ownership note for you to arbitrate:** you have addressed me
as U11, U12 and U7 at different points, so the `u12 worker ->
batch-dashboard-app` mapping is ambiguous from my side. I claimed it
because `dashboard/app` is where I have done the most work this session
(TaskContextMenu, Column, TaskCard, TaskDetailModal, columnRoles,
taskActivity) and I know which of its guards are load-bearing fallbacks.
**If another worker is the intended owner, say so and I will hand the
branch over rather than both of us pushing to it** — two workers on one
shared branch is exactly what silently discarded a reviewed fix in #2645
today.

## The work order (measured at branch point, tests excluded)

**75 guards across 32 files.** Largest: `TaskContextMenu.tsx` 9 ·
`Column.tsx` 7 · `ListView.tsx` 6 · `TaskDetailModal.tsx` 4 · then a
long tail of 3s, 2s and 1s. Full per-file list is in the committed work
order so feeders can claim without re-measuring.

## Two rules this surface keeps tripping on

**1. A literal after `??`, or in the `else` of a `flags ?` ternary, is a
DEGRADED-MODE answer — not an unconverted guard.** Two real states reach
it: the **pre-load window** (board renders before the workflows fetch
resolves) and a card stranded on an id its workflow no longer declares.
In both, `columnFlagsById` has no entry at all. Deleting the fallback
does not remove a decision — it substitutes "no role" silently, and
affordances vanish during first paint.

Those sites reach 0 by **marking**, not deleting. Expect
`TaskContextMenu.tsx` and the `utils` files to be **mostly marks**. A "9
→ 0" that deleted 9 fallbacks is a regression wearing a green census.

**2. A marker excuses ONLY the construct it is attached to** — the
statement or function holding the literal, not a sibling declaration.
This has cost three passes, two of them mine; my first attempt on
`reliability-metrics.ts` scored **1 of 6**. **Verify by the count
moving, not by the comment existing.** With the ratchet gate-blocking, a
mis-marked batch either wedges the gate or locks the miss into a
re-recorded baseline.

## Status

Opening commit is the work order only — **0 of 75 converted so far.** I
am near the end of my context, so I am establishing the branch and the
shared list rather than starting conversions I cannot finish cleanly.
Feeders can begin immediately; I will keep the branch rebased.

My other PR **#2762** (`live-agent-count.ts` 6 → 0) is green and
unconflicted — per your rule it should land rather than fold into a
batch, and it is `packages/core` so it belongs to batch-core anyway.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Task UI now resolves workflow “column roles” per task to drive
diffs/merge details, routing/steering, progress/runtime visibility, and
review badges.
* Right-dock/overflow views and dev-server now use per-task column
traits for “executing” behavior and dependency-based “Up Next”
eligibility.
* **Bug Fixes**
* Fixed bulk action selection/delete/archive eligibility and prevented
cross-workflow role leakage.
* Made in-review/stale-paused-review, stuck, and effective
executor/validator model logic role-aware.
* **Tests**
* Added regression coverage for degraded-flag behavior and ensured
resolved-flag props aren’t ignored.
  * Added a static check to fail builds on inert optional flag seams.
* **Documentation**
  * Updated batch work-order and mega-batch branch guidance.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---

## Late addition: the seam gate was masking a real offender

`scripts/check-inert-flag-seams.mjs` matched call sites by NAME, so two
same-named functions in
different modules were conflated. I had documented that as a known
false-positive source and moved
on — reports mentioning `sortTasksForDisplayColumn` are noise, read past
them.

That annotation was the damage. Core's `sortTasksForDisplayColumn`
genuinely never receives its
`columnFlags` argument outside its own tests. The dashboard's separate
function of the same name
(`app/components/taskSorting.ts`), called with up to five arguments from
`Lane`/`Board`/`ListView`,
was raising the arg-count max and clearing core's seam. The offender was
behind a row everyone had
been told to skip.

The gate now records the module each callee is imported from and matches
it against the seam's
declaring module.

**Measured, by reverting the change:** the scan prints `17 seams, all
supplied` and emits **no row**
for the function. With the change, it is reported. Both directions
watched.

Reported on #2783 rather than fixed from outside — core owns it, and
"wire the flags" vs "drop the
parameter and let the literal stay counted" is their judgment call.
TEMPORARY allow-list entry
carries it meanwhile; the existing staleness check fails the moment the
site becomes supplied, so
the entry cannot outlive the fix.

Two known limits remain, both inherent to name matching and both
documented in the script: the
one-supplier floor, and the `__tests__` exclusion (hence the two
permanent `ALLOWED` entries).


## And the one-supplier floor, closed the same way

I wrote in the section above that the floor "hasn't cost anything yet."
That is verbatim the
reasoning that kept the imported-shadow bug alive, so I closed it
instead of leaving the note.

`best < arity` asked only whether SOME caller supplied the argument. One
correct call site cleared
the seam while every sibling took the legacy fallback — the
`isTaskStuck` defect class, where two of
three sites omitted the flags and the gate stayed green because the
third was right. Review caught
that one. A partially-supplied seam is the harder of the two:
wholly-unsupplied is uniformly wrong,
this works on the board you tested and degrades on the column you did
not.

**Measured:** dropping the flags argument at `Column.tsx`'s supplied
call site produces
`supplied by 5/6 call sites; omitted at
packages/dashboard/app/components/Column.tsx:1 (of 2)`;
restoring returns `all supplied at every call site`. Red and green both
watched.

Two real omissions found, both on `isNearDuplicateCanonicalInactive`:

- **`TaskDetailModal.tsx`** — deliberate, and it **corrects a note I
left at that site**. The old
note said hoisting the flags state was "the actual fix." It is not, for
this call: the flags in
scope describe the *modal's* task, and the canonical is a **different
task** on a column this
component never resolves. Passing them would type-check, read as a
conversion, and answer about
the wrong task — exactly what `column-role-degraded-flags.test.ts`
exists to catch. Supplying it
  correctly needs a fetch, which is a data change and out of scope.
- **`core/task-store/branch-group-ops.ts`** — genuinely wireable (the
impl is async and already
holds `store` and `canonicalId`). Reported on #2783, not edited from
outside.

Exemptions for this class are keyed by **call site**
(`<file>::<function>`), not by function name.
A name-level entry would waive every site of a partially-supplied seam,
which is backwards — its
other sites are correct and are the reason the omission is worth
reporting. Both entries carry the
same staleness check as the name-level list and cannot outlive their
fix.

Remaining known limit, now the only one: the `__tests__` exclusion,
which makes a test-only export
read as having no callers. That is what the two permanent `ALLOWED`
entries are.


## The `__tests__` exclusion, and two allow-list entries built on false
reasons

Named as the "last remaining limit" above, so it got closed too. The
scan now reads test files for
call sites — but counts them **separately**, and a test never clears a
seam. That direction is the
dangerous one: counting test callers as suppliers would have re-hidden
core's
`sortTasksForDisplayColumn`, whose only suppliers are its own tests.
Measured by lifting its
exemption: still reported.

Both permanent allow-list entries claimed the scanner couldn't see their
callers. **Both reasons
were false**, and reading tests is what proved it:

- **`evaluateMergeBlockerGuard`** — zero callers in tests either. Its
only reference in the repo is
its own declaration; never registered as a trait hook; the
`evaluateDefaultWorkflowGuards` reader
its file header credits does not exist. The `lifecycleColumns`
conversion went onto dead code, and
its note describes a crossing the guard cannot make. Reported on #2783,
including the two things I
am explicitly *not* concluding (no `"guard"` hook is registered in
production; whether that is
  residue or a dropped registration needs core's intent).
- **`isRecoverableMissingWorktreeReviewFailure`** — 5 test call sites.
It wraps
`...WithProgress`/`...NoProgress`, the live pair called from
`self-healing.ts`, both supplying
  `reviewColumns`. Entry kept, true reason recorded.

### A wrong turn, recorded because it is the failure mode this PR is
about

I first classified no-production-caller seams as *informational* when
they weren't re-exported from
a package index, reasoning that a public export might be called
externally. That silently downgraded
`sortTasksForDisplayColumn` — a confirmed real offender — from failing
to a footnote. Publication
status has nothing to do with whether there is production behaviour to
be wrong. Reverted to the
simple rule: no production caller means inert, and it fails.

It is worth stating plainly because it is the exact shape of everything
else in this PR: a change
that made the gate read *cleaner* while making it catch *less*, and it
type-checked, passed every
test, and would have reviewed fine.

### Where that leaves the check

Every blind spot named in this PR has now been closed, and **each one
produced a real defect within
minutes of closing it** — imported shadows, the one-supplier floor, the
`__tests__` exclusion. Four
verified findings went to core, one to engine. I would not read the
remaining ~240 guards' green
gates as evidence that they are clean; I would read them as untested.


## Two guards for one question, one of them worse

Having hardened the script, I checked its older twin rather than
assuming it was fine.
`resolved-flags-seams-have-suppliers.test.ts` carried its own copy of
the trailing-flags-parameter
check — written before the script existed — with **all three** holes the
script has since closed.

**Measured on one reintroduced defect** (dropping the flags argument at
`Column.tsx`'s supplied
`isNearDuplicateCanonicalInactive` call):

| | result |
|---|---|
| `scripts/check-inert-flag-seams.mjs` | `supplied by 5/6 call sites;
omitted at .../Column.tsx:1 (of 2)` |
| this test's arity half | **3 passed** |

Deleted the arity half. Redundancy between a strong and a weak check
isn't redundancy — it's a green
result available to whoever runs the weak one, and there was no signal
at the call site telling you
which you were looking at.

The **props-shape half stays**: it has no twin in the script, and I
confirmed it still fires by
reintroducing the original `PrPanel` defect (outer component stops
destructuring `taskColumnFlags`)
— it reports `PrPanel declares taskColumnFlags but never takes it`.

Dashboard app suite: **113 files / 3921 tests** (was 3922 — the deleted
case is the difference).


## The gate started catching defects as they landed

Syncing with main brought in three fresh conversions from other workers.
The hardened check flagged
all three immediately — the first time these guards have fired on
someone else's landed code rather
than on my own.

- **`TaskCard`** — `getRunningOptionalGateBadge(task)` omitted flags
while *both* `ListView` sites
supplied. Fixed, and `taskColumnFlags` added to the `useMemo` deps: no
`exhaustive-deps` rule here,
so a memo that reads flags without listing them keeps the first-paint
`undefined` answer and
  reproduces the bug through staleness instead of omission.
- **`TaskTokenStatsPanel`** — `getTotalAgentActiveMs` omitted while
`TaskCard` supplied, so the same
runtime number came from the real column on a card and from legacy ids
in the detail modal. Now
takes `columnFlags`, supplied from `detailColumnFlags` — correct here
because the panel renders the
  modal's **own** task, unlike the near-duplicate canonical above.
- **`ListView` ×2** — passed `columnFlagsById.get(task.column)`, the
cross-workflow **union**. A task
whose own workflow doesn't declare that column gets a *neighbour
workflow's* traits. The landed
comment justified it as "this list already owns `columnFlagsById`" —
exactly the reasoning
`column-role-degraded-flags.test.ts` exists to reject. It failed on
merge and is how I found this.

Also: the `getTotalAgentActiveMs` exemption I was carrying
**self-retired**. Main wired the seam, the
staleness check failed the entry, and I removed it. That mechanism has
now paid for itself once.

### Pre-existing, NOT from this PR: `App.test.tsx` is red on main

`app/components/__tests__/App.test.tsx` fails **10 of 141** identically
with my changes, with my
changes stashed, and with main's own `App.tsx` restored. Not mine, and
not in the merge gate.

**Bisected on clean `main` checkouts, so this is measured rather than
inferred:**

| commit | date | result |
|---|---|---|
| `main~400` (`41d60f0355`) | 2026-07-25 | **140 passed** (140 tests) |
| `main~275` (`74d6513fae`) | 2026-07-27 | 3 failed / 141 |
| `main~210` (`d2ce1ba8b5`) | 2026-07-29 | 10 failed / 141 |
| `main` (`6fc98fd6c7`) | 2026-07-30 | 10 failed / 141 |

So it is **not one regression** — it degraded in two stages across
2026-07-25 → 07-29, and the test
file itself changed in that window (140 → 141 tests). Three commits
touched it there:
`73b2a32e2b`, `f26cbedf4f`, `f157bf7460`. That window overlaps the
workflow-owned lifecycle
migration, which is suggestive but not something I confirmed.

The failures are render-level, not assertion-level — `Unable to find an
element with the text: + New
Task`, `Unable to find role="dialog"`, `Unable to find ... Back nav
task`. The board appears to
render nothing. That reads like a real regression or a harness mismatch
after the lifecycle
migration, not a flake, so I have deliberately **not** quarantined it —
quarantine is for flakes, and
using it here would hide the signal. Flagging for whoever owns
`App.tsx`.

My suites: `app/__tests__` **113 files / 3921 tests** green, `tsc` 0,
lint 0, census `--strict` 0,
seam gate 0.

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-07-30 12:46:12 -07:00

11 KiB

Raw Blame History

category, module, tags, problem_type, applies_when

batch-dashboard-app — the work order

CLAIMED — do not re-convert (u12 worker, 2026-07-30)

TWO WORKERS ARE ON THIS BRANCH. The coordinator assigned this batch to the u12 worker and another agent opened it; rather than contest ownership we are both feeding it, taking from opposite ends of the list. One of us should stand down — flagged to the coordinator, unresolved as of this note.

ALREADY CONVERTED IN GREEN PRs, so converting them here duplicates work and will conflict:

Column.tsx 7 -> 0 PR #2738 (green, mergeable) — also fixes a board-level workflowMode flag answering a per-column question, which blanked every affordance on a column the workflow no longer declares ListView.tsx 6 -> 0 PR #2738 — same change, plus per-TASK flag resolution for bulk actions

Those are the next two entries in the list below by size. Skip them.

SIZED AND NOT CONVERTED — the ORIGINAL seven, u12: six now wired, one genuinely blocked

UPDATE 2026-07-30-20:10. Six of the seven below are now converted end to end, each threaded from a parent that already resolves flags (TaskDetailModal's detailColumnFlags, or MainContent's columnFlagsByTaskId). The exception is the last one, and it is worth reading before anyone "finishes" it:

ResearchTaskActionModal — threading the board's flags map here is the WRONG fix. The modal fetches its OWN page via fetchTasks(50, 0, projectId), not the board's task set, and the rows this filter cares about are ARCHIVED ones — exactly the rows a board-built map does not contain. It would look converted, drop the count, and leave the case it exists for unresolved. The honest fix is resolving lanes for the page it fetched: a fetchTasks variant returning flags, or a per-task resolution over the 50 rows. Data-fetch change, not prop threading.

DevServerView — CLOSED 2026-07-30-20:30. Was converted on its MainContent surface only, with the right-dock overflowViewRegistry path still falling back; both surfaces are now covered because OverflowViewRenderProps carries columnFlagsByTaskId. Kept here because the reasoning matters: the guard count read 0 for the file the entire time ONE surface was broken.

BATCH CLOSE-OUT — 75 -> 6, and the six are the TRUE number (u12, 2026-07-30-22:40)

This section was rewritten three times as the batch progressed and had gone self-contradictory — claiming 75 -> 6 in one line, "TWO guards" in the next, and listing files the dock fix had already closed. Replaced wholesale with the measured final state rather than patched again.

2 utils/taskRevert.ts REVERTED to literals — findOpenUndoTaskForSource's only caller sits ~60 lines above where detailColumnFlags is derived, so it cannot supply them. 2 utils/taskTiming.ts REVERTED to literals — both callers reach these from module-level helpers with no flags in scope. 1 components/ResearchTaskActionModal.tsx Fetches its OWN page; a board-built map misses the archived rows this filter is about. Needs a data-fetch change. 1 components/TaskCard.tsx Left counted by an earlier pass on purpose, "so the census keeps pointing at the class". Not overridden from outside.

WHY THE COUNT WENT UP AT THE END. It read 2 before the seam guard (__tests__/resolved-flags-seams-have-suppliers.test.ts) was added. That guard found FIVE inert conversions in one tranche of mine — parameters and props that no caller supplied, so the literal was gone, the census had banked the credit, and the legacy fallback ran forever. Three were wired; three were reverted to literals because their callers genuinely cannot supply flags.

So 6 is honest and 2 was not. An optional parameter every caller omits is strictly worse than the literal it replaced.

CLOSED SINCE THE EARLIER DRAFTS: DockTaskList (3) and DevServerView's dock surface, both by the one registry change; useTasks (1), by deleting a check the line below it already implied.

RESOLVED 2026-07-30-06:20 — the cross-batch coupling is GONE, and my flag of it was wrong

I previously recorded useTasks.ts <-> core/src/in-review-stall.ts as a coupling that had to be ordered: both keyed on the literal, so no badge was produced and none needed clearing, and converting the core gate alone would regress.

THAT WAS WRONG ON ONE OF THE THREE SIGNALS. getInReviewStalledSignal is ALREADY trait-converted (U4), so inReviewStalled is produced on a renamed board today — and the dashboard literal was already refusing to clear it while a review agent wrote logs. A live bug, not a scheduled one.

Fixed by DELETING the dashboard column check, which the line below it already implies: all three stall fields are only ever produced for review-lane cards, because each producer gates on review itself. Converting was not an option anyway — it would need a flags map threaded into useTasks, and that map is built in App FROM the list this hook produces.

NOTHING IS BLOCKED ON ORDERING ANY MORE. batch-core can convert getInReviewStallReason and detectStalledReview whenever it likes; the dashboard side no longer cares.

ORIGINAL SIZING (kept for the reasoning):

These have NO column flags in scope. Adding an optional columnFlags parameter to each and calling it a conversion would be inert: no caller passes anything, behaviour is unchanged, and the census drops by seven. That is the half-conversion trap this program has hit repeatedly, so they are sized here instead of faked.

Each needs its CALLER threaded, which is a per-component change, not a sweep:

MergeDetails.tsx complete role task.column !== "done" gates the whole panel ChangesDiffModal.tsx complete role const isDone = column === "done" RoutingTab.tsx wip role active-task check, same shape as taskActivity's TaskPlannerChatTab.tsx wip role const agentRunning = task.column === "in-progress" DevServerView.tsx wip role filters worktree-bearing wip cards ResearchTaskActionModal.tsx archived role filters archived out of a picker PrPanel.tsx hold role renders one hint string; lowest value of the seven

The cheapest route for most of them is the prop their parent already resolves — TaskCard and ListView both hold per-task flags today, and four of these seven render beneath one of those.

MARKED, NOT CONVERTED (census false positive):

command-center/liveSnapshotMetrics.ts isInProgressColumn matches DISPLAY-NAME aliases ("in progress", "doing") for a funnel stage against snapshot labels. No task, no workflow, bare string signature. The aliases exist so custom boards do not show zero work — widening them is the documented intent, converting them is impossible without inventing a task to resolve.

DONE ON THIS BRANCH BY u12 (working the tail upward, so the largest-first pass does not collide):

taskActivity.ts 3, worktreeGrouping.ts 3, taskRevert.ts 2, taskTiming.ts 2, inReviewStallCopy.ts 1, stalePausedReviewCopy.ts 1, taskStuck.ts 1, useExecutorStats.ts 1

Branch: batch-dashboard-app. Feed conversions here as commits; do not open per-file PRs. Measured at the branch point, packages/dashboard/app only (tests excluded).

9  packages/dashboard/app/components/TaskContextMenu.tsx
  7  packages/dashboard/app/components/Column.tsx
  6  packages/dashboard/app/components/ListView.tsx
  4  packages/dashboard/app/components/TaskDetailModal.tsx
  3  packages/dashboard/app/components/DockTaskList.tsx
  3  packages/dashboard/app/components/TaskCard.tsx
  3  packages/dashboard/app/components/TaskChangesTab.tsx
  3  packages/dashboard/app/components/TaskChatTab.tsx
  3  packages/dashboard/app/hooks/useTaskDiffStats.ts
  3  packages/dashboard/app/utils/taskActivity.ts
  3  packages/dashboard/app/utils/worktreeGrouping.ts
  2  packages/dashboard/app/App.tsx
  2  packages/dashboard/app/components/Board.tsx
  2  packages/dashboard/app/components/DocumentsView.tsx
  2  packages/dashboard/app/components/WorkflowResultsTab.tsx
  2  packages/dashboard/app/components/effective-model-resolution.ts
  2  packages/dashboard/app/utils/taskRevert.ts
  2  packages/dashboard/app/utils/taskTiming.ts
  1  packages/dashboard/app/components/ChangesDiffModal.tsx
  1  packages/dashboard/app/components/DevServerView.tsx
  1  packages/dashboard/app/components/MergeDetails.tsx
  1  packages/dashboard/app/components/PrPanel.tsx
  1  packages/dashboard/app/components/ResearchTaskActionModal.tsx
  1  packages/dashboard/app/components/RoutingTab.tsx
  1  packages/dashboard/app/components/TaskPlannerChatTab.tsx
  1  packages/dashboard/app/components/command-center/liveSnapshotMetrics.ts
  1  packages/dashboard/app/hooks/useExecutorStats.ts
  1  packages/dashboard/app/hooks/useTasks.ts
  1  packages/dashboard/app/utils/inReviewStallCopy.ts
  1  packages/dashboard/app/utils/quickAddStart.ts
  1  packages/dashboard/app/utils/stalePausedReviewCopy.ts
  1  packages/dashboard/app/utils/taskStuck.ts
TOTAL 75

Before you convert: the two rules this batch keeps getting wrong

1. A literal after ??, or in the else of a flags ? ternary, is a DEGRADED-MODE answer — not an unconverted guard. The trait path above it is already correct; the literal runs when the trait path has no input. Two states reach it and both are real: the PRE-LOAD WINDOW (the board renders before the workflows fetch resolves) and a card stranded on an id its workflow no longer declares — in both, columnFlagsById has no entry at all. Deleting the fallback does not remove a decision, it substitutes "no role" silently, and affordances vanish during first paint.

So those sites reach 0 by MARKING (DELIBERATE-LITERAL with the reason), not by deleting. Files in this list that are mostly role helpers — TaskContextMenu.tsx, columnRoles-adjacent utils, taskActivity.ts — should be expected to be mostly marks. A "9 -> 0" here that deleted 9 fallbacks is a regression wearing a green census.

2. A marker excuses ONLY the construct it is attached to. Attach it to the statement or function holding the literal — not to a sibling declaration, and not to the enclosing file comment. This has now cost three separate passes (including two of mine); my first attempt on reliability-metrics.ts scored 1 of 6. Verify a marker by the count moving, not by the comment existing — the ratchet is gate-blocking now, so a mis-marked batch either wedges the gate or locks the miss into a re-recorded baseline.

Per-file census in the PR body

Rule from the brief. Take the number from node scripts/lifecycle-column-census.mjs before and after, per file, and re-record the baseline in the same commit that lowers it.

11 KiB Raw Blame History

batch-dashboard-app — the work order

CLAIMED — do not re-convert (u12 worker, 2026-07-30)

Before you convert: the two rules this batch keeps getting wrong

Per-file census in the PR body

11 KiB

Raw Blame History