wogiflow 2.9.1 → 2.10.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -131,6 +131,45 @@ Return:
131
131
 
132
132
  **If investigation fails to identify a clear root cause**, consider escalating to `/wogi-debug-hypothesis` which spawns parallel agents to investigate competing theories about the root cause.
133
133
 
134
+ ### Phase 2.5: Hypothesis Verification Gate (MANDATORY)
135
+ <!-- PIN: hypothesis-verification-gate -->
136
+
137
+ **After forming a root cause hypothesis, you MUST verify it before proceeding to Phase 3 or communicating ANY confidence to the user.**
138
+
139
+ This gate prevents the #1 bug-investigation failure: the AI forms a hypothesis, tells the user "should work" or "go try it," and the user discovers it's wrong. Premature confidence erodes trust and wastes 25K+ tokens per incident on rework.
140
+
141
+ **The rule**: `hypothesis → verify → confirm → THEN communicate`
142
+
143
+ **Procedure**:
144
+
145
+ 1. **State the hypothesis explicitly**: Write it as a testable claim: "The root cause is X because Y, which means Z should reproduce it."
146
+
147
+ 2. **Dispatch verification** (at least ONE of these must confirm the hypothesis):
148
+ - **Code trace**: Read the code path and confirm the hypothesis explains the behavior
149
+ - **Test execution**: Run a test or command that would fail if the hypothesis is correct
150
+ - **Data verification**: Query the actual data/state that the hypothesis predicts is wrong
151
+ - **Reproduction**: Reproduce the bug by following the hypothesized trigger path
152
+
153
+ 3. **Record the evidence**: Before proceeding, state what you verified and what the result was:
154
+ ```
155
+ HYPOTHESIS: [the claim]
156
+ VERIFICATION: [what you tested]
157
+ RESULT: [confirmed / refuted / inconclusive]
158
+ ```
159
+
160
+ 4. **If CONFIRMED** → proceed to Phase 3 with the verified root cause
161
+ 5. **If REFUTED** → form a new hypothesis and repeat Phase 2.5
162
+ 6. **If INCONCLUSIVE** → escalate to `/wogi-debug-hypothesis` for parallel investigation
163
+
164
+ **BLOCKED phrases until verification passes**: The following phrases are GATED behind hypothesis verification. Do NOT use them in any communication to the user until you have verification evidence:
165
+ - "fixed", "should work", "go try", "go refresh"
166
+ - "I believe the issue is", "the problem was" (past tense implies fixed)
167
+ - "this should resolve", "that should take care of"
168
+
169
+ **Permitted before verification**: "I'm investigating X as a possible cause", "my working hypothesis is", "I need to verify whether..."
170
+
171
+ **Config**: `config.enforcement.hypothesisGate.enabled` (default: true)
172
+
134
173
  ### Phase 3: Populate Bug Report
135
174
  <!-- PIN: bug-population -->
136
175
 
@@ -239,14 +278,20 @@ The bug report IS the specification. `/wogi-start` uses the acceptance criteria
239
278
 
240
279
  When `/wogi-start` runs on a bug task, these additional steps apply:
241
280
 
242
- ### Explore Phase: Verify Root Cause
281
+ ### Explore Phase: Verify Root Cause (Hypothesis Gate Re-Check)
243
282
 
244
- Before implementing the fix, verify the root cause hypothesis:
283
+ Before implementing the fix, RE-VERIFY the root cause hypothesis from the bug report:
245
284
 
246
285
  1. Read the bug file's Root Cause Analysis section
247
286
  2. Trace the code path described in the analysis
248
- 3. Confirm or update the hypothesis
249
- 4. If hypothesis is wrong, update the bug file and re-analyze
287
+ 3. Confirm or update the hypothesis using at least ONE verification method (code trace, test, data query, reproduction)
288
+ 4. If hypothesis is WRONG update the bug file, re-analyze, and repeat Phase 2.5's verification gate
289
+ 5. If hypothesis is CONFIRMED → record the evidence in the bug file's Root Cause section and proceed
290
+
291
+ **Anti-premature-confidence rule**: During bug-fix implementation, do NOT tell the user "fixed" or "should work" until ALL acceptance criteria pass in Step 3.5. The correct communication pattern is:
292
+ - DURING fix: "Implementing the fix for [root cause]..."
293
+ - AFTER Step 3.5 passes: "Fix verified — all acceptance criteria pass. [evidence]"
294
+ - NEVER: "Go refresh, it should work now" (this is gated behind verification)
250
295
 
251
296
  ### Implementation: Fix + Prevent
252
297
 
@@ -22,9 +22,34 @@ Auto-routed from `/wogi-start` when user says:
22
22
  - "we should standardize on..."
23
23
  - "update our rules to..."
24
24
  - "add a rule for..."
25
+ - "just fix those yourself" / "handle that yourself" / "don't ask me about X" (→ authority delegation)
25
26
 
26
27
  ## How It Works
27
28
 
