<!-- AUTO-GENERATED by scripts/wi-claude-rules-sync.sh — do not edit. -->
<!-- bundle: 50-beirat-plan | sources: 5 .mdc files -->
---
name: beirat
description: WI Beirat, Risk-Veto, Security-Check, go-ready planning, plan-status
---

<!-- source: .cursor/rules/wi-protect-veto-alternatives.mdc -->

# WI — Protect / Veto / Alternativen (Rule 1)

## Zweck

Bei **riskanten** Code-/Struktur-Änderungen muss der Agent **einen kurzen Beirat-Block** im Chat produzieren, daraus **3 Alternativen A/B/C** destillieren und Option A als Default bauen. Bei **Hard-Stop-Votum (`✗`)** oder User-`#Axxx stop` wartet der Agent.

Trivial-Tasks (Typo, 1 CSS-Farbe, Button-Label, Reihenfolge in statischer Liste, Kommentar) laufen **ohne** diesen Block weiter.

## Trigger (risky_only)

Beirat-Block ist Pflicht, wenn **mindestens einer** zutrifft:

- Diff ≥ ~20 Zeilen
- Registration-Submit / Registration-Form
- Mail-Versand, Reminder-Cron
- Login-/Join-URL-Generierung (Hash, Code, Expiry)
- AJAX- / REST-Handler, neue oder geänderte Route
- SQL-Query (neu, geändert, `$wpdb`)
- Nonce- / Capability-Logik
- Enqueue-Reihenfolge, Script-Loader
- Hooks / Filter mit hoher Frequenz (`init`, `wp`, `template_redirect`, `save_post`, …)
- Update-/Migration-Code (`dbDelta`, Version-Bumps)
- Cache-Layer (Transient, Object-Cache)
- Freemius-Integration (License-Gate, Permission-Manager)
- Admin-Wizard, Setup-Flow, Onboarding
- AI-Stack (→ zusätzlich [wi-ai-stack-advisory.mdc](wi-ai-stack-advisory.mdc), wenn aktiv)

**Kein Trigger:** reine Textänderung in statischem String, 1 CSS-Property, Label-Rename, Kommentar.

## Pflicht-Block im Chat (vor Umsetzung)

```
🌟 North Star #Axxx (siehe wi-north-star.mdc)
- Pol A (Teilnehmer-Wohlfühlen): ✓/–/✗ <1 Zeile>
- Pol B (Host-Zielerreichung):    ✓/–/✗ <1 Zeile>

🔎 Pre-Filter
- Musk  (delete?):     ✓/✗ <1 Zeile>
- Jobs  (demobar?):    ✓/⚠ <1 Zeile>
- Krug  (think-free?): ✓/⚠ <1 Zeile>

🧮 Musk 5-Step
1. Requirement hinterfragen: <1 Zeile>
2. Löschen:                  <1 Zeile, was kann weg>
3. Simplifizieren:            <1 Zeile>
4. Zyklen beschleunigen:      <1 Zeile>
5. Automatisieren:            <1 Zeile>

⚠️ Risiko-Scan
- Compat / Security / Speed / Admin-UX / Participant-Journey: je <ja/nein + Grund>

👥 Beirat (Patron Saints)
- Dev-Senior      (Linus Torvalds):       ✓/⚠/✗ <1 Zeile>
- Dev-Security    (Bruce Schneier):       ✓/⚠/✗ <1 Zeile>
- Dev-Performance (John Carmack):         ✓/⚠/✗ <1 Zeile>
- Sales           (Brunson + Rackham):    ✓/⚠/✗ <1 Zeile>
- Participant     (Bezos + Lufthansa):    ✓/⚠/✗ <1 Zeile — welcher Touchpoint?>
- Admin           (DHH / Jason Fried):    ✓/⚠/✗ <1 Zeile>
- Communication   (Carnegie):             ✓/⚠/✗/n-a <nur bei User-Copy/Ton>
- Strategy        (Kim/Mauborgne, ERRC):  ✓/⚠/✗/n-a <nur bei Neu-Feature>
- Copy            (Wiebe + Schwartz):     ✓/⚠/✗/n-a <nur bei User-Text, Awareness-Stufe>

👥 Beirat — situativ erweitert (je max. 1 Zeile, nur wenn Trigger unten zutrifft; sonst `— n/a`)
- Gehirngerecht   (Vera F. Birkenbihl):   ✓/⚠/✗/n-a <Wizard, Einstellungen, Explain-Text, Hilfe, komplexe Labels>
- User-Flow       (Top-Software-UX):      ✓/⚠/✗/n-a <neue/geänderte UI, Navigation, Onboarding, nächster Schritt unklar?>
- Marketing/Sales (Anforderung + Release): ✓/⚠/✗/n-a <Version/Changelog, verkaufsrelevante Copy, „wann raus?“>

Abstimmung: <alle ✓ | n ⚠ | m ✗>

Alternativen (destilliert aus Pre-Filter + Musk-5 + Beirat):

A (Default — sicherste, Krug/Birkenbihl-konform):
  <max 2 Zeilen Beschreibung>
  Revert: <1 Zeile>

B (Mittelweg — A + zusaetzlicher Nutzen):
  <max 2 Zeilen Beschreibung>
  Revert: <1 Zeile>

C (Vision — radikal/schnell/experimentell):
  <max 2 Zeilen Beschreibung>
  Revert: <1 Zeile>

→ Umsetzung: A (Soft-Warn). Wechsel: `#Axxx go B` / `#Axxx go C`.
   Bei ✗ im Beirat ODER Musk-Filter: HARD-STOP — warte auf `#Axxx go A/B/C` oder `#Axxx override`.
