jumpstart-mode 1.0.5 → 1.0.7

package/.jumpstart/commands/commands.md

@@ -26,15 +26,17 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 
 **Pre-conditions:** None. This is the entry point of the workflow.
 
-**Behaviour:**
+**Behavior:**
 1. Load the Challenger agent persona from `.jumpstart/agents/challenger.md`.
-2. If the human provided an initial statement, use it as Step 1 input.
-3. If no statement was provided, prompt the human to describe their idea or problem.
-4. Follow the Challenger's Elicitation Protocol (Steps 1-8).
-5. Populate `specs/challenger-brief.md` using the template.
-6. Create and maintain `specs/insights/challenger-brief-insights.md` documenting key reasoning and alternatives considered.
-7. Present the brief for human approval.
-8. On approval, update `config.yaml` to set `current_phase: 0` and mark the gate as passed.
+2. If `project.approver` is empty in config, ask the human for their name and save it.
+3. If the human provided an initial statement, use it as Step 1 input.
+4. If no statement was provided, prompt the human to describe their idea or problem.
+5. Follow the Challenger's Elicitation Protocol (Steps 1-8).
+6. Populate `specs/challenger-brief.md` using the template.
+7. Create and maintain `specs/insights/challenger-brief-insights.md` documenting key reasoning and alternatives considered.
+8. Present the brief for human approval.
+9. On approval, fill in Phase Gate (checkboxes, approver name, date), update `config.yaml` to set `current_phase: 0`.
+10. Automatically hand off to Phase 1.
 
 ---
 
@@ -61,7 +63,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 - `specs/challenger-brief.md` must exist and be approved.
 - If the pre-condition is not met, display: "Phase 0 must be completed first. Run `/jumpstart.challenge` to begin."
 
-**Behaviour:**
+**Behavior:**
 1. Verify pre-conditions.
 2. Load the Analyst agent persona from `.jumpstart/agents/analyst.md`.
 3. Read `specs/challenger-brief.md` and `.jumpstart/config.yaml`.
@@ -69,7 +71,8 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 5. Populate `specs/product-brief.md` using the template.
 6. Create and maintain `specs/insights/product-brief-insights.md` documenting key reasoning and alternatives considered.
 7. Present the brief for human approval.
-8. On approval, update `config.yaml` to set `current_phase: 1` and mark the gate as passed.
+8. On approval, fill in Phase Gate (checkboxes, approver name, date), update `config.yaml` to set `current_phase: 1`.
+9. Automatically hand off to Phase 2.
 
 ---
 
@@ -84,7 +87,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 **Description:** Generate the Product Requirements Document from the approved Product Brief. The PM agent defines epics, writes user stories with acceptance criteria, specifies non-functional requirements, and structures implementation milestones.
 
 **VS Code Chat Features:**
-- If `vscode_tools.use_todo_lists` is enabled, track progress through the 9-step Planning Protocol
+- If `vscode_tools.use_todo_lists` is enabled, track progress through the 10-step Planning Protocol
 - Particularly useful when decomposing many epics into stories—shows which epics are complete
 - If `use_ask_questions` is enabled, use for epic validation and prioritization discussions
 
@@ -98,15 +101,16 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 - `specs/product-brief.md` must exist and be approved.
 - If pre-conditions are not met, display which phases are incomplete.
 
-**Behaviour:**
+**Behavior:**
 1. Verify pre-conditions.
 2. Load the PM agent persona from `.jumpstart/agents/pm.md`.
 3. Read `specs/challenger-brief.md`, `specs/product-brief.md`, and `.jumpstart/config.yaml`.
-4. Follow the PM's Planning Protocol (Steps 1-9).
+4. Follow the PM's Planning Protocol (Steps 1-10).
 5. Populate `specs/prd.md` using the template.
 6. Create and maintain `specs/insights/prd-insights.md` documenting key reasoning and alternatives considered.
 7. Present the PRD for human approval.
-8. On approval, update `config.yaml` to set `current_phase: 2` and mark the gate as passed.
+8. On approval, fill in Phase Gate (checkboxes, approver name, date), update `config.yaml` to set `current_phase: 2`.
+9. Automatically hand off to Phase 3.
 
 ---
 
