docs(android): M12 phase 1 as landed #113

wtclaude · 2026-08-08T09:55:36Z

wtclaude commented

2026-08-08 09:55:36 +00:00

What & why

The record for the colors phase. Code pair: Android-app#34.

Seven notes under a new "Phase 1 as landed", of which three are departures the build forced rather than choices it made:

ColorScheme does not implement equals. AC-1 asks for "the full ColorScheme equality, not a spot check", and material3 1.3.0 declares no equals/hashCode on it — checked against the artifact, not assumed. The proof became a field-by-field compare by reflection over every Color-valued getter (36 roles in 1.3.0) against a verbatim copy of the pre-M12 scheme held in the test. That is stronger than what the AC asked for, not weaker: a role Material adds, or one the mapping forgets, cannot escape it, and the expected value is what the app used to do rather than what the new code does today.
ShardPillFg is derived, not a sixteenth token. §5.1 lists it among ThemeComponents.kt's themable imports, but the token table has fifteen rows and none of them is it — its value is ShardCta's, both --accent-bright. It follows cta under the rule §5.1 already states for ShardOnCta, so the neutral pill's text tracks the CTA fill instead of freezing at today's literal.
An env-accent instance changes on screen, and it is the intended fix rather than a regression to weigh. §5.1 called RunicGatewayTheme(accent) "wrong twice over"; correcting it means a shard with a BRAND_ACCENT_COLOR and no theme_visual row no longer carries that color on primary, so its filled CTA buttons go back to the light --accent-bright fill the M5 design specifies while links and highlights keep the brand color. Worth writing down because it is the one thing in this phase that moves for an instance nobody has touched from Admin → Appearance — and the answer for a shard that wants accented buttons is now to set the accent there.

The other four are boundary decisions worth having on the record: the palette resolution and the scheme mapping are both pure (so AC-1 and AC-2 are plain JVM assertions with no Compose test rule), the §5.1 migration grep came out exactly as predicted — nine imports left, all semantic — toneColors became @Composable rather than growing a palette parameter on a public signature, and the test counts.

PLAN.md §9's M12 entry records phase 1 landed beside phase 0.

How it was tested

Documentation only — nothing to build or run. The notes were written from the merged-ready diff and the actual test run (373 green), not from the plan; §8's table row is ticked and the "as landed" section sits between phase 0's and the phase 7 cancellation note, matching the shape phase 0 established.

Checklist

I have read CONTRIBUTING.md.
The change builds and existing tests/checks pass locally. (Markdown only.)
I have added or updated tests/docs where it makes sense. (This PR is the docs.)
My commits are reasonably scoped with clear messages.

AI-assisted contributions (required)

AI tools were used. Tool(s): Claude Code (Opus 5). I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a Co-Authored-By trailer.

License

I agree that my contribution is licensed under this project's license (GNU GPL v3.0 or later), and I have the right to contribute it.

## What & why The record for the colors phase. Code pair: **Android-app#34**. Seven notes under a new "Phase 1 as landed", of which three are departures the build *forced* rather than choices it made: - **`ColorScheme` does not implement `equals`.** AC-1 asks for "the full `ColorScheme` equality, not a spot check", and material3 1.3.0 declares no `equals`/`hashCode` on it — checked against the artifact, not assumed. The proof became a **field-by-field compare by reflection** over every `Color`-valued getter (36 roles in 1.3.0) against a **verbatim copy of the pre-M12 scheme** held in the test. That is stronger than what the AC asked for, not weaker: a role Material adds, or one the mapping forgets, cannot escape it, and the expected value is what the app *used to do* rather than what the new code does today. - **`ShardPillFg` is derived, not a sixteenth token.** §5.1 lists it among `ThemeComponents.kt`'s themable imports, but the token table has fifteen rows and none of them is it — its value *is* `ShardCta`'s, both `--accent-bright`. It follows `cta` under the rule §5.1 already states for `ShardOnCta`, so the neutral pill's text tracks the CTA fill instead of freezing at today's literal. - **An env-accent instance changes on screen**, and it is the intended fix rather than a regression to weigh. §5.1 called `RunicGatewayTheme(accent)` "wrong twice over"; correcting it means a shard with a `BRAND_ACCENT_COLOR` and no `theme_visual` row no longer carries that color on `primary`, so its filled CTA buttons go back to the light `--accent-bright` fill the M5 design specifies while links and highlights keep the brand color. Worth writing down because it is the one thing in this phase that moves for an instance nobody has touched from Admin → Appearance — and the answer for a shard that wants accented buttons is now to set the accent there. The other four are boundary decisions worth having on the record: the palette resolution and the scheme mapping are both **pure** (so AC-1 and AC-2 are plain JVM assertions with no Compose test rule), the §5.1 migration grep came out exactly as predicted — nine imports left, all semantic — `toneColors` became `@Composable` rather than growing a palette parameter on a public signature, and the test counts. `PLAN.md` §9's M12 entry records phase 1 landed beside phase 0. ## How it was tested Documentation only — nothing to build or run. The notes were written from the merged-ready diff and the actual test run (373 green), not from the plan; §8's table row is ticked and the "as landed" section sits between phase 0's and the phase 7 cancellation note, matching the shape phase 0 established. ## Checklist - [x] I have read [CONTRIBUTING.md](CONTRIBUTING.md). - [x] The change builds and existing tests/checks pass locally. *(Markdown only.)* - [x] I have added or updated tests/docs where it makes sense. *(This PR is the docs.)* - [x] My commits are reasonably scoped with clear messages. ## AI-assisted contributions (required) - [x] AI tools were used. Tool(s): `Claude Code (Opus 5)`. I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a `Co-Authored-By` trailer. ## License - [x] I agree that my contribution is licensed under this project's license (**GNU GPL v3.0 or later**), and I have the right to contribute it.

wtclaude added 1 commit 2026-08-08 09:55:37 +00:00

docs(android): M12 phase 1 as landed a860557e91

The colors phase, shipped as Android-app#34. Seven notes, of which three are
departures the build forced rather than choices it made:

ColorScheme has no equals in material3 1.3.0, so AC-1's "full equality, not a
spot check" is a field-by-field compare by reflection over all 36 color roles,
against a verbatim copy of the pre-M12 scheme held in the test.

ShardPillFg is derived from --accent-bright rather than being a sixteenth
token, under the rule 5.1 already states for ShardOnCta.

An instance with an env accent and no theme_visual row loses its accented CTA
buttons, because brand.accent now seeds --accent alone. That is 5.1's "wrong
twice over" being corrected, and it is the one thing on screen that moves.

PLAN.md 9's M12 entry records phase 1 landed.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech merged commit afe0e9245f into edge

2026-08-08 09:57:03 +00:00

whitlocktech referenced this issue from a commit

2026-08-08 09:57:03 +00:00

Merge pull request 'docs(android): M12 phase 1 as landed' (#113) from docs/android-theming-nav-phase-1 into edge

whitlocktech deleted branch docs/android-theming-nav-phase-1

2026-08-08 09:57:03 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/docs#113