## Code Review

### expert_build/prompts.py:SUMMARIZE_CODE
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: Well-structured prompt template with clear sections (Overview, Usage Patterns, API/Config, Key Behaviors, Relationships). Uses `{content}` placeholder consistently with the existing `SUMMARIZE` template. Imported and used correctly in `summarize.py`.
---

### expert_build/summarize.py:cmd_summarize (file globbing + template selection)
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: The glob expansion `[*input_dir.glob("*.md"), *input_dir.glob("*.py")]` with `key=lambda p: p.name` sort is correct. Template selection `SUMMARIZE_CODE if source_path.suffix == ".py" else SUMMARIZE` is clean and correct. The existing CLI wiring in `cli.py:110` requires no changes since the `summarize` subcommand already delegates to `cmd_summarize`, and the new `.py` support is picked up automatically by the globbing change.
---

### expert_build/summarize.py:cmd_summarize (truncation warning)
VERDICT: CONCERN
CORRECTNESS: QUESTIONABLE
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: The inline ternary with implicit string concatenation is technically correct — Python concatenates adjacent string tokens at the grammar level, so the `else` branch properly combines `f"  WARN: truncated from {original_len} to 30000 chars. "` with `f"Large documents may lose tail content."`. However, the visual indentation is misleading: `f"Large documents may lose tail content."` aligns with `f"Consider: code-expert chunk-pdf {source_path}"`, making it look like it belongs to the `if` branch. This is a maintenance hazard — a future editor could easily misread the branches and introduce a bug. Recommend refactoring to an explicit `if/else` block:

```python
if source_path.suffix == ".pdf":
    print(f"  WARN: truncated from {original_len} to 30000 chars. "
          f"Consider: code-expert chunk-pdf {source_path}")
else:
    print(f"  WARN: truncated from {original_len} to 30000 chars. "
          f"Large documents may lose tail content.")
```
---

### expert_build/summarize.py (test coverage)
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: Observations confirm zero test files and zero test callers for `cmd_summarize`. Both the new `.py` globbing behavior and the template selection logic are untested. At minimum, a test should verify: (1) `.py` files are discovered alongside `.md`, (2) `SUMMARIZE_CODE` is used for `.py` and `SUMMARIZE` for `.md`, (3) the truncation warning renders correctly for both PDF and non-PDF suffixes.
---

## Summary

Two concerns, no blockers. The code is functionally correct but:
1. The inline ternary warning message is a readability trap — refactor to a plain `if/else`.
2. `cmd_summarize` has zero test coverage, and this PR adds two new behaviors (`.py` support, conditional warning messages) without tests.

### SELF_REVIEW
LIMITATIONS: Full observation of `cmd_summarize` was provided, which gave good coverage. Could not verify whether `.py` files with coincidental `---` at the start (e.g., in a docstring) would be incorrectly parsed as frontmatter — this is an edge case that predates this PR but is now reachable via the new `.py` globbing.
---

### FEATURE_REQUESTS
- Show the result of actually running `python -c "ast.parse(...)"` or equivalent on ambiguous expressions like the inline ternary to confirm parse-tree structure, rather than relying on reviewer mental parsing.
---
