live_interaction_contracts

# DELEGATION_LEDGER — format & classification rules (v1, durable)

This file defines the ledger's **format and rules**. The actual per-machine
classification for a given LiveView/browser version is **generated by the harness**
into `delegation-ledger.json` and `delegation-ledger.md` — do not hand-edit those,
and do not copy their version-specific rows into this file or into `SPEC.md`.

## Classification

Each machine is classified per LiveView/browser version:

- **green** — delegation survived **all** tested non-destructive patches on all engines.
- **amber** — works only under specific restrictions (state a machine can partly
  express, or one facet green and another unknown).
- **red** — fails under ordinary non-destructive patching.
- **unknown** — insufficient evidence (not observable via automation).

## State-location taxonomy (the field that predicts the class)

For each machine the ledger records where its state lives, because that predicts the
class per the cross-cutting invariant:

- **top-layer / pseudo-class** (not an attribute) → delegation-safe
- **DOM node-bound editing state** (value, selection, scroll) → safe while node continues
- **server-reconciled attribute** (`open`) → **red** — reconciliation strips it
- **browser-internal / not observable** → **unknown**

## Per-machine recorded fields

Node-object survival (JS expando) and machine-state survival are recorded separately
for each patch class: sibling / content / attribute / nearby-reorder / nearby-stream /
push_patch / reconnect, plus the destructive controls push_navigate and
remove/reinsert, and whether behavior differs by engine.

The separation is the point: **node survival ✓ with state survival ✗** is the
signature of a reflected-attribute failure (node kept, state stripped).

## Rules

1. The ledger is a **generated artifact**, regenerated by `harness/ledger.mjs` from
   a recorded harness result file. The release/default source is the stable
   full-matrix `harness/results-1.2.5.json`; `mix live_interaction_contracts.ledger
   --results results.json` may be used to inspect freshly generated local results.
2. Green requires all three engines. A single-engine difference downgrades to amber
   with the difference recorded.
3. Red fixtures are **expected failures**, not bugs — CI asserts they stay red.
4. Unknown/amber machines **must appear** in the generated ledger; they never silently
   drop out.
5. A machine changes class only via regenerated evidence, never by editing prose.

## Current ledger

See the generated `delegation-ledger.md` / `delegation-ledger.json`. As of the last
generated run the shape is: popover / select-value / input-editing / scroll green;
dialog / details red; select-popup / IME unknown. **That sentence is a pointer, not a
source of truth — the generated files are.**

The ledger classifies **raw native** machines. A red machine may still have an
**amber adapter** — a contract-aware repair with its own conformance suite. `<dialog>`
is red raw but has a 7/7 amber adapter (`CONTRACT_DIALOG.md`); the adapter is tracked
separately (`priv/dialog-adapter-spike/`), not in this raw-machine ledger.