Code/Git Forensics — Risky APs AP1, AP18, AP19, AP24, AP26

Scope und Methode

Untersucht wurden verfügbare Dokumente, Git-Historie und Code-/Dependency-Hinweise. Es wurden keine Haupt-Funding-Dokumente editiert.

Verwendete Checks:

• git log --follow --date=short --pretty=format:'%h %ad %s' -- <relevante Dateien>
• git log -S <Suchbegriff> --all -- docs apps
• rg über apps, packages, docs nach Technologie-/AP-Begriffen
• rg in package.json, apps, packages nach yjs, automerge, crdt, tensorflow, tfjs, onnx

Executive Summary

AP	Forensik-Befund	Status	Konsequenz
AP1	Inhaltlich starke Dokumente, aber Git-Chronologie stützt die offene Problemphase nur schwach.	Code/Git-Prüfung nötig	Nicht überclaimen; retrospektive Dokumentation ehrlich darstellen.
AP18	ADR-032 dokumentiert Technologieentscheidung (Loro/Yjs) und Dual-Layer-Architektur. Spike ausstehend.	einreichungsreif	AP-Katalog expandiert; V2-Integration vollzogen.
AP19	Forschungsrichtung CBOR/CWT/COSE identifiziert. Standard-Wallet-Trivialisierung entfällt.	Kandidat	V2-Integration als optionaler AP; ADR + CWT-Claim-Schema-Spike als nächste Schritte.
AP24	Dokumentierte Bedingung On-Device-ML; keine TFJS/ONNX-Dependency gefunden.	bedingt/blockiert	Erst Prototyp/ADR für Edge Quality Scoring.
AP26	Architekturbelege für Trigger/Workflow vorhanden; Gefahr n8n/Standard-Automation bleibt.	bedingt	Nur mit non-trivialer Cross-Context-Orchestrierung und Timing-Konflikten.

---

AP1 — Margenbesteuerung & Tax-Decomposition Engine

Dokumentenbelege

• AP-Katalog: Forschungsfrage, Belege und F&E-/Engineering-Split in funding-work-packages.md:19-24.
• AP-Katalog warnt explizit vor retrospektiver Git-Chronologie in funding-work-packages.md:32-46.
• tax-engine.md enthält §25-UStG-Algorithmus, Drittlands-Split und Persistenzpflichtfelder: apps/api/docs/tax-engine.md:83-140.
• ADR-012 dokumentiert das Problem der per-variant tax estimation und warum der Ansatz scheitert: docs/3-resources/decisions/adr-012-toms-tax-deferral.md:32-41.
• ADR-012 entscheidet Deferral in FinancialLedger / Phase 3: docs/3-resources/decisions/adr-012-toms-tax-deferral.md:58-64.
• ADR-006 dokumentiert Costing/Pricing-Separation und Finanzledger-Integration: docs/3-resources/decisions/adr-006-costing-pricing-separation.md:14-20, :51-57.

Git-Historie

git log --follow auf AP1-nahe Dateien ergab:

Datei	Früheste sichtbare relevante Commits im aktuellen Verlauf	Befund
apps/api/docs/tax-engine.md	f1ebd58 2026-04-07 docs: add Kalkulations-Docs	Tax-Engine-Dokument existiert vor späterer SB-2-/ADR-012-Dokumentation.
docs/3-resources/decisions/adr-012-toms-tax-deferral.md	sichtbare Historie ab b4428f0/2205e96 um 2026-04-13; AP-Katalog nennt 2026-04-10	Bestätigt nicht eigenständig eine offene Problemphase vor tax-engine.md.
docs/2-areas/strategy/STRATEGIC_BLIND_SPOTS.md	sichtbare Historie ab 2026-04-13+; AP-Katalog nennt SB-2 als bereits resolved	Git-Stützung für „SB-2 war offen“ bleibt schwach.
apps/api/docs/period-lock.md	f1ebd58 2026-04-07, 631d867 2026-04-08	Kann AP1/GoBD-Kontext stützen, aber nicht die gescheiterte Per-Variante-Iteration.
apps/api/docs/storno-workflow.md	f1ebd58 2026-04-07	Stützt GoBD-/Ledger-Kontext, nicht v1/v2-Failure direkt.

Zusätzliche git log -S-Suchen nach Tax-Decomposition und Per-Variante fanden primär spätere Funding-/Review-Commits (u.a. 2026-05-01/2026-04-30) und keinen klaren Codezustand vor 2026-04-07, der den gescheiterten Ansatz beweist.

Forensik-Urteil

• Inhaltliche F&E-Substanz: stark dokumentiert.
• Chronologie als Beweis für offene Unwägbarkeit: schwach / retrospektiv.
• Empfehlung: AP1 nicht fallenlassen, aber im Antrag nicht behaupten, dass Git eine offene SB-2-Phase vor Lösung zeigt. Besser: „ADR-012 dokumentiert die verworfene v1/v2-Konzeption; formelle Dokumentation erfolgte retrospektiv, die Deferral-Architektur bleibt in Phase 3 unvalidiert.“

