analyze: report hardcoded --ak-* theme tokens in runtime TS/JS

[smiggleworth]

Summary

Hardcoding Askr theme token names such as --ak-* in runtime TS/JS is a stated Askr convention violation. It is not reported.

Why this is an Askr violation

Stated twice in the askr repo, in both cases as a hard rule rather than a preference:

AGENTS.md, "Runtime and Async Conventions":

Do not hardcode Askr theme tokens such as --ak-* in runtime TS/JS.

docs/reference/conventions.md, "Theming in Runtime Code":

Runtime TS/JS should not hardcode Askr token names like --ak-*.

• Keep token declarations and semantic mappings in theme CSS.
• Use component state helpers and slot/state attributes for runtime behavior.
• If a dynamic style is needed, route through a semantic class or data attribute, then resolve it in CSS.

Hardcoded tokens break theme swapping and defeat the askr-themes layer.

Not caught today

<div style={{ color: 'var(--ak-color-fg-muted)' }} />

element.style.setProperty('--ak-surface-raised', value);

const TOKENS = { bg: '--ak-color-bg' };

Proposed detection

Report --ak- appearing in a string literal, template literal, or JSX string attribute in any .ts / .tsx / .js / .jsx source file in the workspace.

This is a cheap syntactic check with essentially no false-positive surface, and it is precisely Askr-specific — a generic CSS-in-JS lint rule has no notion of the --ak- namespace.

Suggested exclusions

• theme package sources (workspaces that declare themselves as the token owner)
• files already covered by the analyzer's configured exclude globs

Remediation

Runtime code should not name Askr theme tokens directly. Move the token to theme CSS and select it from runtime code with a semantic class or data-* attribute.

Rule metadata

• id: askr/no-hardcoded-theme-token
• category: correctness
• severity: warning
• autofix: none