dc50425e98
## What The FNXC convention exists so a reader can place a note against the change that motivated it. A stamp dated *after* the edit landed defeats exactly that. This is program-wide drift, not one author's slip — I contributed to it in my own commits this week, which is how I noticed it. ## Measured, on this tree **104 stamps across 61 files** dated later than the day they were written, from one day ahead to **2026-10-19 (81 days)**: | count | date | count | date | count | date | |---|---|---|---|---|---| | 50 | 2026-07-31 | 6 | 2026-08-05 | 3 | 2026-08-13 | | 17 | 2026-08-01 | 1 | 2026-08-07 | 1 | 2026-08-19 | | 7 | 2026-08-02 | 1 | 2026-08-12 | 2 | 2026-08-26 | | 11 | 2026-08-03 | | | 3 | 2026-10-19 | An earlier number I circulated was ~70. That came from a narrower pathspec and was wrong; **104** is the measurement. ## How Each stamp is rewritten to the date of the commit that introduced **that line**, via per-line `git blame` — deliberately *not* stamped uniformly with today's date. A uniform stamp swaps a wrong date for a different wrong date and flattens the ordering that makes these comments navigable; blame preserves it. Times of day are untouched, and a blame date in the future is clamped rather than trusted. ## Why the verification is listed A docs sweep across 61 files is precisely where a stray edit hides, so the safety claims are mechanical rather than asserted: - every changed line begins with a comment marker — **no code touched**; - **no test asserts an FNXC date later than today**, so no `toContain` assertion on embedded source text can be silently invalidated (several such assertions do exist); - CSS files, which carry several of those assertions, are outside the pathspec. ## Verified lint clean · merge gate green (487 + 158 + 10 + 71) · `census --strict` exit 0 · tsc clean for core, engine, and dashboard (`tsconfig.app.json`). **No behavior change.** Comment text only. ## Not done here A guard preventing recurrence. A check that rejects an FNXC stamp dated after the commit would stop this returning, but it needs a decision about where it runs (lint rule vs. gate) and it is a behavior change to CI — it does not belong riding inside the sweep it would police.
66 lines
3.1 KiB
TypeScript
66 lines
3.1 KiB
TypeScript
/*
|
|
FNXC:MergeQueue 2026-07-15-10:45:
|
|
AI merge sets task.status to reviewing/landing for most of the live merge window. Board/list badges must never show those raw engine strings; map the full active-merge pipeline to operator-facing Merging… (and Merging fixes… for merging-fix).
|
|
*/
|
|
import type { TFunction } from "i18next";
|
|
import { isActiveMergeStatus } from "../../../core/src/active-merge-status";
|
|
|
|
/*
|
|
FNXC:TaskStatusBadge 2026-07-22-00:00:
|
|
FN-8475 restores truthful status visibility: Coding (Ideas) deliberately plans in Todo,
|
|
so a real non-queued task status must not be hidden based only on its board column.
|
|
Queued remains an intake-only presentation exclusion at TaskCard and ListView call sites.
|
|
*/
|
|
export function hasTaskStatusBadge(status: string | null | undefined): boolean {
|
|
return typeof status === "string" && status.trim().length > 0;
|
|
}
|
|
|
|
export function getTaskStatusBadgeLabel(
|
|
status: string | null | undefined,
|
|
t: TFunction<"app">,
|
|
/*
|
|
FNXC:TaskStatusBadge 2026-07-19-02:55 (U12 / R2 / R11):
|
|
Workflow-step state wins over the raw status vocabulary. A card whose Plan Review is running
|
|
reads "Plan Review" — the step's own IR-declared name — instead of the engine token "planning"
|
|
or "needs-replan". Pass `getRunningWorkflowStepLabel(task)` here; omit it and the legacy status
|
|
mapping below is unchanged, so every existing caller keeps its behavior.
|
|
*/
|
|
workflowStepLabel?: string,
|
|
): string {
|
|
/*
|
|
FNXC:TaskStatusBadge 2026-07-19-09:40:
|
|
Every active-merge status ("merging", "merging-pr", "merging-fix", "reviewing", "landing") must
|
|
win over a still-running workflow-step label (a pre-merge step's startedAt-without-completedAt
|
|
state can survive into the merge pipeline). Checking the status before the workflow-step override
|
|
enforces this for every caller (TaskCard, ListView grouped rows, ListView table rows) instead of
|
|
relying on per-call-site pre-checks. "merging-fix" keeps its distinct "Merging fixes…" label.
|
|
*/
|
|
if (isActiveMergeStatus(status)) {
|
|
return status === "merging-fix"
|
|
? t("tasks.statusMergingFix", "Merging fixes…")
|
|
: t("tasks.statusMerging", "Merging…");
|
|
}
|
|
if (workflowStepLabel) return workflowStepLabel;
|
|
if (!status) return "";
|
|
/*
|
|
FNXC:TaskStatusBadge 2026-07-22-09:22:
|
|
FN-8493 requires operator copy "Revising" while a revise/replan cycle is in progress. Keep the
|
|
engine token "needs-replan" unchanged and map centrally so board cards and list rows agree.
|
|
*/
|
|
if (status === "needs-replan") {
|
|
return t("tasks.statusReplan", "Revising");
|
|
}
|
|
/*
|
|
FNXC:TaskStatusBadge 2026-07-26-14:05:
|
|
"planning" is an engine token, not operator copy, and it was only ever hidden because U12's
|
|
workflow-step override happened to cover the same cards. Now that the Plan Review gate has its own
|
|
badge, callers suppress the step-name override while that badge renders — which uncovered the raw
|
|
lowercase token underneath. Map it to the same "Planning" copy the transient-planner badge already
|
|
uses so the two paths cannot read differently.
|
|
*/
|
|
if (status === "planning") {
|
|
return t("tasks.statusPlanning", "Planning");
|
|
}
|
|
return status;
|
|
}
|