Produktions-Audit

Was macht Produktions-Audit?

Verwenden Sie diesen Skill, wenn der Benutzer fragt, ob eine Anwendung bereit für den Versand ist, was in der Produktion kaputt gehen könnte oder was vor einem Launch behoben werden muss. Es handelt sich um eine maintainer-sichere Neufassung der veralteten Community-Idee "production-audit": Sie behält die nützliche Produktionsreife-Perspektive bei und entfernt nicht gepinnte externe Ausführungen sowie die Weitergabe von Daten an Dritte.

Wann verwenden

• Der Benutzer fragt: "Ist das produktionsreif?", "Was würde in der Produktion kaputt gehen?", "Was haben wir übersehen?", "Auditiere dieses Repo" oder "Bereit zum Versand?"
• 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-Walkthrough steht kurz bevor.
• CI ist grün, aber der Benutzer möchte das Produktionsrisiko bewerten, nicht nur den Teststatus.
• Eine bereitgestellte 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 die richtige Perspektive eine zeilenweise sichere Codierung ist; 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-Bereitschaft und nicht die Anwendungsbereitschaft bewerten.
• Wenn der Benutzer nach einem formellen Compliance-Audit fragt. Dieser Skill ist Engineering-Triage, keine rechtliche, finanzielle, medizinische oder regulatorische Zertifizierung.
• Wenn die einzige verfügbare Evidenz eine Produktidee ohne Repo, Bereitstellung, CI oder Laufzeitoberfläche ist.

Funktionsweise

Erstellen Sie das Audit aus lokalen und vom Benutzer autorisierten Informationen. Führen Sie keinen nicht gepinnten Remote-Code aus, laden Sie keine Repository-Inhalte in Drittanbieterdienste hoch und rufen Sie keine externen Scanner auf, es sei denn, der Benutzer genehmigt dieses spezifische Tool und den Datenfluss ausdrücklich.

Verwenden Sie diese Reihenfolge:

1. Ermitteln Sie die Release-Oberfläche.
2. Lesen Sie die letzten Änderungen und den aktuellen Branch-Status.
3. Untersuchen Sie Laufzeit, Authentifizierung, Daten, Zahlungen, Hintergrundjobs, KI und Bereitstellungsgrenzen, die tatsächlich im Repo existieren.
4. Überprüfen Sie CI, Tests, Migrationen, Umgebungsdokumentation und den Rollback-Pfad.
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

Untersuchen Sie dann die projektspezifische Oberfläche:

• Paketskripte, CI-Workflows, Release-Skripte, Docker-Dateien und Bereitstellungsmanifeste.
• API-Routen, Webhooks, Auth-Middleware, Hintergrundarbeiter, 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 bereitgestellte URL im Rahmen liegt, führen Sie nur Browser- oder HTTP-Prüfungen gegen diese URL durch und vermeiden Sie Aktionen mit Anmeldedaten, es sei denn, der Benutzer stellt ein sicheres Testkonto zur Verfügung.

Risikobewertungen

Sicherheit und Authentifizierung

• Sind öffentliche Routen, API-Routen und Admin-Routen klar getrennt?
• Sind Authentifizierung und Autorisierung serverseitig erzwungen?
• Werden Geheimnisse von 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 Agentenoberflä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, Berechtigungen und Service-Rollen-Grenzen dem Mandantenmodell der App?
• Sind Wiederholungen 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 jede Zahlungs-, Abonnement- oder Erfüllungs-Webhook idempotent?
• Werden Wiederholungen, doppelte Zustellungen und Zustellungen in falscher Reihenfolge behandelt?
• Sind Testmodus- und Livemodus-Anmeldedaten getrennt?

Betrieb

• Kann die App von einem sauberen Checkout aus mit dokumentierten Befehlen gestartet werden?
• Sind erforderliche Umgebungsvariablen benannt, validiert und scheitern sie schnell?
• Gibt es einen Health Check, der die Erreichbarkeit von Abhängigkeiten nachweist?
• Sind Deploy-, Rollback- und Incident-Owner-Pfade dokumentiert?
• Sind Logs nützlich, ohne Geheimnisse oder personenbezogene Daten preiszugeben?

Benutzererfahrung

• Sind die launchkritischen Pfade auf Desktop und Mobilgeräten abgedeckt?
• Sind Formulare auf Mobilgeräten ohne Input-Zoom, Layout-Überschneidungen oder blockierte Absendezustände nutzbar?
• Informieren Lade-, Leer-, Fehler- und Berechtigungsverweigerungs-Zustände den Benutzer darüber, was passiert ist?
• Gibt es einen Support- oder Wiederherstellungspfad, wenn eine kritische Operation fehlschlägt?

Bewertung

Verwenden Sie Bewertungen, um die Priorisierung zu erzwingen, nicht um mathematische Sicherheit zu suggerieren.

Bereich	Punktzahl	Bedeutung
Blockiert	0-49	Nicht ausliefern, bis die größten Risiken behoben sind
Risikoreich	50-69	Nur hinter einem kleinen Rollout oder einer internen Beta ausliefern
Mit Einschränkungen startbereit	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 einer dieser Punkte 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 eingecheckten 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:

Produktions-Audit: 76/100, mit Einschränkungen startbereit, mit Webhook-Idempotenz und Rollback-Dokumentation als den zwei Risiken, die vor dem öffentlichen Launch behoben werden müssen.

Listen Sie dann auf:

• Blockaden: Muss behoben werden vor dem Deploy.
• Hochwertige Korrekturen: Nächste Korrekturen, wenn der Benutzer die Punktzahl verbessern möchte.
• Geprüfte Evidenz: Dateien, Befehle, CI, bereitgestellte URL oder PRs, die untersucht wurden.
• Fehlende Evidenz: Was würde das Vertrauen ändern, wenn es bereitgestellt würde.
• Nächster Schritt: Eine konkrete Korrektur oder ein Verifikationsschritt.

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

Beispiel

Benutzer:

Ist das bereit für den Versand?

Antwort:

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

Blockaden:
- Idempotenz für `checkout.session.completed` hinzufügen, bevor Bestellungen ausgeführt 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 Aktualisierung der Abrechnungsseite hinzufügen.

Geprüfte Evidenz:
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- GitHub Actions-Ausführung 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 in einen externen Audit-Dienst ohne explizite Zustimmung.
• Erstellen einer Bewertung, ohne die geprüfte Evidenz zu nennen.
• Grünes CI als Produktionsreife zu behandeln.
• Enden mit einem allgemeinen "Lassen Sie mich wissen, was Sie tun möchten."

Siehe auch

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