From 2fe549624ae59faf3805f1ab5c1e5ca5d70b3631 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?M=C3=A5rten=20Angner?= <marten@angner.se>
Date: Wed, 3 Dec 2025 14:46:26 +0100
Subject: [PATCH] refactor: enhance WDS documentation and finalize PRD
 structure

- Updated the WDS conversion roadmap to include Positive Language Guidelines, emphasizing the use of constructive language in documentation.
- Removed outdated phase documents for Product Exploration, User Research, and Requirements, streamlining the method guide.
- Revised the UX Design phase to focus on UX-Sketches and Usage Scenarios, improving clarity on design processes.
- Finalized the PRD structure in the integration guide, ensuring comprehensive coverage of functional requirements and development priorities.
- Enhanced documentation for the Design System phase, detailing component extraction and integration with design tools.
---
 WDS-V6-CONVERSION-ROADMAP.md                  |  40 +-
 ...d => phase-1-product-exploration-guide.md} |   5 +-
 ...de.md => phase-2-trigger-mapping-guide.md} |   7 +-
 .../docs/method/phase-3-prd-platform-guide.md | 269 ++++++++
 .../docs/method/phase-3-requirements-guide.md | 159 -----
 .../docs/method/phase-4-ux-design-guide.md    | 118 +++-
 .../method/phase-5-design-system-guide.md     | 583 +++++++++++++++++-
 .../docs/method/phase-6-integration-guide.md  | 343 +++++++++--
 .../method/phase-6-prd-finalization-guide.md  | 469 ++++++++++++++
 .../wds/docs/method/wds-method-guide.md       |   2 +-
 10 files changed, 1712 insertions(+), 283 deletions(-)
 rename src/modules/wds/docs/method/{phase-1-exploration-guide.md => phase-1-product-exploration-guide.md} (96%)
 rename src/modules/wds/docs/method/{phase-2-research-guide.md => phase-2-trigger-mapping-guide.md} (98%)
 create mode 100644 src/modules/wds/docs/method/phase-3-prd-platform-guide.md
 delete mode 100644 src/modules/wds/docs/method/phase-3-requirements-guide.md
 create mode 100644 src/modules/wds/docs/method/phase-6-prd-finalization-guide.md

diff --git a/WDS-V6-CONVERSION-ROADMAP.md b/WDS-V6-CONVERSION-ROADMAP.md
index ec5f082a..8d796a25 100644
--- a/WDS-V6-CONVERSION-ROADMAP.md
+++ b/WDS-V6-CONVERSION-ROADMAP.md
@@ -338,13 +338,47 @@ Your rhythm:
 | Inconsistent output formats | Specs look different each time | Complete template examples |
 | Question dumping | 20 questions at once | Conversation examples showing one-at-a-time |
 
-### 6.3 Instruction Style
+### 6.3 Positive Language Guidelines
+
+**Principle:** Frame everything in terms of benefits and opportunities, not problems and costs.
+
+**Patterns to Avoid:**
+
+| Negative Pattern | Positive Alternative |
+|------------------|---------------------|
+| "Nothing kills a project faster than..." | "It's valuable to discover early..." |
+| "expensive development problems" | "easy to address while solutions are flexible" |
+| "Finding them later is expensive" | "Finding them now means more options" |
+| "Don't do X" | "What works well is Y" |
+| "Avoid these mistakes" | "Successful patterns include..." |
+| "This prevents failure" | "This enables success" |
+| "You'll waste time if..." | "You'll save time by..." |
+
+**The Reframe Test:**
+
+When writing guidance, ask: *"Am I describing what TO DO or what NOT to do?"*
+
+Good WDS documentation:
+- Celebrates early discovery (not fears late discovery)
+- Describes successful patterns (not failure modes)
+- Frames constraints as opportunities (not limitations)
+- Uses "enables" not "prevents"
+
+**Example Transformation:**
+
+Before:
+> "Nothing kills a project faster than discovering in development that a core feature is technically impossible."
+
+After:
+> "It's a great morale boost when you've proven your core features will work. And if you discover limitations, it's valuable to know them early so design can account for them from the start."
+
+### 6.4 Instruction Style
 
 **Identity-First:**
 ```markdown
 ## Who You Are
 
-You're Mary, a thoughtful business analyst who genuinely cares 
+You're Saga, a thoughtful analyst who genuinely cares 
 about understanding the product before documenting it.
 
 You prefer deep conversations over quick surveys. You ask one 
@@ -370,7 +404,7 @@ What works well:
 - One question at a time keeps things focused
 - Reflecting back shows you're listening
 
-What to avoid:
+What tends to feel less collaborative:
 - Listing many questions (feels like a survey)
 - Generating without checking in
 ```
diff --git a/src/modules/wds/docs/method/phase-1-exploration-guide.md b/src/modules/wds/docs/method/phase-1-product-exploration-guide.md
similarity index 96%
rename from src/modules/wds/docs/method/phase-1-exploration-guide.md
rename to src/modules/wds/docs/method/phase-1-product-exploration-guide.md
index 426ae8cf..df714026 100644
--- a/src/modules/wds/docs/method/phase-1-exploration-guide.md
+++ b/src/modules/wds/docs/method/phase-1-product-exploration-guide.md
@@ -1,8 +1,7 @@
-# Phase 1: Product Exploration
+# Phase 1: Product Exploration (Product Brief) (Project brief)
 
 **Agent:** Saga the Analyst  
-**Output:** `A-Product-Brief/` (or your configured prefix)  
-**Duration:** 30-60 minutes
+**Output:** `A-Product-Brief/` (or your configured prefix)
 
 ---
 
diff --git a/src/modules/wds/docs/method/phase-2-research-guide.md b/src/modules/wds/docs/method/phase-2-trigger-mapping-guide.md
similarity index 98%
rename from src/modules/wds/docs/method/phase-2-research-guide.md
rename to src/modules/wds/docs/method/phase-2-trigger-mapping-guide.md
index eabd7caf..98ef9df9 100644
--- a/src/modules/wds/docs/method/phase-2-research-guide.md
+++ b/src/modules/wds/docs/method/phase-2-trigger-mapping-guide.md
@@ -1,8 +1,7 @@
-# Phase 2: User Research (Trigger Mapping)
+# Phase 2: Trigger map
 
 **Agent:** Saga the Analyst  
-**Output:** `B-Trigger-Map/` (or your configured prefix)  
-**Duration:** 2-3 hours
+**Output:** `B-Trigger-Map/` (or your configured prefix)
 
 ---
 
@@ -172,7 +171,7 @@ Now the magic happens. You connect strategy to concrete features using a systema
 3. **Map to Driving Forces** - Which positive and negative drivers does it address?
 4. **Score the Impact** - Features serving multiple groups and drivers score higher
 
-**The Scoring System:**
+**The Scoring System:** *(Beta - refinements welcome)*
 
 For each feature, award points:
 
