eric/notarius
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Plan ConfigKit adoption and clarify implementation policy

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-12 02:39:03 +00:00
parent 946fa10764
commit 00972e8d48
8 changed files with 1342 additions and 576 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/policy/architecture.md
View File

@@ -38,6 +38,36 @@ Notarius is contract-first without being abstraction-heavy. Interfaces and
extension points should protect demonstrated boundaries. New abstraction is not
itself an architectural goal.
## Implementation Discipline
Simplify the mechanism, not the user's choices.
**Keep implementation machinery proportionate.** Use straightforward,
idiomatic code and introduce only the machinery needed to support the requested
behavior and flexibility. Optimize for conceptual simplicity and
maintainability, not for the fewest lines, fewest options, or narrowest product
surface.
**Do not invent restrictions.** Do not reject, prohibit, constrain, cap,
harden, or otherwise narrow behavior unless required by the user, an explicit
repository contract, or an unavoidable correctness constraint. Preserve
operator and caller choice where policy has not been established. If an
additional restriction appears advisable, present it as a decision rather than
silently implementing it.
**An implementation detail is not repository policy.** Tests and documentation
must not elevate incidental behavior into a durable guarantee or restriction
unless that behavior was expressly selected as part of the contract. Existing
explicit contracts remain authoritative; changing or weakening one requires a
deliberate decision rather than being inferred from this principle.
[ADR-0017](../adr/0017-defer-cache-access-policy-to-deployment.md) illustrates
these principles. Notarius previously elevated private cache creation modes
into application policy even though Unix deployments already express access
policy through directory permissions, process umask, setgid inheritance, and
default ACLs. The revised design retains application-owned correctness
boundaries while leaving deployment security policy to the operator.
## Layers And Dependency Direction
The application boundary is the composition root and may depend on concrete