claude-sonnet-5 review: Phase 4 (by gpt-5.3-codex)

.github/skills/python-code-reviewer/skill.md

@@ -29,12 +29,13 @@ Perform thorough, evidence-based code reviews for Python projects. Every finding
 2. **Establish Canonical Authority First:** Read architecture/contracts (`docs/ver4/*`, `docs/invariant/*`, UI docs) and active instructions/skills before evaluating source behavior.
 3. **Read Representative Modules:** Sample across all layers (routes/pages, UI components, services, workers, persistence, provider adapters, settings, tests) before drawing conclusions.
 4. **Run Drift Analysis:** Compare documented intended behavior versus repository ground truth; identify both implementation drift and undocumented-but-repeatable conventions that should be formalized.
-5. **Assess Boundary and Coupling Health:** Evaluate UI/service/persistence/provider dependency flow, identify circular dependencies, leaky abstractions, and transaction ownership ambiguity.
-6. **Assess Invariant Placement:** For each hard rule, decide whether it belongs in docs (rationale), instructions (active steering), skills (periodic audit procedure), or deterministic tests (enforcement).
-7. **Verify Claims:** Run or reference project tooling (`ruff check`, `ty`, `pytest`) rather than guessing.
-8. **Prioritize Hot Paths:** Focus deeply on request handling, database sessions, background workers, and external API calls.
-9. **Enforce Read-Only Safety:** Do not modify code unless explicitly instructed.
-10. **Escalate Provenance Audits:** For evidence/provenance-heavy changes, apply invariant checks from `.github/skills/evidence-provenance-auditor/skill.md` and include pass/fail outcomes in the report.
+5. **Run Dead-Code/Orphan Sweep:** Identify candidate orphan modules/functions/classes with zero inbound references, then verify expected exceptions (entrypoints, framework/plugin registration, dynamic imports/reflection, CLI hooks, test-only utilities) before marking as orphaned.
+6. **Assess Boundary and Coupling Health:** Evaluate UI/service/persistence/provider dependency flow, identify circular dependencies, leaky abstractions, and transaction ownership ambiguity.
+7. **Assess Invariant Placement:** For each hard rule, decide whether it belongs in docs (rationale), instructions (active steering), skills (periodic audit procedure), or deterministic tests (enforcement).
+8. **Verify Claims:** Run or reference project tooling (`ruff check`, `ty`, `pytest`) rather than guessing.
+9. **Prioritize Hot Paths:** Focus deeply on request handling, database sessions, background workers, and external API calls.
+10. **Enforce Read-Only Safety:** Do not modify code unless explicitly instructed.
+11. **Escalate Provenance Audits:** For evidence/provenance-heavy changes, apply invariant checks from `.github/skills/evidence-provenance-auditor/skill.md` and include pass/fail outcomes in the report.
 
 ## Repo-Specific Deterministic Checks (Transcription)
 
@@ -49,6 +50,7 @@ When reviewing this repository, always include explicit pass/fail checks for:
 7. **Media boundary conformance:** print/export media is record-validated and UI media URL generation uses controlled resolver paths.
 8. **Eager-loading conformance:** service/UI read paths satisfy `lazy="raise"` expectations.
 9. **Cross-cutting error conformance:** service/API/UI translation and retry behavior align with `.github/instructions/error-handling.instructions.md`.
+10. **Orphaned/dead-code conformance:** include a deterministic orphan sweep and report confirmed orphans removed/retained with rationale.
 
 ## Core Review Areas
 
@@ -93,7 +95,12 @@ When reviewing this repository, always include explicit pass/fail checks for:
 ### 9. Duplication & Consolidation
 - Identify repeated code blocks, candidate helper abstractions, divergent patterns for identical operations, and duplicated domain constants.
 
-### 10. Architecture & Governance
+### 10. Orphaned/Dead Code Audit
+- Find candidate orphan modules/functions/classes with no inbound references.
+- Validate each candidate against dynamic wiring exceptions (entrypoints, plugin registration, reflection/dynamic imports, CLI hooks, test utilities).
+- Report outcomes as: removed orphan, retained-with-justification, or uncertain-follow-up.
+
+### 11. Architecture & Governance
 - **Architectural Drift:** Compare intended architecture rules against implementation behavior and cite concrete drift points.
 - **Systemic Health:** Evaluate domain cohesion, dependency direction, lifecycle consistency, and operational reliability seams.
 - **Invariant Routing:** Recommend the correct enforcement layer per rule (docs vs instructions vs skills vs tests).