Capstone‑Integration: technisches‑produktseitiges Demo und der „App‑Pass“

1. Was ist der „App‑Pass“ und wozu brauchen Sie ihn

Der App‑Pass ist ein kompaktes, aber gehaltvolles Dokument (typisch 1–2 Seiten Markdown oder ein Abschnitt in der README), das jeder Person schnell ein Bild von Ihrer ChatGPT App gibt: wie sie aufgebaut ist, welche Einschränkungen sie hat, wie sie Geld verdient und wie Sie sie im Produktionseinsatz betreiben.

Das ist keine Marketingbroschüre. Es geht nicht um „die innovativsten KI‑Technologien“, sondern um sehr bodenständige Dinge:

• wo die Grenze zwischen ChatGPT, Ihrem Widget, dem MCP‑Server, den Agents und ACP/Stripe verläuft;
• welche PII Sie speichern, wie OAuth/Scopes und die Secret‑Rotation organisiert sind;
• welche SLOs zu Latenz und Verfügbarkeit Sie haben, welche Dashboards und Alerts existieren;
• wie viel ein erfolgreicher Ablauf im Schnitt kostet und wie Sie dafür Geld verlangen;
• welche typischen Incidents bereits beschrieben sind und wo die Runbooks liegen;
• was Sie mit dieser App in den nächsten Monaten vorhaben.

Sie können den Pass als Aggregator von Links und High‑Level‑Beschreibungen betrachten, der seltener als der Code, aber häufiger als die „offizielle Investorenpräsentation“ geändert wird.

Für Sie als Entwickler einer ChatGPT App ist der Pass zudem eine Reife‑Checkliste. Wenn ein Abschnitt leer ist („und SLOs haben wir irgendwie nicht beschrieben…“), ist das ein gutes rotes Flag: Es fehlt nicht nur an Dokumentation, sondern auch an der Praxis selbst.

2. Grundstruktur des App‑Passes für GiftGenius

Für GiftGenius bietet sich folgende Struktur an (Sie können sie leicht für Ihre App anpassen, die Grundidee bleibt).

Stellen wir in einer kleinen Tabelle dar, wer was liest und warum:

Im Folgenden gehen wir jeden dieser Blöcke durch und skizzieren parallel einen echten PASSPORT.md für GiftGenius.

3. Architektur: den gesamten Stack auf einem Bild zeigen

Der Architekturteil ist das Herzstück des Passes. Sie müssen keine UML‑Diagramme mit 200 Rechtecken malen. Wichtig sind Schichten und Flüsse: vom Nutzer in ChatGPT bis zu Ihrer Datenbank und dem Payment. Für eine ChatGPT App mit Apps SDK und MCP ist dieser Pfad standardisiert.

Ein praktisches Format ist ein Mermaid‑Diagramm direkt in PASSPORT.md. Zum Beispiel für GiftGenius:

flowchart TD
  U[User in ChatGPT] --> C[ChatGPT + GPT-5]
  C --> W[GiftGenius Widget
Next.js + Apps SDK]
  W --> MCP[MCP Server
giftgenius-mcp]
  MCP --> A[Agent: GiftPlanner]
  A --> DB[(Postgres: products,gifts)]
  A --> ACP[ACP / Stripe]
  ACP --> ORD[(Orders)]

Im Text unter der Grafik beschreiben Sie das Schlüsselszenario:

Der Nutzer beschreibt im Chat die zu beschenkende Person. Das Modell entscheidet, das Tool suggest_gifts auf dem MCP‑Server aufzurufen. Der Agent kann zusätzlich Kataloge als Ressourcen lesen und mehrere Tools ausführen. Anschließend wird bei der Geschenk‑Auswahl eine ACP‑Session in Stripe erstellt, der Checkout läuft über Webhooks, und das Ergebnis wird in der Datenbank gespeichert.

Gut ist es, wenn Sie Technologien direkt erwähnen: Next.js 16 + Apps SDK, MCP‑Server auf Node/Python, PostgreSQL, Redis als Cache, Stripe als Zahlungsanbieter.

