getpaidskills/launch-checklist

Was macht launch-checklist?

Führen Sie das automatisierte Audit aus, beheben Sie die Fehler im Code, wiederholen Sie den Vorgang bis alles sauber ist, und gehen Sie dann die manuellen Punkte durch, die das Skript nicht erkennen kann. Berichten Sie dem Benutzer, was geändert wurde und was noch erledigt werden muss.

Schritt 1 — Audit ausführen

Gegen die Produktions-URL, falls vorhanden, sonst gegen einen lokalen Produktions-Build (npm run build && npm start, nicht den Dev-Server — Dev-Server fügen Skripte hinzu und überspringen Caching):

python3 scripts/audit_site.py https://example.com            # Textbericht
python3 scripts/audit_site.py http://localhost:3000 --max-pages 30 --json > audit.json

Was geprüft wird (Details in references/checks.md):

• Pro Seite: <title> (10–60 Zeichen), Meta-Beschreibung (50–160), genau ein <h1>, <html lang>, Viewport, canonical (absolut, gleicher Host), og:title/description/image, twitter:card, <img> ohne alt, HTML-Größe, Antwortzeit, noindex auf Seiten, die Sie wahrscheinlich indiziert haben möchten, doppelte Titel/Beschreibungen über alle Seiten hinweg.
• Site: /robots.txt existiert und sperrt nicht alles mit Disallow: /, enthält Verweis auf eine Sitemap; /sitemap.xml (oder die in robots genannte) wird analysiert und ihre URLs geben 200 auf demselben Host zurück; Favicon erreichbar; apple-touch-icon; eine zufällige URL gibt 404 zurück (nicht 200 oder eine Weiterleitung zur Startseite); http→https-Weiterleitung (bei https-Seiten); Links zu Datenschutzerklärung/AGB (und Widerrufsbelehrung, falls die Seite etwas verkauft); /llms.txt vorhanden (nur informativ).

Exit-Code 1 bei jedem FAIL. Gecrawlte Seiten: Start-URL + Links auf demselben Host, bis zu --max-pages (Standard 20).

Schritt 2 — Im Codebase beheben

Erkennen Sie das Framework und verwenden Sie das passende Rezept. Für Next.js App Router enthält references/fixes-nextjs.md fertige robots.ts, sitemap.ts, not-found.tsx, metadata, Icon-Konventionen. Generische HTML/andere Frameworks: references/fixes-generic.md.

Regeln:

• Beheben Sie die Ursache (gemeinsames Layout / Metadata-Helper), nicht Seite für Seite, wenn das Problem wiederholt auftritt.
• Fügen Sie niemals noindex hinzu oder blockieren Sie Crawler ohne Nachfrage.
• Fehlende Rechtsseiten: Generieren Sie sie mit dem Skill legal-pages, falls installiert; andernfalls teilen Sie es dem Benutzer mit — erfinden Sie keine Rechtstexte selbst.
• Fehlende OG-Bilder: Verwenden Sie den Skill og-image-kit, falls installiert.

Schritt 3 — Wiederholen bis kein FAIL mehr

Führen Sie denselben Befehl erneut aus. WARN-Punkte: Beheben Sie die günstigen, listen Sie den Rest für den Benutzer auf.

Schritt 4 — Manuelle Punkte (Skript kann nicht prüfen)

Gehen Sie references/manual-checklist.md mit dem Benutzer durch — Analytics installiert, Fehlerverfolgung, Transaktions-E-Mail-Zustellbarkeit (SPF/DKIM/DMARC), Zahlungsablauf Ende-zu-Ende mit einer echten kleinen Zahlung getestet, Backups, Uptime-Monitor, Search Console / Bing Webmaster-Verifizierung und Sitemap-Einreichung, Status der Domain-Verlängerung. Markieren Sie jeden Punkt als erledigt / nicht zutreffend / Benutzer muss erledigen.

Schritt 4b — Zahlungs-Selbstprüfung (falls die Seite Geld nimmt)

python3 scripts/payment_check.py --src . --provider creem          # Code-Scan
python3 scripts/payment_check.py --url http://localhost:3000        # Durchläuft einen laufenden Build
python3 scripts/payment_check.py --url http://localhost:3000 --secret "$CREEM_WEBHOOK_SECRET"  # Nur Testmodus-Secret

FAILs: Webhook akzeptiert unsignierte oder gefälschte Anfragen, parst JSON vor der Verifikation, keine Deduplizierung anhand der Ereignis-ID, Erfolgsseite gewährt Zugriff, Zahlungs-Secrets in NEXT_PUBLIC_* oder committet, Webhook leitet weiter oder sitzt hinter einem Bot-Check. Beheben Sie sie, wiederholen Sie den Vorgang, führen Sie dann die manuellen Kartentests in references/payment-checks.md durch (erfolgreiche Karte, abgelehnte Karte, Rückerstattung, Dashboard-Erneutesenden, Stornieren). Übergeben Sie niemals ein Live-Webhook-Secret. scripts/test_payment_check.py ist der eigene Test des Skripts. Test-, Spezifikations- und Fixture-Dateien (*.test.ts, *.spec.tsx, test_*.py, alles unter tests/, e2e/, __tests__/, fixtures/) werden nicht als Handler oder Erfolgsseiten gewertet, da sie absichtlich unsignierte Anfragen senden und Zeilen einfügen; sie werden dennoch auf committete Live-Schlüssel gescannt. Der Bericht gibt an, wie viele übersprungen wurden (INFO test files).

Berichtsformat

Launch-Audit für <url> — <datum>
FAIL behoben: …   (datei:zeile geändert)
WARN behoben: …
Noch offen (benötigt dich): …
Manuelle Checkliste: x/y erledigt