選択できるのは25トピックまでです。 トピックは、先頭が英数字で、英数字とダッシュ('-')を使用した35文字以内のものにしてください。

step-01-preflight-and-context.md 7.7KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237
  1. ---
  2. name: 'step-01-preflight-and-context'
  3. description: 'Determine mode, verify framework, and load context and knowledge'
  4. outputFile: '{test_artifacts}/automation-summary.md'
  5. nextStepFile: '{skill-root}/steps-c/step-02-identify-targets.md'
  6. knowledgeIndex: './resources/tea-index.csv'
  7. ---
  8. # Step 1: Preflight & Context Loading
  9. ## STEP GOAL
  10. Determine execution mode, verify framework readiness, and load the necessary artifacts and knowledge fragments.
  11. ## MANDATORY EXECUTION RULES
  12. - 📖 Read the entire step file before acting
  13. - ✅ Speak in `{communication_language}`
  14. - 🚫 Halt if framework scaffolding is missing
  15. ---
  16. ## EXECUTION PROTOCOLS:
  17. - 🎯 Follow the MANDATORY SEQUENCE exactly
  18. - 💾 Record outputs before proceeding
  19. - 📖 Load the next step only when instructed
  20. ## CONTEXT BOUNDARIES:
  21. - Available context: config, loaded artifacts, and knowledge fragments
  22. - Focus: this step's goal only
  23. - Limits: do not execute future steps
  24. - Dependencies: prior steps' outputs (if any)
  25. ## MANDATORY SEQUENCE
  26. **CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
  27. ## 1. Stack Detection & Verify Framework
  28. **Read `config.test_stack_type`** from `{config_source}`.
  29. **Auto-Detection Algorithm** (when `test_stack_type` is `"auto"` or not configured):
  30. - Scan `{project-root}` for project manifests:
  31. - **Frontend indicators**: `package.json` with react/vue/angular/next dependencies, `playwright.config.*`, `vite.config.*`, `webpack.config.*`
  32. - **Backend indicators**: `pyproject.toml`, `pom.xml`/`build.gradle`, `go.mod`, `*.csproj`/`*.sln`, `Gemfile`, `Cargo.toml`
  33. - **Both present** = `fullstack`; only frontend = `frontend`; only backend = `backend`
  34. - Explicit `test_stack_type` config value overrides auto-detection
  35. - **Backward compatibility**: if `test_stack_type` is not in config, treat as `"auto"` (preserves current frontend behavior for existing installs)
  36. Store result as `{detected_stack}` = `frontend` | `backend` | `fullstack`
  37. **Verify framework exists:**
  38. **If {detected_stack} is `frontend` or `fullstack`:**
  39. - `playwright.config.ts` or `cypress.config.ts`
  40. - `package.json` includes test dependencies
  41. **If {detected_stack} is `backend` or `fullstack`:**
  42. - Relevant test config exists (e.g., `conftest.py`, `src/test/`, `*_test.go`, `.rspec`, test project `*.csproj`)
  43. If missing: **HALT** with message "Run `framework` workflow first."
  44. ---
  45. ## 2. Determine Execution Mode
  46. - **BMad-Integrated** if story/tech-spec/test-design artifacts are provided or found
  47. - **Standalone** if only source code is available
  48. - If unclear, ask the user which mode to use
  49. ---
  50. ## 3. Load Context
  51. ### BMad-Integrated (if available)
  52. - Story with acceptance criteria
  53. - PRD and/or tech spec
  54. - Test-design document (if exists)
  55. ### Standalone
  56. - Skip artifacts; proceed to codebase analysis
  57. ### Always Load
  58. - Test framework config
  59. - Existing test structure in `{test_dir}`
  60. - Existing tests (for coverage gaps)
  61. ### Read TEA Config Flags
  62. - From `{config_source}` read `tea_use_playwright_utils`
  63. - From `{config_source}` read `tea_use_pactjs_utils`
  64. - From `{config_source}` read `tea_pact_mcp`
  65. - From `{config_source}` read `tea_browser_automation`
  66. - From `{config_source}` read `test_stack_type`
  67. ---
  68. ### Tiered Knowledge Loading
  69. Load fragments based on their `tier` classification in `tea-index.csv`:
  70. 1. **Core tier** (always load): Foundational fragments required for this workflow
  71. 2. **Extended tier** (load on-demand): Load when deeper analysis is needed or when the user's context requires it
  72. 3. **Specialized tier** (load only when relevant): Load only when the specific use case matches (e.g., contract-testing only for microservices, email-auth only for email flows)
  73. > **Context Efficiency**: Loading only core fragments reduces context usage by 40-50% compared to loading all fragments.
  74. ### Playwright Utils Loading Profiles
  75. **If `tea_use_playwright_utils` is enabled**, select the appropriate loading profile:
  76. - **API-only profile** (when `{detected_stack}` is `backend` or no `page.goto`/`page.locator` found in test files):
  77. Load: `overview`, `api-request`, `auth-session`, `recurse` (~1,800 lines)
  78. - **Full UI+API profile** (when `{detected_stack}` is `frontend`/`fullstack` or browser tests detected):
  79. Load: all Playwright Utils core fragments (~4,500 lines)
  80. **Detection**: Scan `{test_dir}` for files containing `page.goto` or `page.locator`. If none found, use API-only profile.
  81. ### Pact.js Utils Loading
  82. **If `tea_use_pactjs_utils` is enabled** (and `{detected_stack}` is `backend` or `fullstack`, or microservices indicators detected):
  83. Load: `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md` (~800 lines)
  84. **If `tea_use_pactjs_utils` is disabled** but contract testing is relevant (microservices architecture detected, existing Pact config found):
  85. Load: `contract-testing.md` (~960 lines)
  86. **Detection**: Scan `{project-root}` for Pact indicators: `pact/` directory, `@pact-foundation/pact` in `package.json`, `pactUrls` in test files, `PACT_BROKER` in env files.
  87. ### Pact MCP Loading
  88. **If `tea_pact_mcp` is `"mcp"`:**
  89. Load: `pact-mcp.md` (~150 lines) — enables agent to use SmartBear MCP tools for fetching provider states and generating pact tests during automation.
  90. ## 4. Load Knowledge Base Fragments
  91. Use `{knowledgeIndex}` and load only what is required.
  92. **Core (always load):**
  93. - `test-levels-framework.md`
  94. - `test-priorities-matrix.md`
  95. - `data-factories.md`
  96. - `selective-testing.md`
  97. - `ci-burn-in.md`
  98. - `test-quality.md`
  99. **Playwright Utils (if enabled):**
  100. - `overview.md`, `api-request.md`, `network-recorder.md`, `auth-session.md`, `intercept-network-call.md`, `recurse.md`, `log.md`, `file-utils.md`, `burn-in.md`, `network-error-monitor.md`, `fixtures-composition.md`
  101. **Traditional Patterns (if Playwright Utils disabled):**
  102. - `fixture-architecture.md`
  103. - `network-first.md`
  104. **Pact.js Utils (if enabled):**
  105. - `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md`
  106. **Contract Testing (if pactjs-utils disabled but relevant):**
  107. - `contract-testing.md`
  108. **Pact MCP (if tea_pact_mcp is "mcp"):**
  109. - `pact-mcp.md`
  110. **Healing (if auto-heal enabled):**
  111. - `test-healing-patterns.md`
  112. - `selector-resilience.md`
  113. - `timing-debugging.md`
  114. **Playwright CLI (if tea_browser_automation is "cli" or "auto"):**
  115. - `playwright-cli.md`
  116. **MCP Patterns (if tea_browser_automation is "mcp" or "auto"):**
  117. - (existing MCP-related fragments, if any are added in future)
  118. ---
  119. ## 5. Confirm Inputs
  120. Summarize loaded artifacts, framework, and knowledge fragments, then proceed.
  121. ---
  122. ## 6. Save Progress
  123. **Save this step's accumulated work to `{outputFile}`.**
  124. - **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
  125. ```yaml
  126. ---
  127. stepsCompleted: ['step-01-preflight-and-context']
  128. lastStep: 'step-01-preflight-and-context'
  129. lastSaved: '{date}'
  130. ---
  131. ```
  132. Then write this step's output below the frontmatter.
  133. - **If `{outputFile}` already exists**, update:
  134. - Add `'step-01-preflight-and-context'` to `stepsCompleted` array (only if not already present)
  135. - Set `lastStep: 'step-01-preflight-and-context'`
  136. - Set `lastSaved: '{date}'`
  137. - Append this step's output to the appropriate section.
  138. **Update `inputDocuments`**: Set `inputDocuments` in the output template frontmatter to the list of artifact paths loaded in this step (e.g., knowledge fragments, test design documents, configuration files).
  139. Load next step: `{nextStepFile}`
  140. ## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
  141. ### ✅ SUCCESS:
  142. - Step completed in full with required outputs
  143. ### ❌ SYSTEM FAILURE:
  144. - Skipped sequence steps or missing outputs
  145. **Master Rule:** Skipping steps is FORBIDDEN.