Files
meeting-assistant/openspec/changes/complete-macos-feature-parity/design.md
T
dh 728e66dd72
PR and Push Build/Test / windows-build-and-test (push) Failing after 38m25s
PR and Push Build/Test / portable-build-and-test (push) Successful in 8m9s
PR and Push Build/Test / macos-native-full (push) Skipped
ci: consolidate platform pipelines and test prerequisites on macOS support
2026-10-06 09:02:19 +02:00

5.3 KiB

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.