latest web build udpated

2025-06-05 20:30:37 -05:00 · 2025-06-05 20:30:37 -05:00 · 50fd1c4a41
parent 0267d2d745
commit 50fd1c4a41
7 changed files with 2034 additions and 427 deletions
--- a/web-build-sample/agent-config.txt
+++ b/web-build-sample/agent-config.txt
@ -1,3 +1,5 @@
 # Configuration for Web Agents
 ## Title: BMAD
 - Name: BMAD
@ -17,9 +19,6 @@
  - "Brain Storming"
  - "Deep Research"
  - "Project Briefing"
 - Interaction Modes:
  - "Interactive"
  - "YOLO"
 - templates:
  - [Project Brief Tmpl](templates#project-brief-tmpl)
@ -27,20 +26,16 @@
 - Name: John
 - Customize: ""
- Description: "For PRDs, project planning, PM checklists and potential replans."
+- Description: "Main goal is to help produce or maintain the best possible PRD and represent the end user the product will serve."
 - Persona: "personas#pm"
 - checklists:
  - [Pm Checklist](checklists#pm-checklist)
  - [Change Checklist](checklists#change-checklist)
 - templates:
  - [Prd Tmpl](templates#prd-tmpl)
 - tasks:
-  - [Create Prd](tasks#create-prd)
+  - [Create Document](tasks#create-doc-from-template):
    - [Prd](templates#prd-tmpl)
  - [Correct Course](tasks#correct-course)
  - [Create Deep Research Prompt](tasks#create-deep-research-prompt)
 - Interaction Modes:
  - "Interactive"
  - "YOLO"
 ## Title: Architect
@ -55,15 +50,24 @@
 - tasks:
  - [Create Architecture](tasks#create-architecture)
  - [Create Deep Research Prompt](tasks#create-deep-research-prompt)
- Interaction Modes:
+
-  - "Interactive"
+## Title: Platform Engineer
-  - "YOLO"
+
 - Name: Alex
 - Customize: "Specialized in cloud-native system architectures and tools, like Kubernetes, Docker, GitHub Actions, CI/CD pipelines, and infrastructure-as-code practices (e.g., Terraform, CloudFormation, Bicep, etc.)."
 - Description: "Alex loves when things are running secure, stable, reliable and performant. His motivation is to have the production environment as resilient and reliable for the customer as possible. He is a Master Expert Senior Platform Engineer with 15+ years of experience in DevSecOps, Cloud Engineering, and Platform Engineering with a deep, profound knowledge of SRE."
 - Persona: "devops-pe.ide.md"
 - Tasks:
  - [Create Infrastructure Architecture](platform-arch.task.md)
  - [Implement Infrastructure Changes](infrastructure-implementation.task.md)
  - [Review Infrastructure](infrastructure-review.task.md)
  - [Validate Infrastructure](infrastructure-validation.task.md)
 ## Title: Design Architect
 - Name: Jane
 - Customize: ""
- Description: "For UI/UX specifications, front-end architecture."
+- Description: "For UI/UX specifications, front-end architecture, and UI 1-shot prompting."
 - Persona: "personas#design-architect"
 - checklists:
  - [Frontend Architecture Checklist](checklists#frontend-architecture-checklist)
@ -74,15 +78,12 @@
  - [Create Frontend Architecture](tasks#create-frontend-architecture)
  - [Create Ai Frontend Prompt](tasks#create-ai-frontend-prompt)
  - [Create UX/UI Spec](tasks#create-uxui-spec)
 - Interaction Modes:
  - "Interactive"
  - "YOLO"
 ## Title: PO
 - Name: Sarah
 - Customize: ""
- Description: "Product Owner"
+- Description: "Product Owner helps validate the artifacts are all cohesive with a master checklist, and also helps coach significant changes"
 - Persona: "personas#po"
 - checklists:
  - [Po Master Checklist](checklists#po-master-checklist)
@ -93,9 +94,6 @@
  - [Checklist Run Task](tasks#checklist-run-task)
  - [Extracts Epics and shards the Architecture](tasks#doc-sharding-task)
  - [Correct Course](tasks#correct-course)
 - Interaction Modes:
  - "Interactive"
  - "YOLO"
 ## Title: SM
@ -104,15 +102,8 @@
 - Description: "A very Technical Scrum Master helps the team run the Scrum process."
 - Persona: "personas#sm"
 - checklists:
  - [Change Checklist](checklists#change-checklist)
  - [Story Dod Checklist](checklists#story-dod-checklist)
  - [Story Draft Checklist](checklists#story-draft-checklist)
 - tasks:
  - [Checklist Run Task](tasks#checklist-run-task)
  - [Correct Course](tasks#correct-course)
  - [Draft a story for dev agent](tasks#story-draft-task)
 - templates:
  - [Story Tmpl](templates#story-tmpl)
 - Interaction Modes:
  - "Interactive"
  - "YOLO"
--- a/web-build-sample/agent-prompt.txt
+++ b/web-build-sample/agent-prompt.txt
@ -4,7 +4,7 @@
 ## Your Role
-You are an AI Orchestrator. Your initial active persona, "BMad, Master of the BMAD Method," is defined by the relevant 'BMAD' agent entry in your `AgentConfig` (typically loading a persona file like `personas#bmad` or `bmad.md`).
+You are an AI Orchestrator. Your initial active persona, "BMad, Master of the BMAD Method," is defined by the relevant 'BMAD' agent entry in your `AgentConfig` from `personas#bmad`.
 Your primary function is to:
@ -18,7 +18,7 @@ Operational steps for how you manage persona loading, task execution, and comman
 ## Operational Workflow
-### 1. Greeting & Initial Configuration:
+### 1. Greeting & Initial Configuration
 - Greet the user. Explain your role: BMad, the Agile AI Orchestrator and expert in the BMad Method - you can offer guidance or facilitate orchestration.
 - **CRITICAL Internal Step:** Your FIRST action is to load and parse `AgentConfig`. This file provides the definitive list of all available agents, their configurations (persona files, tasks, etc.), and resource paths. If missing or unparsable, inform user and request it.
@ -29,7 +29,7 @@ Operational steps for how you manage persona loading, task execution, and comman
  - Example: "1. Agent 'Product Manager' (John): For PRDs, project planning. Tasks: [Create PRD], [Correct Course]."
  - Ask user to select agent & optionally a specific task, along with an interaction preference (Default will be interactive, but user can select YOLO (not recommended)).
-### 2. Executing Based on Persona Selection:
+### 2. Executing Based on Persona Selection
 - **Identify Target Agent:** Match user's request against an agent's `Title` or `Name` in `AgentConfig`. If ambiguous, ask for clarification.
--- a/web-build-sample/checklists.txt
+++ b/web-build-sample/checklists.txt
@ -337,7 +337,7 @@ This checklist serves as a comprehensive framework for the Architect to validate
 ## 5. Sprint Change Proposal Components
-_(Ensure all agreed-upon points from previous sections are captured in the proposal)_
+(Ensure all agreed-upon points from previous sections are captured in the proposal)
 - [ ] **Identified Issue Summary:** Clear, concise problem statement.
 - [ ] **Epic Impact Summary:** How epics are affected.
@ -363,6 +363,7 @@ _(Ensure all agreed-upon points from previous sections are captured in the propo
 # Frontend Architecture Document Review Checklist
 ## Purpose
 This checklist is for the Design Architect to use after completing the "Frontend Architecture Mode" and populating the `front-end-architecture-tmpl.txt` (or `.md`) document. It ensures all sections are comprehensively covered and meet quality standards before finalization.
 ---
@ -396,10 +397,12 @@ This checklist is for the Design Architect to use after completing the "Frontend
 ## IV. Component Breakdown & Implementation Details
 ### Component Naming & Organization
 - [ ] Are conventions for naming components (e.g., PascalCase) described?
 - [ ] Is the organization of components on the filesystem clearly explained (reiterating from directory structure if needed)?
 ### Template for Component Specification
 - [ ] Is the "Template for Component Specification" itself complete and well-defined?
  - [ ] Does it include fields for: Purpose, Source File(s), Visual Reference?
  - [ ] Does it include a table structure for Props (Name, Type, Required, Default, Description)?
@ -412,6 +415,7 @@ This checklist is for the Design Architect to use after completing the "Frontend
 - [ ] Is there a clear statement that this template should be used for most feature-specific components?
 ### Foundational/Shared Components (if any specified upfront)
 - [ ] If any foundational/shared UI components are specified, do they follow the "Template for Component Specification"?
 - [ ] Is the rationale for specifying these components upfront clear?
@ -513,6 +517,495 @@ This checklist is for the Design Architect to use after completing the "Frontend
 ==================== END: frontend-architecture-checklist ====================
 ==================== START: infrastructure-checklist ====================
 # Infrastructure Change Validation Checklist
 This checklist serves as a comprehensive framework for validating infrastructure changes before deployment to production. The DevOps/Platform Engineer should systematically work through each item, ensuring the infrastructure is secure, compliant, resilient, and properly implemented according to organizational standards.
 ## 1. SECURITY & COMPLIANCE
 ### 1.1 Access Management
 - [ ] RBAC principles applied with least privilege access
 - [ ] Service accounts have minimal required permissions
 - [ ] Secrets management solution properly implemented
 - [ ] IAM policies and roles documented and reviewed
 - [ ] Access audit mechanisms configured
 ### 1.2 Data Protection
 - [ ] Data at rest encryption enabled for all applicable services
 - [ ] Data in transit encryption (TLS 1.2+) enforced
 - [ ] Sensitive data identified and protected appropriately
 - [ ] Backup encryption configured where required
 - [ ] Data access audit trails implemented where required
 ### 1.3 Network Security
 - [ ] Network security groups configured with minimal required access
 - [ ] Private endpoints used for PaaS services where available
 - [ ] Public-facing services protected with WAF policies
 - [ ] Network traffic flows documented and secured
 - [ ] Network segmentation properly implemented
 ### 1.4 Compliance Requirements
 - [ ] Regulatory compliance requirements verified and met
 - [ ] Security scanning integrated into pipeline
 - [ ] Compliance evidence collection automated where possible
 - [ ] Privacy requirements addressed in infrastructure design
 - [ ] Security monitoring and alerting enabled
 ## 2. INFRASTRUCTURE AS CODE
 ### 2.1 IaC Implementation
 - [ ] All resources defined in IaC (Terraform/Bicep/ARM)
 - [ ] IaC code follows organizational standards and best practices
 - [ ] No manual configuration changes permitted
 - [ ] Dependencies explicitly defined and documented
 - [ ] Modules and resource naming follow conventions
 ### 2.2 IaC Quality & Management
 - [ ] IaC code reviewed by at least one other engineer
 - [ ] State files securely stored and backed up
 - [ ] Version control best practices followed
 - [ ] IaC changes tested in non-production environment
 - [ ] Documentation for IaC updated
 ### 2.3 Resource Organization
 - [ ] Resources organized in appropriate resource groups
 - [ ] Tags applied consistently per tagging strategy
 - [ ] Resource locks applied where appropriate
 - [ ] Naming conventions followed consistently
 - [ ] Resource dependencies explicitly managed
 ## 3. RESILIENCE & AVAILABILITY
 ### 3.1 High Availability
 - [ ] Resources deployed across appropriate availability zones
 - [ ] SLAs for each component documented and verified
 - [ ] Load balancing configured properly
 - [ ] Failover mechanisms tested and verified
 - [ ] Single points of failure identified and mitigated
 ### 3.2 Fault Tolerance
 - [ ] Auto-scaling configured where appropriate
 - [ ] Health checks implemented for all services
 - [ ] Circuit breakers implemented where necessary
 - [ ] Retry policies configured for transient failures
 - [ ] Graceful degradation mechanisms implemented
 ### 3.3 Recovery Metrics & Testing
 - [ ] Recovery time objectives (RTOs) verified
 - [ ] Recovery point objectives (RPOs) verified
 - [ ] Resilience testing completed and documented
 - [ ] Chaos engineering principles applied where appropriate
 - [ ] Recovery procedures documented and tested
 ## 4. BACKUP & DISASTER RECOVERY
 ### 4.1 Backup Strategy
 - [ ] Backup strategy defined and implemented
 - [ ] Backup retention periods aligned with requirements
 - [ ] Backup recovery tested and validated
 - [ ] Point-in-time recovery configured where needed
 - [ ] Backup access controls implemented
 ### 4.2 Disaster Recovery
 - [ ] DR plan documented and accessible
 - [ ] DR runbooks created and tested
 - [ ] Cross-region recovery strategy implemented (if required)
 - [ ] Regular DR drills scheduled
 - [ ] Dependencies considered in DR planning
 ### 4.3 Recovery Procedures
 - [ ] System state recovery procedures documented
 - [ ] Data recovery procedures documented
 - [ ] Application recovery procedures aligned with infrastructure
 - [ ] Recovery roles and responsibilities defined
 - [ ] Communication plan for recovery scenarios established
 ## 5. MONITORING & OBSERVABILITY
 ### 5.1 Monitoring Implementation
 - [ ] Monitoring coverage for all critical components
 - [ ] Appropriate metrics collected and dashboarded
 - [ ] Log aggregation implemented
 - [ ] Distributed tracing implemented (if applicable)
 - [ ] User experience/synthetics monitoring configured
 ### 5.2 Alerting & Response
 - [ ] Alerts configured for critical thresholds
 - [ ] Alert routing and escalation paths defined
 - [ ] Service health integration configured
 - [ ] On-call procedures documented
 - [ ] Incident response playbooks created
 ### 5.3 Operational Visibility
 - [ ] Custom queries/dashboards created for key scenarios
 - [ ] Resource utilization tracking configured
 - [ ] Cost monitoring implemented
 - [ ] Performance baselines established
 - [ ] Operational runbooks available for common issues
 ## 6. PERFORMANCE & OPTIMIZATION
 ### 6.1 Performance Testing
 - [ ] Performance testing completed and baseline established
 - [ ] Resource sizing appropriate for workload
 - [ ] Performance bottlenecks identified and addressed
 - [ ] Latency requirements verified
 - [ ] Throughput requirements verified
 ### 6.2 Resource Optimization
 - [ ] Cost optimization opportunities identified
 - [ ] Auto-scaling rules validated
 - [ ] Resource reservation used where appropriate
 - [ ] Storage tier selection optimized
 - [ ] Idle/unused resources identified for cleanup
 ### 6.3 Efficiency Mechanisms
 - [ ] Caching strategy implemented where appropriate
 - [ ] CDN/edge caching configured for content
 - [ ] Network latency optimized
 - [ ] Database performance tuned
 - [ ] Compute resource efficiency validated
 ## 7. OPERATIONS & GOVERNANCE
 ### 7.1 Documentation
 - [ ] Change documentation updated
 - [ ] Runbooks created or updated
 - [ ] Architecture diagrams updated
 - [ ] Configuration values documented
 - [ ] Service dependencies mapped and documented
 ### 7.2 Governance Controls
 - [ ] Cost controls implemented
 - [ ] Resource quota limits configured
 - [ ] Policy compliance verified
 - [ ] Audit logging enabled
 - [ ] Management access reviewed
 ### 7.3 Knowledge Transfer
 - [ ] Cross-team impacts documented and communicated
 - [ ] Required training/knowledge transfer completed
 - [ ] Architectural decision records updated
 - [ ] Post-implementation review scheduled
 - [ ] Operations team handover completed
 ## 8. CI/CD & DEPLOYMENT
 ### 8.1 Pipeline Configuration
 - [ ] CI/CD pipelines configured and tested
 - [ ] Environment promotion strategy defined
 - [ ] Deployment notifications configured
 - [ ] Pipeline security scanning enabled
 - [ ] Artifact management properly configured
 ### 8.2 Deployment Strategy
 - [ ] Rollback procedures documented and tested
 - [ ] Zero-downtime deployment strategy implemented
 - [ ] Deployment windows identified and scheduled
 - [ ] Progressive deployment approach used (if applicable)
 - [ ] Feature flags implemented where appropriate
 ### 8.3 Verification & Validation
 - [ ] Post-deployment verification tests defined
 - [ ] Smoke tests automated
 - [ ] Configuration validation automated
 - [ ] Integration tests with dependent systems
 - [ ] Canary/blue-green deployment configured (if applicable)
 ## 9. NETWORKING & CONNECTIVITY
 ### 9.1 Network Design
 - [ ] VNet/subnet design follows least-privilege principles
 - [ ] Network security groups rules audited
 - [ ] Public IP addresses minimized and justified
 - [ ] DNS configuration verified
 - [ ] Network diagram updated and accurate
 ### 9.2 Connectivity
 - [ ] VNet peering configured correctly
 - [ ] Service endpoints configured where needed
 - [ ] Private link/private endpoints implemented
 - [ ] External connectivity requirements verified
 - [ ] Load balancer configuration verified
 ### 9.3 Traffic Management
 - [ ] Inbound/outbound traffic flows documented
 - [ ] Firewall rules reviewed and minimized
 - [ ] Traffic routing optimized
 - [ ] Network monitoring configured
 - [ ] DDoS protection implemented where needed
 ## 10. COMPLIANCE & DOCUMENTATION
 ### 10.1 Compliance Verification
 - [ ] Required compliance evidence collected
 - [ ] Non-functional requirements verified
 - [ ] License compliance verified
 - [ ] Third-party dependencies documented
 - [ ] Security posture reviewed
 ### 10.2 Documentation Completeness
 - [ ] All documentation updated
 - [ ] Architecture diagrams updated
 - [ ] Technical debt documented (if any accepted)
 - [ ] Cost estimates updated and approved
 - [ ] Capacity planning documented
 ### 10.3 Cross-Team Collaboration
 - [ ] Development team impact assessed and communicated
 - [ ] Operations team handover completed
 - [ ] Security team reviews completed
 - [ ] Business stakeholders informed of changes
 - [ ] Feedback loops established for continuous improvement
 ## 11. BMAD WORKFLOW INTEGRATION
 ### 11.1 Development Agent Alignment
 - [ ] Infrastructure changes support Frontend Dev (Mira) and Fullstack Dev (Enrique) requirements
 - [ ] Backend requirements from Backend Dev (Lily) and Fullstack Dev (Enrique) accommodated
 - [ ] Local development environment compatibility verified for all dev agents
 - [ ] Infrastructure changes support automated testing frameworks
 - [ ] Development agent feedback incorporated into infrastructure design
 ### 11.2 Product Alignment
 - [ ] Infrastructure changes mapped to PRD requirements maintained by Product Owner
 - [ ] Non-functional requirements from PRD verified in implementation
 - [ ] Infrastructure capabilities and limitations communicated to Product teams
 - [ ] Infrastructure release timeline aligned with product roadmap
 - [ ] Technical constraints documented and shared with Product Owner
 ### 11.3 Architecture Alignment
 - [ ] Infrastructure implementation validated against architecture documentation
 - [ ] Architecture Decision Records (ADRs) reflected in infrastructure
 - [ ] Technical debt identified by Architect addressed or documented
 - [ ] Infrastructure changes support documented design patterns
 - [ ] Performance requirements from architecture verified in implementation
 ## 12. ARCHITECTURE DOCUMENTATION VALIDATION
 ### 12.1 Completeness Assessment
 - [ ] All required sections of architecture template completed
 - [ ] Architecture decisions documented with clear rationales
 - [ ] Technical diagrams included for all major components
 - [ ] Integration points with application architecture defined
 - [ ] Non-functional requirements addressed with specific solutions
 ### 12.2 Consistency Verification
 - [ ] Architecture aligns with broader system architecture
 - [ ] Terminology used consistently throughout documentation
 - [ ] Component relationships clearly defined
 - [ ] Environment differences explicitly documented
 - [ ] No contradictions between different sections
 ### 12.3 Stakeholder Usability
 - [ ] Documentation accessible to both technical and non-technical stakeholders
 - [ ] Complex concepts explained with appropriate analogies or examples
 - [ ] Implementation guidance clear for development teams
 - [ ] Operations considerations explicitly addressed
 - [ ] Future evolution pathways documented
 ## 13. CONTAINER PLATFORM VALIDATION
 ### 13.1 Cluster Configuration & Security
 - [ ] Container orchestration platform properly installed and configured
 - [ ] Cluster nodes configured with appropriate resource allocation and security policies
 - [ ] Control plane high availability and security hardening implemented
 - [ ] API server access controls and authentication mechanisms configured
 - [ ] Cluster networking properly configured with security policies
 ### 13.2 RBAC & Access Control
 - [ ] Role-Based Access Control (RBAC) implemented with least privilege principles
 - [ ] Service accounts configured with minimal required permissions
 - [ ] Pod security policies and security contexts properly configured
 - [ ] Network policies implemented for micro-segmentation
 - [ ] Secrets management integration configured and validated
 ### 13.3 Workload Management & Resource Control
 - [ ] Resource quotas and limits configured per namespace/tenant requirements
 - [ ] Horizontal and vertical pod autoscaling configured and tested
 - [ ] Cluster autoscaling configured for node management
 - [ ] Workload scheduling policies and node affinity rules implemented
 - [ ] Container image security scanning and policy enforcement configured
 ### 13.4 Container Platform Operations
 - [ ] Container platform monitoring and observability configured
 - [ ] Container workload logging aggregation implemented
 - [ ] Platform health checks and performance monitoring operational
 - [ ] Backup and disaster recovery procedures for cluster state configured
 - [ ] Operational runbooks and troubleshooting guides created
 ## 14. GITOPS WORKFLOWS VALIDATION
 ### 14.1 GitOps Operator & Configuration
 - [ ] GitOps operators properly installed and configured
 - [ ] Application and configuration sync controllers operational
 - [ ] Multi-cluster management configured (if required)
 - [ ] Sync policies, retry mechanisms, and conflict resolution configured
 - [ ] Automated pruning and drift detection operational
 ### 14.2 Repository Structure & Management
 - [ ] Repository structure follows GitOps best practices
 - [ ] Configuration templating and parameterization properly implemented
 - [ ] Environment-specific configuration overlays configured
 - [ ] Configuration validation and policy enforcement implemented
 - [ ] Version control and branching strategies properly defined
 ### 14.3 Environment Promotion & Automation
 - [ ] Environment promotion pipelines operational (dev → staging → prod)
 - [ ] Automated testing and validation gates configured
 - [ ] Approval workflows and change management integration implemented
 - [ ] Automated rollback mechanisms configured and tested
 - [ ] Promotion notifications and audit trails operational
 ### 14.4 GitOps Security & Compliance
 - [ ] GitOps security best practices and access controls implemented
 - [ ] Policy enforcement for configurations and deployments operational
 - [ ] Secret management integration with GitOps workflows configured
 - [ ] Security scanning for configuration changes implemented
 - [ ] Audit logging and compliance monitoring configured
 ## 15. SERVICE MESH VALIDATION
 ### 15.1 Service Mesh Architecture & Installation
 - [ ] Service mesh control plane properly installed and configured
 - [ ] Data plane (sidecars/proxies) deployed and configured correctly
 - [ ] Service mesh components integrated with container platform
 - [ ] Service mesh networking and connectivity validated
 - [ ] Resource allocation and performance tuning for mesh components optimal
 ### 15.2 Traffic Management & Communication
 - [ ] Traffic routing rules and policies configured and tested
 - [ ] Load balancing strategies and failover mechanisms operational
 - [ ] Traffic splitting for canary deployments and A/B testing configured
 - [ ] Circuit breakers and retry policies implemented and validated
 - [ ] Timeout and rate limiting policies configured
 ### 15.3 Service Mesh Security
 - [ ] Mutual TLS (mTLS) implemented for service-to-service communication
 - [ ] Service-to-service authorization policies configured
 - [ ] Identity and access management integration operational
 - [ ] Network security policies and micro-segmentation implemented
 - [ ] Security audit logging for service mesh events configured
 ### 15.4 Service Discovery & Observability
 - [ ] Service discovery mechanisms and service registry integration operational
 - [ ] Advanced load balancing algorithms and health checking configured
 - [ ] Service mesh observability (metrics, logs, traces) implemented
 - [ ] Distributed tracing for service communication operational
 - [ ] Service dependency mapping and topology visualization available
 ## 16. DEVELOPER EXPERIENCE PLATFORM VALIDATION
 ### 16.1 Self-Service Infrastructure
 - [ ] Self-service provisioning for development environments operational
 - [ ] Automated resource provisioning and management configured
 - [ ] Namespace/project provisioning with proper resource limits implemented
 - [ ] Self-service database and storage provisioning available
 - [ ] Automated cleanup and resource lifecycle management operational
 ### 16.2 Developer Tooling & Templates
 - [ ] Golden path templates for common application patterns available and tested
 - [ ] Project scaffolding and boilerplate generation operational
 - [ ] Template versioning and update mechanisms configured
 - [ ] Template customization and parameterization working correctly
 - [ ] Template compliance and security scanning implemented
 ### 16.3 Platform APIs & Integration
 - [ ] Platform APIs for infrastructure interaction operational and documented
 - [ ] API authentication and authorization properly configured
 - [ ] API documentation and developer resources available and current
 - [ ] Workflow automation and integration capabilities tested
 - [ ] API rate limiting and usage monitoring configured
 ### 16.4 Developer Experience & Documentation
 - [ ] Comprehensive developer onboarding documentation available
 - [ ] Interactive tutorials and getting-started guides functional
 - [ ] Developer environment setup automation operational
 - [ ] Access provisioning and permissions management streamlined
 - [ ] Troubleshooting guides and FAQ resources current and accessible
 ### 16.5 Productivity & Analytics
 - [ ] Development tool integrations (IDEs, CLI tools) operational
 - [ ] Developer productivity dashboards and metrics implemented
 - [ ] Development workflow optimization tools available
 - [ ] Platform usage monitoring and analytics configured
 - [ ] User feedback collection and analysis mechanisms operational
 ---
 ### Prerequisites Verified
 - [ ] All checklist sections reviewed (1-16)
 - [ ] No outstanding critical or high-severity issues
 - [ ] All infrastructure changes tested in non-production environment
 - [ ] Rollback plan documented and tested
 - [ ] Required approvals obtained
 - [ ] Infrastructure changes verified against architectural decisions documented by Architect agent
 - [ ] Development environment impacts identified and mitigated
 - [ ] Infrastructure changes mapped to relevant user stories and epics
 - [ ] Release coordination planned with development teams
 - [ ] Local development environment compatibility verified
 - [ ] Platform component integration validated
 - [ ] Cross-platform functionality tested and verified
 ==================== END: infrastructure-checklist ====================
 ==================== START: pm-checklist ====================
 # Product Manager (PM) Requirements Checklist
@ -521,6 +1014,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 ## 1. PROBLEM DEFINITION & CONTEXT
 ### 1.1 Problem Statement
 - [ ] Clear articulation of the problem being solved
 - [ ] Identification of who experiences the problem
 - [ ] Explanation of why solving this problem matters
@ -528,6 +1022,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Differentiation from existing solutions
 ### 1.2 Business Goals & Success Metrics
 - [ ] Specific, measurable business objectives defined
 - [ ] Clear success metrics and KPIs established
 - [ ] Metrics are tied to user and business value
@ -535,6 +1030,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Timeframe for achieving goals specified
 ### 1.3 User Research & Insights
 - [ ] Target user personas clearly defined
 - [ ] User needs and pain points documented
 - [ ] User research findings summarized (if available)
@ -544,6 +1040,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 ## 2. MVP SCOPE DEFINITION
 ### 2.1 Core Functionality
 - [ ] Essential features clearly distinguished from nice-to-haves
 - [ ] Features directly address defined problem statement
 - [ ] Each Epic ties back to specific user needs
@ -551,6 +1048,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Minimum requirements for success defined
 ### 2.2 Scope Boundaries
 - [ ] Clear articulation of what is OUT of scope
 - [ ] Future enhancements section included
 - [ ] Rationale for scope decisions documented
@ -558,6 +1056,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Scope has been reviewed and refined multiple times
 ### 2.3 MVP Validation Approach
 - [ ] Method for testing MVP success defined
 - [ ] Initial user feedback mechanisms planned
 - [ ] Criteria for moving beyond MVP specified
@ -567,6 +1066,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 ## 3. USER EXPERIENCE REQUIREMENTS
 ### 3.1 User Journeys & Flows
 - [ ] Primary user flows documented
 - [ ] Entry and exit points for each flow identified
 - [ ] Decision points and branches mapped
@ -574,6 +1074,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Edge cases considered
 ### 3.2 Usability Requirements
 - [ ] Accessibility considerations documented
 - [ ] Platform/device compatibility specified
 - [ ] Performance expectations from user perspective defined
@ -581,6 +1082,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] User feedback mechanisms identified
 ### 3.3 UI Requirements
 - [ ] Information architecture outlined
 - [ ] Critical UI components identified
 - [ ] Visual design guidelines referenced (if applicable)
@ -590,6 +1092,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 ## 4. FUNCTIONAL REQUIREMENTS
 ### 4.1 Feature Completeness
 - [ ] All required features for MVP documented
 - [ ] Features have clear, user-focused descriptions
 - [ ] Feature priority/criticality indicated
@ -597,6 +1100,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Dependencies between features identified
 ### 4.2 Requirements Quality
 - [ ] Requirements are specific and unambiguous
 - [ ] Requirements focus on WHAT not HOW
 - [ ] Requirements use consistent terminology
@ -604,6 +1108,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Technical jargon minimized or explained
 ### 4.3 User Stories & Acceptance Criteria
 - [ ] Stories follow consistent format
 - [ ] Acceptance criteria are testable
 - [ ] Stories are sized appropriately (not too large)
@ -614,6 +1119,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 ## 5. NON-FUNCTIONAL REQUIREMENTS
 ### 5.1 Performance Requirements
 - [ ] Response time expectations defined
 - [ ] Throughput/capacity requirements specified
 - [ ] Scalability needs documented
@ -621,6 +1127,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Load handling expectations set
 ### 5.2 Security & Compliance
 - [ ] Data protection requirements specified
 - [ ] Authentication/authorization needs defined
 - [ ] Compliance requirements documented
@ -628,6 +1135,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Privacy considerations addressed
 ### 5.3 Reliability & Resilience
 - [ ] Availability requirements defined
 - [ ] Backup and recovery needs documented
 - [ ] Fault tolerance expectations set
@ -635,6 +1143,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Maintenance and support considerations included
 ### 5.4 Technical Constraints
 - [ ] Platform/technology constraints documented
 - [ ] Integration requirements outlined
 - [ ] Third-party service dependencies identified
@ -644,6 +1153,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 ## 6. EPIC & STORY STRUCTURE
 ### 6.1 Epic Definition
 - [ ] Epics represent cohesive units of functionality
 - [ ] Epics focus on user/business value delivery
 - [ ] Epic goals clearly articulated
@ -651,6 +1161,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Epic sequence and dependencies identified
 ### 6.2 Story Breakdown
 - [ ] Stories are broken down to appropriate size
 - [ ] Stories have clear, independent value
 - [ ] Stories include appropriate acceptance criteria
@ -658,6 +1169,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Stories aligned with epic goals
 ### 6.3 First Epic Completeness
 - [ ] First epic includes all necessary setup steps
 - [ ] Project scaffolding and initialization addressed
 - [ ] Core infrastructure setup included
@ -667,6 +1179,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 ## 7. TECHNICAL GUIDANCE
 ### 7.1 Architecture Guidance
 - [ ] Initial architecture direction provided
 - [ ] Technical constraints clearly communicated
 - [ ] Integration points identified
@ -675,6 +1188,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Known areas of high complexity or technical risk flagged for architectural deep-dive
 ### 7.2 Technical Decision Framework
 - [ ] Decision criteria for technical choices provided
 - [ ] Trade-offs articulated for key decisions
 - [ ] Rationale for selecting primary approach over considered alternatives documented (for key design/feature choices)
@ -683,6 +1197,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Guidance on technical debt approach provided
 ### 7.3 Implementation Considerations
 - [ ] Development approach guidance provided
 - [ ] Testing requirements articulated
 - [ ] Deployment expectations set
@ -692,6 +1207,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 ## 8. CROSS-FUNCTIONAL REQUIREMENTS
 ### 8.1 Data Requirements
 - [ ] Data entities and relationships identified
 - [ ] Data storage requirements specified
 - [ ] Data quality requirements defined
@ -700,6 +1216,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Schema changes planned iteratively, tied to stories requiring them
 ### 8.2 Integration Requirements
 - [ ] External system integrations identified
 - [ ] API requirements documented
 - [ ] Authentication for integrations specified
@ -707,6 +1224,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Integration testing requirements outlined
 ### 8.3 Operational Requirements
 - [ ] Deployment frequency expectations set
 - [ ] Environment requirements defined
 - [ ] Monitoring and alerting needs identified
@ -716,6 +1234,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 ## 9. CLARITY & COMMUNICATION
 ### 9.1 Documentation Quality
 - [ ] Documents use clear, consistent language
 - [ ] Documents are well-structured and organized
 - [ ] Technical terms are defined where necessary
@ -723,6 +1242,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 - [ ] Documentation is versioned appropriately
 ### 9.2 Stakeholder Alignment
 - [ ] Key stakeholders identified
 - [ ] Stakeholder input incorporated
 - [ ] Potential areas of disagreement addressed
@ -732,6 +1252,7 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 ## PRD & EPIC VALIDATION SUMMARY
 ### Category Statuses
 | Category | Status | Critical Issues |
 |----------|--------|----------------|
 | 1. Problem Definition & Context | PASS/FAIL/PARTIAL | |
@ -745,12 +1266,15 @@ This checklist serves as a comprehensive framework to ensure the Product Require
 | 9. Clarity & Communication | PASS/FAIL/PARTIAL | |
 ### Critical Deficiencies
 - List all critical issues that must be addressed before handoff to Architect
 ### Recommendations
 - Provide specific recommendations for addressing each deficiency
 ### Final Decision
 - **READY FOR ARCHITECT**: The PRD and epics are comprehensive, properly structured, and ready for architectural design.
 - **NEEDS REFINEMENT**: The requirements documentation requires additional work to address the identified deficiencies.
@ -765,6 +1289,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ## 1. PROJECT SETUP & INITIALIZATION
 ### 1.1 Project Scaffolding
 - [ ] Epic 1 includes explicit steps for project creation/initialization
 - [ ] If using a starter template, steps for cloning/setup are included
 - [ ] If building from scratch, all necessary scaffolding steps are defined
@ -772,6 +1297,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 - [ ] Repository setup and initial commit processes are defined (if applicable)
 ### 1.2 Development Environment
 - [ ] Local development environment setup is clearly defined
 - [ ] Required tools and versions are specified (Node.js, Python, etc.)
 - [ ] Steps for installing dependencies are included
@ -779,6 +1305,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 - [ ] Development server setup is included
 ### 1.3 Core Dependencies
 - [ ] All critical packages/libraries are installed early in the process
 - [ ] Package management (npm, pip, etc.) is properly addressed
 - [ ] Version specifications are appropriately defined
@ -787,6 +1314,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ## 2. INFRASTRUCTURE & DEPLOYMENT SEQUENCING
 ### 2.1 Database & Data Store Setup
 - [ ] Database selection/setup occurs before any database operations
 - [ ] Schema definitions are created before data operations
 - [ ] Migration strategies are defined if applicable
@ -794,12 +1322,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 - [ ] Database access patterns and security are established early
 ### 2.2 API & Service Configuration
 - [ ] API frameworks are set up before implementing endpoints
 - [ ] Service architecture is established before implementing services
 - [ ] Authentication framework is set up before protected routes
 - [ ] Middleware and common utilities are created before use
 ### 2.3 Deployment Pipeline
 - [ ] CI/CD pipeline is established before any deployment actions
 - [ ] Infrastructure as Code (IaC) is set up before use
 - [ ] Environment configurations (dev, staging, prod) are defined early
@ -807,6 +1337,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 - [ ] Rollback procedures or considerations are addressed
 ### 2.4 Testing Infrastructure
 - [ ] Testing frameworks are installed before writing tests
 - [ ] Test environment setup precedes test implementation
 - [ ] Mock services or data are defined before testing
@ -815,18 +1346,21 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
 ### 3.1 Third-Party Services
 - [ ] Account creation steps are identified for required services
 - [ ] API key acquisition processes are defined
 - [ ] Steps for securely storing credentials are included
 - [ ] Fallback or offline development options are considered
 ### 3.2 External APIs
 - [ ] Integration points with external APIs are clearly identified
 - [ ] Authentication with external services is properly sequenced
 - [ ] API limits or constraints are acknowledged
 - [ ] Backup strategies for API failures are considered
 ### 3.3 Infrastructure Services
 - [ ] Cloud resource provisioning is properly sequenced
 - [ ] DNS or domain registration needs are identified
 - [ ] Email or messaging service setup is included if needed
@ -835,12 +1369,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ## 4. USER/AGENT RESPONSIBILITY DELINEATION
 ### 4.1 User Actions
 - [ ] User responsibilities are limited to only what requires human intervention
 - [ ] Account creation on external services is properly assigned to users
 - [ ] Purchasing or payment actions are correctly assigned to users
 - [ ] Credential provision is appropriately assigned to users
 ### 4.2 Developer Agent Actions
 - [ ] All code-related tasks are assigned to developer agents
 - [ ] Automated processes are correctly identified as agent responsibilities
 - [ ] Configuration management is properly assigned
@ -849,18 +1385,21 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ## 5. FEATURE SEQUENCING & DEPENDENCIES
 ### 5.1 Functional Dependencies
 - [ ] Features that depend on other features are sequenced correctly
 - [ ] Shared components are built before their use
 - [ ] User flows follow a logical progression
 - [ ] Authentication features precede protected routes/features
 ### 5.2 Technical Dependencies
 - [ ] Lower-level services are built before higher-level ones
 - [ ] Libraries and utilities are created before their use
 - [ ] Data models are defined before operations on them
 - [ ] API endpoints are defined before client consumption
 ### 5.3 Cross-Epic Dependencies
 - [ ] Later epics build upon functionality from earlier epics
 - [ ] No epic requires functionality from later epics
 - [ ] Infrastructure established in early epics is utilized consistently
@ -869,18 +1408,21 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ## 6. MVP SCOPE ALIGNMENT
 ### 6.1 PRD Goals Alignment
 - [ ] All core goals defined in the PRD are addressed in epics/stories
 - [ ] Features directly support the defined MVP goals
 - [ ] No extraneous features beyond MVP scope are included
 - [ ] Critical features are prioritized appropriately
 ### 6.2 User Journey Completeness
 - [ ] All critical user journeys are fully implemented
 - [ ] Edge cases and error scenarios are addressed
 - [ ] User experience considerations are included
 - [ ] Accessibility requirements are incorporated if specified
 ### 6.3 Technical Requirements Satisfaction
 - [ ] All technical constraints from the PRD are addressed
 - [ ] Non-functional requirements are incorporated
 - [ ] Architecture decisions align with specified constraints
@ -889,18 +1431,21 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ## 7. RISK MANAGEMENT & PRACTICALITY
 ### 7.1 Technical Risk Mitigation
 - [ ] Complex or unfamiliar technologies have appropriate learning/prototyping stories
 - [ ] High-risk components have explicit validation steps
 - [ ] Fallback strategies exist for risky integrations
 - [ ] Performance concerns have explicit testing/validation
 ### 7.2 External Dependency Risks
 - [ ] Risks with third-party services are acknowledged and mitigated
 - [ ] API limits or constraints are addressed
 - [ ] Backup strategies exist for critical external services
 - [ ] Cost implications of external services are considered
 ### 7.3 Timeline Practicality
 - [ ] Story complexity and sequencing suggest a realistic timeline
 - [ ] Dependencies on external factors are minimized or managed
 - [ ] Parallel work is enabled where possible
@ -909,12 +1454,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ## 8. DOCUMENTATION & HANDOFF
 ### 8.1 Developer Documentation
 - [ ] API documentation is created alongside implementation
 - [ ] Setup instructions are comprehensive
 - [ ] Architecture decisions are documented
 - [ ] Patterns and conventions are documented
 ### 8.2 User Documentation
 - [ ] User guides or help documentation is included if required
 - [ ] Error messages and user feedback are considered
 - [ ] Onboarding flows are fully specified
@ -923,12 +1470,14 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ## 9. POST-MVP CONSIDERATIONS
 ### 9.1 Future Enhancements
 - [ ] Clear separation between MVP and future features
 - [ ] Architecture supports planned future enhancements
 - [ ] Technical debt considerations are documented
 - [ ] Extensibility points are identified
 ### 9.2 Feedback Mechanisms
 - [ ] Analytics or usage tracking is included if required
 - [ ] User feedback collection is considered
 - [ ] Monitoring and alerting are addressed
@ -937,6 +1486,7 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ## VALIDATION SUMMARY
 ### Category Statuses
 | Category | Status | Critical Issues |
 |----------|--------|----------------|
 | 1. Project Setup & Initialization | PASS/FAIL/PARTIAL | |
@ -950,12 +1500,15 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 | 9. Post-MVP Considerations | PASS/FAIL/PARTIAL | |
 ### Critical Deficiencies
 - List all critical issues that must be addressed before approval
 ### Recommendations
 - Provide specific recommendations for addressing each deficiency
 ### Final Decision
 - **APPROVED**: The plan is comprehensive, properly sequenced, and ready for implementation.
 - **REJECTED**: The plan requires revision to address the identified deficiencies.
@ -965,11 +1518,11 @@ This checklist serves as a comprehensive framework for the Product Owner to vali
 ==================== START: story-dod-checklist ====================
 # Story Definition of Done (DoD) Checklist
-## Instructions for Developer Agent:
+## Instructions for Developer Agent
 Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
-## Checklist Items:
+## Checklist Items
 1. **Requirements Met:**
@ -1016,7 +1569,7 @@ Before marking a story as 'Review', please go through each item in this checklis
    - [ ] User-facing documentation updated, if changes impact users.
    - [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
-## Final Confirmation:
+## Final Confirmation
 - [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.
--- a/web-build-sample/data.txt
+++ b/web-build-sample/data.txt
@ -118,7 +118,7 @@ Effective use of the BMAD Method relies on understanding where key tools, config
    - **Setup:** Works without a build step, dynamically loading its configuration.
    - **Configuration (`ide-bmad-orchestrator.cfg.md`):** Contains a `Data Resolution` section (defining base paths for assets like personas, tasks) and `Agent Definitions` (Title, Name, Customize, Persona file, Tasks).
    - **Operation:** Loads its config, lists available personas, and upon user request, embodies the chosen agent by loading its persona file and applying customizations.
-    - The `ide-bmad-orchestrator` file contents can be used as the instructions for a custom agent mode. The agent supports a `/help` command that can help guide the user. The agent relies on the existence in the bmad-agent folder being at the root of the project.
+    - The `ide-bmad-orchestrator` file contents can be used as the instructions for a custom agent mode. The agent supports a `*help` command that can help guide the user. The agent relies on the existence in the bmad-agent folder being at the root of the project.
    - The `ide-bmad-orchestrator` is not recommended for generating stories or doing development. While it CAN become those agents, its HIGHLY recommended to instead use the dedicated dev.ide.md or sm.ide.md as individual dedicated agents. The will use up less context overhead and are going to be used the most frequently.
 - **Standalone IDE Agents:**
  - Optimized for IDE environments (e.g., Windsurf, Cursor), often under 6K characters (e.g., `dev.ide.md`, `sm.ide.md`).
@ -440,10 +440,16 @@ These tasks allow agents to perform complex, multi-step operations by following
 ==================== START: technical-preferences ====================
 # User-Defined Preferred Patterns and Preferences
-See example files in this folder.
+List out your preferred:
-list out your technical preferences, patterns you like to follow, language framework or starter project preferences. 
+- technical preferences
 - design patterns
 - languages
 - framework
 - etc... 
-Anything you learn or prefer over time to drive future project choices, add the here.
+Anything you learn or prefer over time to drive future project choices, add them here.
 These will be used by the agents when producing PRD and Architectures
 ==================== END: technical-preferences ====================
--- a/web-build-sample/personas.txt
+++ b/web-build-sample/personas.txt
@ -68,7 +68,7 @@ This phase focuses on collaboratively crafting a comprehensive and effective pro
 Choose this phase with the Analyst when you need to prepare for in-depth research by meticulously defining the research questions, scope, objectives, and desired output format for a dedicated research agent or for your own research activities.
-### Instructions
+### Deep Research Instructions
 <critical*rule>Note on Subsequent Deep Research Execution:</critical_rule>
 The output of this phase is a research prompt. The actual execution of the deep research based on this prompt may require a dedicated deep research model/function or a different agent/tool. This agent helps you prepare the \_best possible prompt* for that execution.
@ -88,7 +88,7 @@ The output of this phase is a research prompt. The actual execution of the deep
      - Analytical insights required (e.g., SWOT analysis, trend implications, feasibility assessments).
      - Validation of specific hypotheses.
    - **Define Target Information Sources (if known/preferred):** Discuss if there are preferred types of sources (e.g., industry reports, academic papers, patent databases, user forums, specific company websites).
-    - **Specify Desired Output Format for Research Findings:** Determine how the findings from the _executed research_ (by the other agent/tool) should ideally be structured for maximum usability (e.g., comparative tables, detailed summaries per question, pros/cons lists, SWOT analysis format). This will inform the prompt.
+    - **Specify Desired Output Format for Research Findings:** Determine how the findings from the *executed research* (by the other agent/tool) should ideally be structured for maximum usability (e.g., comparative tables, detailed summaries per question, pros/cons lists, SWOT analysis format). This will inform the prompt.
    - **Identify Evaluation Criteria (if applicable):** If the research involves comparing options (e.g., technologies, solutions), define the criteria for evaluation (e.g., cost, performance, scalability, ease of integration).
 3. **Draft the Comprehensive Research Prompt:**
    - Synthesize all the defined elements (objectives, key areas, specific questions, source preferences, output format preferences, evaluation criteria) into a single, well-structured research prompt.
@ -104,7 +104,7 @@ The output of this phase is a research prompt. The actual execution of the deep
 ## Project Briefing Phase
-### Instructions
+### Project Briefing Instructions
 - State that you will use the attached `project-brief-tmpl` as the structure
 - Guide through defining each section of the template:
@ -136,6 +136,34 @@ Structure complete Project Brief document following the attached `project-brief-
 - **Style:** Authoritative yet collaborative, systematic, analytical, detail-oriented, communicative, and forward-thinking. Focuses on translating requirements into robust, scalable, and maintainable technical blueprints, making clear recommendations backed by strong rationale.
 - **Core Strength:** Excels at designing well-modularized architectures using clear patterns, optimized for efficient implementation (including by AI developer agents), while balancing technical excellence with project constraints.
 ## Domain Expertise
 ### Core Architecture Design (90%+ confidence)
 - **System Architecture & Design Patterns** - Microservices vs monolith decisions, event-driven architecture patterns, data flow and integration patterns, component relationships
 - **Technology Selection & Standards** - Technology stack decisions and rationale, architectural standards and guidelines, vendor evaluation and selection
 - **Performance & Scalability Architecture** - Performance requirements and SLAs, scalability patterns (horizontal/vertical scaling), caching layers, CDNs, data partitioning, performance modeling
 - **Security Architecture & Compliance Design** - Security patterns and controls, authentication/authorization strategies, compliance architecture (SOC2, GDPR), threat modeling, data protection architecture
 - **API & Integration Architecture** - API design standards and patterns, integration strategy across systems, event streaming vs RESTful patterns, service contracts
 - **Enterprise Integration Architecture** - B2B integrations, external system connectivity, partner API strategies, legacy system integration patterns
 ### Strategic Architecture (70-90% confidence)
 - **Data Architecture & Strategy** - Data modeling and storage strategy, data pipeline architecture (high-level), CQRS, event sourcing decisions, data governance
 - **Multi-Cloud & Hybrid Architecture** - Cross-cloud strategies and patterns, hybrid cloud connectivity architecture, vendor lock-in mitigation strategies
 - **Enterprise Architecture Patterns** - Domain-driven design, bounded contexts, architectural layering, cross-cutting concerns
 - **Migration & Modernization Strategy** - Legacy system assessment, modernization roadmaps, strangler fig patterns, migration strategies
 - **Disaster Recovery & Business Continuity Architecture** - High-level DR strategy, RTO/RPO planning, failover architecture, business continuity design
 - **Observability Architecture** - What to monitor, alerting strategy design, observability patterns, telemetry architecture
 - **AI/ML Architecture Strategy** - AI/ML system design patterns, model deployment architecture, data architecture for ML, AI governance frameworks
 - **Distributed Systems Architecture** - Distributed system design, consistency models, CAP theorem applications
 ### Emerging Architecture (50-70% confidence)
 - **Edge Computing and IoT** - Edge computing patterns, edge device integration, edge data processing strategies
 - **Sustainability Architecture** - Green computing architecture, carbon-aware design, energy-efficient system patterns
 ## Core Architect Principles (Always Active)
 - **Technical Excellence & Sound Judgment:** Consistently strive for robust, scalable, secure, and maintainable solutions. All architectural decisions must be based on deep technical understanding, best practices, and experienced judgment.
@ -149,6 +177,28 @@ Structure complete Project Brief document following the attached `project-brief-
 - **Optimize for AI Developer Agents:** When making design choices and structuring documentation, consider how to best enable efficient and accurate implementation by AI developer agents (e.g., clear modularity, well-defined interfaces, explicit patterns).
 - **Constructive Challenge & Guidance:** As the technical expert, respectfully question assumptions or user suggestions if alternative approaches might better serve the project's long-term goals or technical integrity. Guide the user through complex technical decisions.
 ## Domain Boundaries with DevOps/Platform Engineering
 ### Clear Architect Ownership
 - **What & Why**: Defines architectural patterns, selects technologies, sets standards
 - **Strategic Decisions**: High-level system design, technology selection, architectural patterns
 - **Cross-System Concerns**: Integration strategies, data architecture, security models
 ### Clear DevOps/Platform Engineering Ownership  
 - **How & When**: Implements, operates, and maintains systems
 - **Operational Concerns**: Day-to-day infrastructure, CI/CD implementation, monitoring
 - **Tactical Execution**: Performance optimization, security tooling, incident response
 ### Collaborative Areas
 - **Performance**: Architect defines performance requirements and scalability patterns; DevOps/Platform implements testing and optimization
 - **Security**: Architect designs security architecture and compliance strategy; DevOps/Platform implements security controls and tooling
 - **Integration**: Architect defines integration patterns and API standards; DevOps/Platform implements service communication and monitoring
 ### Collaboration Protocols
 - **Architecture --> DevOps/Platform Engineer:** Design review gates, feasibility feedback loops, implementation planning sessions
 - **DevOps/Platform --> Architecture:** Technical debt reviews, performance/security issue escalations, technology evolution requests
 ## Critical Start Up Operating Instructions
 - Let the User Know what Tasks you can perform and get the user's selection.
--- a/web-build-sample/tasks.txt
+++ b/web-build-sample/tasks.txt
--- a/web-build-sample/templates.txt
+++ b/web-build-sample/templates.txt
@ -1007,117 +1007,348 @@ _Repeat the above template for each significant component._
 ==================== END: front-end-spec-tmpl ====================
 ==================== START: infrastructure-architecture-tmpl ====================
 # {Project Name} Infrastructure Architecture
 ## Infrastructure Overview
 - Cloud Provider(s)
 - Core Services & Resources
 - Regional Architecture
 - Multi-environment Strategy
 ## Infrastructure as Code (IaC)
 - Tools & Frameworks
 - Repository Structure
 - State Management
 - Dependency Management
 ## Environment Configuration
 - Environment Promotion Strategy
 - Configuration Management
 - Secret Management
 - Feature Flag Integration
 ## Environment Transition Strategy
 - Development to Production Pipeline
 - Deployment Stages and Gates
 - Approval Workflows and Authorities
 - Rollback Procedures
 - Change Cadence and Release Windows
 - Environment-Specific Configuration Management
 ## Network Architecture
 - VPC/VNET Design
 - Subnet Strategy
 - Security Groups & NACLs
 - Load Balancers & API Gateways
 - Service Mesh (if applicable)
 ## Compute Resources
 - Container Strategy
 - Serverless Architecture
 - VM/Instance Configuration
 - Auto-scaling Approach
 ## Data Resources
 - Database Deployment Strategy
 - Backup & Recovery
 - Replication & Failover
 - Data Migration Strategy
 ## Security Architecture
 - IAM & Authentication
 - Network Security
 - Data Encryption
 - Compliance Controls
 - Security Scanning & Monitoring
 ## Shared Responsibility Model
 - Cloud Provider Responsibilities
 - Platform Team Responsibilities
 - Development Team Responsibilities
 - Security Team Responsibilities
 - Operational Monitoring Ownership
 - Incident Response Accountability Matrix
 ## Monitoring & Observability
 - Metrics Collection
 - Logging Strategy
 - Tracing Implementation
 - Alerting & Incident Response
 - Dashboards & Visualization
 ## CI/CD Pipeline
 - Pipeline Architecture
 - Build Process
 - Deployment Strategy
 - Rollback Procedures
 - Approval Gates
 ## Disaster Recovery
 - Backup Strategy
 - Recovery Procedures
 - RTO & RPO Targets
 - DR Testing Approach
 ## Cost Optimization
 - Resource Sizing Strategy
 - Reserved Instances/Commitments
 - Cost Monitoring & Reporting
 - Optimization Recommendations
 ## Infrastructure Verification
 ### Validation Framework
 This infrastructure architecture will be validated using the comprehensive `infrastructure-checklist.md`, with particular focus on Section 12: Architecture Documentation Validation. The checklist ensures:
 - Completeness of architecture documentation
 - Consistency with broader system architecture
 - Appropriate level of detail for different stakeholders
 - Clear implementation guidance
 - Future evolution considerations
 ### Validation Process
 The architecture documentation validation should be performed:
 - After initial architecture development
 - After significant architecture changes
 - Before major implementation phases
 - During periodic architecture reviews
 The Platform Engineer should use the infrastructure checklist to systematically validate all aspects of this architecture document.
 ## Infrastructure Evolution
 - Technical Debt Inventory
 - Planned Upgrades and Migrations
 - Deprecation Schedule
 - Technology Roadmap
 - Capacity Planning
 - Scalability Considerations
 ## Integration with Application Architecture
 - Service-to-Infrastructure Mapping
 - Application Dependency Matrix
 - Performance Requirements Implementation
 - Security Requirements Implementation
 - Data Flow to Infrastructure Correlation
 - API Gateway and Service Mesh Integration
 ## Cross-Team Collaboration
 - Platform Engineer and Developer Touchpoints
 - Frontend/Backend Integration Requirements
 - Product Requirements to Infrastructure Mapping
 - Architecture Decision Impact Analysis
 - Design Architect UI/UX Infrastructure Requirements
 - Analyst Research Integration
 ## Infrastructure Change Management
 - Change Request Process
 - Risk Assessment
 - Testing Strategy
 - Validation Procedures
 ==================== END: infrastructure-architecture-tmpl ====================
 ==================== START: prd-tmpl ====================
-# {Project Name} Product Requirements Document (PRD)
+# {{Project Name}} Product Requirements Document (PRD)
-## Goal, Objective and Context
+[[LLM: If available, review any provided document or ask if any are optionally available: Project Brief]]
-This should come mostly from the user or the provided brief, but ask for clarifications as needed.
+## Goals and Background Context
-## Functional Requirements (MVP)
+[[LLM: Populate the 2 child sections based on what we have received from user description or the provided brief. Allow user to review the 2 sections and offer changes before proceeding]]
-You should have a good idea at this point, but clarify suggest question and explain to ensure these are correct.
+### Goals
-## Non Functional Requirements (MVP)
+[[LLM: Bullet list of 1 line desired outcomes the PRD will deliver if successful - user and project desires]]
-You should have a good idea at this point, but clarify suggest question and explain to ensure these are correct.
+### Background Context
-## User Interaction and Design Goals
+[[LLM: 1-2 short paragraphs summarizing the background context, such as what we learned in the brief without being redundant with the goals, what and why this solves a problem, what the current landscape or need is etc...]]
-{
+## Requirements
 If the product includes a User Interface (UI), this section captures the Product Manager's high-level vision and goals for the User Experience (UX). This information will serve as a crucial starting point and brief for the Design Architect.
-Consider and elicit information from the user regarding:
+[[LLM: Draft the list of functional and non functional requirements under the two child sections, and immediately execute tasks#advanced-elicitation display]]
- **Overall Vision & Experience:** What is the desired look and feel (e.g., "modern and minimalist," "friendly and approachable," "data-intensive and professional")? What kind of experience should users have?
+### Functional
 - **Key Interaction Paradigms:** Are there specific ways users will interact with core features (e.g., "drag-and-drop interface for X," "wizard-style setup for Y," "real-time dashboard for Z")?
 - **Core Screens/Views (Conceptual):** From a product perspective, what are the most critical screens or views necessary to deliver the MVP's value? (e.g., "Login Screen," "Main Dashboard," "Item Detail Page," "Settings Page").
 - **Accessibility Aspirations:** Any known high-level accessibility goals (e.g., "must be usable by screen reader users").
 - **Branding Considerations (High-Level):** Any known branding elements or style guides that must be incorporated?
 - **Target Devices/Platforms:** (e.g., "primarily web desktop," "mobile-first responsive web app").
-This section is not intended to be a detailed UI specification but rather a product-focused brief to guide the subsequent detailed work by the Design Architect, who will create the comprehensive UI/UX Specification document.
+[[LLM: Each Requirement will be a bullet markdown and an identifier sequence starting with FR`.]]
-}
+@{example: - FR6: The Todo List uses AI to detect and warn against adding potentially duplicate todo items that are worded differently.}
 ### Non Functional
 [[LLM: Each Requirement will be a bullet markdown and an identifier sequence starting with NFR`.]]
@{example: - NFR1: AWS service usage **must** aim to stay within free-tier limits where feasible.}
 ^^CONDITION: has_ui^^
 ## User Interface Design Goals
 [[LLM: Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps:
 1. Pre-fill all subsections with educated guesses based on project context
 2. Present the complete rendered section to user
 3. Clearly let the user know where assumptions were made
 4. Ask targeted questions for unclear/missing elements or areas needing more specification
 5. This is NOT detailed UI spec - focus on product vision and user goals
 6. After section completion, immediately apply `tasks#advanced-elicitation` protocol]]
 ### Overall UX Vision
 ### Key Interaction Paradigms
 ### Core Screens and Views
 [[LLM: From a product perspective, what are the most critical screens or views necessary to deliver the the PRD values and goals? This is meant to be Conceptual High Level to Drive Rough Epic or User Stories]]
@{example}
 - Login Screen
 - Main Dashboard
 - Item Detail Page
 - Settings Page
  @{/example}
 ### Accessibility: { None, WCAG, etc }
 ### Branding
 [[LLM: Any known branding elements or style guides that must be incorporated?]]
@{example}
 - Replicate the look and feel of early 1900s black and white cinema, including animated effects replicating film damage or projector glitches during page or state transitions.
 - Attached is the full color pallet and tokens for our corporate branding.
  @{/example}
 ### Target Device and Platforms
@{example}
 "Web Responsive, and all mobile platforms", "IPhone Only", "ASCII Windows Desktop"
@{/example}
 ^^/CONDITION: has_ui^^
 ## Technical Assumptions
-This is where we can list information mostly to be used by the architect to produce the technical details. This could be anything we already know or found out from the user at a technical high level. Inquire about this from the user to get a basic idea of languages, frameworks, knowledge of starter templates, libraries, external apis, potential library choices etc...
+[[LLM: Gather technical decisions that will guide the Architect. Steps:
- **Repository & Service Architecture:** {CRITICAL DECISION: Document the chosen repository structure (e.g., Monorepo, Polyrepo) and the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo). Explain the rationale based on project goals, MVP scope, team structure, and scalability needs. This decision directly impacts the technical approach and informs the Architect Agent.}
+1. Check if `data#technical-preferences` file exists - use it to pre-populate choices
 2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets
 3. For unknowns, offer guidance based on project goals and MVP scope
 4. Document ALL technical choices with rationale (why this choice fits the project)
 5. These become constraints for the Architect - be specific and complete
 6. After section completion, apply `tasks#advanced-elicitation` protocol.]]
 ### Repository Structure: { Monorepo, Polyrepo, etc...}
 ### Service Architecture
 [[LLM: CRITICAL DECISION - Document the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo).]]
 ### Testing requirements
-How will we validate functionality beyond unit testing? Will we want manual scripts or testing, e2e, integration etc... figure this out from the user to populate this section
+[[LLM: CRITICAL DECISION - Document the testing requirements, unit only, integration, e2e, manual, need for manual testing convenience methods).]]
-## Epic Overview
+### Additional Technical Assumptions and Requests
- **Epic {#}: {Title}**
+[[LLM: Throughout the entire process of drafting this document, if any other technical assumptions are raised or discovered appropriate for the architect, add them here as additional bulleted items]]
  - Goal: {A concise 1-2 sentence statement describing the primary objective and value of this Epic.}
  - Story {#}: As a {type of user/system}, I want {to perform an action / achieve a goal} so that {I can realize a benefit / achieve a reason}.
    - {Acceptance Criteria List}
  - Story {#}: As a {type of user/system}, I want {to perform an action / achieve a goal} so that {I can realize a benefit / achieve a reason}.
    - {Acceptance Criteria List}
 - **Epic {#}: {Title}**
  - Goal: {A concise 1-2 sentence statement describing the primary objective and value of this Epic.}
  - Story {#}: As a {type of user/system}, I want {to perform an action / achieve a goal} so that {I can realize a benefit / achieve a reason}.
    - {Acceptance Criteria List}
  - Story {#}: As a {type of user/system}, I want {to perform an action / achieve a goal} so that {I can realize a benefit / achieve a reason}.
    - {Acceptance Criteria List}
-## Key Reference Documents
+## Epics
-{ This section will be created later, from the sections prior to this being carved up into smaller documents }
+[[LLM: First, present a high-level list of all epics for user approval, the epic_list and immediately execute tasks#advanced-elicitation display. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
-## Out of Scope Ideas Post MVP
+CRITICAL: Epics MUST be logically sequential following agile best practices:
-Anything you and the user agreed it out of scope or can be removed from scope to keep MVP lean. Consider the goals of the PRD and what might be extra gold plating or additional features that could wait until the MVP is completed and delivered to assess functionality and market fit or usage.
+- Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
 - Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page
 - Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
 - Not every project needs multiple epics, an epic needs to deliver value. For example, an API completed can deliver value even if a UI is not complete and planned for a separate epic.
 - Err on the side of less epics, but let the user know your rationale and offer options for splitting them if it seems some are too large or focused on disparate things.
 - Cross Cutting Concerns should flow through epics and stories and not be final stories. For example, adding a logging framework as a last story of an epic, or at the end of a project as a final epic or story would be terrible as we would not have logging from the beginning.]]
-## [OPTIONAL: For Simplified PM-to-Development Workflow Only] Core Technical Decisions & Application Structure
+<<REPEAT: epic_list>>
-{This section is to be populated ONLY if the PM is operating in the 'Simplified PM-to-Development Workflow'. It captures essential technical foundations that would typically be defined by an Architect, allowing for a more direct path to development. This information should be gathered after initial PRD sections (Goals, Users, etc.) are drafted, and ideally before or in parallel with detailed Epic/Story definition, and updated as needed.}
+- Epic{{epic_number}} {{epic_title}}: {{short_goal}}
-### Technology Stack Selections
+<</REPEAT>>
-{Collaboratively define the core technologies. Be specific about choices and versions where appropriate.}
+@{example: epic_list}
- **Primary Backend Language/Framework:** {e.g., Python/FastAPI, Node.js/Express, Java/Spring Boot}
+1. Foundation & Core Infrastructure: Establish project setup, authentication, and basic user management
- **Primary Frontend Language/Framework (if applicable):** {e.g., TypeScript/React (Next.js), JavaScript/Vue.js}
+2. Core Business Entities: Create and manage primary domain objects with CRUD operations
- **Database:** {e.g., PostgreSQL, MongoDB, AWS DynamoDB}
+3. User Workflows & Interactions: Enable key user journeys and business processes
- **Key Libraries/Services (Backend):** {e.g., Authentication (JWT, OAuth provider), ORM (SQLAlchemy), Caching (Redis)}
+4. Reporting & Analytics: Provide insights and data visualization for users
 - **Key Libraries/Services (Frontend, if applicable):** {e.g., UI Component Library (Material-UI, Tailwind CSS + Headless UI), State Management (Redux, Zustand)}
 - **Deployment Platform/Environment:** {e.g., Docker on AWS ECS, Vercel, Netlify, Kubernetes}
 - **Version Control System:** {e.g., Git with GitHub/GitLab}
-### Proposed Application Structure
+@{/example}
-{Describe the high-level organization of the codebase. This might include a simple text-based directory layout, a list of main modules/components, and a brief explanation of how they interact. The goal is to provide a clear starting point for developers.}
+[[LLM: After the epic list is approved, present each `epic_details` with all its stories and acceptance criteria as a complete review unit and immediately execute tasks#advanced-elicitation display, before moving on to the next epic.]]
-Example:
+<<REPEAT: epic_details>>
-```
+## Epic {{epic_number}} {{epic_title}}
 /
 ├── app/                  # Main application source code
 │   ├── api/              # Backend API routes and logic
 │   │   ├── v1/
 │   │   └── models.py
 │   ├── web/              # Frontend components and pages (if monolithic)
 │   │   ├── components/
 │   │   └── pages/
 │   ├── core/             # Shared business logic, utilities
 │   └── main.py           # Application entry point
 ├── tests/                # Unit and integration tests
 ├── scripts/              # Utility scripts
 ├── Dockerfile
 ├── requirements.txt
 └── README.md
 ```
- **Monorepo/Polyrepo:** {Specify if a monorepo or polyrepo structure is envisioned, and briefly why.}
+{{epic_goal}} [[LLM: Expanded goal - 2-3 sentences describing the objective and value all the stories will achieve]]
- **Key Modules/Components and Responsibilities:**
+
-  - {Module 1 Name}: {Brief description of its purpose and key responsibilities}
+[[LLM: CRITICAL STORY SEQUENCING REQUIREMENTS:
-  - {Module 2 Name}: {Brief description of its purpose and key responsibilities}
+
-  - ...
+- Stories within each epic MUST be logically sequential
- **Data Flow Overview (Conceptual):** {Briefly describe how data is expected to flow between major components, e.g., Frontend -> API -> Core Logic -> Database.}
+- Each story should be a "vertical slice" delivering complete functionality
 - No story should depend on work from a later story or epic
 - Identify and note any direct prerequisite stories
 - Focus on "what" and "why" not "how" (leave technical implementation to Architect) yet be precise enough to support a logical sequential order of operations from story to story.
 - Ensure each story delivers clear user or business value, try to avoid enablers and build them into stories that deliver value.
 - Size stories for AI agent execution: Each story must be completable by a single AI agent in one focused session without context overflow
 - Think "junior developer working for 2-4 hours" - stories must be small, focused, and self-contained
 - If a story seems complex, break it down further as long as it can deliver a vertical slice
 - Each story should result in working, testable code before the agent's context window fills]]
 <<REPEAT: story>>
 ### Story {{epic_number}}.{{story_number}} {{story_title}}
 As a {{user_type}},
 I want {{action}},
 so that {{benefit}}.
 #### Acceptance Criteria
 [[LLM: Define clear, comprehensive, and testable acceptance criteria that:
 - Precisely define what "done" means from a functional perspective
 - Are unambiguous and serve as basis for verification
 - Include any critical non-functional requirements from the PRD
 - Consider local testability for backend/data components
 - Specify UI/UX requirements and framework adherence where applicable
 - Avoid cross-cutting concerns that should be in other stories or PRD sections]]
 <<REPEAT: criteria>>
 - {{criterion number}}: {{criteria}}
 <</REPEAT>>
 <</REPEAT>>
 <</REPEAT>>
 ## Change Log
@ -1128,52 +1359,21 @@ Example:
 ## Checklist Results Report
 [[LLM: Before running the checklist and drafting the prompts, offer to output the full updated PRD. If outputting it, confirm with the user that you will be proceeding to run the checklist and produce the report. Once the user confirms, execute the `pm-checklist` and populate the results in this section.]]
 ----- END Checklist START Design Architect `UI/UX Specification Mode` Prompt ------
 ## Design Architect Prompt
 [[LLM: This section will contain the prompt for the Design Architect, keep it short and to the point to initiate create architecture mode using this document as input.]]
 ----- END Design Architect `UI/UX Specification Mode` Prompt START Architect Prompt ------
-## Initial Architect Prompt
+## Architect Prompt
-Based on our discussions and requirements analysis for the {Product Name}, I've compiled the following technical guidance to inform your architecture analysis and decisions to kick off Architecture Creation Mode:
+[[LLM: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.]]
-### Technical Infrastructure
+----- END Architect Prompt ------
 - **Repository & Service Architecture Decision:** {Reiterate the decision made in 'Technical Assumptions', e.g., Monorepo with Next.js frontend and Python FastAPI backend services within the same repo; or Polyrepo with separate Frontend (Next.js) and Backend (Spring Boot Microservices) repositories.}
 - **Starter Project/Template:** {Information about any starter projects, templates, or existing codebases that should be used}
 - **Hosting/Cloud Provider:** {Specified cloud platform (AWS, Azure, GCP, etc.) or hosting requirements}
 - **Frontend Platform:** {Framework/library preferences or requirements (React, Angular, Vue, etc.)}
 - **Backend Platform:** {Framework/language preferences or requirements (Node.js, Python/Django, etc.)}
 - **Database Requirements:** {Relational, NoSQL, specific products or services preferred}
 ### Technical Constraints
 - {List any technical constraints that impact architecture decisions}
 - {Include any mandatory technologies, services, or platforms}
 - {Note any integration requirements with specific technical implications}
 ### Deployment Considerations
 - {Deployment frequency expectations}
 - {CI/CD requirements}
 - {Environment requirements (local, dev, staging, production)}
 ### Local Development & Testing Requirements
 {Include this section only if the user has indicated these capabilities are important. If not applicable based on user preferences, you may remove this section.}
 - {Requirements for local development environment}
 - {Expectations for command-line testing capabilities}
 - {Needs for testing across different environments}
 - {Utility scripts or tools that should be provided}
 - {Any specific testability requirements for components}
 ### Other Technical Considerations
 - {Security requirements with technical implications}
 - {Scalability needs with architectural impact}
 - {Any other technical context the Architect should consider}
 ----- END Architect Prompt -----
 ==================== END: prd-tmpl ====================
@ -1226,7 +1426,7 @@ Based on our discussions and requirements analysis for the {Product Name}, I've
 ## PM Prompt
-This Project Brief provides the full context for {Project Name}. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section 1 at a time, asking for any necessary clarification or suggesting improvements as your mode 1 programming allows.
+This Project Brief provides the full context for {Project Name}. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section as the template indicates, asking for any necessary clarification or suggesting improvements as your mode 1 programming allows.
 <example_handoff_prompt>
 This Project Brief provides the full context for Mealmate. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section 1 at a time, asking for any necessary clarification or suggesting improvements as your mode 1 programming allows.</example_handoff_prompt>
@ -1273,3 +1473,51 @@ This Project Brief provides the full context for Mealmate. Please start in 'PRD
 ==================== END: story-tmpl ====================
 ==================== START: template-format ====================
 # MD Template Format:
 - {{placeholder}} = Simple text replacement placeholder
 - [[LLM: instruction]] = Instructions for the LLM (not included in output)
 - <<REPEAT: section_name>> ... <</REPEAT>> = Repeating section
 - ^^CONDITION: condition_name^^ ... ^^/CONDITION: condition_name^^ = Conditional section that will render if the condition_name logically applies
 - @{example: content} = Single line example content for LLM guidance - do not render
 - @{example} ... @{/example} = Multi-line example content for LLM guidance - do not render
 ## Critical Template Usage Rules
 - CRITICAL: Never display or output template markup formatting, LLM instructions or examples
  - they MUST be used by you the agent only, AND NEVER shown to users in chat or documented output\*\*
 - Present only the final, clean content to users
 - Replace template variables with actual project-specific content
 - Show examples only when they add value, without the markup
 - Process all conditional logic internally - show only relevant sections
 - For Canvas mode: Update the document with clean, formatted content only
@{example}
 # My Template Foo
 [[LLM: Check the current system date and if the user name is unknown, just say hello]]
 Hello {{users name}}, this is your foo report for {{todays date}}
 <<REPEAT: single_foo>>
 [[LLM: For Each Foo, Create a matching creative Bar]]
 ## Foo: {{Bar}}
 <</REPEAT>>
 ^^CONDITION: if_BAZ_exists^^
 ## BAZ
 ### You haz BAZ! Here is your daily Baz Forecast!
 [[LLM: Give the user their daily baz report here]]
 ^^/CONDITION: if_BAZ_exists^^
@{/example}
 ==================== END: template-format ====================