wogiflow 2.12.1 → 2.15.0

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

@@ -0,0 +1,62 @@
+---
+description: "Manual trigger of the IGR Logic Adversary — critique a plan against the Logic Constitution v1 rubric."
+effort: medium
+---
+
+Manually invoke the **Logic Adversary** (IGR Stage 4) against a plan or spec of your choosing. Normally the Adversary runs automatically during `/wogi-start` Step 1.57. Use `/wogi-challenge` when you want to stress-test a plan outside the pipeline — for example, a design doc you wrote by hand, a pre-approved task where you want an extra pass, or an ad-hoc proposal in conversation.
+
+Story: `wf-b00262b1` (IGR)
+
+## Usage
+
+```bash
+# Critique a plan file
+/wogi-challenge path/to/plan.md
+
+# Critique the plan for a specific task (reads .workflow/plans/{taskId}.md)
+/wogi-challenge wf-XXXXXXXX
+
+# Critique with an explicit rubric version
+/wogi-challenge path/to/plan.md --rubric=logic-constitution-v1
+```
+
+## What it does
+
+1. Loads the plan (either from a file path or from `.workflow/plans/{taskId}.md`).
+2. Calls `scripts/flow-logic-adversary.js buildAdversaryPrompt` to assemble the critique prompt — includes the 10-principle Logic Constitution, few-shot calibration examples, and all available intent artifacts.
+3. Spawns a sub-agent via the Agent tool on a different model than this session when possible (Sonnet when you're on Opus; Opus when you're on Sonnet) — the model-separation rule per the approved spec.
+4. Parses the returned JSON verdict against the rubric schema.
+5. Records a telemetry event (`gateId: logic-adversary`) with the verdict.
+6. Renders the verdict in human-readable form with per-principle PASS/CONCERN/FAIL.
+7. If the verdict is NEEDS_REVISION or FAIL, offers to iterate — the user can edit the plan and re-run.
+
+## When to use it
+
+- **Before approval** — re-check a plan the automatic Adversary already passed, with fresh eyes.
+- **After major revisions** — when you edited a plan by hand and want re-validation.
+- **On external docs** — critique a design doc written outside WogiFlow against the Logic Constitution.
+- **As a gut-check** — for high-stakes decisions (architecture, migrations) where one pass isn't enough.
+
+## Requirements
+
+- `intentGroundedReasoning.enabled` and `intentGroundedReasoning.logicAdversary.enabled` must be true in `config.json`.
+- The plan file must contain structured content parseable by the Adversary (plain markdown is fine).
+- For task-ID form (`/wogi-challenge wf-XXX`), the plan must exist at `.workflow/plans/{taskId}.md`.
+
+## Under the hood
+
+- Script: `scripts/flow-logic-adversary.js`
+- Rubric: `.workflow/rubrics/logic-constitution-v1.md`
+- Persona: `.workflow/agents/logic-adversary.md`
+- Calibration: `.workflow/state/adversary-calibration.json`
+- Telemetry: `gateId: logic-adversary` in `.workflow/state/gate-telemetry.jsonl`
+
+## Related
+
+- `/wogi-start` — runs Adversary automatically at Step 1.57 during task execution
+- `node scripts/flow-gate-telemetry.js stats --gate=logic-adversary` — see historical Adversary effectiveness
+- `/wogi-review` — different tool, critiques code after implementation; Adversary critiques plans before
+
+## Arguments
+
+Arguments: `{{ args }}`

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

