Am 07.10.2026 hat das RefreshDatabase eines frischen Demo-Projekts (Test der Vorlagen aus dev/git-deploy-monitoring) die lokale Datenbank `pressekonto` auf global-mysql vollständig geleert (Binärlog binlog.000009, Pos. 566161486). Ursache: docker-compose.yml setzte DB_* als Container-Umgebungsvariablen, die in Laravel Vorrang vor jeder .env haben; die phpunit.xml des Demo-Projekts erzwang kein SQLite. Die eigene Suite war nicht beteiligt (force="true" und Guard in tests/TestCase.php greifen; Gegenprobe mit MySQL-Variablen grün). - docker-compose.yml: DB_* entfernt (Werte identisch in .env), wirksam nach Neuerstellen des Containers. - Baukasten: „Testdatenbank absichern" (phpunit.xml mit force, Guard, Gegenprobe) als Pflicht vor RefreshDatabase. - .ai/rules/general.md und CLAUDE.md: fremde/frische Laravel-Projekte nur mit SQLite :memory: testen; migrate hier erst nach migrate:status. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| 2026-09-01 | ||
| 2026-09-11-audit | ||
| archive | ||
| betrieb | ||
| git-deploy-monitoring | ||
| glitch-tip | ||
| lagacy-rechnungen | ||
| README.md | ||
| roadmap.md | ||
dev/ — Projekt- und Betriebsdokumentation
Stand: 29.09.2026 — das System ist live (pressekonto.com, presseecho.de, businessportal24.com). Die Struktur trennt aktive Betriebs-/Planungsdoku von abgeschlossenen Phasen (Archiv).
Aktiv
| Pfad | Inhalt |
|---|---|
betrieb/deploy-runbook.md |
Deploy- und Betriebs-Runbook (SFTP-Deploy-Checkliste, Worker, Scheduler, Stripe-Webhook, Rollback) — erste Anlaufstelle für alles Operative |
betrieb/api-legacy-paritaet.md |
Verhaltens-Referenz der Legacy-API-Kompatibilitätsschicht (/service/…) — lebendes Dokument, solange Alt-Integrationen (Connektar) die Pfade nutzen |
betrieb/umami.md |
Umami-Analytics-Snippets je Domain |
2026-09-01/ |
Aktuelle Roadmap (roadmap-2026.md + Anhänge 1 und 2), Basiswerte Block 0, Umsetzungsprotokoll Teil 1–11 |
2026-09-11-audit/ |
Audits und Entwicklungsplan (ENTWICKLUNGSPLAN.md, Blöcke 1–9), Umsetzungsaudits 18.09./25.09./29.09., Bildkennzeichnung (Plan Fassung 2, Decision-Update) — der jüngste Umsetzungsaudit ist der Einstieg in den aktuellen Stand |
roadmap.md |
Nachlauf Go-Live (Stand 20.07.) und Ideen-Backlog — die laufende Planung steht in 2026-09-01/ |
Lokal / gitignored (bleiben liegen, nicht committen)
| Pfad | Inhalt |
|---|---|
migration/ |
Medien-Staging der Legacy-Migration (~7 GB Uploads beider Altportale) — Quelle für legacy:migrate-media; behalten, bis das Alt-System endgültig abgeschaltet und ein Server-Backup gezogen ist |
api/ |
Postman-Collection (enthält API-Keys!) und Activity-Log-Auswertungen der Alt-APIs |
archive/migration-2026/sql/ |
Legacy-DB-Dumps (Snapshots vom 23.04.2026) |
Archiv (archive/)
Abgeschlossene Phasen, als Historie/Referenz erhalten:
optimize/— System-Optimierungsphasen 0–6 und das Cutover-Runbook der Legacy-Migration (erledigt 20.07.2026; enthält weiterhin die Anleitung für--since-Delta-Läufe, falls das Alt-System noch einmal Daten liefert)release/— Release-Entwicklungsplan, manuelle QA-Checkliste, Boost-Platzierungs-Entscheidungmigration-2026/— Analyse- und Planungsdoku der Legacy-Migration (Datenmodell, Merge-Strategie, API-Kunden, Fortschritt)frontend/+frontend-audits/— Frontend-Konzepte und die Responsive-/Mobile-Audits vom 16.07.agentur-attribution/,legacy_logging/,legacy_performance/,_old/— ältere Einzelthemen bzw. Altsystem-Reste