chore: remove 328 unreferenced files — 22% of the tracked tree — after a skeptic pass rescued 62 of the candidates

[houko]

Description

Removes 328 files — 12.7 MB, 22.4% of the tracked tree (56.8 MB → 44.0 MB, 5,271 files → 4,943) — plus the dead exports, swallowed errors and wrong error messages found alongside them.

Every deletion went through a skeptic first, whose job was the opposite of the audit's: prove each candidate is still alive. They rescued 62 candidates and left 18 as unprovable either way. Both groups are untouched here. That pass is the substance of this PR, not a formality:

• packages/services/src/file/file-upload.service.ts was on the delete list. It has five consumers inside its own package (file.service.ts, sites-file.service.ts, issue-attachment, issue-comment, project-page) and zero outside it — and the audit's method searched only outside packages/services. Deleting it takes down @pace/services and all three apps. The general form: an unreferenced-export scan that excludes a package's own source is unsound for any package whose modules compose each other.
• packages/types/src/index.ts:61 — the audit proposed dropping export * from "./base-layouts". That line is the only path by which the live gantt layout reaches GANTT_TIMELINE_TYPE. It breaks the build immediately.
• Eleven route redirect targets appear only as string arguments in apps/web/app/routes/core.ts (including the /inbox → /intake legacy redirect), so no symbol search sees them.
• trend-piece.tsx and sticky-item-drag-handle.tsx are referenced from commented-out JSX — temporarily disabled features, not dead code. TrendPiece also uses export default, so a symbol search was never authoritative for it.

One methodological finding that should outlive this PR

Git history carries no file-age information in this repo, so no argument may rest on it. 2e3185ec is the root commit: the entire fork was squashed into it on 2026-09-14, 5,235 files and 573,103 insertions. Every file looks exactly as old as every other file.

The audit used that one commit to reach opposite conclusions about two directories — components/readonly/ was "predates the fork, inherited dead code, delete" and components/base-layouts/ was "two commits, first 2026-09-14, in-flight refactor, keep". Identical evidence, contradictory verdicts. Both are held back here, on the affirmative signals instead: readonly/ is a complete, symmetric 8-component slice carrying a deliberate API comment and written in current house style, and base-layouts/'s companion type tree has already been partly adopted by shipping code. Neither should be deleted without a word from whoever owns those views.

Type of Change

• Code refactoring
• Bug fix (non-breaking change which fixes an issue)

Screenshots and Media (if applicable)

None — nothing user-facing changes. The 256 deleted assets are unreachable from any code path; the check that establishes that is described below.

Test Scenarios

• pnpm turbo run build check:types check:lint check:format --force — 59/59, no cache, exit 0.
• apps/api: gofmt -l . no output, go vet ./... clean, go test ./... 0 failures (non-Docker path; database-backed tests skip themselves by design).
• Assets, the reverse check rather than the forward one: every asset path string remaining anywhere in the tree resolves to a file that still exists. That is stronger than the basename search the audit used, and it is what catches collisions — empty-state/label.svg scores "referenced" under a basename search purely because the live string empty_label.svg contains it. A wrong deletion here is a hard Vite build error, not a silent 404, so the green build is meaningful.
• Assets are reachable only through static Vite ?url imports with literal paths: no import.meta.glob, no require.context, no new URL( in any of the three apps or in packages. Re-verified rather than taken from the audit.

Honest limits on what green proves:

• Go does not error on an unused package-level func, so the Go build passing shows only that nothing broke — not that the two deleted helpers were dead. The evidence for that is the search: zero references in a single-module repo, no build tags, no dot-imports, both symbols unexported so neither reflection nor interface satisfaction can reach them.
• No browser was used. Nothing here should be visible, but "should" is the operative word for the 256 assets.

References

Needs one decision before or after merge: apps/web/app/(all)/[workspaceSlug]/(settings)/settings/(workspace)/integrations/page.tsx exists on disk and appears in no route() call. Its two dependencies are provably unreachable at runtime, but apps/web/tsconfig.json has "include": ["**/*"], so deleting them leaves that page type-checking against unresolvable imports. All four files are kept. If the integrations settings page is not meant to ship, delete page.tsx and the three together; if it is, all four stay and the sibling integration-card / select-repository / select-channel files removed here were the genuinely dead half.

Found while doing this, deliberately not fixed here:

• Italic text in exported PDFs renders upright. apps/web/core/components/editor/pdf/document.tsx:195-212 registers all nine fontStyle: "italic" variants against the upright source files. The nine italic Inter faces are therefore kept — they are unimported because of this bug, and deleting them would cement it.
• A latent crash at apps/web/core/components/workspace/sidebar/favorites/favorites-menu.tsx:172: if (!sourceId || !groupedFavorites[sourceId].parent) return; has no optional chaining, so any drop whose sourceId is absent throws inside the drag-and-drop onDrop. It is an unfinished move-favorite-out-of-folder handler.
• Three packages/propel build-config defects, all additions rather than deletions: tsdown.config.ts lists entry src/emoji-reaction-picker/index.ts for a directory that does not exist; src/separator is in neither the entry list nor package.json exports, so no app can import it; and @pace/propel/utils/placement is imported by the apps but absent from the exports map.
• Three more assets look dead by the same standard and were left for a skeptic pass: empty-state/label.svg, empty-state/estimates/dark.svg and estimates/light.svg (32,211 bytes). They scored "alive" only through substring collision.
• apps/space/app/assets/robots.txt is in the wrong place; it belongs in apps/space/public/.
• Six exports in packages/utils/src/url.ts (isValidIPv4, isValidIPv6, validateIPAddress, isLocalhost, extractHostname, formatURLForDisplay) now have only url.test.ts as a consumer. The skeptic correctly rescued them — the audit's evidence against them came from a broken prefix filter — but they are a test-only island that the barrel still re-exports. That is an API decision, not a sweep.
• user-image-upload-modal.tsx:90 logs "Error in uploading user asset" from the removal path; the sibling workspace modal gets it right.
• Five catch blocks in apps/space/core/store/issue-detail.store.ts bind the error as _error and never use it, so they now log a static string with no diagnostic payload. Renaming and passing it is the real fix; the underscore convention was left alone.

Two corrections to the audit's own evidence, so nobody acts on them later: its finding-72 list of 13 unreferenced packages/shared-state exports is unreliable — IFilterInstance is imported by seven apps/web files — and its claim that no-projects-* assets are unreferenced is wrong; settings/projects/page.tsx imports both. Neither affected what was deleted.

The i18n commit adds a report, not a gate: it prints unused English keys and exits 0, with strict mode opt-in. A heuristic this fuzzy failing CI would block the next PR that adds a label map, and no translation key or locale file is touched.

[github-actions]

React Doctor found 2 new issues in 2 files · 2 warnings · score 83 / 100 (Needs work) · 24 fixed · vs main

2 warnings

core/components/profile/user-image-upload-modal.tsx

• ⚠️ L30 React function has high control-flow complexity no-high-complexity-react-function

core/components/workspace/workspace-image-upload-modal.tsx

• ⚠️ L35 React function has high control-flow complexity no-high-complexity-react-function

_{Reviewed by React Doctor for commit ad4021b. See inline comments for fixes.}