initial commit

_bmad/wds/workflows/5-agentic-development/steps-p/1-prototype-setup.md

@@ -0,0 +1,140 @@
+---
+name: '1-prototype-setup'
+description: 'Set up the prototype environment for an entire scenario (one-time setup)'
+
+# File References
+nextStepFile: './2-scenario-analysis.md'
+---
+
+# Step 1: Prototype Setup
+
+## STEP GOAL:
+
+Set up the prototype environment for an entire scenario (one-time setup). This assumes the scenario specification already exists.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on running the initiation dialog, creating folder structure, and setting up demo data
+- 🚫 FORBIDDEN to begin building any pages or components — that is a later step
+- 💬 Approach: Ask the 4 initiation questions, then create the folder structure with user
+- 📋 Skip this phase if scenario already has `data/demo-data.json` and `PROTOTYPE-ROADMAP.md`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Prototype folder structure created with demo data and roadmap
+- 💾 Create demo-data.json and PROTOTYPE-ROADMAP.md
+- 📖 Reference PROTOTYPE-INITIATION-DIALOG.md for exact conversation scripts
+- 🚫 Do not build any pages or UI during this step
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Scenario specification (from scenario-init workflow)
+- Focus: Environment setup — folder structure, demo data, configuration
+- Limits: No page building, no UI work
+- Dependencies: Scenario specification must exist
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. User Requests Scenario Setup
+
+**User says**: "Create interactive prototypes for Scenario [N]: [Scenario Name]"
+
+**Your response**: Follow the **Scenario Initiation Dialog** in `PROTOTYPE-INITIATION-DIALOG.md`
+
+### 2. Run Initiation Dialog
+
+**Ask 4 questions**:
+
+1. **Device Compatibility** (Mobile-Only / Mobile+Tablet / Fully Responsive / Desktop-Only)
+2. **Design Fidelity** (Gray Model / Design System / Figma Integration)
+3. **Languages** (if project supports multiple languages)
+4. **Demo Data** (Create realistic test family data)
+
+**See**: `PROTOTYPE-INITIATION-DIALOG.md` for exact conversation scripts
+
+### 3. Create Prototype Folder Structure
+
+**Actions**:
+
+1. **Create prototype folder**: `[Scenario-Number]-[Scenario-Name]-Prototype/`
+2. **Create all subfolders**:
+   - `data/` - Demo data JSON files
+   - `work/` - Planning/work files (one per page)
+   - `stories/` - Section implementation guides (created just-in-time)
+   - `shared/` - Shared JavaScript (utilities, API abstraction)
+   - `components/` - Reusable UI components
+   - `pages/` - Page-specific scripts (if complex)
+   - `assets/` - Images, icons, etc.
+3. **Create `data/demo-data.json`** with demo family
+4. **Create `PROTOTYPE-ROADMAP.md`** with scenario overview
+5. **Record device compatibility and design approach** in roadmap
+
+**Folder structure created**:
+```
+[Scenario-Number]-[Scenario-Name]-Prototype/
+├── PROTOTYPE-ROADMAP.md
+├── data/
+│   └── demo-data.json
+├── work/              (empty, will be filled per-page)
+├── stories/           (empty, created just-in-time)
+├── shared/            (empty, add as needed)
+├── components/        (empty, add as needed)
+├── pages/             (empty, add if needed)
+└── assets/            (empty, add as needed)
+
+HTML files will be placed in root as they're created.
+```
+
+### 4. Present MENU OPTIONS
+
+Display: "**Select an Option:** [C] Continue to Step 2: Scenario Analysis"
+
+#### Menu Handling Logic:
+- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the prototype folder structure is created with demo data and roadmap will you then load and read fully `{nextStepFile}` to execute.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- Initiation dialog completed (4 questions answered)
+- Prototype folder structure created with all subfolders
+- demo-data.json created with realistic test data
+- PROTOTYPE-ROADMAP.md created with scenario overview
+- Device compatibility and design approach recorded
+
+### ❌ SYSTEM FAILURE:
+- Beginning page building before setup is complete
+- Skipping initiation dialog questions
+- Not creating demo data
+- Not creating the roadmap
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/wds/workflows/5-agentic-development/steps-p/2-scenario-analysis.md

