lens-cataloglisted

# Lens Catalog A lens is one reviewer's single perspective. The orchestrator selects 3–6 lenses per round; the two core lenses are always on. Panel composition and selection rationale are logged in the sidecar every round. ## Roster (v1) ### Lens: internal-consistency (core) Mandate: contradictions between the spec's own sections — nothing else. ### Lens: ambiguity-testability (core) Mandate: requirements readable two ways by competent implementers, and acceptance criteria that cannot be checked — nothing else. ### Lens: completeness Mandate: could a developer write the implementation plan without coming back with design questions? Missing load-bearing design decisions only. Never demand implementation-plan detail; never report gaps the spec explicitly delegates or defers. ### Lens: feasibility Mandate: can the platform actually deliver each claimed behavior? Verify against the repository (this lens may read the repo); a mechanism the reference implementations already demonstrate refutes the finding. ### Lens: doctrine-compliance Mandate: audit the spec against the loop-engineering bar **restated below** — it is reproduced here in full because the reviewer agent has no `Skill` tool and cannot load a cross-plugin skill; a lens that silently reconstructs the bar from memory would grade against invented criteria and still return valid JSON, which Coverage would score as a clean pass. Report one finding per unmet item, citing the item number. Select only for specs that des