# Understand Processflow Rules And Gimmicks

> Konsolidierte Regeln + Plattform-Gimmicks für die ProcessFlow-Prozessarbeit (neverlost) — Prozess-Triage/Duplikate/Kombinationen, Lösungskonzept-Stilregeln (kein Datenschutz!), Save-/Persistenz-Fallen, Phasen-Feld, In-App-KI-Macken. IMMER zusätzlich laden, wenn an ProcessFlow-Prozessen gearbeitet wird (neben processflow-review + processflow-app).

- Skill: `psquared-development/understand-processflow-rules-and-gimmicks` (Agent Skill)
- Install (CLI): `npx skillmds@latest add psquared-development/understand-processflow-rules-and-gimmicks`
- Raw SKILL.md: https://api.skillmd.com/api/skills/psquared-development/understand-processflow-rules-and-gimmicks/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: psquared-development (https://skillmd.com/u/psquared-development)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/psquared-development/understand-processflow-rules-and-gimmicks

---


# ProcessFlow — Regeln & Gimmicks (konsolidiert)

Wissens-Skill aus den realen Engagements (ZIWA → Stütz → Bettenrid). Ergänzt
`processflow-review` (Guardrails/Fehlermuster) und `processflow-app` (Driver) — ersetzt sie nicht.
Bei Widerspruch gilt: neueste User-Anweisung > dieser Skill > Default.

> **⚠️ AKTUELLE SCOPE-REGEL (Martin, 07/2026): Ab jetzt werden je Firma nur noch 5 Prozesse
> tief bearbeitet** (nicht mehr 10). Ältere „Top-10/max 10"-Angaben in `processflow-review`/
> `processflow-overview` sind damit überschrieben — Triage bleibt gleich, Cut liegt bei 5.
> Nicht bearbeitete, unauditierte KI-Entwürfe per Prio-Spinner HINTER die auditierten schieben.

## 1 · Standard-Ablauf neue Firma (verbindliche Reihenfolge)

**Phase A — Kickoff (Session-Start):**
1. Skills laden: diesen + `processflow-review` + `processflow-app`; Engagement-Memory lesen.
2. Helper-App starten (`python3 app.py`), Chrome-MCP verbinden, Token aus `localStorage`,
   Firma ingesten (**immer per `project_id` filtern**), Transkript(e) in die App laden.
3. Transkript VOLLSTÄNDIG lesen: Branche/Produkte exakt, echte Systeme/ERP, wer sagte was,
   Kundenprioritäten. ASR-Verhörer notieren (Namen im Zweifel gegen Canvas-Fotos prüfen).

**Phase B — Duplikat-/Redundanz-Pass über ALLE Prozesse (vor jeder Einzelarbeit):**
1. Alle Prozesse der Firma sichten (Liste + Scores + Kurzbeschreibung). Dabei wissen:
   **`source_image_url` gesetzt = echtes Workshop-Canvas** (Foto), **null = KI-synthetisiert**
   (ganzer Canvas ist eine Annahme → besonders duplikat-/halluzinationsverdächtig).
2. Jedem Prozess sein **Szenario aus dem Transkript** zuordnen — nicht dem Namen trauen
   (Bettenrid: „Kundendubletten – Falschbuchungen" = Buchhaltungs-OP-Abgleich, NICHT das
   CRM-Datenthema; mehrere E-Mail-/Termin-Entwürfe meinten denselben Prozess).
3. **Merge-Vorschlag als Artifact/Übersicht an den Menschen** (nichts still mergen):
   je Cluster ein **Hauptprozess** (der mit Canvas-Foto bzw. dem klarsten Transkript-Beleg)
   + Liste der Duplikate/Satelliten, die er absorbiert; **Namensvorschlag** für den
   Hauptprozess, wenn der KI-Name das Szenario schlecht trifft; Begründung je Entscheidung.