diff --git a/src/modules/wds/docs/method/phase-3-prd-platform-guide.md b/src/modules/wds/docs/method/phase-3-prd-platform-guide.md
new file mode 100644
index 00000000..1fd005ad
--- /dev/null
+++ b/src/modules/wds/docs/method/phase-3-prd-platform-guide.md
@@ -0,0 +1,269 @@
+# Phase 3: PRD Platform (Technical Foundation)
+
+**Agent:** Freyja the PM  
+**Output:** `C-Requirements/` (or your configured prefix)
+
+---
+
+## What This Phase Does
+
+This phase establishes everything technical that can be done **without the final UI**. It's about platform decisions, technical feasibility, and proving that your innovative features actually work.
+
+By the end, you'll have a solid technical foundation and confidence that your key features are buildable.
+
+---
+
+## The Core Principle
+
+**Prove our concept works technically — in parallel with design work.**
+
+While UX designers explore how users interact with features, technical validation runs alongside:
+- Can we actually build this?
+- Do the external services we need exist and work as expected?
+- What platform and infrastructure do we need?
+- What constraints does design need to know about?
+
+Design and technical validation inform each other. Neither waits for the other to finish.
+
+---
+
+## What You'll Create
+
+- **Platform Architecture** - Technology stack and infrastructure decisions
+- **Data Model** - Core entities and relationships
+- **Integration Map** - External services and how they connect
+- **Technical Proofs of Concept** - Validation that risky features work
+- **Experimental Endpoints** - API specs for known requirements (feeds into E-UI-Roadmap)
+- **Security Framework** - Authentication, authorization, data protection
+- **Technical Constraints Document** - What design needs to know
+
+---
+
+## How It Works
+
+### Stage 1: Platform Decisions (30-45 minutes)
+
+Establish the technical foundation:
+
+**Architecture:**
+- What technology stack fits your needs?
+- Monolith vs. microservices vs. serverless?
+- What hosting/infrastructure approach?
+- What are the key technical constraints?
+
+**Data Model:**
+- What are the core entities?
+- How do they relate to each other?
+- What's the database strategy?
+
+### Stage 2: Integration Mapping (20-30 minutes)
+
+Identify all external dependencies:
+
+- Authentication providers (OAuth, SSO)
+- Payment systems (Stripe, PayPal)
+- Third-party APIs (Google Maps, SendGrid, Twilio)
+- Data sources and feeds
+- Analytics and monitoring
+
+### Stage 3: Technical Proofs of Concept (Variable)
+
+**This is crucial.** For innovative or risky features, validate feasibility BEFORE committing to the design.
+
+**Examples:**
+
+| Feature Idea | Proof of Concept Question |
+|--------------|---------------------------|
+| "Show drive time between locations" | Can we call Google Maps Directions API and get estimated duration? |
+| "Real-time availability updates" | Can we set up WebSocket connections that scale? |
+| "AI-powered recommendations" | Does the ML model perform well enough with our data? |
+| "Offline mode" | Can we sync data reliably when connection returns? |
+| "Video calling" | Which provider works best? What's the latency? |
+
+**What a PoC validates:**
+- The API/service exists and does what we need
+- Performance is acceptable
+- Cost is within budget
+- Data format works for our needs
+- Edge cases are handleable
+
+**PoC Output:**
+- Working code snippet or prototype
+- Documented limitations and gotchas
+- Cost estimates (API calls, compute, etc.)
+- Go/No-Go recommendation for the feature
+
+> **Why this matters:** It's a great morale boost when you've proven your core features will work. And if you discover limitations or surprises, it's valuable to know them early so design can account for them from the start.
+
+### Stage 4: Security & Performance Framework (20-30 minutes)
+
+**Security:**
+- Authentication approach (passwords, OAuth, SSO, passwordless)
+- Authorization model (roles, permissions, row-level security)
+- Data encryption needs (at rest, in transit)
+- Compliance requirements (GDPR, HIPAA, PCI-DSS, etc.)
+
+**Performance:**
+- Expected load and scale
+- Response time expectations
+- Availability requirements (99.9%? 99.99%?)
+- Caching strategy
+
+### Stage 5: Experimental Endpoints (Variable)
+
+**Set up the endpoints you KNOW you'll need.**
+
+Even before the UI is designed, you often know certain data operations are essential. Setting these up early provides:
+
+- **Early validation** - Does the endpoint actually return what we need?
+- **Fail fast** - Discover problems before investing in design
+- **Developer head start** - Backend work can begin immediately
+- **Design confidence** - Designers know what data is available
+
+**What to set up:**
+
+| Endpoint Type | Example | Why Early? |
+|---------------|---------|------------|
+| Core CRUD | `GET /api/dogs`, `POST /api/bookings` | Foundation for everything |
+| External integrations | `GET /api/routes/estimate` (Google Maps) | Validates third-party works |
+| Authentication | `/api/auth/login`, `/api/auth/refresh` | Security model proven |
+| Key calculations | `/api/availability/check` | Business logic validated |
+
+**Output:**
+
+For each experimental endpoint, document:
+- Endpoint specification (method, path, request/response)
+- What it validates
+- Current status (stub, working, blocked)
+- Dependencies and notes
+
+These specifications go in your Requirements folder AND become tasks in the `E-UI-Roadmap/` handover folder for development teams.
+
+> **The mindset:** Every endpoint you validate early is one less surprise during development. Every endpoint that fails early saves weeks of wasted design work.
+
+### Stage 6: Technical Constraints Document (15-20 minutes)
+
+Create a summary of what UX design needs to know:
+
+- **What's possible** - Features validated by PoCs
+- **What's not possible** - Technical limitations discovered
+- **What's expensive** - Features with high API/compute costs
+- **What affects design** - Loading times, offline behavior, real-time vs. polling
+- **Platform capabilities** - What the framework/platform provides out of the box
+
+This document becomes essential input for Phase 4 (UX Design).
+
+---
+
+## The Design Connection
+
+Phase 3 is informed by:
+
+- **Product Brief** (Phase 1) - Strategic vision and constraints
+- **Trigger Map** (Phase 2) - Prioritized features from Feature Impact Analysis
+
+And it enables:
+
+- **UX Design** (Phase 4) - Design within known technical constraints
+- **Design System** (Phase 5) - Component technical requirements
+- **Development** - Platform work can begin in parallel with design
+
+---
+
+## Parallel Streams
+
+Once Phase 3 is complete:
+
+```
+Phase 3 Complete
+       │
+       ├──► E-UI-Roadmap/ receives:
+       │    • Experimental endpoint specs
+       │    • API implementation tasks
+       │    • Infrastructure setup tasks
+       │
+       ├──► Platform/Backend Development can START
+       │    (Infrastructure, APIs, data model)
+       │
+       └──► Phase 4: UX Design can START
+            (Informed by technical constraints)
+```
+
+This parallelism is one of WDS's key efficiency gains. Development teams can begin backend work while designers continue with UX.
+
+---
+
+## When to Use This Phase
+
+**Use this phase when:**
+- Building platform/infrastructure for a new product
+- Features depend on external APIs or services
+- Innovative features need technical validation
+- Development team needs architectural clarity before design
+
+**Skip or minimize if:**
+- Simple project with obvious technical approach
+- Working within existing platform/infrastructure
+- Enhancement that doesn't change architecture
+- All features use proven, familiar technology
+
+---
+
+## What to Prepare
+
+Bring:
+- Product Brief (Phase 1)
+- Trigger Map with Feature Impact Analysis (Phase 2)
+- Any existing technical constraints
+- Development team availability for PoC work
+
+---
+
+## What Comes Next
+
+Your technical foundation enables:
+
+- **Phase 4: UX Design** - Design with confidence about what's technically possible
+- **Phase 6: Dev Integration** - Handoff with complete technical context
+- **Development** - Backend/platform work can begin immediately
+
+---
+
+## Tips for Great Sessions
+
+**Validate risky features first**
+- If the Google Maps API doesn't return drive times in a usable format, you need to know NOW
+- Don't design features you can't build
+
+**Document constraints clearly**
+- Designers need to know what's possible
+- "Loading state required" vs "instant" changes UX significantly
+
+**Involve developers**
+- Technical decisions benefit from dev input
+- PoC work may require developer time
+- Architecture is a conversation, not a decree
+
+**Stay connected to strategy**
+- Reference Feature Impact Analysis scores
+- High-impact features deserve more PoC investment
+- Don't over-engineer for hypothetical needs
+
+---
+
+## Example Output
+
+See: `examples/dog-week-patterns/C-Requirements/` for the Dog Week technical foundation.
+
+**What Dog Week needed to prove early:**
+
+- *"Can we show dog owners how long it takes to walk to a dog walker?"* → Google Maps Directions API returns walking time between coordinates ✓
+- *"Can we check real-time availability across multiple walkers?"* → Endpoint aggregates calendar data in <200ms ✓
+- *"Can we handle Swish payments for Swedish users?"* → Swish API integration validated with test transactions ✓
+- *"Can walkers see their schedule on mobile?"* → Responsive calendar component renders correctly on iOS/Android browsers ✓
+
+These early discoveries shaped both the design AND the development approach.
+
+---
+
+*Phase 3 of the Whiteport Design Studio method*
diff --git a/src/modules/wds/docs/method/phase-3-requirements-guide.md b/src/modules/wds/docs/method/phase-3-requirements-guide.md
deleted file mode 100644
index e4a080a6..00000000
--- a/src/modules/wds/docs/method/phase-3-requirements-guide.md
+++ /dev/null
@@ -1,159 +0,0 @@
-# Phase 3: Requirements (PRD)
-
-**Agent:** Freyja the PM  
-**Output:** `D-PRD/` (or your configured prefix)  
-**Duration:** 1-2 hours
-
----
-
-## What This Phase Does
-
-Requirements defines the technical foundation and functional specifications. This phase bridges strategic vision with implementation details, creating the PRD (Product Requirements Document) that guides development.
-
-By the end, you'll have clear requirements that development teams can act on.
-
----
-
-## What You'll Create
-
-Your PRD includes:
-
-- **Platform Architecture** - Technology stack and infrastructure decisions
-- **Data Model** - Core entities and relationships
-- **API Specifications** - Endpoints and data contracts
-- **Integration Requirements** - External services and dependencies
-- **Security Framework** - Authentication, authorization, data protection
-- **Performance Requirements** - Speed, scale, reliability expectations
-- **Functional Specifications** - Feature-level requirements
-
----
-
-## How It Works
-
-### Platform Foundation First
-
-Before diving into features, establish the technical foundation:
-
-**Architecture Decisions:**
-- What technology stack fits your needs?
-- Monolith vs. microservices vs. serverless?
-- What hosting/infrastructure approach?
-- What are the key technical constraints?
-
-**Data Model:**
-- What are the core entities?
-- How do they relate to each other?
-- What's the database strategy?
-
-**Integration Points:**
-- What external services are needed?
-- Authentication providers?
-- Payment systems?
-- Third-party APIs?
-
-### Security & Performance
-
-**Security Framework:**
-- How do users authenticate?
-- What authorization model?
-- Data encryption approach?
-- Compliance requirements?
-
-**Performance Requirements:**
-- Expected load and scale?
-- Response time expectations?
-- Availability requirements?
-- Caching strategy?
-
-### Functional Requirements
-
-After the foundation is set, define feature-level requirements:
-
-- User stories or use cases
-- Acceptance criteria
-- Edge cases and error handling
-- Integration with the technical foundation
-
----
-
-## The Design Connection
-
-PRD work in WDS is informed by:
-
-- **Product Brief** (Phase 1) - Strategic vision and success criteria
-- **Trigger Map** (Phase 2) - User priorities and business goals
-
-And it enables:
-
-- **UX Design** (Phase 4) - Technical context for design decisions
-- **Design System** (Phase 5) - Component technical requirements
-- **Development** - Clear implementation guidance
-
----
-
-## When to Use This Phase
-
-**Use this phase when:**
-- Building platform/infrastructure for a new product
-- Need technical decisions documented before design
-- Development team needs architectural clarity
-
-**Timing considerations:**
-- Can run parallel to Phase 4 (UX Design) once foundation is set
-- Platform infrastructure can start while UX design continues
-- Functional requirements often finalize after Phase 4
-
-**Skip or minimize if:**
-- Simple project with obvious technical approach
-- Working within existing platform/infrastructure
-- Enhancement that doesn't change architecture
-
----
-
-## What to Prepare
-
-Bring:
-- Product Brief (Phase 1)
-- Trigger Map (Phase 2)
-- Any existing technical constraints
-- Development team input if available
-
----
-
-## What Comes Next
-
-Your PRD enables:
-
-- **Phase 4: UX Design** - Design within technical constraints
-- **Phase 6: Dev Integration** - Handoff with complete technical context
-- **Development** - Backend/platform work can begin
-
----
-
-## Tips for Great Sessions
-
-**Balance depth with progress**
-- Document decisions, not every detail
-- Focus on what developers need to start
-- Iterate as design clarifies requirements
-
-**Stay connected to strategy**
-- Reference trigger map priorities
-- Ensure technical decisions serve user goals
-- Don't over-engineer for hypothetical needs
-
-**Collaborate with development**
-- Technical decisions benefit from dev input
-- Early alignment prevents rework
-- Architecture is a conversation, not a decree
-
----
-
-## Example Output
-
-See: `examples/dog-week-patterns/D-PRD/` for a complete PRD from a real project.
-
----
-
-*Phase 3 of the Whiteport Design Studio method*
-
diff --git a/src/modules/wds/docs/method/phase-4-ux-design-guide.md b/src/modules/wds/docs/method/phase-4-ux-design-guide.md
index a0c920c9..8944b61a 100644
--- a/src/modules/wds/docs/method/phase-4-ux-design-guide.md
+++ b/src/modules/wds/docs/method/phase-4-ux-design-guide.md
@@ -1,8 +1,7 @@
-# Phase 4: UX Design (Conceptual Specifications)
+# Phase 4: UX Design (UX-Sketches & Usage Scenarios)
 
 **Agent:** Baldr the UX Expert  
