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

1. **GitHub path looks correct** — `gh label list --json name -q ".[].name"` with `-L 1000` is a pragmatic approach. Silent failure on `gh label create` is acceptable since the subsequent `_create_issue` call will surface the error if the label still doesn't exist.

2. **GitLab path has a potential flag issue** — `glab label list -F json` may not be the correct flag across glab versions. The glab CLI has used `--output json` and `-F json` inconsistently. However, the existing `_create_issue` function also shells out to `glab` with similar patterns, and the try/except around JSON parsing provides a safety net (falls back to empty set, so all labels get created — a harmless over-creation).

3. **No error logging on label creation failure** — Both the GitHub and GitLab branches swallow `subprocess.run` results for `label create`. A failed creation is silent. The user sees "Creating label: X" but never "Failed to create label: X". Compare with `_create_issue` (line 3040) which logs `result.stderr` on failure. This inconsistency could make debugging harder when label creation fails due to permission issues.

4. **No tests** — `test_count: 0`. This is a new function with branching logic (GitHub vs GitLab), subprocess calls, and JSON parsing — it warrants at least unit tests with mocked subprocess calls to verify both paths and error handling.

---

### ftl_code_expert/cli.py:file_issues (label integration at line 3536-3538)
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: UNTESTED
INTEGRATION: WIRED
REASONING: The integration point is correctly placed — after dedup and confirmation, before filing. The guard `not dry_run and remaining` is correct: no point creating labels if nothing will be filed or if it's a dry run. The `required_labels` set correctly unions the two fixed label prefixes with user-supplied `--label` values. The label set `{"reasons-gate", "reasons-negative"}` matches the pattern used in the filing loop (line 3549: `f"reasons-{ctype}"` where ctype is `"gate"` or `"negative"`).

---

### ftl_code_expert/data/CLAUDE.md.template
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: N/A
INTEGRATION: N/A
REASONING: Documentation-only change. Adds verification commands and a usage guide for the reasons database. Commands referenced (`verify`, `infer-sources`, `reasons search/show/explain/list`) are consistent with the CLI interface. Clear, well-structured guidance.

---

### SELF_REVIEW
LIMITATIONS:
- Could not verify the exact `glab label list` flag syntax against the installed glab version — the `-F json` flag correctness is uncertain.
- No test files were provided or found, so I cannot assess whether existing tests might break or whether test infrastructure exists for subprocess-mocking in this project.
- The full `_find_existing_issues` and `_confirm_beliefs` functions were not observed — cannot verify whether the overall `file_issues` flow has any ordering dependencies that the new `_ensure_labels` call might interact with.
---

### FEATURE_REQUESTS
- When `test_count: 0` is detected, include a sample of existing test files for the same module to show the project's testing patterns — this helps reviewers assess whether "untested" is an anomaly or the norm.
- Include the output of `<tool> label list --help` or similar to verify CLI flag correctness when the diff shells out to external tools.
---
