@su-record/vibe 3.2.64 → 4.0.1

package/skills/vibe.brand-assets/templates/brand-guide.md

@@ -1,161 +0,0 @@
-# Brand Guide: {{PROJECT_NAME}}
-
-**Version**: {{VERSION}}
-**Last Updated**: {{DATE}}
-**Maintainer**: {{MAINTAINER}}
-
----
-
-## Brand Identity
-
-| Attribute | Value |
-|-----------|-------|
-| Product Name | {{PRODUCT_NAME}} |
-| Tagline | {{TAGLINE}} |
-| Category | {{CATEGORY}} (SaaS / Mobile App / Consumer / Developer Tool) |
-| Personality | {{PERSONALITY_WORDS}} |
-| Tone | {{TONE}} |
-
----
-
-## Logo
-
-| Asset | File | Usage |
-|-------|------|-------|
-| Primary logo (color) | `{{LOGO_COLOR_PATH}}` | Default usage on white/light backgrounds |
-| Primary logo (white) | `{{LOGO_WHITE_PATH}}` | Dark backgrounds |
-| Primary logo (dark) | `{{LOGO_DARK_PATH}}` | Light backgrounds where color logo lacks contrast |
-| Icon only (color) | `{{ICON_COLOR_PATH}}` | App icons, favicons, small contexts |
-| Icon only (mono) | `{{ICON_MONO_PATH}}` | Single-color contexts |
-| Wordmark only | `{{WORDMARK_PATH}}` | When icon is shown separately |
-
-### Logo Clear Space
-
-Maintain minimum clear space of **{{LOGO_CLEAR_SPACE}}** on all sides of the logo. No other elements within this zone.
-
-### Logo Minimum Size
-
-| Context | Minimum Width |
-|---------|--------------|
-| Print | {{LOGO_MIN_PRINT}} |
-| Digital | {{LOGO_MIN_DIGITAL}} |
-| Favicon | 16px (icon only) |
-
-### Logo Misuse
-
-- Do not stretch or distort the logo
-- Do not apply drop shadows to the logo
-- Do not place on busy backgrounds without a clear area
-- Do not recreate with incorrect fonts or colors
-- Do not use at sizes below minimum
-
----
-
-## Color Palette
-
-### Primary Colors
-
-| Name | Hex | RGB | HSL | Usage |
-|------|-----|-----|-----|-------|
-| {{PRIMARY_NAME}} | {{PRIMARY_HEX}} | {{PRIMARY_RGB}} | {{PRIMARY_HSL}} | Primary brand, CTAs |
-| {{SECONDARY_NAME}} | {{SECONDARY_HEX}} | {{SECONDARY_RGB}} | {{SECONDARY_HSL}} | Secondary actions |
-
-### Neutral Colors
-
-| Name | Hex | Usage |
-|------|-----|-------|
-| {{NEUTRAL_DARK}} | {{NEUTRAL_DARK_HEX}} | Primary text |
-| {{NEUTRAL_MID}} | {{NEUTRAL_MID_HEX}} | Secondary text, borders |
-| {{NEUTRAL_LIGHT}} | {{NEUTRAL_LIGHT_HEX}} | Backgrounds, dividers |
-
-### Semantic Colors
-
-| Name | Hex | Usage |
-|------|-----|-------|
-| Error | {{ERROR_HEX}} | Error states, destructive actions |
-| Success | {{SUCCESS_HEX}} | Confirmation, positive states |
-| Warning | {{WARNING_HEX}} | Caution states |
-| Info | {{INFO_HEX}} | Informational states |
-
----
-
-## Typography
-
-### Typefaces
-
-| Role | Font Family | Weight(s) | Source |
-|------|------------|-----------|--------|
-| Heading | {{HEADING_FONT}} | {{HEADING_WEIGHTS}} | {{HEADING_SOURCE}} |
-| Body | {{BODY_FONT}} | {{BODY_WEIGHTS}} | {{BODY_SOURCE}} |
-| Monospace | {{MONO_FONT}} | {{MONO_WEIGHTS}} | {{MONO_SOURCE}} |
-
-### Type Scale
-
-| Level | Size | Weight | Line Height | Use |
-|-------|------|--------|-------------|-----|
-| Display | {{DISPLAY_SIZE}} | {{DISPLAY_WEIGHT}} | {{DISPLAY_LH}} | Hero text |
-| H1 | {{H1_SIZE}} | {{H1_WEIGHT}} | {{H1_LH}} | Page titles |
-| H2 | {{H2_SIZE}} | {{H2_WEIGHT}} | {{H2_LH}} | Section headings |
-| H3 | {{H3_SIZE}} | {{H3_WEIGHT}} | {{H3_LH}} | Subsections |
-| Body | {{BODY_SIZE}} | {{BODY_WEIGHT}} | {{BODY_LH}} | Paragraphs |
-| Caption | {{CAPTION_SIZE}} | {{CAPTION_WEIGHT}} | {{CAPTION_LH}} | Labels, captions |
-
----
-
-## Iconography
-
-| Attribute | Value |
-|-----------|-------|
-| Icon library | {{ICON_LIBRARY}} |
-| Icon style | {{ICON_STYLE}} (outline / solid / duotone) |
-| Standard sizes | 16px, 20px, 24px |
-| Stroke width | {{STROKE_WIDTH}} |
-| Color usage | Match adjacent text or use `--color-primary` for emphasis |
-
----
-
-## App Icons & Favicons
-
-| Asset | Size | File | Format |
-|-------|------|------|--------|
-| Favicon | 16×16 | `public/favicon-16x16.png` | PNG |
-| Favicon | 32×32 | `public/favicon-32x32.png` | PNG |
-| Favicon bundle | 16/32/48 | `public/favicon.ico` | ICO |
-| Apple Touch Icon | 180×180 | `public/apple-touch-icon.png` | PNG |
-| Android Chrome | 192×192 | `public/android-chrome-192x192.png` | PNG |
-| Android Chrome | 512×512 | `public/android-chrome-512x512.png` | PNG |
-
----
-
-## Imagery & Illustration
-
-| Attribute | Guideline |
-|-----------|-----------|
-| Photography style | {{PHOTO_STYLE}} |
-| Illustration style | {{ILLUSTRATION_STYLE}} |
-| Image treatment | {{IMAGE_TREATMENT}} |
-| Avoid | {{IMAGE_AVOID}} |
-
----
-
-## Motion
-
-| Attribute | Value |
-|-----------|-------|
-| Default duration | 200ms |
-| Fast duration | 150ms (micro-interactions) |
-| Slow duration | 300ms (page transitions) |
-| Default easing | `cubic-bezier(0.4, 0, 0.2, 1)` |
-| Personality | {{MOTION_PERSONALITY}} (subtle / expressive / none) |
-
----
-
-## Voice & Tone
-
-| Context | Tone | Example |
-|---------|------|---------|
-| Marketing | {{MARKETING_TONE}} | {{MARKETING_EXAMPLE}} |
-| UI labels | {{UI_TONE}} | {{UI_EXAMPLE}} |
-| Error messages | {{ERROR_TONE}} | {{ERROR_EXAMPLE}} |
-| Success messages | {{SUCCESS_TONE}} | {{SUCCESS_EXAMPLE}} |
-| Empty states | {{EMPTY_TONE}} | {{EMPTY_EXAMPLE}} |

