Architecture Decision Records
Every decision here was expensive to reverse once code depended on it, so it was written down before or alongside the implementation rather than reconstructed afterwards.
Each record states the decision, what was rejected, why, what it costs, and, most importantly, the trigger that should make us revisit it. A decision without a revisit trigger is a belief, not an engineering choice.
| ADR | Decision | Status |
|---|---|---|
| 0001 | Repository visibility and ownership | Accepted |
| 0002 | Session propagation model | Accepted |
| 0003 | Detector terminology | Accepted |
| 0004 | Parameter capture and privacy defaults | Accepted |
| 0005 | SQL fingerprint strategy | Accepted |
| 0006 | ASP.NET Core behavior | Accepted |
| 0007 | Stack trace capture | Accepted |
| 0008 | Supported .NET versions | Accepted |
| 0009 | Provider support | Accepted |
| 0010 | Testing framework dependency | Accepted |
| 0011 | Versioning and report schema | Accepted |
| 0012 | Publishing credentials | Accepted |
| 0013 | Baseline storage and comparison | Accepted |
Statuses
- Proposed: written, not yet acted on.
- Accepted: in force. Code and documentation must match it.
- Superseded: replaced by a later ADR, which is linked from the header.
Adding a record
Open a pull request that adds NNNN-short-kebab-title.md using the same headings as an
existing record. A change to a public API, a captured field, the report schema, the
supported framework matrix, or the release pipeline needs an ADR before the implementation.