<!-- AUTO-GENERATED by scripts/wi-claude-rules-sync.sh — do not edit. -->
<!-- bundle: 00-tobias-core | sources: 6 .mdc files -->
<!-- source: .cursor/rules/00-wi-delegate-pro-first.mdc -->

# WI Rule 0 — Delegate Pro First (FIRST — vor North Star, vor allem anderen)

## Merkregel (hart)

> **Cursor delegiert und liefert Beweise.**  
> **Claude Pro plant, denkt, strukturiert und produziert Code und Tiefe.**  
> **Composer nur Hände, nicht Kopf.**

Cross-ref: [wi-sub-go-model-policy.mdc](wi-sub-go-model-policy.mdc) · [scripts/wi-sub-go.sh](../../scripts/wi-sub-go.sh) · [CLAUDE.md](../../CLAUDE.md)

## Pflicht — erste Reaktion auf jede User-Nachricht

**Bevor** Cursor tief analysiert (lange `read`/`grep`, Plan-Modus-Recherche, Explore-Subagent, Composer als Denker):

1. **Intent** in einem Satz (Idee / Frage / Plan / Code / nur Deploy-QA).
2. **Denkarbeit → sofort Claude Pro** via [`scripts/wi-sub-go.sh`](../../scripts/wi-sub-go.sh) (nicht Cursor API Fable/Opus im Picker):

| Intent | Erste Sub-Go-Aktion (Default) |
|--------|-------------------------------|
| Idee, Analyse, Architektur, „was/wie/warum“, komplex | `--model opus --effort high --review-only` |
| Plan, `go`, P0…Pn, go-ready Discovery | `--model opusplan --effort high --plan` (Review oder Umsetzung je Phase) |
| Ship-set Implementation | `--model auto` (sonnet → eskalieren) |
| Nur Deploy / QA / Screenshot (keine neue Logik) | Kein Sub-Go — Cursor Hände |

3. **Cursor danach:** Sub-Go-Output einordnen, Risk-Veto wenn nötig, **Beweise** (lint, deploy, cache, Smart QA, Screenshots, `WI_SUBGO_RESULT`).

## Verbot als Erstreaktion (Hard-Stop)

- Lange **nur-Cursor**-Recherche (viele Files, Explore-Subagent, Plan-Readonly-Marathon) **ohne** Sub-Go `opus` / `opusplan` für dieselbe Frage.
- **Composer / Auto** als Gehirn für WI-Logik, Legacy, Journey, Architektur, Plan-Inhalt.
- In **Plan-Modus** erst 12 Domänen in Cursor durchdenken statt Discovery an Pro zu delegieren.

Kurz lesen (1–3 Dateien, Pfad finden) für Sub-Go-Prompt ist ok — **nicht** Ersatz für Pro-Analyse.

## Ausnahmen (Cursor-only, kein `claude -p`)

- User-Prefix **`cursor-only:`**
- Sub-Go-Blocker (`claude` fehlt, Pro-Login, nach dokumentiertem Limit + Learnings)
- Reine Meta (Git-Status, Rule-Frage ohne Ship-Bezug) — trotzdem bei Komplexität Pro bevorzugen

## Output-first

Opus/Fable gegen Pro-Limit laufen ist ok. Kein Zurückrudern auf Cursor-API-Modelle für Tiefe.

---

<!-- source: .cursor/rules/wi-north-star.mdc -->

# WebinarIgnition — North Star (Minimal)

**Rule 0 (FIRST):** [00-wi-delegate-pro-first.mdc](00-wi-delegate-pro-first.mdc) — Cursor delegiert + Beweise; Claude Pro denkt/plant/code; Composer nur Hände. Vor Analyse/Plan: Sub-Go `opus` / `opusplan`, nicht Cursor-Marathon.

## Arbeits-Modus (vor allem anderen)

Jede Agent-Interaktion mit Tobias läuft in 4 Schritten, in dieser Reihenfolge:

1. **Zuhören** — Nachricht voll lesen, Kernfrage + Kontext erfassen. Bei echter Unklarheit: max. 1–2 kurze Rückfragen. Sonst direkt weiter.
2. **Beraten** — Expertise anwenden. Wenn Input gegen North Star / V5-Fokus / aktuelle Ideen läuft: klar benennen. Alternativen zeigen, aber knapp.
3. **Notieren** — Trennung zwischen „jetzt" und „später":
   - **Jetzt** → Heute-Top-3 oder direkt als `#Axxx`-Task.
   - **Gut, aber später** → `.cursor/wi-current-ideas.md` mit Datum.
4. **Umsetzen** — das **eine wichtigste** Ding für heute. Nicht 5 parallel. Fokus auf Done, nicht auf perfekt.

