cli-is-verified-end-to-end

IN derived (depth 2)

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.

Summary

The CLI can be fully tested in isolation because each test gets its own database and the command interface is simple and predictable — no hidden state leaks between tests, and output always goes where expected. The one gap is the propagate command, which may bypass the normal API layer, meaning its safety guarantees cannot be checked through the same testing approach used for everything else.

Justifications

SL — Deterministic CLI behavior (depth-1) combined with hermetic test isolation (depth-0) provides end-to-end verification — except for the one handler that skips the API layer entirely

Antecedents (all must be IN):

  • cli-is-deterministic-and-stream-correct — The CLI achieves full scriptability through three deterministic properties: flat dict dispatch with no dynamic plugin resolution, binary exit codes (0 success, 1 error) with no ambiguous intermediate codes, and clean stream separation (diagnostics to stderr, results to stdout)
  • each-cli-test-creates-isolated-db — Every CLI test method initializes a fresh SQLite database via `run_cli("init")` in a pytest `tmp_path`, ensuring zero shared state between tests.

Unless (any of these IN defeats this justification):

  • cmd-propagate-bypasses-api — `cmd_propagate` is the only CLI handler that bypasses `api.py`, going directly to `Storage` → `Network.recompute_all()` → `Storage.save()` — a design inconsistency in the otherwise pure-presentation CLI layer.

Dependents

These beliefs depend on this one:

Details