One paragraph: what this project does and what it does not do. State the invariant — the property that, if violated, would make the whole project pointless. Future maintainers will read this paragraph first.
Replace this section with an ASCII or Mermaid diagram. Keep it under 20
lines — anything bigger belongs in architecture/.
+------------------+ +------------------+
| Component A | ---> | Component B |
+------------------+ +------------------+
|
v
+------------------+
| Component C |
+------------------+For each external input, describe:
-
Source: where it comes from.
-
Validation: what guarantees we enforce on entry.
-
Transformation: high-level processing stages.
-
Sink: where the result goes.
Enumerate the load-bearing invariants of the system. Each should have:
-
A one-line statement.
-
The code location(s) that enforce it.
-
The failure mode if the invariant is violated.
Example:
| # | Invariant | Enforced at | Failure mode |
|---|---|---|---|
1 |
All HTTP requests carry a valid |
|
Logs become unjoinable; correlation breaks. |
2 |
The output buffer is always flushed before exit. |
|
Last ~16KB of log lost on crash. |
-
Internal: list other hyperpolymath repos this depends on.
-
External: SHA-pinned (see
Cargo.lock/deno.lock/ etc.). -
Build-time: tools required to build (just, deno, cargo, …).
Explicit non-goals. Things we deliberately do not do, with a one-line reason for each. This section saves more time than the rest combined.
-
Usage — consumer perspective.
-
Contributing — developer setup.
-
ADRs — historical record of why this shape.