Phased strict-mode migration for the dashboard tree (1,039-error probe, boundary-first plan)

[steipete]

Finding

tsconfig.dashboard.json alone disables strict, noUncheckedIndexedAccess, and
exactOptionalPropertyTypes; both Node configs enable all three. A strict-mode probe on the
dashboard tree produced 1,039 errors: 718 in worker.ts, 273 in exact-review-queue.ts,
28 in github-api.ts — about 840 of them implicit-any parameters/bindings.

Concrete consequence today: classifyGithubWebhook and its parameter objects are implicit
any, and the accepted comment decision is eventually cast as any. A call like
{ event: 7, paylod: {} } (typo included) compiles and fails only at runtime, in hosted webhook
intake — the exact surface where malformed external input arrives.

Why not just flip the flag

1,039 errors at once is unreviewable and would freeze the dashboard tree. The recent extractions
(github-api.ts, exact-review-decision.ts, exact-review-read-model.ts,
exact-review-queue-shared.ts, dashboard-pages.ts) make a phased path practical: small
modules first, monoliths last, external-input boundaries prioritized.

Proposed phases

1. Ingress union first (highest value): type the webhook classification path as a
   discriminated union over event kinds; kill the as any on the accepted decision. ~50–100
   lines, immediately protects the external boundary.
2. Per-file strict adoption via a // @ts-strict allowlist (or a second tsconfig with an
   include list, whichever the build tolerates better): start with github-api.ts (28 errors)
   and the freshly extracted modules (near-zero expected), ratchet the list in CI so files never
   regress once added.
3. Monolith conversion in slices: exact-review-queue.ts (273) then worker.ts (718),
   converted per functional region, each slice its own PR with the established container-proof
   discipline.
4. Flip the config flags once the allowlist covers the tree; delete the allowlist.

Sizing

Phase 1: one PR. Phase 2: 2–3 small PRs. Phase 3: est. 6–10 PRs at reviewable size. Total
+500–900 lines of annotations by the probe's estimate.

Survey provenance: strict-probe run on 5439582beebe during the 2026-08-11 modernization
review; typed-signature and as any sites verified in source at that head.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 15, 2026, 3:03 PM ET / 19:03 UTC.

Summary
Keep this as the canonical strictness tracker. Current main has completed webhook-ingress typing and a 30-file strict ratchet, but the dashboard’s primary configuration remains relaxed and the two large remaining modules are outside strict enforcement.

Reproducibility: not applicable. this is a planned maintainability migration, not a reported runtime failure. Current source does clearly reproduce the remaining configuration gap by excluding the Worker and queue from strict checking.

Root-cause cluster
Relationship: canonical
Canonical: #1128
Summary: This issue remains the canonical tracker; linked merged PRs implemented bounded phases but not the remaining monolith conversion.

Members:

• partial_overlap: refactor(dashboard): type webhook ingress decisions #1132 - Merged Phase 1 typed webhook ingress, while deliberately leaving the strict-ratchet and monolith phases out of scope.
• partial_overlap: refactor(dashboard): enforce strict checks for small modules #1141 - Merged the first 13-module strict-ratchet slice without changing the relaxed dashboard-wide configuration.
• partial_overlap: refactor(dashboard): extend strict coverage across 13 modules #1154 - Merged a second small-module strictness slice, but current main still excludes the Worker and queue.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Share version, platform, channel/provider, and relevant config details.

Maintainer decision needed

Question	Recommendation
Should the project resume the remaining strictness migration for dashboard/worker.ts and dashboard/exact-review-queue.ts, and at what reviewable cadence?	Resume bounded strictness slices: Schedule small responsibility-based promotions for the two excluded modules while preserving the current ratchet and its proof discipline.

Why: The remaining work spans two active, large runtime modules and requires a maintainer choice about engineering capacity and acceptable slice boundaries; the issue is explicitly marked for a product decision and no automatic fix PR.

