Documentation Criteria

Documentation Creation Criteria

Templates

• prd-template.md - Product Requirements Document template
• adr-template.md - Architecture Decision Record template
• ui-spec-template.md - UI Specification template (frontend/fullstack features)
• design-template.md - Technical Design Document template
• plan-template.md - Work Plan template

Creation Decision Matrix [MANDATORY]

Build one path in this order:

1. Select the base path from Structural Scale.
2. Frontend or fullstack scope inserts UI Spec immediately before the Design Doc.
3. One or more qualifying ADR decision points insert an ADR batch immediately before the Design Doc. A qualifying decision point sets the scale floor to Medium.

ENFORCEMENT: EVALUATE structural scale and ADR conditions BEFORE starting implementation

Structural Scale

Classify the decision burden, not repository layout. File count is supporting evidence only.

A qualifying ADR decision point sets the floor at Medium because it creates a durable decision. Large applies when multiple independently valuable outcomes require separate design decisions; one coherent outcome remains Medium across multiple layers. ADR decision points come from the Choice and Durability filters independently of scale.

ADR Creation Conditions

First check accepted ADRs that govern the changed responsibility. Then apply both filters in order for each technical topic within the confirmed implementation scope:

1. Choice requires judgment — current requirements, accepted decisions, and representative repository patterns support at least two credible materially distinct options whose selection requires comparison.
2. Decision is durable — choosing among those options materially changes a responsibility, dependency direction, shared contract, persistence model, technology dependency, reversibility, or lifecycle cost that future work must understand or preserve.

Create one ADR for each topic that passes both filters. Route topics with one evident choice, generic technical concerns, operational possibilities, and rejected activities directly to the Design Doc or out of current design as applicable.

Treat choices as one decision point when they must be selected or reconsidered together. Use separate decision points when each choice can be selected and revisited independently.

Qualifying durable choices include:

• introducing or replacing a technology, library, platform, storage model, or external dependency;
• changing ownership, dependency direction, trust boundary, or a shared public contract in a way with credible materially different alternatives;
• reversing or superseding an accepted architecture decision;
• choosing an irreversible or high-cost-to-reverse data or compatibility strategy.

A local contract, data-flow, state, or component change that follows an accepted design, has one evident repository-supported implementation, or remains cheaply reversible belongs in the Design Doc. Counts of files, consumers, nesting levels, states, steps, and Structural Scale remain supporting evidence rather than ADR criteria.

What Each Document Fixes

Each document fixes one class of decision needed by its downstream consumer. The decision matrix determines whether the document is required; the applicable template defines its content.

Storage Locations

ADR Status

Proposed -> Accepted -> Deprecated/Superseded/Rejected