gitmedia/presseportale
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2
presseportale/.ai/rules/general.md
Kevin Adametz 53e3b270e0 dev: Vorgehen bei sensiblen Daten in der Historie dokumentiert, Roadmap 1.1/1.2 erledigt 
- git-deploy.md Abschnitt G: Rotieren, Sichern, Umschreiben, Prüfen,
  Hash-Zuordnung, Push, Server, Forgejo/NAS, lokales Aufräumen
- Protokoll: Speicherbereinigung in Forgejo und auf dem NAS erledigt,
  keine weiteren Klone, Live-Schlüssel bereits rotiert
- Agenten-Regel: keine personenbezogenen Daten oder Schlüssel ins Repository
- Roadmap: 1.1 und 1.2 erledigt, Context7 und lokales MySQL-Root unter 1.3

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-09 12:53:24 +00:00

2.5 KiB
Raw Blame History

paths
**/*

General

Befehle direkt im Dev-Container ausführen

Die Arbeitsumgebung /var/www/html liegt bereits im DEV-Container. PHP-/Artisan-, Composer- und Node-Befehle dort direkt ausführen (z. B. php artisan test --compact), ohne vendor/bin/sail davor. Eine Sail-Meldung über nicht laufendes Docker ist in diesem Container kein Nachweis, dass Docker auf dem Host gestoppt ist. Diese ausdrückliche Benutzeranweisung ersetzt die allgemeine Sail-Prefix-Vorgabe für diese Umgebung.

Fremde oder frische Laravel-Projekte nie gegen die lokale Datenbank testen

Auf global-mysql liegen die Datenbanken mehrerer Projekte, und Container-Umgebungsvariablen haben in Laravel Vorrang vor .env und nicht erzwungenen phpunit.xml-Werten. Ein frisches Laravel-Projekt hat die SQLite-Zeilen in phpunit.xml nur auskommentiert — RefreshDatabase führt dann migrate:fresh auf der Datenbank aus, die die Umgebung vorgibt (07.10.2026: so wurde pressekonto vollständig geleert). Deshalb:

  • Tests, migrate, migrate:fresh, db:wipe oder Seeder eines anderen bzw. frisch angelegten Laravel-Projekts in diesem Container nur mit DB_CONNECTION=sqlite DB_DATABASE=:memory: DB_URL= davor ausführen, z. B. DB_CONNECTION=sqlite DB_DATABASE=:memory: DB_URL= php artisan test.
  • Vorher prüfen, dass phpunit.xml dort SQLite :memory: mit force="true" setzt (siehe dev/git-deploy-monitoring/02-fehlerprotokoll-glitchtip.md, „Testdatenbank absichern“).
  • php artisan migrate in diesem Projekt erst nach php artisan migrate:status: Stehen unerwartet viele Migrationen aus, ist die Datenbank nicht die erwartete — anhalten und nachfragen.

Keine personenbezogenen Daten oder Schlüssel ins Repository

Datenbank-Dumps, Produktions-Logs, Postman-Collections, Adresslisten, .env-Inhalte und API-Schlüssel nie committen, auch nicht unter dev/ oder im Archiv. Am 12.05.2026 wurden zwei Produktiv-Dumps committet; Enttracken half nicht, erst die Historienbereinigung vom 09.10.2026 hat sie entfernt (alle Hashes neu, Force-Push, Server-Abgleich). Deshalb:

  • Vor jedem git add prüfen, ob neue Dateien solche Daten enthalten; im Zweifel nachfragen. Solche Arbeitsdateien gehören ins Scratchpad und werden nach Gebrauch gelöscht.
  • Ist es doch passiert: nicht nur löschen, sondern Betreiber informieren und nach dev/betrieb/git-deploy.md, Abschnitt G vorgehen (zuerst Schlüssel rotieren).
  • Die Historie nie ohne ausdrückliche Freigabe umschreiben oder force-pushen.