--- name: 'step-01-load-context' description: 'Resolve coverage oracle, load knowledge base, and gather related artifacts' nextStepFile: '{skill-root}/steps-c/step-02-discover-tests.md' knowledgeIndex: './resources/tea-index.csv' outputFile: '{test_artifacts}/traceability-matrix.md' --- # Step 1: Resolve Coverage Oracle & Load Knowledge Base ## STEP GOAL Resolve the best available coverage oracle, capture confidence and provenance, and gather supporting artifacts for traceability. ## MANDATORY EXECUTION RULES - 📖 Read the entire step file before acting - ✅ Speak in `{communication_language}` --- ## EXECUTION PROTOCOLS: - 🎯 Follow the MANDATORY SEQUENCE exactly - 💾 Record outputs before proceeding - 📖 Load the next step only when instructed ## CONTEXT BOUNDARIES: - Available context: config, source tree, 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. Resolve Coverage Oracle At least one of the following must be usable: - Formal requirements (story/epic acceptance criteria, PRD, test design) - Contract/spec artifacts (OpenAPI, GraphQL schema, protobuf, etc.) - External pointers to a requirements source that can be resolved through installed adapters/MCPs - Analyzable source code that supports synthetic journey/requirement inference Tests exist OR gaps are explicitly acknowledged. Resolve the oracle in this order: 1. **Formal requirements first** - Story/epic acceptance criteria - PRD / test design / tech spec - Inline requirements provided by the user 2. **Contract/spec artifacts second** - OpenAPI / Swagger - GraphQL schema or SDL - Other machine-readable contract definitions 3. **External pointers third** - Placeholder files that point to external trackers or docs such as Jira, Linear, Confluence, shared docs, or other systems of record - Follow the pointer automatically only when a compatible adapter/plugin/MCP is available in the active runtime - Record `externalPointerStatus` as one of: `not_used`, `resolved`, `skipped`, or `unavailable` 4. **Synthetic oracle last** - If no formal oracle exists and `allow_synthetic_oracle` is enabled, inspect `{source_dir}` to infer a provisional trace target - For UI apps, infer journeys from: - routes/pages/screens/layout entry points - navigation flows and feature entry links - forms, submit actions, create/update/delete paths - auth/session/logout/role-gated flows - loading, empty, validation, error, and permission-denied states - feature flags and major conditional branches - Deduplicate the inferred items into a compact, traceable list (prefer 5-12 items) - Assign stable IDs such as `J-01`, `J-02`, etc. - Assign provisional priorities using `test-priorities-matrix.md` - `P0`: auth, checkout/payment, destructive data changes, revenue-critical, hard blockers to core use - `P1`: primary user journeys and common CRUD paths - `P2`: secondary workflows and edge scenarios - `P3`: low-risk polish or optional flows Record the resolved oracle metadata in step output/frontmatter using consistent keys: - `coverageBasis` (`acceptance_criteria` | `synthetic_requirements` | `openapi_endpoints` | `user_journeys`) — the type of oracle selected for coverage tracing - `oracleResolutionMode` (`formal_requirements` | `spec_artifact` | `external_pointer` | `synthetic_source`) — how the oracle was discovered/resolved - `oracleConfidence` (`high` | `medium` | `low`) — confidence in the resolved oracle as a coverage source - `oracleSources` — list of artifact paths, URIs, or references used to resolve the oracle - `externalPointerStatus` (`not_used` | `resolved` | `skipped` | `unavailable`) — status of external pointer resolution when pointer files are present If none of the four oracle types can be resolved, **HALT** and request the smallest missing clarification needed to continue. --- ## 2. Load Knowledge Base From `{knowledgeIndex}` load: - `test-priorities-matrix.md` - `risk-governance.md` - `probability-impact.md` - `test-quality.md` - `selective-testing.md` --- ## 3. Load Artifacts If available: - Story file and acceptance criteria - Test design doc (priorities) - Tech spec / PRD - OpenAPI or similar contract/spec files - Placeholder files that reference external requirements systems - Route maps, page/screen registries, and other source files used for synthetic journey inference Summarize what was found and explicitly state the resolved oracle, its confidence, and why that oracle was selected. --- ### 4. Save Progress **Save this step's accumulated work to `{outputFile}`.** - **If `{outputFile}` does not exist** (first save), create it using the workflow template (if available) with YAML frontmatter: ```yaml --- stepsCompleted: ['step-01-load-context'] lastStep: 'step-01-load-context' lastSaved: '{date}' coverageBasis: '{resolved coverage_basis}' oracleConfidence: '{resolved oracle_confidence}' oracleResolutionMode: '{resolved oracle_resolution_mode}' oracleSources: ['{resolved oracle source 1}', '{resolved oracle source 2}'] externalPointerStatus: '{resolved external_pointer_status}' --- ``` Then write this step's output below the frontmatter. - **If `{outputFile}` already exists**, update: - Add `'step-01-load-context'` to `stepsCompleted` array (only if not already present) - Set `lastStep: 'step-01-load-context'` - Set `lastSaved: '{date}'` - Set `coverageBasis` to the resolved oracle basis - Set `oracleConfidence` to the resolved oracle confidence - Set `oracleResolutionMode` to the resolved oracle resolution mode - Set `oracleSources` to the resolved oracle sources - Set `externalPointerStatus` to the resolved external pointer status - Append this step's output to the appropriate section of the document. 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.