package/skills/vibe.capability-loop/SKILL.md

@@ -1,208 +0,0 @@
----
-name: vibe.capability-loop
-user-invocable: false
-invocation: [auto]
-tier: standard
-description: Use when the same agent or tool failure repeats, or a missing capability blocks progress, to reproduce the cause and build a permanent repository capability.
-triggers: [capability loop, failure loop, build capability, missing capability, agent failed, why did it fail]
-priority: 60
----
-
-# Capability Loop — Failure → Capability Building
-
-> **Principle**: "Ask what capability is missing, not why it failed." Every failure is a missing tool, guardrail, abstraction, or piece of documentation. Build the capability so the failure NEVER recurs.
-
-## When to Use
-
-| Trigger | Signal |
-|---------|--------|
-| Agent fails a task | Error, wrong output, timeout, confusion |
-| Same error occurs twice | Pattern of missing capability |
-| Agent asks clarifying question | Information not discoverable |
-| Review finds recurring issue | Systemic gap, not one-off mistake |
-| Manual intervention needed | Agent should have been self-sufficient |
-
-## Core Flow
-
-```
-FAILURE → DIAGNOSE → CLASSIFY → BUILD → VERIFY → PERSIST
-```
-
-### Step 1: DIAGNOSE — What Capability is Missing?
-
-Do NOT ask "why did it fail?" Instead ask: **"What would have prevented this failure?"**
-
-```
-Diagnosis questions (answer ALL):
-
-1. TOOL: Did the agent lack a tool to accomplish the task?
-   → Missing CLI command, missing API, missing utility function
-
-2. GUARDRAIL: Did the agent do something it shouldn't have?
-   → Missing lint rule, missing test, missing hook check
-
-3. ABSTRACTION: Did the agent struggle with unnecessary complexity?
-   → Missing helper, missing wrapper, missing shared module
-
-4. DOCUMENTATION: Did the agent lack discoverable information?
-   → Missing CLAUDE.md entry, missing code comment, missing type definition
-
-5. FEEDBACK: Did the agent not know it was doing the wrong thing?
-   → Missing error message, missing test assertion, missing type error
-```
-
-### Step 2: CLASSIFY — What Type of Capability?
-
-| Category | Example | Where to Build |
-|----------|---------|---------------|
-| **Tool** | "No way to validate schema" | New CLI command or skill |
-| **Guardrail** | "Accidentally deleted migration" | New hook or test |
-| **Abstraction** | "Copy-pasted auth logic 3 times" | New shared module |
-| **Documentation** | "Didn't know config format" | CLAUDE.md or code comments |
-| **Feedback** | "Didn't realize test was wrong" | Better error messages or types |
-
-### Step 3: BUILD — Create the Capability
-
-Based on classification, build the appropriate artifact:
-
-#### Tool → New Skill or Command
-```
-1. Create skills/{capability-name}/SKILL.md
-2. Add triggers for automatic activation
-3. Test with a simulated scenario
-```
-
-#### Guardrail → New Test or Hook
-```
-1. Add test to tests/arch-guard.test.ts (if structural)
-2. Or add check to hooks/scripts/ (if runtime)
-3. Verify it catches the original failure
-```
-
-#### Abstraction → New Module
-```
-1. Extract shared code into appropriate location
-2. Update existing callers to use new abstraction
-3. Add tests for the abstraction
-```
-
-#### Documentation → CLAUDE.md or Inline
-```
-1. If it's a constraint/gotcha → add to CLAUDE.md "Gotchas" section
-2. If it's discoverable from code → add code comment or type definition
-3. If it's a pattern → add to relevant language rule file
-```
-
-#### Feedback → Better Types or Errors
-```
-1. Add TypeScript type that prevents the mistake at compile time
-2. Or add runtime validation with clear error message
-3. Or add test that catches the mistake early
-```
-
-### Step 4: VERIFY — Reproduce and Confirm Fix
-
-```
-1. Reproduce the original failure scenario
-2. Confirm the new capability prevents it
-3. Run existing tests to verify no regressions
-4. If the capability is a test, verify it FAILS without the fix
-```
-
-**Termination branches:**
-- ✅ **Capability prevents the failure** → Step 5 PERSIST
-- ❌ **Capability does NOT prevent the failure** → Step 4.5 ESCALATE (re-diagnose or ask user)
-
-### Step 4.5: ESCALATE — When VERIFY Fails (조건부)
-
-> **진입 조건**: Step 4 VERIFY 실패. 통과했으면 이 단계 전체를 건너뛴다.
-> **Problem**: 만든 capability 가 실제로 실패를 막지 못했다는 뜻 — 대개 초기 진단이 틀렸거나(Tool 로 골랐는데 Guardrail 이 필요했다) 누락 capability 가 여럿이다.
-> **조용히 진행 금지** — 미달 capability 로그는 `.vibe/capabilities-log.md` 를 오염시키고 실패는 재발한다.
-
-에스컬레이션 루프 전문(재진단·타입 재분류·롤백 판단): `references/escalate.md`
-
-### Step 5: PERSIST — Record for Future Reference
-
-Save the capability-building decision:
-
-```
-save_memory("capability-{name}", {
-  failure: "description of what failed",
-  diagnosis: "what capability was missing",
-  category: "tool|guardrail|abstraction|documentation|feedback",
-  solution: "what was built",
-  files_changed: ["list of files"]
-})
-```
-
-Update `.vibe/capabilities-log.md`:
-
-```markdown
-## {date} — {capability-name}
-
-**Status**: resolved | escalated_to_manual | diagnosis_exhausted
-**Failure**: {what happened}
-**Missing**: {what capability was absent}
-**Tried**: {list of categories attempted, e.g., [Tool, Guardrail]}
-**Built**: {what was created (if resolved)}
-**Files**: {list}
-**Prevents**: {what class of failures this prevents (if resolved)}
-**Notes**: {for escalated/exhausted — what the user decided or what remains unsolved}
-```
-
-## Decision Tree
-
-```
-Agent failed
-    │
-    ├─ Could a TOOL have done it automatically?
-    │   YES → Build tool (skill/command/script)
-    │
-    ├─ Should the agent have been PREVENTED from doing it?
-    │   YES → Build guardrail (hook/test/lint rule)
-    │
-    ├─ Was the agent REPEATING work that should be shared?
-    │   YES → Build abstraction (module/helper/utility)
-    │
-    ├─ Did the agent lack KNOWLEDGE it needed?
-    │   YES → Add documentation (CLAUDE.md/comments/types)
-    │
-    └─ Did the agent not KNOW it was wrong?
-        YES → Build feedback (types/errors/tests)
-
-    ↓
-VERIFY: Does the built capability actually prevent the failure?
-    │
-    ├─ YES → PERSIST (log as "resolved")
-    │
-    └─ NO  → ESCALATE (Step 4.5)
-              │
-              ├─ Other categories untried? → Re-diagnose with exclusion list
-              │                              → BUILD next category → VERIFY
-              │
-              └─ All categories tried OR same diagnosis loops:
-                   │
-                   ├─ Interactive: Ask user (custom angle / manual / abort)
-                   └─ ultrawork: Auto-record "diagnosis_exhausted" → continue
-```
-
-## Anti-patterns
-
-- "Add a note to be more careful" → Build a guardrail instead
-- "Document the right way to do it" → If possible, make the wrong way a compile/test error
-- "Tell the agent to check X first" → Make X discoverable automatically
-- "It was a one-off mistake" → If it happened once, it will happen again. Build the capability.
-
-## Integration Points
-
-- After `/vibe.run` failure → auto-trigger capability-loop diagnosis
-- After `/vibe.review` findings → suggest capability-loop for recurring patterns
-- After manual agent correction → prompt "What capability would have prevented this?"
-
-## Done Criteria
-
-- [ ] The pre-change reproduction command and failing output are recorded.
-- [ ] The missing capability type and selection evidence are recorded.
-- [ ] The same reproduction command passes after the change.
-- [ ] The related deterministic test or guard passes.
-- [ ] The capability log contains status and verification evidence.

