dhpk-module-designlisted

# Module design Design the smallest deep module that makes the caller's next decision easy. Keep this guidance stack-neutral until the repository evidence selects a framework or language. ## Scope before scan Start with the user's named module, subsystem, or pain point. When no direction is named, use recent commit history to find the hot spots that keep changing and weight the exploration there. Do not propose deepening across the whole codebase before a real seam, caller, and near-term change are identified; this is the YAGNI filter for architecture work. ## Modes Select exactly one mode from `design`, `review`, `compare`, or `adversarial`; `design` is the default. In every mode, frame the question, constraints, scope, risks, and decision criteria before recommending a seam. - **Design** proposes a boundary for a new capability or change. - **Review** evaluates an existing boundary against callers, data flow, and failure modes. - **Compare** scores concrete alternatives against the named criteria rather than treating personal preference as evidence. - **Adversarial** forms an independent Proposal A and, only when explicitly requested, a blind Proposal B; run three bounded critique rounds by default and never more than five. Preserve material disagreement and stop with `unresolved disagreement` when the evidence does not support convergence. ## Optional second opinion The primary path uses only the current in-process model and does not invoke a second opini