@cregis-dev/cckit 0.4.1 → 0.6.1

package/templates/bmad/tea/workflows/testarch/teach-me-testing/steps-c/step-04-session-02.md

@@ -1,465 +0,0 @@
----
-name: 'step-04-session-02'
-description: 'Session 2: Core Concepts - Risk-based testing, DoD, testing philosophy (45 min)'
-
-progressFile: '{test_artifacts}/teaching-progress/{user_name}-tea-progress.yaml'
-sessionNotesTemplate: '../templates/session-notes-template.md'
-sessionNotesFile: '{test_artifacts}/tea-academy/{user_name}/session-02-notes.md'
-nextStepFile: './step-03-session-menu.md'
-advancedElicitationTask: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-partyModeWorkflow: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
----
-
-# Step 4: Session 2 - Core Concepts
-
-## STEP GOAL:
-
-To teach testing fundamentals including risk-based testing, TEA quality standards (Definition of Done), and testing as engineering philosophy in a 45-minute session.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a Master Test Architect and Teaching Guide
-- ✅ We engage in collaborative learning, not lectures
-- ✅ You bring expertise in TEA methodology and teaching pedagogy
-- ✅ Learner brings their role context, experience, and learning goals
-- ✅ Together we build their testing knowledge progressively
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on Session 2 content (Core Concepts)
-- 🚫 FORBIDDEN to skip ahead to other sessions
-- 💬 Approach: Teach fundamentals, provide examples, quiz understanding
-- 🚪 Teaching is mostly autonomous, quiz is collaborative
-- 📚 Reference TEA docs and knowledge fragments
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Load TEA docs just-in-time
-- 💾 Generate session notes after completion
-- 📖 Update progress file with session completion and score
-- 🚫 FORBIDDEN to skip quiz - validates understanding
-- ⏭️ Always return to session menu hub after completion
-
-## CONTEXT BOUNDARIES:
-
-- Available context: Progress file with user role/experience
-- Focus: Session 2 - Testing fundamentals and TEA principles
-- Limits: Only Session 2 content
-- Dependencies: Progress file exists with assessment data
-
-## MANDATORY SEQUENCE
-
-**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
-
-### 1. Session Welcome
-
-Display:
-
-"🧪 **Session 2: Core Concepts** (45 minutes)
-
-**Objective:** Understand WHY behind TEA principles
-
-**What you'll learn:**
-
-- Testing as Engineering philosophy
-- Risk-based testing with P0-P3 matrix
-- TEA Definition of Done (quality standards)
-- Probability × Impact risk scoring
-
-Let's dive into the fundamentals!"
-
-### 2. Update Progress File (Session Started)
-
-Load {progressFile} and update session-02-concepts:
-
-- Set `status: 'in-progress'`
-- Set `started_date: {current_date}`
-
-Save the updated progress file.
-
-### 3. Teaching: Testing as Engineering
-
-Present this content:
-
-"### 🏗️ Testing as Engineering
-
-**Core Philosophy:** Testing is not an afterthought - it's engineering.
-
-**What this means:**
-
-- Tests are **designed** before they're written (like architecture before coding)
-- Tests have **quality standards** (not just "does it run?")
-- Tests are **maintained** like production code
-- Testing decisions are **risk-based** (prioritize what matters)
-
-{If role == QA:}
-**For QA Engineers:** You're not just finding bugs - you're engineering test systems that scale. Design before write, maintain like production code.
-
-{If role == Dev:}
-**For Developers:** Think of tests like you think of production code. Design patterns, refactoring, DRY principles - they all apply to tests.
-
-{If role == Lead:}
-**For Tech Leads:** Testing as engineering means architecture decisions: fixture patterns, data strategies, CI orchestration. Not just "write more tests."
-
-{If role == VP:}
-**For VPs:** Testing is an engineering discipline requiring investment in tooling, architecture, and knowledge. Not a checklist item.
-
-**Key Principle:** If you wouldn't accept sloppy production code, don't accept sloppy test code.
-
-**Documentation:** <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/testing-as-engineering/>"
-
-### 4. Teaching: Risk-Based Testing
-
-Present this content:
-
-"### ⚖️ Risk-Based Testing: The P0-P3 Matrix
-
-**Problem:** You can't test everything. How do you prioritize?
-
-**Solution:** Risk = Probability × Impact
-
-**The P0-P3 Matrix:**
-
-**P0 - Critical (Must Test)**
-
-- Login/Authentication
-- Payment processing
-- Data loss scenarios
-- Security vulnerabilities
-- **Impact:** Business fails if broken
-- **Probability:** High usage, high complexity
-
-**P1 - High (Should Test)**
-
-- Core user workflows
-- Key features
-- Data integrity
-- **Impact:** Major user pain
-- **Probability:** Frequent usage
-
-**P2 - Medium (Nice to Test)**
-
-- Secondary features
-- Edge cases with workarounds
-- **Impact:** Inconvenience
-- **Probability:** Moderate usage
-
-**P3 - Low (Optional)**
-
-- Tooltips, help text
-- Nice-to-have features
-- Aesthetic issues
-- **Impact:** Minimal
-- **Probability:** Low usage
-
-{If role == QA:}
-**For QA Engineers:** Use P0-P3 to defend test coverage decisions. "We have 100% P0 coverage, 80% P1" is better than "we have 50% coverage overall."
-
-{If role == Dev:}
-**For Developers:** When writing tests, ask "Is this P0 login or P3 tooltip?" Focus your time accordingly.
-
-{If role == Lead:}
-**For Tech Leads:** P0-P3 helps allocate test automation budget. Mandate P0/P1 automation, P2/P3 is cost-benefit analysis.
-
-{If role == VP:}
-**For VPs:** Risk-based testing aligns engineering effort with business impact. Metrics that matter: P0 coverage, not lines of code.
-
-**Documentation:** <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/risk-based-testing/>
-
-**Knowledge Fragment:** probability-impact.md defines scoring criteria"
-
-### 5. Teaching: Definition of Done (Quality Standards)
-
-Present this content:
-
-"### ✅ TEA Definition of Done: Quality Standards
-
-**The Problem:** "The tests pass" isn't enough. What about quality?
-
-**TEA Definition of Done ensures:**
-
-**1. No Flaky Tests**
-
-- Tests pass/fail deterministically
-- No "run it again, it'll work" tests
-- Use explicit waits, not hard sleeps
-- Handle async properly
-
-**2. No Hard Waits/Sleeps**
-
-- Use `waitFor` conditions, not `sleep(5000)`
-- React to state changes, don't guess timing
-- Tests complete when ready, not after arbitrary delays
-
-**3. Stateless & Parallelizable**
-
-- Tests run independently, any order
-- No shared state between tests
-- Can run in parallel (fast feedback)
-- Use cron jobs/semaphores only when unavoidable
-
-**4. No Order Dependency**
-
-- Every `it`/`describe`/`context` block works in isolation
-- Supports `.only` execution for debugging
-- Tests don't depend on previous tests
-
-**5. Self-Cleaning Tests**
-
-- Test sets up its own data
-- Test automatically deletes/deactivates entities created
-- No manual cleanup required
-
-**6. Tests Live Near Source Code**
-
-- Co-locate test files with code they validate
-- `component.tsx` → `component.spec.tsx` in same folder
-
-**7. Low Maintenance**
-
-- Minimize manual upkeep
-- Avoid brittle selectors
-- Use APIs to set up state, not UI clicks
-- Don't repeat UI actions
-
-{If role == QA:}
-**For QA Engineers:** These standards prevent the "test maintenance nightmare." Upfront investment in quality = long-term stability.
-
-{If role == Dev:}
-**For Developers:** Write tests you'd want to inherit. No flaky tests, no "run twice" culture, no mystery failures.
-
-{If role == Lead:}
-**For Tech Leads:** Enforce these standards in code review. Flaky test PRs don't merge. Period.
-
-{If role == VP:}
-**For VPs:** Definition of Done isn't perfectionism - it's engineering rigor. Flaky tests erode trust in CI/CD.
-
-**Documentation:** <https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/explanation/test-quality-standards/>
-
-**Knowledge Fragment:** test-quality.md has execution limits and criteria"
-
-### 6. Teaching: Key Takeaways
-
-Present this content:
-
-"### 🎯 Session 2 Key Takeaways
-
-**1. Testing is Engineering**
-
-- Design before write
-- Maintain like production code
-- Apply engineering principles
-
-**2. Risk-Based Testing**
-
-- P0 = Critical (login, payment)
-- P1 = High (core workflows)
-- P2 = Medium (secondary features)
-- P3 = Low (tooltips, nice-to-have)
-- Prioritize based on Probability × Impact
-
-**3. Definition of Done**
-
-- No flaky tests (deterministic)
-- No hard waits (use waitFor)
-- Stateless & parallelizable
-- Self-cleaning tests
-- Low maintenance
-
-**4. Quality Standards = Engineering Rigor**
-
-- Not perfectionism, but reliability
-- Prevents test maintenance nightmares
-- Builds trust in CI/CD
-
-**You now understand the WHY behind TEA principles!**"
-
-### 7. Quiz: Validate Understanding
-
-Display:
-
-"### ✅ Knowledge Check
-
-3 questions to validate your understanding. Passing: ≥70% (2 of 3 correct)."
-
-**Question 1:**
-
-"**Question 1 of 3:**
-
-In the P0-P3 matrix, what priority level should login/authentication have?
-
-A) P3 - Low priority
-B) P2 - Medium priority
-C) P1 - High priority
-D) P0 - Critical priority
-
-Your answer (A, B, C, or D):"
-
-**Wait for response. Validate:**
-
-- Correct answer: D
-- If correct: "✅ Correct! Login/authentication is P0 - critical. Business fails if broken."
-- If incorrect: "❌ Login/authentication is P0 - Critical (D). It's high usage, high impact, and business-critical."
-
-**Store result**
-
-**Question 2:**
-
-"**Question 2 of 3:**
-
-What is the problem with using `sleep(5000)` instead of `waitFor` conditions?
-
-A) It makes tests slower
-B) It's a hard wait that doesn't react to state changes (violates DoD)
-C) It uses too much memory
-D) It's not supported in modern frameworks
-
-Your answer (A, B, C, or D):"
-
-**Wait for response. Validate:**
-
-- Correct answer: B
-- If correct: "✅ Correct! Hard waits don't react to state - they guess timing. Use `waitFor` to react to conditions."
-- If incorrect: "❌ The issue is that hard waits don't react to state changes (B). They guess timing instead of waiting for conditions. This violates TEA Definition of Done."
-
-**Store result**
-
-**Question 3:**
-
-"**Question 3 of 3:**
-
-What does "self-cleaning tests" mean in TEA Definition of Done?
-
-A) Tests automatically fix their own bugs
-B) Tests delete/deactivate entities they create during testing
-C) Tests run faster by cleaning up code
-D) Tests remove old test files
-
-Your answer (A, B, C, or D):"
-
-**Wait for response. Validate:**
-
-- Correct answer: B
-- If correct: "✅ Correct! Self-cleaning tests clean up their data - no manual cleanup needed."
-- If incorrect: "❌ Self-cleaning means tests delete/deactivate entities they created (B). No manual cleanup required."
-
-**Store result**
-
-**Calculate score:**
-
-- Total points / 3 \* 100 = score (0-100)
-
-**Display results:**
-
-"**Quiz Results:** {score}/100
-
-{If score >= 70:}
-✅ **Passed!** You understand core testing concepts.
-
-{If score < 70:}
-⚠️ **Below passing.** Would you like to:
-
-- **[R]** Review the content again
-- **[C]** Continue anyway (score will be recorded)
-
-{Wait for response if < 70, handle R or C}"
-
-### 8. Generate Session Notes
-
-Create {sessionNotesFile} using {sessionNotesTemplate} with session-02 content including:
-
-- Teaching topics covered
-- TEA docs referenced
-- Knowledge fragments referenced (test-quality.md, probability-impact.md)
-- Quiz results
-- Key takeaways
-- Next recommended session based on experience level
-
-### 9. Update Progress File (Session Complete)
-
-Load {progressFile} and update session-02-concepts:
-
-- Set `status: 'completed'`
-- Set `completed_date: {current_date}`
-- Set `score: {score}`
-- Set `notes_artifact: '{sessionNotesFile}'`
-
-Update progress metrics:
-
-- Increment `sessions_completed` by 1
-- Calculate `completion_percentage`
-- Set `next_recommended: 'session-03-architecture'`
-
-Update stepsCompleted array:
-
-- Append 'step-04-session-02'
-- Update lastStep
-
-Save the updated progress file.
-
-### 10. Session Complete Message
-
-Display:
-
-"🎉 **Session 2 Complete!**
-
-**Your Score:** {score}/100
-
-**Session notes saved:** {sessionNotesFile}
-
-You now understand:
-
-- Testing as engineering philosophy
-- Risk-based testing (P0-P3 matrix)
-- TEA Definition of Done
-- Why quality standards matter
-
-**Next:** Session 3 (Architecture & Patterns) or explore any session from the menu.
-
-**Progress:** {completion_percentage}% complete ({sessions_completed} of 7 sessions)"
-
-### 11. Present MENU OPTIONS
-
-Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Session Menu
-
-#### Menu Handling Logic:
-
-- IF A: Execute {advancedElicitationTask}, and when finished redisplay the menu
-- IF P: Execute {partyModeWorkflow}, and when finished redisplay the menu
-- IF C: Progress file already updated, then load, read entire file, then execute {nextStepFile}
-- IF Any other: help user, then redisplay menu
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Teaching content presented (Testing as Engineering, Risk-based, DoD)
-- Examples adapted to user role
-- Quiz administered (3 questions)
-- Score calculated correctly
-- Session notes generated
-- Progress file updated
-- stepsCompleted array updated
-- User routed back to hub
-
-### ❌ SYSTEM FAILURE:
-
-- Skipping quiz
-- Not adapting to role
-- Not generating notes
-- Not updating progress
-- Not routing to hub
-
-**Master Rule:** Teach, quiz, generate notes, update progress, return to hub.