Sie können dem Architekturteil einen kleinen technischen Ausschnitt hinzufügen, damit sichtbar wird, wie sich die Architekturbausteine im Code niederschlagen. Zum Beispiel ein Stück eines Next.js‑Routes, das requestId und userId an den MCP‑Client durchreicht:

// app/api/suggest-gifts/route.ts
import { mcpClient } from "@/lib/mcpClient";

export async function POST(req: Request) {
  const { occasion, budget } = await req.json();
  const requestId = crypto.randomUUID();      // Trace für Logs
  const userId = req.headers.get("x-user-id") ?? "anonymous";

  const result = await mcpClient.callTool("suggest_gifts", {
    occasion, budget, requestId, userId,
  });

  return Response.json({ requestId, result });
}

Ein solcher Ausschnitt hilft, den abstrakten Pfeil im Diagramm „Widget → MCP“ mit realem Code zu verknüpfen.

4. Security & Privacy: was genau festzuhalten ist

Sicherheit im Pass bedeutet nicht „wir nutzen HTTPS und ein TypeScript‑Backend, also ist alles gut“. Gefragt sind konkrete Antworten für Security, Compliance und Rechtsabteilung.

Für GiftGenius sollten Sie kurz beschreiben:

Welches Authentifizierungs‑ und Autorisierungsmodell:
Für Commerce‑Szenarien wird OAuth 2.1 mit PKCE über den MCP Auth Server verwendet; das Token ist an user_id und tenant_id gebunden, alle Tool‑Aufrufe im Zusammenhang mit dem Checkout benötigen den Scope commerce.checkout.

Welche Daten PII sind und wie Sie damit umgehen.
Zum Beispiel: E‑Mail und Name sind PII, Geschenkpräferenzen sind pseudo‑anonymisierte Daten; wir loggen nur gehashte E‑Mails, die Lieferadresse speichern wir nicht, sondern geben sie nur an Stripe und die Webhooks weiter.

Wie Retention und Löschung organisiert sind:
Tool‑Logs bewahren wir 30 Tage auf, Commerce‑Events — 1 Jahr; auf Nutzeranfrage können wir Bestellungen und zugehörige Analytics‑Events löschen.

Wie Sie Secrets verwalten:
Beschreiben Sie kurz, wo OpenAI API Key, Stripe Secret, OAuth Client Secret liegen (z. B. in einem Managed Secret Store), wie oft sie rotiert werden und wie dies im Staging getestet wird.

Im Pass können Sie einen kleinen techniknahen Ausschnitt geben, um das Prinzip der „minimal notwendigen Rechte“ zu demonstrieren.

// config/scopes.ts
export const TOOL_SCOPES = {
  suggest_gifts: ["read:products"],
  get_gift_details: ["read:products"],
  create_checkout_session: ["read:products", "write:orders", "stripe:checkout"],
} as const;

Im Tool‑ und MCP‑Auth‑Beschrieb verweisen Sie dann auf dieselben Scopes. Das ist nicht nur ein Lippenbekenntnis zu „Least Privilege“, sondern ein konkreter Vertrag.

5. Observability und SLO: damit sichtbar ist, wie die App lebt

Der nächste Block im Pass handelt von Observability: wie Sie feststellen, dass die App lebt und gesund ist. Hier kommen strukturierte Logs, Metriken, SLOs und Links zu Dashboards zusammen.

Für GiftGenius ist es sinnvoll zu beschreiben:

Die wichtigsten SLOs.
Zum Beispiel: Verfügbarkeit des MCP ≥ 99.5% wird zu Verfügbarkeit des MCP ≥ 99,5 %, p95‑Latenz für suggest_gifts < 5 Sekunden, Erfolgsrate für den Checkout ≥ 99 %.

Wo man diese SLOs einsehen kann.
Name und URL des Dashboards in Grafana/Datadog/… (im Pass reicht „Dashboard: GiftGenius / SLO“).

Das Format der strukturierten Logs.
Im vorherigen Modul zu Observability haben Sie bereits Felder wie request_id, tool_name, user_id/tenant_id, tokens_in/tokens_out, cost_estimate, duration_ms, error_code durchdacht. Im Pass ist ein kleines JSON‑Beispiel hilfreich; noch besser: wir definieren den TypeScript‑Typ, der auch im Code verwendet wird.