```

### Trigger — situative erweiterte Stimmen (vor Umsetzung)

| Stimme | Wann ausfüllen (nicht `n-a`) |
|--------|------------------------------|
| **Birkenbihl** | Wizard, lange Einstellungen, Erklär-/Hilfetexte, Empty States, Warnhinweise, mehrstufige Formulare |
| **User-Flow** | Neue oder geänderte Admin-/TN-Oberfläche, Menü/Tab-Reihenfolge, Onboarding, „wo klicke ich als Nächstes?“ |
| **Marketing/Sales** | `Version:` / Release-Thema, Changelog, positioning-relevante Strings, expliziter Release-/Launch-Kontext |

## Beirat nach Umsetzung — QA-Gate (vor Abschluss / vor User-`#Axxx working`)

**Pflicht:** Nach Deploy + Screenshot-Selbsttest und **bevor** die Nachricht mit **`✅ #Axxx gefixt und geprüft`** / Abschlussformat aus [wi-agent-workflow.mdc](wi-agent-workflow.mdc) geht, wenn **mindestens einer** zutrifft:

- Gleiche Trigger wie **risky_only** (oben), oder
- Staging-sichtbare Änderung (PHP/CSS/JS/Templates/Listen-UI laut Deliverable-Loop), oder
- Participant-Journey / wp-admin-Plugin-UI (siehe [wi-participant-journey.mdc](wi-participant-journey.mdc), [wi-agent-workflow.mdc](wi-agent-workflow.mdc))

**Ausnahme (kein QA-Gate-Block):** reine Doku/Rule-/lokale Skripte ohne Staging-Sichtbarkeit; reiner Lint ohne Logik; wie **Kein Trigger** oben.

**Hard-Stop:** **`✗` bei QA Team** → nicht abschließen: Fix → erneut Lint/Deploy/Screenshot/QA-Gate.

```
🧪 QA-Gate #Axxx (nach Umsetzung, vor Abschluss)
- QA Team (Regression, Edge Cases, Admin+TN wo relevant, Mobil-Screenshot wenn UI): ✓/⚠/✗ <1 Zeile>
- Gehirngerecht (Birkenbihl — flüssig erfassbar?): ✓/⚠/✗/n-a <1 Zeile>
- User-Flow (nächster Schritt, Reibung, Empty States): ✓/⚠/✗/n-a <1 Zeile>
- Marketing/Sales (Anforderung erfüllt; bei grün: jetzt veröffentlichen statt endlos polieren): ✓/⚠/✗/n-a <1 Zeile>
```

**Priorität:** Marketing/Sales darf **nicht** Security oder Participant-Journey überstimmen (siehe [wi-risk-veto.mdc](wi-risk-veto.mdc) / North-Star-Reihenfolge). Marketing **darf** bei technisch grünem Zustand Druck Richtung **Release/Veröffentlichung** ausüben — nicht zugunsten unsicherer Änderungen.

## Patron Saints — Kern-Fragen (je 1 Satz zur Erinnerung)

