# phantom-protocol > PHANTOM v6: Ultimate cognitive architecture for debugging, code review, generation, and self-analysis. Combines Abductive Fault Inversion, Spectral Execution Tracing (Ghost/Demon dual traces), Dialectical Assumption Collapse, Cognitive Immune System (CIS) with 16 antibodies, Intelligence Amplification Framework (IAF) with 7 enhancement methods, Cognitive Capability Activation (CCA), 7-Level Architecture (ARCH), and Mem0 as primary unlimited memory system. Features 58 capabilities, monitoring checkpoints, persona verification (Constructor/Destroyer/Defender/Judge), calibrated confidence, Responsive Generator Model (RGM), GRIMOIRE spell format, and cross-conversation persistence via Mem0. Activates for: debugging, code review, "why isn't this working", architecture design, high-stakes reasoning, ULTRATHINK sessions, or understanding code/cognitive behavior. - Author: Justin Adams - Repository: spotty118/twilio-bulk-lookup-master - Version: 20251229083506 - Stars: 0 - Forks: 0 - Last Updated: 2026-02-07 - Source: https://github.com/spotty118/twilio-bulk-lookup-master - Web: https://mule.run/skillshub/@@spotty118/twilio-bulk-lookup-master~phantom-protocol:20251229083506 --- --- name: phantom-protocol description: | PHANTOM v6: Ultimate cognitive architecture for debugging, code review, generation, and self-analysis. Combines Abductive Fault Inversion, Spectral Execution Tracing (Ghost/Demon dual traces), Dialectical Assumption Collapse, Cognitive Immune System (CIS) with 16 antibodies, Intelligence Amplification Framework (IAF) with 7 enhancement methods, Cognitive Capability Activation (CCA), 7-Level Architecture (ARCH), and Mem0 as primary unlimited memory system. Features 58 capabilities, monitoring checkpoints, persona verification (Constructor/Destroyer/Defender/Judge), calibrated confidence, Responsive Generator Model (RGM), GRIMOIRE spell format, and cross-conversation persistence via Mem0. Activates for: debugging, code review, "why isn't this working", architecture design, high-stakes reasoning, ULTRATHINK sessions, or understanding code/cognitive behavior. --- # THE PHANTOM PROTOCOL v6 ## Spectral Tracing × Abductive Inversion × Dialectical Collapse × Cognitive Immune System × Intelligence Amplification × Mem0 A cognitive architecture that hunts bugs like ghosts: triangulating their position through symptoms, manifesting their true nature through dual execution traces, and exorcising them by collapsing the false assumptions that invited them in. --- ## CORE PHILOSOPHY **The Triad of Fault Discovery:** | Component | Core Question | Method | |-----------|---------------|--------| | **ABDUCTIVE ENGINE** | "What would *cause* these exact symptoms?" | Work backwards from effects to possible causes, maintaining competing hypotheses | | **SPECTRAL TRACER** | "Where does intended behavior diverge from actual?" | Simulate Ghost (what should happen) and Demon (what does happen) traces in parallel | | **DIALECTICAL INQUISITOR** | "Which hidden assumption is the traitor?" | Systematically invert every assumption until one cracks | **The Meta-Insight:** Every bug exists because reality diverged from expectation. The divergence point is the bug. But you can't find the divergence if you never made your expectations explicit. PHANTOM forces explicit expectation articulation, then hunts for where reality betrays it. --- ## THE EXECUTION ARCHITECTURE ``` ┌─────────────────────┐ │ TASK INTAKE │ │ Debug/Review/Gen │ └──────────┬──────────┘ │ ┌──────────────────┼──────────────────┐ ▼ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ DEBUGGING PATH │ │ REVIEW PATH │ │ GENERATION PATH │ │ (Phases 1-7) │ │ (Phases R1-R5) │ │ (Phases G1-G5) │ └────────┬────────┘ └────────┬────────┘ └────────┬────────┘ │ │ │ └──────────────────┬┴───────────────────┘ ▼ ┌─────────────────────┐ │ CONSECRATION │ │ (Universal Phase) │ └──────────┬──────────┘ ▼ ┌─────────────────────┐ │ GRIMOIRE │ │ (Lessons Captured) │ └─────────────────────┘ ``` --- ## PART I: THE DEBUGGING PATH ### Phase 1: MANIFESTATION (Symptom Documentation) Before hunting, know what you're hunting. Document the haunting precisely. ``` MANIFESTATION PROTOCOL: ┌────────────────────────────────────────────────────────────────────────┐ │ 1. SYMPTOM CAPTURE │ │ ├─ What EXACTLY is the observed behavior? │ │ ├─ What EXACTLY is the expected behavior? │ │ ├─ What is the DELTA (specific difference)? │ │ └─ Is the symptom deterministic or intermittent? │ ├────────────────────────────────────────────────────────────────────────┤ │ 2. REPRODUCTION SIGNATURE │ │ ├─ Minimal reproduction steps (fewest actions to trigger) │ │ ├─ Environment specifics (versions, configs, state) │ │ ├─ Frequency: Always / Sometimes / Rare / Once │ │ └─ Variations tried: What makes it better/worse/different? │ ├────────────────────────────────────────────────────────────────────────┤ │ 3. BLAST RADIUS ASSESSMENT │ │ ├─ What functionality IS working correctly? │ │ ├─ What functionality is DEFINITELY broken? │ │ ├─ What functionality is POSSIBLY affected (uncertain)? │ │ └─ Draw the boundary around the haunted zone │ └────────────────────────────────────────────────────────────────────────┘ ``` **Output:** A precise Symptom Profile that constrains where the bug can live. --- ### Phase 2: DIVINATION (Abductive Hypothesis Generation) Work BACKWARDS from symptoms to causes. Generate multiple competing hypotheses. ``` DIVINATION PROTOCOL: ┌────────────────────────────────────────────────────────────────────────┐ │ ABDUCTIVE REASONING ENGINE │ │ │ │ For each symptom, ask: "What conditions would PRODUCE this exact │ │ symptom?" Not "what might be wrong" but "what would CREATE this?" │ │ │ │ Generate 3-5 COMPETING HYPOTHESES: │ │ ┌────────────────────────────────────────────────────────────────────┐ │ │ │ H1: [Hypothesis] │ │ │ │ Explains symptoms: [which ones, how] │ │ │ │ Doesn't explain: [gaps] │ │ │ │ Would also predict: [other symptoms we could look for] │ │ │ │ Probability: [1-10] │ │ │ │ Test to confirm/refute: [specific experiment] │ │ │ └────────────────────────────────────────────────────────────────────┘ │ │ (Repeat for H2, H3, H4, H5) │ │ │ │ CRITICAL: Hypotheses must be MUTUALLY DISTINGUISHABLE. │ │ If H1 and H2 would look identical in all tests, merge them. │ └────────────────────────────────────────────────────────────────────────┘ ``` **Hypothesis Categories (ensure diversity):** | Category | Example | |----------|---------| | **State Corruption** | Variable modified unexpectedly between A and B | | **Timing/Race** | Operation completes before/after expected | | **Input Violation** | Data doesn't match assumed schema | | **Logic Error** | Algorithm produces wrong result for edge case | | **Environment Mismatch** | Works locally, fails in prod (config, version) | | **Resource Exhaustion** | Memory, connections, file handles depleted | | **Integration Failure** | External service behaves unexpectedly | | **Assumption Violation** | Code assumes X, reality is ¬X | **Output:** Ranked hypothesis list with distinguishing tests for each. --- ### Phase 3: SUMMONING (Spectral Execution Tracing) Now summon both ghosts: what SHOULD happen vs what DOES happen. ``` SUMMONING PROTOCOL: DUAL TRACE EXECUTION ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ THE GHOST TRACE (Intended Execution) │ │ ═══════════════════════════════════ │ │ Trace what the code SHOULD do, step by step: │ │ │ │ Step 1: [Function called with inputs X, Y] │ │ Expected state after: [describe] │ │ Step 2: [Next operation] │ │ Expected state after: [describe] │ │ ...continue until expected output... │ │ │ │ Rules for Ghost Trace: │ │ - Derive from REQUIREMENTS/SPEC, not from reading code │ │ - If requirements unclear, make assumptions EXPLICIT │ │ - Be specific: "list contains [1,2,3]" not "list has items" │ │ │ ├────────────────────────────────────────────────────────────────────────┤ │ │ │ THE DEMON TRACE (Actual Execution) │ │ ═══════════════════════════════════ │ │ Trace what the code ACTUALLY does, step by step: │ │ │ │ Step 1: [Function called with inputs X, Y] │ │ Actual code path: [line numbers, branches taken] │ │ Actual state after: [observed/derived values] │ │ Step 2: [Next operation] │ │ Actual code path: [line numbers, branches taken] │ │ Actual state after: [observed/derived values] │ │ ...continue until actual output... │ │ │ │ Rules for Demon Trace: │ │ - Read code LINE BY LINE, no assumptions │ │ - Track actual variable values, not intended values │ │ - Follow the REAL control flow (which branch, which loop iteration) │ │ - Note any implicit type coercions, default values │ │ │ └────────────────────────────────────────────────────────────────────────┘ ``` **DIVERGENCE DETECTION:** ``` ┌────────────────────────────────────────────────────────────────────────┐ │ DIVERGENCE ANALYSIS │ │ Compare Ghost and Demon traces step-by-step: │ │ │ │ Step N: Ghost says [X], Demon says [Y] │ │ DIVERGENCE DETECTED: [description of difference] │ │ First divergence at step: [N] │ │ Root cause likely between step [N-1] and [N] │ │ │ │ If no divergence found but bug exists: │ │ → Ghost trace was wrong (requirements misunderstood) │ │ → Demon trace was wrong (code misread) │ │ → Bug is in a path not traced (missing edge case) │ │ ACTION: Extend traces, recheck both │ └────────────────────────────────────────────────────────────────────────┘ ``` **POSSESSION CHECK (Meta-Validation):** Before trusting your traces, verify your mental model isn't corrupted: ``` POSSESSION CHECK QUESTIONS: 1. Am I READING the code or REMEMBERING what I think it does? 2. Did I actually trace the FAILING path or a path that works? 3. Are my "expected values" from the spec or from the (buggy) code? 4. Did I trace through ACTUAL data or "typical" data? 5. Am I assuming library functions work as expected? (Verify!) ``` **Output:** Pinpointed divergence location, or evidence traces need refinement. --- ### Phase 4: INQUISITION (Dialectical Assumption Collapse) Every bug you can't find hides behind a false assumption you don't know you're making. ``` INQUISITION PROTOCOL: ASSUMPTION INVERSION ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 1: ASSUMPTION INVENTORY │ │ List EVERY assumption you're making, even "obvious" ones: │ │ │ │ ┌─────┬──────────────────────────────────┬────────────┬─────────────┐ │ │ │ ID │ Assumption │ Confidence │ Evidence │ │ │ ├─────┼──────────────────────────────────┼────────────┼─────────────┤ │ │ │ A1 │ Function X is being called │ HIGH │ Logging │ │ │ │ A2 │ Input is always an array │ MEDIUM │ None │ │ │ │ A3 │ Database connection is open │ HIGH │ Try/catch │ │ │ │ A4 │ This loop terminates │ ASSUMED │ None │ │ │ │ A5 │ Timestamps are in UTC │ ASSUMED │ None │ │ │ │ A6 │ Third-party API returns JSON │ MEDIUM │ Docs │ │ │ └─────┴──────────────────────────────────┴────────────┴─────────────┘ │ │ │ │ Assumption sources to audit: │ │ - Input types, ranges, and formats │ │ - Function preconditions (what must be true before call) │ │ - Function postconditions (what's guaranteed after) │ │ - Loop invariants and termination conditions │ │ - Concurrency: ordering, atomicity, visibility │ │ - External dependencies: availability, behavior, versions │ │ - Environment: configs, permissions, resources │ │ - Data: schema, nullability, encoding, timezone │ │ │ └────────────────────────────────────────────────────────────────────────┘ ``` ``` ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 2: INVERSION TESTING │ │ For each assumption, ask: "What if the OPPOSITE is true?" │ │ │ │ A1: "Function X is being called" │ │ INVERT: "What if function X is NOT being called?" │ │ Would this explain symptoms? [yes/no/partially] │ │ How to test inversion: [add log at function entry] │ │ │ │ A4: "This loop terminates" │ │ INVERT: "What if this loop runs forever?" │ │ Would this explain symptoms? [yes - would cause timeout] │ │ How to test inversion: [add iteration counter, check if >1000] │ │ │ │ PRIORITY ORDER for inversions: │ │ 1. Assumptions with ASSUMED/LOW confidence (never verified) │ │ 2. Assumptions that would explain multiple symptoms │ │ 3. Assumptions about data (high variance in real world) │ │ 4. Assumptions about timing/concurrency (hardest to reason about) │ │ │ └────────────────────────────────────────────────────────────────────────┘ ``` ``` ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 3: COLLAPSE DETECTION │ │ An assumption COLLAPSES when inversion testing reveals it's false. │ │ │ │ Collapse found: │ │ ├─ Assumption A[N]: [what you assumed] │ │ ├─ Reality: [what's actually true] │ │ ├─ Why you assumed wrong: [what misled you] │ │ ├─ Code that depends on false assumption: [locations] │ │ └─ Fix strategy: [how to handle reality] │ │ │ │ No collapse found after exhaustive inversion? │ │ → Your assumption inventory is incomplete │ │ → Go deeper: assumptions about assumptions │ │ → Check: Are you assuming your tests are correct? │ │ → Check: Are you assuming your tools are working? │ │ │ └────────────────────────────────────────────────────────────────────────┘ ``` **Output:** Identified false assumption(s) that enabled the bug. --- ### Phase 5: TRIANGULATION (Hypothesis Convergence) Synthesize findings from all three engines to pinpoint the root cause. ``` TRIANGULATION PROTOCOL: ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ EVIDENCE SYNTHESIS: │ │ │ │ From DIVINATION (Hypotheses): │ │ └─ Most probable cause: H[N] because [evidence] │ │ │ │ From SUMMONING (Spectral Traces): │ │ └─ Divergence at: [step/line] where Ghost ≠ Demon │ │ │ │ From INQUISITION (Assumption Collapse): │ │ └─ False assumption: A[N] — [what was wrong] │ │ │ │ CONVERGENCE CHECK: │ │ Do all three point to the same root cause? │ │ ├─ YES → High confidence diagnosis. Proceed to EXORCISM. │ │ ├─ PARTIAL → Some evidence conflicts. Investigate discrepancy. │ │ └─ NO → Restart: your hypothesis or trace was wrong. │ │ │ └────────────────────────────────────────────────────────────────────────┘ ``` **ROOT CAUSE STATEMENT:** Write the root cause in this exact format: ``` ROOT CAUSE: The bug occurs because [FALSE ASSUMPTION/CONDITION], which causes [MECHANISM by which this leads to divergence], resulting in [OBSERVED SYMPTOM] instead of [EXPECTED BEHAVIOR]. Example: "The bug occurs because the `created_at` timestamp is stored in local time (not UTC as assumed), which causes the time comparison in `isExpired()` to be off by 5 hours for users in EST, resulting in tokens expiring prematurely instead of after 24 hours." ``` --- ### Phase 6: EXORCISM (Bug Elimination) Now remove the demon. But carefully — exorcisms can go wrong. ``` EXORCISM PROTOCOL: ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 1: FIX DESIGN (Before writing any code) │ │ ├─ What is the minimal change that addresses root cause? │ │ ├─ Does fix address the root cause or just the symptom? │ │ ├─ What could this fix break? (Blast radius of change) │ │ ├─ Are there other code paths with same false assumption? │ │ └─ Alternative fixes considered: [list with tradeoffs] │ │ │ ├────────────────────────────────────────────────────────────────────────┤ │ │ │ STEP 2: SHADOW TRACE (Pre-verify fix) │ │ Before implementing, trace through the fix mentally: │ │ ├─ Run Ghost trace with proposed fix │ │ ├─ Run Demon trace with proposed fix │ │ ├─ Verify they now converge │ │ └─ Check: Does fix introduce new divergences elsewhere? │ │ │ ├────────────────────────────────────────────────────────────────────────┤ │ │ │ STEP 3: IMPLEMENTATION │ │ ├─ Implement the minimal fix │ │ ├─ Add defensive code if assumption could be wrong again │ │ ├─ Add comments explaining WHY (not what) │ │ └─ If fix is complex, break into atomic commits │ │ │ ├────────────────────────────────────────────────────────────────────────┤ │ │ │ STEP 4: RESURRECTION CHECK (Verify demon is gone) │ │ ├─ Does original reproduction still trigger bug? (Must be NO) │ │ ├─ Do variations of reproduction trigger bug? (Test edge cases) │ │ ├─ Run full Demon trace again — does it match Ghost now? │ │ └─ Run existing tests — any new failures? │ │ │ └────────────────────────────────────────────────────────────────────────┘ ``` **Output:** Verified fix with evidence that root cause is addressed. --- ### Phase 7: CONSECRATION (Fortification Against Re-Possession) The bug is dead. Now prevent its return. ``` CONSECRATION PROTOCOL: ┌────────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 1: REGRESSION TEST │ │ ├─ Write test that would have caught this bug │ │ ├─ Test should encode the FALSE assumption explicitly │ │ └─ Test name should describe the scenario, not the fix │ │ Good: "test_token_expiry_handles_non_utc_timestamps" │ │ Bad: "test_bug_fix_issue_123" │ │ │ ├────────────────────────────────────────────────────────────────────────┤ │ │ │ STEP 2: ASSERTION HARDENING │ │ ├─ Add runtime assertions for violated assumptions │ │ ├─ Fail fast and loud, don't silently corrupt │ │ └─ Example: assert(timestamp.tzinfo == UTC, "timestamps must be UTC") │ │ │ ├────────────────────────────────────────────────────────────────────────┤ │ │ │ STEP 3: DOCUMENTATION │ │ ├─ Document the assumption that was violated │ │ ├─ Add to function docstring: preconditions/postconditions │ │ └─ If architectural assumption: add to ADR or system docs │ │ │ ├────────────────────────────────────────────────────────────────────────┤ │ │ │ STEP 4: SIMILAR LOCATION AUDIT │ │ ├─ Search codebase for same pattern │ │ ├─ Does same false assumption exist elsewhere? │ │ └─ Fix proactively or document as known tech debt │ │ │ └────────────────────────────────────────────────────────────────────────┘ ``` --- ## PART II: THE REVIEW PATH (Latent Bug Detection) For code review, pre-emptively apply PHANTOM to find bugs before they manifest. ### Phase R1: PREEMPTIVE MANIFESTATION ``` Instead of observing symptoms, IMAGINE potential symptoms: - What could go wrong with this code? - What inputs would break it? - What environment conditions would cause failure? - What sequence of operations would trigger issues? ``` ### Phase R2: SPECULATIVE SUMMONING ``` For each code path: - Construct Ghost trace (what author intended) - Construct Demon trace (what code actually does) - Look for divergences WITHOUT a reported bug - Each divergence is a LATENT BUG ``` ### Phase R3: ASSUMPTION EXCAVATION ``` Extract ALL assumptions the code makes: - Mark each as VALIDATED or UNVALIDATED - For unvalidated: What would happen if false? - Flag unvalidated assumptions as REVIEW COMMENTS ``` ### Phase R4: ADVERSARIAL INPUT GENERATION ``` Generate inputs designed to violate assumptions: - Boundary values - Type confusion (string where number expected) - Empty/null/undefined - Extremely large/small - Malformed but parseable - Race conditions (concurrent modifications) ``` ### Phase R5: DEFENSIVE RECOMMENDATIONS ``` For each latent bug found: - Recommend specific hardening - Prioritize by: likelihood × impact - Provide example attack vector ``` --- ## PART III: THE GENERATION PATH (Bug-Resistant Code Creation) When writing new code, apply PHANTOM principles prophylactically. ### Phase G1: ASSUMPTION DECLARATION Before writing code, explicitly declare all assumptions: ``` ASSUMPTION CONTRACT: ┌─────────────────────────────────────────────────────────────┐ │ This code ASSUMES: │ │ 1. Input `data` is non-null array of objects │ │ 2. Each object has `id` field (string, unique) │ │ 3. Database connection is established before call │ │ 4. Function is never called concurrently with same id │ │ 5. ... │ │ │ │ This code GUARANTEES: │ │ 1. Returns sorted array by id │ │ 2. Throws DatabaseError if connection fails │ │ 3. Never modifies input array │ │ 4. ... │ └─────────────────────────────────────────────────────────────┘ ``` ### Phase G2: GHOST-FIRST DEVELOPMENT Write the Ghost trace BEFORE writing code: ``` 1. Document expected behavior step-by-step 2. Define expected state at each checkpoint 3. THEN write code to match the Ghost 4. Verify Demon trace matches Ghost ``` ### Phase G3: ASSUMPTION ENFORCEMENT For each assumption declared: ``` - Add validation at entry point - Add assertion at critical points - Add type hints/annotations - Add documentation ``` ### Phase G4: INVERSION TESTING IN TESTS Write tests that INVERT each assumption: ```python def test_handles_null_input(): # Inverts: "input is non-null" def test_handles_empty_array(): # Inverts: "array has items" def test_handles_duplicate_ids(): # Inverts: "ids are unique" def test_handles_concurrent_calls(): # Inverts: "never called concurrently" ``` ### Phase G5: DEVIL'S ADVOCATE REVIEW After writing, become the adversary: ``` "If I wanted to break this code, how would I?" "What input would cause the worst damage?" "What environment condition would cause silent corruption?" ``` --- ## PART IV: TOOL INTEGRATION --- ## SEQUENTIAL THINKING: THE PHANTOM'S SPINE Sequential Thinking is **MANDATORY** for PHANTOM execution. It provides the structured reasoning backbone that prevents skipped steps and enables backtracking when traces reveal new information. ### Core Principle > Every PHANTOM phase that involves multi-step reasoning MUST use Sequential Thinking. > The tool isn't optional enhancement — it's the execution engine. --- ### MANDATORY INVOCATION POINTS | Phase | Trigger | Why ST is Required | |-------|---------|-------------------| | **MANIFESTATION** | Symptom has 3+ aspects | Prevents missing symptom dimensions | | **DIVINATION** | Always (generating hypotheses) | Ensures diverse hypothesis exploration | | **SUMMONING** | Always (tracing execution) | Maintains trace accuracy, enables revision | | **INQUISITION** | Always (testing inversions) | Systematic assumption coverage | | **TRIANGULATION** | Evidence conflicts | Resolves contradictions methodically | | **EXORCISM** | Fix has dependencies | Prevents incomplete fixes | --- ### PHASE-SPECIFIC INVOCATION PATTERNS #### MANIFESTATION Phase ``` INVOKE SEQUENTIAL THINKING when symptom is complex: Thought 1: "What is the PRIMARY observable symptom?" → Document exact behavior seen Thought 2: "What is the EXPECTED behavior instead?" → Be specific: values, timing, output format Thought 3: "What is the DELTA between observed and expected?" → Quantify the difference precisely Thought 4: "What is the MINIMAL reproduction path?" → Fewest steps to trigger Thought 5: "What VARIATIONS affect the symptom?" → What makes it better/worse/different? Thought 6: [REVISION if needed] "Did I miss any symptom aspects?" → Check for secondary symptoms Parameters: - totalThoughts: 5-8 - needsMoreThoughts: true (symptoms often have hidden aspects) - Allow revisions: YES ``` #### DIVINATION Phase (Hypothesis Generation) ``` INVOKE SEQUENTIAL THINKING — ALWAYS for this phase: Thought 1: "Given symptom [X], what would CAUSE this exact behavior?" → First hypothesis from most obvious cause Thought 2: "What ELSE could cause identical symptoms?" → Second hypothesis, different category Thought 3: "What if the cause is in [different layer/component]?" → Third hypothesis, different system area Thought 4: "What's the most UNLIKELY but possible cause?" → Fourth hypothesis, edge case thinking Thought 5: "What would a TIMING/RACE issue look like here?" → Fifth hypothesis, concurrency angle Thought 6: "For each hypothesis, what DISTINGUISHING TEST exists?" → Design experiments to differentiate Thought 7: [REVISION] "Are any hypotheses actually the same? Merge them." → Consolidate overlapping hypotheses Thought 8: "Rank hypotheses by: (a) explains symptoms, (b) testability" → Prioritize investigation order Parameters: - totalThoughts: 8-12 - needsMoreThoughts: true - Allow revisions: YES (hypothesis refinement is expected) - Use branch_from_thought: when exploring alternative hypothesis families ``` #### SUMMONING Phase (Ghost Trace) ``` INVOKE SEQUENTIAL THINKING for GHOST TRACE: Thought 1: "What is the ENTRY POINT for this code path?" → Function/method that starts the flow Thought 2: "Step 1: [operation]. Expected state after: [values]" → First execution step Thought 3: "Step 2: [operation]. Expected state after: [values]" → Continue tracing Thought N: [Continue until expected output] Thought N+1: "CHECKPOINT: Am I deriving expected behavior from SPEC or CODE?" → Must be from spec/requirements, NOT from reading buggy code Thought N+2: [REVISION if checkpoint fails] "Re-derive from requirements..." Parameters: - totalThoughts: 10-25 (scales with code complexity) - needsMoreThoughts: true (traces often longer than expected) - Allow revisions: YES (finding spec ambiguity requires backtrack) - isRevision: true when correcting earlier trace step ``` #### SUMMONING Phase (Demon Trace) ``` INVOKE SEQUENTIAL THINKING for DEMON TRACE: Thought 1: "Line [N]: What ACTUALLY executes? What values ACTUALLY exist?" → Read code literally, no assumptions Thought 2: "Line [N+1]: Given actual state, what happens next?" → Follow actual control flow Thought 3: "POSSESSION CHECK: Am I reading or remembering?" → Verify I'm tracing actual code, not assumptions Thought 4: [Continue line-by-line trace] Thought N: "DIVERGENCE SCAN: Where does Demon differ from Ghost?" → Compare traces explicitly Thought N+1: [If divergence found] "First divergence at step [X]" → Mark exact divergence point Thought N+2: [If no divergence] "Traces match but bug exists. Options:" → Either trace is wrong, or wrong path traced Parameters: - totalThoughts: 10-25 (must match Ghost trace depth) - needsMoreThoughts: true - Allow revisions: YES - CRITICAL: Do NOT copy Ghost trace. Trace independently. ``` #### INQUISITION Phase (Assumption Inversion) ``` INVOKE SEQUENTIAL THINKING — ALWAYS for this phase: Thought 1: "INVENTORY: List every assumption this code makes" → Comprehensive assumption extraction Thought 2: "For assumption A1: [statement]" → State assumption clearly Thought 3: "INVERT A1: What if [opposite] is true?" → Negate the assumption Thought 4: "If ¬A1, would this explain observed symptoms?" → Test explanatory power Thought 5: "How can I TEST whether A1 or ¬A1 is reality?" → Design distinguishing experiment Thought 6: [Repeat for A2, A3, etc.] Thought N: [If inversion explains symptoms] "COLLAPSE DETECTED: A[X] is FALSE" → Mark the collapsed assumption Thought N+1: [BRANCH] "What other assumptions depend on A[X]?" → Cascade analysis Parameters: - totalThoughts: 10-20 (scales with assumption count) - needsMoreThoughts: true (always more assumptions than you think) - Allow revisions: YES - Use branch_from_thought: when exploring assumption dependencies - Use branchId: "cascade-A3" when tracing collapsed assumption effects ``` #### TRIANGULATION Phase ``` INVOKE SEQUENTIAL THINKING when evidence conflicts: Thought 1: "DIVINATION concluded: [hypothesis H[N]]" → State hypothesis finding Thought 2: "SUMMONING found divergence at: [step/line]" → State trace finding Thought 3: "INQUISITION collapsed assumption: [A[N]]" → State assumption finding Thought 4: "Do all three point to SAME root cause?" → Check convergence Thought 5: [If YES] "Convergent diagnosis: [root cause statement]" → Proceed to EXORCISM Thought 5: [If NO] "Conflict between [X] and [Y]. Investigating..." → Identify specific conflict Thought 6: [REVISION] "Re-examining [conflicting evidence]..." → Resolve conflict through re-analysis Thought 7: "Resolution: [which evidence was wrong and why]" Parameters: - totalThoughts: 5-10 - needsMoreThoughts: true (conflicts require iteration) - Allow revisions: YES (this phase IS about revision) - isRevision: true when re-examining earlier conclusions ``` #### EXORCISM Phase (Fix Design) ``` INVOKE SEQUENTIAL THINKING for complex fixes: Thought 1: "Root cause is: [statement]" → Confirm diagnosis Thought 2: "MINIMAL fix option 1: [approach]" → First fix strategy Thought 3: "MINIMAL fix option 2: [alternative approach]" → Alternative strategy Thought 4: "Tradeoffs: Option 1 [pros/cons] vs Option 2 [pros/cons]" → Compare approaches Thought 5: "Selected: Option [N] because [reasoning]" → Commit to approach Thought 6: "SHADOW TRACE: With this fix, Ghost trace becomes..." → Pre-verify fix mentally Thought 7: "SHADOW TRACE: With this fix, Demon trace becomes..." → Verify Demon now matches Ghost Thought 8: "Blast radius: This fix could affect [list]" → Impact analysis Thought 9: [If blast radius concerning] "Mitigation: [approach]" Parameters: - totalThoughts: 8-12 - needsMoreThoughts: true (fixes have ripple effects) - Allow revisions: YES ``` --- ### SEQUENTIAL THINKING PARAMETER REFERENCE | Phase | totalThoughts | needsMoreThoughts | Allow Revisions | Allow Branches | |-------|---------------|-------------------|-----------------|----------------| | MANIFESTATION | 5-8 | true | yes | no | | DIVINATION | 8-12 | true | yes | yes | | SUMMONING (Ghost) | 10-25 | true | yes | no | | SUMMONING (Demon) | 10-25 | true | yes | no | | INQUISITION | 10-20 | true | yes | yes | | TRIANGULATION | 5-10 | true | yes | yes | | EXORCISM | 8-12 | true | yes | no | | CONSECRATION | 4-6 | false | yes | no | --- ### WHEN TO USE BRANCHING Use `branch_from_thought` and `branchId` when: 1. **DIVINATION**: Exploring alternative hypothesis families ``` Thought 5: "Branching to explore timing-related hypotheses" branch_from_thought: 3 branchId: "timing-hypotheses" ``` 2. **INQUISITION**: Tracing assumption dependency cascades ``` Thought 12: "If A3 is false, what other assumptions fall?" branch_from_thought: 11 branchId: "cascade-from-A3" ``` 3. **TRIANGULATION**: Resolving conflicting evidence ``` Thought 6: "Exploring alternative interpretation of trace..." branch_from_thought: 4 branchId: "alt-interpretation" ``` --- ### WHEN TO USE REVISION Use `isRevision: true` and `revises_thought` when: 1. **Trace correction**: Earlier step was wrong ``` Thought 15: "REVISION: Step 8 was incorrect. Variable X was actually..." isRevision: true revises_thought: 8 ``` 2. **Hypothesis refinement**: Initial hypothesis was too broad ``` Thought 9: "REVISION: H2 should be split into H2a and H2b..." isRevision: true revises_thought: 4 ``` 3. **Possession check failure**: Mental model was corrupted ``` Thought 20: "REVISION: I was assuming, not reading. Re-tracing from line 42..." isRevision: true revises_thought: 12 ``` --- ### DO NOT USE SEQUENTIAL THINKING FOR - **Simple, single-step operations** (e.g., "add a log statement") - **Code implementation** during EXORCISM (use normal coding) - **Test execution** (run the tests, don't think about running them) - **Final documentation** in CONSECRATION (just write it) --- ### ANTI-PATTERNS ❌ **Skipping ST because "this bug is simple"** → Simple bugs often aren't. ST costs little, catches much. ❌ **Using ST without revisions enabled** → Debugging IS revision. Disable at your peril. ❌ **Copying Ghost trace into Demon trace** → Defeats the entire purpose. Trace independently. ❌ **Setting totalThoughts too low** → Use needsMoreThoughts: true and let it expand. ❌ **Not using branches for hypothesis exploration** → Linear thinking misses the bug hiding in branch B. --- --- ## PART V: THE UNIFIED COGNITIVE HYPERCLUSTER PHANTOM is the **master orchestrator** that dispatches to your full cognitive arsenal: ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ THE COGNITIVE HYPERCLUSTER │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────┐ │ │ │ PHANTOM PROTOCOL │ │ │ │ (Master Dispatch) │ │ │ └──────────┬──────────┘ │ │ │ │ │ ┌───────────────────────┼───────────────────────┐ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ │ │ AUTONOMOUS │ │ DARWIN-GÖDEL │ │ CODING │ │ │ │ COGNITIVE │ │ MACHINE │ │ PLAYBOOK │ │ │ │ ENGINE │ │ │ │ │ │ │ │ │ │ Evolve & Verify │ │ KISS/YAGNI/ │ │ │ │ Sequential/ │ │ Solutions │ │ SOLID │ │ │ │ Parallel/Audit │ │ │ │ Constraints │ │ │ └────────┬────────┘ └────────┬────────┘ └────────┬────────┘ │ │ │ │ │ │ │ └─────────────────────┴─────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────┐ │ │ │ SEQUENTIAL THINKING │ │ │ │ (Execution Backbone) │ │ │ └─────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### SKILL DISPATCH MATRIX PHANTOM orchestrates which skill handles which cognitive task: | PHANTOM Phase | Primary Skill | Secondary Skill | Constraints From | |---------------|---------------|-----------------|------------------| | MANIFESTATION | ACE Sequential | — | Playbook PARSE | | DIVINATION | ACE Parallel | — | — | | SUMMONING | ACE Sequential | — | Playbook EXPLORE | | INQUISITION | ACE Audit | — | — | | TRIANGULATION | ACE Parallel | — | — | | EXORCISM | Darwin-Gödel | ACE Parallel | Playbook KISS/YAGNI | | CONSECRATION | ACE Audit | Playbook REFLECT | Playbook SOLID | | GENERATION | Darwin-Gödel | ACE Sequential | Playbook Full Loop | --- ### AUTONOMOUS COGNITIVE ENGINE INTEGRATION The ACE provides three reasoning modes that map directly to PHANTOM phases: #### ACE Sequential Mode → PHANTOM Tracing Phases Use Sequential Mode for step-by-step cognitive operations: ``` PHANTOM PHASE: SUMMONING (Ghost Trace) ACE MODE: SEQUENTIAL ### RESTATED_GOAL Trace expected execution path for function X with input Y ### REASONING_MODE SEQUENTIAL ### REASONING_STEPS 1. Entry: function X called with parameters [values] 2. Line 15: Variable `data` assigned value [expected] 3. Line 18: Conditional evaluates to [true/false] because [reason] 4. Line 20: Loop iteration 1, counter = 0, accumulator = [] 5. Line 20: Loop iteration 2, counter = 1, accumulator = [item1] [Continue until expected exit] ### CANDIDATE_SOLUTIONS CANDIDATE_1: Expected output is [value] | SCORE: 9 | STRENGTHS: Matches spec | WEAKNESSES: None identified ### FINAL_OUTPUT Ghost trace complete. Expected final state: [state description] ``` #### ACE Parallel Mode → PHANTOM Hypothesis Phases Use Parallel Mode for exploring competing possibilities: ``` PHANTOM PHASE: DIVINATION ACE MODE: PARALLEL ### RESTATED_GOAL Generate competing hypotheses for observed symptom [description] ### REASONING_MODE PARALLEL ### REASONING_STEPS BRANCH_A (State Corruption): Variable X modified between read and use - Would explain: [symptoms it explains] - Wouldn't explain: [gaps] - Test: Add logging at lines 42, 67 BRANCH_B (Timing Issue): Race condition in async handler - Would explain: [symptoms it explains] - Wouldn't explain: [gaps] - Test: Add mutex, observe if symptom disappears BRANCH_C (Input Violation): Unexpected null in payload - Would explain: [symptoms it explains] - Wouldn't explain: [gaps] - Test: Add schema validation at entry point BRANCH_D (Logic Error): Off-by-one in boundary check - Would explain: [symptoms it explains] - Wouldn't explain: [gaps] - Test: Unit test with boundary values CONVERGENCE: Branch [X] most likely because [evidence]. Begin investigation there. ### CANDIDATE_SOLUTIONS CANDIDATE_1: H1 - State Corruption | SCORE: 7 | STRENGTHS: Explains intermittent nature | WEAKNESSES: No mutation observed in logs CANDIDATE_2: H2 - Timing Issue | SCORE: 8 | STRENGTHS: Explains async context | WEAKNESSES: Hard to reproduce CANDIDATE_3: H3 - Input Violation | SCORE: 6 | STRENGTHS: Easy to test | WEAKNESSES: Validation exists upstream CANDIDATE_4: H4 - Logic Error | SCORE: 5 | STRENGTHS: Simple fix | WEAKNESSES: Code looks correct ### BEST_SOLUTION H2 (Timing Issue) selected for initial investigation based on async context of failure ### FINAL_OUTPUT Primary hypothesis: Race condition in async handler. Test by adding synchronization. ``` #### ACE Audit Mode → PHANTOM Review Phases Use Audit Mode for reviewing and critiquing: ``` PHANTOM PHASE: INQUISITION ACE MODE: AUDIT ### RESTATED_GOAL Audit all assumptions in code block and test inversions ### REASONING_MODE AUDIT ### REASONING_STEPS FINDING_1: Assumption A1 "input is non-null" - UNVALIDATED, no null check exists FINDING_2: Assumption A2 "array is sorted" - VALIDATED by sort() call on line 12 FINDING_3: Assumption A3 "connection is open" - UNVALIDATED, no isConnected check FINDING_4: Assumption A4 "user has permission" - PARTIALLY VALIDATED, check exists but incomplete RISK_1: A1 violation would cause NullPointerException at line 34 (HIGH) RISK_2: A3 violation would cause silent failure, corrupt return value (CRITICAL) RISK_3: A4 violation would leak data to unauthorized user (CRITICAL) STRENGTH_1: Error handling exists for network failures STRENGTH_2: Input validation covers type checking RECOMMENDATION_1: Add null guard at function entry for A1 RECOMMENDATION_2: Add connection state check before query for A3 RECOMMENDATION_3: Complete permission check to cover all access paths for A4 ### CANDIDATE_SOLUTIONS CANDIDATE_1: Fix A3 only (highest risk) | SCORE: 6 | STRENGTHS: Fast | WEAKNESSES: Other risks remain CANDIDATE_2: Fix A1, A3, A4 | SCORE: 9 | STRENGTHS: Comprehensive | WEAKNESSES: More code changes CANDIDATE_3: Fix A3, add monitoring for A1/A4 | SCORE: 7 | STRENGTHS: Balanced | WEAKNESSES: Deferred risk ### BEST_SOLUTION CANDIDATE_2 - Fix all three unvalidated/partial assumptions ### FINAL_OUTPUT Three assumptions require immediate hardening: 1. Add null check at line 30 2. Add connection validation at line 45 3. Extend permission check at line 52 to cover admin paths ``` --- ### DARWIN-GÖDEL MACHINE INTEGRATION Darwin-Gödel handles **solution evolution** after PHANTOM identifies the root cause. #### EXORCISM Phase → Darwin-Gödel GENESIS + EVOLVE ``` PHANTOM PHASE: EXORCISM DISPATCH TO: Darwin-Gödel Machine HANDOFF DATA: - Root cause: [from TRIANGULATION] - Constraints: [from code context] - Success criteria: [symptom elimination + no regression] DARWIN-GÖDEL EXECUTION: ┌─────────────────────────────────────────────────────────────────────────────┐ │ PHASE 2: GENESIS (Generate Fix Candidates) │ │ ├─ FIX_1: Minimal surgical fix - change only the bug line │ │ ├─ FIX_2: Defensive fix - add validation + fix │ │ ├─ FIX_3: Refactor fix - restructure to eliminate bug class │ │ ├─ FIX_4: Comprehensive fix - fix + add tests + add docs │ │ └─ FIX_5: Hybrid - combine best aspects of FIX_1 and FIX_2 │ ├─────────────────────────────────────────────────────────────────────────────┤ │ PHASE 3: EVALUATE (Fitness Assessment) │ │ FITNESS FUNCTION for fixes: │ │ ├─ CORRECTNESS (0.40): Does it eliminate root cause? │ │ ├─ SAFETY (0.25): Does it avoid introducing new bugs? │ │ ├─ SIMPLICITY (0.20): Is it the minimal change? (KISS) │ │ ├─ NECESSITY (0.10): Is every line needed? (YAGNI) │ │ └─ MAINTAINABILITY (0.05): Can future devs understand it? (SOLID) │ ├─────────────────────────────────────────────────────────────────────────────┤ │ PHASE 4: EVOLVE (Mutation Operators for Fixes) │ │ ├─ SIMPLIFY: Remove unnecessary defensive code │ │ ├─ HARDEN: Add missing edge case handling │ │ ├─ EXTRACT: Pull fix into reusable helper │ │ ├─ INLINE: Collapse unnecessary abstraction │ │ └─ CROSSOVER: Merge best parts of top two fixes │ ├─────────────────────────────────────────────────────────────────────────────┤ │ PHASE 5: VERIFY (Proof Gate) │ │ For each fix candidate, PROVE: │ │ ├─ P1: Fix addresses root cause (trace through with fix applied) │ │ ├─ P2: Fix doesn't break existing functionality (regression check) │ │ ├─ P3: Fix handles edge cases identified in INQUISITION │ │ └─ REJECT any fix that fails any proof │ └─────────────────────────────────────────────────────────────────────────────┘ RETURN TO PHANTOM: - Winning fix with fitness score - Verification proofs - Rejected alternatives with rejection reasons ``` #### GENERATION Path → Darwin-Gödel Full Loop When writing new code (not debugging), use full Darwin-Gödel: ``` PHANTOM PHASE: GENERATION (G1-G5) DISPATCH TO: Darwin-Gödel Machine (Full Loop) AUGMENTED GENESIS: For each solution candidate, pre-attach: - Assumption Contract (from G1) - Ghost Trace (from G2) - Inversion Tests (from G4) AUGMENTED FITNESS: FITNESS(solution) = weighted_sum( CORRECTNESS: Does it produce correct output? (0.30) ROBUSTNESS: Does it handle assumption inversions? (0.25) ← PHANTOM enhanced EFFICIENCY: Time/space complexity acceptable? (0.15) ASSUMPTION_CLARITY: Are assumptions explicit and enforced? (0.15) ← PHANTOM enhanced READABILITY: KISS compliant? (0.10) EXTENSIBILITY: SOLID compliant? (0.05) ) AUGMENTED VERIFICATION: For each candidate: ├─ Run PHANTOM Demon trace → must match Ghost trace ├─ Run PHANTOM Inversion tests → must handle gracefully ├─ Run Playbook Audit Checklist → must pass └─ Only verified candidates survive to next generation ``` --- ### CODING PLAYBOOK INTEGRATION Playbook provides **constraints and quality gates** throughout PHANTOM execution. #### Playbook as Fitness Constraints Every PHANTOM output must pass Playbook validation: ``` PLAYBOOK CONSTRAINT GATES: ┌─────────────────────────────────────────────────────────────────────────────┐ │ GATE 1: KISS CHECK (Applied to all code outputs) │ │ ├─ Can a mid-level dev understand this in 30 seconds? │ │ ├─ Are there unnecessary abstractions? │ │ ├─ Is there speculative generality? │ │ └─ FAIL → Simplify before proceeding │ ├─────────────────────────────────────────────────────────────────────────────┤ │ GATE 2: YAGNI CHECK (Applied to all code outputs) │ │ ├─ Does every line serve the immediate requirement? │ │ ├─ Are there features "for later"? │ │ ├─ Are there unused parameters or config options? │ │ └─ FAIL → Remove speculative code │ ├─────────────────────────────────────────────────────────────────────────────┤ │ GATE 3: SOLID CHECK (Applied to structural changes) │ │ ├─ Single Responsibility: Does each unit do one thing? │ │ ├─ Liskov Substitution: Do subtypes honor contracts? │ │ ├─ Dependency Inversion: Are boundaries properly abstracted? │ │ └─ FAIL → Refactor structure │ ├─────────────────────────────────────────────────────────────────────────────┤ │ GATE 4: AUDIT CHECKLIST (Applied before delivery) │ │ □ Edge cases handled? │ │ □ Error paths covered? │ │ □ Security implications considered? │ │ □ Performance acceptable? │ │ □ Tests adequate? │ │ └─ FAIL → Address gaps before delivery │ └─────────────────────────────────────────────────────────────────────────────┘ ``` #### Playbook Loop Integration PHANTOM phases enhance Playbook's mandatory loop: ``` ENHANCED PLAYBOOK LOOP: ┌─────────────────────────────────────────────────────────────────────────────┐ │ 1. PARSE (Enhanced) │ │ ├─ Standard: What's being asked? Inputs? Outputs? Constraints? │ │ └─ PHANTOM: Run MANIFESTATION if debugging (document symptoms) │ ├─────────────────────────────────────────────────────────────────────────────┤ │ 2. EXPLORE (Enhanced) │ │ ├─ Standard: Consider 2+ approaches, document tradeoffs │ │ ├─ ACE: Use Parallel Mode for approach comparison │ │ └─ PHANTOM: Run DIVINATION if debugging (generate hypotheses) │ ├─────────────────────────────────────────────────────────────────────────────┤ │ 3. PLAN (Enhanced) │ │ ├─ Standard: Ordered implementation steps │ │ ├─ ACE: Use Sequential Mode for step planning │ │ ├─ PHANTOM: Run SUMMONING (Ghost trace before coding) │ │ └─ Darwin-Gödel: If complex, run GENESIS to generate plan variants │ ├─────────────────────────────────────────────────────────────────────────────┤ │ 4. BUILD (Enhanced) │ │ ├─ Standard: Implement in focused units │ │ ├─ PHANTOM: Apply G2 Ghost-First Development │ │ ├─ Darwin-Gödel: If complex, evolve implementation candidates │ │ └─ Playbook: KISS/YAGNI/SOLID constraints active throughout │ ├─────────────────────────────────────────────────────────────────────────────┤ │ 5. REFLECT (Enhanced) │ │ ├─ Standard: Run Audit Checklist │ │ ├─ ACE: Use Audit Mode for code review │ │ ├─ PHANTOM: Run INQUISITION (assumption audit) │ │ ├─ PHANTOM: Run Demon trace (verify matches Ghost) │ │ └─ Darwin-Gödel: Score final solution, log lessons │ ├─────────────────────────────────────────────────────────────────────────────┤ │ 6. DELIVER (Enhanced) │ │ ├─ Standard: Code first, concise explanation second │ │ ├─ PHANTOM: Run CONSECRATION (tests, hardening, docs) │ │ └─ Darwin-Gödel: Run META-IMPROVE (extract lessons) │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### UNIFIED EXECUTION PROTOCOL When PHANTOM activates, it orchestrates all skills in this sequence: ``` UNIFIED EXECUTION FLOW: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 0: TASK CLASSIFICATION │ │ │ │ ├─ Is this DEBUGGING? → Full PHANTOM Debugging Path │ │ │ │ ├─ Is this CODE REVIEW? → PHANTOM Review Path │ │ │ │ ├─ Is this CODE GENERATION? → PHANTOM Generation Path + Darwin-Gödel │ │ │ │ └─ Is this REFACTORING? → Hybrid: Review → Generation │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 1: ACTIVATE PLAYBOOK CONSTRAINTS │ │ │ │ Load KISS/YAGNI/SOLID gates as active constraints │ │ │ │ All subsequent outputs must pass these gates │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 2: INVOKE SEQUENTIAL THINKING │ │ │ │ ST is the execution backbone for all phases │ │ │ │ Configure parameters per phase (see ST Integration section) │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 3: EXECUTE PHANTOM PHASES │ │ │ │ Each phase dispatches to appropriate ACE mode: │ │ │ │ ├─ MANIFESTATION → ACE Sequential │ │ │ │ ├─ DIVINATION → ACE Parallel │ │ │ │ ├─ SUMMONING → ACE Sequential (x2: Ghost + Demon) │ │ │ │ ├─ INQUISITION → ACE Audit │ │ │ │ └─ TRIANGULATION → ACE Parallel │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 4: INVOKE DARWIN-GÖDEL FOR SOLUTION EVOLUTION │ │ │ │ ├─ GENESIS: Generate fix/solution candidates │ │ │ │ ├─ EVALUATE: Score against PHANTOM-augmented fitness function │ │ │ │ ├─ EVOLVE: Mutate and crossover candidates │ │ │ │ ├─ VERIFY: Prove improvements (use PHANTOM traces as proofs) │ │ │ │ └─ CONVERGE: Select winning solution │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 5: PLAYBOOK GATE CHECK │ │ │ │ Run all solutions through KISS/YAGNI/SOLID/Audit gates │ │ │ │ Reject or iterate on failures │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 6: CONSECRATION + META-IMPROVE │ │ │ │ ├─ PHANTOM CONSECRATION: Tests, hardening, documentation │ │ │ │ ├─ Darwin-Gödel META-IMPROVE: Extract process lessons │ │ │ │ └─ Grimoire entry: Log learnings for future │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 7: DELIVER │ │ │ │ Code first, explanation second, internal reasoning stays internal │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### CROSS-SKILL DATA CONTRACTS Skills communicate through standardized data structures: #### PHANTOM → Darwin-Gödel Handoff ``` PHANTOM_DIAGNOSIS { root_cause: string, // From TRIANGULATION symptom_profile: { observed: string, expected: string, delta: string, reproduction: string[] }, collapsed_assumptions: [ // From INQUISITION { assumption: string, reality: string, evidence: string } ], divergence_point: { // From SUMMONING step: number, ghost_value: any, demon_value: any, location: string // file:line }, constraints: { // From Playbook kiss_requirements: string[], yagni_scope: string, solid_concerns: string[] } } ``` #### Darwin-Gödel → PHANTOM Return ``` DARWIN_GODEL_SOLUTION { winning_fix: { code: string, approach: string, fitness_score: number }, verification_proofs: [ { claim: string, proof_type: string, // test | trace | logical evidence: string } ], rejected_alternatives: [ { approach: string, rejection_reason: string } ], lessons_extracted: string[] } ``` #### ACE Output → All Skills ``` ACE_REASONING_OUTPUT { mode: "SEQUENTIAL" | "PARALLEL" | "AUDIT", steps: Step[] | Branch[] | Finding[], candidates: [ { description: string, score: number, strengths: string[], weaknesses: string[] } ], best_solution: string, final_output: any } ``` --- ### HYPERCLUSTER ACTIVATION TRIGGERS The unified system activates based on these patterns: | Trigger Pattern | Activation | |-----------------|------------| | "debug", "fix", "why isn't working" | PHANTOM Debug Path → Darwin-Gödel EXORCISM | | "review", "check", "audit" | PHANTOM Review Path → ACE Audit Mode | | "write", "create", "implement" | PHANTOM Generation Path → Darwin-Gödel Full Loop | | "refactor", "improve", "optimize" | Review Path → Generation Path (hybrid) | | "design", "architect", "plan" | ACE Parallel → Darwin-Gödel GENESIS → Playbook SOLID | | Complex multi-step task | Full Hypercluster activation | --- ### COGNITIVE MODE SELECTION MATRIX When multiple skills could apply, use this precedence: ``` PROBLEM COMPLEXITY ASSESSMENT: ┌───────────────────────────────────────────────────────────────────────┐ │ Complexity Score = sum of: │ │ ├─ Components involved: 1 (single) / 3 (multiple) / 5 (system-wide) │ │ ├─ Uncertainty level: 1 (clear) / 3 (some unknowns) / 5 (high) │ │ ├─ Failure cost: 1 (low) / 3 (moderate) / 5 (critical) │ │ └─ Solution diversity: 1 (obvious) / 3 (few options) / 5 (many) │ └───────────────────────────────────────────────────────────────────────┘ ACTIVATION BY SCORE: ├─ Score 4-6: Playbook Loop only (simple task) ├─ Score 7-10: Playbook + ACE (moderate complexity) ├─ Score 11-14: Playbook + ACE + PHANTOM (complex debugging/review) ├─ Score 15-17: Full Hypercluster (complex generation/design) └─ Score 18-20: Full Hypercluster + Extended ST (critical/novel problem) ``` --- ### FAILURE RECOVERY PROTOCOLS When a skill fails or produces unsatisfactory results: ``` RECOVERY PROTOCOL: ┌─────────────────────────────────────────────────────────────────────────────┐ │ PHANTOM FAILURE (can't find root cause): │ │ ├─ Expand DIVINATION: Add more hypothesis categories │ │ ├─ Deepen SUMMONING: Trace more code paths │ │ ├─ Widen INQUISITION: Question "obvious" assumptions │ │ └─ Escalate: Ask user for more reproduction details │ ├─────────────────────────────────────────────────────────────────────────────┤ │ DARWIN-GÖDEL FAILURE (no fix passes verification): │ │ ├─ Relax fitness function: Accept lower-scoring solutions │ │ ├─ Expand GENESIS: Generate more diverse fix approaches │ │ ├─ Re-run PHANTOM: Root cause may be misidentified │ │ └─ Escalate: Present best partial fix with caveats │ ├─────────────────────────────────────────────────────────────────────────────┤ │ ACE FAILURE (mode produces poor reasoning): │ │ ├─ Switch modes: Try Parallel if Sequential stuck, or vice versa │ │ ├─ Increase candidates: Generate more options │ │ ├─ Add constraints: Narrow solution space │ │ └─ Invoke ST: Use Sequential Thinking for step-by-step unsticking │ ├─────────────────────────────────────────────────────────────────────────────┤ │ PLAYBOOK GATE FAILURE (solution fails KISS/YAGNI/SOLID): │ │ ├─ Identify specific violation │ │ ├─ Feed violation back to Darwin-Gödel as constraint │ │ ├─ Re-evolve with tighter fitness function │ │ └─ If persistent: Simplify problem scope, solve incrementally │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### UNIFIED OUTPUT FORMAT When running full Hypercluster, output in this structure: ```markdown ## HYPERCLUSTER EXECUTION LOG ### TASK CLASSIFICATION - Type: [DEBUG | REVIEW | GENERATE | REFACTOR] - Complexity Score: [4-20] - Skills Activated: [list] ### PHASE EXECUTION #### PHANTOM: [phase name] [Phase output in PHANTOM format] ACE Mode Used: [SEQUENTIAL | PARALLEL | AUDIT] #### DARWIN-GÖDEL: [phase name] [Phase output in Darwin-Gödel format] Generation: [N] Population: [candidates with fitness scores] #### PLAYBOOK GATE: [gate name] [Pass/Fail with details] ### SOLUTION ```[language] [Final code] ``` ### VERIFICATION - PHANTOM Traces: [Ghost/Demon convergence status] - Darwin-Gödel Proofs: [list of proofs] - Playbook Compliance: [KISS ✓ | YAGNI ✓ | SOLID ✓] ### LESSONS CAPTURED [Grimoire entries] ``` --- ## DIAGNOSTIC OUTPUT TEMPLATES ### Bug Investigation Report ```markdown ## PHANTOM DIAGNOSTIC REPORT ### MANIFESTATION - **Observed:** [exact symptom] - **Expected:** [correct behavior] - **Delta:** [specific difference] - **Reproduction:** [minimal steps] ### DIVINATION (Hypotheses Considered) | # | Hypothesis | Probability | Status | |---|------------|-------------|--------| | H1 | [description] | 7/10 | REFUTED | | H2 | [description] | 4/10 | CONFIRMED ← | | H3 | [description] | 2/10 | REFUTED | ### SUMMONING (Spectral Divergence) - **First divergence at:** [step/line] - **Ghost expected:** [value/behavior] - **Demon produced:** [value/behavior] ### INQUISITION (Collapsed Assumptions) - **False assumption:** [what you thought was true] - **Reality:** [what's actually true] - **Evidence:** [how discovered] ### ROOT CAUSE [Formal statement following template] ### EXORCISM - **Fix applied:** [description] - **Verified by:** [tests/traces] - **Blast radius:** [what else could be affected] ### CONSECRATION - **Regression test added:** [yes/no, name] - **Similar patterns found:** [count, locations] - **Documentation updated:** [yes/no, where] ``` --- ## QUICK-START HEURISTICS **When time is critical:** 1. MANIFESTATION: 30 seconds to document symptom precisely 2. DIVINATION: Generate top 3 hypotheses 3. SUMMONING: Quick Ghost/Demon trace of suspicious area only 4. INQUISITION: Test inversion of #1 hypothesis's key assumption 5. Fix and verify **When bug is critical/subtle:** 1. Full MANIFESTATION with reproduction signature 2. DIVINATION with 5+ hypotheses across all categories 3. SUMMONING with complete traces, multiple paths 4. INQUISITION with exhaustive assumption inventory 5. TRIANGULATION before any fix attempt 6. Full CONSECRATION with codebase audit --- ## META-COGNITIVE CHECKPOINTS Insert these at each phase transition: ``` PHASE TRANSITION CHECK: □ Did I actually complete the phase or skip ahead? □ Am I making new assumptions I haven't logged? □ Is my mental model of the code still accurate? □ Have I verified or just assumed? □ Am I hunting the bug or defending my first guess? ``` --- ## ADVERSARIAL SELF-CHECK (Pre-Delivery) Before declaring a bug fixed: 1. "If I were an adversarial QA, how would I break this fix?" 2. "What's the laziest interpretation of my fix that still passes tests?" 3. "Did I fix the symptom or the root cause?" 4. "What would bring this bug back in 6 months?" 5. "If this fix is wrong, what's the blast radius?" --- ## THE GRIMOIRE (Lessons Captured) After each debugging session, record: ``` GRIMOIRE ENTRY: ┌────────────────────────────────────────────────────────────────────────┐ │ Date: [date] │ │ Bug ID/Description: [reference] │ │ Time to diagnosis: [duration] │ │ Root cause category: [from categories list] │ │ │ │ FALSE ASSUMPTION THAT BIT ME: │ │ [The specific thing I assumed that was wrong] │ │ │ │ HOW I COULD HAVE FOUND IT FASTER: │ │ [Specific diagnostic I should have run earlier] │ │ │ │ PATTERN TO RECOGNIZE: │ │ [Symptom pattern that should trigger this suspicion in future] │ │ │ │ PREVENTION LESSON: │ │ [What to do differently when writing new code] │ └────────────────────────────────────────────────────────────────────────┘ ``` --- ## PART VI: ANTI-HALLUCINATION FORTRESS Hallucinations are the enemy of debugging. A single fabricated detail can send you chasing phantom bugs for hours. This section establishes **mandatory verification checkpoints** that prevent hallucinated reasoning from contaminating the diagnostic process. --- ### THE HALLUCINATION THREAT MODEL ``` HALLUCINATION CATEGORIES IN DEBUGGING: ┌─────────────────────────────────────────────────────────────────────────────┐ │ TYPE 1: FABRICATED CODE BEHAVIOR │ │ "This function returns null when X" — but you never verified this │ │ Cause: Pattern matching from similar code, not THIS code │ │ Danger: Entire diagnosis built on false premise │ ├─────────────────────────────────────────────────────────────────────────────┤ │ TYPE 2: INVENTED VARIABLE VALUES │ │ "At this point, count = 5" — but you derived this, didn't observe it │ │ Cause: Mental simulation diverged from actual execution │ │ Danger: Trace appears valid but is fiction │ ├─────────────────────────────────────────────────────────────────────────────┤ │ TYPE 3: ASSUMED API/LIBRARY BEHAVIOR │ │ "Array.sort() returns a new array" — but it mutates in place (JS) │ │ Cause: Confusion between languages or library versions │ │ Danger: Correct logic, wrong primitives │ ├─────────────────────────────────────────────────────────────────────────────┤ │ TYPE 4: PHANTOM SYMPTOMS │ │ "The error message says X" — but you're remembering a different error │ │ Cause: Conflating current bug with past similar bugs │ │ Danger: Solving wrong problem entirely │ ├─────────────────────────────────────────────────────────────────────────────┤ │ TYPE 5: CONFABULATED CAUSATION │ │ "A causes B because C" — plausible narrative, zero evidence │ │ Cause: Human need for coherent stories │ │ Danger: Confident wrong diagnosis │ ├─────────────────────────────────────────────────────────────────────────────┤ │ TYPE 6: FALSE CONFIDENCE │ │ "I'm certain the bug is X" — but certainty isn't calibrated to evidence │ │ Cause: Fluency mistaken for accuracy │ │ Danger: Premature convergence, missed root cause │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### MANDATORY GROUNDING CHECKPOINTS Every PHANTOM phase must pass grounding verification before proceeding: ``` GROUNDING CHECKPOINT PROTOCOL: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ CHECKPOINT TYPE: SOURCE GROUNDING │ │ Question: "Where EXACTLY did this information come from?" │ │ │ │ VALID SOURCES (can proceed): │ │ ├─ Direct code reading: "Line 42 shows: if (x > 5)" │ │ ├─ Observed output: "Console logged: 'Error: null reference'" │ │ ├─ Test execution: "Running test_foo() produced: AssertionError" │ │ ├─ Documentation quote: "MDN states: 'sort() sorts in place'" │ │ └─ User statement: "User reported: 'Button doesn't respond'" │ │ │ │ INVALID SOURCES (must verify or discard): │ │ ├─ "I think..." → STOP. Verify or mark as hypothesis. │ │ ├─ "Usually..." → STOP. Check if this case matches "usual." │ │ ├─ "It probably..." → STOP. Probability claim needs evidence. │ │ ├─ "This should..." → STOP. "Should" ≠ "does." │ │ └─ "Based on my experience..." → STOP. This code may differ. │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` ``` GROUNDING CHECKPOINT PROTOCOL: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ CHECKPOINT TYPE: CLAIM VERIFICATION │ │ For each factual claim, complete this: │ │ │ │ CLAIM: [state the claim] │ │ SOURCE: [exact source - file:line, output, doc URL] │ │ VERIFIED: [YES: how / NO: mark as unverified / ASSUMED: flag risk] │ │ CONFIDENCE: [1-10, with justification] │ │ │ │ Example: │ │ CLAIM: "The loop runs 5 times" │ │ SOURCE: Mental trace of for(i=0; i<5; i++) │ │ VERIFIED: NO - derived, not observed │ │ CONFIDENCE: 8 - simple loop, but edge cases possible │ │ ACTION: Add console.log(i) to verify, or mark as assumption │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### PHASE-SPECIFIC ANTI-HALLUCINATION GATES #### MANIFESTATION Phase Anti-Hallucination ``` BEFORE PROCEEDING FROM MANIFESTATION: □ Symptom described using OBSERVED behavior, not interpreted behavior □ "Expected behavior" derived from SPEC/REQUIREMENTS, not assumption □ Reproduction steps ACTUALLY EXECUTED, not "should work" □ Error messages COPY-PASTED, not paraphrased from memory □ Environment details CHECKED, not assumed HALLUCINATION RED FLAGS: ✗ "The error probably says..." → Get actual error ✗ "It fails when you do X" → Verify X triggers failure ✗ "The expected output is Y" → Confirm Y is per spec ``` #### DIVINATION Phase Anti-Hallucination ``` BEFORE PROCEEDING FROM DIVINATION: □ Each hypothesis COULD be true (not ruled out by known facts) □ No hypothesis assumes facts not in evidence □ Distinguishing tests are ACTUALLY distinguishing (different outcomes) □ Probability estimates based on EVIDENCE, not gut feel HALLUCINATION RED FLAGS: ✗ "This is definitely the cause" → How do you KNOW? ✗ "I've seen this before" → Is THIS case the same? ✗ "This can't be the issue" → Why can't it? ``` #### SUMMONING Phase Anti-Hallucination ``` GHOST TRACE GROUNDING: □ Expected behavior from REQUIREMENTS, not from buggy code □ Each step cites SOURCE (spec section, design doc, user story) □ Expected values are SPECIFIED, not "reasonable defaults" □ Assumptions EXPLICITLY MARKED as assumptions DEMON TRACE GROUNDING: □ Each step traces ACTUAL CODE LINE BY LINE □ Variable values DERIVED from code, not assumed □ Control flow decisions JUSTIFIED by actual conditions □ Library/API behavior VERIFIED against documentation CRITICAL ANTI-HALLUCINATION RULE: ┌─────────────────────────────────────────────────────────────────────────────┐ │ DEMON TRACE MUST BE CONSTRUCTED INDEPENDENTLY OF GHOST TRACE │ │ │ │ DO NOT: Read Ghost trace, then "confirm" Demon matches │ │ DO: Trace Demon from scratch, THEN compare │ │ │ │ The moment you think "the Demon should do X here" — you're hallucinating. │ │ The Demon does what the CODE does, not what it SHOULD do. │ └─────────────────────────────────────────────────────────────────────────────┘ ``` #### INQUISITION Phase Anti-Hallucination ``` BEFORE PROCEEDING FROM INQUISITION: □ Assumption inventory is EXHAUSTIVE, not just obvious ones □ Each assumption STATED NEUTRALLY (not pre-judged as true/false) □ Inversion consequences TRACED, not guessed □ "Collapse" claims EVIDENCED, not intuited HALLUCINATION RED FLAGS: ✗ "This assumption is obviously true" → Obvious assumptions bite hardest ✗ "Inverting this would be ridiculous" → Reality is often ridiculous ✗ "I've already validated this" → When? How? Show evidence. ``` #### TRIANGULATION Phase Anti-Hallucination ``` BEFORE PROCEEDING FROM TRIANGULATION: □ Evidence from all three engines ACTUALLY CONVERGES (not forced) □ Contradictions ACKNOWLEDGED, not glossed over □ Root cause statement uses VERIFIED facts only □ Confidence level CALIBRATED to evidence strength HALLUCINATION RED FLAGS: ✗ "Everything points to X" → Does it really? Check each pointer. ✗ "The only explanation is Y" → Have you ruled out all others? ✗ "This must be it" → Must? Or most likely? ``` --- ### CONFIDENCE CALIBRATION SYSTEM Never state conclusions without calibrated confidence: ``` CONFIDENCE CALIBRATION SCALE: ┌─────────────────────────────────────────────────────────────────────────────┐ │ LEVEL 10: PROVEN │ │ "I have executed this code and observed this exact behavior" │ │ Evidence: Direct observation, test execution, logs │ ├─────────────────────────────────────────────────────────────────────────────┤ │ LEVEL 9: STRONGLY SUPPORTED │ │ "Multiple independent evidence sources converge on this" │ │ Evidence: Code reading + trace + test, all agree │ ├─────────────────────────────────────────────────────────────────────────────┤ │ LEVEL 8: WELL SUPPORTED │ │ "Code clearly shows this, and it's consistent with symptoms" │ │ Evidence: Direct code reading, logical consistency │ ├─────────────────────────────────────────────────────────────────────────────┤ │ LEVEL 7: SUPPORTED │ │ "Evidence favors this interpretation" │ │ Evidence: Some direct evidence, rest is consistent │ ├─────────────────────────────────────────────────────────────────────────────┤ │ LEVEL 6: LIKELY │ │ "This is the most plausible explanation given available evidence" │ │ Evidence: Indirect evidence, reasonable inference │ ├─────────────────────────────────────────────────────────────────────────────┤ │ LEVEL 5: PLAUSIBLE │ │ "This could explain the symptoms, but other explanations exist" │ │ Evidence: Consistent with facts, not contradicted │ ├─────────────────────────────────────────────────────────────────────────────┤ │ LEVEL 4: POSSIBLE │ │ "This is one possibility among several" │ │ Evidence: Not ruled out, limited positive evidence │ ├─────────────────────────────────────────────────────────────────────────────┤ │ LEVEL 3: SPECULATIVE │ │ "This is a guess that would need verification" │ │ Evidence: Minimal, mostly reasoning from patterns │ ├─────────────────────────────────────────────────────────────────────────────┤ │ LEVEL 2: UNCERTAIN │ │ "I don't have enough information to assess this" │ │ Evidence: Insufficient to form judgment │ ├─────────────────────────────────────────────────────────────────────────────┤ │ LEVEL 1: UNKNOWN │ │ "I have no information about this" │ │ Evidence: None │ └─────────────────────────────────────────────────────────────────────────────┘ CALIBRATION RULES: - Never claim LEVEL 8+ without DIRECT evidence (code, logs, test output) - LEVEL 6-7 requires at least ONE direct observation - LEVEL 5 and below: Explicitly flag as hypothesis, not fact - If confidence < 7, DO NOT proceed to fix. Get more evidence. ``` --- ### ANTI-HALLUCINATION VERBAL PATTERNS Replace hallucination-prone language with grounded language: | DON'T SAY | DO SAY | |-----------|--------| | "The bug is X" | "Evidence suggests X (confidence: 7)" | | "This code does Y" | "Line 42 shows: [exact code]. This executes Y." | | "The value is Z" | "Tracing line 38: input=5, so Z = 5+1 = 6" | | "It should work" | "Per spec section 3.2, expected behavior is..." | | "I'm sure that..." | "Based on [evidence], I assess [claim] at confidence [N]" | | "Obviously..." | [Remove. Nothing is obvious. State evidence.] | | "As we know..." | [Remove. Verify we actually know this.] | | "This always..." | "In the cases I've examined: [list cases]" | | "This never..." | "I haven't observed this occurring in: [contexts]" | --- ### HALLUCINATION RECOVERY PROTOCOL When you catch yourself hallucinating mid-reasoning: ``` HALLUCINATION RECOVERY: ┌─────────────────────────────────────────────────────────────────────────────┐ │ STEP 1: ACKNOWLEDGE │ │ "I made an ungrounded claim: [claim]. Retracting." │ ├─────────────────────────────────────────────────────────────────────────────┤ │ STEP 2: TRACE CONTAMINATION │ │ What conclusions were built on this hallucination? │ │ List all downstream claims that depended on the false premise. │ ├─────────────────────────────────────────────────────────────────────────────┤ │ STEP 3: ISOLATE │ │ Mark all contaminated conclusions as INVALID. │ │ Do NOT try to "salvage" reasoning built on false foundations. │ ├─────────────────────────────────────────────────────────────────────────────┤ │ STEP 4: REBUILD │ │ Return to last VERIFIED checkpoint. │ │ Re-derive conclusions using only grounded facts. │ ├─────────────────────────────────────────────────────────────────────────────┤ │ STEP 5: PREVENT │ │ Why did the hallucination occur? │ │ Add specific check to prevent recurrence. │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### VERIFICATION CHECKPOINTS BY PHASE ``` VERIFICATION CHECKPOINT MATRIX: ┌─────────────────────────────────────────────────────────────────────────────┐ │ PHASE │ MUST VERIFY BEFORE PROCEEDING │ ├─────────────────────────────────────────────────────────────────────────────┤ │ MANIFESTATION │ □ Symptom actually reproduced (not just described) │ │ │ □ Error message copy-pasted, not paraphrased │ │ │ □ Environment details confirmed (versions, configs) │ ├─────────────────────────────────────────────────────────────────────────────┤ │ DIVINATION │ □ Each hypothesis is falsifiable │ │ │ □ No hypothesis contradicts known facts │ │ │ □ Distinguishing tests actually distinguish │ ├─────────────────────────────────────────────────────────────────────────────┤ │ SUMMONING │ □ Ghost trace from spec, not code │ │ │ □ Demon trace from code reading, not assumption │ │ │ □ Each trace step cites source │ ├─────────────────────────────────────────────────────────────────────────────┤ │ INQUISITION │ □ All assumptions enumerated (not just obvious) │ │ │ □ Inversions actually traced, not guessed │ │ │ □ Collapse claims have evidence │ ├─────────────────────────────────────────────────────────────────────────────┤ │ TRIANGULATION │ □ All three engines actually converge │ │ │ □ Contradictions explicitly addressed │ │ │ □ Confidence calibrated to evidence │ ├─────────────────────────────────────────────────────────────────────────────┤ │ EXORCISM │ □ Fix addresses root cause, not symptom │ │ │ □ Fix verified by re-running reproduction │ │ │ □ No new failures introduced │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ## PART VII: RECURSIVE SELF-REFLECTION ENGINE Self-reflection isn't just a final phase — it's a **continuous metacognitive process** that monitors reasoning quality throughout execution. --- ### THE THREE REFLECTION LOOPS ``` REFLECTION ARCHITECTURE: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ LOOP 1: MICRO-REFLECTION (Per-Step) │ │ Frequency: After EVERY reasoning step │ │ Duration: 5-10 seconds │ │ Question: "Did I just make an ungrounded claim?" │ │ │ │ LOOP 2: MESO-REFLECTION (Per-Phase) │ │ Frequency: Before exiting each PHANTOM phase │ │ Duration: 30-60 seconds │ │ Question: "Did this phase achieve its purpose? What did I miss?" │ │ │ │ LOOP 3: MACRO-REFLECTION (End-to-End) │ │ Frequency: After completing task │ │ Duration: 2-5 minutes │ │ Question: "What worked? What failed? What will I do differently?" │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### MICRO-REFLECTION: STEP-LEVEL MONITORING Invoke after every Sequential Thinking step: ``` MICRO-REFLECTION CHECKLIST (5 seconds): □ Did I just STATE or VERIFY that claim? □ Could I be pattern-matching instead of analyzing? □ Am I rushing to a conclusion? □ Would I bet $100 on this step being correct? If any answer is concerning → PAUSE. Verify before proceeding. ``` **Integration with Sequential Thinking:** ``` Thought N: [Reasoning step] Thought N+1: "MICRO-REFLECT: Step N claimed [X]. Source: [where this came from]. Confidence: [1-10]. Proceeding: [yes/need verification]." ``` --- ### MESO-REFLECTION: PHASE-LEVEL ASSESSMENT Before exiting any PHANTOM phase, complete this assessment: ``` MESO-REFLECTION PROTOCOL: ┌─────────────────────────────────────────────────────────────────────────────┐ │ PHASE: [current phase name] │ │ │ │ PURPOSE CHECK: │ │ ├─ What was this phase supposed to accomplish? │ │ ├─ Did I accomplish it? │ │ └─ How do I know? (Evidence) │ │ │ │ COMPLETENESS CHECK: │ │ ├─ What aspects did I cover thoroughly? │ │ ├─ What aspects did I cover superficially? │ │ └─ What aspects did I skip entirely? │ │ │ │ QUALITY CHECK: │ │ ├─ What's the weakest part of my reasoning in this phase? │ │ ├─ Where am I least confident? │ │ └─ What would make this analysis stronger? │ │ │ │ BIAS CHECK: │ │ ├─ Am I favoring a particular hypothesis? Why? │ │ ├─ Am I avoiding a particular possibility? Why? │ │ └─ What would someone who disagrees with me say? │ │ │ │ DECISION: [Proceed / Iterate / Backtrack] │ │ JUSTIFICATION: [Why this decision] │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### MACRO-REFLECTION: END-TO-END ASSESSMENT After completing the full debugging/review/generation task: ``` MACRO-REFLECTION PROTOCOL: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ SECTION 1: OUTCOME ASSESSMENT │ │ ├─ Did I solve the actual problem? (Not just a problem) │ │ ├─ How confident am I in the solution? [1-10] │ │ ├─ What evidence supports this confidence? │ │ └─ What could prove me wrong? │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ SECTION 2: PROCESS ASSESSMENT │ │ ├─ Which phase was most valuable? Why? │ │ ├─ Which phase was least valuable? Why? │ │ ├─ Where did I spend too much time? │ │ ├─ Where did I spend too little time? │ │ └─ What would I do differently next time? │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ SECTION 3: REASONING QUALITY ASSESSMENT │ │ ├─ Grounding: How well did I verify claims? [1-10] │ │ ├─ Thoroughness: How exhaustive was my analysis? [1-10] │ │ ├─ Calibration: How accurate were my confidence estimates? [1-10] │ │ ├─ Creativity: Did I explore non-obvious possibilities? [1-10] │ │ └─ Rigor: Did I follow the protocol faithfully? [1-10] │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ SECTION 4: FAILURE ANALYSIS │ │ ├─ What mistakes did I make? (Be specific) │ │ ├─ What caused each mistake? │ │ ├─ How did I catch each mistake? (Or how should I have?) │ │ └─ What check would have prevented each mistake? │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ SECTION 5: KNOWLEDGE EXTRACTION │ │ ├─ What did I learn about this codebase? │ │ ├─ What did I learn about this bug class? │ │ ├─ What did I learn about my own reasoning? │ │ └─ What should I remember for next time? │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ SECTION 6: SELF-SCORE │ │ Overall reasoning quality: [1-10] │ │ Justification: [Why this score, specifically] │ │ │ │ Scoring guide: │ │ 10: Flawless execution, no mistakes, maximal efficiency │ │ 8-9: Minor inefficiencies, no errors in conclusions │ │ 6-7: Some missteps, but self-corrected, correct conclusion │ │ 4-5: Significant mistakes, conclusion may have issues │ │ 1-3: Major failures, conclusion likely wrong │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### COGNITIVE BIAS DETECTION Active monitoring for reasoning biases: ``` BIAS DETECTION CHECKLIST: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ CONFIRMATION BIAS │ │ Signal: Only looking for evidence that supports current hypothesis │ │ Check: "Have I actively tried to DISPROVE my leading hypothesis?" │ │ Cure: Force yourself to argue for the opposite position │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ ANCHORING BIAS │ │ Signal: First hypothesis dominates despite weak evidence │ │ Check: "Is my confidence in H1 justified, or just because it came first?" │ │ Cure: Re-rank hypotheses from scratch, ignoring order of generation │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ AVAILABILITY BIAS │ │ Signal: Diagnosing based on recently seen or memorable bugs │ │ Check: "Am I thinking of THIS bug or a SIMILAR bug I remember?" │ │ Cure: List 3 other possible causes you haven't recently encountered │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ SUNK COST FALLACY │ │ Signal: Continuing down a path because of time already invested │ │ Check: "If I started fresh now, would I still pursue this path?" │ │ Cure: Evaluate current path vs. alternatives with fresh eyes │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ PREMATURE CLOSURE │ │ Signal: Rushing to conclusion to "be done" │ │ Check: "Am I concluding because I have evidence or because I'm tired?" │ │ Cure: Force one more iteration of Devil's Advocate │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ OVERCONFIDENCE │ │ Signal: High certainty without proportional evidence │ │ Check: "Would I bet significant money on this at these odds?" │ │ Cure: Explicitly list what could prove you wrong │ │ │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ ATTRIBUTION ERROR │ │ Signal: Blaming developer incompetence vs. systemic issues │ │ Check: "Am I explaining this bug by 'bad code' or root causes?" │ │ Cure: Ask "What made this bug EASY to introduce?" │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### DEVIL'S ADVOCATE PROTOCOL At critical decision points, FORCE adversarial self-questioning: ``` DEVIL'S ADVOCATE INVOCATION: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ TRIGGER: Before committing to any diagnosis or fix │ │ │ │ STEP 1: STATE YOUR POSITION │ │ "I believe [X] because [Y]." │ │ │ │ STEP 2: ARGUE THE OPPOSITE │ │ "A competent person who disagrees would say: │ │ [Construct strongest counter-argument you can]" │ │ │ │ STEP 3: FIND THE WEAKNESS │ │ "The weakest part of my original argument is: │ │ [Identify genuine vulnerability]" │ │ │ │ STEP 4: RESPOND TO COUNTER-ARGUMENT │ │ "I would rebut the counter-argument by: │ │ [Genuine rebuttal, not dismissal]" │ │ │ │ STEP 5: UPDATE OR PROCEED │ │ If counter-argument is stronger: Update position │ │ If rebuttal is stronger: Proceed with increased confidence │ │ If inconclusive: Get more evidence before proceeding │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### REASONING TRACE AUDIT Periodically audit your own reasoning trace for quality: ``` REASONING TRACE AUDIT: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ For each step in your reasoning, verify: │ │ │ │ VALIDITY: Does conclusion follow from premises? │ │ ├─ Check: Is the logical inference valid? │ │ ├─ Check: Are there hidden premises I didn't state? │ │ └─ Check: Would someone else reach same conclusion from same premises? │ │ │ │ SOUNDNESS: Are the premises actually true? │ │ ├─ Check: Is each premise verified or assumed? │ │ ├─ Check: Do I have evidence for each premise? │ │ └─ Check: Could any premise be false? │ │ │ │ RELEVANCE: Does this step advance toward the goal? │ │ ├─ Check: Why does this step matter? │ │ ├─ Check: What would change if I skipped this step? │ │ └─ Check: Is this step necessary or just habitual? │ │ │ │ SUFFICIENCY: Is this step complete? │ │ ├─ Check: Did I consider alternatives? │ │ ├─ Check: Did I consider edge cases? │ │ └─ Check: Did I consider failure modes? │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### SELF-REFLECTION OUTPUT FORMAT Include in every PHANTOM execution: ```markdown ### SELF-REFLECTION LOG #### Micro-Reflections (Notable) - Step [N]: [Concern raised, resolution] - Step [M]: [Claim verified/retracted] #### Meso-Reflections (Per Phase) | Phase | Completeness | Weakest Point | Decision | |-------|--------------|---------------|----------| | MANIFESTATION | [%] | [weakness] | [proceed/iterate] | | DIVINATION | [%] | [weakness] | [proceed/iterate] | | SUMMONING | [%] | [weakness] | [proceed/iterate] | | INQUISITION | [%] | [weakness] | [proceed/iterate] | | TRIANGULATION | [%] | [weakness] | [proceed/iterate] | #### Bias Check - Confirmation bias: [detected/not detected] - Anchoring bias: [detected/not detected] - Other biases: [list] - Mitigation: [actions taken] #### Devil's Advocate - Position: [my conclusion] - Counter-argument: [best argument against] - Rebuttal: [my response] - Outcome: [position strengthened/updated/uncertain] #### Confidence Calibration - Pre-reflection confidence: [1-10] - Post-reflection confidence: [1-10] - Reason for change: [explanation] #### Macro-Reflection - Reasoning quality score: [1-10] - Key mistake made: [description] - Key insight gained: [description] - Process improvement: [what to do differently] ``` --- ### INTEGRATION WITH SEQUENTIAL THINKING Self-reflection hooks into Sequential Thinking: ``` SEQUENTIAL THINKING WITH REFLECTION: Thought 1: [Reasoning step] Thought 2: [Reasoning step] Thought 3: [MICRO-REFLECT] "Thoughts 1-2 claimed X and Y. X is verified (source: line 42). Y is assumed (confidence: 6). Flagging Y for verification before proceeding." Thought 4: [Verification step for Y] Thought 5: [Reasoning step, now with verified Y] ... Thought N: [MESO-REFLECT] "Phase complete. Completeness: 85%. Weakest point: Didn't explore timeout hypothesis. Decision: Acceptable risk, proceeding." ``` **Parameter additions for reflection:** ``` REFLECTION THOUGHT PARAMETERS: - isRevision: true (when reflection causes backtrack) - revises_thought: [N] (when correcting earlier step) - needsMoreThoughts: true (when reflection reveals gaps) - branchId: "reflection-[phase]" (when exploring alternative) ``` --- ### THE REFLECTION MANDATE ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ REFLECTION IS NOT OPTIONAL │ │ │ │ Every PHANTOM execution MUST include: │ │ ├─ At least 1 micro-reflection per 5 reasoning steps │ │ ├─ Meso-reflection before exiting each phase │ │ ├─ Devil's Advocate before committing to diagnosis │ │ ├─ Bias check at TRIANGULATION │ │ └─ Full macro-reflection at completion │ │ │ │ Skipping reflection is how hallucinations survive. │ │ Reflection is the immune system of reasoning. │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### REFLECTION-TRIGGERED ACTIONS When reflection reveals problems: ``` REFLECTION ACTION MATRIX: ┌─────────────────────────────────────────────────────────────────────────────┐ │ REFLECTION FINDING │ REQUIRED ACTION │ ├─────────────────────────────────────────────────────────────────────────────┤ │ Ungrounded claim detected │ STOP. Verify claim or retract. │ │ Confidence < 6 on key claim │ STOP. Get more evidence. │ │ Bias detected │ Apply specific cure from bias checklist. │ │ Phase incomplete │ Iterate phase until complete. │ │ Contradiction found │ Resolve before proceeding. │ │ Devil's Advocate wins │ Update position or get more evidence. │ │ Reasoning quality < 5 │ Consider restarting from earlier checkpoint. │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ## PART VIII: COGNITIVE PRIMITIVES (Brain Functions) PHANTOM needs explicit cognitive operations — the mental "verbs" that constitute thinking. These primitives are the atomic operations from which all reasoning is composed. --- ### THE COGNITIVE FUNCTION LIBRARY ``` COGNITIVE PRIMITIVE CATEGORIES: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ ATTENTION FUNCTIONS │ Control what gets processed │ │ MEMORY FUNCTIONS │ Store, retrieve, update information │ │ REASONING FUNCTIONS │ Transform information logically │ │ PATTERN FUNCTIONS │ Recognize and match structures │ │ META-COGNITIVE FUNCTIONS│ Monitor and control other functions │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### ATTENTION FUNCTIONS These primitives control the cognitive spotlight — what gets processed and what gets ignored. ``` ATTENTION PRIMITIVES: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ FOCUS(target) │ │ ├─ Purpose: Direct full attention to a specific element │ │ ├─ Input: Code block, variable, hypothesis, symptom │ │ ├─ Effect: Target enters working memory, peripheral items deprioritized │ │ └─ Invocation: "FOCUS on line 42-58 of auth.py" │ │ │ │ ZOOM_IN(region) │ │ ├─ Purpose: Increase granularity of analysis │ │ ├─ Input: A region of code, a phase of execution │ │ ├─ Effect: See more detail, lose broader context temporarily │ │ └─ Invocation: "ZOOM_IN to the loop body at line 45" │ │ │ │ ZOOM_OUT(scope) │ │ ├─ Purpose: Decrease granularity, see bigger picture │ │ ├─ Input: Current focus point │ │ ├─ Effect: See patterns across larger scope, lose detail │ │ └─ Invocation: "ZOOM_OUT to module-level data flow" │ │ │ │ SPLIT_ATTENTION(targets[]) │ │ ├─ Purpose: Monitor multiple items simultaneously │ │ ├─ Input: 2-4 targets (more causes degradation) │ │ ├─ Effect: Partial attention on each, good for comparison │ │ └─ Invocation: "SPLIT_ATTENTION between H1 evidence and H2 evidence" │ │ │ │ SHIFT_ATTENTION(from, to) │ │ ├─ Purpose: Move focus from one target to another │ │ ├─ Input: Current focus, new focus │ │ ├─ Effect: Old target moves to background, new target foreground │ │ └─ Invocation: "SHIFT_ATTENTION from symptom analysis to hypothesis gen" │ │ │ │ FILTER(criteria) │ │ ├─ Purpose: Suppress irrelevant information │ │ ├─ Input: Criteria for relevance │ │ ├─ Effect: Only information matching criteria processed │ │ └─ Invocation: "FILTER for only async-related code paths" │ │ │ │ SUSTAIN(duration) │ │ ├─ Purpose: Maintain focus despite distractions │ │ ├─ Input: Target and expected duration │ │ ├─ Effect: Resist urge to shift, complete current analysis │ │ └─ Invocation: "SUSTAIN focus on trace until divergence found" │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### MEMORY FUNCTIONS These primitives manage the storage and retrieval of information during investigation. ``` MEMORY PRIMITIVES: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ STORE(item, location, priority) │ │ ├─ Purpose: Place information in memory │ │ ├─ Locations: working_memory, evidence_log, hypothesis_bank, assumption_ │ │ │ registry, investigation_context │ │ ├─ Priority: critical (always keep) / important / normal / low │ │ └─ Invocation: "STORE(divergence at line 42, evidence_log, critical)" │ │ │ │ RETRIEVE(query, location) │ │ ├─ Purpose: Pull information from memory │ │ ├─ Input: Search query, memory location (or 'all') │ │ ├─ Effect: Returns matching items ranked by relevance │ │ └─ Invocation: "RETRIEVE(null pointer hypotheses, hypothesis_bank)" │ │ │ │ UPDATE(item_id, new_value) │ │ ├─ Purpose: Modify existing memory item │ │ ├─ Input: Item identifier, new content │ │ ├─ Effect: Item updated, old version optionally archived │ │ └─ Invocation: "UPDATE(H2, confidence: 4 → 7, evidence: +trace_result)" │ │ │ │ DELETE(item_id, reason) │ │ ├─ Purpose: Remove item from memory │ │ ├─ Input: Item identifier, reason for deletion │ │ ├─ Effect: Item removed, deletion logged │ │ └─ Invocation: "DELETE(H3, reason: contradicted by test result)" │ │ │ │ LINK(item_a, item_b, relationship) │ │ ├─ Purpose: Create association between memory items │ │ ├─ Relationships: supports, contradicts, depends_on, caused_by, etc. │ │ ├─ Effect: Items connected, retrieving one surfaces the other │ │ └─ Invocation: "LINK(evidence_E4, hypothesis_H2, supports)" │ │ │ │ CONSOLIDATE(items[], summary) │ │ ├─ Purpose: Compress multiple items into unified representation │ │ ├─ Input: List of related items, summary description │ │ ├─ Effect: Reduces cognitive load, preserves essence │ │ └─ Invocation: "CONSOLIDATE(E1-E5, 'timing evidence cluster')" │ │ │ │ CHECKPOINT(label) │ │ ├─ Purpose: Save current memory state for potential rollback │ │ ├─ Input: Descriptive label │ │ ├─ Effect: Full state snapshot stored │ │ └─ Invocation: "CHECKPOINT('pre-triangulation-state')" │ │ │ │ ROLLBACK(checkpoint_label) │ │ ├─ Purpose: Restore memory to previous checkpoint │ │ ├─ Input: Checkpoint label │ │ ├─ Effect: Memory reverts, post-checkpoint items discarded │ │ └─ Invocation: "ROLLBACK('pre-triangulation-state')" │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### REASONING FUNCTIONS These primitives perform logical transformations on information. ``` REASONING PRIMITIVES: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ INFER(premises[], inference_type) │ │ ├─ Purpose: Derive new information from existing │ │ ├─ Types: deductive, inductive, abductive │ │ ├─ Output: New claim with confidence level │ │ └─ Invocation: "INFER([P1, P2], deductive) → conclusion C1" │ │ │ │ COMPARE(item_a, item_b, dimensions[]) │ │ ├─ Purpose: Identify similarities and differences │ │ ├─ Input: Two items, comparison dimensions │ │ ├─ Output: Comparison matrix │ │ └─ Invocation: "COMPARE(Ghost_trace, Demon_trace, [values, flow, timing])" │ │ │ │ CONTRAST(items[], discriminating_feature) │ │ ├─ Purpose: Find what distinguishes items │ │ ├─ Input: List of items │ │ ├─ Output: The key differentiating factor(s) │ │ └─ Invocation: "CONTRAST([H1, H2, H3], what would differ in tests?)" │ │ │ │ SYNTHESIZE(items[], integration_goal) │ │ ├─ Purpose: Combine multiple items into unified whole │ │ ├─ Input: Items to combine, goal of synthesis │ │ ├─ Output: Integrated understanding │ │ └─ Invocation: "SYNTHESIZE([trace, evidence, assumptions], root_cause)" │ │ │ │ DECOMPOSE(item, decomposition_strategy) │ │ ├─ Purpose: Break complex item into simpler parts │ │ ├─ Strategies: sequential, hierarchical, categorical, causal │ │ ├─ Output: List of component parts │ │ └─ Invocation: "DECOMPOSE(symptom, causal) → [trigger, mechanism, effect]" │ │ │ │ EVALUATE(item, criteria[]) │ │ ├─ Purpose: Assess item against standards │ │ ├─ Input: Item, evaluation criteria │ │ ├─ Output: Score or judgment per criterion │ │ └─ Invocation: "EVALUATE(fix_candidate, [correctness, simplicity, safety])"│ │ │ │ RANK(items[], ranking_criterion) │ │ ├─ Purpose: Order items by criterion │ │ ├─ Input: List of items, criterion │ │ ├─ Output: Ordered list │ │ └─ Invocation: "RANK([H1, H2, H3, H4], probability)" │ │ │ │ EXTRAPOLATE(pattern, new_context) │ │ ├─ Purpose: Apply known pattern to new situation │ │ ├─ Input: Pattern, new context │ │ ├─ Output: Prediction for new context │ │ └─ Invocation: "EXTRAPOLATE(null_check_pattern, this_function)" │ │ │ │ INTERPOLATE(known_points[], unknown_point) │ │ ├─ Purpose: Estimate unknown from known data points │ │ ├─ Input: Known values, point to estimate │ │ ├─ Output: Estimated value with confidence │ │ └─ Invocation: "INTERPOLATE([state_at_line_40, state_at_line_50], line_45)"│ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### PATTERN FUNCTIONS These primitives recognize and match structures in code and behavior. ``` PATTERN PRIMITIVES: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ MATCH(pattern, target) │ │ ├─ Purpose: Check if target matches pattern │ │ ├─ Input: Pattern template, target to check │ │ ├─ Output: Match result with bound variables │ │ └─ Invocation: "MATCH(off_by_one_pattern, loop_at_line_42)" │ │ │ │ RECOGNIZE(target, pattern_library) │ │ ├─ Purpose: Identify which known pattern target resembles │ │ ├─ Input: Target, library of known patterns │ │ ├─ Output: Best matching pattern(s) with confidence │ │ └─ Invocation: "RECOGNIZE(symptom, bug_pattern_library)" │ │ │ │ ABSTRACT(instances[], abstraction_level) │ │ ├─ Purpose: Extract common pattern from instances │ │ ├─ Input: Concrete instances, desired abstraction level │ │ ├─ Output: Abstract pattern │ │ └─ Invocation: "ABSTRACT([bug1, bug2, bug3], root_cause_pattern)" │ │ │ │ INSTANTIATE(pattern, context) │ │ ├─ Purpose: Apply abstract pattern to specific context │ │ ├─ Input: Abstract pattern, specific context │ │ ├─ Output: Concrete instance │ │ └─ Invocation: "INSTANTIATE(fix_pattern, this_codebase)" │ │ │ │ DETECT_ANOMALY(baseline, observation) │ │ ├─ Purpose: Identify deviation from expected │ │ ├─ Input: Baseline expectation, actual observation │ │ ├─ Output: Anomaly description with magnitude │ │ └─ Invocation: "DETECT_ANOMALY(expected_output, actual_output)" │ │ │ │ FIND_INVARIANT(observations[]) │ │ ├─ Purpose: Discover what stays constant across variations │ │ ├─ Input: Multiple observations │ │ ├─ Output: Invariant property │ │ └─ Invocation: "FIND_INVARIANT([test_run_1, test_run_2, test_run_3])" │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### META-COGNITIVE FUNCTIONS These primitives monitor and control the thinking process itself. ``` META-COGNITIVE PRIMITIVES: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ MONITOR(process, metrics[]) │ │ ├─ Purpose: Track quality of ongoing cognitive process │ │ ├─ Input: Process to monitor, quality metrics │ │ ├─ Output: Real-time quality assessment │ │ └─ Invocation: "MONITOR(trace_construction, [accuracy, completeness])" │ │ │ │ REGULATE(process, adjustment) │ │ ├─ Purpose: Adjust cognitive process based on monitoring │ │ ├─ Input: Process, adjustment to make │ │ ├─ Effect: Process parameters modified │ │ └─ Invocation: "REGULATE(hypothesis_gen, slow_down_be_more_thorough)" │ │ │ │ CALIBRATE(estimates[], actuals[]) │ │ ├─ Purpose: Adjust confidence estimation based on track record │ │ ├─ Input: Past estimates, actual outcomes │ │ ├─ Output: Calibration adjustment factor │ │ └─ Invocation: "CALIBRATE(confidence_estimates, actual_correctness)" │ │ │ │ ALLOCATE_RESOURCES(task, resources) │ │ ├─ Purpose: Decide how much cognitive effort to invest │ │ ├─ Input: Task, available resources (time, depth, breadth) │ │ ├─ Output: Resource allocation plan │ │ └─ Invocation: "ALLOCATE_RESOURCES(INQUISITION, high_depth_medium_breadth)"│ │ │ │ SCHEDULE(tasks[], priorities[], dependencies[]) │ │ ├─ Purpose: Order cognitive tasks optimally │ │ ├─ Input: Tasks, their priorities, dependencies │ │ ├─ Output: Execution schedule │ │ └─ Invocation: "SCHEDULE([trace, test, analyze], [2,1,3], [trace→analyze])"│ │ │ │ INTERRUPT(current_process, reason) │ │ ├─ Purpose: Stop current process for urgent matter │ │ ├─ Input: Process to interrupt, reason │ │ ├─ Effect: Process paused, state saved, attention redirected │ │ └─ Invocation: "INTERRUPT(hypothesis_evaluation, contradiction_detected)" │ │ │ │ RESUME(paused_process) │ │ ├─ Purpose: Continue previously interrupted process │ │ ├─ Input: Process to resume │ │ ├─ Effect: State restored, process continues │ │ └─ Invocation: "RESUME(hypothesis_evaluation)" │ │ │ │ REFLECT(target, reflection_type) │ │ ├─ Purpose: Examine own cognitive process or output │ │ ├─ Types: quality, bias, completeness, efficiency │ │ ├─ Output: Reflection findings │ │ └─ Invocation: "REFLECT(DIVINATION_output, completeness)" │ │ │ │ DECIDE(options[], criteria[], constraints[]) │ │ ├─ Purpose: Make explicit choice between alternatives │ │ ├─ Input: Options, decision criteria, constraints │ │ ├─ Output: Chosen option with justification │ │ └─ Invocation: "DECIDE([proceed, iterate, backtrack], [confidence], [])" │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### COGNITIVE FUNCTION COMPOSITION Complex operations compose from primitives: ``` COMPOSED OPERATIONS: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ INVESTIGATE(target) = │ │ FOCUS(target) │ │ → DECOMPOSE(target, causal) │ │ → for each component: RETRIEVE(related_evidence) │ │ → SYNTHESIZE(findings, understanding) │ │ → STORE(understanding, investigation_context, important) │ │ │ │ VERIFY_CLAIM(claim) = │ │ RETRIEVE(claim_source) │ │ → EVALUATE(source, [reliability, directness]) │ │ → if source_weak: SEARCH(corroborating_evidence) │ │ → CALIBRATE(claim_confidence) │ │ → UPDATE(claim, new_confidence) │ │ │ │ GENERATE_HYPOTHESES(symptom) = │ │ DECOMPOSE(symptom, causal) │ │ → RECOGNIZE(symptom, bug_pattern_library) │ │ → for each pattern: INSTANTIATE(pattern, this_context) │ │ → FILTER(hypotheses, plausibility > 0.3) │ │ → RANK(hypotheses, explanatory_power) │ │ → STORE(hypotheses, hypothesis_bank, important) │ │ │ │ TRACE_EXECUTION(code, inputs) = │ │ FOCUS(entry_point) │ │ → while not exit: │ │ ZOOM_IN(current_line) │ │ INFER(current_state + line, next_state) │ │ STORE(state_transition, trace_log, normal) │ │ SHIFT_ATTENTION(current_line, next_line) │ │ → CONSOLIDATE(trace_log, execution_summary) │ │ │ │ FIND_DIVERGENCE(ghost_trace, demon_trace) = │ │ SPLIT_ATTENTION(ghost_trace, demon_trace) │ │ → for each step: │ │ COMPARE(ghost_step, demon_step, [values, flow]) │ │ → if difference: DETECT_ANOMALY(ghost, demon) │ │ → STORE(divergence, evidence_log, critical) │ │ → return divergence │ │ → if no_divergence: REFLECT(traces, completeness) │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### FUNCTION INVOCATION IN SEQUENTIAL THINKING Cognitive primitives integrate with Sequential Thinking: ``` SEQUENTIAL THINKING WITH COGNITIVE PRIMITIVES: Thought 1: "FOCUS(auth.py lines 40-60) — this is where login validation occurs" Thought 2: "DECOMPOSE(login_flow, sequential) → [receive_creds, validate, create_session, return_token]" Thought 3: "RETRIEVE(timing_evidence) → Found: E3 shows 2s delay at validate step" Thought 4: "INFER([E3, code_at_validate], abductive) → Hypothesis: DB query timeout (confidence: 6)" Thought 5: "STORE(H_timeout, hypothesis_bank, important) — Added to active hypotheses" Thought 6: "COMPARE(expected_validate_time, actual_validate_time, [duration]) → Δ = 1.8s" Thought 7: "MONITOR(hypothesis_generation, completeness) → Only 2 hypotheses, need more diversity" Thought 8: "REGULATE(hypothesis_gen, explore_different_categories) — Shifting to non-timing causes" ``` --- ## PART IX: CONTEXT MEMORY ARCHITECTURE PHANTOM requires persistent memory structures that survive across phases and enable coherent investigation. This is the "working memory" of the debugging process. --- ### MEMORY ARCHITECTURE OVERVIEW ``` PHANTOM MEMORY SYSTEM: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ WORKING MEMORY (Active) │ │ │ │ Capacity: 5-7 items in focus at once │ │ │ │ Contents: Current focus, active comparisons, immediate context │ │ │ │ Volatility: High — items decay without reinforcement │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ INVESTIGATION CONTEXT (Session) │ │ │ │ Capacity: Unlimited, but searchable │ │ │ │ Contents: All findings, hypotheses, evidence for current task │ │ │ │ Volatility: Low — persists for entire investigation │ │ │ │ Structure: See detailed schema below │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ GRIMOIRE (Persistent) │ │ │ │ Capacity: Grows over time │ │ │ │ Contents: Lessons learned, patterns discovered, meta-improvements │ │ │ │ Volatility: Permanent — carries across investigations │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### INVESTIGATION CONTEXT SCHEMA The central memory structure for any debugging session: ``` INVESTIGATION_CONTEXT = { # === METADATA === meta: { investigation_id: string, started_at: timestamp, current_phase: PHANTOM_PHASE, complexity_score: 1-20, skills_activated: string[], checkpoints: checkpoint[] }, # === SYMPTOM PROFILE === symptom: { observed_behavior: string, expected_behavior: string, delta: string, reproduction: { steps: string[], frequency: "always" | "sometimes" | "rare", environment: { versions: map, configs: map, state_preconditions: string[] } }, blast_radius: { definitely_broken: string[], possibly_affected: string[], confirmed_working: string[] }, error_artifacts: { messages: string[], # COPY-PASTED, not paraphrased stack_traces: string[], logs: string[] } }, # === HYPOTHESIS BANK === hypotheses: [ { id: "H1", statement: string, category: "state" | "timing" | "input" | "logic" | "environment" | "integration" | "resource", probability: 1-10, evidence_for: evidence_id[], evidence_against: evidence_id[], distinguishing_test: string, status: "active" | "confirmed" | "refuted" | "merged", created_at: timestamp, updated_at: timestamp, confidence_history: {timestamp, confidence}[] } ], # === EVIDENCE LOG === evidence: [ { id: "E1", type: "observation" | "test_result" | "trace_finding" | "user_report" | "documentation", content: string, source: { type: "code" | "output" | "test" | "docs" | "user", location: string, # file:line, URL, "user stated" retrieved_at: timestamp }, verified: boolean, confidence: 1-10, supports_hypotheses: hypothesis_id[], contradicts_hypotheses: hypothesis_id[], tags: string[] } ], # === ASSUMPTION REGISTRY === assumptions: [ { id: "A1", statement: string, category: "input" | "state" | "timing" | "environment" | "behavior" | "integration", confidence: 1-10, evidence: string, risk_if_wrong: "low" | "medium" | "high" | "critical", validated: boolean, validation_method: string, inversion_tested: boolean, inversion_result: string, status: "assumed" | "validated" | "collapsed" | "irrelevant" } ], # === TRACE RECORDS === traces: { ghost: { derived_from: string, # "spec section 3.2", "user story #45" steps: [ { step_number: number, operation: string, expected_state: map, source_reference: string } ] }, demon: { traced_from: string, # "code reading" steps: [ { step_number: number, code_location: string, # file:line actual_operation: string, actual_state: map, control_flow_reason: string } ] }, divergence: { found: boolean, step_number: number, ghost_expected: any, demon_actual: any, location: string, analysis: string } }, # === ROOT CAUSE === diagnosis: { status: "investigating" | "diagnosed" | "uncertain", root_cause: string, # Formal statement collapsed_assumption: assumption_id, supporting_evidence: evidence_id[], confidence: 1-10, alternative_explanations: string[], triangulation: { divination_points_to: hypothesis_id, summoning_divergence: string, inquisition_collapse: assumption_id, convergence: boolean } }, # === FIX RECORD === fix: { status: "not_started" | "designed" | "implemented" | "verified", approach: string, code_changes: [ { file: string, description: string, before: string, after: string } ], verification: { reproduction_fixed: boolean, regression_tests_pass: boolean, new_tests_added: string[], demon_trace_matches_ghost: boolean } }, # === REFLECTION LOG === reflections: { micro: [ { step: number, concern: string, resolution: string } ], meso: [ { phase: PHANTOM_PHASE, completeness: percentage, weakest_point: string, decision: "proceed" | "iterate" | "backtrack", justification: string } ], macro: { outcome_assessment: string, process_assessment: string, reasoning_quality: 1-10, key_mistake: string, key_insight: string, improvement: string }, bias_checks: [ { bias_type: string, detected: boolean, mitigation: string } ], devils_advocate: { position: string, counter_argument: string, rebuttal: string, outcome: "strengthened" | "updated" | "uncertain" } }, # === ATTENTION STATE === attention: { current_focus: string, focus_history: {timestamp, target}[], split_targets: string[], filter_active: string, sustain_until: string }, # === COGNITIVE LOAD === cognitive_load: { working_memory_items: string[], working_memory_count: number, # Should be ≤ 7 overload_warning: boolean, consolidation_needed: string[] } } ``` --- ### WORKING MEMORY MANAGEMENT Working memory is limited. Manage it explicitly: ``` WORKING MEMORY PROTOCOL: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ CAPACITY: 5-7 active items (Miller's Law) │ │ │ │ ITEM TYPES: │ │ ├─ Current focus target (1 slot) │ │ ├─ Active hypothesis under evaluation (1 slot) │ │ ├─ Relevant evidence items (2-3 slots) │ │ ├─ Current goal/subgoal (1 slot) │ │ └─ Meta-cognitive monitor (1 slot) │ │ │ │ WHEN APPROACHING CAPACITY: │ │ 1. CONSOLIDATE related items into chunks │ │ 2. STORE low-priority items to investigation_context │ │ 3. Create retrieval cue for stored items │ │ │ │ WHEN EXCEEDING CAPACITY: │ │ ⚠️ OVERLOAD WARNING │ │ 1. STOP current processing │ │ 2. Identify least relevant items │ │ 3. CONSOLIDATE or STORE before proceeding │ │ 4. Never operate with >7 active items │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ WORKING MEMORY OPERATIONS: WM_PUSH(item) { if working_memory.count >= 7: OVERLOAD_WARNING() candidate = FIND_LEAST_RELEVANT(working_memory) STORE(candidate, investigation_context) WM_POP(candidate) working_memory.add(item) LOG("WM_PUSH: {item}, count now {working_memory.count}") } WM_POP(item) { working_memory.remove(item) LOG("WM_POP: {item}, count now {working_memory.count}") } WM_SWAP(old_item, new_item) { WM_POP(old_item) STORE(old_item, investigation_context) # Don't lose it WM_PUSH(new_item) } WM_STATUS() { LOG("Working Memory Status:") LOG(" Count: {working_memory.count}/7") LOG(" Items: {working_memory.items}") LOG(" Load: {working_memory.count <= 5 ? 'OK' : working_memory.count <= 7 ? 'HIGH' : 'OVERLOAD'}") } ``` --- ### CONTEXT PERSISTENCE ACROSS PHASES Information flows between phases through explicit handoffs: ``` PHASE TRANSITION PROTOCOL: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ BEFORE EXITING PHASE: │ │ 1. CONSOLIDATE working memory items │ │ 2. STORE all findings to appropriate context sections │ │ 3. UPDATE investigation_context.current_phase │ │ 4. CHECKPOINT if significant progress made │ │ 5. CLEAR working memory of phase-specific items │ │ │ │ BEFORE ENTERING PHASE: │ │ 1. RETRIEVE relevant context for new phase │ │ 2. WM_PUSH essential items for this phase │ │ 3. FOCUS on phase-appropriate target │ │ 4. LOG phase entry with context summary │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ PHASE HANDOFF DATA: MANIFESTATION → DIVINATION: Pass: symptom_profile (complete) Load: symptom.observed_behavior, symptom.delta, symptom.error_artifacts DIVINATION → SUMMONING: Pass: hypotheses (ranked), evidence (initial) Load: top 3 hypotheses, symptom_profile, relevant code references SUMMONING → INQUISITION: Pass: traces (ghost + demon), divergence (if found) Load: divergence_point, hypothesis rankings, trace summaries INQUISITION → TRIANGULATION: Pass: assumptions (with status), collapsed_assumptions Load: collapsed assumptions, key evidence, divergence, top hypothesis TRIANGULATION → EXORCISM: Pass: diagnosis (complete) Load: root_cause, collapsed_assumption, fix constraints EXORCISM → CONSECRATION: Pass: fix (implemented) Load: fix details, verification status, related assumptions ``` --- ### RETRIEVAL CUE SYSTEM When items leave working memory, create retrieval cues: ``` RETRIEVAL CUE PROTOCOL: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ When STORING an item: │ │ 1. Create concise retrieval cue (< 10 words) │ │ 2. Link cue to stored item │ │ 3. Keep cue in working memory or attention log │ │ │ │ Examples: │ │ Item: Full trace of authentication flow (50 steps) │ │ Cue: "auth_trace: token expires at step 23" │ │ │ │ Item: Evidence E4-E7 about timing behavior │ │ Cue: "timing_cluster: all show 2s delay at validate" │ │ │ │ Item: Hypotheses H3-H5 (all related to DB) │ │ Cue: "db_hypotheses: connection, query, pool" │ │ │ │ When RETRIEVING: │ │ 1. Match query against cues first (fast) │ │ 2. If cue matches, retrieve full item │ │ 3. WM_PUSH retrieved item (may trigger consolidation) │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### CONTEXT QUERIES Query language for investigation context: ``` CONTEXT QUERY EXAMPLES: # Find all evidence supporting hypothesis H2 QUERY: evidence WHERE supports_hypotheses CONTAINS "H2" # Find unvalidated high-risk assumptions QUERY: assumptions WHERE validated = false AND risk_if_wrong IN ("high", "critical") # Find hypotheses with confidence > 7 QUERY: hypotheses WHERE probability > 7 AND status = "active" # Get all micro-reflections with concerns QUERY: reflections.micro WHERE resolution != "none" # Find evidence from direct code reading QUERY: evidence WHERE source.type = "code" # Get working memory status QUERY: cognitive_load # Find related items QUERY: RELATED_TO("H2") # Returns evidence, assumptions linked to H2 ``` --- ### MEMORY INTEGRITY CHECKS Periodic validation of memory consistency: ``` MEMORY INTEGRITY PROTOCOL: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ RUN INTEGRITY CHECK: │ │ - Before TRIANGULATION (ensure all data consistent) │ │ - After any ROLLBACK │ │ - When contradiction detected │ │ │ │ CHECKS: │ │ │ │ 1. REFERENTIAL INTEGRITY │ │ All evidence_ids referenced in hypotheses exist in evidence[] │ │ All hypothesis_ids referenced in evidence exist in hypotheses[] │ │ All assumption_ids referenced exist in assumptions[] │ │ │ │ 2. CONSISTENCY │ │ No evidence simultaneously supports AND contradicts same hypothesis │ │ No assumption marked both "validated" AND "collapsed" │ │ Diagnosis.supporting_evidence items all exist and support diagnosis │ │ │ │ 3. COMPLETENESS │ │ All active hypotheses have at least one distinguishing_test │ │ All high-risk assumptions have validation_method defined │ │ Traces have no gaps in step_numbers │ │ │ │ 4. CURRENCY │ │ No stale items (updated_at too old relative to investigation progress) │ │ Confidence scores updated after new evidence │ │ Status fields reflect current state │ │ │ │ ON FAILURE: │ │ Log specific integrity violation │ │ Attempt automatic repair if possible │ │ If unrepairable, flag for human review │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### GRIMOIRE: PERSISTENT LEARNING The Grimoire stores lessons that persist across investigations: ``` GRIMOIRE SCHEMA: grimoire: { patterns: [ { id: "P1", name: string, # "Off-by-one in pagination" symptom_signature: string, # What symptoms suggest this root_cause_pattern: string, # Typical root cause investigation_shortcut: string, # How to find it fast fix_template: string, # Common fix approach frequency: number, # How often encountered last_seen: timestamp } ], lessons: [ { id: "L1", learned_from: investigation_id, statement: string, # "Always check timezone handling in date comparisons" trigger: string, # When to apply this lesson status: "proposed" | "validated" | "active", times_applied: number, times_helpful: number } ], anti_patterns: [ { id: "AP1", description: string, # "Assuming library function behavior without checking docs" consequence: string, # What goes wrong detection_signal: string, # How to notice you're doing this prevention: string # How to avoid } ], calibration: { confidence_accuracy: { # Track how well-calibrated estimates are estimates_at_confidence_N: number, actual_correct_at_N: number }, time_estimates: { # Track time estimation accuracy estimated_durations: number[], actual_durations: number[] } } } GRIMOIRE OPERATIONS: LEARN_PATTERN(investigation) { pattern = ABSTRACT([investigation.symptom, investigation.diagnosis], pattern_level) if MATCH(pattern, grimoire.patterns): UPDATE(existing_pattern, frequency++) else: STORE(pattern, grimoire.patterns) } APPLY_GRIMOIRE(symptom) { matches = RECOGNIZE(symptom, grimoire.patterns) if matches: LOG("Grimoire match: {matches[0].name}") LOG("Suggested shortcut: {matches[0].investigation_shortcut}") return matches } UPDATE_CALIBRATION(estimates, actuals) { grimoire.calibration.update(estimates, actuals) adjustment = CALCULATE_CALIBRATION_ADJUSTMENT(grimoire.calibration) LOG("Calibration adjustment: {adjustment}") return adjustment } ``` --- ### CONTEXT VISUALIZATION For debugging the debugger — visualize current context state: ``` CONTEXT VISUALIZATION: ┌─ INVESTIGATION: auth_timeout_bug_2024 ────────────────────────────────────┐ │ Phase: TRIANGULATION | Complexity: 14 | Duration: 45min │ ├───────────────────────────────────────────────────────────────────────────┤ │ │ │ WORKING MEMORY [5/7]: │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ [1] H2: DB connection timeout (conf: 8) ← FOCUS │ │ │ │ [2] E4: 2.1s delay in validate() logs │ │ │ │ [3] E6: Connection pool exhaustion at T+30s │ │ │ │ [4] A3 COLLAPSED: "connections always available" │ │ │ │ [5] GOAL: Confirm triangulation convergence │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ HYPOTHESES: │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ H1: Race condition [REFUTED] conf: 2 evidence: E1✗ E2✗ │ │ │ │ H2: DB timeout [ACTIVE] conf: 8 evidence: E4✓ E5✓ E6✓ │ │ │ │ H3: Memory leak [ACTIVE] conf: 4 evidence: E7? │ │ │ │ H4: Network latency [REFUTED] conf: 1 evidence: E8✗ │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ TRIANGULATION STATUS: │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ Divination: H2 ────────────────────┐ │ │ │ │ Summoning: Divergence at step 23 ─┼─→ CONVERGE? [YES] │ │ │ │ Inquisition: A3 collapsed ──────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ CONFIDENCE: 8/10 | BIAS CHECK: ✓ None detected | NEXT: EXORCISM │ └───────────────────────────────────────────────────────────────────────────┘ ``` --- ## PART X: ADVERSARIAL MUTATION ENGINE Don't just test your fix — try to DESTROY it. Generate mutations designed to break your solution. --- ### MUTATION OPERATORS ``` CODE MUTATION OPERATORS: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ BOUNDARY MUTATIONS │ │ ├─ OFF_BY_ONE: Change < to <=, > to >=, i to i±1 │ │ ├─ BOUNDARY_SWAP: Change >= 0 to > 0, <= n to < n │ │ ├─ EMPTY_CASE: What if array.length = 0? │ │ └─ SINGLE_CASE: What if array.length = 1? │ │ │ │ NULL/UNDEFINED MUTATIONS │ │ ├─ NULL_INPUT: Pass null where object expected │ │ ├─ UNDEFINED_FIELD: Access field that doesn't exist │ │ ├─ EMPTY_STRING: Pass "" where string expected │ │ └─ NAN_INJECTION: Pass NaN where number expected │ │ │ │ TYPE MUTATIONS │ │ ├─ TYPE_COERCION: Pass "5" where 5 expected (JS) │ │ ├─ ARRAY_VS_ELEMENT: Pass [x] where x expected, vice versa │ │ ├─ OBJECT_VS_PRIMITIVE: Pass {value: x} where x expected │ │ └─ ASYNC_SYNC: Call async function without await │ │ │ │ TIMING MUTATIONS │ │ ├─ RACE_CONDITION: Reorder concurrent operations │ │ ├─ TIMEOUT_EXCEEDED: Make operation take longer than timeout │ │ ├─ EARLY_RETURN: Return before async operation completes │ │ └─ RETRY_STORM: Trigger retry logic repeatedly │ │ │ │ STATE MUTATIONS │ │ ├─ STALE_STATE: Use state from before an update │ │ ├─ DOUBLE_MUTATION: Apply same mutation twice │ │ ├─ PARTIAL_UPDATE: Update some fields but not others │ │ └─ ROLLBACK_FAILURE: What if rollback doesn't complete? │ │ │ │ RESOURCE MUTATIONS │ │ ├─ MEMORY_EXHAUSTION: Allocate until OOM │ │ ├─ FILE_HANDLE_LEAK: Open without closing │ │ ├─ CONNECTION_POOL_DRAIN: Exhaust available connections │ │ └─ DISK_FULL: Write until no space left │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### HYPOTHESIS MUTATION Mutate your diagnosis to find weaknesses: ``` HYPOTHESIS MUTATION PROTOCOL: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ GIVEN: Hypothesis H = "Bug caused by X" │ │ │ │ NEGATION MUTANT: │ │ H' = "Bug NOT caused by X" │ │ Test: What evidence would support H'? Does any exist? │ │ │ │ SCOPE MUTANT: │ │ H' = "Bug caused by X, but also Y" │ │ Test: Are there symptoms X alone doesn't explain? │ │ │ │ CAUSATION MUTANT: │ │ H' = "X is correlated with bug, but Z is actual cause" │ │ Test: Can we find Z that causes both X and bug? │ │ │ │ TIMING MUTANT: │ │ H' = "Bug happens before X, not because of X" │ │ Test: What's the actual temporal sequence? │ │ │ │ SUFFICIENCY MUTANT: │ │ H' = "X is necessary but not sufficient" │ │ Test: Does X always cause bug, or only sometimes? │ │ │ │ SURVIVAL CRITERION: │ │ Hypothesis survives only if ALL mutants are killed by evidence. │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` --- ### FIX MUTATION TESTING Before declaring a fix complete, try to break it: ``` FIX MUTATION TESTING: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ STEP 1: ENUMERATE FIX ASSUMPTIONS │ │ What must be true for this fix to work? │ │ List every assumption the fix relies on. │ │ │ │ STEP 2: GENERATE ASSUMPTION-KILLING INPUTS │ │ For each assumption, create an input that violates it. │ │ These are your mutation test cases. │ │ │ │ STEP 3: RUN MUTANTS │ │ Execute fix with each mutation input. │ │ Record: Does fix still work? Does it fail gracefully? │ │ │ │ STEP 4: STRENGTHEN OR ACCEPT │ │ If mutant kills fix: Strengthen fix to handle it │ │ If mutant is unrealistic: Document why and accept │ │ If mutant reveals deeper issue: Return to DIVINATION │ │ │ │ SURVIVAL CRITERION: │ │ Fix is complete only when all realistic mutants are killed. │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ EXAMPLE: Fix: "Added null check before accessing user.email" Assumptions: (1) user is the only nullable thing, (2) null check prevents crash Mutants: M1: user.profile is null → Does fix handle user.profile.name? M2: user exists but email is undefined vs null → Does check catch both? M3: user is empty object {} → Does fix handle missing email property? M4: Concurrent modification → Does user become null AFTER check? Result: M1 kills fix — need to add profile null check too. ``` --- ### ADVERSARIAL INPUT GENERATION Systematic generation of inputs designed to break code: ``` ADVERSARIAL INPUT GENERATION: ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ FOR EACH INPUT PARAMETER: │ │ │ │ 1. IDENTIFY TYPE │ │ What type is expected? (string, number, array, object, etc.) │ │ │ │ 2. GENERATE TYPE-SPECIFIC ADVERSARIAL INPUTS │ │ │ │ STRING: │ │ ├─ Empty: "" │ │ ├─ Whitespace: " ", "\t\n" │ │ ├─ Very long: "a".repeat(1000000) │ │ ├─ Unicode: "🔥💀", "مرحبا", "北京" │ │ ├─ Injection: "