Not a conversion. A **conversion that was never connected to
production**, found by a parity sweep rather than by the census.
## How it surfaced
An AST pass over all **43** github/gitlab-named files, paired by name
with counts compared:
```
github-tracking-comments.ts=9 vs gitlab-tracking-comments.ts=4 ASYMMETRIC
github-tracking-state.ts=2 vs gitlab-tracking-state.ts=0 ASYMMETRIC
github-issue-comment.ts=1 vs gitlab-issue-comment.ts=1
...8 more pairs, all symmetric at 0
```
The first is the pair #2715 fixes. The second pointed here — and the
asymmetry turned out not to be the interesting part.
## The defect
`decideIssueAction` has accepted an injectable `classify` since U12/R2,
and that file's own header states the bug the seam fixed:
> "A user-authored workflow whose terminal column is called something
else never closed its linked GitHub issue, and a custom archive column
never mapped to `not_planned`."
Its **only production caller** passed no classifier:
```ts
const decision = decideIssueAction(event.from, event.to);
```
So every real move fell through to `legacyColumnLifecycleClass`, and
**the documented bug was still live**. The seam was reachable from unit
tests only — which is why all 68 cases in that file were green while the
behaviour they document did not work.
Same shape as this branch's earlier finding on the tracking-comment
guard, where the guard returned *before* resolving. **Adding a seam and
wiring it are two changes; only the second one fixes anything.** Worth
watching for elsewhere in this program: a file can read as fully
converted, pass its suite, and still take the legacy path on every call.
## Ordering, inverted on purpose
`decideIssueAction` ran first, before the tracking-enabled check,
because comparing two strings is free. Resolving a workflow is not — so
the cheap property read now short-circuits and only tracked tasks
resolve, the ordering `github-tracking-comments.ts` and its GitLab twin
already settled on. Untracked tasks returned without acting before and
still do.
The two remaining literals **are** `legacyColumnLifecycleClass`, that
seam's named default, now marked `DELIBERATE-LITERAL` — and marked only
in the same commit as the wiring. While the default was the live path on
every move, exempting it would have hidden the real defect behind a
marker.
## Revert proof — it detects an *unwired* seam, not a missing one
Dropping the resolved classifier while **leaving the seam intact** fails
both new cases with 0 `setIssueState` calls. That is the whole point:
the new cases drive the **service**, not the pure decision function, so
they fail for exactly the reason the 68 existing cases could not. Those
pass either way.
## Two self-inflicted errors, recorded because both are recurrences
- **I hand-edited the baseline with python and wrote a raw NUL byte into
the JSON**, breaking the census parse. The `deliberateByFile` keys use a
real `\0` separator and must be written through `JSON.stringify`, never
string interpolation.
- **I then restored the baseline from a newer `origin/main` than my
branch point**, which made `--strict` report a `scheduler.ts: 12 → 26`
rise that was pure version mixing. Rebase first, then edit. (The real
`scheduler.ts` baseline staleness is already owned by #2712 — I checked
before assuming it was mine.)
## Verification
`pnpm test:gate` **GREEN** (158 + 10 + 487 + 71) · **71 passed** in the
tracking-state suite · dashboard `tsc` clean · `pnpm lint` clean ·
census `--strict` exits 0.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
54d1a29621