anchi-kit 1.2.1 → 1.2.2

package/.cursor/skills/debugging/references/root-cause-tracing.md

@@ -1,122 +0,0 @@
-# Root Cause Tracing
-
-Systematically trace bugs backward through call stack to find original trigger.
-
-## Core Principle
-
-**Trace backward through call chain until finding original trigger, then fix at source.**
-
-Bugs often manifest deep in call stack (git init in wrong directory, file created in wrong location). Instinct is to fix where error appears, but that's treating symptom.
-
-## When to Use
-
-**Use when:**
-- Error happens deep in execution (not at entry point)
-- Stack trace shows long call chain
-- Unclear where invalid data originated
-- Need to find which test/code triggers problem
-
-## The Tracing Process
-
-### 1. Observe the Symptom
-```
-Error: git init failed in /Users/jesse/project/packages/core
-```
-
-### 2. Find Immediate Cause
-What code directly causes this?
-```typescript
-await execFileAsync('git', ['init'], { cwd: projectDir });
-```
-
-### 3. Ask: What Called This?
-```typescript
-WorktreeManager.createSessionWorktree(projectDir, sessionId)
-  → called by Session.initializeWorkspace()
-  → called by Session.create()
-  → called by test at Project.create()
-```
-
-### 4. Keep Tracing Up
-What value was passed?
-- `projectDir = ''` (empty string!)
-- Empty string as `cwd` resolves to `process.cwd()`
-- That's the source code directory!
-
-### 5. Find Original Trigger
-Where did empty string come from?
-```typescript
-const context = setupCoreTest(); // Returns { tempDir: '' }
-Project.create('name', context.tempDir); // Accessed before beforeEach!
-```
-
-## Adding Stack Traces
-
-When can't trace manually, add instrumentation:
-
-```typescript
-async function gitInit(directory: string) {
-  const stack = new Error().stack;
-  console.error('DEBUG git init:', {
-    directory,
-    cwd: process.cwd(),
-    stack,
-  });
-
-  await execFileAsync('git', ['init'], { cwd: directory });
-}
-```
-
-**Critical:** Use `console.error()` in tests (not logger - may not show)
-
-**Run and capture:**
-```bash
-npm test 2>&1 | grep 'DEBUG git init'
-```
-
-**Analyze stack traces:**
-- Look for test file names
-- Find line number triggering call
-- Identify pattern (same test? same parameter?)
-
-## Finding Which Test Causes Pollution
-
-If something appears during tests but don't know which test:
-
-Use bisection script: `scripts/find-polluter.sh`
-
-```bash
-./scripts/find-polluter.sh '.git' 'src/**/*.test.ts'
-```
-
-Runs tests one-by-one, stops at first polluter.
-
-## Key Principle
-
-**NEVER fix just where error appears.** Trace back to find original trigger.
-
-When found immediate cause:
-- Can trace one level up? → Trace backwards
-- Is this the source? → Fix at source
-- Then add validation at each layer (see defense-in-depth.md)
-
-## Real Example
-
-**Symptom:** `.git` created in `packages/core/` (source code)
-
-**Trace chain:**
-1. `git init` runs in `process.cwd()` ← empty cwd parameter
-2. WorktreeManager called with empty projectDir
-3. Session.create() passed empty string
-4. Test accessed `context.tempDir` before beforeEach
-5. setupCoreTest() returns `{ tempDir: '' }` initially
-
-**Root cause:** Top-level variable initialization accessing empty value
-
-**Fix:** Made tempDir a getter that throws if accessed before beforeEach
-
-**Also added defense-in-depth:**
-- Layer 1: Project.create() validates directory
-- Layer 2: WorkspaceManager validates not empty
-- Layer 3: NODE_ENV guard refuses git init outside tmpdir
-- Layer 4: Stack trace logging before git init

package/.cursor/skills/debugging/references/systematic-debugging.md

