ADR-0002: Fix artifact lifecycle design flaws

Status: accepted | Date: 2026-01-17

References: RFC-0000

Context

Analysis of the artifact lifecycle state machines revealed several design flaws:

1. Clause kind vs status duplication: The kind enum includes deprecated alongside normative and informative, but status also has deprecated. This creates confusion about where deprecation state belongs.

2. ADR missing rejected state: The ADR lifecycle is proposed → accepted → superseded. If a proposal is rejected rather than accepted, there is no state to record this outcome. The alternative is leaving it as proposed forever or deleting it, both of which lose information.

3. Work Item forced activation before cancellation: The lifecycle queue → active → done|cancelled implies you must start work before abandoning it. This is illogical - planned work can be abandoned before starting.

4. RFC status×phase constraint rules undocumented: The 3×4 matrix of valid/invalid status×phase combinations exists implicitly but is not formally documented in SCHEMA.md.

Decision

We will fix all four lifecycle design flaws:

1. Remove deprecated from Clause kind: The kind field should only contain semantic categories (normative, informative). Deprecation is a lifecycle state that belongs in status.

2. Add rejected to ADR lifecycle: The new lifecycle becomes:

   proposed → accepted → superseded
            → rejected
   

   This allows recording when a proposal was considered but declined.

3. Allow Work Item queue → cancelled: The new lifecycle becomes:

   queue → active → done
       ↘        ↘ cancelled
   

   Work can be abandoned at any stage.

4. Document RFC constraint rules: Add explicit invariant rules to SCHEMA.md stating when status×phase combinations are forbidden.

Consequences

Positive:

• Cleaner separation of concerns (kind = category, status = lifecycle)
• Complete lifecycle coverage for all artifact types
• Explicit rules prevent confusion about valid state combinations

Negative:

• Existing tools validating kind: deprecated will need updating
• Schema version bump required for breaking changes

Migration:

• Any clause with kind: deprecated should change to kind: normative, status: deprecated
• Currently no such clauses exist in the codebase