@@ -0,0 +1,130 @@
+---
+name: '2-scenario-analysis'
+description: 'Analyze the entire scenario to identify all logical views and map which scenario steps use which views'
+
+# File References
+nextStepFile: './3-logical-view-breakdown.md'
+---
+
+# Step 2: Scenario Analysis & Logical View Identification
+
+## STEP GOAL:
+
+Analyze the entire scenario to identify all logical views and map which scenario steps use which views. A "logical view" is a conceptual page/screen with multiple states.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on reading all scenario step specs, identifying logical views, getting user confirmation, and creating the logical view map
+- 🚫 FORBIDDEN to begin building any views or breaking them into sections — that is the next step
+- 💬 Approach: Present logical view mapping to user for review and confirmation
+- 📋 Multiple scenario steps can use the same logical view with different states
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Complete logical view map with all views identified and confirmed by user
+- 💾 Create `work/Logical-View-Map.md` with view mapping and build order
+- 📖 Read all scenario step specification files
+- 🚫 Do not begin section breakdown or implementation
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Prototype folder structure from Step 1; all scenario step specifications
+- Focus: Identifying logical views and mapping scenario steps to views
+- Limits: No section breakdown, no implementation
+- Dependencies: Step 1 must be complete (prototype folder exists)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Read All Scenario Step Specifications
+
+**Actions**:
+1. List all scenario step folders in `../[Scenario]/`
+2. Read each `[Step].md` specification file
+3. Note step names, purposes, and any "inherit from" or "base page" references
+
+### 2. Identify Logical Views
+
+For each scenario step, determine:
+- Is this a **new logical view** (new page/screen)?
+- Or does it **reuse an existing logical view** (same page, different state)?
+
+**Key indicators of SAME logical view**:
+- Spec says "inherit from [other step]"
+- Spec says "same structure as [other step]"
+- Same page name (e.g., "Family Page" in 1.5, 1.7, 1.9)
+- Overlay/modal/confirmation on existing page
+
+**Key indicators of NEW logical view**:
+- Completely different page structure
+- Different purpose and user context
+- No reference to inheriting from another step
+
+Present the mapping to user for confirmation.
+
+### 3. User Reviews & Confirms Mapping
+
+**Wait for response**
+
+**If user says "N"**:
+- Ask what needs adjustment
+- Update logical view mapping
+- Re-present for confirmation
+
+**If user says "Y"**: Proceed to create the map document
+
+### 4. Create Logical View Map Document
+
+Create `work/Logical-View-Map.md` with view details, build order, and notes.
+
+### 5. Present MENU OPTIONS
+
+Display: "**Select an Option:** [C] Continue to Step 3: Logical View Breakdown"
+
+#### Menu Handling Logic:
+- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the logical view mapping is confirmed by user and the map document is created will you then load and read fully `{nextStepFile}` to execute.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- All scenario step specifications read
+- Logical views identified with correct grouping
+- User confirmed the mapping
+- Logical-View-Map.md created with build order
+
+### ❌ SYSTEM FAILURE:
+- Beginning to build views before analysis is complete
+- Not reading all scenario step specifications
+- Not getting user confirmation on the mapping
+- Not creating the map document
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/wds/workflows/5-agentic-development/steps-p/3-logical-view-breakdown.md

