Produktionsaudit

Was macht Produktionsaudit?

Verwenden Sie dieses Skill, wenn der Benutzer fragt, ob eine Anwendung bereit zur Auslieferung ist, was in der Produktion brechen könnte oder was vor einem Launch behoben werden muss. Es handelt sich um eine wartbare Neufassung der veralteten Community-Idee "production-audit": Sie behält die nützliche Produktionsreife-Perspektive bei und entfernt ungepinnte externe Ausführung und die Weitergabe von Daten an Dritte.

Wann verwenden

• Der Benutzer fragt: "Ist das produktionsreif?", "Was würde in der Prod brechen?", "Was haben wir übersehen?", "Prüfe dieses Repo" oder "Bereit zur Auslieferung?"
• Ein Feature wurde gemerged und benötigt einen Pre-Deploy- oder Post-Merge-Risikocheck.
• Ein öffentlicher Launch, eine Demo, ein Kunden-Rollout oder ein Investoren-Durchlauf steht bevor.
• CI ist grün, aber der Benutzer möchte das Produktionsrisiko, nicht nur den Teststatus.
• Eine deployed URL, ein Release-Branch, ein PR oder der aktuelle Checkout ist für die Evidenzsammlung verfügbar.

Wann nicht verwenden

• Während der aktiven Implementierung, wenn der richtige Fokus auf zeilenweiser sicherer Programmierung liegt; verwenden Sie zuerst security-review.
• Für reine Bibliotheken, Vorlagen, reine Dokumentations-Repos oder Gerüste, es sei denn, der Benutzer möchte die Paketierungs-/Release-Fähigkeit statt der Anwendungsbereitschaft prüfen.
• Wenn der Benutzer nach einem formellen Compliance-Audit fragt. Dieses Skill ist technisches Triage, keine rechtliche, finanzielle, medizinische oder regulatorische Zertifizierung.
• Wenn die einzige verfügbare Evidenz eine Produktidee ohne Repo, Deployment, CI oder Runtime-Oberfläche ist.

Wie es funktioniert

Erstellen Sie das Audit aus lokaler und vom Benutzer autorisierter Evidenz. Führen Sie keine ungepinnten Remote-Codes aus, laden Sie Repository-Inhalte nicht in Dienste Dritter hoch und rufen Sie keine externen Scanner auf, es sei denn, der Benutzer genehmigt ausdrücklich dieses spezifische Tool und den Datenfluss.

Verwenden Sie diese Reihenfolge:

1. Legen Sie die Release-Oberfläche fest.
2. Lesen Sie die letzten Änderungen und den aktuellen Branch-Status.
3. Inspizieren Sie Runtime, Auth, Daten, Zahlungen, Hintergrund-Jobs, KI und Deployment-Grenzen, die tatsächlich im Repo existieren.
4. Überprüfen Sie CI, Tests, Migrationen, Umgebungsdokumentation und Rollback-Pfade.
5. Erstellen Sie eine kurze Ship/Block-Empfehlung mit spezifischen Korrekturen.

Evidenz-Checkliste

Beginnen Sie mit günstigen, lokalen Signalen:

git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD

Inspizieren Sie dann die projektspezifische Oberfläche:

• Paketskripte, CI-Workflows, Release-Skripte, Docker-Dateien und Deployment-Manifeste.
• API-Routen, Webhooks, Auth-Middleware, Hintergrund-Worker, Cron-Jobs und Datenbankmigrationen.
• Dokumentation der Umgebungsvariablen und Startprüfungen.
• Observability-Hooks, Fehlerberichterstattung, Logs, Health Checks und Dashboards.
• Rollback-, Seed-, Migrations- und Backfill-Anweisungen.
• E2E-Abdeckung für die wichtigsten Benutzerpfade.

Wenn eine deployed URL im Scope liegt, verwenden Sie nur Browser- oder HTTP-Prüfungen gegen diese URL und vermeiden Sie berechtigte Aktionen, es sei denn, der Benutzer stellt ein sicheres Testkonto zur Verfügung.

Risikolinsen

Sicherheit und Authentifizierung

• Sind öffentliche Routen, API-Routen und Admin-Routen klar getrennt?
• Werden Authentifizierung und Autorisierung serverseitig erzwungen?
• Werden Geheimnisse aus Client-Bundles, Logs, Beispielausgaben und eingecheckten Dateien ferngehalten?
• Sind Ratenbegrenzungen, CSRF-Schutz, CORS-Richtlinie und Upload-Validierung vorhanden, wo die App sie benötigt?
• Verteidigt sich die KI- oder Agenten-Oberfläche gegen Prompt Injection, Tool-Missbrauch und nicht vertrauenswürdige Inhalte, die in privilegierte Aktionen gelangen?

Datenintegrität

• Laufen Migrationen sauber durch und haben sie einen Rollback- oder Wiederherstellungsplan?
• Werden destruktive Migrationen, Backfills und Datenimporte sicher durchgeführt?
• Entsprechen Datenbankrichtlinien, Grants und Service-Rollen-Grenzen dem Mieter-Modell der App?
• Sind Wiederholungsversuche für Schreibvorgänge, Jobs und Webhook-Handler idempotent?

Zahlungen und Webhooks

