App Quality Patterns (QP library)

Style: Mode-B-lite router. The patterns live in references/<category>.md — load ONLY the categories the feature touches. Each pattern: ID · Trigger · Requirement · Verify (copy-ready smoke recipe) · Anti-pattern.

Purpose

Cross-project behavioral "definition of done" requirements that LLM-built apps repeatedly miss. They are not stack guidance (CLI skills own HOW) and not process rules (FLOW_RULES owns those) — they are WHAT must be true of the built feature. Distilled from recurring consumer-project defects; the library grows one table row at a time.

Category index (load on trigger match)

Integration contract (how patterns reach the lifecycle)

Growth rule

A defect observed across ≥2 projects (or once with clear generality) → add ONE row to the matching category file (new category file only when none fits) via skill-authoring; ship in the next release. Project-specific patterns go in that project's docs/skills/, never here. Keep rows dense — this library is loaded mid-spec.

Anti-patterns

• Do NOT paste pattern bodies into specs/handoffs — cite the QP ID (FR-23; the AC text carries the requirement one line).
• Do NOT turn QPs into regex/lint gates — behavioral requirements verify at smoke/review (FR-25 lesson, inverse case).
• Do NOT load all categories for every feature — the index exists to scope the read.
• Do NOT use QPs to override stack-specific CLI guidance — QP says WHAT, CLI skills say HOW.

Clean-room note

Original Fusebase Flow content. The patterns codify widely-known web/app engineering practice observed failing in LLM-generated apps; no third-party code, prompts, skill files, or hook scripts are copied. See docs/source-map.md.