Kevin Adametz
1cd4d8e33a
Kriterien vom Auftraggeber (12.06.2026): Quelle der Aktiv-Erkennung ist
ausschliesslich das read-only Rechnungsarchiv legacy_invoices (D-12).
Legacy-Rechnungen bleiben Archiv; neue manuelle Rechnungen entstehen im
MAN-Rechnungskreis.
- Aktiv-Regel: juengste Rechnung pro (Portal, Legacy-Vereinbarung) mit
payment_option.type=recurring und user_payment_option.status=active;
next_due_date max. --grace-months (Default 12) ueberfaellig, sonst
stale -> bleibt reines Archiv. Einmal-Kaeufe werden nie uebernommen.
- Uebernahme als grandfathered in user_payment_options:
current_period_end = next_due_date, Betraege/Intervall der letzten
Legacy-Rechnung in legacy_conditions -> der taegliche MAN-Lauf
(billing:generate-manual-invoices) fakturiert zum gewohnten
jaehrlichen Rhythmus weiter. Versteckte Katalog-Platzhalter
LEGACY-{PE|BP}-{Artikel} in payment_options.
- Replay-faehig (D-18): Re-Runs aktualisieren anhand der Legacy-IDs in
legacy_conditions statt zu duplizieren — die Kern-Migration laeuft
kurz vor dem Relaunch erneut.
- Optionen: --dry-run, --as-of, --grace-months, --no-report; JSON-Report
nach storage/app/migration/. Dry-Run gegen Test-Snapshot: 22 aktive
jaehrliche Vereinbarungen, davon 4 sofort faellig, 0 stale.
- Doku: MIGRATION-STEPS.md (Runbook-Reihenfolge nach archive-invoices),
05-DATABASE-MERGE §5.6, 12-NAECHSTE-SCHRITTE 6.6, 08-PROGRESS,
PHASE-9-Plan + Checkliste.
Tests: GrandfatherLegacySubscriptionsTest (7, inkl. End-to-End
Migration -> MAN-Rechnung mit Legacy-Betraegen). Suite: 475 passed,
4 skipped. Pint clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
277 lines
16 KiB
Markdown
277 lines
16 KiB
Markdown
# 12 – Nächste Schritte (Roadmap)
|
||
|
||
**Stand:** 2026-05-04
|
||
**Quellen:** [`03-MIGRATION-PLAN.md`](./03-MIGRATION-PLAN.md), [`08-PROGRESS.md`](./08-PROGRESS.md), [`11-NOCH-ZU-TUN-OPTIMIERUNGEN.md`](./11-NOCH-ZU-TUN-OPTIMIERUNGEN.md), [`09-REVIEW-QUALITAET.md`](./09-REVIEW-QUALITAET.md)
|
||
|
||
Dieses Dokument bündelt **alles, was laut Entwicklungsplan noch offen ist**, in einer einzigen Übersicht – nach Priorität und Phase sortiert. Stand der Test-Suite: **180 Tests grün, 3 geskippt, 0 Fehler**.
|
||
|
||
**Legende:** 🔴 hoch · 🟡 mittel · 🟢 niedrig · ⏸️ vertagt · ⬜ offen · 🔄 in Arbeit
|
||
|
||
---
|
||
|
||
## 1. Schnell-Status
|
||
|
||
### Was ist fertig
|
||
- Phase 0 – Vorbereitung (bis auf Stripe-Daten vom Auftraggeber)
|
||
- Phase 1 – Fundament (Schema, Models, Factories, Seeder, Migrations grün)
|
||
- Phase 2 – Auth & Tenancy (Magic-Link, Portal-Scope, Portal-Switcher, Roll-Aware-Login-Redirect)
|
||
- Phase 3 – Admin-UI (Press Releases, Categories, Footer-Codes, Companies, Contacts, Users, Roles **alle real angebunden**)
|
||
- Phase 4 – Customer-Portal (jetzt als „Mein Bereich" unter `/admin/me/*` ins Admin-Panel konsolidiert)
|
||
- Phase 5 (teilweise) – PressReleaseService inkl. Reject-Reason + Audit-Log, BlacklistService, ImageService, HasUniqueSlug-Trait
|
||
- Phase 6 – Daten-Migration: Kern komplett (Users/Companies/Contacts/PMs/Bilder, idempotent, Bilder-Sync); **Legacy-Rechnungen brauchen einen Vollimport-Nachziehschritt**
|
||
- Phase 7 – API v1 vollständig (Endpunkte, Sanctum, Rate-Limit, OpenAPI, Tests, Legacy-Cut, Kundenreport)
|
||
|
||
### Was steht als Nächstes an
|
||
1. **Externe Abhängigkeit klären** (siehe §2): Stripe-Keys + Grandfathering-Kriterien vom Auftraggeber.
|
||
2. **Legacy-Rechnungen vollständig importieren** (siehe §8): DB-Struktur prüfen/erweitern, Import-Skript finalisieren, Status + User-Zuordnung erhalten, PDF-Erzeugung aus Legacy-Daten beim Abruf.
|
||
3. **PM-Veröffentlichung abrunden**: Inline-Edit durch Admin, Bulk-Aktionen, In-App-Notifications (Bell-Icon).
|
||
4. **Newsletter wieder aufnehmen** (P3.7 + P5.3 – aktuell vertagt).
|
||
5. **Phase 8 (Stripe-Billing)** als größter Brocken – sobald Stripe-Daten da sind.
|
||
6. **Phase 10 (Härtung) + 11 (Deployment)** – Security-Review, Coverage-Ziel, Staging-Rehearsal, DNS-Cutover.
|
||
|
||
---
|
||
|
||
## 2. Externe Blocker (Auftraggeber liefert)
|
||
|
||
Diese Punkte können wir nicht selbst anstoßen – ohne sie blockt P8 und teilweise P11.
|
||
|
||
| # | Aufgabe | Plan-Ref | Wirkung |
|
||
|---|---|---|---|
|
||
| ⬜ 0.5 | Stripe-Test-Account + API-Keys | 03-MP §0 | P8 komplett blockiert |
|
||
| ⬜ 0.6 | Liste der neuen Stripe-Produkte (Preisliste) | 03-MP §0 | P8.2 blockiert |
|
||
| ⬜ 0.7 | Liste der aktiven Alt-Abos (oder Kriterien) für Grandfathering | 03-MP §0 | P6.6 + P8.8 blockiert |
|
||
| ⬜ 11.4 | Finale Texte fürs Go-Live-Mailing (Passwort-Reset/Sicherheitshinweis) | 03-MP §11 | Versand am Go-Live blockiert; Command + Mailable selbst sind fertig |
|
||
| ⬜ 11.5 | Freigabeliste + operative Mailtexte für API-Kunden-Migration | 03-MP §11 | Versand blockiert; Kundenreport selbst ist fertig |
|
||
|
||
**Empfehlung:** Diese fünf Punkte als kompakte Mail/Liste an den Auftraggeber – ohne sie kann der Go-Live-Pfad nicht abgeschlossen werden.
|
||
|
||
---
|
||
|
||
## 3. Pressemitteilungs-Block: Nice-to-Have-Erweiterungen
|
||
|
||
Der Kern (Erstellen → Submit → Review → Publish/Reject mit Reason + Audit-Log) ist fertig. Diese Erweiterungen würden den Workflow noch runder machen:
|
||
|
||
| # | Aufgabe | Priorität | Aufwand |
|
||
|---|---|---|---|
|
||
| ⬜ pm-x1 | **Inline-Edit + „Speichern & Veröffentlichen"** auf einer Seite im Admin – heute zwei separate Schritte | 🟡 | 0.25 d |
|
||
| ⬜ pm-x2 | **Bulk-Aktionen im Admin-Index**: mehrere PMs auf einmal `Veröffentlichen`/`Ablehnen` (mit gemeinsamer Begründung) | 🟡 | 0.5 d |
|
||
| ⬜ pm-x3 | **In-App-Notifications** (Bell-Icon in der Sidebar) für Customer: „PM veröffentlicht/abgelehnt" – ergänzt heutige Mail | 🟡 | 0.5–1 d |
|
||
| ⬜ pm-x4 | **Permission-Granularität**: `press-releases:review` (lesen + freigeben) vs. `press-releases:publish` (final veröffentlichen) trennen, falls Editor nicht direkt veröffentlichen soll | 🟢 | 0.25 d |
|
||
|
||
---
|
||
|
||
## 4. Phase 1 – Restarbeiten
|
||
|
||
| # | Aufgabe | Priorität | Status |
|
||
|---|---|---|---|
|
||
| 1.8 | `DefaultAdminUserSeeder` + `SalutationTranslationSeeder` ergänzen | 🟢 | 🔄 |
|
||
| 1.10 | Zentrale Factory-Smoke-Suite (alle Factories erzeugen valide Models) | 🟢 | 🔄 |
|
||
|
||
---
|
||
|
||
## 5. Phase 3 – Admin-UI: Restarbeiten
|
||
|
||
| # | Bereich | Aufgabe | Priorität | Status |
|
||
|---|---|---|---|---|
|
||
| 3.7 | Newsletter | Subscriber-Liste + CSV Im-/Export | 🟡 | ⏸️ vertagt 2026-05-04 |
|
||
| 3.8 | Invoices (neu) | Liste, Detail, Stripe-Status, PDF-Download | 🔴 | ⬜ wartet auf P8 |
|
||
| 3.9 | Legacy-Invoices Admin | Admin-Spiegel zur Customer-Sicht finalisieren | 🟡 | ✅ Übersicht mit Filtern, Mapping-Hinweisen und PDF-Download umgesetzt; Navigation heißt **Legacy Rechnungen** |
|
||
| 3.10 | Payments | Liste + Detail | 🔴 | ⬜ wartet auf P8 |
|
||
|
||
---
|
||
|
||
## 6. Phase 4 – Customer-Portal: Restarbeiten
|
||
|
||
| # | Aufgabe | Priorität | Status |
|
||
|---|---|---|---|
|
||
| 4.2 | Customer-Dashboard: aktive Abos + offene neue Rechnungen | 🟡 | 🔄 wartet auf P8 |
|
||
| 4.4 | Neue Rechnungen einsehen & PDF-Download | 🔴 | 🔄 wartet auf P8 |
|
||
|
||
---
|
||
|
||
## 7. Phase 5 – Domain-Services: Restarbeiten
|
||
|
||
| # | Aufgabe | Priorität | Status |
|
||
|---|---|---|---|
|
||
| 5.3 | `NewsletterService` neu (Subscribe / Confirm / Unsubscribe mit Token) | 🟡 | ⏸️ vertagt 2026-05-04 |
|
||
| 5.4 | `CompanyService` (Aktivierung, Logo-Upload, Footer-Code-Management) | 🟡 | ⬜ |
|
||
| 5.7 | Domain-Events + Listeners (`PressReleasePublished` → `SendPublishNotification` etc.) | 🟢 | 🔄 nur Mailables, keine echten Events |
|
||
| 5.8 | Vollständige Service-Test-Suite (Coverage > 70 %) | 🟡 | 🔄 |
|
||
|
||
> **Hinweis:** `ImageService` (5.5) hat noch einen offenen Restpunkt: **Legacy-Thumbnail-Redirect** – kein Blocker, aber nice für SEO-Kontinuität alter Bild-URLs.
|
||
|
||
---
|
||
|
||
## 8. Phase 6 – Daten-Migration: Restarbeiten
|
||
|
||
| # | Aufgabe | Priorität | Status |
|
||
|---|---|---|---|
|
||
| 6.5d | **Legacy-Rechnungen Vollimport**: alle bestehenden Rechnungen aus den Legacy-DBs inkl. Status, Beträgen, Datum, Zahlart, vollständigem Raw-Snapshot und User-Zuordnung importieren; `legacy:archive-invoices` schreibt Import-Report + PDF-Payload; PDF-Erzeugung bleibt DB-basiert/on-demand statt Datei-Migration | 🔴 | ✅ umgesetzt 2026-05-04; Rehearsal gegen Produktiv-Snapshot bleibt P6.10 |
|
||
| 6.6 | `legacy:grandfather-subscriptions` (aktive Alt-Abos übernehmen) | 🔴 | ✅ umgesetzt 2026-06-12 (Kriterien vom Auftraggeber: Quelle ist das Rechnungsarchiv — jüngste Rechnung pro Vereinbarung mit `recurring` + `active`; Übernahme als `grandfathered` mit `current_period_end = next_due_date`, MAN-Kreis fakturiert weiter; Replay-fähig, Rehearsal bleibt P6.10) |
|
||
| 6.10 | **Rehearsal-Lauf** gegen produktiven Snapshot auf Staging | 🔴 | ⬜ |
|
||
|
||
**Wichtig für 6.5d:** `legacy:archive-invoices` importiert jetzt Rechnungsdaten, Billing-Adress-Snapshot und User-Payment-Snapshot in `legacy_invoices.raw_snapshot`/`pdf_payload`, zählt unzugeordnete Legacy-User im Report und lässt diese Rechnungen trotzdem im Archiv. Für Legacy-Rechnungen bleibt die bestehende Logik erhalten: Rechnung liegt als Datenbankdatensatz vor und das PDF wird bei Bedarf auf Knopfdruck aus diesen Daten erzeugt. Neue Stripe-Rechnungen werden separat in P8 geplant. Der finale Nachweis der Vollständigkeit erfolgt weiterhin im Staging-Rehearsal mit aktuellem Produktiv-Snapshot.
|
||
|
||
---
|
||
|
||
## 9. Phase 8 – Stripe-Billing (komplett offen, größter Brocken)
|
||
|
||
Hängt komplett an §2 (Stripe-Account + Produktliste).
|
||
|
||
| # | Aufgabe | Priorität | Aufwand |
|
||
|---|---|---|---|
|
||
| 8.1 | Stripe-Setup (`.env`, Cashier vs. raw `stripe-php`) | 🔴 | 0.25 d |
|
||
| 8.2 | `PaymentOption`-Admin + Sync zu Stripe Products/Prices (`stripe:sync-products`) | 🔴 | 0.5 d |
|
||
| 8.3 | Checkout-Flow im Customer-Portal (Stripe Checkout Session + Rückkehr-URL) | 🔴 | 0.5 d |
|
||
| 8.4 | Webhook-Controller `/webhooks/stripe` + Event-Handler (checkout-session-completed, invoice-paid, invoice-payment-failed, subscription-deleted) | 🔴 | 0.5 d |
|
||
| 8.5 | `InvoiceNumberGenerator` (`{YYYY}{MM}-{seq}`) | 🟡 | 0.25 d |
|
||
| 8.6 | PDF-Blade + `InvoiceService` | 🟡 | 0.25 d |
|
||
| 8.7 | Mahnwesen vereinfacht (`invoices:remind` für Stripe-Fails) | 🟡 | 0.25 d |
|
||
| 8.8 | **Grandfathering-Handler** (`ExpireGrandfatheredSubscriptions`-Scheduler + Customer-Mail) | 🔴 | 0.25 d |
|
||
| 8.9 | Legacy-Rechnungen Archiv-UI im Admin finalisieren + DB-basierte Legacy-PDF-Erzeugung absichern | 🟡 | ✅ |
|
||
| 8.10 | Tests mit Stripe-Test-Mode (Fake-Webhooks) | 🔴 | 0.25 d |
|
||
|
||
**Gesamt P8:** ~2.5–3 Manntage netto, sobald Stripe-Daten vorliegen.
|
||
|
||
---
|
||
|
||
## 10. Phase 9 – Scheduler & Queues
|
||
|
||
| # | Aufgabe | Priorität | Status |
|
||
|---|---|---|---|
|
||
| 9.1 | Supervisor/Queue-Worker-Setup dokumentieren (Dev + Prod) | 🟡 | ⬜ |
|
||
| 9.2 | Cron-Jobs für `invoices:remind`, `grandfather:expire`, `newsletter:campaign-digest` (optional) ergänzen | 🟡 | 🔄 (`magic-links:purge` + `press-releases:purge-drafts` da, P8/P5-Jobs fehlen) |
|
||
| 9.3 | Failure-Alerting (Log-Channel + Mail bei fehlgeschlagenen Jobs) | 🟡 | ⬜ |
|
||
|
||
---
|
||
|
||
## 11. Phase 10 – Testing & Härtung
|
||
|
||
| # | Aufgabe | Priorität | Status |
|
||
|---|---|---|---|
|
||
| 10.1 | Coverage-Ziel **70 %** auf `app/Services` und `app/Actions` | 🔴 | ⬜ |
|
||
| 10.2 | Architecture-Tests (Pest `arch()`) – z. B. „kein Volt-Volt darf direkt `Mail::send` aufrufen" | 🟡 | ⬜ |
|
||
| 10.3 | `php artisan test --parallel` grün | 🟡 | ⬜ |
|
||
| 10.4 | Manuelle QA-Checkliste durchgehen (siehe `06-FEATURES-SCOPE.md §15`) | 🔴 | ⬜ |
|
||
| 10.5 | **Security-Review**: CSRF, CORS, Rate-Limits, File-Uploads, Magic-Link-TTL | 🔴 | ⬜ |
|
||
|
||
---
|
||
|
||
## 12. Phase 11 – Deployment
|
||
|
||
| # | Aufgabe | Priorität | Status |
|
||
|---|---|---|---|
|
||
| 11.1 | Produktiv-DB-Server provisionieren + Backups konfigurieren | 🔴 | ⬜ |
|
||
| 11.2 | Staging-Deployment + Smoke-Tests | 🔴 | ⬜ |
|
||
| 11.3 | Produktiv-Import-**Rehearsal** gegen aktuellen Legacy-Snapshot | 🔴 | ⬜ |
|
||
| 11.4 | Go-Live-Mailing (Passwort-Reset + Sicherheitshinweis) versenden | 🔴 | 🔄 (Code fertig, Texte/Versand offen) |
|
||
| 11.5 | API-Kunden-Kommunikation (Token-Migration) versenden | 🔴 | 🔄 (Report fertig, Texte/Versand offen) |
|
||
| 11.6 | DNS-Cutover-Plan: `pressekonto.de` auf neuen Server | 🔴 | ⬜ |
|
||
| 11.7 | Read-Only-Modus auf Legacy-Systemen während Final-Import | 🔴 | ⬜ |
|
||
| 11.8 | Abschalten der alten Symfony-Server (nach Review-Periode) | 🟡 | ⬜ |
|
||
|
||
---
|
||
|
||
## 13. Performance-Optimierungen (aus 11-NOCH-ZU-TUN)
|
||
|
||
Nicht zwingend für Go-Live nötig, aber fürs Polishing:
|
||
|
||
| # | Aufgabe | Priorität | Quelle |
|
||
|---|---|---|---|
|
||
| ⬜ opt-1 | Slow-Admin-Reports mit echten Daten füllen + auswerten | 🔴 | 11-NOCH §1 |
|
||
| ⬜ opt-2 | EXPLAIN auf Top-Slow-Queries laufen lassen, Indexe nachziehen | 🔴 | 11-NOCH §2 |
|
||
| ⬜ opt-3 | `admin.users.edit` aufteilen (Profil-Partial → BillingAddress-Partial → Volt-Komponente `company-links` → Volt-Komponente `contact-links`) | 🟡 | 11-NOCH §3.1 |
|
||
| ⬜ opt-4 | `admin.companies.show` – Kontakte-Tab als eigene Volt-Komponente isolieren | 🟡 | 11-NOCH §4 |
|
||
| ⬜ opt-5 | Listen weiter splitten (nur bei messbarer Langsamkeit, nicht prophylaktisch) | 🟢 | 11-NOCH §5 |
|
||
| ⬜ opt-6 | Billing-Dummy-Views durch echte Implementierung ersetzen | 🔴 | 11-NOCH §6 (= P3.8/3.10/3.11 in P8) |
|
||
| ⬜ opt-7 | Rollen-Index nur bei Bedarf optimieren (Pagination/Cache) | 🟢 | 11-NOCH §7 |
|
||
| ⬜ opt-8 | Slow-Requests zusätzlich in DB persistieren (Trends über Releases) | 🟢 | 11-NOCH §8 |
|
||
| ⬜ opt-9 | Report-UI erweitern (CSV-Export, Zeitraum-Schnellfilter, Vergleichsmodi) | 🟢 | 11-NOCH §9 |
|
||
|
||
---
|
||
|
||
## 14. Restpunkte aus dem Qualitätsreview (09-REVIEW)
|
||
|
||
Die kritischen Punkte aus §2 sind durchgängig behoben. Aus §3/§4 stehen noch aus:
|
||
|
||
| # | Aufgabe | Priorität | Quelle |
|
||
|---|---|---|---|
|
||
| ⬜ rev-1 | `gdpr_consent_at` im Registrierungsflow befüllen | 🔴 | 09-REVIEW §3 / §4.6 |
|
||
| ⬜ rev-2 | `UserManagementTest.php` (820 Zeilen) in `tests/Feature/Admin/UserCrudTest.php`, `CompanyCrudTest.php`, `ContactCrudTest.php`, `FilterPresetTest.php` aufteilen | 🟡 | 09-REVIEW §3.5 |
|
||
| ⬜ rev-3 | `session()->flash()` in inline Volt-Aktionen (ohne Redirect) durch `$this->dispatch('notify', ...)` ersetzen | 🟡 | 09-REVIEW §3.6 |
|
||
| ⬜ rev-4 | `04-DATA-MODEL.md` um `contact_user`-Pivot ergänzen (Doku-Lücke) | 🟢 | 09-REVIEW §3.4 |
|
||
| ⬜ rev-5 | Drei `user_filter_presets`-Migrations zu einer zusammenführen (Hygiene vor Go-Live) | 🟢 | 09-REVIEW §3.2 |
|
||
| ⬜ rev-6 | ENUM → VARCHAR mit Enum-Cast prüfen, falls beim Rehearsal Lock-Probleme auf großen Tabellen auftreten | 🟢 | 09-REVIEW §3.7 |
|
||
|
||
---
|
||
|
||
## 15. Empfohlene Reihenfolge der nächsten Sessions
|
||
|
||
Folgende Tranchen-Reihenfolge priorisiert das Erreichen der Produktionsreife:
|
||
|
||
### Tranche A – Legacy-Rechnungen Vollimport ✅ erledigt 2026-05-04
|
||
1. P6.5d Source-Audit: Legacy-Rechnungstabellen, Statuswerte, benötigte PDF-Daten und User-Mapping geprüft
|
||
2. `legacy:archive-invoices` zu vollständigem, idempotentem Import-/Report-Skript ausgebaut
|
||
3. DB-Vorbereitung mit `pdf_payload` + `pdf_generated_at` nachgezogen
|
||
4. Customer-PDF-Abruf auf DB-basierte Legacy-PDF-Erzeugung abgesichert
|
||
|
||
### Tranche B – PM-Block abrunden (~1 Tag, sofort möglich)
|
||
5. `pm-x1` Inline-Edit + „Speichern & Veröffentlichen" im Admin
|
||
6. `pm-x2` Bulk-Aktionen im Admin-Index
|
||
7. `pm-x3` In-App-Notifications (Bell-Icon)
|
||
8. `rev-1` `gdpr_consent_at` im Registrierungsflow (DSGVO)
|
||
|
||
### Tranche C – Newsletter-Wiederaufnahme (~1 Tag)
|
||
9. P5.3 `NewsletterService` (Subscribe/Confirm/Unsubscribe mit Token)
|
||
10. P3.7 Admin-Newsletter-UI (Subscriber-Liste + CSV)
|
||
|
||
### Tranche D – Service-Härtung & Test-Coverage (~1 Tag)
|
||
11. P5.4 `CompanyService`
|
||
12. P5.7 Domain-Events einführen
|
||
13. P10.1 Coverage auf 70 % heben
|
||
14. P10.2 `arch()`-Tests
|
||
|
||
### Tranche E – Performance-Polishing (~0.5 Tage, optional)
|
||
15. `opt-1` + `opt-2` Echte Slow-Reports auswerten + EXPLAIN
|
||
16. `opt-3` `admin.users.edit` aufteilen
|
||
|
||
### Tranche F – Wartet auf Auftraggeber: P8 Stripe (~2.5–3 Tage)
|
||
17. Sobald Stripe-Daten vorliegen: P8 komplett (8.1 – 8.10)
|
||
18. P3.8 + P3.10 (Invoices/Payments-Admin echt anbinden)
|
||
19. P4.2 + P4.4 (Customer-Dashboard + neue Rechnungen)
|
||
|
||
### Tranche G – Phase 9 + 10 + 11 (~2–3 Tage)
|
||
20. P9.1 – 9.3 Queue/Scheduler/Alerting
|
||
21. P10.4 + 10.5 QA-Checkliste + Security-Review
|
||
22. P11.1 – 11.3 Staging-Deployment + Rehearsal
|
||
23. P11.4 + 11.5 Mailings versenden
|
||
24. P11.6 – 11.8 DNS-Cutover + Legacy-Read-Only + Abschaltung
|
||
|
||
---
|
||
|
||
## 16. Aufwandsschätzung Rest
|
||
|
||
| Block | Aufwand | Abhängigkeiten |
|
||
|---|---|---|
|
||
| Tranche A (Legacy-Rechnungen Vollimport) | ✅ erledigt | Produktiv-Snapshot-Rehearsal bleibt P6.10 |
|
||
| Tranche B (PM-Polishing) | ~1 d | – |
|
||
| Tranche C (Newsletter) | ~1 d | – |
|
||
| Tranche D (Service-Härtung) | ~1 d | – |
|
||
| Tranche E (Performance) | ~0.5 d | – |
|
||
| Tranche F (Stripe + Billing) | ~3 d | Stripe-Daten ⬜ |
|
||
| Tranche G (Deployment) | ~2.5 d | Tranche F + Auftraggeber-Texte |
|
||
| **Σ Restaufwand** | **~9.5–10 Manntage** | – |
|
||
|
||
Der Endspurt zum Go-Live (Tranche F + G) ist davon ~5.5 Tage und hängt komplett am Auftraggeber-Input.
|
||
|
||
---
|
||
|
||
## 17. Zusammenfassung: Was kann **heute** ohne externen Input passieren?
|
||
|
||
- Tranche B (PM-Polishing) – 1 Tag
|
||
- Tranche C (Newsletter) – 1 Tag
|
||
- Tranche D (Service-Härtung & Tests) – 1 Tag
|
||
- Tranche E (Performance-Polishing) – 0.5 Tage
|
||
- Restpunkte aus §14 (Quality-Review-Cleanup) – 0.5 Tage
|
||
|
||
= **~4 Manntage produktive Arbeit**, bevor wir auf Stripe-/Go-Live-Daten vom Auftraggeber warten müssen.
|