@@ -0,0 +1,128 @@
+---
+name: '3-logical-view-breakdown'
+description: 'Select a logical view to build and break it into implementable sections'
+
+# File References
+nextStepFile: './4a-announce-and-gather.md'
+---
+
+# Step 3: Logical View Selection & Section Breakdown
+
+## STEP GOAL:
+
+Select a logical view to build and break it into implementable sections. This creates the work plan, but NOT the story files yet (those are created just-in-time).
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on confirming view selection, gathering objects from specs, proposing section breakdown, and creating the work file
+- 🚫 FORBIDDEN to create story files or begin implementing — those are later steps
+- 💬 Approach: Collaboratively break down the view into 4-8 sections with user approval
+- 📋 Group objects logically, consider all states, estimate time per section
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Work file created with approved section breakdown
+- 💾 Create `work/[View-Name]-Work.yaml` with section plan
+- 📖 Read all scenario step specs that use the selected logical view
+- 🚫 Do not create story files or write any HTML/JS
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Logical view map from Step 2; all scenario step specifications
+- Focus: Section breakdown planning — objects, grouping, estimation
+- Limits: No story files, no implementation
+- Dependencies: Step 2 must be complete (logical view map exists)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Confirm Logical View Selection
+
+**User says**: "Let's build [Logical View Name]" or selects from list
+
+### 2. Gather All Specifications
+
+**Actions**:
+
+1. **Read all scenario step specs** that use this logical view
+2. **Extract all Object IDs** across all states
+3. **Identify unique objects** vs **state-specific objects**
+4. **Note functional requirements** from all specs
+
+Present objects to user for confirmation.
+
+### 3. User Confirms Objects
+
+**If user says "N"**: Ask what's missing or should be removed, update, re-present
+**If user says "Y"**: Continue to section breakdown
+
+### 4. Propose Section Breakdown
+
+**Actions**:
+
+1. **Group objects logically** into 4-8 sections
+2. **Consider all states** when grouping
+3. **Estimate time** per section
+
+Present breakdown to user for approval.
+
+### 5. User Reviews Section Breakdown
+
+**If user says "N"**: Ask what needs adjustment, revise, re-present
+
+### 6. Create Work File
+
+**When user approves**: Create `work/[View-Name]-Work.yaml` with section details, statuses, and estimates.
+
+### 7. Present MENU OPTIONS
+
+Display: "**Select an Option:** [C] Continue to Step 4a: Announce and Gather"
+
+#### Menu Handling Logic:
+- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the section breakdown is approved and work file is created will you then load and read fully `{nextStepFile}` to execute.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- Logical view selection confirmed
+- All objects extracted from specifications
+- User confirmed object list
+- Section breakdown approved (4-8 sections)
+- Work file created with section plan
+
+### ❌ SYSTEM FAILURE:
+- Creating story files before work file is approved
+- Beginning implementation before planning
+- Not getting user approval on section breakdown
+- Not extracting all objects from specs
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/wds/workflows/5-agentic-development/steps-p/4a-announce-and-gather.md

@@ -0,0 +1,111 @@
+---
+name: '4a-announce-and-gather'
+description: 'Announce which section is being built and gather all requirements from specifications'
+
+# File References
+nextStepFile: './4b-create-story-file.md'
+---
+
+# Step 4a: Announce Section & Gather Requirements
+
+## STEP GOAL:
+
+Announce which section we're building and gather all requirements from specifications. Prepare to create the story file by collecting all necessary information.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on announcing the section, reading relevant specs, and gathering requirements
+- 🚫 FORBIDDEN to create the story file or begin implementation — those are the next steps
+- 💬 Approach: Announce what will be built, then systematically gather all requirements
+- 📋 Extract object IDs, descriptions, state behavior, functional requirements, and design references
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 All requirements gathered from specifications for this section
+- 💾 Requirements ready for story file creation
+- 📖 Reference the work file and all relevant scenario step specifications
+- 🚫 Do not create story files or write code
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Work file from Step 3; all scenario step specifications
+- Focus: Requirements gathering for the current section
+- Limits: No story file creation, no implementation
+- Dependencies: Work file must exist (Step 3 complete), previous section approved (or this is Section 1)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Announce Section
+
+Present to user what section is being built, including features, object IDs, states covered, and estimated time.
+
+### 2. Read Relevant Specifications
+
+**Actions**:
+
+1. Open work file: `work/[View]-Work.yaml`
+2. Find Section [N] details
+3. Read all scenario step specifications that need this section
+4. For each spec, extract:
+   - Object IDs for this section
+   - Object descriptions (type, label, behavior)
+   - State-specific behavior
+   - Functional requirements
+   - Design references
+
+### 3. Gather Requirements Summary
+
+Present requirements summary to user including object count, specifications referenced, states to handle, functions needed, and design tokens.
+
+### 4. Present MENU OPTIONS
+
+Display: "**Select an Option:** [C] Continue to Step 4b: Create Story File"
+
+#### Menu Handling Logic:
+- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN all requirements are gathered from specifications will you then load and read fully `{nextStepFile}` to execute.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- Section announced with clear scope
+- All relevant specifications read
+- Object IDs, behaviors, and states extracted
+- Requirements summary presented to user
+
+### ❌ SYSTEM FAILURE:
+- Creating story file before requirements are gathered
+- Not reading all relevant specifications
+- Missing object IDs or state behaviors
+- Beginning implementation prematurely
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/wds/workflows/5-agentic-development/steps-p/4b-create-story-file.md

