TheTree_mock/docs/plans/original-completion-2026-10-02/execution/p04-01/EVIDENCE_COLLECTION.md

P04-01: C段階の結合とrepair4収集契約の履歴

repair6 現在値（2026-10-16、以下の旧blocked記述に優先）

旧値: 実applicabilityは native ordering bytes で拒否、C全体blocked、 whole native未確認。新値: 補正済みbundleのverify_native成功、 ownership/save/ledger個別検査とapplicability成功。供給bundleへの書込みは0。 全文rawの登録版/production一致と両body SHAの全文SHA一致だけを認める。 後続コメント除外prefixを許す暫定処理は削除した。

下記3本のPythonコマンドを各1回実行しexit 0を確認。 native fixtureは既存23負例+signature行SHA/コメント除外SHAの2負例を全て拒否。 合成補正コピーは廃止し、補正済み供給rawをそのまま正対照に使用。 既存fixture14件拒否、A/Bの登録版・production版・行移動正対照成功、3負例拒否、 native applicability成功。実行結果、旧検査値、新旧bundle pin、検査コードSHAは c-native-validation.jsonに記録。verify_nativeは有限C検査でありwhole gateは未実行。 原未達の条件、formal_original_credit=0、15条件+EV/7領域/安全性3結果、 30/88の分母、予算、repair上限を維持する。Root追加paid/再送は今回の範囲外。 engine、全回帰、製品、Runner、config、DB、git書込み、他agentは全て0。 正式検証・独立レビュー・オーナー判断待ち。以下の「今回」は旧検査履歴を指す。

C段階の追補対象

供給rawの現在位置は build_dir/audit-support/native-first-current/。 所有権、台帳・service・予約、正式保存の結合を追加する対象であり、 この資料の存在だけでは原受入を満たさない。formal_original_creditは0を維持する。

今回のC実装と入力blocker

変更はchecker、Python fixtureと本ディレクトリ内のdocsだけ。 Root helperはコピー・再実装せず、既存native成果物を読む。 結合の正確な規則はCHECKER_PROTOCOL.mdのC追補を参照。 新規engine/全回帰/Runner操作/git書込み/他agent起動は全て0。 旧39rawを読了・採用した数も0。repair4-context.jsonの旧履歴は保持した。

供給rawでは次の個別Python検査が成功した。

• OWNERSHIP_RAW_PROVENANCEの96 fileのbytes/SHAと10プロセスのlifecycle/cleanup。
• Writer/Readerの5点×4member、元20member不変、typed .var 14件の実SHA結合。
• 生receipt 8行、service.paymentのidempotency経由での1回課金、財布差分、 PAUSED時の進捗・予約保持、復帰後の消費、維持費発生1439→支払い1440。

ただし POST_P18_CURRENT_SOURCE_APPLICABILITY.json の4関数の registered_body_sha256/production_body_sha256は本文を含まない。 実Git blobで検算すると、以下の関数先頭からのprefix SHAに一致した。

path	function	hash対象のbyte数（本文を含まない）
autoload/simulation_runtime.gd	_complete_service_transaction	140
scripts/facility/facility_service.gd	_prepare_service_for_tick	87
scripts/facility/facility_service.gd	_complete_service	113
scripts/facility/facility_service.gd	_fail_service	119

4つとも複数行引数の後の ) -> ... より前で終わる。全文比較は別途成立するが、 報告されたbody hashとの一致は成立しないため、実bundleは native ordering bytes でfailする。workerはこの供給資料もmanifestも変更していない。 Root側で同じproduction Git blobの全文を対象にapplicabilityとそのmanifestを 再生成する必要がある。engineの再起動を必要とする不整合ではない。 旧暫定処理では後続トップレベルdoc commentの有無だけの2関数差をraw prefix一致 として扱っていた。repair6で撤去し、現在は全文SHA一致のみ必須とする。

