oep-client-python 0.0.43__tar.gz → 0.0.45__tar.gz

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/CHANGELOG.md

@@ -2,6 +2,124 @@
 
 ## Unreleased
 
+## 0.0.45
+- (EN) Added: `oep_client.memo` for `oep.probe.memo` (oep-if-memo): list (paged, by prefix), read and write in parts at the
+  route's max_frame, delete; a read whose data does not match its crc raises MemoTorn. `oep dump` names the interface and
+  its max_object / max_objects. Registry and documents synced from oep-spec 2cd20aa (the memo interface; MUSTs that only
+  touch quality relaxed to SHOULD); the conformance checkers' pins moved with it after a review (none checks a relaxed rule).
+- (JA) 追加: `oep.probe.memo`（oep-if-memo）の `oep_client.memo`。list（ページ分け、prefix）、経路の max_frame に合わせて分ける read と
+  write、delete。データが crc と合わない read は MemoTorn。`oep dump` がこのインターフェースと max_object / max_objects を示す。registry と
+  文書を oep-spec 2cd20aa から同期した（メモ欄。品質だけにかかわる必須を推奨にした）。適合の検査の固定は、見直して合わせた（緩めた規則を
+  確かめる検査は無い）。
+- (EN) Fixed (tests/hw): capture_repeat_rearm configured 100 kHz whatever the probe declared, so a probe whose lowest rate
+  is above it (ESP32-P4: 627 kHz) refused the rate and the test skipped as if rearm were missing. It takes a declared
+  rate, and skips only when trigger_opts is the refused tag. It passes on ESP32-P4 and P4X probes.
+- (JA) 修正（tests/hw）: capture_repeat_rearm は probe の宣言によらず 100 kHz で configure していたので、最も遅いレートがそれより速い
+  probe（ESP32-P4: 627 kHz）ではレートで断られ、rearm が無いかのように skip していた。宣言したレートを使い、断られた tag が
+  trigger_opts のときだけ skip する。ESP32-P4 と P4X のプローブで通る。
+- (EN) Added: `python -m oep_client.conformance.release_hw` checks electrically that a released pin goes back to its idle
+  state whatever released it (core §8, §9, §6.4): the channel's idle is set to pull-up / pull-down, fixture gpio drives the
+  line the other way, and a CH32 target's GPIO input, read over the probe's debug wire, must read the drive and then the
+  pull after plan_release, end, another id's force and the lease running out. All eight pass on an ESP32-P4 probe with a
+  CH32X035.
+- (JA) 追加: `python -m oep_client.conformance.release_hw` は、どの道で解いても解いたピンが空きの状態に戻ることを電気的に確かめる
+  （core §8、§9、§6.4）: channel の idle を pull-up / pull-down にし、fixture gpio で逆に駆動し、プローブの debug の線で読む CH32 の
+  target の GPIO の入力が、駆動を読み、plan_release、end、別の id の force、lease の期限切れの後にプルを読む。ESP32-P4 のプローブと
+  CH32X035 で 8 つとも通る。
+- (EN) Added: `python -m oep_client.conformance.notify_hw` checks subscriptions and notifications on a real probe
+  (core §10, §9, §6.4; transports §3) with a logic capture streaming on one channel the user names: subscribe needs the
+  lock, unsubscribe with none succeeds, seq from 0 one by one with positions back to back, answers first while it
+  streams, a new subscribe restarts seq, max_delay_ms batches, nothing on another route, nothing after end or a force.
+  All nine pass on ESP32-P4 and P4X probes.
+- (JA) 追加: `python -m oep_client.conformance.notify_hw` は、利用者が名指した 1 本の線でロジックのキャプチャをストリーミングさせ、
+  実機で購読と通知を確かめる（core §10、§9、§6.4、transports §3）: subscribe はロックが要る、購読が無い unsubscribe は成功、seq は 0 から
+  1 ずつで position は途切れない、ストリーミング中も応答が先、subscribe し直すと seq は 0 から、max_delay_ms でまとめて送る、ほかの
+  経路には届かない、end と force の後は届かない。ESP32-P4 と P4X のプローブで 9 つとも通る。
+- (EN) Added: `python -m oep_client.conformance.force_hw` checks on a real probe that force releases the resources of the
+  session it takes from (core §6.4, §9): S attaches to a target (a debug connection), T of another id opens with force;
+  S's connection is gone from connections, its number is no_resource, S's keepalive is refused, and T's attach gets a new,
+  larger number. It passes on an ESP32-P4 probe with a CH32V208 over rvswd.
+- (JA) 追加: `python -m oep_client.conformance.force_hw` は、実機で force が奪ったセッションの資源を解放することを確かめる（core §6.4、
+  §9）: S が target に attach し（debug の接続）、別の id の T が force で open する。S の接続は connections から消え、その番号は
+  no_resource、S の keepalive は断られ、T の attach は新しい大きい番号になる。ESP32-P4 のプローブと rvswd の CH32V208 で通る。
+- (EN) Added: the two-route checks (one lock seen from both routes, another session's open refused locked with its owner,
+  an answer only on the route of its request; transports §3) run on any second route, not only a second TCP connection:
+  `usb_hw --peer hid|bulk` opens the other USB kind of the same device, `--peer-port` its OEP CDC port (CORE-ROUTE-PEER-*).
+  They pass on ESP32-P4 and P4X probes for bulk with HID and bulk with CDC.
+- (JA) 追加: 2 つの経路の検査（どちらの経路からも同じ 1 つのロックが見え、別のセッションの open は持ち主つきの locked で断られ、
+  答えは要求の来た経路にだけ返る。transports §3）を、2 本目の TCP の接続だけでなく、どの経路でも回す: `usb_hw --peer hid|bulk` は同じ
+  device のもう一方の USB の経路を、`--peer-port` はその OEP の CDC の口を開く（CORE-ROUTE-PEER-*）。ESP32-P4 と P4X のプローブで、bulk と
+  HID、bulk と CDC の組で通る。
+- (EN) Added: oep-conformance runs the reconnect checks over TCP too (a new connection is the route moving, transports §3):
+  the session, its lock, its replay record and its lease outlive the connection. New check CORE-RECONNECT-UNREAD (serial
+  and TCP): a request whose answer is lost with the closed route is resent on the new one and comes back as the recorded
+  answer or result_lost, never run again (core §5.1; a recorded clock answer is told by its uptime). The virtual bench's
+  loopback TCP passes all five.
+- (JA) 追加: oep-conformance は、接続し直しの検査を TCP でも回す（新しい接続は経路の移動、transports §3）: セッション、ロック、再送の
+  記録、lease は接続より長く残る。新しい検査 CORE-RECONNECT-UNREAD（シリアルと TCP）: 閉じた経路で答えを失った要求を新しい経路で
+  送り直すと、記録した答えか result_lost が返り、二度は実行されない（core §5.1。記録した clock の答えは uptime で分かる）。仮想ベンチの
+  loopback の TCP は 5 つとも通る。
+- (EN) Added: `python -m oep_client.conformance.usb_hw` runs the raw bulk / HID checks on a real probe, named by
+  VID:PID and its serial number (the unit id), under the shared lock; it checks the USB descriptors too (serial = unit
+  id, one OEP vendor interface with one bulk pair, one OEP HID with one report ID, MS OS 2.0 WINUSB as a SHOULD). New
+  check CORE-USB-IN-END: answers framed to exactly one and two IN packets (oep.probe.link's source) must arrive without
+  more data after them (transports §1, the probe's last transfer ended). On ESP32-P4 and P4X probes every bulk and HID
+  check passes.
+- (JA) 追加: `python -m oep_client.conformance.usb_hw` は、VID:PID と serial number（unit id）で名指した実機に、共通のロックを取って、
+  bulk / HID の生の検査を回す。USB の descriptor も確かめる（serial が unit id、OEP の vendor interface が 1 つで bulk が 1 組、OEP の HID が
+  1 つで report ID が 1 つ、MS OS 2.0 の WINUSB は SHOULD）。新しい検査 CORE-USB-IN-END: 枠がちょうど IN packet 1 個分と 2 個分の答え
+  （oep.probe.link の source）が、続く data なしで届くこと（transports §1、probe の最後の転送の終わり）。ESP32-P4 と P4X のプローブで、
+  bulk と HID の検査はすべて通る。
+- (EN) Docs: the rule-by-rule trace (docs/trace) names the tests as they are now (the subject-named modules, no review
+  rounds or item numbers; the later-copy tests as the refusal tests that replaced them), and core §2.3's rows follow the
+  spec's split of the twice-sent tag into requests (malformed) and answers (the first is used). tools/check_trace.py
+  passes on oep-spec 3b6dbbc.
+- (JA) 文書: 規則ごとの対応表（docs/trace）は、今の試験の名前を指す（主題で名付けたモジュール、回や項目の番号なし。後の写しの試験は、
+  置き換えた断りの試験）。core §2.3 の行は、2 回送られた tag を要求（malformed）と応答（最初を使う）に分けた仕様に合わせた。
+  tools/check_trace.py は oep-spec 3b6dbbc で通る。
+- (EN) Removed: capture's optional features no probe implemented, as oep-spec 3b6dbbc drops them. `configure` no longer
+  takes `format_name`, and its `options` take only `glitch_filter` (group 0) and `clock`; `Config.format_name` and the
+  `threshold_used`, `coupling_used`, `offset_used`, `bandwidth_used`, `resolution_used` and `oversample_used` entries of
+  `Config.used` are gone. The virtual bench no longer offers the external data paths (`Endpoint.external_disconnect`,
+  `virtual_bench.EXTERNAL_TCP_PORT` / `EXTERNAL_UDP_PORT`), the named format (`NAMED_FORMAT`) or the analog front-end
+  settings; `with_capture_options` adds format 3, the external clock and the glitch filter to the logic track. The spec
+  snapshot follows 3b6dbbc, the trace's capture rows follow the spec's sections (§0, §3.8, trigger records at §3.9), and
+  the host-request checker's reviewed pins move with it.
+- (JA) 削除: oep-spec 3b6dbbc に合わせ、どの probe も持たなかった capture の任意の機能を外した。`configure` は `format_name` を
+  取らず、`options` は `glitch_filter`（群 0）と `clock` だけを取る。`Config.format_name` と、`Config.used` の `threshold_used`、
+  `coupling_used`、`offset_used`、`bandwidth_used`、`resolution_used`、`oversample_used` は無くなった。仮想ベンチは、データの外部の
+  経路（`Endpoint.external_disconnect`、`virtual_bench.EXTERNAL_TCP_PORT` / `EXTERNAL_UDP_PORT`）、名前付きの形式（`NAMED_FORMAT`）、
+  アナログの前段の設定を出さない。`with_capture_options` は、ロジックのトラックに形式 3、外部クロック、グリッチフィルタを足す。仕様の
+  写しは 3b6dbbc に合わせ、対応表の capture の行は仕様の節（§0、§3.8、トリガの記録は §3.9）に合わせ、host の要求の検査器の
+  固定もそれに移した。
+- (EN) Tests: the spec snapshot (vectors, registry, the documents' digests) follows oep-spec b8d63c6, and the conformance
+  checkers' reviewed pins move with it: the core, capture and fixture changes since are wording only (a §0 heading, the
+  state table's stopped 2, the critical-bit sentence, no product names). The core checker passes on an ESP32-P4 probe.
+- (JA) 試験: 仕様の写し（ベクタ、registry、文書のハッシュ）を oep-spec b8d63c6 に合わせ、適合の検査器の固定も移した。core、capture、
+  fixture のその間の変更は文言だけ（§0 の見出し、状態の表の stopped 2、critical の bit の文、製品名の削除）。core の検査器は
+  ESP32-P4 のプローブで通る。
+- (EN) Docs: comments, docstrings and documents cite the spec's sections as they are now (core §10 for notifications,
+  §5.1 for resending, plan §2.4, restart §2, link §3). The port_speed procedure, once host guide §17 and now this
+  client's own, is cited as the README's section. `acquire` takes describe's tags and the trigger types from the
+  registry instead of writing their numbers.
+- (JA) 文書: 注釈、docstring、文書は、仕様の今の節を指す（通知は core §10、再送は §5.1、plan §2.4、restart §2、link §3）。
+  前は host ガイド §17 にあり今はこの client 自身のものになった port_speed の手順は、README の節として指す。`acquire` は describe の
+  tag とトリガの型を、番号を書かずに registry から引く。
+
+## 0.0.44
+- (EN) Changed: `targets` names the CH32V20x family `ch32v20x` (was `ch32v203`) and knows the CH32V208 by its target_id
+  (top 12 bits 0x208; a CH32V208WBU6 measured), so `oep pins` identifies it and maps its pads; the CH32V203's id is not
+  recorded yet. The module and `oep pins` no longer point to documents oep-spec no longer has.
+- (JA) 変更: `targets` は CH32V20x の系列を `ch32v20x` と呼び（前は `ch32v203`）、CH32V208 を target_id（上位 12 ビット 0x208。
+  CH32V208WBU6 で測定）で知る。`oep pins` が識別してパッドを map できる。CH32V203 の id はまだ記録していない。モジュールと `oep pins`
+  は、oep-spec に今は無い文書を指さなくなった。
+- (EN) Docs: the conformance, testing and hardware documents describe the current state only (no interim wording, no
+  pinned commits; how checkers pin the reviewed spec is in docs/conformance-spec-compatibility.ja.md). The README no longer
+  calls the client experimental. `tests/test_conformance_reviewed_pins.py` also checks the capture-serial checker's pins.
+- (JA) 文書: 適合検査、テスト方針、実機設定の文書を今の状態だけにした（途中の状態の言葉と、固定した commit の番号を外した。
+  検査器がレビュー済みの仕様に固定する仕方は docs/conformance-spec-compatibility.ja.md）。README の「実験段階」を外した。
+  `tests/test_conformance_reviewed_pins.py` は capture-serial の検査器の固定も確かめる。
+
 ## 0.0.43
 - (EN) Added: `Host.open`, `Host.take` and `core.take` take `extensions` - named extensions (a name, or (name, data))
   carried on the open after the owner, sent critical, so a probe that does not know one refuses it (`Unsupported`, its
@@ -522,7 +640,7 @@
     missing bits 0); read_rx's ns is when CS went inactive (I2C: the STOP or next START).
   - Virtual bench: the configure contract and answer rows, wrapping generations and serials, generations on every
     event and in the group's start answer / status, marks and segments paging, release by core §2.6, step's zeros,
-    spi-target masking and an optional ns (`Endpoint.spi_ns`). New tests/test_spec_2c6d18d.py; the new vectors and
+    spi-target masking and an optional ns (`Endpoint.spi_ns`). New tests/test_capture_generation_rules.py; the new vectors and
     ops.json `events` run both ways (arm-adi's probe side skipped: the virtual bench has no arm-adi).
 - (JA) **oep-spec 0098b56〜2c6d18d（0991759 の外部レビューのインターフェース再確認）に合わせた。** registry と vectors を同期し、
   README は 2c6d18d を名乗る。壊れる変更（wire と API）:
@@ -544,7 +662,7 @@
     read_rx の ns は CS が無効になった時刻（I2C は STOP か次の START）。
   - 仮想ベンチ: configure の契約と応答の行、一周する世代と serial、どの出来事にも世代、組の start の応答と status の世代、marks と
     segments のページング、core §2.6 での release、step の 0、spi-target のビットの消去と任意の ns（`Endpoint.spi_ns`）。
-    tests/test_spec_2c6d18d.py を足した。新しい vectors と ops.json の `events` を両側から通す（arm-adi の probe 側は飛ばす: 仮想ベンチに
+    tests/test_capture_generation_rules.py を足した。新しい vectors と ops.json の `events` を両側から通す（arm-adi の probe 側は飛ばす: 仮想ベンチに
     arm-adi は無い）。
 - (EN) **`oep find` and `discovery.find_unit` verify what they find (oep-spec 0991759, host guide §4.1).** The DNS-SD
   service name `oep` is not registered, so another service may advertise `_oep._tcp`. `discovery.verify(found)` checks
@@ -776,7 +894,7 @@
   - oep-if-link / host guide §17 (44aa045): the sink count is max_frame - 12, which this client already sends
     (`core.link_sink_size`); nothing changed.
   - The tests run with `OEP_SESSION_DIR` in a temporary directory (tests/conftest.py; tests/hw keeps the real one).
-    New tests/test_spec_283e5b5.py. README / tests/hw README (EN / JA).
+    New tests/test_transport_session_rules.py. README / tests/hw README (EN / JA).
 - (JA) **oep-spec 283e5b5〜f8bb2de**（2026-10-07 の外部レビューの再確認と、その後の直し）。README は `f8bb2de` を名乗る。registry と
   ベクタを写した（`tools/sync_registry.sh`）: `resend_max` は無くなった（送り直しは host が決める。この client の送り直し - 待ちの後に
   1 回、持っているシリアルの口で壊れたフレームが来たらすぐ 3 回まで - はそのまま）。`interface_name_max_bytes` は 64 -> 48
@@ -801,7 +919,7 @@
   - oep-if-link / host ガイド §17（44aa045）: sink の count は max_frame − 12 で、この client はもとからそれを送る（`core.link_sink_size`）。
     変更なし。
   - 試験は `OEP_SESSION_DIR` を一時の場所にして走る（tests/conftest.py。tests/hw は本当の場所のまま）。新しい
-    tests/test_spec_283e5b5.py。README と tests/hw の README（EN / JA）。
+    tests/test_transport_session_rules.py。README と tests/hw の README（EN / JA）。
 - (EN) **Breaking (API, CLI): the fake probe is the virtual bench**, with no aliases (pre-freeze). The virtual bench is a
   probe, the targets behind it and the fixture wiring, modelled after the real jigs: the environment host software is
   tested in. "Bench" alone still means the real HIL jigs. Renamed: module `oep_client.fake` -> `oep_client.virtual_bench`,

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: oep-client-python
-Version: 0.0.43
+Version: 0.0.45
 Summary: Open Embedded Probe (OEP) v1 host: serial / USB / TCP transports, the session rules, the standard interfaces, and a virtual bench
 Project-URL: Homepage, https://github.com/Open-Embedded-Probe/oep-client-python
 Project-URL: Repository, https://github.com/Open-Embedded-Probe/oep-client-python
@@ -31,11 +31,10 @@ Description-Content-Type: text/markdown
 
 The host side of Open Embedded Probe (OEP). It speaks the v1 protocol of
 [oep-spec](https://github.com/Open-Embedded-Probe/oep-spec) (the core `docs/oep-core.ja.md`, `docs/oep-transports.ja.md`
-and the interfaces `interfaces/*.ja.md`), v1 before the freeze: until the freeze the spec may still break. The wire numbers come from `oep_client.registry`, a verbatim copy of
-oep-spec's generated `generated/oep-v1/oep_v1_registry.py`. This is an experimental stage: breaking changes are expected and
-no compatible API is promised.
+and the interfaces `interfaces/*.ja.md`). The wire numbers come from `oep_client.registry`, a verbatim copy of
+oep-spec's generated `generated/oep-v1/oep_v1_registry.py`.
 
-**The spec this implements: the oep-spec commit in `tests/vectors/SPEC_COMMIT`** (no `v0.x` tag yet; oep-spec versioning §2 / §6 - before the
+**The spec this implements: the oep-spec commit in `tests/vectors/SPEC_COMMIT`** (oep-spec versioning §2 / §6: before the
 freeze, revision 1 alone does not fix the forms, so an implementation names the spec commit it implements). The registry
 and the shared vectors in `tests/vectors/` are copied from that commit; the history is in [CHANGELOG.md](CHANGELOG.md).
 
@@ -66,7 +65,7 @@ sets the version in pyproject.toml, uv.lock and `oep_client.__version__` and tur
 the tests and the build it commits, tags, makes the GitHub Release and publishes to PyPI (Trusted Publishing). Record changes
 under Unreleased in CHANGELOG.md, (EN) and (JA).
 
-A minimal check: [hardware quickstart](docs/hardware-quickstart.ja.md). See the shared [testing policy](docs/testing-policy.ja.md) and [guide for projects using OEP](docs/testing-consumers.ja.md). The [hardware design](docs/hardware-configuration.ja.md) and [configuration examples](docs/hardware-schema.ja.md) describe the planned format; its offline validator/planner is available; integration with the hardware runner is pending. These working documents are in Japanese.
+A minimal check: [hardware quickstart](docs/hardware-quickstart.ja.md). See the shared [testing policy](docs/testing-policy.ja.md) and [guide for projects using OEP](docs/testing-consumers.ja.md). Equipment configuration: [hardware design](docs/hardware-configuration.ja.md) and [configuration examples](docs/hardware-schema.ja.md) (in Japanese).
 
 ## Modules (`oep_client`)
 
@@ -500,4 +499,3 @@ IP_MULTICAST_IF 127.0.0.1. A different `--unit-id` per job keeps parallel jobs a
 name too). A container or VM answers only on its own network. tests/test_virtual_bench_announce.py does this with
 `oep find`, `discovery.find_unit` and `oep://UNIT_ID?via=net` (both engines) - with in-process responders announcing a non-OEP
 TCP service and a wrong TXT unit_id beside it, which the verify drops - skipped where multicast does not loop back.
-

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/README.ja.md

@@ -2,11 +2,10 @@
 
 [English](README.md)
 
-Open Embedded Probe の host 側。v1（oep-spec の本体 `docs/oep-core.ja.md`、`docs/oep-transports.ja.md` とインターフェース `interfaces/*.ja.md`）を話す。凍結の前の v1 で、凍結までは仕様が壊れることがある。番号は oep-spec の
-`generated/oep-v1/oep_v1_registry.py` をそのまま写した `oep_client.registry` から取る。破壊的変更を前提とする
-実験段階で、互換 API は約束しない。
+Open Embedded Probe の host 側。v1（oep-spec の本体 `docs/oep-core.ja.md`、`docs/oep-transports.ja.md` とインターフェース `interfaces/*.ja.md`）を話す。番号は oep-spec の
+`generated/oep-v1/oep_v1_registry.py` をそのまま写した `oep_client.registry` から取る。
 
-**実装する仕様: `tests/vectors/SPEC_COMMIT` にある oep-spec の commit**（`v0.x` のタグはまだ無い。oep-spec versioning §2 / §6: 凍結の前は revision 1 だけでは
+**実装する仕様: `tests/vectors/SPEC_COMMIT` にある oep-spec の commit**（oep-spec versioning §2 / §6: 凍結の前は revision 1 だけでは
 形が決まらないので、実装は自分が実装する仕様の commit を名乗る）。番号の表と `tests/vectors/` の共有ベクタはその commit から写したもの。
 変更の履歴は [CHANGELOG.md](CHANGELOG.md) にある。
 
@@ -33,7 +32,7 @@ HEAD 以外の commit を選べる。commit とファイルの hash は `tests/v
 pyproject.toml、uv.lock、`oep_client.__version__` を書き換え、CHANGELOG.md の Unreleased をその版にし、試験と build の後に commit と tag、
 GitHub Release、PyPI（Trusted Publishing）へ出す。変更は CHANGELOG.md の Unreleased に (EN) / (JA) で書き足しておく。
 
-最小構成の確認は [動作確認手順](docs/hardware-quickstart.ja.md)。共通の [テスト方針](docs/testing-policy.ja.md) と [OEP を使うプロジェクトのガイド](docs/testing-consumers.ja.md) も見る。[構成設計](docs/hardware-configuration.ja.md)と[設定形式・雛形](docs/hardware-schema.ja.md)は予定の形式を書く（offline の検査・計画は実装あり、実機の runner との連携は未実装）。
+最小構成の確認は [動作確認手順](docs/hardware-quickstart.ja.md)。共通の [テスト方針](docs/testing-policy.ja.md) と [OEP を使うプロジェクトのガイド](docs/testing-consumers.ja.md) も見る。設備の設定は[構成設計](docs/hardware-configuration.ja.md)と[設定形式・雛形](docs/hardware-schema.ja.md)にある。
 
 ## モジュール（`oep_client`）
 
@@ -414,4 +413,3 @@ multicast の経路が無い host では `--announce-on 127.0.0.1` にし、問
 tests/test_virtual_bench_announce.py がこれを `oep find`、`discovery.find_unit`、`oep://UNIT_ID?via=net`（両方の engine）で試す（同じ process の responder が、OEP でない TCP の
 サービスと違う TXT の unit_id を並べて広告し、確かめでそれが外れることも見る）。multicast が
 戻らない所では skip する。
-

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/README.md

@@ -4,11 +4,10 @@
 
 The host side of Open Embedded Probe (OEP). It speaks the v1 protocol of
 [oep-spec](https://github.com/Open-Embedded-Probe/oep-spec) (the core `docs/oep-core.ja.md`, `docs/oep-transports.ja.md`
-and the interfaces `interfaces/*.ja.md`), v1 before the freeze: until the freeze the spec may still break. The wire numbers come from `oep_client.registry`, a verbatim copy of
-oep-spec's generated `generated/oep-v1/oep_v1_registry.py`. This is an experimental stage: breaking changes are expected and
-no compatible API is promised.
+and the interfaces `interfaces/*.ja.md`). The wire numbers come from `oep_client.registry`, a verbatim copy of
+oep-spec's generated `generated/oep-v1/oep_v1_registry.py`.
 
-**The spec this implements: the oep-spec commit in `tests/vectors/SPEC_COMMIT`** (no `v0.x` tag yet; oep-spec versioning §2 / §6 - before the
+**The spec this implements: the oep-spec commit in `tests/vectors/SPEC_COMMIT`** (oep-spec versioning §2 / §6: before the
 freeze, revision 1 alone does not fix the forms, so an implementation names the spec commit it implements). The registry
 and the shared vectors in `tests/vectors/` are copied from that commit; the history is in [CHANGELOG.md](CHANGELOG.md).
 
@@ -39,7 +38,7 @@ sets the version in pyproject.toml, uv.lock and `oep_client.__version__` and tur
 the tests and the build it commits, tags, makes the GitHub Release and publishes to PyPI (Trusted Publishing). Record changes
 under Unreleased in CHANGELOG.md, (EN) and (JA).
 
-A minimal check: [hardware quickstart](docs/hardware-quickstart.ja.md). See the shared [testing policy](docs/testing-policy.ja.md) and [guide for projects using OEP](docs/testing-consumers.ja.md). The [hardware design](docs/hardware-configuration.ja.md) and [configuration examples](docs/hardware-schema.ja.md) describe the planned format; its offline validator/planner is available; integration with the hardware runner is pending. These working documents are in Japanese.
+A minimal check: [hardware quickstart](docs/hardware-quickstart.ja.md). See the shared [testing policy](docs/testing-policy.ja.md) and [guide for projects using OEP](docs/testing-consumers.ja.md). Equipment configuration: [hardware design](docs/hardware-configuration.ja.md) and [configuration examples](docs/hardware-schema.ja.md) (in Japanese).
 
 ## Modules (`oep_client`)
 
@@ -473,4 +472,3 @@ IP_MULTICAST_IF 127.0.0.1. A different `--unit-id` per job keeps parallel jobs a
 name too). A container or VM answers only on its own network. tests/test_virtual_bench_announce.py does this with
 `oep find`, `discovery.find_unit` and `oep://UNIT_ID?via=net` (both engines) - with in-process responders announcing a non-OEP
 TCP service and a wrong TXT unit_id beside it, which the verify drops - skipped where multicast does not loop back.
-

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/README.ja.md

@@ -2,9 +2,9 @@
 
 | 文書 | 対象と状態 |
 |---|---|
-| [最小構成の動作確認](hardware-quickstart.ja.md) | 現在動く validate/plan/仮想 smoke と `.env` の実行手順 |
+| [最小構成の動作確認](hardware-quickstart.ja.md) | validate/plan/仮想 smoke と `.env` の実行手順 |
 | [SPECからの適合検査](conformance-checks.ja.md) | core / interfaceの公開検査器と実行範囲 |
-| [lease・forceの大枠検査](session-smoke-conformance.ja.md) | 明示time/resource adapterで循環corr作業版の期限・再送・所有者交代を確認 |
+| [lease・forceの大枠検査](session-smoke-conformance.ja.md) | 明示time/resource adapterでleaseの期限・再送・所有者交代を確認 |
 | [有限保持の通知出力](notification-output-sample.ja.md) | 限定raw fixtureで購読拒否・seq抜け・部分frame・応答優先を確認 |
 | [Host TLVの読出し検査](host-tlv-conformance.ja.md) | 明示readerアダプタで未知tag・critical・重複・破損と長さ境界を確認 |
 | [Host通知と期限](host-notification-conformance.ja.md) | 現SPECのrole振り分け、未知kindのseq、通知が続く時の応答待ち/pumpを確認 |
@@ -14,11 +14,11 @@
 | [core発見処理の検査](discovery-conformance.ja.md) | list/fn 0 describeの任意cursor、labelと宣言の不変性を確認 |
 | [資源番号の上限](allocator-conformance.ja.md) | 明示seedでu16上限、解放後の非再利用、再送と再起動を確認 |
 | [通知seqと再購読](notification-sequence-conformance.ja.md) | 論理経路でseqの一周・drop・購読置換・再送を確認 |
-| [raw USB検査](usb-conformance.ja.md) | bulk/HIDの独立検査器と最小ソフトウェアモデル。実機raw adapterは未実装 |
-| [全体テスト方針](testing-policy.ja.md) | OEP と利用プロジェクトの保証対象、責任、改修計画 |
+| [raw USB検査](usb-conformance.ja.md) | bulk/HIDの独立検査器と最小ソフトウェアモデル |
+| [全体テスト方針](testing-policy.ja.md) | OEP と利用プロジェクトの保証対象と責任 |
 | [利用プロジェクト向けガイド](testing-consumers.ja.md) | 任意の言語・target・framework で OEP を使う側のテスト手順 |
 | [構成と配線の確定](hardware-configuration.ja.md) | 個体、探索、確認済み接続、役割、共有制御の設計 |
-| [実機設定形式](hardware-schema.ja.md) | 公開のキーと判定、入力と確定 TOML、`.env` の雛形。offline 初期実装あり、実機連携は未実装 |
-| [現行 Python 実機ハーネス](../tests/hw/README.ja.md) | 現在使用できる設定と手順、新形式への移行事項 |
+| [実機設定形式](hardware-schema.ja.md) | 公開のキーと判定、入力と確定 TOML、`.env` の雛形 |
+| [Python 実機ハーネス](../tests/hw/README.ja.md) | 設定と手順 |
 
 ここにある文書の保守窓口は oep-client-python です。保証と合否の所有者は各実装に分かれ、通信の規範は oep-spec に置きます。全体方針はプロジェクト共通で、Python のテストだけの説明ではありません。実設備の台帳は外部で管理し、runner へ明示設定で渡します。

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/allocator-conformance.ja.md

@@ -18,7 +18,7 @@ privateベンチや隣接checkoutは探索しない。資源opの符号化はres
 境界seed 0xFFFFFFFE/0xFFFFFFFFと時計はlogical fixtureの明示制御であり、実機opではない。
 seedを設定するのはfresh/空のallocatorだけ。この検査で2^32−1回の実割当を行ったとは主張しない。
 通常の容量不足と区別し、sample容量8に対して同時資源は最大2で試す。
-予約だけで失敗した番号を欠番にしてよい規則は変更せず、一般の作成失敗でnext_id不変は要求しない。
+予約だけで失敗した番号は欠番にしてよく、一般の作成失敗でnext_id不変は要求しない。
 
 client checkoutのルートで実行する。
 

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/analog-payload-conformance.ja.md

@@ -52,7 +52,7 @@ rate/samples/mode/triggerの拒否、query成功時の非適用を確認する
 区画満杯のstate 5はconfigureをunavailable・cause 6で拒否し、積んだ区画とdataを消さない。
 logic/analog双方を確認する。planありのstate 5でもqueryを許可する規則はSPEC §3.3と
 `test_virtual_bench_capture_query.py`で確認する。
-既存仮想endpointのinterface回帰であり、そのlegacy coreを現在の独立core適合fixtureと同一視しない。
+仮想ベンチの`Endpoint`のinterface回帰であり、独立core適合fixture（`core-v1`）の検査とは別。
 
 ```sh
 uv run pytest -q tests/test_virtual_bench_capture_requests.py
@@ -98,8 +98,7 @@ logic/analogのone-shot完了、short stop、error、repeat満杯/解放、到
 新start後までqueueに残る旧通知は元の世代を保ち、Hostが現在の世代以外を捨てることも確認する。
 世代/時刻/停止理由の改変、通知欠落と不要なtriggerを故障注入して検出する。
 stoppedのerrorはreason 3のときだけ照合し、それ以外で0を要求しない。
-これは既存fixtureの通知動作の追加回帰。到達しないtrigger、全通知/streaming/並行性と
-現在のcoreへ移行した全analog操作の適合は継続して整備する。
+これはfixtureの通知動作の回帰。到達しないtrigger、全通知/streaming/並行性と全analog操作の適合は検査しない。
 
 ```sh
 uv run pytest -q tests/test_virtual_bench_capture_notifications.py
@@ -114,7 +113,7 @@ forceでは現在のsampleを使い、まだ足りないpretrigger分だけ区
 capture-groupは即時のtrackだけを束ねるので、groupの待機やforceはここで扱わない。
 
 既存one-shot fixtureと同じく、成立後の将来sampleは即時に合成する。
-これは物理的な待ち時間の証明ではない。自然な早期trigger、全modeのtriggerは別途整備する。
+これは物理的な待ち時間の証明ではない。自然な早期trigger、全modeのtriggerは検査しない。
 
 ```sh
 uv run pytest -q tests/test_virtual_bench_capture_waiting.py
@@ -140,7 +139,7 @@ logicのedge/level、analogのcross_up/down（疎なroleも含む）、pretrigge
 rawデータ・時刻・世代付き通知を照合する。
 開始前のsampleをedge/crossingの比較に使わない。
 one-shotは最後のsample時刻を待って区画を公開する。取得途中は区画を返さない。
-[取得時間の検査](capture-metadata-conformance.ja.md#仮想captureの時間検査)を併用する。物理latency、全mode契約は別途整備する。
+[取得時間の検査](capture-metadata-conformance.ja.md#仮想captureの時間検査)を併用する。物理latency、全mode契約は検査しない。
 
 ```sh
 uv run pytest -q tests/test_virtual_bench_capture_pretrigger.py
@@ -154,7 +153,7 @@ uv run pytest -q tests/test_virtual_bench_capture_pretrigger.py
 queryの候補rate/samples/modeは適用されないことも確認する。plan無しはcause 6、
 取得中の不正rate 0はmalformedで、現在の取得を変えない。
 configureの取得中/結合中拒否は継続し、queryと同じ扱いにはしない。
-既存endpointのlegacy coreの検査であり、独立core適合fixtureとの同一視や全query契約の証明はしない。
+仮想ベンチの`Endpoint`の検査であり、独立core適合fixtureの検査や全query契約の証明ではない。
 
 ```sh
 uv run pytest -q tests/test_virtual_bench_capture_query.py
@@ -169,7 +168,7 @@ forceと既知波形の初回triggerで履歴を残し、repeatの最初の区
 streamingの通し番号とerror時write_posは、捨てた開始前履歴を数えず実際の完了区画から計算する。
 
 既知波形も経過済みsampleだけで条件成立を検出する。待機後の信号変化は下記の別試験で確認する。
-物理latency、offset/skewを含む全modeの時間因果性、storage gap・全stream区画契約は別途整備する。
+物理latency、offset/skewを含む全modeの時間因果性、storage gap・全stream区画契約は検査しない。
 
 ```sh
 uv run pytest -q tests/test_virtual_bench_capture_trigger_modes.py

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/arm-adi-conformance.ja.md

@@ -96,7 +96,7 @@ TAR/data/bufferの段階へ失敗を注入し、読出しでは返せた値のpr
 RDBUFF回収失敗では、まだ返せない語をtarget busから読んでいてもdoneに加えない。
 writeのdoneは送れた語数であり、fixtureでtargetへの配送を落としても送信数を返す。
 WAIT時のstore一回実行、block replay、失敗語/後続への不正アクセスも確認する。
-最適化したpipeline方式、全ての遅延FAULTの方針はまだ確認しない。
+最適化したpipeline方式、全ての遅延FAULTの方針は検査しない。
 AP bank/SELECTの完全なdecode、sticky状態とABORT、ADIv6、SWD attachのTARGETSEL/tid、
 packetのparity/turnaround/idle、電気的な再試行と時間、CPUの実行状態は別途必要。
 全経路のframe容量、u32番地を越えるblockの扱い、production Hostとの統合も未完成である。

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/attach-conformance.ja.md

@@ -21,7 +21,7 @@
 
 論理pin組はRVSWD (0,1)/(2,3)/(6,7)、SWIO (0,0xFFFF)/(2,0xFFFF)/(6,0xFFFF)、SWD (4,5)。channel_groupで明示する。scanは実装しない。method 0の論理成功だけを確認し、haltや電気的な速度選定を証明しない。resetの線の動作、idle_clock、targetselは未検査（`WireOptionsChecks`）。reset TLVはsampleのreset channel（8）で受理とraw tagの拒否、先頭コピーの使用（hold）だけを確かめる。
 
-仮想コアへ`request_tags` / `dispatch_request`の明示拡張入口を加え、拡張固有critical TLVを検査・実行へ渡す。入口がない既存拡張は従来の処理を使う。session・header・cacheの判定は入口より先に行う。同一要求再送でTLV解析や実行を繰り返さない。
+仮想コアは`request_tags` / `dispatch_request`の明示拡張入口で、拡張固有critical TLVを検査・実行へ渡す。入口が無い拡張は共通の処理を使う。session・header・cacheの判定は入口より先に行う。同一要求再送でTLV解析や実行を繰り返さない。
 
 単体19件でmax_speed 0の受理、未知critical無視、既知noncritical拒否、raw tag喪失、後のtag優先、後のコピーの未検証、拒否時targetアクセス、console応答の余分なbyte、ARM console受理、方式競合無視、速度上限超過、再送再実行、connectionsのmetadata不正を検出する。採用条件/選択SPEC変更、所有中fixture再起動拒否、拡張入口とsession/cacheの優先順も確認する。
 

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/capture-group-geometry-conformance.ja.md

@@ -31,10 +31,10 @@ sample時刻の推定値は一般には実時間と完全には一致しない
 これはmetadata例の生成器で、取得エンジンや大量のsample bufferを実装するmodelではない。
 configure例はrate/capacity以外の通常の必須情報も持つが、全layout/scaleなどの検証は別checkerの担当。
 
-単体62件は27例、28の不正観測/前提（旧形式のstart/statusを含む）、報告不確かさの非利用、
-既存仮想Endpointの6構成を含む。Endpoint構成はlogic/analogのbind順と3組の範囲内rate。
+単体62件は27例、28の不正観測/前提（誤った形のstart/statusを含む）、報告不確かさの非利用、
+仮想ベンチの`Endpoint`の6構成を含む。Endpoint構成はlogic/analogのbind順と3組の範囲内rate。
 実際の応答bodyをwireから取り、組のstart_nsとADCの既知の変換遅れ（5000ns）から起点を求めて照合する。
-既存Endpoint/Hostのlegacy coreやop番号の適合を証明する検査ではない。
+`Endpoint`/Hostのcoreやop番号の適合を証明する検査ではない。
 
 `full_conformance`はfalse。wire拒否/再送/全世代進行、bindの実現可能性、全configure/data構造、
 repeat/streaming/通知、stopの短い区画、物理clock/skew/精度は未検査。

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/capture-metadata-conformance.ja.md

@@ -15,7 +15,6 @@ describeの成功だけで取得操作やデータ寿命の適合を証明しな
 - analog: frontendの9 byte固定形（frontend、range_min_mv、range_max_mv）を1つ以上、番号ごとに1行。
 - capture-group: tracksの要素数n≥1とu16列の形。
 - config: items（0x41）の存在、1つ以上、重複なし、項目番号0を含まない（probe.config §4）。
-  旧版のslots_max/wifi_maxは現仕様に無いため検査しない。
 
 storage max_bytesとsave/erase提供時の存在は既存SelectedMetadataChecksで別に確認する。
 itemsの未知tagを独自拡張でないと推測して禁止しない。

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/capture-serial-conformance.ja.md

@@ -23,7 +23,5 @@ readはu64位置を返し、既に解放した位置ならgap、未取得の未
 保持するのは最大2区画で、次serialとの差はu32の1/4未満である。任意の保持容量や保持幅全域の証明にはしない。
 この共通の区画手順を他のcapture拡張へ移す際は、明示adapter・独立のsample/packing oracleを用意する。
 単体34件：正常1、観測故障22、実model/Core故障7、制御不足2、本文guard2。
-レビュー済み本文SHAはoep-spec 02c08c9のcapture/commonに合わせた。
-初期fixtureのconstructor、analog feed入口、frame容量を修正した。現在のモデル本体/Core/productionは変更していない。
-mark保持、streaming/groupとの通知交錯、任意capacity、物理sampling、production Host統合は残る。
+mark保持、streaming/groupとの通知交錯、任意capacity、物理sampling、production Hostとの統合は検査しない。
 full_conformance=false。

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/capture-timeline-lifecycle-conformance.ja.md

@@ -15,7 +15,7 @@ fast 2種類それぞれで20ケース、計40構成を検査する。
 - startの再送は取得中、stopの再送は部分区画を完成させた後で行う。
   同じ要求の応答と状態が一致し、世代やデータを変えないことを確認する。
 - queryは取得中と片方が完了した状態で両trackへ送る。
-  提案した537Hz/5 sampleを答え、元の設定・timeline・データを保持することを確認する。
+  probeが候補として返した537Hz/5 sampleを答え、元の設定・timeline・データを保持することを確認する。
 - endとforceによるsession交代は取得中、lease期限は取得中と取得完了後の保持データを持つ状態で確認する。
   bind、plan、購読、取得データと区画を解放し、pinをidleへ戻す。世代は保持する。
 - 世代の使い切り: groupの世代が0xFFFFFFFFならgroup startを、trackの世代が0xFFFFFFFFなら

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/config-conformance.ja.md

@@ -16,7 +16,7 @@ getの応答は`more generation count 項目 [TLV]`、stateは`storage_state sav
 - IDLE：使用中のchannelへのidleは解放時に効き、空きのchannelへのidleはただちに効く。
   disableしたchannelは駆動せず、planはunavailable cause 5で断る。disableのunsetでただちに空き状態へ戻り、使えるようになる。
 - ATOMIC：重複キー（bit7違いを含む）、idle/disable/labelの長さ違い、項目番号0、countと項目の不一致はmalformed。
-  宣言しない項目（旧planの0x01、0xFF）は受け取ったtagで、範囲外channel・未知のidle modeは項目tagで、未知criticalの要求TLVはそのtagでunsupported。
+  宣言しない項目（0x01、0xFFなど）は受け取ったtagで、範囲外channel・未知のidle modeは項目tagで、未知criticalの要求TLVはそのtagでunsupported。
   unsetの重複キー/項目番号0/切れた行はmalformed、宣言しない項目はunsupported。
   idleとdisableの併存はcause 5、使用中channelのdisableはcause 1。
   channel TLVはcore §4.3で「分かる範囲で付ける」任意のため、付けた場合にぶつかったchannelを指すことだけを照合する。拒否は設定・generation・pinを変えない。
@@ -39,4 +39,4 @@ generationの折返し、無いキーのunsetでの加算、容量超過のcause
 旧config consumer/Endpointの自動attach・bind形は、この現仕様の適合根拠には使わない。
 get paging/数値キー順は[別の部分検査](config-paging-conformance.ja.md)で確認する。
 同内容saveの書き込み抑止と保存容量境界は[別の部分検査](config-storage-conformance.ja.md)で確認する。
-channelごとのpull/出力の非対応、firmware自身のchannel、物理保存とproduction追従は残る。full_conformance=false。
+channelごとのpull/出力の非対応、firmware自身のchannel、物理保存とproductionのHostは検査しない。full_conformance=false。

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/config-execution-conformance.ja.md

@@ -30,4 +30,4 @@ lease停止漏れ/早い更新/待機中停止・更新/送信後更新漏れ、
 誤った実行時間、pin変更、同内容/拒否時/再送の書込みを検出する。
 set/unsetは要求の先頭のcount(u8)から項目/行を読み、固定長に頼らない。
 Host実時計のtimeout、物理flash、保存後のqueue処理、実経路の同時実行、応答待ち中のforce/open競合、
-eraseの実行時間とproduction追従は残る。full_conformance=false。
+eraseの実行時間とproductionのHostは検査しない。full_conformance=false。

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/config-fallback-conformance.ja.md

@@ -10,7 +10,7 @@ getの項目とgeneration 1、stateのstorage_state/saved_generation 0/reason、
 ch1/ch6へのplanの可否（disableならunavailable cause 5）を照合する。
 
 - FORMAT：容器が壊れて境界を確かめられない。何も適用せずstate 2/reason 1。保存のdisable ch6も効かない。
-- UNKNOWN：未知の項目（旧planの0x01）。それを除き適用し、state 3/reason 2。
+- UNKNOWN：未知の項目。それを除き適用し、state 3/reason 2。
 - CHANNEL：channels以上のlabel。MODE：未知のidle mode。LABEL：textの無いlabel。いずれも除いて適用し、3/2。
 - CONFLICT：同じchannelにidleとdisable。disableを優先してidleを適用せず、3/2。
 - DUPLICATE：同じキーのlabelが2つ。そのキーを適用せず、3/2。
@@ -30,4 +30,4 @@ idleの優先、重複キーの片方の採用、容量不足時の順序、起
 set/save/erase後の誤った保存状態、idleの未適用を検出する。
 get pagingは[別の部分検査](config-paging-conformance.ja.md)で確認する。
 同内容saveの書込み抑止は[別の部分検査](config-storage-conformance.ja.md)で確認する。
-erase中の電源断で残る完全性を確認できない保存、保存中排他/電源断、物理保存とproduction追従は残る。full_conformance=false。
+erase中の電源断で残る完全性を確認できない保存、保存中排他/電源断、物理保存とproductionのHostは検査しない。full_conformance=false。

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/config-paging-conformance.ja.md

@@ -3,7 +3,7 @@
 ConfigPagingModelとChecksへSPEC registryを明示し、InterfaceChecksの後に
 `ConfigPagingChecks(checks, SampleConfigPagingAdapter(model)).run()`を実行する。
 privateベンチや隣接SPECを自動探索しない。max_frame 64/128/256の3つの明示profileを使う。
-fn 0のchannelsは512、GPIOの駆動候補は従来の0〜7。大きい番号の項目を確認するための論理fixtureであり、512本の物理pinを模擬する意味ではない。
+fn 0のchannelsは512、GPIOの駆動候補は0〜7。大きい番号の項目を確認するための論理fixtureであり、512本の物理pinを模擬する意味ではない。
 
 getの応答は`more(u8) generation(u32) count(u8) count×項目 [TLV]`。項目はcountで数えて読み、残りは応答の末尾TLVとして別に読む。
 
@@ -24,8 +24,8 @@ generation変更時は古い項目を捨ててfirst 0へ戻す。more 1なのに
 byte辞書順/byte offset、項目抜け/重複、誤ったmore/generation、途中で切った項目、bit7残留、frame超過、
 countと項目数の不一致、変更ごとに進まないgeneration、読取りの設定/pin/lease/cache変更と、
 Hostが再読込みせず異なる版を混ぜる故障を検出する。応答の未知の非critical末尾TLVは項目と混ぜずに受け入れる。
-初期モデルの256 byte固定ページ上限は64/128で応答長違反となり、通知したmax_frameから応答headerを差し引く形へ修正した。
+ページの上限は、通知したmax_frameから応答headerを差し引いた長さ。
 
-任意channelカタログ、真の並行要求/継続変更、production Host連携は残る。
+任意channelカタログ、真の並行要求/継続変更、production Hostとの連携は検査しない。
 saveの書込み抑止は[別の部分検査](config-storage-conformance.ja.md)で確認する。
-saveの排他/電源断、物理設備は残る。full_conformance=false。
+saveの排他/電源断、物理設備は検査しない。full_conformance=false。

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/config-power-loss-conformance.ja.md

@@ -31,9 +31,9 @@ JSON/CRCをcheckerのoracleに使わず、wireで設定したold/newの全項目
 Core内部観測とbyte画像は仮想fixture用の補助制御であり、Probeへ新たな読取りAPIを要求しない。
 
 単体33件：正常1、共通宣言1、wire故障4、状態/保存故障19、制御不足8。
-active領域上書き/消去、誤った旧世代選択、commit/CRC破損後の成功、項目の混在、idle/disableの復帰漏れ、live planの残留、
-起動時generation、同じbootの再使用、早い応答、復帰の書換え、旧保持者/履歴/cache、途中再開、volatileな未来設定への誤った復帰を検出する。
-初期モデルがactive領域を上書きして以前の保存を失うことを再現し、他方の領域へ書く形へ修正した。
+active領域上書き/消去、誤った古い世代の選択、commit/CRC破損後の成功、項目の混在、idle/disableの復帰漏れ、live planの残留、
+起動時generation、同じbootの再使用、早い応答、復帰の書換え、前の保持者/履歴/cache、途中再開、volatileな未来設定への誤った復帰を検出する。
+モデルはactiveでない側の領域へ書き、active領域の保存を失わない。
 
 保存中の応答抑止/実行時間/lease、erase中の電源断（storage_state 2）、実flashのerase/program tear・摩耗・物理永続性、
-任意破損/内部counter wrap、production実装追従は残る。full_conformance=false。
+任意破損/内部counter wrap、production実装は検査しない。full_conformance=false。

{oep_client_python-0.0.43 → oep_client_python-0.0.45}/docs/config-storage-conformance.ja.md

@@ -25,5 +25,5 @@ max_bytesが数えるのは項目の見出し込みのbyteだけなので、63/6
 毎回書込み/書込み欠落/変更の取りこぼし、generationや挿入順だけの比較、set時の自動保存、
 erase漏れ/現在設定消去/state残留、容量境界/cause/拒否時の書込み、pin変更、不正保存、boot時の書換え/消失を検出する。
 回数のassertは明示backendの観測条件であり、保存の内部形式や物理保存方式をoracleとして用いない。
-実flashの摩耗、保存中排他/電源断、起動時の項目ごとの検証、production Host統合は残る。
+実flashの摩耗、保存中排他/電源断、起動時の項目ごとの検証、production Hostとの統合は検査しない。
 full_conformance=false。