@@ -0,0 +1,110 @@
+---
+name: '4b-create-story-file'
+description: 'Create the focused story file for this section with all implementation details'
+
+# File References
+nextStepFile: './4c-implement-section.md'
+---
+
+# Step 4b: Create Story File
+
+## STEP GOAL:
+
+Create the focused story file for this section with all implementation details. Use the story template to create complete, clear instructions for implementation.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on creating the story file with objects, HTML structure, Tailwind classes, JavaScript requirements, demo data, and acceptance criteria
+- 🚫 FORBIDDEN to begin implementing — that is the next step
+- 💬 Approach: Create comprehensive story file, then offer user review or proceed to implementation
+- 📋 Story file must include both agent-verifiable (Puppeteer) and user-evaluable (qualitative) criteria
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Complete story file created with all implementation instructions
+- 💾 Create `stories/[View].[N]-[section-name].md`
+- 📖 Reference requirements gathered in Step 4a
+- 🚫 Do not write any HTML, CSS, or JavaScript code
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Requirements gathered in Step 4a; work file; specifications
+- Focus: Story file creation — complete implementation instructions
+- Limits: No code implementation
+- Dependencies: Step 4a must be complete (requirements gathered)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Create Story File
+
+Create `stories/[View].[N]-[section-name].md` with:
+- Purpose, specifications reference
+- All objects with type, label, behavior, states, and spec reference
+- HTML structure to build
+- Tailwind classes to use
+- JavaScript requirements (functions and state handling)
+- Demo data requirements
+- Acceptance criteria (agent-verifiable and user-evaluable)
+- Test instructions (Puppeteer self-verification and user qualitative review)
+
+### 2. Present Story to User
+
+Present summary and offer user the choice to review the story first or proceed to implementation.
+
+### 3. Handle User Response
+
+**If user says "review"**: Show key sections, answer questions, make adjustments, ask if ready to implement.
+**If user says "implement"** or "Y": Proceed to next step.
+
+### 4. Present MENU OPTIONS
+
+Display: "**Select an Option:** [C] Continue to Step 4c: Implement Section"
+
+#### Menu Handling Logic:
+- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the story file is created and user is ready to proceed will you then load and read fully `{nextStepFile}` to execute.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- Story file created with complete implementation instructions
+- All objects defined with types, behaviors, and states
+- Acceptance criteria include both agent-verifiable and user-evaluable items
+- User approved or chose to proceed
+
+### ❌ SYSTEM FAILURE:
+- Beginning implementation without a story file
+- Missing objects or acceptance criteria
+- Not offering user the chance to review
+- Creating incomplete story file
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/wds/workflows/5-agentic-development/steps-p/4c-implement-section.md

@@ -0,0 +1,139 @@
+---
+name: '4c-implement-section'
+description: 'Implement the section following the story file precisely'
+
+# File References
+nextStepFile: './4d-present-for-testing.md'
+---
+
+# Step 4c: Implement Section
+
+## STEP GOAL:
+
+Implement the section following the story file precisely. Linear code generation is the task.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on implementing the HTML structure, adding object IDs, Tailwind classes, JavaScript, and placeholders per the story file
+- 🚫 FORBIDDEN to deviate from the story file instructions or add unplanned features
+- 💬 Approach: Follow the story file precisely, implementing section by section
+- 📋 For Section 1, create new HTML file; for subsequent sections, update existing file
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Section implemented with all objects, styles, and JavaScript per story file
+- 💾 HTML file created/updated with section implementation
+- 📖 Follow story file instructions precisely
+- 🚫 Do not add features not in the story file
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Story file from Step 4b; page template (for Section 1)
+- Focus: Code implementation following story file
+- Limits: Only implement what the story file specifies
+- Dependencies: Step 4b must be complete (story file exists and approved)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Begin Implementation
+
+Announce implementation start.
+
+### 2. Create or Update HTML File
+
+**For Section 1 ONLY**:
+- Create new HTML file from `templates/page-template.html`
+- Name it: `[View].html`
+- Place in prototype root folder
+
+**For Sections 2+**:
+- Open existing `[View].html` file
+- Find insertion point (after previous section or before placeholder)
+
+### 3. Add HTML Structure
+
+**Follow story file precisely**:
+
+1. Add HTML structure with Tailwind classes from story
+2. Add all Object IDs on interactive elements
+3. Add state-specific classes/attributes
+4. Add placeholder content where specified
+
+### 4. Add JavaScript
+
+**If section needs JavaScript**:
+
+1. Add functions specified in story file
+2. Add event listeners for interactive elements
+3. Add state handling logic
+4. Add console logging for debugging
+5. Load demo data from `data/demo-data.json`
+
+### 5. Add Placeholder for Remaining Sections
+
+**If more sections remain**: Add a placeholder div at the bottom indicating the next section.
+
+### 6. Final Check
+
+**Before presenting to user, verify**:
+- [ ] All Object IDs from story file are present
+- [ ] Tailwind classes match story file
+- [ ] JavaScript functions implemented
+- [ ] Console logging added
+- [ ] Code is clean and readable
+- [ ] No syntax errors
+
+### 7. Present MENU OPTIONS
+
+Display: "**Select an Option:** [C] Continue to Step 4d: Present for Testing"
+
+#### Menu Handling Logic:
+- IF C: Update design log, then load, read entire file, then execute {nextStepFile}
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the section is fully implemented per the story file will you then load and read fully `{nextStepFile}` to execute.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- All Object IDs from story file present
+- Tailwind classes match story file
+- JavaScript functions implemented
+- Code is clean, readable, and error-free
+- Placeholder for remaining sections added (if applicable)
+
+### ❌ SYSTEM FAILURE:
+- Deviating from story file instructions
+- Missing Object IDs
+- Adding unplanned features
+- Syntax errors in code
+- Not following story file precisely
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/wds/workflows/5-agentic-development/steps-p/4d-present-for-testing.md

