adr-lifecycle

Architectural decision record lifecycle management automates tracking status changes from proposed to accepted, superseded, or deprecated. It enforces consistency and immutability in architectural decisions using frontmatter fields and lifecycle scripts.

Superseding an architectural decision record is handled automatically by backfilling the 'superseded_by' field when a new ADR is promoted. This maintains an immutable body for the original decision rationale.

Standardizing ADR creation requires using specified YAML frontmatter fields, including both required and optional metadata. This frontmatter spec ensures architectural decisions are tracked consistently across their lifecycle.

Architectural decision records use immutable bodies, meaning the decision rationale cannot be altered after creation. To change a decision, you must create a new ADR that supersedes the previous one.

The three-test gate is a validation step in the ADR lifecycle process used when proposing a new architectural decision record. Running the lifecycle skill triggers this gate to ensure decisions meet consistency requirements before acceptance.

Architectural decision record lifecycle management is needed when planning new features that require documented architectural decisions and rationale. It ensures decisions are tracked from proposed to accepted while maintaining an immutable history.