この入力不整合が残るため、C段階の実raw全体の成功は未確認（blocked）。 これは原P04-01未達とは別のblockerであり、修正済みの合成コピーで全C検査が 通ることを原証拠の合格へ換算しない。

有限の検証

実行したのは次のPython確認のみ。全て一時ファイルをallowed_paths内へ限定し削除する。

python3 -B docs/plans/original-completion-2026-10-02/execution/p04-01/checker_native_fixtures.py /Users/korizatou114/Projects/TheTree-managed-worktrees/p04-01/.runtime/P04-01/build/audit-support/native-first-current
python3 -B docs/plans/original-completion-2026-10-02/execution/p04-01/checker_negative_fixtures.py
python3 -B docs/plans/original-completion-2026-10-02/execution/p04-01/checker_applicability_fixtures.py --native-bundle /Users/korizatou114/Projects/TheTree-managed-worktrees/p04-01/.runtime/P04-01/build/audit-support/native-first-current

Cの結果は c-native-validation.json。23負例を拒否し、実rawの3個別検査成功、 実applicability拒否、修正した合成applicabilityの組合せ正対照成功を区別する。 既存fixtureはscalarのみの旧正対照を含む14件を拒否。 A/Bは登録版・production版の正対照と行移動の正対照、3負例、C資料の拒否を確認した。 未収集indexに対するwhole gate/validateは再実行していない。

固定の原未達

非ゼロ給与のシフト交代×00:00、command再送、停電→閉店同Tick、退出/予約孤立、 破壊、EVは未収集。正式保存のSHA同一性は全原条件のsave_restore証明とは別。 15条件、reachable EV、7領域、安全性3結果を減らさず、未収集をfalse/pending扱いとする。 原30/88のformal_original_credit=0、独立レビュー・通常統合未実施を維持する。

以下はrepair4時点の履歴であり、C追補の実装・検証状態には上記が優先する。

本修正は未完成であり、収集開始・machine gate・原受入の承認ではない。 原30/88、7領域、部分点0を維持する。D05全体はpending、既存の承認2条件を 超える規則は作らない。D-034/A01の再承認は求めない。

読取確認

.review-material はこのcheckoutには存在しない。指定された実体 build_dir/audit-support/p04-native-existing-sources/ のwrapper 4本とGD probe 6本、および tools/run_all_tests.py、tools/regression/owned_outer.py を確認した。 10本のraw SHA/sizeは配布SOURCE_MANIFEST.jsonと一致し、repair4-context.json に保存した。外部旧worktreeのartifactパスは由来としてのみ扱った。

実checkout HEADは 9767b0a28ca8d252520307dbbac60a1d8cfb87ab、Runtimeは d52a995ae715542bbc550f68d35889540658275d12e04ae0b21ac276f5843f39。 提供されたproduction資料の版は 5f6bc11d6bb6e92d22d787989b219fef3a435bc1、 Runtimeは 7f01b2dcdf28bc965c7588173c2dc70054633faf7204b1ac38ba0f4369331b47。 productionのGit objectも存在する。production資料を実checkoutのsource_mapとして 流用しない。登録版は deb1bcb2374eb378b840ca345db952bd8572cb6e。

A/Bの変更

checkerはspecのcurrent_source_pinsを登録pinとして保持し、登録Git blobのSHAを 独立計算する。indexはregistered_pinsとversionsのexecution_origin/registered/ tested/integrationを分離する。integrationは未統合のためnullのみ。 testedのautoload/scripts全GDはcheckoutとHEAD blobの一致を必須にする。

20関数の抽出はchecker内固定。行頭func/static funcから次の行頭関数までの raw bytesを比較し、コメント・空白・改行を正規化しない。先頭宣言は <top-level> 単位としてdiffに含める。追加・削除関数も含む。 git diff --no-ext-diff --no-renames --name-only -z base..HEAD -- autoload/ scripts/ で変更GDを列挙し、Git blobから変更関数を計算する。applicability_deltaは path/function順の配列と完全一致させる。未知の変更も無影響と推定せず、 delta_casesに保守的な全条件被覆を要求する。境界case IDの存在は後続coverageで 検証するが、Cの生証拠結合は未実装なので、この段階では適用可の最終判断に使えない。

