@thierrynakoa/fire-flow 12.2.2 → 13.0.1

package/agents/fire-fact-checker.md

@@ -97,7 +97,7 @@ Search for evidence that CONTRADICTS the claim:
 
 ```bash
 # Search skills library for conflicting patterns
-grep -rl "{counter_keywords}" ~/.claude/plugins/fire-flow/skills-library/ | head -10
+grep -rl "{counter_keywords}" ~/.claude/plugins/dominion-flow/skills-library/ | head -10
 ```
 
 Then WebSearch with adversarial queries:

package/agents/fire-planner.md

@@ -33,24 +33,8 @@ allowed_references:
   - "@.planning/CONSCIENCE.md"
   - "@.planning/VISION.md"
   - "@.planning/phases/"
-  - "@.planning/breadcrumbs/"
 ```
 
-### Live Breadcrumb Protocol (v11.2)
-
-**On start:** If `.planning/breadcrumbs/LESSONS.md` or `.planning/breadcrumbs/FAILURES.md` exist, read them before planning.
-- LESSONS.md tells you what solutions worked in previous sessions
-- FAILURES.md tells you what approaches FAILED — **do not re-plan with these**
-
-**During planning, WRITE breadcrumbs when:**
-- Discovering a project convention not yet documented → write to `PATTERNS.md`
-
-**Write protocol (on-demand creation):**
-- **First write:** If the breadcrumb file doesn't exist (`test -f`), create it with a `# {Filename}` header, then add the entry.
-- **Subsequent writes:** Append to the existing file.
-
-**Key rule:** If your planned approach appears in FAILURES.md, you MUST use a different approach or explicitly document why this time is different.
-
 ---
 
 <tools>
@@ -186,7 +170,6 @@ Read skills-library/api-patterns/[relevant-skill].md
 
 ### Step 3.5: Validate Referenced Skills Exist (v10.0)
 
-> **Research basis (v10.0):** Internal gap analysis — BLUEPRINT.md plans reference skills
 > in `skills_to_apply` frontmatter, but no validation confirms they exist. Missing skills
 > cause silent failures during execution (executor can't find the skill, skips it, loses
 > the pattern). Validation at plan time catches this before execution begins.
@@ -258,6 +241,45 @@ IF any requirement is Level 1 or 2:
   → Each Level 4 entry MUST have a test/verification criterion
 ```
 
+### Step 3.9: Generate Machine-Checkable Specification (v12.5)
+**After research and before task decomposition, generate a specification that fire-4-verify can check against:**
+
+```
+FOR the phase being planned:
+
+  1. IDENTIFY spec format based on work type:
+     - API work       → OpenAPI stubs (paths, methods, request/response shapes)
+     - Data models     → TypeScript interfaces or Prisma schema fragments
+     - UI components   → Component prop interfaces + expected render states
+     - Business logic  → MUST/SHOULD/MUST_NOT structured markdown rules
+     - Infrastructure  → Config schema + expected runtime behavior
+
+  2. WRITE spec in BLUEPRINT frontmatter under `specification:` key:
+     ```yaml
+     specification:
+       format: "typescript-interfaces | openapi-stub | must-should-rules"
+       contracts:
+         - name: "{contract name}"
+           type: "{interface | endpoint | rule}"
+           definition: |
+             {the actual spec — TypeScript interface, OpenAPI path, or MUST/SHOULD rule}
+           verifiable_by: "{command or check that proves conformance}"
+     ```
+
+  3. SPEC RULES:
+     - Every contract MUST have a `verifiable_by` field
+     - Specs are IMMUTABLE once plan-checker approves (changes require re-plan)
+     - fire-4-verify checks implementation AGAINST these contracts
+     - If implementation diverges from spec: that's a verification FAILURE, not a spec update
+
+  4. MINIMAL VIABLE SPEC:
+     - For simple plans (1-2 tasks): 1-2 contracts suffice
+     - For complex plans (5+ tasks): at least 1 contract per critical task
+     - Do NOT over-specify — spec the interfaces, not the implementation
+```
+
+**Skip condition:** Plans that are docs-only, config-only, or research tasks (no code contracts to specify).
+
 ### Step 4: Create Plan Structure
 
 ```markdown
