Here is my senior code review of the proposed changes introducing concurrent/parallel model execution and individual issue topic queueing.

---

### ftl_project_expert/llm.py
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: 
- `invoke_concurrent` and `invoke_concurrent_sync` are implemented cleanly using `asyncio.Semaphore` to limit concurrency and `asyncio.gather(..., return_exceptions=True)` to safely isolate individual invocation errors.
- Both new functions are completely untested (the project has no unit or integration tests), which is a key concern.
- The use of `asyncio.run` in `invoke_concurrent_sync` is correct for synchronous Click CLI commands as they do not run inside an existing event loop.
---

### ftl_project_expert/cli.py:scan
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: 
- Adds the `--per-issue` option which correctly flags `all_pages = True` and skips overview generation to enqueue topics directly.
- Fully integrated with command arguments.
- It triggers the pagination loop which exposes the cache-overwriting bug in `_scan_page`.
- Untested.
---

### ftl_project_expert/cli.py:_scan_page
VERDICT: CONCERN
CORRECTNESS: QUESTIONABLE
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: 
- **Overwriting Cache Bug**: When `per_issue` is `True` and `all_pages` is active, `_scan_page` is called per page. In each call, `_cache_issues(issues, project_dir)` is invoked, which completely overwrites the contents of `issues-cache.json`. By the end of scanning, **only the last page's issues remain in the cache**, rendering the offline fallback for previous pages' topics broken during future `explore` commands.
- **Redundant Imports**: The local imports of `Topic` and `add_topics` are redundant as they are already imported at the top of the file (lines 20-21).
- Untested.
---

### ftl_project_expert/cli.py:explore
VERDICT: CONCERN
CORRECTNESS: QUESTIONABLE
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: PARTIAL
REASONING: 
- **Parallelism Ignored on Pick**: The `--parallel` (`max_parallel`) option is correctly passed down to the `explore --loop` handler. However, if a user picks multiple topics manually via `explore --pick 1,2,3 --parallel 3`, the topics are processed purely sequentially in a standard `for` loop, ignoring the parallel limit option. This is an integration gap.
- Untested.
---

### ftl_project_expert/cli.py:_explore_loop
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: 
- Properly delegates to `_explore_loop_parallel` when parallel limits are configured (`max_parallel > 1`) and falls back cleanly to sequential loop execution.
- Untested.
---

### ftl_project_expert/cli.py:_explore_loop_parallel
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: 
- Correctly batches the pending topics, constructs prompts, and waits for concurrent model invocations.
- Exception handling in results is robust.
- **State safety**: Disk and queue mutations (like creating entries and enqueuing sub-topics) are handled sequentially in the results iteration. This prevents concurrent file system write race conditions.
- Note: Popped topics remain marked `"done"` even on error (matching sequential behaviour, but worth highlighting).
- Untested.
---

### ftl_project_expert/cli.py:_build_topic_prompt
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: 
- Refactoring the prompt-building logic into its own helper is an excellent design separation.
- **Synchronous Bottleneck**: Because this function calls the platform source APIs synchronously (e.g., `source.get_issue`) and is executed sequentially via list comprehension in `_explore_loop_parallel` before invoking the LLM batch, these sequential platform queries act as a major synchronous bottleneck before parallel LLM execution can begin.
- Untested.
---

### ftl_project_expert/cli.py:_run_topic
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: 
- Correctly uses the new `_build_topic_prompt` helper logic with no behavioral regressions.
- Untested.
---

### ftl_project_expert/cli.py:propose_beliefs
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: 
- Adds `--parallel` (`max_parallel`) option and handles parallel prompt dispatch correctly.
- Safely processes concurrent batch results while logging individual errors to prevent failure cascades.
- Untested.
---

### ftl_project_expert/cli.py:review_proposals
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: 
- Successfully implements batching and parallel review pipeline.
- Handles concurrent batch failures cleanly while consolidating valid decisions on the main loop.
- Untested.
---

### ftl_project_expert/cli.py:update
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: 
- The `--parallel` option is cleanly wired throughout the entire update pipeline, passing it sequentially to exploration, belief extraction, and review stages.
- No option signature mismatch issues.
- Untested.
---

### SELF_REVIEW
LIMITATIONS: 
- Since the workspace does not contain any test files or test runner configuration, I was unable to verify existing test behavior or ensure no regressions in a live test suite.
- I could not verify actual integration behavior with platform sources (GitHub/GitLab/Jira) or external LLM backends due to the lack of live credentials/sandbox environments.
---

### FEATURE_REQUESTS
- Implement actual mock classes/fixtures for both model endpoints and project platform sources to make unit testing the CLI pipelines feasible.
- Modify `_cache_issues` to load the existing cache, merge new issues, and write it back, preventing sequential pagination pages from destroying cached data from preceding pages.
- Add async support to the `Source` classes so prompt building/issue-fetching can run concurrently alongside the LLM invocations.