- **Linus Torvalds** — „We don't break userspace." → Bricht das Hooks/Options/Shortcodes/REST/Freemius? PHP 7.4 neben 2013er Code?
- **Bruce Schneier** — OWASP. → Nonce, Capability, Escape, Sanitize, Prepare. Angreifer denkt mit. Least Privilege?
- **John Carmack** — „Measure, don't guess." → Neue Query? Sync-Call im Render? N+1? Cache-Impact? 100/600 TN?
- **Russell Brunson + Neil Rackham** — Funnel & SPIN. → Conversion Registration→Attendance→Offer? SPIN statt „BUY NOW!"?
- **Jeff Bezos + Lufthansa** — Working-backwards + Touchpoint. → Was gewinnt der TN in 1 Satz? Welcher Touchpoint bricht?
- **DHH / Jason Fried** — Convention over configuration. → Findet Solopreneur die Einstellung in 5 Min ohne Handbuch?

**Situativ** (nur bei passendem Trigger, sonst `— n/a`):

- **Dale Carnegie** (bei User-facing Copy/Notice/Error/Mail) → Nutzen zuerst, kein Schuldton, Wertschätzung statt Jargon.
- **Kim / Mauborgne (ERRC-Grid)** (bei **neuem** Feature, nicht Bugfix) → Eliminate / Reduce / Raise / Create vs. WebinarJam/Demio.
- **Joanna Wiebe + Eugene Schwartz** (bei **jeder** User-Text-Änderung: LP, Mail, Admin-Notice, Empty-State, Button) → 5-Sek-Test, VoC, Awareness-Stufe (Unaware→Most-aware).
- **Vera F. Birkenbihl (gehirngerecht)** → Wird das in **einem** Durchgang verstanden? Fachchinesisch weg? Muster statt Pauken? Belohnung statt Schuldgefühle?
- **User-Flow / Top-Software-UX** → Ist der Happy Path in ≤3 Klicks klar? Passen Label, Ort und Erwartung? Mobile ohne Ratespiel?
- **Marketing/Sales (Requirements + Ship)** → Sind die **vereinbarten** Nutzen/Claims getroffen? Ist die Version **verkaufbar** dokumentiert? Wenn QA grün: **Ship** — kein Feature-Creep in der gleichen Task.

Volle Personas liegen in [.cursor/advisors/](.cursor/advisors/). Für Tiefen-Reviews (Diff/PR) siehe unten.

## Abstimmung + Default

- Alle `✓`/`n-a` → Option A ist der direkte Fix, B/C leichte Varianten.
- Mindestens ein `⚠` → Option A adressiert die Bedenken, B/C sind Ausweichpfade.
- **Mindestens ein `✗`** → **Hard-Stop**. Agent setzt NICHT um, wartet auf User-Entscheid (`#Axxx go A/B/C` oder `#Axxx override`).

**QA-Gate:** `✗` bei **QA Team** nach Umsetzung → kein Task-Abschluss; iterieren bis QA mindestens `⚠` mit dokumentiertem Restrisiko oder `✓`.

## Rückbau-Pfad

Jede Alternative liefert 1-Zeilen-Revert-Hinweis (`scp` Vorgänger-Datei / `git revert <hash>` / WP-Revision-ID).

## Tiefen-Review via Task-Tool (parallel)

Für ausführliche Reviews (vor Release, bei großen Diffs) startet der Agent **parallele `generalPurpose`-Subagents** mit je einer Advisor-Persona als Rollen-Prompt:

- User-Triggers im Chat:
  - `@linus review <file|diff>` · `@schneier audit <file>` · `@carmack profile <file>` · `@brunson funnel-check <feature>` · `@bezos journey-audit <touchpoint>` · `@dhh admin-test <admin-flow>`
  - Erweitert: `@qa sweep <url|flow>` → [qa-team.md](../advisors/qa-team.md) · `@birkenbihl clarity <copy>` → [birkenbihl.md](../advisors/birkenbihl.md) · `@uxflow check <screen>` → [uxflow.md](../advisors/uxflow.md) · `@marketing ship-check <release>` → [marketing-ship.md](../advisors/marketing-ship.md)
  - Oder allgemein: *„Lass Linus + Carmack + Schneier parallel auf @inc/foo.php schauen"*
- Agent lädt die Persona aus `.cursor/advisors/<name>.md` und hängt sie als System-Kontext an den `Task(subagent_type=generalPurpose)`-Aufruf.
- Mehrere Advisors in **einem Tool-Batch** = echte Parallelität.
- Ergebnis wird im Chat zusammengefasst: *„Linus sagt… / Carmack sagt… / Schneier sagt…"* → dann Votum-Block + 3 Alternativen wie oben.

