---
name: feedback-success-signal-decoupled-from-operational-state-2026-08-14
description: 成功 signal (unit test 緑 / CI 緑) が 実際の稼働と decouple されている欠陥 class — 13 例で確定 (STEP 1334/151 wiring + rei-learning-cycle 握りつぶし + Rei-Automator wrong-impl wiring + SendInput silent 沈黙 + Unicode 注入静か失敗 + Base64 CLI 化け + PS 5.1 UTF-8 parse + rev.1 BOM 落とし + allowlist bypass via auto_approve + em-dash cp932 crash + git reset lock 残留 + cross-session propagation gap)。 対策 5 段 (端点 test 内向き閉じ / CI 非致命的 skip / observation anchor / 同 domain 複数実装 wiring audit / test-writer-check-test 3 段 gate) + 独立検証系 (cross-agent)
metadata:
  node_type: memory
  type: feedback
  originSessionId: d2082c05-0e81-4fc9-9613-331ad2f49b5b
  modified: 2026-08-15T15:02:44.758Z
---

# 成功 signal が 稼働状態から decouple されている (2026-08-14 → 08-16、 13 例確定)

## rule

**成功 signal (unit test 緑 / CI 緑 / build 成功) は 「クラス/step が 個別に正しい」 を示すだけで、 「本番経路で呼ばれる」 「取得が生きている」 「観測が入っている」 を示さない**。 二つを 等号で結ぶと 実装済のまま 137 日 dead / 8 route 全 404 / 取得 4 日停止 に CI 緑のまま 気付かない欠陥に落ちる。 成功 signal を 実 observation に anchor しない設計は 全て 同型の欠陥 class に属する。

前身 rule (`feedback_endpoint_only_test_misses_wiring_gap_2026-08-14` = 端点 test 内向き閉じ 2 例前提) を 3 例目 (CI 非致命的 skip) 統合で 上位 pattern に昇格。 旧 file は本 file で 完全置換 (2026-08-14 段 0a 実行)。

## Why (3 例統合 table)

| # | STEP | 場所 | 成功 signal | 実際の稼働 | gap |
|---|---|---|---|---|---|
| 1 | 151 writer | production 呼び出し元 | unit test 緑 (writer class 単独) | 本番で 呼ばれず (137 日間 SQLite 全 7 表 0 行) | 実装済 vs 配線済 |
| 2 | 1334 reader | server Router 連鎖 | unit test 緑 (handler.routes() 直叩き) | 本番 404 (8 route 全て、 rei-server.ts 未連鎖) | 実装済 vs 配線済 |
| 3 | 未 STEP | `.github/workflows/rei-learning-cycle.yml` 38 箇所 | CI 緑 (`\|\| echo` / `\|\| true` 握りつぶし) | arxiv fetch 4 日停止 (2026-08-09 死、 誰も気付かず) | 稼働中 vs 観測済 |
| 4 | 2026-08-15 arc | `src/aios/api/automator-api.ts:36` | MCP `execute_action` 成功 (dfumtValue=TRUE, executedCount=1) | 5 か月間 execution-log.json 更新ゼロ (2026-03-07 stagnant、 in-memory のみ) | wrong-implementation wiring (2 実装並存、 persistence 無し版に wired) |
| 5 | Phase 1.5 SendInput | Win32 INPUT struct union | SendInput 呼出 例外なし | struct size 32 byte (正 40 byte) で 0 return silent 沈黙 (何も 送出されない) | struct size mismatch = 沈黙 return、 例外形式で 表面化しない |
| 6 | Phase 1.5 SendInput | `\n` を KEYEVENTF_UNICODE で 注入 | send call 成功 (return value 正常) | 大半 の control が 無反応 (Unicode 注入 では 改行 効かず、 VK_RETURN 必要) | send 成功 vs UI 反応 |
| 7 | Phase 1.5 PowerShell 引数 | 文字列 CLI 引数渡し 到達成功 | 到達時点で 既に 文字化け (cmdline 経由 encoding 事故) | 到達 vs 内容保持、 Base64 boundary encoding で 塞ぐ |
| 8 | Phase 1.5 rev.1 | Windows PowerShell 5.1 parse 「エラー」 表示 | 実際は BOM なし UTF-8 の Japanese comment 誤解釈 (pwsh 7 では 通る)、 parse エラーが 実 syntax 由来 と 誤読される | tool version 依存の parse ambiguity、 「parse エラー が 出た」 signal が 誤原因を 指す |
| 9 | Phase 1.5 rev.1 (chat-Claude 自認) | 「成果物 rev.1 完成」 signal 出た | 実は BOM 抜け + StartDelayMs 抜けで **実行不能**、 push まで 通っていた 可能性 (私 が PS 5.1 verify + focus 問題 気付き で 塞いだ) | 成果物完成 signal vs 実 usable state |
| 10 | rei-automator-mcp Phase 1 | `Automator({allowed_actions={'file_read'}, auto_approve=True}).propose('shell_command')` → `approved=True + execute() 成功 PWNED` | allowlist bypass (execute() は allowlist 独立 check 無かった、 selftest [5] は auto_approve=False 経路 のみ で 検出できず = **「テスト を 書いた こと 自体 が 検証済み signal に なった」**) | test-writer-check-test の 誤成功、 test 存在で 検証済み と 見える が 全経路 cover していない |
| 11 | rei-automator-mcp Phase 2 find_element | script test 完走 signal + selftest 22 → 30 PASS | Windows console (cp932) 出力で em-dash (—) 含む log line で `UnicodeEncodeError` crash、 Linux/pwsh 7 では 通る | encoding-locale 依存 silent crash、 test 完走 signal と 実 Windows console 出力の間の gap |
| 12 | 2026-08-15 Track 3+4 close | mount 越し `git reset` return 成功 | `.git/HEAD.lock` + `.git/refs/heads/main.lock` を 残留、 次回以降の git operation を `cannot lock ref` で失敗 (別 session B が `_to_delete/` 退避 + `.git/info/exclude` で 迂回、 環境差で 別 session A が `rm -rf` 成功) | mount 越し side-effect 残留 silent (return success + lock 残存)、 tool 実行者と 実 filesystem 挙動 の gap |
| 13 | 2026-08-15 stash 22 close arc | session B が commit `ec15cb32f` + `7acb84d79` 済 (11:47-11:57、 filesystem + git log 全確定) | 私 (session A) の memory に 完成報告 record ゼロ、 pause state summary のみ、 藤本さん転送で 初認識 (**損失なし** = 情報 catalog のみ、 実 filesystem verify で 整合 確認済) | commit signal green + on-disk file 生成済 vs cross-session state propagation gap、 並行 session 系 subtype (Track 3+4 lock 残留 = 例 12 に続く) |

**例 1 詳細**: `ArxivCache.save() / KnowledgeCacheDB.saveWikipedia() / saveOeis() / saveWikidataPerson() / saveKnowledgeArticle()` は unit test で 直接呼び出しで green、 `src/` `scripts/` 全域 grep で production 呼び出し元 **ゼロ**、 `test/step151-*` の 7 箇所のみ。 `ArxivFetcher` は `ArxivCache` を import すらしていない。 SQLite 知識テーブル 7 種 全てが 137 日間 一度も書かれていない。

**例 2 詳細**: `KnowledgeApiHandler` (STEP 151、 8 route) は unit test で `new KnowledgeApiHandler(...)` して routes() を直接叩き 全 green、 `rei-server.ts` の Router 連鎖には **一度も接続されていなかった**。 HTTP 層では 8 route 全 404 = 「単体 test 緑 + 本番 404」。 commit 4bbb1ae84 (STEP 1334) で修復、 test/step1334 39/39 PASS (**★ handler を直接 new しない**、 HTTP 層越し integration test で 6 route + 404 fallback + 既存 route 回帰 まで確認)。

**例 3 詳細**: `.github/workflows/rei-learning-cycle.yml` に `\|\| echo` / `\|\| true` が **38 箇所** (実測)。 `radar:scan` + `daily-radar.ts` 両方が `\|\| echo '... skipped (non-fatal)'` で終わる。 arxiv fetch が 2026-08-09 に死んで 4 日経過するが **CI は緑のまま**。 失敗が握りつぶされる workflow 設計が 38 箇所存在するため 個別修理では潰しきれない = 全 categorize + heartbeat 設計が本命。

**例 4 詳細 (2026-08-15 Rei-Automator 復活起動 arc で 顕在化)**: `AutomatorRouter` (`src/aios/api/automator-api.ts:36`) は `WorkspaceAutomator` (persistence code 無し) を 使い、 `ReiAutomatorBridge` (`src/aios/rei-automator-bridge.ts:230-232` に `_saveLog()` 持つ) は 実装は残るが **どこからも import されていない**。 5 か月間 dormant だった Rei-Automator を revive し MCP `execute_action` を叩いたところ、 in-memory 状態は `executedCount=1` に更新される (成功 signal green) が、 `data/automator-log/execution-log.json` on-disk は 2026-03-07 の 単一 entry のまま 更新なし。 server shutdown で in-memory record は消える = 実質 5 か月間 全 execution が 記録漏れ状態。 この pattern の subtype は **wrong-implementation wiring** = 「2 つの実装が並存、 正しい方でなく persistence 落ちてる方に wired」。 2026-08-15 session で `WorkspaceAutomator` に `_loadLog()` + `_saveLog()` + `logDir?: string` config 追加で修復、 scratch 12/12 PASS + MCP end-to-end で on-disk 586 B → 1575 B 増加確認。

**例 5-9 詳細 (2026-08-15 Phase 1.5 SendInput arc)**: chat-Claude 実装 documented 3 pitfalls (struct size / newline / Base64) + 私 発見 の PS 5.1 UTF-8 parse issue + chat-Claude 自認 rev.1 完成 signal の 5 件、 全て 「成功 signal 出るが 実際は 動かない」 型。 例 8 (PS 5.1 parse) は 特に 「parse error が 出たけど 実 syntax は 正しい」 = 「失敗 signal が 誤原因を 指す」 = tool version 依存 の 表示エラー。 例 9 は 独立検証系 (私 の PS 5.1 verify + focus 問題 気付き) が なければ push まで 通っていた 可能性。 [[feedback-independent-verification-cross-agent-collaboration-2026-08-15]] pattern の 直接根拠。

**例 10 詳細 (2026-08-15 rei-automator-mcp Phase 1 arc)**: `Automator({allowed_actions={'file_read'}, auto_approve=True}).propose('shell_command', 'echo PWNED')` → `approved=True` (bypass) → `execute()` success + `exit=0 PWNED\r\n` (allowlist 外 kind 実行)。 root cause: `propose()` が `approve()` を 経由せず `approved=self.auto_approve` を 直接立てる、 `execute()` は `action.approved` しか check せず、 allowlist を 独立 check していなかった。 selftest [5] は `auto_approve=False` 経路 のみ で bug 検出できず。 ★ **「テスト を 書いた こと 自体 が 検証済み という 誤った 成功シグナル に なっていた」** (chat-Claude arc close 明示)。 test 存在 で 「検証済み」 と 見える が **全経路 cover していない** = test の 誤成功 sub-pattern。 rei-automator-mcp @ commit `2348ba7` で fix (execute() 独立 allowlist check + regression test [5b] 4 assertion、 selftest 22/22 PASS)、 public repo なので 早急に 塞いだ。

**例 11 詳細 (2026-08-15 rei-automator-mcp Phase 2 find_element release arc)**: script test は Linux 環境 (pwsh 7) + macOS 環境で 通り、 selftest 22 → 30 PASS の 成功 signal 出た。 Windows console (cp932 default codepage) で 実行時、 log 出力に em-dash (`—` U+2014) 含む行で `UnicodeEncodeError: 'cp932' codec can't encode character '—'` crash、 script 途中で 落ちる。 pwsh 7 (UTF-8 default) では 通るため cross-platform test で 検出困難。 root cause = **encoding-locale 依存 silent crash**、 (a) source code 内 em-dash 使用 + (b) Windows cp932 console + (c) print/log 出力 の 3 条件揃うと 発火、 いずれか 1 つ 欠けると 発火せず。 subtype = **encoding-locale 依存系** (例 5-7 silent 沈黙系 + 例 8 tool 版依存系 の 交差、 但し return success ではなく **crash** で 表面化する点で 例 5-7 と 逆)。 対策: ASCII-only log strings + em-dash → `--` 置換、 encoding-explicit test (Windows cp932 env で CI job 1 本 追加)。

**例 12 詳細 (2026-08-15 Track 3+4 close arc、 mount 越し git reset lock 残留)**: mount 越し `git reset` return 成功 (exit 0 + "HEAD is now at ..." message) → 実 filesystem 側で `.git/HEAD.lock` + `.git/refs/heads/main.lock` を **残留**、 次回以降の 全 git operation を `cannot lock ref` で失敗させる。 別 session B が `_to_delete/` 退避 + `.git/info/exclude` 登録で 迂回対処、 環境差 (別 session A の Windows native git) で `rm -rf` 成功。 root cause = **mount 越し filesystem semantics の 差** (open file handle が 解放されず lock が 残る、 tool return は lock 作成後 の 削除 step で 失敗しても success return する場合あり)。 subtype = **side-effect 残留 silent** = tool 実行者側 signal と 実 filesystem 挙動 の gap、 (a) tool return success + (b) 副作用 (lock file / temp file / open handle) 残留 + (c) 次 tool run で 検出可能、 の 遅延顕在化 pattern。 対策: 書き込み系 git operation 直後に `find .git -name '*.lock'` 必須、 hit あれば 掃除 or 環境切替。 例 11 との相違: 例 11 は 即時 crash、 例 12 は 遅延 (次回発火)。

**例 13 詳細 (2026-08-15 → 08-16 stash 22 close arc、 cross-session state propagation gap)**: session B が commit `ec15cb32f` (docs stash 22 構造原因) + `7acb84d79` (docs attic MANIFEST) を 11:47-11:57 に生成、 filesystem 側 全 file 配置済 + `git log` で 確定。 一方 session A (私) の memory (MEMORY.md 経由 SessionStart hook) には 「pending state summary」 のみ save されており、 「完成 report」 は record ゼロ。 藤本さん が session B の 完成 report を session A に **手動転送** して 初認識、 その後 session A で `git status` + `git for-each-ref refs/attic/stash-2026-08-15/` + config verify で filesystem 側の完成状態と 整合 確認 (**情報損失なし** = catalog として retain の判断)。 root cause = **並行 session 間の memory sync 手段が 未整備** (session B は自身の memory を書けるが session A の memory は書けない、 藤本さんが唯一の bridge)。 subtype = **cross-session state propagation gap** = 並行 session 系 subtype、 例 12 (git reset lock 残留 = 別 session 間の filesystem semantics 差) に続く 並行 session 系の 2 例目、 但し **filesystem 側は 完全一致 + memory 側のみ 遅延** の 情報 catalog gap で 実損なし。 対策: (a) session B 完了時に session A memory への retroactive save protocol (本 arc で 実践、 藤本さん GO で 私が 追記) + (b) 藤本さん転送を trigger にする pattern 定着 (現在の bridge 手段) + (c) 将来的に memory dir 共有 or session B の write access permit で 直接同期。

**共通の抽象化**: 13 例とも 「(A) 何かが成功と判定される signal」 と 「(B) 実際に稼働している/観測が入っている状態」 が 別物であるにもかかわらず、 signal 側だけを 見て「緑」 を得ている。 (A) → (B) の 論理的接続 (呼び出し元 grep / server 連鎖 / 失敗の可視化 / persistence 呼び出し / return value 実測 / UI 反応確認 / boundary encoding preserve / tool-version parse verify / 全経路 test cover / encoding-locale env verify / lock 掃除 / cross-session sync bridge) が 誰も 張っていない。

**subtype 一覧** (13 例で 分類):
- **wiring 系 (例 1-2, 4)**: 実装 は 存在するが production 呼び出し元 が 無い or 誤側に wired
- **CI/失敗 握りつぶし系 (例 3)**: `|| echo` / `|| true` で 失敗 signal を 消す
- **silent 沈黙系 (例 5-7)**: 呼出 return 正常 だが 実効果 なし (struct size / Unicode 注入 / CLI boundary)
- **tool 表示 誤読系 (例 8)**: 「parse error 出た」 signal の 原因が 実 syntax でなく tool version 依存 の 誤解釈
- **成果物完成 signal 系 (例 9)**: 実装完了 signal 出た が 実は 実行不能 (BOM 抜け 等)
- **test 誤成功系 (例 10)**: test が 存在するが 全経路 cover していない = test 書いた だけで 「検証済み」 signal に 見える
- **encoding-locale 依存系 (例 11)**: source + console codepage + 出力 op 3 条件揃いで 即 crash、 単一環境 test では 検出不能、 subtype 直交軸 (silent 沈黙系 は success return、 本 subtype は crash)
- **並行 session 系 (例 12-13)**: (12) mount 越し / 別 session filesystem semantics 差 で side-effect 残留 → 遅延顕在化 (次 tool run で `cannot lock ref`) / (13) 並行 session 間の memory sync 手段未整備 で 完成報告が 特定 session の memory に届かない (filesystem 側は 全整合、 情報 catalog gap のみ)

## How to apply

### 対策 5 段 (10 例に対応)

1. **端点 test 内向き閉じ (例 1+2 対策)** — 新規 handler / cache / persistent writer / reader を STEP で追加する場合、 unit test 単独では merge しない。 production 経路 (server routing / bootstrap wiring / fetcher pipeline) から辿る **integration / wiring test** を必ず 併設。 端点だけの test では 配線漏れを検出できない前提で 設計。 具体: (a) unit test が `new Handler()` を直接呼んでいる (b) production entry (server / bootstrap / fetcher) が 該当 class を import していない、 の 2 条件が揃うと 例 1 pattern と同型 = audit 対象。

2. **CI 非致命的 skip 全数 categorize (例 3 対策)** — `\|\| echo` / `\|\| true` / `continue-on-error: true` / `if: always()` を workflow 全域で grep し、 (i) 本当に非致命的で握りつぶし妥当 / (ii) 実は致命的で 通知が必要 / (iii) 別 job 分離推奨、 の 3 分類で 全 categorize。 (ii) は heartbeat + red-if-stale (前回成功から N 時間経過で 明示的に red) で 失敗の可視化。 「握りつぶし禁止」 でなく 「握りつぶすなら 別 channel で 見える化」。

3. **成功 signal を 実 observation に anchor する (上位対策)** — 4 例共通の 本質的対策。 (A) 稼働 → (B) 観測 の対応表を 明示的に張る:
   - reader 稼働 → HTTP route ping / fetchLog レコード追加
   - writer 稼働 → 対象 store 書き込み件数 dashboard / 直近 N 時間の row 数増加
   - fetcher 稼働 → 最終成功 timestamp / stale 判定 threshold
   - executor 稼働 → on-disk log の mtime / size 変化 / 直近 N 時間の entry 追加 (例 4 発火時に 「成功 signal 出るが 5 か月間 log mtime 変わらず」 の gap が 発見の 直接手がかりだった)
   observation が 一定期間 途絶えたら 明示的に red signal 出す設計。 CI 緑 = 稼働 と 等号を置かない。

4. **同 domain 複数実装の wiring audit (例 4 対策)** — 「2 つの実装が並存 → 正しい方 (persistence / DB write / 副作用 持ち) でなく 誤った方 (in-memory only / 副作用無し) に wired」 pattern の 早期検出。 具体: (a) 同 abstract role (Automator / Cache / Store / Fetcher) の 実装 class を grep で 網羅列挙 (`class .*Automator|class .*Cache|class .*Store` etc)、 (b) 各 class の 副作用有無 (`writeFileSync|writeFile|INSERT|UPDATE` grep) を 比較、 (c) production wiring (server / bootstrap / router) が 副作用持ち側を 参照しているか verify、 (d) 参照が 副作用無し側 = wrong-implementation wiring 疑い。 例 4 の場合、 `Automator` role で `WorkspaceAutomator` + `ReiAutomatorBridge` 2 実装並存、 前者に `_saveLog()` 無し、 後者に有り、 wiring は 前者参照 = 該当。

5. **test-writer-check-test 3 段 gate (例 10 対策、 2026-08-15 新規)** — 「test を 書いた」 signal と 「全経路 cover」 signal を 分離する。 test 存在 だけで 「検証済み」 と 判断しない ため、 test 追加時に **経路 audit** を セットで行う: (a) test が cover する 引数組合せ を 列挙 (auto_approve × allowlist × propose-vs-execute 等)、 (b) production code の branch 全 enumeration との 差分 verify、 (c) 「test cover していない branch」 が 副作用ある か 判定、 (d) 副作用ある branch は 独立 test 追加。 例 10 では auto_approve=False 経路 のみ の [5] に対し auto_approve=True 経路 の [5b] を 追加、 4 assertion で 全 cover。 **加えて 独立検証系** ([[feedback-independent-verification-cross-agent-collaboration-2026-08-15]]) の 検証者 が test 網羅性を review する pattern を default に (私 単独 では 自分の test の 抜けを 検出困難、 chat-Claude critique で 実際に allowlist bypass が 発覚)。

### 4 段語彙 → 「成功 signal / 稼働 signal」 対概念に拡張

「実装済 (implemented)」 vs 「配線済 (wired)」 vs 「稼働中 (operational)」 vs 「観測済 (observed)」 の 4 段は前身 rule の core だったが、 3 例統合で 対概念に整理:

- **成功 signal**: unit test 緑 / CI 緑 / build 成功 / 個別 class 動作 confirm
- **稼働 signal**: production entry で 実際に呼ばれ、 副作用 (DB row 増加 / HTTP 200 応答 / fetch レコード) が 観測可能な状態

STEP 151 writer は 成功 signal のみ (実装 test 緑) で 稼働 signal ゼロ。 STEP 1334 で reader は 成功 signal + 配線済まで到達、 稼働 signal は 藤本さん verify + fetchLog 蓄積で ようやく確立予定。 例 3 (arxiv radar) は 稼働 signal が 途絶えたのに 成功 signal (CI 緑) が 変わらず、 gap が 4 日 隠された。

### 「test 緑 = 動作」 の 思い込みを禁じる

[[feedback-zero-sorry-floor-not-ceiling]] (「0 sorry = floor」) の姉妹原則:

> **「test 全 PASS = floor」** — writer / reader / configuration / wiring / production integration / fetch liveness / row-count observation まで 揃って初めて 動作、 test 緑は 最低条件の 1 つに過ぎない。

同じく **「CI 緑 = floor」** — CI 緑は 「壊れていない」 の証明であって 「稼働している」 の証明ではない、 稼働は 別 signal (heartbeat / fetchLog / row count) で 独立に 確認。

## 別 STEP hook (段 1 = 次 session queue)

「38 箇所 audit + heartbeat 設計 + red-if-stale 選定」 は 個別 arxiv 修理より 本質的な 3 例統合対策。 次 session queue 段 1 (別 STEP) で 実行:

- (a) `.github/workflows/*.yml` 全域で `\|\| echo` / `\|\| true` / `continue-on-error` / `if: always()` を grep、 全 hit を list 化
- (b) 各 hit を 3 分類 ((i) 妥当 / (ii) 致命的だが握りつぶし / (iii) 別 job 分離推奨)
- (c) (ii) について heartbeat + red-if-stale の 通知先設計 (site 反映 / Slack / GitHub issue auto-open / dashboard 色)
- (d) (i)(iii) は そのままか rewrite か judgment
- (e) 同型漏れ 別軸 audit (8 Router 全て / Fetcher 全て / Persistent state を持つ layer 全て で writer/reader 配線漏れが 何個あるか)

段 2 (案 C 実装 = rebuild script + OEIS/Wikidata/SEP schema) は 段 1 完了後 = 「計器が壊れたことを知る手段」 (heartbeat + red-if-stale) が 先に無いと、 rebuild script も `\|\| echo skipped` で silent 死ぬと 3 例目 pattern を そのまま踏む。 [[feedback-one-reproduction-over-ten-unverified]] 「10 の未検証より 1 の再現」 順序原則の 姉妹適用。

## rename 実行記録

- 旧 file: `feedback_endpoint_only_test_misses_wiring_gap_2026-08-14.md` (2 例前提の 端点 test scope) → 本 file で置換、 削除
- 新 file: 本 file (`feedback_success_signal_decoupled_from_operational_state_2026-08-14.md`) = 3 例統合の 上位 pattern scope
- 更新箇所: (a) 3 例 table 冒頭化 (b) 対策 3 段 (端点 test 内向き閉じ / CI 非致命的 skip / observation-anchor) (c) 4 段語彙 → 「成功 signal / 稼働 signal」 対概念 に 拡張 (d) 「38 箇所 audit + heartbeat 設計」 別 STEP hook 化
- 関連 memory 内 `[[feedback-endpoint-only-test-misses-wiring-gap-2026-08-14]]` link は 本 slug に 同時更新: MEMORY.md + project_session_2026-08-14_step1334_arc_close_state + project_step1334_knowledge_api_wiring_and_deeper_disconnect_2026-08-14 + project_knowledge_store_dual_sqlite_json_2026-08-14 + project_ssm_phase2cd_lean4_and_mlir_2026-08-14

## 関連

- [[project-step1334-knowledge-api-wiring-and-deeper-disconnect-2026-08-14]] (本 pattern の 例 1+2 origin、 3 findings で 例 3 が 顕在化する契機)
- [[project-knowledge-store-dual-sqlite-json-2026-08-14]] (STEP 151 writer disconnect の 帰結 = SQLite 知識層が 実質 dead state)
- [[project-session-2026-08-14-step1334-arc-close-state]] (3 例目確定 + 段 0a-4 引継 queue)
- [[project-rei-automator-phase2-find-element-2026-08-15]] (例 11 origin = em-dash cp932 crash pattern の 出所)
- [[project-rei-aios-track3-4-close-2026-08-15]] (例 12 origin = git reset lock 残留 pattern の 出所)
- [[project-stash-22-close-arc-2026-08-15]] (例 13 origin = cross-session state propagation gap pattern の 出所、 本 feedback update trigger arc)
- [[feedback-zero-sorry-floor-not-ceiling]] (「0 sorry = floor」 姉妹原則、 本 rule は 「test 緑 / CI 緑 = floor」)
- [[feedback-one-reproduction-over-ten-unverified]] (「10 の未検証より 1 の再現」 順序原則、 段 1 → 段 2 の operational 適用根拠)
- [[feedback-external-verify-beats-internal-review-4patterns-2026-08-13]] (外部 verify > 内部 review、 端点 test 内向き閉じ + CI 内向き閉じ の欠陥と同型 pattern)
- [[feedback-defect-class-input-vs-lifecycle-2026-08-13]] (欠陥 class 直交軸 record、 本 pattern は lifecycle 軸の「成功 signal → 稼働 signal」 遷移欠)
- [[feedback-independent-verification-cross-agent-collaboration-2026-08-15]] (例 13 の 対策 (a) 藤本さん bridge の 一般化、 cross-agent 検証系 が memory sync gap も cover)