Finding
autobot-frontend/scripts/check-ts-delta.sh enforces a TypeScript-error baseline of 188, taken from docs/developer/audits/typescript-baseline.md:6 (**Total: 188**, dated 2026-04-25).
The step immediately before it in the same job — Run type checking (.github/workflows/frontend-test.yml:103-105, package.json:35 → vue-tsc --noEmit -p tsconfig.app.json) — tolerates zero errors.
So check-ts-delta permits 188 regressions that the preceding step already rejects. It cannot fail unless the stricter gate ahead of it has already failed.
Why this matters now
That redundant step is the one that hung for three hours on the singleton self-hosted runner (#13341), blocking every merge in the repository. It was also failing open — || true swallowed the compiler exit code, so a vue-tsc crash with no diagnostics printed PASS: 0 errors and exited 0, in exactly the OOM mode #10298 documents for this step.
Both defects are fixed in PR #13346. But it reframes the incident: three hours of blocked merges came from a gate that gates nothing the previous step does not gate harder.
The decision
Two coherent options — this is an owner call, not a mechanical fix:
- Delete the step. If
Run type checking genuinely enforces zero, the delta check is dead weight, and deleting it removes a hang surface, a fail-open surface, and ~90s from the repo's slowest job.
- Refresh the baseline to the real count and keep it. Only worthwhile if the two steps are meant to check different things — e.g. if
type-check is expected to be relaxed later, or if the delta check is meant to cover files the tsconfig.app.json project excludes. If so, that intent should be written down, because nothing in the tree currently states it.
The stale 188 is itself evidence the step has not been meaningfully consulted since April.
Whichever is chosen, docs/developer/audits/typescript-baseline.md should stop asserting a number nothing reads.
Discovered during
Review of PR #13346 (#13341). Deliberately not acted on there — deleting or re-baselining a check is a scope decision, and that PR was already correcting two live defects in the same file.
Related
Finding
autobot-frontend/scripts/check-ts-delta.shenforces a TypeScript-error baseline of 188, taken fromdocs/developer/audits/typescript-baseline.md:6(**Total: 188**, dated 2026-04-25).The step immediately before it in the same job —
Run type checking(.github/workflows/frontend-test.yml:103-105,package.json:35→vue-tsc --noEmit -p tsconfig.app.json) — tolerates zero errors.So
check-ts-deltapermits 188 regressions that the preceding step already rejects. It cannot fail unless the stricter gate ahead of it has already failed.Why this matters now
That redundant step is the one that hung for three hours on the singleton self-hosted runner (#13341), blocking every merge in the repository. It was also failing open —
|| trueswallowed the compiler exit code, so avue-tsccrash with no diagnostics printedPASS: 0 errorsand exited 0, in exactly the OOM mode #10298 documents for this step.Both defects are fixed in PR #13346. But it reframes the incident: three hours of blocked merges came from a gate that gates nothing the previous step does not gate harder.
The decision
Two coherent options — this is an owner call, not a mechanical fix:
Run type checkinggenuinely enforces zero, the delta check is dead weight, and deleting it removes a hang surface, a fail-open surface, and ~90s from the repo's slowest job.type-checkis expected to be relaxed later, or if the delta check is meant to cover files thetsconfig.app.jsonproject excludes. If so, that intent should be written down, because nothing in the tree currently states it.The stale 188 is itself evidence the step has not been meaningfully consulted since April.
Whichever is chosen,
docs/developer/audits/typescript-baseline.mdshould stop asserting a number nothing reads.Discovered during
Review of PR #13346 (#13341). Deliberately not acted on there — deleting or re-baselining a check is a scope decision, and that PR was already correcting two live defects in the same file.
Related