observer-ggboy-bmad-method 6.0.0-alpha.23

package/docs/how-to/workflows/setup-party-mode.md

@@ -0,0 +1,89 @@
+---
+title: "How to Set Up Party Mode"
+description: How to set up and use Party Mode for multi-agent collaboration
+---
+
+Use Party Mode to orchestrate dynamic multi-agent conversations with your entire BMad team.
+
+## When to Use This
+
+- Exploring complex topics that benefit from diverse expert perspectives
+- Brainstorming with agents who can build on each other's ideas
+- Getting comprehensive views across multiple domains
+- Strategic decisions with trade-offs
+
+:::note[Prerequisites]
+- BMad Method installed with multiple agents
+- Any agent loaded that supports party mode
+:::
+
+## Steps
+
+### 1. Load Any Agent
+
+Start with any agent that supports party mode (most do).
+
+### 2. Start Party Mode
+
+```
+*party-mode
+```
+
+Or use the full path:
+```
+/bmad:core:workflows:party-mode
+```
+
+### 3. Introduce Your Topic
+
+Present a topic or question for the group to discuss:
+
+```
+I'm trying to decide between a monolithic architecture
+and microservices for our new platform.
+```
+
+### 4. Engage with the Discussion
+
+The facilitator will:
+- Select 2-3 most relevant agents based on expertise
+- Let agents respond in character
+- Enable natural cross-talk and debate
+- Continue until you choose to exit
+
+### 5. Exit When Ready
+
+Type "exit" or "done" to conclude the session. Participating agents will say personalized farewells.
+
+## What Happens
+
+1. **Agent Roster** — Party Mode loads your complete agent roster
+2. **Introduction** — Available team members are introduced
+3. **Topic Analysis** — The facilitator analyzes your topic
+4. **Agent Selection** — 2-3 most relevant agents are selected
+5. **Discussion** — Agents respond, reference each other, engage in cross-talk
+6. **Exit** — Session concludes with farewells
+
+## Example Party Compositions
+
+| Topic                  | Typical Agents                                        |
+| ---------------------- | ----------------------------------------------------- |
+| **Product Strategy**   | PM + Innovation Strategist + Analyst                  |
+| **Technical Design**   | Architect + Creative Problem Solver  + Game Architect |
+| **User Experience**    | UX Designer + Design Thinking Coach  + Storyteller    |
+| **Quality Assessment** | TEA + DEV + Architect                                 |
+
+## Key Features
+
+- **Intelligent agent selection** — Selects based on expertise needed
+- **Authentic personalities** — Each agent maintains their unique voice
+- **Natural cross-talk** — Agents reference and build on each other
+- **Graceful exit** — Personalized farewells
+
+## Tips
+
+- **Be specific about your topic** — Better agent selection
+- **Let the conversation flow** — Don't over-direct
+- **Ask follow-up questions** — Go deeper on interesting points
+- **Take notes on key insights** — Capture valuable perspectives
+- **Use for strategic decisions** — Not routine tasks

package/docs/how-to/workflows/setup-test-framework.md