**Technik-Kurzpfad (bestes Coden + nichts kaputt):** Checkliste *vor / während / nach* dem Coden — [wi-development-guardrails.mdc](wi-development-guardrails.mdc), Abschnitt **Coding safety cheatsheet**.

Dieser 4-Schritt ersetzt für ~90 % der Tasks jeden größeren Beirats-/Pre-Filter-Zirkus. Der **aktive Beirat** (Linus, Schneier, Carmack, Brunson, Bezos, DHH + situativ Carnegie/Kim-Mauborgne/Wiebe-Schwartz) wird **automatisch** bei Rule-1-Triggern angehört — siehe [wi-protect-veto-alternatives.mdc](wi-protect-veto-alternatives.mdc) und [wi-compat-security-speed.mdc](wi-compat-security-speed.mdc). Für Tiefen-Reviews stehen die Patron-Saint-Personas in `.cursor/advisors/` bereit und können via `@linus`/`@bezos`/… oder Task-Tool parallel gerufen werden.

## WI-Energie-Prinzip (Tobias-Originalworte)

> Wenn der Teilnehmer sich wohlfühlt UND der Webinar-Host Umsatz macht und seine Ziele erreicht — **DAS** ist unsere Energie, die alles versorgt.

**Entscheidungsregel:**
- **Pol A (TN-Wohlfühlen):** Vertrauen · Mobile < 2 s · Trust-Signale · Freude · Einfachheit
- **Pol B (Host-Zielerreichung):** Conversion · Retention · Skalierung · Umsatz · Upgrade-Wahrscheinlichkeit
- Beide ✓ → grün · Eine ✗ → Hard-Stop (außer die andere gewinnt ungleich mehr)

## Arbeitsprinzip — Fragen statt annehmen

Vor Umsetzung aktiv prüfen: Last/Skalierung, Browser/Device, Freemius-Tier, Cache. Fehlt Info → **Tobias fragen** oder selbst per `grep`/`wp db`/Log prüfen. **Nicht raten.**

## Skalierungs-Zielgruppen

- **100 TN** Standard-Komfort.
- **600 TN** — Kunde Felix, Live-Webinar **19. Mai**. Hard-Gate.
- **1000+** — Wachstumsziel, Architektur darf nicht blockieren.
- Kein Change an Registration/Live-Room/Chat/Reminder/Replay ohne 600-TN-Plausibilisierung.

## V5-Fokus + MRR-Ziel (2026)

**Release-Thema:** V5 = Gutenberg-Integration + KI-Wizard + Detail-Verbesserungen.

**Release-Kadenz (hart):** min. 1 Release pro Monat. Aktueller Zustand (seit Dez 2025 nur Beta) = Anti-Pattern, aktiv überwinden. Warnschwelle: ab 20 Tagen ohne öffentlichen Release → kleines v4.8.x-Release priorisieren.

**Release-Sequenz (hart, nicht umkehrbar):**
1. Dev + lokal testen
2. Staging-Test (Cloudways) — siehe [wi-staging-infra.mdc](.cursor/rules/wi-staging-infra.mdc)
3. **End-Test-Matrix** (siehe unten, alle drei Abschnitte grün)
4. **Veröffentlichen** (wp.org / Bitbucket-Tag / Update-Check live)
5. Marketing / Launch-Arbeit (E-Mail an 10 000+ Liste, Changelog, Webinar-FAQ)

Marketing **niemals vor** Schritt 4. Ankündigung eines Features, das Kunden noch nicht updaten können, verbrennt Vertrauen.

**Geschäftsziel:** 100+ Plus-Lizenz-Kunden × $99/Mo ≈ $9 900 MRR, Deadline **Ende 2026**.

## End-Test-Matrix (vor jedem Release, alle drei grün)

**a) Marketer-Builder-Compat:**
- OptimizePress 3.x · Thrive Suite (Architect + Theme Builder + Leads) · Elementor + Pro · Divi 4.x/5.x · Beaver Builder (optional) · Block-Themes (Twenty Twenty-Five, Kadence, GeneratePress)

**b) User-Admin-Flow-Check** (Onboarding + Standard-Webinar in ≤ 5 Min, ohne Doku):
- Aktivierung → Setup-Wizard → 1. Webinar anlegen → Registration-LP → Reminder-Sequence → Testlauf mit 1 simuliertem TN

**c) Teilnehmer-Journey (Touchpoint-Audit):**
- Registration → Confirmation → Calendar-Reminder → Last-Minute-Reminder → Join-Link → Live-Room → Replay → Follow-up-Mail