@@ -141,7 +145,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 - `specs/prd.md` must exist and be approved.
 - If pre-conditions are not met, display which phases are incomplete.
 
-**Behaviour:**
+**Behavior:**
 1. Verify pre-conditions.
 2. Load the Architect agent persona from `.jumpstart/agents/architect.md`.
 3. Read all preceding spec files and `.jumpstart/config.yaml`.
@@ -150,7 +154,8 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 6. Create ADR files in `specs/decisions/` using the ADR template.
 7. Create and maintain `specs/insights/architecture-insights.md` documenting key reasoning and alternatives considered.
 8. Present both documents for human approval.
-9. On approval, update `config.yaml` to set `current_phase: 3` and mark the gate as passed.
+9. On approval, fill in Phase Gate (checkboxes, approver name, date), update `config.yaml` to set `current_phase: 3`.
+10. Automatically hand off to Phase 4.
 
 ---
 
@@ -182,7 +187,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
   - `specs/implementation-plan.md`
 - If pre-conditions are not met, display which phases are incomplete.
 
-**Behaviour:**
+**Behavior:**
 1. Verify pre-conditions.
 2. Load the Developer agent persona from `.jumpstart/agents/developer.md`.
 3. Read all spec files and `.jumpstart/config.yaml`.
@@ -190,7 +195,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 5. Update `specs/implementation-plan.md` with task completion status as work progresses.
 6. Create and maintain `specs/insights/implementation-plan-insights.md` documenting implementation decisions and problem-solving approaches.
 7. On completion of all milestones, present the final summary to the human.
-8. Update `config.yaml` to set `current_phase: 4`.
+8. On approval, fill in Phase Gate (checkboxes, approver name, date), update `config.yaml` to set `current_phase: 4`.
 
 ---
 
@@ -206,7 +211,7 @@ This file defines the slash commands that drive the Jump Start workflow. Each co
 /jumpstart.status
 ```
 
-**Behaviour:**
+**Behavior:**
 1. Read `.jumpstart/config.yaml` for `current_phase`.
 2. Check which spec files exist and their approval status.
 3. If Phase 4 is in progress, read `specs/implementation-plan.md` for task completion counts.
@@ -251,7 +256,7 @@ Next action: Run [/jumpstart.command] to continue.
 /jumpstart.review
 ```
 
-**Behaviour:**
+**Behavior:**
 1. Determine the current phase from `config.yaml`.
 2. Read the relevant artifact(s) for that phase.
 3. Compare against the template to identify:
@@ -278,7 +283,7 @@ Next action: Run [/jumpstart.command] to continue.
 /jumpstart.insights developer
 ```
 
-**Behaviour:**
+**Behavior:**
 1. Read files from `specs/insights/` directory.
 2. If a phase filter is provided (challenger, analyst, pm, architect, developer), show only insights for that phase.
 3. Otherwise, show all insights files in chronological order with phase categories.
@@ -306,5 +311,5 @@ Next action: Run [/jumpstart.command] to continue.
 /jumpstart.help
 ```
 
-**Behaviour:**
+**Behavior:**
 Display the command reference with current availability based on workflow state. Commands whose pre-conditions are not met should be shown as unavailable with a note on what must be completed first.

package/.jumpstart/config.yaml

@@ -1,7 +1,7 @@
 # ============================================================================
 # Jump Start Framework Configuration
 # ============================================================================
-# This file controls the behaviour of the Jump Start agentic coding workflow.
+# This file controls the behavior of the Jump Start agentic coding workflow.
 # Edit values below to customise the framework for your project.
 # ============================================================================
 
@@ -9,6 +9,7 @@ project:
   name: ""                              # Your project name (populated by `jumpstart init`)
   description: ""                       # One-line project description
   created_at: ""                        # ISO date, auto-populated
+  approver: ""                          # Name of the human approver (captured during first phase gate)
 
 # ---------------------------------------------------------------------------
 # Workflow Settings
@@ -17,6 +18,8 @@ workflow:
   require_gate_approval: true           # Require explicit human approval between phases
   auto_commit_artifacts: false          # Auto-commit spec files to git after generation
   allow_phase_skip: false               # If true, allows jumping to a later phase