4. Nach menschlicher Freigabe umsetzen:
   - **Duplikate → Schalter „Nicht benötigt"** auf dem Lösungskonzept-Tab setzen (native
     Toggle neben „Berater-freigegeben"; DB-Spalte `processes.solution_concept_not_needed`
     — REST-lesbar zum Verifizieren). **Nicht löschen** — sie bleiben nachvollziehbar.
   - **Hauptprozesse umbenennen** (freigegebener Vorschlag): der Prozessname ist ein echtes
     Textfeld in den Canvas-Metadaten → direkt editierbar (kein Copilot nötig).
   - Merge-Entscheidungen in den Team-Feed + `list_notes` dokumentieren (was absorbiert wen).
5. **Top-5-Auswahl** (aktuelle Scope-Regel, s. o.): Analyse-Reihenfolge + Kundenprioritäten
   aus dem Transkript; Umstufungen mit ▲/▼ + Begründung; Prio-Spinner 1…5 setzen, Rest dahinter.

**Phase C — Einzelarbeit, 1 nach 1** (je Prozess §§2–8): Recherche → Kritik → Copilot-Rework →
Steps → Solutions → Diagramme → Phasen-Feld → live verifizieren. Artifact-Checkpoints zwischen
den Stufen: (a) Transkript-Analyse, (b) Lösungsplanung mit recherchierten Preisen — Mensch gibt
je Richtung frei, ERST DANN in ProcessFlow schreiben.

**Phase D — Abschluss:** Final-Sweep (§9) → Dominik-HTML 4+1 (§10). Freigaben setzt der Mensch.

**Schreib-Reihenfolge je Prozess:** Konzept-Text → Executive Summary (eigenes Feld, driftet!) →
Umsetzungsschritte → Solutions/Tools → Diagramme → Phasen-Feld → Guards. Nach JEDEM Schritt live
verifizieren (DB-Grep bzw. Screenshot), nie der Chat-Antwort glauben.

## 2 · Stilregeln Lösungskonzept + Executive Summary (Martin, verbindlich)

- **KEIN Datenschutz/DSGVO im Lösungskonzept oder der Executive Summary.** Keine
  „## Datenschutz"-Abschnitte, keine EU-Hosting-/AVV-/Drittland-Hinweise, keine
  Tool-Ausschlusslisten („ChatGPT ausgeschlossen", „laut Tool-Ausschlussliste"). Echte
  Rechts-Klärpunkte (z. B. Einwilligungslage) als normalen Analyse-Schritt in Phase 0 schreiben.
- **KEINE Canvas-/Foto-Referenzen** („lt. Canvas-Foto", „im Canvas nicht erfasst").
- **KEINE Schätz-/Verifikations-Hedges** („Schätzung — zu bestätigen", „vorab prüfen", „nicht
  bestätigt"). Klärpunkte gehören als Analyse-Schritt in die Phasen (z. B. „Lizenzlage prüfen" =
  Teil von Phase 0), nie als Disclaimer in die Ausgangslage.
