maintainability: processors.ts (16.2k lines, 437 touches) is the structural cause of this audit's drift and determinism gaps; plus a confirmed dead wire

[JSONbored]

Summary

Two maintainability findings with measured churn evidence, plus one confirmed piece of dead code. Filed because both are the structural cause of defects found elsewhere in this audit — not as generic cleanup.

1. src/queue/processors.ts — 16,200 lines, 437 touches since 2026-07-01

86 of those touches came in the last week alone. It is where most of this audit's confirmed bugs physically live:

• the decision-clock violations (replay determinism)
• both sibling-drift families (drift: the #9399 sibling-guard pattern is live in four more places — fix the four, then remove the structure that generates them #9491) — five near-identical command handlers, two panel twins, three advisory runners, all drifting inside one file
• the cap-close vs accept-path parity gap (approval-queue: accept path builds a thinner executor context — #9159 mutex, moderation ladder and #9055 base guard all silently inert #9482)
• the visual capture-blip wiring (gate(visual): capture-retry marker never cleared + pending marker skips instead of holds → screenshot gate silently disabled (false merge) #9462, gate(visual): browserless render failure is swallowed, not deferred → screenshot gate false-closes legitimate PRs (#9030/#9207 unpatched sibling) #9464)

The drift is mechanical: a guard is added to the instances someone greps for, and the next one is 8,000 lines away in the same file.

Highest-value splits, in order:

• The ~9 slash-command and panel handlers behind one shared dispatch owning state, redelivery and rate-limit guards once. (Also delivers most of drift: the #9399 sibling-guard pattern is live in four more places — fix the four, then remove the structure that generates them #9491.)
• The three run*ForAdvisory spend gates behind one shared precondition struct.
• The plan-and-execute pass into its own module with a required, typed decision-pass context (clock, authorLogin, baseRef) that both the live path and the approval-accept path must construct. This one change structurally fixes approval-queue: accept path builds a thinner executor context — #9159 mutex, moderation ladder and #9055 base guard all silently inert #9482 and roughly half the determinism gap below, because both are caused by ad-hoc optional context fields.

2. Replay determinism: the recorded clock reaches one consumer

#9256/#9028 shipped "replayable time", but the captured decisionClock is threaded into exactly one consumer (maybeForceFreshRebase, processors.ts:3911). At least three other clock reads still decide outcomes:

• processors.ts:2907 — activeMergeBlockedSha(pr, pr.headSha, Date.now()) feeds the plan and the recorded reason code; it is a second, unrecorded clock read in the same pass that captures decisionClock at :3184.
• processors.ts:3498 — account-age Date.now() → isNewAccount → halves the contributor cap → cap close. decisionClock is in scope and unused; the twin src/queue/account-age-throttle.ts:13 has no nowMs seam at all.
• src/review/unlinked-issue-guardrail.ts:277 (also :192, :92) — a wall-clock gap chooses close vs hold. And because replayDecision only re-derives evaluateGateCheck (the action is pinned), replaying such a decision reports verdict: "match" — a false certification, not a caught divergence.

There is also a class a JS grep cannot see: SQL-side datetime('now', ?) in src/review/submitter-reputation.ts.

• Thread decisionClock.nowMs into the merge-blocked, account-age and unlinked-issue paths.
• Record isNewAccount and the guardrail's gap inputs in DecisionReplayInput.
• If any read is deliberately left live, extend the honest-scope note at src/review/decision-replay.ts:26-33 to name it — the current list does not.

Verified clock-free (do not re-audit): the pure core evaluateGateCheck and all its transitive imports, src/settings/**, salvageability, risk-control, the verdict-flip guard, and the close-audit holdout (HMAC-derived draw).

3. Dead wire, and no check for the class

src/review/issue-rag-wire.ts has zero production importers — both real consumers import packages/loopover-engine/src/issue-rag-query directly, and only its own test imports the wire. Test coverage camouflages the rot, and commit 39cc9583c shows this class has bitten before.

There are 26 *-wire.ts files and no registration protocol; ~18 are direct-import-only, so a forgotten import is a silently dead feature. The one real registry (src/review/feature-activation.ts:80-89, a total Record over CONVERGED_FEATURE_KEYS) is compile-time drift-proof and is the right model.

No dead-wire check exists: there is no knip or ts-prune, and none of the ~15 scripts/check-*-drift.ts covers wires.

• Delete issue-rag-wire.ts (or wire it up, if it was meant to be used).
• Add a check that every src/ file has at least one non-test importer. scripts/check-import-specifiers.ts is a ready template.
• Deduplicate the manifest-override + 60 s TTL cache triple hand-rolled in at least eight places (ops-wire, maintainer-recap-wire, loop-escalation-wire, contributor-trust-profile-wire, and four non-wires) — feature-activation.ts's own header calls this pattern the root cause of a prior incident.

Note on src/api/routes.ts (6,906 lines, 173 touches)

The requiresApiToken exemption list plus the canSessionAccessPath allowlist is a proven drift generator — #9120 was literally "route doc said unauthenticated, list said 401", and three later routes carry comments promising to update both "in the SAME PR so the two can never drift", by convention only. A route-registration structure that co-locates auth posture with the route would retire the class. Lower priority than the above; recorded so it is not rediscovered.

[linear-code]

JSO-6556