# Spike D — App-Group-Container ohne Sandbox

Gemessen am 10.08.2026. Werkzeug: `Spikes/appgroup-probe.swift`,
gebaut und signiert über `Spikes/build-appgroup-probe.sh`.

## Ergebnis: bestätigt

Ein **nicht sandboxed** Prozess, signiert mit `Apple Development (PP34X97WS3)` und der
Entitlement `com.apple.security.application-groups`, erhält den Container:

```
/Users/scarriffle/Library/Group Containers/PP34X97WS3.group.com.scarriffleservices.calendarr
```

- `containerURL(forSecurityApplicationGroupIdentifier:)` liefert einen Pfad, nicht `nil`
- Schreibzugriff vorhanden
- `CFNotificationCenterAddObserver` auf dem Darwin-Center registriert ohne Fehler

Damit ist die Kernannahme des Plans belegt: Onyx kann nicht-sandboxed sein — und damit
IOKit, den privilegierten Helper und den MediaRemote-Adapter nutzen — **und** trotzdem den
Calendarr-Snapshot über `CalendarrCore` lesen. Die Bridge-App als Rückfalloption entfällt.

## Zustand des Containers

```
.com.apple.containermanagerd.metadata.plist
Library/
```

Kein `widget-cache.json`. Die Calendarr-Mac-App ist auf dieser Maschine noch nie gelaufen,
`SnapshotStore().read()` wird also korrekt `.neverWritten` liefern. Das ist der erste Zustand,
den das Kalender-Widget behandeln muss, und der einzige, der sich derzeit real testen lässt.

Anmerkung: das Verzeichnis existierte vor diesem Spike nicht — `containermanagerd` legt es beim
ersten Zugriff an. Ein vorhandener Container ist also **kein** Beleg dafür, dass Calendarr
jemals geschrieben hat. Genau deshalb ist `.neverWritten` ein eigener Zustand und nicht
„Datei fehlt".

## Offener Punkt

Der Spike signiert eine nackte Binary ohne Provisioning-Profil. Das App-Bundle bekommt von
Xcode ein eingebettetes Profil — das ist der weniger strenge Fall, der Zugriff kann dort nicht
schlechter sein. Beim ersten echten Build wird trotzdem gegengeprüft, dass `containerURL`
nicht `nil` ist; das ist laut Integrationsanleitung der Fehler, der sich sonst als leere App
ohne jede Meldung zeigt.