Les enseignants ont besoin de moyennes à jour immédiatement après la publication ou modification des notes, sans attendre un batch nocturne. Le système recalcule via Domain Events synchrones : statistiques d'évaluation (min/max/moyenne/médiane), moyennes matières pondérées (normalisation /20), et moyenne générale par élève. Les résultats sont stockés dans des tables dénormalisées avec cache Redis (TTL 5 min). Trois endpoints API exposent les données avec contrôle d'accès par rôle. Une commande console permet le backfill des données historiques au déploiement.
238 lines
7.7 KiB
Markdown
238 lines
7.7 KiB
Markdown
---
|
|
name: 'step-01-preflight-and-context'
|
|
description: 'Determine mode, verify framework, and load context and knowledge'
|
|
outputFile: '{test_artifacts}/automation-summary.md'
|
|
nextStepFile: './step-02-identify-targets.md'
|
|
knowledgeIndex: '{project-root}/_bmad/tea/agents/bmad-tea/resources/tea-index.csv'
|
|
---
|
|
|
|
# Step 1: Preflight & Context Loading
|
|
|
|
## STEP GOAL
|
|
|
|
Determine execution mode, verify framework readiness, and load the necessary artifacts and knowledge fragments.
|
|
|
|
## MANDATORY EXECUTION RULES
|
|
|
|
- 📖 Read the entire step file before acting
|
|
- ✅ Speak in `{communication_language}`
|
|
- 🚫 Halt if framework scaffolding is missing
|
|
|
|
---
|
|
|
|
## EXECUTION PROTOCOLS:
|
|
|
|
- 🎯 Follow the MANDATORY SEQUENCE exactly
|
|
- 💾 Record outputs before proceeding
|
|
- 📖 Load the next step only when instructed
|
|
|
|
## CONTEXT BOUNDARIES:
|
|
|
|
- Available context: config, loaded artifacts, and knowledge fragments
|
|
- Focus: this step's goal only
|
|
- Limits: do not execute future steps
|
|
- Dependencies: prior steps' outputs (if any)
|
|
|
|
## MANDATORY SEQUENCE
|
|
|
|
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise.
|
|
|
|
## 1. Stack Detection & Verify Framework
|
|
|
|
**Read `config.test_stack_type`** from `{config_source}`.
|
|
|
|
**Auto-Detection Algorithm** (when `test_stack_type` is `"auto"` or not configured):
|
|
|
|
- Scan `{project-root}` for project manifests:
|
|
- **Frontend indicators**: `package.json` with react/vue/angular/next dependencies, `playwright.config.*`, `vite.config.*`, `webpack.config.*`
|
|
- **Backend indicators**: `pyproject.toml`, `pom.xml`/`build.gradle`, `go.mod`, `*.csproj`/`*.sln`, `Gemfile`, `Cargo.toml`
|
|
- **Both present** = `fullstack`; only frontend = `frontend`; only backend = `backend`
|
|
- Explicit `test_stack_type` config value overrides auto-detection
|
|
- **Backward compatibility**: if `test_stack_type` is not in config, treat as `"auto"` (preserves current frontend behavior for existing installs)
|
|
|
|
Store result as `{detected_stack}` = `frontend` | `backend` | `fullstack`
|
|
|
|
**Verify framework exists:**
|
|
|
|
**If {detected_stack} is `frontend` or `fullstack`:**
|
|
|
|
- `playwright.config.ts` or `cypress.config.ts`
|
|
- `package.json` includes test dependencies
|
|
|
|
**If {detected_stack} is `backend` or `fullstack`:**
|
|
|
|
- Relevant test config exists (e.g., `conftest.py`, `src/test/`, `*_test.go`, `.rspec`, test project `*.csproj`)
|
|
|
|
If missing: **HALT** with message "Run `framework` workflow first."
|
|
|
|
---
|
|
|
|
## 2. Determine Execution Mode
|
|
|
|
- **BMad-Integrated** if story/tech-spec/test-design artifacts are provided or found
|
|
- **Standalone** if only source code is available
|
|
- If unclear, ask the user which mode to use
|
|
|
|
---
|
|
|
|
## 3. Load Context
|
|
|
|
### BMad-Integrated (if available)
|
|
|
|
- Story with acceptance criteria
|
|
- PRD and/or tech spec
|
|
- Test-design document (if exists)
|
|
|
|
### Standalone
|
|
|
|
- Skip artifacts; proceed to codebase analysis
|
|
|
|
### Always Load
|
|
|
|
- Test framework config
|
|
- Existing test structure in `{test_dir}`
|
|
- Existing tests (for coverage gaps)
|
|
|
|
### Read TEA Config Flags
|
|
|
|
- From `{config_source}` read `tea_use_playwright_utils`
|
|
- From `{config_source}` read `tea_use_pactjs_utils`
|
|
- From `{config_source}` read `tea_pact_mcp`
|
|
- From `{config_source}` read `tea_browser_automation`
|
|
- From `{config_source}` read `test_stack_type`
|
|
|
|
---
|
|
|
|
### Tiered Knowledge Loading
|
|
|
|
Load fragments based on their `tier` classification in `tea-index.csv`:
|
|
|
|
1. **Core tier** (always load): Foundational fragments required for this workflow
|
|
2. **Extended tier** (load on-demand): Load when deeper analysis is needed or when the user's context requires it
|
|
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)
|
|
|
|
> **Context Efficiency**: Loading only core fragments reduces context usage by 40-50% compared to loading all fragments.
|
|
|
|
### Playwright Utils Loading Profiles
|
|
|
|
**If `tea_use_playwright_utils` is enabled**, select the appropriate loading profile:
|
|
|
|
- **API-only profile** (when `{detected_stack}` is `backend` or no `page.goto`/`page.locator` found in test files):
|
|
Load: `overview`, `api-request`, `auth-session`, `recurse` (~1,800 lines)
|
|
|
|
- **Full UI+API profile** (when `{detected_stack}` is `frontend`/`fullstack` or browser tests detected):
|
|
Load: all Playwright Utils core fragments (~4,500 lines)
|
|
|
|
**Detection**: Scan `{test_dir}` for files containing `page.goto` or `page.locator`. If none found, use API-only profile.
|
|
|
|
### Pact.js Utils Loading
|
|
|
|
**If `tea_use_pactjs_utils` is enabled** (and `{detected_stack}` is `backend` or `fullstack`, or microservices indicators detected):
|
|
|
|
Load: `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md` (~800 lines)
|
|
|
|
**If `tea_use_pactjs_utils` is disabled** but contract testing is relevant (microservices architecture detected, existing Pact config found):
|
|
|
|
Load: `contract-testing.md` (~960 lines)
|
|
|
|
**Detection**: Scan `{project-root}` for Pact indicators: `pact/` directory, `@pact-foundation/pact` in `package.json`, `pactUrls` in test files, `PACT_BROKER` in env files.
|
|
|
|
### Pact MCP Loading
|
|
|
|
**If `tea_pact_mcp` is `"mcp"`:**
|
|
|
|
Load: `pact-mcp.md` (~150 lines) — enables agent to use SmartBear MCP tools for fetching provider states and generating pact tests during automation.
|
|
|
|
## 4. Load Knowledge Base Fragments
|
|
|
|
Use `{knowledgeIndex}` and load only what is required.
|
|
|
|
**Core (always load):**
|
|
|
|
- `test-levels-framework.md`
|
|
- `test-priorities-matrix.md`
|
|
- `data-factories.md`
|
|
- `selective-testing.md`
|
|
- `ci-burn-in.md`
|
|
- `test-quality.md`
|
|
|
|
**Playwright Utils (if enabled):**
|
|
|
|
- `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`
|
|
|
|
**Traditional Patterns (if Playwright Utils disabled):**
|
|
|
|
- `fixture-architecture.md`
|
|
- `network-first.md`
|
|
|
|
**Pact.js Utils (if enabled):**
|
|
|
|
- `pactjs-utils-overview.md`, `pactjs-utils-consumer-helpers.md`, `pactjs-utils-provider-verifier.md`, `pactjs-utils-request-filter.md`
|
|
|
|
**Contract Testing (if pactjs-utils disabled but relevant):**
|
|
|
|
- `contract-testing.md`
|
|
|
|
**Pact MCP (if tea_pact_mcp is "mcp"):**
|
|
|
|
- `pact-mcp.md`
|
|
|
|
**Healing (if auto-heal enabled):**
|
|
|
|
- `test-healing-patterns.md`
|
|
- `selector-resilience.md`
|
|
- `timing-debugging.md`
|
|
|
|
**Playwright CLI (if tea_browser_automation is "cli" or "auto"):**
|
|
|
|
- `playwright-cli.md`
|
|
|
|
**MCP Patterns (if tea_browser_automation is "mcp" or "auto"):**
|
|
|
|
- (existing MCP-related fragments, if any are added in future)
|
|
|
|
---
|
|
|
|
## 5. Confirm Inputs
|
|
|
|
Summarize loaded artifacts, framework, and knowledge fragments, then proceed.
|
|
|
|
---
|
|
|
|
## 6. Save Progress
|
|
|
|
**Save this step's accumulated work to `{outputFile}`.**
|
|
|
|
- **If `{outputFile}` does not exist** (first save), create it with YAML frontmatter:
|
|
|
|
```yaml
|
|
---
|
|
stepsCompleted: ['step-01-preflight-and-context']
|
|
lastStep: 'step-01-preflight-and-context'
|
|
lastSaved: '{date}'
|
|
---
|
|
```
|
|
|
|
Then write this step's output below the frontmatter.
|
|
|
|
- **If `{outputFile}` already exists**, update:
|
|
- Add `'step-01-preflight-and-context'` to `stepsCompleted` array (only if not already present)
|
|
- Set `lastStep: 'step-01-preflight-and-context'`
|
|
- Set `lastSaved: '{date}'`
|
|
- Append this step's output to the appropriate section.
|
|
|
|
**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).
|
|
|
|
Load next step: `{nextStepFile}`
|
|
|
|
## 🚨 SYSTEM SUCCESS/FAILURE METRICS:
|
|
|
|
### ✅ SUCCESS:
|
|
|
|
- Step completed in full with required outputs
|
|
|
|
### ❌ SYSTEM FAILURE:
|
|
|
|
- Skipped sequence steps or missing outputs
|
|
**Master Rule:** Skipping steps is FORBIDDEN.
|