• Werden Webhook-Signaturen überprüft, bevor vertrauenswürdige Payload-Felder geparst werden?
• Ist jeder Zahlungs-, Abonnement- oder Erfüllungs-Webhook idempotent?
• Werden Wiederholungen, doppelte Zustellungen und Zustellungen in falscher Reihenfolge behandelt?
• Sind Testmodus- und Live-Modus-Anmeldeinformationen getrennt?

Betrieb

• Kann die App aus einem sauberen Checkout unter Verwendung dokumentierter Befehle gestartet werden?
• Sind erforderliche Umgebungsvariablen benannt, validiert und verhalten sie sich fehlerschnell?
• Gibt es einen Health Check, der die Erreichbarkeit von Abhängigkeiten nachweist?
• Sind Deployment-, Rollback- und Incident-Owner-Pfade dokumentiert?
• Sind Logs nützlich, ohne Geheimnisse oder persönliche Daten preiszugeben?

Benutzererfahrung

• Sind die launchkritischen Pfade auf Desktop und Mobilgeräten abgedeckt?
• Sind Formulare auf Mobilgeräten ohne Input-Zoom, Layout-Überlappungen oder blockierte Absende-Zustände nutzbar?
• Teilen Lade-, Leer-, Fehler- und Berechtigungsverweigerungs-Zustände dem Benutzer mit, was passiert ist?
• Gibt es einen Support- oder Wiederherstellungspfad, wenn ein kritischer Vorgang fehlschlägt?

Bewertung

Verwenden Sie Bewertungen, um die Priorisierung zu erzwingen, nicht um mathematische Sicherheit vorzutäuschen.

Bereich	Punkte	Bedeutung
Blockiert	0-49	Nicht ausliefern, bis die größten Risiken behoben sind
Riskant	50-69	Nur hinter einem kleinen Rollout oder einer internen Beta ausliefern
Startklar mit Einschränkungen	70-84	Ausliefern, wenn die Eigentümer die aufgeführten Risiken akzeptieren
Stark	85-100	Keine offensichtlichen Launch-Blocker aus der verfügbaren Evidenz

Begrenzen Sie die Punktzahl auf 69, wenn eine der folgenden Bedingungen zutrifft:

• Authentifizierung oder Autorisierung fehlt bei sensiblen Daten.
• Zahlungs- oder Erfüllungs-Webhooks sind nicht idempotent.
• Erforderliche Migrationen können nicht sicher ausgeführt werden.
• Geheimnisse sind in Client-Bundles, Logs oder committeten Dateien offengelegt.
• Es gibt keinen Rollback-Pfad für ein Release mit hohen Auswirkungen.

Begrenzen Sie die Punktzahl auf 84, wenn CI nicht grün ist oder der launchkritische Pfad nicht End-to-End getestet wurde.

Ausgabeformat

Beginnen Sie mit einem Satz:

Produktionsaudit: 76/100, startklar mit Einschränkungen, mit Webhook-Idempotenz und Rollback-Dokumentation als den beiden Risiken, die vor dem öffentlichen Launch behoben werden sollten.

Listen Sie dann auf:

• Blocker: Muss behoben werden vor dem Deployment.
• Hochwertige Korrekturen: Nächste Korrekturen, wenn der Benutzer die Punktzahl verbessern möchte.
• Geprüfte Evidenz: Dateien, Befehle, CI, deployed URL oder PRs, die inspiziert wurden.
• Fehlende Evidenz: Was das Vertrauen ändern würde, wenn es bereitgestellt würde.
• Nächster Schritt: Ein konkreter Fix oder ein Verifizierungsschritt.

Halten Sie Stärken kurz. Der Benutzer fragte nach der Bereitschaft, also ist die nützliche Antwort das verbleibende Risiko und der nächste Schritt.

Beispiel

Benutzer:

Ist diese bereit zur Auslieferung?

Antwort:

Produktionsaudit: 68/100, riskant, weil Stripe-Webhooks verifiziert, aber nicht idempotent sind und es keinen Rollback-Hinweis für die ausstehende Migration gibt.

Blocker:
- Idempotenz für `checkout.session.completed` hinzufügen, bevor Bestellungen erfüllt werden.
- Rollback-Pfad für `20260511_add_billing_state.sql` schreiben und testen.

Hochwertige Korrekturen:
- Health Check hinzufügen, der die Erreichbarkeit von Datenbank und Zahlungsanbieter überprüft.
- Einen E2E-Pfad für Upgrade, Webhook-Erfüllung und Abrechnungsseiten-Aktualisierung hinzufügen.

Geprüfte Evidenz:
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- GitHub Actions Run für den Release-Branch

Nächster Schritt: Soll ich zuerst die Webhook-Idempotenz patchen?

Anti-Patterns

• Ausführen von npx <package>@latest oder einem Remote-Scanner als Standard-Audit-Pfad.
• Hochladen von Quellcode, Geheimnissen, Kundendaten oder privater Topologie zu einem externen Audit-Dienst ohne ausdrückliche Genehmigung.
• Erstellen einer Punktzahl, ohne die geprüfte Evidenz zu nennen.
• Grüne CI als Produktionsreife zu behandeln.
• Mit einem allgemeinen "Lassen Sie mich wissen, was Sie tun möchten" enden.

Siehe auch

• Skill: security-review
• Skill: deployment-patterns
• Skill: e2e-testing
• Skill: tdd-workflow
• Skill: verification-loop