-**Output:** `C-Scenarios/` (or your configured prefix)  
-**Duration:** 2-4 hours per scenario (varies by complexity)
+**Output:** `C-Scenarios/` (or your configured prefix)
 
 ---
 
@@ -10,7 +9,7 @@
 
 UX Design transforms ideas into detailed visual specifications. Working with Baldr, you conceptualize, sketch, and specify every interaction until your design can be logically explained without gaps.
 
-**The key insight:** Designs that can be logically explained without gaps are easy to develop. The specification process reveals holes in your thinking before they become expensive development problems.
+**The key insight:** Designs that can be logically explained without gaps are easy to develop. The specification process reveals gaps in your thinking early - when they're easy to address.
 
 ---
 
@@ -24,14 +23,14 @@ For each scenario/page:
 - **Interaction Behaviors** - What happens when users interact
 - **State Definitions** - All possible states for dynamic elements
 - **Multilingual Content** - Text in all supported languages
-- **HTML Previews** - Interactive prototypes for validation
+- **HTML Prototypes** - Interactive prototypes for validation
 
 ---
 
-## Three Ways to Work
+## How Baldr the UX Expert helps you design software
 
 ### 4A: Scenario Exploration
-**When:** No sketch exists, discovering the solution together
+**When:** Discovering the Concept, the process, flow screen or component solution together, before sketching begin
 
 Baldr helps you:
 - Think through the user's journey
@@ -39,32 +38,68 @@ Baldr helps you:
 - Consider psychological triggers from your Trigger Map
 - Arrive at a clear solution ready for sketching
 
-### 4B: Sketch Analysis
-**When:** You have a sketch, need to specify it
+### 4B: UI Sketch Analysis
+**When:** You have a sketch and you need feedback on it
 
 Baldr helps you:
 - Analyze what the sketch shows
 - Ask clarifying questions
 - Identify all components and states
-- Create complete specifications
 
-### 4C: Specification Creation
+### 4C: Conceptual Specification
 **When:** Design is clear, need development-ready specs
 
 Baldr helps you:
 - Document every detail systematically
 - Assign Object IDs for testing
 - Define all interactions and states
-- Prepare multilingual content
+- Prepare multilingual content, error codes, instructions and any other content needed for the developers
 
-### 4D: HTML Preview
-**When:** Specifications complete, need visual validation
+### 4D: HTML Prototype
+**When:** Specifications complete, and we make the sketch come alive to test the concept
 
 Baldr helps you:
-- Create interactive HTML prototypes
+- Create interactive prototypes
 - Test the design in browser
 - Discover gaps and issues
-- Refine specifications before development
+- Refine specifications 
+- Visualize the concept before development
+
+### 4E: PRD Update
+**When:** Page design is complete, before moving to the next scenario
+
+Baldr helps you:
+- Identify what features this page requires
+- Add functional requirements to the PRD
+- Reference the page (e.g., "Required by: 2.1-Dog-Calendar")
+- Note any API endpoints, validations, or data needs discovered
+
+**Why this step matters:**
+
+Each page reveals concrete requirements:
+- "This form needs email validation"
+- "We need a GET endpoint for availability"
+- "Users need to upload images here"
+
+Capturing these while the page is fresh ensures nothing is forgotten. The PRD becomes a complete feature inventory with traceability to the pages that need each feature.
+
+**PRD grows like this:**
+
+```markdown
+## Functional Requirements
+
+### Email Validation
+**Required by:** 1.2-Sign-Up, 2.3-Profile-Edit
+- Validate format on input
+- Check domain exists
+- Prevent duplicates
+
+### Availability Calendar API
+**Required by:** 2.1-Dog-Calendar, 3.1-Booking-Flow
+- GET /api/walkers/{id}/availability
+- Returns 2-week window
+- Updates via WebSocket
+```
 
 ---
 
@@ -76,10 +111,10 @@ Scenarios organize your design work into a clear hierarchy:
 C-Scenarios/
 ├── 00-Scenario-Overview.md
 ├── 01-User-Onboarding/
-│   ├── 1.1-Welcome-Page/
-│   │   ├── 1.1-Welcome-Page.md
+│   ├── 1.1-Start-Page/
+│   │   ├── 1.1-Start-Page.md
 │   │   ├── Sketches/
-│   │   └── Frontend/
+│   │   └── Prototype/
 │   └── 1.2-Sign-Up/
 │       ├── 1.2-Sign-Up.md
 │       └── ...
@@ -110,6 +145,31 @@ signin-form-email-input
 signin-form-error-email
 ```
 
+### Design System Integration
+
+**When Design System is enabled** (Phase 5), each object in your specification includes component library references:
+
+**Example specification entry:**
+```markdown
+### Submit Button
+**Object ID:** `signin-form-submit-button`
+**Component:** primary-button (from Design System)
+**Figma Component:** Primary Button
+**Variant:** size=large, type=primary
+**State:** default
+
+Triggers form validation and submission...
+```
+
+**Benefits:**
+- Designers know which Figma component to use
+- Developers know which code component to implement
+- Design System ensures consistency
+- Object IDs connect spec → design → code
+
+**Without Design System:**
+Just describe the element directly in the specification without component references.
+
 ---
 
 ## The Pressure-Testing Process
@@ -122,11 +182,11 @@ When you try to specify every detail, you discover:
 - "What if the user does X before Y?"
 - "Where does this data come from?"
 
-Finding these gaps now is cheap. Finding them during development is expensive.
+Finding these gaps now means addressing them while solutions are still flexible.
 
 ---
 
-## HTML Previews
+## HTML Prototypes
 
 Interactive prototypes that validate your design:
 
@@ -145,14 +205,14 @@ Interactive prototypes that validate your design:
 
 **File Structure:**
 ```
-1.1-Welcome-Page/
-├── 1.1-Welcome-Page.md (specification)
+1.1-Start-Page/
+├── 1.1-Start-Page.md (specification)
 ├── Sketches/
 │   └── concept-sketch.jpg
