adr-workflowlisted

# adr-workflow Use when a structural choice changes how future code is written and a future contributor would otherwise ask "why?". ADRs are codebase-scoped. Product or cross-organization strategy belongs in the product's decision system. This composes with `harness:writing-plans`: plans describe work; ADRs preserve the decisions behind it. ## Write an ADR when - A library or platform choice creates material lock-in. - A naming, layout or dependency convention affects the codebase broadly. - Ownership, trust or deployment boundaries change. - A performance, availability, privacy or security trade-off is accepted. - A previous accepted ADR must be reversed or narrowed. Do not write one for bug fixes, preference, pure refactors or choices reversible in one small PR. If no credible alternative was rejected, the record is usually ceremony rather than a decision. ## Storage contract One decision owns one Markdown file. Never append to, number from, or regenerate a shared index. Default location: ```text docs/decisions/ 2026-07-24-use-drizzle--018f43f4-3ac4-7c40-8000-000000000001.md ``` An existing project may keep an established equivalent such as `docs/decisions-log/` or `decisions/`. The filename contains: - an ISO date for scanning; - a readable slug describing the chosen direction; - a collision-resistant UUID used by the ADR identity. Prefer the project command when present: ```sh void-harness decisions new \ --title "Adopt Server Actions for UI mutations" \