@@ -0,0 +1,98 @@
+---
+title: "How to Set Up a Test Framework with TEA"
+description: How to set up a production-ready test framework using TEA
+---
+
+Use TEA's `*framework` workflow to scaffold a production-ready test framework for your project.
+
+## When to Use This
+
+- No existing test framework in your project
+- Current test setup isn't production-ready
+- Starting a new project that needs testing infrastructure
+- Phase 3 (Solutioning) after architecture is complete
+
+:::note[Prerequisites]
+- BMad Method installed
+- Architecture completed (or at least tech stack decided)
+- TEA agent available
+:::
+
+## Steps
+
+### 1. Load the TEA Agent
+
+Start a fresh chat and load the TEA (Test Architect) agent.
+
+### 2. Run the Framework Workflow
+
+```
+*framework
+```
+
+### 3. Answer TEA's Questions
+
+TEA will ask about:
+
+- Your tech stack (React, Node, etc.)
+- Preferred test framework (Playwright, Cypress, Jest)
+- Testing scope (E2E, integration, unit)
+- CI/CD platform (GitHub Actions, etc.)
+
+### 4. Review Generated Output
+
+TEA generates:
+
+- **Test scaffold** — Directory structure and config files
+- **Sample specs** — Example tests following best practices
+- **`.env.example`** — Environment variable template
+- **`.nvmrc`** — Node version specification
+- **README updates** — Testing documentation
+
+## What You Get
+
+```
+tests/
+├── e2e/
+│   ├── example.spec.ts
+│   └── fixtures/
+├── integration/
+├── unit/
+├── playwright.config.ts  # or cypress.config.ts
+└── README.md
+```
+
+## Optional: Playwright Utils Integration
+
+TEA can integrate with `@seontechnologies/playwright-utils` for advanced fixtures:
+
+```bash
+npm install -D @seontechnologies/playwright-utils
+```
+
+Enable during BMad installation or set `tea_use_playwright_utils: true` in config.
+
+**Utilities available:** api-request, network-recorder, auth-session, intercept-network-call, recurse, log, file-utils, burn-in, network-error-monitor
+
+## Optional: MCP Enhancements
+
+TEA can use Playwright MCP servers for enhanced capabilities:
+
+- `playwright` — Browser automation
+- `playwright-test` — Test runner with failure analysis
+
+Configure in your IDE's MCP settings.
+
+## Tips
+
+- **Run only once per repository** — Framework setup is a one-time operation
+- **Run after architecture is complete** — Framework aligns with tech stack
+- **Follow up with CI setup** — Run `*ci` to configure CI/CD pipeline
+
+## Next Steps
+
+After test framework setup:
+
+1. **Test Design** — Create test plans for system or epics
+2. **CI Configuration** — Set up automated test runs
+3. **Story Implementation** — Tests are ready for development

package/docs/index.md