-└── Frontend/
-    ├── 1.1-Welcome-Page-Preview.html
-    ├── 1.1-Welcome-Page-Preview.css
-    └── 1.1-Welcome-Page-Preview.js
+└── Prototype/
+    ├── 1.1-Start-Page-Prototype.html
+    ├── 1.1-Start-Page-Prototype.css
+    └── 1.1-Start-Page-Prototype.js
 ```
 
 ---
@@ -173,7 +233,7 @@ Interactive prototypes that validate your design:
 - Have sketches ready to specify
 - Know what you want, need to document it
 
-**Use HTML previews (4D) if:**
+**Use HTML prototypes (4D) if:**
 - Specifications feel complete
 - Want to validate before development
 - Need stakeholder sign-off
@@ -214,7 +274,7 @@ Your specifications enable:
 - Success states
 - Edge cases
 
-**Don't skip the preview**
+**Don't skip the prototype**
 - Click through your design
 - Find the gaps before development
 - Refine specs based on what you learn
diff --git a/src/modules/wds/docs/method/phase-5-design-system-guide.md b/src/modules/wds/docs/method/phase-5-design-system-guide.md
index 8808d665..34e2d82e 100644
--- a/src/modules/wds/docs/method/phase-5-design-system-guide.md
+++ b/src/modules/wds/docs/method/phase-5-design-system-guide.md
@@ -1,8 +1,7 @@
-# Phase 5: Design System (Component Design)
+# Phase 5: Design System (Component Library)
 
 **Agent:** Baldr the UX Expert  
-**Output:** `D-Design-System/` (or your configured prefix)  
-**Duration:** Ongoing (grows with your product)
+**Output:** `D-Design-System/` (or your configured prefix)
 
 ---
 
@@ -10,7 +9,7 @@
 
 Design System builds your component library following atomic design principles. Working with Baldr, you create reusable patterns that serve user psychology and ensure visual consistency.
 
-The design system grows organically from your Phase 4 specifications - as you design scenarios, components are extracted and documented here.
+**The key approach:** The design system grows **alongside** Phase 4 work. As you sketch and specify pages, you simultaneously extract and document components. By the time your scenarios are complete, your design system is already built.
 
 ---
 
@@ -68,6 +67,27 @@ Complex components made of molecules:
 
 ## How It Works
 
+### The Parallel Workflow
+
+Phase 5 isn't a separate phase you do *after* Phase 4 - it happens **during** Phase 4:
+
+```
+Phase 4 Page Design          →    Phase 5 Design System
+─────────────────                  ─────────────────
+Sketch button for Page 1.1   →    Create "Primary Button" atom
+Reuse button on Page 1.2     →    Reference existing atom
+Sketch input for Page 2.1    →    Create "Text Input" atom
+Create form on Page 2.2      →    Create "Form Group" molecule
+Notice pattern across pages  →    Extract as reusable component
+```
+
+**The rhythm:**
+1. Design a page/component in Phase 4
+2. Notice "This could be reusable"
+3. Extract to Design System
+4. Next page references the system component
+5. Repeat
+
 ### Component Extraction
 
 As you specify scenarios in Phase 4, components naturally emerge:
@@ -76,7 +96,251 @@ As you specify scenarios in Phase 4, components naturally emerge:
 2. **Extract to system** - Document the component with all variants
 3. **Reference in specs** - Link scenario specs to system components
 
-### Component Documentation
+---
+
+## Creating Your Design System Documentation
+
+### The Extraction Process
+
+**Step 1: Spot the Pattern**
+
+While working on Phase 4 scenarios, notice when you're designing something reusable:
+- "I just designed this button for Page 1.1... and I need it again on Page 1.2"
+- "This form input pattern will be used everywhere"
+- "We have 3 different card layouts, but they share the same structure"
+
+**Step 2: Create the Component Document**
+
+In your `D-Design-System/` folder, create a component file:
+
+```
+D-Design-System/
+├── 01-design-tokens.md
+├── 02-atoms/
+│   ├── primary-button.md          ← Create this
+│   ├── text-input.md
+│   └── ...
+├── 03-molecules/
+│   └── form-group.md
+└── 04-organisms/
+    └── page-header.md
+```
+
+**Step 3: Document the Component**
+
+Use this template for each component:
+
+```markdown
+# Primary Button
+
+## Overview
+The primary button is used for the main call-to-action on any page or section.
+
+## Component Details
+
+**Category:** Atom
+**Object ID Pattern:** `*-primary-button`
+**Component Library:** [If using one, e.g., "Chakra UI Button"]
+**Figma Component:** Primary Button
+
+## Variants
+
+### Size
+- **Small:** Compact spaces, secondary actions
+- **Medium:** Default size for most use cases
+- **Large:** Hero sections, important CTAs
+
+### State
+- **Default:** Ready for interaction
+- **Hover:** Visual feedback on mouse over
+- **Active:** Currently being clicked
+- **Disabled:** Action not available
+- **Loading:** Processing user action
+
+## Visual Specifications
+
+**Design Tokens:**
+- Background: `color-primary-500`
+- Text: `color-white`
+- Border Radius: `radius-md`
+- Padding: `spacing-3` (vertical), `spacing-6` (horizontal)
+- Font: `font-semibold`, `text-base`
+
+**States:**
+- Hover: `color-primary-600`
+- Active: `color-primary-700`
+- Disabled: `color-gray-300`, opacity 50%
+
+## Usage Guidelines
+
+**When to use:**
+- Primary action on a page or modal
+- Main CTA in hero sections
+- Form submissions
+- Confirmation actions
+
+**When NOT to use:**
+- Multiple primary actions (use secondary instead)
+- Destructive actions (use danger variant)
+- Navigation (use links or secondary buttons)
+
+## Accessibility
+
+- Minimum contrast ratio: 4.5:1
+- Keyboard accessible (Enter/Space)
+- Focus visible indicator
+- ARIA label when icon-only
+
+## Example Usage
+
+**In specifications:**
+```markdown
+### Submit Button
+**Object ID:** `contact-form-submit-button`
+**Component:** primary-button
+**Variant:** size=large
+**State:** default → loading → success
+```
+
+**In Figma:**
+Use "Primary Button" component from library
+
+**In Code (if using Chakra):**
+```jsx
+<Button colorScheme="blue" size="lg">Submit</Button>
+```
+
+## Used In
+
+- 1.1-Start-Page: Hero CTA
+- 1.2-Sign-Up: Submit registration
+- 2.1-Contact-Form: Send message
+- [Update as you use the component]
+```
+
+**Step 4: Update as You Go**
+
+Each time you use this component in a new scenario:
+1. Add it to the "Used In" section
+2. Note any new variants discovered
+3. Update specifications if the component evolves
+
+### Interactive Component Gathering
+
+**As you work through Phase 4:**
+
+```
+Design Page 1.1
+  ↓
+Notice: "This button is reusable"
+  ↓
+Create: primary-button.md in Design System
+  ↓
+Reference in 1.1 spec: component=primary-button
+  ↓
+Design Page 1.2
+  ↓
+Need same button: Reference existing component
+  ↓
+Design Page 2.1
+  ↓
+Need slightly different: Add variant to component doc
+  ↓
+Update all references with new variant option
+```
+
+---
+
+## Interactive HTML Component Showcase
+
+Beyond documentation, create an **interactive HTML guide** where stakeholders and developers can see and interact with all components.
+
+### Structure
+
+```
+D-Design-System/
+├── component-showcase.html    ← Interactive guide
+├── component-showcase.css
+├── component-showcase.js
+├── 01-design-tokens.md
+├── 02-atoms/
+│   ├── primary-button.md
+│   └── ...
+```
+
+### What the Showcase Includes
+
+**For each component:**
+1. **Live rendered examples** - See the actual component
+2. **All variants** - Size, state, and style options
+3. **Interactive states** - Hover, click, focus to see behavior
+4. **Visual specifications** - Design tokens, spacing, colors used
+5. **Usage notes** - When to use this component
+
+### Building the Showcase
+
+**As you document each component:**
+
+1. **Add to showcase HTML** - Create a card with live examples
+2. **Show all variants** - Size, state, visual options
+3. **Make it interactive** - Buttons click, inputs accept text, states change
+4. **Display tokens** - Show the actual colors, fonts, spacing
+5. **Keep it synced** - Update when components evolve
+
+**Use the provided templates:**
+
+Find ready-to-use templates in:
+- `reference/templates/component-showcase-template.html`
+- `reference/templates/component-card-template.html`
+
+See complete examples in:
+- `examples/dog-week-patterns/D-Design-System/component-showcase.html`
+
+### Benefits
+
+**For Designers:**
+- Visual inventory of all components
+- See components in isolation
+- Test interactions and states
+- Share with stakeholders for feedback
+
+**For Developers:**
+- Visual reference for implementation
+- Understand variant options
+- See all states and interactions
+- Check responsive behavior
+
+**For Stakeholders:**
+- See the design language
+- Review consistency
+- Experience interactive components
+- Provide informed feedback
+
+**For QA:**
+- Test all component states
+- Verify accessibility
+- Check responsive behavior
+- Document expected behavior
+
+### Maintaining the Showcase
+
+**Keep it current:**
+- Add new components as they're documented
+- Update when variants change
+- Remove deprecated components
+- Sync with Figma library updates
+
+**Single source of truth:**
+- Markdown docs = specifications and usage
+- HTML showcase = visual reference and interaction
+- Figma = design source
+- Code = implementation
+
+All four should stay aligned.
+
+---
+
+## Component Documentation
 
 Each component includes:
 
@@ -102,19 +366,276 @@ Each component includes:
 
 ---
 
-## Trigger Map Connection
+## Choosing a Component Library
 
-Components aren't just visual - they serve user psychology:
+### Build vs. Use Existing
 
-**Example: Primary Button**
-- **Serves trigger:** Reduces decision anxiety for professional users
-- **Design intent:** Bold, confident, clear
-- **Psychological purpose:** Makes taking action feel safe
+**Build your own Design System when:**
+- Unique brand identity required
+- Custom interactions not available in libraries
+- Full control over every detail needed
+- Have design resources to maintain system
 
-**Example: Error Message**
-- **Serves trigger:** Prevents frustration and abandonment
-- **Design intent:** Clear, helpful, non-judgmental
-- **Psychological purpose:** Recovery feels possible
+**Use existing component library when:**
+- Fast time to market
+- Standard UI patterns sufficient
+- Limited design resources
+- Want battle-tested accessibility
+
+**WDS supports both approaches** - you can document either custom components or library components using the same structure.
+
+---
+
+## Recommended Component Libraries
+
+These libraries work well with WDS's specification approach:
+
+### React Ecosystem
+
+**Shadcn/ui** (Recommended for flexibility)
+- Not a library, but a collection of copy-paste components
+- Built on Radix UI primitives (excellent accessibility)
+- [ui.shadcn.com](https://ui.shadcn.com)
+
+*Pros:*
+- Full component ownership - code lives in your repo
+- Easy to customize without fighting library constraints
+- No package bloat or version conflicts
+- Perfect for WDS documentation (you own the code)
+
+*Cons:*
+- Manual updates when new versions release
+- Need to maintain copied code yourself
+- Requires understanding of component internals
+
+---
+
+**Chakra UI** (Recommended for speed)
+- Comprehensive component library
+- Excellent TypeScript support
+- Built-in dark mode and theming
+- [chakra-ui.com](https://chakra-ui.com)
+
+*Pros:*
+- Fast to get started - works out of the box
+- Excellent accessibility defaults
+- Great developer experience
+- Active community and good documentation
+
+*Cons:*
+- Less control over internals
+- Can be opinionated about styling approach
+- Larger bundle size than headless options
+
+---
+
+**Radix UI** (Recommended for headless)
+- Unstyled, accessible components
+- Complete control over styling
+- Composable primitives
+- [radix-ui.com](https://radix-ui.com)
+
+*Pros:*
+- Best-in-class accessibility built-in
+- Total styling freedom
+- Small bundle size (only import what you need)
+- No design opinions forced on you
+
+*Cons:*
+- Requires you to style everything yourself
+- Steeper learning curve than styled libraries
+- More initial setup work
+
+---
+
+**Material UI (MUI)**
+- Mature, comprehensive library
+- Material Design by default (can customize)
+- Large ecosystem of additional packages
+- [mui.com](https://mui.com)
+
+*Pros:*
+- Battle-tested with large community
+- Very comprehensive component set
+- Good documentation and examples
+- Material Design is familiar to users
+
+*Cons:*
+- Heavy bundle size
+- Material Design aesthetic hard to override
+- Can feel dated for modern designs
+- Customization can be complex
+
+### Vue Ecosystem
+
+**Nuxt UI**
+- Built for Nuxt/Vue 3
+- Modern, fast, accessible
+- [ui.nuxt.com](https://ui.nuxt.com)
+
+*Pros:*
+- Optimized specifically for Nuxt
+- Modern design aesthetics
+- Good performance
+- Growing ecosystem
+
+*Cons:*
+- Nuxt-specific (not for plain Vue)
+- Younger library with smaller community
+- Less comprehensive than mature alternatives
+
+---
+
+**PrimeVue**
+- Rich component set
+- Multiple themes available
+- Enterprise-focused
+- [primevue.org](https://primevue.org)
+
+*Pros:*
+- Very comprehensive component library
+- Multiple pre-built themes
+- Good for complex enterprise UIs
+- Active development
+
+*Cons:*
+- Can feel corporate/dated
+- Larger bundle size
+- Theme customization can be complex
+
+### Framework-Agnostic
+
+**Tailwind CSS** (Recommended for design freedom)
+- Utility-first CSS framework
+- Combine with headless components
+- Maximum flexibility
+- [tailwindcss.com](https://tailwindcss.com)
+
+*Pros:*
+- Complete design freedom
+- Small production bundle (unused styles purged)
+- Fast prototyping with utility classes
+- Pairs perfectly with WDS specifications
+
+*Cons:*
+- Not a component library (need to build or combine)
+- HTML can get verbose
+- Learning curve for utility-first approach
+- Need separate component primitives (e.g., Radix)
+
+### Selection Criteria
+
+**Choose based on:**
+
+| Priority | Consider |
+|----------|----------|
+| **Speed** | Chakra UI, MUI, PrimeVue (ready-to-use) |
+| **Customization** | Shadcn/ui, Radix UI, Tailwind (full control) |
+| **Accessibility** | Radix UI, Chakra UI (built-in a11y) |
+| **Design System** | Shadcn/ui, custom components (full documentation) |
+| **Team Familiarity** | What your dev team already knows |
+
+### WDS Integration Pattern
+
+**With existing library:**
+1. Document library components in your WDS Design System
+2. Reference library component names in specifications
+3. Add project-specific variants/customizations
+4. Maintain consistency across your product
+
+**Example WDS entry for library component:**
+```markdown
+## Primary Button
+
+**Library Component:** Chakra UI Button
+**Import:** `import { Button } from '@chakra-ui/react'`
+
+**Usage in WDS:**
+- Object ID suffix: `-primary-button`
+- Figma Component: Primary Button
+- Props: `colorScheme="blue" size="lg"`
+
+**Variants:**
+- Default: `variant="solid"`
+- Secondary: `variant="outline"`
+- Ghost: `variant="ghost"`
+
+**When to use:**
+Primary call-to-action buttons...
+```
+
+---
+
+## Design Application Integration
+
+Your WDS component system connects to your visual design tools (Figma, Sketch, Adobe XD):
+
+### Unified Naming Convention
+
+**Use the exact same names across all tools:**
+
+| WDS Component Name | Figma Component | Code Component | Object ID |
+|-------------------|-----------------|----------------|-----------|
+| `primary-button` | Primary Button | `PrimaryButton` | `*-primary-button` |
+| `text-input` | Text Input | `TextInput` | `*-text-input` |
+| `form-group` | Form Group | `FormGroup` | `*-form-group` |
+
+### The Workflow
+
+```
+WDS Specification → Figma Design → Code Implementation
+─────────────────    ─────────     ──────────────────
+1. Document          2. Create      3. Build with
+   "primary-button"     component      same name
+   in Design System     in Figma       in code
+
+Object IDs reference the same names:
+signin-form-submit-primary-button (everywhere)
+```
+
+### Figma/Design Tool Setup
+
+**Component Library Structure:**
+
+Match your WDS atomic design structure:
+```
+Design File/
+├── 🎨 Design Tokens
+│   ├── Colors
+│   ├── Typography
+│   └── Spacing
+├── ⚛️ Atoms
+│   ├── primary-button
+│   ├── text-input
+│   └── ...
+├── 🧬 Molecules
+│   ├── form-group
+│   ├── search-bar
+│   └── ...
+└── 🧩 Organisms
+    ├── page-header
+    └── ...
+```
+
+**Naming in Figma:**
+- Component names match WDS names (kebab-case or Title Case)
+- Variants match WDS variants (Primary, Secondary, Disabled)
+- Properties match WDS states (default, hover, active, error)
+
+### Benefits of Unified Naming
+
+- **Designers:** Find components easily in Figma library
+- **Developers:** No translation needed from design to code
+- **Testers:** Object IDs make sense and are predictable
+- **Documentation:** Single source of truth for naming
+- **Handoff:** Zero ambiguity about which component to use
+
+### When You Design in Figma
+
+1. **Reference your WDS Design System** for component names and structure
+2. **Create visual designs** using those exact names
+3. **Export/handoff** with matching naming to developers
+4. **Specifications remain in WDS** - Figma provides the pixels, WDS provides the logic
 
 ---
 
@@ -143,19 +664,31 @@ As you design more scenarios:
 
 ## When to Use This Phase
 
-**Build alongside Phase 4:**
-- As you design scenarios, extract components
-- Design system grows organically with specs
+**Enable Design System phase if:**
+- Building reusable component library
+- Multiple pages/scenarios with shared patterns
+- Need design consistency across product
+- Handoff requires component documentation
 
-**Dedicated design system work when:**
-- Consolidating after multiple scenarios
-- Preparing for development sprint
+**Work in parallel with Phase 4 when enabled:**
+- As you sketch, identify component patterns
+- As you specify, extract to Design System
+- Design System grows with each page completed
+- No separate "design system phase" at the end
+
+**Skip this phase if:**
+- Small project (single landing page)
+- Using existing design system (Material, Chakra, etc.)
+- One-off designs without reuse
+- Quick prototype or MVP without component library needs
+
+**Dedicated consolidation when:**
+- Multiple scenarios complete, need cleanup
+- Preparing for development handoff
+- Found inconsistencies to resolve
 - Onboarding new team members
 
-**Skip formal documentation if:**
-- Very small project
-- One-off design without reuse
-- Using existing design system
+> **Note:** You'll choose whether to enable the Design System phase during project setup (`workflow-init`). This decision can be revisited as your project grows.
 
 ---
 
diff --git a/src/modules/wds/docs/method/phase-6-integration-guide.md b/src/modules/wds/docs/method/phase-6-integration-guide.md
index 09a81f1b..288e11af 100644
--- a/src/modules/wds/docs/method/phase-6-integration-guide.md
+++ b/src/modules/wds/docs/method/phase-6-integration-guide.md
@@ -1,78 +1,287 @@
-# Phase 6: Dev Integration (UI Roadmap)
+# Phase 6: PRD Finalization
 
 **Agent:** Freyja the PM  
-**Output:** `E-UI-Roadmap/` (or your configured prefix)  
-**Duration:** 1-2 hours
+**Output:** Complete PRD in `C-Requirements/` + Handoff materials in `E-UI-Roadmap/`  
+**Duration:** 2-4 hours
 
 ---
 
 ## What This Phase Does
 
-Dev Integration prepares everything development teams need. This phase creates the bridge between design and implementation - the handoff package that enables development to begin without additional discovery work.
+PRD Finalization compiles all the functional requirements discovered during Phase 4 into a complete, development-ready Product Requirements Document.
 
-By the end, developers have a clear roadmap for building the UI you've designed.
+**The key insight:** Your PRD started in Phase 3 with platform/infrastructure. During Phase 4, each page added functional requirements (via step 4E). Now you organize, prioritize, and finalize everything for development handoff.
+
+By the end, developers have a complete PRD covering both technical foundation and all UI-driven features.
 
 ---
 
 ## What You'll Create
 
-Your UI Roadmap includes:
+**Updated PRD (C-Requirements/) includes:**
 
-- **Priority Sequence** - What to build first and why
-- **Scenario Mapping** - How scenarios translate to development order
-- **Component Inventory** - All components needed, with status
-- **Technical Notes** - Design constraints and decisions
-- **Object ID Inventory** - Complete list for testing
-- **Handoff Checklist** - Verification that everything is ready
-- **Open Questions** - Items for the dev team to decide
+**From Phase 3 (Technical Foundation):**
+- Platform architecture
+- Data model
+- Integration map
+- Technical proofs of concept
+- Experimental endpoints
+- Security framework
+
+**Added from Phase 4 (Functional Requirements):**
+- All features discovered during page design
+- Page-to-feature traceability
+- Priority rankings
+- Feature dependencies
+- Implementation notes
+
+**New in Phase 6:**
+- Feature organization by epic/area
+- Development sequence
+- MVP scope definition
+- Technical dependencies mapped
+
+**Handoff Package (E-UI-Roadmap/):**
+- Priority sequence document
+- Scenario-to-development mapping
+- Component inventory (if Design System enabled)
+- Open questions for dev team
 
 ---
 
-## The Handoff Package
+## How It Works
 
-### Priority Sequence
+### Stage 1: Review Collected Requirements (30-45 minutes)
 
-Based on your Trigger Map priorities:
-- Which scenarios serve the most important user triggers?
-- What's the critical path for MVP?
-- What can be deferred to later releases?
+**Gather all functional requirements added during Phase 4:**
+
+Go through each scenario specification and extract the requirements added in step 4E:
 
-**Example:**
 ```
