---
name: feedback-defect-class-input-vs-lifecycle-2026-08-13
description: defect class 2 直交軸 = input-deterministic (bad-bytes 型、regex+input で導ける、review 可検出) vs lifecycle-emergent (D-3 型、source-only では絶対出ない、実 execution だけで出る)。検証手法自体が直交、v0.2.5 candidate feature を並列でなく直交軸で扱う必要性の record
metadata: 
  node_type: memory
  type: feedback
  originSessionId: c3511ef5-c9e4-4d3d-ad7e-1dd6a9c51580
  modified: 2026-08-13T13:28:23.575Z
---

# defect class 2 直交軸 — input vs lifecycle (2026-08-13)

benchtop-harness Phase 3 の 2 predicted-yet-unpredicted 発見 (bad-bytes vs D-3) が **defect の異なる class に属する** ことが実測から明確になった。両者を「同格の silent 損失」と括るのは影響 deg では正しいが、**検証手法として直交** = mitigation の設計軸が別。

**Why**: 藤本さん総括「D-3 の実運用インパクトは bad-bytes と同格」に対し、Rei 側が「deg は同格でも class は別」を提示。 v0.2.5 candidate feature #1 (`channel_n_asymmetry_warning`) と #2 (port 解放) を **同 priority list に並べる** のではなく、**異なる検証軸として直交扱い** することで、将来の defect discovery pipeline が漏れなく組める。

**How to apply**:

- 「silent 損失」 = 「返り値 success + `partial: false` + 実データ欠落」 の総称、これは symptom 分類
- Root class として (A) input-deterministic と (B) lifecycle-emergent の 2 軸に分ける
- **各軸に対応する検証手法が違う** ので、v0.2.5+ feature 設計時は「(A) 用 feature」「(B) 用 feature」の 2 系列で維持
- 新 feature 提案時は「どっちの class を潰すか」を明示させる (混在してれば両方潰せていない可能性大)

## 2 class の対比

| 側面 | (A) input-deterministic | (B) lifecycle-emergent |
|---|---|---|
| 実例 | bad-bytes = `\xff` を H の直前に注入 → H だけ silent 消失 | D-3 = benchtop-mcp が port を close しない → 外部 tool 使用不能 + session 間 data 混入 |
| defect の form | 「input X → output Y (欠) は関数的」 | 「単発 open は OK / 累積で state 積む」 |
| review で見つかるか | **見つかる** (regex + input を読めば導ける) | **見つからない** (source に「close する」も「しない」も書かれていない、契約書の空白) |
| 実測で見つかるか | 見つかる (mock 1 回で発火) | 見つかる (mock を **2 回以上**、または timeline 上に session を並べて初めて発火) |
| 検証手法 | **input space の 網羅** — 極端 input / boundary / malformed の 系列 | **timeline / lifecycle の 網羅** — open 後 close せず / 2 回目 open / 隣接 process から probe / long-running |
| preflight で気付けたか | Yes (F 章の sandbox 再実装で予想成立) | No (mock 1 回では出ない、実 serial の 2 回目 measure で発火) |

## 検証手法の 直交性

**input-deterministic** の検証は input を変える:
- bad-bytes: `\xff` を 4 iter ごとに → H だけ落ちる (7/28 pattern)
- crlf-mixed: 行末を `\r\n` に → benchtop からは構造消滅
- digit-change: 桁数を 15 に → tool は検出不能 (negative finding)

これらは「function under test の domain を扱う」。regex / parser / boundary の話。

**lifecycle-emergent** の検証は timeline を変える:
- D-3: 1 回目 measure → 2 回目 drain (別 process から) で fail 判明
- B-1 (com0com 側): emitter 先起動 → measure 後起動 で buffer 消化 mode
- port open→read loop 2s: 単発 measure では見えず、emitter との相対 timing で cut #1 が吸収

これらは「system の state accumulation を扱う」。lifecycle / concurrency / resource ownership の話。

**両者は input で対処できず、timeline でも対処できない** = 検証手法自体が直交。片方に強い test suite は他方に blind。

## v0.2.5 candidate feature の 再整理

observations.md の priority list を **class 別に分解**:

**Class (A) input-deterministic 対策**:
1. `channel_n_asymmetry_warning` — session 内 ch 間 n asymmetry (bad-bytes 型 検出)
2. parse の strict mode (定義済 ch 揃わない行 skip) — line-cut 型 partial 検出

**Class (B) lifecycle-emergent 対策**:
1. port 解放 (measure 終了時 close or `close_port()` tool) — D-3
2. session 間 residual data warning (前 session の未消化 buffer を検出して warn) — B-1
3. lifecycle state audit (「今 port 何個 open してるか」を 出す tool) — D-3 診断用

**両 class 横断 (計器精度)**:
- `duration_s` 定義明記 or 改名 (`span_s` / `last_row_t_s`) — A-1 + D-2-4
- `plot_session` / `measure` にも `duration_s` — A-1
- session summary に行内 channel カバレッジ分布 — line-cut

「並列 priority list」よりこの分解の方が gap 検出精度が高い (両 class を並列で 4 個 提案しても 「両方に blind な 3 番目の class」の可能性は消えない)。

## 一般化 — 他 domain への 移植性

class 分離の 精神は benchtop 固有ではなく、Rei stack の 他 tool にも 移植可能:

- **rei-solver**: (A) input = 命題文字列の boundary / malformed / (B) lifecycle = solver session の state / cache accumulation / concurrent solve
- **rei-fpga**: (A) input = IR JSON の malformed / (B) lifecycle = yosys 状態 / bitstream cache / port ownership
- **rei-aios core**: (A) input = axiom text の parse edge / (B) lifecycle = SEED_KERNEL の shared state / invention pipeline history accumulation

**新 tool 検証時**: preflight で (A) input space と (B) lifecycle timeline の **両軸で mock を動かす** を default 化する。片軸だけでは class blindness が残る。

## chat-Claude 側での再発性 (予備 evidence)

benchtop-harness で発火した 「execution だけで出る」 pattern の 4 件 (D-3 / com0com buffering / open→read loop 2s / duration_s 非対称) は **全て lifecycle-emergent 側**。 preflight で潰した 4 件は **全て input-deterministic 側** (regex 読解 + F 章 sandbox で導出可能)。

= 「review が強いのは input side、execution が強いのは lifecycle side」 の 実測分離。 これが偶然か 一般則かは 他 domain (rei-solver Phase 3 相当 が来たとき) で verify predicate。

## 関連

- [[project-benchtop-harness-phase3-full-arc-2026-08-13]] — 本 defect class 分離の 発生現場、bad-bytes 完全的中 + D-3 発見の記録
- [[feedback-external-verify-beats-internal-review-4patterns-2026-08-13]] — execution が review を補う 5 pattern (本 defect class 分離は 5 pattern の class-level 一般化)
- [[feedback-mcp-server-verify-3layer-diagnosis-2026-08-13]] — MCP server 検証で発火した 7th 原則 (self-review 対 external-verify gap)、同じ精神系
- [[project-benchtop-mcp-v022-review-2-pack-2026-08-13]] — 検証対象 benchtop-mcp v0.2.4 arc、本 defect class 分離を v0.2.5 candidate feature 設計に適用
- [[feedback-one-reproduction-over-ten-unverified]] — 「十本未検証より一本再現」、lifecycle-emergent の 「1 本 execution が review N 波を超える」 と同じ形

## Version

- v1 initial: 2026-08-13 Phase 3 full arc close 時、bad-bytes vs D-3 の class 分離を Rei 側から追加 framing、藤本さん memory 化 signal per 保存