// lib/logging.ts
export type ToolInvocationLog = {
  level: "info" | "error";
  timestamp: string;
  requestId: string;
  userId?: string;
  toolName: string;
  tokensIn?: number;
  tokensOut?: number;
  costEstimateUsd?: number;
};

Und eine Helper‑Funktion:

export function logToolInvocation(event: ToolInvocationLog) {
  console.log(JSON.stringify({ type: "tool_invocation", ...event }));
}

Dieser Typ wird nun zur Brücke zwischen Code und Pass: Im Observability‑Abschnitt schreiben Sie, dass alle Tool‑Aufrufe im Format ToolInvocationLog geloggt werden, und verlinken das Dashboard, das diese Einträge aggregiert.

Man kann eine kurze Textkette ergänzen:

Event‑Log → Log‑Storage → SLO‑Dashboards → Alerts → Incident/Runbook.

6. Economics & Product Metrics: Geld und Nutzerverhalten

Hier verbinden Sie alles, was Sie im vorherigen Block zur Ökonomie (M19) erarbeitet haben: Kostenmetriken, Pricing und Produkt‑Analytics.

Für GiftGenius sollten Sie im Pass festhalten:

Die Unit‑Economics des Schlüsselszenarios (vereinfacht: „Ökonomie einer abgeschlossenen Aufgabe“).
Zum Beispiel: „Der durchschnittliche cost_per_successful_task (Geschenk‑Vorschlag mit erfolgreicher Zahlung) = 0,13 $ (LLM + Infra). Durchschnittlicher Erlös pro Task = 0,80 $ (CPA von Partnern).“

Das Hauptmonetarisierungsmodell.
Kurz: „Kostenlose Basissuche ohne Kauf; Monetarisierung über CPA für den Besuch beim Partner‑Shop + optionales Premium‑Abo mit erweiterten Filtern und Geschenk‑Historie.“

Zentrale Produktmetriken.
Zum Beispiel: Activation‑Rate = Anteil der Nutzer mit mindestens einem workflow_completed; Repeat‑Rate = Anteil der Nutzer, die mindestens einmal im Monat zurückkehren; Conversion workflow_completed → checkout_success.

Experimente.
Liste laufender A/B‑Tests: „Modell A (teuer) vs. Modell B (günstig)“, „Langer Wizard vs. schneller Inline‑Flow“. Für jedes Experiment speichern Sie experiment_id, Varianten und Zielmetriken (Conversion, cost_per_task, quality‑score).

Auch im Code kann sich das zeigen, damit der Pass nicht Theorie bleibt — etwa über einen einheitlichen Helper für Analytics‑Events:

// lib/analytics.ts
export function trackEvent(
  name: string,
  payload: Record<string, unknown>,
) {
  console.log(JSON.stringify({
    type: "analytics",
    name,
    ts: new Date().toISOString(),
    ...payload,
  }));
}

Und ein Aufruf beim erfolgreichen Abschluss des Workflows:

trackEvent("workflow_completed", {
  userId,
  requestId,
  experimentId: "model_ab_01",
  variant: "A",
  costUsd: 0.13,
  checkoutSuccess: true,
});

Im Pass beschreiben Sie, welche Events die wichtigsten sind und welche KPIs daran hängen. Der Code ist der Beleg, dass Sie wirklich messen — und nicht nur versprechen.

Metriken und Ökonomie haben aber nur dann Sinn, wenn die App stabil im Produktionseinsatz läuft. Deshalb schauen wir im nächsten Abschnitt, wie Sie im Pass die operative Seite von GiftGenius festhalten: Incidents, On‑Call und Runbooks.

7. Ops & Incidents: wie Sie im Produktionseinsatz mit der App leben

Dieser Abschnitt behandelt, wie Sie reagieren, wenn etwas nicht nach Plan läuft.

Für GiftGenius ist es sinnvoll, im Pass mindestens zwei typische Incidents zu nennen:

Zahlungsprobleme.
Zum Beispiel: Rückgang der Checkout‑Erfolgsrate unter das SLO, massenhafte Fehler bei Stripe‑Webhooks. Im Pass verweisen Sie auf das Runbook „Checkout Failures“ mit Symptomen, „wo schauen“ (Error‑Dashboard, Logs des Webhook‑Endpoints), schnellen Mitigation‑Schritten (temporär: fehlerhaften Feature‑Flag deaktivieren, einen Teil des Traffics in die Sandbox leiten oder vorübergehend nur Gutscheine anbieten) und Follow‑ups (Post‑Mortem, neue Alerts hinzufügen).

Probleme mit MCP/LLM.
Zum Beispiel: Anstieg der p95‑Latenz für suggest_gifts auf 9 Sekunden oder der Fehler „Error talking to app“ für einen großen Anteil von Requests. Hier gibt es ein eigenes Runbook: OpenAI‑Status prüfen, Tunnel/Vercel prüfen, MCP‑Health‑Check, Umschalten in einen degradierten Modus, in dem der Agent versucht, ohne Katalogzugriff zu antworten (generische Ideen aus dem Modell, ohne Commerce).

In diesem Abschnitt beschreiben Sie außerdem kurz den operativen Kalender: wie oft Sie SLOs überprüfen, Cost‑Reviews durchführen, Security‑Logs prüfen und Secrets rotieren.

Ergänzen Sie auch, wer On‑Call ist (auch wenn es nur eine Person ist — Sie selbst) und in welchen Slack‑Kanal bzw. an welche E‑Mail Alerts gehen.

8. Roadmap & Risks: ein ehrlicher Blick nach vorn

Der finale Block des Passes handelt von der Zukunft. Es muss kein Roman sein. 3–5 realistische Schritte zur Weiterentwicklung der App und einige bekannte Einschränkungen reichen.

Für GiftGenius könnte das so aussehen:

• Start von LLM‑Bewertungen (LLM‑evals) für die Qualität der Vorschläge, um Qualität mit Conversion zu verknüpfen;
• Hinzufügen einer weiteren Locale und Test lokalisierter Tool‑Beschreibungen;
• Experiment mit günstigeren Modellen auf einem Teil des Traffics;
• Verbesserung der Resilienz gegenüber Stripe‑Störungen (Webhooks und verzögerte Bestätigungen robuster verarbeiten);
• Vorbereitung auf die Migration auf eine neue Version des Apps SDK oder MCP (inkl. Versionierung der Tool‑Verträge).

Einschränkungen: API‑Caps/Limits, Beschränkungen des ChatGPT‑UIs (z. B. Limit der Kartenanzahl in der Ausgabe), Schwachstellen der aktuellen Architektur (Single‑Region‑DB, kein Hot‑Standby für MCP etc.).

Plan für Experimente: welche Hypothesen Sie zu Pricing/UX/Modellen prüfen wollen und anhand welcher Metriken Sie entscheiden.

9. Wo der Pass lebt und wie man ihn aktualisiert

In der Praxis ist das bequemste Format ein PASSPORT.md im Repository‑Root von GiftGenius oder im Ordner docs/ sowie eine Kopie/Link in Ihrem Doku‑System (Confluence, Notion etc.).

Er sollte leicht genug sein, um in 10–15 Minuten gelesen zu werden, und dicht genug, um damit Fragen zu beantworten:

• „Was ist diese App überhaupt und wie ist sie aufgebaut?“
• „Was passiert, wenn X ausfällt?“
• „Wie viel kostet uns ein Nutzer?“
• „Welche Risiken beschäftigen uns derzeit am meisten?“

Aktualisieren Sie den Pass bei Änderungen an:

• Architekturgrenzen (neuer Service, neuer Zahlungsanbieter, Migration auf einen anderen Stack);
• wichtigen SLOs oder der Security‑Policy (z. B. andere Retention);
• dem Monetarisierungsmodell;
• signifikanten Incidents und den Erkenntnissen aus den Post‑Mortems.

Kleine Codeänderungen erfordern keine sofortige Pass‑Anpassung, sonst wird er zu einem weiteren veraltenden Dokument.

Der Pass ist im Grunde die Essenz dessen, was Sie über Ihre App wissen. Der nächste logische Schritt ist, darauf basierend lebenden Menschen vom Produkt zu erzählen: Techies und dem Business.