@@ -0,0 +1,127 @@
+---
+name: '4d-present-for-testing'
+description: 'Present the implemented section to user with clear test instructions after agent self-verification'
+---
+
+# Step 4d: Present Section for Testing
+
+## STEP GOAL:
+
+Present the implemented section to user with clear test instructions after performing agent self-verification.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on agent self-verification with Puppeteer, presenting implementation, and requesting qualitative user review
+- 🚫 FORBIDDEN to skip self-verification before presenting to user
+- 💬 Approach: Verify first, then present with clear test instructions for qualitative aspects
+- 📋 Only present to user when all agent-verifiable criteria pass
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Agent self-verification complete, section presented to user for qualitative review
+- 💾 Record verification results
+- 📖 Reference story file acceptance criteria for verification
+- 🚫 Do not present to user until self-verification passes
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Implemented section from Step 4c; story file acceptance criteria
+- Focus: Self-verification and user presentation
+- Limits: No code changes during presentation (unless self-verification fails)
+- Dependencies: Step 4c must be complete (section implemented)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 0. Agent Self-Verification (Before Presenting)
+
+**BEFORE presenting to the user, verify your own work with Puppeteer.**
+
+See: [Inline Testing Guide](../data/guides/INLINE-TESTING-GUIDE.md) for full methodology.
+
+**Actions**:
+
+1. Open the page in browser using Puppeteer
+2. Set viewport to target device width
+3. Verify each agent-verifiable criterion from the story file
+4. Narrate findings using the pass/fail pattern (actual vs expected)
+5. Fix any failures and re-verify
+
+**If modifying existing features**: Compare against baseline captured before implementation. Confirm only intended changes occurred.
+
+**Only proceed to Step 1 when all agent-verifiable criteria pass.**
+
+### 1. Present Implementation
+
+Present what was built, listing new features with Object IDs and files updated.
+
+### 2. Present Verification Results & Request Qualitative Review
+
+Present Puppeteer verification results, then ask user to evaluate qualitative aspects:
+- Feel the flow: Does the interaction feel natural?
+- Visual hierarchy: Does your eye go to the right place first?
+- Clarity: Is it immediately clear what to do?
+- Consistency: Does this section feel like it belongs with the rest?
+
+### 3. Wait for User Feedback
+
+**User will respond with one of**:
+- Approved: "Looks good!" / "Y" / "Perfect!" -> Go to `4g-section-approved.md`
+- Issue: "The button doesn't..." / "I see a problem with..." -> Go to `4e-handle-issue.md`
+- Improvement: "Could we make it..." / "What if we..." -> Go to `4f-handle-improvement.md`
+
+### 4. Present MENU OPTIONS
+
+Display based on user feedback:
+- **If approved**: "[C] Continue to Step 4g: Section Approved"
+- **If issue reported**: "[C] Continue to Step 4e: Handle Issue"
+- **If improvement suggested**: "[C] Continue to Step 4f: Handle Improvement"
+
+#### Menu Handling Logic:
+- IF C: Update design log, then load, read entire file, then execute the appropriate next step file
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN user has provided feedback will you then load and read fully the appropriate next step file to execute.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- Agent self-verification completed before presenting
+- All agent-verifiable criteria pass
+- Implementation presented clearly with Object IDs
+- Qualitative review requested from user
+- User feedback captured and routed correctly
+
+### ❌ SYSTEM FAILURE:
+- Presenting to user without self-verification
+- Skipping Puppeteer verification
+- Not requesting qualitative review
+- Routing user feedback incorrectly
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/wds/workflows/5-agentic-development/steps-p/4e-handle-issue.md

