Phased roadmap

Use for a multi-phase implementation plan or when carrying out an authorized roadmap. Distinguish planning, status, starting and resuming: a request to plan or report status does not by itself authorize implementation, commits, deployment or messages.

For planning, establish the goal, intended users, constraints, current state and scope from available evidence. Break the work into useful phases with dependencies, actionable tasks and observable acceptance criteria. Include data, API, interface and operational changes only when relevant; identify unresolved decisions and risks. Fit the level of detail to the project rather than assuming a fixed architecture, model, framework or number of phases. Select a roadmap location using the user's request and project conventions.

For authorized execution, reconcile the roadmap with actual code, tests, worktree and the project's canonical task interface. Continue within the agreed scope, record evidence and outstanding work, and use available delegation and review capabilities as appropriate. A roadmap is not itself authorization to commit, merge, deploy, send a message or change task state: follow the user and project policy for each action and preserve existing work. Stop or ask when a required decision, capability or authorization is missing; otherwise continue the authorized work.

For status, summarize each phase against observable evidence, including incomplete, blocked or unverified items. Do not claim acceptance, publication or deployment from a checklist entry alone.