@@ -1,102 +0,0 @@
-# Systematic Debugging
-
-Four-phase debugging framework that ensures root cause investigation before attempting fixes.
-
-## The Iron Law
-
-```
-NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
-```
-
-If haven't completed Phase 1, cannot propose fixes.
-
-## The Four Phases
-
-Must complete each phase before proceeding to next.
-
-### Phase 1: Root Cause Investigation
-
-**BEFORE attempting ANY fix:**
-
-1. **Read Error Messages Carefully** - Don't skip past errors/warnings, read stack traces completely
-2. **Reproduce Consistently** - Can trigger reliably? Exact steps? If not reproducible → gather more data
-3. **Check Recent Changes** - What changed? Git diff, recent commits, new dependencies, config changes
-4. **Gather Evidence in Multi-Component Systems**
-   - For EACH component boundary: log data entering/exiting, verify environment propagation
-   - Run once to gather evidence showing WHERE it breaks
-   - THEN analyze to identify failing component
-5. **Trace Data Flow** - Where does bad value originate? Trace up call stack until finding source (see root-cause-tracing.md)
-
-### Phase 2: Pattern Analysis
-
-**Find pattern before fixing:**
-
-1. **Find Working Examples** - Locate similar working code in same codebase
-2. **Compare Against References** - Read reference implementation COMPLETELY, understand fully before applying
-3. **Identify Differences** - List every difference however small, don't assume "that can't matter"
-4. **Understand Dependencies** - What other components, settings, config, environment needed?
-
-### Phase 3: Hypothesis and Testing
-
-**Scientific method:**
-
-1. **Form Single Hypothesis** - "I think X is root cause because Y", be specific not vague
-2. **Test Minimally** - SMALLEST possible change to test hypothesis, one variable at a time
-3. **Verify Before Continuing** - Worked? → Phase 4. Didn't work? → NEW hypothesis. DON'T add more fixes
-4. **When Don't Know** - Say "I don't understand X", don't pretend, ask for help
-
-### Phase 4: Implementation
-
-**Fix root cause, not symptom:**
-
-1. **Create Failing Test Case** - Simplest reproduction, automated if possible, MUST have before fixing
-2. **Implement Single Fix** - Address root cause identified, ONE change, no "while I'm here" improvements
-3. **Verify Fix** - Test passes? No other tests broken? Issue actually resolved?
-4. **If Fix Doesn't Work**
-   - STOP. Count: How many fixes tried?
-   - If < 3: Return to Phase 1, re-analyze with new information
-   - **If ≥ 3: STOP and question architecture**
-5. **If 3+ Fixes Failed: Question Architecture**
-   - Pattern: Each fix reveals new shared state/coupling problem elsewhere
-   - STOP and question fundamentals: Is pattern sound? Wrong architecture?
-   - Discuss with human partner before more fixes
-
-## Red Flags - STOP and Follow Process
-
-If catch yourself thinking:
-- "Quick fix for now, investigate later"
-- "Just try changing X and see if it works"
-- "Add multiple changes, run tests"
-- "Skip the test, I'll manually verify"
-- "It's probably X, let me fix that"
-- "I don't fully understand but this might work"
-- "One more fix attempt" (when already tried 2+)
-
-**ALL mean:** STOP. Return to Phase 1.
-
-## Human Partner Signals You're Doing It Wrong
-
-- "Is that not happening?" - Assumed without verifying
-- "Will it show us...?" - Should have added evidence gathering
-- "Stop guessing" - Proposing fixes without understanding
-- "Ultrathink this" - Question fundamentals, not just symptoms
-- "We're stuck?" (frustrated) - Approach isn't working
-
-**When see these:** STOP. Return to Phase 1.
-
-## Common Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Issue is simple, don't need process" | Simple issues have root causes too |
-| "Emergency, no time for process" | Systematic is FASTER than guess-and-check |
-| "Just try this first, then investigate" | First fix sets pattern. Do right from start |
-| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem |
-
-## Real-World Impact
-
-From debugging sessions:
-- Systematic approach: 15-30 minutes to fix
-- Random fixes approach: 2-3 hours of thrashing
-- First-time fix rate: 95% vs 40%
-- New bugs introduced: Near zero vs common

package/.cursor/skills/debugging/references/verification.md

