From 7763063cbdaaeaea781c6311885bb8de0dcb41f7 Mon Sep 17 00:00:00 2001 From: gsxdsm Date: Thu, 30 Jul 2026 16:17:37 -0700 Subject: [PATCH] docs(task-revert): the recorded conversion "blocker" is a correctness boundary, not a cost (#2868) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `findOpenUndoTaskForSource` carries a note saying its conversion is blocked on **hoisting the flags derivation** in `TaskDetailModal` — framed as a hook-ordering cost in a 5000-line component, i.e. something somebody could pay. I went to pay it, and the framing is wrong in a way that would have produced a **worse defect than the literal**. ## Why hoisting would not unblock it This function scans the `tasks` list for **other** tasks pointing back at the source, so the column it classifies belongs to a **neighbour**. `detailColumnFlags` describes the **modal's own** task — its own FNXC note says exactly that, and it is guarded by `detailFlagsAreForThisTask` *precisely because* using it for anything else is wrong. So supplying it here would answer *"is this neighbour finished?"* with the modal task's traits. On a project where two workflows reuse a column id, an open undo task gets classified by a workflow it does not belong to, and the "Undo task" affordance vanishes or persists wrongly. **Wrong flags are worse than a stale vocabulary.** The literal is at least uniformly legacy; this would be wrong *on data*. It is the flags-for-the-wrong-row shape — the same question I have been applying all program: *do these flags describe the column of the row this guard is about?* ## What a correct conversion needs Per-**neighbour** flags: the caller would have to resolve each candidate's own workflow, which the modal does not have and should not fetch mid-render. Until a per-task lane map exists at that call site, **the literal is the right answer**. ## Why this is worth a PR rather than silence The previous note is an invitation. Somebody following it would land a plausible-looking conversion, drop the census count by one, and introduce a data-dependent bug that only appears on multi-workflow projects — the exact "conversion that scores as a win" pattern documented in `docs/solutions/workflow-learnings/`. The census entry stays and is now labelled as **accurate debt** rather than a missed conversion. No behaviour change; comment only. Dashboard app `tsc` clean, `pnpm lint` clean, `app/utils` suites 59 files / 689 tests green. Co-authored-by: Claude Opus 5 (1M context) --- packages/dashboard/app/utils/taskRevert.ts | 24 +++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/packages/dashboard/app/utils/taskRevert.ts b/packages/dashboard/app/utils/taskRevert.ts index 4cbb37d4e5..957eba9ce2 100644 --- a/packages/dashboard/app/utils/taskRevert.ts +++ b/packages/dashboard/app/utils/taskRevert.ts @@ -94,9 +94,27 @@ export function findOpenUndoTaskForSource(tasks: readonly Task[], sourceTaskId: and the behaviour was the legacy fallback forever. Reverted rather than left as a dead seam. An unsupplied optional parameter is strictly worse than - the literal — the literal is at least honest, and the census keeps pointing here. Unblocking it - means hoisting the flags derivation above that call, which is a hook-ordering change in a - 5000-line component (same blocker as the near-duplicate gate in that file). + the literal — the literal is at least honest, and the census keeps pointing here. + + FNXC:WorkflowResolvedColumns 2026-07-30-20:50 (correcting the unblock recorded above): + HOISTING THE FLAGS WOULD NOT UNBLOCK THIS — IT WOULD INTRODUCE A WORSE DEFECT. + + The note above says the blocker is hook ordering, i.e. a cost. It is not: it is a correctness + boundary. This function scans the `tasks` list for OTHER tasks pointing back at the source, so the + column it classifies belongs to a NEIGHBOUR. `detailColumnFlags` in TaskDetailModal describes the + MODAL'S OWN task, and its own FNXC note says so explicitly — it is guarded by + `detailFlagsAreForThisTask` precisely because using it for anything else is wrong. + + So supplying it here would answer "is this neighbour finished?" with the modal task's traits: on a + project where two workflows reuse a column id, an open undo task would be classified by a workflow + it does not belong to and the affordance would vanish or persist wrongly. That is the flags-for- + the-wrong-row shape, and it is worse than the literal because it is wrong on data rather than + merely stale on vocabulary. + + A CORRECT conversion needs per-NEIGHBOUR flags — the caller would have to resolve each candidate's + own workflow, which the modal does not have and should not fetch mid-render. Until a per-task lane + map is available at that call site, the literal is the right answer and the census entry is + accurate debt rather than a missed conversion. */ if (candidate.column === "done" || candidate.column === "archived") { continue;