## Code Review

### expert_build/prompts.py
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: COVERED
INTEGRATION: WIRED
REASONING: The prompt now instructs the LLM to include an `accept` boolean and the JSON schema example includes it. The guidance ("well-supported" vs "vague, speculative, or poorly supported") gives the LLM clear criteria. The backslash line continuation in the prompt is fine for Python f-string formatting.
---

### expert_build/propose.py:auto_accept_proposals
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: COVERED
INTEGRATION: WIRED
REASONING: The two regexes are safe in sequence — `\[ACCEPT/REJECT\]` won't be affected by the `\[REJECT\]` substitution since `[ACCEPT/REJECT]` doesn't contain the literal substring `[REJECT]`. The first sub handles the legacy format; the second handles the new format. Both callers in `pipeline.py` (lines 156-157) work correctly since the function now handles both old and new markers.
---

### expert_build/propose.py:cmd_propose_beliefs (verdict + header changes)
VERDICT: CONCERN
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: COVERED
INTEGRATION: PARTIAL
REASONING: The verdict logic at line 444 (`b.get("accept", True)`) is correct — defaults to accept when the field is missing, providing backward compatibility. The header text at line 368 is updated. However, `cmd_accept_beliefs` at line 483 still prints the stale message `"Edit the file and change [ACCEPT/REJECT] to [ACCEPT] for beliefs to keep."` — this should reference `[REJECT]` instead of `[ACCEPT/REJECT]` since new proposals no longer emit that marker. This is a user-facing guidance mismatch.
---

### tests/test_pipeline.py:test_converts_reject_to_accept
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: COVERED
INTEGRATION: WIRED
REASONING: Properly tests the new `[REJECT]` → `[ACCEPT]` conversion in `auto_accept_proposals`. Asserts both that all markers become `[ACCEPT]` and that no `[REJECT]` remains. Complements the existing `test_replaces_markers` (for `[ACCEPT/REJECT]`) and `test_preserves_already_accepted`.
---

### tests/test_propose.py:test_accept_verdict_from_llm + test_reject_verdict_from_llm
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: COVERED
INTEGRATION: WIRED
REASONING: Both tests exercise the full `cmd_propose_beliefs` path with `accept=True` and `accept=False` respectively, verifying the correct `[ACCEPT]` / `[REJECT]` markers appear in output. The `_json_beliefs` helper change (`accept=True` default) is backward-compatible — all 12 existing callers omit `accept` and will get the same behavior as the old code (which wrote `[ACCEPT/REJECT]`, now writes `[ACCEPT]`).
---

### tests/test_propose.py:_json_beliefs
VERDICT: PASS
CORRECTNESS: VALID
SPEC_COMPLIANCE: N/A
ISSUE_COMPLIANCE: N/A
BELIEF_COMPLIANCE: N/A
TEST_COVERAGE: COVERED
INTEGRATION: WIRED
REASONING: Adding the `accept` keyword arg with default `True` is backward-compatible. All existing callers that don't pass `accept` will now generate beliefs with `accept: true`, which produces `[ACCEPT]` markers — matching the old behavior where `auto_accept_proposals` would convert `[ACCEPT/REJECT]` to `[ACCEPT]` anyway.
---

## Summary

One actionable concern: **stale user-facing message in `cmd_accept_beliefs`** at `expert_build/propose.py:483`. The print statement still references the old `[ACCEPT/REJECT]` format:

```python
print("Edit the file and change [ACCEPT/REJECT] to [ACCEPT] for beliefs to keep.")
```

Should be updated to match the new workflow, e.g.:
```python
print("Edit the file and change [REJECT] to [ACCEPT] for beliefs to keep.")
```

Everything else — the prompt change, verdict logic, `auto_accept_proposals` expansion, and test coverage — is correct and well-integrated.

### SELF_REVIEW
LIMITATIONS: Could not run the test suite to confirm all existing tests still pass with the `_json_beliefs` default change (existing tests may assert on `[ACCEPT/REJECT]` markers that are no longer emitted). The observation data confirmed test file locations but I relied on the grep results to verify existing assertions rather than reading every test in full.
---

### FEATURE_REQUESTS
- Include the full test files (not just changed hunks) when test helpers like `_json_beliefs` are modified, so the reviewer can verify all existing callers still produce correct assertions against the new output format.
---
