# Changelog

## Score

- CAI 60 → 58 (-2.1)
- Rubric changed (rubric-2026.10.1 → rubric-2026.10.5) — scores are not directly comparable.

## Lenses

- Code Health 100 → 76 (-24.3)
- Architecture 91 → 93 (+1.3)
- Maturity 63 → 63 (+0.0)
- Readiness 43 → 43 (+0.0)
- Security 83 → 83 (+0.0)

## Resolved (6)

- Confusing dual abstraction for command execution. `Command` exposes `exec_program` and `exec_subprocess`, while `ProgramRunner` and `SubprocessRunner` expose `call`. It is unclear if `Command` methods delegate to the Runner classes or if they are independent implementations. The naming `exec_program` vs `call` is inconsistent.
- Documentation: no architecture or design documentation (README.md)
- Inconsistent argument handling for CLI entry points. Most methods accept an `argv` array, but `provision`, `validate`, and `ls` do not. This suggests either a lack of uniformity in how the CLI parser is invoked or that some commands ignore arguments while others require them, making the API surface unpredictable for callers.
- Inconsistent argument signatures for similar lifecycle operations. `DNS.up` and `SSH.up` take no arguments, while `DNS.restart` and `SSH.restart` take `args`. This implies that 'up' operations might use defaults or config, while 'restart' requires overrides, but the naming doesn't reflect this distinction clearly (e.g., `up` vs `start`).
- PR-triggered workflow without a permissions block
- Redundant abstraction layers with inconsistent parameter passing. The CLI layer passes `compose_argv` to Infra methods, which then initialize Command objects that also take `compose_argv`. This duplication suggests the CLI layer is merely a pass-through without adding value, or that the separation of concerns is unclear.

## New (5)

- Ambiguous distinction between `exec_program` and `exec_subprocess`. The names suggest a technical implementation detail (process type) rather than a user-facing operation. It is unclear if this is a public API or internal helper. If public, the distinction is confusing; if internal, it should not be exposed at the top-level `Dip.Command` type.
- Inconsistent argument handling for CLI entry points. Most methods accept `argv`, but `provision()` and `validate()` do not. This suggests an inconsistency in how the CLI layer handles argument parsing or delegation, or implies these commands are stateless/single-argument while others are not.
- Inconsistent argument naming in sub-CLI modules. `DNS.up()` and `SSH.up()` take no arguments, while `DNS.restart(args)` and `SSH.restart(args)` take `args`. Meanwhile, `Dip.CLI.up(argv)` takes `argv`. It is unclear if `args` in the sub-modules is a subset of `argv` or a different structure, creating confusion for implementers of these sub-commands.
- Inconsistent constructor parameter naming compared to other command constructors. Most commands use `initialize(argv, ...)` or `initialize(...)`, but Infra commands explicitly name the first argument `compose_argv`. This breaks the pattern established by `Dip.Commands.Compose` and others.
- PR-triggered workflow without a permissions block (.github/workflows/ci.yml)