@@ -1,123 +0,0 @@
-# Verification Before Completion
-
-Run verification commands and confirm output before claiming success.
-
-## Core Principle
-
-**Evidence before claims, always.**
-
-Claiming work complete without verification is dishonesty, not efficiency.
-
-## The Iron Law
-
-```
-NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
-```
-
-If haven't run verification command in this message, cannot claim it passes.
-
-## The Gate Function
-
-```
-BEFORE claiming any status or expressing satisfaction:
-
-1. IDENTIFY: What command proves this claim?
-2. RUN: Execute FULL command (fresh, complete)
-3. READ: Full output, check exit code, count failures
-4. VERIFY: Does output confirm claim?
-   - If NO: State actual status with evidence
-   - If YES: State claim WITH evidence
-5. ONLY THEN: Make claim
-
-Skip any step = lying, not verifying
-```
-
-## Common Failures
-
-| Claim | Requires | Not Sufficient |
-|-------|----------|----------------|
-| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
-| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
-| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
-| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
-| Regression test works | Red-green cycle verified | Test passes once |
-| Agent completed | VCS diff shows changes | Agent reports "success" |
-| Requirements met | Line-by-line checklist | Tests passing |
-
-## Red Flags - STOP
-
-- Using "should", "probably", "seems to"
-- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!")
-- About to commit/push/PR without verification
-- Trusting agent success reports
-- Relying on partial verification
-- Thinking "just this once"
-- Tired and wanting work over
-- **ANY wording implying success without having run verification**
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "Should work now" | RUN verification |
-| "I'm confident" | Confidence ≠ evidence |
-| "Just this once" | No exceptions |
-| "Linter passed" | Linter ≠ compiler |
-| "Agent said success" | Verify independently |
-| "Partial check is enough" | Partial proves nothing |
-
-## Key Patterns
-
-**Tests:**
-```
-✅ [Run test command] [See: 34/34 pass] "All tests pass"
-❌ "Should pass now" / "Looks correct"
-```
-
-**Regression tests (TDD Red-Green):**
-```
-✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
-❌ "I've written regression test" (without red-green verification)
-```
-
-**Build:**
-```
-✅ [Run build] [See: exit 0] "Build passes"
-❌ "Linter passed" (linter doesn't check compilation)
-```
-
-**Requirements:**
-```
-✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
-❌ "Tests pass, phase complete"
-```
-
-**Agent delegation:**
-```
-✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
-❌ Trust agent report
-```
-
-## When To Apply
-
-**ALWAYS before:**
-- ANY variation of success/completion claims
-- ANY expression of satisfaction
-- ANY positive statement about work state
-- Committing, PR creation, task completion
-- Moving to next task
-- Delegating to agents
-
-**Rule applies to:**
-- Exact phrases
-- Paraphrases and synonyms
-- Implications of success
-- ANY communication suggesting completion/correctness
-
-## The Bottom Line
-
-**No shortcuts for verification.**
-
-Run command. Read output. THEN claim result.
-
-Non-negotiable.

package/.cursor/skills/debugging/scripts/find-polluter.sh

