Review 003 addendum: env-variable boundary verified — every env::var read is test-target-only (pg gate modules), production paths are env-free with config riding PgOpts/SqliteOpts/DSN per ADR-008 §6 and deployment.md (family posture: alkvault 'nothing important goes in env vars', alkhttp 'no handler reads std::env::var'); wave-6 release-readiness gains the prepublish re-check (no-env-in-production grep + one-sentence pin in the engine specs / deployment matrix)
This commit is contained in:
1 parent
ed883e06ea
commit
dbb17068cc
1 file changed
+29
-1
@@ -40,6 +40,32 @@ SKIP posture, but reviewers should set the env before believing a pg
|
||||
claim: this review's first baseline run reported zero pg tests executed
|
||||
(25 suite tests "passing" in 0.02 s).
|
||||
|
||||
## Env-variable boundary (verified — family posture)
|
||||
|
||||
The alk* family rule is "nothing important goes in env vars" (alkvault
|
||||
README), with the alkhttp spelling as the wire-facing case ("no handler
|
||||
reads `std::env::var`"). Verified this session by grep across the whole
|
||||
workspace: **every `env::var` read lives in a test target** — the pg
|
||||
gate modules (`store/*_tests.rs`, `tests/schema_tests.rs`,
|
||||
`tests/contract_suite.rs`). Production paths (`alkstore/src`, both
|
||||
engines' machinery, the contract suite, the constructors) are env-free
|
||||
— the only `std::env` uses in the other crates are `std::env::temp_dir()`
|
||||
inside test modules for temp-file paths, not configuration.
|
||||
Configuration reaches production exclusively through `PgOpts` /
|
||||
`SqliteOpts` / DSN arguments passed by the caller's own config layer
|
||||
(`engine-postgres.md`, ADR-008 §6; deployment.md's config table carries
|
||||
no env entry) — the engines never consult the process environment, so
|
||||
no credential (or any setting) can arrive implicitly.
|
||||
|
||||
For wave 6 (release readiness / prepublish) this boundary is an
|
||||
explicit re-check item, not a settled fact: re-run the
|
||||
no-env-in-production grep, and pin the boundary in the engine specs /
|
||||
deployment matrix in one sentence ("env reads are harness-only;
|
||||
production configuration is the opts-constructor surface"). Should a
|
||||
future consumer-facing surface ever want env conveniences, the family
|
||||
pattern is caller-side: the app's own config layer reads env (or
|
||||
vault/config file) and hands the store's opts its values.
|
||||
|
||||
## Verdict
|
||||
|
||||
**No correctness or security defects found; wave 5's deliverables are
|
||||
@@ -214,4 +240,6 @@ No changes required to keep wave 5's verdict standing. For wave 6's
|
||||
window: Finding 1 is a decomposable small task (transient-fault seam +
|
||||
retry/exhaustion pin); Findings 2–3 can ride the same task or be
|
||||
accepted with the code-read as their pin — either way the disposition
|
||||
should be recorded. Findings 4–5 need no work.
|
||||
should be recorded. Findings 4–5 need no work. The env-variable
|
||||
boundary section above folds into wave 6's release-readiness pass as a
|
||||
verified-now / re-check-at-prepublish item.
|
||||
Reference in new issue
Block a user