Now I have everything I need for the review.

---

### CLAUDE.md (new file)
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: UNRELATED
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: N/A
INTEGRATION: N/A
REASONING: Standard project documentation file. Not related to the issue but harmless. Content matches the existing CLAUDE.md already loaded from the project.

---

### ftl_project_expert/cli.py:summary — belief truncation logic
VERDICT: CONCERN
CORRECTNESS: QUESTIONABLE
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: PARTIAL
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING:

**What the fix does well:**
- Addresses the root cause by capping beliefs sent to the LLM at 500 (line ~2034).
- Uses `--status IN` to filter out retracted beliefs — sensible, only active beliefs matter for a summary.
- Uses `--by-impact` to sort by dependent count, so the most important beliefs survive truncation.
- Improved error messaging now includes prompt size in KB (line ~2089), directly addressing the "Report the actual failure clearly" suggestion from the issue.
- User-facing output distinguishes between truncated and non-truncated runs (lines ~2066-2072).

**Concerns:**

1. **`--by-impact` flag availability is not guarded.** The `reasons` CLI does support `--by-impact` and `--status` (confirmed via `--help`), but the code calls `reasons` as an external subprocess. If the user has an older version of the `reasons` CLI installed that predates these flags, the subprocess will fail with a non-zero exit code, and the code at line ~2048 (`if result.returncode == 0`) will silently fall through to "No beliefs found" — a confusing failure mode. Consider logging stderr when the `reasons list` call fails.

2. **Hard-coded `max_beliefs = 500` is not configurable.** The magic number 500 is reasonable for Claude's context window but there's no CLI flag or config option to override it. For smaller models or larger contexts, users can't tune this. Minor concern — the current value works, but a `--max-beliefs` flag would be cheap to add.

3. **`beliefs.md` path is not capped.** When beliefs come from `beliefs.md` (lines ~2053-2056), no truncation is applied. The same issue could occur with a large `beliefs.md` file. The `total_count` is set to `belief_count` so the truncation message won't appear, and the full text goes to the LLM uncapped. This is a gap — the issue could recur for users not using `reasons.db`.

4. **No tests.** The observation confirms `test_count: 0` for the summary function. Given that this is a bug fix changing core behavior (filtering and truncation), at least a unit test verifying the truncation logic would be appropriate. The `build_summary_prompt` function is a pure function that's easy to test, and the truncation logic in `summary()` could be extracted into a testable helper.

5. **`belief_count` passed to `build_summary_prompt` now reflects truncated count, not total.** The summary prompt says "Beliefs analyzed: {belief_count}" — with truncation this will say "Beliefs analyzed: 500" when the network has 10,822 beliefs. The prompt doesn't tell the LLM that these are the top 500 by impact from a larger set. The LLM might make claims about completeness that are misleading. Consider adding a note in the prompt when truncation occurred.

---

### ftl_project_expert/cli.py:summary — error reporting improvement
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: ADDRESSES
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: The error message now includes prompt size in KB (line ~2089), which directly addresses the issue's complaint that `RuntimeError` had empty stderr and was hard to diagnose. Looking at `llm.py:49`, the `RuntimeError` message format is `"Model {model} failed: {stderr.decode()}"`, so the outer catch now wraps this with the prompt size context. This is a clear improvement for debugging.

---

### SELF_REVIEW
LIMITATIONS:
- Could not verify whether `--by-impact` actually sorts by dependent count or some other metric — the `reasons` source is external to this repo.
- No test files exist for the `summary` command, so I cannot check for broken test assertions — but this also means the fix ships untested.
- Could not verify the typical size of 500 belief lines to confirm it fits within Claude CLI input limits. The prompt template is compact (~400 bytes of boilerplate), so 500 beliefs at ~100-200 bytes each would be ~50-100 KB — well within limits.

---

### FEATURE_REQUESTS
- Include `reasons` CLI source or docs when the diff calls it as a subprocess, so I can verify flag behavior without relying on runtime `--help`.
- Show callers of modified functions to verify no other code path feeds untruncated beliefs into `build_summary_prompt`.
- When test coverage is 0, flag it prominently in the observation results summary.
