universal-agent-memory 3.1.0 → 4.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "universal-agent-memory",
-  "version": "3.1.0",
+  "version": "4.1.0",
   "description": "Universal AI agent memory system - CLAUDE.md templates, memory, worktrees for Claude Code, Factory.AI, VSCode, OpenCode",
   "type": "module",
   "main": "dist/index.js",

package/templates/CLAUDE.template.md

@@ -1,5 +1,5 @@
 <!--
-  CLAUDE.md Universal Template - v10.19-opt
+  CLAUDE.md Universal Template - v11.0-slim
 
   Core Variables:
     {{PROJECT_NAME}}, {{DESCRIPTION}}, {{DEFAULT_BRANCH}}, {{STRUCTURE_DATE}}
@@ -44,42 +44,13 @@
 
 ---
 
-## CODE FIELD - COGNITIVE ENVIRONMENT
+## CODE PRINCIPLES
 
-**Apply to ALL code generation. Creates conditions where better code emerges naturally.**
-
-### Core Inhibitions
-
-```
-Do not write code before stating assumptions.
-Do not claim correctness you haven't verified.
-Do not handle only the happy path.
-Under what conditions does this work?
-```
-
-### Before Writing Code
-
-- What are you assuming about the input?
-- What are you assuming about the environment?
-- What would break this?
-- What would a malicious caller do?
-
-### Do Not
-
-- Write code before stating assumptions
-- Claim correctness you haven't verified
-- Handle the happy path and gesture at the rest
-- Import complexity you don't need
-- Solve problems you weren't asked to solve
-- Produce code you wouldn't want to debug at 3am
-
-### Expected Output Format
-
-**Before code**: Assumptions stated explicitly, scope bounded
-**In code**: Smaller than expected, edge cases handled or explicitly rejected
-**After code**: "What this handles" and "What this does NOT handle" sections
-
-*Attribution: Based on [context-field research](https://github.com/NeoVertex1/context-field)*
+- State assumptions before writing code
+- Verify correctness -- do not claim it
+- Handle error paths, not just the happy path
+- Do not import complexity you do not need
+- Produce code you would want to debug at 3am
 
 ---
 
@@ -98,8 +69,6 @@ Under what conditions does this work?
 | kubectl with secrets | `ops-approved-operations.yml` |
 | One-time secret operation | `ops-create-ephemeral.yml` (self-destructs after run) |
 
-**Local commands without secrets** (read-only, public resources) are allowed for testing.
-
 ### Two-Phase Infrastructure Workflow
 
 ```
@@ -107,7 +76,6 @@ PHASE 1: LOCAL PROOF (ALLOWED - NO SECRETS)
   - kubectl get/describe/logs (read-only operations)
   - terraform plan (uses GitHub pipeline for secrets)
   - Direct cloud console changes for rapid prototyping
-  - Manual commands to verify behavior (public resources)
   - SECRETS REQUIRED? -> Use pipeline, not local commands
 
 PHASE 2: IaC PARITY (MANDATORY - VIA PIPELINE)
@@ -119,639 +87,107 @@ PHASE 2: IaC PARITY (MANDATORY - VIA PIPELINE)
   - RULE: Work is NOT complete until IaC matches live state
 ```
 
-### Core Principle
-
-```
-Local testing proves the solution. IaC ensures reproducibility.
-Manual changes are TEMPORARY. IaC changes are PERMANENT.
-If it's not in IaC, it doesn't exist (will be destroyed/lost).
-Secrets live in GitHub - use pipelines for secret-dependent operations.
-```
-
 ### Approved Pipelines
 
-| Task | Pipeline | Trigger | Notes |
-|------|----------|---------|-------|
-| Kubernetes operations | `ops-approved-operations.yml` | Manual dispatch | Has cluster secrets |
-| Ephemeral environments | `ops-create-ephemeral.yml` | Manual dispatch | Self-destructs after run |
-| Terraform changes | `iac-terraform-cicd.yml` | PR to {{DEFAULT_BRANCH}} | Has TF secrets |
-| Ephemeral Terraform | `ops-ephemeral-terraform.yml` | Manual dispatch | One-time TF operations |
-
-### What This Means for Agents
-
-**PHASE 1 - Local Testing (ALLOWED for non-secret operations):**
-- Run read-only commands: `kubectl get`, `kubectl describe`, `kubectl logs`
-- Run `terraform plan` via pipeline (needs secrets)
-- Make cloud console changes to prototype
-- Use ephemeral pipelines for secret-dependent testing
-
-**PHASE 2 - IaC Parity (MANDATORY - always via pipeline):**
-- ALL manual changes MUST be translated to IaC (Terraform/K8s YAML)
-- IaC MUST be committed to version control
-- Deployment MUST go through CI/CD pipeline (has secrets)
-- Final state MUST match IaC exactly (verify with diff)
-- Manual/ephemeral resources MUST be cleaned up
-
-**NEVER:**
-- Run `terraform apply` locally (no secrets available)
-- Run `kubectl apply` with secret-dependent resources locally
-- Create secrets via `kubectl create secret` (use Sealed Secrets)
-- Hardcode or expose secrets in code/logs
+| Task | Pipeline | Trigger |
+|------|----------|---------|
+| Kubernetes operations | `ops-approved-operations.yml` | Manual dispatch |
+| Ephemeral environments | `ops-create-ephemeral.yml` | Manual dispatch |
+| Terraform changes | `iac-terraform-cicd.yml` | PR to {{DEFAULT_BRANCH}} |
+| Ephemeral Terraform | `ops-ephemeral-terraform.yml` | Manual dispatch |
 {{/if}}
 
 ---
 
-## UNIVERSAL AGENT PATTERNS
-
-**Forty-two patterns proven to improve LLM agent reliability. Apply to ALL task execution.**
-
-### Pattern 1: Environment Isolation
-Code installed during execution may NOT persist across phases (agent -> test -> deploy).
-- Check what dependencies are pre-installed before using them
-- Prefer pre-installed tools over installing new ones
-- Design for minimal dependency footprint
-
-### Pattern 2: Recipe Following
-LLMs excel at explicit step-by-step instructions but struggle with ambiguous tasks.
-- Convert complex tasks into numbered sequential commands
-- Each step should be atomic and verifiable
-- Provide exact commands, not descriptions
-
-### Pattern 3: Pre-execution State Protection
-LLMs do NOT reliably follow negative instructions ("do not delete X").
-- Backup critical files BEFORE starting work
-- Never rely on "do not" for critical constraints
-- Protect state proactively, not reactively
+## SESSION START
 
 ```bash
-cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
-sqlite3 db.sqlite ".backup /tmp/db_backup.sqlite"
+uam task ready
+sqlite3 ./{{MEMORY_DB_PATH}} "SELECT * FROM memories ORDER BY id DESC LIMIT 10;"
+sqlite3 ./{{MEMORY_DB_PATH}} "SELECT * FROM session_memories WHERE session_id='current' ORDER BY id DESC LIMIT 5;"
+uam agent status
 ```
 
-### Pattern 4: Tool Specification
-Agents succeed more when told WHICH tool to use, not just WHAT to accomplish.
-- Specify exact tool and flags when possible
-- Reduce search space of possible approaches
-
-### Pattern 5: Recognizing Impossible Tasks
-Some tasks require pre-computed solutions (compressed algorithms, lookup tables, trained models).
-- Identify tasks requiring: compression below limits, pre-trained weights, exhaustive search
-- These cannot be solved by reasoning alone
-- Detect early to avoid wasted computation
-
-### Pattern 6: Hierarchical Prompting (Recency Bias)
-LLMs weight information at the END of context more heavily.
-- Structure: capabilities -> context -> CRITICAL instructions
-- Put most important constraints at the END
-- Repeat critical instructions if essential
-
-### Pattern 7: Task Classification
-Different task types require different strategies. See also P40 (Adaptive Reasoning Depth).
-
-| Category | Strategy |
-|----------|----------|
-| State-sensitive | Pre-backup critical files |
-| Recipe-following | Step-by-step commands |
-| Tool-dependent | Specify exact tool + flags |
-| Research/exploration | Parallel searches |
-| Complex/ambiguous | P38 Branching Exploration |
-| Multi-file change | P41 Atomic Task Loop |
-
-### Pattern 8: CLI over Libraries
-When environment dependencies are uncertain, prefer subprocess + CLI over library imports.
-- CLI tools more likely pre-installed
-- Better backward compatibility
-- Easier to verify: `which tool`
-
-### Pattern 9: Format Translation Pipeline
-When task involves non-text data (images, audio, video, binary), convert to standard format first.
-- Identify input format and required output
-- Find converter tool: image->text, audio->transcript, binary->structured
-- Convert to standard intermediate format (FEN, JSON, CSV, etc.)
-
-### Pattern 10: Whitelist-First Sanitization
-For security filtering (XSS, SQL injection, command injection), ALWAYS use allow-list approach.
-- NEVER use blacklist/regex to filter malicious patterns
-- Use established security libraries (bleach, DOMPurify, parameterized queries)
-
-### Pattern 11: Pre-Computed Solution Recognition
-Some tasks have known solutions that cannot be derived through reasoning alone.
-- Recognize tasks matching known solved problems (chess engines, crypto tables, ML models)
-- Search GitHub/papers FIRST before attempting to solve
-- Download and adapt existing solutions rather than reinventing
-
-### Pattern 12: Output Existence Verification (OEV)
-**CRITICAL: 37% of task failures are "output file not created"**
-
-BEFORE completing ANY task:
-1. **Parse expected outputs** from task description (files, paths, artifacts)
-2. **Verify each output EXISTS**: `ls -la /expected/path`
-3. **If missing: CREATE IT** - don't explain, don't ask, just create
-4. **Re-verify** before reporting completion
-
-### Pattern 13: Iterative Refinement Loop (IRL)
-When tests are available and some pass but others fail:
-1. Run tests after implementation
-2. If partial success: read failing test, fix specific issue, re-run
-3. Repeat until 100% pass OR timeout approaching
-4. Reserve 20% of time budget for iteration
-
-### Pattern 14: Output Format Validation (OFV)
-When task specifies exact output format:
-1. Extract format requirements from task description
-2. Validate output matches spec before completion
-3. If validation fails: fix output, don't re-explain
-
-### Pattern 15: Exception Recovery (ER)
-When code throws exceptions:
-1. Read the stack trace
-2. Fix the specific error (ImportError -> install/use stdlib, FileNotFoundError -> create file)
-3. Re-run and verify
-4. Don't give up after first exception
-
-### Pattern 16: Task-First Execution (TFE)
-**CRITICAL: Prevents regression where agent analyzes but forgets to create outputs**
-
-BEFORE any analysis or exploration:
-1. **Parse task for REQUIRED OUTPUTS** (files, artifacts, states)
-2. **Create MINIMAL WORKING versions immediately** (touch files, create stubs)
-3. **THEN refine to full implementation**
-4. **Never finish a turn without outputs existing**
-
-### Pattern 17: Constraint Extraction (CE)
-Agent misses specific constraints buried in task descriptions.
-
-BEFORE implementing:
-1. **Parse for constraint keywords**: "exactly", "only", "single", "must be", "no more than"
-2. **Extract format constraints**: file types, line counts, size limits, response formats
-3. **Create constraint checklist**
-4. **Validate EACH constraint before completion**
-
-### Pattern 18: Multi-Tool Pipeline (MTP)
-Complex tasks need multiple tools chained together.
-
-1. **Decompose task into stages** (input -> transform -> output)
-2. **Identify tool for EACH stage** (don't implement from scratch if tool exists)
-3. **Verify tools available**: `which tool || pip install package`
-4. **Chain in pipeline**
-
-### Pattern 19: Enhanced Impossible Task Refusal (ITR+)
-Pattern 5 identifies impossible tasks but agent still attempts them.
-
-**Impossibility markers -> REFUSE IMMEDIATELY:**
-- Compression below Shannon limit (e.g., "GPT-2 in 5KB" - weights are 500MB+)
-- Pre-trained weights required but none provided
-- Exhaustive search in exponential space
-- Undecidable problems
-
-### Pattern 20: Adversarial Thinking (AT)
-Security bypass/attack tasks require "attacker mindset".
-
-1. **Detect**: Keywords "bypass", "break", "exploit", "circumvent", "evade"
-2. **Flip perspective**: Not "how to use correctly" but "how to break it"
-3. **Enumerate attack vectors** (case variation, encoding, null bytes, context breaking)
-4. **Test each vector until one works**
-
----
-
-## DOMAIN-SPECIFIC PATTERNS
-
-**Task-specific guidance for common failure categories.**
-
-### Pattern 21: Chess Engine Integration (CEI)
-Chess tasks require external engines - reasoning alone cannot find optimal moves.
-
-**Detection**: Keywords "chess", "best move", "FEN", "PGN", "checkmate"
-
-**Protocol**:
-1. Check for Stockfish: `which stockfish || apt-get install -y stockfish`
-2. Parse board state to FEN format
-3. Use Stockfish for analysis
-4. Extract best move from engine output
-
-**NEVER**: Try to calculate chess moves through reasoning - use the engine.
-
-### Pattern 22: Git Recovery Forensics (GRF)
-Git recovery tasks require forensic approach, not standard git commands.
-
-**Detection**: Keywords "recover", "corrupted", "lost commit", "fix git", "reflog"
-
-**Protocol**:
-1. **BACKUP FIRST**: `cp -r .git .git.bak`
-2. Check integrity: `git fsck --full --no-dangling`
-3. Check reflog: `git reflog` (commits survive even after reset)
-4. Check loose objects: `find .git/objects -type f`
-5. Recover from pack files if needed
-
-**NEVER**: Run destructive commands without backup. Use `--dry-run` first.
-
-### Pattern 23: Compression Impossibility Detection (CID)
-Some compression tasks are mathematically impossible.
-
-**Detection**: Keywords "compress", "codegolf", "under X bytes", "minimal size"
-
-**Impossibility Markers**:
-- ML model weights (GPT-2 = 500MB+, cannot be <1MB without losing function)
-- Random/encrypted data (incompressible by definition)
-- Asking for compression ratio beyond information-theoretic limits
-
-**NEVER**: Attempt to compress ML weights to <1% of original size.
-
-### Pattern 24: Polyglot Code Construction (PCC)
-Polyglot tasks require specific compiler/interpreter quirks.
-
-**Detection**: Keywords "polyglot", "works in both", "compile as X and Y"
-
-**Protocol**: Search for existing polyglot examples before implementing.
-
-### Pattern 25: Service Configuration Pipeline (SCP)
-Multi-service configuration requires ordered setup.
-
-**Detection**: Keywords "configure", "server", "webserver", "service", "daemon"
-
-**Protocol**:
-1. **Identify all services** needed
-2. **Check service status**: `systemctl status <service>`
-3. **Configure in dependency order** (base -> dependent)
-4. **Test each service** before moving to next
-5. **Verify end-to-end** after all configured
-
-### Pattern 26: Near-Miss Iteration (NMI)
-When tests show >50% passing, focus on specific failing tests.
-
-**Detection**: Test results show partial success (e.g., 8/9, 6/7, 5/6)
-
-**Protocol**:
-1. Run tests with verbose output
-2. Extract ONLY failing test names
-3. Read failing test code to understand exact requirement
-4. Fix specific issue without breaking passing tests
-5. Re-run ONLY failing tests first
-6. Then run full suite to verify no regressions
-
-**Reserve 30% of time budget for near-miss iteration.**
-
-### Pattern 27: Output Directory Cleanup (ODC)
-Tests often check for ONLY specific files in output directories.
-
-**Detection**: Tasks mentioning "single file", "only", constraints on output directory contents
-
-**Protocol**:
-1. **Before completing**, list output directory
-2. **Remove non-required files**: compiled binaries, temp files, backups
-3. **Keep ONLY the required outputs** as specified in task
-
-### Pattern 28: Service Smoke Test (SST)
-Services must be tested BEFORE claiming completion.
-
-**Detection**: Tasks involving servers, daemons, APIs, web services
-
-**Protocol**:
-1. Start the service
-2. **Immediately test it** with curl/wget/client
-3. If test fails: debug, fix, restart, re-test
-4. Only complete when test PASSES
-
-**NEVER complete without a successful smoke test.**
-
-### Pattern 29: Multi-Solution Discovery (MSD)
-Some tasks require finding ALL valid solutions, not just one.
-
-**Detection**: Keywords "all moves", "both solutions", "list all", "find every"
-
-### Pattern 30: Performance Threshold Tuning (PTT)
-Tasks with numeric thresholds require iterative tuning.
-
-**Detection**: Keywords "win rate", "accuracy", "percentage", "threshold", "at least X%"
-
-### Pattern 31: Round-Trip Verification (RTV)
-For transform/encode/compress tasks, verify the reverse operation.
-
-**Detection**: Keywords "compress", "encode", "serialize", "encrypt", and task mentions reverse operation.
-
-**Protocol**:
-1. Create test data
-2. Apply forward transform (compress)
-3. **Immediately apply reverse** (decompress)
-4. **Verify original == result**
-5. Fix if not matching
-
-### Pattern 32: CLI Execution Verification (CEV)
-When creating executable CLI tools, verify execution method matches tests.
-
-**Detection**: Tasks requiring executable scripts, CLI tools, command-line interfaces
-
-**Protocol**:
-1. Add proper shebang: `#!/usr/bin/env python3`
-2. Make executable: `chmod +x <script>`
-3. **Test EXACTLY as verifier will run it**: `./tool args` not `python3 tool args`
-4. Verify output format matches expected format
-
-**Common mistake**: Script works with `python3 script.py` but fails with `./script.py` (missing shebang/chmod)
-
-### Pattern 33: Numerical Stability Testing (NST)
-Numerical algorithms require robustness against edge cases.
-
-**Detection**: Statistical sampling, numerical optimization, floating-point computation
-
-**Protocol**:
-1. Test with multiple random seeds (3+ iterations, not just one)
-2. Test domain boundaries explicitly (0, near-zero, infinity)
-3. Use adaptive step sizes for derivative computation
-4. Add tolerance margins for floating-point comparisons (1e-6 typical)
-5. Handle edge cases: empty input, single element, maximum values
-
-### Pattern 34: Image-to-Structured Pipeline (ISP)
-Visual data requires dedicated recognition tools, not reasoning.
-
-**Detection**: Tasks involving image analysis, diagram parsing, visual data extraction
-
-**Protocol**:
-1. **NEVER rely on visual reasoning alone** - accuracy is unreliable
-2. Search for existing recognition libraries
-3. Verify extracted structured data before using
-4. If no tools available, clearly state the limitation
-
-### Pattern 35: Decoder-First Analysis (DFA)
-For encode/compress tasks with provided decoder, analyze decoder FIRST.
-
-**Detection**: Task provides a decoder/decompressor and asks to create encoder/compressor
-
-**Protocol**:
-1. **Read and understand the provided decoder** before writing encoder
-2. Identify expected input format from decoder source
-3. Create minimal test case matching decoder's expected format
-4. Test round-trip with decoder BEFORE optimizing for size
-5. If decoder crashes, your format is wrong - don't optimize further
-
-### Pattern 36: Competition Domain Research (CDR)
-Competitive tasks benefit from researching domain-specific winning strategies.
-
-**Detection**: Keywords "win rate", "beat", "competition", "versus", "tournament"
-
-**Protocol**:
-1. **Research domain strategies BEFORE implementing**
-2. Time-box implementation iterations: stop at 70% time budget
-3. Track progress per iteration to identify improvement trajectory
-4. If not meeting threshold, document best achieved + gap
+**On work request**: `uam task create --title "..." --type task|bug|feature`
 
 ---
 
-## ADVANCED REASONING PATTERNS
-
-**Six patterns derived from state-of-the-art LLM optimization research (2025-2026). Address reasoning depth, self-verification, branching exploration, feedback grounding, and task atomization.**
-
-### Pattern 37: Pre-Implementation Verification (PIV)
-**CRITICAL: Prevents wrong-approach waste — the #1 cause of wasted compute.**
-
-After planning but BEFORE writing any code, explicitly verify your approach:
-
-**Detection**: Any implementation task (always active for non-trivial changes)
+## DECISION LOOP
 
-**Protocol**:
 ```
-=== PRE-IMPLEMENTATION VERIFY ===
-1. ROOT CAUSE: Does this approach address the actual root cause, not a symptom?
-2. EXISTING TESTS: Will this break any existing passing tests?
-3. SIMPLER PATH: Is there a simpler approach I'm overlooking?
-4. ASSUMPTIONS: What am I assuming about the codebase that I haven't verified?
-5. SIDE EFFECTS: What else does this change affect?
-=== VERIFIED: [proceed/revise] ===
+1. CLASSIFY  -> complexity? backup needed? tools?
+2. PROTECT   -> cp file file.bak (for configs, DBs, critical files)
+3. MEMORY    -> query relevant context + past failures
+4. AGENTS    -> check overlaps (if multi-agent)
+5. SKILLS    -> check {{SKILLS_PATH}} for domain-specific guidance
+6. WORK      -> implement (ALWAYS use worktree for ANY file changes)
+7. REVIEW    -> self-review diff before testing
+8. TEST      -> completion gates pass
+9. LEARN     -> store outcome in memory
 ```
 
-**If ANY answer raises doubt**: STOP. Re-read the problem. Revise approach before coding.
-
-*Research basis: CoT verification (+4.3% accuracy), Reflexion framework (+18.5%), SEER adaptive reasoning (+4-9%)*
-
-### Pattern 38: Branching Exploration (BE)
-For complex or ambiguous problems, explore multiple approaches before committing.
-
-**Detection**: Problem has multiple valid approaches, ambiguous requirements, or high complexity
-
-**Protocol**:
-1. **Generate 2-3 candidate approaches** (brief description, not full implementation)
-2. **Evaluate each** against: simplicity, correctness likelihood, test-compatibility, side-effect risk
-3. **Select best** with explicit reasoning
-4. **Commit fully** to selected approach — no mid-implementation switching
-5. **If selected approach fails**: backtrack to step 1, eliminate failed approach, try next
-
-**NEVER**: Start coding the first approach that comes to mind for complex problems.
-**ALWAYS**: Spend 5% of effort exploring alternatives to save 50% on wrong-path recovery.
-
-*Research basis: MCTS-guided code generation (RethinkMCTS: 70%→89% pass@1), Policy-Guided Tree Search*
-
-### Pattern 39: Execution Feedback Grounding (EFG)
-Learn from test failures systematically — don't just fix, understand and remember.
-
-**Detection**: Any test failure or runtime error during implementation
-
-**Protocol**:
-1. **Categorize the failure** using the Failure Taxonomy (see below)
-2. **Identify root cause** (not just the symptom the error message shows)
-3. **Fix with explanation**: What was wrong, why, and what the fix addresses
-4. **Store structured feedback** in memory:
-   ```bash
-   sqlite3 ./{{MEMORY_DB_PATH}} "INSERT INTO memories (timestamp,type,content) VALUES (datetime('now'),'failure_analysis','type:<category>|cause:<root_cause>|fix:<what_fixed>|file:<filename>');"
-   ```
-5. **Query before similar tasks**: Before implementing, check memory for past failures in same area
-
-**Failure Taxonomy** (use for categorization):
-| Type | Description | Recovery Strategy |
-|------|-------------|-------------------|
-| `dependency_missing` | Import/module not found | Install or use stdlib alternative |
-| `wrong_approach` | Fundamentally incorrect solution | P38 Branching - try different approach |
-| `format_mismatch` | Output doesn't match expected format | P14 OFV - re-read spec carefully |
-| `edge_case` | Works for happy path, fails on edge | Add boundary checks, test with extremes |
-| `state_mutation` | Unexpected side effect on shared state | Isolate mutations, use copies |
-| `concurrency` | Race condition or timing issue | Add locks, use sequential fallback |
-| `timeout` | Exceeded time/resource limit | Optimize algorithm, reduce scope |
-| `environment` | Works locally, fails in target env | P1 Environment Isolation checks |
-
-*Research basis: RLEF/RLVR (RL from Execution Feedback), verifiable rewards for coding agents*
-
-### Pattern 40: Adaptive Reasoning Depth (ARD)
-Match reasoning effort to task complexity — don't over-think simple tasks or under-think hard ones.
-
-**Detection**: Applied automatically at Pattern Router stage
-
-**Complexity Classification**:
-| Complexity | Indicators | Reasoning Protocol |
-|-----------|------------|-------------------|
-| **Simple** | Single file, clear spec, known pattern, <20 lines | Direct implementation. No exploration phase. |
-| **Moderate** | Multi-file, some ambiguity, 20-200 lines | Plan-then-implement. State assumptions. P37 verify. |
-| **Complex** | Cross-cutting concerns, ambiguous spec, >200 lines, unfamiliar domain | P38 explore → P37 verify → implement → P39 feedback loop. |
-| **Research** | Unknown solution space, no clear approach | Research first (web search, codebase analysis) → P38 explore → implement iteratively. |
-
-**Rule**: Never apply Complex-level reasoning to Simple tasks (wastes tokens). Never apply Simple-level reasoning to Complex tasks (causes failures).
-
-*Research basis: SEER adaptive CoT, test-time compute scaling (2-3x gains from adaptive depth)*
-
-### Pattern 41: Atomic Task Loop (ATL)
-For multi-step changes, decompose into atomic units with clean boundaries.
-
-**Detection**: Task involves changes to 3+ files, or multiple independent concerns
-
-**Protocol**:
-1. **Decompose** the task into atomic sub-tasks (each independently testable)
-2. **Order** by dependency (upstream changes first)
-3. **For each sub-task**:
-   a. Implement the change (single concern only)
-   b. Run relevant tests
-   c. Commit if tests pass
-   d. If context is getting long/confused, note progress and continue fresh
-4. **Final verification**: Run full test suite after all sub-tasks complete
-
-**Atomicity rules**:
-- Each sub-task modifies ideally 1-2 files
-- Each sub-task has a clear pass/fail criterion
-- Sub-tasks should not depend on uncommitted work from other sub-tasks
-- If a sub-task fails, only that sub-task needs rework
-
-*Research basis: Addy Osmani's continuous coding loop, context drift prevention research*
-
-### Pattern 42: Critic-Before-Commit (CBC)
-Review your own diff against requirements before running tests.
+---
 
-**Detection**: Any implementation about to be tested or committed
+## MEMORY SYSTEM
 
-**Protocol**:
 ```
-=== SELF-REVIEW ===
-Diff summary: [what changed, in which files]
-
-REQUIREMENT CHECK:
-☐ Does the diff address ALL requirements from the task?
-☐ Are there any unintended changes (debug prints, commented code, temp files)?
-☐ Does the code handle the error/edge cases mentioned in the spec?
-☐ Is the code consistent with surrounding style and conventions?
-☐ Would this diff make sense to a reviewer with no context?
-
-ISSUES FOUND: [list or "none"]
-=== END REVIEW ===
+L1 Working  | SQLite memories      | {{SHORT_TERM_LIMIT}} max | <1ms
+L2 Session  | SQLite session_mem   | current session          | <5ms
+L3 Semantic | {{LONG_TERM_BACKEND}}| search                   | ~50ms
+L4 Knowledge| SQLite entities/rels | graph                    | <20ms
 ```
 
-**If issues found**: Fix BEFORE running tests. Cheaper to catch logic errors by reading than by test-debug cycles.
-
-*Research basis: Multi-agent reflection (actor+critic, +20% accuracy), RL^V unified reasoner-verifier*
-
----
-
-## CONTEXT OPTIMIZATION
-
-**Reduce token waste and improve response quality through intelligent context management.**
-
-### Progressive Context Disclosure
-Not all patterns are needed for every task. The Pattern Router activates only relevant patterns.
-- **Always loaded**: Pattern Router, Completion Gates, Error Recovery
-- **Loaded on activation**: Only patterns flagged YES by router
-- **Summarize, don't repeat**: When referencing prior work, summarize in 1-2 lines, don't paste full output
-
-### Context Hygiene
-- **Prune completed context**: After a sub-task completes, don't carry its full debug output forward
-- **Compress tool output**: Quote only the 2-3 lines that inform the next decision
-- **Avoid context poisoning**: Don't include failed approaches in context unless actively debugging them
-- **Reset on drift**: If responses become unfocused or repetitive, summarize progress and continue with clean context
-
-### Token Budget Awareness
-| Task Type | Target Context Usage | Strategy |
-|-----------|---------------------|----------|
-| Simple fix | <10% of window | Direct implementation, minimal exploration |
-| Feature implementation | 30-50% of window | Structured exploration, then focused implementation |
-| Complex debugging | 50-70% of window | Deep investigation justified, but prune between attempts |
-| Research/exploration | 20-40% of window | Broad search first, then narrow and deep |
-
----
-
-## SELF-IMPROVEMENT PROTOCOL
-
-**The agent improves its own effectiveness over time by learning from outcomes.**
+### Commands
 
-### After Task Completion (Success or Failure)
-1. **Record outcome** with structured metadata:
-   ```bash
-   sqlite3 ./{{MEMORY_DB_PATH}} "INSERT INTO session_memories (session_id,timestamp,type,content,importance) VALUES ('current',datetime('now'),'outcome','task:<summary>|result:<pass/fail>|patterns_used:<list>|time_spent:<estimate>|failure_type:<category_or_none>',8);"
-   ```
+```bash
+# L1: Working Memory
+sqlite3 ./{{MEMORY_DB_PATH}} "INSERT INTO memories (timestamp,type,content) VALUES (datetime('now'),'action','...');"
 
-2. **If failure occurred**: Store in semantic memory for cross-session learning:
-   ```bash
-   {{MEMORY_STORE_CMD}} lesson "Failed on <task_type>: <what_went_wrong>. Fix: <what_worked>." --tags failure,<category>,<language> --importance 8
-   ```
+# L2: Session Memory
+sqlite3 ./{{MEMORY_DB_PATH}} "INSERT INTO session_memories (session_id,timestamp,type,content,importance) VALUES ('current',datetime('now'),'decision','...',7);"
 
-3. **If novel technique discovered**: Store as reusable pattern:
-   ```bash
-   {{MEMORY_STORE_CMD}} lesson "New technique for <domain>: <technique_description>. Use when <conditions>." --tags technique,<domain> --importance 9
-   ```
+# L3: Semantic Memory
+{{MEMORY_STORE_CMD}} lesson "..." --tags t1,t2 --importance 8
 
-### Before Starting Similar Tasks
-Query memory for relevant past outcomes:
-```bash
-sqlite3 ./{{MEMORY_DB_PATH}} "SELECT content FROM memories WHERE type='failure_analysis' AND content LIKE '%<relevant_keyword>%' ORDER BY timestamp DESC LIMIT 5;"
+# L4: Knowledge Graph
+sqlite3 ./{{MEMORY_DB_PATH}} "INSERT INTO entities (type,name,first_seen,last_seen,mention_count) VALUES ('file','x.ts',datetime('now'),datetime('now'),1);"
 ```
 
-### Repo-Specific Learning
-Over time, accumulate repository-specific patterns:
-- Which test frameworks and assertions this repo uses
-- Common failure modes in this codebase
-- Preferred code style and naming conventions
-- Architecture decisions and their rationale
-
-Store these as high-importance semantic memories tagged with the repo name.
+Decay: `effective_importance = importance * (0.95 ^ days_since_access)`
 
 ---
 
-## CODE QUALITY HEURISTICS
+## WORKTREE WORKFLOW — MANDATORY
 
-**Apply to ALL generated code. Verify before committing.**
+> **MANDATORY**: ALL file changes MUST use a worktree. No exceptions. Never commit directly to any branch without a worktree. After PR is merged, worktree cleanup is MANDATORY — never leave stale worktrees.
 
-### Pre-Commit Code Review Checklist
-- [ ] Functions ≤ 30 lines (split if longer)
-- [ ] No God objects or functions doing multiple unrelated things
-- [ ] Names are self-documenting (no single-letter variables outside loops)
-- [ ] Error paths handled explicitly (not just happy path)
-- [ ] No debug prints, console.logs, or commented-out code left behind
-- [ ] Consistent with surrounding code style (indentation, naming, patterns)
-- [ ] No hardcoded values that should be constants or config
-- [ ] Imports are minimal — only what's actually used
-
-### Code Smell Detection
-If you notice any of these, fix before committing:
-- **Duplicated logic** → Extract to shared function
-- **Deep nesting (>3 levels)** → Early returns, extract helper
-- **Boolean parameters** → Consider separate methods or options object
-- **Magic numbers** → Named constants
-- **Catch-all error handling** → Specific error types with appropriate responses
-
----
-
-## SESSION START PROTOCOL
-
-**EXECUTE IMMEDIATELY before any response:**
+| Change Scope | Workflow |
+|-------------|----------|
+| ANY file change (even single-file) | **Worktree REQUIRED** |
 
 ```bash
-uam task ready                                    # Check existing work
-sqlite3 ./{{MEMORY_DB_PATH}} "SELECT * FROM memories ORDER BY id DESC LIMIT 10;"
-sqlite3 ./{{MEMORY_DB_PATH}} "SELECT * FROM session_memories WHERE session_id='current' ORDER BY id DESC LIMIT 5;"
-uam agent status                                  # Check other active agents
+{{WORKTREE_CREATE_CMD}} <slug>           # ALWAYS create first
+cd {{WORKTREE_DIR}}/NNN-<slug>/
+git add -A && git commit -m "type: description"
+{{WORKTREE_PR_CMD}} <id>                 # Create PR
+# After PR merge:
+{{WORKTREE_CLEANUP_CMD}} <id>            # MANDATORY cleanup after merge
 ```
 
-**On work request**: `uam task create --title "..." --type task|bug|feature`
-
----
+**Applies to**: {{WORKTREE_APPLIES_TO}} — ALL changes without exception
 
-## MULTI-AGENT COORDINATION PROTOCOL
+**Cleanup is MANDATORY**: After every PR merge, immediately run `{{WORKTREE_CLEANUP_CMD}} <id>`. Never leave merged worktrees behind.
 
-**Skip this section for single-agent sessions.** Only activate when multiple agents work concurrently (e.g., parallel subagents via Task tool, or multiple Claude Code sessions on same repo).
+---
 
-**Parallel-first rule**: When safe, run independent tool calls in parallel (searches, reads, status checks) and invoke multiple subagents concurrently for review.
+## MULTI-AGENT COORDINATION
 
-### Before Claiming Any Work (multi-agent only)
+**Skip for single-agent sessions.** Only activate when multiple agents work concurrently.
 
 ```bash
 uam agent overlaps --resource "<files-or-directories>"
 ```
 
-### Overlap Response Matrix
-
 | Risk Level | Action |
 |------------|--------|
 | `none` | Proceed immediately |
@@ -759,15 +195,14 @@ uam agent overlaps --resource "<files-or-directories>"
 | `medium` | Announce, coordinate sections |
 | `high`/`critical` | Wait or split work |
 
-### Agent Capability Routing
+### Agent Routing
 
-| Task Type | Route To | Capabilities |
-|-----------|----------|--------------|
-| Security review | `security-auditor` | owasp, secrets, injection |
-| Performance | `performance-optimizer` | algorithms, memory, caching |
-| Documentation | `documentation-expert` | jsdoc, readme, api-docs |
-| Code quality | `code-quality-guardian` | complexity, naming, solid |
-| Solution verification | self (P42 CBC) | diff review, requirement check |
+| Task Type | Route To |
+|-----------|----------|
+| Security review | `security-auditor` |
+| Performance | `performance-optimizer` |
+| Documentation | `documentation-expert` |
+| Code quality | `code-quality-guardian` |
 
 {{#if LANGUAGE_DROIDS}}
 ### Language Droids
@@ -783,121 +218,13 @@ uam agent overlaps --resource "<files-or-directories>"
 {{{MCP_PLUGINS}}}
 {{/if}}
 
----
-
-## MULTI-AGENT EXECUTION (DEPENDENCY-AWARE)
-
-**Skip for single-agent sessions.** When using parallel subagents:
-1. **Decompose** into discrete work items. **Map dependencies** (A blocks B).
-2. **Parallelize** dependency-free items with separate agents and explicit file boundaries.
-3. **Gate edits** with `uam agent overlaps --resource "<files>"` before touching any file.
-4. **Merge in dependency order** (upstream first).
-
----
-
-## TOKEN EFFICIENCY RULES
-
-- Prefer concise, high-signal responses; avoid repeating instructions or large logs.
-- Summarize command output; quote only the lines needed for decisions.
-- Use parallel tool calls to reduce back-and-forth.
-- Ask for clarification only when necessary to proceed correctly.
-
----
-
-## DECISION LOOP
-
-```
-0. CLASSIFY  -> complexity? backup? tool? steps? (P40 Adaptive Depth)
-1. PROTECT   -> cp file file.bak
-2. MEMORY    -> query relevant context + past failures (P39)
-3. EXPLORE   -> if complex: generate 2-3 approaches (P38)
-4. VERIFY    -> pre-implementation check (P37)
-5. AGENTS    -> check overlaps
-6. SKILLS    -> check {{SKILLS_PATH}}
-7. WORKTREE  -> create, work (P41 atomic tasks)
-8. REVIEW    -> self-review diff (P42)
-9. TEST      -> gates pass
-10. LEARN    -> store outcome in memory (P39)
-```
-
----
-
-## MEMORY SYSTEM
-
-```
-L1 Working  | SQLite memories      | {{SHORT_TERM_LIMIT}} max | <1ms
-L2 Session  | SQLite session_mem   | current                  | <5ms
-L3 Semantic | {{LONG_TERM_BACKEND}}| search                   | ~50ms
-L4 Knowledge| SQLite entities/rels | graph                    | <20ms
-```
-
-### Layer Selection
-
-| Question | YES -> Layer |
-|----------|-------------|
-| Just did this (last few minutes)? | L1: Working |
-| Session-specific decision/context? | L2: Session |
-| Reusable learning for future? | L3: Semantic |
-| Entity relationships? | L4: Knowledge Graph |
-
-### Memory Commands
-
-```bash
-# L1: Working Memory
-sqlite3 ./{{MEMORY_DB_PATH}} "INSERT INTO memories (timestamp,type,content) VALUES (datetime('now'),'action','...');"
-
-# L2: Session Memory
-sqlite3 ./{{MEMORY_DB_PATH}} "INSERT INTO session_memories (session_id,timestamp,type,content,importance) VALUES ('current',datetime('now'),'decision','...',7);"
-
-# L3: Semantic Memory
-{{MEMORY_STORE_CMD}} lesson "..." --tags t1,t2 --importance 8
-
-# L4: Knowledge Graph
-sqlite3 ./{{MEMORY_DB_PATH}} "INSERT INTO entities (type,name,first_seen,last_seen,mention_count) VALUES ('file','x.ts',datetime('now'),datetime('now'),1);"
-sqlite3 ./{{MEMORY_DB_PATH}} "INSERT INTO relationships (source_id,target_id,relation,timestamp) VALUES (1,2,'depends_on',datetime('now'));"
-```
-
-### Consolidation Rules
-
-- **Trigger**: Every 10 working memory entries
-- **Action**: Summarize -> session_memories, Extract lessons -> semantic memory
-- **Dedup**: Skip if content_hash exists OR similarity > 0.92
-
-### Decay Formula
-
-```
-effective_importance = importance * (0.95 ^ days_since_access)
-```
-
----
-
-## WORKTREE WORKFLOW
-
-**Use worktrees for multi-file features/refactors. Skip for single-file fixes.**
-
-| Change Scope | Workflow |
-|-------------|----------|
-| Single-file fix (<20 lines) | Direct commit to feature branch, no worktree needed |
-| Multi-file change (2-5 files) | Worktree recommended if touching shared interfaces |
-| Feature/refactor (3+ files, new feature) | Worktree required |
-| CLAUDE.md or config changes | Worktree required |
-
-```bash
-# Create (when needed)
-{{WORKTREE_CREATE_CMD}} <slug>
-cd {{WORKTREE_DIR}}/NNN-<slug>/
-
-# Work
-git add -A && git commit -m "type: description"
+### Parallel Execution
 
-# PR (runs tests, triggers parallel reviewers)
-{{WORKTREE_PR_CMD}} <id>
-
-# Cleanup (ALWAYS cleanup after merge)
-{{WORKTREE_CLEANUP_CMD}} <id>
-```
-
-**Applies to**: {{WORKTREE_APPLIES_TO}}
+When safe, run independent tool calls in parallel. When using parallel subagents:
+1. Decompose into discrete work items. Map dependencies.
+2. Parallelize dependency-free items with separate agents and explicit file boundaries.
+3. Gate edits with `uam agent overlaps` before touching any file.
+4. Merge in dependency order (upstream first).
 
 ---
 
@@ -906,15 +233,12 @@ git add -A && git commit -m "type: description"
 **Before ANY commit/PR, invoke quality droids in PARALLEL:**
 
 ```bash
-# These run concurrently - do NOT wait between calls
 Task(subagent_type: "code-quality-guardian", prompt: "Review: <files>")
 Task(subagent_type: "security-auditor", prompt: "Audit: <files>")
 Task(subagent_type: "performance-optimizer", prompt: "Analyze: <files>")
 Task(subagent_type: "documentation-expert", prompt: "Check: <files>")
 ```
 
-### Review Priority
-
 | Droid | Blocks PR | Fix Before Merge |
 |-------|-----------|------------------|
 | security-auditor | CRITICAL/HIGH | Always |
@@ -924,6 +248,19 @@ Task(subagent_type: "documentation-expert", prompt: "Check: <files>")
 
 ---
 
+## CODE QUALITY
+
+### Pre-Commit Checklist
+- Functions <= 30 lines
+- Self-documenting names
+- Error paths handled explicitly
+- No debug prints or commented-out code left behind
+- Consistent with surrounding code style
+- No hardcoded values that should be constants
+- Imports are minimal
+
+---
+
 ## AUTOMATIC TRIGGERS
 
 | Pattern | Action |
@@ -931,75 +268,24 @@ Task(subagent_type: "documentation-expert", prompt: "Check: <files>")
 | work request (fix/add/change/update/create/implement/build) | `uam task create --type task` |
 | bug report/error | `uam task create --type bug` |
 | feature request | `uam task create --type feature` |
-| single-file fix | direct commit to branch, skip worktree |
-| multi-file feature (3+ files) | create worktree, then work |
+| ANY file change | **create worktree (MANDATORY)** |
 | review/check/look | query memory first |
 | ANY code change | tests required |
 
-**Agent coordination**: Only use `uam agent` commands when multiple agents are active concurrently. For single-agent sessions (most common), skip agent registration and overlap checks.
-
 ---
 
-## UAM VISUAL STATUS FEEDBACK (MANDATORY WHEN UAM IS ACTIVE)
-
-**When UAM tools are in use, ALWAYS use the built-in status display commands to provide visual feedback on progress and underlying numbers. Do NOT silently perform operations -- show the user what is happening.**
+## UAM VISUAL STATUS FEEDBACK
 
-### After Task Operations
-After creating, updating, closing, or claiming tasks, run:
-```bash
-uam dashboard progress     # Show completion %, status bars, velocity
-uam task stats             # Show priority/type breakdown with charts
-```
+**When UAM tools are in use, show visual feedback:**
 
-### After Memory Operations
-After storing, querying, or prepopulating memory, run:
 ```bash
-uam memory status          # Show memory layer health, capacity gauges, service status
-uam dashboard memory       # Show detailed memory dashboard with architecture tree
+uam dashboard overview     # Full overview at session start
+uam dashboard progress     # After task operations
+uam task stats             # After task state changes
+uam memory status          # After memory operations
+uam dashboard agents       # After agent/coordination operations
 ```
 
-### After Agent/Coordination Operations
-After registering agents, checking overlaps, or claiming resources, run:
-```bash
-uam dashboard agents       # Show agent status table, resource claims, active work
-```
-
-### Periodic Overview
-At session start and after completing major work items, run:
-```bash
-uam dashboard overview     # Full overview: task progress, agent status, memory health
-```
-
-### Display Function Reference
-
-UAM provides these visual output functions (from `src/cli/visualize.ts`):
-
-| Function | Purpose | When to Use |
-|----------|---------|-------------|
-| `progressBar` | Completion bar with % and count | Task/test progress |
-| `stackedBar` + `stackedBarLegend` | Multi-segment status bar | Status distribution |
-| `horizontalBarChart` | Labeled bar chart | Priority/type breakdowns |
-| `miniGauge` | Compact colored gauge | Capacity/utilization |
-| `sparkline` | Inline trend line | Historical data trends |
-| `table` | Formatted data table | Task/agent listings |
-| `tree` | Hierarchical tree view | Memory layers, task hierarchy |
-| `box` | Bordered summary box | Section summaries |
-| `statusBadge` | Colored status labels | Agent/service status |
-| `keyValue` | Aligned key-value pairs | Metadata display |
-| `inlineProgressSummary` | Compact progress bar with counts | After task mutations |
-| `trend` | Up/down arrow with delta | Before/after comparisons |
-| `heatmapRow` | Color-coded cell row | Activity density |
-| `bulletList` | Status-colored bullet list | Health checks |
-
-### Rules
-
-1. **Never silently complete a UAM operation** -- always follow up with the relevant dashboard/status command
-2. **Show numbers, not just success messages** -- the user needs to see counts, percentages, and trends
-3. **Use `uam dashboard overview`** at session start to establish baseline awareness
-4. **Use `uam task stats`** after any task state change to show the impact
-5. **Use `uam memory status`** after any memory write to confirm storage and show capacity
-6. **Prefer dashboard commands over raw SQLite queries** for status checks -- they provide formatted visual output
-
 ---
 
 {{#if HAS_PROJECT_MD}}
@@ -1096,40 +382,24 @@ UAM provides these visual output functions (from `src/cli/visualize.ts`):
 
 ## COMPLETION GATES - MANDATORY
 
-**CANNOT say "done" or "complete" until ALL gates pass. This is NOT optional.**
+**CANNOT say "done" until ALL gates pass.**
 
-### GATE 1: Output Existence Check
+### GATE 1: Output Existence
 ```bash
-echo "=== GATE 1: OUTPUT EXISTENCE ==="
 for f in $EXPECTED_OUTPUTS; do
-  [ -f "$f" ] && echo "✓ $f exists" || echo "✗ MISSING: $f"
+  [ -f "$f" ] && echo "ok $f" || echo "MISSING: $f"
 done
 ```
+If missing: CREATE IT immediately.
 
-### GATE 2: Constraint Compliance Check
-```
-Extract ALL constraints from task description:
-- File count constraint (e.g., "single file")
-- Line count constraint (e.g., "exactly one line")
-- Format constraint (e.g., "valid JSON")
-- Size constraint (e.g., "under 5KB")
-
-Verify EACH constraint is satisfied before proceeding.
-```
+### GATE 2: Constraint Compliance
+Extract ALL constraints from task ("exactly", "only", "single", "must be", "no more than"). Verify EACH.
 
-### GATE 3: Test Verification
+### GATE 3: Tests Pass
 ```bash
-echo "=== GATE 3: TEST VERIFICATION ==="
 {{TEST_COMMAND}} 2>&1 | tail -30
-# If < 100% pass: iterate (fix specific failure, re-run)
-# Reserve 20% of time for iteration
 ```
-
-**HARD STOP RULE:**
-- If Gate 1 fails -> CREATE missing files immediately
-- If Gate 2 fails -> FIX constraint violations immediately
-- If Gate 3 fails -> ITERATE until 100% or timeout
-- NEVER report "complete" with failing gates
+If < 100%: iterate (fix specific failure, re-run). Reserve 20% of time for iteration.
 
 ---
 
@@ -1138,16 +408,17 @@ echo "=== GATE 3: TEST VERIFICATION ==="
 ```
 ☐ Tests pass
 ☐ Lint/typecheck pass
-☐ Worktree used (not {{DEFAULT_BRANCH}})
-☐ Self-review completed (P42)
-☐ Memory updated (outcome + lessons from P39)
+☐ Worktree used (MANDATORY for ALL changes)
+☐ Worktree cleaned up after PR merge (MANDATORY)
+☐ Self-review completed
+☐ Memory updated
 ☐ PR created
 ☐ Parallel reviews passed
 {{#if HAS_INFRA}}
 ☐ IaC parity verified
 {{/if}}
 ☐ No secrets in code
-☐ No debug artifacts left (console.logs, commented code, temp files)
+☐ No debug artifacts left
 ```
 
 ---
@@ -1155,65 +426,10 @@ echo "=== GATE 3: TEST VERIFICATION ==="
 ## COMPLETION PROTOCOL
 
 ```
-MERGE -> DEPLOY -> MONITOR -> FIX (iterate until 100%)
-
-1. MERGE: PR approved -> merge to {{DEFAULT_BRANCH}} -> delete branch
-2. DEPLOY: CI/CD runs -> check status -> confirm live
-3. MONITOR: Check logs -> verify functionality -> smoke tests
-4. FIX: New worktree -> fix -> GOTO 1
-5. COMPLETE: Update memory -> close tasks
+MERGE -> CLEANUP WORKTREE -> DEPLOY -> MONITOR -> FIX (iterate until 100%)
 ```
 
-**Never "done" until:** PR merged + deployed + verified working
-
----
-
-## NEAR-MISS ITERATION PROTOCOL (P26 ENFORCED)
-
-When >50% of tests pass but not all:
-1. **Read exact failure message** for each failing test
-2. **Fix ONLY the specific failing test** - do not refactor passing code
-3. **Re-run tests** immediately after each fix
-4. **Reserve 30% of time budget** for this iteration loop
-5. **Repeat** until 100% pass or time exhausted
-6. **Never give up** on a task that is >50% passing - small fixes flip outcomes
-
----
-
-## DECODER-FIRST PROTOCOL (P35 ENFORCED)
-
-When a task provides a decoder, validator, or expected output format:
-1. **READ the decoder/validator source code FIRST** before writing any implementation
-2. **Extract the exact format** it expects (headers, encoding, byte order, etc.)
-3. **Implement encoder/generator** to match that exact format
-4. **Test round-trip**: `original == decode(encode(original))` BEFORE optimizing
-5. **Never optimize** until round-trip verification passes
-
----
-
-## ERROR RECOVERY ESCALATION
-
-On any test failure or error:
-1. **Categorize** using P39 Failure Taxonomy (`dependency_missing`, `wrong_approach`, `format_mismatch`, `edge_case`, `state_mutation`, `concurrency`, `timeout`, `environment`)
-2. **Read exact error message** - do not guess
-3. **Query memory** for past failures of this type: `SELECT content FROM memories WHERE type='failure_analysis' AND content LIKE '%<type>%' LIMIT 3;`
-4. **If same error twice**: change approach completely (P38 Branching), do not retry same fix
-5. **If dependency missing**: install it (`pip install`, `npm install`, `apt-get`)
-6. **If permission denied**: use alternative path or `chmod`
-7. **If timeout**: reduce scope, submit partial solution
-8. **Store failure** in memory after resolution (P39 protocol)
-9. **Never repeat a failed command** without modification
-
----
-
-## TIME BUDGET ALLOCATION
-
-For complex tasks (compilation, VM, multi-service):
-- **20%** - Environment assessment (deps, tools, constraints)
-- **50%** - Core implementation
-- **30%** - Iteration, debugging, test fixes
-
-If timeout approaching: submit best partial solution rather than nothing.
+**Never "done" until:** PR merged + worktree cleaned up + deployed + verified working
 
 ---
 
@@ -1243,126 +459,11 @@ If timeout approaching: submit best partial solution rather than nothing.
 
 ---
 
-## CRITICAL REMINDERS (READ LAST)
-
-**These reminders exploit recency bias - place at END for maximum compliance.**
-
-0. **PATTERN ROUTER (MANDATORY FIRST STEP)**:
-   BEFORE ANY work, you MUST print this analysis block:
-   ```
-   === PATTERN ROUTER ===
-   Task: [one-line task summary]
-   Classification: [file-creation | constraint-validation | adversarial | pipeline | impossible]
-   Complexity: [simple | moderate | complex | research] (P40)
+## TOKEN EFFICIENCY
 
-   SELECTED PATTERNS:
-   - P12 (OEV): [YES/NO] - Does task require creating files?
-   - P17 (CE): [YES/NO] - Does task have "exactly/only/single/must be" constraints?
-   - P20 (AT): [YES/NO] - Does task involve "bypass/break/exploit/filter"?
-   - P11 (Pre-computed): [YES/NO] - Is this a known algorithm (crypto/chess/ML)?
-   - P18 (MTP): [YES/NO] - Does task need multiple tools chained?
-   - P37 (PIV): [YES/NO] - Non-trivial implementation needing plan verification?
-   - P38 (BE): [YES/NO] - Multiple valid approaches or high ambiguity?
-   - P41 (ATL): [YES/NO] - Changes span 3+ files or multiple concerns?
-   - P42 (CBC): [YES/NO] - Implementation that will be committed?
-
-   REASONING DEPTH (per P40):
-   - Simple → Direct implementation
-   - Moderate → Plan, verify (P37), implement
-   - Complex → Explore (P38), verify (P37), implement, feedback (P39)
-   - Research → Search first, then explore (P38), implement iteratively
-
-   ACTIVE PATTERNS: [list only YES patterns]
-   === END ROUTER ===
-   ```
-   DO NOT proceed without printing this block first.
-
-1. **BACKUP FIRST**: Before modifying ANY config, database, or critical file:
-   `cp <file> <file>.bak`
-
-2. **CHECK ENVIRONMENT**: Before using a library, verify it exists:
-   `which <tool> || python3 -c "import <lib>" 2>/dev/null || echo "NOT AVAILABLE"`
-
-3. **USE CLI OVER LIBRARIES**: When in doubt, use subprocess + CLI tools.
-
-4. **STEP-BY-STEP**: Break complex tasks into numbered commands. Execute one at a time.
-
-5. **VERIFY EACH STEP**: Check output before proceeding to next step.
-
-6. **STATE-SENSITIVE OPERATIONS**: If task involves recovery, forensics, or state inspection - backup EVERYTHING first.
-
-7. **IMPOSSIBLE DETECTION**: If task requires compression magic, ML inference, or exhaustive search - flag as potentially impossible.
-
-8. **TEST IN ISOLATION**: Dependencies installed during work may not persist. Use pre-installed tools.
-
-9. **OUTPUT VERIFICATION (MANDATORY)**: Before saying "done" or "complete":
-   ```bash
-   ls -la $EXPECTED_OUTPUTS 2>&1
-   # If ANY file is missing: CREATE IT NOW
-   ```
-
-10. **ITERATE ON PARTIAL SUCCESS**: If tests show partial pass (e.g., 8/9):
-    - Read the failing test output
-    - Fix the specific failure
-    - Re-run tests
-    - Repeat until 100% or timeout
-
-11. **CREATE BEFORE EXPLAIN**: If a required output file doesn't exist:
-    - CREATE a minimal working version FIRST
-    - Don't explain why it's missing
-    - Just make the file exist with valid content
-
-12. **TASK-FIRST**: Create required output files BEFORE analyzing.
-    Touch placeholders immediately, then refine with real content.
-
-13. **EXTRACT CONSTRAINTS (MANDATORY)**: If P17 is active, you MUST print:
-    ```
-    === CONSTRAINT CHECKLIST ===
-    Extracted from task description:
-    ☐ [constraint 1]
-    ☐ [constraint 2]
-
-    BEFORE completing, verify EACH constraint:
-    ☑ constraint 1: [PASS/FAIL]
-    ☑ constraint 2: [PASS/FAIL]
-    === END CONSTRAINTS ===
-    ```
-
-14. **MULTI-TOOL PIPELINE**: For complex tasks, identify ALL tools needed.
-    Don't implement from scratch if existing tools exist.
-
-15. **REFUSE IMPOSSIBLE**: If task violates information theory (compress 500MB to 5KB),
-    REFUSE immediately. Create IMPOSSIBLE.md explaining why. Don't attempt.
-
-16. **VERIFY BEFORE CODING (P37)**: For moderate+ complexity tasks, print the
-    PRE-IMPLEMENTATION VERIFY block. Catch wrong approaches before wasting tokens.
-
-17. **EXPLORE BEFORE COMMITTING (P38)**: For complex/ambiguous tasks, generate 2-3
-    candidate approaches and evaluate before coding. 5% exploration saves 50% rework.
-
-18. **LEARN FROM FAILURES (P39)**: After ANY test failure, categorize it using the
-    Failure Taxonomy and store structured feedback in memory. Query memory before similar tasks.
-
-19. **REVIEW YOUR OWN DIFF (P42)**: Before running tests, do a self-review of your
-    changes against requirements. Catch logic errors by reading, not by test-debug cycles.
-
-20. **ADVERSARIAL MINDSET (MANDATORY)**: If P20 is active, you MUST:
-    ```
-    === ADVERSARIAL ANALYSIS ===
-    Target: [what are we trying to bypass/break?]
-    Defense mechanism: [how does the filter/protection work?]
-
-    ATTACK VECTORS TO TRY:
-    1. Case variation
-    2. Encoding
-    3. Null bytes
-    4. Double encoding
-    5. Context breaking
-    6. Event handlers
-    7. [add task-specific vectors]
-
-    TEST EACH vector until one works.
-    === END ADVERSARIAL ===
-    ```
+- Prefer concise, high-signal responses
+- Summarize command output; quote only decision-relevant lines
+- Use parallel tool calls to reduce back-and-forth
+- Check `{{SKILLS_PATH}}` for domain-specific skills before re-inventing approaches
 
 </coding_guidelines>