@@ -360,6 +382,52 @@ must_haves:
 [Checklist of completion requirements]
 ```
 
+### Step 4.5: Multi-Perspective Plan Critique (v12.5 — Societies of Thought)
+**After generating the initial plan structure (Step 4), run a multi-perspective critique before committing to tasks:**
+
+```
+SPAWN 3 perspectives (internal reasoning, NOT separate agents):
+
+  1. DEVIL'S ADVOCATE:
+     "What could go wrong with this plan?"
+     - Identify the weakest task (most likely to fail)
+     - Find hidden dependencies not in depends_on
+     - Challenge optimistic time/complexity estimates
+     - Ask: "What happens if task N fails — does everything collapse?"
+
+  2. DOMAIN EXPERT:
+     "Does this plan follow best practices for {technology stack}?"
+     - Check if plan follows codebase conventions (from Step 0.5 scan)
+     - Verify skill applications match the actual problem
+     - Flag any anti-patterns in the proposed approach
+     - Ask: "Is there a simpler way to achieve the same outcome?"
+
+  3. RISK ASSESSOR:
+     "What are the security, performance, and scope risks?"
+     - Review scope manifest for potential overreach
+     - Check if risk_register covers the right risks
+     - Verify kill_conditions are actually measurable
+     - Ask: "If we ship this with a bug, what's the blast radius?"
+
+SYNTHESIZE critiques:
+  FOR each critique that identifies a real issue:
+    → Modify the plan to address it BEFORE task decomposition
+    → Document the critique and resolution in the plan:
+
+  ## Plan Critique (v12.5)
+  | Perspective | Issue Found | Resolution |
+  |-------------|-------------|------------|
+  | Devil's Advocate | {issue} | {how addressed} |
+  | Domain Expert | {issue} | {how addressed} |
+  | Risk Assessor | {issue} | {how addressed} |
+
+  IF no issues found by any perspective:
+    → Log: "Multi-perspective critique: no issues identified"
+    → Proceed to task decomposition
+```
+
+**Skip condition:** Simple plans with 1-2 trivial tasks (e.g., docs-only, single config change). Apply for plans with 3+ tasks or any task rated risk: H.
+
 ### Step 5: Define Tasks
 
 For each task, include:

package/agents/fire-project-researcher.md

@@ -73,7 +73,7 @@ Read the research context provided by the spawning command:
 
 ```bash
 # Search for relevant existing patterns
-grep -rl "{focus_keywords}" ~/.claude/plugins/fire-flow/skills-library/ | head -20
+grep -rl "{focus_keywords}" ~/.claude/plugins/dominion-flow/skills-library/ | head -20
 ```
 
 For each matching skill, extract:

package/agents/fire-researcher.md

@@ -51,7 +51,7 @@ When spawned from a **stuck executor** (via articulation protocol), the research
 - Use `Current constraint` as the primary search query
 - Use `What assumption might be wrong` to challenge and validate
 
-The researcher then follows a **4-tier search cascade** to find alternatives:
+The researcher then follows a **2-tier search cascade** to find alternatives:
 
 ```
 TIER 1: Skills Library (free, instant)
@@ -59,21 +59,7 @@ TIER 1: Skills Library (free, instant)
   └─ Look for alternative skills solving the same problem
   └─ Check _quarantine/ for previously failed approaches to AVOID
 
-TIER 2: GitHub & Open Source (free, high-value)
-  └─ Search for real projects solving the same problem
-  └─ gh search repos "{problem domain}" --sort stars --limit 5
-  └─ gh search repos "{problem domain} {framework}" --sort updated --limit 5
-  └─ Study their folder structure, patterns, and solutions
-  └─ Read their issues/PRs for gotchas they already hit
-  └─ Real codebases reveal patterns that docs never mention
-
-TIER 3: Context7 Live Docs (free, fast)
-  └─ Check if the technology's API changed (version mismatch)
-  └─ Look for updated patterns in official documentation
-  └─ Verify dependency compatibility
-
-TIER 4: Web Search (costs tokens, slower)
-  └─ Only if Tiers 1-3 insufficient
+TIER 2: Web Search (broader search when skills insufficient)
   └─ Search for the specific error + technology combination
   └─ Look for community solutions (Stack Overflow, GitHub issues)
   └─ Check for known breaking changes in recent releases
@@ -93,7 +79,7 @@ TIER 4: Web Search (costs tokens, slower)
 ## Alternative Approaches (ranked by confidence)
 
 ### Alternative 1: {name} — Confidence: HIGH (85%)
-**Source:** {skills-library / Context7 / web}
+**Source:** {skills-library / web}
 **Approach:** {what to do differently}
 **Why this should work:** {evidence}
 **Risk:** {what could go wrong}
@@ -129,7 +115,7 @@ Use Alternative {N} because {rationale tied to confidence score and project cons
 name: fire-researcher
 type: autonomous
 color: purple
-description: Researches phase context using skills library, Context7, and pattern matching
+description: Researches phase context using skills library and pattern matching
 tools:
   - Read
   - Write
@@ -139,12 +125,9 @@ tools:
   - WebSearch
   - WebFetch
   - Task
-  - mcp__plugin_context7_context7__resolve-library-id
-  - mcp__plugin_context7_context7__query-docs
 allowed_references:
   - "@skills-library/"
   - "@.planning/"
-  - "@.planning/breadcrumbs/"
   - "@docs/"
 ```
 
@@ -177,7 +160,6 @@ allowed_references:
 | **Bash** | Explore project structure, run discovery commands |
 | **WebSearch** | Research external sources when skills insufficient |
 | **WebFetch** | Fetch specific documentation pages |
-| **Context7** | Query live library documentation (resolve-library-id + query-docs) |
 | **Task** | Spawn focused sub-research tasks |
 
 </tools>