fitme·story
vpre-v5.0 · 2 min read
Summary card · 60-second read

Android Design System — A Documentation Deliverable That Skipped Six Phases on Purpose

Version
vpre-v5.0
Date
2026-04-04
Tier
light

A 92-token iOS → Material Design 3 mapping that ships zero lines of Android code on purpose. Research + PRD execute normally; Tasks / UX / Implementation / Testing / Review all marked `skipped` with rationale on every skipped phase. The reference example for research-only deliverables in the PM workflow.

Honest disclosures
  • •No live user impact. Deliverable is documentation; the kill criterion ("Defer Android expansion if iOS core not stable") is the success state if Android port never starts. Cost: ~30 min of research time.
  • •Tokens-mapped + component-parity-audit metrics are counts in research.md, not behavioral measurements. They verify "I made the mapping" not "the mapping is correct."
  • •No ux-spec.md exists for this feature — research-only, no UX surface. UX phase was correctly skipped, not implicitly omitted.
  • •Originally consolidated into the six-features roundup (2026-04-20). Split into a dedicated case study on 2026-05-05 as part of the chain-of-custody initiative — this case study is a backfill (case_study_type: pre_pm_workflow_backfill); not retroactively claiming live PM workflow tracking.
How to read this case studyT1/T2/T3 · ledger · kill criterion▾
T1Instrumented
Numbers come from a machine-generated ledger or commit. Reproducible. Highest reader trust.
T2Declared
Numbers stated by a structured declaration (PRD, plan, frontmatter) but not directly measured.
T3Narrative
Estimates and observations from session memory. Useful for context; not citable as evidence.
Ledger
Where to verify the claim — a file path, GitHub issue, or backlog entry. Anything labelled ledger: is the audit trail.
Kill criterion
The pre-registered threshold under which this work would have been killed mid-flight. Not fired = work shipped without hitting the threshold.
Deferred
Items intentionally not closed in this version. Each cites the ledger that tracks remaining work.
No Android mapping
iOS-only token system
No documented relationship between iOS tokens and Material Design 3. Future Android port would have to re-derive every mapping decision from scratch.
92 tokens mapped
config-android.json + 310-line ref doc
46 colors → MD3 role mapping with hex, 22 typography styles → MD3 type scale, 8 spacing tokens → 4pt grid, 6+ radius → MD3 shape categories, 2 shadow → tonal elevation, 4 motion → MD3 motion specs. Style Dictionary generates `.kt` from existing `tokens.json`.
Kill criterion · not fired
  • Defer Android expansion if iOS core not stable. The kill criterion IS the deliverable disposition: documentation shipped, port deferred, artifact retained as reference material.

Why this is the reference example for research-only deliverables

The PM workflow has a phase model: Research → PRD → Tasks → UX → Implement → Test → Review → Merge → Documentation. Most features execute all 9. Some legitimately don't.

The android-design-system feature shipped on 2026-04-04 with 3 phases executed and 6 phases skipped, where every skipped phase carries an explicit status: skipped and a rationale. This is the difference between implicit skip ("Tasks never started") and explicit skip ("Tasks not applicable — research-only deliverable, no implementation"). The PM workflow already supports this; android-design-system is the worked example.

What shipped

FileLinesPurpose
design-tokens/config-android.json47Style Dictionary's Android output config
docs/design-system/android-token-mapping.md310iOS → MD3 mapping reference
.claude/features/android-design-system/research.md201Decision record

tokens_mapped: 92/92, component_parity_audit: 13/13, style_dictionary_config_ready: true. The metrics target the deliverable, not user behavior — appropriate for a research artifact.

Why this case study exists

The original six-features-roundup (2026-04-20) consolidated 6 pre-rule features into one document because three of them had material too thin to support a dedicated case study. Android DS was in the "thin" group not because the work was thin (it wasn't — 92 token mappings + 310-line reference doc) but because a case study about a documentation deliverable would effectively be a doc about a doc.

On 2026-05-05, the chain-of-custody initiative (full-repair-mode plan, Decision 3 + Q1 = Option 3 hybrid split) re-evaluated each section. Android DS was reclassified as "dense enough" — its source artifacts (PRD + research + tasks + a 310-line deliverable doc) justify a dedicated record, primarily because it's the PM workflow's worked example for research-only deliverables. Other features will reach this shape; the precedent should be findable as its own case study, not buried in a roundup.

Cross-feature lesson

Research-only deliverables are a real work type, not a degenerate one. The PM workflow accommodates them via explicit-skip + rationale on every skipped phase. The metrics target the deliverable (tokens_mapped 92/92), not user behavior. Kill criterion targets the disposition decision ("defer if iOS core not stable"), not adoption. Future research-only features should follow this template.

Links