+  auto_handoff: true                    # Automatically proceed to next phase after approval
+  archive_on_restart: true               # Archive existing artifacts before regenerating (rename with date suffix)
   current_phase: null                   # Tracks active phase (0-4), managed by framework
 
 # ---------------------------------------------------------------------------
@@ -28,9 +31,9 @@ agents:
     persona_file: "agents/challenger.md"
     capture_insights: true              # Capture decision rationale and alternatives considered
     elicitation_depth: standard         # quick | standard | deep
-    #   quick:    3 assumption checks, 3 Whys, minimal stakeholder mapping
-    #   standard: 5-7 assumption checks, 5 Whys, full stakeholder map
-    #   deep:     10+ assumption checks, 5 Whys with branching, stakeholder
+    #   quick:    3 assumption checks, linear root cause analysis (approx 3 layers), minimal stakeholder mapping
+    #   standard: 5-7 assumption checks, recursive root cause analysis (drill until root found, usually ~5 layers), full stakeholder map
+    #   deep:     10+ assumption checks, multi-branch root cause analysis (Ishikawa/Fishbone style), stakeholder
     #             interviews simulation, competitive problem framing
     max_assumptions: 10                 # Cap on surfaced assumptions
     require_reframe: true               # Force at least one problem reframe
@@ -88,7 +91,7 @@ agents:
 # Integration Settings
 # ---------------------------------------------------------------------------
 integrations:
-  ai_assistant: "copilot"              # copilot | claude-code | cursor | gemini | windsurf
+  ai_assistant: "copilot"              # copilot | claude-code | cursor | gemini | windsurf | codex
   git_branch_per_phase: false           # Create a branch for each phase
   branch_naming: "jumpstart/phase-{n}-{name}"  # Branch name template
 

package/.jumpstart/templates/architecture.md

@@ -6,9 +6,9 @@
 > **Created:** [DATE]
 > **Approved:** [DATE or pending]
 > **Upstream References:**
-> - [specs/challenger-brief.md](../challenger-brief.md)
-> - [specs/product-brief.md](../product-brief.md)
-> - [specs/prd.md](../prd.md)
+> - [specs/challenger-brief.md](challenger-brief.md)
+> - [specs/product-brief.md](product-brief.md)
+> - [specs/prd.md](prd.md)
 
 ---
 
@@ -245,8 +245,8 @@ Push to branch
 
 | ADR | Title | Status | File |
 |-----|-------|--------|------|
-| ADR-001 | [Decision title] | Accepted | [specs/decisions/001-short-title.md](../decisions/001-short-title.md) |
-| ADR-002 | [Decision title] | Accepted | [specs/decisions/002-short-title.md](../decisions/002-short-title.md) |
+| ADR-001 | [Decision title] | Accepted | [specs/decisions/001-short-title.md](decisions/001-short-title.md) |
+| ADR-002 | [Decision title] | Accepted | [specs/decisions/002-short-title.md](decisions/002-short-title.md) |
 
 [List all ADRs. Full content lives in individual files in specs/decisions/.]
 
@@ -272,7 +272,7 @@ Push to branch
 
 ## Insights Reference
 
-**Companion Document:** [specs/insights/architecture-insights.md](../insights/architecture-insights.md)
+**Companion Document:** [specs/insights/architecture-insights.md](insights/architecture-insights.md)
 
 This artifact was informed by ongoing insights captured during Solutioning. Key insights that shaped this document:
 

package/.jumpstart/templates/challenger-brief.md

@@ -36,18 +36,25 @@
 
 **Starting point:** [The core problem extracted from the original statement]
 