@@ -0,0 +1,127 @@
+---
+name: '4e-handle-issue'
+description: 'Fix reported issues in the section, document, and re-verify'
+---
+
+# Step 4e: Handle Issue
+
+## STEP GOAL:
+
+Fix reported issues in the section. Identify, fix, document, and re-test.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on acknowledging the issue, fixing it, updating the story file with learning, re-verifying, and re-presenting
+- 🚫 FORBIDDEN to add unrelated improvements while fixing an issue
+- 💬 Approach: Acknowledge, analyze, fix, document the learning, then re-verify
+- 📋 Update story file with what was wrong, why, and what was learned
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Issue fixed, documented in story file, re-verified with Puppeteer
+- 💾 Update story file with changes made section
+- 📖 Reference the reported issue and story file
+- 🚫 Do not add unrelated features or improvements
+
+## CONTEXT BOUNDARIES:
+
+- Available context: User's issue report; current implementation; story file
+- Focus: Issue identification, fix, documentation, re-verification
+- Limits: Only fix the reported issue — no scope expansion
+- Dependencies: User has reported an issue (from Step 4d)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Acknowledge Issue
+
+Acknowledge the specific problem, analyze why it is happening, and describe the fix.
+
+### 2. Fix the Issue
+
+**Actions**:
+
+1. Identify the root cause
+2. Make the specific fix in the code
+3. Test the fix mentally (does it solve the problem?)
+4. Keep the fix focused and local
+
+### 3. Update Story File with Learning
+
+Add to story file `stories/[View].[N]-[section-name].md`:
+- Problem: What was wrong
+- Root cause: Why it happened
+- Solution: What was changed
+- Code change: Specific change made
+- Learned: What to do differently next time
+
+### 3.5. Re-Verify with Puppeteer
+
+After fixing the issue, run Puppeteer verification before re-presenting:
+
+1. Open page in browser
+2. Verify the fix resolves the reported issue
+3. Verify no regressions on previously passing criteria
+4. Narrate findings with pass/fail
+
+**Only proceed to re-present when all criteria pass.**
+
+### 4. Re-present for Testing
+
+Present the fix, explain what changed, why it works now, and request re-testing.
+
+**Note**: This may loop multiple times until issue is resolved. After re-presenting, route back to Step 4d for user feedback.
+
+### 5. Present MENU OPTIONS
+
+Display: "**Select an Option:** [C] Continue to Step 4d: Present for Testing (re-test)"
+
+#### Menu Handling Logic:
+- IF C: Update design log, then load, read entire file, then execute `./4d-present-for-testing.md`
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the issue is fixed and re-verified will you then loop back to present for testing again.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- Issue acknowledged and analyzed
+- Root cause identified
+- Focused fix implemented
+- Story file updated with learning
+- Re-verified with Puppeteer before re-presenting
+
+### ❌ SYSTEM FAILURE:
+- Not acknowledging or analyzing the issue
+- Fix does not address root cause
+- Not updating story file with learning
+- Skipping re-verification
+- Adding unrelated improvements during fix
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/wds/workflows/5-agentic-development/steps-p/4f-handle-improvement.md

