docs(k1): record connection mode acceptance

This commit is contained in:
DCCONSTRUCTIONS
2026-07-19 09:52:33 +03:00
parent 57b2208cae
commit 75d2e5da4b
9 changed files with 131 additions and 22 deletions
+14 -10
View File
@@ -4,14 +4,17 @@ This directory is the plugin-local, versioned compatibility vocabulary for
verified K1 wire behavior. It is deliberately **not** a platform ontology and
does not add runtime dependencies on NODE.DC Ontology Core.
The first profile is
[`fw-3.0.2/direct-lan.v1.json`](fw-3.0.2/direct-lan.v1.json). It matches exactly:
The active profile is
[`fw-3.0.2/local-network.v2.json`](fw-3.0.2/local-network.v2.json). It matches exactly:
- model: XGRIDS LixelKity K1;
- firmware: `3.0.2`;
- topology: K1 and connector on the same owner-controlled LAN;
- evidence scope: one physical scanner across controlled direct-LAN and
owner-operated LixelGO/iPhone laboratory runs.
- topology matrix: Bridge (`direct-lan`), Quick Connect (`device-ap`) and
Direct Connect (`controller-hotspot`);
- evidence scope: one physical scanner across Mission Core Bridge and
owner-operated LixelGO/iPhone Quick Connect runs. The Direct Connect adapter
reuses the same physically accepted 99-byte BLE Wi-Fi frame, but its complete
Mission Core path still awaits a separate physical acceptance run.
It must not be applied to another firmware or treated as a vendor API claim.
Unknown firmware fails closed.
@@ -63,14 +66,15 @@ The loader uses only the Python standard library and performs no device I/O:
python plugins/xgrids-k1/profile_loader.py
```
It verifies the exact firmware/topology scope, evidence vocabulary, source
references, GATT UUIDs, MQTT subscribe-only boundary, channel evidence, camera
RTSP/H.264 endpoints, operator-manual acquisition, and disabled vendor request
mappings.
It verifies the exact firmware/topology matrix, each mode's bounded network
actions, evidence vocabulary, source references, GATT UUIDs, local MQTT
boundary, channel evidence, camera RTSP/H.264 endpoints, operator-manual
acquisition, and disabled descriptive-profile vendor request mappings.
## Evolution rules
1. A different firmware or topology gets a new profile file and profile ID.
1. A different firmware or connection topology gets a new profile file and
profile ID unless it is added through another evidence-backed schema revision.
2. New evidence may only promote the flags supported by retained raw evidence,
a documented decoder/replay check, or a physical lab report.
3. Unknown fields remain explicit; they are never filled from naming or payload