@@ -0,0 +1,63 @@
+---
+title: Welcome to the BMad Method
+---
+
+The BMad Method (**B**reakthrough **M**ethod of **A**gile AI **D**riven Development) is an AI-driven development framework that helps you build software faster and smarter. It provides specialized AI agents, guided workflows, and intelligent planning that adapts to your project's complexity—whether you're fixing a bug or building an enterprise platform.
+
+If you're comfortable working with AI coding assistants like Claude, Cursor, or GitHub Copilot, you're ready to get started.
+
+---
+
+## New Here? Start with a Tutorial
+
+The fastest way to understand BMad is to try it. Choose a tutorial to walk through your first project in about 10 minutes.
+
+- **[Get Started with BMad](/docs/tutorials/getting-started/getting-started-bmadv6.md)** — Latest features, still in active development
+
+:::tip[Already familiar with AI-assisted development?]
+Feel free to skip around. Use the sidebar to jump to any topic, or check out [What Are Agents?](/docs/explanation/core-concepts/what-are-agents.md) to understand how BMad organizes its AI personas.
+:::
+
+---
+
+## How to Use These Docs
+
+These docs are organized into four sections based on what you're trying to do:
+
+| Section           | Purpose                                                                                                    |
+| ----------------- | ---------------------------------------------------------------------------------------------------------- |
+| **Tutorials**     | Learning-oriented. Step-by-step guides that walk you through building something. Start here if you're new. |
+| **How-To Guides** | Task-oriented. Practical guides for solving specific problems. "How do I customize an agent?" lives here.  |
+| **Explanation**   | Understanding-oriented. Deep dives into concepts and architecture. Read when you want to know *why*.       |
+| **Reference**     | Information-oriented. Technical specifications for agents, workflows, and configuration.                   |
+
+---
+
+## What You'll Need
+
+BMad works with any AI coding assistant that supports custom system prompts or project context. Popular options include:
+
+- **[Claude Code](https://code.claude.com)** — Anthropic's CLI tool (recommended)
+- **[Cursor](https://cursor.sh)** — AI-first code editor
+- **[Windsurf](https://codeium.com/windsurf)** — Codeium's AI IDE
+- **[Roo Code](https://roocode.com)** — VS Code extension
+
+You should be comfortable with basic software development concepts like version control, project structure, and agile workflows. No prior experience with BMad-style agent systems is required—that's what these docs are for.
+
+---
+
+## Join the Community
+
+Get help, share what you're building, or contribute to BMad:
+
+- **[Discord](https://discord.gg/gk8jAdXWmj)** — Chat with other BMad users, ask questions, share ideas
+- **[GitHub](https://github.com/bmad-code-org/BMAD-METHOD)** — Source code, issues, and contributions
+- **[YouTube](https://www.youtube.com/@BMadCode)** — Video tutorials and walkthroughs
+
+---
+
+## Next Step
+
+Ready to dive in? Pick a tutorial and start building.
+
+- **[Get Started with BMad](/docs/tutorials/getting-started/getting-started-bmadv6.md)** — Explore the latest features

package/docs/reference/agents/index.md

@@ -0,0 +1,109 @@
+---
+title: "Agents Reference"
+description: Complete reference for BMad Method agents and their commands
+---
+
+Quick reference of all BMad Method agents and their available commands.
+
+:::tip[Universal Commands]
+All agents support: `*menu` (redisplay options), `*dismiss` (dismiss agent), and `*party-mode` (multi-agent collaboration).
+:::
+
+## Analyst (Mary)
+
+Business analysis and research.
+
+**Commands:**
+- `*workflow-status` — Get workflow status or initialize tracking
+- `*brainstorm-project` — Guided brainstorming session
+- `*research` — Market, domain, competitive, or technical research
+- `*product-brief` — Create a product brief (input for PRD)
+- `*document-project` — Document existing brownfield projects
+
+## PM (John)
+
+Product requirements and planning.
+
+**Commands:**
+- `*workflow-status` — Get workflow status or initialize tracking
+- `*create-prd` — Create Product Requirements Document
+- `*create-epics-and-stories` — Break PRD into epics and user stories (after Architecture)
+- `*implementation-readiness` — Validate PRD, UX, Architecture, Epics alignment
+- `*correct-course` — Course correction during implementation
+
+## Architect (Winston)
+
+System architecture and technical design.
+
+**Commands:**
+- `*workflow-status` — Get workflow status or initialize tracking
+- `*create-architecture` — Create architecture document to guide development
+- `*implementation-readiness` — Validate PRD, UX, Architecture, Epics alignment
+- `*create-excalidraw-diagram` — System architecture or technical diagrams
+- `*create-excalidraw-dataflow` — Data flow diagrams
+
+## SM (Bob)
+
+Sprint planning and story preparation.
+
+**Commands:**
+- `*sprint-planning` — Generate sprint-status.yaml from epic files
+- `*create-story` — Create story from epic (prep for development)
+- `*validate-create-story` — Validate story quality
+- `*epic-retrospective` — Team retrospective after epic completion
+- `*correct-course` — Course correction during implementation
+
+## DEV (Amelia)
+
+Story implementation and code review.
+
+**Commands:**
+- `*dev-story` — Execute story workflow (implementation with tests)
+- `*code-review` — Thorough code review
+
+## Quick Flow Solo Dev (Barry)
+
+Fast solo development without handoffs.
+
+**Commands:**
+- `*quick-spec` — Architect technical spec with implementation-ready stories
+- `*quick-dev` — Implement tech spec end-to-end solo
+- `*code-review` — Review and improve code
+
+## TEA (Murat)
+
+Test architecture and quality strategy.
+
+**Commands:**
+- `*framework` — Initialize production-ready test framework
+- `*atdd` — Generate E2E tests first (before implementation)
+- `*automate` — Comprehensive test automation
+- `*test-design` — Create comprehensive test scenarios
+- `*trace` — Map requirements to tests, quality gate decision
+- `*nfr-assess` — Validate non-functional requirements
+- `*ci` — Scaffold CI/CD quality pipeline
+- `*test-review` — Review test quality
+
+## UX Designer (Sally)
+
+User experience and UI design.
+
+**Commands:**
+- `*create-ux-design` — Generate UX design and UI plan from PRD
+- `*validate-design` — Validate UX specification and design artifacts
+- `*create-excalidraw-wireframe` — Create website or app wireframe
+
+## Technical Writer (Paige)
+
+Technical documentation and diagrams.
+
+**Commands:**
+- `*document-project` — Comprehensive project documentation
+- `*generate-mermaid` — Generate Mermaid diagrams
+- `*create-excalidraw-flowchart` — Process and logic flow visualizations
+- `*create-excalidraw-diagram` — System architecture or technical diagrams
+- `*create-excalidraw-dataflow` — Data flow visualizations
+- `*validate-doc` — Review documentation against standards
+- `*improve-readme` — Review and improve README files
+- `*explain-concept` — Create clear technical explanations
+- `*standards-guide` — Show BMad documentation standards

package/docs/reference/configuration/core-tasks.md

@@ -0,0 +1,67 @@
+---
+title: "Core Tasks"
+---
+
+Reusable task definitions that can be invoked by any BMad module, workflow, or agent.
+
+## Contents
+
+- [Index Docs](#index-docs) — Generate directory index files
+- [Adversarial Review](#adversarial-review) — Critical content review
+- [Shard Document](#shard-document) — Split large documents into sections
+
+## Index Docs
+
+**Generates or updates an index.md file documenting all files in a specified directory.**
+
+**Use it when:**
+- You need navigable documentation for a folder of markdown files
+- You want to maintain an updated index as content evolves
+
+**How it works:**
+1. Scan the target directory for files and subdirectories
+2. Group content by type, purpose, or location
+3. Read each file to generate brief (3-10 word) descriptions
+4. Create or update index.md with organized listings
+
+**Output:** Markdown index with sections for Files and Subdirectories, each entry containing a relative link and description.
+
+## Adversarial Review
+
+**Performs a cynical, skeptical review of any content to identify issues and improvement opportunities.**
+
+**Use it when:**
+- Reviewing code diffs before merging
+- Finalizing specifications or user stories
+- Releasing documentation
+- Any artifact needs a critical eye before completion
+
+**How it works:**
+1. Load the content to review (diff, branch, document, etc.)
+2. Perform adversarial analysis — assume problems exist
+3. Find at least ten issues to fix or improve
+4. Output findings as a markdown list
+
+:::note[Unbiased Review]
+This task runs in a separate subagent with read access but no prior context, ensuring an unbiased review.
+:::
+
+## Shard Document
+
+**Splits large markdown documents into smaller files based on level 2 (`##`) sections.**
+
+**Use it when:**
+- A markdown file has grown too large to work with effectively
+- You want to break a monolithic document into manageable sections
+- Individual sections need to be edited independently
+
+**How it works:**
+1. Confirm source document path (must be markdown)
+2. Determine destination folder (defaults to folder named after document)
+3. Execute sharding via `npx @kayvan/markdown-tree-parser`
+4. Verify output files and index.md were created
+5. Handle original document — delete, move to archive, or keep
+
+:::caution[Original File]
+After sharding, delete or archive the original to avoid confusion. Updates should happen in the sharded files only.
+:::

package/docs/reference/configuration/global-config.md

@@ -0,0 +1,28 @@
+---
+title: "Global Inheritable Config"
+---
+
+Configuration values defined in the Core Module that all other modules inherit by default.
+
+## Core Config Values
+
+These values are set during installation and recorded to the core `module.yaml`:
+
+| Config Key | Default | Description |
+|------------|---------|-------------|
+| `user_name` | System username | User's display name |
+| `communication_language` | `english` | Language for agent communication |
+| `document_output_language` | `english` | Language for generated documents |
+| `output_folder` | `_bmad-output` | Directory for workflow outputs |
+
+## Inheritance Behavior
+
+All installed modules automatically clone these values into their own config. Modules can:
+
+- **Accept defaults** — Use core values as-is (recommended)
+- **Override values** — Replace with module-specific settings
+- **Extend values** — Build on core values with additional paths
+
+:::tip[Extending Config]
+Use `{output_folder}` to reference the core value. Example: BMad Method defines `planning_artifacts` as `{output_folder}/planning-artifacts`, automatically inheriting whatever output folder the user configured.
+:::

package/docs/reference/glossary/index.md

@@ -0,0 +1,159 @@
+---
+title: "BMad Glossary"
+---
+
+Terminology reference for the BMad Method.
+
+## Core Concepts
+
+| Term                      | Definition                                                                                                                                                                        |
+| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Agent**                 | Specialized AI persona with specific expertise (PM, Architect, SM, DEV, TEA) that guides users through workflows and creates deliverables.                                        |
+| **BMad**                  | Breakthrough Method of Agile AI-Driven Development — AI-driven agile framework with specialized agents, guided workflows, and scale-adaptive intelligence.                        |
+| **BMad Method**           | Complete methodology for AI-assisted software development, encompassing planning, architecture, implementation, and quality assurance workflows that adapt to project complexity. |
+| **BMM**                   | BMad Method Module — core orchestration system providing comprehensive lifecycle management through specialized agents and workflows.                                             |
+| **Scale-Adaptive System** | Intelligent workflow orchestration that adjusts planning depth and documentation requirements based on project needs through three planning tracks.                               |
+| **Workflow**              | Multi-step guided process that orchestrates AI agent activities to produce specific deliverables. Workflows are interactive and adapt to user context.                            |
+
+## Scale and Complexity
+
+| Term                        | Definition                                                                                                                                                                |
+| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **BMad Method Track**       | Full product planning track using PRD + Architecture + UX. Best for products, platforms, and complex features. Typical range: 10-50+ stories.                             |
+| **Enterprise Method Track** | Extended planning track adding Security Architecture, DevOps Strategy, and Test Strategy. Best for compliance needs and multi-tenant systems. Typical range: 30+ stories. |
+| **Planning Track**          | Methodology path (Quick Flow, BMad Method, or Enterprise) chosen based on planning needs and complexity, not story count alone.                                           |
+| **Quick Flow Track**        | Fast implementation track using tech-spec only. Best for bug fixes, small features, and clear-scope changes. Typical range: 1-15 stories.                                 |
+
+## Planning Documents
+
+| Term                      | Definition                                                                                                                                         |
+| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Architecture Document** | *BMad Method/Enterprise.* System-wide design document defining structure, components, data models, integration patterns, security, and deployment. |
+| **Epics**                 | High-level feature groupings containing multiple related stories. Typically 5-15 stories each representing cohesive functionality.                 |
+| **Game Brief**            | *BMGD.* Document capturing game's core vision, pillars, target audience, and scope. Foundation for the GDD.                                        |
+| **GDD**                   | *BMGD.* Game Design Document — comprehensive document detailing all aspects of game design: mechanics, systems, content, and more.                 |
+| **PRD**                   | *BMad Method/Enterprise.* Product Requirements Document containing vision, goals, FRs, NFRs, and success criteria. Focuses on WHAT to build.       |
+| **Product Brief**         | *Phase 1.* Optional strategic document capturing product vision, market context, and high-level requirements before detailed planning.             |
+| **Tech-Spec**             | *Quick Flow only.* Comprehensive technical plan with problem statement, solution approach, file-level changes, and testing strategy.               |
+
+## Workflow and Phases
+
+| Term                        | Definition                                                                                                                                     |
+| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
+| **Phase 0: Documentation**  | *Brownfield.* Conditional prerequisite phase creating codebase documentation before planning. Only required if existing docs are insufficient. |
+| **Phase 1: Analysis**       | Discovery phase including brainstorming, research, and product brief creation. Optional for Quick Flow, recommended for BMad Method.           |
+| **Phase 2: Planning**       | Required phase creating formal requirements. Routes to tech-spec (Quick Flow) or PRD (BMad Method/Enterprise).                                 |
+| **Phase 3: Solutioning**    | *BMad Method/Enterprise.* Architecture design phase including creation, validation, and gate checks.                                           |
+| **Phase 4: Implementation** | Required sprint-based development through story-by-story iteration using sprint-planning, create-story, dev-story, and code-review workflows.  |
+| **Quick Spec Flow**         | Fast-track workflow for Quick Flow projects going straight from idea to tech-spec to implementation.                                           |
+| **Workflow Init**           | Initialization workflow creating bmm-workflow-status.yaml, detecting project type, and determining planning track.                             |
+| **Workflow Status**         | Universal entry point checking for existing status file, displaying progress, and recommending next action.                                    |
+
+## Agents and Roles
+
+| Term                 | Definition                                                                                                                                       |
+| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Analyst**          | Agent that initializes workflows, conducts research, creates product briefs, and tracks progress. Often the entry point for new projects.        |
+| **Architect**        | Agent designing system architecture, creating architecture documents, and validating designs. Primary agent for Phase 3.                         |
+| **BMad Master**      | Meta-level orchestrator from BMad Core facilitating party mode and providing high-level guidance across all modules.                             |
+| **DEV**              | Developer agent implementing stories, writing code, running tests, and performing code reviews. Primary implementer in Phase 4.                  |
+| **Game Architect**   | *BMGD.* Agent designing game system architecture and validating game-specific technical designs.                                                 |
+| **Game Designer**    | *BMGD.* Agent creating game design documents (GDD) and running game-specific workflows.                                                          |
+| **Party Mode**       | Multi-agent collaboration feature where agents discuss challenges together. BMad Master orchestrates, selecting 2-3 relevant agents per message. |
+| **PM**               | Product Manager agent creating PRDs and tech-specs. Primary agent for Phase 2 planning.                                                          |
+| **SM**               | Scrum Master agent managing sprints, creating stories, and coordinating implementation. Primary orchestrator for Phase 4.                        |
+| **TEA**              | Test Architect agent responsible for test strategy, quality gates, and NFR assessment. Integrates throughout all phases.                         |
+| **Technical Writer** | Agent specialized in creating technical documentation, diagrams, and maintaining documentation standards.                                        |
+| **UX Designer**      | Agent creating UX design documents, interaction patterns, and visual specifications for UI-heavy projects.                                       |
+
+## Status and Tracking
+
+| Term                         | Definition                                                                                                                   |
+| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
+| **bmm-workflow-status.yaml** | *Phases 1-3.* Tracking file showing current phase, completed workflows, and next recommended actions.                        |
+| **DoD**                      | Definition of Done — criteria for marking a story complete: implementation done, tests passing, code reviewed, docs updated. |
+| **Epic Status Progression**  | `backlog → in-progress → done` — lifecycle states for epics during implementation.                                           |
+| **Gate Check**               | Validation workflow (implementation-readiness) ensuring PRD, Architecture, and Epics are aligned before Phase 4.             |
+| **Retrospective**            | Workflow after each epic capturing learnings and improvements for continuous improvement.                                    |
+| **sprint-status.yaml**       | *Phase 4.* Single source of truth for implementation tracking containing all epics, stories, and their statuses.             |
+| **Story Status Progression** | `backlog → ready-for-dev → in-progress → review → done` — lifecycle states for stories.                                      |
+
+## Project Types
+
+| Term                     | Definition                                                                                                                      |
+| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
+| **Brownfield**           | Existing project with established codebase and patterns. Requires understanding existing architecture and planning integration. |
+| **Convention Detection** | *Quick Flow.* Feature auto-detecting existing code style, naming conventions, and frameworks from brownfield codebases.         |
+| **document-project**     | *Brownfield.* Workflow analyzing and documenting existing codebase with three scan levels: quick, deep, exhaustive.             |
+| **Feature Flags**        | *Brownfield.* Implementation technique for gradual rollout, easy rollback, and A/B testing of new functionality.                |
+| **Greenfield**           | New project starting from scratch with freedom to establish patterns, choose stack, and design from clean slate.                |
+| **Integration Points**   | *Brownfield.* Specific locations where new code connects with existing systems. Must be documented in tech-specs.               |
+
+## Implementation Terms
+
+| Term                    | Definition                                                                                                                                 |
+| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Context Engineering** | Loading domain-specific standards into AI context automatically via manifests, ensuring consistent outputs regardless of prompt variation. |
+| **Correct Course**      | Workflow for navigating significant changes when implementation is off-track. Analyzes impact and recommends adjustments.                  |
+| **Shard / Sharding**    | Splitting large planning documents into section-based files for LLM optimization. Phase 4 workflows load only needed sections.             |
+| **Sprint**              | Time-boxed period of development work, typically 1-2 weeks.                                                                                |
+| **Sprint Planning**     | Workflow initializing Phase 4 by creating sprint-status.yaml and extracting epics/stories from planning docs.                              |
+| **Story**               | Single unit of implementable work with clear acceptance criteria, typically 2-8 hours of effort. Grouped into epics.                       |
+| **Story Context**       | Implementation guidance embedded in story files during create-story, referencing existing patterns and approaches.                         |
+| **Story File**          | Markdown file containing story description, acceptance criteria, technical notes, and testing requirements.                                |
+| **Track Selection**     | Automatic analysis by workflow-init suggesting appropriate track based on complexity indicators. User can override.                        |
+
+## Game Development Terms
+
+| Term                           | Definition                                                                                           |
+| ------------------------------ | ---------------------------------------------------------------------------------------------------- |
+| **Core Fantasy**               | *BMGD.* The emotional experience players seek from your game — what they want to FEEL.               |
+| **Core Loop**                  | *BMGD.* Fundamental cycle of actions players repeat throughout gameplay. The heart of your game.     |
+| **Design Pillar**              | *BMGD.* Core principle guiding all design decisions. Typically 3-5 pillars define a game's identity. |
+| **Environmental Storytelling** | *BMGD.* Narrative communicated through the game world itself rather than explicit dialogue.          |
+| **Game Type**                  | *BMGD.* Genre classification determining which specialized GDD sections are included.                |
+| **MDA Framework**              | *BMGD.* Mechanics → Dynamics → Aesthetics — framework for analyzing and designing games.             |
+| **Meta-Progression**           | *BMGD.* Persistent progression carrying between individual runs or sessions.                         |
+| **Metroidvania**               | *BMGD.* Genre featuring interconnected world exploration with ability-gated progression.             |
+| **Narrative Complexity**       | *BMGD.* How central story is to the game: Critical, Heavy, Moderate, or Light.                       |
+| **Permadeath**                 | *BMGD.* Game mechanic where character death is permanent, typically requiring a new run.             |
+| **Player Agency**              | *BMGD.* Degree to which players can make meaningful choices affecting outcomes.                      |
+| **Procedural Generation**      | *BMGD.* Algorithmic creation of game content (levels, items, characters) rather than hand-crafted.   |
+| **Roguelike**                  | *BMGD.* Genre featuring procedural generation, permadeath, and run-based progression.                |
+
+## Test Architect (TEA) Concepts
+
+| Term                         | Definition                                                                                                                                                    |
+| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **ATDD**                     | Acceptance Test-Driven Development — Generating failing acceptance tests BEFORE implementation (TDD red phase).                                               |
+| **Burn-in Testing**          | Running tests multiple times (typically 5-10 iterations) to detect flakiness and intermittent failures.                                                       |
+| **Component Testing**        | Testing UI components in isolation using framework-specific tools (Cypress Component Testing or Vitest + React Testing Library).                              |
+| **Coverage Traceability**    | Mapping acceptance criteria to implemented tests with classification (FULL/PARTIAL/NONE) to identify gaps and measure completeness.                           |
+| **Epic-Level Test Design**   | Test planning per epic (Phase 4) focusing on risk assessment, priorities, and coverage strategy for that specific epic.                                       |
+| **Fixture Architecture**     | Pattern of building pure functions first, then wrapping in framework-specific fixtures for testability, reusability, and composition.                         |
+| **Gate Decision**            | Go/no-go decision for release with four outcomes: PASS ✅ (ready), CONCERNS ⚠️ (proceed with mitigation), FAIL ❌ (blocked), WAIVED ⏭️ (approved despite issues). |
+| **Knowledge Fragment**       | Individual markdown file in TEA's knowledge base covering a specific testing pattern or practice (33 fragments total).                                        |
+| **MCP Enhancements**         | Model Context Protocol servers enabling live browser verification during test generation (exploratory, recording, and healing modes).                         |
+| **Network-First Pattern**    | Testing pattern that waits for actual network responses instead of fixed timeouts to avoid race conditions and flakiness.                                     |
+| **NFR Assessment**           | Validation of non-functional requirements (security, performance, reliability, maintainability) with evidence-based decisions.                                |
+| **Playwright Utils**         | Optional package (`@seontechnologies/playwright-utils`) providing production-ready fixtures and utilities for Playwright tests.                               |
+| **Risk-Based Testing**       | Testing approach where depth scales with business impact using probability × impact scoring (1-9 scale).                                                      |
+| **System-Level Test Design** | Test planning at architecture level (Phase 3) focusing on testability review, ADR mapping, and test infrastructure needs.                                     |
+| **tea-index.csv**            | Manifest file tracking all knowledge fragments, their descriptions, tags, and which workflows load them.                                                      |
+| **TEA Integrated**           | Full BMad Method integration with TEA workflows across all phases (Phase 2, 3, 4, and Release Gate).                                                          |
+| **TEA Lite**                 | Beginner approach using just `*automate` workflow to test existing features (simplest way to use TEA).                                                        |
+| **TEA Solo**                 | Standalone engagement model using TEA without full BMad Method integration (bring your own requirements).                                                     |
+| **Test Priorities**          | Classification system for test importance: P0 (critical path), P1 (high value), P2 (medium value), P3 (low value).                                            |
+
+---
+
+## See Also
+
+- [TEA Overview](/docs/explanation/features/tea-overview.md) - Complete TEA capabilities
+- [TEA Knowledge Base](/docs/reference/tea/knowledge-base.md) - Fragment index
+- [TEA Command Reference](/docs/reference/tea/commands.md) - Workflow reference
+- [TEA Configuration](/docs/reference/tea/configuration.md) - Config options
+
+---
+
+Generated with [BMad Method](https://bmad-method.org)