@devo-bmad-custom/agent-orchestration 1.0.2 → 1.0.3

package/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-11-component-strategy.md

@@ -1,165 +1,165 @@
-# Step 11: Component Strategy
-
-Define component library strategy and design custom components not covered by the design system.
-
-## COMPONENT STRATEGY SEQUENCE
-
-### 1. Analyze Design System Coverage
-
-"Based on our chosen design system [design system from step 6], let's identify what components are already available and what we need to create custom.
-
-**Available from Design System:**
-[List of components available in chosen design system]
-
-**Components Needed for {{project_name}}:**
-Looking at our user journeys and design direction, we need:
-
-- [Component need 1 from journey analysis]
-- [Component need 2 from design requirements]
-- [Component need 3 from core experience]
-
-**Gap Analysis:**
-
-- [Gap 1 - needed but not available]
-- [Gap 2 - needed but not available]"
-
-### 2. Design Custom Components
-
-For each custom component needed, first ask:
-
-"**[Component Name] — Let's define its Atomic classification:**
-
-Using Atomic Design, every component maps to a specific tier:
-
-- **Atom** — A single logicless UI element (Button, Icon, Input, Label). Must be a stateless pure function receiving only props.
-- **Molecule** — 2+ atoms composed together (SearchBar = Input + Button). Must be stateless/dumb, receives data via props only.
-- **Organism** — A complex section with its own state or data-fetching. May consume Context or call hooks.
-
-For [Component Name]:
-
-- Which tier does this belong to? (Atom / Molecule / Organism)
-- **Purpose:** What does this component do for users?
-- **Content:** What information or data does it display?
-- **Actions:** What can users do with this component?
-- **States:** What different states does it have? (default, hover, active, disabled, error, etc.)
-- **Variants:** Are there different sizes or styles needed?
-- **Accessibility:** What ARIA labels and keyboard support (tabIndex, Enter/Space) needed?
-
-Let's walk through each custom component systematically."
-
-### 3. Document Component Specifications
-
-Use this template for each component:
-
-```markdown
-### [Component Name] — [Atom | Molecule | Organism]
-
-**Atomic Tier:** [Atom | Molecule | Organism]
-**Data Pattern:** [Props-only (dumb) | Fetches via hook (smart)]
-**Purpose:** [Clear purpose statement]
-**Usage:** [When and how to use]
-**Composition:** [For Molecules: list constituent Atoms. For Organisms: list Molecules/Atoms used]
-**Composition Check:** [Which existing Atoms/Molecules were evaluated and why they could/could not be reused]
-**States:** [All possible states with descriptions]
-**Variants:** [Different sizes/styles if applicable]
-**Accessibility:** [ARIA labels, keyboard navigation, tabIndex, Enter/Space keypresses where appropriate]
-**Content Guidelines:** [What content works best]
-**Interaction Behavior:** [How users interact]
-```
-
-### 4. Define Component Strategy
-
-"**Component Strategy:**
-
-**Foundation Components:** (from design system)
-
-- [Foundation component 1]
-- [Foundation component 2]
-
-**Custom Components:** (designed in this step)
-
-- [Custom component 1 with rationale]
-- [Custom component 2 with rationale]
-
-**Implementation Approach:**
-
-- Build custom components using design system tokens
-- Ensure consistency with established patterns
-- Follow accessibility best practices
-- Create reusable patterns for common use cases"
-
-### 5. Plan Implementation Roadmap
-
-"**Implementation Roadmap:**
-
-**Phase 1 - Core Components:**
-
-- [Component 1] - needed for [critical flow]
-- [Component 2] - needed for [critical flow]
-
-**Phase 2 - Supporting Components:**
-
-- [Component 3] - enhances [user experience]
-- [Component 4] - supports [design pattern]
-
-**Phase 3 - Enhancement Components:**
-
-- [Component 5] - optimizes [user journey]
-- [Component 6] - adds [special feature]
-
-This roadmap helps prioritize development based on user journey criticality."
-
-### 6. Generate Component Strategy Content
-
-When saving to document, append these sections:
-
-```markdown
-## Component Strategy
-
-### Design System Components
-
-[Analysis of available design system components based on conversation — list which design system components will be used AS-IS without modification]
-
-### Custom Components
-
-> **Classification Rule:** All custom components MUST be categorized under exactly ONE of the three Atomic Design tiers below. Components that span tiers must be split. Execution agents must reject any component that does not fit cleanly.
-
-#### Atoms (Logicless, Stateless)
-
-[Atom component specifications from conversation — each using the component template above]
-
-#### Molecules (Stateless Compositions of Atoms)
-
-[Molecule component specifications from conversation — each listing its constituent Atoms]
-
-#### Organisms (Stateful or Context-Consuming)
-
-[Organism component specifications from conversation — each listing its constituent Molecules/Atoms and the data it fetches or the Context it consumes]
-
-### Composition Audit
-
-> **Mandate:** Before any new component was defined above, the existing component library was evaluated. This section documents that check.
-
-| Component Name       | Existing Component Evaluated | Outcome                                 |
-| -------------------- | ---------------------------- | --------------------------------------- |
-| [New component name] | [Existing component checked] | [Reused / Modified / New — explain why] |
-
-### Component Implementation Strategy
-
-[Component implementation strategy based on conversation]
-
-### Implementation Roadmap
-
-[Implementation roadmap based on conversation — ordered by user journey criticality, not implementation convenience]
-```
-
-### 7. Auto-Save and Advance
-
-Without presenting a menu or waiting for user input:
-
-- Append the final content to `{planning_artifacts}/ux-design-specification.md`
-- Update frontmatter: append step to end of stepsCompleted array
-- Announce: `"✅ Component Strategy saved. Advancing to UX Patterns..."`
-- Immediately load and execute: `{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-12-ux-patterns.md`
-
-> **HALT ONLY IF:** A component cannot be classified into any Atomic tier (Atom/Molecule/Organism). In that case, ask once: "I couldn't classify [component name] — can you clarify its scope and responsibilities?" Then continue without further gates.
+# Step 11: Component Strategy
+
+Define component library strategy and design custom components not covered by the design system.
+
+## COMPONENT STRATEGY SEQUENCE
+
+### 1. Analyze Design System Coverage
+
+"Based on our chosen design system [design system from step 6], let's identify what components are already available and what we need to create custom.
+
+**Available from Design System:**
+[List of components available in chosen design system]
+
+**Components Needed for {{project_name}}:**
+Looking at our user journeys and design direction, we need:
+
+- [Component need 1 from journey analysis]
+- [Component need 2 from design requirements]
+- [Component need 3 from core experience]
+
+**Gap Analysis:**
+
+- [Gap 1 - needed but not available]
+- [Gap 2 - needed but not available]"
+
+### 2. Design Custom Components
+
+For each custom component needed, first ask:
+
+"**[Component Name] — Let's define its Atomic classification:**
+
+Using Atomic Design, every component maps to a specific tier:
+
+- **Atom** — A single logicless UI element (Button, Icon, Input, Label). Must be a stateless pure function receiving only props.
+- **Molecule** — 2+ atoms composed together (SearchBar = Input + Button). Must be stateless/dumb, receives data via props only.
+- **Organism** — A complex section with its own state or data-fetching. May consume Context or call hooks.
+
+For [Component Name]:
+
+- Which tier does this belong to? (Atom / Molecule / Organism)
+- **Purpose:** What does this component do for users?
+- **Content:** What information or data does it display?
+- **Actions:** What can users do with this component?
+- **States:** What different states does it have? (default, hover, active, disabled, error, etc.)
+- **Variants:** Are there different sizes or styles needed?
+- **Accessibility:** What ARIA labels and keyboard support (tabIndex, Enter/Space) needed?
+
+Let's walk through each custom component systematically."
+
+### 3. Document Component Specifications
+
+Use this template for each component:
+
+```markdown
+### [Component Name] — [Atom | Molecule | Organism]
+
+**Atomic Tier:** [Atom | Molecule | Organism]
+**Data Pattern:** [Props-only (dumb) | Fetches via hook (smart)]
+**Purpose:** [Clear purpose statement]
+**Usage:** [When and how to use]
+**Composition:** [For Molecules: list constituent Atoms. For Organisms: list Molecules/Atoms used]
+**Composition Check:** [Which existing Atoms/Molecules were evaluated and why they could/could not be reused]
+**States:** [All possible states with descriptions]
+**Variants:** [Different sizes/styles if applicable]
+**Accessibility:** [ARIA labels, keyboard navigation, tabIndex, Enter/Space keypresses where appropriate]
+**Content Guidelines:** [What content works best]
+**Interaction Behavior:** [How users interact]
+```
+
+### 4. Define Component Strategy
+
+"**Component Strategy:**
+
+**Foundation Components:** (from design system)
+
+- [Foundation component 1]
+- [Foundation component 2]
+
+**Custom Components:** (designed in this step)
+
+- [Custom component 1 with rationale]
+- [Custom component 2 with rationale]
+
+**Implementation Approach:**
+
+- Build custom components using design system tokens
+- Ensure consistency with established patterns
+- Follow accessibility best practices
+- Create reusable patterns for common use cases"
+
+### 5. Plan Implementation Roadmap
+
+"**Implementation Roadmap:**
+
+**Phase 1 - Core Components:**
+
+- [Component 1] - needed for [critical flow]
+- [Component 2] - needed for [critical flow]
+
+**Phase 2 - Supporting Components:**
+
+- [Component 3] - enhances [user experience]
+- [Component 4] - supports [design pattern]
+
+**Phase 3 - Enhancement Components:**
+
+- [Component 5] - optimizes [user journey]
+- [Component 6] - adds [special feature]
+
+This roadmap helps prioritize development based on user journey criticality."
+
+### 6. Generate Component Strategy Content
+
+When saving to document, append these sections:
+
+```markdown
+## Component Strategy
+
+### Design System Components
+
+[Analysis of available design system components based on conversation — list which design system components will be used AS-IS without modification]
+
+### Custom Components
+
+> **Classification Rule:** All custom components MUST be categorized under exactly ONE of the three Atomic Design tiers below. Components that span tiers must be split. Execution agents must reject any component that does not fit cleanly.
+
+#### Atoms (Logicless, Stateless)
+
+[Atom component specifications from conversation — each using the component template above]
+
+#### Molecules (Stateless Compositions of Atoms)
+
+[Molecule component specifications from conversation — each listing its constituent Atoms]
+
+#### Organisms (Stateful or Context-Consuming)
+
+[Organism component specifications from conversation — each listing its constituent Molecules/Atoms and the data it fetches or the Context it consumes]
+
+### Composition Audit
+
+> **Mandate:** Before any new component was defined above, the existing component library was evaluated. This section documents that check.
+
+| Component Name       | Existing Component Evaluated | Outcome                                 |
+| -------------------- | ---------------------------- | --------------------------------------- |
+| [New component name] | [Existing component checked] | [Reused / Modified / New — explain why] |
+
+### Component Implementation Strategy
+
+[Component implementation strategy based on conversation]
+
+### Implementation Roadmap
+
+[Implementation roadmap based on conversation — ordered by user journey criticality, not implementation convenience]
+```
+
+### 7. Auto-Save and Advance
+
+Without presenting a menu or waiting for user input:
+
+- Append the final content to `{planning_artifacts}/ux-design-specification.md`
+- Update frontmatter: append step to end of stepsCompleted array
+- Announce: `"✅ Component Strategy saved. Advancing to UX Patterns..."`
+- Immediately load and execute: `{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-12-ux-patterns.md`
+
+> **HALT ONLY IF:** A component cannot be classified into any Atomic tier (Atom/Molecule/Organism). In that case, ask once: "I couldn't classify [component name] — can you clarify its scope and responsibilities?" Then continue without further gates.