## Overhead-Schutz

- Beirat nur bei Trigger. Trivial-Tasks: kein Block.
- Jede Stimme max. 1 Zeile im Chat-Block. **Pre-Umsetzung:** Kern-Beirat + situative Zeilen zusammen ca. **12–16 Zeilen**; bei Platznot: Birkenbihl/User-Flow/Marketing **bündeln** („Birkenbihl+UX: beide ✓ — …").
- **Post-Umsetzung:** QA-Gate **+4 Zeilen** (oder 1 gebündelte Zeile nur wenn User explizit „kurz“ verlangt — Default: vier Zeilen).
- Option A baut sofort bei Soft-Warn — kein Warte-Zyklus.
- Hard-Stop nur bei `✗` oder explizitem `#Axxx stop`.
- Agent darf Stimmen bündeln, wenn zwei identisch votieren („Dev-Senior + Security: beide ✓ — Nonce + Hook-Signatur ok").

## Cross-Referenzen

- North Star: [wi-north-star.mdc](wi-north-star.mdc)
- Compat / Security / Speed-Checkliste: [wi-compat-security-speed.mdc](wi-compat-security-speed.mdc)
- Agent-Workflow (Deploy / Screenshot-Loop / Abschluss): [wi-agent-workflow.mdc](wi-agent-workflow.mdc)
- Staging: [wi-staging-infra.mdc](wi-staging-infra.mdc)
- Freemius-Premium-QA: [cloudways-freemius-premium-qa.mdc](cloudways-freemius-premium-qa.mdc)
- Risk-Veto: [wi-risk-veto.mdc](wi-risk-veto.mdc)

---

<!-- source: .cursor/rules/wi-risk-veto.mdc -->

# Risk-Veto (Soft-Warn) — Kernworkflow

Baut auf **`wi-agent-workflow.mdc`** auf: Der Veto-Block gehört zu **Schritt 1 (Fix umsetzen)** und steht **vor** PHP-Lint (Schritt 2). Trigger-Definitionen: **`wi-participant-journey.mdc`**, **`wi-compat-security-speed.mdc`**.

## Wann der Veto greift

- **Trigger-Check vor Umsetzung:** Berührt der geplante Task mindestens einen Bereich aus **`wi-participant-journey.mdc`** oder **`wi-compat-security-speed.mdc`**? Wenn **ja** → **Veto-Block Pflicht** (siehe unten), bevor Code geschrieben oder bestehende Logik geändert wird.
- **Keine stille Annahme:** Ist der Risiko-Bereich uneindeutig, **einmal** kurz nachfragen (z. B. AskQuestion), statt zu raten.
- **Ausnahmen (kein Veto, 1-Weg erlaubt):** Reine Doku/README, Lint-Fixes **ohne** Logikänderung, String-Typos die **nicht** in live sichtbaren Participant-Flows landen, reine Screenshots/Assets ohne Codepfad-Änderung.

## Veto-Block-Format (Pflicht, vor dem Code / zu Beginn der Umsetzungsantwort)

```
🛑 Risk-Veto — #Axxx
Betroffen: [Participant-Journey | Security | Kompatibilitaet | Speed | Admin-UX]
Risiko (1 Satz): …

Option A (Default, sicher):  …  · Rollback: …
Option B (Mittelweg):        …  · Rollback: …
Option C (aggressiv/Benefit): …  · Rollback: …

Umsetzung jetzt: A. Umschwenken mit: „#Axxx go B" oder „#Axxx go C".
```

## Verhalten nach dem Block

- **Default:** Option **A** (sicherster Fix) umsetzen, dann wie gewohnt Deploy + Screenshot (`wi-deliverable-loop.mdc` / `wi-agent-workflow.mdc`).
- **Hard-Stop** (kein stilles A): Nur wenn **A** ebenfalls Risiken hätte, die **nur der User** tragen kann — dann stoppen und klären, statt A zu erzwingen.
- **Nach Deploy + Screenshot:** Optionen **B** und **C** im Abschnitt **„Noch zu prüfen“** / **„Für dich zum Check“** nochmals mit **Ein-Zeilen-Kommando** zum Umschwenken (`#Axxx go B` / `#Axxx go C`).

## Priorität bei Konflikt zwischen Zielen

**Participant-Journey** > **Security** > **Kompatibilität** > **Speed** > **Admin-UX**.

## Qualitätsregel für A/B/C

- **Verbot:** A, B und C dürfen nicht dasselbe unter anderem Namen beschreiben — sie müssen sich in **Scope, Risiko oder Rollback-Kosten** messbar unterscheiden.

---

<!-- source: .cursor/rules/wi-security-check-before-done.mdc -->

# WI — Security-Check vor Abschluss (Pflicht)

## Regel (hart, keine Ausnahme)

**Vor** jeder `✅ #Axxx gefixt und geprüft`-Nachricht — also **nach** Deploy + Screenshot aber **vor** dem Abschluss-Block — führt der Agent **automatisch** einen Security-Quick-Check durch. Kein "fertig" ohne diese Prüfung.

## Wann (Trigger)

Immer wenn der Task **mindestens einen** dieser Punkte berührt:

- Neuer oder geänderter **HTTP-Endpoint** (AJAX, REST, Node.js Route)
- **Socket.IO** Events oder Verbindungen
- Daten die vom **Browser/Client** kommen und verarbeitet werden
- **Datenbank-Queries** mit User-Input
- **Ausgabe** von User-kontrollierten Daten (HTML, JSON, JS)
- **Authentication / Authorization** Logik
- **File-Operationen** mit User-Input
- **Externe API-Calls** mit Secrets/Tokens

## Security-Beirat-Block (Pflicht-Format)

```
🔒 Security-Check #Axxx (Schneier — vor Abschluss)
- Input Validation: ✓/⚠/✗ <Sind alle Inputs sanitized/validiert? absint, sanitize_text_field, etc.>
- Output Escaping: ✓/⚠/✗ <esc_html, esc_attr, esc_url auf allen Ausgaben?>
- Auth/Authz: ✓/⚠/✗ <Capability-Check + Nonce wo nötig? Kein nopriv ohne Grund?>
- SQL Injection: ✓/⚠/✗ <$wpdb->prepare für alle dynamischen Queries?>
- CSRF: ✓/⚠/✗ <Nonces auf State-ändernden Actions?>
- Rate Limiting: ✓/⚠/✗ <Kann ein Angreifer den Endpoint fluten?>
- Info Disclosure: ✓/⚠/✗ <Gibt der Endpoint zu viel preis? Stack traces, DB-Schema, Keys?>
- Node/API Security: ✓/⚠/✗/n-a <API-Key, CORS, Token-Auth, Body-Limits?>
```

## Verhalten

- **Alle ✓:** Weiter zum Abschluss-Block.
- **⚠ vorhanden:** Im Abschluss-Block unter "Noch zu prüfen" dokumentieren, aber abschließen erlaubt.
- **✗ vorhanden:** **HARD-STOP** — Fix implementieren, erneut Deploy + Screenshot, dann nochmal Security-Check. Kein Abschluss mit ✗.

## Ausnahmen (kein Security-Check nötig)

- Reine CSS/Layout-Änderungen ohne Datenfluss
- Reine Textänderungen in statischen Strings (kein User-Input involviert)
- Reine Doku/README/Rule-Dateien
- Screenshot-/Asset-Dateien

## Cross-Ref

- Detaillierte Security-Checkliste: [wi-compat-security-speed.mdc](wi-compat-security-speed.mdc)
- Beirat-Workflow: [wi-protect-veto-alternatives.mdc](wi-protect-veto-alternatives.mdc)
- Agent-Workflow (Schritt 5): [wi-agent-workflow.mdc](wi-agent-workflow.mdc)

---

<!-- source: .cursor/rules/wi-plan-go-autonomous.mdc -->

# WI — Plan go-ready (Discovery + Vertrag)

## Default

- **Plan-Phase** = Ausführungsvertrag, nicht Skizze.
- Nach User-**`go`** (oder „autonom“, „alle Phasen“, „ohne Rückfragen“): **alle** Plan-Punkte + **Empfehlungen (bei go: ja)** ohne Architektur-Rückfragen — außer **Hard-Stop** (Veto **✗**, fehlende Secrets/SSH, `#Axxx override`).
- **Nicht raten** während der Umsetzung; vor `go` alles in den Plan schreiben.

**Trigger volle Discovery:** >~3 Schritte, >3 Dateien, Participant-Journey/Mail/AJAX/SQL, oder User verlangt Plan. **Trivial** (Typo, 1 CSS-Zeile): kurzer Plan ohne 12-Domänen-Tabelle — trotzdem Go-Ready in 5 Zeilen.

Cross-Ref: [`wi-agent-workflow.mdc`](wi-agent-workflow.mdc), [`wi-risk-veto.mdc`](wi-risk-veto.mdc), [`wi-staging-infra.mdc`](wi-staging-infra.mdc).

---

## Ablauf vor `go`

1. **Readonly Research** (Code, Rules, HC-Matrix). **Rule 0:** Discovery-Denken zuerst an Pro — `./scripts/wi-sub-go.sh --model opus --effort high --review-only` (oder `opusplan --plan`); Cursor nur Kurz-Pfade + Beweise, kein Explore-Marathon ohne Sub-Go.
2. **Discovery** — 12 Domänen (unten); irrelevant = `n/a` + 1 Zeile warum.
3. **Entscheidungstabelle** im Plan (30–80 Zeilen ok): je Zeile **A | B | C | ★ | Entscheidung | Quelle**.
4. **Hybrid AskQuestion:** **max. 1** Batch, nur **✗ offen** oder Chat vs Plan Widerspruch (typisch 3–8 Fragen).
5. **„Gutes Gefühl vor go“** — 1 Screen (Pflicht, max. ~25 Zeilen).
6. **Go-Ready: ja** — dann `CreatePlan` / Plan final (Abschnitt **Agent & Model** mit `💡 Model: … · Plan erstellt: YYYY-MM-DD` direkt unter H1; bei Plan-Übergabe im Chat dieselbe Zeile **nur Modellname**, ohne Tokens/Kosten); User sagt **`go`**.

---

## Entscheidungsarten

| Symbol | Bedeutung | User (~45 Min Review) |
|--------|-----------|------------------------|
| **★** | Agent-Empfehlung (Veto A, North Star, Legacy) | Stichprobe lesen |
| **⚠** | Trade-off, nicht offensichtlich | **Explizit** bestätigen |
| **✗** | Nur User (URL, Lizenz, Copy, Business, Legal) | Muss vor `go` geklärt sein |
| **🤖** | A/B/C quasi gleich (±10 % Risiko/Nutzen, gleicher Rollback) | Agent wählt + 1 Zeile Begründung — **nicht** in AskQuestion |

**Quasi-gleich:** Entscheidungsspalte `🤖 B` (Beispiel), nicht User mit 40 Vergleichen belasten.

---

## 12 Domänen (global, jede große Planung)

| # | Domäne | Default-★ wenn nicht anders |
|---|--------|------------------------------|
| 1 | North Star / Ziel | Pol A + B |
| 2 | Scope | Minimal diff, kein Creep |
| 3 | Touchpoints | Nur betroffene URLs/Flows |
| 4 | Architektur | [`wi-profi-plugin-principle.mdc`](wi-profi-plugin-principle.mdc) |
| 5 | Compat | Kein Shortcode-Break; `is_premium` true |
| 6 | Security | Nonce, Cap, prepare, escape |
| 7 | Speed / 600 TN | Kein neues N+1/Polling ohne Grund |
| 8 | UX / Copy | EN + Loco; Birkenbihl-kurz |
| 9 | CSS / Layout | [`wi-css-change-impact.mdc`](wi-css-change-impact.mdc) eng |
| 10 | Staging / QA | User-URL > HC-Matrix; SS-Pfade |
| 11 | Deploy / Release | Version bump + incremental; commit-scope |
| 12 | Rollback / Risiko | Veto Option A + Revert 1 Zeile |

Pro Domäne **≥1** Tabellenzeile (D01…) oder `n/a`.

---

## Pflicht-Abschnitte im Plan

1. **Agent & Model** — `💡 Model: <sichtbarer Modellname> · Plan erstellt: YYYY-MM-DD` (direkt unter H1; nur Modellname, **keine** Tokens/Kosten — Kosten nur in Cursor-Usage-UI)
2. Ziel (1 Satz, messbar TN/Host/Admin)
3. Scope — In / Out / Manuell-only
4. **Discovery-Tabelle** (D01…Dn)
5. **Gutes Gefühl vor go** (siehe unten)
6. **Empfehlungen (bei go umsetzen)** — ja + Datei/URL
7. Phasen **P0…Pn** — Dateien, Prüf-URLs, `.cursor-wi-screenshots/ss-….png`
8. Risk & QA — Veto, Security, Server-Load, CSS-Impact **konkret**
9. Rollback — pro Phase oder gesamt
10. Todos — aligned mit Phasen; optional `discovery-review` vor Execute

Vorlage: [`.cursor/plans/_TEMPLATE.go-ready.md`](../plans/_TEMPLATE.go-ready.md).

---

## „Gutes Gefühl vor go“ (Pflicht)

1. Ein Satz: Was ist nach `go` anders?
2. Top-3 Risiken + wie P/SS abdeckt
3. Bewusst **nicht** gemacht (Out of scope)
4. **Deine Klicks:** nur IDs mit **⚠** oder **✗** (z. B. D07, D19)
5. **Go-Ready:** ja / nein (BLOCKER: …)
6. Grobe Umsetzungszeit P0…Pn

Unüberzeugend → Plan nachschärfen, nicht `go` erzwingen.

---

## User-Review ~45 Min (Hybrid)

| Phase | Aktion |
|-------|--------|
| 0–5 min | „Gutes Gefühl“ lesen |
| 5–25 min | Tabelle: alle **✗** und **⚠** |
| 25–35 min | **★** Stichprobe (10–15 wichtigste Zeilen) |
| 35–40 min | AskQuestion nur wenn **✗ offen** |
| 40–45 min | Korrekturen → **Go-Ready: ja** → User `go` |

---

## Go-Ready-Checkliste (Agent)

- [ ] 12 Domänen: je Zeile oder `n/a`
- [ ] Kein **✗ offen**
- [ ] Prüf-URLs https vollständig; Evergreen vs Live / Webinar-ID
- [ ] Empfehlungen (go): ja + Pfade
- [ ] „Gutes Gefühl“-Block vorhanden
- [ ] **Agent & Model**-Zeile im Plan (nur Modellname + Datum)
- [ ] Veto: kein **✗** ohne dokumentiertes override

---

## Nach `go`

- Alle Phasen + Empfehlungen (ja); Deploy + Cache + Screenshot + QA-Gate wo Pflicht.
- Kein Scope erweitern ohne neuen Plan.
- Git erst **`working ✓`** ([`wi-commit-scope.mdc`](wi-commit-scope.mdc)).

## Während der Umsetzung — Plan-Pflege Pflicht

- Der Plan ist ein laufendes Arbeitsprotokoll, nicht nur ein Start-Dokument.
- Nach jedem abgeschlossenen, blockierten oder geänderten Plan-Punkt den Plan **oder** `plans/plan-status.yaml` aktualisieren: Status, Version, Host, Report/Screenshot-Pfad, offener Blocker.
- Kein Plan-Punkt gilt als erledigt, wenn er nur im Chat erwähnt wurde. Erledigt = im Plan/Status eingetragen **und** verifiziert.
- Wenn ein Plan-Punkt nur teilweise geprüft ist, als `partial` / `in_progress` markieren und konkret notieren, welcher Host/Flow/Report noch fehlt.

## Plan-Abschluss (alle Phasen + `working ✓`)

Wenn **alle** Plan-Phasen erledigt sind und Tobias **`working ✓`** bestätigt hat:

1. Git commit + push (allowlist) wie [`wi-commit-scope.mdc`](wi-commit-scope.mdc).
2. **Loco (Pflicht-Hinweis im Chat):** Abschlussnachricht enthält eine Zeile **`loco all`** — Tobias startet danach `./scripts/loco-all.sh` (Staging-Version = local, dann Batch + Pull `languages/`). Details: [`wi-loco-all.mdc`](wi-loco-all.mdc). Agent führt `loco all` **nicht** ohne explizites Chat-Kommando aus; nur notieren + ggf. Staging-Version kurz vergleichen.

## Nach User `working ✓` (Handoff)

Antwortformat: [`wi-agent-workflow.mdc`](wi-agent-workflow.mdc) — **Nächstes Todo (Plan)** + **Noch offen** (Pläne, Ideas, Backlog, letztes „Noch zu prüfen“).

---

<!-- source: .cursor/rules/wi-plan-status.yaml.mdc -->

# WI — Plan-Status (Single Source of Truth)

## Kanon

- **Status-Wahrheit:** [`plans/plan-status.yaml`](../../plans/plan-status.yaml) — **lokal only**, nie committen (`/plans/` in `.gitignore`).
- **Spezifikation:** `.cursor/plans/*.plan.md` — Aufgabenbeschreibung; **frontmatter `todos:` sind nicht Status-Wahrheit**.

## P-Nummern — globale Vergabe (Pflicht vor jedem neuen Plan)

**Vor dem Erstellen eines neuen Plans** (Pflicht, kein Überspringen):

1. `plans/plan-status.yaml` lesen
2. Höchste vorhandene `plan_nr` ermitteln (Feld `plan_nr: "Pn"` pro Eintrag)
3. Nächste Nummer nehmen: höchste + 1
4. Neuen Eintrag mit dieser `plan_nr` in `plan-status.yaml` anlegen

**Keine feste Zahl in dieser Rule pflegen.** Die aktuelle höchste P-Nummer muss immer live aus `plans/plan-status.yaml` ermittelt werden.

**NIEMALS:**
- Mit P0 oder P1 neu anfangen, wenn bereits höhere Nummern vergeben sind
- Eine `plan_nr` wiederverwenden
- `plan_nr` weglassen (jeder Plan bekommt eine)
- Einen Plan als "altversion blockiert" abschließen. Wenn ein Zielhost eine alte Version hat, ist der nächste Task immer Upload/Update + Retest oder ein klarer Credential-Blocker.

## Aufgaben-Nummerierung & Commit-Format

**Commit-Message-Format:**

```
[P{n}:{Planname}] #A{xxx} Beschreibung | #A{xxx} Beschreibung | #A{xxx} Beschreibung
```

**Beispiel:**

```
[P4:Perf-Fixes] #A237 Bot-Defense | #A238 Grid-Include | #A239 Mail-Async
```

**Regeln:**

- Jede Aufgabe bekommt ihre eigene `#Axxx`-Nummer — niemals mehrere Aufgaben unter einer ID
- `#Axxx` zählt global aufsteigend — nie wiederverwenden
- P-Nummer zählt global aufsteigend: P1, P2, P3, …
- Phase optional: P4a, P4b, P4c, …
- Planname: kurz, kein Leerzeichen, Bindestrich erlaubt
- Trenner zwischen Aufgaben: ` | `
- Kein Doppelpunkt nach `#Axxx`

## Definition of Done (hart)

`status: completed` **nur** wenn alle drei erfüllt:

1. Alle Code-Schritte abgeschlossen
2. Tobias **`working`** / **`#Axxx working`** bestätigt
3. Git **commit + push** zu Bitbucket erfolgreich

Sonst: `pending` | `partial` | `failed` — **nie raten**.

**NIEMALS:**

- `completed` setzen bevor Tobias `working` gesagt hat
- `completed` setzen ohne erfolgreichen Bitbucket-Push
- Status raten oder annehmen

## Session-Start (Pflicht)

1. `plans/plan-status.yaml` lesen
2. `git status --short` + `git log -3 --oneline` gegen `commit`/`tobias_working` in YAML prüfen
3. Abweichung → im Chat melden + Korrektur-Optionen (YAML anpassen oder Git nachziehen)
4. Höchste `plan_nr` notieren → nächste freie Nummer für eventuelle neue Pläne bereithalten

## Vor jeder Plan- oder Task-Umsetzung

1. Prüfen, ob alle Zielzugänge fuer Deploy/Upload/Smoke vorhanden sind.
2. Bei Staging-/Kundenseiten: nicht erst am Ende feststellen, dass Upload fehlt.
3. Wenn Zugang fehlt oder ungültig ist: sofort konkret melden (Host, User/Mechanismus, gescheiterter Schritt) und nicht mit unabschließbaren Tests weitermachen.
4. Alte Plugin-Versionen auf einem Zielhost sind kein QA-Ergebnis. Sie sind ein offener Upload-Schritt oder ein Credential-Blocker.

## Während jeder Plan-Umsetzung

1. Nach jedem Planpunkt `plans/plan-status.yaml` oder den laufenden Plan aktualisieren: `fertig`, `partial`, Version, Host, Report/Screenshot, Blocker.
2. Status nie nur im Chat halten. Wenn ein Punkt geprüft wurde, muss die Prüfung im Plan nachvollziehbar sein.
3. Teilprüfungen nicht grün markieren: fehlende Hosts/Flows/PCP/debug.log als offene Unterpunkte eintragen.
4. Wenn der Planinhalt von der Realität abweicht, Plan zuerst korrigieren, dann weiterarbeiten.

## Agent bei Task-Ende

- Nach **`working ✓`**: betroffenen Plan-Eintrag in `plan-status.yaml` aktualisieren (`commit`, `version`, `tobias_working`, `deployed`, `schritte`, `status`).
- Markdown-Plan-YAML **nicht** als Ersatz pflegen.

Cross-Ref: [`wi-agent-workflow.mdc`](wi-agent-workflow.mdc), [`wi-commit-scope.mdc`](wi-commit-scope.mdc).

