Establish an ADR process and record accepted architectural decisions

[DenWin]

Parent: #24. Begin after #17 establishes current-state facts.

Goal

Create a lightweight docs/adr process for consequential decisions without turning observations, brainstorming, or routine implementation choices into ADRs.

ADR template

• title and status
• date and decision owners
• context/problem
• constraints and decision drivers
• considered alternatives
• decision
• consequences and trade-offs
• security/operations/testing impact
• migration/rollback where applicable
• related issues, PRs, and superseded ADRs

Initial candidate decisions

Create an ADR only after each decision is actually accepted:

• application factory and bootstrap separation
• persisted authentication/session strategy
• job workspace/storage ownership
• converter catalog and orchestration structure
• output filename-template grammar
• TDD, retrospective characterization, and real-world assessment policy
• production Debian base and image pinning
• artifact signing/SBOM/provenance policy

Governance

• ADRs are immutable historical decisions; supersede rather than rewrite material history.
• Proposed ADRs remain proposed until approved.
• Architecture docs describe current state and link decisions; they do not duplicate ADR rationale.
• PR template asks whether an ADR is required.
• Define who can accept/supersede an ADR.

Acceptance criteria

• Template and index exist.
• Status lifecycle is documented.
• Initial ADRs represent accepted decisions only.
• Architecture documentation links relevant ADRs.
• Routine changes are not burdened with unnecessary ADRs.