L2-F: Triage Kandidaten-APs (AP10–AP19)

Herkunft: funding-drilldown-L1.md — Level-2-Drilldown F von 8.

Ziel: Systematische Bewertung aller 10 Kandidaten-APs auf Förderfähigkeit, Vorhaben-Zuordnung und Einreichungs-Priorisierung.

Reihenfolge: G → A → B → D/E/F (parallel) → C → H. F läuft parallel zu D und E.

---

Scope

Systematische Bewertung aller 10 Kandidaten-APs auf Förderfähigkeit, Vorhaben-Zuordnung und Einreichungs-Priorisierung.

Nicht im Scope: Kern-APs (→ L2-D), Commerce-APs (→ L2-E), neue AP-Kandidaten (→ L2-G).

Quelldokumente

• docs/strategy/funding-work-packages.md (§Neue Kandidaten)
• docs/supporting/reference/bsfz-ablehnungsrisiken.md (§Risikoübersicht, §Muster A/B/C)
• Pro AP die referenzierten Belege:
  • AP10: Domain Model (CostingSheet.fx_risk_buffer)
  • AP11: Domain Model (Seat Re-Mapping)
  • AP12: TelemetryPoint, ADR-027
  • AP13: Domain Model (Border Manifests)
  • AP14: Domain Model (Dispatch Conflict)
  • AP15: docs/protocols/dispatch-availability-engine.md
  • AP16: Domain Model (ExpenseReceipt)
  • AP17: Domain Model (Reseller), ADR-016
  • AP18: Codebasis-Check erforderlich (CRDT vs. Last-Write-Wins)
  • AP19: Codebasis-Check erforderlich

Untersuchungsfragen

1. Codebasis-Validierung: Für jeden AP: Existiert Code oder Schema, das die Forschungsfrage stützt? Oder existiert nur ein Domain-Model-Eintrag?
2. Vorhaben-Zuordnung: Welche APs gehören in bestehende Vorhaben (1–4), welche bilden ein fünftes Vorhaben?
3. Go/No-Go: Für jeden AP: Einreichen (Jahr 1), verschieben (Jahr 2+), oder verwerfen?
4. Argumentationsmuster: Passt das in bsfz-ablehnungsrisiken.md vorgeschlagene Muster (A/B/C) für jeden AP, oder braucht es Anpassungen?
5. Kombinierbarkeit: Welche APs stärken sich gegenseitig, wenn sie im gleichen Vorhaben eingereicht werden (z.B. AP15 + AP3)?
6. Bedingungen: AP18 (CRDT) ist bedingt förderfähig. Welche anderen APs haben versteckte Bedingungen?
7. Stunden-Gesamtrahmen: Welches Volumen ergibt sich bei optimaler Selektion? Bleibt es innerhalb des 40h/Woche-Rahmens?

Erwartete Ergebnisse

• Triage-Tabelle (AP × Go/No-Go/Verschieben + Begründung)
• Vorhaben-Zuordnungsvorschlag für die aufgenommenen APs
• Aktualisierte Stundenübersicht
• Bedingungsliste (was muss vor Einreichung geklärt werden)

Akzeptanzkriterien

• Jeder der 10 APs hat eine Go/No-Go/Verschieben-Entscheidung mit Begründung ≤3 Sätze
• AP18 und AP19 haben einen Codebasis-Check-Befund (nicht nur "muss geprüft werden")
• Triage-Tabelle enthält Spalten: AP | Entscheidung | Begründung | Vorhaben | Stunden | Bedingungen

Offene Hypothesen (L1)

• AP15 → AP3 Integration empfohlen: bsfz-ablehnungsrisiken.md empfiehlt explizit: "Standalone-Risiko: 🔴 Hoch; integriert in AP3: 🟢 Niedrig." Die EU-561-Integration ist das Forschungselement, nicht der CSP-Solver an sich.
• AP18 CRDT-Bedingung: Nur förderfähig bei Yjs/Automerge-Implementierung. Bei Last-Write-Wins via Hasura: nicht beantragen. Codebasis-Prüfung in dieser L2-Session durchführen.
• AP19 Wallet-Bedingung: Standard-Wallet-Pass-Infrastruktur eliminiert die Forschungsfrage. Nur förderfähig bei Custom-Offline-Validierungsprotokoll.
• Beleglage heterogen: AP10–AP17 haben Domain-Model-Einträge, aber nur AP12 (ADR-027), AP15 (dispatch-availability-engine.md) und AP17 (ADR-016) haben formale Belege jenseits des Domain-Models.

Randbedingungen

• Konservative Bewertung bevorzugen — lieber weniger APs mit starker Beweislage als viele mit dünner Basis
• AP18 (CRDT) erfordert eine Codebasis-Prüfung, die in dieser Session durchgeführt werden soll