29
+ ### Step 0: Authority Delegation Detection
30
+
31
+ **Before all other steps**, check if the user's request is an authority delegation rather than a coding rule:
32
+
33
+ **Delegation phrases**: "just fix those yourself", "handle that yourself", "don't ask me about [X]", "you decide on [X]", "stop asking about [X]", "from now on just fix [category]".
34
+
35
+ **If detected**:
36
+ 1. Identify the decision category from the user's message (engineering, infrastructure, productBehavior, security, ux, naming, performance)
37
+ 2. Run: `node node_modules/wogiflow/scripts/flow-decision-authority.js update-category <category> <new-authority>`
38
+ - "fix it yourself" / "handle it" → `agent-decides`
39
+ - "just report after" → `agent-decides-report-after`
40
+ - "always ask me" → `owner-decides`
41
+ - "auto-fix" → `auto-fix-report-after`
42
+ 3. Confirm: "Updated decision authority: [category] → [authority]. I'll [description] from now on."
43
+ 4. **STOP** — do not proceed to the coding rule flow (Steps 1-6). Authority delegation is not a coding rule.
44
+
45
+ **Example**:
46
+ ```
47
+ User: "from now on just fix security issues yourself, don't ask me"
48
+ → Detected: authority delegation for 'security' → 'agent-decides'
49
+ → Run: flow-decision-authority.js update-category security agent-decides
50
+ → "Updated: security decisions → agent-decides. I'll handle security fixes autonomously from now on."
51
+ ```
52
+
28
53
  ### Step 0.5: Product vs Project Classification (MANDATORY)
29
54
 
30
55
  Before writing ANY rule, determine where it belongs:
