akcli-deep-reviewlisted

# akcli-deep-review — you propose, akcli verifies The deterministic detectors have breadth (39 rules); you have depth — you can read datasheets, understand design intent, and spot problems no topology pattern expresses. The contract that keeps that power honest: **every claim you make goes through `akcli review validate` before anyone calls it a finding.** Four gates (schema, anchor existence, datasheet evidence, deterministic-rule masquerade); failures land in `quarantined[]` with reasons. Accepted candidates are `llm_reviewed` **observations** — they never block a release, never override a deterministic finding, never auto-create a contract. ## Candidate discipline (the four gates, from your side) 1. **Anchor everything (G2).** Every candidate carries `anchors` naming real entities: `{"kind": "component", "id": "U3"}`, `{"kind": "net", "id": "VBUS"}`, `{"kind": "pin", "id": "U3.7"}`. Check they exist first (`akcli component board.kicad_sch U3`, `akcli net board.kicad_sch VBUS`) — a ghost anchor quarantines the whole candidate. An observation you cannot anchor is not a finding; drop it or ask the user. 2. **Own namespace, own humility (G1, G4).** Codes are `REVIEW_LLM_<TOPIC>` — never a registered deterministic code (that is masquerade and gets quarantined). Do not set `confidence` (the gate stamps `llm_reviewed`) and do not pre-set `status`. 3. **Datasheet claims cite the store (G3).** If a candidate leans on a datasheet number, its `evidence.d