@@ -0,0 +1,122 @@
+---
+name: '4f-handle-improvement'
+description: 'Implement user improvement suggestion, capture learning, and consider specification update'
+---
+
+# Step 4f: Handle Improvement Suggestion
+
+## STEP GOAL:
+
+Implement user's improvement suggestion and capture learning. Enhance the implementation based on user feedback.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on acknowledging the improvement, implementing it, updating the story file, considering spec updates, and re-presenting
+- 🚫 FORBIDDEN to reject valid improvement suggestions without explanation
+- 💬 Approach: Acknowledge, implement, document, consider spec update, re-present
+- 📋 Ask user if the improvement should be reflected in the specification
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Improvement implemented, documented in story file, spec update considered
+- 💾 Update story file with improvement details
+- 📖 Reference the user's suggestion
+- 🚫 Keep changes focused on the improvement
+
+## CONTEXT BOUNDARIES:
+
+- Available context: User's improvement suggestion; current implementation; story file
+- Focus: Implementing the improvement and capturing the learning
+- Limits: Only implement the suggested improvement
+- Dependencies: User has suggested an improvement (from Step 4d)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Acknowledge Improvement
+
+Acknowledge the suggestion, describe current approach, proposed improvement, and benefit.
+
+### 2. Implement Improvement
+
+**Actions**:
+
+1. Understand the user's suggestion
+2. Implement the improvement in the code
+3. Ensure it enhances UX or code quality
+4. Keep changes focused
+
+### 3. Update Story File with Improvement
+
+Add to story file `stories/[View].[N]-[section-name].md`:
+- Original: What it was
+- Improved to: What it is now
+- Reason: Why it is better
+- Impact: How it improves UX/code
+- Learned: Pattern to use in future
+
+### 4. Consider Specification Update
+
+Ask user if the improvement should be reflected in the specification for future work.
+
+**If user says "Y"**: Note which spec files to update and what should be added.
+**If user says "N"**: Learning is captured in story file for reference.
+
+### 5. Re-present for Testing
+
+Present the improvement, explain what changed, why it is better, and request re-testing.
+
+After re-presenting, route back to Step 4d for user feedback.
+
+### 6. Present MENU OPTIONS
+
+Display: "**Select an Option:** [C] Continue to Step 4d: Present for Testing (re-test)"
+
+#### Menu Handling Logic:
+- IF C: Update design log, then load, read entire file, then execute `./4d-present-for-testing.md`
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the improvement is implemented and documented will you then loop back to present for testing again.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- Improvement acknowledged and understood
+- Implementation enhances UX or code quality
+- Story file updated with improvement details
+- Specification update considered
+- Re-presented for testing
+
+### ❌ SYSTEM FAILURE:
+- Rejecting valid improvement without explanation
+- Not documenting the improvement in story file
+- Not asking about specification update
+- Implementing something different from what was suggested
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/wds/workflows/5-agentic-development/steps-p/4g-section-approved.md

@@ -0,0 +1,122 @@
+---
+name: '4g-section-approved'
+description: 'Finalize section approval, update status, and determine next action'
+
+# File References
+nextStepFile: './5-finalization.md'
+---
+
+# Step 4g: Section Approved & Next Steps
+
+## STEP GOAL:
+
+Finalize section approval and determine next action. Update status and move forward.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on updating story file status, updating work file, checking progress, and routing to next section or finalization
+- 🚫 FORBIDDEN to begin next section without updating status files
+- 💬 Approach: Celebrate completion, update records, present progress and next steps
+- 📋 If more sections remain, loop back to Step 4a; if all complete, proceed to Step 5
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Section status updated, progress reported, next action determined
+- 💾 Update story file status and work file
+- 📖 Reference work file for section progress tracking
+- 🚫 Do not skip status updates
+
+## CONTEXT BOUNDARIES:
+
+- Available context: Approved section; work file with section plan
+- Focus: Status updates and routing
+- Limits: No new implementation
+- Dependencies: User has approved the section (from Step 4d)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Section Approved
+
+Acknowledge user approval and announce status update.
+
+### 2. Update Story File Status
+
+Update `stories/[View].[N]-[section-name].md` with:
+- Status: Complete
+- Completed date
+- Implementation summary (objects, issues, improvements, time)
+
+### 3. Update Work File
+
+Update `work/[View]-Work.yaml` with section status, completed date, actual time, issues encountered, and improvements made.
+
+### 4. Check Progress
+
+Count sections: total, completed, remaining.
+
+### 5a. If More Sections Remain
+
+Present progress, announce next section, and ask if ready to continue.
+
+**If user says "Y"**: Go back to **Step 4a** (`4a-announce-and-gather.md`)
+**If user says "N"** or wants to pause: Save state and acknowledge pause.
+
+### 5b. If All Sections Complete
+
+Announce completion of all sections and present summary of files created and states covered. Suggest proceeding to Phase 5 for integration testing.
+
+### 6. Present MENU OPTIONS
+
+Display based on status:
+- **If more sections**: "[C] Continue to Step 4a: Announce and Gather (next section)"
+- **If all complete**: "[C] Continue to Step 5: Finalization"
+
+#### Menu Handling Logic:
+- IF C (more sections): Update design log, then load, read entire file, then execute `./4a-announce-and-gather.md`
+- IF C (all complete): Update design log, then load, read entire file, then execute {nextStepFile}
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN status files are updated and user has chosen to continue will you then load and read fully the appropriate next step file to execute.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- Story file status updated to complete
+- Work file updated with section status
+- Progress reported to user
+- Correct routing (next section or finalization)
+
+### ❌ SYSTEM FAILURE:
+- Not updating story file status
+- Not updating work file
+- Skipping progress report
+- Routing incorrectly (wrong next step)
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.

