対外公開版（匿名化済み） — 顧客名・案件名・固有ライブラリ／パス／プログラム名は一般化しています。用語は青点線にマウスオーバーで定義を表示。巻末「用語集」も参照。
いま改めて言える結論：
Bob単体に「調査・判定・文章化」を全部任せない。
Cursor（機械抽出）→ Bob（業務向け説明）→ Codex（第三者査読）→ 人間（最終判断）の四層が、
400件超のIBM i資産でも破綻しにくい。
CursorCALL閉包・file_usage・coverage・未決の機械抽出。正本入力を作る。
Bobbob_contextを根拠にレポート化。PARTIALはSRC全行精読で昇格を試みる。
Codex反映漏れ・件数差分・確度違反の査読。文章の上手さは見ない。
人間影響調査利用可否・顧客確認・優先順位。推測で確定しない。
必ず分ける2つの判定
| 判定軸 | 意味 | いまの指針 |
|---|
| 手順の横展開可否 | 同じCursor→Bob→Codexを他機能にも使ってよいか |
条件付き可 BATCH 1〜5・査読重大0・件数差分0 |
| 個別レポートの影響調査利用可否 | その1本を移行判断の根拠にしてよいか |
別判定 技術UNRESOLVED/PARTIAL残が多いと不可 |
よくある誤解：「レポートが綺麗に出た＝影響調査完了」。
PARTIAL/UNRESOLVEDを明示した棚卸し資料は作れるが、それは完了ではない。
確度の意味（現場向け和訳）
| コード | 和訳 | 使い方 |
|---|
| CONFIRMED / 確定 | ソース行番号などの根拠で確認済み | 影響調査の根拠に使える |
| PARTIAL / 部分確認 | 宣言はあるが操作命令未確認など | 残課題。推測で確定にしない |
| UNRESOLVED / 未解決 | 技術的にまだ決められない | 次確認先をメモする |
| 顧客確認待ち | 業務意味・利用有無など人に聞く | 技術UNRESOLVEDと混ぜない |
2026-07 時点で追加で「今だから分かる」こと
- 固定形式RPGは空白区切りではない。
CHAINRECFMT01 は列位置の隣接表示。RPG III/IVの列パーサが主経路。
- WRITE/UPDAT/DELET はレコード様式が来やすい。DDSでファイルへ正規化してからCRUDを付ける。
- DSPPGMREF WHFUSGは「コンパイル時のI/Oめやす」。PARTIALの補助にはなるが、SRC行なしでCONFIRMEDにしない。
- 成果物の更新順は「レポート精読昇格 → CRUD図再生成 → テーブル定義書再生成 → HTMLリンク再同期」。
- HTML化の落とし穴（表区切りの
||、証跡ログ前の---、チェックリスト本文切り落とし）は変換器側で吸収する。
- 実機取得（DSPDBR・開ファイル）は、静的で残ったPARTIALの最後の決め手。
時系列で見た「気づき」
| 局面 | 当時の仮説 | いまの結論 |
|---|
| 中間ファイル | CSVをBobに渡せば十分 | Cursorで CALL閉包・coverage・未決を機械抽出してから渡す |
| RPG I/O | 空白区切り正規表現で足りる | 現行はRPG III列が主。連結表示を正規表現だけだと取りこぼす |
| PARTIAL昇格 | F仕様のUF/IFで更新とみなせる | 操作命令行が無い限り PARTIAL。昇格は列パーサ＋DDS |
| 画面 | L2化でワイヤーが付く | プレースホルダだらけ。DSPFから機械生成が必要 |
| CRUD/定義書 | レポートとは独立に作れる | レポート派生。更新順を守らないと陳腐化 |
| 実機 | 静的だけで完結できる | PARTIAL残〜150ファイル。DSPDBR/開ファイルが必要 |