v0.0.41

0.0.41

• (EN) Added: oep_client.acquire, one capture put together. A line is named by the probe's channel name (fn 0's channel_name, GPIO47) or a port's line label (x035.swdio), looked up on the session; a stream's length is seconds (as LogicCapture.stream). capture_at(address, Request) opens the probe, takes its lease, raises a UART link and lets it all go; capture(hst, Request) runs on a session the caller holds (with ProbeLog, the target's control). Modes oneshot / repeat / stream, logic and analog in a capture-group with a trigger on either track (capture §4.4), format 1 lines as their changes. The Result has the tick rate, the parts (tick0, meta: start_ns, start_uncertainty_ns, trigger_tick, ...), their channels as the probe gave them (Bits, Changes, Analog), the losses (any makes the capture a failure) and meta["probe"] (model, firmware, unit_id, address = the probe's place without the route, boot_id, clock, calibration, link). Moved from wireskein's oep source, which now writes this result as a file. numpy (extra acquire) puts streams and format 1 blocks together.
• (JA) 追加: oep_client.acquire。1 回の取り込みを組み立てる。線は、プローブのチャンネルの名前（fn 0 の channel_name、GPIO47）か口の線の label（x035.swdio）で指し、セッションの上で番号に引く。ストリームの長さは seconds（LogicCapture.stream と同じ）。capture_at(address, Request) はプローブを開き、lease を取り、UART の速さを上げ、終わったら手放す。capture(hst, Request) は呼び手が持つセッションの上で動く（ProbeLog や target の操作と一緒に）。mode は oneshot / repeat / stream、ロジックとアナログを capture-group で一緒に、どちらのトラックの trigger も（capture §4.4）、形式 1 の線は変化で。Result は刻みの速さ、区間（tick0、meta: start_ns、start_uncertainty_ns、trigger_tick など）、プローブが渡したままのチャンネル（Bits、Changes、Analog）、欠落（1 つでもあれば失敗）、meta["probe"]（model、firmware、unit_id、address = 経路を除いたプローブの場所、boot_id、clock、calibration、link）を持つ。wireskein の oep の取り込みから移した（wireskein はこの結果をファイルに書く）。stream と形式 1 のブロックの組み立てに numpy（追加の依存 acquire）を使う。
• (EN) Changed (breaking): a probe is named by its OEP address, oep://<unit_id>[/<port>[/<target>]][?via=<route>]
  (oep-spec host guide §5.3; link.parse_address, link.Address, hst.address). Without via: its USB device (found by
  its USB serial, any VID:PID: vendor bulk, then HID, then its one CDC port), else the TCP probe DNS-SD finds; via=usb /
  bulk / hid / cdc / net keeps to that route, via=tcp:: and via=tty: name it. On every route
  describe's unit_id must be the one named. tcp:UNIT_ID, usb:UNIT_ID and usb:VID:PID[:SERIAL] are gone
  (oep://UNIT_ID?via=net, ?via=usb); a serial port path, tcp://HOST[:PORT] and a bare usb stay as short forms for a
  probe whose unit_id is not known.
• (JA) 変更（壊す変更）: probe は OEP のアドレス oep://<unit_id>[/<port>[/<target>]][?via=<経路>] で名指す（oep-spec の host
  ガイド §5.3。link.parse_address、link.Address、hst.address）。via が無ければ USB のデバイス（USB の serial で探す。
  VID:PID は問わない。vendor bulk、HID、ただ 1 つの CDC の順）、無ければ DNS-SD が見つけた TCP の probe。via=usb / bulk / hid / cdc /
  net はその経路だけ、via=tcp:: と via=tty: は経路を名指す。どの経路でも describe の unit_id が名指したものと
  同じでなければならない。tcp:UNIT_ID、usb:UNIT_ID、usb:VID:PID[:SERIAL] は無くした（oep://UNIT_ID?via=net、?via=usb）。
  unit_id を知らない probe には、シリアルの口の path、tcp://HOST[:PORT]、ただの usb を短い形として残す。
• (EN) Changed: virtual_bench_serve --pty says so on stderr when it gets no inotify instance (a user's
  fs.inotify.max_user_instances used up by editors and file watchers): it then cannot see the close of a host that ended
  without closing the port, and the pty stays busy. The test of that case skips with this reason instead of failing.
• (JA) 変更: virtual_bench_serve --pty は、inotify を作れないとき（エディタやファイルの見張りが、ユーザーの
  fs.inotify.max_user_instances を使い切ったときなど）に、その旨を stderr に出す。このとき、口を閉じずに終わった host の
  close が見えないので、pty は使用中のまま残る。その場合の試験は、落ちる代わりにこの理由で skip する。
• (EN) Fixed: oep pins' map named pads another device moves as wired - an X035's PC16/PC17, held by a USB host,
  "followed" different channels on every run. The map now reads the target's pads first with nothing driven and leaves
  out those that move (a note names them), and a pad must follow its channel on 4 tries (was 2).
• (JA) 修正: oep pins の map が、ほかの機器が動かすピンを「つながっている」としていた（USB ホストにつながる X035 の PC16/PC17 が、
  走らせるたびに違うチャネルに追従した）。map は、まず何も駆動しないで target のピンを読み、動くピンを外す（note に出す）。チャネルに
  追従するかは 4 回確かめる（前は 2 回）。

Repository: https://github.com/Open-Embedded-Probe/oep-client-python

Full Changelog: v0.0.40...v0.0.41

v0.0.40

0.0.40

• (EN) Labels may carry the target pin a line reaches (oep-spec host guide §5.3): S.N@P, and S@P for a line with no
  role. settings.parse_label, pin_from_labels, label_text, pin_name; port_line / find_line read S.N@P as
  S.N, ports_named counts S@P. oep pins --save writes the pins: the debug and NRST pins from
  targets.FAMILIES (nrst_pad), the rest from the map (x035@pb6; a role the port's labels give is kept).
• (JA) label に、線がつながる target のピンを持たせられる（oep-spec host ガイド §5.3）: S.N@P、役目の無い線は S@P。
  settings.parse_label、pin_from_labels、label_text、pin_name。port_line / find_line は S.N@P を S.N として読み、
  ports_named は S@P も数える。oep pins --save はピンも書く: debug と NRST のピンは targets.FAMILIES（nrst_pad）から、
  ほかは map から（x035@pb6。口の label が持つ役目は保つ）。
• (EN) oep pins leaves alone a channel labelled for something else (another port's line, or a name only such as
  rgb_led); the --name port's own lines stay in. The CH32X035's NRST (PA21) is read from its option bytes as the
  V00x's (RST_MODE 11: none); with an NRST on, the reset step runs before the map and the map never drives the reset
  line (or the port's labelled nrst); a pad the option bytes leave a GPIO is mapped like any other. The reset search
  tries the port's labelled nrst first.
• (JA) oep pins は、ほかのもののラベルが付いたチャネル（別の口の線、または rgb_led のような名前だけのもの）を触らない。--name の
  口の線は対象に残る。CH32X035 の NRST（PA21）は、V00x と同じく option bytes で有無を読む（RST_MODE 11 は無し）。NRST が有効なら
  reset の段階を map の前に走らせ、map はリセットの線（と口のラベル nrst）を駆動しない。option bytes がふつうの GPIO にしているピンは
  ほかと同じに対応を調べる。リセットの線の探索は、口のラベル nrst を最初に試す。
• (EN) oep pins finds more and maps the wiring. The scan goes the nearest pairs first, in batches, until one answers
  or --budget (new; default 55 s) is spent - the 600-pair limit is gone; --all-pairs goes on to the last pair;
  the report says when not every pair was tried (unique-in-partial, not-finished), and exit 0 means one target
  found. A driven-low channel is also tried as SWDIO (after the floating pairs at the same distance): a target that
  was talked to may keep its SWDIO low. When nothing answers the lines are read again and the new pairs scanned.
  --pairs SWDIO:SWCLK,... names the pairs to try. A new map step (before reset) says which target pad each
  channel reaches: the hart halted, its pads floating inputs, each channel driven high and low and the target's INDR
  read; a pad that seems to follow two channels is tried again with the others held low (a floating line keeps
  what a neighbour coupled into it); pads bonded to one lead are named together ("PC16/PC11"). --name now labels
  the debug lines too (<name>.swdio / <name>.swclk, or <name>.swio), so oep://<unit>/<name> opens the
  target. targets.FAMILIES carries each family's GPIO block, debug pads, bonded pads and whether it has an NRST to
  look for (the CH32X035: none).
• (JA) oep pins がより広く探し、配線の対応を出す。スキャンは近い組から順に、まとまりごとに、答えが出るか --budget（新設。既定 55 秒）
  を使い切るまで進む（600 組の上限はなくした）。--all-pairs は最後の組まで進む。全部の組を試していないときはレポートがそう言う
  （unique-in-partial、not-finished）。終了コード 0 は、ターゲットが 1 つ見つかったこと。low に駆動された線も SWDIO として試す（同じ
  距離の浮いた組の後）: 話しかけた後のターゲットは SWDIO を low に保つことがある。何も答えなければ線を読み直し、新しい組をスキャンする。
  --pairs SWDIO:SWCLK,... で試す組を指定できる。新しい段階 map（reset の前）は、ターゲットのどのピンが各チャネルにつながるかを出す:
  ハートを止め、ピンを浮いた入力にし、各チャネルを high と low に出してターゲットの INDR を読む。2 つのチャネルに追従するピンは、ほかを
  low に保って試し直す（浮いた線は隣の線から拾った電荷を保つ）。パッケージの中で 1 本のリードにつながる GPIO はまとめて出す
  （"PC16/PC11"）。--name は debug の線にもラベルを付ける（<name>.swdio / <name>.swclk、または <name>.swio）ので、
  oep://<unit>/<name> でターゲットを開ける。targets.FAMILIES に、系列ごとの GPIO の配置、debug のピン、1 本のリードにつながる
  GPIO、探す NRST があるか（CH32X035 は無い）を持たせた。
• (EN) probe_log: a probe's own log (oep-probe-arduino's OepProbeLog.h) read as lines - each line's text cut at its
  mark, with the probe's clock -, sample_of placing a line in a capture segment (the same clock as its start_ns),
  rows giving the lines as a recorder's log rows (WireSkein's run.json: the host's time.monotonic() from Host.clock
  readings, probe_ns, boot_id, the probe's name; # lines as markers). Missing lines show: a lost mark, a jump in the
  marks' serials, a read past what is kept.
• (JA) probe_log: プローブ上のコードのログ（oep-probe-arduino の OepProbeLog.h）を行として読む - 各行の本文をそのマークで切り、プローブの
  時計を付ける。sample_of は行をキャプチャの区画に置く（start_ns と同じ時計）。rows は行を記録器のログの行にする（WireSkein の
  run.json: Host.clock の読みから求めたホストの time.monotonic()、probe_ns、boot_id、プローブの名前。# の行はマーカー）。欠けた行は
  分かる: lost のマーク、マークの通し番号の飛び、残っていない所からの読み。
• (EN) Capture data format 2, the analog blocks (oep-if-capture §1.4): AnalogCapture.configure(carriage={role: (kind, D)}) (kind a bit set of capture_blocks.PACKED / MINMAX / SUM), analog_blocks() reading a segment into its
  blocks (capture_blocks.read_analog_blocks, checked against oep-spec's shared vectors), Config.segment_bytes of the
  fixed-size blocks. The virtual bench's analog declares format 2 and makes it in every mode, the trigger judged on the
  original samples.
• (JA) キャプチャのデータの形式 2、アナログのブロック（oep-if-capture §1.4）: AnalogCapture.configure(carriage={role: (kind, D)})
  （kind は capture_blocks.PACKED / MINMAX / SUM のビット集合）、区画をブロックに読む analog_blocks()
  （capture_blocks.read_analog_blocks、oep-spec の共有ベクタで確かめた）、大きさの決まったブロックの Config.segment_bytes。仮想ベンチの
  アナログは形式 2 を宣言し、どのモードでも作る。トリガは元のサンプルで判定する。
• (EN) The capture's optional features in the virtual bench, declared by virtual_bench.with_capture_options(probe):
  named formats (format 0xFF, format_names), the front end of §3.8 (threshold, glitch filter - the data and the trigger
  after it -, external clock with a qualifier and format 3's timed states, coupling, offset in the scale's zero,
  bandwidth, impedance, resolution and oversample setting b) and the external data paths of §3.9 (TCP with mux 0 / 1,
  UDP packets, the OEPX mark, write_pos, read refused, the overflow check against the path's capacity, a path that goes
  stopping its tracks in error). A probe without a declaration does not have the feature (its TLVs unknown). Client:
  configure(format_name=..., options={...}) sends them (critical, overflow plain), Config.used / timebase /
  format_name / external_clock read the answer, state_timed() reads format 3.
• (JA) キャプチャの任意の機能を仮想ベンチに足した。virtual_bench.with_capture_options(probe) で宣言する: 名前付きの形式（format 0xFF、
  format_names）、§3.8 の前段（threshold、グリッチフィルタ - データとトリガの両方がフィルタの後 -、qualifier 付きの外部クロックと形式 3 の
  時刻つきのステート、coupling、scale の zero に入る offset、bandwidth、impedance、b を決める resolution と oversample）、§3.9 の外部の
  経路（TCP の mux 0 / 1、UDP のパケット、OEPX の印、write_pos、read の断り、経路の帯域に対する overflow の確かめ、切れた経路はトラックを
  エラーで止める）。宣言の無い probe はその機能を持たない（TLV は知らないもの）。クライアント: configure(format_name=..., options={...})
  で送る（critical、overflow は印なし）。応答は Config.used / timebase / format_name / external_clock、形式 3 は state_timed() で読む。
• (EN) The virtual bench models fixture §5-§9 (virtual_fixture_drive): the I2C and SPI controllers, PWM, the edge
  counter and the DAC on p4-x035 and esp32-v003, with their refusals, results, times and plan rules. Found against the
  spec and fixed: esp32-v003-64 declared the Wi-Fi items below their max_frame floor; a gateway outside the prefix got an
  address; unit_id any was taken; a save of the same contents was written again; the controllers' max_length did not
  fit a 64-byte frame.
• (JA) 仮想ベンチが fixture §5〜§9 をモデルにした（virtual_fixture_drive）: I2C と SPI のコントローラ、PWM、エッジのカウンタ、DAC を
  p4-x035 と esp32-v003 に。断り、結果、時間、plan の規則も。仕様と照らして見つけて直したもの: esp32-v003-64 が max_frame の下限より下で
  Wi-Fi の項目を宣言していた。prefix の外の gateway でアドレスを得ていた。unit_id any を受けていた。同じ内容の save を書き直していた。
  コントローラの max_length が 64 byte の frame に収まらなかった。
• (EN) The virtual bench's capture-group trigger source has the rest of §4.4 where with_capture_options declares it:
  pulse, analog_pulse, pattern, serial (UART: it decodes the logic waves' 8N1 lines; I2C / SPI not declared), the
  external input trig_in (a TEST HOOK level per role, judged at 1 MHz) and trigger_out (its pulses kept), the group's
  trig_in / trig_out plan roles, and rearm 1 with holdoff (repeat: a segment a track at every event; streaming: records
  without cutting). Instants count only after their stage is entered. Client: Cond.pulse, analog_pulse, pattern,
  uart, external, TriggerSource(trigger_out=...).
• (JA) 仮想ベンチの capture-group の出来事の元が、with_capture_options の宣言で §4.4 の残りを持つ: pulse、analog_pulse、pattern、serial
  （UART: ロジックの波形の 8N1 の線を復号する。I2C / SPI は宣言しない）、外部の入力 trig_in（役割ごとの試験用のレベル、1 MHz で判定）と
  trigger_out（パルスを記録する）、組の plan の役割 trig_in / trig_out、holdoff つきの rearm 1（リピート: 出来事ごとに各トラックの区画、
  ストリーミング: 区画を切らずに記録）。瞬間の条件は、段に入った後だけを数える。クライアント: Cond.pulse、analog_pulse、pattern、uart、
  external、TriggerSource(trigger_out=...)。
• (EN) docs/trace follows oep-spec 02c08c9 for every document: each unit traced to the tests that prove it or excluded
  with its reason.
• (JA) docs/trace をすべての文書で oep-spec 02c08c9 に追従させた。どの単位も、証明する試験か、理由つきの除外を持つ。
• (EN) The independent conformance checkers follow oep-spec 02c08c9 (they were pinned to a09fa45's text): the reviewed
  document hashes moved after reading the changes. fn 0's required ops are the eight core ops, get with settings, state
  with save, network with a netif (core §11) - the checkers had taken every registry core op as required. The Host request
  policy (HostRequestChecks and its sample encoder) keeps its policy by TLV name and takes the numbers from the selected
  registry (the wire and capture TLVs were renumbered); it covers the capture TLVs added since (critical: format,
  format_name, data_path, carriage, trigger_opts and the §3.8 front-end ones). The core response oracle knows item, setting,
  setting_choice, channel_name and netif, and no longer label. The capture configure sends block_max without the critical
  bit (§3.3's table).
• (JA) 独立した適合の検査器を oep-spec 02c08c9 に追従させた（a09fa45...

v0.0.39

0.0.39

• (EN) No user-facing changes recorded.
• (JA) ユーザー向け変更の記録はありません。

Repository: https://github.com/Open-Embedded-Probe/oep-client-python

Full Changelog: v0.0.38...v0.0.39

v0.0.38

0.0.38

• (JA) 名前と初期値（oep-spec cc82b5e）に合わせた:
  • 設定の値は出どころを持たない。get の値は fn number key len data で、Value.origin と show() の 4 つ目を無くした。書き出しは全部の値、
    入れ直しは unset を先に、全部の値と比べる。unset_all は全部の値を消す。changeable()（set / unset があるか。初期値だけの probe は get だけ）。
  • 口と線（host ガイド §5.3）: label S.N が口 S の線 N（S は英字で始まる英字・数字・- の 16 文字まで、N は英字・数字・-・_）。
    大小文字を区別せずに比べ、書いたとおりに見せる。裸の nrst は口の線にならない。find_line(source, name, port=None)（口を省くと名付けられた
    口が 1 つのときだけ）、ports_named、port_line。core.firmware_labels / probe_labels は無くした（固定の label が無いため）。
  • oep pins は <口>.nrst / <口>.power_hi を勧める（口は --name、無ければ probe にある 1 つの口）。
  • 仮想ベンチ: 出どころを無くし、profile の label は初期値（保存の無い起動で入る。x035.swdio、v003.swio などの S.N の形）。label は
    大小文字を区別せずに一意（重なる set は unavailable cause 5、保存に 2 つあれば channel の小さい方）。with_settings(changeable=False) で get だけ。

Repository: https://github.com/Open-Embedded-Probe/oep-client-python

Full Changelog: v0.0.37...v0.0.38

v0.0.37

0.0.37

• (JA) 設定を core（oep-spec core §13、9fc6ad9 / c4fbd6e）に合わせた。oep_client.config（oep.probe.config）を無くし、
  oep_client.settings を足した:
  • fn 0 の get / set / unset / save / state / network。値は（fn、項目番号、key）で運び、host には（カテゴリ、平らな名前、値、出どころ）で見せる。
  • 設定のファイル（docs/oep-settings-file.ja.md）の書き出しと入れ直し（export、plan_import、apply_import）。secret は読まない。
  • oep config を oep settings（show / items / set / unset / save / state / network / export / import）に置き換えた。
  • 仮想ベンチは fn 0 の設定（各持ち主の項目、固定・既定の値、名前での保存）を持つ。共有ベクタの設定の場合と settings_file.json を通す。
  • 線の名前の探し方（find_line）は、出どころによらず全部の channel.{}.label から探す（firmware の label も設定の固定の値）。
• (JA) libusb1 経由の HID（hidapi がない環境の経路）で、カーネルの HID ドライバを外して interface を claim してから、
  レポート記述子を読むようにした。今までは claim の前に読んでいて、Linux の usbfs に LIBUSB_ERROR_IO で断られていた
  （RP2 の HID は interface 3、2026-10-22）。OEP の記述子でなければ interface を戻し、ドライバを付け直す。
• (JA) CaptureDrops に dropped_bytes を足した。ストリームが落としたバイト数の合計で、理由を問わない（写す経路で区画を捨てた
  分も含む）。oep-probe-arduino e08687c 以降。それより前の形では None。
• (JA) USB（vendor bulk）の既定を UsbProcessStream にした（POSIX のみ）。
  • wireskein の測定: 負荷 14 の host で、P4X の 40 MB/s・30 秒を取った。thread の版は 6 回中 3 回で欠損があり、process の
    版は 3 回とも欠損 0 だった。
  • OEP_USB_STREAM=thread で、今までどおり UsbAsyncStream（このプロセスのスレッド）を使う。Windows は pipe を fd で
    渡せないので、今までどおり。
  • 子プロセスが動かない（起動できない、準備の前に終わった、時間切れ）ときは、警告を出して UsbAsyncStream に戻す。機器が
    無いという答えはそのまま返す。
  • 開くのに、子プロセスを起こす分だけ時間がかかる（約 0.6 秒）。
• (JA) CaptureDrops に spill_peak と spill_bytes を足した。P4 のファーム 826eee0 からの、ストリームの DMA リングの後ろの
  待避 FIFO（PSRAM、8 MiB）の最大使用量と大きさ。それより前のファームの形では None。
• (JA) UsbAsyncStream の既定を 32 KiB × 480 本にした（前は 64 KiB × 128）。
  • probe は各転送を短いパケットで終えるので、URB の大きさによらず 1 本に 1 フレーム（40 MB/s の P4X で約 19 KB）しか入らない。
    host が溜められるのは「本数 × 1 フレーム」になる（64 KiB × 128 は約 2.4 MB、40 MB/s で 60 ms）。wireskein の測定による。
  • 480 × 32 KiB は 15 MiB で、usbfs_memory_mb の既定 16 に収まる。usbfs が途中で断ったら、そこまでの本数で続ける
    （1 本も出せなければ例外）。
  • open_usb_host(urb_size=, depth=) で選べる。UsbProcessStream は、このプロセスの URB_SIZE / DEPTH を引き継ぐ。
• (JA) UsbProcessStream: UsbAsyncStream を別のプロセス（python -m oep_client.usb_stream）で動かす。形は UsbAsyncStream と同じ
  （read、in_waiting、write、reset_input_buffer、close、stats）。
  • IN の転送の受け取りと出し直しは、そのプロセスの event のスレッドと GIL で行う。host の側のスレッドが GIL を長く持っても
    （numpy、大きな bytes の結合など）、転送は止まらない。読まれていない分は、そのプロセスに溜まる。
  • データはパイプで、write と stats は socket pair で受け渡す。multiprocessing の spawn は使わない（呼び出し側の main を
    もう一度走らせるため）。
  • 環境変数 OEP_USB_STREAM=process で、open_host の USB がこれを使う（既定は今までどおり UsbAsyncStream）。
  • wireskein の切り分けを受けた。負荷 14 のとき、event のスレッドが最大 6 秒止まり、40 MB/s の P4X で欠損が出ていた。
    実機では、まだ確かめていない。
• (JA) UsbAsyncStream: 戻った IN の転送は、データを写したらすぐ出し直し、ロック（read() と共有）はその後に取るようにした。
  前はロックを取ってから出し直していたので、read() がロックを持つ間は転送が戻らなかった。stats() を足した（callbacks、
  inflight_min = callback の時点で出ていた転送の最少、gap_max_s = callback の間隔の最大、buffered_max、bytes、urb_size、
  depth）。open() / コンストラクタで urb_size と depth を選べる（既定は URB_SIZE × DEPTH = 64 KiB × 128）。
  wireskein の切り分け（負荷 14 で 40 MB/s に欠損。event のスレッドが時々数百 ms から数秒止まる）を受けた。
• (JA) CaptureGroup.stream(link, tracks, seconds=, nbytes=, into=) -> {fn: Received}: ストリーミングのトラックを集めた
  capture-group で、1 本の経路に混ざって届く push をトラックごと（fn ごと）の Received に分けて集める。seq、generation、gap、
  segment_info の扱いは LogicCapture.stream() と同じ（その内側を _collect() に切り出した）。nbytes は全トラックが届くまで待つ。
  CaptureGroup.finish() は各トラックの finish() を呼ぶ。wireskein の依頼。
• (JA) Wire.scan: 1 回の要求に入れる組を、255 までかつ経路の max_frame に収まる数にした。前は 255 組を詰めていて、
  max_frame 1024 の経路で候補が多いと（rp2350-pins の 812 組）1031 バイトの要求を送っていた（仮想ベンチはそれを受けていた）。JS への移植で見つかった。

Repository: https://github.com/Open-Embedded-Probe/oep-client-python

Full Changelog: v0.0.36...v0.0.37

v0.0.36

0.0.36

• (JA) 試験: segment_columns の試験は、numpy が無ければ飛ばす（numpy は任意の依存。numpy の無い CI で落ちていた）。
• (JA) CaptureGroup.trigger_caps() -> TriggerCaps | None: capture-group の describe の trigger_caps（§4.4、0x41）を読む（max_stages、
  max_terms、max_conds、cross_track、types、protocols、trigger_out_latency_ns。trigger_out が無ければ None）。takes(COND[...]) と
  kinds()（宣言された条件の型の名前）で、bind の前に頼めるかを確かめられる。宣言なしや知らない形では None（宣言は目安で、正しいのは
  bind の答え）。wireskein の依頼。P4X（5a61110）で level、edge、cross_up、cross_down と読めた。
• (JA) capture_blocks.segment_columns / LogicCapture.columns(data, samples): 形式 1 の区画を、ブロックを作らずに列で読む（numpy が要る）。
  raw のチャネルはビット列、events のチャネルは区画を通した刻み（EventColumn: quanta、levels、counts、start_level）。fallback の
  ブロックは、その標本から probe と同じ数え方で刻みに直す。検査は read_logic_blocks と同じ。ヘッダだけを Python で辿り、raw は
  （fallback の組、r）ごとにまとめて、events は区画の全行を一度に読む（wireskein の提案と試作。60 ブロックの区画で 54 → 10 ms）。
• (JA) 仮想ベンチ: 形式 0 / 4 とアナログの streaming も、1 回の tick で作るサンプルを BLOCKS_A_TICK までにした（形式 1 と同じ。作れる
  速さで遅れて流す）。前は経過した時間ぶんを一度に作ろうとして、tick が長引くほど次の tick が重くなり、1 MHz × 2 本でも 0.3 秒の
  あいだ push が 1 つも来ず、stop の応答に 12.8 秒かかっていた（wireskein の報告）。
• (JA) oep-spec e1d5495 に追従（registry とベクタを取り込み）。configure / query の応答の judge_latency_ns（§3.3）を
  Config.judge_latency_ns で読む（組の出来事の元の条件を判定するトラックの、出来事と知るまでの最大の時間。返さない probe は None）。
• (JA) UsbAsyncStream.DEPTH の既定を 32 から 128 にした（64 KiB × 128 = 8 MiB、40 MB/s で 200 ms ぶん）。P4X の 40 MHz・8 本の 30 秒で、
  32 では USB の受け取り側のときどきの止まり（URB の出し直しの遅れ、バス）で 0.2〜0.6 % を落とした。128 では wireskein の 2 回と
  こちらの 5 回（形式 0 を 4 回、形式 4 を 1 回）、すべて落としなし。
• (JA) LogicCapture.stream() の keepalive の間隔を、同じ into の呼びをまたいで数えるようにした。前は呼ぶたびに数え直していたので、
  0.2 秒ずつ刻んで呼ぶ host では keepalive が 1 度も出ず、30 秒の取得の途中で lease が切れていた（wireskein の報告）。
• (JA) capture.CaptureDrops.buffer_peak: Arduino の firmware の capture-drops に足された最後の u32（ストリームの溜め、P4 では PSRAM の
  DMA リングが、送られずに持っていた最大のバイト数）。前の形（30 B）は buffer_peak を None にして読む。
• (JA) oep-spec 569e86b（capture §3.3 stream_buffer）に追従。Config.stream_buffer と Config.tolerable_delay_s()（host が読みを止めて
  よい時間の目安。形式 1 / 2 は最悪の帯域を渡す）。仮想ベンチは streaming の応答で 1 MiB を返す。link.reader（"usb-async"、"usb-sync"、
  ほかは stream の型の名前）で、どちらの USB の読みかが分かる（wireskein の依頼。同期の読みでは host の揺れが probe の落としになる）。
• (JA) 名前付き拡張（core §2.2、tag 0x7F）を共通に読む: message.named_extensions(tlvs)、Tail.named()（名前 → data、同じ名前は最初）。
  キャプチャの Status.named。Arduino の firmware 独自の診断 capture.CaptureDrops（io.github.open-embedded-probe.capture-drops:
  落としの内訳、経路、stage の数、メモリ）を CaptureDrops.of(status) で読む（wireskein の依頼）。registry と vectors は oep-spec 0eb94f8。
• (JA) 受信: 呼び出し側の時間切れの時点で frame が途中まで届いていても、FramingLost にしない（届いた分を取っておいて次の呼び出しで続ける）。
  FramingLost は、frame の途中で受信が probe_frame_gap_ms 以上止まったときだけ。16 KiB の push が 20 ms の pump の境目にかかると「区切りが
  崩れた」とみなして同期をやり直し、その間の push を捨てていた（2026-10-20、P4X の形式 4）。
• (JA) capture_blocks.LogicBlock.start_levels: events のチャネル全部（fallback も含む）の、ブロックの直前のレベル（§1.3 start_level）。
  区画の境目の変化を、fallback のブロックでも数えられる（wireskein の依頼）。
• (JA) 仮想ベンチ: 形式 1 の streaming は、1 回の tick で作るサンプルを BLOCKS_A_TICK までにする（作れる速さで遅れて流す）。stop は作りかけの
  ブロックだけを閉じる。2 MHz × 4 本で、遅れを取り戻そうとして応答しなくなっていた（wireskein の報告）。
• (JA) 仮想ベンチの §4.4 を oep-spec e87b50b に合わせた（段の入り口の when、アーム前の最後のサンプルとの比較、決めた段のトラックの不確かさ）。
• (JA) oep-spec 8e7ca20 の capture に追従（第 1 波）。
  • 形式 1（ロジックのブロック、§1.3）: capture_blocks.read_logic_blocks で復号する。raw と fallback のチャネルはビット列（bytes）で、events の
    チャネルは (tick、level、count) で返す。numpy があれば、見出しだけを Python で読み、残りを numpy でまとめて読む。
    LogicCapture.configure(data_format=, events=, roles=, block_max=) で設定し、read_segment は区画の終わり（次の区画の position か
    write_pos）まで 1 回で読む。lc.blocks() で復号し、worst_bytes() で最悪の大きさを計算する。
  • 形式 4（試験の並び）: ストリームの position k のバイトが k & 0xFF になる。
  • trigger_opts（arm、rearm、when、hysteresis）は capture.TriggerOpts で設定する。既定は arm 1、when 0 で、前の版の「最初に見えた条件で立つ」は
    arm 0、when 1 で表す。
  • トリガの記録（§3.10）は lc.triggers() で読む。triggered の出来事は record、sample、uncertainty_ns も持つ。
  • 仮想ベンチ: P4 のロジックは形式 1（mode 1 / 2）と形式 4 を、アナログは形式 4 を宣言する。rearm 1 の repeat では区画の間も state 3 のまま
    待ち、status の flags bit2、区画の flags bit3 / bit0 を立てる。configure は実装した TLV だけを知っていて、ほかを critical なら unsupported で
    断る。capture-group の force は §4.4 を入れるまで ops から外す。
  • conformance: triggers と group の force を任意の op として扱い、bind の TLV が定義されていても通す。
  • 仮想ベンチの形式 1 は streaming にも対応する。ブロックは揃ってから送る。stop では短い最後のブロックを送る。区画の位置は、区画が始まるたびに
    記録した表から引く。購読が無い間に始まった区画は丸ごと捨てる。
  • capture-group §4.4 の出来事の元（trigger source）を入れた。
    • クライアント: capture.TriggerSource、Stage、Cond（level、edge、cross_up / cross_down、above / below、timer）で式を組み、
      CaptureGroup.bind(tracks, source) で送る（どれも critical）。CaptureGroup.force()、GroupStatus.trigger（fn、ns、uncertainty_ns）、
      group の triggered（trigger_fn、record、ns、uncertainty）。トラックは trigger=(LINKED, 0, 0) と自分の pretrigger で configure する。
    • 仮想ベンチ（P4 の group）: features bit 0 と trigger_caps を宣言し、force を持つ。持つものは、4 段 × 4 項 × 4 条件、トラックをまたぐ AND、
      count、within_ns、on_timeout 0 / 1、abort、arm。rearm 1、外部の入力、trigger_out、serial は持たない。
      • 判定は、項が見るトラックのうち最も速いもののサンプルで行う（時刻の来たサンプルだけを見る）。
      • 出来事では、各トラックが自分のサンプルで区画を切り、自分の triggered を送る。
      • linked のトラックを単独で start すると cause 6、trigger source の組に linked でないトラックを入れると cause 6。
  • 仮想ベンチの --logic-wave ROLE=SPEC（virtual_bench_capture.logic_wave）: ロジックの役割ごとに波形を選ぶ。counter、quiet[:LEVEL]、
    square:PERIOD、uart:BAUD[:TEXT]（8N1 の文字、文字の間はアイドル）。静かな線と UART のような線で、形式 1 の典型の帯域を測れる
    （§1.3 の例: 2110 B / ブロック、125 MHz で 64.4 MB/s。仕様の見積もりは 63.6 MB/s）。

Repository: https://github.com/Open-Embedded-Probe/oep-client-python

Full Changelog: v0.0.34...v0.0.36

v0.0.34

0.0.34

• (JA) oep-spec bc52327（debug §2 の閉じた後の保持、§2.2 holds、probe.config の wire-hold、core §8 の例外）に追従。仮想ベンチは、線切れ以外で
  接続を閉じたらその口の休みの状態を保持し、ピンを取られる、wire-hold が off、idle / disable の項目、で保持を終える。駆動が止まると halt を失う
  target（VirtualTarget.needs_drive、CH32L103）を表せる。クライアントは WireBase.holds()、config.WireHold、oep config wire-hold PROBE CH on|off。

Repository: https://github.com/Open-Embedded-Probe/oep-client-python

Full Changelog: v0.0.33...v0.0.34

v0.0.33

0.0.33

• (JA) oep-spec ba4e8ee（debug §3.1、core §12 規則 8、probe.config の rvswd-rest）に追従。rvswd の線の休ませ方は、attach の idle_clock が無ければ
  probe が決める（その SWCLK の channel の設定 rvswd-rest、無ければ target_id の系統: CH32L103 は low）。仮想ベンチはそのとおりに休ませ、attach の応答と
  connections に使う休ませ方を返す。クライアントは Wire.idle_clock、ConnectionInfo.idle_clock で読み、config.RvswdRest と
  oep config rvswd-rest PROBE CH auto|high|low で口ごとに自動を止められる。
• (JA) oep-spec 91209aa の線の名前（swdio / swclk / swio / rx / tx）を registry から引く（config.LINE_NAMES）。console-passthrough は 13 byte のまま
  （91209aa の idle_clock の欄は oep-spec edbe841 で取り下げ）。
• (JA) tests/hw: OEP_HW_IDLE_CLOCK=low|high で rvswd の attach に休ませ方を明示できる。無ければ probe の判定に任せ、結果に使った休ませ方を記録する。
• (JA) CI: equipment の段が走ったときだけ証跡を upload する（テストの段が落ちると .pytest-results/ が空で警告が出ていた）。

Repository: https://github.com/Open-Embedded-Probe/oep-client-python

Full Changelog: v0.0.32...v0.0.33

v0.0.32

0.0.32

• (JA) 仮想ベンチに --minimal-ops（virtual_bench.minimal_ops）を足す。console と fixture UART の任意の op（marks、clear、mark、write）を
  ops から外し、unknown_operation で答える。host が任意の op を describe の ops を見ずに使っていないかを、実機なしで試せる
  （oep-spec 0c5cb8c / dbfa865 の適合の項目。ch32rv のモニタが最小構成の console で止まった事例からの提案）。
• (JA) oep-spec 67876b7（probe.config §1.2 console_passthrough）に追従。仮想ベンチは、セッションがその口とピンを使っていない間、止めない attach で
  target のコンソールの出力をフレームの外で口へ送る（OEP の接続・ストリームは作らない。試し直しは swio だけ）。クライアントは config.ConsolePassthrough。
• (JA) oep-spec df32360 / 91a5653（probe.config §1.1 passthrough、transports §4 の素通し）に追従。仮想ベンチは、セッションがその口・fn・RX のピンを
  使っていない間、fixture UART が受けたバイトをフレームの間に送り、後ろに区切りの 0x00 を置く。クライアントは config.Passthrough で設定・読み出し・解除する。
  実験（docs/spec-follow-notes.ja.md R8）: テキストのコンソールを素通しにしても、セッションの外の照会・セッションの要求とも失敗 0。
• (JA) oep-spec cf69012（link §3: phase 3 は理由によらず取り消さない）に追従。仮想ベンチと検査器の論理モデルから idle の復帰保留の取り消しを外し、
  検査器の PENDING-IDLE-OWNER / -OTHER は phase 3 のまま旧 baud で答えてから戻ることを求める（故障注入は取り消してしまうモデル）。
• (JA) oep-spec bd40a9c（debug §4.1「やり直してよい群」）に追従。RiscvDm.held は、DM の作業用レジスタと、値のほかに作用の無いレジスタ
  （GPR、dpc、dcsr）の読み書きだけの群（same_value_rewrites）を、確かめられなかったときに新しい corr でやり直す。それ以外の書き込みを含む群はやり直さない。
  write_register は GPR / dpc / dcsr で同じ群に読み戻しを入れ、線のちらつきで取りこぼした書き込みを成功として返さない（以前は黙って書き損じた）。
  仮想ベンチのリンク断のモデル（5 種、全アクセス位置）での試算: read_register 38.9% → 100%、write_register 36.7% → 96.7%、dpc の読み 34.7% → 97.9%、
  誤った値・誤った書き込みは 0 件。
• (JA) RiscvDm.held: 応答が success でも前後の look や二度読みが合わなかった群のうち、書き込みを含むものはやり直さず、
  LinkNotHeld で止める（common §3、core §4.2: 作用が不明な書き込みを新しい corr で繰り返さない）。読むだけの群はこれまでどおりやり直す。
  落ちやすい debug link（CH32L103 と RVSWD）では read_register / write_register が LinkNotHeld になりやすくなる。緩めてよいかは仕様の判断を待つ
  （docs/spec-follow-notes.ja.md の行 7 / U4）。
• (JA) TCP の接続を開き直したとき（transports §5: 区切りを失った）、Host は次の要求の前に、残っている購読を同じ条件で購読し直す。
  購読は閉じた接続へ送り続け、新しい接続へは持ち越されない（core §6.2、§10.3、transports §3）ため、以前は開き直した後のストリーミングのデータが黙って止まっていた。
  host ガイド §12 の「同じ session_id の open で通知が移る」は core と食い違う（docs/spec-follow-notes.ja.md の U1）。
• (JA) 第 8 回のレビュー（docs/trace/review8/）は途中で打ち切った。core §0〜§7・restart・plan と debug の一部で見つけた食い違いの修正だけを入れた（全試験と check_trace は通る）。a09fa45 への追従はここで区切り、以降は下流のモジュールや実機で見つかったものを都度直す。
• (JA) 第 7 回は単位ごとではなく、繰り返し現れる誤りの種類ごとにコード全体を掃いた（docs/trace/review7/、6 種類・約 1070 か所）。46 件の食い違いを見つけて直した:
  • 応答・断りの payload を完全一致で比べていた検査器（14 件、core §2.3 / §4.3: 固定部分の後ろの TLV は空の固定部分と rejected にも付く）。
  • 応答 TLV の読み手（7 件）: 壊れた後続のコピーが正しい最初のコピーを隠さない、unit_id・transport は定義の長さのときだけ使う、後続のコピーも検証する。
  • 任意のものを必須にしていた検査器（11 件）: 再送の記録（core §5.1）、1 回の read の量、I2C / SPI の features、halt する attach の dpc、2 本目の TCP 接続。逆向きに、空の read_rx と write の無い UART の TX を検査に足した。
  • host の待ちと立て直し（7 件）: core §4.4 の下限を全要求の処理時間の上限で数える、シリアルの口で諦めた要求も経路の立て直しと boot_id の確認へ、再起動を見た open の後は describe を読み直す、port_speed の戻しの答えを失ったら状態を読む。
  • 要求の検証（2 件）と状態・資源（5 件）: hold_ms が max_op_ms を超える reset、bind の知らない fn、plan の保持は (fn, role, channel) ごと、plan の持つピンは idle の再設定から外す、ロックの終わりで未送信の購読フレームを捨てる、出力の idle のピンへのアナログの plan を断る。
• (JA) 第 6 回の独立レビュー（docs/trace/review6/、文書の割り振りをまた変えた）で、33 件の食い違いを見つけて直した。主なもの:
  • core §2.3 / §5.1 / §6.4 / §7.2 / §7.5 / §10.3、transports §5、common §1.3: 応答の TLV は定義どおりの長さと最初のコピーだけを使う（capture・riscv の読み手）、TCP で再送を諦めたら接続を閉じて開き直す、区切りを失って静かにならない口は閉じて開き直す、list の数えた並びの後ろは TLV、owner を実装しない probe を許す、x- の unit_id で経路をまとめない、serial の範囲は持っている印どうしの差。
  • debug §1 / §2 / §3 / §4 / §4.6 / §6: role_channels は挙げた role だけを縛る、線の応答が無い間は放して休ませる、遅い速さでの再試行は任意、attach の flags bit0、resume の前に DATA0 / DATA1 を戻す、コンソールの読みで havereset を確認応答する、ブロックの op の無い arm-adi は生の transfer で組む、features は bit が立つときだけ欠陥。
  • 検査器: 固定部分が空の応答や断りの payload の後ろの TLV を認める（link、probe.config、fixture、plan）、断りが 2 つ当たる組を送らない（capture）、アナログの取得中の pad を空きの状態と比べない、save の間に来た要求を順に答える。
• (JA) 第 5 回の独立レビュー（docs/trace/review5/、文書の割り振りをまた変えた）で、31 件の食い違いを見つけて直した（第 4 回は 41 件）。主なもの:
  • core §2.2 / §2.3 / §4.3 / §4.4 / §6.4 / §7.2 / §7.5 / §10.1 / §10.3: 応答の bit 7 の立った TLV を知らない tag として読み飛ばす、繰り返さない tag は最初のものだけを使い長さは定義どおりに確かめる（describe を読むクライアント各所）、locked の残り時間は 0 でもよい、検査器の待ちを §4.4 の下限以上にする、owner は最初の正しいコピーを使う、list の revision は名前と組で選ぶ、unit_id は 1〜32 byte の a-z 0-9 -（x- は名指さない）、待っていない corr の応答はどのフレーミングでも捨てる、購読の保持量が足りなければ cause 2 で断ってよい。
  • debug §1 / §2 / §3 / §4 / console §1: channel_group と role_channels の両方に合う組だけを使う、attach reset の後の待ちも max_op_ms に収める、後続の同じ tag も検証する、halt / resume は任意の op、reset の前に DATA0 / DATA1 を書き戻す、console の最小の op は open / read / close / streams。
  • capture §2.2 / §3.2 / §4.1: flags bit1 は stop で終わった区画だけ、repeat の release は state 3 と 5 だけ解放、start の失敗の固定形から世代を取る、group の bind は frame 全体で start の答えの大きさを確かめる。
  • plan §2.1 / §2.4、fixture §2 / §3 / §4: 残る割り当ては取り直さない、unsupported は断った割り当ての tag、uart / i2c / spi の後続の同じ tag も検証する。
• (JA) 第 4 回の独立レビュー（docs/trace/review4/、コードと a09fa45 の食い違いを探すことに絞った）で、41 件の食い違いを見つけて直した。各件は仕様の一文を引用して記録してある（review4 の divergences）。主なもの:
  • core §2.3 / §4.3 / §5.1 / §6.1 / §6.2 / §7.1 / §7.2 / §9 / §12: 繰り返さない tag は最初のものを使う（ops、max_op_ms、describe の共通 tag）、open のセッションの判定を書式より先に、順 4 で断る要求も最後の corr と lease を進める、list は 1 フレームに入る分を返す、revision 0 の答えを読まない、資源の番号の使い切りは何も触る前に断る、end_previous は lock_state を先に見て空いていれば何も開かない、名前は逆 DNS か oep.<層>.<名前> だけ。
  • debug §1 / §2.1 / §3 / §4.4 / §4.5 / §6: connections の swd の tid は DPIDR、read_block / run の結果が max_frame に収まらなければ実行前に unsupported、count 0 は success done 0、reset の channel が attach のピンなら cause 1、reset channel は role 3 で宣言、scan は答えが収まる分だけ試す。
  • capture §3.2 / §3.3 / §3.4 / §4.1: trigger の role は plan の role 番号、trigger の value の範囲、ストリーミングの stop の serial_done、start の失敗とエラーの stopped reason 3、group の stopped の reason、クライアントの read が別の位置の答えを受けない。
  • plan §2.1 / §2.2 / §2.4、link §3、probe.config §1、fixture §4、common §3: plan_release の fn 0 は無視、同じ割り当ての集合は何もしない、port_speed の idle 復帰の取り消しと verify 期限の扱い、label の文字列は UTF-8 であればよい、spi-target の modes は必須、書き込みを含むかもしれない step の一覧を自動で再実行しない。
• (JA) 規則の対応表に第 3 回の独立レビューをかけた（docs/trace/review3/、文書の割り振りをまた変えた）。902 単位のうち 105 単位を弱いとして試験を足した（第 1 回 84、第 2 回 80: まだ収束していない）。見つけて直した a09fa45 との食い違い:
  • core §6.1: lease は応答を生成した時点から数え直す（送信待ち・送信完了によらない）。論理のコア（virtual_core）と、送信完了で数え直すことを求めていた独立検査器 5 本（lease、writer lease、config execution、port_speed execution、response race）を直した。
  • core §2.1: preflight と virtual smoke が、fn 0 の describe の文字列を表示の前に置き換える。
  • probe.config §3: 消去・保存の途中で完全性を確かめられない保存が残ったら、次の起動で何も適用せず storage_state 2 / reason 1 を示す（仮想ベンチ）。
  • debug §3.2 / §4 / §4.4 / §6: 失敗の後の swio の線はプルアップで放す、halt の後は haltreq を下ろす、run は要求全体を max_op_ms のうちに終える、arm-adi の read_block / write_block は組の任意（論理モデルと検査器）。
  • capture §3.3: repeat の samples を容量と関係なくバイト境界へ切り下げない、役割数で上限が rate_range を下回るときは rate の tag で unsupported。
• (JA) 規則の対応表を、文書の割り振りを変えた別の担当で第 2 回の独立レビューにかけた（docs/trace/review2/*.json）。第 1 回が ok とした単位から 80 個の弱い対応を見つけて試験を足し、除外 10 個を覆して試験にした。抜き取りの照合（docs/trace/review/sample-audit.ja.md）では、その後の無作為の 40 個すべてで試験が規則を確かめていた。見つけて直した a09fa45 との食い違い:
  • core §2.1: list のインターフェース名も、表示の前に制御文字と不正な UTF-8 を置き換える。
  • link §3: 戻りを待つ phase 3 の間は、上げた口に新しい通知のフレームを始めない（口が戻ってから送る）。
  • debug §1 / §3 / §4: scan は dmactive を立てる、attach は設定の書き込みと scratch（PROGBUF0）の書き込みと読み戻しで線を確かめ、読み戻らなければ completed failed / line で connection を作らない、method 1 で止まらない hart は timeout で haltreq を下げ hartsel を 0 に戻す、高水準の op の後は hartsel を 0 に戻す。
• (JA) 規則の対応表（docs/trace）を、書いた者と別のレビューで全 902 単位について審査した（docs/trace/review/*.json）: 名指した試験が単位の規則そのものを確かめているか、除外が妥当か。弱い 84 件は試験を足して直し、抜き取りの照合（docs/trace/review/sample-audit.ja.md）でもう 1 件を直した。その過程で見つけた a09fa45 との食い違いを直した:
  • core §4.1: session_id 0 の照会を 32768 回以上続けても、次のセッションの要求が result_lost にならない（半周の前にセッションの keepalive を挟む。メモの 6 行目）。
  • core §6.2 / §10.3 / §10.4: 持ち主が別の経路から open し直しても通知の送り先は変えない（subscribe し直したら移る）、置き換えた購読の未送信分はシリアルの口の送信待ちからも捨てる、シリアルの口と TCP の通知の送信待ちは max_frame × 2 まで。
  • fixture §3 / §4: read_rx の ns TLV は応答が max_frame に収まるときだけ付ける。
  • capture §1.2: アナログの plan が持つピンに probe.config で出力の idle を入れる set を断る（どちらが後でも）。
  • debug §4.3 / §4.5 / §4.6 / §6: クライアントはブロックの長さを max_frame にも収め、仮想ベンチは reset op と高水準の op で havereset を確認応答する。
• (JA) oep-spec a09fa45 の全文書（core、transports、common、plan、restart、link、fixture、debug、console、probe.config、capture）の規範の単位 902 個を、それを確かめる試験と故障注入に 1 つずつ対応させた（docs/trace/.json、tools/spec_units.py、tools/check_trace.py。除外は見出し行・用語集・参照の一覧・仕様書の書き方の規則・電気的な線と target 側の規則だけで、理由つき）。足りない規則には tests/test_trace_.py に試験を足した。その照合で見つけた a09fa45 との食い違いを直した:
  • transports §1 / §3 / §5: HID の report の count が長さを超えたら捨てる（切り詰めない）、HID の口は usage page 0xFF4F・usage 0x45 だけ、full speed の USB でも OUT endpoint の wMaxPacketSize で長さ 0 のパケットを送る、TCP では待っていない corr の応答を読み飛ばし、壊れたフレームでは接続を開き直して confirm する。
  • fixture §2: write を持たない UART は plan の TX role を受けない、configure していない RX のピンは空きの状態。
  • debug §1 / §3: scheme 1 の target_id 0 と 0xFFFFFFFF は「無い」、swio の attach は速さを選ばず min_clock_hz の速さ（esp32-v003 は 888888 Hz を宣言）。
  • capture §1.2 / §2.1 / §3.2: アナログの pad は取得が止まれば空きへ戻る、購読の無い間のストリーミングは送れない分を捨てて位置が飛び（flags bit0）、送る余地の無いまま始まった区画は再購読の後も丸ごと捨てる。
  • console §2: dmseq の検査器が、未同期からの初回同期に restart のマークを付けないことを確かめる。
  • core §2.3: 応答の describe で長さの違う共通 tag は使わずに読み飛ばし（Description.broken）、繰り返さない tag は最初のものを使う。interface_profiles.json の「mode0 SPI target」（max_length を u32 で書くベクタの誤り、メモ E1）はこの規則で読み、xfail は無くなった。
• (JA) 段階 9 / 9b を規則ごとに確かめ直した（docs/stage9-rule-trace.ja.md）。console の describe mechanisms を仕様どおり n(u8)、n × mechanism で宣言・読みするように直した（仮想ベンチ、Console.mechanisms()、oep dump、検査器とそのモデル。これまで n が無かった）。宣言の検査は n ≥ 1・重複なし・count の一致も確かめる。故障注入を足した: probe.config の項目番号 0・範囲外 channel・長さ違い・未知の mode を受け付ける、変えない set でピンを触る、console の streams の順番違い、失敗した reset にマークを付ける、mechanisms の count 無し / 重複 / 空。
• (JA) oep-spec a09fa45 の節ごとの確認表（docs/spec-a09fa45-sections.ja.md）を足した: core / transports / 各インターフェース文書の番号付きの節ごとに、名指して確かめる試験と独立した検査器を挙げる。足りなかった節に試験を足した: oep.probe.plan の各規則（tests/test_plan.py: list に出す条件、セッションの資源、§1 の宣言、§2.1 の置き換えと原子性・残る割り当て・cause 6 / 4 / 2、§2.2 の解放、§2.3 のピン、§2.4 の断り方）、common §1.5（位置の飛びは通知の欠落で、保持は read で確かめる）、core §2.7 / §12.1、capture §3.1 / §3.6（tests/test_spec_sections.py）。
• (JA) swd の scan と detach をクライアントから送る試験を足した（oep-if-debug §5 の形）。scan の行の Found.id（rvswd / swio は DMSTATUS、swd は DPIDR...

v0.0.31

0.0.31

• (EN) No user-facing changes recorded.
• (JA) ユーザー向け変更の記録はありません。

Repository: https://github.com/Open-Embedded-Probe/oep-client-python

Full Changelog: v0.0.30...v0.0.31