/recovery-plan

description: "Generate prioritized action plan from diagnosis and crawl issues with Change Governor risk points."
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, mcp__*

Recovery Plan

Zweck

Aus Diagnose-Befund und Crawl-Issues einen priorisierten, phasengerechten Action-Plan ableiten. Beruecksichtigt Recovery-Phase, Do-Not-Touch-Prinzip, Batch-Change-Limits und (sofern aktiv) den Settlement Gate. Der Plan setzt keine SEO-Aenderungen automatisch um. Er dient der menschlichen Freigabe.

Change Governance

Mode: `audit_only`. Change Budget: 0. Keine Live-Shop-Writes.

Jede geplante Aenderung muss als Change Plan mit Risikopunkten ausgegeben werden (Format: `change-budget.schema.json`). Der Plan referenziert `SEO_CHANGE_GOVERNOR.md` fuer die Punkteberechnung. Human Approval Gate per `SAFE_LIVE_CHANGE_RULES.md`. Settlement-Gate-Pruefung pro `SEO_SETTLEMENT_GATE.md`.

Settlement Gate Pre-Check (Pflicht vor Planung)

Vor jeder Planung muss geprueft werden:

1. **Gibt es einen aktiven Settlement Gate?** — Lies `~/.cache/seo-rescue/{slug}/recovery-gate.json`. Falls Datei existiert und `settlement_gate_active = true`: weiter mit Schritt 2. Sonst: normaler Planungs-Ablauf.

**Writer dieser Datei ist `recovery-audit`** (siehe `commands/recovery-audit.md`, Schritt 7: Settlement-Gate-Detection) — recovery-plan liest sie nur. Fehlt die Datei, gilt der Gate als `never_triggered`. Ausnahme: Wenn `change-history.ndjson` existiert und Eintraege mit `triggered_settlement_gate: true` ODER einen un-auditierten Major Batch (Schwellenwerte per `SEO_SETTLEMENT_GATE.md` section 3) enthaelt, zuerst `/seo-rescue:recovery-audit` ausfuehren, damit der Gate-State materialisiert wird — sonst Warnung `gate_state_possibly_stale` eintragen. 2. **Wann war der letzte Major Batch?** — Aus `change-history.ndjson` letzten Eintrag mit `triggered_settlement_gate: true` lesen. 3. **Gibt es Re-Evaluation-Daten?** — Mindestens 2 von: GSC-Pull nach `started_at`, SF-Crawl nach `started_at`, Live-HTTP-Checks, DataForSEO-Snapshot, Sistrix-Signal, Backlink-Audit. 4. **Sind Unlock-Kriterien erfuellt?** — Per `SEO_SETTLEMENT_GATE.md` section 9: time, data, stability, decision.

Verhalten bei aktivem Gate

Wenn `settlement_gate_active = true`:

• **Keine Live-Planung.** Plan wird als Read-only Roadmap erzeugt.
• Massnahmen werden in vier Buckets eingeordnet:
• `allowed_during_gate` — Audit, Pulls, Briefings, Rollback-Drafts
• `blocked_until_re_eval` — alles was Live-Writes braucht, ohne Notfall
• `emergency_only` — nur unter `SEO_SETTLEMENT_GATE.md` section 7.A oder 7.B
• `prepare_now_execute_later` — Schema-Drafts, Title-Drafts, Rico-Tickets — Vorbereitung erlaubt, Live-Push verboten
• `requires_human_approval: true` bleibt gesetzt, aber `live_changes_allowed: false`.
• `next_allowed_review_date` und `unlock_status` (`blocked | partial | open`) aus der Gate-Datei in den nested `settlement_gate_status`-Mirror uebernehmen (analog `recovery-diagnose`). Die operativen Plan-Felder (`live_changes_allowed`, `allowed_now`, `blocked_now`, `emergency_exceptions`, `reason`) bleiben flach daneben.

Pflichtfelder im Output bei aktivem Gate

{
  "settlement_gate_status": {
    "active": true,
    "next_allowed_review_date": "2026-06-06",
    "unlock_status": "blocked"
  },
  "live_changes_allowed": false,
  "allowed_now": [
    "act-001 (audit)",
    "act-002 (rico-briefing)"
  ],
  "blocked_now": [
    "act-003 (title-rewrite — blocked_until_re_eval)",
    "act-004 (cms-slot-patch — blocked_until_re_eval)"
  ],
  "emergency_exceptions": [],
  "reason": "major_batch_settlement_window"
}

Wenn der User auf Live-Aenderung waehrend Gate drueckt, **muss** Claude die Standard-Settlement-Gate-Antwort aus `SAFE_LIVE_CHANGE_RULES.md` ausgeben und stoppen. Ungenutztes Budget aus vorherigen Wochen darf nicht als Freigabe interpretiert werden ("Reserve bleibt Reserve").

Trigger

`/seo-rescue:recovery-plan <domain>`

Input-Kontrakt

| Feld | Quelle | Pflicht | |------|--------|---------| | `domain` | CLI-Argument | ja | | `befund.json` | Cache (recovery-diagnose) | nein (degradiert) | | `befund.json.hardening_candidates` | Cache (recovery-diagnose, Schritt 11 — experimental N=1) | nein (optional; `null` wenn GSC fehlte) | | `issues.json` | Cache (recovery-crawl) | nein (degradiert) |

**Input-Flexibilitaet:**

| Verfuegbare Inputs | Plan-Typ | |-------------------|---------| | `befund.json` + `issues.json` | Vollstaendiger Plan (Diagnose + technische Issues) | | Nur `befund.json` | Diagnose-Plan (ohne technische Issue-Details) | | Nur `issues.json` | Technischer Plan (ohne VI/Keyword-Kontext) | | Keines, aber `imports/` vorhanden | Minimaler Plan aus Import-Daten | | Nichts verfuegbar | `failed` — Abbruch |

Capabilities

Keine externen API-Calls — recovery-plan arbeitet ausschliesslich auf gecachten Artifacts und Referenzdokumenten.

Ablauf

Schritt 1: Domain normalisieren

Normalisiere den Input via `normalizeDomain()` aus `lib/safe.js`.

Schritt 2: Run-ID generieren

Falls eine `run_id` vom Orchestrator (`recovery-full`) uebergeben wurde: diese unveraendert verwenden, KEIN eigenes Prefix erzeugen. Sonst generiere eine eindeutige Run-ID fuer diesen Lauf:

node -e "const { randomUUID } = require('crypto'); console.log('plan-' + randomUUID().slice(0,8) + '-' + Date.now())"

Schritt 3: Inputs laden

Lade `befund.json` und `issues.json` aus `~/.cache/seo-rescue/{slug}/`.

• `befund.json` fehlt → Warnung, weiter ohne Diagnose-Kontext (Plan eingeschraenkt)
• `befund.json` status=`failed` → Warnung, behandle wie fehlend
• `issues.json` fehlt → Warnung, Plan nur auf Basis der Diagnose
• `issues.json` status=`failed` → Warnung, Plan nur auf Basis der Diagnose
• Beide fehlen und kein Import-Verzeichnis → Status `failed`, Abbruch mit Hinweis: erst `recovery-diagnose` und/oder `recovery-crawl` ausfuehren

**Data-Quality der Inputs pruefen:**

Wenn `befund.json.data_quality = "poor"`