Plus **Felix-600-TN-Gate** bei kritischen Pfaden (siehe Skalierungs-Zielgruppen).

## Produkt-Vision V5+ — Admin-KI statt Tobias-manuell

**Wandel:** weg von „Tobias setzt Webinare für Kunden auf" → hin zu „**Admin setzt Webinar technisch UND inhaltlich selbst auf**, via KI-Prompt in WI oder über MCP in seiner eigenen KI."

**Zwei Kanäle:** In-Plugin KI-Wizard (Premium) · MCP-Server für externe KI-Clients (Claude Desktop / ChatGPT / Perplexity / Gemini).

**WI liefert:** Prompt-Templates · MCP-Tool-Surface · KI-Agenten-Dokumentation. Prompts + Docs sind **Release-Artefakte**, nicht nur Code.

**Ziel-Zustand:** **von KIs empfohlen · von TN geliebt · von Hosts geliebt.**

## Aktuelle Ideen (lebender Kontext)

Regelwerk ohne abgefragte Ideen = Bürokratie. **Mit** abgefragten Ideen = lebendig.

- **Beim Startup:** Agent fragt „Welche aktuellen Ideen/Prioritäten heute? Stichworte genügen."
- **Wenn Tobias TODOs in einer Nachricht nennt:** Agent schreibt sie automatisch in `.cursor/wi-current-ideas.md` mit Datum/Zeit.
- **Vor Entscheidungen:** Agent liest `wi-current-ideas.md`. Bei Widerspruch Ideen ↔ Regel: **Ideen gewinnen** (außer Security/Compat-Hardlines, dann Rückfrage).

**Hierarchie:** `wi-impulses.md` (Chaos) → `wi-current-ideas.md` (destilliert, aktiv) → `wi-backlog.md` (Tasks mit `#Axxx`).

## Tages-Rhythmus (Kurz)

- **Pomodoro:** 45 Min Fokus + 10–15 Min Pause. Agent meldet bei ~40 Min Cut-Point-Vorschlag.
- **Shutdown (abends):** Dankbarkeits-Liste in `.cursor/wi-wins.md` · Top-3 morgen · Release-Check „Tage seit letztem Release?"
- **Startup (morgens):** Top-3 lesen · 2 Min Stille für Nacht-Impulse · Quick-Scan Support/Melanie · Heute-Fokus = 1 Haupt + max. 2 Neben.

## Hyperfokus-Delegation

Tobias im Hyperfokus → notiert in Chat/Backlog, Agent setzt um (Staging, Screenshot, Selbstprüfung gemäß [wi-agent-workflow.mdc](.cursor/rules/wi-agent-workflow.mdc)). Kritische Pfade (Registration-Submit, Live-Room, Reminder-Cron, AI-Keys, MCP-Whitelist) **nur mit expliziter Freigabe**. Bei Unsicherheit wartet der Agent, statt zu raten.

Gefühls-Anker nach Agent-Tasks: `🟢 #Axxx done — Pause ohne schlechtes Gewissen` oder `🟡 #Axxx wartet auf dich, kein Stress`.

## Eskalation zum vollen Beirats-Regelwerk

Bei Rule-1-Triggern ([wi-protect-veto-alternatives.mdc](wi-protect-veto-alternatives.mdc) — riskante Diffs, Registration-/Mail-/AJAX-/SQL-/Nonce-/Enqueue-/Freemius-Pfade, Hooks mit hoher Frequenz, Update-/Migration-Code) eskaliert Schritt 2 „Beraten" automatisch zum aktiven Beirat: Pre-Filter (Musk/Jobs/Krug), Musk 5-Step, 6 fixe + 3 situative Patron-Saint-Stimmen, 3 Alternativen A/B/C, Hard-Stop bei ✗. Für Journey-Tasks + AI-Stack siehe Phase-2- und Phase-3-Regeln (werden aktiviert, sobald gebraucht). Für Standard-Tasks bleibt der 4-Schritt-Modus.

---

<!-- source: .cursor/rules/wi-task-scope-choice.mdc -->

# WI — Task Scope Choice

For every non-trivial task, Tobias should be able to choose the scope before implementation. The scope choice is based on task risk, not on how many lines of code are likely to change.

## Automatic QA Mode

Choose the lightest mode that still protects the product:

- Sparmodus: questions, docs, tiny UI/copy changes, or code paths with no meaningful breakage risk. No deploy/screenshot/security ceremony unless the user asks.
- Standard-QA: normal code changes with limited blast radius. Read the relevant files, make the minimal fix, run focused checks, and summarize clearly.
- Full-QA: any change where a mistake can break Participant-Journey, Mail, AJAX/REST, SQL, auth/capabilities/nonces, payment/license, release, migration, cache/enqueue, or high-traffic live behavior. Use the full WI deploy/screenshot/security workflow.

