Plan ConfigKit adoption and clarify implementation policy

docs/policy/architecture.md

@@ -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

docs/policy/documentation.md

@@ -30,6 +30,18 @@ that the behavior exists. The roadmap owns implementation status and sequencing
 until the decision is implemented. Current architecture, user, operator,
 integration, and internal documentation are updated when the behavior lands.
 
+### Implementation Details And Policy
+
+Documentation must distinguish an explicit contract from an incidental
+implementation choice. Do not describe a restriction, guarantee, security
+policy, default, or limit as authoritative merely because the current code
+implements it. Documentation may accurately describe current behavior without
+making it a permanent requirement; distinguish descriptive behavior from
+normative policy. The
+[implementation-discipline rules](architecture.md#implementation-discipline)
+own the criteria for adopting product restrictions and for elevating behavior
+into repository policy.
+
 ### Audience And Detail
 
 Write for the document's stated audience and include only the detail needed for

docs/policy/testing.md

@@ -87,6 +87,13 @@ Do not force all behavior through oversized end-to-end tests. Do not test every
 
 A test should protect a decision, contract, or invariant—not memorialize the current implementation.
 
+Tests must not create a stronger product contract than the requirement they
+protect. In particular, do not turn an incidental limit, restriction,
+permission choice, validation rule, or implementation default into policy by
+asserting it without an expressly selected contract. Follow the
+[implementation-discipline rules](architecture.md#implementation-discipline)
+when deciding what behavior deserves durable protection.
+
 Before adding or retaining a test, ask:
 
 > What realistic defect would this test catch?