Raised in #2448 review and deliberately filed rather than blocked on, because it is cross-platform scope.
The shape. SnapshotState now carries two parallel channels for the same concept:
systemSurfaceOnly?: boolean — Android: the capture is an occluding system surface (notification shade, quick settings) rather than app content.iosSystemSurfaceBundleId?: string — iOS: the capture is an in-place system surface (a web sign-in sheet, com.apple.SafariViewService) presented over the app.
withSystemSurfaceDisclosure (src/daemon/system-surface-disclosure.ts) then branches on which field is set to pick a platform-specific sentence. As the reviewer put it, that is a missing shared model, not a nit.
Why it matters beyond tidiness. Both fields answer the same two questions — "is this capture app content?" and "what should the agent be told?" — and every new consumer has to learn that the answer lives in two places with different types. The iOS side additionally needs the identity (which surface) because it feeds comparison refusal; the Android side only needs the boolean today, but the shade/quick-settings distinction is latent.
Rough direction (not prescriptive): one optional systemSurface?: { platform-neutral kind; identity? } that both producers populate, with the disclosure derived from the kind rather than from which field happens to be set. The Android boolean becomes the degenerate case. Wants a look at whether the Android systemSurfaceOnly producers can supply an identity cheaply, and at the SnapshotState field checklist rules before adding or replacing fields.
Not urgent. Both channels work and are tested today. This is about preventing a third platform from adding a third channel.
Context: #2448 added the iOS side; the Android side predates it.
Raised in #2448 review and deliberately filed rather than blocked on, because it is cross-platform scope.
The shape.
SnapshotStatenow carries two parallel channels for the same concept:systemSurfaceOnly?: boolean— Android: the capture is an occluding system surface (notification shade, quick settings) rather than app content.iosSystemSurfaceBundleId?: string— iOS: the capture is an in-place system surface (a web sign-in sheet,com.apple.SafariViewService) presented over the app.withSystemSurfaceDisclosure(src/daemon/system-surface-disclosure.ts) then branches on which field is set to pick a platform-specific sentence. As the reviewer put it, that is a missing shared model, not a nit.Why it matters beyond tidiness. Both fields answer the same two questions — "is this capture app content?" and "what should the agent be told?" — and every new consumer has to learn that the answer lives in two places with different types. The iOS side additionally needs the identity (which surface) because it feeds comparison refusal; the Android side only needs the boolean today, but the shade/quick-settings distinction is latent.
Rough direction (not prescriptive): one optional
systemSurface?: { platform-neutral kind; identity? }that both producers populate, with the disclosure derived from the kind rather than from which field happens to be set. The Android boolean becomes the degenerate case. Wants a look at whether the AndroidsystemSurfaceOnlyproducers can supply an identity cheaply, and at theSnapshotStatefield checklist rules before adding or replacing fields.Not urgent. Both channels work and are tested today. This is about preventing a third platform from adding a third channel.
Context: #2448 added the iOS side; the Android side predates it.