## Code Review

### expert_build/cli.py:main (validation block)
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: PARTIAL
INTEGRATION: WIRED
REASONING: The validation logic is correct: it compares `sub.choices.keys()` against `commands.keys()`, reports both directions of mismatch with `sorted()` for deterministic output, and exits with code 1 on failure. The check runs after `parse_args()` on every invocation, so any subparser/dispatch drift is caught immediately regardless of which command the user runs. The runtime cost is negligible (two set comparisons). One minor note: the "dispatch key without subcommand" direction is somewhat academic since `parse_args()` would reject unknown commands before reaching the check — but the clear error message is still valuable for developer debugging, and it's correct.

---

### tests/test_cli.py
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: PARTIAL
INTEGRATION: WIRED
REASONING: The test confirms the current registration is in sync (if the sets mismatched, `sys.exit(1)` would raise `SystemExit` and fail the test). However: (1) `pytest` is imported but unused — remove it. (2) The error branch (lines 144-153 of cli.py) is never exercised. A negative test that monkeypatches `commands` to introduce a mismatch and asserts on `SystemExit` + the stderr message would verify the validation logic itself, not just the current state. Without it, the validation code could be subtly broken (e.g., wrong exit code, swapped set directions) and tests would still pass. (3) The test name `test_cli_registration_is_consistent` accurately describes what it checks, but the commit message `ff9fed0` says "Fix CLI test to exercise the registration validation path" — the validation *path* executes, but only the happy branch.

---

### SELF_REVIEW
LIMITATIONS: The "main_callers" observation returned noise from `.venv/` (httpcore, h11, idna, soupsieve) rather than actual callers of `expert_build.cli.main` — likely a grep for the word "main" that matched unrelated code. This didn't affect the review since the entrypoint is obviously called from the console_scripts entry point, but it indicates the observation tool needs scoping. I also could not see whether there's a `pyproject.toml` or `setup.cfg` entry point wiring `main()` as a console script, but this is not part of the diff.

---

### FEATURE_REQUESTS
- Filter observation results to exclude `.venv/` and other vendored directories by default — the "main_callers" result was 99% noise from installed packages
- For tests, show whether the test actually passes when run (`pytest --co` or a quick execution) — this would catch import errors or silent failures

---