-Priority 1: User Onboarding (Scenarios 1.1-1.3)
-  - Serves highest-priority business goal
-  - Enables all other user scenarios
-  
-Priority 2: Core Feature (Scenarios 2.1-2.4)
-  - Primary value delivery
-  - Most important user trigger activation
-  
-Priority 3: Settings & Account (Scenarios 3.1-3.2)
-  - Supporting functionality
-  - Can launch with minimal version
+From 1.1-Start-Page:
+- User authentication system
+- Session management
+- Password reset flow
+
+From 1.2-Sign-Up:
+- Email validation (format, domain check, duplicate prevention)
+- Phone number validation with country code
+- Account activation via email
+
+From 2.1-Dog-Calendar:
+- Availability calendar API
+- Real-time updates via WebSocket
+- Date/time localization
 ```
 
-### Scenario-to-Development Mapping
+**Compile into master feature list** with page references preserved.
 
-How design scenarios map to development work:
+### Stage 2: Organize by Epic/Feature Area (30-45 minutes)
 
-| WDS Scenario | Development Epic | Dependencies |
-|--------------|------------------|--------------|
-| 01-User-Onboarding | Epic 1: Auth System | None |
-| 02-Core-Feature | Epic 2: Main Feature | Epic 1 |
-| 03-Settings | Epic 3: User Settings | Epic 1 |
+**Group related features together:**
 
-### Component Inventory
+```markdown
+## Epic 1: User Authentication & Account Management
 
