Architecture Decision Records (ADR)¶
ADRs capture explicit design choices: context, decision, consequences. They answer “why do we do it this way?” later.
Numbering¶
0001,0002, … — added in chronological order (do not reorder; supersede via a new ADR that supersedes an older one).- Filenames:
0001-short-slug.md.
Retrospective ADRs¶
Much behaviour was already implemented before an ADR existed. Handle that by:
- Adding a new ADR that describes current behaviour and marking it Accepted (“documented after the fact”).
- Stating in the ADR: “Retrospective — behaviour in place since …”.
- Pointing to code/wiki where useful (
flows/reference/…,engine/reference/…).
This keeps history traceable without rewriting everything.
Contents¶
| No | Title | Status |
|---|---|---|
| 0001 | Registry-driven declarations for scoped context / designer | Proposed (direction) |
| 0002 | Plan: scoped_context (variables) — run, contract, designer |
Active plan |
| 0003 | Workflow scope as compositional unit (input/output/context, connections) | Proposed (concept) |
| 0004 | Orchestrator: scoped_context per scope, shadowing, parallel isolation |
Proposed (implementation plan) |
| 0005 | External triggers, XML/JSON/RAW payloads, examples; variables provider test flow first | Proposed |
| 0006 | RabbitMQ persistence with two-track message policy (CEL, 512KB) | Proposed |
| 0007 | Run checkpointing & crash recovery (ledger, resume phases) | Proposed (design) |
| 0008 | Stateless variables provider; runner-owned values & type metadata | Accepted (retrospective) |
| 0009 | Trigger-only gateway exposure; per-route auth (OAuth, token, API/function key, Basic); edge policies | Accepted (Phase 1) |
| 0010 | IAM RBAC: policies, rollen (groups), direct vs effective grants, wildcard enforcement, audit log | Accepted (Phase 1 & 2) |