ci: consolidate platform pipelines and test prerequisites on macOS support

2026-10-06 09:02:19 +02:00
1 parent 1b19b08f2e
commit 728e66dd72
@@ -0,0 +1,41 @@
+## Context
+
+Windows und macOS teilen Aufnahme- und Agent-Fachlogik in .NET. Der Mac-Port verwendet noch nicht sämtliche bestehenden Recovery-, Auswahl- und Desktop-Aktionswege. Die Chat-Präsentation transportiert außerdem nur einen Teil der bereits definierten Darstellungszustände. Das neutrale Testtarget entdeckt bedingt kompilierte Windows-Fälle auch auf einem Windows-Host nicht.
+
+Der vorhandene Kommunikations-Change stellt User requests und unabhängige Workflow-Sessions bereit. Seine offene Windows-Resourcebuild- und native UI-Abnahme bleiben erhalten; diese Funktion wird nicht erneut implementiert.
+
+## Goals / Non-Goals
+
+**Goals:** dieselben fachlichen Ergebnisse auf beiden Plattformen; Verhaltenstests an bestehenden öffentlichen Grenzen; tatsächliche native Abnahme; Testabsicherung und Recovery, Pause sowie sicherer Exit zuerst; nachvollziehbare echte Abhängigkeiten.
+
+**Non-Goals:** Code-, Test- oder CI-Implementierung in diesem Planungsschritt; neue ASR-Backends; zusätzliche Kalenderquellenauswahl oder Credential-Speicherung; Live-Neustart, Installation, Auslieferung oder Archivierung.
+
+## Decisions
+
+1. **Anforderungen beim bisherigen Eigentümer ergänzen.** Recovery, Pause, Mikrofonangebote, Desktop, Kalender und Resemblyzer erhalten macOS-Szenarien in ihren ursprünglichen aktiven Changes. Der koordinierende Change führt ausschließlich die zusätzliche Prüf-Capability. Damit bleiben bestehende Fachverträge die Verhaltensquelle.
+2. **Hohe vorhandene Testgrenzen nutzen.** Aufnahme wird über Desktop-Aktion und öffentlichen RecordingCoordinator, Kalender über öffentliche Metadatensuche/Scheduler, Agenten über Session/Chat bis Präsentation und Speaker-Funktionen über öffentliche Tool-/Queue-/Encoder-Grenzen geprüft. Reine Registrierung oder ein Stub beweisen keine native Funktion.
+3. **Recovery liefert die schmale Geräteanbindung.** Vollständiger Fallback benötigt Geräteauflösung und ID-basierte Capture. Eine fertige Auswahloberfläche ist keine Voraussetzung. Recovery arbeitet nach Laufzeitwahl, Konfiguration, Standard und verfügbarem Ersatz. Default-only Retry ist ein Teilschritt, keine volle Parität.
+4. **Fachlogik und native Adapter behalten.** Auswahl-, Pause-, Exit-, Profil-, Kalender- und User-request-Regeln bleiben im C#-Kern. Swift erweitert Apple-Geräte-, Menü-, Notification-, Shortcut- und Fensterbindungen; die bestehende WebView erhält die benötigte Darstellung. Verteilte OS-Abfragen in der Fachlogik sind nicht erforderlich.
+5. **Agent-Darstellung in fünf Ergebnisse teilen.** Markdown, Links, Bilder, Aktivität und Scroll sind einzeln beobachtbar. Parser, Resolver, Activity-ViewModel und Scroll-Policy bestehen bereits. Bilder enthalten ihren eigenen Auflösungs-/Transport-/Öffnungsweg; Activity und Scroll benötigen keine neue Markdown-Darstellung.
+6. **Neue Unterhaltung explizit und verlustfrei öffnen.** Die Sessionverwaltung erstellt eine zusätzliche leere Session und ein Fenster ohne Modellaufruf. Bestehende Gespräche und Drafts bleiben erhalten. Implizites Löschen beim Schließen verletzt den bereits geschützten Erhaltungsvertrag.
+7. **Plattformnachweise getrennt berichten.** Echter Windows-TFM, Discovery und Assertions sind erforderlich; RID genügt nicht. Unverfügbare Laufzeittests melden Skip statt scheinbaren Erfolg. Windows-Resourcebuild, native Pixeltests und operative Mac-Prüfungen erhalten eigene Ergebnisse.
+
+## Risks / Trade-offs
+
+- [Engine stoppt bei lebendem Helper] → native Konfigurations-/Stop-Erkennung und Recovery nachweisen; reine Prozessfehlerprüfung genügt nicht.
+- [Verzögerte Aktion beeinflusst anderen Run] → ursprüngliche Run-/Request-Lebensdauer binden und Wirkungslosigkeit veralteter Entscheidungen prüfen.
+- [Gleichzeitige Änderungen an nativer Präsentation] → Dateibearbeitung bei späterer Umsetzung koordinieren; gemeinsame Dateien sind keine fachlichen Blocker.
+- [Betriebsumgebung fehlt] → fehlenden Runner, Gerätezustand, Backend oder Berechtigung ausdrücklich als offene Abnahme ausweisen.
+- [Delta verliert vorhandene Szenarien] → vollständige Requirementblöcke erhalten und macOS-Szenarien additiv integrieren; vor Archivierung Konflikte aktiver Deltas abgleichen.
+- [Standard-Paketpin auf macOS nicht installierbar] → offizielle Indexdaten prüfen und frische isolierte CPU-Provisionierung nachweisen; explizite Nutzerpins nicht still ändern.
+
+## Migration Plan
+
+Zunächst werden nur Planungsdokumente veröffentlicht. Spätere Umsetzung erfolgt in kleinen vollständigen Slices: roter Verhaltenstest, minimale Umsetzung, relevante grüne Tests, strikte OpenSpec-Validierung und operative Abnahme. Bereits gültige Nachweise werden weiterverwendet; Wiederholung benötigt eine neue Änderung oder konkrete Regression.
+
+Die bestehende Kommunikation und ihre Nachweise bleiben erhalten. Eine fehlgeschlagene oder unmögliche Prüfung bleibt offen. Keine aktive Aufnahme oder Verarbeitung wird für eine Abnahme ohne ausdrückliche Autorisierung unterbrochen.
+
+## Open Questions
+
+- Verfügbare Windows-/Mac-Testumgebung, native UI-Steuerung, Audiofixture und aktivierte Backendkonfiguration sind vor den entsprechenden operativen Prüfungen zu bestimmen.
+- Unterstützte Python-/macOS-/Architektur-Kombinationen und installierbare Standardpins werden im Resemblyzer-Slice mit offiziellen Paketdaten und frischem Lauf verbindlich nachgewiesen.