-| Level | Question | Answer |
-|-------|----------|--------|
-| Why 1 | Why does this problem exist? | [Human's answer] |
-| Why 2 | Why does [answer to Why 1] happen? | [Human's answer] |
-| Why 3 | Why does [answer to Why 2] happen? | [Human's answer] |
-| Why 4 | Why does [answer to Why 3] happen? | [Human's answer] |
-| Why 5 | Why does [answer to Why 4] happen? | [Human's answer] |
+> **Method:** Ask "Why?" until the root cause is revealed. This may take fewer or more than 5 iterations. Ensure the logic holds by checking backwards: "Root Cause > therefore > ... > Problem."
 
-**Root cause identified:** [Summary of the deepest cause reached]
+**Analysis Chain:**
 
-**Alternative threads noted (if any):**
-- [Branch point and alternative direction not pursued]
+1. **Why?** [Answer 1]
+2. **Why?** [Answer 2]
+3. **Why?** [Answer 3]
+4. **Why?** [Answer 4]
+5. **Why?** [Answer 5 - add or remove steps as needed to reach root cause]
+
+**Logic Check (Working Backwards):**
+> [Root Cause] **therefore** [Answer N-1] ... **therefore** [Original Problem].
+> *Does this chain of causality make logical sense without logical leaps?*
+
+**Root Cause Identified:**
+> [Summary of the deepest cause reached]
+
+**Alternative branches (if any):**
+- [Branch point] -> [Alternative root cause]
 
 ---
 
@@ -85,7 +92,7 @@ How will we know the problem has been solved?
 
 | # | Criterion | Type | Measurable? |
 |---|-----------|------|------------|
-| 1 | [Outcome-based success criterion, solution-agnostic] | Behavioural / Metric / Qualitative | Yes / Needs refinement |
+| 1 | [Outcome-based success criterion, solution-agnostic] | Behavioral / Metric / Qualitative | Yes / Needs refinement |
 | 2 | | | |
 | 3 | | | |
 
@@ -111,7 +118,7 @@ How will we know the problem has been solved?
 
 ## Insights Reference
 
-**Companion Document:** [specs/insights/challenger-brief-insights.md](../insights/challenger-brief-insights.md)
+**Companion Document:** [specs/insights/challenger-brief-insights.md](insights/challenger-brief-insights.md)
 
 This artifact was informed by ongoing insights captured during Problem Discovery. Key insights that shaped this document:
 

package/.jumpstart/templates/implementation-plan.md

@@ -6,8 +6,8 @@
 > **Created:** [DATE]
 > **Approved:** [DATE or pending]
 > **Upstream References:**
-> - [specs/prd.md](../prd.md)
-> - [specs/architecture.md](../architecture.md)
+> - [specs/prd.md](prd.md)
+> - [specs/architecture.md](architecture.md)
 
 ---
 
@@ -200,7 +200,7 @@ Document any deviations from the original plan during implementation.
 
 ## Insights Reference
 
-**Companion Document:** [specs/insights/implementation-plan-insights.md](../insights/implementation-plan-insights.md)
+**Companion Document:** [specs/insights/implementation-plan-insights.md](insights/implementation-plan-insights.md)
 
 This artifact was informed by ongoing insights captured during Solutioning and Implementation. Key insights that shaped this document:
 

package/.jumpstart/templates/insights.md

@@ -2,7 +2,7 @@
 
 > **Phase:** [0-4] -- [Phase Name]
 > **Agent:** [Agent Name]
-> **Parent Artifact:** [`specs/[artifact-name].md`](specs/[artifact-name].md)
+> **Parent Artifact:** [`specs/[artifact-name].md`](../[artifact-name].md)
 > **Created:** [DATE]
 > **Last Updated:** [DATE]
 
@@ -49,9 +49,9 @@ You can record different kinds of insights. Here are some common types, but don'
 When an insight relates to a specific section of the parent artifact, link to it:
 
 ```markdown
-→ See [Problem Statement](specs/challenger-brief.md#reframed-problem-statement)
-→ Related to [User Persona 2](specs/product-brief.md#user-personas)
-→ Influences [Architecture Decision 003](specs/decisions/003-api-design.md)
+→ See [Problem Statement](../challenger-brief.md#reframed-problem-statement)
+→ Related to [User Persona 2](../product-brief.md#user-personas)
+→ Influences [Architecture Decision 003](../decisions/003-api-design.md)
 ```
 
 ### Timestamps
@@ -122,8 +122,8 @@ During assumption surfacing, the human initially framed the problem as "develope
 This realization shifted the problem from "ongoing inefficiency" to "high-friction project initialization." The scope and solution implications are very different.
 
 **Cross-references:**
-- [Assumption #3](specs/challenger-brief.md#assumptions-identified) captured this shift
-- [Reframed Problem Statement](specs/challenger-brief.md#reframed-problem-statement) now focuses on "project setup friction"
+- [Assumption #3](../challenger-brief.md#assumptions-identified) captured this shift
+- [Reframed Problem Statement](../challenger-brief.md#reframed-problem-statement) now focuses on "project setup friction"
 
 ---
 
@@ -140,7 +140,7 @@ The human chose to follow the organizational path, which revealed that the root
 I noted the tooling branch as "Alternative thread" in the brief—it might resurface during architecture phase.
 
 **Cross-references:**
-- [Root Cause Analysis](specs/challenger-brief.md#root-cause-analysis-five-whys)
+- [Root Cause Analysis](../challenger-brief.md#root-cause-analysis-five-whys)
 
 ---
 
@@ -157,8 +157,8 @@ While synthesizing interview notes (simulated), I noticed a third distinct behav
 This persona has inverse priorities: they *want* more friction at setup to ensure compliance. Including them changes the requirements—solution needs configuration/policy layer, not just speed.
 
 **Cross-references:**
-- Added as [Persona 3: Platform Engineer](specs/product-brief.md#user-personas)
-- Impacts [Feature Priority](specs/product-brief.md#feature-prioritization)—audit/compliance features elevated
+- Added as [Persona 3: Platform Engineer](../product-brief.md#user-personas)
+- Impacts [Feature Priority](../product-brief.md#feature-prioritization)—audit/compliance features elevated
 
 ---
 
@@ -175,7 +175,7 @@ This could be a meaningful differentiation point—not just templates, but *opin
 Noted as open question for PM phase to address with proposed value prop testing.
 
 **Cross-references:**
-- [Competitive Analysis](specs/product-brief.md#competitive-landscape)
+- [Competitive Analysis](../product-brief.md#competitive-landscape)
 
 ---
 
@@ -197,8 +197,8 @@ Decision: defer all advanced customization to v2. MVP will be opinionated by def
 Trade-off acknowledged: loses Platform Engineer as primary MVP audience. They become secondary (can still use, but won't get custom policy enforcement).
 
 **Cross-references:**
-- [MVP Scope](specs/prd.md#mvp-scope)
-- [Persona 3 deprioritized rationale](specs/prd.md#out-of-scope)
+- [MVP Scope](../prd.md#mvp-scope)
+- [Persona 3 deprioritized rationale](../prd.md#out-of-scope)
 
 ---
 
@@ -215,7 +215,7 @@ Problem: "active" is vague. Active in what sense? Commits? Deploys? Team still e
 Alternative: "Users report 50% reduction in setup time" (survey-based, direct). Suggested we use both: time saved (short-term) and project longevity (long-term quality signal).
 
 **Cross-references:**
-- [Success Metrics](specs/prd.md#success-metrics)—now includes both
+- [Success Metrics](../prd.md#success-metrics)—now includes both
 
 ---
 
@@ -243,8 +243,8 @@ Reasoning:
 Trade-off: Hard to add community-contributed templates without code changes. Acceptable for MVP.
 
 **Cross-references:**
-- [Architecture Decision Record 004](specs/decisions/004-template-storage.md)
-- [Component: Template Engine](specs/architecture.md#component-template-engine)
+- [Architecture Decision Record 004](../decisions/004-template-storage.md)
+- [Component: Template Engine](../architecture.md#component-template-engine)
 
 ---
 
@@ -266,8 +266,8 @@ Options:
 Chose #1 + note to revisit in developer phase. Flagged as performance testing requirement in implementation plan.
 
 **Cross-references:**
-- [Performance Requirements](specs/architecture.md#non-functional-requirements)
-- [Implementation Task: Optimize File I/O](specs/implementation-plan.md#phase-1-tasks)
+- [Performance Requirements](../architecture.md#non-functional-requirements)
+- [Implementation Task: Optimize File I/O](../implementation-plan.md#phase-1-tasks)
 
 ---
 
@@ -310,7 +310,7 @@ Trade-off: if we expand CLI to 10+ commands later, we might regret this. For MVP
 
 **Cross-references:**
 - [Implementation: CLI module](src/cli.js)
-- [Dependency Justification](specs/architecture.md#external-dependencies)—updated to remove yargs
+- [Dependency Justification](../architecture.md#external-dependencies)—updated to remove yargs
 
 ---
 

package/.jumpstart/templates/prd.md

@@ -6,8 +6,8 @@
 > **Created:** [DATE]
 > **Approved:** [DATE or pending]
 > **Upstream References:**
-> - [specs/challenger-brief.md](../challenger-brief.md)
-> - [specs/product-brief.md](../product-brief.md)
+> - [specs/challenger-brief.md](challenger-brief.md)
+> - [specs/product-brief.md](product-brief.md)
 
 ---
 
@@ -180,6 +180,162 @@ _Alternative checklist format (if configured):_
 
 ---
 
+## Task Breakdown
+
+> **Purpose:** Decompose user stories into actionable development tasks for the Developer agent (Phase 4). This section bridges requirements and implementation.
+
+**Format:** `[Task ID] [P?] [Story] Description`
+- **[P]**: Can run in parallel (different files, no dependencies)
+- **[Story]**: Which user story this task belongs to (e.g., E1-S1, E2-S3)
+
+**Path Conventions:** Adjust paths based on project structure:
+- Single project: `src/`, `tests/`
+- Web app: `backend/src/`, `frontend/src/`
+- Mobile: `api/src/`, `mobile/src/`
+
+---
+
+### Phase 1: Setup (Shared Infrastructure)
+
+**Purpose:** Project initialization and basic structure
+
+- [ ] T001 Create project structure per implementation plan
+- [ ] T002 Initialize [language] project with [framework] dependencies
+- [ ] T003 [P] Configure linting and formatting tools
+- [ ] T004 [P] Setup environment configuration management
+
+---
+
+### Phase 2: Foundational (Blocking Prerequisites)
+
+**Purpose:** Core infrastructure that MUST be complete before ANY user story implementation
+
+**⚠️ CRITICAL:** No user story work can begin until this phase is complete
+
+- [ ] T005 Setup database schema and migrations framework
+- [ ] T006 [P] Implement authentication/authorization framework
+- [ ] T007 [P] Setup API routing and middleware structure
+- [ ] T008 Create base models/entities that all stories depend on
+- [ ] T009 Configure error handling and logging infrastructure
+
+**Checkpoint:** ☐ Foundation ready - user story implementation can now begin
+
+---
+
+### Phase 3: Story E1-S1 - [Story Title] (Priority: Must Have)
+
+**Goal:** [Brief description of what this story delivers]
+**Independent Test:** [How to verify this story works on its own]
+
+#### Tests for E1-S1 (Include if tests requested)
+
+> **NOTE:** Write tests FIRST, ensure they FAIL before implementation
+
+- [ ] T010 [P] [E1-S1] Contract test for [endpoint] in `tests/contract/test_[name].[ext]`
+- [ ] T011 [P] [E1-S1] Integration test for [user journey] in `tests/integration/test_[name].[ext]`
+
+#### Implementation for E1-S1
+
+- [ ] T012 [P] [E1-S1] Create [Entity] model in `src/models/[entity].[ext]`
+- [ ] T013 [E1-S1] Implement [Service] in `src/services/[service].[ext]` (depends on T012)
+- [ ] T014 [E1-S1] Implement [endpoint/feature] in `src/[location]/[file].[ext]`
+- [ ] T015 [E1-S1] Add validation and error handling
+- [ ] T016 [E1-S1] Add logging for story operations
+
+**Checkpoint:** ☐ Story E1-S1 fully functional and independently testable
+
+---
+
+### Phase 4: Story E1-S2 - [Story Title] (Priority: Must Have)
+
+**Goal:** [Brief description]
+**Independent Test:** [How to verify this story works on its own]
+
+#### Tests for E1-S2 (Include if tests requested)
+
+- [ ] T017 [P] [E1-S2] Contract test for [endpoint] in `tests/contract/test_[name].[ext]`
+- [ ] T018 [P] [E1-S2] Integration test in `tests/integration/test_[name].[ext]`
+
+#### Implementation for E1-S2
+
+- [ ] T019 [P] [E1-S2] Create [Entity] model in `src/models/[entity].[ext]`
+- [ ] T020 [E1-S2] Implement [Service] in `src/services/[service].[ext]`
+- [ ] T021 [E1-S2] Implement [endpoint/feature] in `src/[location]/[file].[ext]`
+- [ ] T022 [E1-S2] Integrate with E1-S1 components (if needed)
+
+**Checkpoint:** ☐ Stories E1-S1 AND E1-S2 both work independently
+
+---
+
+<!-- TEMPLATE NOTE: Repeat Phase blocks for each user story -->
+<!-- Organize by priority: Must Have → Should Have → Could Have -->
+<!-- Each story should be independently implementable and testable -->
+
+---
+
+### Phase N: Polish & Cross-Cutting Concerns
+
+**Purpose:** Improvements that affect multiple user stories
+
+- [ ] TXXX [P] Documentation updates in `docs/`
+- [ ] TXXX Code cleanup and refactoring
+- [ ] TXXX Performance optimization across all stories
+- [ ] TXXX [P] Additional unit tests (if requested) in `tests/unit/`
+- [ ] TXXX Security hardening
+
+---
+
+### Dependencies & Execution Order
+
+#### Phase Dependencies
+
+```
+Setup (Phase 1)
+    ↓
+Foundational (Phase 2) ← BLOCKS all user stories
+    ↓
+User Stories (Phase 3+) → Can proceed in parallel or sequentially by priority
+    ↓
+Polish (Phase N)
+```
+
+#### Within Each User Story
+
+1. Tests (if included) MUST be written and FAIL before implementation
+2. Models before services
+3. Services before endpoints
+4. Core implementation before integration
+5. Story complete before moving to next priority
+
+#### Parallel Opportunities
+
+- All Setup tasks marked [P] can run in parallel
+- All Foundational tasks marked [P] can run in parallel
+- Once Foundational completes, all user stories can start in parallel
+- Models within a story marked [P] can run in parallel
+- Tests within a story marked [P] can run in parallel
+
+---
+
+### Implementation Strategy
+
+#### MVP First (Highest Priority Stories Only)
+
+1. Complete Phase 1: Setup
+2. Complete Phase 2: Foundational (CRITICAL - blocks all stories)
+3. Complete highest priority user story (e.g., E1-S1)
+4. **STOP and VALIDATE:** Test story independently
+5. Deploy/demo if ready
+
+#### Incremental Delivery
+
+1. Setup + Foundational → Foundation ready
+2. Add Story 1 → Test independently → Deploy/Demo (MVP!)
+3. Add Story 2 → Test independently → Deploy/Demo
+4. Each story adds value without breaking previous stories
+
+---
+
 ## Glossary
 
 | Term | Definition |
@@ -190,7 +346,7 @@ _Alternative checklist format (if configured):_
 ---
 ## Insights Reference
 
-**Companion Document:** [specs/insights/prd-insights.md](../insights/prd-insights.md)
+**Companion Document:** [specs/insights/prd-insights.md](insights/prd-insights.md)
 
 This artifact was informed by ongoing insights captured during Planning. Key insights that shaped this document:
 
@@ -209,6 +365,7 @@ See the insights document for complete decision rationale, alternatives consider
 - [ ] Acceptance criteria are specific and testable (no vague qualifiers)
 - [ ] Non-functional requirements have measurable thresholds
 - [ ] At least one implementation milestone is defined
+- [ ] Task breakdown includes Setup, Foundational, and at least one user story phase
 - [ ] Dependencies have identified mitigations
 - [ ] Risks have identified mitigations
 - [ ] Success metrics map to Phase 0 validation criteria

package/.jumpstart/templates/product-brief.md

@@ -5,7 +5,7 @@
 > **Status:** Draft | Approved
 > **Created:** [DATE]
 > **Approved:** [DATE or pending]
-> **Upstream Reference:** [specs/challenger-brief.md](../challenger-brief.md)
+> **Upstream Reference:** [specs/challenger-brief.md](challenger-brief.md)
 
 ---
 
@@ -176,7 +176,7 @@ Capabilities explicitly excluded from this effort. Documenting these is as impor
 
 ## Insights Reference
 
-**Companion Document:** [specs/insights/product-brief-insights.md](../insights/product-brief-insights.md)
+**Companion Document:** [specs/insights/product-brief-insights.md](insights/product-brief-insights.md)
 
 This artifact was informed by ongoing insights captured during Analysis. Key insights that shaped this document: