tuya2ildevice 0.1.0__tar.gz

tuya2ildevice-0.1.0/.gitignore

@@ -0,0 +1,9 @@
+__pycache__/
+*.pyc
+.pytest_cache/
+dist/
+*.egg-info/
+.venv/
+venv/
+.coverage
+.DS_Store

tuya2ildevice-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 3735943886
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

tuya2ildevice-0.1.0/PKG-INFO

@@ -0,0 +1,146 @@
+Metadata-Version: 2.5
+Name: tuya2ildevice
+Version: 0.1.0
+Summary: Sans-IO converter: Tuya (rustuya / rustuya-bridge) device + DPS packets <-> ildevice descriptor, values and commands
+Project-URL: Repository, https://github.com/3735943886/tuya2ildevice
+License-Expression: MIT
+License-File: LICENSE
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Home Automation
+Requires-Python: >=3.10
+Provides-Extra: host
+Requires-Dist: paho-mqtt>=2.0; extra == 'host'
+Provides-Extra: test
+Requires-Dist: jsonschema; extra == 'test'
+Requires-Dist: paho-mqtt>=2.0; extra == 'test'
+Requires-Dist: pytest; extra == 'test'
+Requires-Dist: pytest-asyncio; extra == 'test'
+Description-Content-Type: text/markdown
+
+# tuya2ildevice
+
+The one place that interprets Tuya. Sans-IO Python: takes a Tuya device as [rustuya](https://github.com/3735943886/rustuya) /
+[rustuya-bridge](https://github.com/3735943886/rustuya-bridge) know it and produces an
+[ildevice](https://github.com/3735943886/ildevice): descriptor, live values and events from dps packets, and dps for
+ildevice commands. It opens no sockets and reads no clock. Other projects
+([rustuya-homeassistant](https://github.com/3735943886/rustuya-homeassistant), ildevice hosts,
+[rustuya-manager](https://github.com/3735943886/rustuya-manager)) import this instead of carrying their own Tuya knowledge.
+
+```
+pip install tuya2ildevice              # no dependencies;  tuya2ildevice[host] adds paho-mqtt for `tuya2ildevice.host`,  [test] for the tests
+```
+
+```python
+from tuya2ildevice import TuyaDriver, Connected, Message, Command, descriptor_of
+
+descriptor_of(device)                 # just the ildevice descriptor of a tuyadevices.json entry
+d = TuyaDriver(device)                # the state machine (il.md section 8)
+d.handle(now, Connected())            # -> [Descriptor]
+d.handle(now, Message("active", {"data": {"dps": {"1": True}}}))   # -> [Value(...), Event(...)]
+d.handle(now, Command("switch_1", "off"))    # -> [SendMessage("set", {"dps": {"1": False}})]  or  [Reject(...)]
+```
+
+## Packets and commands
+
+- `Message(channel, json)`: `active` (device push: fires events, accumulates `add_ele`-style deltas) or `passive` /
+  `state` (readback, snapshot: values only). Payload: `{"dps":{}}`, `{"data":{"dps":{}}}` or bare `{"1":true}`.
+- `Command(prop, value)` is checked as il.md section 5 says before anything is sent; failures come back as `Reject`.
+  Values convert as in Home Assistant core (brightness goes through 0..255; cover position is reversed unless
+  `control_back_mode` is `back`), so a written value can differ slightly from what is read back.
+- Covers of class garage/gate are read only unless `TuyaDriver(..., allow_hazardous=True)` (il.md S-1).
+- A dp no platform table claims gets no property, as in Home Assistant core; `TuyaDriver(..., expose_unused=True)` gives
+  each one a property chosen by its Tuya type (rustuya-homeassistant v1 did that). Integer, Enum and Boolean are writable only if the dp is
+  in `function`; String, Raw, Json and Bitmap are read-only. `config` if writable, else `diagnostic`.
+- Assembled: switch, button, select, number, sensor, binary_sensor, event, light, cover, fan, siren, valve,
+  humidifier, climate, alarm (kind `alarm`), vacuum. Not assembled: camera (a stream is outside the IL; `driver.unsupported` lists it).
+  A doorbell `alarm_message` event loses its message text (an ildevice event has only a kind).
+
+## User overrides
+
+`TuyaDriver(device, overrides=mapping)` / `Hub(devices, overrides=mapping)`; `mapping` is `{product_id or device id: block}`,
+already loaded (the host reads files; `merge_all([...])` merges several, later wins). Details and the block format are in
+[overrides.py](src/tuya2ildevice/overrides.py):
+
+```json
+{ "5rta89nj": {
+    "dp":     {"104": {"code": "percent_control", "type": "Integer", "values": {"min": 0, "max": 100, "scale": 0, "step": 1}}},
+    "remove": ["cycle_time"],
+    "props":  {"countdown_1": {"label": "Timer", "category": "config", "rw": false}},
+    "device": {"model": "Sliding Window Opener"} } }
+```
+
+`dp`, `remove`, `category` patch the schema before classification (a defined dp is classified like any other);
+`props` (by property name) and `device` patch the descriptor. Unknown keys raise `OverrideError`.
+`Hub.reload(mapping)` applies new overrides live: republishes changed descriptors and clears removed properties.
+`from_v1(custom_converters)` converts rustuya-homeassistant `dp_meta`; `discovery_overrides` (HA payload fields) are
+dropped with a warning.
+
+## Code converters
+
+The equivalent of v1's `custom_converters/*.py`: a per-device `Converter` object sees the driver's dp state on every
+packet and returns derived property values (and timer requests, since it cannot read a clock). See
+[converters.py](src/tuya2ildevice/converters.py).
+
+```python
+class MyConverter(Converter):
+    def props(self):  return {"motion": {"type": "select", "role": "motion", "options": ["opening", "closing", "stopped"]}}
+    def update(self, now, codes, changed, active):  return {"motion": "stopped"}      # or Result(values=..., timers=...)
+
+TuyaDriver(device, converters={"<product_id or device id>": [lambda device: MyConverter()]})
+```
+
+Built-in ones are named in an override block: `{"<product_id>": {"converters": {"cover_motion": {"settle": 5}}}}`.
+`cover_motion` (ported from v1's `00_curtain.py`) derives the cover's `motion` role (opening / closing / stopped) from the
+control, set-position and position dps; a snapshot never starts motion. Timers come out as `SetTimer` (driver) or
+`Schedule` (`Hub`); the host calls back with `Timer` / `hub.on_timer(now, id, name)`. Loading a user's `.py` file is the
+host's job; the code runs in-process.
+
+## rustuya-bridge <-> tuya2ildevice <-> an IL host over MQTT
+
+`Hub` ([mqtt.py](src/tuya2ildevice/mqtt.py)) owns one driver per device and maps both sides. Its methods take what was
+received and return `Publish(side, topic, payload, retain, qos)`; the host only executes them.
+`tuya2ildevice.host` is the host: `Runner` drives a `Hub` on two transports (`MqttTransport` over paho, or the in-process
+`InProcessTransport`), keeps the Last Will presence (M-12), reconnects, adds/removes devices while running
+(`set_device`, `remove_device`, `sync_devices`) and follows rustuya-manager's `tuyadevices.json` (`DeviceWatcher`).
+`read_bridge_config` + `BridgeTopics.from_config` take the topic layout the bridge announces on `{root}/bridge/config`.
+
+| direction | topic |
+|---|---|
+| bridge -> hub | `rustuya/event/{active,passive,state}/<id>` (dps JSON, or single-DP), `rustuya/error/<id>` (`errorCode` 0 = connected) |
+| hub -> bridge | `rustuya/command` `{"action":"set"/"get",...}` (a `get` after each connect) |
+| hub -> IL host | il-mqtt.md: retained `il/<id>` and `il/<id>/<prop>`; events and `il/<id>/reject` not retained; `il/_producer/tuya` presence |
+| IL host -> hub | `il/<id>/<prop>/set` (retained writes ignored) |
+
+Run the bridge with `mqtt_retain: true` and register the devices in it yourself (`add`); the hub never touches keys.
+
+## Layout
+
+```
+src/tuya2ildevice/
+  driver.py    TuyaDriver: packets/commands <-> outputs          io.py      inputs and outputs as data
+  assemble.py  engine entity plans -> ildevice props/roles       checks.py  il.md section 5 command checks
+  mqtt.py      Hub, BridgeTopics, IlTopics                       tuya/      the DP engine (see below)
+tuya/          classify + platforms, adapter (raw dps <-> values), quirks, ops, codecs, units
+tuya/tables/   per-platform description tables, generated from HA core     tuya/quirks/   from tuya-device-handlers
+tuya/data/     HA's allowed units per device class
+scripts/       generators for those data files, and golden/ (builds the golden data; needs HA core + oracle venvs)
+docs/          engine-spec.md (the engine's behaviour), analysis/ (how it was derived from HA core)
+tests/         golden/ = 324 HA core fixtures + core's own snapshots; chain/ = the same through an IL host's planner
+```
+
+The engine reproduces Home Assistant core's `tuya` integration exactly, including its quirks, and the golden tests
+pin it: `tests/golden/golden.json` is core's own entity snapshots for every fixture. To follow a new HA core /
+tuya-device-handlers release, run the generators in `scripts/` against it, then the tests; a difference is either
+a real change to adopt or a regression.
+
+## Tests
+
+```
+pip install -e .[test] && python -m pytest
+```
+
+`tests/test_adapter.py` compares the raw-dps adapter with the Tuya SDK and is skipped unless `tuya-device-sharing-sdk==0.2.15`
+is installed. The spec repository (`../ildevice`, or `$ILDEVICE`) supplies the schema and the language-neutral vectors
+(commands, wire values, topics) read directly from its checkout; those tests are skipped if it is not there. `tests/chain/`
+compares every Home Assistant core tuya fixture with core's entity snapshots through an IL host's HA-free planner
+(needs that host's `ildevice.core` on `sys.path`; not collected without it).

tuya2ildevice-0.1.0/README.md

@@ -0,0 +1,127 @@
+# tuya2ildevice
+
+The one place that interprets Tuya. Sans-IO Python: takes a Tuya device as [rustuya](https://github.com/3735943886/rustuya) /
+[rustuya-bridge](https://github.com/3735943886/rustuya-bridge) know it and produces an
+[ildevice](https://github.com/3735943886/ildevice): descriptor, live values and events from dps packets, and dps for
+ildevice commands. It opens no sockets and reads no clock. Other projects
+([rustuya-homeassistant](https://github.com/3735943886/rustuya-homeassistant), ildevice hosts,
+[rustuya-manager](https://github.com/3735943886/rustuya-manager)) import this instead of carrying their own Tuya knowledge.
+
+```
+pip install tuya2ildevice              # no dependencies;  tuya2ildevice[host] adds paho-mqtt for `tuya2ildevice.host`,  [test] for the tests
+```
+
+```python
+from tuya2ildevice import TuyaDriver, Connected, Message, Command, descriptor_of
+
+descriptor_of(device)                 # just the ildevice descriptor of a tuyadevices.json entry
+d = TuyaDriver(device)                # the state machine (il.md section 8)
+d.handle(now, Connected())            # -> [Descriptor]
+d.handle(now, Message("active", {"data": {"dps": {"1": True}}}))   # -> [Value(...), Event(...)]
+d.handle(now, Command("switch_1", "off"))    # -> [SendMessage("set", {"dps": {"1": False}})]  or  [Reject(...)]
+```
+
+## Packets and commands
+
+- `Message(channel, json)`: `active` (device push: fires events, accumulates `add_ele`-style deltas) or `passive` /
+  `state` (readback, snapshot: values only). Payload: `{"dps":{}}`, `{"data":{"dps":{}}}` or bare `{"1":true}`.
+- `Command(prop, value)` is checked as il.md section 5 says before anything is sent; failures come back as `Reject`.
+  Values convert as in Home Assistant core (brightness goes through 0..255; cover position is reversed unless
+  `control_back_mode` is `back`), so a written value can differ slightly from what is read back.
+- Covers of class garage/gate are read only unless `TuyaDriver(..., allow_hazardous=True)` (il.md S-1).
+- A dp no platform table claims gets no property, as in Home Assistant core; `TuyaDriver(..., expose_unused=True)` gives
+  each one a property chosen by its Tuya type (rustuya-homeassistant v1 did that). Integer, Enum and Boolean are writable only if the dp is
+  in `function`; String, Raw, Json and Bitmap are read-only. `config` if writable, else `diagnostic`.
+- Assembled: switch, button, select, number, sensor, binary_sensor, event, light, cover, fan, siren, valve,
+  humidifier, climate, alarm (kind `alarm`), vacuum. Not assembled: camera (a stream is outside the IL; `driver.unsupported` lists it).
+  A doorbell `alarm_message` event loses its message text (an ildevice event has only a kind).
+
+## User overrides
+
+`TuyaDriver(device, overrides=mapping)` / `Hub(devices, overrides=mapping)`; `mapping` is `{product_id or device id: block}`,
+already loaded (the host reads files; `merge_all([...])` merges several, later wins). Details and the block format are in
+[overrides.py](src/tuya2ildevice/overrides.py):
+
+```json
+{ "5rta89nj": {
+    "dp":     {"104": {"code": "percent_control", "type": "Integer", "values": {"min": 0, "max": 100, "scale": 0, "step": 1}}},
+    "remove": ["cycle_time"],
+    "props":  {"countdown_1": {"label": "Timer", "category": "config", "rw": false}},
+    "device": {"model": "Sliding Window Opener"} } }
+```
+
+`dp`, `remove`, `category` patch the schema before classification (a defined dp is classified like any other);
+`props` (by property name) and `device` patch the descriptor. Unknown keys raise `OverrideError`.
+`Hub.reload(mapping)` applies new overrides live: republishes changed descriptors and clears removed properties.
+`from_v1(custom_converters)` converts rustuya-homeassistant `dp_meta`; `discovery_overrides` (HA payload fields) are
+dropped with a warning.
+
+## Code converters
+
+The equivalent of v1's `custom_converters/*.py`: a per-device `Converter` object sees the driver's dp state on every
+packet and returns derived property values (and timer requests, since it cannot read a clock). See
+[converters.py](src/tuya2ildevice/converters.py).
+
+```python
+class MyConverter(Converter):
+    def props(self):  return {"motion": {"type": "select", "role": "motion", "options": ["opening", "closing", "stopped"]}}
+    def update(self, now, codes, changed, active):  return {"motion": "stopped"}      # or Result(values=..., timers=...)
+
+TuyaDriver(device, converters={"<product_id or device id>": [lambda device: MyConverter()]})
+```
+
+Built-in ones are named in an override block: `{"<product_id>": {"converters": {"cover_motion": {"settle": 5}}}}`.
+`cover_motion` (ported from v1's `00_curtain.py`) derives the cover's `motion` role (opening / closing / stopped) from the
+control, set-position and position dps; a snapshot never starts motion. Timers come out as `SetTimer` (driver) or
+`Schedule` (`Hub`); the host calls back with `Timer` / `hub.on_timer(now, id, name)`. Loading a user's `.py` file is the
+host's job; the code runs in-process.
+
+## rustuya-bridge <-> tuya2ildevice <-> an IL host over MQTT
+
+`Hub` ([mqtt.py](src/tuya2ildevice/mqtt.py)) owns one driver per device and maps both sides. Its methods take what was
+received and return `Publish(side, topic, payload, retain, qos)`; the host only executes them.
+`tuya2ildevice.host` is the host: `Runner` drives a `Hub` on two transports (`MqttTransport` over paho, or the in-process
+`InProcessTransport`), keeps the Last Will presence (M-12), reconnects, adds/removes devices while running
+(`set_device`, `remove_device`, `sync_devices`) and follows rustuya-manager's `tuyadevices.json` (`DeviceWatcher`).
+`read_bridge_config` + `BridgeTopics.from_config` take the topic layout the bridge announces on `{root}/bridge/config`.
+
+| direction | topic |
+|---|---|
+| bridge -> hub | `rustuya/event/{active,passive,state}/<id>` (dps JSON, or single-DP), `rustuya/error/<id>` (`errorCode` 0 = connected) |
+| hub -> bridge | `rustuya/command` `{"action":"set"/"get",...}` (a `get` after each connect) |
+| hub -> IL host | il-mqtt.md: retained `il/<id>` and `il/<id>/<prop>`; events and `il/<id>/reject` not retained; `il/_producer/tuya` presence |
+| IL host -> hub | `il/<id>/<prop>/set` (retained writes ignored) |
+
+Run the bridge with `mqtt_retain: true` and register the devices in it yourself (`add`); the hub never touches keys.
+
+## Layout
+
+```
+src/tuya2ildevice/
+  driver.py    TuyaDriver: packets/commands <-> outputs          io.py      inputs and outputs as data
+  assemble.py  engine entity plans -> ildevice props/roles       checks.py  il.md section 5 command checks
+  mqtt.py      Hub, BridgeTopics, IlTopics                       tuya/      the DP engine (see below)
+tuya/          classify + platforms, adapter (raw dps <-> values), quirks, ops, codecs, units
+tuya/tables/   per-platform description tables, generated from HA core     tuya/quirks/   from tuya-device-handlers
+tuya/data/     HA's allowed units per device class
+scripts/       generators for those data files, and golden/ (builds the golden data; needs HA core + oracle venvs)
+docs/          engine-spec.md (the engine's behaviour), analysis/ (how it was derived from HA core)
+tests/         golden/ = 324 HA core fixtures + core's own snapshots; chain/ = the same through an IL host's planner
+```
+
+The engine reproduces Home Assistant core's `tuya` integration exactly, including its quirks, and the golden tests
+pin it: `tests/golden/golden.json` is core's own entity snapshots for every fixture. To follow a new HA core /
+tuya-device-handlers release, run the generators in `scripts/` against it, then the tests; a difference is either
+a real change to adopt or a regression.
+
+## Tests
+
+```
+pip install -e .[test] && python -m pytest
+```
+
+`tests/test_adapter.py` compares the raw-dps adapter with the Tuya SDK and is skipped unless `tuya-device-sharing-sdk==0.2.15`
+is installed. The spec repository (`../ildevice`, or `$ILDEVICE`) supplies the schema and the language-neutral vectors
+(commands, wire values, topics) read directly from its checkout; those tests are skipped if it is not there. `tests/chain/`
+compares every Home Assistant core tuya fixture with core's entity snapshots through an IL host's HA-free planner
+(needs that host's `ildevice.core` on `sys.path`; not collected without it).

tuya2ildevice-0.1.0/docs/analysis/PHASE1_SYNTHESIS.md

@@ -0,0 +1,85 @@
+# Phase 1 synthesis: what HA core's tuya integration actually does
+
+Sources: HA core dev @ 949a484 (2026-09-19), tuya-device-handlers 0.0.29,
+tuya-device-sharing-sdk 0.2.15. Per-area catalogs (with file:line evidence) are
+catalog/A..F. Headline claims were spot-checked against source by the
+coordinator (PLATFORMS list, siren features, local_strategy usage, quirk count).
+
+## 1. Shape of the system
+
+    CustomerDevice (cloud schema: function / status_range / status)
+      -> quirk stage (by product_id; mutates schema/status/category)     [handlers]
+      -> category -> per-platform description tables                    [core]
+      -> definition (resolves dp codes + types into wrappers)           [handlers]
+      -> wrapper: read(status)->value ; write(value)->[{code,value}]    [handlers]
+      -> HA entity (thin)                                               [core]
+
+Handlers (7.1k lines) has NO homeassistant imports. Core (9.7k lines) holds the
+tables + thin entities. 18 platforms; lock / media_player / water_heater are NOT
+among them (lock-category devices register but create zero entities).
+
+## 2. Numbers
+
+- DeviceCategory 139 members (98 referenced; categories are open strings in fixtures)
+- DPCode 415 members
+- 617 literal entity descriptions (834 expanded); sensor alone 250/450
+- 32 quirk files (14 override kinds; 30 pure data, 3 code hooks)
+- 324 test fixtures, 285 produce entities (1205 total, quirks disabled), 39 produce none
+- only 16/324 fixtures carry local_strategy (numeric dp ids)
+
+## 3. Facts that constrain the IL
+
+1. Everything is keyed by dp CODE, never dp id. Schema = function + status_range
+   (type, range, scale, step, enum values). local_strategy is touched only by quirks.
+2. Entity existence = category table AND required dp codes present with required
+   type (tuple-of-candidates fallback, prefer_function toggle). No product_id
+   selection outside quirks. Some platforms have degenerate rules (climate: every
+   dbl/kt/qn/rs/wk/wkf device gets one even with no dps; vacuum: always for `sd`).
+3. Reads are pure; invalid raw values become None (unknown), not errors. One
+   stateful reader (delta accumulator, needs dp_timestamps).
+4. Writes are pure: value -> list of {code,value}; validated against schema.
+   Multi-dp writes exist only in light (ordered color+mode) and a few climate paths.
+5. Cross-dp rules exist: cover inversion depends on control_back_mode; alarm
+   TRIGGERED depends on master_state + decoded alarm_msg; light color mode depends
+   on work_mode; climate hvac_mode from switch+mode. Some read dps NOT in schema.
+6. Named fixed transforms needed: linear remap (with inversion), mired/Kelvin,
+   HSV json/hex codecs, unit conversion, electricity raw/json parsers, wind lookup,
+   bitmap bit/in-set, base64 utf8/raw, enum<->HA maps, many-to-one status maps.
+7. No optimistic state, no debounce; dp_timestamps only for the delta accumulator.
+   Availability = device online flag only.
+8. Quirks: keyed product_id; run before classification; add/replace/remove dp,
+   retype/rescale, category override, initial status map, TypeInformation class swap
+   per dpcode, apply_when predicate (code), feeder wrapper (code). Custom user
+   quirks are arbitrary Python files (out of scope for a data IL).
+9. Hard-coded literals live in code ("Sensor Low Battery", FZ/ZZ/STOP, chargego,
+   back) -- IL must carry them as data.
+10. Documented quirks of core itself: climate hvac_mode reads an unfiltered map (can
+    report a mode not in hvac_modes); cover open/close with a position dp sends only
+    position; unverified paths: cover tilt, mach_operate (no fixtures).
+
+## 4. Fit with our situation
+
+- Our registration cache already stores local_strategy + function + status_range
+  (const.py CONF_LOCAL_STRATEGY/FUNCTION/STATUS_RANGE), so core's actual required
+  input (function/status_range) IS available to us; tuya2ha today classifies from
+  local_strategy alone and ignores function/status_range types.
+- We need dp code <-> dp id translation on top (bridge speaks numeric dp ids);
+  the SDK also has 24 value-convert strategies (local raw -> cloud value) that
+  core assumes already applied. Whether the bridge's values need those is UNKNOWN
+  (SDK strategy implementations were not read).
+- Lock is outside "reuse of core knowledge": core has none. Needs another source.
+- Removable from IL scope: cloud auth/MQ, scenes, camera streaming, feeder
+  services, user-quirk plugins, optimistic state, debounce.
+
+## 5. Decisions the IL design needs from the user
+
+D1. Fidelity target: reproduce core exactly (including its quirks like the climate
+    unfiltered map) vs. reproduce intended behavior.
+D2. Schema source contract: require function/status_range (like core) with
+    local_strategy for dp-id mapping, vs. keep tuya2ha's local_strategy-only mode too.
+D3. Do SDK value-convert strategies need porting (blocked on live verification).
+D4. Quirk scope: data-only quirks in IL (30/32) + small declarative predicate
+    language, or also code hooks.
+D5. Lock/media_player/etc: out of scope, or source knowledge elsewhere (tuya-local
+    yaml corpus / own design).
+D6. Golden tests: use core's snapshots as-is (quirks off) and add quirk-on cases.