codymaster 4.1.3 → 4.3.0

package/skills/cm-quality-gate/SKILL.md

@@ -5,8 +5,6 @@ description: "Use before any deployment or completion claim. Enforces test gates
 
 # Quality Gate — Test + Verify + Ship Safe
 
-> **Role: QA Lead** — You enforce test gates, evidence-based verification, and frontend safety. No deploy without passing you.
-
 > **Three checkpoints, one skill:** Pre-deploy testing, evidence verification, frontend safety.
 
 ## The Iron Laws
@@ -133,32 +131,6 @@ Setting up or enhancing test suites for projects with frontend JavaScript/TypeSc
 | 5. Corruption Patterns | Known bad patterns (empty functions, truncation) | Required |
 | 6. Import/Export | Module references resolve | Recommended |
 | 7. CSS Validation | CSS files parse correctly | Recommended |
-| 8. XSS/Injection Safety | No unescaped innerHTML with dynamic data | **CRITICAL** |
-
-### Layer 8: XSS/Injection Safety (Learned: March 2026)
-
-```javascript
-import { execSync } from 'child_process';
-
-test('no unescaped innerHTML with dynamic data', () => {
-  // Scan all JS files for innerHTML with template literals NOT using escape
-  const result = execSync(
-    `grep -rn 'innerHTML.*\\\${' public/js/*.js | grep -v 'esc\\|SecurityUtils' || true`,
-    { encoding: 'utf-8' }
-  );
-  expect(result.trim()).toBe(''); // Must be empty = all escaped
-});
-
-test('sanitize.js loaded in all HTML pages', () => {
-  const htmlFiles = execSync('ls public/*.html', { encoding: 'utf-8' }).trim().split('\n');
-  for (const file of htmlFiles) {
-    const content = fs.readFileSync(file, 'utf-8');
-    if (content.includes('kit.js')) {
-      expect(content).toContain('sanitize.js'); // Must load before kit.js
-    }
-  }
-});
-```
 
 ### Setup
 
@@ -184,91 +156,26 @@ test('app.js has valid syntax', () => {
 
 ### Gate 4: Update Working Memory
 
-Per `_shared/helpers.md#Update-Continuity`
+After ALL gates pass, update `.cm/CONTINUITY.md`:
+- **Current Phase:** Set to `verified` or `ready-to-deploy`
+- **Just Completed:** Add `✅ Quality gate passed: [test count] tests, 0 failures`
 
-After ALL gates pass → record `✅ Quality gate passed: [test count] tests, 0 failures`
-
-After ANY gate fails → **FIRST run Memory Integrity Check:**
+After ANY gate fails, **FIRST run Memory Integrity Check:**
 1. List active learnings/decisions for the failing module
 2. Ask: "Did AI follow a learning/decision that caused this failure?"
 3. If YES → HEAL memory (invalidate/correct/scope-reduce) BEFORE recording new learning
 4. Record meta-learning in `.cm/meta-learnings.json` if memory was the cause
 
----
-
-### Gate 5: Quality Score Report
-
-After all gates execute, output a numeric quality score:
-
-```
-🎯 Gate Score: 87/100
-├── Secret Scan:      10/10 ✅
-├── Syntax:           10/10 ✅
-├── Tests:             8/10 ⚠️  (2 skipped tests)
-├── i18n Parity:      10/10 ✅
-├── Build:            10/10 ✅
-├── Dist Verify:      10/10 ✅
-├── Frontend Safety:   9/10 ✅
-└── Coverage:          7/10 ⚠️  (75% vs 80% target)
-```
-
-**Scoring Rules:**
-| Component | Max | How to Score |
-|-----------|-----|-------------|
-| Secret Scan | 10 | 10 = clean, 0 = any secret found |
-| Syntax | 10 | 10 = no errors, 0 = parse fails |
-| Tests | 15 | 15 = all pass, −2 per failure, −1 per skip |
-| i18n | 10 | 10 = parity, −5 per mismatch |
-| Build | 15 | 15 = clean build, 0 = build fails |
-| Dist Verify | 10 | 10 = all files present, −2 per missing |
-| Frontend Safety | 15 | 15 = all layers pass, −3 per failure |
-| Coverage | 15 | 15 = ≥80%, scale down linearly |
-
-**Thresholds:**
-- **≥80** → ✅ **PASS** — safe to deploy
-- **60-79** → ⚠️ **WARN** — deploy with caution, document risks
-- **<60** → ❌ **FAIL** — fix before deploy
+**Then** update `.cm/CONTINUITY.md`:
+- **Active Blockers:** Add the failing gate details
+- **Mistakes & Learnings:** Record what failed with scope tag:
+  - What Failed: [test/gate that failed]
+  - How to Prevent: [fix pattern]
+  - Scope: `module:{failing-module}` or `global` if systemic
+  - Memory-caused: [yes/no — was existing memory the root cause?]
 
----
-
-### Gate 6: Security Scan (Snyk Code) (Added: March 2026)
-
-> Run SAST scan to catch path traversal, XSS, injection, and other vulnerabilities BEFORE deploy.
-
-```bash
-# If snyk CLI installed:
-snyk code test --severity-threshold=high
-
-# Gate decision:
-# 0 HIGH findings → proceed
-# Any HIGH findings → STOP. Fix before deploy.
-# MEDIUM findings → review, add to .snyk if mitigated
-```
-
-**When findings are false positives:**
-1. Verify the mitigation is real (e.g., `safe_resolve()` for path traversal, `esc()` for XSS)
-2. Add to `.snyk` exclude with documentation explaining the mitigation
-3. Never suppress without documenting WHY
-
-**Scoring:**
-| Component | Max | How to Score |
-|-----------|-----|-------------|
-| Security Scan | 10 | 10 = 0 HIGH, −5 per HIGH, −1 per unreviewed MEDIUM |
-
----
-
-### Gate 7: i18n HTML Safety (Added: March 2026)
-
-> Translation JSON files must NOT contain structural HTML markup (icons, links, scripts). Only safe formatting tags (`<strong>`, `<em>`, `<br>`, `<code>`) are acceptable. Structural HTML in translations conflicts with XSS sanitizers.
-
-```bash
-# Check for dangerous HTML in translation files
-grep -rn '<i \|<a \|<script\|<svg\|onclick\|onerror\|href=' public/i18n/**/*.json || true
-
-# Gate decision:
-# 0 matches → proceed
-# Any matches → STOP. Move HTML markup to templates, not translation values.
-```
+> **Token savings:** Next session instantly knows if last run passed or failed
+> without re-running the test suite just to check status.
 
 ---
 

package/skills/cm-reactor/SKILL.md

@@ -0,0 +1,274 @@
+---
+name: cm-reactor
+description: "Strategic codebase re-direction when requirements change, architecture doesn't fit, or tech debt blocks progress. TRIZ-powered pivot protocol for large codebases."
+---
+
+# Reactor — Strategic Codebase Re-direction
+
+> **When the code works but the direction is wrong, you don't debug — you REACT.**
+> TRIZ-powered protocol for pivoting large codebases without losing stability.
+
+## When to Use
+
+**ALWAYS when:**
+- Requirements changed significantly after code was built
+- Architecture no longer fits the problem (wrong patterns, wrong abstractions)
+- 3+ patches on the same area — symptom of structural mismatch
+- Tech debt blocks new feature development
+- "We need to rewrite X" — STOP. Use this skill first.
+- Migrating from one framework/library/pattern to another
+- Post-mortem reveals systemic issues needing strategic change
+
+**Skip when:**
+- Simple bug fix → use `cm-debugging`
+- Routine refactoring (extract method, rename) → use `cm-clean-code`
+- New project from scratch → use `cm-project-bootstrap`
+- Small scope change (< 5 files affected) → just refactor directly
+
+## The Iron Law
+
+```
+NO REWRITE WITHOUT REACTOR ANALYSIS FIRST
+```
+
+Rewrites fail 70% of the time. Incremental strategic migration succeeds 90% of the time.
+
+## TRIZ Principles Applied
+
+| # | Principle | How Applied |
+|---|-----------|-------------|
+| **#35** | Parameter Change | Change the fundamental parameter (language, pattern, architecture) — not the symptom |
+| **#28** | Mechanics Substitution | Replace one mechanism with a more effective one (OOP → FP, REST → GraphQL, etc.) |
+| **#13** | The Other Way Around | Instead of adapting new code to old architecture, adapt old architecture to new requirements |
+| **#25** | Self-Service | Design the migration so each component can migrate independently |
+| **#1** | Segmentation | Break monolithic change into independent migration units |
+| **#10** | Prior Action | Prepare the codebase (interfaces, adapters) BEFORE the actual migration |
+
+## The 5-Phase Process
+
+```
+Phase 1: ASSESS    → Understand what's wrong and why (not just symptoms)
+Phase 2: MAP       → Trace all dependencies and blast radius
+Phase 3: DESIGN    → Plan the migration path with strangler fig pattern
+Phase 4: EXECUTE   → Migrate incrementally, one unit at a time
+Phase 5: VERIFY    → Confirm direction is correct + clean up old code
+```
+
+### Phase 1: ASSESS — Identify the Contradiction
+
+> **Goal:** Find the TRIZ contradiction — what do we WANT vs what BLOCKS us?
+
+1. **State the current direction:**
+   ```
+   Current: We built [X architecture/pattern/structure]
+   Problem: It doesn't support [Y requirement/scale/use case]
+   ```
+
+2. **Identify the contradiction:**
+   ```
+   We WANT: [desired capability]
+   But: [current architecture] prevents it because [technical reason]
+   
+   TRIZ Contradiction:
+   Improving [parameter A] worsens [parameter B]
+   Example: "Improving modularity worsens performance"
+           "Improving flexibility worsens type safety"
+   ```
+
+3. **Define the Ideal Final Result (IFR):**
+   ```
+   The system ITSELF [achieves the goal]
+   WITHOUT [the current blocking factor]
+   WHILE maintaining [what currently works well]
+   ```
+
+4. **Scope assessment:**
+   ```
+   Files affected: [count from codeintell or grep]
+   Components affected: [list]
+   Tests affected: [count]
+   External API changes: [yes/no — breaking change?]
+   Estimated effort: [S/M/L/XL]
+   Risk level: [Low/Medium/High/Critical]
+   ```
+
+### Phase 2: MAP — Dependency Analysis
+
+> **Goal:** Know exactly what touches what before changing anything.
+
+1. **Use Code Intelligence** (if available):
+   ```
+   codegraph_impact("target_symbol", depth=3)
+   → Shows all callers, dependencies, affected files
+   
+   codegraph_context("target_module")
+   → Shows architecture around the area
+   ```
+
+2. **Manual mapping** (if codegraph unavailable):
+   ```
+   grep -rn "import.*{module}" src/
+   grep -rn "{function_name}" src/
+   → Build dependency tree manually
+   ```
+
+3. **Categorize files by migration priority:**
+
+   | Category | Description | Action |
+   |----------|-------------|--------|
+   | **Core** | The files that MUST change for the new direction | Migrate first |
+   | **Dependent** | Files that import/use Core files | Migrate after Core, use adapters |
+   | **Peripheral** | Files loosely connected | Migrate last or leave untouched |
+   | **Dead** | Files no longer needed after migration | Flag for deletion in Phase 5 |
+
+4. **Output: Migration Map Document**
+   ```markdown
+   ## Migration Map: [Initiative Name]
+   
+   ### Core (must change): [N files]
+   - file_a.ts → [what changes]
+   - file_b.ts → [what changes]
+   
+   ### Dependent (affected): [N files]
+   - file_c.ts → [how affected]
+   
+   ### Peripheral (optional): [N files]
+   - file_d.ts → [minimal change]
+   
+   ### Dead (remove after): [N files]
+   - old_module.ts → DELETE after migration complete
+   ```
+
+### Phase 3: DESIGN — Strangler Fig Migration
+
+> **Goal:** Design an incremental migration path — NEVER big-bang rewrite.
+
+**Strangler Fig Pattern (TRIZ #10 Prior Action):**
+```
+1. Create NEW structure alongside OLD structure
+2. Route NEW traffic/calls to NEW structure
+3. Gradually migrate OLD consumers to NEW structure
+4. Remove OLD structure when no longer used
+```
+
+**Migration design template:**
+```markdown
+## Migration Path
+
+### Step 1: Create Adapter Layer
+- [ ] Create interface/abstraction that both old and new code satisfy
+- [ ] All consumers now use the adapter, not direct implementation
+
+### Step 2: Build New Implementation
+- [ ] New code behind the adapter — can be tested independently
+- [ ] Feature flag or config switch between old/new
+
+### Step 3: Gradual Cut-over
+- [ ] Migrate consumers one-by-one to new implementation
+- [ ] Each migration is a separate commit/PR
+- [ ] Tests pass at EVERY step (never break green)
+
+### Step 4: Clean up (→ triggers cm-clean-code)
+- [ ] Remove old implementation
+- [ ] Remove adapter layer (if no longer needed)
+- [ ] Remove feature flag
+- [ ] Update documentation
+```
+
+**Rules:**
+- Never break the build at any step
+- Each step MUST be independently deployable
+- Tests must pass at every intermediate state
+- If any step fails → STOP, don't cascade
+
+### Phase 4: EXECUTE — Incremental Migration
+
+> **Goal:** Execute migration plan step by step with quality gates.
+
+**Use `cm-execution` Mode A (Batch) or Mode E (TRIZ-Parallel):**
+
+```
+For each migration step:
+  1. Write/update tests FIRST (cm-tdd)
+  2. Implement the change
+  3. Run full test suite
+  4. Commit with clear message: "reactor: [step description]"
+  5. If tests fail → STOP, diagnose, fix before next step
+  
+Progress tracking:
+  → Update cm-tasks.json with each completed migration step
+  → Update CONTINUITY.md with migration status
+```
+
+**Commit convention:**
+```
+reactor: create adapter layer for auth module
+reactor: implement new auth service behind adapter
+reactor: migrate login page to new auth
+reactor: migrate signup page to new auth
+reactor: remove old auth implementation
+reactor: cleanup — remove adapter (direct usage now)
+```
+
+### Phase 5: VERIFY & CLEAN
+
+> **Goal:** Confirm the new direction works AND trigger cm-clean-code.
+
+1. **Direction verification:**
+   ```
+   □ New architecture supports the originally blocked requirement
+   □ Performance is equal or better
+   □ All tests pass
+   □ No regression in existing features
+   □ Documentation updated
+   ```
+
+2. **Trigger cm-clean-code:**
+   ```
+   After reactor completes → ALWAYS run cm-clean-code
+   Reason: Migration leaves dead code, unused imports, stale references
+   ```
+
+3. **Record in CONTINUITY.md:**
+   ```
+   Decision: Migrated [X] from [old pattern] to [new pattern]
+   Rationale: [why — the TRIZ contradiction we resolved]
+   Scope: module:[affected module]
+   ```
+
+---
+
+## Red Flags — STOP
+
+| Thought | Reality |
+|---------|---------|
+| "Let's just rewrite everything" | Big-bang rewrites fail 70%+ of the time |
+| "It's faster to start from scratch" | You lose all edge-case handling and bug fixes |
+| "We don't need tests during migration" | Migration without tests = guaranteed regression |
+| "Let's change the direction AND add features" | One thing at a time. Direction first, features after |
+| "This adapter layer is extra work" | Adapter saves you from big-bang. It pays for itself |
+| "We can just search-and-replace" | Structural changes ≠ text changes |
+
+## Integration
+
+| Skill | When |
+|-------|------|
+| `cm-brainstorm-idea` | UPSTREAM: Identifies need for direction change |
+| `cm-codeintell` | Phase 2: Dependency analysis via codegraph |
+| `cm-planning` | Phase 3: Formalize migration plan |
+| `cm-execution` | Phase 4: Execute migration steps |
+| `cm-tdd` | Phase 4: Tests before each migration step |
+| `cm-clean-code` | Phase 5: MANDATORY cleanup after reactor |
+| `cm-debugging` | If migration introduces bugs |
+| `cm-continuity` | Record direction decisions |
+
+### Lifecycle Position
+
+```
+cm-brainstorm-idea → cm-reactor → cm-planning → cm-execution → cm-clean-code
+     (analyze)       (redirect)     (plan)        (build)        (hygiene)
+```
+
+## The Bottom Line
+
+**Don't rewrite. React. Migrate incrementally. Clean up after. Every step must pass tests.**