@@ -0,0 +1,84 @@
1
+ ---
2
+ description: "Compressed execution prompt for 2nd+ task in a session. ~80% smaller than full wogi-start.md."
3
+ effort: medium
4
+ ---
5
+ Compressed task execution for continuation tasks (2nd+ in session). Routing, triage, and examples are skipped — the AI already has them in context.
6
+
7
+ ## Quick Dispatch
8
+
9
+ Task ID: `wf-XXXXXXXX` → Load from `ready.json`, move to inProgress.
10
+
11
+ ## Execution Loop
12
+
13
+ ### 1. Load Context
14
+ - Read task from `ready.json` (acceptance criteria, files, type)
15
+ - Check `app-map.md`, `function-map.md`, `decisions.md` for relevant entries
16
+ - Load spec from `.workflow/specs/wf-XXXXXXXX.md` or `.workflow/changes/*/wf-XXXXXXXX.md`
17
+
18
+ ### 2. Explore (L2+ tasks — MANDATORY)
19
+ Launch research agents in parallel (see `.claude/docs/explore-agents.md`):
20
+ - Agent 1 (Codebase), Agent 4 (Risk), Agent 5 (Standards) — always
21
+ - Agent 6 (Consumer Impact) — L1+ tasks or refactor/migration L2
22
+ - Agents 2-3 (Web) — if `researchDepth` is "thorough"
23
+ - **REUSE GATE**: Check reuse candidates before proceeding
24
+
25
+ ### 3. Scope-Confidence Gate (L0/L1 only)
26
+ Extract assumptions → verify against codebase → present UNVERIFIABLE/CONTRADICTED to user.
27
+
28
+ ### 4. Spec Generation (L1+ or 3+ criteria)
29
+ Generate to `.workflow/specs/wf-XXXXXXXX.md` with acceptance criteria, boundary declarations, files to change.
30
+
31
+ ### 5. Decision Authority (Cross-Cutting)
32
+ Classify decisions via `flow-decision-authority.js`. engineering/naming → agent-decides. productBehavior/ux → owner-decides. security → auto-fix. Max 5 owner questions per batch.
33
+
34
+ ### 6. Implementation Loop
35
+ For each criterion:
36
+ 1. Implement following `decisions.md` patterns
37
+ 2. Validate: `node --check` / lint / typecheck after each file edit
38
+ 3. If failing: debug, fix, retry (max 5)
39
+
40
+ ### 6.5. Additional Mandatory Gates
41
+
42
+ **Inventory Verification** (remove/fix/replace-all tasks): Pre/post inventory scan per Step 3.55. Wait for user confirmation.
43
+
44
+ **Item Reconciliation** (3+ item inputs): Enumerate all items, verify each becomes a criterion, reconcile at completion per Step 1.25.
45
+
46
+ **Scope-Confidence Gate** (L0/L1 only): Extract assumptions, verify against codebase, present UNVERIFIABLE/CONTRADICTED per Step 1.45.
47
+
48
+ ### 7. Verification Gates (ALL MANDATORY)
49
+
50
+ **Criteria Check**: Re-read ALL criteria, verify each is implemented AND works.
51
+
52
+ **Sub-Agent Verification** (if agents used): Distrust self-reports. Trace full feature chain. Check wiring.
53
+
54
+ **Skeptical Evaluator** (L2+, if `config.skepticalEvaluator.enabled`): Spawn code-reviewer agent to independently grade each criterion.
55
+
56
+ **Runtime Verification**: Generate and run tests per `flow-runtime-verification.js`. Frontend → browser tests. Backend → API tests.
57
+
58
+ **Wiring Validation**: `flow-wiring-verifier.js` — verify created files are imported/used. Check removal impact.
59
+
60
+ **Standards Compliance**: `flow-standards-gate.js` — naming, security, decisions.md rules.
61
+
62
+ ### 8. Quality Gates
63
+ Run `flow-spec-verifier.js verify`. Check `config.qualityGates` for task type:
64
+ - **feature**: loopComplete, tests, registryUpdate, requestLogEntry, integrationWiring, standardsCompliance
65
+ - **bugfix**: loopComplete, tests, requestLogEntry, standardsCompliance, learningEnforcement
66
+ - **fix**: loopComplete, requestLogEntry, standardsCompliance
67
+
68
+ ### 9. Finalize
69
+ 1. Move task to `recentlyCompleted` in ready.json
70
+ 2. Update `request-log.md`
71
+ 3. Registry maps auto-updated by `registryUpdate` gate
72
+ 4. Commit: `feat: Complete wf-XXXXXXXX - [title]`
73
+
74
+ ## Sprint Reset (5+ criteria)
75
+ At every 3rd criterion: commit progress, save checkpoint to `task-checkpoint.json`, compact context, resume from checkpoint.
76
+
77
+ ## Rules
78
+ - Validate after EVERY file edit
79
+ - Re-read ALL criteria before marking done
80
+ - Quality gates MUST pass
81
+ - Never skip wiring validation
82
+ - Update request-log.md
83
+
84
+ ARGUMENTS: {args}
@@ -10,6 +10,18 @@ Start working on a task. Provide the task ID as argument: `/wogi-start wf-XXXXXX
10
10
 
11
11
  When invoked with a **quoted request** instead of a task ID, assess intent and route.
12
12
 
13
+ ### Step 0a: Continuation Mode Check
14
+
15
+ For the 2nd+ task in a session, use the compressed prompt to save ~94% tokens:
16
+
17
+ ```bash
18
+ node -e "const {isContinuationTask}=require('wogiflow/scripts/flow-session-state');console.log(isContinuationTask())"
19
+ ```
20
+
21
+ If `true` AND the input is a task ID (not natural language) → invoke `/wogi-start-continuation` instead. The compressed prompt contains all mandatory gates but skips routing logic, triage tables, examples, and edge case documentation that are already in context from the first task.
22
+
23
+ If `false` OR the input is natural language → continue with the full prompt below.
24
+
13
25
  ### Step 0: Detect Request Type
14
26
 
15
27
  - Task ID format: `wf-XXXXXXXX` → Skip triage, go to Structured Execution
@@ -159,6 +171,29 @@ Check `ready.json` for 2+ tasks. If parallelizable (no dependencies), offer para
159
171
  3. Check `app-map.md`, `function-map.md`, `api-map.md`, `decisions.md`
160
172
  4. Auto-invoke matched skills based on task context
161
173
 
174
+ ### Decision Authority Framework (Cross-Cutting — applies to ALL steps)
175
+
176
+ **Before presenting ANY decision to the user**, classify it using `flow-decision-authority.js`:
177
+
178
+ ```bash
179
+ node node_modules/wogiflow/scripts/flow-decision-authority.js classify "<decision text>"
180
+ ```
181
+
182
+ | Authority Level | Action |
183
+ |-----------------|--------|
184
+ | `agent-decides` | Decide autonomously. Report in completion summary only. |
185
+ | `agent-decides-report-after` | Decide autonomously. Explicitly state the decision after implementing. |
186
+ | `owner-decides` | Present to user. Wait for answer before proceeding. |
187
+ | `auto-fix-report-after` | Fix automatically. Report what was fixed after. |
188
+
189
+ **Batch enforcement**: When multiple decisions arise in a single task, use `batchClassify()`. If owner-decides questions exceed `maxOwnerQuestionsPerBatch` (default: 5), overflow is automatically downgraded to `agent-decides-report-after`. This prevents question flooding (12+ questions in one batch).
190
+
191
+ **Default categories**: engineering → agent-decides, infrastructure → agent-decides-report-after, productBehavior → owner-decides, security → auto-fix-report-after, ux → owner-decides, naming → agent-decides, performance → agent-decides-report-after.
192
+
193
+ **User can update**: Via `/wogi-decide "from now on, just fix [category] yourself"` which calls `updateCategoryAuthority()` to change the config.
194
+
195
+ **Low-confidence classification**: When the classifier cannot confidently categorize a decision, it defaults to `owner-decides` (safest fallback).
196
+
162
197
  ### Step 1.2: Clarifying Questions
163
198
 
164
199
  Before generating specs (skip for small tasks ≤2 files, bugfixes, explicit specs):
@@ -219,7 +254,7 @@ Before launching: check `.workflow/state/research-cache.json` for cached results
219
254
  | 3. Version Verifier | API compatibility, deprecated APIs, version gotchas | Web |
220
255
  | 4. Risk & History | feedback-patterns, corrections, promoted rules, rejected approaches | Local |
221
256
  | 5. Standards Preview | Applicable rules, reuse candidates across ALL registries, security patterns | Local |
222
- | 6. Consumer Impact | **Refactor/migration only.** Map ALL consumers, classify BREAKING/NEEDS-UPDATE/SAFE | Local |
257
+ | 6. Consumer Impact | **ALL L1+ tasks.** Map ALL consumers, classify BREAKING/NEEDS-UPDATE/SAFE. Write results to `.workflow/state/blast-radius-{taskId}.json` | Local |
223
258
 
224
259
  Launch all in parallel. When `config.hybrid.enabled`, route via `model` parameter (explore → sonnet, search → haiku, judging → opus).
225
260
 
@@ -236,10 +271,66 @@ Launch all in parallel. When `config.hybrid.enabled`, route via `model` paramete
236
271
 
237
272
  **For L1/L0 tasks**: Offer to deepen research (exhaustive search, load all skills, full dependency tree).
238
273
 
239
- **Fallback**: If agents fail, log warning and proceed with remaining. Consumer Impact failure on refactor tasks = HARD BLOCK (require user confirmation). See `.claude/docs/explore-agents.md` for details.
274
+ **Fallback**: If agents fail, log warning and proceed with remaining. Consumer Impact failure on L1+ tasks = HARD BLOCK (require user confirmation). See `.claude/docs/explore-agents.md` for details.
240
275
 
241
276
  **Constraints**: READ-ONLY phase. No Edit/Write. Agents use only Glob, Grep, Read, WebSearch, WebFetch.
242
277
 
278
+ ### Step 1.45: Scope-Confidence Gate (L0/L1 tasks only)
279
+
280
+ **Activates when**: Task level is L0 or L1. Skip for L2/L3 tasks.
281
+
282
+ **The problem this solves**: Multi-day plans often depend on assumptions about what exists (new tables, new models, new APIs, new services). Without verification, a 7-10 day plan can collapse to 1 day when a single question reveals the assumption was wrong. This gate audits scope-inflating assumptions BEFORE the spec is generated — not the same as clarifying questions (Step 1.2) which target user intent.
283
+
284
+ **Procedure**:
285
+
286
+ 1. **Extract assumptions**: From the explore phase results and task description, list every assumption the plan depends on:
287
+ - New database tables/schemas needed
288
+ - New API endpoints or services to create
289
+ - New models or data structures
290
+ - External integrations assumed not to exist
291
+ - Infrastructure components (queues, caches, workers)
292
+
293
+ 2. **Verify each assumption against the codebase**:
294
+ - For each assumption, grep/glob for existing implementations
295
+ - Check schema files, migration files, service directories, API routes
296
+ - Check `app-map.md`, `function-map.md`, `api-map.md`, `schema-map.md` for registered components
297
+
298
+ 3. **Classify results**:
299
+ | Status | Meaning | Action |
300
+ |--------|---------|--------|
301
+ | VERIFIED | Assumption confirmed by codebase evidence | Proceed — scope is accurate |
302
+ | EXISTS | Assumed-new thing already exists | **Scope reduction** — remove from plan |
303
+ | UNVERIFIABLE | Cannot confirm or deny from codebase | **Ask user** before proceeding |
304
+ | CONTRADICTED | Codebase shows opposite of assumption | **Scope change** — replan required |
305
+
306
+ 4. **Present findings to user** (MANDATORY when any UNVERIFIABLE or CONTRADICTED found):
307
+ ```
308
+ ━━━ SCOPE-CONFIDENCE AUDIT ━━━
309
+ Task: [title]
310
+
311
+ Assumptions verified:
312
+ ✓ [assumption] — found at [file:line]
313
+
314
+ Scope reductions (already exists):
315
+ ↓ [assumption] — exists at [file:line], removing from plan
316
+
317
+ Needs confirmation:
318
+ ? [assumption] — does [X] already exist? Could not find in codebase.
319
+
320
+ Contradictions:
321
+ ✗ [assumption] — codebase shows [opposite evidence]
322
+
323
+ Revised estimate: [original] → [adjusted based on findings]
324
+ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
325
+ ```
326
+
327
+ 5. **Wait for user response** on UNVERIFIABLE items before proceeding to spec generation. Spec MUST reflect verified scope, not assumed scope.
328
+
329
+ **This is NOT the same as Step 1.2 (Clarifying Questions)**:
330
+ - Step 1.2 targets **user intent** ("what do you want?")
331
+ - Step 1.45 targets **scope assumptions** ("what does the codebase already have?")
332
+ - Step 1.2 runs before explore; Step 1.45 runs after explore (uses explore results)
333
+
243
334
  ### Step 1.5: Generate Specification
244
335
 
245
336
  For medium/large tasks (check `config.specificationMode`):
@@ -857,7 +948,7 @@ Run `node node_modules/wogiflow/scripts/flow-standards-gate.js wf-XXXXXXXX [chan
857
948
 
858
949
  Checks scoped by task type: component → naming/components/security. Utility → naming/functions/security. API → naming/api/security. Bugfix → naming/security. Feature → all. Refactor/migration → all + consumer-impact verification.
859
950
 
860
- **Consumer impact check** (refactor/migration): For each BREAKING consumer from explore phase, verify it was updated. If any NOT migrated → BLOCK task completion.
951
+ **Consumer impact check** (ALL L1+ tasks): For each BREAKING consumer from explore phase (blast-radius analysis), verify it was updated. If any NOT migrated → BLOCK task completion. Results are persisted in `.workflow/state/blast-radius-{taskId}.json`.
861
952
 
862
953
  **Reuse candidate check** (AI-as-Judge): Standards gate returns similar items from all registries. AI reasons about PURPOSE overlap (not just name). If purpose overlaps → ask user (use existing / extend / create new). If purpose clearly differs → proceed silently.
863
954
 
@@ -15,8 +15,8 @@ This command helps you configure Claude Code's status line (shown at the bottom
15
15
 
16
16
  ## Prerequisites
17
17
 
18
- - Claude Code v1.0.52+ (January 2026 or later)
19
- - The `context_window.used_percentage` field is available in status line input
18
+ - Claude Code v1.0.52+ (January 2026 or later) — `context_window.used_percentage` field
19
+ - Claude Code v2.1.97+ (optional) `refreshInterval` setting and `workspace.git_worktree` variable
20
20
 
21
21
  ## Setup Instructions
22
22
 
@@ -38,18 +38,23 @@ Add or update the `statusLine` section in `~/.claude/settings.json`:
38
38
  {
39
39
  "statusLine": {
40
40
  "enabled": true,
41
- "format": "{{#if task}}[{{task.id}}] {{/if}}{{model}} | Ctx: {{context_window.used_percentage}}%{{#if skill}} | Skill: {{skill}}{{/if}}"
41
+ "format": "{{#if task}}[{{task.id}}] {{/if}}{{model}} | Ctx: {{context_window.used_percentage}}%{{#if skill}} | Skill: {{skill}}{{/if}}",
42
+ "refreshInterval": 5
42
43
  }
43
44
  }
44
45
  ```
45
46
 
47
+ `refreshInterval` re-runs the status line every N seconds so live values (task ID,
48
+ context %, active skill, worktree branch) stay current between prompts. Requires
49
+ Claude Code 2.1.97+. Omit the field or set it to 0 to disable auto-refresh.
50
+
46
51
  ### Format Options
47
52
 
48
53
  | Format | Display Example |
49
54
  |--------|-----------------|
50
55
  | **Compact** | `opus | 45%` |
51
56
  | **Standard** | `[wf-123] opus | Ctx: 45%` |
52
- | **Detailed** | `[wf-123] My Task | opus | Ctx: 45% (85k remaining) | Skill: nestjs` |
57
+ | **Detailed** | `[WT] [wf-123] My Task | opus | 45% used | nestjs` |
53
58
 
54
59
  ### Available Variables
55
60
 
@@ -61,11 +66,19 @@ Add or update the `statusLine` section in `~/.claude/settings.json`:
61
66
  | `{{task.id}}` | Current WogiFlow task ID (if any) |
62
67
  | `{{task.title}}` | Current task title |
63
68
  | `{{skill}}` | Currently active skill |
69
+ | `{{workspace.git_worktree}}` | Truthy when cwd is inside a linked git worktree (2.1.97+) |
64
70
  | `{{worktree.name}}` | Worktree name (if running in --worktree session) |
65
71
  | `{{worktree.branch}}` | Worktree branch name |
66
72
  | `{{worktree.path}}` | Worktree directory path |
67
73
  | `{{worktree.original}}` | Original repo directory |
68
74
 
75
+ **`workspace.git_worktree` vs `worktree.*`**: `workspace.git_worktree` is set
76
+ whenever the cwd is in any linked git worktree (even outside a Claude Code
77
+ `--worktree` session). The `worktree.*` variables are populated only when Claude
78
+ Code itself created the worktree via `--worktree`. Use `workspace.git_worktree`
79
+ for a simple "am I in a worktree?" indicator; use `worktree.branch` for the full
80
+ branch label.
81
+
69
82
  ### Recommended Formats
70
83
 
71
84
  **Minimal** (lowest overhead):
@@ -80,7 +93,7 @@ Add or update the `statusLine` section in `~/.claude/settings.json`:
80
93
 
81
94
  **Full Context** (detailed):
82
95
  ```json
83
- "format": "[{{task.id}}] {{model}} | {{context_window.used_percentage}}% used | {{#if skill}}{{skill}}{{/if}}"
96
+ "format": "{{#if workspace.git_worktree}}[WT] {{/if}}{{#if task}}[{{task.id}}] {{task.title}} | {{/if}}{{model}} | {{context_window.used_percentage}}% used{{#if skill}} | {{skill}}{{/if}}"
84
97
  ```
85
98
 
86
99
  **With Worktree** (for parallel task execution):
@@ -72,6 +72,8 @@ flow parallel check # See available parallel tasks
72
72
  | 2.1.0+ | 2.1.77+ | PreToolUse allow/deny separation, 128k output tokens, worktree sparse checkout, compaction circuit breaker |
73
73
  | 2.4.0+ | 2.1.83+ | managed-settings.d/, CwdChanged/FileChanged hooks, ENV_SCRUB, --channels limitations, MEMORY.md 25KB cap |
74
74
  | 2.5.0+ | 2.1.84+ | TaskCreated hook, YAML glob lists in rules, CLAUDE_STREAM_IDLE_TIMEOUT_MS, WorktreeCreate HTTP transport, idle-return prompt, MCP 2KB cap |
75
+ | 2.9.0+ | 2.1.90+ | --resume deferred-tool cache fix, MCP schema perf, PostToolUse format-on-save fix, PreToolUse exit-code-2 fix, .husky protected |
76
+ | 2.9.2+ | 2.1.97+ | Stop/SubagentStop long-session fix, subagent worktree cwd leak fix, refreshInterval status line, workspace.git_worktree, MCP HTTP/SSE leak fix, 429 backoff, compaction transcript dedup |
75
77
 
76
78
  ### Environment Variables (2.1.19+)
77
79
 
@@ -287,6 +289,80 @@ await cancelTask('wf-123', 'superseded', false);
287
289
 
288
290
  - **ANTHROPIC_DEFAULT_{OPUS,SONNET,HAIKU}_MODEL_SUPPORTS**: New env vars to override effort/thinking capability detection for pinned default models on Bedrock/Vertex/Foundry. WogiFlow's hybrid mode routes to different models — 3P users who pin models can now declare their capabilities properly.
289
291
 
292
+ ### Features in 2.1.90+
293
+
294
+ - **--resume deferred-tool prompt-cache fix**: Fixed `--resume` causing a full prompt-cache miss on the first request for sessions with deferred tools, MCP servers, or custom agents (regression since v2.1.69). WogiFlow sessions using deferred MCP tools (Atlassian, Figma, Gmail, Google Calendar) now resume with cache preserved — faster first-turn response after `--resume` or `/wogi-suspend` + resume.
295
+
296
+ - **MCP schema cache-key performance**: Eliminated per-turn `JSON.stringify` of MCP tool schemas on cache-key lookup. WogiFlow sessions with MCP servers benefit automatically — reduced CPU overhead on every turn. Combined with the SSE linear-time fix (large streamed frames were previously quadratic) and SDK transcript write fix (long conversations no longer slow down quadratically), this significantly improves performance for long WogiFlow sessions.
297
+
298
+ - **PostToolUse format-on-save fix**: Fixed `Edit`/`Write` failing with "File content has changed" when a PostToolUse format-on-save hook rewrites the file between consecutive edits. WogiFlow's PostToolUse validation is read-only (`tsc --noEmit`, `eslint`) and does NOT rewrite files, so this was never triggered. However, users who configure custom validation commands with formatters (e.g., `prettier --write`) in `config.validation.afterFileEdit.commands` would have hit this bug on older CC versions.
299
+
300
+ - **PreToolUse exit-code-2 blocking fix**: Fixed PreToolUse hooks that emit JSON to stdout and exit with code 2 not correctly blocking the tool call. WogiFlow hooks always `exit(0)` and use `permissionDecision: 'deny'` in the JSON payload for blocking — the correct pattern. Not affected, but good to know the exit-code-2 pattern now also works for other tools.
301
+
302
+ - **Auto mode boundary enforcement**: Fixed auto mode not respecting explicit user boundaries ("don't push", "wait for X before Y") even when the action would otherwise be allowed. Improves safety when users set boundaries during WogiFlow task execution.
303
+
304
+ - **PowerShell hardening**: Hardened PowerShell tool permission checks — fixed trailing `&` background job bypass, `-ErrorAction Break` debugger hang, archive-extraction TOCTOU, and parse-fail fallback deny-rule degradation. Also removed `Get-DnsClientCache` and `ipconfig /displaydns` from auto-allow (DNS cache privacy). WogiFlow has no PowerShell commands — not affected. Windows users benefit from improved security.
305
+
306
+ - **Added /powerup**: Interactive lessons teaching Claude Code features with animated demos. Available to WogiFlow users alongside `/wogi-help`.
307
+
308
+ - **Added .husky to protected directories**: `.husky/` directory now protected in `acceptEdits` mode, preventing accidental modification of git hooks. WogiFlow projects using Husky for pre-commit hooks benefit from this protection.
309
+
310
+ - **CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE env var**: Keeps the existing marketplace cache when git pull fails. Useful in offline environments where WogiFlow sessions need marketplace plugins.
311
+
312
+ - **--resume picker changes**: `--resume` picker no longer shows sessions created by `claude -p` or SDK invocations. WogiFlow sessions are interactive, so they remain visible in the picker. SDK-spawned sessions (e.g., from wogiflow-cloud's remote agents) are now correctly hidden from manual resume.
313
+
314
+ ### Features in 2.1.97+
315
+
316
+ - **Stop/SubagentStop hooks no longer fail on long sessions**: Fixed prompt-type Stop/SubagentStop hooks failing after extended session activity, and hook evaluator API errors now display the actual error message instead of a generic "JSON validation failed". **Impact on WogiFlow**: CRITICAL reliability fix. WogiFlow's `scripts/hooks/entry/claude-code/stop.js` enforces routing-pending detection (blocks stop until `/wogi-start` is invoked) and runs loop-exit checks — on long sessions this hook was silently failing, meaning routing enforcement degraded and loop gating could skip. After upgrading to 2.1.97+, routing enforcement is reliable for the full session lifetime. No WogiFlow code change needed; the fix is purely in Claude Code's hook evaluator.
317
+
318
+ - **Subagent worktree cwd leak fix**: Fixed subagents using `isolation: "worktree"` or a `cwd:` override leaking their working directory back into the parent session's Bash tool. **Impact on WogiFlow**: HIGH severity fix. WogiFlow's parallel explore phase (`flow-parallel.js`) and `/wogi-bulk` spawn multiple worktree-isolated sub-agents. Prior to 2.1.97, the parent session's subsequent `Bash` calls could inherit a stale worktree path — causing file edits, git commands, or validation to run in the wrong directory. This was silent and hard to debug. After upgrading, parallel execution with worktree isolation is safe again.
319
+
320
+ - **`refreshInterval` status line setting**: New top-level field on `statusLine` in `settings.json` that re-runs the status line every N seconds so live values (task ID, context %, active skill, worktree branch) stay current between prompts. **WogiFlow adoption**: `flow-statusline-setup.js` now prompts for and writes `refreshInterval` during interactive setup (default **5 seconds**), and exposes a `--refresh-interval N` CLI flag that can be used standalone or combined with `--format`. Setting to 0 disables auto-refresh. The `buildStatusLine()` helper preserves any existing statusLine fields, so `--format X` no longer wipes a user's previously-configured refresh interval (and vice versa).
321
+
322
+ - **`workspace.git_worktree` in status line JSON input**: New variable set when the current directory is inside a linked git worktree (independent of Claude Code's `--worktree` flag). **WogiFlow adoption**: The `detailed` preset in `flow-statusline-setup.js` now includes `{{#if workspace.git_worktree}}[WT] {{/if}}` so users see a clear worktree indicator even when they entered a worktree via `git worktree add` outside a `--worktree` session. `wogi-statusline-setup.md` documents the distinction between `workspace.git_worktree` (any linked worktree) and the existing `worktree.*` variables (only when Claude Code created the worktree).
323
+
324
+ - **Compaction transcript dedup**: Fixed compaction writing duplicate multi-MB subagent transcript files on prompt-too-long retries. **Impact on WogiFlow**: WogiFlow's explore phase launches 5-6 parallel agents per L2+ task. Previously, compaction was writing duplicate transcripts for each agent, bloating session state and slowing `--resume`. Automatic improvement after upgrade.
325
+
326
+ - **MCP HTTP/SSE memory leak fix**: Fixed MCP HTTP/SSE connections accumulating ~50 MB/hr of unreleased buffers when servers reconnect. **Impact on WogiFlow**: WogiFlow configures MCP servers (memory server, Figma MCP, and optional cloud Atlassian/Gmail/Calendar via deferred tools). Long WogiFlow sessions — especially `/wogi-bulk-loop` continuous runs — were accumulating hidden memory. Automatic improvement after upgrade.
327
+
328
+ - **429 retry exponential backoff**: Fixed 429 retries burning all attempts in ~13 seconds when the server returned a small `Retry-After` — exponential backoff now applies as a minimum. **Impact on WogiFlow**: WogiFlow's heavy context loading (CLAUDE.md + state files + specs + explore agents) can trigger rate limits on burst workloads. Prior to 2.1.97, all retry attempts were consumed in seconds. Now retries are properly spaced and recoverable.
329
+
330
+ - **Rate-limit upgrade options preserved across compaction**: Fixed rate-limit upgrade options disappearing after context compaction. **Impact on WogiFlow**: WogiFlow's sprint-based context reset (Step 3.05) triggers compaction mid-task. Users hitting rate limits during long tasks no longer lose their upgrade path after compaction.
331
+
332
+ - **Slash command picker YAML boolean keyword fix**: Fixed slash command picker breaking when a plugin's frontmatter `name:` is a YAML boolean keyword (`true`, `false`, `yes`, `no`, `on`, `off`). **Impact on WogiFlow**: WogiFlow's `flow-workflow.js` has a YAML parser that coerces bare `true`/`false` strings to JS booleans — if any WogiFlow skill or plugin accidentally used one of these as a `name`, the picker would break. All current WogiFlow skills use descriptive kebab-case names (e.g., `wogi-start`, `wogi-review`) so none are affected. Plugin authors publishing to WogiFlow should continue to quote any YAML boolean keywords in frontmatter as a defensive measure.
333
+
334
+ - **`permissions.additionalDirectories` mid-session changes apply**: Fixed `permissions.additionalDirectories` changes in `settings.json` not applying mid-session, and fixed removing a directory from `settings.permissions.additionalDirectories` revoking access to the same directory passed via `--add-dir`. **Impact on WogiFlow**: WogiFlow can emit `additionalDirectories` changes during installation, worktree creation, or team sync. Prior to 2.1.97, these changes required a session restart. Now they apply immediately — `/wogi-rescan` and `/wogi-onboard` flows that touch permissions no longer need a manual restart.
335
+
336
+ - **Permission rules matching JS prototype property names**: Fixed permission rules with names matching JavaScript prototype properties (e.g., `toString`, `constructor`, `hasOwnProperty`) causing `settings.json` to be silently ignored. **Impact on WogiFlow**: Defensive improvement. WogiFlow's `generateSettings()` in `.workflow/bridges/claude-bridge.js` uses `PERM_SAFE_RE` regex validation and never emits prototype names, but this fix protects any user who adds custom permission rules.
337
+
338
+ - **Managed-settings allow rules cleanup**: Fixed managed-settings `allow` rules remaining active after an admin removed them until process restart. **Impact on wogiflow-cloud**: Relevant for teams using managed settings for policy enforcement. Admins can now dynamically grant/revoke permissions without requiring end-user session restarts.
339
+
340
+ - **`--dangerously-skip-permissions` downgrade fix**: Fixed bypass mode being silently downgraded to `accept-edits` after approving a write to a protected path. Security improvement — WogiFlow does not rely on bypass mode but users running `/wogi-bulk --continuous` with `--dangerously-skip-permissions` benefit.
341
+
342
+ - **Bash permission hardening**: Hardened Bash tool permissions, tightening checks around env-var prefixes and network redirects, and reducing false prompts on common commands. Also improved Accept Edits mode to auto-approve filesystem commands prefixed with safe env vars or process wrappers (e.g. `LANG=C rm foo`, `timeout 5 mkdir out`). **Impact on WogiFlow**: Reduces interruptions during validation (`tsc`, `eslint`, `node --test`) that pass through env-var wrappers. WogiFlow's `generatePermissions()` was designed for literal command prefixes — users no longer need to enumerate every env-var-prefixed variant.
343
+
344
+ - **Focus view toggle (Ctrl+O) in NO_FLICKER mode**: New toggle shows just the prompt, a one-line tool summary with edit diffstats, and the final response. Useful during long WogiFlow task execution to see high-level progress without the full tool call stream. Documentation-only for WogiFlow — no code change. Worth mentioning in `/wogi-help`.
345
+
346
+ - **Running indicator in `/agents`**: `● N running` indicator now appears in `/agents` next to agent types with live subagent instances. WogiFlow's explore phase agents (5-6 per task) and worktree-isolated sub-agents are now visible at a glance. Free UX improvement.
347
+
348
+ - **`workspace.git_worktree` on status line JSON input** (see refreshInterval entry above for WogiFlow adoption).
349
+
350
+ - **Image compression alignment**: Pasted and attached images are now compressed to the same token budget as images read via the Read tool. **Impact on WogiFlow**: The Figma analyzer skill and `/wogi-debug-browser` screenshots benefit automatically — token cost is now predictable regardless of how the image entered the session.
351
+
352
+ - **Session transcript size improvements**: Empty hook entries are skipped and stored pre-edit file copies are capped. **Impact on WogiFlow**: WogiFlow registers 12+ hooks — many of which return empty `hookSpecificOutput` for fast-path exits. These were bloating the transcript. Automatic improvement after upgrade, with meaningful reduction in session file size for long runs.
353
+
354
+ - **Per-block token usage accuracy**: Per-block transcript entries now carry the final token usage instead of the streaming placeholder. **Impact on WogiFlow**: `/wogi-status`, cost tracking, and retrospective analysis that reads token usage from transcripts now report accurate numbers.
355
+
356
+ - **Bash OTEL TRACEPARENT inheritance**: Bash subprocesses now inherit a W3C `TRACEPARENT` env var when OTEL tracing is enabled. **Impact on wogiflow-cloud**: Teams product opportunity — WogiFlow hook subprocesses can propagate trace context to the cloud observability backend for end-to-end request tracing. Tracked as cloud opportunity; no OSS code change needed.
357
+
358
+ - **Improved context-low warning**: Now shows as a transient footer notification instead of a persistent row. **Impact on WogiFlow**: WogiFlow's proactive compaction triggers at 75% threshold. The transient warning matches WogiFlow's "compaction is invisible infrastructure" principle — less visual noise during task execution.
359
+
360
+ - **Bedrock SigV4 empty-string fix**: Fixed Bedrock SigV4 authentication failing when `AWS_BEARER_TOKEN_BEDROCK` or `ANTHROPIC_BEDROCK_BASE_URL` are set to empty strings (as GitHub Actions does for unset inputs). **Impact on wogiflow-cloud CI**: Relevant for teams running WogiFlow tasks from GitHub Actions with Bedrock backends. No OSS code change needed.
361
+
362
+ - **MCP OAuth refresh fix**: Fixed MCP OAuth `oauth.authServerMetadataUrl` not being honored on token refresh after restart, fixing ADFS and similar IdPs. **Impact on WogiFlow**: Enterprise users with ADFS-backed MCP servers benefit automatically.
363
+
364
+ - **`/claude-api` skill updated for Managed Agents**: The `/claude-api` skill now covers Managed Agents (`/v1/agents`, `/v1/sessions`) alongside the Claude API. **Impact on WogiFlow**: Informational — WogiFlow's `claude-api` skill reference remains accurate.
365
+
290
366
  ### Simple Mode Naming Distinction
291
367
 
292
368
  Claude Code's `CLAUDE_CODE_SIMPLE` environment variable (which enables a simplified tool set) is **unrelated** to WogiFlow's `loops.simpleMode` (a lightweight task completion loop using string detection). They are separate features that happen to share the word "simple":
@@ -421,4 +497,4 @@ Run `/keybindings` in Claude Code to customize your shortcuts.
421
497
 
422
498
  ---
423
499
 
424
- *Last updated: 2026-03-11*
500
+ *Last updated: 2026-04-09*
@@ -164,12 +164,15 @@ Return:
164
164
  - Security patterns that apply
165
165
  ```
166
166
 
167
- ## Agent 6: Consumer Impact Analyzer (Refactor/Migration/Schema Changes)
167
+ ## Agent 6: Consumer Impact Analyzer (ALL L1+ Tasks)
168
168
 
169
- Launch as `Agent(subagent_type=Explore)` (local only). **MANDATORY for refactor, migration, architecture tasks AND any task that modifies schema/model files.**
169
+ Launch as `Agent(subagent_type=Explore)` (local only). **MANDATORY for ALL L1+ tasks (stories, epics, features).** Also triggered for any L2 task that modifies schema/model files.
170
170
 
171
- Trigger keywords: refactor, replace, rename, restructure, extract, consolidate, deprecate, migrate, move, reorganize.
172
- Trigger files: *.prisma, *.entity.ts, *.model.ts, *.schema.ts, files listed in schema-map.md.
171
+ Previously limited to refactor/migration only, but blast-radius analysis has proven valuable for ALL task types — a feature task's consumer grep collapsed a 3-day estimate to 0.5 days (18:1 ROI).
172
+
173
+ Trigger: ALL tasks at level L1 or L0. L2 tasks when keywords or trigger files match.
174
+ Trigger keywords (L2 only): refactor, replace, rename, restructure, extract, consolidate, deprecate, migrate, move, reorganize.
175
+ Trigger files (L2 only): *.prisma, *.entity.ts, *.model.ts, *.schema.ts, files listed in schema-map.md.
173
176
 
174
177
  ```
175
178
  Analyze consumer impact for task: "[TASK_TITLE]"
@@ -206,10 +209,23 @@ Return:
206
209
  - Indirect consumer chains
207
210
  - Risk: HIGH (10+), MEDIUM (3-9), LOW (0-2) breaking consumers
208
211
  - If HIGH: recommend phased migration (create new → migrate consumers → remove old)
212
+
213
+ 5. Write results to `.workflow/state/blast-radius-{taskId}.json`:
214
+ {
215
+ "taskId": "[TASK_ID]",
216
+ "taskTitle": "[TASK_TITLE]",
217
+ "timestamp": "[ISO_DATE]",
218
+ "consumers": { "breaking": [...], "needsUpdate": [...], "safe": [...] },
219
+ "risk": "HIGH|MEDIUM|LOW",
220
+ "breakingCount": N,
221
+ "totalConsumers": N
222
+ }
209
223
  ```
210
224
 
211
225
  **CRITICAL**: If 5+ BREAKING consumers found, spec MUST include migration plan. Implementation is BLOCKED without it.
212
226
 
227
+ **Blast-radius artifact**: Results are persisted to `.workflow/state/blast-radius-{taskId}.json` for use by downstream gates (context estimator, standards compliance, workspace dispatch).
228
+
213
229
  ## Launching
214
230
 
215
231
  All agents launch in parallel as `Agent(subagent_type=Explore)` calls in a single message. When `config.hybrid.enabled`, use the `model` parameter on each Agent call to route by task type:
@@ -226,7 +242,7 @@ The `model` parameter was restored in Claude Code 2.1.72 for per-invocation over
226
242
  - If any agent fails, log warning and proceed with remaining agents
227
243
  - Agents 1, 4, 5, 6 are local-only (should rarely fail)
228
244
  - Agents 2, 3 use web search (may fail on network issues)
229
- - If Consumer Impact fails AND task is refactor: **HARD BLOCK** — require user confirmation
245
+ - If Consumer Impact fails AND task is L1+: **HARD BLOCK** — require user confirmation
230
246
  - If ALL agents fail: proceed with codebase analysis only (minimal mode)
231
247
 
232
248
  ## Constraints