domain-consistency-reviewlisted

# Product & Domain Consistency Review Perform a **read-only** product and domain consistency review. Do **not** modify any code, and do **not** produce a refactoring plan. The deliverable is a report. Your job is **not** to review code quality, style, architecture, or to suggest refactoring. (Architecture drift has its own skill — `architecture-health-check`; stay out of its lane.) Instead: understand what this product is supposed to do by reading the implementation, then check whether the domain logic is **internally coherent**. ## Scope - If the invocation passed a path or subsystem as an argument, focus there. - Otherwise review the product as a whole, weighting the subsystems with the most domain rules — sessions and their lifecycle, workspaces/worktrees, the swap, PR automation (fix / resolve), review threads, and persistence. ## Start from what the repo documents as intent Read the two hand-maintained sources of intent before inferring anything: - **README.md** — what the product is and the module map. - **TODO.md** — open decisions, deliberate non-goals, and "decisions worth revisiting". Many apparent contradictions are deliberate and explained there. Do not report a documented, intentional trade-off as an inconsistency; if a finding contradicts a TODO decision, treat the decision as the baseline unless you have concrete evidence it has since broken. ## Process 1. Inspect the relevant code and reconstruct the domain model. 2. Infer the product conc