REACH_REFSはpath/function/anchor_sha256/line_countに変更。実tested関数内で 本文raw bytesのアンカーを一意に解決する。旧固定範囲が隣接関数へ跨がる reserve/rescue箇所は関数単位に分割した。行位置が7行移動しても解決し、 本文変更・欠落・重複アンカーは失敗する。

新collectorを作らず残す既存実行パターン

Root側の既存wrapper修正で保持すべき順序は、r.source_refs(R) → 明示QA上書きしたrefs → r.copy_source によるprivate stage → bootstrap → cacheの cp -c と別inode確認 → parse-paths/contracts → execute_phase → finallyの owned_outer.finish_captured → fixed_guardと不変性確認。 このworkerはwrapperを起動・変更していない。適用可能なパラメータ化patchと 全不足probeはまだ提出できていないため、以下は実行済みの契約ではなく残作業である。

• R/OUT/QA/testpath/cache/input manifestは最終tested checkoutに対して固定する。 1299件数や旧source-after.json一致をauthorityにしない。現r.source_refsがauthority。
• checkout mapと、testpathにQAを明示上書きしたselected mapを別に記録する。 source_map=tested、probeの元pathとSHA、QA_overrides、実stageの同SHAを結合する。 候補製品source overrideは持ち込まない。
• source_before/after、default_player_before/after、doc4_before/after、stage inventory、 parse-paths、contracts、wrapper raw、phase receipt、started/ended、 outer-owned-finally、execution.jsonを保存する。booleanだけでは不変性の代用にならない。
• case receiptはphaseのactual_pidとexecution.actual_captured_PIDs、cleanupの全PID集合に 結合する。cleanup_errorsが空、全childのengine_ended、終了codeを実成果物間で照合する。
• 各条件のscalarに加え、生台帳・service/settlement ID・予約配列とのcount_eqまたは same_literalが必要。save_restoreはWriter保存直前と正式Reader復元直後の 台帳・予約のsame_literal、および別PIDを要求する。nonceやログ文言では代用しない。

負履歴（起動禁止）

10本すべてのSHAはrepair4-context.jsonに記録した。特に以下を再実行しない。

• shift-end-repro-r03.gdは1080で「課金なし・予約保持」を期待し、承認済みの 完了段階先行と矛盾する。対応native-r03.pyには旧1299 pinもある。
• formal-boundary-reload-native-r03.pyは旧candidate sealと製品2件overrideを使う。 SHAを書換えて別候補receiptとして使わない。
• formal-boundary-reload-r01.gdのmanifest.source_refs==1299も旧前提。
• midnight native-r01とpower native-r04も固定1299と旧full-run cacheに依存する。 power readerは旧Writerの二つの正式保存slotに依存し、fresh Writerではない。

15+EVの被覆確認（未収集）

同一プロセス内でも条件ごとのseed、before/after、case receiptを保持する。 以下のartifact名は既存probeが出すもの。不足欄を合格扱いにしない。

