EQ_S4_STAGE_PLAN r03（P28-02-EQ 段階 S4 の完了。EQ_S4_STAGE_PLAN r01 と r02 は、全てそのまま有効。この r03 は、run 20dc4135cc3041dbb82fcc2b2a6b0cbe（900秒の期限で exit 124）で保持された実装を引き継いで、正式な submitted まで閉じるための残りの作業だけを決める。S4 の範囲は小さくしない。SPEC、TASK、6条件、eq/references、eq/registration、補足 r01/r02/r03、全ての段階の計画は変更しない）

0. 引き継ぐもの（再実装しない、再監査しない）
- W の中の現在の70件のファイル（RootB/retained-s4-20dc413-r01、RETURN の SHA a2c0d5ffd42b67ef340d5624dd299e294b867168bd1270933aec458a9cde1dc5 と一致するもの）。実装済みの run_eq.py と verify_eq.py、現在の134件の試験。
- 既存の119件の試験の本体と、全ての unit の生出力（S4 の attempt 01 の構文、02 の追加の unit、04 の recompute の不一致の失敗、S4_SUPPLEMENTARY の作成の assert の失敗を含む）。消さない、書き直さない。
- attempt 05 の 132件の PASS（194.460秒、embedded exit 0）は、その版だけの事実。その後に2件が加わり、attempt 06 は出力なしで期限に達した。現在の134件の PASS は、まだ証明されていない。134件が通ったとは書かない。

1. medium の修正（必須）
- eq/run_eq.py:257 と eq/verify_eq.py:144 は、check.check_probe(...) の戻り値を捨てている。check_probe は例外ではなく {ok, errors} を返す（eq/check_eq.py:384）。
- 両方の箇所を、static = check.check_probe(...) にして、require(static['ok'], <errors の全件を含む message>) で拒否するように直す。戻り値を使わない他の check の呼出しが無いかを、run_eq.py と verify_eq.py の中だけで確かめ、同じ形のものがあれば同じく直して記録する。
- 拒否の試験を加える: check_probe が {ok: false, errors: [...]} を返すとき、run_eq.py の driver（--check と、--run の probe の検査の段階）と verify_eq.py の両方が拒否すること。ok: true のときに通ること。

2. 残りの文書と context
- PROGRESS.md と IMPLEMENTATION.md を S4 の内容に更新する（今は S3b の記述のまま）。r01 §0 の「S4 must」の要件と、末尾の S4 binding requirements の全ての項目について、満たしたコードと試験の対応表を書く。r02 の訂正（collector だけの読取専用の import、restart_pair を import しない、raw3 の正確な名前、exit を owned の受領から読む、check_report と check_lifecycle の引数、証拠の名前の一覧、validation の書込みの場所）を、どのコードで満たしたかも書く。
- S4_SUPPLEMENTARY.json: plan の全文を手で再構築しない。Root が同じ W の runtime に、元の bytes の読取専用の JSON として置いた r09 の ACTUAL_OPUS_TASK_CONTEXT.json（RootB/eq-staged-s4-owner-run-input-r09/ACTUAL_OPUS_TASK_CONTEXT.json と同じ bytes。W の中の path は Root の packet が示す）を読み込み、その内容を変えずに、1つの key actual_commander_context として保存する。元のファイルの SHA と、各 plan の SHA が一致することを確かめて記録する。この r03 と RUN r03 は、Root がその後に追加で配置するものを、同じ方法で保存する。
- 以前の手での再構築の assert の失敗は、失敗の記録として残す。

3. 時間の配分（900秒の期限は変えない）
- 全件の unit は約200秒かかる（attempt 05 で 194.460秒）。修正の確認は、関係する試験の class だけを指定した部分の実行（python3 -B test_eq.py <Class> ...）で行い、その生出力も保存する。
- 全件の実行は、全ての修正と追加の後に、最後に1回だけ行う。開始は、期限まで少なくとも300秒が残っている時点までとする。不具合の修正が必要になった場合は、記録して、関係する部分の再確認と、もう1回の全件の実行を行ってよい。
- 時間が足りない場合は、それまでの成果と生出力を残して、通常の blocked で返す。全件の PASS を推定で書かない。

4. 最終の確認と提出
- 最後の全件の実行は、134件 + この r03 で加えた試験の全て。全件 PASS の生出力と SHA と件数と時間を、UNIT_OUTPUT.txt と、新しい attempt のファイルに保存する。
- 正式な JSON: status はちょうど "submitted"、commit は 2549cf7d6992560b850bbd11934e3c14b39a1988。局所の unit の証拠であり、native の実行・受け入れた S・Q での測定・製品の PASS とは表記しない。
- worker は、engine の起動、run_eq.py --run の実行、正式の validation の試しの実行、git への書込み、製品の変更、全回帰をしない。API の fallback は使わない（設定のまま）。
- 通常の実装上の判断は、記録して進める。

5. 提出の後（worker の範囲の外。変更しない）
- Root の正確な S の native の7つの phase → bundle の配置 → 両方の validation → fresh の独立した Opus による6条件の全てのレビュー → 通常の資格・承認・integration・final → OPT と whole-unit。
- 原本の 23/88・4/30 への加算は0。原本の条件・課金・権限・900秒は変えない。
