<!-- AUTO-GENERATED by scripts/wi-claude-rules-sync.sh — do not edit. -->
<!-- bundle: 50-plan | sources: 2 .mdc files -->
---
name: plan
description: WI go-ready plan and plan-status workflow only
---

<!-- 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).