Next Actions

1. git log -S 'tax_amount', git log -S 'margin_taxable', git log -S 'PriceMatrix' auf apps, packages, docs/3-resources/schemas vertiefen.
2. Prüfen, ob ältere schema-/L3-Drilldown-Commits PriceMatrix-Tax-Felder vor ADR-012 enthalten.
3. Wenn kein Beleg: Antragstext bewusst ohne Git-Timeline-Claim formulieren.

---

AP18 — CRDT-Based Collaborative Trip Planning

Dokumentenbelege

• AP18 Forschungsfrage und Belege: funding-work-packages.md:189-207.
• ADR-032 Collaborative Trip Planning: docs/3-resources/decisions/adr-032-collaborative-trip-planning.md (Dual-Layer-Architektur, Loro/Yjs-Bewertung, Projektionsservice, Versionierungslifecycle, GoBD-Auditmodell).
• Risiko-Policy: bsfz-ablehnungsrisiken.md:283-293 — ADR-032 erfüllt die CRDT-Bedingung.
• L2-F blockierte AP18: L2-F-result.md:21, :49, :59 — historisch, durch ADR-032 aufgelöst.

Code-/Dependency-Check

• Keine loro-/yjs-/automerge-/CRDT-Dependencies in package.json, apps oder packages — erwartungsgemäß, da AP18 ein zukünftiges Forschungsvorhaben ist.
• ADR-032 dokumentiert die Technologieentscheidung (Loro primär, Yjs Fallback) und den Phase-1-Spike-Plan.

Forensik-Urteil

AP18 ist einreichungsreif. ADR-032 erfüllt die Dokumentationsvoraussetzung (Forschungsfrage, Technologieentscheidung, Architektur, Unwägbarkeiten, Phasenplan). Der Phase-1-Spike steht aus — das ist kein Blocker für die BSFZ-Einreichung, da das FZulG den Forschungsprozess fördert, nicht abgeschlossene Ergebnisse.

Next Actions

1. Steuerberater-Review für Vorhaben-2-Zuordnung und Stundenbudget (220h).
2. Phase-1-Spike (Loro vs. Yjs) nach Steuerberater-Freigabe starten.
3. Status von 🟡 auf ✅ hochstufen nach erfolgreichem Spike.

---

AP19 — Passenger-Side Offline Credential Validation (CBOR/CWT/COSE)

Dokumentenbelege

• AP19 Forschungsfrage und V2-Integration: funding-work-packages.md:196-204.
• Risikoübersicht: bsfz-ablehnungsrisiken.md:236.
• Muster B beschreibt CBOR/CWT/COSE-Credential-Versionierung als Kern: bsfz-ablehnungsrisiken.md:267-273.
• AP2-Manifest als Revocation-Orakel: offline-sync-protocol.md.
• Produkt-/Strategie-Dokumente zeigen Standard-Wallet-Digital-Ticketing als Baseline (APNs/Google Wallet API), aber AP19 geht über diesen Standard hinaus mit CBOR/CWT/COSE-basiertem Offline-Validierungsprotokoll.

Technologieentscheidung

• CBOR/CWT/COSE (IETF RFC 8949, RFC 9052, RFC 8392) als kryptographisches Credential-Format.
• EU Digital COVID Certificate als Precedent für statische Credentials — Busflow erweitert den Stack auf mutable Buchungszustände.
• Standard-Wallet-Pass-Infrastruktur (APNs/Google Wallet API) bleibt als Zustellkanal erhalten; das CWT ist der kryptographische Kern im QR-Code.
• credential_version im CWT wird gegen das AP2-Fahrermanifest abgeglichen — das Manifest dient als Offline-Revocation-Orakel.

Code-/Dependency-Check

• Keine CWT/COSE-Dependencies in package.json, apps oder packages (erwartungsgemäß — AP19 ist prospektive Forschung).
• Relevante npm-Kandidaten: @auth0/cose (COSE-Primitives), cbor-x/cbor2 (CBOR-Encoding), kein dominantes CWT-Library.
• AP2-Manifest-Infrastruktur (offline-sync-protocol.md) existiert und kann als Revocation-Kanal erweitert werden.

Forensik-Urteil

AP19 ist Kandidat (vormals blockiert). Die Forschungsrichtung CBOR/CWT/COSE entschärft das Wallet-Trivialisierungsrisiko. Der IETF-RFC-Stack liefert eine formale Basis, die EU-DCC-Precedent stützt die Frascati-Argumentation (bewährt für statische Credentials, offen für mutable Buchungszustände). Eine formale Technologieentscheidung (ADR) steht noch aus.

Next Actions

1. ADR für CWT-Claim-Schema (custom Claims für booking_id, seat_id, vehicle_id, credential_version, mutation_hash) schreiben.
2. Spike: QR-Code-Kapazität unter Feldbedingungen mit vollem Claimset testen.
3. AP2-Manifest um credential_version-Feld erweitern (Protokoll-Erweiterung).
4. CWT-Issuance-Service in NestJS + Verification-Modul in Driver-PWA als Machbarkeitsstudie.