- **KEINE Frequenz-/Zeitaufwand-Angaben in der Ausgangslage** (stehen im Canvas).
- **KEINE Meta-Disclaimer** („kein KI-Einsatz", „klassische Threshold-Logik").
- **Keine A/B-Varianten, wenn der Kunde entschieden hat** (Bettenrid P7: GF wollte Prognose →
  nur die OS-Lösung, Power BI komplett raus — nicht als „Einstieg" behalten).
- **Kein Tool-Hardcoding bei Single-Source-Recherche:** Findet die Recherche nur EINEN Anbieter
  und Preis/Integration sind offen → **Evaluation-first**: Phase 0 bewertet den Markt-Kandidaten
  („z. B. adelo") + weitere Anbieter + IMMER eine `<firma>-OS`-Eigenbau-Variante (besonders wenn
  der Kunde „wenige Systeme" wünscht). Entscheidungskriterien ins Konzept; Diagramm-Knoten
  neutral („Terminierungslösung, Auswahl in Phase 0"); Schritte „Gewählte Lösung konfigurieren".
- **Eine gemeinsame OS-Solution `<firma>-OS`** für ALLE OS-Prozesse verknüpfen — nicht pro Modul
  eine eigene („die Software wird das OS"). Tool-Empfehlung heißt dann auch nur so.
- **Entweder-Oder nie doppelt verknüpfen:** nur die Erstempfehlung als Solution; Alternativen und
  Fallbacks bleiben im Text (sonst summieren sich Kosten: Omnifact+Langdock = 45 €/M-Fehler).
- **Echte Systemnamen** überall (Navision, nicht „Warenwirtschaftssystem (ERP)") — sobald der
  Name belegt ist (Canvas-Foto schlägt Transkript-Wortlaut; ASR verhört Namen: Vision→Navision,
  Petra Tagessa→Pedram Taghizadeh, Samuel Thomas→Thomas Sengl).
- Kundenseitiger, selbstbewusster Ton; Struktur/Hausstil von guten Prozessen spiegeln
  (`## Ausgangslage` → Phasen → `### Empfehlung`); Rollen statt Personen-Initialen.

## 3 · Das Phasen-Feld (UMSETZUNGSSCHRITTE / „~Xh Umsetzung")

- Die Kopfzeile „~Xh Umsetzung" und der sichtbare „UMSETZUNGSSCHRITTE (Σ Xh)"-Block lesen aus
  **`report.phases`** — NICHT aus `report.next_steps` (das schreibt der Konzept-Copilot). Beide
  driften auseinander → **immer synchron halten: phases-Summe = estimated_hours = next_steps**.
- **Der Copilot KANN `phases` nicht schreiben** (sagt er selbst). **Zuverlässiger nativer Weg:**
  Zeilen im UMSETZUNGSSCHRITTE-Editor per MCP befüllen (textarea/input value-setter reicht für
  den State) → dann den **„Speichern"-Button oben im Lösungskonzept-Editor klicken** — der
  committet auch die Phasen. Auto-Save allein feuert NICHT auf automatisierte Eingaben.
- Editor-Bedienung: „Schritt hinzufügen" für neue Zeilen; Löschen = **`lucide-x`-Icon** je Zeile
  (kein Trash-Icon); Phasen-Überschriften = Zeilen mit 0h. Vorher zählen, wie viele Alt-Zeilen
  existieren — sonst stapeln sich neue auf alte (22 Zeilen/98h-Falle).
- **„Schritte vorschlagen" zieht aus `implementation_custom`** — nicht aus `next_steps` oder der
  Tool-Variante. Bei „kein Entwicklungsprojekt empfohlen" (Tool-Fälle) kommt genau eine 0h-Zeile
  → Button ist dort nutzlos; Schritte manuell aus den next_steps übertragen (Bettenrid P4).

## 4 · Save-/Persistenz-Gimmicks (die teuersten Fallen)

- **„Neu generieren" NIEMALS klicken** — überschreibt sämtliche Audit-Fixes im Konzept.
- **Nach jedem Copilot-Lauf: Seite neu laden + DB gegenprüfen** (Vorher/Nachher-Grep). Der
  Copilot behauptet manchmal Erledigung ohne Tool-Call; Läufe hängen (>2 min = vermutlich nicht
  gespeichert); React-State zeigt Werte, die nie persistiert wurden.
- **`update_report` verlinkt manchmal automatisch externe Komponenten als Solutions**
  („+N externe Bausteine verlinkt") → nach jedem Report-Update die Solution-Links gegenprüfen
  und Fremdes entfernen (so kam Easy Contract an den Kundenservice-Prozess). Verursachung über
  `process_solutions.created_at` klären.
- **Solution-Klassen-Dialog („Individuelle Software"/„Workflow") schreibt `type` unzuverlässig** —
  beim Speichern landete schon „tool". Die DB kennt im `solutions.type`-Enum **nur
  `tool` | `custom_workflow`**; OS/Individual-Web-Apps = `custom_workflow` (UI-Badge zeigt dafür
  je nach Ansicht „Individuelle Software" — das Badge zählt, nicht die Roh-Spalte). Der Copilot
  **halluziniert Felder** (`kind`, `is_individual_software`) — nie glauben, per REST
  `?select=type` prüfen.
- **Bestand/Neu-Toggles** (Radix-Switches): nach Klick unzuverlässig auslesen → erst nach Reload
  als gesichert werten; Klicks brauchen die volle Pointer-Event-Sequenz.
- **Copilot schreibt manchmal wörtliche `\n`-Escapes** in Textfelder (v. a. `external_components`)
  — im UI erscheint dann sichtbarer „\n-"-Text statt Zeilenumbrüchen. Nach Feld-Rewrites das Feld
  auf die zwei Zeichen Backslash+n greppen; Fix per Mikro-Prompt („ersetze jedes wörtliche \n- durch
  echten Zeilenumbruch") oder Feld komplett mit sauberer Liste neu diktieren.
- **Nicht-Copilot-Felder:** `gdpr_compliance` (E), `process_scores.rationales` und `phases` kann
  der Copilot nicht schreiben — Stale-Referenzen (winkk/n8n/Mistral/alte Varianten) überleben
  dort. Vor Präsentation PDF-Export ziehen und prüfen, ob diese Felder ausgegeben werden.
- **Token ~1 h:** leere REST-Antworten/`PGRST303`/`KeyError: 0` = Token abgelaufen → frisches
  Token aus Chrome-`localStorage` ziehen, NICHT die Daten anzweifeln. Lokale Helper-App-JSON ist
  ein Snapshot — Zahlen fürs Deliverable immer live nachlesen.
- **Direkte REST-Writes nur mit ausdrücklichem User-OK je Fall** (Leitplanke: In-App-KI + native
  Controls). Ausnahme-Präzedenz: `phases` bevor der Speichern-Button-Weg bekannt war.

## 5 · In-App-KI (Konzept-Copilot) richtig bedienen

- **Work-Modus** (nicht Ask). Canvas-Änderungen erzeugen Vorschläge → „Übernehmen" nötig.
  **Achtung: Der Modus resettet nach Browser-/Chrome-Neustart auf Ask** — vor jedem Prompt auf
  der Seite prüfen, sonst antwortet er nur beschreibend („Sobald Sie auf Work umschalten…").
- **Mikro-Prompts statt Sammel-Prompts:** große verkettete Aufträge enden in
  Endlos-Denkschleifen (>2 min „Reasoning…") — eine gezielte Änderung pro Nachricht; bei Hänger
  Seite neu laden und erneut senden. Für gezielte Textkorrekturen **exakte Ersetzungen** angeben
  („Ersetze X durch Y"), nicht beschreiben.
- **Formatierungserhaltend arbeiten** („kein Voll-Neuschrieb") — außer ein Feld soll bewusst neu.
- Die **Executive Summary ist ein eigenes Feld** und wird bei Konzept-Updates NICHT mitgezogen —
  immer separat prüfen/nachziehen. **Ein Voll-Rework via Copilot lässt sie sogar LEER zurück**
  (Bettenrid P1/P2: `concrete_approach` neu, `executive_summary` = leer, fiel erst im Review auf)
  → nach jedem Rework auf Nicht-Leere prüfen.
- **`update_report`-Schreibfelder** (vom Copilot selbst offengelegt — was fehlt, geht nur nativ
  oder gar nicht): `ai_content_score`, `ai_percentage`, `ai_solution_categories`,
  `ai_technologies`, `concrete_approach`, `estimated_hours`, `executive_summary`,
  `external_components(_structured)`, `implementation_custom/_recommendation/_tool_based`,
  `known_solutions`, `next_steps`, `pain_point_categories`, `quick_win_or_project`,
  `score_reasoning`, `solution_level(_reasoning)`, `tool_recommendations`.
- **Die Copilot-Solution-Suche findet Bestandseinträge oft nicht** („Solutions gesucht ·
  0 gefunden" trotz existierendem Katalogeintrag) → er legt dann Duplikate an oder behauptet
  fälschlich, ein Eintrag „war diesem Prozess nicht zugeordnet". Für BESTEHENDE Einträge immer
  den nativen „Manuell zuordnen"-Picker nutzen; den Copilot nur zum Entfernen von Zuordnungen
  und zum Anlegen projekteigener Solutions (OS-Module) einsetzen.

## 6 · Solutions-Landkarte & Katalog

- **Bestand/Neu hängt am LINK, nicht am Eintrag:** `process_solutions.is_existing_system` ist
  pro Prozess-Zuordnung — derselbe Katalogeintrag kann auf Prozess A Bestand und auf B Neu sein.
- **„Solution bearbeiten" am Prozess editiert den KATALOGEINTRAG** — ein Rename propagiert auf
  ALLE Links. Als Massen-Fix nutzbar („ERP-System (nicht näher spezifiziert)"→„Navision" fixte
  25 Links auf einmal), aber gefährlich bei geteilten Einträgen: vorher zählen, ob Links
  außerhalb des Projekts existieren.
- **Katalogeinträge sind org-scope** und tauchen in den Pickern ALLER Kundenprojekte auf →
  kundenspezifische Systeme eindeutig benennen; im Prozess-Picker nie „…als Tool anlegen"
  klicken, wenn der Eintrag existieren könnte (so entstehen die Landkarten-Duplikate).
- **Massen-Hygiene nativ:** Projekt-Einstellungen → Tools: „**Tausch**" ersetzt ein Tool in
  allen N Prozessen des Projekts (Bestand-Marks + Notizen bleiben erhalten; der Ziel-Eintrag
  muss existieren — der Dialog kann keinen anlegen) · „**Duplikate zusammenführen (KI)**" für
  Namens-Dubletten (z. B. „Microsoft Outlook" vs. „… / Exchange Online").
- **Die Erstanalyse sprüht Default-Tools über zig Prozesse** (Bettenrid: winkk.ai×40,
  Mistral×50, Easy Contract×28 von 68) → Landkarten-Hygiene fest einplanen; die „N Prozesse"-
  Spalte der Tools-Seite ist der Indikator. Konzept-Fixes ziehen die Links NICHT nach — nach
  jeder Konzeptänderung „Zugeordnete Solutions" gegenprüfen (Konzept↔Links driften).

## 7 · Reihenfolge, Rollen & Freigaben

- **`processes.manual_priority` ist DIE Analyse-Reihenfolge** — die maßgebliche Ansicht für
  alle Beteiligten („Prio-Ansicht stimmt") und der Nummernkreis in Handovers/Deliverables.
- **Spinner setzen (funktionierender Weg, 07/2026):** Auf der **Projekt-Prozessliste** hat jede
  Zeile ein spinbutton „Manuelle Priorität". Mit passender Rolle (Org-/Projektzugriff)
  persistiert **MCP `fill` auf die spinbutton-uid + anschließend `Tab`** (echte/trusted
  CDP-Events). **JS-value-setter und synthetische Events speichern NICHT** (UI zeigt den neuen
  Wert, DB behält den alten — immer per REST `?select=manual_priority` gegenprüfen). Berater-
  Login ohne Zugriff → mit exakten Ziel-Nummern delegieren.
- **Nach der Auditrunde die Prio-Ansicht herstellen:** auditierte Prozesse auf 1…N, verdrängte
  unauditierte Entwürfe auf N+1/N+2 — sonst zeigt die „richtige" Ansicht falsche Einträge.
- **Nie eigene Nummernkreise erfinden:** Artifacts/Handovers referenzieren `manual_priority`;
  Alt-Nummern höchstens als Alias daneben (Bettenrid-Lektion: Artifact-P# vs. Prio-Feld =
  zwei Wahrheiten, Verwirrung im Team).
- **„Berater-freigegeben"-Schalter = `processes.solution_concept_reviewed_at/_by`** — REST-lesbar
  für Status-Boards; das „Berater-OK"-Badge in Listen liest daraus.
- **Mehrere Akteure am selben Projekt:** vor jedem Arbeits-/Re-Audit-Lauf Live-Delta ziehen
  (`solutions?updated_at=gte.<datum>`, `process_solutions`-Links, Report-Marker-Grep) statt dem
  lokalen Helper-Snapshot zu trauen. Fremde Edits dokumentieren und abstimmen — nie still
  zurückdrehen (vielleicht weiß die andere Person etwas Neues).

## 8 · Diagramme

- Je Prozess **End-to-End-Ablauf + Architektur** (Dominiks G1); Ausnahme triviale Ein-Tool-Fälle.
- **Kurze Labels mit explizitem `<br/>`-Umbruch** (2–3 Zeilen à ~25 Zeichen) — der Renderer
  schneidet lange einzeilige Labels an der Boxbreite ab. Dem Copilot den **Mermaid-Code EXAKT
  vorgeben** („unverändert übernehmen"), sonst baut er lange Labels/Subgraphen/Personennamen.
- `flowchart TD`, ≤ ~10 Nodes Architektur, keine Subgraphen im Ablauf, echte Systemnamen,
  Captions kundenseitig (nie „rosa/:::custom/C4/Layer/Mermaid").
- **Nach jedem Diagramm-Update visuell per Screenshot verifizieren** (Diagramme-Subtab) —
  Quelltext sauber ≠ Rendering sauber. Farb-Logik: magenta=Individualsoftware, grün=neues Tool,
  schwarz=Bestand, grau=Akteur.
- **Auch Kanten-Labels werden abgeschnitten** — kurz halten („Golden Records", nicht
  „Bereinigte Datensätze · Golden Records · …").
- **Screenshot-Timeout-Fallback:** Wenn `take_screenshot` in `Page.captureScreenshot timed out`
  läuft, das Rendering per DOM messen (SVG-Textknoten suchen, `getBoundingClientRect` von Text
  vs. Box vergleichen) — nicht blind weitermachen.
- **Browser-Lock:** „The browser is already running for …chrome-profile" = eine ANDERE Session
  (Kollege/zweites Terminal) hält den MCP-Chrome → User bitten freizugeben; kein --isolated
  starten (eigene Session hätte keinen Login).

## 9 · Final-Sweep vor der Übergabe (Checkliste, alle live aus der DB)

Vor „fertig" EINEN Batch-Sweep über alle bearbeiteten Prozesse fahren — nie einzeln abhaken:
1. **Freigaben:** `solution_concept_reviewed_at/_by` gesetzt (durch Mensch!).
2. **Stunden-Dreiklang:** phases-Summe = `estimated_hours` = next_steps-Summe.
3. **Executive Summary** vorhanden (> ~100 Zeichen) — Voll-Reworks lassen sie leer.
4. **Stil-Grep über ALLE Textfelder**, nicht nur die zuletzt editierten: `concrete_approach`,
   `executive_summary`, `external_components`, `solution_level_reasoning`,
   `tool_recommendations`, `known_solutions`, `implementation_recommendation`. Verbotsliste:
   „## Datenschutz"/„### Datenschutz", „Canvas-Foto"/„lt. Canvas", „Schätzung —",
   „zu bestätigen", „nicht bestätigt", „zu verifizieren", wörtliches Backslash-n.
   **Altlasten verstecken sich in Konzept-KÖRPERN früherer Bearbeiter** — Sweeps, die nur
   ExecSums prüfen, übersehen sie.
5. **Diagramme:** je 2 (Ablauf+Architektur), Rendering visuell geprüft.
6. **Solution-Links = Konzeptstand** (Auto-Link-Falle!), Bestand-Flags korrekt,
   Entweder-Oder nur einfach verknüpft, gemeinsame `<firma>-OS`-Solution überall.
7. **Prio-Ansicht 1…N = auditierte Menge** (Spinner, s. §7).
8. **Fremd-Flags klären:** Meldungen der Kollegen-KI ernst nehmen, Verursachung über
   `created_at`-Zeitstempel belegen (nicht raten, wer's war), Antwort in den Team-Feed.

## 10 · Ideal-Endergebnis: das Dominik-HTML (4+1) — Standard-Abschluss

Das Abschluss-Deliverable, das sich bewährt hat („kam extrem gut an"): **eine einzige
selbstständige HTML-Datei** (inline CSS, Systemfonts, keine externen Abhängigkeiten, hell,
via Slack teilbar — KEIN claude.ai-Artifact), Ablage im Firmenordner. Inhalt in dieser
Reihenfolge:
1. **Kopf:** Review abgeschlossen, N Prozesse auditiert + freigegeben, Hinweis „die
   Prio-Ansicht in ProcessFlow ist die maßgebliche Sicht", Stand-Datum.
2. **Empfehlung in einem Satz** (Box).
3. **Die Top-4 als Karten in Präsentations-Dramaturgie:** 2 Quick Wins zuerst (Vertrauen,
   kleine Stundenzahlen), dann die strategischen `<firma>-OS`-Module als EINE Plattform-Story.
   Je Karte: Chip (Quick Win/Strategisch + Stunden), Abteilung, Lösung, **1–2 wörtliche
   Transkript-Zitate** (stärkstes Element!), 2–3 Sätze warum.
4. **„+1"-Ausblick:** der explizite Wunsch des Entscheiders (GF-Prio-1) als fünfte Folie, die
   die OS-Story zu Ende erzählt und beim Entscheider endet — inkl. dokumentierter
   Tausch-Option, falls Dominik die andere Dramaturgie will. (4-to-present-Gate beachten:
   2+2-Balance, verschiedene Abteilungen, jede Top-Kundenpriorität abgedeckt oder begründet,
   max. 1 Eigenprodukt.)
5. **Präsentations-Tipps:** mit Kunden-Zitaten eröffnen; OS als eine Geschichte; Quick-Win-
   Stunden zuerst nennen; Termin-Anker nutzen (z. B. Jubiläum); KEINE „auf Anfrage"-Preise
   improvisieren; offene Technik-Fragen souverän auf den Klärungstermin verweisen;
   Impact-Bewertung an den Kunden zurückspielen (5. Säule).
6. **Tabelle aller auditierten Prozesse in Prio-Reihenfolge** mit ProcessFlow-Deeplinks
   (`…/process/<id>/wizard?tab=feasibility`), Stunden, Typ-Chips; Gesamtsumme; Hinweis auf
   verschobene unauditierte Entwürfe.
7. **Fragen für den nächsten Kundentermin** (ERP-Version/API, Lizenzstatus, Schnittstellen,
   offene Namen).
8. **Fußzeile:** Basis (Transkripte, Canvas-Fotos, Tool-Recherche mit Datum), „HI-Freigabe &
   Präsentationstermin bei Dominik".
Vor dem Verschicken die Datei im Browser öffnen und per Screenshot prüfen.

## 11 · Nie (hart)

- **HI-/Berater-Freigabe setzen** → immer der Mensch. **Präsentationstermin nennen** → Dominik.
- Kundendaten (`data/`) committen. „Neu generieren" klicken. Der Chat-Antwort des Copilots ohne
  DB-Check glauben. Bei Ein-Anbieter-Recherche das Tool hart verdrahten.

## Verweise

Guardrails/Fehlermuster-Register: `processflow-review` · Driver/Chrome-MCP: `processflow-app` ·
Workflow: `processflow-overview` → `processflow-run <prozess>`. Kanonischer Standard: Dominiks SOP.