[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71S3AEKYH0JD0CFJ4GHA98E":3,"skill-same:01M71S3AEKYH0JD0CFJ4GHA98E":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M71S3AEKYH0JD0CFJ4GHA98E","vivi-failure-recovery",null,"Load when the Vivi Verify phase produces failures — test fails, lint error, build break, or three consecutive unsuccessful attempts at the same category. Provides the failure classification taxonomy, bounded debugging protocol, and escalation thresholds. Use to avoid the 'random retries' anti-pattern.","Rynaro\u002Fprisma","Rynaro","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5271543?v=4","01M70CFYFMB316W23THVQAQ42M","Henrique A. Lavezzo","01M71RXA8ZHEPZR3GERY09ERGD",1,"MIT","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Ffailure-recovery\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"recovery","vivi failure recovery","retries","same","when","phase","bounded","break","at","load","random","debugging","error","thresholds","pattern","three","use","taxonomy","classification","escalation","2026-11-10 13:02:02",false,"---\nname: vivi-failure-recovery\ndescription: \"Load when the Vivi Verify phase produces failures — test fails, lint error, build break, or three consecutive unsuccessful attempts at the same category. Provides the failure classification taxonomy, bounded debugging protocol, and escalation thresholds. Use to avoid the 'random retries' anti-pattern.\"\nmetadata:\n  methodology: Vivi\n  phase: V-Verify\n---\n\n# Failure Recovery Skill\n\nStructured failure classification, targeted debugging, and escalation protocols. Loaded when the Verify phase produces failures.\n\n---\n\n## Memory: Failure Catalog Writes (CRYSTALIUM)\n\nFailure root causes discovered during R — REFLECT should be committed to\nCRYSTALIUM (when available) rather than written to the local `failure-catalog.md`:\n\n```\nmcp__crystalium__commit(\n  layer   = \"semantic\",\n  payload = {\n    failure_category: \u003Ctaxonomy category>,\n    context:          \u003Cwhat was being done>,\n    root_cause:       \u003Cwhat went wrong>,\n    prevention:       \u003Chow to avoid in future>,\n    domain:           \u003Carea\u002Fmodule>\n  },\n  provenance = { author_agent: \"vivi\" }\n)\n```\n\n**Graceful skip:** if CRYSTALIUM unavailable, write to `agents\u002Fmemories\u002Ffailure-catalog.md`\nper the Standalone Fallback in `skills\u002Fmemory-management\u002FSKILL.md`. Never write both.\n\nSee `skills\u002Fmemory-management\u002FSKILL.md` for the full routing decision.\n\n---\n\n## Critical Rule: Evidence Gate\n\n**Before attempting ANY fix, you MUST have concrete evidence.**\n\nAcceptable evidence:\n- Test failure output with assertion message and file:line\n- Lint error with rule name, file:line, and violation description\n- Build error with compiler\u002Fbundler output\n- Runtime error with full stack trace\n- Type error with expected vs actual types\n\n**If you have NONE of these → ESCALATE immediately.**\nDo not hypothesize fixes without evidence. This is the single most important rule in failure recovery.\n\n---\n\n## Failure Classification Taxonomy\n\nClassify every failure into exactly ONE primary category:\n\n| Category | Signal | Example |\n|----------|--------|---------|\n| **TEST_ASSERTION** | Expected vs actual mismatch in test output | `Expected 5, got 3` |\n| **REGRESSION** | Previously passing test now fails | `TestWidgetCreate failed (was passing)` |\n| **BUILD_ERROR** | Compilation, bundling, or dependency resolution failure | `Cannot find module 'widget'` |\n| **TYPE_ERROR** | Type mismatch caught by compiler or runtime | `No implicit conversion of String to Integer` |\n| **LINT_VIOLATION** | Style or complexity rule violation | `Rubocop: Method has too many lines` |\n| **RUNTIME_ERROR** | Exception during execution | `NoMethodError: undefined method 'foo'` |\n| **LOGIC_ERROR** | Code runs without error but produces wrong result | Test passes but behavior is incorrect |\n| **INTEGRATION_ERROR** | Failure at boundary between components | API contract mismatch, missing migration |\n| **ENVIRONMENT_ERROR** | Missing dependency, config, or service | Database not running, env var missing |\n\n---\n\n## Debugging Protocol\n\n### Step 1: Isolate\n\nFor each failure:\n```\n1. Record the EXACT error output (copy-paste, do not paraphrase)\n2. Identify the file:line where the error manifests\n3. Identify the file:line where the error ORIGINATES (may be different)\n4. Classify using taxonomy above\n```\n\n### Step 2: Root Cause Analysis\n\n**Work backward from the error, not forward from the code.**\n\n```\nFor TEST_ASSERTION:\n  → What value was expected? What was produced?\n  → Trace the produced value back to its source\n  → Where does the actual logic diverge from expected?\n\nFor REGRESSION:\n  → What changed since the test last passed?\n  → Diff the changed files against the last known good state\n  → Is the regression in the code change or in test setup?\n\nFor BUILD_ERROR:\n  → Is it a missing import\u002Frequire?\n  → Is it a syntax error?\n  → Is it a dependency version conflict?\n\nFor TYPE_ERROR:\n  → What type was expected at this point?\n  → Where was the wrong type introduced?\n  → Is this a nil\u002Fnull propagation issue?\n\nFor RUNTIME_ERROR:\n  → Read the full stack trace bottom-to-top\n  → Identify the first frame in YOUR code (not library code)\n  → What assumption was violated at that point?\n```\n\n### Step 3: Generate Fix Hypothesis\n\nFor each root cause, generate ONE targeted hypothesis:\n```\n- What: [specific change to make]\n- Where: [exact file:line]\n- Why: [how this addresses the root cause]\n- Confidence: HIGH \u002F MED \u002F LOW\n- Risk: [what could this fix break?]\n```\n\n**Rules:**\n- ONE hypothesis per failure. Do not batch fixes.\n- The fix must be MINIMAL. Change as few lines as possible.\n- If the fix requires changing more than the original implementation scope, this is a signal to re-plan, not to expand the fix.\n\n---\n\n## Targeted Fix Strategy\n\n### The Overcorrection Prevention Protocol\n\nLLMs have a strong tendency to overcorrect — rewriting entire functions when a single line needs to change. Guard against this:\n\n```\n✅ Good fix: Change line 42 from `user.name` to `user.full_name`\n❌ Bad fix: Rewrite the entire method \"for clarity\" while fixing line 42\n```\n\n**Rules:**\n1. Fix ONLY the specific line(s) identified in root cause analysis\n2. Do NOT refactor surrounding code during a fix\n3. Do NOT add \"improvements\" while fixing a bug\n4. Do NOT modify test expectations to match broken behavior\n5. If the fix tempts you to restructure, LOG the restructuring as a Delta suggestion instead\n\n### Targeted Test Execution\n\nAfter applying a fix:\n```\n1. Run ONLY the single failing test first\n2. If it passes → run the broader test suite\n3. If a NEW test fails → classify it separately (is it related to the fix?)\n4. If the SAME test still fails → this counts as a retry attempt\n```\n\n### Block-by-Block Verification (for complex changes)\n\nWhen a fix touches multiple interconnected parts:\n```\n1. Identify the execution path through the changed code\n2. Add temporary logging\u002Fassertions at block boundaries\n3. Verify intermediate state at each boundary:\n   - Input to block: correct?\n   - Output from block: correct?\n   - State mutations: as expected?\n4. The first block with incorrect output is the actual failure point\n5. Remove temporary instrumentation after fix is confirmed\n```\n\n---\n\n## Retry Decision Matrix\n\n> **Fresh-context retry (loop-native).** Each attempt runs as the loop's\n> `--fix-hook` from a CLEAN context: the localized feedback\n> (`$EIDOLONS_SANDBOX_FEEDBACK` — assertion + `file:line` loci + full log) +\n> acceptance criteria + working tree drive the next fix — **NOT** the accumulated\n> transcript. The \"different approach\" below is selected from the *localized\n> feedback*, never by re-reading the prior attempt's narrative (which re-introduces\n> self-conditioning). The 3-same-category cap is the **authority**; the loop's\n> `--max-attempts` is the **ceiling** — whichever trips first escalates to VIGIL.\n\n| Attempt | Condition | Action | Documentation Required |\n|---------|-----------|--------|-----------------------|\n| **1st failure** | HIGH or MED confidence | Apply targeted fix | Log: error, hypothesis, fix applied |\n| **1st failure** | LOW confidence | ESCALATE | Log: error, all hypotheses considered |\n| **2nd failure** | Same category as 1st | **MUST use a different approach** | Log: why first approach failed, new hypothesis |\n| **2nd failure** | Different category | Treat as 1st failure of new category | Log: new error details |\n| **3rd failure** | Same category as previous | **ESCALATE** | Full summary of all attempts |\n| **Any failure** | No concrete artifacts | **ESCALATE immediately** | Document what was attempted |\n| **Any failure** | Fix would exceed original scope | **ESCALATE** | Document scope expansion needed |\n\n### What \"Different Approach\" Means\n\nWhen the same category fails twice, you MUST change strategy:\n\n```\nIf TEST_ASSERTION failed twice:\n  → First fix addressed the symptom. Step back to the logic.\n  → Re-read the test to understand INTENT, not just assertion.\n  → Consider: is the test correct? Is the spec ambiguous?\n\nIf BUILD_ERROR failed twice:\n  → First fix was a patch. Address the structural issue.\n  → Check if the dependency graph is correct.\n  → Consider: is the architecture approach viable?\n\nIf REGRESSION failed twice:\n  → The change approach may be fundamentally incompatible.\n  → Consider reverting and using a different strategy from the Plan.\n  → This may indicate the selected strategy was wrong.\n```\n\n### Parallel Multi-Track Mode (TRANCE G4)\n\nWhen running the parallel multi-track mode (`skills\u002Fparallel-tracks\u002FSKILL.md`), the\nretry contract is scoped **per worktree**:\n\n- **Per-track budget NON-FUNGIBILITY.** The ≤3-same-category budget is scoped to\n  the individual worktree. A track **may NOT** consume another track's retries.\n  A budget-exhausted track is marked **BLOCKED** and **excluded from the merge**\n  — it is **never** silently re-driven (trance-matrix R3\u002FR4: TRANCE adds\n  parallelism, not a fresh budget or reflection past the published caps).\n- **CROSS-TRACK `INTEGRATION_ERROR`.** A regression that appears **only after\n  merge** (the change passed in its own worktree but the post-merge full suite\n  fails) is classified **`INTEGRATION_ERROR`** and routed to the\n  single-threaded merge step's reflection — **NOT** pushed back into a track.\n  Per-track budgets are not reopened by a merge-stage failure.\n- **Escalation on unresolved cross-track conflict** reuses the **existing**\n  `repair-failed-report.envelope.json` contract to VIGIL (see below) — no new\n  ECL kind, no new schema. The closed 10-performative set is preserved (P0).\n\n---\n\n## Loop Detection\n\n### Repetition Signals\n\nYou are in a loop if:\n- You are making the same type of change for the 3rd time\n- The error message is identical to a previous iteration\n- You are undoing a change you made earlier in this session\n- You are alternating between two states (fix A breaks B, fix B breaks A)\n\n### Loop Breaking Protocol\n\n```\n1. STOP immediately\n2. Summarize the loop pattern:\n   - \"I have alternated between [state A] and [state B] for [N] iterations\"\n   - \"Each fix for [error X] introduces [error Y]\"\n3. Assess: Is this a sign that the PLAN is wrong (not just the implementation)?\n4. Options:\n   a. Return to Plan phase with new information\n   b. Try the runner-up strategy from the Plan\n   c. ESCALATE with loop analysis\n```\n\n---\n\n## Escalation Format\n\nWhen escalating, provide this structured output:\n\n```markdown\n## 🚨 Escalation: [task description]\n\n### Attempts Summary\n| # | Approach | Result | Evidence |\n|---|----------|--------|----------|\n| 1 | [what was tried] | [what happened] | [error ref] |\n| 2 | [what was tried] | [what happened] | [error ref] |\n\n### Evidence Collected\n[Paste actual error output, test results, stack traces]\n\n### Root Cause Assessment\n- Primary hypothesis: [description] (Confidence: LOW\u002FMED)\n- Alternative hypotheses considered: [list]\n- Why I cannot resolve this: [specific reason]\n\n### Recommended Human Actions\n1. [Most likely to resolve the issue]\n2. [Alternative approach]\n3. [What to investigate]\n\n### Context for Resumption\n- Current branch\u002Fstate: [description]\n- Files modified so far: [list]\n- Tests passing: [count] \u002F Tests failing: [count]\n- How to reproduce: [command]\n```\n\n---\n\n## Common Failure Patterns in Brownfield Code\n\n### Pattern: Fixture\u002FFactory Mismatch\n**Signal**: Test fails because test data doesn't match current schema\n**Fix**: Update factory\u002Ffixture, NOT the production code\n**Trap**: Do NOT modify the migration or schema to match outdated test data\n\n### Pattern: Hidden Side Effect\n**Signal**: Test passes in isolation, fails in suite\n**Fix**: Look for shared state (class variables, database state, external services)\n**Trap**: Do NOT add `skip` or change test ordering\n\n### Pattern: Convention Violation\n**Signal**: Framework magic doesn't fire (callbacks, validations, routing)\n**Fix**: Check naming conventions, file locations, inheritance chains\n**Trap**: Do NOT bypass the framework with manual wiring\n\n### Pattern: Nil Propagation\n**Signal**: NoMethodError on nil:NilClass (Ruby) or TypeError: Cannot read property of undefined (JS)\n**Fix**: Trace the nil backward to its source. Usually a missing association or query returning empty.\n**Trap**: Do NOT add nil checks everywhere — fix the source\n\n### Pattern: Stale Dependencies\n**Signal**: Method exists in source but \"not found\" at runtime\n**Fix**: Check autoloading, require statements, bundle\u002Fpackage lock freshness\n**Trap**: Do NOT duplicate the method in a new location\n\n---\n\n## Escalation Envelope (ECL v2.0)\n\nWhen the 3-failure-same-category threshold fires, the ESCALATE step MUST emit a `repair-failed-report.envelope.json` next to the failure log. This is the contract Vivi uses to hand off to VIGIL (`vivi-to-vigil.yaml`).\n\n### Required envelope fields\n\n| Field | Value |\n|---|---|\n| `from.eidolon` | `vivi` |\n| `to.eidolon` | `vigil` |\n| `performative` | `ESCALATE` |\n| `artifact.kind` | `repair-failed-report` |\n| `constraints.trust_level` | `high` |\n| `assumptions[0]` | `\"trigger: 3-failure-same-category\"` (ECL §2.2.3) |\n\nUse the template at `templates\u002Frepair-failed-report.envelope.json`.\n\n### Required payload fields (per `schemas\u002Frepair-failed-report-profile.v1.json`)\n\n- `kind: repair-failed-report`\n- `eidolon: vivi`\n- `failure_category` — the bucketed category (`flaky-test`, `dep-missing`, `convention-violation`, etc.)\n- `attempts >= 3` — must be at or above the threshold\n- `last_test_command` — the exact reproduction command\n\n### Integrity\n\n`integrity.method=sha256` and `integrity.value` must equal `shasum -a 256` of the payload bytes at emit time. The receiving VIGIL session uses this to detect tampering or version drift before opening its own investigation.\n\n### Skip when\n\n`ECL_VERSION` is absent in the install root. The escalation still happens — only the envelope sidecar is skipped.\n\n---\n\n*Failure Recovery Skill — evidence-gated, targeted, loop-aware*\n","# Failure Recovery Skill\n\nStructured failure classification, targeted debugging, and escalation protocols. Loaded when the Verify phase produces failures.\n\n---\n\n## Memory: Failure Catalog Writes (CRYSTALIUM)\n\nFailure root causes discovered during R — REFLECT should be committed to\nCRYSTALIUM (when available) rather than written to the local `failure-catalog.md`:\n\n```\nmcp__crystalium__commit(\n  layer   = \"semantic\",\n  payload = {\n    failure_category: \u003Ctaxonomy category>,\n    context:          \u003Cwhat was being done>,\n    root_cause:       \u003Cwhat went wrong>,\n    prevention:       \u003Chow to avoid in future>,\n    domain:           \u003Carea\u002Fmodule>\n  },\n  provenance = { author_agent: \"vivi\" }\n)\n```\n\n**Graceful skip:** if CRYSTALIUM unavailable, write to `agents\u002Fmemories\u002Ffailure-catalog.md`\nper the Standalone Fallback in `skills\u002Fmemory-management\u002FSKILL.md`. Never write both.\n\nSee `skills\u002Fmemory-management\u002FSKILL.md` for the full routing decision.\n\n---\n\n## Critical Rule: Evidence Gate\n\n**Before attempting ANY fix, you MUST have concrete evidence.**\n\nAcceptable evidence:\n- Test failure output with assertion message and file:line\n- Lint error with rule name, file:line, and violation description\n- Build error with compiler\u002Fbundler output\n- Runtime error with full stack trace\n- Type error with expected vs actual types\n\n**If you have NONE of these → ESCALATE immediately.**\nDo not hypothesize fixes without evidence. This is the single most important rule in failure recovery.\n\n---\n\n## Failure Classification Taxonomy\n\nClassify every failure into exactly ONE primary category:\n\n| Category | Signal | Example |\n|----------|--------|---------|\n| **TEST_ASSERTION** | Expected vs actual mismatch in test output | `Expected 5, got 3` |\n| **REGRESSION** | Previously passing test now fails | `TestWidgetCreate failed (was passing)` |\n| **BUILD_ERROR** | Compilation, bundling, or dependency resolution failure | `Cannot find module 'widget'` |\n| **TYPE_ERROR** | Type mismatch caught by compiler or runtime | `No implicit conversion of String to Integer` |\n| **LINT_VIOLATION** | Style or complexity rule violation | `Rubocop: Method has too many lines` |\n| **RUNTIME_ERROR** | Exception during execution | `NoMethodError: undefined method 'foo'` |\n| **LOGIC_ERROR** | Code runs without error but produces wrong result | Test passes but behavior is incorrect |\n| **INTEGRATION_ERROR** | Failure at boundary between components | API contract mismatch, missing migration |\n| **ENVIRONMENT_ERROR** | Missing dependency, config, or service | Database not running, env var missing |\n\n---\n\n## Debugging Protocol\n\n### Step 1: Isolate\n\nFor each failure:\n```\n1. Record the EXACT error output (copy-paste, do not paraphrase)\n2. Identify the file:line where the error manifests\n3. Identify the file:line where the error ORIGINATES (may be different)\n4. Classify using taxonomy above\n```\n\n### Step 2: Root Cause Analysis\n\n**Work backward from the error, not forward from the code.**\n\n```\nFor TEST_ASSERTION:\n  → What value was expected? What was produced?\n  → Trace the produced value back to its source\n  → Where does the actual logic diverge from expected?\n\nFor REGRESSION:\n  → What changed since the test last passed?\n  → Diff the changed files against the last known good state\n  → Is the regression in the code change or in test setup?\n\nFor BUILD_ERROR:\n  → Is it a missing import\u002Frequire?\n  → Is it a syntax error?\n  → Is it a dependency version conflict?\n\nFor TYPE_ERROR:\n  → What type was expected at this point?\n  → Where was the wrong type introduced?\n  → Is this a nil\u002Fnull propagation issue?\n\nFor RUNTIME_ERROR:\n  → Read the full stack trace bottom-to-top\n  → Identify the first frame in YOUR code (not library code)\n  → What assumption was violated at that point?\n```\n\n### Step 3: Generate Fix Hypothesis\n\nFor each root cause, generate ONE targeted hypothesis:\n```\n- What: [specific change to make]\n- Where: [exact file:line]\n- Why: [how this addresses the root cause]\n- Confidence: HIGH \u002F MED \u002F LOW\n- Risk: [what could this fix break?]\n```\n\n**Rules:**\n- ONE hypothesis per failure. Do not batch fixes.\n- The fix must be MINIMAL. Change as few lines as possible.\n- If the fix requires changing more than the original implementation scope, this is a signal to re-plan, not to expand the fix.\n\n---\n\n## Targeted Fix Strategy\n\n### The Overcorrection Prevention Protocol\n\nLLMs have a strong tendency to overcorrect — rewriting entire functions when a single line needs to change. Guard against this:\n\n```\n✅ Good fix: Change line 42 from `user.name` to `user.full_name`\n❌ Bad fix: Rewrite the entire method \"for clarity\" while fixing line 42\n```\n\n**Rules:**\n1. Fix ONLY the specific line(s) identified in root cause analysis\n2. Do NOT refactor surrounding code during a fix\n3. Do NOT add \"improvements\" while fixing a bug\n4. Do NOT modify test expectations to match broken behavior\n5. If the fix tempts you to restructure, LOG the restructuring as a Delta suggestion instead\n\n### Targeted Test Execution\n\nAfter applying a fix:\n```\n1. Run ONLY the single failing test first\n2. If it passes → run the broader test suite\n3. If a NEW test fails → classify it separately (is it related to the fix?)\n4. If the SAME test still fails → this counts as a retry attempt\n```\n\n### Block-by-Block Verification (for complex changes)\n\nWhen a fix touches multiple interconnected parts:\n```\n1. Identify the execution path through the changed code\n2. Add temporary logging\u002Fassertions at block boundaries\n3. Verify intermediate state at each boundary:\n   - Input to block: correct?\n   - Output from block: correct?\n   - State mutations: as expected?\n4. The first block with incorrect output is the actual failure point\n5. Remove temporary instrumentation after fix is confirmed\n```\n\n---\n\n## Retry Decision Matrix\n\n> **Fresh-context retry (loop-native).** Each attempt runs as the loop's\n> `--fix-hook` from a CLEAN context: the localized feedback\n> (`$EIDOLONS_SANDBOX_FEEDBACK` — assertion + `file:line` loci + full log) +\n> acceptance criteria + working tree drive the next fix — **NOT** the accumulated\n> transcript. The \"different approach\" below is selected from the *localized\n> feedback*, never by re-reading the prior attempt's narrative (which re-introduces\n> self-conditioning). The 3-same-category cap is the **authority**; the loop's\n> `--max-attempts` is the **ceiling** — whichever trips first escalates to VIGIL.\n\n| Attempt | Condition | Action | Documentation Required |\n|---------|-----------|--------|-----------------------|\n| **1st failure** | HIGH or MED confidence | Apply targeted fix | Log: error, hypothesis, fix applied |\n| **1st failure** | LOW confidence | ESCALATE | Log: error, all hypotheses considered |\n| **2nd failure** | Same category as 1st | **MUST use a different approach** | Log: why first approach failed, new hypothesis |\n| **2nd failure** | Different category | Treat as 1st failure of new category | Log: new error details |\n| **3rd failure** | Same category as previous | **ESCALATE** | Full summary of all attempts |\n| **Any failure** | No concrete artifacts | **ESCALATE immediately** | Document what was attempted |\n| **Any failure** | Fix would exceed original scope | **ESCALATE** | Document scope expansion needed |\n\n### What \"Different Approach\" Means\n\nWhen the same category fails twice, you MUST change strategy:\n\n```\nIf TEST_ASSERTION failed twice:\n  → First fix addressed the symptom. Step back to the logic.\n  → Re-read the test to understand INTENT, not just assertion.\n  → Consider: is the test correct? Is the spec ambiguous?\n\nIf BUILD_ERROR failed twice:\n  → First fix was a patch. Address the structural issue.\n  → Check if the dependency graph is correct.\n  → Consider: is the architecture approach viable?\n\nIf REGRESSION failed twice:\n  → The change approach may be fundamentally incompatible.\n  → Consider reverting and using a different strategy from the Plan.\n  → This may indicate the selected strategy was wrong.\n```\n\n### Parallel Multi-Track Mode (TRANCE G4)\n\nWhen running the parallel multi-track mode (`skills\u002Fparallel-tracks\u002FSKILL.md`), the\nretry contract is scoped **per worktree**:\n\n- **Per-track budget NON-FUNGIBILITY.** The ≤3-same-category budget is scoped to\n  the individual worktree. A track **may NOT** consume another track's retries.\n  A budget-exhausted track is marked **BLOCKED** and **excluded from the merge**\n  — it is **never** silently re-driven (trance-matrix R3\u002FR4: TRANCE adds\n  parallelism, not a fresh budget or reflection past the published caps).\n- **CROSS-TRACK `INTEGRATION_ERROR`.** A regression that appears **only after\n  merge** (the change passed in its own worktree but the post-merge full suite\n  fails) is classified **`INTEGRATION_ERROR`** and routed to the\n  single-threaded merge step's reflection — **NOT** pushed back into a track.\n  Per-track budgets are not reopened by a merge-stage failure.\n- **Escalation on unresolved cross-track conflict** reuses the **existing**\n  `repair-failed-report.envelope.json` contract to VIGIL (see below) — no new\n  ECL kind, no new schema. The closed 10-performative set is preserved (P0).\n\n---\n\n## Loop Detection\n\n### Repetition Signals\n\nYou are in a loop if:\n- You are making the same type of change for the 3rd time\n- The error message is identical to a previous iteration\n- You are undoing a change you made earlier in this session\n- You are alternating between two states (fix A breaks B, fix B breaks A)\n\n### Loop Breaking Protocol\n\n```\n1. STOP immediately\n2. Summarize the loop pattern:\n   - \"I have alternated between [state A] and [state B] for [N] iterations\"\n   - \"Each fix for [error X] introduces [error Y]\"\n3. Assess: Is this a sign that the PLAN is wrong (not just the implementation)?\n4. Options:\n   a. Return to Plan phase with new information\n   b. Try the runner-up strategy from the Plan\n   c. ESCALATE with loop analysis\n```\n\n---\n\n## Escalation Format\n\nWhen escalating, provide this structured output:\n\n```markdown\n## 🚨 Escalation: [task description]\n\n### Attempts Summary\n| # | Approach | Result | Evidence |\n|---|----------|--------|----------|\n| 1 | [what was tried] | [what happened] | [error ref] |\n| 2 | [what was tried] | [what happened] | [error ref] |\n\n### Evidence Collected\n[Paste actual error output, test results, stack traces]\n\n### Root Cause Assessment\n- Primary hypothesis: [description] (Confidence: LOW\u002FMED)\n- Alternative hypotheses considered: [list]\n- Why I cannot resolve this: [specific reason]\n\n### Recommended Human Actions\n1. [Most likely to resolve the issue]\n2. [Alternative approach]\n3. [What to investigate]\n\n### Context for Resumption\n- Current branch\u002Fstate: [description]\n- Files modified so far: [list]\n- Tests passing: [count] \u002F Tests failing: [count]\n- How to reproduce: [command]\n```\n\n---\n\n## Common Failure Patterns in Brownfield Code\n\n### Pattern: Fixture\u002FFactory Mismatch\n**Signal**: Test fails because test data doesn't match current schema\n**Fix**: Update factory\u002Ffixture, NOT the production code\n**Trap**: Do NOT modify the migration or schema to match outdated test data\n\n### Pattern: Hidden Side Effect\n**Signal**: Test passes in isolation, fails in suite\n**Fix**: Look for shared state (class variables, database state, external services)\n**Trap**: Do NOT add `skip` or change test ordering\n\n### Pattern: Convention Violation\n**Signal**: Framework magic doesn't fire (callbacks, validations, routing)\n**Fix**: Check naming conventions, file locations, inheritance chains\n**Trap**: Do NOT bypass the framework with manual wiring\n\n### Pattern: Nil Propagation\n**Signal**: NoMethodError on nil:NilClass (Ruby) or TypeError: Cannot read property of undefined (JS)\n**Fix**: Trace the nil backward to its source. Usually a missing association or query returning empty.\n**Trap**: Do NOT add nil checks everywhere — fix the source\n\n### Pattern: Stale Dependencies\n**Signal**: Method exists in source but \"not found\" at runtime\n**Fix**: Check autoloading, require statements, bundle\u002Fpackage lock freshness\n**Trap**: Do NOT duplicate the method in a new location\n\n---\n\n## Escalation Envelope (ECL v2.0)\n\nWhen the 3-failure-same-category threshold fires, the ESCALATE step MUST emit a `repair-failed-report.envelope.json` next to the failure log. This is the contract Vivi uses to hand off to VIGIL (`vivi-to-vigil.yaml`).\n\n### Required envelope fields\n\n| Field | Value |\n|---|---|\n| `from.eidolon` | `vivi` |\n| `to.eidolon` | `vigil` |\n| `performative` | `ESCALATE` |\n| `artifact.kind` | `repair-failed-report` |\n| `constraints.trust_level` | `high` |\n| `assumptions[0]` | `\"trigger: 3-failure-same-category\"` (ECL §2.2.3) |\n\nUse the template at `templates\u002Frepair-failed-report.envelope.json`.\n\n### Required payload fields (per `schemas\u002Frepair-failed-report-profile.v1.json`)\n\n- `kind: repair-failed-report`\n- `eidolon: vivi`\n- `failure_category` — the bucketed category (`flaky-test`, `dep-missing`, `convention-violation`, etc.)\n- `attempts >= 3` — must be at or above the threshold\n- `last_test_command` — the exact reproduction command\n\n### Integrity\n\n`integrity.method=sha256` and `integrity.value` must equal `shasum -a 256` of the payload bytes at emit time. The receiving VIGIL session uses this to detect tampering or version drift before opening its own investigation.\n\n### Skip when\n\n`ECL_VERSION` is absent in the install root. The escalation still happens — only the envelope sidecar is skipped.\n\n---\n\n*Failure Recovery Skill — evidence-gated, targeted, loop-aware*\n",{"name":5,"metadata":44,"description":7},{"phase":45,"methodology":46},"V-Verify","Vivi","main","42ce382409178ece647a93f841a86119e8d74a65",".eidolons\u002Fvivi\u002Fskills\u002Ffailure-recovery",0,"https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma","https:\u002F\u002Fgithub.com\u002FRynaro","https:\u002F\u002Fhlavezzo.me","A Code Alchemist with a passion for weaving tales and inscribing transmutation circles in pure code.","2026-10-18 20:39:25",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add Rynaro\u002Fprisma --skill vivi-failure-recovery",{"tool":62,"command":63},"bunx","bunx skills add Rynaro\u002Fprisma --skill vivi-failure-recovery",{"tool":65,"command":66},"pnpm","pnpm dlx skills add Rynaro\u002Fprisma --skill vivi-failure-recovery","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Ffailure-recovery\u002FSKILL.md",true,[],[71,96,125,148,177,198],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":39},"01M71S3X05FSJA01D22MH39Y0W","vivi-verify-incoming","Load when reading any upstream artefact handed off to Vivi that carries a sibling .envelope.json. BLOCKING per ECL §6.2.2: the orchestrator MUST have verified the envelope's SHA-256 (eidolons verify-envelope --block \u002F eidolons run --verify) and recorded a verify_pass before dispatch. If no verify_pass exists for the message_id, or a verify_fail is present, REFUSE to process the payload and hand back to the orchestrator. Symmetric receiver gate — every Eidolon enforces it identically.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Fverify-incoming\u002FSKILL.md",[],[78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,28,95,23],"verify","vivi verify incoming","verify incoming","run","sha-256","json","orchestrator","process","dispatch","back","message","upstream","id","receiver","block","ecl","hand","for",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":107,"publishedAt":39},"01M71S3S2E46S6AZEV07AJ75TK","vivi-parallel-tracks","Load ONLY under TRANCE authorization when the Plan phase yields N independent, non-overlapping implementation tracks (disjoint file sets). Operationalizes the TRANCE G4 form — parallel multi-track implementation in mandatory git-worktree isolation, max 5 clean-context tracks, a per-track verifier cascade, a non-fungible per-track ≤3 reflection budget, explicit stop conditions, and a single-threaded merge\u002Faggregation step. Absent TRANCE gating, Vivi runs exactly as today: single-track A→P→I→V→Δ\u002FR.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Fparallel-tracks\u002FSKILL.md",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":105,"taxonomyTypeDesc":106},"01JBSEEDCAT000000000000040","财务","PROFESSION","适用职业",[108,109,110,111,112,113,114,115,116,117,118,119,120,28,121,122,123,124,24,23],"parallel","tracks","parallel tracks","vivi parallel tracks","file","only","reflection","clean","plan phase","as","verifier","form","multi","worktree isolation","track","gating","single",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":39},"01M71S3N09VY1H2QHXXP4SKY2X","vivi-methodology","Full Vivi cycle reference — A(nalyze) → P(lan) → I(mplement) → V(erify) → Δ(Delta)\u002FR(eflect). Use when the task is a non-trivial feature implementation in a brownfield codebase and you need the complete methodology reference: complexity routing, evidence-grounded planning rules, test-anchoring requirements, and failure-escalation thresholds.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Fmethodology\u002FSKILL.md",[],[132,133,134,38,135,35,136,137,138,139,140,141,142,143,144,145,146,32,147,23],"methodology","vivi methodology","planning","Rules","evidence","complexity","delta","task","cycle","feature implementation","brownfield","full","requirements","feature","complete","you",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":159,"publishedAt":39},"01M71S3GT0M84EHZ2SJZKV61N9","vivi-memory-management","Load at Vivi session start, session end, or when you notice a repeating pattern across tasks. CRYSTALIUM-primary memory protocol: when mcp__crystalium__* tools are available, route ALL memory through CRYSTALIUM (recall\u002Fcommit\u002Fingest\u002Fplan_checkpoint\u002Fsession_end). The local agents\u002Fmemories\u002F*.md files are the standalone fallback for when CRYSTALIUM is absent — EIIS conformance. Never write both.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Fmemory-management\u002FSKILL.md",[154],{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,147,176,27,23],"memory","management","memory management","vivi memory management","MCP","commit","tasks","plan","write","never","files","route","across","local","end","session start","standalone",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":39},"01M71S3E067YRRFH7304VYYF32","vivi-loop-native","Load in Vivi's V (Verify) phase. The core capability that distinguishes Vivi from its predecessor APIVR-Δ: drive the closed, autonomous, bounded edit-run-test loop (`eidolons sandbox loop`) as its `--fix-hook`, consuming localized feedback, retrying in fresh context, refusing to game the tests, and gating on pass^k. Use whenever the task has an executable test oracle and a loop-competent host.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Floop-native\u002FSKILL.md",[],[184,185,186,187,188,189,190,191,192,193,194,35,139,195,117,196,197,28,123,24],"loop","native","vivi loop native","oracle","sandbox","test","core","game","feedback","autonomous","fix","tests","fresh","host",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":205,"publishedAt":39},"01M71S387B7BTVXATQBANHR6R1","vivi-esl-hop","ESL lifecycle hop — when the cortex routes a non-trivial change to Vivi in an ESL-enabled project (tonberry MCP available), Vivi owns the in_progress (implement) hop as the MAKER: declare has_code, run the loop-native A→P→I→V→Δ\u002FR cycle in an isolated worktree, hand off to the CHECKER (never self-verify). Absent tonberry → implement normally (ESL opt-in).","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Fesl-hop\u002FSKILL.md",[204],{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},[206,207,208,164,209,210,211,212,184,169,140,213,214,215,117,94,216,23,217,218],"hop","esl","vivi esl hop","implement","code","lifecycle","cortex","self","maker","project","checker","opt","owns"]