10. Technisch‑produktseitiges Demo: warum zwei „Versionen der Geschichte“ nötig sind

Wenn Sie GiftGenius zeigen, sprechen Sie fast immer zu zwei Zielgruppen (manchmal sitzen beide im selben Raum):

• Technik (CTO, Architekten, Security, Entwicklungs‑Leads);
• Produkt/Business (CEO, Investoren, Produktmanager, Marketing).

Für technische Personen ist wichtig, dass:

• die Architektur verständlich ist, Schichten getrennt sind und es Erweiterungspunkte gibt;
• Zuverlässigkeit und Observability durchdacht sind: Logs, Tracing, SLOs, Alerts;
• es eine Resilienz‑Story gibt: Was passiert, wenn OpenAI, MCP, Stripe ausfallen;
• wie Sie die Evolution planen (Migration von SDK/MCP/Modellen).

Für das Business ist anderes wichtiger:

• welchen Schmerz der Nutzer hat (z. B. „Geschenksuche dauert 40 Minuten“);
• wie GiftGenius diesen Schmerz innerhalb von ChatGPT in wenigen Minuten löst;
• wie Sie monetarisieren, Unit‑Economics und Wachstumsmetriken;
• ob dadurch die Akquisekosten sinken und Conversion/Umsatz steigen.

Denken Sie daher an zwei „Schichten“ derselben Demo‑Story: Reifezeichen eines Produkts zeigen Sie beiden, aber mit unterschiedlichen Akzenten.

11. Technisches Demo‑Szenario für GiftGenius (5–7 Minuten)

Stellen wir uns vor, Sie präsentieren GiftGenius vor einem technischen Publikum.

Zuerst kurz Kontext.
Genau 30 Sekunden: „GiftGenius – ChatGPT App für Geschenkvorschläge mit ACP‑Checkout. Wir leben innerhalb von ChatGPT, nutzen das Apps SDK, MCP und einen Agenten zur Schritt‑Planung.“

Dann der Architektur‑Slide/Ausschnitt aus dem Pass.
Sie öffnen ein Diagramm ähnlich dem in Mermaid und erklären, wo die Verantwortungsgrenze von ChatGPT (LLM‑Teil) liegt, wo Ihr Widget ist, wo MCP und wo die Commerce‑Schicht mit Stripe. Zeigen Sie, dass alle Tools im MCP gekapselt sind und das Widget eine dünne UI‑Schicht darstellt.

Live‑Demo mit Logs.
Starten Sie ein Split‑Screen: links ChatGPT mit GiftGenius, rechts Logs oder MCP Inspector. Stellen Sie eine natürliche Anfrage wie „Finde ein Geschenk für einen Gamer bis 50 $“. Während der Ausführung zeigen Sie:

• den Tool‑Aufruf suggest_gifts mit request_id;
• den strukturierten Log tool_invocation mit sichtbaren tokens, cost_estimate und duration_ms;
• ein zweites Tool, das die ACP‑Session anlegt und eine Bestellung erstellt.

Stark ist es, wenn Sie direkt ins Dashboard zeigen können: „hier die p95‑Latenz dieses Szenarios der letzten 24 Stunden, hier die Checkout‑Erfolgsrate“. Das ist der Moment, in dem Techies verstehen, dass dies kein Pet‑Project, sondern ein System mit Observability ist.

Failure‑Injection (optional, aber sehr wirkungsvoll).
Wenn Sie dem System genügend vertrauen (oder das Szenario vorbereitet haben), können Sie temporär z. B. den Katalogzugriff (DB) deaktivieren und die Anfrage wiederholen. Sie zeigen damit:

• der MCP loggt den Fehler korrekt und ein Alert wird ausgelöst;
• der Agent wechselt in einen degradierten Modus und sagt dem Nutzer ehrlich, dass der Katalog nicht verfügbar ist, kann aber generische Ideen liefern;
• der Checkout ist in diesem Modus nicht verfügbar.

Zum Schluss — kurz zu Betrieb und Evolution.
Beenden Sie mit einem Slide aus dem Pass mit SLOs, Incidents und Roadmap: Ihre Zielwerte, wie Sie sie monitoren, welche Incidents bereits mit Runbooks abgedeckt sind, was in v2 kommt (Skalierung, neue Modelle, neue Märkte).