---

AP24 — Field-Device Media Pipeline mit On-Device Quality Scoring

Dokumentenbelege

• AP24 Forschungsfrage, On-Device Quality Scoring und Belege: funding-work-packages.md:240-245.
• Harte Warnung: ohne On-Device-ML nur Standard-Upload-Pipeline: funding-work-packages.md:247-248.
• Risikoübersicht: bsfz-ablehnungsrisiken.md:249.
• Operations-Schema enthält Photo-/Image-/OCR-nahe Pipeline-Elemente, aber für Expense Receipt/OCR bzw. Upload-Handling:
  • docs/3-resources/schemas/schema-operations.md:754-763 receipt image key / OCR data.
  • docs/3-resources/schemas/schema-operations.md:812-815 AI OCR service.
  • docs/3-resources/schemas/schema-operations.md:892-893 OCR-/Photo-upload-Failure-Fälle.

Code-/Dependency-Check

Suchen nach tensorflow, tfjs, onnx, onnxruntime-web, quality scoring, on-device, media pipeline ergaben:

• Keine TFJS-/ONNX-Dependency in package.json, apps, packages gefunden.
• Image-/Photo-Treffer betreffen primär Upload/OCR/Branding/Tour-Content, nicht On-Device Quality Scoring.
• Kein AP24-spezifischer Edge-ML-Prototyp gefunden.

Forensik-Urteil

AP24 ist derzeit bedingt bis blockiert. Es gibt Upload-/OCR-nahe Infrastruktur, aber der förderrelevante Kern (On-Device Quality Scoring/Edge ML) ist nicht belegt.

Next Actions

1. Technische Entscheidung: TFJS, ONNX Runtime Web oder kein Edge-ML.
2. Minimaler Spike: Bildqualität lokal bewerten (Blur/Exposure/Face/Consent-Hinweis), Laufzeit auf Zielgerät messen.
3. ADR/Protokoll erstellen, das Standard-Upload klar von Edge-Quality-Scoring trennt.

---

AP26 — Proactive Lifecycle Communication Engine

Dokumentenbelege

• AP26 Forschungsfrage und Trivialitätswarnung: funding-work-packages.md:257-265.
• Risikoübersicht: bsfz-ablehnungsrisiken.md:251.
• Workflow-Orchestration-Grundlage: Hasura Events/Cron, XState, n8n, BullMQ/NestJS in docs/2-areas/architecture/workflow-orchestration.md:21-40, :67-87.
• Feature-Subset zeigt Trigger-Based Automation, Broadcasts, initial manuelle Approval-Pfade: docs/2-areas/strategy/STRATEGY_feature-subsets.md:107-113.
• Produkt-/Passagier-Dokumente zeigen Wallet/WhatsApp/Magic-Link-Lifecycle, z.B. apps/passenger/README.md:6, :14, :39.

Code-/Dependency-Check

• Es gibt Architektur-/Produktbelege für Workflow-/Messaging-Ziele.
• Treffer in Code sind bisher generische Trigger/Audit-/Workflow-Mechanismen, nicht AP26-spezifische non-triviale Cross-Context Timing-Optimierung.
• workflow-orchestration.md:84-87 nennt n8n als Prototyping und Migration zu NestJS/BullMQ; das stützt zwar Planmäßigkeit, kann aber auch zeigen, dass Standard-Automation zunächst ausreicht.

Forensik-Urteil

AP26 ist bedingt. Die Quelllage stützt eine Event-/Workflow-Architektur, aber noch nicht sicher eine F&E-Unwägbarkeit jenseits Standard-Automation.

Next Actions

1. Konkrete Konfliktszenarien dokumentieren: widersprüchliche Events aus Commerce/Operations/Communications, mandantenspezifische Zeitfenster, ChannelPreference, Zustell-Failure.
2. Standard-Workflow-Engine-Abgrenzung explizit schreiben: Was kann n8n/Temporal trivial, was nicht?
3. Falls non-triviale Koordination belegt: AP26 als V2/V4-Brücke oder Folgevorhaben; sonst zurückstellen.

---

Gesamt-Fazit für Patch-Readiness

• AP1: Kann strategisch weitergeführt werden, aber nur mit ehrlicher Chronologie. Kein starker Git-Beweis für offene SB-2-Phase.
• AP18: Einreichungsreif — ADR-032 dokumentiert Technologieentscheidung, Architektur und Unwägbarkeiten. Spike ausstehend (kein BSFZ-Blocker).
• AP19: Kandidat — Forschungsrichtung CBOR/CWT/COSE entschärft Wallet-Trivialisierung. ADR + Spike als nächste Schritte.
• AP24: Nicht einreichen ohne On-Device-ML-Prototyp/ADR.
• AP26: Nur als F&E formulieren, wenn Cross-Context-Orchestrierung non-triviale technische Konflikte hat; sonst Standard-Automation/Marketingrisiko.