# Prospective exact capture for Finder, browsers, and spreadsheets

Status: contract and server-side source seams implemented; native products,
runtime routing, retained manifests, qualification, and replay authority are not.

## Why this boundary exists

Finder, allowlisted browsers, Excel, and Numbers currently contribute macOS
Accessibility context and consented visual fallback only. That evidence can show
which app or control had focus, but it cannot prove an exact URL commit, selected
file identity, changed cell values, or a file operation. Treating that context as
an exact edit would manufacture facts that never reached the Event Spine.

`demonstration_cross_app_adapter_contract` defines one signed semantic envelope
for these apps. `demonstration_cross_app_sources` provides three injected
transport seams. Neither module starts a native product or contacts an app.

## Signed session contract

The server creates a fresh channel challenge for one exact workspace, task, and
recording session. A configured transport receives only that public channel ID
and non-authorizing recording control. Every native message must bind and sign:

- workspace, task, session, channel, application, adapter build, and instance;
- a strictly monotonic sequence and unique message ID;
- a canonical payload digest;
- either a bounded operation batch or a capture-incomplete diagnostic;
- `authority=observation_only`, `execution_authorized=false`, and
  `production_ready=false`.

The server accepts signatures only from an exact preconfigured Ed25519 public
key/build binding. A signature identifies the configured source; it is not a
capability qualification, approval, execution grant, or statement that the
recording is complete. A new server channel rejects envelopes copied from an
earlier verifier instance even when the recording IDs are reused.

Raw keys, keystrokes, clipboard content, screenshots, pointer coordinates,
cookies, authorization fields, passwords, and credential-bearing URLs are
rejected. Only applications selected for the recording can create a verifier or
submit an envelope.

## App-specific evidence policy

### Finder

An Apple Events snapshot may describe current folder navigation or selected
stable item IDs. FSEvents alone is not an exact file-operation receipt: events
can be coalesced and do not prove the initiating operation. A file move is
accepted only when a future native bridge pairs FSEvents with a signed
file-operation receipt bound to the same item plus distinct before and after
state. No such Finder bridge is shipped by this repository today.

### Browser

A future allowlisted extension/CDP bridge may describe committed HTTP(S)
navigation, tab/control selection, and a committed form-control change. The
contract rejects URL credentials and sensitive query parameters, password or
hidden controls, password/payment/one-time-code autocomplete classes, raw input
events, and keystroke fields. A form mutation requires a trusted DOM change
receipt with distinct before and after state. Attaching CDP or an extension to a
browser/profile/tab remains an explicit user installation and consent step.

### Spreadsheet

Office add-in `onSelectionChanged` evidence may describe a stable workbook,
worksheet, and A1 range. `onChanged` may describe a value mutation only when the
adapter supplies distinct before/after state and a receipt whose postcondition
matches the typed value matrix. Formula payloads are excluded from this initial
contract. Numbers can provide read/selection snapshots through a future native
bridge, but no authoritative passive Numbers cell-change event has been proven;
its source must report `capture_complete=false` for those mutations.

## Degraded operation and integration hook

Each source starts without failing the recording. If its native transport is
missing or disconnected, `source.status()` reports `state=degraded`,
`recording_continues=true`, `capture_complete=false`, and a bounded diagnostic.
A signed gap diagnostic latches that degraded status for the session; later
exact events are still accepted but cannot erase the known missed interval.

The existing application-adapter runtime can integrate these seams by:

1. constructing one `SignedOperationBatchVerifier` from server-owned trusted
   build keys and the exact selected applications;
2. adding the three source objects next to its current native sources and
   passing their server-issued `channel_id` in transport control;
3. merging `source.status()` and diagnostics into its review-visible status;
4. routing only server-verified operation batches into a future cross-app
   retention adapter after exact physical manifests exist.

Do not send these batches into the current Photoshop/Unity operation recorder:
Finder/browser/spreadsheet adapter identities and operations intentionally have
no qualified physical-manifest binding yet. Replay must remain blocked until a
step has a typed stable target, declared arguments, verified postcondition,
registered handler, qualified capability, disposable scope for writes, and the
separate governed approvals. Nothing here changes `production_ready`.

## External gates still open

- build, sign, install, and independently review the Finder bridge, browser
  extension/CDP bridge, Office add-in, and any Numbers bridge;
- provision and rotate trusted build keys without accepting browser-supplied
  public keys;
- add durable channel/sequence recovery if a recording must survive a server
  process restart;
- add physical manifests and handlers only after isolated sandbox evidence;
- integrate source status into authenticated Learning Studio routes;
- run distinct real-app qualification cases and independent review.