### expert_build/cli.py:main
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: The validation logic is correct — set comparison between `sub.choices.keys()` and `commands.keys()` will catch both directions of mismatch (subparser without dispatch entry, and dispatch key without subparser). The error message is clear and diagnostic. Placement after `parse_args()` means argparse will reject unknown commands before this check runs, but the check still catches the dangerous case: a subparser that *is* accepted by argparse but has no dispatch entry, which would otherwise produce a `KeyError` at `commands[args.command](args)`. The reverse direction (dispatch key without subparser) is a developer sanity check since argparse would never route to it.

Two concerns:

1. **No tests.** The observation confirms zero test files for `cli.py`. This validation is a one-time developer safety net, but a test that monkeypatches the dict to create a mismatch would confirm the check works and doesn't regress. At minimum, a test that the happy path (current matching state) doesn't exit would be valuable.

2. **Minor: set repr in error messages.** `f"subcommands without dispatch: {missing_dispatch}"` uses Python's default set repr, which has non-deterministic ordering across runs (in Python 3.6+). This doesn't affect correctness but makes the error output harder to test with exact string matching. Consider `sorted(missing_dispatch)` for reproducible output.

---

### SELF_REVIEW
LIMITATIONS: The "main_callers" observation returned spurious results from `.venv` (httpcore, h11, etc.) rather than actual callers of `main()` — likely a grep false positive on the word "main". I relied on the function body and test observations instead. Could not verify whether any CI or integration test exercises `main()` end-to-end outside of the test files detected.

---

### FEATURE_REQUESTS
- Filter `.venv`/`node_modules` from caller search results — the current "main_callers" observation returned 200+ false positives from vendored dependencies
- When `test_count: 0`, automatically check for tests in common alternative locations (e.g., `test_*.py` patterns matching the module name, or tests embedded in CI configs)
---
