Sweep codebase for TypeScript and Mantine/React rule violations (AGENTS.md)

[cliffhall]

Summary

Do a codebase-wide audit sweep for violations of the TypeScript and Mantine/React conventions codified in `AGENTS.md`, and fix (or file follow-ups for) what turns up.

Scope — what to sweep for

TypeScript rules

• No `any` types anywhere.
• No suppressed error types (e.g. disabling `no-unused-vars` / `no-explicit-any` in tsconfig or eslint config to satisfy the linter/compiler).
• Double casts (`as unknown as T`) — every remaining one must carry an inline comment justifying why it is safe and why no better option exists; unjustified ones get fixed (type guard, narrower single cast, or fix the underlying type). Builds on the Refactor / justify codebase-wide 'as unknown as' casts (starting with serverList.ts) #1690/Refactor / justify codebase-wide 'as unknown as' casts (#1690) #1756 cleanup.

Mantine / React rules

• No inline styles (`style={{ ... }}`) on components.
• No raw hex values (`#ddd`, etc.) or `rgba()` literals in component props or theme files — use `--inspector-*` CSS custom properties.
• No `div`/basic HTML elements used purely for layout — prefer Mantine `Box`/`Group`/`Stack`.
• No CSS class where the style could be a component prop or theme variant; CSS classes are a last resort (only pseudo-selectors, nested child selectors, keyframes, native HTML element styles belong in App.css).
• Flat CSS properties (margin, padding, background, border, color, font-size, …) in App.css that should be theme variants or `.withProps()`.
• Subcomponents with 2+ props not declared as named `.withProps()` constants; `Box` used for a `.withProps()` subcomponent constant (Box doesn't support `.withProps()`).
• Domain-specific variant logic pushed into theme files instead of the owning element component; element components importing from `src/theme/` instead of `@mantine/core`.
• No inline code — extract to named functions in the same file (or a shared location if reusable).

Deliverable

A categorized inventory of violations with file:line references, and PRs fixing them (batched sensibly by rule category so each stays reviewable). Genuinely-unavoidable cases get a justified inline comment rather than a silent pass.

[cliffhall]

Audit sweep results

Ran a three-way parallel audit (TypeScript rules, Mantine styling, Mantine structure) across clients/*/src and core/, verifying every candidate in context to filter false positives. The codebase was already substantially conforming (post-#1690/#1756) — the actionable set was small enough for a single reviewable PR: #1771.

TypeScript rules — clean

Rule	Result
No any types	0 violations — the only \bany\b hits are the English word in comments and Vitest's expect.any(...) matcher.
No suppressed error types (config)	0 — root no-unused-vars stays at error with the sanctioned _-prefix pattern; no-explicit-any is never disabled.
Justified double casts	0 unjustified — all 12 non-test as unknown as already carry justification comments.

Two optional tightenings applied:

• App.tsx messagesToLogEntries — replaced an as unknown as double cast with a single narrowing cast on just the params value.
• createRemoteLogger pino/browser.js @ts-expect-error — genuinely unavoidable (TS resolves the real untyped .js file, so an ambient declare module fails with TS7016). Kept, with a comment now explaining why no better option exists.

Mantine styling — 1 minor finding

• No inline styles (the one in SortableServerCard is the sanctioned dnd-kit per-frame transform).
• No stray hex / rgba() color literals in props or theme overrides. (Filtered: theme.ts hex are the Mantine MantineColorsTuple palette arrays — a required exception; #1234 in comments are issue-number references, not colors.)
• No layout divs.
• Fixed: ServerListScreen used a .grid-align-start CSS class for a single align-items: start → folded into the existing styles prop, class + App.css rule removed.

Mantine structure — 4 findings fixed; Rules 2/3/4 clean

• Box.withProps misuse: 0. Domain logic in theme files: 0. Element components importing from src/theme/: 0.
• Fixed (repeated inline elements → named .withProps() constants):
  • NetworkEntry — DimmedNote + SectionLabel replace 9 repeated inline <Text>s.
  • ServerImportConfigModal — GroupHeading replaces 3 repeated <Text fw={600} size="sm">s.
  • ViewHeader — HeaderStackCell replaces the twice-repeated animated wrapper.
  • ResourceControls — TightRow replaces two <Group gap="xs" wrap="nowrap">.
• Fixed (inline logic → named functions):
  • ToolsScreen — handleSelectTool replaces the ~20-line inline onSelectTool.
  • ServerConfigModal — setTextField/clearTextField factories replace 6 repeated text-field onChange/clear closures.

All fixes verified via npm run ci (3472 unit tests, ≥90 per-file coverage gate, smokes + headless-browser boot, 456 Storybook play tests).

[cliffhall]

Correction — the literal AGENTS.md rule is the practice, in all cases

Superseding my earlier framing in this comment. The maintainer decision (via review of #1771) is that the wording and practice must match, and the practice is the rule exactly as written in AGENTS.md:

ALWAYS declare a meaningfully named subcomponent as a constant using .withProps() if a component has two or more props.

No "repeated within a file" softening. Every inline Mantine element carrying two or more static props must be a named .withProps() constant — single-occurrence ones included. The ~30 remaining offenders the #1771 re-review surfaced (e.g. ServerConfigModal.tsx:425 <Text c="red" size="sm" role="alert">) are in scope and are being fixed under #1771, not deferred.