[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71S2AWPET7PZG5NPG76D5FA":3,"skill-same:01M71S2AWPET7PZG5NPG76D5FA":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},"01M71S2AWPET7PZG5NPG76D5FA","ramza-parallel-spec",null,"TRANCE-only G3 evaluator-optimizer mode: fan out 2-4 perspective-diverse clean-context candidate specs, score with a bias-hardened evaluator anchored on ramza-score, judge-merge into ONE spec, terminate at confidence ≥85% or hard cap 3 iterations. Read-only; never the default — runs ONLY when the cortex authorizes TRANCE.","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\u002Framza\u002Fskills\u002Fparallel-spec\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"ramza parallel spec","spec","parallel","at","merge","cap","with","optimizer","candidate","one","fan out","when","only","bias","clean","default","mode","read-only","never","cortex","2026-11-10 13:02:02",false,"---\nname: ramza-parallel-spec\ndescription: \"TRANCE-only G3 evaluator-optimizer mode: fan out 2-4 perspective-diverse clean-context candidate specs, score with a bias-hardened evaluator anchored on ramza-score, judge-merge into ONE spec, terminate at confidence ≥85% or hard cap 3 iterations. Read-only; never the default — runs ONLY when the cortex authorizes TRANCE.\"\nmetadata:\n  methodology: RAMZA\n  phase: TRANCE\n---\n\n# RAMZA — Parallel Spec Mode (G3 evaluator-optimizer)\n\nThis mode **wraps** the standard RS→S→P→E→C→T→R→A cycle — it does NOT replace it.\nIt operationalizes the G3 TRANCE form named in the nexus trance-matrix (\"Generator +\nevaluator + termination gate; cap 3 iterations\").\n\n## Activation — TRANCE-GATED (never default)\n\n**This mode is TRANCE-gated. Do NOT fan out candidate specs at standard tier; run\nthe single-pass RS→S→P→E→C→T→R→A cycle instead.**\n\nActivate ONLY when the cortex authorizes TRANCE — i.e. BOTH complexity AND stakes\nflags hold: complexity 10–12 (per `ramza-score --rubric complexity`) STRATEGIC\u002FCHANGE\nspecs, multi-service architecture, or high-rework-risk system design. At standard\ntier, fall back to the normal cycle.\n\n## Read-vs-write safety\n\nRAMZA is READ-ONLY in every phase (`DESIGN-RATIONALE.md` D2), so the parallel\ngenerator branches are the explicitly-SAFE parallel-READ case — **NO worktree\nisolation is required** (R1-01). This is distinct from Vivi\u002FAPIVR-Δ's\nparallel-WRITE, which does need worktree isolation.\n\n## The cycle: GENERATE → EVALUATE → JUDGE-MERGE → TERMINATE\n\n### 1. GENERATE (perspective-diverse fan-out)\n\nFan out **2-4 clean-context generator branches** (default 3, hard cap 4). Each\nbranch receives the SAME Scope + Pattern context but a DIFFERENT assigned\nperspective, producing a full candidate draft spec:\n\n- one **conservative** (low-risk, proven)\n- one **pattern-leveraging** (maximize reuse of existing conventions)\n- one **innovative** (novel approach)\n- optionally one **risk-minimizing** (blast-radius-first)\n\nPerspective diversity is **deliberate**, not naive N-identical sampling — quality\ndominates raw diversity, so cap at 3-4 high-quality branches, never spawn N clones\n(R3-04, R3-06; cost-ceiling C1 max 5 → capped at 4 here because spec generation is\nexpensive). Use **clean-context subagents** so branches cannot self-condition on each\nother's trajectory (R1-03).\n\n### 2. EVALUATE (bias-hardened scoring)\n\nA single evaluator scores each candidate through the tool — never hand-computed:\n\n```\necho '{\"alignment\":9,\"correctness\":8,\"maintainability\":7,\"performance\":7,\"simplicity\":6,\"risk\":7,\"innovation\":5}' \\\n  | ramza-score --rubric explore --state \u003Cstate> --label \"\u003Ccandidate-perspective>\"\n```\n\nThe 7-dimension weighted rubric (Alignment 25% + Correctness 20% +\nMaintainability 15% + Performance 15% + Simplicity 10% + Risk 10% + Innovation\n5%, see `docs\u002Fmethodology\u002Fscoring.md`) is arithmetic done by `ramza-score`, not\nthe evaluator — the evaluator's job is producing honest per-dimension inputs\nwhile applying EXPLICIT LLM-as-judge bias mitigations (R3-09):\n\n- **Strip authoring-branch identity\u002Flabel** from each candidate before scoring\n  (counters self-preference \u002F identity bias).\n- **Randomize \u002F rotate candidate presentation order** across the comparison\n  (counters position bias).\n- **Length-normalize** — judge on rubric-dimension content, not verbosity\n  (counters verbosity bias).\n- **Anchor on deterministic checks** — prefer `ramza-lint` \u002F `ramza-ears-lint`\n  and the dependency\u002Fconstraint layers already in the Test (T) phase as the\n  trust anchor over pure LLM judgment.\n\nRecord the per-candidate `ramza-score` results (each call appends to the state\nfile's `gates[]` and the calibration log) and the bias mitigations applied, so\nthe evaluation is auditable in the final spec.\n\n### 3. JUDGE-MERGE (mandatory aggregation)\n\nSynthesize ONE spec by taking the **highest-scoring approach per dimension**:\n\n- Record which candidate won each dimension and why, via `[DECISION]` markers\n  (per-dimension provenance table).\n- Carry every rejected candidate's rationale into the **Rejected Alternatives**\n  section (a full-tier-required section, see `docs\u002Fmethodology\u002Ftiers.md`) —\n  never silently discard a losing branch.\n\nThe result is one synthesized dual-format spec (Markdown + YAML\u002FJSON) that\nstill passes through the normal Assemble exit gates — `ramza-freeze`, then\n`ramza-verify-emit` before any envelope is emitted. Downstream sees exactly one\nspec + one validated ECL envelope, identical to the standard cycle. The\nparallel mode is invisible at the hand-off boundary.\n\n### 4. TERMINATE (bounded)\n\nStop when the merged-spec confidence **≥85%** (`ramza-score --rubric\nconfidence` at the Assemble gate) OR the iteration count reaches the **hard cap\nof 3** — whichever comes first. The cap is inviolable (inherited unchanged from\nSPECTRA, `DESIGN-RATIONALE.md` D2; the nexus trance-matrix R4 refusal gate). On\nnon-convergence, emit a `[GAP]`\u002F`[BLOCKED]` gap report and escalate to the\nhuman — **do not loop past the cap**.\n\n## Hard constraints (P0)\n\n1. TRANCE-only — never the default; standard tier runs the single-pass cycle.\n2. READ-ONLY; no worktree isolation needed (read-only ⇒ safe parallel).\n3. Cap branches at 4 (default 3); cap iterations at 3.\n4. Evaluator MUST apply identity-strip + order-rotate + length-normalize +\n   deterministic-anchor and record them auditably; scoring arithmetic always\n   runs through `ramza-score`, never hand-computed.\n5. JUDGE-MERGE produces ONE spec with per-dimension `[DECISION]` provenance,\n   and still passes through `ramza-freeze` + `ramza-verify-emit` before\n   emission.\n6. Non-convergence → `[GAP]` escalation, never an unbounded loop.\n\nSee `SPEC.md` \"## Parallel spec mode (TRANCE-gated)\" for the\nfull methodology section and `DESIGN-RATIONALE.md` for the succession's\nresearch basis.\n\n---\n\n*RAMZA — Parallel Spec Mode (TRANCE \u002F G3)*\n","# RAMZA — Parallel Spec Mode (G3 evaluator-optimizer)\n\nThis mode **wraps** the standard RS→S→P→E→C→T→R→A cycle — it does NOT replace it.\nIt operationalizes the G3 TRANCE form named in the nexus trance-matrix (\"Generator +\nevaluator + termination gate; cap 3 iterations\").\n\n## Activation — TRANCE-GATED (never default)\n\n**This mode is TRANCE-gated. Do NOT fan out candidate specs at standard tier; run\nthe single-pass RS→S→P→E→C→T→R→A cycle instead.**\n\nActivate ONLY when the cortex authorizes TRANCE — i.e. BOTH complexity AND stakes\nflags hold: complexity 10–12 (per `ramza-score --rubric complexity`) STRATEGIC\u002FCHANGE\nspecs, multi-service architecture, or high-rework-risk system design. At standard\ntier, fall back to the normal cycle.\n\n## Read-vs-write safety\n\nRAMZA is READ-ONLY in every phase (`DESIGN-RATIONALE.md` D2), so the parallel\ngenerator branches are the explicitly-SAFE parallel-READ case — **NO worktree\nisolation is required** (R1-01). This is distinct from Vivi\u002FAPIVR-Δ's\nparallel-WRITE, which does need worktree isolation.\n\n## The cycle: GENERATE → EVALUATE → JUDGE-MERGE → TERMINATE\n\n### 1. GENERATE (perspective-diverse fan-out)\n\nFan out **2-4 clean-context generator branches** (default 3, hard cap 4). Each\nbranch receives the SAME Scope + Pattern context but a DIFFERENT assigned\nperspective, producing a full candidate draft spec:\n\n- one **conservative** (low-risk, proven)\n- one **pattern-leveraging** (maximize reuse of existing conventions)\n- one **innovative** (novel approach)\n- optionally one **risk-minimizing** (blast-radius-first)\n\nPerspective diversity is **deliberate**, not naive N-identical sampling — quality\ndominates raw diversity, so cap at 3-4 high-quality branches, never spawn N clones\n(R3-04, R3-06; cost-ceiling C1 max 5 → capped at 4 here because spec generation is\nexpensive). Use **clean-context subagents** so branches cannot self-condition on each\nother's trajectory (R1-03).\n\n### 2. EVALUATE (bias-hardened scoring)\n\nA single evaluator scores each candidate through the tool — never hand-computed:\n\n```\necho '{\"alignment\":9,\"correctness\":8,\"maintainability\":7,\"performance\":7,\"simplicity\":6,\"risk\":7,\"innovation\":5}' \\\n  | ramza-score --rubric explore --state \u003Cstate> --label \"\u003Ccandidate-perspective>\"\n```\n\nThe 7-dimension weighted rubric (Alignment 25% + Correctness 20% +\nMaintainability 15% + Performance 15% + Simplicity 10% + Risk 10% + Innovation\n5%, see `docs\u002Fmethodology\u002Fscoring.md`) is arithmetic done by `ramza-score`, not\nthe evaluator — the evaluator's job is producing honest per-dimension inputs\nwhile applying EXPLICIT LLM-as-judge bias mitigations (R3-09):\n\n- **Strip authoring-branch identity\u002Flabel** from each candidate before scoring\n  (counters self-preference \u002F identity bias).\n- **Randomize \u002F rotate candidate presentation order** across the comparison\n  (counters position bias).\n- **Length-normalize** — judge on rubric-dimension content, not verbosity\n  (counters verbosity bias).\n- **Anchor on deterministic checks** — prefer `ramza-lint` \u002F `ramza-ears-lint`\n  and the dependency\u002Fconstraint layers already in the Test (T) phase as the\n  trust anchor over pure LLM judgment.\n\nRecord the per-candidate `ramza-score` results (each call appends to the state\nfile's `gates[]` and the calibration log) and the bias mitigations applied, so\nthe evaluation is auditable in the final spec.\n\n### 3. JUDGE-MERGE (mandatory aggregation)\n\nSynthesize ONE spec by taking the **highest-scoring approach per dimension**:\n\n- Record which candidate won each dimension and why, via `[DECISION]` markers\n  (per-dimension provenance table).\n- Carry every rejected candidate's rationale into the **Rejected Alternatives**\n  section (a full-tier-required section, see `docs\u002Fmethodology\u002Ftiers.md`) —\n  never silently discard a losing branch.\n\nThe result is one synthesized dual-format spec (Markdown + YAML\u002FJSON) that\nstill passes through the normal Assemble exit gates — `ramza-freeze`, then\n`ramza-verify-emit` before any envelope is emitted. Downstream sees exactly one\nspec + one validated ECL envelope, identical to the standard cycle. The\nparallel mode is invisible at the hand-off boundary.\n\n### 4. TERMINATE (bounded)\n\nStop when the merged-spec confidence **≥85%** (`ramza-score --rubric\nconfidence` at the Assemble gate) OR the iteration count reaches the **hard cap\nof 3** — whichever comes first. The cap is inviolable (inherited unchanged from\nSPECTRA, `DESIGN-RATIONALE.md` D2; the nexus trance-matrix R4 refusal gate). On\nnon-convergence, emit a `[GAP]`\u002F`[BLOCKED]` gap report and escalate to the\nhuman — **do not loop past the cap**.\n\n## Hard constraints (P0)\n\n1. TRANCE-only — never the default; standard tier runs the single-pass cycle.\n2. READ-ONLY; no worktree isolation needed (read-only ⇒ safe parallel).\n3. Cap branches at 4 (default 3); cap iterations at 3.\n4. Evaluator MUST apply identity-strip + order-rotate + length-normalize +\n   deterministic-anchor and record them auditably; scoring arithmetic always\n   runs through `ramza-score`, never hand-computed.\n5. JUDGE-MERGE produces ONE spec with per-dimension `[DECISION]` provenance,\n   and still passes through `ramza-freeze` + `ramza-verify-emit` before\n   emission.\n6. Non-convergence → `[GAP]` escalation, never an unbounded loop.\n\nSee `SPEC.md` \"## Parallel spec mode (TRANCE-gated)\" for the\nfull methodology section and `DESIGN-RATIONALE.md` for the succession's\nresearch basis.\n\n---\n\n*RAMZA — Parallel Spec Mode (TRANCE \u002F G3)*\n",{"name":5,"metadata":44,"description":7},{"phase":45,"methodology":46},"TRANCE","RAMZA","main","42ce382409178ece647a93f841a86119e8d74a65",".eidolons\u002Framza\u002Fskills\u002Fparallel-spec",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 ramza-parallel-spec",{"tool":62,"command":63},"bunx","bunx skills add Rynaro\u002Fprisma --skill ramza-parallel-spec",{"tool":65,"command":66},"pnpm","pnpm dlx skills add Rynaro\u002Fprisma --skill ramza-parallel-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Framza\u002Fskills\u002Fparallel-spec\u002FSKILL.md",true,[],[71,97,124,150,178,199],{"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,95,96,30],"verify","vivi verify incoming","verify incoming","run","sha-256","json","orchestrator","process","dispatch","back","message","upstream","id","receiver","block","ecl","hand","load","for",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":108,"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",[103],{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000040","财务","PROFESSION","适用职业",[21,109,110,111,112,31,113,33,114,115,116,117,118,95,119,120,121,122,123,30],"tracks","parallel tracks","vivi parallel tracks","file","reflection","plan phase","as","verifier","form","multi","worktree isolation","track","gating","single","phase",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"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",[],[131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,30],"methodology","vivi methodology","planning","escalation","Rules","use","evidence","complexity","delta","task","cycle","feature implementation","brownfield","full","requirements","feature","complete","thresholds","you",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":161,"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",[156],{"categoryNo":157,"categoryName":158,"taxonomyType":159,"taxonomyTypeDesc":160},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[162,163,164,165,166,167,168,169,170,37,171,172,173,174,175,176,149,177,22,30],"memory","management","memory management","vivi memory management","MCP","commit","tasks","plan","write","files","route","across","local","end","session start","standalone",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"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",[],[185,186,187,188,189,190,191,192,193,194,195,136,140,196,115,197,198,95,121,123],"loop","native","vivi loop native","oracle","sandbox","test","core","game","feedback","autonomous","fix","tests","fresh","host",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":39},"01M71S3AEKYH0JD0CFJ4GHA98E","vivi-failure-recovery","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.","https:\u002F\u002Fgithub.com\u002FRynaro\u002Fprisma\u002Fblob\u002Fmain\u002F.eidolons\u002Fvivi\u002Fskills\u002Ffailure-recovery\u002FSKILL.md",[],[206,207,208,134,209,210,136,211,212,148,213,214,215,95,22,216,217,123,30,218],"recovery","vivi failure recovery","debugging","classification","taxonomy","three","pattern","error","retries","random","break","bounded","same"]