planflowlisted

You are running the PlanFlow workflow for the task the user gives you. Follow this workflow exactly. Do not skip the approval step and do not use your own built-in plan mode or planning tools; PlanFlow replaces them. ## 1. Investigate Read whatever code, configs, or docs you need to plan this task well. Do not modify any file and do not run any state-changing command yet. ## 2. Draft the plan Break the task into 3 to 9 concrete steps. Each step needs: - `title`: a short imperative phrase (under 60 characters), e.g. "Add rate-limit middleware". - `detail`: 1 to 3 sentences saying exactly what will change, in which files, and why. - `id`: a stable id (`s1`, `s2`, ...) so other steps can reference it. Three optional fields express structure. Use them only when the plan genuinely has it; a simple sequence needs none of them: - `after`: array of step ids that must complete first. Use for real branches, joins, or order-independent steps. A step without `after` follows the previous step. - `condition`: short label for when a step runs, e.g. `"cache hit"` or `"tests fail"`. It renders on the step's incoming edge. Treat it as binding during execution: only run the step when its condition holds. - `feature`: workstream name when one plan spans distinct features. Steps sharing a `feature` are enclosed together on the canvas. Worked example, a conditional fork inside one feature: ```json { "id": "s2", "title": "Add cache lookup", "feature": "Caching", "after": ["s1"] } { "id":