cli-is-verified-pure-delegation
OUT derived (depth 3)
The CLI is both structurally pure (every handler delegates to API functions with no business logic) and end-to-end verified (hermetic integration tests confirm delegation produces correct output through the full argv-parsing pipeline).
Summary
The CLI would be fully trustworthy as a thin pass-through layer if every command both avoided embedding logic and was covered by integration tests, but that combination does not currently hold. The cmd_propagate code path appears to bypass the API layer, which means at least one command cannot be verified through the standard test harness, breaking the guarantee that delegation alone is sufficient for correctness.
Justifications
SL — Structural purity guarantees the CLI adds no behavior; verification confirms this guarantee holds in practice — together they establish the CLI as a trustworthy transparent interface layer.
Antecedents (all must be IN):
- cli-is-pure-delegation-layer — The CLI is a pure delegation layer: every handler dispatches through a flat dict lookup to API functions with no business logic, producing binary exit codes and correct stream separation — a complete separation of formatting from computation.
- cli-is-verified-end-to-end — The CLI is verified through hermetic end-to-end integration tests (isolated databases per test, full argv-parsing pipeline, deterministic stream-correct output) — unless cmd_propagate bypasses the API layer, leaving one code path's safety guarantees unverifiable through the standard integration testing harness.
Dependents
These beliefs depend on this one:
- full-user-stack-is-verified-atomic-delegation — The full user-facing stack forms a verified chain of atomic delegation: the CLI is structurally pure delegation verified through hermetic integration tests, and every mutation flowing through the API layer is atomic, audited, and produces observable before/after diffs — ensuring end-to-end traceability from user command to persisted state change.