holoctl-parallel-evaluatorlisted

# Parallel evaluator — decide single vs batch before creating tickets Run this evaluation any time you're about to call the boardmaster (`/ticket`, or implicitly when the user announces work). The boardmaster will repeat the check, but doing it here means the decomposition arrives **pre-formed** rather than the boardmaster having to derive it from scratch. ## Decision Ask yourself: *can this work split into N pieces that touch **disjoint files** and have **independent acceptance** (no piece's DoD references another's output)?* - **Yes (N ≥ 2)** → propose batch with the file partition. - **No** → single ticket. - **Unsure** → present both options to the user with the candidate decomposition pre-formed. Never push the decomposition work back. ## Signals for batch - Pedido has factored conjunctions: "add X **and** Y", "implement A, B, **and** C", "fix bugs in foo **and** bar". - Modular structure exists: separate packages/layers/modules. - DoD naturally fragments into implement / test / document, on different files. ## Signals against batch (=> single) - Refactor that rewrites a structure (renaming across the codebase, lifting an abstraction). - Acceptance only makes sense if all pieces snap together (cross-cutting changes). - Pedido is explicitly "small change", "quick fix", "one-liner". - Fewer than 3 identifiable files to touch. ## How to present If you're calling the boardmaster: ``` Boardmaster: decompose request "{user_request}" into single OR batch. Candidate b