wogiflow 1.0.25 → 1.0.31

package/.claude/commands/wogi-compact.md

@@ -15,6 +15,21 @@ Root (overview)
     └── File changes (expandable)
 ```
 
+## CRITICAL: Task Queue Check
+
+**Before ANY compaction**, you MUST:
+
+1. Read `.workflow/state/ready.json`
+2. Note pending tasks in your summary
+3. **NEVER claim "nothing pending" without checking ready.json**
+
+If tasks exist:
+- **In Progress** (`inProgress` in ready.json): List task IDs currently being worked on
+- **Ready** (`ready` in ready.json): Count + list task IDs awaiting work
+- **Blocked** (`blocked` in ready.json): Count blocked tasks
+
+This ensures task awareness survives context compaction.
+
 ## Before Compacting
 
 1. **Update progress.md** with:
@@ -48,7 +63,12 @@ Provide this information for the compaction system:
 - [Task/change 1]
 - [Task/change 2]
 
-**In Progress**:
+**Pending Tasks** (REQUIRED - from ready.json):
+- In Progress: [task IDs or "none"]
+- Ready: [count] tasks - [first 5 task IDs]
+- Blocked: [count] tasks
+
+**In Progress (Current)**:
 - TASK-XXX: [description] - [current state, what's left]
 
 **Key Decisions**:
@@ -65,11 +85,25 @@ Provide this information for the compaction system:
 
 **Context to Preserve**:
 - [Important context that should survive compaction]
+
+**ON RESUME**: Check `.workflow/state/ready.json` for pending work.
 ```
 
 ## Context Pressure Monitoring
 
-Check context pressure status:
+### Smart Compaction (v2.2)
+
+With smart compaction enabled (`config.smartCompaction.enabled`), context is managed intelligently:
+
+- **Before task start**: `/wogi-start` estimates task's context needs
+- **Proactive compaction**: Only compacts if `current + estimated > 95%`
+- **Emergency threshold**: Always compacts if context exceeds 95%
+
+This means fixed thresholds are less relevant - compaction happens when actually needed based on the specific task.
+
+### Legacy Fixed Thresholds
+
+If smart compaction is disabled, check context pressure status:
 - **Normal**: Under 50k tokens - no action needed
 - **Warning**: 50k-80k tokens - consider compacting soon
 - **Critical**: Over 80k tokens - compact immediately

package/.claude/commands/wogi-init.md

