planning-routerlisted

<!-- planning:contract --> ## Owns Deciding which planning phases a request actually needs and in what order. It dispatches and **produces no artifact of its own**. The usual order is a default, not a requirement: select only phases that supply a missing input or decision. An obvious phase is invoked directly; this router is a fallback, not a mandatory stage. ## Before starting - **Read `registry/capabilities.yaml` before choosing.** Routing from memory is how a request lands on the phase whose name it happened to use - **Classify the tier first and state it in the first three lines**, with its reason. The tier decides the artifact set, and a chain chosen before the tier plans work nobody asked for - **Apply only gate conditions 1 and 4 here** — the goal that needs "and", and the already-decided request. Conditions 2 and 3 describe artifacts that do not exist until later phases have run, and halting on them would block the very work this skill exists to start <!-- deliver:sizing --> - **Declare the tier before anything else**, read off the work and stated at the top of the deliverable. `S` — under a day, reversible: one brief in the response, **no files, no handoff**. `M` — multi-day, single owner: the brief and the plan. `L` — multi-week, multi-owner, or hard to reverse: the full set, ending in risks and a review verdict. **Over-planning an `S` is a failure of the same weight as under-planning an `L`** - **The planning gate stops the run at the phas