条件	既存probe / phase / artifact	不足
midnight_settlement, midnight_replay	midnight-boundary-r01 / repro / observations.json, midnight-*.var	countとraw台帳の結合、同minute再送の明示
paused_midnight	midnight-boundary-r01は開業サービスのみ	停止した同一serviceの日跨ぎ系列
night_staff_absent	shift-end-repro-r03 / repro / 18-01観測	旧誤期待を除いた独立caseと非完了service
power_stop, recovery_completion	power-formal-recovery-r04 / reader-a,b / recovery-*.var	fresh停止入力、台帳JSON、旧Writer依存の解消
dependency_stop	供給6 probe内に専用系列なし	関連施設停止・進捗/予約/service ID保持
exit_release	exit-boundary-r01 / repro / queued-*.var, observations.json	raw stateとcount結合
patience_release, closure_release	供給6 probe内に専用系列なし	待機解放、開始済み継続を区別したcase
same_minute_replay	exit/destruction/midnightはsnapshot巻戻し再実行	同minuteコマンド再送の独立条件
shift_completion	shift-end-repro-r03 / repro / 18-00各phase観測	誤期待の修正、課金1回のraw結合
overtime_task	供給6 probe内に専用系列なし	interrupt_level=0残業・勤務記録1回
destruction_stop	destruction-completion-boundary-r02 / repro / unfinished-*.var	raw台帳結合。completeは別帰結として維持
save_restore	formal-boundary-reload-r01 / writer,reader / *.var, writer.json, reader.json	final版の入力seal、JSON台帳/予約、owned PID結合
EV	供給6 probe内に専用系列なし	staff予約→EV移動→停止→到着の実状態

transportはreach=falseのソース根拠のみで、別engine条件は追加しない。

再利用の有限条件と未供給資料

input.jsonのevidence_refsは旧証拠の参照であり、生証拠そのものではない。 今回の供給先で確認できたのはsource、監査、適用性診断とgate失敗ログである。 旧39件のraw receipt/state/packageを照合して採用した件数は0。 「20関数一致」だけで39件を採用することは禁止する。

必要な追加のローカルraw資料:

1. 旧39件のexecution/phase/started/ended/outer-owned-finally/log/state一式と 元source/config/input/environment pin。既存input.jsonのreference SHAで照合する。
2. formal-boundary-reload-input-r02.json （wrapper記録SHA 195cb767e597008d1767aa0b6c8300711b83e8cf101863166e7932d9bd4ed612） と、そのwhole_typed_inputs、元exact_execution、保存package全4メンバー。
3. power original writer.json （wrapper記録SHA cf3850c262012e5e52743bfb8b41af7ef5608689fb10c059c8a494216b0aff52） と参照slot。旧candidateは比較用負履歴に限定する。

原則は最終の正確な版で再実行する。登録版証拠を再利用する有限条件は、A(i)の 20関数raw一致、A(ii)の全delta一致、A(iii)の変更境界をtested engine caseで被覆し、 さらに当該旧caseのsource/config/input/environmentとraw状態を独立照合できること。 relationship restore/schema変更は正式Writer/Reader再実行、build/path/arrivalに 関係する変更は当該経路に到達するcaseの再実行が必要。今回の資料だけでは再利用0。

Rootのコマンドと残る作業

現在実行できるのは次のPython確認のみ（engineプロセス0）。

python3 docs/plans/original-completion-2026-10-02/execution/p04-01/checker_applicability_fixtures.py
python3 docs/plans/original-completion-2026-10-02/execution/p04-01/checker_negative_fixtures.py
BUILD_OUTPUT_DIR=/Users/korizatou114/Projects/TheTree-managed-worktrees/p04-01/.runtime/P04-01/build python3 tools/check_p04_order_evidence.py --verify-only

最後のコマンドはindex未収集ならexit 1が期待値。Python正対照はengine証明ではない。 Cのchecker強化、Dのparameter patch/不足probe、Eのowned/count/restore/他候補流用負例は未完成。 旧checkerのscalar/receipt自己申告を受入可能な証拠とみなしてはならない。 現在のcheckerを正式受入に使用せず、修正全体をblockedとしてRootへ返す。

native収集の正確なコマンド列は、上記入力と未完成patchがないため提示できない。 仮のコマンドを実行可能と偽って提示しない。共有stageでimport+parseを2プロセス、 midnight/power/exit/shift/destruction/save Writer/save Reader/EVを8プロセスに 束ねられれば計10プロセスが計画目安になるが、これは確定数・目標数ではない。 条件ごとに必要な状態系列とguard成立を優先する。 Rootのnative収集→validate→別セッション独立レビュー→通常統合は未実施。