Architecture Decision Records
Architecture Decision Records (ADRs) capture significant decisions that shape neoc. Each ADR is a short, dated record of a decision and the forces that motivated it. The format follows npryce/adr-tools.
ADRs are retrospective: they document decisions that have been made and are in force. By contrast, RFCs are forward-looking: they propose changes that have not yet been accepted. An accepted RFC that introduces a load-bearing decision typically produces a corresponding ADR; see the relevant RFC for the design rationale, and the ADR for the resulting decision.
Status
Each ADR carries one of the following statuses in its front matter and the body:
| Status | Meaning |
|---|---|
Proposed | The decision is under discussion. Not yet in force. |
Accepted | The decision is in force. The codebase is expected to comply. |
Deprecated | The decision is no longer recommended. A replacement has not yet superseded it. |
Superseded | The decision has been replaced by a later ADR, which is linked from the body. |
Index
- 0001. Use Luau as the embedded scripting language
- 0002. Strip the unsafe halves of the Lua standard library
- 0003. Three-namespace module structure (
std,lib,vnd) - 0004.
vnd:*module names match upstream crate names verbatim - 0005. Tuple-return convention for recoverable failures
- 0006. Hidden async with synchronous-looking Lua APIs
See also
- Template — Copy when creating a new ADR.
- RFCs — Forward-looking design proposals.
- The module system — Touchpoint for ADRs 0003, 0004, and 0005.