/recovery-full

description: "Full recovery workflow: diagnose -> crawl -> audit -> plan -> monitor. Respects Change Governor mode."
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, mcp__*

Recovery Full Workflow

Zweck

Verkettung aller fuenf Recovery-Commands in einem Durchlauf (Diagnose -> Crawl -> Audit -> Plan -> Monitor). Ein Befehl fuer den vollstaendigen Recovery-Workflow von Diagnose bis Monitoring-Setup. Alle Schritte teilen eine gemeinsame `run_id` fuer end-to-end Traceability.

Change Governance

Keine Live-Aenderungen ohne expliziten Modus + Budget + Freigabe. Bei breiten Instruktionen wie "alles", "mach alles", "ALLESS": **Hard Stop** per `SEO_CHANGE_GOVERNOR.md`.

Vor jedem Write: Change Plan ausgeben. Nach jedem Write: Live QA + `change-history.ndjson` Eintrag. Budget-Tracking ueber die gesamte Session. `recovery-audit` muss VOR der ersten Schreiboperation laufen wenn `change-history.ndjson` existiert.

Settlement-Gate-Verhalten (Pflicht)

Wenn `~/.cache/seo-rescue/{slug}/recovery-gate.json` mit `settlement_gate_active: true` existiert:

• `recovery-full` darf **keine** Live-Aenderungen vorschlagen oder durchfuehren
• `recovery-full` darf nur folgende Schritte ausfuehren:
• Diagnose (read-only)
• Crawl (read-only)
• Audit (read-only)
• Monitoring-Render (read-only)
• Re-Evaluation-Report
• Ticketliste fuer Rico / Entwicklung
• **Plan-After-Gate-Dokument** anstelle eines normalen Action-Plans

Wenn der User trotzdem Live-Aenderungen fordert

• Stop mit Begruendung
• Keine Ausfuehrung
• Konkrete Unlock-Kriterien aus `SEO_SETTLEMENT_GATE.md` section 9 nennen
• Standard Settlement-Gate Response aus `SAFE_LIVE_CHANGE_RULES.md` ausgeben
• Hinweis auf `next_allowed_review_date` aus dem Gate-Objekt

Plan-After-Gate-Dokument

Statt eines normalen Action-Plans erzeugt `recovery-full` bei aktivem Gate ein Plan-After-Gate-Dokument:

{
  "type": "plan_after_gate",
  "settlement_gate_active": true,
  "live_changes_allowed": false,
  "next_allowed_review_date": "...",
  "prepared_now": [
    "schema_drafts",
    "title_drafts",
    "rico_briefings",
    "rollback_plans"
  ],
  "deferred_until_unlock": [
    "title_rewrites",
    "internal_link_additions",
    "cms_slot_patches",
    "category_deactivations"
  ],
  "unlock_criteria_status": {
    "time": "not_met|met",
    "data": "not_met|partial|met",
    "stability": "not_met|partial|met",
    "decision": "not_met|met"
  }
}

Trigger

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

Input-Kontrakt

| Feld | Quelle | Pflicht | |------|--------|---------| | `domain` | CLI-Argument | ja |

Ablauf

Schritt 1: Domain normalisieren + Run-ID generieren

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

Die resultierenden Werte (`input_domain`, `domain`, `canonical_domain`, `slug`) werden an alle Sub-Commands weitergegeben.

Generiere eine gemeinsame `run_id` fuer den gesamten Workflow:

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

Diese `run_id` wird in ALLE Sub-Command-Outputs eingebettet (befund.json, issues.json, action-plan.json, history.ndjson-Eintrag). Sie ermoeglichen spaetere Korrelation aller Artifacts aus einem Full-Run.

Schritt 2 [1/5]: Diagnose ausfuehren

Gib aus: `"[1/5] Starte Diagnose fuer {domain}..."`

Lies und befolge `commands/recovery-diagnose.md`. Uebergib die gemeinsame `run_id`.

Nach Abschluss:

• Lies `~/.cache/seo-rescue/{slug}/befund.json`
• Gib Kurz-Befund aus: VI, Diagnosis, Severity, data_quality; falls `hardening_candidates` non-null und nicht leer: zusaetzlich `Hardening-Kandidaten: {n} (knocking-at-the-door, N=1 experimentell)` — recovery-plan konsumiert sie in Schritt 5 als Quick-Win-Evidenz
• Sammle `warnings` und `errors` fuer die Gesamtzusammenfassung
• Pruefe status:
• `"failed"` — Pruefe ob alternative Datenquellen (CSV-Imports) vorhanden sind. Falls JA: Warnung, weiter mit eingeschraenktem Workflow. Falls NEIN: Abbruch des gesamten Workflows. Ohne jede Datengrundlage kein sinnvoller Fortschritt.
• `"partial"` — Warnung, weitermachen.
• `"complete"` — Weitermachen.

Schritt 3 [2/5]: Crawl ausfuehren

Gib aus: `"[2/5] Starte Crawl..."`

Lies und befolge `commands/recovery-crawl.md`. Uebergib die gemeinsame `run_id`.

Nach Abschluss:

• Lies `~/.cache/seo-rescue/{slug}/issues.json`
• Gib Issue-Summary aus: critical/high/medium/low, crawler_provider
• Sammle `warnings` und `errors` fuer die Gesamtzusammenfassung
• Pruefe status:
• `"failed"` — Warnung eintragen. Versuche CSV-Import-Fallback (gemaess `commands/recovery-crawl.md`). Falls Fallback ebenfalls fehlschlaegt: Warnung, weiter mit Plan nur auf Basis der Diagnose.
• `"partial"` / `"complete"` — Weitermachen.

Schritt 4 [3/5]: Audit ausfuehren

Gib aus: `"[3/5] Starte Change-Audit..."`

Lies und befolge `commands/recovery-audit.md`. Uebergib die gemeinsame `run_id`.

Dieser Schritt materialisiert den Settlement-Gate-State (`recovery-gate.json`) und das `hypothesis_registry`, das Schritt 5 (Plan) fuer das Hypothesis Verification Gate benoetigt. Er laeuft IMMER — auch ohne `change-history.ndjson` (dann per Reconstruction-Priority degradiert oder mit leerem Registry und `never_triggered`-Gate).

Nach Abschluss:

• Lies `~/.cache/seo-rescue/{slug}/change-audit.json`
• Gib Kurz-Summary aus: Changes detected, Settlement-Gate-Status, hypothesis_registry-Groesse
• Sammle `warnings` und `errors` fuer die Gesamtzusammenfassung
• Pruefe status:
• `"failed"` — Warnung. Weiter mit Plan; der Plan degradiert dann gemaess `hypothesis_gate_no_audit_output` auf Roadmap-only.
• `"partial"` / `"complete"` — Weitermachen.

Schritt 5 [4/5]: Action-Plan erstellen

Gib aus: `"[4/5] Erstelle Action-Plan..."`

Lies und befolge `commands/recovery-plan.md`. Uebergib die gemeinsame `run_id`.

Nach Abschluss:

• Lies `~/.cache/seo-rescue/{slug}/action-plan.json`
• Gib Top-5 Massnahmen mit Evidence aus