-All components from your Design System with development status:
+### Features
 
-| Component | Design Status | Dev Status | Notes |
-|-----------|--------------|------------|-------|
-| Button Primary | Complete | Ready | Use existing library |
-| Phone Input | Complete | Needs Build | Custom with country selector |
-| Calendar Widget | Complete | Needs Build | Complex interactions |
+**User Registration**
+- Required by: 1.2-Sign-Up
+- Email validation (format, domain, duplicates)
+- Phone validation with country codes
+- Account activation flow
 
-### Object ID Inventory
+**User Login**
+- Required by: 1.1-Start-Page, multiple pages
+- Email/password authentication
+- Session management (30-day persistence)
+- "Remember me" functionality
+
+**Password Management**
+- Required by: 1.1-Start-Page (reset link)
+- Password reset via email
+- Password strength validation
+- Secure token generation
+```
+
+### Stage 3: Define Priorities & Sequence (45-60 minutes)
+
+**Based on your Phase 2 Feature Impact Analysis:**
+
+Reference the scoring you did in Phase 2 to inform priorities:
+
+```markdown
+## Development Sequence
+
+### Priority 1: MVP - Core User Flow
+**Target:** Weeks 1-4
+
+Features from Epic 1 (Authentication) + Epic 2 (Core Booking):
+- User registration (Impact Score: 14)
+- User login (Impact Score: 16)
+- Availability calendar (Impact Score: 16)
+- Basic booking flow (Impact Score: 18)
+
+**Why this order:**
+Serves Priority 1 target group, addresses highest-impact drivers.
+
+### Priority 2: Enhanced Features
+**Target:** Weeks 5-8
+
+Features from Epic 3 (Payments) + Epic 4 (Notifications):
+- Payment processing (Impact Score: 12)
+- Booking confirmations (Impact Score: 11)
+- Calendar sync (Impact Score: 8)
+```
+
+### Stage 4: Map Dependencies (20-30 minutes)
+
+**Technical dependencies between features:**
+
+```markdown
+## Feature Dependencies
+
+**Booking Flow** depends on:
+- ✓ User authentication (must be logged in)
+- ✓ Availability calendar (must see open slots)
+- ⚠️ Payment system (can launch with "pay in person" temporarily)
+- ⚠️ Notifications (can launch without, add later)
+
+**Recommendation:** Launch MVP with auth + calendar, add payments in Sprint 2.
+```
+
+### Stage 5: Create Handoff Package (30-45 minutes)
+
+**Organize for development team:**
+
+In `E-UI-Roadmap/` folder, create:
+
+1. **`priority-sequence.md`** - What to build when and why
+2. **`scenario-to-epic-mapping.md`** - How WDS scenarios map to dev epics
+3. **`component-inventory.md`** (if Design System enabled) - All components needed
+4. **`open-questions.md`** - Decisions for dev team to make
+
+---
+
+## The Complete PRD Structure
+
+Your finalized PRD in `C-Requirements/` combines all phases:
+
+```markdown
+# Product Requirements Document
+
+## 1. Technical Foundation (from Phase 3)
+
+### Platform Architecture
+- Technology stack decisions
+- Infrastructure approach  
+- Hosting and deployment
+
+### Data Model
+- Core entities and relationships
+- Database schema
+- Data flow diagrams
+
+### Integrations
+- External services (Google Maps, Stripe, etc.)
+- API specifications
+- Authentication providers
+
+### Security & Performance
+- Authentication/authorization approach
+- Data protection
+- Performance requirements
+- Proofs of concept results
+
+## 2. Functional Requirements (from Phase 4)
+
+### Epic 1: User Authentication & Account Management
+**Features:**
+- User registration (Required by: 1.2-Sign-Up)
+- User login (Required by: 1.1-Start-Page, multiple)
+- Password management (Required by: 1.1-Start-Page)
+
+[Detailed specifications for each feature]
+
+### Epic 2: [Next Epic]
+[...]
+
+## 3. Development Roadmap (from Phase 6)
+
+### Priority 1: MVP (Weeks 1-4)
+- Features list with Impact Scores
+- Why these first (references Trigger Map)
+- Timeline estimate
+- Dependencies
+
+### Priority 2: Enhanced Features (Weeks 5-8)
+[...]
+
+## 4. Dependencies & Constraints
+- Technical dependencies between features
+- Design constraints from Phase 4
+- Third-party limitations discovered in Phase 3
+
+## 5. Success Metrics
+- Business goals from Phase 1
+- Feature-specific KPIs
+- How we measure success
+```
+
+---
+
+## Continuous vs. Final Handoff
+
+**The pattern:**
+
+- **Phase 3:** Initial PRD with technical foundation
+- **Phase 4:** PRD grows with each page (step 4E adds requirements)  
+- **Phase 6 (First time):** Organize MVP scope from completed scenarios
+  - Create first handoff package
+  - Development can begin
+- **Phase 4 continues:** More pages designed, more requirements added
+- **Phase 6 (Ongoing):** Update PRD priorities, create new handoff packages
+  - Weekly or bi-weekly updates
+  - Keep dev team synced
+
+**You can run Phase 6 multiple times as design progresses.**
+
+---
+
+## When to Use This Phase
+
+**First PRD Finalization when:**
+- You have MVP-level scenarios complete (enough for dev to start)
+- Core user flows are specified  
+- Critical features are documented
+- Enough work for 2-4 week sprint
+
+**Ongoing PRD Updates as:**
+- Additional scenarios complete
+- New feature areas designed
+- Priorities shift based on learning
+- Sprint planning needs updated scope
+
+**Timeline example:**
+
+```
+Week 1-2: Phase 1-3 (Strategy, Research, Platform foundation)
+Week 3-4: Phase 4 Scenarios 1-3 (Core MVP flows)
+Week 5:   Phase 6 First Finalization
+          └──► PRD v1.0: MVP scope ready
+          └──► Development Sprint 1 begins
+
+Week 6-7: Phase 4 Scenarios 4-6 (Additional features)
+          Phase 5 Design System (extract components)
+Week 8:   Phase 6 Update
+          └──► PRD v1.1: Sprint 2 scope added
+          └──► Development Sprint 2 begins
+
+Week 9+:  Design continues in parallel with development
+          Regular Phase 6 updates for new sprints
+```
+
+**The beauty:** Design doesn't block development. You hand off in waves.
 
 Complete list for test automation:
 
@@ -94,7 +303,7 @@ Before handoff, verify:
 - Design system covers all components
 - Object IDs assigned throughout
 - Multilingual content complete
-- HTML previews validated
+- HTML prototypes validated
 
 ### Identify Priorities
 
@@ -147,7 +356,7 @@ Organize everything into the UI Roadmap folder:
 - [ ] Usage guidelines written
 
 ### Validation
-- [ ] HTML previews created for key scenarios
+- [ ] HTML prototypes created for key scenarios
 - [ ] Stakeholder review complete
 - [ ] Open questions documented
 
@@ -158,19 +367,35 @@ Organize everything into the UI Roadmap folder:
 
 ## When to Use This Phase
 
-**Use this phase when:**
-- Design work is substantially complete
-- Ready to hand off to development
-- Need to coordinate design-to-dev transition
+**First handoff when:**
+- You have enough scenarios for MVP
+- Core user flows are specified
+- Critical components are documented
+- Developers can start building foundational features
 
-**Start here if:**
-- Joining a project with existing designs
-- Need to organize existing documentation
-- Preparing for development sprint planning
+**Ongoing handoffs as:**
+- Each major scenario completes
+- New component patterns emerge
+- Design decisions affect development
+- Sprint planning needs updated priorities
 
-**Run continuously if:**
-- Working in parallel with development
-- Gradual handoff as scenarios complete
+**The rhythm:**
+
+```
+Week 1-2: Design Phase 1-3 (Strategy, Research, Platform)
+Week 3-4: Design Phase 4 Scenarios 1-2 (Core flows)
+         └──► First Handoff: MVP scope
+Week 5-6: Design Phase 4 Scenarios 3-4
+         Design Phase 5 (Components from 1-2)
+         └──► Second Handoff: Additional features
+Week 7+:  Design continues...
+          Development builds in parallel
+          └──► Ongoing handoffs as design progresses
+```
+
+**You DON'T need to finish all design before handing off.**
+
+Development and design work in parallel streams, with regular sync points.
 
 ---
 
diff --git a/src/modules/wds/docs/method/phase-6-prd-finalization-guide.md b/src/modules/wds/docs/method/phase-6-prd-finalization-guide.md
new file mode 100644
index 00000000..9f642442
--- /dev/null
+++ b/src/modules/wds/docs/method/phase-6-prd-finalization-guide.md
@@ -0,0 +1,469 @@
+# Phase 6: PRD Finalization (Complete PRD)
+
+**Agent:** Freyja the PM  
+**Output:** Complete PRD in `C-Requirements/` + Handoff materials in `E-UI-Roadmap/`
+
+---
+
+## What This Phase Does
+
+PRD Finalization compiles all the functional requirements discovered during Phase 4 into a complete, development-ready Product Requirements Document.
+
+**The key insight:** Your PRD started in Phase 3 with platform/infrastructure. During Phase 4, each page added functional requirements (via step 4E). Now you organize, prioritize, and finalize everything for development handoff.
+
+By the end, developers have a complete PRD covering both technical foundation and all UI-driven features.
+
+---
+
+## What You'll Create
+
+**Updated PRD (C-Requirements/) includes:**
+
+**From Phase 3 (Technical Foundation):**
+- Platform architecture
+- Data model
+- Integration map
+- Technical proofs of concept
+- Experimental endpoints
+- Security framework
+
+**Added from Phase 4 (Functional Requirements):**
+- All features discovered during page design
+- Page-to-feature traceability
+- Priority rankings
+- Feature dependencies
+- Implementation notes
+
+**New in Phase 6:**
+- Feature organization by epic/area
+- Development sequence
+- MVP scope definition
+- Technical dependencies mapped
+
+**Handoff Package (E-UI-Roadmap/):**
+- Priority sequence document
+- Scenario-to-development mapping
+- Component inventory (if Design System enabled)
+- Open questions for dev team
+
+---
+
+## How It Works
+
+### Stage 1: Review Collected Requirements (30-45 minutes)
+
+**Gather all functional requirements added during Phase 4:**
+
+Go through each scenario specification and extract the requirements added in step 4E:
+
+```
+From 1.1-Start-Page:
+- User authentication system
+- Session management
+- Password reset flow
+
+From 1.2-Sign-Up:
+- Email validation (format, domain check, duplicate prevention)
+- Phone number validation with country code
+- Account activation via email
+
+From 2.1-Dog-Calendar:
+- Availability calendar API
+- Real-time updates via WebSocket
+- Date/time localization
+```
+
+**Compile into master feature list** with page references preserved.
+
+### Stage 2: Organize by Epic/Feature Area (30-45 minutes)
+
+**Group related features together:**
+
+```markdown
+## Epic 1: User Authentication & Account Management
+
+### Features
+
+**User Registration**
+- Required by: 1.2-Sign-Up
+- Email validation (format, domain, duplicates)
+- Phone validation with country codes
+- Account activation flow
+
+**User Login**
+- Required by: 1.1-Start-Page, multiple pages
+- Email/password authentication
+- Session management (30-day persistence)
+- "Remember me" functionality
+
+**Password Management**
+- Required by: 1.1-Start-Page (reset link)
+- Password reset via email
+- Password strength validation
+- Secure token generation
+```
+
+### Stage 3: Define Priorities & Sequence (45-60 minutes)
+
+**Based on your Phase 2 Feature Impact Analysis:**
+
+Reference the scoring you did in Phase 2 to inform priorities:
+
+```markdown
+## Development Sequence
+
+### Priority 1: MVP - Core User Flow
+**Target:** Weeks 1-4
+
+Features from Epic 1 (Authentication) + Epic 2 (Core Booking):
+- User registration (Impact Score: 14)
+- User login (Impact Score: 16)
+- Availability calendar (Impact Score: 16)
+- Basic booking flow (Impact Score: 18)
+
+**Why this order:**
+Serves Priority 1 target group, addresses highest-impact drivers.
+
+### Priority 2: Enhanced Features
+**Target:** Weeks 5-8
+
+Features from Epic 3 (Payments) + Epic 4 (Notifications):
+- Payment processing (Impact Score: 12)
+- Booking confirmations (Impact Score: 11)
+- Calendar sync (Impact Score: 8)
+```
+
+### Stage 4: Map Dependencies (20-30 minutes)
+
+**Technical dependencies between features:**
+
+```markdown
+## Feature Dependencies
+
+**Booking Flow** depends on:
+- ✓ User authentication (must be logged in)
+- ✓ Availability calendar (must see open slots)
+- ⚠️ Payment system (can launch with "pay in person" temporarily)
+- ⚠️ Notifications (can launch without, add later)
+
+**Recommendation:** Launch MVP with auth + calendar, add payments in Sprint 2.
+```
+
+### Stage 5: Create Handoff Package (30-45 minutes)
+
+**Organize for development team:**
+
+In `E-UI-Roadmap/` folder, create:
+
+1. **`priority-sequence.md`** - What to build when and why
+2. **`scenario-to-epic-mapping.md`** - How WDS scenarios map to dev epics
+3. **`component-inventory.md`** (if Design System enabled) - All components needed
+4. **`open-questions.md`** - Decisions for dev team to make
+
+---
+
+## The Complete PRD Structure
+
+Your finalized PRD in `C-Requirements/` combines all phases:
+
+```markdown
+# Product Requirements Document
+
+## 1. Technical Foundation (from Phase 3)
+
+### Platform Architecture
+- Technology stack decisions
+- Infrastructure approach  
+- Hosting and deployment
+
+### Data Model
+- Core entities and relationships
+- Database schema
+- Data flow diagrams
+
+### Integrations
+- External services (Google Maps, Stripe, etc.)
+- API specifications
+- Authentication providers
+
+### Security & Performance
+- Authentication/authorization approach
+- Data protection
+- Performance requirements
+- Proofs of concept results
+
+## 2. Functional Requirements (from Phase 4)
+
+### Epic 1: User Authentication & Account Management
+**Features:**
+- User registration (Required by: 1.2-Sign-Up)
+- User login (Required by: 1.1-Start-Page, multiple)
+- Password management (Required by: 1.1-Start-Page)
+
+[Detailed specifications for each feature]
+
+### Epic 2: [Next Epic]
+[...]
+
+## 3. Development Roadmap (from Phase 6)
+
+### Priority 1: MVP (Weeks 1-4)
+- Features list with Impact Scores
+- Why these first (references Trigger Map)
+- Timeline estimate
+- Dependencies
+
+### Priority 2: Enhanced Features (Weeks 5-8)
+[...]
+
+## 4. Dependencies & Constraints
+- Technical dependencies between features
+- Design constraints from Phase 4
+- Third-party limitations discovered in Phase 3
+
+## 5. Success Metrics
+- Business goals from Phase 1
+- Feature-specific KPIs
+- How we measure success
+```
+
+---
+
+## Continuous vs. Final Handoff
+
+**The pattern:**
+
+- **Phase 3:** Initial PRD with technical foundation
+- **Phase 4:** PRD grows with each page (step 4E adds requirements)  
+- **Phase 6 (First time):** Organize MVP scope from completed scenarios
+  - Create first handoff package
+  - Development can begin
+- **Phase 4 continues:** More pages designed, more requirements added
+- **Phase 6 (Ongoing):** Update PRD priorities, create new handoff packages
+  - Weekly or bi-weekly updates
+  - Keep dev team synced
+
+**You can run Phase 6 multiple times as design progresses.**
+
+---
+
+## When to Use This Phase
+
+**First PRD Finalization when:**
+- You have MVP-level scenarios complete (enough for dev to start)
+- Core user flows are specified  
+- Critical features are documented
+- Enough work for 2-4 week sprint
+
+**Ongoing PRD Updates as:**
+- Additional scenarios complete
+- New feature areas designed
+- Priorities shift based on learning
+- Sprint planning needs updated scope
+
+**Timeline example:**
+
+```
+Week 1-2: Phase 1-3 (Strategy, Research, Platform foundation)
+Week 3-4: Phase 4 Scenarios 1-3 (Core MVP flows)
+Week 5:   Phase 6 First Finalization
+          └──► PRD v1.0: MVP scope ready
+          └──► Development Sprint 1 begins
+
+Week 6-7: Phase 4 Scenarios 4-6 (Additional features)
+          Phase 5 Design System (extract components)
+Week 8:   Phase 6 Update
+          └──► PRD v1.1: Sprint 2 scope added
+          └──► Development Sprint 2 begins
+
+Week 9+:  Design continues in parallel with development
+          Regular Phase 6 updates for new sprints
+```
+
+**The beauty:** Design doesn't block development. You hand off in waves.
+
+Complete list for test automation:
+
+| Scenario | Object ID | Element Type | Notes |
+|----------|-----------|--------------|-------|
+| 1.1 | `welcome-hero-cta` | Button | Primary action |
+| 1.1 | `welcome-signin-link` | Link | Secondary action |
+| 1.2 | `signin-email-input` | Input | Required field |
+| 1.2 | `signin-error-email` | Error | Validation message |
+
+---
+
+## How It Works
+
+### Review Completeness
+
+Before handoff, verify:
+- All scenarios specified and reviewed
+- Design system covers all components
+- Object IDs assigned throughout
+- Multilingual content complete
+- HTML prototypes validated
+
+### Identify Priorities
+
+With Freyja, map your Trigger Map priorities to development order:
+- Which user triggers are most critical?
+- What's the minimum viable experience?
+- What can wait for later releases?
+
+### Document Technical Context
+
+Capture what developers need to know:
+- Design decisions and their rationale
+- Technical constraints discovered during design
+- Interaction patterns that need special attention
+- Performance considerations
+
+### Create the Handoff
+
+Organize everything into the UI Roadmap folder:
+- Clear priority sequence
+- Complete component inventory
+- Technical notes and open questions
+- Verification checklist
+
+---
+
+## The Handoff Checklist
+
+```markdown
+## Design Handoff Verification
+
+### Product Foundation
+- [ ] Product Brief complete and current
+- [ ] Trigger Map with prioritized users and goals
+- [ ] ICP clearly defined
+
+### Requirements
+- [ ] PRD with technical specifications
+- [ ] Platform architecture documented
+- [ ] Integration requirements listed
+
+### Visual Design
+- [ ] All scenarios have specifications
+- [ ] All pages have Object IDs
+- [ ] States documented (empty, loading, error, success)
+
+### Design System
+- [ ] All components documented
+- [ ] Design tokens defined
+- [ ] Usage guidelines written
+
+### Validation
+- [ ] HTML prototypes created for key scenarios
+- [ ] Stakeholder review complete
+- [ ] Open questions documented
+
+### Ready for Development ✅
+```
+
+---
+
+## When to Use This Phase
+
+**First handoff when:**
+- You have enough scenarios for MVP
+- Core user flows are specified
+- Critical components are documented
+- Developers can start building foundational features
+
+**Ongoing handoffs as:**
+- Each major scenario completes
+- New component patterns emerge
+- Design decisions affect development
+- Sprint planning needs updated priorities
+
+**The rhythm:**
+
+```
+Week 1-2: Design Phase 1-3 (Strategy, Research, Platform)
+Week 3-4: Design Phase 4 Scenarios 1-2 (Core flows)
+         └──► First Handoff: MVP scope
+Week 5-6: Design Phase 4 Scenarios 3-4
+         Design Phase 5 (Components from 1-2)
+         └──► Second Handoff: Additional features
+Week 7+:  Design continues...
+          Development builds in parallel
+          └──► Ongoing handoffs as design progresses
+```
+
+**You DON'T need to finish all design before handing off.**
+
+Development and design work in parallel streams, with regular sync points.
+
+---
+
+## What to Prepare
+
+Bring:
+- Completed scenario specifications (Phase 4)
+- Design System (Phase 5)
+- PRD (Phase 3)
+- Trigger Map priorities (Phase 2)
+
+---
+
+## What Comes Next
+
+Your UI Roadmap enables:
+
+- **Development kickoff** - Clear starting point
+- **Sprint planning** - Prioritized work items
+- **Test automation** - Object ID inventory
+- **QA validation** - Specifications to verify against
+
+---
+
+## Tips for Great Sessions
+
+**Think from dev perspective**
+- What questions will developers have?
+- What decisions can't you make for them?
+- What context will save them time?
+
+**Be explicit about priorities**
+- Not everything is Priority 1
+- Make trade-offs visible
+- Connect priorities to business goals
+
+**Document the unknowns**
+- Open questions are valuable
+- Don't pretend certainty you don't have
+- Let dev team contribute decisions
+
+**Keep it updated**
+- Handoff is ongoing, not one-time
+- Update as design evolves
+- Maintain as source of truth
+
+---
+
+## Integration with BMM
+
+When handing off to BMad Method (BMM) for development:
+
+```
+WDS → E-UI-Roadmap/ → BMM Architecture & Stories
+```
+
+The UI Roadmap provides:
+- Context for architecture decisions
+- Specifications for story creation
+- Priorities for sprint planning
+- Test automation foundations
+
+---
+
+## Example Output
+
+See: `examples/dog-week-patterns/E-UI-Roadmap/` for a complete UI Roadmap from a real project.
+
+---
+
+*Phase 6 of the Whiteport Design Studio method*
+
diff --git a/src/modules/wds/docs/method/wds-method-guide.md b/src/modules/wds/docs/method/wds-method-guide.md
index a1cdddd9..618be59c 100644
--- a/src/modules/wds/docs/method/wds-method-guide.md
+++ b/src/modules/wds/docs/method/wds-method-guide.md
@@ -101,7 +101,7 @@ Transform ideas into detailed visual specifications. Your agent helps you think
 - Component definitions with Object IDs
 - Interaction behaviors and states
 - Multilingual content
-- HTML previews for validation
+- HTML prototypes for validation
 
 ---