P04-01実提出3bba4f34f0df8fe812776c2dbef8e6891fa4fa0bのS2a Root初実測を受け、同じS2a検証fixture内の通常repair12の開始判断・具体修理指示をお願いします。現在repair_ready used12/maxnull。新提出3bba初回必須wholevalidateだけを1度実行しindex未収集FAILで通常repair_pending→repair_readyへ進めた。登録条件/DB/config/gates不変、同版のmissing-indexを反復しない。未実装を外部block理由にせず、原30/88/部分点0を維持する。
実Root native: 製品1338source、import73287/parse73357/Writer73390 PASS、Reader73527は「formal equality day_summary」1failだけ。Writerは3fresh branch C1/C2/C3すべてPASS、Readerは全Runtime var_to_bytes完全一致・ledger/payroll一致・別PID正式保存4member同SHA・原不変・復元直後1440 publicadvance再呼出しすべてPASSだがrawgetter day_summaryのvar_to_bytes比較だけFAIL。RootJSON再照合ではgetter全値/全Runtime/再呼出し前後すべて一致。owned4終了/全guard0、全失敗raw保持。全体合格とはしない。
根拠絶対path: /Users/korizatou114/Projects/TheTree-managed-worktrees/p04-01/.runtime/P04-01/build/audit-support/p04-whole-closure-r01/ROOT_S2A_NATIVE_R01_RESULT.json 。実raw原本は同build/p04-s2a-native-r01/raw/ のwriter-C3-midnight.var、reader-C3-branch.varとJSON、writer-C2-recall.var/JSON、writer-C1-join.var/JSON、同native root/reader/stderr.log、execution.json。workerは直接読取可。Root実測では1440 sale25G transaction ledger_00000085、給与transaction81のstaff_akane120/staff_bardo135、維持費transaction82の3rows(2+2+1G)。C2実API戻りOK/replay=true/processed_minutes0/daily_closes0。paid duty実記録も正:Akane1+236min、Bardo361min（1439→1440 +1）。取引数と行数を混同しない。過去期比較の売上時点/日帰属は変更しない。
根拠ソース(製品とWのOperationsCoordinatorファイルが同一かSHAを最初に確認): scripts/operations/operations_coordinator.gd:1196-1218の新規summaryはStringNameキー(&"day"等)をsource orderで構築。:577get_day_summaryは生内部Dictionary.duplicateのみ。:668-711create_snapshotは公開保存形式の_snapshot_root_reportを使用し、:2943以降rootキーをString化・sort、:3008-3070_visit_snapshot_treeはStringName値もString化、Dictionary key String化とsortを明示する。restore_snapshotはそのcanonical保存形を採用。全Runtimeのtyped保存状態は完全一致なので、getterのStringNameキー/辞書順序とcanonical保存形式の差である可能性が強い。これはRoot推論で、実raw型診断をまだしていない。値欠損とは断定しない。
Opusあなたがこの既存canonical保存契約と元S2a/P04受入条件を読んで判断すること。方針案: 原getter rawは消さずtype/key-order fingerprints（Writer/Reader各、再帰型コードを含む）を追加して差を実測する。保存一致の本体は既存公開operations_coordinator.create_snapshot()['day_summaries']からday1を取得したcanonical view（whole Runtimeにも含まれる）で全typed bytes一致を要求し、rawgetterと同canonical day1の全値の結合を明示して表示用JSON一致だけで代用しない。元の全Runtime var_to_bytes、ledger/payroll、原/copy全memberSHA、同1440再呼出し全typed不変は一切緩めない。もし原契約にrawgetterのキー型/順序まで保存前後不変が必要ならfixtureassertを削って合格にせず、根拠と製品修理の必要箇所を具体的に示す。data型の違いを無差別JSONnormalizeして隠す修正は禁止。
追加でS2aのduty joinは存在だけでなく、非zero paid staffの同日ShiftInstanceの実worked/overtime記録>0と実deltaを照合して、payroll settlement取引数を導出すること。既存生データはそれを満たす（Bardoの0勤務キャンセルshiftを実勤務代わりに採用しない）。upkeepは3行でもdistinct tx1、原1の基準を維持する。
scopeはs2/既存3ファイルの必要修理/型診断/説明のみ。他のs1/A/checker/C/protocol/product/DB/契約/分母/baseは編集0。worker検証はpy_compile+wrapper--check-only(engine0、default/privateprofile読取0)、手動commit0/全回帰0で正常code-ready提出。Rootはfreshr02でimport/parse/Writer/別PIDReaderの実run1回のみ。モデルは実Opusあなたが理由を付けて選ぶ。run.reasonはworkerへ自己完結の具体修理指示と絶対pathを渡し、contextadapterは増やさない。
