### ftl_project_expert/llm.py
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: The addition of `invoke_concurrent` and its synchronous wrapper is correctly implemented. Using `asyncio.Semaphore` is an appropriate way to limit concurrency and avoid hitting OS or API rate limits. The use of `return_exceptions=True` in `asyncio.gather` ensures that one failing LLM call does not cancel the entire batch, allowing for robust parallel processing.
---

### ftl_project_expert/cli.py
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: The integration of parallel processing into the `explore`, `propose-beliefs`, and `review-proposals` commands is well-structured. However, there are a few concerns:
1. **Partial Parallelism**: In `_explore_loop_parallel`, the call to `_build_topic_prompt` happens inside a list comprehension (lines 614), which means all network calls to fetch issue details from GitHub/Jira/GitLab are still performed sequentially before any LLM calls start. This significantly limits the performance benefits of the `--parallel` flag when many topics are being explored.
2. **Unused Import**: `invoke_concurrent` is imported on line 15 but is not directly used in this file (only `invoke_concurrent_sync` is used).
3. **Hidden Feature Addition**: Support for GitLab was added to the issue fetching logic in `_build_topic_prompt` (lines 657-661). While this is a positive addition, it was bundled with the concurrency refactor and might have been missed if not for careful review.
4. **Error Handling & Reliability**: If a parallel batch fails in `propose_beliefs` or `review_proposals`, the current implementation logs the error and continues, effectively skipping those entries. While this matches the sequential behavior, the "blast radius" of a failure is larger in parallel mode.
---

### SELF_REVIEW
LIMITATIONS: I do not have access to the `ftl-entry` CLI or the `topics.py` source code (other than the `pop_next` snippet in observations), so I cannot verify if there are potential race conditions when multiple parallel "batches" finish and try to write entries or update the queue at the same time. However, the current implementation processes results sequentially after the parallel LLM calls, which should mitigate most concurrency issues.
---

### FEATURE_REQUESTS
- Include the `tests/` directory in the initial workspace scan to help reviewers identify if tests exist for modified modules.
- Provide the ability to see "unused imports" or run a basic linter check on the diff.