@@ -509,9 +509,6 @@ This file tracks all changes made to the project.
 **Files**: .workflow/*, .claude/*
 ```
 
-**roadmap.md** (future work):
-Copy from `templates/roadmap.md` to `.workflow/roadmap.md`
-
 #### 4.4 Create Spec Files
 
 **stack.md** in `.workflow/specs/`:

package/.claude/commands/wogi-peer-review.md

@@ -154,6 +154,48 @@ Respond with:
 - For learning different perspectives
 - When stuck on architecture decisions
 
+## Phase: Post-Review Actions
+
+After peer review completes, optionally create tasks from actionable improvements.
+
+### Store & Create Tasks
+
+Unlike `/wogi-review` (which finds bugs), peer review finds **improvement opportunities**. These are optional enhancements, not required fixes.
+
+**Task creation rules:**
+- Strong agreements (2+ models) → Create task if user approves
+- Single-model suggestions → Note in tech-debt.json for future
+- Disagreements → Document in review report, no task
+
+**Present options:**
+```
+═══════════════════════════════════════
+ACTIONABLE IMPROVEMENTS
+═══════════════════════════════════════
+3 improvements with strong agreement:
+• Extract repeated logic to helper (readability)
+• Add memoization for expensive computation (performance)
+• Use early return pattern (readability)
+
+Options:
+[1] Create tasks - Add as improvement tasks (P3)
+[2] Add to tech-debt - Track for future
+[3] Skip - Just log the review
+```
+
+### Learning Loop
+
+For recurring suggestions across reviews:
+
+1. If same improvement suggested 3+ times → Consider adding to decisions.md
+2. If pattern disagreement resolved consistently → Document the resolution
+
+Example:
+```
+Pattern "prefer-early-return" suggested 4 times across reviews.
+Add to coding standards? [Y/n]
+```
+
 ## Options
 
 - `--provider <name>` - Override configured provider
@@ -162,3 +204,4 @@ Respond with:
 - `--task <id>` - Review task changes
 - `--json` - Output JSON for automation
 - `--verbose` - Show full model responses
+- `--create-tasks` - Auto-create tasks for strong agreements

package/.claude/commands/wogi-review.md

@@ -608,6 +608,159 @@ The review is not complete until the user confirms. This ensures:
 - User can request additional fixes
 - User can reject fixes that change behavior unexpectedly
 
+## Phase 4: Store Findings & Create Tasks
+
+After review completes, store findings and create actionable tasks.
+
+### Step 1: Store Each Finding as Bug
+
+Save each finding to `.workflow/bugs/` using the bug template:
+
+```bash
+# For each finding, create a bug file
+# wf-XXXXXXXX.md (8-char hash of finding description)
+```
+
+Bug file format:
+```markdown
+# Bug: [Issue title]
+
+**ID**: wf-XXXXXXXX
+**Severity**: Critical | High | Medium | Low
+**Discovered**: review-YYYYMMDD-HHMMSS
+**File**: path/to/file.ts:line
+**Status**: open
+
+## Description
+[Issue description from review]
+
+## Reproduction
+Found during code review of [files reviewed]
+
+## Fix
+[Recommendation from review]
+```
+
+### Step 2: Create Tasks (Severity-Based Aggregation)
+
+Apply smart aggregation based on severity and regression risk:
+
+| Severity | Regression Risk | Action |
+|----------|-----------------|--------|
+| Critical | Any | Individual task (P0) |
+| High | High risk | Individual task (P1) |
+| High | Low risk | Aggregate with medium (P1) |
+| Medium | Any | Aggregate together (P2) |
+| Low | Any | Aggregate together (P3) |
+
+**Regression risk indicators** (treat as High risk):
+- Changes to shared utilities/helpers
+- Changes to API contracts or types
+- Changes to authentication/authorization
+- Changes to data persistence
+- Changes affecting multiple consumers
+
+**Result**:
+- Critical/high-risk issues → Individual tasks per issue
+- Low-risk issues → One aggregated "Fix N low-risk review findings" task
+
+### Step 3: Present Options to User
+
+```
+═══════════════════════════════════════
+TASKS CREATED FROM REVIEW
+═══════════════════════════════════════
+Found 8 issues:
+• 2 critical/high-risk → 2 separate tasks created
+  - wf-abc12345: Fix SQL injection in user query (P0)
+  - wf-def67890: Fix missing auth check in API (P1)
+• 6 low-risk → 1 aggregated task created
+  - wf-ghi11111: Fix 6 low-risk review findings (P2)
+
+Options:
+[1] Fix all - Start all tasks (/wogi-bulk)
+[2] Fix critical first - Start critical/high tasks only
+[3] Review tasks - Show in /wogi-ready, start manually
+```
+
+Use AskUserQuestion to present these options.
+
+## Phase 5: Learning Loop
+
+After presenting findings, trigger self-reflection to prevent future issues.
+
+### Step 1: Self-Reflection Prompt
+
+For each category of findings, ask:
+
+```
+═══════════════════════════════════════
+LEARNING OPPORTUNITY
+═══════════════════════════════════════
+Review found patterns that could be prevented.
+
+Analyzing what can be updated to prevent these in future...
+```
+
+### Step 2: Check Each Finding Against Knowledge Base
+
+For each finding, evaluate:
+
+| Finding Type | Check Against | Potential Update |
+|--------------|---------------|------------------|
+| Code pattern issue | `decisions.md` | Add new coding rule |
+| Security issue | `.claude/rules/security/` | Add security pattern |
+| Missing validation | skill patterns | Add anti-pattern |
+| Component misuse | `app-map.md` | Add usage notes |
+| Repeated mistake | `feedback-patterns.md` | Track for promotion |
+
+### Step 3: Create Corrections
+
+For preventable patterns, create correction records:
+
+```bash
+# Automatically create correction in .workflow/corrections/
+# This feeds into feedback-patterns.md
+```
+
+Example correction:
+```markdown
+### CORR-XXX | 2026-01-21
+
+**Pattern**: Missing try-catch around file reads
+**Frequency**: Found in 3 places this review
+**Prevention**: Add to security-patterns.md rule
+
+**Action taken**: Updated .claude/rules/security/security-patterns.md
+```
+
+### Step 4: Check for Promotion Opportunities
+
+If a pattern has occurred 3+ times in feedback-patterns.md:
+
+```
+═══════════════════════════════════════
+PATTERN PROMOTION AVAILABLE
+═══════════════════════════════════════
+Pattern "missing-try-catch-file-reads" has occurred 4 times.
+
+Promote to decisions.md as permanent coding rule? [Y/n]
+```
+
+### Step 5: Learning Summary
+
+```
+═══════════════════════════════════════
+LEARNING CAPTURED
+═══════════════════════════════════════
+• Created correction: CORR-047 (missing null checks)
+• Updated: .claude/rules/security/security-patterns.md
+• Pattern "null-check-before-access" at 3 occurrences
+  → Promoted to decisions.md ✓
+
+Future reviews will check for these patterns.
+```
+
 ## Auto-Fix Suggestions
 
 For certain issue types, offer automated fixes:

package/.claude/commands/wogi-start.md

@@ -1,6 +1,101 @@
 Start working on a task. Provide the task ID as argument: `/wogi-start wf-XXXXXXXX`
 
-## Structured Execution (v2.1)
+## Request Triage (NEW)
+
+When invoked with a **quoted request** instead of a task ID (e.g., `/wogi-start "update github and npm"`), first determine what type of request this is:
+
+### Step 0: Detect Request Type
+
+**Is this a task ID or a quoted request?**
+- Task ID format: `wf-XXXXXXXX` (letters, numbers, hyphens) → Skip triage, go to Structured Execution
+- Quoted request: `"anything in quotes"` → Continue with triage below
+
+### Operational Commands (Execute Directly)
+
+These are release/deploy/maintenance actions that don't require task tracking:
+
+| Category | Examples | Action |
+|----------|----------|--------|
+| **Version Control** | push, pull, fetch, merge, sync, commit | Execute git command |
+| **Publishing** | publish to npm/pypi, deploy to prod/staging | Run publish/deploy |
+| **Build/CI** | run tests, build, lint, format, typecheck | Run the command |
+| **Maintenance** | update dependencies, bump version | Run maintenance |
+
+**Examples that execute directly:**
+- `"update github and npm"` → `git push && npm publish`
+- `"push to origin"` → `git push origin`
+- `"push to bitbucket"` → `git push`
+- `"deploy to production"` → Run deploy script
+- `"bump version"` → `npm version patch`
+- `"run tests"` → `npm test`
+- `"sync with remote"` → `git pull && git push`
+
+**Action**: Execute the commands directly. No task/story needed.
+
+### Implementation Requests (Create Task First)
+
+These involve changing application code/behavior and need planning:
+
+| Category | Examples | Action |
+|----------|----------|--------|
+| **Features** | add, create, build, implement new functionality | Create story |
+| **Bug fixes** | fix, repair, resolve issues | Create story |
+| **Refactoring** | refactor, restructure, reorganize code | Create story |
+| **Code Changes** | modify, update, change existing behavior | Create story |
+
+**Examples that need a task:**
+- `"add dark mode toggle"` → Run `/wogi-story "add dark mode toggle"` first
+- `"fix the login bug"` → Run `/wogi-story "fix the login bug"` first
+- `"refactor auth system"` → Run `/wogi-story "refactor auth system"` first
+- `"update the login form"` → Run `/wogi-story "update the login form"` first
+
+**Action**: Run `/wogi-story "[request]"` to create story with acceptance criteria, wait for approval, then start implementation.
+
+### Decision Logic
+
+Use Claude's understanding (not regex) to decide:
+
+1. **Does request mention git/npm/docker/deploy/build operations without code changes?**
+   - YES → **Operational** → Execute directly
+   - NO → Continue to step 2
+
+2. **Does request involve changing application code/behavior?**
+   - YES → **Implementation** → Create story first
+   - NO → Continue to step 3
+
+3. **Is it a simple, isolated command (run X, check Y)?**
+   - YES → **Operational** → Execute directly
+   - NO → **Implementation** → Create story first
+
+**Key question**: "Does this request require writing/modifying application code?"
+- YES → Create story first (track acceptance criteria, quality gates)
+- NO → Just execute it (git, npm, deploy are infrastructure, not code)
+
+### Triage Output
+
+**Operational:**
+```
+Request: "update github and npm"
+Category: OPERATIONAL (version control + publishing)
+Action: Executing directly...
+
+→ git push origin master
+→ npm publish
+✓ Done
+```
+
+**Implementation:**
+```
+Request: "add dark mode toggle"
+Category: IMPLEMENTATION (new feature)
+Action: Creating story first...
+
+→ Running /wogi-story "add dark mode toggle"
+```
+
+---
+
+## Structured Execution (v2.2)
 
 This command implements a **structured execution loop**:
 - **Model-invoked skills**: Auto-loads relevant skills based on task context
@@ -15,6 +110,9 @@ This command implements a **structured execution loop**:
 ┌─────────────────────────────────────────────────────────┐
 │  /wogi-start wf-XXXXXXXX                                │
 ├─────────────────────────────────────────────────────────┤
+│  0.25 CONTEXT CHECK: Will this task fit in context?     │
+│     → Estimate task's context needs                     │
+│     → If current + estimated > 95% → Compact first      │
 │  0.5 PARALLEL CHECK: Are other tasks parallelizable?    │
 │     → If yes: Show parallel option before proceeding    │
 │  1. Load context + Match skills (auto-invoke)           │
@@ -51,6 +149,70 @@ This command implements a **structured execution loop**:
 └─────────────────────────────────────────────────────────┘
 ```
 
+### Step 0.25: Pre-Task Context Check (Automatic)
+
+**Before loading full task context, estimate if the task will fit:**
+
+1. Get current context usage percentage (from status line or estimate)
+2. Load task metadata from ready.json (just ID, title, type - not full spec yet)
+3. Estimate task's context needs using `flow-context-estimator.js`:
+   - Count acceptance criteria → ~3% each
+   - Count expected files → ~2% each
+   - Check for refactor/migration keywords → +10% buffer
+   - If parent task with subtasks → multiply by (1 + subtasks × 0.3)
+   - Fallback to defaults: small=10%, medium=25%, large=40%
+
+4. Calculate: `projected_total = current + estimated`
+
+5. **Decision:**
+   - If `projected_total > 95%` → **Compact first**, then resume
+   - If `current >= 95%` → **Emergency compact** (always, regardless of task)
+   - Otherwise → **Proceed** without compaction
+
+**Example outputs:**
+
+```
+📊 Context Check: Proceeding without compaction
+   Current: 60%
+   Task estimate: +25%
+   Projected: 85%
+   Safe threshold: 95%
+   Factors: 4 criteria, 3 files
+```
+
+```
+📊 Context Check: Compaction needed before task
+   Current: 75%
+   Task estimate: +30%
+   Projected: 105%
+   Safe threshold: 95%
+   Factors: 8 criteria, 6 files, +refactor buffer
+
+→ Running /wogi-compact before starting task...
+```
+
+**Why this approach?**
+- Traditional fixed thresholds (compact at 80%) are arbitrary
+- A task needing 15% context shouldn't trigger compaction at 70%
+- This approach compacts only when actually necessary
+- Large tasks at low context proceed; small tasks at high context compact
+
+**Config**: Controlled by `config.smartCompaction`:
+```json
+{
+  "enabled": true,
+  "safeThreshold": 0.95,
+  "emergencyThreshold": 0.95,
+  "estimation": {
+    "perFile": 0.02,
+    "perCriterion": 0.03,
+    "refactorBuffer": 0.10
+  }
+}
+```
+
+---
+
 ### Step 0.5: Parallel Execution Check (Automatic)
 
 **Before starting, automatically check if parallel execution is available:**
@@ -492,8 +654,9 @@ Phase commands:
 - If can't fix after 3 attempts, stop and report
 
 ### Context getting too large
-- After 3+ scenarios, check context size
-- If getting large, commit current progress and suggest `/wogi-compact`
+- **Pre-task check** estimates context needs and compacts proactively if needed
+- After 3+ scenarios, re-check context size
+- If getting large mid-task, commit current progress and suggest `/wogi-compact`
 - Progress is preserved in files and ready.json
 
 ## Important

package/.claude/rules/security/security-patterns.md

@@ -114,3 +114,30 @@ const tempPath = path.join(os.tmpdir(), 'myfile.txt');
 // Bad - manual concatenation can break on Windows
 const tempPath = os.tmpdir() + '/myfile.txt';
 ```
+
+## 8. Shell Command Parameter Validation
+
+When executing shell commands with dynamic parameters, always validate inputs.
+
+**Risk**: Command injection via unvalidated parameters passed to execSync/spawn.
+
+```javascript
+// DANGEROUS - lang parameter not validated
+execSync(`sg --pattern "${pattern}" --lang ${lang} --json "${path}"`);
+
+// SAFER - validate against whitelist
+const ALLOWED_LANGUAGES = new Set(['typescript', 'javascript', 'python', 'go']);
+if (!ALLOWED_LANGUAGES.has(lang)) {
+  throw new Error(`Unsupported language: ${lang}`);
+}
+
+// BEST - use execFile with array arguments (no shell interpretation)
+const { execFileSync } = require('child_process');
+execFileSync('sg', ['--pattern', pattern, '--lang', lang, '--json', path]);
+```
+
+**Best practices:**
+- Validate all dynamic parameters against allowlists
+- Prefer `execFile`/`execFileSync` with array arguments over `exec`/`execSync` with template strings
+- When using template strings, escape all user-controlled values
+- Never interpolate user input directly into shell commands

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wogiflow",
-  "version": "1.0.25",
+  "version": "1.0.31",
   "description": "AI-powered development workflow management system with multi-model support",
   "main": "lib/index.js",
   "bin": {