_bmad/wds/workflows/5-agentic-development/steps-p/5-finalization.md

@@ -0,0 +1,137 @@
+---
+name: '5-finalization'
+description: 'Complete integration test and final approval for the logical view'
+
+# File References
+activityWorkflowFile: '../workflow-prototyping.md'
+---
+
+# Step 5: Finalization
+
+## STEP GOAL:
+
+Complete integration test and final approval for the logical view.
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+### Universal Rules:
+
+- 🛑 NEVER generate content without user input
+- 📖 CRITICAL: Read the complete step file before taking any action
+- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Role Reinforcement:
+
+- ✅ You are an Implementation Partner guiding structured development activities
+- ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role
+- ✅ We engage in collaborative dialogue, not command-response
+- ✅ You bring software development methodology expertise, user brings domain knowledge and codebase familiarity
+- ✅ Maintain clear and structured tone throughout
+
+### Step-Specific Rules:
+
+- 🎯 Focus only on announcing completion, running integration tests across all states, handling final issues, and presenting the complete logical view
+- 🚫 FORBIDDEN to add new sections or features — only test and fix integration issues
+- 💬 Approach: Comprehensive integration testing across all states with user
+- 📋 All states must work correctly before marking the logical view as complete
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Integration test complete, all states working, logical view approved
+- 💾 Final status recorded in work files and story files
+- 📖 Reference logical view map for all states that need testing
+- 🚫 Do not add new features — only fix integration issues
+
+## CONTEXT BOUNDARIES:
+
+- Available context: All completed sections; work file; logical view map; all story files
+- Focus: Integration testing across all states
+- Limits: No new features, only integration fixes
+- Dependencies: All sections must be approved (Step 4g complete for all)
+
+## Sequence of Instructions (Do not deviate, skip, or optimize)
+
+### 1. Announce Completion
+
+Present all completed sections, files created, and states covered.
+
+### 2. Integration Test Instructions
+
+Provide test instructions for each state:
+- Clear browser data between states
+- Actions to trigger each state
+- Expected results for each state
+
+**Check**:
+- All Object IDs present
+- State transitions work smoothly
+- No console errors
+- Responsive at target device width
+
+### 3. Handle Final Issues or Approve
+
+**If user reports issues**: Fix issues, update story files with learnings, update specifications if needed, re-test, loop until approved.
+
+**If user approves**: Present complete summary including:
+- View name and HTML file
+- Sections completed count
+- Object IDs implemented count
+- States working count
+- Device optimization
+- Quality checklist (all items checked)
+- All files created
+
+Present options:
+- Build another logical view in this scenario?
+- Start a new scenario?
+- Refine this view?
+
+### 4. Scenario Completion Check
+
+When all logical views complete, review `work/Logical-View-Map.md`:
+- Are all logical views built?
+- Are all scenario steps covered?
+- Are all states working?
+
+If YES: Scenario prototype complete!
+
+### 5. Present MENU OPTIONS
+
+Display: "**Select an Option:** [M] Return to Activity Menu"
+
+#### Menu Handling Logic:
+- IF M: Update design log, then load, read entire file, then execute {activityWorkflowFile}
+- IF Any other comments or queries: help user respond then [Redisplay Menu Options]
+
+#### EXECUTION RULES:
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed when user selects 'M'
+- User can chat or ask questions - always respond and then redisplay menu options
+
+## CRITICAL STEP COMPLETION NOTE
+
+ONLY WHEN the integration test passes and logical view is approved will you then load and read fully `{activityWorkflowFile}` to execute.
+
+---
+
+## 🚨 SYSTEM SUCCESS/FAILURE METRICS
+
+### ✅ SUCCESS:
+- All sections complete and integrated
+- All states tested and working
+- All Object IDs present
+- Responsive at target device width
+- No console errors
+- Quality checklist fully checked
+- Complete summary presented to user
+
+### ❌ SYSTEM FAILURE:
+- Not testing all states
+- Skipping integration test
+- Not presenting complete summary
+- Leaving console errors unresolved
+- Not checking scenario completion status
+
+**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.