frontend-patterns/canon/PatternSchema.md

Pattern Schema

Each pattern consists of structured metadata plus explanatory prose.

Canonical metadata

---
id: FEP-AFF-001
name: Optimistic Overlay
family:
  - affordance
  - mutation
scale: L6
status: hypothesis

context:
  - remote authority
  - perceptible mutation latency

forces:
  improves:
    - interaction_latency
    - perceived_responsiveness
  worsens:
    - reconciliation_complexity
    - implementation_complexity

requires:
  - identifiable_mutation
  - authoritative_state

relations:
  refines:
    - local_interaction_state
  enables:
    - immediate_feedback
  conflicts_with:
    - destructive_uncompensated_mutation

known_uses: []

evidence:
  maturity: hypothesis
  sources: []
---

Human-readable structure

Every pattern should contain:

# Pattern Name

## Context

## Problem

## Forces

## Solution

## Dynamics

## Resulting Context

## Consequences

## Failure Modes

## Known Uses

## Related Patterns

## Evidence

## Implementation Notes

Requirements

A pattern should:

• describe a recurring problem,
• expose at least two meaningful forces,
• propose a reusable configuration,
• explain consequences,
• identify failure modes,
• create or refine a context in which other patterns apply.

A useful technique is not automatically a pattern.

A framework feature is not automatically a pattern.

A pattern name should identify a reusable architectural idea rather than a product-specific API.