@dzhechkov/keysarium 1.4.0 → 1.5.0

package/templates/.claude/skills/feature-adr/modules/03.5-ideation-swarm.md

@@ -0,0 +1,180 @@
+# Step 3.5: QCSD Ideation Swarm
+
+> Quality criteria assessment using HTSM v6.3, Risk Storming, and Testability analysis on refined ADR before implementation begins.
+
+## Source
+
+Adapted from [agentic-qe qcsd-ideation-swarm](https://github.com/proffesor-for-testing/agentic-qe) (Tier 3: Verified).
+
+> Load: `references/agentic-qe/qcsd-ideation-swarm.md`
+
+## When
+
+M+ tiers. This step runs AFTER Step 3 (ADR) and BEFORE Step 6 (Implementation Plan).
+- **M:** Core agents only (3 agents)
+- **L/XL:** Core + conditional agents (3-9 agents based on feature flags)
+
+## Model
+
+sonnet (analytical quality assessment — multiple parallel agents)
+
+## Input
+
+- `{REQUIREMENTS}` from Step 1
+- `{ADR_DECISIONS}` from Step 3 (with shift-left validation results)
+- `{RESEARCH_FINDINGS}` from Step 2 (if L/XL)
+- `{DOMAIN_MODEL}` from Step 4 (if available)
+
+## Protocol
+
+### 1. Flag Detection (MANDATORY)
+
+Scan feature requirements + ADR decisions and SET these flags:
+
+```
+□ HAS_UI = FALSE
+  Set TRUE if feature contains: UI, frontend, visual, component, screen, page, form,
+  button, modal, dialog, dashboard, widget, interface, display, view, layout, CSS, styling
+
+□ HAS_SECURITY = FALSE
+  Set TRUE if feature contains: auth, security, credential, token, encrypt, PII,
+  compliance, password, login, session, OAuth, JWT, permission, role, access control
+
+□ HAS_UX = FALSE
+  Set TRUE if feature contains: user experience, UX, journey, usability, user flow,
+  persona, friction, delight, onboarding, retention, engagement
+```
+
+Output flag detection results before proceeding.
+
+### 2. Spawn Core Agents (3 parallel — MANDATORY)
+
+ALL THREE core agents MUST be spawned in a SINGLE message:
+
+#### Agent 1: Quality Criteria Recommender (HTSM v6.3)
+
+Analyze ALL 10 HTSM categories with weight and testability score:
+
+| Category | Focus |
+|----------|-------|
+| Capability | Does it do what's required? |
+| Reliability | Under stress, load, edge cases |
+| Usability | Learnability, accessibility, efficiency |
+| Charisma | Visual design, responsiveness |
+| Security | Authentication, authorization, data protection |
+| Scalability | Growth handling, resource limits |
+| Compatibility | Browsers, devices, APIs, integrations |
+| Performance | Speed, throughput, resource usage |
+| Installability | Deployment, configuration, migration |
+| Development | Testability, maintainability, portability |
+
+**Output**: Quality criteria analysis with weighted scores per category.
+
+#### Agent 2: Risk Assessor (SFDIPOT)
+
+Apply SFDIPOT risk framework:
+- **S**tructure: Code architecture, component dependencies
+- **F**unction: Business logic, calculations, workflows
+- **D**ata: Data integrity, migrations, edge values
+- **I**nterfaces: API contracts, integration points
+- **P**latform: OS, browser, infrastructure dependencies
+- **O**perations: Deployment, monitoring, maintenance
+- **T**ime: Scheduling, concurrency, timeouts, caching
+
+**Output**: Minimum 10 risks with probability (1-5), impact (1-5), and risk score.
+
+#### Agent 3: Requirements Validator (Testability Scoring)
+
+Apply 10 Principles of Testability, score each 0-100:
+1. Observability — can we see what the system does?
+2. Controllability — can we put it in the state we need?
+3. Decomposability — can we test parts independently?
+4. Simplicity — is it only as complex as needed?
+5. Stability — does it change predictably?
+6. Information — do we have what we need to test?
+7. Communication — do we know what to test?
+8. Relation to prior work — can we leverage past tests?
+9. Time — do we have enough time to test?
+10. Accountability — who owns quality?
+
+**Output**: Testability score (0-100) with per-principle breakdown.
+
+### 3. Spawn Conditional Agents (L/XL, based on flags)
+
+| Flag | Agent | Analysis |
+|------|-------|----------|
+| HAS_UI | Accessibility Auditor | WCAG 2.2 AA compliance assessment |
+| HAS_SECURITY | Security Auditor | STRIDE threat modeling |
+| HAS_UX | QX Partner | User journey and experience quality |
+
+### 4. GO/NO-GO Decision
+
+After all agents complete, apply decision logic:
+
+| Metric | NO-GO | CONDITIONAL | GO |
+|--------|-------|-------------|-----|
+| Testability Score | < 40 | 40-79 | ≥ 80 |
+| HTSM Coverage | < 6/10 categories | 6-7/10 | ≥ 8/10 |
+| AC Completeness | < 50% | 50-89% | ≥ 90% |
+| Critical Risks | > 2 | 1-2 | 0 |
+
+- **NO-GO**: BLOCK. Requirements/ADR need rework. Return to Step 1 or Step 3.
+- **CONDITIONAL**: Proceed with warnings. Pass findings to Steps 6-8 as advisory context.
+- **GO**: Full confidence. Proceed to Step 6.
+
+### 5. Synthesis Report
+
+Generate consolidated `03.5_ideation_report.md` with:
+1. Executive summary (GO/CONDITIONAL/NO-GO verdict)
+2. Quality criteria scores (10 HTSM categories)
+3. Risk matrix (top 10 risks by risk score)
+4. Testability assessment (10 principles with scores)
+5. Test ideas (categorized: unit / integration / E2E)
+6. Conditional agent findings (if any)
+7. Recommendations prioritized by risk × impact
+
+## Output
+
+Create `features/<slug>/03.5_ideation_report.md` with full QCSD report.
+
+Set `{IDEATION_VERDICT}` variable (GO | CONDITIONAL | NO-GO).
+Set `{QUALITY_RISKS}` variable with top risks for downstream steps.
+
+## Checkpoint Format
+
+```
+═══════════════════════════════════════════════════════
+⏸️ STEP 3.5: QCSD Ideation Swarm Complete
+<promise>FEATURE_ADR_QUALITY_ASSESSED</promise>
+Tier: {COMPLEXITY_TIER}
+
+Verdict: {GO | CONDITIONAL | NO-GO}
+Agents spawned: {N} (3 core + {M} conditional)
+Testability: {score}/100 | HTSM: {N}/10 | Critical risks: {K}
+
+• "ок" — proceed to implementation planning
+• "NO-GO: rework [area]" — return to Step 1/3
+• "углуби [category]" — deeper analysis
+═══════════════════════════════════════════════════════
+```
+
+## Quality Gates
+
+- [ ] All 3 core agents spawned and completed
+- [ ] Conditional agents spawned for all TRUE flags
+- [ ] GO/NO-GO decision applied correctly
+- [ ] NO-GO blocks pipeline (returns to Step 1 or 3)
+- [ ] Testability score computed (0-100)
+- [ ] Risk matrix contains ≥10 risks
+- [ ] HTSM 10 categories all evaluated
+- [ ] Ideation report created
+
+## Anti-Patterns
+
+| Anti-Pattern | Detection | Fix |
+|-------------|-----------|-----|
+| Skipping ideation "for speed" | No 03.5 artifact | BLOCK — mandatory for M+ |
+| Fewer than 3 core agents | Agent count < 3 | BLOCK — all 3 required |
+| Skipping conditional agents | TRUE flag without agent | BLOCK — spawn if flag is TRUE |
+| Ignoring NO-GO verdict | Proceeding despite NO-GO | BLOCK — rework required |
+| Placeholder analysis | "[TODO]" in report | Reject — full analysis required |

package/templates/.claude/skills/feature-adr/modules/06-implementation-plan.md

@@ -10,17 +10,48 @@ Always runs. Adapts depth by tier:
 
 ## Model
 
-sonnet (analytical decomposition)
+sonnet (analytical decomposition) + code-goal-planner SPARC-GOAP methodology
 
 ## Input
 
 - `{REQUIREMENTS}` from Step 1
 - `{ADR_DECISIONS}` from Step 3 (M+)
+- `{IDEATION_VERDICT}` and `{QUALITY_RISKS}` from Step 3.5 (M+)
 - `{DOMAIN_MODEL}` from Step 4 (L/XL)
 - `{ARCHITECTURE}` from Step 5 (M+)
 
 ## Protocol
 
+> Load: `references/agentic-qe/code-goal-planner.md` for SPARC-GOAP methodology.
+
+### 0. Apply SPARC-GOAP Goal State Analysis
+
+Before decomposing tasks, define the goal state using the code-goal-planner SPARC methodology:
+
+```yaml
+goal: implement_{feature_slug}
+current_state:
+  features_complete: [existing features in codebase]
+  test_coverage: {current %}
+  relevant_files: [files that will be affected]
+
+goal_state:
+  features_complete: [...current, {new feature}]
+  test_coverage: {target %}
+  acceptance_criteria: [from {REQUIREMENTS}]
+  adr_decisions_implemented: [from {ADR_DECISIONS}]
+  quality_risks_mitigated: [from {QUALITY_RISKS}]
+
+sparc_phases:
+  specification: {REQUIREMENTS} + {ADR_DECISIONS}
+  pseudocode: Algorithm/logic design from ADRs
+  architecture: {ARCHITECTURE} + {DOMAIN_MODEL}
+  refinement: TDD cycles per task group
+  completion: Integration + deployment + validation
+```
+
+This analysis provides the planning context for task decomposition below.
+
 ### 1. Decompose into Tasks
 
 Break the feature into atomic tasks. Each task should be:
@@ -28,13 +59,16 @@ Break the feature into atomic tasks. Each task should be:
 - **Completable** — produces working code (not half-done)
 - **Testable** — has clear done criteria
 
-Task format:
+Task format (SPARC-enhanced):
 ```
 TASK-{N}: {Title}
   Description: {What to do}
+  SPARC Phase: specification | pseudocode | architecture | refinement | completion
   Files: {Files to create/modify}
   Depends on: TASK-{M} (or none)
   Test: {How to verify it works}
+  Success Criteria: {Measurable outcome}
+  Risk Mitigation: {From QUALITY_RISKS if applicable}
 ```
 
 ### 2. Order by Dependencies
@@ -54,16 +88,17 @@ Rules:
 - Tasks with no dependencies go first
 - Parallel-safe tasks are marked for concurrent execution
 - Tests depend on the code they test (but can be written first — TDD)
+- Map each task group to a SPARC phase (spec → pseudo → arch → refine → complete)
 
 ### 3. Identify Parallel Groups
 
 Group tasks that can be worked on simultaneously:
 
 ```
-Group 1: TASK-1, TASK-6  (no dependencies, can parallel)
-Group 2: TASK-2, TASK-3  (depend on Group 1)
-Group 3: TASK-4          (depends on Group 2)
-Group 4: TASK-5          (depends on all)
+Group 1: TASK-1, TASK-6  (no dependencies, can parallel)  [SPARC: architecture]
+Group 2: TASK-2, TASK-3  (depend on Group 1)               [SPARC: refinement]
+Group 3: TASK-4          (depends on Group 2)               [SPARC: refinement]
+Group 4: TASK-5          (depends on all)                   [SPARC: completion]
 ```
 
 For L/XL: assign parallel groups to different agents.
@@ -76,12 +111,26 @@ Insert checkpoints between groups:
 - After controllers → verify API contract
 - After tests → verify coverage
 
-### 5. Risk Assessment
+### 5. Risk Assessment (enhanced with QCSD findings)
 
 For each group, identify:
 - What could block this task?
 - What's the fallback if approach doesn't work?
 - Does this task have external dependencies (APIs, packages)?
+- **NEW**: Which risks from `{QUALITY_RISKS}` (Step 3.5) affect this task?
+- **NEW**: What mitigation from the ideation report applies here?
+
+### 6. Requirements Gap Check
+
+Before finalizing the plan, validate completeness:
+
+1. Cross-reference every `{REQUIREMENT}` (FR-N) → at least one TASK covers it
+2. Cross-reference every `{ADR_DECISION}` → at least one TASK implements it
+3. Cross-reference every critical risk from `{QUALITY_RISKS}` → mitigation in some TASK
+4. If gaps found → add missing TASKs and re-order the DAG
+5. **Iterate until no gaps remain** (max 3 iterations, then flag for user)
+
+This gap-check loop ensures the implementation plan is complete before coding begins.
 
 ## Output
 

package/templates/.claude/skills/feature-adr/modules/08-qe.md

@@ -56,19 +56,53 @@ For critical user flows:
 - Test with realistic data volumes
 - Test failure recovery scenarios
 
-### 3. Code Review (M+)
+### 3. Code Review via Brutal Honesty Review (M+)
 
-Adapted from agentic-qe brutal-honesty-review protocol:
+> Load: `references/agentic-qe/brutal-honesty-review.md`
 
-#### Review Dimensions
+Apply the **brutal-honesty-review** protocol from agentic-qe (Tier 2: Validated).
 
-| Dimension | Weight | Questions |
-|-----------|--------|-----------|
-| **Correctness** | 30% | Does it do what requirements say? Edge cases handled? |
-| **Security** | 20% | Injection risks? Auth bypasses? Data exposure? |
-| **Maintainability** | 20% | Readable? Follows patterns? Future-proof? |
-| **Performance** | 15% | N+1 queries? Unnecessary allocations? Missing indexes? |
-| **Consistency** | 15% | Matches codebase conventions? Naming consistent? |
+#### Mode Selection
+
+Choose review mode based on context:
+
+| Mode | When | Style |
+|------|------|-------|
+| **Linus** (technical precision) | Code has architectural/performance issues | "You're holding the lock for the entire I/O. Did you test under load?" |
+| **Ramsay** (standards-driven quality) | Tests or quality is subpar | "15 tests, 14 happy path. Where's the edge cases?" |
+| **Bach** (BS detection) | Architecture decisions seem cargo-cult | "Why are you using microservices for a single-user tool?" |
+
+**Default mode**: Linus for code review, Ramsay for test review.
+**Calibration**: Level 1 (Direct) — professional and actionable.
+
+#### Review Structure (per finding)
+
+```markdown
+## What's Broken
+[Surgical description — specific file, line, function]
+
+## Why It's Wrong
+[Technical explanation with evidence, not opinion]
+
+## What Correct Looks Like
+[Clear model of excellence — code example or pattern reference]
+
+## How to Fix It
+[Actionable steps, specific to this codebase]
+
+## Why This Matters
+[Impact if not fixed — security, performance, maintainability]
+```
+
+#### Review Dimensions (weighted)
+
+| Dimension | Weight | Mode | Questions |
+|-----------|--------|------|-----------|
+| **Correctness** | 30% | Linus | Does it do what requirements say? Edge cases handled? |
+| **Security** | 20% | Linus | Injection risks? Auth bypasses? Data exposure? |
+| **Maintainability** | 20% | Ramsay | Readable? Follows patterns? Future-proof? |
+| **Performance** | 15% | Linus | N+1 queries? Unnecessary allocations? Missing indexes? |
+| **Consistency** | 15% | Ramsay | Matches codebase conventions? Naming consistent? |
 
 #### Review Process
 
@@ -76,24 +110,51 @@ Adapted from agentic-qe brutal-honesty-review protocol:
 2. **Check against requirements** — is anything missing or extra?
 3. **Check against ADR decisions** — does code match chosen approach?
 4. **Check against architecture** — do components match diagrams?
-5. **Flag issues** with severity:
-   - 🔴 **BLOCKER** — must fix before merge
-   - 🟡 **WARNING** — should fix, but not blocking
+5. **Check against QCSD ideation risks** — are `{QUALITY_RISKS}` from Step 3.5 mitigated?
+6. **Flag issues** with severity:
+   - 🔴 **BLOCKER** — must fix before merge (Linus mode: "This is completely broken")
+   - 🟡 **WARNING** — should fix, but not blocking (Ramsay mode: "This is RAW")
    - 🔵 **SUGGESTION** — nice to have improvement
 
-### 4. Multi-Agent Review Panel (XL only)
+### 4. Multi-Agent Review Panel (L/XL)
+
+For L/XL features, spawn 3 parallel review agents using brutal-honesty modes:
+
+| Agent | Role | Mode | Model | Focus |
+|-------|------|------|-------|-------|
+| Agent 1 | Correctness Reviewer | Linus | sonnet | Requirements coverage, logic errors, performance |
+| Agent 2 | Security Reviewer | Linus | sonnet | OWASP top 10, auth, data exposure |
+| Agent 3 | Quality & Architecture Reviewer | Ramsay | sonnet | Test quality, pattern compliance, ADR adherence |
 
-For XL features, spawn 3 parallel review agents:
+Each agent produces independent findings using the brutal-honesty structure
+(What's Broken → Why → Correct → Fix → Impact). Synthesize into single report.
 
-| Agent | Role | Model | Focus |
-|-------|------|-------|-------|
-| Agent 1 | Correctness Reviewer | sonnet | Requirements coverage, logic errors |
-| Agent 2 | Security Reviewer | sonnet | OWASP top 10, auth, data exposure |
-| Agent 3 | Architecture Reviewer | sonnet | Pattern compliance, ADR adherence |
+### 5. Gap Detection Loop (M+)
+
+After review findings are compiled, run a gap check:
+
+```
+ITERATION {N}:
+  1. Check: Every FR-{N} from requirements → has passing test or verification
+  2. Check: Every ADR decision → reflected in code
+  3. Check: Every critical risk from QCSD → has mitigation in code
+  4. Check: Every 🔴 BLOCKER → has fix plan
+
+  If gaps found:
+    → List gaps explicitly
+    → Fix gaps (return to Step 7 for code changes if needed)
+    → Re-run smoke tests
+    → Increment iteration counter
+
+  If no gaps:
+    → Proceed to acceptance criteria validation
+
+  Max iterations: 3. After 3 iterations, flag remaining gaps for user decision.
+```
 
-Each agent produces independent findings. Synthesize into single report.
+This loop implements the "did we miss something?" recursive check from the original pipeline spec.
 
-### 5. Acceptance Criteria Validation
+### 6. Acceptance Criteria Validation
 
 For each requirement from Step 1:
 ```
@@ -103,7 +164,7 @@ FR-{N}: {requirement}
   Test: {test name or manual verification}
 ```
 
-### 6. QE Report
+### 7. QE Report
 
 Compile all findings into a structured report:
 
@@ -164,4 +225,7 @@ Verdict: {READY | NEEDS FIXES | CONDITIONAL}
 - [ ] No 🔴 BLOCKER findings remain
 - [ ] All MUST requirements have ✅ PASS status
 - [ ] Test coverage adequate for tier (S: smoke, M: unit, L: unit+integration, XL: full)
+- [ ] Brutal-honesty review completed (M+) with structured findings
+- [ ] Gap detection loop completed with zero remaining gaps (M+)
+- [ ] QCSD quality risks from Step 3.5 verified as mitigated (M+)
 - [ ] QE report created and complete