## Code Review: `walk-commits --parallel` support

### ftl_code_expert/cli.py:walk_commits
VERDICT: CONCERN
CORRECTNESS: QUESTIONABLE
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING:

**Structure is sound.** The two-phase refactor (build topics, then batch-process) mirrors the existing `explore` command pattern (lines 770-780) and correctly reuses `_explore_topics_concurrent` and `_finalize_topic`. The batch slicing, progress display, and fallback to sequential `_run_file_topic` for `parallel=1` or last-batch-of-one are all correct.

**Error handling asymmetry (lines 1369-1377).** In parallel mode, exceptions are logged and skipped (`click.echo(f" Error: {r}")`) — the run continues. In sequential mode, `_run_file_topic` (line 1022) calls `sys.exit(1)` on the first error. This means identical inputs produce different failure behavior depending on `--parallel`. A file that triggers an LLM error will abort the entire walk in sequential mode but be silently skipped in parallel mode. This is the same pattern used in `explore`, so it may be intentional, but it's worth noting.

**Dead data in `topics_with_commits`.** The `commit` half of each `(topic, commit)` tuple is never referenced after topic construction — the commit SHA and subject are already baked into `topic.title` and `topic.source`. Minor; no functional impact.

**No tests.** `walk_commits_tests` shows zero test files. This is a non-trivial control flow change (batching, async/sync branching) with no coverage at all.

---

### SELF_REVIEW
LIMITATIONS: Could not verify that `ctx.obj["parallel"]` is set by the CLI group — the group definition was not in the diff or observations. Assumed it exists based on the same pattern working in the `explore` command. Could not run the code to verify batch boundary behavior with real data.

---

### FEATURE_REQUESTS
- Include the CLI group/parent command definition when child commands reference `ctx.obj` keys not defined in their own options — this is critical for verifying integration of group-level flags.
- Show the test directory structure or test manifest so reviewers can assess whether the absence of tests is a gap vs. a known state.

---
