product-teardownlisted

# Product Teardown v2 Turn external observation into a defensible implementation decision. The unit of work is a **transferable pattern**, not a feature list, screenshot inventory, technology list, or competitor profile. ## Core contract Preserve this chain for every material recommendation: `source evidence -> source observation -> mechanism hypothesis -> destination problem evidence -> transfer conditions -> adaptation option -> implementation path -> validation -> action` Never collapse the stages. - Seeing UI proves only visible behavior/state, not backend architecture, rationale, adoption, or outcome. - Seeing code proves implementation in the inspected version, not production use, customer value, or causal impact. - Seeing a successful company use a pattern does not prove the pattern caused success. - Seeing the same pattern across several products proves prevalence, not effectiveness. Use claim states consistently: - `OBSERVED` - directly supported by inspectable evidence. - `INFERRED` - interpretation derived from observed evidence. - `HYPOTHESIS` - proposed rationale, causal mechanism, expected effect, or transfer claim requiring validation. - `UNKNOWN` - material point not established by available evidence. Read `references/evidence-model.md` whenever building or judging the evidence ledger. ## Two independent axes ### Teardown shape Choose one: - `SOURCE_ONLY` - inspect a source and produce a pattern library. Never emit `ADOPT` without destination evid