@exaudeus/workrail 3.12.0 → 3.14.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (54) hide show
  1. package/dist/console/assets/{index-CRgjJiMS.js → index-EsSXrC_a.js} +11 -11
  2. package/dist/console/index.html +1 -1
  3. package/dist/di/container.js +8 -0
  4. package/dist/di/tokens.d.ts +1 -0
  5. package/dist/di/tokens.js +1 -0
  6. package/dist/infrastructure/session/HttpServer.js +2 -14
  7. package/dist/manifest.json +93 -53
  8. package/dist/mcp/boundary-coercion.d.ts +2 -0
  9. package/dist/mcp/boundary-coercion.js +73 -0
  10. package/dist/mcp/handler-factory.d.ts +1 -1
  11. package/dist/mcp/handler-factory.js +13 -6
  12. package/dist/mcp/handlers/v2-manage-workflow-source.d.ts +7 -0
  13. package/dist/mcp/handlers/v2-manage-workflow-source.js +50 -0
  14. package/dist/mcp/handlers/v2-workflow.d.ts +3 -0
  15. package/dist/mcp/handlers/v2-workflow.js +58 -0
  16. package/dist/mcp/output-schemas.d.ts +93 -0
  17. package/dist/mcp/output-schemas.js +8 -1
  18. package/dist/mcp/server.js +2 -0
  19. package/dist/mcp/tool-descriptions.js +20 -0
  20. package/dist/mcp/tools.js +6 -0
  21. package/dist/mcp/types/tool-description-types.d.ts +1 -1
  22. package/dist/mcp/types/tool-description-types.js +1 -0
  23. package/dist/mcp/types/workflow-tool-edition.d.ts +1 -1
  24. package/dist/mcp/types.d.ts +2 -0
  25. package/dist/mcp/v2/tool-registry.js +8 -0
  26. package/dist/mcp/v2/tools.d.ts +12 -0
  27. package/dist/mcp/v2/tools.js +7 -1
  28. package/dist/types/workflow-definition.d.ts +1 -0
  29. package/dist/v2/infra/in-memory/managed-source-store/index.d.ts +8 -0
  30. package/dist/v2/infra/in-memory/managed-source-store/index.js +33 -0
  31. package/dist/v2/infra/local/data-dir/index.d.ts +2 -0
  32. package/dist/v2/infra/local/data-dir/index.js +6 -0
  33. package/dist/v2/infra/local/managed-source-store/index.d.ts +15 -0
  34. package/dist/v2/infra/local/managed-source-store/index.js +164 -0
  35. package/dist/v2/ports/data-dir.port.d.ts +2 -0
  36. package/dist/v2/ports/managed-source-store.port.d.ts +25 -0
  37. package/dist/v2/ports/managed-source-store.port.js +2 -0
  38. package/package.json +2 -1
  39. package/spec/authoring-spec.json +9 -2
  40. package/spec/workflow.schema.json +418 -96
  41. package/workflows/adaptive-ticket-creation.json +276 -282
  42. package/workflows/document-creation-workflow.json +70 -191
  43. package/workflows/documentation-update-workflow.json +59 -309
  44. package/workflows/intelligent-test-case-generation.json +37 -212
  45. package/workflows/personal-learning-materials-creation-branched.json +1 -21
  46. package/workflows/presentation-creation.json +143 -308
  47. package/workflows/relocation-workflow-us.json +161 -535
  48. package/workflows/scoped-documentation-workflow.json +110 -181
  49. package/workflows/workflow-for-workflows.v2.json +72 -16
  50. package/workflows/CHANGELOG-bug-investigation.md +0 -298
  51. package/workflows/bug-investigation.agentic.json +0 -212
  52. package/workflows/bug-investigation.json +0 -112
  53. package/workflows/mr-review-workflow.agentic.json +0 -538
  54. package/workflows/mr-review-workflow.json +0 -277