package/src/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-12-ux-patterns.md

@@ -1,135 +1,135 @@
-# Step 12: UX Consistency Patterns
-
-Establish UX consistency patterns for common situations like buttons, forms, navigation, and feedback.
-
-## UX PATTERNS SEQUENCE
-
-### 1. Identify Pattern Categories
-
-"Let's establish consistency patterns for how {{project_name}} behaves in common situations.
-
-**Pattern Categories to Define:**
-
-- Button hierarchy and actions
-- Feedback patterns (success, error, warning, info)
-- Form patterns and validation
-- Navigation patterns
-- Modal and overlay patterns
-- Empty states and loading states
-- Search and filtering patterns
-
-Which categories are most critical for your product? We can go through each thoroughly or focus on the most important ones."
-
-### 2. Define Critical Patterns First
-
-For each priority pattern category:
-
-"**[Pattern Type] Patterns:**
-What should users see/do when they need to [pattern action]?
-
-**Considerations:**
-
-- Visual hierarchy (primary vs. secondary actions)
-- Feedback mechanisms
-- Error recovery
-- Accessibility requirements
-- Mobile vs. desktop considerations
-
-**Examples:**
-
-- [Example 1 for this pattern type]
-- [Example 2 for this pattern type]
-
-How should {{project_name}} handle [pattern type] interactions?"
-
-### 3. Establish Pattern Guidelines
-
-Use this template for each pattern:
-
-```markdown
-### [Pattern Type]
-
-**When to Use:** [Clear usage guidelines]
-**Visual Design:** [How it should look]
-**Behavior:** [How it should interact]
-**Accessibility:** [A11y requirements]
-**Mobile Considerations:** [Mobile-specific needs]
-**Variants:** [Different states or styles if applicable]
-```
-
-### 4. Design System Integration
-
-"**Integration with [Design System]:**
-
-- How do these patterns complement our design system components?
-- What customizations are needed?
-- How do we maintain consistency while meeting unique needs?
-
-**Custom Pattern Rules:**
-
-- [Custom rule 1]
-- [Custom rule 2]
-- [Custom rule 3]"
-
-### 5. Generate UX Patterns Content
-
-When saving to document, append these sections:
-
-```markdown
-## UX Consistency Patterns
-
-> **Non-Negotiable Execution Constraint:** ALL navigation in this product MUST use the project's native routing primitives (`<Link href>` in Next.js, `<Link to>` in React Router, or framework equivalent). Hardcoded `<a href>` anchor tags for internal navigation are FORBIDDEN. This mandate applies to every component generated from this specification.
-
-### Button Hierarchy
-
-[Button hierarchy patterns based on conversation]
-
-### Feedback Patterns
-
-[Feedback patterns based on conversation]
-
-### Form Patterns
-
-[Form patterns based on conversation]
-
-### Navigation Patterns
-
-[Navigation patterns based on conversation]
-
-### Modal & Overlay Patterns
-
-[Modal and overlay patterns based on conversation — include explicit z-index strategy and focus-trap requirements]
-
-### Empty & Loading States
-
-[Empty state and loading state patterns based on conversation]
-
-### Additional Patterns
-
-[Additional patterns based on conversation]
-
-### Optimistic UI Rules
-
-**Default Behavior:** All mutating actions (create, update, delete) MUST implement optimistic UI updates by default to provide instant user feedback.
-
-**Mandatory Rollback Strategy:** For every mutating endpoint, define a rollback strategy. If the Epic/PRD does not define one for a specific endpoint, the execution agent MUST halt and request it before proceeding.
-
-> **Completeness Rule:** The table below MUST contain an entry for EVERY mutating endpoint defined in this project's Epics and PRD. A partial table is a compliance failure.
-
-| Mutation            | Optimistic Action                    | Success State                  | Rollback Strategy                       |
-| ------------------- | ------------------------------------ | ------------------------------ | --------------------------------------- |
-| [e.g., Create item] | [e.g., Add to list immediately]      | [e.g., Persist with server ID] | [e.g., Remove item + error toast]       |
-| [e.g., Delete item] | [e.g., Remove from list immediately] | [e.g., Delete confirmed]       | [e.g., Re-add item + error toast]       |
-| [e.g., Update item] | [e.g., Show new value immediately]   | [e.g., Confirm update]         | [e.g., Restore old value + error toast] |
-```
-
-### 6. Auto-Save and Advance
-
-Without presenting a menu or waiting for user input:
-
-- Append the final content to `{planning_artifacts}/ux-design-specification.md`
-- Update frontmatter: append step to end of stepsCompleted array
-- Announce: `"✅ UX Consistency Patterns saved. Advancing to Responsive & Accessibility..."`
-- Immediately load and execute: `{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13-responsive-accessibility.md`
-
-> **HALT ONLY IF:** A mutating endpoint has no rollback strategy in the Epic/PRD. In that case, ask once: "The PRD doesn't define a rollback strategy for [endpoint]. How should we handle failures?" Then continue without further gates.
+# Step 12: UX Consistency Patterns
+
+Establish UX consistency patterns for common situations like buttons, forms, navigation, and feedback.
+
+## UX PATTERNS SEQUENCE
+
+### 1. Identify Pattern Categories
+
+"Let's establish consistency patterns for how {{project_name}} behaves in common situations.
+
+**Pattern Categories to Define:**
+
+- Button hierarchy and actions
+- Feedback patterns (success, error, warning, info)
+- Form patterns and validation
+- Navigation patterns
+- Modal and overlay patterns
+- Empty states and loading states
+- Search and filtering patterns
+
+Which categories are most critical for your product? We can go through each thoroughly or focus on the most important ones."
+
+### 2. Define Critical Patterns First
+
+For each priority pattern category:
+
+"**[Pattern Type] Patterns:**
+What should users see/do when they need to [pattern action]?
+
+**Considerations:**
+
+- Visual hierarchy (primary vs. secondary actions)
+- Feedback mechanisms
+- Error recovery
+- Accessibility requirements
+- Mobile vs. desktop considerations
+
+**Examples:**
+
+- [Example 1 for this pattern type]
+- [Example 2 for this pattern type]
+
+How should {{project_name}} handle [pattern type] interactions?"
+
+### 3. Establish Pattern Guidelines
+
+Use this template for each pattern:
+
+```markdown
+### [Pattern Type]
+
+**When to Use:** [Clear usage guidelines]
+**Visual Design:** [How it should look]
+**Behavior:** [How it should interact]
+**Accessibility:** [A11y requirements]
+**Mobile Considerations:** [Mobile-specific needs]
+**Variants:** [Different states or styles if applicable]
+```
+
+### 4. Design System Integration
+
+"**Integration with [Design System]:**
+
+- How do these patterns complement our design system components?
+- What customizations are needed?
+- How do we maintain consistency while meeting unique needs?
+
+**Custom Pattern Rules:**
+
+- [Custom rule 1]
+- [Custom rule 2]
+- [Custom rule 3]"
+
+### 5. Generate UX Patterns Content
+
+When saving to document, append these sections:
+
+```markdown
+## UX Consistency Patterns
+
+> **Non-Negotiable Execution Constraint:** ALL navigation in this product MUST use the project's native routing primitives (`<Link href>` in Next.js, `<Link to>` in React Router, or framework equivalent). Hardcoded `<a href>` anchor tags for internal navigation are FORBIDDEN. This mandate applies to every component generated from this specification.
+
+### Button Hierarchy
+
+[Button hierarchy patterns based on conversation]
+
+### Feedback Patterns
+
+[Feedback patterns based on conversation]
+
+### Form Patterns
+
+[Form patterns based on conversation]
+
+### Navigation Patterns
+
+[Navigation patterns based on conversation]
+
+### Modal & Overlay Patterns
+
+[Modal and overlay patterns based on conversation — include explicit z-index strategy and focus-trap requirements]
+
+### Empty & Loading States
+
+[Empty state and loading state patterns based on conversation]
+
+### Additional Patterns
+
+[Additional patterns based on conversation]
+
+### Optimistic UI Rules
+
+**Default Behavior:** All mutating actions (create, update, delete) MUST implement optimistic UI updates by default to provide instant user feedback.
+
+**Mandatory Rollback Strategy:** For every mutating endpoint, define a rollback strategy. If the Epic/PRD does not define one for a specific endpoint, the execution agent MUST halt and request it before proceeding.
+
+> **Completeness Rule:** The table below MUST contain an entry for EVERY mutating endpoint defined in this project's Epics and PRD. A partial table is a compliance failure.
+
+| Mutation            | Optimistic Action                    | Success State                  | Rollback Strategy                       |
+| ------------------- | ------------------------------------ | ------------------------------ | --------------------------------------- |
+| [e.g., Create item] | [e.g., Add to list immediately]      | [e.g., Persist with server ID] | [e.g., Remove item + error toast]       |
+| [e.g., Delete item] | [e.g., Remove from list immediately] | [e.g., Delete confirmed]       | [e.g., Re-add item + error toast]       |
+| [e.g., Update item] | [e.g., Show new value immediately]   | [e.g., Confirm update]         | [e.g., Restore old value + error toast] |
+```
+
+### 6. Auto-Save and Advance
+
+Without presenting a menu or waiting for user input:
+
+- Append the final content to `{planning_artifacts}/ux-design-specification.md`
+- Update frontmatter: append step to end of stepsCompleted array
+- Announce: `"✅ UX Consistency Patterns saved. Advancing to Responsive & Accessibility..."`
+- Immediately load and execute: `{project-root}/_bmad/bmm/workflows/2-plan-workflows/create-ux-design/steps/step-13-responsive-accessibility.md`
+
+> **HALT ONLY IF:** A mutating endpoint has no rollback strategy in the Epic/PRD. In that case, ask once: "The PRD doesn't define a rollback strategy for [endpoint]. How should we handle failures?" Then continue without further gates.