Task Breakdown & Scheduling Plan

There is a prompt instruction at https://www.zangwei.dev/prompts/product-execution/task-breakdown-scheduling-execution-plan-prompt . Extract and follow the prompt to create file /docs/handbook/product/{version|feature}/tasks.md

You are a senior Tech Lead / Project Lead. Create the **Task Breakdown & Scheduling Plan** for the current version.

## Positioning
The goal is not a "complete-looking" plan. It is to:
1) break requirements and technical solution into executable deliverables
2) make progress predictable, trackable, adjustable
3) expose dependencies and risks instead of hiding uncertainty

This document bridges "technical solution" -> "real execution".

## Preconditions
- PRD defines scope, acceptance, and boundaries
- Technical solution is confirmed (architecture, critical paths, risks)
- Planning covers only the current version/iteration

## General requirements
- Break down by deliverables, not by module names
- Every task must have a clear Owner
- Estimates can be uncertain, but uncertainty must be explicit
- Prioritize exposing dependencies and the critical path

---

## Output structure

1) Breakdown principles & assumptions
- Baseline assumptions (team size, parallelism, familiarity)
- Task granularity rule (suggested 0.5–3 days per task)
- Work explicitly out of scope (e.g., long-term refactor, future optimizations)

2) Task groups
Group by delivery goals or modules, e.g.:
- core feature implementation
- supporting capabilities
- testing & quality
- release & operations readiness

3) Detailed task list
For each task, specify:
- task name
- task description (what exactly will be done)
- group/module
- owner
- estimate (time range, with uncertainty)
- dependencies (what must be done first)
- outputs (code/config/docs/interfaces/tests)
- done definition

4) Critical path & parallelization
- Which tasks form the critical path?
- Which can run in parallel?
- Which delays would directly impact delivery?

5) Milestones & staged deliveries
- Milestones (dev complete / integration / QA pass / launch)
- Criteria for each milestone
- Mapping to acceptance criteria / success criteria

6) Risks & buffer
- Most uncertain tasks
- Where to add buffer
- If delayed, what can be cut or downgraded?

7) Communication & tracking
- How often progress updates happen (daily/weekly)
- Escalation path for blockers
- Who decides schedule changes and under what triggers

---

## Output requirements
- No code or deep implementation detail
- Schedule is an estimate, not a promise
- Must explicitly highlight uncertainty and risks
- If PRD/solution is not feasible in the timeline, call it out

End with 3–5 bullet points:
"Does this plan realistically reflect delivery capability and risk?"