@@ -1,237 +1,62 @@
1
1
  {
2
2
  "id": "intelligent-test-case-generation",
3
- "name": "Intelligent Test Case Generation from Tickets",
4
- "version": "0.0.1",
5
- "description": "Transforms ticket requirements into systematic test cases using evidence-driven analysis, dual-brain processing (NLP + LLM), document discovery, and progressive scenario expansion. Produces integration and end-to-end tests optimized for developer readability and LLM consumption with confidence scoring and validation loops.",
3
+ "name": "Test Case Generation from Tickets",
4
+ "version": "1.0.0",
5
+ "description": "Systematically extracts integration and end-to-end test cases from ticket requirements. Reads the ticket carefully, identifies boundary conditions and edge cases, traces affected code paths, and produces developer-readable test case descriptions ready for implementation.",
6
6
  "preconditions": [
7
- "Agent has access to codebase analysis tools (grep, file readers, semantic search)",
8
- "User can provide ticket information in any standard format (JIRA, GitHub Issues, etc.)",
9
- "Agent has access to document analysis capabilities for BRDs, architecture docs, specs",
10
- "Workflow execution environment supports confidence scoring and validation loops"
11
- ],
12
- "clarificationPrompts": [
13
- "What ticket system are you using? (JIRA, GitHub Issues, Azure DevOps, etc.)",
14
- "What's your team's experience level with test case creation? (Mixed junior/senior, mostly senior, mostly junior)",
15
- "Do you have existing test patterns or frameworks we should align with?",
16
- "What automation level do you prefer? (High: auto-approve >8.0 confidence, Medium: standard confirmations, Low: extra validation)",
17
- "Are there specific document repositories we should search? (Confluence, SharePoint, Git repos, etc.)"
7
+ "User provides a ticket (title, description, acceptance criteria) in any standard format.",
8
+ "Agent has read access to the codebase for tracing affected paths and finding existing test patterns.",
9
+ "Agent can browse relevant documentation such as architecture docs or API specs if they exist."
18
10
  ],
19
11
  "metaGuidance": [
20
- "PAUSE POLICY: If required variables are missing and no assumptions accepted, pause and ask targeted questions before proceeding.",
21
- "EVIDENCE POLICY: If evidenceScore < threshold, request more sources and do not proceed until satisfied or assumptions are accepted.",
22
- "ASSUMPTION POLICY: Proceed with documented assumptions only after explicit confirmation; record risks and mitigation.",
23
- "DUAL-BRAIN PROCESSING: Always use both structured NLP extraction AND creative LLM expansion for comprehensive coverage.",
24
- "CONFIDENCE CALIBRATION: Use mathematical confidence framework with adjustable thresholds based on automation level.",
25
- "LIVING DOCUMENTATION: Maintain TEST_CONTEXT.md throughout workflow. Update after major milestones for session continuity.",
26
- "HYPOTHESIS-DRIVEN TESTING: Generate test hypotheses first, then validate with evidence.",
27
- "**FUNCTION DEFINITIONS:** fun analyzeTicket(depth=1|2|3) = 'Analyze ticket at specified depth levels: L1=requirements, L2=dependencies, L3=system impact. Extract entities, actions, data flows, acceptance criteria.'",
28
- "fun evaluateReadiness() = 'Compute requiredVarsFound, missingVars[], completenessScore (0-1) from context. Set proceed/question/assumption flags.'",
29
- "fun collectEvidence(minimumSources=3) = 'Gather supporting evidence for hypotheses. Score evidence quality 1-10. Document sources and confidence levels.'",
30
- "fun discoverDocuments(types) = 'Search for missing documentation via semantic search. Types may include BRDs, ArchitectureDocs, ApiSpecs, ExistingTests. Score relevance and completeness.'",
31
- "fun scoreAndValidate(autoApproveThreshold=8.0) = 'Score item using criteria (1-10). Apply gates: >8.0 auto-approve; 6.0–7.9 review; <6.0 require additional evidence.'",
32
- "fun updateTestContext(sections) = 'Maintain TEST_CONTEXT.md: ticket analysis, evidence, hypotheses, confidence scores, validation results.'",
33
- "fun dualBrainProcess(enableNlp=true, enableCreative=true) = 'Stage 1: NLP extraction of structured data (entities, dependencies, flows). Stage 2: LLM creative expansion (edge cases, negative paths, integration scenarios).'",
34
- "fun generateTestHypotheses(count=5) = 'Create 3–5 test hypotheses focused on integration/E2E scenarios. Include risk assessment.'",
35
- "fun progressiveExpansion(levels) = 'Expand scenarios in layers: Core→Edge→System→Chaos. Adapt complexity to user experience.'",
36
- "fun adaptToUserLevel(level=Junior|Mixed|Senior) = 'Deliver content adapted to the selected user level.'",
37
- "fun scoreConfidence(weights) = 'Calculate confidence (1-10) using: requirements clarity, system context, evidence quality, coverage completeness.'",
38
- "fun validateCoverage(minScore=7) = 'Assess coverage completeness; identify gaps; score coverage 1-10; suggest additional scenarios if needed.'",
39
- "fun formatDualOutput(human=true, machine=true) = 'Generate both human-readable (Gherkin/Markdown) and machine-readable (JSON/structured) formats simultaneously.'",
40
- "fun buildTicketSignature() = 'Extract entities, acceptance criteria, identifiers (ticket ID), impacted modules, user flows; output tokens/phrases and canonical signature.'",
41
- "fun scoreDocRelevance(chunk, signature) = 'Compute lexical+semantic relevance; detect explicit mentions of ticket ID/criteria; return relevanceScore 0–1 with rationale.'",
42
- "fun extractCitations(criteria) = 'For each acceptance criterion, locate explicit quotes/snippets with {doc, section, quote, relevanceScore}.'",
43
- "fun computeCriteriaCoverage() = 'Compute fraction (0–1) of acceptance criteria with ≥1 strong citation.'",
44
- "fun computeTicketSpecificEvidenceScore() = 'Aggregate evidence quality emphasizing ticket specificity; scale 1–10.'",
45
- "fun computeDocNoiseRatio() = 'Compute proportion (0–1) of cited text that is generic/non-ticket; lower is better.'"
12
+ "EXPLORE FIRST: use tools to read the ticket and codebase before asking the user anything. Only ask for information you genuinely cannot discover yourself.",
13
+ "SCOPE: focus on integration and end-to-end tests. Unit tests are out of scope unless the ticket explicitly targets internal logic.",
14
+ "BOUNDARY CONDITIONS: for each acceptance criterion, actively look for boundary values, empty/null cases, permission boundaries, and ordering dependencies.",
15
+ "TRACEABILITY: every test scenario must map to at least one acceptance criterion or identified risk. Do not generate untraceable scenarios.",
16
+ "DEVELOPER READABILITY: write test descriptions in plain language a developer can implement without guessing. Include what to set up, what to call, and what to assert.",
17
+ "HONEST GAPS: if the ticket is ambiguous or the acceptance criteria are incomplete, name the specific gap and propose the most reasonable interpretation rather than silently guessing.",
18
+ "V2 DURABILITY: use output.notesMarkdown as the primary durable record. Do not create TEST_CONTEXT.md or any markdown checkpoint file unless the user explicitly asks."
46
19
  ],
47
20
  "steps": [
48
21
  {
49
- "id": "phase-0-intelligent-triage",
50
- "title": "Phase 0: Intelligent Ticket Triage & Context Setup",
51
- "prompt": "**SYSTEMATIC TEST GENERATION BEGINS** - Transform ticket requirements into comprehensive test cases through evidence-driven analysis.\n\nanalyzeTicket(depth=3) and buildTicketSignature() to establish foundation:\n\n**STEP 1: Ticket Analysis & Classification**\n- **Ticket Information**: Please provide the complete ticket details (title, description, acceptance criteria, labels, etc.)\n- **System Context**: What system/component does this ticket affect?\n- **Change Type**: Is this a new feature, bug fix, enhancement, or refactoring?\n- **Risk Assessment**: What's the business impact if this functionality fails?\n\n**STEP 2: Complexity & Scope Assessment**\nBased on the ticket analysis, I'll classify the testing complexity:\n- **Simple**: Single component, clear requirements, minimal integration\n- **Standard**: Multiple components, moderate integration, some unknowns\n- **Complex**: Cross-system changes, high integration, significant risk\n\n**STEP 3: User Experience Level**\nWhat's your experience level with test case creation?\n- **Junior**: Need detailed guidance and explanations\n- **Mixed**: Team has varying skill levels\n- **Senior**: Prefer efficient, advanced patterns\n\n**STEP 4: Automation Preferences**\nWhat automation level do you prefer?\n- **High**: Auto-approve confidence >8.0, minimal confirmations\n- **Medium**: Standard confirmations for key decisions\n- **Low**: Extra validation for comprehensive coverage\n\n**OUTPUTS**: Set context variables for adaptive workflow execution, including ticketSignature.",
52
- "agentRole": "You are a senior test strategy specialist with expertise in analyzing software requirements and determining optimal testing approaches. Your role is to quickly assess ticket complexity, understand system context, and set up the workflow for systematic test case generation.",
53
- "guidance": [
54
- "THOROUGH ANALYSIS: Extract all relevant information from ticket details",
55
- "CONTEXT AWARENESS: Understand the ticket's place in the larger system",
56
- "ADAPTIVE SETUP: Configure workflow based on user experience and preferences",
57
- "EVIDENCE FOUNDATION: Establish the evidence base for systematic test generation"
58
- ],
59
- "requireConfirmation": true
60
- },
61
- {
62
- "id": "phase-0b-readiness",
63
- "title": "Phase 0b: Readiness Evaluation (Soft Gate)",
64
- "prompt": "Evaluate readiness: compute requiredVarsFound, missingVars[], completenessScore (0-1), gather evidence, set evidenceScore (1-10). Outcome flags: proceedNeeded, questioningNeeded, assumptionNeeded.",
65
- "askForFiles": true,
66
- "hasValidation": true,
67
- "validationCriteria": [
68
- { "type": "length", "min": 200, "message": "Summarize readiness and evidence (≥200 chars)" }
69
- ],
70
- "requireConfirmation": true
71
- },
72
- {
73
- "id": "phase-0c-questioning-loop",
74
- "type": "loop",
75
- "title": "Resolve Missing Inputs",
76
- "loop": { "type": "forEach", "items": "missingVars", "itemVar": "missing", "maxIterations": 5 },
77
- "body": [
78
- {
79
- "id": "ask-missing",
80
- "title": "Provide: {{missing}}",
81
- "prompt": "Please provide '{{missing}}'. If unknown, choose an option or confirm an assumption. Attach links/files if applicable.",
82
- "askForFiles": true,
83
- "requireConfirmation": true
84
- }
85
- ]
86
- },
87
- {
88
- "id": "phase-0d-assumptions",
89
- "title": "Assumption Proposal & Risks",
90
- "prompt": "Propose explicit assumptions for remaining gaps with risks and mitigation. Confirm to proceed and record assumptions[].",
91
- "requireConfirmation": true
22
+ "id": "phase-0-ticket-analysis",
23
+ "title": "Phase 0: Read the Ticket and Understand the System",
24
+ "prompt": "Read everything before you generate a single test case.\n\nStart with the ticket. Extract:\n- The core user action or system change being described\n- Every acceptance criterion (numbered list)\n- Explicit constraints and non-goals\n- Labels, priority, and any linked tickets that add context\n\nThen trace the affected code. Find:\n- Which modules, services, and API endpoints are touched\n- What data flows are involved (what goes in, what comes out, what persists)\n- Existing tests that cover adjacent behavior -- these show the expected test style and depth\n- Integration points that could break (external services, caches, auth, queues)\n\nFor each affected module, confirm you can state: what it does, what its entry points are, and what its integration boundaries are. If you cannot answer all three, keep tracing before moving on.\n\nThen classify the scope:\n- `ticketComplexity`: Simple / Standard / Complex\n - Simple: single path, 1-3 clear acceptance criteria, low integration breadth\n - Standard: multiple paths or criteria, moderate integration surface\n - Complex: cross-service, high ambiguity, or significant edge case density\n- `testDepth`: Integration / E2E / Both\n\nFinally, check what you know:\n- Which acceptance criteria are clearly testable as stated?\n- Which are ambiguous or incomplete?\n- What integration boundaries are in scope?\n\nCapture:\n- `ticketSummary` -- one paragraph covering the core change and why it matters\n- `acceptanceCriteria` -- numbered list extracted from the ticket\n- `affectedPaths` -- key modules, endpoints, or services involved\n- `existingTestPatterns` -- test framework, naming style, and fixture approach used in this repo\n- `ticketComplexity`\n- `testDepth`\n- `ambiguities` -- acceptance criteria or requirements that are unclear or incomplete",
25
+ "requireConfirmation": false
92
26
  },
93
27
  {
94
- "id": "phase-1-evidence-gathering",
28
+ "id": "phase-0b-clarify-ambiguities",
29
+ "title": "Phase 0b: Resolve Critical Ambiguities",
95
30
  "runCondition": {
96
- "and": [
97
- { "or": [ { "var": "completenessScore", "gte": 0.7 }, { "var": "assumptionAccepted", "equals": true } ] },
98
- { "var": "evidenceScore", "gte": 7.5 }
99
- ]
31
+ "var": "ambiguities",
32
+ "not_equals": []
100
33
  },
101
- "title": "Phase 1: Evidence Gathering & Ticket-Specific Scoring",
102
- "prompt": "collectEvidence(ticket requirements) and discoverDocuments(system context)\n\n**TICKET-SPECIFIC EVIDENCE COLLECTION**\n- scoreDocRelevance(each document chunk, ticketSignature)\n- extractCitations(acceptance criteria) and build evidenceMap: criterion -> [{doc, section, quote, relevanceScore}]\n- computeCriteriaCoverage()\n- computeTicketSpecificEvidenceScore()\n- computeDocNoiseRatio()\n\nscoreAndValidate(evidence completeness, 7/10 threshold)\n\nupdateTestContext(evidence-analysis, evidenceMap, criteriaCoverage, ticketSpecificEvidenceScore, docNoiseRatio)\n\n**QUALITY GATE**: Require criteriaCoverage ≥ 0.7, ticketSpecificEvidenceScore ≥ 7.0, docNoiseRatio ≤ 0.3 before proceeding.",
103
- "agentRole": "You are a systematic evidence analyst specializing in gathering comprehensive context for test case generation. Your expertise lies in identifying information gaps, discovering relevant documentation, and building complete evidence bases for reliable test design.",
104
- "guidance": [
105
- "SYSTEMATIC COLLECTION: Use structured approach to gather all relevant evidence",
106
- "GAP IDENTIFICATION: Actively identify and address missing information",
107
- "DOCUMENT DISCOVERY: Use semantic search and intelligent questioning to find context",
108
- "QUALITY THRESHOLD: Don't proceed without sufficient evidence foundation"
109
- ],
110
- "validationCriteria": [
111
- { "type": "length", "min": 200, "message": "Evidence collection must be comprehensive (minimum 200 characters of analysis)" },
112
- { "type": "regex", "pattern": "criteriaCoverage|coverage", "flags": "i", "message": "Include criteriaCoverage metric" },
113
- { "type": "regex", "pattern": "docNoiseRatio", "flags": "i", "message": "Include docNoiseRatio metric" },
114
- { "type": "regex", "pattern": "evidenceMap|citation|quote", "flags": "i", "message": "Provide explicit citations/quotes per criterion" }
115
- ],
116
- "hasValidation": true
117
- },
118
- {
119
- "id": "phase-1b-evidence-audit",
120
- "title": "Phase 1b: Evidence Audit (Ticket-Specific)",
121
- "prompt": "Audit the ticket-specific evidence before hypothesis formation.\n\n**Produce:**\n- evidenceMap (acceptance criterion -> citations with {doc, section, quote, relevanceScore})\n- criteriaCoverage (0–1), ticketSpecificEvidenceScore (1–10), docNoiseRatio (0–1)\n- Brief rationale for any low-coverage criteria and targeted follow-up actions\n\nConfirm metrics and highlight gaps. Do not proceed if coverage/noise thresholds are not met.",
122
- "validationCriteria": [
123
- { "type": "regex", "pattern": "evidenceMap|criterion", "flags": "i", "message": "Include evidenceMap mapping criteria to citations" },
124
- { "type": "regex", "pattern": "criteriaCoverage|ticketSpecificEvidenceScore|docNoiseRatio", "flags": "i", "message": "Report ticket-specific metrics" }
125
- ],
126
- "hasValidation": true,
34
+ "prompt": "Before generating test scenarios, resolve the ambiguities you found.\n\nFor each ambiguity in `ambiguities`:\n1. State what is unclear and why it matters for test design\n2. Propose the most reasonable interpretation based on context\n3. Ask me to confirm, adjust, or provide the missing information\n\nKeep questions targeted. If the ticket, codebase, or docs can answer the question, answer it yourself first.\n\nIf the user's response significantly changes the scope or adds new acceptance criteria, revisit Phase 1 scenario identification before continuing — do not carry stale scenarios forward.\n\nCapture:\n- `resolvedAmbiguities` -- list of ambiguities with chosen interpretation\n- `openAmbiguities` -- ambiguities the user still needs to resolve (initialize as empty)",
127
35
  "requireConfirmation": true
128
36
  },
129
37
  {
130
- "id": "phase-2-gap-check",
131
- "title": "Phase 2 Gap Check",
132
- "prompt": "Quick gap check before hypotheses. If new gaps detected, append to openQuestions and run questioning loop once.",
133
- "runCondition": { "or": [ { "var": "newGapsDetected", "equals": true }, { "var": "newGapsDetected", "equals": false } ] }
38
+ "id": "phase-1-scenario-identification",
39
+ "title": "Phase 1: Identify Test Scenarios",
40
+ "prompt": "Turn the acceptance criteria and your system knowledge into a concrete list of test scenarios.\n\nFor each acceptance criterion, identify:\n\n**Happy path scenarios** (the criterion succeeds under normal conditions)\n- What is the minimal valid input that exercises this criterion?\n- Are there multiple valid input shapes that should each be tested?\n\n**Boundary and edge cases**\n- Empty, null, or missing inputs\n- Minimum and maximum values\n- Permission boundaries (authorized vs unauthorized)\n- Ordering dependencies (what must exist or happen first?)\n- Concurrent or retry scenarios if the feature involves state\n\n**Failure and degradation scenarios**\n- What happens when a dependency is unavailable or returns an error?\n- What happens when the input is invalid?\n- What happens when a required precondition is not met?\n\nFor each scenario, note:\n- Which acceptance criterion it covers\n- The risk if this case is not tested (Low / Medium / High)\n- Whether it is integration-level or E2E\n- `uncertain`: true if you are not confident the expected behavior is correct or if the implementation approach is unclear\n\nDo not write the test cases yet -- just the scenario list. For any scenario marked `uncertain: true`, add the specific question to `openAmbiguities` so it can be resolved before test cases are written.\n\nCapture:\n- `scenarios` -- list of identified test scenarios with criterion mapping and risk level",
41
+ "requireConfirmation": false
134
42
  },
135
43
  {
136
- "id": "phase-2-dual-brain-analysis",
137
- "runCondition": {
138
- "and": [
139
- { "or": [ { "var": "completenessScore", "gte": 0.7 }, { "var": "assumptionAccepted", "equals": true } ] },
140
- { "var": "evidenceScore", "gte": 7.5 },
141
- { "var": "criteriaCoverage", "gte": 0.7 },
142
- { "var": "docNoiseRatio", "lte": 0.3 },
143
- { "var": "ticketSpecificEvidenceScore", "gte": 7.0 }
144
- ]
145
- },
146
- "title": "Phase 2: Dual-Brain Processing & Hypothesis Formation",
147
- "prompt": "dualBrainProcess(collected evidence) and generateTestHypotheses(ticket, context)\n\n**DUAL-BRAIN PROCESSING ARCHITECTURE**\nCombine structured NLP analysis with creative LLM expansion to generate comprehensive test hypotheses.\n\nscoreAndValidate(each hypothesis, testability criteria)\n\nupdateTestContext(hypothesis-analysis, ranked test hypotheses with risk assessment)\n\n**QUALITY GATE**: Maximum 5 hypotheses, each scored for testability and business impact.",
148
- "agentRole": "You are a dual-brain test analysis expert combining systematic NLP processing with creative scenario generation. Your role is to extract structured information while also discovering creative test scenarios that human analysts might miss.",
149
- "guidance": [
150
- "STRUCTURED EXTRACTION: Use NLP techniques for systematic information parsing",
151
- "CREATIVE EXPANSION: Generate innovative test scenarios beyond obvious cases",
152
- "HYPOTHESIS RIGOR: Base all hypotheses on concrete evidence from analysis",
153
- "RISK PRIORITIZATION: Focus on high-impact, high-probability test scenarios"
154
- ],
155
- "validationCriteria": [
156
- { "type": "regex", "pattern": "hypothesis|test case|scenario", "flags": "i", "message": "Output must contain test hypotheses or scenarios" }
157
- ],
158
- "hasValidation": true
159
- },
160
- {
161
- "id": "phase-3-gap-check",
162
- "title": "Phase 3 Gap Check",
163
- "prompt": "Quick gap check before scenario generation. If new gaps detected, append to openQuestions and run questioning loop once.",
164
- "runCondition": { "or": [ { "var": "newGapsDetected", "equals": true }, { "var": "newGapsDetected", "equals": false } ] }
165
- },
166
- {
167
- "id": "phase-3-progressive-test-generation",
168
- "runCondition": {
169
- "and": [
170
- { "or": [ { "var": "completenessScore", "gte": 0.7 }, { "var": "assumptionAccepted", "equals": true } ] },
171
- { "var": "evidenceScore", "gte": 7.5 },
172
- { "var": "criteriaCoverage", "gte": 0.7 },
173
- { "var": "docNoiseRatio", "lte": 0.3 },
174
- { "var": "ticketSpecificEvidenceScore", "gte": 7.0 }
175
- ]
176
- },
177
- "title": "Phase 3: Progressive Test Scenario Generation",
178
- "prompt": "progressiveExpansion(validated hypotheses, user experience level)\n\n**PROGRESSIVE TEST EXPANSION ARCHITECTURE**\nGenerate layered test scenarios: Core→Edge→System→Chaos, adapted to user experience level.\n\nadaptToUserLevel(test scenario complexity, user experience level)\n\nupdateTestContext(test-scenarios, layered test scenarios with traceability)\n\n**OUTPUT**: Comprehensive test scenarios adapted to user capabilities.",
179
- "agentRole": "You are a progressive test design architect specializing in creating layered test scenarios that scale with team expertise. Your role is to generate comprehensive test coverage while adapting complexity to user capabilities.",
180
- "guidance": [
181
- "LAYERED APPROACH: Build test scenarios in progressive complexity layers",
182
- "ADAPTIVE COMPLEXITY: Match scenario depth to user experience level",
183
- "COMPREHENSIVE COVERAGE: Ensure all critical paths are tested",
184
- "PRACTICAL IMPLEMENTATION: Include setup, execution, and cleanup details"
185
- ]
44
+ "id": "phase-2-coverage-check",
45
+ "title": "Phase 2: Check Coverage Before Writing",
46
+ "prompt": "Before writing test cases, verify that the scenario list is complete.\n\nFor each acceptance criterion, confirm:\n- At least one happy path scenario covers it\n- At least one boundary or failure scenario exists if the criterion involves state, permissions, or external calls\n- No criterion is left with zero scenarios\n\nAlso check:\n- Are there important integration points (auth, external services, persistence) with no coverage?\n- Are there critical paths in the code you traced that have no corresponding scenario?\n\nIf you find a gap, add the missing scenario to `scenarios` now. If a gap exists but you cannot fill it without more information, add it to `openAmbiguities`.\n\nReport:\n- Acceptance criteria coverage (which criteria have at least one scenario)\n- Integration boundary coverage (which boundaries are tested)\n- Any remaining gaps and why they exist\n\nCapture:\n- `scenarios` -- updated with any added scenarios\n- `coverageSummary` -- brief coverage assessment",
47
+ "requireConfirmation": false
186
48
  },
187
49
  {
188
- "id": "phase-4-confidence-scoring",
189
- "runCondition": {
190
- "and": [
191
- { "or": [ { "var": "completenessScore", "gte": 0.7 }, { "var": "assumptionAccepted", "equals": true } ] },
192
- { "var": "evidenceScore", "gte": 7.5 },
193
- { "var": "criteriaCoverage", "gte": 0.7 },
194
- { "var": "docNoiseRatio", "lte": 0.3 },
195
- { "var": "ticketSpecificEvidenceScore", "gte": 7.0 }
196
- ]
197
- },
198
- "title": "Phase 4: Confidence Scoring & Quality Validation",
199
- "prompt": "scoreConfidence(generated test cases, evidence base) and validateCoverage(scenarios, requirements)\n\n**CONFIDENCE SCORING FRAMEWORK**\nApply mathematical confidence framework using 4-factor scoring: Requirements Clarity, System Context, Evidence Quality, Coverage Completeness.\n\nscoreAndValidate(test scenarios, confidence criteria)\n\nupdateTestContext(confidence-analysis, scored scenarios with coverage gaps)\n\n**OUTPUT**: Confidence-scored test scenarios with coverage analysis and gap recommendations.",
200
- "agentRole": "You are a test quality assurance specialist with expertise in confidence scoring and coverage analysis. Your role is to objectively assess test scenario quality and ensure comprehensive coverage of requirements.",
201
- "guidance": [
202
- "OBJECTIVE SCORING: Use mathematical framework for consistent confidence assessment",
203
- "COVERAGE ANALYSIS: Systematically map test scenarios to requirements",
204
- "GAP IDENTIFICATION: Actively identify and address coverage gaps",
205
- "QUALITY GATES: Apply appropriate thresholds based on automation preferences"
206
- ],
207
- "validationCriteria": [
208
- { "type": "regex", "pattern": "confidence|score|coverage", "flags": "i", "message": "Output must include confidence scoring and coverage analysis" }
209
- ],
210
- "hasValidation": true
50
+ "id": "phase-3-write-test-cases",
51
+ "title": "Phase 3: Write the Test Cases",
52
+ "prompt": "Write a test case description for each scenario in `scenarios`.\n\nEach test case must include:\n\n**ID**: TC-{N} where N is a sequential number\n**Title**: one clear sentence describing what is being verified\n**Acceptance Criterion**: which criterion from `acceptanceCriteria` this covers\n**Type**: Integration or E2E\n**Risk**: Low / Medium / High (from your scenario analysis)\n**Preconditions**: what must be set up or exist before the test runs\n**Test Steps**: numbered list of actions in plain language\n**Expected Result**: what the system should do or return\n**Notes**: any implementation hints, known edge cases, or open questions\n\nWrite test cases in the style found in `existingTestPatterns`. If no patterns were found, use this plain Markdown structure for each test case: **Given** (preconditions and setup), **When** (the action taken), **Then** (expected result and assertions).\n\nGroup test cases by acceptance criterion.\n\nAfter writing all test cases, produce a summary table with:\n- TC-{N} | Title | Type | Risk | Criterion\n\nCapture:\n- `testCaseCount` -- total number of test cases written",
53
+ "requireConfirmation": false
211
54
  },
212
55
  {
213
- "id": "phase-5-dual-format-output",
214
- "runCondition": {
215
- "and": [
216
- { "or": [ { "var": "completenessScore", "gte": 0.7 }, { "var": "assumptionAccepted", "equals": true } ] },
217
- { "var": "evidenceScore", "gte": 7.5 },
218
- { "var": "criteriaCoverage", "gte": 0.7 },
219
- { "var": "docNoiseRatio", "lte": 0.3 },
220
- { "var": "ticketSpecificEvidenceScore", "gte": 7.0 }
221
- ]
222
- },
223
- "title": "Phase 5: Dual-Format Output Generation",
224
- "prompt": "formatDualOutput(validated test scenarios) - Generate both human-readable and LLM-consumable formats\n\n**DUAL-FORMAT GENERATION STRATEGY**\n\n**FORMAT 1: Human-Readable (Developer-Optimized)**\nClear, scannable format for manual review and JIRA integration:\n- Test scenarios with objectives, preconditions, steps, expected results\n- Priority levels and confidence scores\n- Proper markdown formatting for JIRA copy-paste\n- Traceability links to requirements\n\n**FORMAT 2: LLM-Readable (Machine-Optimized)**\nJSON format optimized for programmatic consumption:\n- Structured metadata with generation info and confidence thresholds\n- Test scenarios with IDs, types, priorities, and confidence scores\n- Requirements mapping and test data specifications\n- Tags for categorization and tool integration\n\n**SIMULTANEOUS GENERATION**\n- Generate both formats from the same source data\n- Ensure consistency between formats\n- Validate format integrity and completeness\n- Optimize for different consumption patterns\n\n**OUTPUT**: Complete test scenarios in both human-readable and machine-readable formats, ready for JIRA integration and future automation",
225
- "agentRole": "You are a dual-format output specialist with expertise in creating documentation optimized for both human consumption and machine processing. Your role is to generate test scenarios that serve both immediate manual use and future automation needs.",
226
- "guidance": [
227
- "DUAL OPTIMIZATION: Create formats optimized for different consumption patterns",
228
- "CONSISTENCY MAINTENANCE: Ensure both formats contain identical information",
229
- "JIRA INTEGRATION: Format human-readable output for easy ticket integration",
230
- "AUTOMATION READY: Structure machine-readable output for future tool consumption"
231
- ],
56
+ "id": "phase-4-review-and-handoff",
57
+ "title": "Phase 4: Review and Handoff",
58
+ "prompt": "Before handing off, do a final review pass.\n\nCheck each test case for:\n- Completeness: are preconditions, steps, and expected results clear enough to implement without guessing?\n- Accuracy: does the expected result match what the system should actually do?\n- Traceability: does every test case map to a criterion or identified risk?\n- Redundancy: are there duplicates that could be merged?\n\nThen summarize what was produced:\n- How many test cases, broken down by type (Integration / E2E) and risk level (High / Medium / Low)\n- Which acceptance criteria have full coverage (happy path + at least one negative case)\n- Which criteria have partial coverage and why\n- Any open questions the implementer should resolve before writing the tests\n- Anything this workflow could not determine from the ticket or codebase\n\nPresent the full test case list, then the summary.",
232
59
  "requireConfirmation": true
233
60
  }
234
61
  ]
235
62
  }