Das Hauptsignal an das Publikum: Es ist nicht nur eine hübsche UI, sondern eine durchdachte Plattform, bereit für den Produktionseinsatz.

12. Produkt‑Demo‑Szenario (Business‑Perspektive)

Nun derselbe GiftGenius, aber als Produkt erzählt.

Beginnen Sie mit der Nutzer‑Story.
Zum Beispiel: „Wir haben Katja, sie muss am Abend ein Geschenk für eine Kollegin auswählen. Normalerweise verbringt sie damit 30–40 Minuten in Shop‑Websites.“

Zeigen Sie ChatGPT mit GiftGenius.
Katja schreibt einen natürlichen Satz statt in einem Marktplatz an Filtern zu klicken: „Finde ein Geschenk für eine Kollegin, die Brettspiele liebt, Budget bis 50 $“. ChatGPT erklärt, dass es GiftGenius nutzen kann, und öffnet das Widget. GiftGenius klärt ein paar Details und zeigt eine Liste von Optionen.

Gehen Sie zum Ergebnis und zum Mehrwert über.
Zeigen Sie Geschenk‑Karten mit der Möglichkeit zu speichern oder direkt zum Kauf überzugehen, Checkout via ACP/Stripe. Wichtig ist der Satz: „Das dauert 3–5 Minuten — und zwar dort, wo der Nutzer ohnehin Zeit verbringt: in ChatGPT.“

Dann 1–2 Minuten zu Monetarisierung und Metriken.
Erklären Sie, dass Sie über CPA oder Provisionen der Shops verdienen und ggf. einen Premium‑Modus für Vielnutzer anbieten. Beziehen Sie sich auf Zahlen aus dem Pass: wie viel ein erfolgreicher Ablauf kostet, wie die Conversion zum Kauf ist und welcher Margen‑Puffer einkalkuliert ist.

Als Nächstes etwas zum Wachstum.
Erzählen Sie, wie Sie Nutzer gewinnen wollen: über den Store‑Listing in ChatGPT, Content, Partner‑Integrationen. Verknüpfen Sie alles mit Produktmetriken: „Wir beobachten, wie sich Änderungen im Listing auf die Zahl neuer app_opened und die Activation‑Rate auswirken; wie Artikel und Videos Retention und den Anteil der Nutzer mit mehr als einem workflow_completed beeinflussen.“

Abschließen mit Risiken und Plan.
Sprechen Sie ehrlich über aktuelle Einschränkungen (z. B. Abhängigkeit von Limits von OpenAI/Stripe, derzeit schwache Lokalisierungs‑Unterstützung) und zeigen Sie die Roadmap: welche Experimente und Verbesserungen im Pipeline sind.

Wenn man das sauber macht, sieht das Business‑Publikum nicht „noch ein KI‑Widget“, sondern ein verständliches Produkt mit Ökonomie und Wachstumsplan.

13. Praxis: den eigenen Pass und das Demo rund um GiftGenius bauen

Als Praxisaufgabe zu dieser Vorlesung können Sie direkt in Ihrem GiftGenius‑Repository die Datei PASSPORT.md anlegen und sie mindestens in fünf Blöcken füllen: Architektur, Sicherheit, Observability/SLO, Ökonomie und Produktmetriken, Incidents/Operationen. Sobald Sie ein neues Runbook ergänzen oder SLOs ändern, gehen Sie zurück in den Pass und spiegeln die Änderung.

Parallel lohnt sich ein Demo‑Skript für 5–7 Minuten: die ersten 2–3 Minuten — Nutzer‑Szenario und Mehrwert, die folgenden 2–3 Minuten — Architektur und Betrieb (SLO, Kosten, Incidents). Ein solches Skript trainiert hervorragend, sowohl die Sprache des Business als auch der Technik zu sprechen — ohne in trockenen Code oder reines Marketing zu verfallen.

Diese Artefakte sind kein Alibi‑Dokument, sondern die Basis des finalen Capstone‑Demos. Genau mit diesem Pass und dem Szenario werden Sie Ihre App später vor den „CTO/CEO“ verteidigen.