Next step
A maintainer must choose whether and when to fund the remaining large-module strictness slices; the issue also opts out of an automatic fix PR.

Review details

Best possible solution:

Retain the monotonic ratchet and fund bounded, responsibility-based strictness slices for the Worker and queue, enabling the dashboard-wide flags only after both are covered.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a planned maintainability migration, not a reported runtime failure. Current source does clearly reproduce the remaining configuration gap by excluding the Worker and queue from strict checking.

Is this the best way to solve the issue?

Yes, the staged ratchet remains the safest path; a global flag flip before the two monoliths are converted would make the change unreviewably broad.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The 22,964 lines in the two excluded monoliths remain outside the strict ratchet, so future edits there still lack the requested compiler guarantees.

Codex review notes: model internal, reasoning high; reviewed against d389e6addf4d.

Label changes

Label justifications:

• P3: This is a staged internal maintainability cleanup with no reported active user-facing failure.

Evidence reviewed

What I checked:

• Relaxed full-tree dashboard configuration: Current main still sets strict, unchecked indexed access, and exact optional properties to false for the dashboard-wide configuration. (tsconfig.dashboard.json:8, d389e6addf4d)
• Partial strict ratchet: The separate strict configuration enables all three flags but has an explicit 30-file allowlist; the dashboard source inventory leaves dashboard/worker.ts and dashboard/exact-review-queue.ts outside it. (tsconfig.dashboard-strict.json:9, d389e6addf4d)
• Ratchet enforcement: The checker verifies the strict flags and baseline roots, so promoted modules cannot silently leave the strict set, but it does not make the excluded monoliths strict. (scripts/check-dashboard-strict.mjs:74, d389e6addf4d)
• Merged phase provenance: History records the ingress typing, first strict slice, and second strict slice as commits a179597, bd86954, and 4d41d3d; these correspond to the merged phase PRs linked from this issue. (tsconfig.dashboard-strict.json:9, 4d41d3df4baf)

Likely related people:

• steipete: Authored the linked ingress and strict-ratchet commits and has continued to change the Worker, queue, and strictness assets on current main. (role: introduced staged strictness work and recent dashboard contributor; confidence: high; commits: a1795973a9e6, bd869542a3a8, 4d41d3df4baf; files: dashboard/worker.ts, dashboard/exact-review-queue.ts, tsconfig.dashboard-strict.json)
• Martin Cleary: Recent current-main commits touch both remaining strictness boundaries through dashboard health and Bay-related work. (role: recent dashboard-area contributor; confidence: medium; commits: 9fb6d6bfe562, d389e6addf4d; files: dashboard/worker.ts, dashboard/exact-review-queue.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[sarcasticbanda25]

This is a clear and correct plan. The strict-probe results (1,039 errors: 718 worker.ts, 273 exact-review-queue.ts, 28 github-api.ts) show the real risk: webhook intake (classifyGithubWebhook) is currently implicit any and can let malformed payloads reach runtime.

Immediate proposal

Phase 1 (priority): I will prepare a small PR to type the webhook ingress:
Add a discriminated union for webhook event shapes and remove the as any on the accepted decision.
Add a tiny runtime validator + tests with one valid and one malformed example so we get both compile-time and runtime protection.
Target size: ~50–150 lines, one PR.
CI/measurement: I’ll add a strict-probe script and a CI job that:
Runs tsc with the strict config over the opted-in files and publishes per-file error counts.
Fails only on regressions/new files being added without typing (we’ll keep a baseline artefact in this issue).
Phase 2 enablement: propose a tsconfig.strict-includes.json (explicit include list) plus a small repo script to add/remove files to that list. CI will enforce that files added to the list must include typing changes in the same PR.
Questions for reviewers/maintainers

Do you prefer the explicit tsconfig include list or a // @ts-strict comment → script flow for opt-in? I can implement either.
Who should review the Phase 1 PR (suggest: one webhook/ingress owner + one types-savvy reviewer)? Please @-mention them, or I can nominate likely reviewers.