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

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

@@ -2,6 +2,110 @@
 
 ## 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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: oep-client-python
-Version: 0.0.44
+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

{oep_client_python-0.0.44 → oep_client_python-0.0.45}/docs/conformance-checks.ja.md

@@ -42,11 +42,11 @@ uv run python -m oep_client.virtual_bench_serve --tcp 0 --profile core-v1
 
 追加する検査はpeerの識別、共通lock/ownerと他sessionの拒否、応答の送り先、接続ごとの途中frameの分離、片側のclose後のlock保持、peerの過大length切断時のprimary保持。応答漏れの無応答観測は100ms、途中header待ちは300ms。JSONにprimary/peerのraw bytesと観測を残す。
 
-close後はsession 0のpeerからlockを観測し、primaryを開き直して再照合する。元のsession Sの要求は新接続へ移さず、自分のownerを確認できた場合だけ別session Tでforceし、Tを同じ新接続でendする。識別・boot・owner・takeoverが不確かなら後続を止め、閉じた接続のsessionの後始末はleaseに任せる。同一sessionのTCP経路移動と再送は未検査として残す。
+close後はsession 0のpeerからlockを観測し、primaryを開き直して再照合する。元のsession Sの要求は新接続へ移さず、自分のownerを確認できた場合だけ別session Tでforceし、Tを同じ新接続でendする。識別・boot・owner・takeoverが不確かなら後続を止め、閉じた接続のsessionの後始末はleaseに任せる。同一sessionのTCP経路移動と再送は、primaryの接続を開き直すCORE-RECONNECT-*（session、replay、ended、lease、unread）で確かめる。
 
 ## raw USBとソフトウェアモデル
 
-bulk/HIDには独立したraw adapter APIと最小USBモデルがある（[USB検査ガイド](usb-conformance.ja.md)）。USB device/gadgetやOSのUSB stackではなく、実機raw adapterとdescriptor検査は持たない。通常CLIのUSB `framing=client` はメッセージ検査だけで、モデルの成功を実機へ適用しない。
+bulk/HIDには独立したraw adapter APIと、最小USBモデル、実機を開く `usb_hw`（descriptorとIN転送の終わりの検査を含む）がある（[USB検査ガイド](usb-conformance.ja.md)）。通常CLIのUSB `framing=client` はメッセージ検査だけで、モデルの成功を実機へ適用しない。
 
 ## 現在の粒度と限界
 
@@ -68,15 +68,15 @@ bulk/HIDには独立したraw adapter APIと最小USBモデルがある（[USB
 
 `result_lost` は仕様が許す保持サイズ上限を考慮して受ける。履歴の古い clock を送り直したとき、新しい時計値で completed を返せば再実行として失敗する。cacheの容量を実装固有の固定値と決めつけない。
 
-実機bulk/HIDのraw adapter・descriptor・packet終端、同一sessionのTCP経路移動・新接続での再送、force時の資源解放、subscription、電気的なpin解放、複数target・各opの動作は未検査。serialではclientのencoder/decoderを使わず、CRCは標準ライブラリ、COBSと受信は別コードで確認する。OSのport排他とportの開閉だけ既存clientを利用する。再接続はOS portのclose/openであり、USBの物理抜き差し・給電断・USB resetを模擬しない。DTR/RTSやbridge配線により再起動した場合、boot変化のFAILとして記録し、session保持の成否は確定しない。重複応答の検査は結果後30msの観測窓内、過大frameの無応答は宣言されたframe gap＋100msの観測窓内に限る。TCPは独立したlengthの受信・送信を使い、壊れた応答の後は立て直しで隠さず止める。framing=clientでは独立wire検査を実行しない。これらを埋める前に全コア準拠・全インターフェース準拠と名乗らない。
+複数target・各opの動作は未検査（ピンの解放は、実機の `python -m oep_client.conformance.release_hw` が、targetのGPIOの入力で電気的に確かめる）。serialではclientのencoder/decoderを使わず、CRCは標準ライブラリ、COBSと受信は別コードで確認する。OSのport排他とportの開閉だけ既存clientを利用する。再接続はOS portのclose/openであり、USBの物理抜き差し・給電断・USB resetを模擬しない。DTR/RTSやbridge配線により再起動した場合、boot変化のFAILとして記録し、session保持の成否は確定しない。重複応答の検査は結果後30msの観測窓内、過大frameの無応答は宣言されたframe gap＋100msの観測窓内に限る。TCPは独立したlengthの受信・送信を使い、壊れた応答の後は立て直しで隠さず止める。framing=clientでは独立wire検査を実行しない。これらを埋める前に全コア準拠・全インターフェース準拠と名乗らない。
 
 既存 `oep-hardware preflight` は個体・旧仕様の宣言・open/end に限った別契約。portable C++、共有ベクタ、仮想テストの成功も、実機適合とは別に報告する。
 
 既存の registry/vector は `tests/vectors/SPEC_COMMIT` と `SPEC_SHA256` で固定し、通常試験はその snapshot を検査する。明示した `OEP_SPEC_DIR` があれば、同じ commit の upstream 内容も比較する。SPEC の HEAD が先行しても旧回帰は自動同期しない。更新は `OEP_SPEC_DIR=/explicit/path OEP_SPEC_REF=<commit> tools/sync_registry.sh` で行う。
 
-資源寿命には[明示adapterによる補助検査](resource-conformance.ja.md)がある。最小サンプルは14資源契約＋2宣言検査を実行する。通常CLIへ自動追加せず、購読・route切断・依存順・電気的idleを未検査として残す。
+forceによる資源の解放は、実機の `python -m oep_client.conformance.force_hw` が、targetへのdebugの接続で確かめる（奪われたセッションの接続が消え、番号がno_resourceになり、奪った側の次の接続は新しい大きい番号）。資源寿命には[明示adapterによる補助検査](resource-conformance.ja.md)がある。最小サンプルは14資源契約＋2宣言検査を実行する。通常CLIへ自動追加せず、購読・route切断・依存順・電気的idleを未検査として残す。
 
-購読・出来事の寿命には[外部刺激adapterの補助検査](subscription-conformance.ja.md)がある。raw通知と観測窓を保存する。data、応答優先、route、queue上限は未検査で、通常CLIには自動追加しない。
+購読と通知は、実機の `python -m oep_client.conformance.notify_hw` が、名指した1本の線のロジックのキャプチャのストリーミングで確かめる（ロック、seqとposition、応答優先、置き換え、max_delay_ms、経路、end / forceで止まる）。購読・出来事の寿命には[外部刺激adapterの補助検査](subscription-conformance.ja.md)がある。raw通知と観測窓を保存する。data、応答優先、route、queue上限は未検査で、通常CLIには自動追加しない。
 
 [data/eventとまとめ送りの補助検査](data-conformance.ja.md)。外部byte位置とloss-freeな刺激条件を明示し、閾値・first-byte delay・共通seq・分割・再送/同session openでの未送信データ保持を検査する。seq一周は単体で65,538個を実際に生成して検証し、実時計・実機の結果と分ける。
 

{oep_client_python-0.0.44 → oep_client_python-0.0.45}/docs/cut-conformance.ja.md

@@ -1,7 +1,7 @@
 # 線切れの応答と解放の論理検査
 
 `CutChecks`と独立した`CutModel`/`SampleCutAdapter`はOEP debug §2、common §1/2、
-core §5.2/9を検査する。共通宣言は第二段階、前提と動作は第三段階。
+core §5.1/9を検査する。共通宣言は第二段階、前提と動作は第三段階。
 動作caseはRVSWD接続のRISC-V DMIとdmseq consoleを使う。
 公開Pythonライブラリだけで利用でき、SPEC/registryは呼び出し側で選ぶ。
 `full_conformance`はfalse。設備設定や私的ベンチを探索しない。

{oep_client_python-0.0.44 → oep_client_python-0.0.45}/docs/data-conformance.ja.md

@@ -1,6 +1,6 @@
 # データ通知とまとめ送りの検査
 
-SPEC core §11.2/11.3の、data/event共通seq、データの形、min_bytes/max_delayを検査する。先に検査側の刺激と期待値を定め、独立したin-processサンプルへ適用する。実機transport、応答優先、送信queue上限、dropによるseq欠落は別段階。
+SPEC core §10.2/11.3の、data/event共通seq、データの形、min_bytes/max_delayを検査する。先に検査側の刺激と期待値を定め、独立したin-processサンプルへ適用する。実機transport、応答優先、送信queue上限、dropによるseq欠落は別段階。
 
 条件は明示した2 fn、既知bytesのデータ刺激と既知markerの出来事刺激、全raw通知の受信。データ位置はinterfaceが決めるので、adapterは外部刺激の開始位置を返す。probeが返したpositionを期待値へ転記してはいけない。共通検査はdata見出し、position:u64、len:u16、後続TLVと、データ内容を独立に検証する。
 

{oep_client_python-0.0.44 → oep_client_python-0.0.45}/docs/host-request-conformance.ja.md

@@ -25,13 +25,13 @@ encoderは文脈の方針に従ってbit7を付け、長さu16 little-endian、
 | swio attach | reset | — | debug §3 |
 | swd scan | max_speed、targetsel | — | core §2.3、debug §1、§5 |
 | swd attach | targetsel、reset | — | debug §3、§5 |
-| logic configure / query（2文脈） | format、format_name、data_path、carriage、trigger_opts、threshold、clock、glitch_filter | mode、rate、samples、segments、trigger、pretrigger、block_max、overflow | capture §3.3、§3.8 |
-| analog configure / query（2文脈） | format、format_name、data_path、carriage、trigger_opts、coupling、offset、bandwidth、resolution、oversample | 上記の基本設定、block_max、overflow、frontend | capture §3.3、§3.8 |
+| logic configure / query（2文脈） | format、carriage、trigger_opts、clock、glitch_filter | mode、rate、samples、segments、trigger、pretrigger、block_max | capture §3.3、§3.8 |
+| analog configure / query（2文脈） | format、carriage、trigger_opts | 上記の基本設定、block_max、frontend | capture §3.3、§3.8 |
 | plan_apply | role_assignment | — | core §2.3、plan §2.1 |
 | uart configure | format | — | fixture §2、Host方針 |
 
 capture §3.3 の表の TLV は、対象の probe がどれも実装するので critical を付けない。表が「critical で送る」とするもの（format、
-format_name、data_path、carriage、trigger_opts）と、§3.8 の前段の TLV（どれも任意）は critical で送る。format と data_path は 0 では
+carriage、trigger_opts）と、§3.8 の TLV（グリッチフィルタと外部クロック、どれも任意）は critical で送る。format は 0 では
 critical が要らないが、この方針は値によらず付ける（表の TLV は付いていても probe が同じに扱う、core §2.3）。
 
 core §2.3は「scanのmax_speed」「attachのreset」をcriticalにする例として挙げる。

{oep_client_python-0.0.44 → oep_client_python-0.0.45}/docs/notification-sequence-conformance.ja.md

@@ -1,6 +1,6 @@
 # 通知seqの一周・再購読・再送の検査
 
-`NotificationSequenceChecks`はcore §5.2/10.2/10.3/10.4、transports §3に基づく第二段階の補助検査。
+`NotificationSequenceChecks`はcore §5.1/10.2/10.3/10.4、transports §3に基づく第二段階の補助検査。
 公開`RouteModel`と`SampleNotificationSequenceAdapter`を使い、選択SPEC checkoutを明示する。
 privateベンチや隣接checkoutの探索は行わない。
 

{oep_client_python-0.0.44 → oep_client_python-0.0.45}/docs/recovery-conformance.ja.md

@@ -1,6 +1,6 @@
 # result_lost後の状態読み直しの補助検査
 
-core §5.2は、実行済みか不明な変更要求を新しいcorrで自動再実行しないこと、再送を諦めた後はboot_idと状態を読み直すことを定める。result_lostは元の要求の成功・拒否・未実行のいずれも証明しない。読み直した状態も、元の結果そのものではない。
+core §5.1は、実行済みか不明な変更要求を新しいcorrで自動再実行しないこと、再送を諦めた後はboot_idと状態を読み直すことを定める。result_lostは元の要求の成功・拒否・未実行のいずれも証明しない。読み直した状態も、元の結果そのものではない。
 
 probeの保持契約とsample hostの回復方針を分けて観測する。sample資源操作、状態の読み方、単独writer条件を一般の拡張へ義務付けるものではない。既存production Hostへ回復処理を組み込む変更ではない。
 

{oep_client_python-0.0.44 → oep_client_python-0.0.45}/docs/recovery-races-conformance.ja.md

@@ -1,6 +1,6 @@
 # 回復中のforceと経路単位の結果不明化
 
-core §5.2は、再送を諦めた経路の未解決要求をすべて結果不明とする。受信済みの確定結果を捨てたり、別経路の要求まで諦めたりはしない。回復時のboot/session確認が終わるまでは、旧資源の一覧を次の操作へ使わない。
+core §5.1は、再送を諦めた経路の未解決要求をすべて結果不明とする。受信済みの確定結果を捨てたり、別経路の要求まで諦めたりはしない。回復時のboot/session確認が終わるまでは、旧資源の一覧を次の操作へ使わない。
 
 batch条件`none`、`prefix`、`queued`は、明示した新しいmodelでそれぞれ実行する。一つの結果で全条件を検査したとは扱わない。通常core検査も別に実施する。
 

{oep_client_python-0.0.44 → oep_client_python-0.0.45}/docs/retention-conformance.ja.md

@@ -1,6 +1,6 @@
 # 再送cacheの保持上限とresult_lostの補助検査
 
-core §5.2は直近max_inflight個以上の記録とcorrの最大値を保持し、要求/応答bytesの保持にサイズ上限を認める。保存済み要求は全bytesで比較し、変更ならmalformed。同じ要求でも応答を保持できなければresult_lost。要求そのものを保持できない場合や、記録が追い出されて最大corr以下の場合もresult_lost。どの場合も再実行・lease更新・資源変更をしない。
+core §5.1は直近max_inflight個以上の記録とcorrの最大値を保持し、要求/応答bytesの保持にサイズ上限を認める。保存済み要求は全bytesで比較し、変更ならmalformed。同じ要求でも応答を保持できなければresult_lost。要求そのものを保持できない場合や、記録が追い出されて最大corr以下の場合もresult_lost。どの場合も再実行・lease更新・資源変更をしない。
 
 一般probeに具体的な保持サイズを要求しない。このfixtureはmax_frame=64に対し保持上限16 byte、履歴8件を明示した`virtual-retention-1` / `io.github.open-embedded-probe.retention` revision 1。通常のcore/pipelineの保持上限72 byteを変更しない。経路の宣言値はpipeline sampleと同じ64/80/3、peerは64/96/2。履歴8件は両経路のmax_inflight以上。
 

{oep_client_python-0.0.44 → oep_client_python-0.0.45}/docs/retention-lifecycle-conformance.ja.md

@@ -1,6 +1,6 @@
 # 保持欠落・履歴の追い出しとsession/boot寿命の補助検査
 
-core §5.2/6/9を、明示した16 byte / 8件の[retention sample](retention-conformance.ja.md)で検査する。要求欠落、応答欠落、記録追い出しをそれぞれ作り、期限切れと異なるIDのforceでの扱いを分ける。終了と同じboot内のID継続、boot変更時の無効化は別の契約。
+core §5.1/6/9を、明示した16 byte / 8件の[retention sample](retention-conformance.ja.md)で検査する。要求欠落、応答欠落、記録追い出しをそれぞれ作り、期限切れと異なるIDのforceでの扱いを分ける。終了と同じboot内のID継続、boot変更時の無効化は別の契約。
 
 reset能力はsession操作の前に確認し、`reset_scope='logical-model'`だけを許す。実機の再起動/転送をこのadapterへ渡さない。
 

{oep_client_python-0.0.44 → oep_client_python-0.0.45}/docs/route-conformance.ja.md

@@ -1,6 +1,6 @@
 # 通知経路・応答優先・送りかけqueueの検査
 
-SPEC core §11.4、transports §3の契約を、2つの明示経路とinstrumentationを持つモデルで検査する。受信済み要求、通知生成、送信停止/部分送信を制御し、各経路の全raw messageと未送信suffixを観測する。設備の自動探索や私的ベンチ依存は加えない。
+SPEC core §10.4、transports §3の契約を、2つの明示経路とinstrumentationを持つモデルで検査する。受信済み要求、通知生成、送信停止/部分送信を制御し、各経路の全raw messageと未送信suffixを観測する。設備の自動探索や私的ベンチ依存は加えない。
 
 共通契約は、応答が要求元に返る、通知がsubscribe元だけへ届く、受信済み要求の応答を通知より先に送る、送りかけ通知の残りbytes合計がmax_frame×2以内、送信停止中も他経路の処理が進む、probe内部で捨てた通知もdata/event共通seqを消費する、経路切断だけではsession/資源/購読/再送履歴を解放しないこと。
 

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

@@ -1,4 +1,4 @@
-# oep-spec a09fa45 の規則ごとの対応表
+# oep-spec の規則ごとの対応表
 
 `tools/spec_units.py` が oep-spec の core / transports / 各インターフェース文書から規範の単位（箇条、番号つきの手順、表の
 データ行）を節ごとに抜き出し、`<文書>:<節>:<番号>`（見出しより前は `pre`）の ID を振る。`<文書>.json` は単位ごとに、