236
-
237
-
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "id": "personal-learning-materials-creation-branched",
3
3
  "name": "Personal Learning Materials Creation Workflow (Branched)",
4
- "version": "1.0.0",
4
+ "version": "1.1.0",
5
5
  "description": "A systematic workflow for creating high-quality learning materials with three thoroughness paths: Quick Start (essential materials), Balanced (comprehensive system), and Comprehensive (enterprise-grade). Adapts depth and features based on user time constraints and quality goals.",
6
6
  "clarificationPrompts": [
7
7
  "Do you have a completed learning plan with defined objectives and modules?",
@@ -83,11 +83,6 @@
83
83
  "Focus on materials that work together as a cohesive system"
84
84
  ],
85
85
  "validationCriteria": [
86
- {
87
- "type": "regex",
88
- "pattern": "\\b(prerequisite|dependency|sequence)\\b",
89
- "message": "Must analyze learning dependencies and sequencing"
90
- },
91
86
  {
92
87
  "type": "contains",
93
88
  "value": "assessment",
@@ -117,11 +112,6 @@
117
112
  "Design for scalability and continuous improvement"
118
113
  ],
119
114
  "validationCriteria": [
120
- {
121
- "type": "regex",
122
- "pattern": "\\b(taxonomy|cognitive|architecture)\\b",
123
- "message": "Must apply advanced learning science principles"
124
- },
125
115
  {
126
116
  "type": "contains",
127
117
  "value": "effectiveness",
@@ -156,11 +146,6 @@
156
146
  "value": "template",
157
147
  "message": "Must include template design for efficiency"
158
148
  },
159
- {
160
- "type": "regex",
161
- "pattern": "\\b(efficient|quick|simple)\\b",
162
- "message": "Must emphasize efficiency and simplicity"
163
- },
164
149
  {
165
150
  "type": "length",
166
151
  "min": 300,
@@ -185,11 +170,6 @@
185
170
  "Design for scalability and enterprise deployment"
186
171
  ],
187
172
  "validationCriteria": [
188
- {
189
- "type": "regex",
190
- "pattern": "\\b(integration|optimization|analytics)\\b",
191
- "message": "Must include advanced integration and optimization planning"
192
- },
193
173
  {
194
174
  "type": "contains",
195
175
  "value": "effectiveness",