If the task is small but high-risk, use Full-QA. Read-only or advisory work may skip deploy/code ceremony, but not careful discovery: if the analysis will drive later risky implementation decisions, use Standard-QA/Full-QA thinking, Beirat/risk voices, A/B/C options, and visual evidence where the user/admin UI matters.

## Visual Discovery

Screenshots are part of discovery when the task depends on what a participant, host, or admin actually sees. Local screenshot capture is cheap; broad image interpretation is the costly part. Therefore:

- Take or use screenshots when UI state, layout, wording, funnel trust, admin confusion, or visual regressions influence the decision.
- Do not run blind screenshot matrices for purely backend, cron, mail-queue, SQL, or release-admin tasks unless a visible surface is in scope.
- A screenshot only counts as evidence if it shows the exact target state or area that is being checked.
- For admin tasks, a wp-admin login screen is not evidence of the admin UI. Log in first; if login is blocked, report the blocker instead of claiming visual verification.
- If the target state is not visible yet, wait, scroll, open the right tab/accordion, use a better viewport, and take another screenshot.
- If the agent still cannot make the target visible, stop and ask Tobias for help with the screenshot/state: what was tried, what is visible, and what is missing.
- When Tobias provides screenshots, focus the analysis on the named area/question first instead of describing the whole image.
- If multiple screenshots are provided, compare only the relevant differences unless Tobias asks for a full visual audit.

Default flow before code:

1. Capture the relevant details and constraints first.
2. Ask the Beirat/Risk voices when the task is risky, architectural, or touches participant/admin journeys.
3. Ask concise clarifying questions only where the decision is genuinely Tobias's.
4. For larger-impact tasks, ask with the Cursor multiple-choice question UI, not only a prose block:
   - A: smallest safe fix / minimal diff
   - B: medium scope / consolidate the touched area
   - C: architectural unification / bring the system closer to WordPress standards where it is sensible
5. Add a short "Gutes Gefühl vor go" block: what changes, top risks, what is intentionally out of scope, and go-readiness.
6. **Admin/TN feature changes:** document **Grund + Wiederherstellung A/B/C** per [wi-no-silent-feature-removal.mdc](wi-no-silent-feature-removal.mdc); repeat open questions after `working ✓` until answered.
7. Implement only after the selected scope is clear, except for trivial one-line fixes.

If Tobias says `go` on a larger-impact task without choosing A/B/C, ask once via multiple choice before implementing. If Risk-Veto has a safe default A, still show the A/B/C choice when the task has meaningful impact.

Architecture preference:

When C is selected or clearly beneficial, prefer comprehensive architecture unification over isolated fixes, especially for URL builders, routing, participant surfaces, mail, Create/AI, and shared WP integration points. Use WordPress-standard APIs and existing WI canonical helpers where possible so future developers, Tobias, and the agent can continue from one coherent path.

---

<!-- source: .cursor/rules/wi-clickable-file-links.mdc -->

# WI — Clickable File Links And Access Blockers

- In chat and project notes, write local file references as clickable Markdown links whenever the user may need to open them.
- Prefer visible link text over code-only link styling, e.g. `[OPEN .env.wicom-staging.local](../../.env.wicom-staging.local)`.
- For access blockers, state the blocker prominently and directly: which host, which field/file is missing, and exactly what value the user must provide.
- Do not silently delete or migrate secrets from one local file to another. First create a local backup, then copy secrets to the new single source, verify the login/upload path, and only then clean the old note.

---

<!-- source: .cursor/rules/wi-links-for-options.mdc -->

# WI — Links For External Options

When suggesting external services, hosting providers, free trials, plugins, tools, or signup paths, always include the direct URL next to the option.

Default format:

- Name — direct link — why it matters / caveat

For hosting decisions, include:

- Signup/free-trial link
- Whether it is immediate or delayed
- Whether it supports WP plugin upload, FTP/SFTP, PHP/MySQL, SSL, and the target server type
- The recommended choice in one sentence

Do not make Tobias search manually for the signup page when a link is known.

---

<!-- source: .cursor/rules/wi-preserve-code-style.mdc -->

# Preserve code style (global)

Never modify formatting, never add extra whitespace, preserve existing code style.

When editing existing files:
- Change only lines required for the task (minimal diff).
- Do not reformat, reflow, indent-fix, or "clean up" unrelated code.
- Match existing indentation (tabs vs spaces), brace placement, and blank-line patterns.
- Do not add or remove trailing blank lines unless the fix truly requires it.

