# P19-03 実装提出報告 提出状態。受入は未確定。原受入「7名×3ルートの到達表があり、未制作内容は欠損として残る。」を維持する。14/88は変更しない。 ## 変更範囲 修復開始点e0420d57a381a1644357f0590536e1d47c9bca9fから、このディレクトリの指定5ファイルのみを変更した。原本、原子要件、work packages、decisions、TASK_SPEC、選定記録、frozen pins、ゲーム入力、marker registryは変更していない。git書込み、他worker起動、Runner操作、ゲーム起動は行っていない。素材追加なし。 ## 要件と検査の対応 |TASK_SPEC implementation_requirements順|成果物|検査| |---|---|---| |1: 原7名×3ルート|REACHABILITY_TABLE.json / .md|expectedのPEOPLE/ROUTES、原本118–124行、atomic entityと21セルの完全一致。test_exact_cell_product| |2: 8カテゴリ、共通/人物固有の分離|JSON common_rules / cells.categories|CATEGORIES全件のcanonical比較。test_categories_and_citations| |3: 原本本文・行・status・anchorのsource SHA・owner|JSONの各共通項目/人物固有項目、catalog_evidence|expected.evidence/cite、verify。test_stale_record_evidence / test_owner_and_status| |4: 欠損、理由、担当、未知値pending|各character_specific、pending、natural_route_complete=false|test_no_invented_values_or_completion。D05/D08は未回答のまま| |5: docs内stdlibチェッカー/自己試験|check_reachability_table.py / test_reachability_table.py|stdlib importsのみ。選択対象外のdocs内配置| |6: read-only --check、厳密な表/Markdown|verify / verify_records / markdown|test_json_and_types / test_markdown_drift。--checkは書込み分岐を通らない| |7: 全frozen source mapと各identity|binding / selection|1368選択ファイルの完全map、marker/policy/engine、184-suite roster、329 .gd、baseline、spec→pins SHA。test_full_frozen_map_and_identities / test_real_source_and_baseline_changes| |8: UI/Runtime/save/Windowsの適用性|JSON route_support、MDルート別適用性|各ルートをcanonical比較。汎用UIラベル、原本登録Runtime、専用snapshotの限定証拠をcommon_rulesで参照| |9: 有意な負例と3種の正例|test_reachability_table.py|欠落/重複/誤人物/誤route/カテゴリ/引用/古い本文・SHA/値創作/誤完成/owner・status/JSON型/Markdown、実ファイル読込差替え、map差分とpins/marker/policy/engine改変。全3statusを含む正例| |10: P13パターン・原文保全|checkerのexpected/verify/markdown、原資料のbase blob照合|tools/check_p13_content_difference.pyのcanonical生成・厳密比較・read-only Git blob証拠パターンを参照。元ファイルは無変更| |11: 報告・残課題・外部gate|本報告、JSON accounting|正式試験・全単位独立レビュー・統合/finalは未実行と明記| 原子要件はB-7.1〜B-7.6をsource_group_idsに含む61件の完全レコードを読込対象とし、JSON authority_snapshotsに保持する。人物キーと原名はそのentityから確認し、原本§6の順で並べた。原本§6は114–135行、§7は136–161行であり、実際の見出しと本文を照合した。人物別の原本仕様がない部分を共通ルールから創作していない。中断/保存の人物固有手順は原本に定義されず、work_packagesのP19-02受入が所有する欠損として残した。 指定されたoriginal_relationship_state.gdには7名のrosterはなく、汎用subject_id等の明示入力検証のみがある。既存unique catalogのヒロインはheroine_anriのみ。監査IDには既存atomic entity.key(anri/fine/tomari/amelia/liz/mimi/satsuki)を使い、他6名の実装catalog ID、ライバル対応、初期値を創作していない。この実装欠損は表の欠損であり、原7名を削減する理由にしていない。 ## Repair 1: 4指摘の対応 編集前に build/owner-handoff/p19-review-r01/ の ACTUAL_OPUS_REPAIR_DIRECTION.json、ACTUAL_WHOLE_UNIT_REVIEW.json、SPEC_HASH_REPRESENTATIONS.json を読んだ。 - MEDIUM: coassignment_attack / zero_break / love_actions / threshold_route_loss と旧UIのlegacy_evidenceを追加。固定anchorの実際の本文・行・Git blob OID・file-bytes SHA-256を保持する。原本準拠statusはmissing、旧実装分類はlegacy_not_originalに統一。P18-01は一対一変換を禁止し、旧数値・日次制限は原本として未承認と明記した。UI定数は実際には98–101行であり、89–97行の無関係なラベルを除いた。共通ルール参照により各該当セルへ結び付けた。所有者・原本欠損・natural_route_complete=falseを維持。 - LOW 独立試験: validate_legacyは候補とcanonicalの比較とは独立に、git showで固定anchorのソースを読み、引用行本文とgit rev-parseによるblob OID、現ファイルとの一致を検査する。test_independent_legacy_source_evidenceは実際のJSONと実ファイルを開き、git hash-object --stdin(書込みなし)でOIDを独立計算し、関数名とshield_broken/EXCLUSIVE_LOCKEDも確認。test_legacy_evidence_required_independentlyは対象全項目の証拠削除・空配列・無条件not implemented・古いOID/本文を拒否する。 - LOW 中断参照: 全21セルのinterruption_cancellationに原本148・153行の本文とbaseline hash、および343–355行のconfirm_route_lockをlegacy_not_originalとして追加。人物固有欠損と担当は維持。 - LOW ハッシュ表示: 263a01b943d8056727335fb76977c010298e1c229077f8da76e48683ba2e89bb は TASK_SPEC.json file-bytes SHA-256。3af3d9b931edc5449796662ad69bb6f67c80b48827a86565b1952931db68dd15 は Runner git-show stripped-UTF-8 contract spec_sha256。上記SPEC_HASH_REPRESENTATIONS.jsonのunchanged_file=trueが証拠であり、両者は同じ無変更ファイルを表す。checker定数と出力にも区別を反映。Git blob OIDは別のgit_blob_oidフィールドでありfile-bytes SHA-256とは区別する。 ## 実行記録(今回のローカル確認) 以下は正式Runner実行ではない。記録済み修復指示に基づき3登録コマンドをローカル実行した。 生成 — exit 0 ```sh python3 -B /Users/korizatou114/Projects/TheTree-managed-worktrees/p19-03-reachability/P19-03-TABLE-implement/docs/plans/original-completion-2026-10-02/execution/p19-03/check_reachability_table.py --project-root /Users/korizatou114/Projects/TheTree-managed-worktrees/p19-03-reachability/P19-03-TABLE-implement --write ``` p19-table — exit 0 ```sh python3 -B /Users/korizatou114/Projects/TheTree-managed-worktrees/p19-03-reachability/P19-03-TABLE-implement/docs/plans/original-completion-2026-10-02/execution/p19-03/check_reachability_table.py --project-root /Users/korizatou114/Projects/TheTree-managed-worktrees/p19-03-reachability/P19-03-TABLE-implement --check ``` p19-negative — exit 0 ```sh python3 -B /Users/korizatou114/Projects/TheTree-managed-worktrees/p19-03-reachability/P19-03-TABLE-implement/docs/plans/original-completion-2026-10-02/execution/p19-03/test_reachability_table.py --project-root /Users/korizatou114/Projects/TheTree-managed-worktrees/p19-03-reachability/P19-03-TABLE-implement ``` p19-source-binding — exit 0 ```sh python3 -B /Users/korizatou114/Projects/TheTree-managed-worktrees/p19-03-reachability/P19-03-TABLE-implement/docs/plans/original-completion-2026-10-02/execution/p19-03/check_reachability_table.py --project-root /Users/korizatou114/Projects/TheTree-managed-worktrees/p19-03-reachability/P19-03-TABLE-implement --source-binding-only ``` --writeの実際の呼出しは同一checkout内で相対スクリプトパスと --project-root . を使用(上記は絶対パス表記)。--checkはMarkdownのバイト完全一致を確認。自己試験は12件OK。source bindingは1368ファイル一致、file_equality=true、actual_commit=e0420d57a381a1644357f0590536e1d47c9bca9f、native_evidence_reuse_accepted=false。git diff --checkはexit 0。構文は上記Python実行で確認。最初の編集用here-documentは一時ファイル作成制限でexit 1、変更は行われず、python3 -cで再実行してexit 0。native full・ゲーム起動・git書込み・Runner操作・他エージェント起動は行っていない。 ## 残る親成果・ゲームの欠損 - P18-01: 原本3軸/盾の通常UI、承認済み初期値、本来の全単位受入。P18-02/03: 同配置・軽減・ブレイク・接触・閾値・確定遷移。既存旧汎用モデルの閾値を原本へ転用しない。 - P19-01/02: 原本行動と全3種決闘、勝敗・費用・盾/履歴の一度だけ反映、通常入口、停止/取消/離脱/保存再開。原本状態保持のbackendを自然ルート完成としない。 - P20-01/02/03: スキル/章・全エンド・図鑑と新規からの通常到達。P26-01/02/03: 人物別必要内容、状態接続、完成資産と制作受入。人物固有イベント/条件/履歴/立ち絵差分は欠損。 - D05、D08はpending。未知の閾値・率・初期値もpendingのまま。P04の既存D05選択、P13の4件の制作followupも未解決。 - この文書単位のnative GUI/Windows実行は適用外。global same-Windows、held gestures、全ゲーム受入はopen。固定入力一致から既存native証拠の正式再利用承認を推定していない。 - Runnerの3 validator、原本§6–7と元受入に対する実装者から独立したwhole-unit Opus review、その後の通常prepare-integration/finalが必要。どの完了数・元台帳も変更していない。