mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-17 00:26:41 +03:00
2c33196c51
* Release: skill v4.1.0, CLI v3.6.0, extension v1.3.2 Skill 4.1.0: the build path becomes a recorded setting with a per-round toggle, the direction round routes challengers by verdict, surface rounds deal structure, and critique delivers its report and its close. CLI 3.6.0: contrast findings stop assuming white when the ground cannot be read, waivers scope to the element that carries them, and Hermes Agent and Antigravity install natively. Extension 1.3.2: no source change, but the bundled engine is rebuilt at release, so the same 59 rules ship with the false-positive work behind them. Chrome and Firefox from the one manifest. Harness output regenerated with build:release, which is what the version validator checks against the manifests. Written with AI assistance (Claude Code). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Bound release-note extraction to the entry it names Every v4.0.x skill release shipped v4.0.0's notes. The extractor took the first `<ul class="cf-items">` after the version header with no upper bound, and the v4.0.1 through v4.0.4 entries wrote their bullets in a `cf-entry-list` instead, so the search ran past all four and landed in v4.0.0. Nothing failed, because finding a list somewhere was treated as success. The search now stops at the entry's own `</article>` and fails with the reason when the entry has no readable list, which is the case the old code silently published its way through. The changelog side is fixed in impeccable-site, where those five entries now use `cf-items` like the other 46: `cf-entry-list` also had no CSS at all, so their bullets were rendering unstyled on the changelog page. Written with AI assistance (Claude Code). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
4.0 KiB
4.0 KiB
Android platform
For native Android apps: Jetpack Compose, Android Views, React Native, Expo, Flutter shipping to Android hardware.
On native, the visitor mode narrows what expression may override. Material Design 3 governs structure, navigation, and interaction in every mode; brand expresses through Material's theming (color roles, type scale, shape, motion). A Material-everywhere cross-platform app that also ships to iPhone still owes iOS its OS guarantees on that hardware: safe-area insets, Reduce Motion, edge-swipe back.
The Android slop test
Would a fluent Android user trust this app, or trip on off-spec components? The most common tell is an iOS app wearing Android's skin: a bottom-only navigation copied from iPhone, a back arrow that ignores the system Back gesture, Cupertino-shaped switches and dialogs. Material 3 is the rulebook; follow its components and theme the brand through it.
Layout & structure
- Material navigation, matched to size. Navigation bar (bottom, 3–5 destinations) on compact width; navigation rail or drawer on expanded width. Never ship a phone bottom-bar untouched on a tablet.
- System Back always works. Honor the predictive Back gesture and Back button; never trap the user or hijack the gesture.
- Edge-to-edge with window insets. Apply the status bar, navigation bar, display cutout, and IME insets so content never hides behind system bars or the keyboard.
- Top app bar for screen context; pair with a FAB when the screen has a single primary action.
Touch targets
- 48×48 dp minimum for every touch target, with at least 8 dp between them.
Typography
- Material type scale. Display, Headline, Title, Body, Label roles (large/medium/small each). Map text to roles; never hand-pick sizes per screen.
- Roboto is the system face; theme a brand face in through the type scale, keeping body, labels, and controls legible and consistent.
- sp units, never fixed px, so type follows the system font-size setting.
Color & theming
- Material color roles (primary, on-primary, surface, surface-variant, secondary-container, outline, error). Role tokens resolve light/dark and contrast variants automatically; raw hex breaks there.
- Dynamic Color (Material You) where it fits: derive the scheme from the user's wallpaper on Android 12+, with a static fallback.
- Dark theme is a first-class scheme. Design and test it; never a quick invert.
- Tonal elevation. Convey elevation through the standard surface tonal levels (plus shadow where appropriate); no arbitrary drop shadows.
Components & motion
- Material components. Buttons (filled / tonal / outlined / text), FAB, switches, chips, snackbars, bottom sheets, Material dialogs, navigation bar/rail/drawer. Never port iOS controls or invent equivalents.
- One FAB, one primary action. Never stack FABs or spend one on a secondary task.
- Snackbars for transient feedback (actionable when useful, never a toast for that); dialogs only for decisions that must interrupt.
- Material motion patterns. Container transform, shared-axis, fade-through, with standard easing and durations; honor the system Remove animations setting with a crossfade or instant cut.
Verifying the build
- Screenshots come from the emulator or a connected device, never a browser. Build and install, then capture with
adb exec-out screencap -p > <path>(pick a device withadb -s <serial>when several are attached). Capture every device class the app ships to, at least one phone and, when tablets are a target, one tablet, and write the files where the review flow expects them. - Dark theme and font scale belong in the pass.
adb shell cmd uimode night yesflips the theme;adb shell settings put system font_scale 1.3(restore1.0after) catches the clipped labels a fixed layout hides; with several targets attached, the capture's-s <serial>goes on these commands too. - Emulators give breadth; gestures, refresh rates, and performance need hardware. Say which one produced the evidence.