Read the type scale from AslTypography

[AhmadKharfan]

Why

The app read its type scale through two different paths:

AslTypography.bodySmall             // the design system's own token
MaterialTheme.typography.bodySmall  // the same object — but only because AslAppTheme installs it there

The second is correct by coincidence of configuration, and nothing at the call site says so. AslAppTheme sets typography = AslTypography, so today they resolve to the same TextStyle instance. But wrap any composable in a bare MaterialTheme { } — a preview, a test harness, a third-party wrapper — and those call sites silently fall back to Material's stock type scale. No compile error, and with no UI tests in this project, nothing to catch it.

67 files took the indirect path. This makes the direct one the only one.

What changed

Every MaterialTheme.typography.X became AslTypography.X across 65 files — 42 in :designsystem, the rest spread over the feature modules and :app. The now-unused MaterialTheme import was removed from each.

The diff is 208 insertions against 207 deletions: an almost exactly 1:1 substitution.

Behavior

No behavior change, and this is provable rather than assumed: AslAppTheme installs AslTypography into MaterialTheme, so MaterialTheme.typography.X and AslTypography.X are the same object for every X.

Scope

Exactly three files still import MaterialTheme, each deliberately:

• designsystem/theme/Theme.kt — the adapter that installs the Asl tokens into Material3 (MaterialTheme(colorScheme = …, typography = AslTypography, shapes = …)). This is the one legitimate consumer and must keep it.
• GitDiffScreen.kt and GitHistoryScreen.kt — hold the three colour tokens with no mapping in Theme.kt's colorScheme(...): surfaceVariant (diff hunk-header background) and tertiary/secondary (git-graph lane colours). Those render with stock Material colours today; substituting the closest-looking Asl token would be a silent visual change. They still need a deliberate design decision — either add tokens for those roles or map them in Theme.kt.

Untouched on purpose: Material3 components (Text, Scaffold, HorizontalDivider, Icon) — the app deliberately builds on M3, and only the token accessor was in question. Also the 15 FontFamily.Monospace uses, since AslCode.* differs in size and weight and swapping them is a visual change, not a substitution.

Tests

No new tests. A provably identical token substitution with no new logic.

Verification

• ./gradlew test — all modules pass.
• ./gradlew :app:compileDebugKotlin — passes.
• ./gradlew detekt — passes.
• Zero MaterialTheme.typography references remain anywhere in designsystem, feature, or app.
• The only three files still importing MaterialTheme are the ones listed above.

Baseline

All baselines regenerated — 64 removed, 0 added. :designsystem −42, :feature:settings −6, :feature:editor −5, :feature:onboarding −4, :feature:projects −3, :feature:terminal −2, :app −2. Project total 307 → 243.

:feature:git is unchanged, correctly: its two remaining entries are the unmapped-colour files.