package/skills/vibe.capability-loop/agents/capability-designer.md

@@ -1,61 +0,0 @@
----
-name: capability-designer
-role: Designs the missing capability — hook, skill, or guard — based on root cause
-tools: [Read, Glob, Grep]
----
-
-# Capability Designer
-
-## Role
-Takes the root cause analysis and designs the correct capability to close the gap. Selects the right intervention type (hook, skill, guard, config) and produces a detailed spec for the implementer to build from.
-
-## Responsibilities
-- Map root cause classification to the correct capability type
-- Survey existing hooks, skills, and guards to avoid duplication
-- Design the capability interface: trigger, input, logic, output, and failure behavior
-- Specify integration points: where does it fit in the existing dispatch chain
-- Define the acceptance test: how will we know the capability works
-
-## Input
-- Root cause analysis from failure-analyst
-- Existing hooks directory listing (hooks/scripts/)
-- Existing skills list for context
-
-## Output
-Capability design spec:
-
-```markdown
-## Capability Design: console-log-guard hook
-
-### Type
-Pre-commit hook (PostToolUse / pre-commit shell script)
-
-### Trigger
-Fires on every `git commit` attempt, after files are staged.
-
-### Logic
-1. Run `git diff --staged` to get staged file contents
-2. Scan for pattern: `console\.log\s*\(`
-3. If found: print file:line references and exit 1 (block commit)
-4. If clean: exit 0 (allow commit)
-
-### Integration Point
-hooks/scripts/console-log-guard.sh — registered in .husky/pre-commit
-or .claude/settings.local.json PostToolUse for Bash tool.
-
-### Failure Behavior
-Block the commit with a clear error message listing offending lines.
-Never silently pass.
-
-### Acceptance Test
-1. Stage a file with console.log → commit must be blocked
-2. Stage a file without console.log → commit must proceed
-3. Staged test file (*.test.ts) → still blocked (rule applies universally)
-```
-
-## Communication
-- Reports findings to: implementer
-- Receives instructions from: orchestrator (capability-loop skill)
-
-## Domain Knowledge
-Capability selection guide: repeated failure → hook (enforce); missing workflow → skill (guide); Claude ignores rules → guard (validate output); wrong tool selected → config (constrain). Prefer hooks for enforcement over CLAUDE.md rules alone — documentation does not prevent behavior.

package/skills/vibe.capability-loop/agents/failure-analyst.md

@@ -1,55 +0,0 @@
----
-name: failure-analyst
-role: Analyzes failure transcripts to find the root cause of a missing capability
-tools: [Read, Grep, Bash]
----
-
-# Failure Analyst
-
-## Role
-Reads failure transcripts, error logs, or problem descriptions to identify the exact root cause. Distinguishes between symptoms and underlying gaps — whether the failure stems from a missing hook, an absent skill, an untrained behavior, or a guard that doesn't exist.
-
-## Responsibilities
-- Read failure transcript or error description in full before diagnosing
-- Classify failure type: hook gap, skill gap, behavior gap, guard gap, or config gap
-- Identify the precise trigger point where the system failed or went off-track
-- Rule out false positives: confirm this is a repeatable failure, not a one-off
-- State the root cause as a falsifiable hypothesis with evidence
-
-## Input
-- Failure transcript (conversation log, error output, or description)
-- Optional: related hooks, skills, or config files for context
-
-## Output
-Root cause analysis:
-
-```markdown
-## Failure Analysis
-
-### Symptom
-Claude generated console.log statements in a commit even though this is
-forbidden by project rules.
-
-### Root Cause
-Hook gap: no pre-commit hook validates for console.log before commit.
-The CLAUDE.md rule exists but there is no enforcement mechanism.
-
-### Evidence
-- CLAUDE.md line 42: "No console.log in commits"
-- git log shows 3 recent commits with console.log (commits abc, def, ghi)
-- No hooks/scripts/ file performs this check
-
-### Classification
-Hook gap — enforcement is missing, rule exists only as documentation.
-
-### Hypothesis
-Adding a pre-commit hook that scans staged files for console.log will
-prevent this failure class. Confidence: HIGH.
-```
-
-## Communication
-- Reports findings to: capability-designer
-- Receives instructions from: orchestrator (capability-loop skill)
-
-## Domain Knowledge
-Failure taxonomy: hook gap (no enforcement), skill gap (no workflow guidance), behavior gap (Claude ignores instruction), guard gap (no validation after action), config gap (wrong model/tool/permission). Root cause must be one of these — not a symptom restatement.

package/skills/vibe.capability-loop/agents/implementer.md

@@ -1,50 +0,0 @@
----
-name: implementer
-role: Builds the new capability from the design spec
-tools: [Read, Write, Edit, Bash, Glob]
----
-
-# Implementer
-
-## Role
-Builds the capability specified by capability-designer. Creates or modifies the necessary hook script, skill file, or config entry. Follows the existing project conventions exactly — no new patterns unless the design requires them.
-
-## Responsibilities
-- Read the capability design spec fully before writing any code
-- Check existing files in the target directory before creating new ones
-- Implement the logic exactly as specified — no scope creep
-- Register the capability in the correct integration point
-- Run a smoke test to confirm basic functionality before handing off to tester
-
-## Input
-- Capability design spec from capability-designer
-- Target directory path (hooks/scripts/, skills/, agents/)
-- Existing related files for convention reference
-
-## Output
-Implementation summary:
-
-```markdown
-## Implementation: console-log-guard hook
-
-### Created Files
-- hooks/scripts/console-log-guard.sh
-
-### Modified Files
-- .husky/pre-commit (added console-log-guard invocation)
-
-### Smoke Test
-- Staged file with console.log → hook blocked commit (exit 1) ✓
-- Staged file without console.log → hook passed (exit 0) ✓
-
-### Notes
-- Script uses grep -n for line numbers in error output
-- Skips node_modules/ automatically via git's staging filter
-```
-
-## Communication
-- Reports findings to: tester
-- Receives instructions from: orchestrator (capability-loop skill)
-
-## Domain Knowledge
-Follow CLAUDE.md complexity limits: functions ≤50 lines, nesting ≤3 levels. Hook scripts must be idempotent and exit cleanly. Skills must use the established SKILL.md frontmatter format. Never create a new integration pattern without checking existing hooks/scripts/ for the established approach.

package/skills/vibe.capability-loop/agents/tester.md

@@ -1,53 +0,0 @@
----
-name: tester
-role: Verifies the new capability prevents the original failure
-tools: [Bash, Read, Write]
----
-
-# Tester
-
-## Role
-Validates that the implemented capability closes the specific failure identified by failure-analyst. Runs both the original failure scenario and boundary cases to confirm the capability works and does not introduce regressions.
-
-## Responsibilities
-- Reproduce the original failure condition before testing the fix
-- Confirm the capability blocks or prevents the failure as designed
-- Test boundary cases from the acceptance criteria in the design spec
-- Verify the capability does not interfere with valid/normal workflow
-- Report results with clear pass/fail evidence for each case
-
-## Input
-- Implementation summary from implementer
-- Capability design spec acceptance tests from capability-designer
-- Original failure description from failure-analyst
-
-## Output
-Test verification report:
-
-```markdown
-## Capability Test: console-log-guard hook
-
-### Original Failure Reproduction
-- Staged file with console.log before fix → commit succeeded (failure confirmed)
-
-### Acceptance Tests
-- [x] Staged file WITH console.log → commit blocked, shows file:line reference
-- [x] Staged file WITHOUT console.log → commit proceeds normally
-- [x] Multiple files staged, one has console.log → commit blocked, lists all violations
-- [x] No staged files → hook exits 0, no error
-
-### Regression Check
-- [x] Normal commit flow (clean code) → unaffected
-- [x] Hook does not run on `git push` → correct, pre-commit only
-
-### Verdict
-CAPABILITY VERIFIED — original failure class is now prevented.
-Loop closed.
-```
-
-## Communication
-- Reports findings to: orchestrator (capability-loop skill) / user
-- Receives instructions from: orchestrator
-
-## Domain Knowledge
-A capability is verified only when: (1) the original failure is reproduced without the fix, (2) the fix prevents the failure, and (3) normal workflow is unaffected. If step 1 cannot be reproduced, halt and re-examine the root cause — the failure may have been a false positive.

package/skills/vibe.capability-loop/references/escalate.md

@@ -1,86 +0,0 @@
-# Step 4.5 — ESCALATE (VERIFY 실패 시)
-
-> vibe.capability-loop SKILL.md Step 4 의 VERIFY 가 **실패했을 때만** 로드한다.
-> VERIFY 가 통과한 호출(정상 경로)은 이 파일을 읽지 않는다.
-
-### Step 4.5: ESCALATE — When VERIFY Fails
-
-> **Problem**: The built capability didn't actually prevent the failure. This usually means the initial diagnosis was wrong (picked `Tool` when it needed `Guardrail`), or the failure has multiple missing capabilities.
->
-> **Do NOT silently proceed** — a sub-standard capability log pollutes `.vibe/capabilities-log.md` and the failure will recur.
-
-**Escalation loop:**
-
-```python
-tried = [current_diagnosis.category]  # e.g., ["Tool"]
-
-while True:
-    # Re-diagnose excluding already-tried categories
-    next_diagnosis = diagnose(failure, exclude=tried)
-
-    if next_diagnosis is None:
-        # All 5 categories (Tool/Guardrail/Abstraction/Documentation/Feedback) exhausted
-        escalate_to_user(failure, tried)
-        break
-
-    if next_diagnosis.category in tried:
-        # Stuck: diagnose keeps returning the same category
-        escalate_to_user(failure, tried)
-        break
-
-    tried.append(next_diagnosis.category)
-    capability = build(next_diagnosis)
-
-    if verify(capability, failure):
-        persist(capability)
-        return  # Success — go to Step 5
-
-    # Still failing — next iteration
-```
-
-**User escalation prompt (interactive mode):**
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-⚠️ CAPABILITY LOOP STUCK
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Failure: {original failure description}
-
-Tried capabilities (all failed to prevent the failure):
-  ❌ Tool: {what was built, why it didn't work}
-  ❌ Guardrail: {what was built, why it didn't work}
-  ❌ Documentation: {what was built, why it didn't work}
-
-Automated diagnosis has run out of angles. This failure may require
-human judgment (process issue, cross-category solution, or external factor).
-
-How would you like to proceed?
-  1. Suggest a different angle (e.g., "this is a process issue", "needs Tool+Guardrail combination")
-     → Attempt custom approach per user instruction, then enter next verify
-  2. "manual" — resolve this failure via manual intervention, end capability loop
-     (record "escalated to manual" in capabilities-log.md)
-  3. "abort" — give up, record failure only
-     (record "diagnosis exhausted" in capabilities-log.md, do not halt the rest of the workflow)
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-**ultrawork mode exception:**
-
-```python
-if ultrawork_mode:
-    # Skip user prompt: try all 5 categories in sequence, record final state
-    all_tried_exhausted = exhaust_all_categories(failure, tried)
-    record_failure_to_log(
-        status="diagnosis_exhausted",
-        tried=all_tried_exhausted,
-        failure=failure
-    )
-    return  # Proceed without blocking downstream workflow
-```
-
-**Rollback of failed builds:**
-
-- Each failed capability build should be rolled back before trying the next category (unless it's non-destructive documentation).
-- For code additions (tool/guardrail/abstraction): `git checkout -- {files}` or delete created files.
-- For docs-only additions: leave in place (low risk) but note in escalation prompt.