@@ -1,63 +0,0 @@
-#!/bin/bash
-# Bisection script to find which test creates unwanted files/state
-# Usage: ./find-polluter.sh <file_or_dir_to_check> <test_pattern>
-# Example: ./find-polluter.sh '.git' 'src/**/*.test.ts'
-
-set -e
-
-if [ $# -ne 2 ]; then
-  echo "Usage: $0 <file_to_check> <test_pattern>"
-  echo "Example: $0 '.git' 'src/**/*.test.ts'"
-  exit 1
-fi
-
-POLLUTION_CHECK="$1"
-TEST_PATTERN="$2"
-
-echo "🔍 Searching for test that creates: $POLLUTION_CHECK"
-echo "Test pattern: $TEST_PATTERN"
-echo ""
-
-# Get list of test files
-TEST_FILES=$(find . -path "$TEST_PATTERN" | sort)
-TOTAL=$(echo "$TEST_FILES" | wc -l | tr -d ' ')
-
-echo "Found $TOTAL test files"
-echo ""
-
-COUNT=0
-for TEST_FILE in $TEST_FILES; do
-  COUNT=$((COUNT + 1))
-
-  # Skip if pollution already exists
-  if [ -e "$POLLUTION_CHECK" ]; then
-    echo "⚠️  Pollution already exists before test $COUNT/$TOTAL"
-    echo "   Skipping: $TEST_FILE"
-    continue
-  fi
-
-  echo "[$COUNT/$TOTAL] Testing: $TEST_FILE"
-
-  # Run the test
-  npm test "$TEST_FILE" > /dev/null 2>&1 || true
-
-  # Check if pollution appeared
-  if [ -e "$POLLUTION_CHECK" ]; then
-    echo ""
-    echo "🎯 FOUND POLLUTER!"
-    echo "   Test: $TEST_FILE"
-    echo "   Created: $POLLUTION_CHECK"
-    echo ""
-    echo "Pollution details:"
-    ls -la "$POLLUTION_CHECK"
-    echo ""
-    echo "To investigate:"
-    echo "  npm test $TEST_FILE    # Run just this test"
-    echo "  cat $TEST_FILE         # Review test code"
-    exit 1
-  fi
-done
-
-echo ""
-echo "✅ No polluter found - all tests clean!"
-exit 0

package/.cursor/skills/debugging/scripts/find-polluter.test.md

@@ -1,102 +0,0 @@
-# find-polluter.sh Test Documentation
-
-## Purpose
-Bisection script to find which test creates unwanted files or state pollution.
-
-## Manual Test Procedure
-
-### Setup Test Scenario
-```bash
-# Create test directory
-mkdir -p /tmp/polluter-test && cd /tmp/polluter-test
-
-# Create clean test
-cat > test1.test.js << 'EOF'
-console.log('Test 1: clean');
-EOF
-
-# Create polluter test
-cat > test2.test.js << 'EOF'
-const fs = require('fs');
-fs.mkdirSync('.git', { recursive: true });
-console.log('Test 2: creates pollution');
-EOF
-
-# Create another clean test
-cat > test3.test.js << 'EOF'
-console.log('Test 3: clean');
-EOF
-```
-
-### Run Script
-```bash
-# For projects with npm test
-/path/to/find-polluter.sh '.git' 'src/**/*.test.ts'
-
-# For node-only tests (modify script to use 'node' instead of 'npm test')
-./find-polluter.sh '.git' '*.test.js'
-```
-
-### Expected Output
-```
-🔍 Searching for test that creates: .git
-Test pattern: *.test.js
-
-Found 3 test files
-
-[1/3] Testing: ./test1.test.js
-[2/3] Testing: ./test2.test.js
-
-🎯 FOUND POLLUTER!
-   Test: ./test2.test.js
-   Created: .git
-```
-
-### Cleanup
-```bash
-rm -rf /tmp/polluter-test
-```
-
-## Test Results
-
-✅ Script logic verified (2025-11-11)
-- Correctly iterates through test files
-- Detects pollution creation
-- Reports the polluting test file
-- Exits early when polluter found
-
-## Usage Notes
-
-**Prerequisites:**
-- Test runner (npm test) must be configured in project
-- Test pattern must match actual test files
-- Pollution path must be accurate
-
-**Customization:**
-If your project doesn't use `npm test`, modify line 42:
-```bash
-# Replace
-npm test "$TEST_FILE" > /dev/null 2>&1 || true
-
-# With your test command
-node "$TEST_FILE" > /dev/null 2>&1 || true
-# Or
-jest "$TEST_FILE" > /dev/null 2>&1 || true
-```
-
-## Common Use Cases
-
-1. **Find test creating .git directory:**
-   ```bash
-   ./find-polluter.sh '.git' 'src/**/*.test.ts'
-   ```
-
-2. **Find test creating node_modules:**
-   ```bash
-   ./find-polluter.sh 'node_modules' 'test/**/*.spec.js'
-   ```
-
-3. **Find test creating specific file:**
-   ```bash
-   ./find-polluter.sh 'unwanted-file.txt' '**/*.test.js'
-   ```

package/.cursor/skills/devops/.env.example

@@ -1,76 +0,0 @@
-# DevOps Skill - Environment Variables
-
-# =============================================================================
-# Cloudflare Configuration
-# =============================================================================
-# Get these from: https://dash.cloudflare.com
-# API Token: Profile -> API Tokens -> Create Token
-# Account ID: Overview -> Account ID (right sidebar)
-
-CLOUDFLARE_API_TOKEN=your_cloudflare_api_token_here
-CLOUDFLARE_ACCOUNT_ID=your_cloudflare_account_id_here
-
-# Optional: Specific zone configuration
-# CLOUDFLARE_ZONE_ID=your_zone_id_here
-
-# =============================================================================
-# Google Cloud Configuration
-# =============================================================================
-# Authentication via service account key file or gcloud CLI
-# Download from: IAM & Admin -> Service Accounts -> Create Key
-
-# Option 1: Service account key file path
-GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account-key.json
-
-# Option 2: Project configuration
-# GCP_PROJECT_ID=your-project-id
-# GCP_REGION=us-central1
-# GCP_ZONE=us-central1-a
-
-# =============================================================================
-# Docker Configuration
-# =============================================================================
-# Optional: Docker registry authentication
-
-# Docker Hub
-# DOCKER_USERNAME=your_docker_username
-# DOCKER_PASSWORD=your_docker_password
-
-# Google Container Registry (GCR)
-# GCR_HOSTNAME=gcr.io
-# GCR_PROJECT_ID=your-project-id
-
-# AWS ECR
-# AWS_ACCOUNT_ID=123456789012
-# AWS_REGION=us-east-1
-
-# =============================================================================
-# CI/CD Configuration
-# =============================================================================
-# Optional: For automated deployments
-
-# GitHub Actions
-# GITHUB_TOKEN=your_github_token
-
-# GitLab CI
-# GITLAB_TOKEN=your_gitlab_token
-
-# =============================================================================
-# Monitoring & Logging
-# =============================================================================
-# Optional: For observability
-
-# Sentry
-# SENTRY_DSN=your_sentry_dsn
-
-# Datadog
-# DD_API_KEY=your_datadog_api_key
-
-# =============================================================================
-# Notes
-# =============================================================================
-# 1. Copy this file to .env and fill in your actual values
-# 2. Never commit .env file to version control
-# 3. Use different credentials for dev/staging/production
-# 4. Rotate credentials regularly
-# 5. Use least-privilege principle for API tokens