14. Typische Fehler bei der Vorbereitung von Pass und Demo

Fehler Nr. 1: den Pass in eine Marketing‑Broschüre verwandeln.
Manchmal ähnelt der Pass einer Landing‑Page: viele allgemeine Worte über „innovative KI“, wenig Konkretes zu Architektur, SLO, Kosten und Incidents. So ein Dokument hilft niemandem: Techies verstehen nicht, wie es innen lebt, und das Business sieht nicht, dass Sie Risiken im Griff haben. In den Pass gehören Fakten, Schemata, Metriken und Links.

Fehler Nr. 2: nur den Code beschreiben, nicht Datenflüsse und Verantwortungen.
Ein verbreiteter Entwickler‑Bias ist, alle Services, Bibliotheken und Frameworks aufzuzählen und die High‑Level‑Skizze „Nutzer → ChatGPT → Widget → MCP → Agents → ACP/DB“ zu vergessen. Neue Leute verstehen dadurch nicht, wer wofür verantwortlich ist und wo Grenzen verlaufen. Im Architekturteil sind Data‑Flows und Schichten wichtiger als die Namen aller npm‑Pakete.

Fehler Nr. 3: Pass nicht mit Observability‑ und Kosten‑Instrumentierung verknüpfen.
Oft steht im Pass stolz „wir haben SLOs“, aber nirgends ist sichtbar, wie sie gemessen werden, wo Logs sind und welche Felder genau in JSON‑Events geschrieben werden. Oder es steht, dass die „LLM‑Kosten unter Kontrolle“ sind, aber keine einzige Metrik cost_per_task existiert. Je schwächer die Verbindung zu realen Logs, Metriken und Dashboards, desto wahrscheinlicher leben SLOs und Kosten nur in Google Docs — nicht im Monitoring‑System.

Fehler Nr. 4: Demo nur über eine schöne UI, ohne Architektur und Ausfallsicherheit.
Es ist leicht, in eine Show abzugleiten: „Schaut euch diese tollen Geschenk‑Karten an.“ Das technische Publikum denkt derweil: „Was passiert, wenn Stripe ausfällt?“, „Wie loggt ihr Tool‑Aufrufe?“, „Ist das skalierbar?“. Wenn im Demo nicht mindestens ein, zwei Stories zu Logs, SLOs und Incidents vorkommen, bleibt bei Techies das Gefühl eines Spielzeugs — nicht eines Produkts.

Fehler Nr. 5: Demo nur für Techies, ohne Nutzer‑Story und Ökonomie.
Der Gegen‑Bias: 10 Minuten über p95‑Latenz, MCP‑Handshake und JSON‑Schema der Tools sprechen, aber nie sagen, welchen Nutzerschmerz man löst, wer bezahlt und was ein Ablauf kostet. Für Business und Produkt wirkt das wie „coole Ingenieur‑Spielerei ohne Business‑Case“. Tragen Sie immer mindestens zwei Hüte: den des Ingenieurs und den des Produktmanagers.

Fehler Nr. 6: Pass und Demo driften auseinander.
Manchmal steht im Pass das eine, im Demo das andere: Im Dokument sind bestimmte SLOs versprochen, auf den Dashboards stehen andere; im Pass sind drei Incidents mit Runbooks, in der Live‑Präsentation greift beim ersten Fehler niemand auf sie zurück. Nutzen Sie den Pass als Drehbuch fürs Demo: Verweisen Sie auf dieselben SLOs, dieselben Dashboards, dieselben Runbooks. So entsteht der Eindruck eines konsistenten Systems — nicht eines Haufens zufälliger Artefakte.

Fehler Nr. 7: den Pass wie eine Einmal‑Hausarbeit behandeln.
Die größte Falle: PASSPORT.md fürs Modul abgeben und dann vergessen. In der Realität führen gerade solche Dokumente dazu, dass Wissen nur in Köpfen lebt. Behandeln Sie den Pass wie einen lebendigen Teil des Codes: Er soll sich bei wesentlichen Architektur‑, Betriebs‑ oder Business‑Entscheidungen mitändern. In ein paar Monaten werden Sie sich dafür selbst danken.