Architecture Decision Records - HAI-Co²

This section records the load-bearing architectural decisions behind HAI-Co². Each ADR is a short MADR-style record that captures one decision: why it was made, what was chosen, and the consequences.

Why we keep ADRs

Audit trail. A year from now, someone will ask “why did we pick X over Y?”, and the answer lives next to the code instead of in chat history.
Onboarding. A new contributor can read this section and understand the project’s structural choices without reading every PR.

Status lifecycle

Status	Meaning
`proposed`	Drafted in a PR; not yet merged or acted on.
`accepted`	Merged and in effect. Default state for live ADRs.
`deprecated`	Superseded by changing circumstances; not directly replaced.
`superseded by NNNN-…`	Overridden by a newer ADR.

Never edit an accepted ADR’s decision. To change direction, open a new ADR, summarise what changed, and mark the old one superseded by NNNN-…. The old record stays intact as history.

Index

#	Decision
0000	Record architecture decisions
0001	Two-branch model with tag-driven releases
0002	Dual development pathways: traditional + AI-assisted
0003	Branch conversations as new threads seeded via checkpointer state
0004	Depth-ordered plan tree + per-turn editable Objective
0005	One turn-anchored feedback table with a frontend-owned instrument
0006	Authenticate programmatic API clients with personal access tokens

When writing a new ADR, copy the template and give it the next 4-digit number.

Features ADR-0000