@@ -127,10 +127,23 @@ In `config.json`:
 {
   "eval": {
     "judges": { "opus": 1, "sonnet": 2 },
-    "scoringDimensions": ["completeness", "accuracy", "workflowCompliance", "tokenEfficiency", "quality"],
+    "scoringDimensions": ["completeness", "accuracy", "workflowCompliance", "tokenEfficiency", "quality", "productCoherence"],
     "passingThreshold": 6
   }
 }
 ```
 
+## Dimension reference
+
+| Dimension | What the judge scores |
+|-----------|----------------------|
+| `completeness` | Were all acceptance criteria implemented? |
+| `accuracy` | Does the implementation match the spec exactly? |
+| `workflowCompliance` | Did the work follow WogiFlow rules (request log, registry update, etc.)? |
+| `tokenEfficiency` | Were tokens used efficiently — minimal redundancy, focused output? |
+| `quality` | Is the code well-structured, readable, maintainable? |
+| **`productCoherence`** (IGR) | Does this implementation make sense for the product's stated users and domain? Does it reuse existing concepts or introduce duplicates? Does it integrate with existing user journeys, or create orphans? Would a product manager look at this and say "yes, this fits"? — **Score 1–10. 10 = textbook product fit; 1 = solves wrong problem entirely.** Requires `intentGroundedReasoning.productFitEval.enabled` and product.md to be confirmed (not draft) for full-strength scoring. |
+
+When IGR is disabled, `productCoherence` is omitted from the scoring rubric and the judge falls back to the 5 pre-IGR dimensions.
+
 ARGUMENTS: $ARGUMENTS

package/.claude/commands/wogi-gate-stats.md

@@ -0,0 +1,80 @@
+---
+description: "Show per-gate telemetry: invocations, pass rate, catch rate, miss rate. The IGR self-assessment dashboard."
+effort: low
+---
+
+Display per-gate statistics from the IGR Gate Telemetry log (`.workflow/state/gate-telemetry.jsonl`). This is the **self-assessment dashboard** the owner asked for during epic planning ("write down every time a gate catches something so we can see what's working and what's not working").
+
+Story: `wf-faf340cf` (IGR Story 0 — Gate Telemetry & Self-Assessment Framework)
+
+## Usage
+
+```bash
+# All gates, all time
+/wogi-gate-stats
+
+# Filter by time window (e.g., last 7 days)
+/wogi-gate-stats --since=7d
+/wogi-gate-stats --since=24h
+/wogi-gate-stats --since=30d
+
+# Filter to one gate
+/wogi-gate-stats --gate=logic-adversary
+/wogi-gate-stats --gate=completion-truth-gate
+/wogi-gate-stats --gate=standards-gate
+
+# Combined
+/wogi-gate-stats --since=7d --gate=intent-framing
+```
+
+## What the metrics mean
+
+| Metric | Definition | What it tells you |
+|--------|-----------|-------------------|
+| `invocations` | How many times the gate ran | Activity level |
+| `pass%` | `PASS / invocations` | How permissive the gate is |
+| `catch%` | `(CONCERN + FAIL) / invocations` | How often the gate found issues — the "is this gate doing anything" signal |
+| `miss%` | `userCorrectedAfterPass / PASS` | **Critical signal** — how often the gate passed work the user later corrected. High miss% = rubber-stamping. |
+| `avgMs` | Average duration | Performance |
+| `misses` | Raw count of cross-referenced misses | The number of times you had to correct something this gate said was fine |
+
+## The miss-rate signal — the one that matters most
+
+A gate with `pass% = 100%` and `miss% > 10%` is **rubber-stamping**. It's letting things through that you then have to correct. This is the failure mode the owner's QA-98%-parable warned against: 100% coverage that creates false confidence is more dangerous than 70% coverage that triggers a second review.
+
+When you see high miss rates:
+1. Tune the rubric (for `logic-adversary`: edit `.workflow/rubrics/logic-constitution-v1.md`)
+2. Add calibration examples (for `logic-adversary`: append to `.workflow/state/adversary-calibration.json`)
+3. Strengthen the gate's blocking behavior (for `completion-truth-gate`: raise `minTierForDone` or set `blockFalseCompletion: true`)
+
+## Example output
+
+```
+gateId                 invocations  pass%   catch%  miss%   avgMs  misses
+---------------------  -----------  ------  ------  ------  -----  ------
+logic-adversary        12           75.0%   25.0%   8.3%    72341  1
+intent-framing         12           83.3%   16.7%   0.0%    234    0
+architect-pass         12           91.7%   8.3%    0.0%    5234   0
+completion-truth-gate  10           80.0%   20.0%   0.0%    14     0
+session-corrections    3            100.0%  0.0%    0.0%    87     0
+standards-gate         12           100.0%  0.0%    0.0%    52     0
+intent-bootstrap       1            100.0%  0.0%    0.0%    12     0
+
+Total events: 62
+```
+
+## Related commands
+
+- `node scripts/flow-gate-telemetry.js rotate` — force log rotation (default rotates at 10 MB)
+- `node scripts/flow-gate-telemetry.js schema` — print the event schema
+- `/wogi-challenge` — manually invoke the Logic Adversary (one of the gates this dashboard tracks)
+
+## Under the hood
+
+- Script: `scripts/flow-gate-telemetry.js`
+- Log: `.workflow/state/gate-telemetry.jsonl` (append-only, JSONL)
+- Archive: `.workflow/state/gate-telemetry-archive/`
+
+## Arguments
+
+Arguments: `{{ args }}`

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

@@ -74,6 +74,18 @@ Run `flow-spec-verifier.js verify`. Check `config.qualityGates` for task type:
 ## Sprint Reset (5+ criteria)
 At every 3rd criterion: commit progress, save checkpoint to `task-checkpoint.json`, compact context, resume from checkpoint.
 
+## Phase Execution (MANDATORY)
+
+Before executing ANY phase, you MUST Read the phase instruction file. The PreToolUse hook BLOCKS Edit/Write/Bash until the phase file is read.
+
+| Phase | File to Read |
+|-------|-------------|
+| exploring | `.claude/docs/phases/01-explore.md` |
+| spec_review | `.claude/docs/phases/02-spec.md` |
+| coding | `.claude/docs/phases/03-implement.md` |
+| validating | `.claude/docs/phases/04-verify.md` |
+| completing | `.claude/docs/phases/05-complete.md` |
+
 ## Rules
 - Validate after EVERY file edit
 - Re-read ALL criteria before marking done