gitmedia/presseportale
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2
presseportale/dev
History
Kevin Adametz 2aebb9d27e companies: Zusammenführung im Bestand, rückabwickelbar (Roadmap 1a.3) 
companies:merge führt Firmen mit derselben Firmen-E-Mail zu einem Newsroom
zusammen — nur über Adressen, die 1a.2 als Dublette oder Namensvariante
klassifiziert hat. Es bleibt die Firma mit den meisten jemals
veröffentlichten Meldungen; Meldungen, Kontakte, Nutzer- und
Zahlungsverknüpfungen wandern per company_id, jede Bewegung steht in
company_merge_moves. companies:unmerge spielt sie rückwärts ab.

77 % der Gruppen sind dieselbe Firma auf beiden Portalen (Altsystem: eine
Firma je Portal). Der Überlebende wird dann `both`; die Meldungen behalten
ihr Portal. Der alte Newsroom-Slug führt per 301 zum Überlebenden.
Slug-Kollisionen auf dem anderen Portal werden übersprungen, nicht
umbenannt. Company::slugExists() kennt jetzt `both`.

Dev-DB: 14 142 Adressen, 16 194 Firmen, 13 297 Meldungen in 2 min;
Rückabwicklung in 1:15 min exakt auf den Stand davor.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-15 08:43:46 +00:00
..
2026-09-01 companies: Zusammenführung im Bestand, rückabwickelbar (Roadmap 1a.3) 2026-09-15 08:43:46 +00:00
archive docs: dev-Doku für den Live-Betrieb neu sortiert — Archiv + Betrieb + Roadmap 2026-07-21 07:52:38 +00:00
betrieb docs: verschobene Doku-Pfade in Code-Kommentaren nachgezogen 2026-07-21 07:53:08 +00:00
README.md docs: dev-Doku für den Live-Betrieb neu sortiert — Archiv + Betrieb + Roadmap 2026-07-21 07:52:38 +00:00
roadmap.md docs: R6.5 in der Roadmap abgehakt (Merge nach main + Tag v1.0.0) 2026-07-21 07:58:20 +00:00

README.md

dev/ — Projekt- und Betriebsdokumentation

Stand: 20.07.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
roadmap.md Offene Punkte und nächste Entwicklungen/Optimierungen

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-Entscheidung
  • migration-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