Architecture decision records
The ADRs capture the load-bearing design calls behind crucible: why the loop is shaped the way it is, what was traded off, and what the alternatives were. They are ordered, append-only, and meant to be read when you want the why rather than the how.
Expand this section in the sidebar to browse the full list.
| ADR | Decision | Status |
|---|---|---|
| 0001 | Adaptive harness | Partially implemented |
| 0002 | Mediated provisioning (MCP) | Implemented |
| 0003 | Async approval waits | Implemented |
| 0004 | Core-loop state model | Implemented |
| 0005 | Engine-side builds (MCP) | Implemented |
| 0006 | Profiler support over MCP | Implemented |
| 0007 | Isolation pre-flight (the metric that misframed #1109) | Accepted (process) |
| 0008 | Domains as immutable composes (the rpm-ostree model) | Partially implemented |
| 0009 | Composite domains (combined multi-component autoresearch) | Implemented |
| 0010 | Candidate portfolios — explore/exploit search | Implemented (v1) |
| 0012 | Crucible-rendered deployments, generating the loop/broker/deployment manifests | Implemented |
| 0014 | Scoping as a governed pipeline, crucible scope <issue> | Partially implemented |
| 0017 | Turn result contract, structured state back from turn pods | Implemented |
| 0018 | Declarative image builds, build backends + the building state | Implemented |
| 0019 | The loop pod stops being a container host, OpenShell's Kubernetes driver | Partially implemented |
| 0020 | Candidate build modes, how a proposal becomes a measured artifact | Proposed |
| 0022 | Measure task DAGs, the engine walks the ladder | Proposed |