cli-is-pure-delegation-layer
OUT derived (depth 1)
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.
Summary
The CLI layer acts purely as a thin pass-through: it maps subcommand names to handler functions via a simple dictionary, calls into the API for all real work, and only concerns itself with formatting output and setting exit codes. This means computation and presentation are fully separated, so you can swap or test either side independently. Currently marked as retracted, meaning one or both of its supporting claims no longer hold.
Justifications
SL — Pure delegation holds for all handlers except cmd_propagate, which bypasses the API and goes directly to Storage/Network
Antecedents (all must be IN):
- cli-is-pure-formatter — Every cmd_* function delegates to api.* and only formats the returned dict for terminal output; no business logic lives in the CLI layer.
- cli-dispatch-is-flat-dict-lookup — CLI dispatch uses a flat `commands` dict mapping subcommand strings to `cmd_*` handler functions — no plugin system or subclass hierarchy.
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:
- cli-is-verified-pure-delegation — 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).