run-tasklisted

# Run target-milestone task cards <HARD-GATE>Every executed Task must exist in an accepted `Task.md`, belong to the initiated `target_milestone_id`, and have valid Requirement, Design, applicable Contract, and structural- authority anchors. If preparing or implementing it still requires a product, architecture, interface, data, error, state, recovery, security, or compatibility decision, do not let a Runner or Coder decide it: pause only the impact cone and send the evidence through a Commander, which invokes the owning Skill inside the same bounded matter. Never expose an unreviewed or unchecked implementation combination as the shared baseline. For RED-gated work, the Coder records a valid production-unchanged RED checkpoint against unchanged behavior before production implementation; no separate approval of that checkpoint is required.</HARD-GATE> This stage requires the Commander-and-Runner hub-and-spoke flow. When instructed to advance `run-task`, the primary orchestrator does not first read and analyze the ready set. It creates one Commander with the Owner instruction, repository, and observable entry points. The Commander reads current authority and state, computes the dependency-aware ready set, and returns the number of Runners to create plus each complete Runner brief. The primary orchestrator mechanically creates those Runners without rewriting their briefs. A Commander may directly create any defined named Agent that the current workflow assigns to it. The norm