Develop: Refactor Plan

Audit the current codebase against docs/PRD.md, review the differences with the user, and write a phased refactor plan to docs/REFACTOR.md. Do not write the plan until the review in step 2 is complete. If docs/PRD.md is missing, do not stop — generate the refactor-scoped PRD first (step 0 below), then continue as normal.

0. No docs/PRD.md? Generate the refactor PRD

Members refactoring an existing app don't need the full studio-develop-prd-roadmap interview — the app already answers most of its questions. Derive a refactor-scoped PRD instead:

1. Read docs/PRODUCT.md and docs/DESIGN.md in full (they're required by this phase; if either is missing, run its fast-track producer first — studio-define-from-code → studio-define-product, or studio-design-design-system-from-code).
2. Explore the codebase: structure, stack, data models, screens, auth/payment integrations — what the app is today.
3. Interview the user briefly, drawing on productos/develop/guides/PRD-GENERATION.md and TECH-STACK-OPTIONS.md: the core loop, what the refactored app must do that today's doesn't, what today's does that should go, and the target stack (confirm or change).
4. Write docs/PRD.md — the target state of this product, in the standard PRD shape, opening with the note > Refactor-scoped PRD, generated by studio-develop-refactor-plan from PRODUCT.md, DESIGN.md, the existing codebase, and the member's decisions. Spec what exists-and-stays, what changes, and what's added; skip from-scratch MVP scoping that doesn't apply.

No separate docs/ROADMAP.md is needed on this path — docs/REFACTOR.md (step 3) is the executable plan, and its format below stands alone. Later feature work reads the PRD as usual.

1. Audit the codebase against the PRD

Read both spec documents in full, then explore the repository: structure, dependencies, data models, API surface, screens, and auth/payment integrations. Build a complete list of differences, classified as: