（非適用）セッション参照helperの複雑化を止める

最初の案は、明示されたexact session IDだけをstate databaseで照合し、activeな対象session recordをread-onlyで開く構成だった。directory探索、raw transcript出力、permission緩和、別UIによる迂回を禁止し、schema、path、symbolic link、file identityが一致しない場合はfail closedで停止する。

IDが不明な場合に備え、parent titleとdirect spawn relationによるmetadata-only discovery、複数のliteral anchorをすべて含む検索、titleを使わずdirect relationとworkspaceを照合するrelation-first discoveryへ範囲が広がった。各modeは自動fallbackせず、候補をprivate packetとして返した時点で停止し、exact IDの確認前には本文を開かない契約にした。

抽出側では、同じO_NOFOLLOW descriptorからmetadata、hash、records、read前後のidentityを作り、request fileのcanonical containmentと全parentのsymlink拒否を確認した。artifact、line、record、stdoutに上限を置き、secret-like valueを見つけた場合はexcerptを返さず停止する設計を試した。

• 同一snapshotを保証できない再open処理を、単一descriptorのstreamingへ改めた。
• underscore形式だけでなくhyphen形式のsecret-like valueも停止対象にした。
• workspace外、credential-like path、parent symlink、読取中の差し替えを拒否した。
• home pathとemailのredaction、実行したfixtureからのtest件数算出を追加した。

検証を進めると、実セッションでpositiveな抽出を再現できておらず、0件の結果だけではhandoff能力の証明にならないことが分かった。また、streaming中に同じfileへ追記された場合、累積読取byteが上限を越える前に止める保証も不足していた。

exact参照から複数のdiscovery mode、confirmation、snapshot、redaction、上限管理まで拡張した結果、当初の目的に対して検索と実装が過度に複雑化したと判断された。成果は適用せず、作業系統を打ち切ることにした。

- Codex session参照の変更では、session reference helperがcanonical lowercase UUIDv7だけを受け付け、CLI path / DB上書き、directory scan、archived / 別session、raw transcript、Computer Use / 別UI fallbackを拒否しているか
- state DBがread-only + `query_only`のexact active lookupで、schema / row count / root-date-basename / metadata ID / symlink / descriptor identity mismatchをfail-closedにするか。metadata、hash、records、before / after statが同一`O_NOFOLLOW` descriptorのsingle streaming snapshotから生成され、再openしていないか
- request fileがcanonical repository containment、全parent symlink、credential-like name、descriptor-based readとread-time identityを検証するか。`sk_` / `rk_`と`sk-` / `rk-`を含むsecret-like matchでexcerptを出さず、一般absolute home path / email redaction、record / output上限、fixture-only read-only / concurrent-mutation / request TOCTOU coverageがあるか