Status: accepted · ADR-7 · Filed 2026-04-17
Decision
PRISM.md is composed at project bootstrap from a layered template system: prism-base.md (universal methodology: lifecycle, artifact vocabulary, session discipline) concatenated with prism-<ptype>.md (project-type-specific overlay: application, research, travel, home-improvement, etc.). The composition happens once at scaffold time. PRISM.md is then version-pinned (methodology_version header in the file). When the canonical template changes, prism_start detects version drift and prompts the user: ‘A newer methodology version (X.Y.Z) is available. Run update?’ — never auto-applies. Adding a new ptype is a matter of writing a new overlay template.
Rationale
The ontology we mapped (Plan, Spec, Decision, TODO, Journal, Retro, Note, Memory) is domain-neutral. What differs across project types is texture, not structure. A layered template system lets the base methodology evolve uniformly while ptype-specific overlays adapt to domain needs. Version-pinning with user-consent upgrades preserves the trust model: you own PRISM.md after scaffold, Prism offers upgrades, you accept or decline. This is the DFW philosophy applied to its own infrastructure — methodology evolves with consent, not by imposition.
Alternatives Considered
Single PRISM.md per project authored by humans — no reuse across projects, every project reinvents the methodology. Dynamic PRISM.md fetched from Prism at every session start — loses offline mode and version-pinning. One monolithic template with conditionals — bloats, hard to maintain per-ptype sections.
