Implementation Plan

Goal

Einen vollständigen Forschungsfragen- und Kandidatenplan für L2-G erstellen, der neue förderfähige AP-Kandidaten aus interner Dokumentation/Architektur identifiziert und als priorisierten Input für L2-A, L2-D/E/F und den AP-Katalog nutzbar macht.

Gemeinsamer Ergebnis- und Run-Contract

• Kanonischer Ergebnisordner: docs/1-projects/bsfz-funding/funding-drilldown-L2-results/.
• Primäres Ergebnis dieses Drilldowns: docs/1-projects/bsfz-funding/funding-drilldown-L2-results/L2-G-result.md.
• Hauptdokument-Edits nur ausführen, wenn der jeweilige L2-Scope sie explizit erlaubt; sonst konkrete Patch-/Textvorschläge im Ergebnisdokument festhalten.
• Reihenfolge/Gates: G → A → B → D/E/F → C → H. Abweichungen müssen im Ergebnis als Annahme oder Blocker markiert werden.

Tasks

1. Quellenlage und Pfadkorrekturen sichern: Die in funding-drilldown-L2-G.md genannten historischen Pfade auf die tatsächliche PARA-Struktur mappen und eine Scan-Checkliste anlegen.

   • File: docs/1-projects/bsfz-funding/funding-drilldown-L1.md
   • File: docs/1-projects/bsfz-funding/funding-drilldown-L2-G.md
   • File: docs/2-areas/architecture/*.md
   • File: docs/3-resources/protocols/*.md
   • File: docs/3-resources/schemas/*.md
   • File: docs/3-resources/decisions/*.md
   • File: docs/2-areas/product/PRODUCT_domain-model.md
   • File: docs/2-areas/product/PRODUCT_differentiators-10-percent.md
   • File: docs/2-areas/strategy/STRATEGY_platform-vision.md
   • File: docs/2-areas/strategy/STRATEGY_feature-subsets.md
   • File: docs/4-archive/STRATEGY_future-ideas.md
   • File: docs/2-areas/strategy/STRATEGIC_BLIND_SPOTS.md
   • File: apps/api/docs/*.md
   • Changes: Keine fachlichen Edits; Arbeitsnotiz/Inventar mit tatsächlichen Pfaden, fehlenden/abweichenden Quellgruppen und Scan-Status erstellen.
   • Acceptance: Jede L2-G-Quellgruppe ist entweder mit tatsächlichen Dateien abgedeckt oder als Pfad-/Umfangsabweichung dokumentiert; insbesondere docs/architecture/, docs/protocols/, docs/schemas/, docs/supporting/architectural-decision-record/ werden auf docs/2-areas/... bzw. docs/3-resources/... gemappt.

2. Bestehenden AP-Katalog als Negativ-/Abgleichsbasis extrahieren: Alle bestehenden APs, Belege, Vorhaben-Zuordnungen, Risikohinweise und Stundenschätzungen erfassen, damit neue Kandidaten nicht doppelt gezählt werden.

   • File: docs/1-projects/bsfz-funding/funding-work-packages.md
   • File: docs/1-projects/bsfz-funding/STRATEGY_public-funding.md
   • File: docs/1-projects/bsfz-funding/bsfz-antrag-vorhaben.md
   • File: docs/1-projects/bsfz-funding/bsfz-ablehnungsrisiken.md
   • Changes: AP-Abdeckungstabelle vorbereiten mit Spalten: AP, Kurzthema, Vorhaben, Belege, bereits abgedeckte Forschungsfrage, nicht erneut als neuer AP werten.
   • Acceptance: Jeder spätere Kandidat kann explizit gegen AP1–AP26 abgegrenzt werden; verwandte Kandidaten werden als „neuer AP“, „Scope-Erweiterung“, oder „Zusatzbeleg für bestehenden AP“ klassifiziert.

3. ADR-Themen-Scan erstellen: Alle ADR-Dateien systematisch nach technischen Unsicherheiten und Forschungsfragen klassifizieren.

   • File: docs/3-resources/decisions/adr-001-boarding-point-strategy.md
   • File: docs/3-resources/decisions/adr-002-financial-ledger-strategy.md
   • File: docs/3-resources/decisions/adr-003-tenant-provisioning.md
   • File: docs/3-resources/decisions/adr-005-multi-tenant-jwt-session.md
   • File: docs/3-resources/decisions/adr-007-crew-fleet-subcontracting-strategy.md
   • File: docs/3-resources/decisions/adr-008-vehicle-maintenance-ownership.md
   • File: docs/3-resources/decisions/adr-010-input-output-vo-separation.md
   • File: docs/3-resources/decisions/adr-011-input-rule-snapshotting.md
   • File: docs/3-resources/decisions/adr-014-ticket-issuance-trigger.md
   • File: docs/3-resources/decisions/adr-018-serviceleg-creation-ownership.md
   • File: docs/3-resources/decisions/adr-022-ubicloud-postgres-cutover.md
   • File: docs/3-resources/decisions/adr-023-swarm-quorum-topology.md
   • File: docs/3-resources/decisions/adr-024-swarm-lb-strategy.md
   • File: docs/3-resources/decisions/adr-025-swarm-manager-failover-dns.md
   • File: docs/3-resources/decisions/adr-027-cardinality-budget-contract.md
   • File: docs/3-resources/decisions/adr-028-gdpr-ttl-retention.md
   • File: docs/3-resources/decisions/adr-029-secrets-and-encryption.md
   • File: docs/3-resources/decisions/adr-030-subscription-tier-gating.md
   • File: docs/3-resources/decisions/adr-031-immutable-infrastructure-policy.md
   • Changes: Tabelle mit allen ADR-Themen erstellen: ADR, Thema, Forschungsfrage, technische Unsicherheit.
   • Acceptance: Alle vorhandenen ADR-Themen sind erfasst; Forschungsfragen werden explizit extrahiert.

4. Blind-Spot-Mining durchführen: SB-1 bis SB-14 auf Forschungsfragen und technisches Potenzial prüfen.

   • File: docs/2-areas/strategy/STRATEGIC_BLIND_SPOTS.md
   • File: docs/3-resources/schemas/schema-operations.md
   • File: docs/3-resources/protocols/offline-sync-protocol.md
   • File: docs/3-resources/protocols/incident-broadcast-protocol.md
   • File: docs/2-areas/architecture/observability.md
   • Changes: Blind-Spot-Tabelle erstellen mit SB, Status, F&E-Potenzial, Go/No-Go, technische Unsicherheit.
   • Acceptance: Alle 14 Blind Spots sind klassifiziert; technische Unsicherheiten sind dokumentiert.

5. Architektur-Mining durchführen: Architekturdateien nach dokumentierten technischen Unwägbarkeiten und forschungsnahen Querschnittsproblemen durchsuchen.

   • File: docs/2-areas/architecture/ai.md
   • File: docs/2-areas/architecture/database.md
   • File: docs/2-areas/architecture/frontend.md
   • File: docs/2-areas/architecture/gdpr-strategy.md
   • File: docs/2-areas/architecture/infrastructure.md
   • File: docs/2-areas/architecture/observability.md
   • File: docs/2-areas/architecture/realtime-strategy.md
   • File: docs/2-areas/architecture/validation-strategy.md
   • File: docs/2-areas/architecture/workflow-orchestration.md
   • Changes: Kandidatenliste mit Schwerpunkt Realtime, Workflow-Orchestration, Observability, Edge/Offline, Multi-Tenant-Isolation, AI/RAG und Datenschutz-Infrastruktur ergänzen.
   • Acceptance: Jede Architekturdatei ist nach Forschungspotenzial bewertet; Infrastruktur-Forschung wird streng gegen Standard-DevOps abgegrenzt.

6. Protokoll- und Event-Mining durchführen: Protokollspezifikationen auf Unsicherheiten und nicht abgedeckte Forschungsfragen prüfen.

   • File: docs/3-resources/protocols/*.md
   • File: docs/3-resources/events/event-catalog.md
   • File: docs/3-resources/events/event-contracts-backoffice.md
   • File: docs/3-resources/events/event-contracts-commerce.md
   • File: docs/3-resources/events/event-contracts-operations.md
   • File: docs/3-resources/events/event-contracts-pricing.md
   • Changes: Protokoll-Abdeckungstabelle erstellen mit Protokoll/Eventgruppe, unmapped Forschungsfrage, Go/No-Go.
   • Acceptance: Jeder relevante Protokollfund wird als Forschungsfrage formuliert; reine Prozess-/CRUD-Themen werden ausgeschlossen.

7. Domain-Model- und Schema-Lücken prüfen: Entity-Definitionen gegen AP-Katalog und Vorhabenstruktur abgleichen, um unmapped Domain-Logik zu finden.

   • File: docs/2-areas/product/PRODUCT_domain-model.md
   • File: docs/3-resources/schemas/schema-backoffice.md
   • File: docs/3-resources/schemas/schema-commerce.md
   • File: docs/3-resources/schemas/schema-communications.md
   • File: docs/3-resources/schemas/schema-operations.md
   • Changes: Entity-Mapping mit Entity/Capability, Bestands-AP, mögliche Forschungsfrage, nur Domänenmodell?, Code-/Schema-Beleg, Entscheidung erstellen.
   • Acceptance: Kandidaten, die nur auf Domain-Model-Erwähnung ohne technische Unwägbarkeit beruhen, werden nicht als eigenständige APs empfohlen; Schema-Belege werden als Mindestanforderung markiert.

8. Produkt-/Strategie-Artefakte intern auswerten und L2-H sauber abgrenzen: Strategische und Produktdokumente nur auf bereits intern dokumentierte technische Artefakte prüfen, keine marktbasierte externe Chancenanalyse durchführen.

   • File: docs/2-areas/product/PRODUCT_differentiators-10-percent.md
   • File: docs/2-areas/strategy/STRATEGY_platform-vision.md
   • File: docs/2-areas/strategy/STRATEGY_feature-subsets.md
   • File: docs/4-archive/STRATEGY_future-ideas.md
   • Changes: Liste intern belegte Kandidaten vs. nur Markt-/Zukunftsidee → L2-H erstellen.
   • Acceptance: Keine L2-H-Arbeit wird vorweggenommen; jede übernommene Idee verweist auf ein internes Artefakt oder wird als Jahr-2+/L2-H-Chance statt L2-G-Kandidat markiert.

9. API-Dokumentation auswerten: Die API-Dokumente auf neue Forschungsfragen oder Kandidaten prüfen.

   • File: apps/api/docs/tax-engine.md
   • File: apps/api/docs/datev-integration.md
   • File: apps/api/docs/period-lock.md
   • File: apps/api/docs/storno-workflow.md
   • Changes: Liste ergänzen; tax-engine.md, datev-integration.md, period-lock.md und storno-workflow.md auf technische Komplexität prüfen.
   • Acceptance: Jedes API-Dokument ist nach Forschungspotenzial klassifiziert.

10. Frascati-Schnelltest pro Kandidat anwenden: Jeden potenziellen Kandidaten mit dem dreistufigen Test aus L2-G prüfen.

• File: docs/1-projects/bsfz-funding/funding-drilldown-L2-G.md
• Changes: Pro Kandidat eine Mini-Scorecard erstellen: Wie-nicht-Was, Unwägbarkeit, Abgrenzung Standard-Engineering, Go/No-Go.
• Acceptance: Kein Kandidat ohne belegte Unwägbarkeit wird als neuer AP empfohlen; Standard-Engineering wird konservativ ausgeschlossen.

11. Neue AP-Kandidaten im AP-Katalog-Format formulieren: Für jeden Go-Kandidaten eine umsetzbare Rohfassung nach Muster von funding-work-packages.md erstellen.

• File: docs/1-projects/bsfz-funding/funding-work-packages.md
• Changes: Entwurf für Abschnitt ## Neue L2-G-Kandidaten vorbereiten mit: AP-Nummer/Arbeitstitel, Status, Forschungsfrage, Neuartigkeit, Stundenaufwand, F&E-/Standard-Split, Vorhaben-Zuordnung, Risikobewertung, Argumentationsmuster, Empfehlung Jahr 1/Jahr 2+/verwerfen.
• Acceptance: Jeder neue Kandidat hat mindestens eine konkrete Forschungsfrage und eine konservative Stundenschätzung; Themen werden nicht dupliziert.

12. Vorhaben-Zuordnung und Input für L2-A erzeugen: Kandidaten so zusammenfassen, dass L2-A die Clustering-Frage direkt verwenden kann.

• File: docs/1-projects/bsfz-funding/STRATEGY_public-funding.md
• File: docs/1-projects/bsfz-funding/bsfz-antrag-vorhaben.md
• File: docs/1-projects/bsfz-funding/funding-work-packages.md
• Changes: Matrix vorbereiten: Kandidat, empfohlenes Vorhaben 1–4, Alternative/fünftes Vorhaben?, Clustering-Auswirkung, Stunden, Risiko, Jahr-1-Empfehlung.
• Changes: Pflichtsektion ## Input für L2-A in L2-G-result.md anlegen mit neuer Kandidatenliste, Frascati-Schnelltest, Stunden-/Scope-Auswirkung und Clustering-Implikationen.
• Acceptance: L2-A kann anhand dieser Matrix entscheiden, ob 4 Vorhaben ausreichen, ob Vorhaben 2 zu breit wird oder ob ein fünftes Vorhaben plausibel ist.

13. Risikobewertung und Argumentationsmuster zuordnen: Neue Kandidaten gegen die bestehenden Argumentationsmuster in bsfz-ablehnungsrisiken.md mappen und notwendige neue Muster markieren.

• File: docs/1-projects/bsfz-funding/bsfz-ablehnungsrisiken.md
• File: docs/1-projects/bsfz-funding/funding-work-packages.md
• Changes: Pro Kandidat Risiko niedrig/mittel/hoch, Ablehnungsgrund, Gegenargument, Muster A/B/C/D oder neues Muster vorbereiten.
• Acceptance: Jeder empfohlene Kandidat hat eine risikobewusste Antragsempfehlung; neue Muster werden nur vorgeschlagen, nicht ohne L2-C finalisiert.

14. Finale Artefakte/Edits planen und ausführen lassen: Aus den Arbeitsnotizen einen finalen L2-G-Ergebnisbericht und gezielte Edits vorbereiten.

• File: docs/1-projects/bsfz-funding/funding-drilldown-L2-results/L2-G-result.md
• File: docs/1-projects/bsfz-funding/funding-work-packages.md
• File: docs/1-projects/bsfz-funding/STRATEGY_public-funding.md
• File: docs/1-projects/bsfz-funding/bsfz-ablehnungsrisiken.md
• Changes: Neues Ergebnisdokument mit vollständigen Tabellen erstellen. Edits an funding-work-packages.md, STRATEGY_public-funding.md und bsfz-ablehnungsrisiken.md nur als konkrete Vorschläge oder nach expliziter Review/Freigabe ausführen; G liefert Mining/Entscheidungsgrundlagen, keine finale Strategieentscheidung.
• Acceptance: Der Ergebnisbericht enthält ADR-Scan, Blind-Spot-Klassifikation, Kandidatenkatalog, Vorhaben-Matrix und L2-A-Übergabe; Edits an kanonischen Dokumenten sind klar von Analyse-/Arbeitsnotizen getrennt.

15. Validierungsdurchlauf gegen Scope und Akzeptanzkriterien durchführen: Ergebnis vor Abschluss gegen L2-G, L1 und nachgelagerte Abhängigkeiten prüfen.

• File: docs/1-projects/bsfz-funding/funding-drilldown-L2-G.md
• File: docs/1-projects/bsfz-funding/funding-drilldown-L1.md
• Changes: Abschlusscheckliste erstellen: alle Untersuchungsfragen beantwortet, alle ADRs/Blind Spots klassifiziert, keine L2-H-Recherche, alle Kandidaten Frascati-geprüft.
• Acceptance: L2-G ist als erster Drilldown nutzbar; L2-A erhält eine Themenliste mit belastbaren Clustering-Inputs; D/E/F erhalten Kandidaten für spätere Detailtriage.

Files to Modify

• docs/1-projects/bsfz-funding/funding-work-packages.md - nur nach Review/Freigabe: angenommene neue AP-Kandidaten und konservative Stundenschätzungen übernehmen; sonst als Patch-Vorschläge in L2-G-result.md dokumentieren.
• docs/1-projects/bsfz-funding/STRATEGY_public-funding.md - nur nach Review/Freigabe: kurze L2-G-Themenzusammenfassung und Clustering-Input für L2-A referenzieren; keine finale Strategieentscheidung vor L2-A.
• docs/1-projects/bsfz-funding/bsfz-ablehnungsrisiken.md - nur nach Review/Freigabe: Input für neue oder erweiterte Argumentationsmuster übernehmen; neue Muster nicht ohne L2-C finalisieren.

New Files

• docs/1-projects/bsfz-funding/funding-drilldown-L2-results/L2-G-result.md - Empfohlenes Ergebnisartefakt mit ADR-Abdeckungstabelle, Blind-Spot-Klassifikation, Quellen-Scan, Kandidatenkatalog, Vorhaben-/Clustering-Matrix und L2-A-Übergabe.

Dependencies

• Task 1 ist Voraussetzung für alle weiteren Tasks, weil L1/L2-G veraltete Pfade nennen.
• Task 2 ist Voraussetzung für Tasks 3–13, damit neue Kandidaten gegen bestehende APs abgegrenzt werden können.
• Tasks 3–9 können nach Task 2 weitgehend parallel ausgeführt werden; sie liefern die Rohfunde.
• Task 10 hängt von Tasks 3–9 ab und ist das Gate, bevor ein Fund als Kandidat formuliert wird.
• Task 11 hängt von Task 10 ab; nur Go-Kandidaten erhalten AP-Rohfassungen.
• Task 12 hängt von Task 11 ab und ist der wichtigste Übergabe-Input für L2-A.
• Task 13 hängt von Task 11 ab, sollte aber vor finalen Edits stattfinden, damit risikoreiche Kandidaten nicht unkommentiert in den AP-Katalog gelangen.
• Task 14 hängt von Tasks 11–13 ab.
• Task 15 ist der abschließende Qualitäts- und Scope-Gate.

Risks

• docs/1-projects/bsfz-funding/context.md war im aktuellen Arbeitsbaum nicht vorhanden; falls ein Parent-Kontext später erzeugt wurde, muss er vor Umsetzung erneut gelesen werden.
• Die L2-G-Quelldokumente nennen historische Pfade (docs/architecture, docs/protocols, docs/schemas, docs/supporting/...), während die tatsächlichen Dateien unter docs/2-areas, docs/3-resources und docs/4-archive liegen; falsche Pfadannahmen würden Quellen auslassen.
• L2-G darf bestehende APs nicht inhaltlich optimieren; es darf nur neue Kandidaten, Zusatzbelege oder No-Go-Klassifikationen liefern. Detail-Triage bestehender APs bleibt L2-D/E/F.
• Infrastrukturthemen wie Swarm, DNS, Secrets, Immutable Infrastructure und Observability haben hohes Standard-Engineering-Risiko; sie dürfen nur als AP empfohlen werden, wenn eine echte technische Unwägbarkeit mit Beleg existiert.
• Einige Kandidaten könnten nur Produktentscheidungen oder Compliance-Umsetzung sein; solche Fälle müssen konservativ als No-Go oder L2-H/Jahr-2+-Chance markiert werden.
• Die Akzeptanzkriterien verlangen „alle 30 ADRs“, im aktuellen Baum existiert kein adr-026; Umsetzung muss die tatsächliche ADR-Liste zählen und die Nummernlücke transparent dokumentieren.
• Die L2-G-Ergebnisse beeinflussen L2-A direkt. Wenn L2-G zu viele schwache Kandidaten empfiehlt, kann L2-A zu falschen Clustering-Schlüssen kommen; daher Jahr-1-Empfehlungen konservativ halten.
• Externe Markt- oder Wissenschaftsrecherche gehört nicht in L2-G; entsprechende Ideen müssen nach L2-H verschoben werden.
• Stundenschätzungen für neue Kandidaten sind unsicher und müssen als konservative Vorabschätzung mit späterer Steuerberater-/Fachvalidierung markiert werden.