docs: record restored parent regression evidence and cost

docs/development/regression-test-design.md

@@ -2,7 +2,7 @@
 
 ## 判断の基準と対象source
 
-**追加は公開境界の不足に絞り、既存の小さい故障検出と保存試験は維持する。** T-761の設計対象は `main@hare/develop` の `adfa42297352c5a64fe8100969aad6fda4df8a81`。着手時のHEAD・ローカルref・origin追跡refは同commit、treeは `4e85ca596e0f51f7eca4505c79c59518c87b6306`、基準との差分・未追跡変更はなかった。以下はこのsourceでの判断であり、実装済みの保証と追加案を分ける。
+**追加は公開境界の不足に絞り、既存の小さい故障検出と保存試験は維持する。** T-761の設計対象は `main@hare/develop` の `adfa42297352c5a64fe8100969aad6fda4df8a81`。着手時のHEAD・ローカルref・origin追跡refは同commit、treeは `4e85ca596e0f51f7eca4505c79c59518c87b6306`、基準との差分・未追跡変更はなかった。以下の採否・probe表はこのsourceでの設計時判断である。採用設計 `e75b027f39e9f307d1b527a92dfe79659fe8f921` を取り込んだ恒久実装・故障検証の結果は末尾へ分け、設計提出だけを完了とはしない。
 
 [テスト設計規則](rust-testing-strategy.md)と[検証規則](validation.md)を適用する。[過去の時間調査](../report/test-suite-timing-investigation.md)の71.06秒・210 suitesは以前の1回測定であり、今回の実測ではない。60秒達成、追加速度最適化、全suiteの再分類は本設計の目的ではない。
 
@@ -14,7 +14,7 @@
 | P1         | 結果返却Tool/WIPがHost retry identityを落とし実Backendへ同じ依頼を渡せない | **B：薄い適合だけ追加候補、T-744所有**。HTTP→実永続sessionは既存で充足。Tools/WIP適合は未試行。                                                                       |
 | P1 維持    | 長いWorkspace操作を待つWorkerのHTTPが暗黙の30秒で切れる                    | **既存で充足**。timeoutの本番適用漏れを今回再現検出。31秒待ちを復活させない。                                                                                         |
 | P1 維持    | 人間・Workerが保存済み履歴を読むと、budget中断後の行やoffsetが壊れる       | **既存で充足**。readerの中断状態喪失を今回検出。画像実storage接続は別の既存試験を維持。                                                                               |
-| P2         | 親Runtime Workerの復元後、既知の子が一覧から消える／入力できない           | **新規が必要（証拠不足）**。DB再openとclient型確認の間を、復元親のclientから公開list→inputまで接続する1ケース。既知の製品回帰と断定しない。                           |
+| P2         | 親Runtime Workerの復元後、既知の子が一覧から消える／入力できない           | **恒久追加済み**。復元親のclientから公開list→input→canonical Sessionを接続する1ケース。実接続でsubjectの`kind`脱落を検出し修正。                                      |
 | P2         | Ticketのlifecycle履歴を公開readとWebで正しく保持・解釈できない             | **C：分離して強化、T-744所有**。detail/history再read、局所履歴component、実Backend bytes→production parserを分担。waiting parser probe成功、全lifecycle/DOMは未試行。 |
 | P2         | 真の旧schemaから移行・再open後にTicketを公開read/queryできない             | **D：公開read/queryだけ強化、T-744所有**。migration→配送対象は既存で充足。Dの追加部分は未試行。                                                                       |
 | P2 維持    | 開発者が成功suiteを信じたが一部ケースを実行していない／取消後の子が残る    | **選んだ規則は既存で充足**。runnerのargv脱落を今回検出。結果件数の総合照合まで自動保証するとは主張しない。                                                            |
@@ -62,21 +62,21 @@
 **追加するのはRuntime Workerの接続試験1つであり、Internal子の復元ではない。** 主な不足は次の既存証拠の間にある。
 
 | 実在test（path略記）                                                                                                        | 入口・本番区間・読取元／限界                                                                                                                                                                                                          |
-| ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `store.rs::tests::worker_control_grants_are_idempotent_scoped_and_support_internal_invalidation`                            | 親子registryとgrantを直接seed→実DB再open→`list_active_worker_control_grants == vec![grant]`、replay/revoke/cascade。公開list、実行、親復元は未通過。                                                                                  |
 | `worker-runtime/src/worker_backend.rs::tests::restart_restore_reconstructs_runtime_owned_worker_mutation_client`            | `worker_context`を2回構築しclient kindとworkspace IDをassert。実`restore_controller`もHTTPも通らない。                                                                                                                                |
 | `workspace-server/src/server.rs::tests::production_profile_backend_restores_zero_input_orchestrator`                        | 本番profileのstop→restore、同identityとonlineをassert。同一API内、子・grant・復元後公開操作なし。                                                                                                                                     |
-| `worker/src/feature/builtin/manage_worker.rs::tests::control_service_deduplicates_worker_list_by_stable_subject` | 本番serviceに`RecordingWorkspaceClient`、重複subjectの投影をassert。実grant・署名検証なし。                                                          |
+| `worker/src/feature/builtin/manage_worker.rs::tests::control_service_projects_runtime_subject_and_deduplicates_worker_list` | 本番serviceに`RecordingWorkspaceClient`、重複subjectの投影をassert。設計時は`control_service_deduplicates_worker_list_by_stable_subject`で、fixtureの応答に既に`kind`があった。恒久実装では実Backend形へ補正。実grant・署名検証なし。 |
 
 本番接続根拠は `ProfileRuntimeWorkerFactory::restore_controller` の `worker_context` 再構築→`Worker::restore_from_worker_metadata_with_context`→返す `RuntimeWorkerController.workspace_client`、Serverの `list_known_workers`（認証親→grant→Runtime summary）と `send_known_worker_input`（grant付きcontrol handle→子入力）である。既存 `worker_control_handle_rechecks_revoked_grants_for_each_operation` はhandle直呼びの失効拒否、`worker_control_input_is_idle_only_and_returns_rejection_as_http_error` はfixture Runtimeへのinput種別を守るが、この復元接続は守らない。
 
-- **配置・最小fixture**：`crates/workspace-server/src/server/tests/worker_operations_tests.rs` の通常lib結合に、仮名 `restored_runtime_parent_lists_and_inputs_existing_child` を追加する。既存production restore/永続session支援を再利用し、隔離temp DB・Runtime FS store・loopback router・親P/子Cだけ。Ticket、Git操作、Workdir、Subjektiv、実モデル課金を持ち込まない。P/Cのregistryとcontrol grantは復旧前だけ作成し、再open後は再seedしない。子作成の冪等性は既存spawn試験に任せる。
+- **配置・最小fixture**：`crates/workspace-server/src/server/tests/restored_parent_control_tests.rs` の通常lib結合に `restored_runtime_parent_lists_and_inputs_existing_child` を追加した。既存production restore/永続session支援を再利用し、隔離temp DB・Runtime FS store・loopback router・親P/子Cだけ。Ticket、Git操作、Workdir、Subjektiv、実モデル課金を持ち込まない。P/Cのregistryとcontrol grantは復旧前だけ作成し、再open後は再seedしない。子作成の冪等性は既存spawn試験に任せる。
 - **操作入力・入口**：親Pを停止してshutdown/join完了後に旧store/APIを解放、同DB/FSを再openし本番factoryでPをrestore。復元controller自身の`workspace_client`（公開field）を既存の公開 `manage_worker_feature(...)` へ渡し、公開Feature installを通して登録したWorkerList／WorkerSendInput Toolで操作する。内部の `WorkspaceWorkerControlService` はprivateのまま使い、Server testから直接構築したり公開範囲を拡大したりしない。list応答の完全subjectをinputの対象へ渡す。外からPを名乗る署名requestを作るだけでは代替しない。HTTP構成を選び `build_router` の外側署名認証も通す。embedded dispatcherだけの成功でHTTP署名を主張しない。
 - **観測・落ちるassertion**：listにCのruntime/worker IDと権限が一致、grant ID/件数不変。IdleとなったCへ一意な本文markerを`UserIfIdle`として1回送信し、acceptedだけでなくCのcanonical sessionを読みmarkerが1件であることをassertする。CのIdleは観測イベントで同期し初期IdleをSubmit完了と誤認しない。LLM判断は範囲外。
 - **fault位置**：復元時の`worker_context`からsigner/Workspace接続を落とす一時mutationではlist成功/subject一致が失敗すること。grantを復旧後にrevokeする境界faultでは次のinputが`UnknownWorker`相当の公開拒否となり、Cのmarker件数不変であること。前者は接続の回帰、後者は権限の再判定を確認する。全API操作の失効行列やC自身のrestoreは既存の別規則へ任せる。
 - **同期・回収**：`confirm_shutdown_and_join`相当の既存完了通知とtask joinを使い、loopback serverもfinally/RAIIで停止・join。bounded watchdogを設け、固定sleep、`drop(api)`だけ、稼働Runtimeの借用をしない。
-- **target/filter・区分**：`cargo test -j 2 -p yoi-workspace-server --lib restored_runtime_parent_lists_and_inputs_existing_child -- --test-threads=1`（提案名、まだ存在しない）。通常runner対象。DB/socketだけを理由にopt-inにしない。suiteを増設せず既存libに収める。
+- **target/filter・区分**：`cargo test -j 2 -p yoi-workspace-server --lib restored_runtime_parent_lists_and_inputs_existing_child -- --test-threads=1`（恒久実装の実行filter）。通常runner対象。DB/socketだけを理由にopt-inにしない。suiteを増設せず既存libに収める。
-- **コストと未確認**：fixture接続を含め1–2人日、追加本体は秒〜十数秒規模を予算とする**推定**。保守費はfactory/認証/回収の結合fixture追従が中心で、純粋unitより高い。このためP1の薄いadapter適合より後に置く。追加不要判定の各項目は実行時間・fixture保守とも増分0である。未実装・未試行・未実測であり、再open後のproduction factoryとHTTP構成の組立て、課金なしの子入力完了支援の再利用可能性を最初に試す。spawn用LLM hookがrestoreにも効くとは仮定しない。支援拡張が大きければ一旦採否を戻し、製品全体E2Eや公開API拡張へ膨らませない。client署名だけの別の新規unitを並行追加して同じ保証を二重計上しない。
+- **設計時のコスト見積り**：fixture接続を含め1–2人日、追加本体は秒〜十数秒規模を予算とした。保守費はfactory/認証/回収の結合fixture追従が中心で、純粋unitより高い。追加不要判定の各項目は実行時間・fixture保守とも増分0である。組立てと課金なしの子入力完了支援は当時未試行だった。実装ではspawn用LLM hookがrestoreには効かないことを確認したうえで、公開APIやtest支援を拡張せず実現した。最終費用・制限は末尾を参照する。client署名だけの別unitを追加して同じ保証を二重計上しない。
 
 Internal子は `worker/src/spawn/registry.rs::load_from_worker_state_with_reclaim` が空registryを生成する。`crates/worker/tests/internal_subworker_restore_test.rs::restore_reclaims_and_clears_legacy_process_children` は親scope回収、`spawned_children`空・reclaimed記録・projection `[]`をassertする。これは旧子の復活成功ではなく、その逆の保証である。
 
@@ -95,7 +95,7 @@ T-744では既存Rust代表8件が成功（上表以外の公開reissue/case/Ans
 
 T-725現行本文・保留trackingを読んだ。`workspace-drive/tests/storage.rs::receipts_survive_response_loss_and_restart_without_double_mutation` は実DB/blob再open後のreceipt一致、同request再送一致、別actor競合拒否、list件数1をassertする。`workspace-server/src/server/tests/worker_drive_tests.rs::lost_mutation_response_is_resolved_by_receipt_without_resending_effect` は本番DriveFeature→署名router/storeを通し、receipt committed・POST mutate数1・別Worker listのlast mutation一致をassertするがRuntime起動はfixtureである。これらの保存/応答喪失規則を再設計しない。実Web adapter接続は `drive_web_roundtrip_tests.rs::repositoryless_drive_real_web_adapter_preserves_bytes_cas_and_latest_reference_lifecycle` の既存ignore/明示実行であり、通常suiteの成功へ含めない。Worker寿命・Web画面までの不足と必要コストはT-725再開時の判断で、今回未確認とする。
 
-## 今回の代表試行と残る検証
+## 設計時の代表試行と残った検証
 
 全て専用checkoutで逐次実行、Rust buildはjobs 2。表の本体はlibtest/Deno表示、外側は`time -p`の1回測定であり、通常suite全体の増分やCI中央値ではない。
 
@@ -105,6 +105,38 @@ T-725現行本文・保留trackingを読んだ。`workspace-drive/tests/storage.
 | `cargo test -j 2 -p worker-runtime --lib blocking_workspace_client_clears_initial_request_timeout -- --test-threads=1`                              | 本番timeout適用をSomeだけに変更。`request ended before response`でtimeout=true、1 failed / exit 101。復元後1 passed。                      | baseline 0.06秒／167.85秒（build約167秒）、fault 0.04秒／19.63秒、復元0.06秒／18.25秒 |
 | `deno task test:runner`、fault時のみ`deno test --allow-read --allow-write --allow-run --allow-env tools/test.test.ts --filter 'round-robin shards'` | 保存selectedNamesは変えず実argvの先頭名を落とす。`task.args.slice(3)`一致assertが失敗 / exit 1。復元後全17 passed。                        | baseline全体7秒／8.11秒、fault単一12ms／0.63秒、復元全体7秒／7.49秒                   |
 
-追加で `cargo test -j 2 -p worker-runtime --lib runtime_owned_workspace_client_ -- --test-threads=1` は3 passed（本体0.20秒／外側0.42秒）。実験patch・stdout・stderr・時間はGit管理外 `target/regression-design/` の `reader-*`、`timeout-*`、`runner-*` へ分離し、3 sourceのdiffが空であることを復元後に確認した。恒久変更は本設計書だけである。
+追加で `cargo test -j 2 -p worker-runtime --lib runtime_owned_workspace_client_ -- --test-threads=1` は3 passed（本体0.20秒／外側0.42秒）。実験patch・stdout・stderr・時間は当時のGit管理外 `target/regression-design/` の `reader-*`、`timeout-*`、`runner-*` へ分離し、3 sourceのdiffが空であることを復元後に確認した。当時の恒久変更は本設計書だけだった。
 
-新規の復元親接続、DB fixture suite、画像巨大入力、Ticket/Drive、全通常suite、E2E/browserは今回実行していない。実モデル試行・稼働更新もない。通常suiteのCI job配線/実行も今回確認しておらず、ローカルの選択成功をCI成功としない。追加案を実装する時は所有suiteの既存fixture再利用を先に測り、通常runnerでの選択と実行jobを確認する。
+設計時には新規の復元親接続、DB fixture suite、画像巨大入力、Ticket/Drive、全通常suite、E2E/browserを実行していなかった。以下は再開後の実装結果であり、これら過去のprobeや71.06秒を再測定したものではない。
+
+## 恒久実装の結果と費用
+
+**本番restore接続を1ケース追加し、実接続で見つかったsubject変換の不具合を修正した。** 同じ `adfa4229` 基準の専用checkoutへ採用設計の3コミットを順に取り込み、設計sourceとの差分が文書1ファイルのみであることを確認した。製品修正は `2f0e0b28`、恒久テストは `46df60cb` に分離している。
+
+### 実現した境界
+
+- 実SQLite・Runtime FS・literal loopbackのouter `build_router` を使う。実Runtime backend/factoryでP/Cを作成し、registryとcontrol grantは復旧前のみ作る。Pの最初のSubmitでSessionを保存し、`stop_worker` のshutdown完了・execution task join後、server taskをabort/join、Feature storageをshutdown、旧storeのWeakがupgrade不能であることをassertしてから同DB/FSを再openする。
+- Runtimeの明示restore admissionから本番 `ProfileRuntimeWorkerFactory::restore_controller` でPを復元する。Cのexecution backendは生存させ、factoryで復元したcontrollerはPだけであることをassertする。C自身やInternal子の復元は保証しない。
+- 復元controllerの公開fieldから得たclientを無変更で `manage_worker_feature` に渡す。公開 `Worker::install_features` を使う非controllerのTool hostで登録Toolを取り出して実行する。このhostはRuntime registryの第三のWorkerではなく、署名主体も作り直さない。private serviceの直構築や公開APIの拡張はない。
+- outer署名認証→実grant→Runtime summary/inputを通し、完全なtagged subject、CのID、権限とgrantの全record一致をassertする。listで得たsubjectを補正せずTool inputへ渡す。入力前にCのイベントを購読し、`SubmissionAccepted` のID→`RunEnd::Finished`→同IDのfinished fenceを持つIdleで同期する。canonical Sessionのtyped `UserInput` entryにmarkerが正確に1件あることを実保存readerで確認する。初期Idle、acceptedのみ、JSON内の文字列出現回数では代替しない。
+- 外部モデルだけを固定する既存spawn hookを使う。restoreにこのhookは効かない。Pは保存済みの認証不要モデル設定で復元し、復元後にモデルturnは発生しない。Cの1回のturnはspawn時の固定clientを使う。factory/restore/Workspace signerのfixture置換も、restore用の試験支援追加もない。45秒watchdogとpanic/timeoutを捕捉するfinally経路でcontroller stop/join・server task回収・storage shutdownを行う。
+
+### 検出した不具合と代表fault
+
+| 状態                    | 具体的観測                                                                                                                                                                                             | 本体／build（各1回、秒） |
+| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------ |
+| 修正前の実接続          | listのsubjectが`runtime_id/worker_id`だけで、期待する`kind: runtime_worker`付きsubjectと不一致。次Toolのschemaへ渡せない。既存unit fixtureが最初からkindを含めていたため未検出だった                   | 10.12／81                |
+| 製品修正後              | Backend subject DTOをTool用tagged subjectへ投影し、既存unit fixtureも実Backend形に補正。Backend schemaは不変。復元親→list→input→canonical marker 1件→revoke後の拒否・Session不変が成功                 | 7.78／56.58              |
+| restore接続脱落mutation | restore側`worker_context`だけ、`workspace_request_client`引数を`None`へ変更。outer signerがないfallbackから実loopbackへ要求し、`WorkerList from restored parent failed`、HTTP 401で1 failed / exit 101 | 6.14／64                 |
+| mutation復元後          | 同filterで1 passed。`worker_backend.rs`のdiffが空であることを確認                                                                                                                                      | 7.78／56.58              |
+
+除去する位置の選定時に、remove専用`worker_mutation_identity`だけを落とした試行は成功（6.53秒）した。この経路のList/Inputはouter Workspace request署名を使い、remove専用forwarderを使わないためであり、その試行を故障検出の証拠に数えない。最初のWorkspace接続脱落では不正base URLで止まったため、fixtureの保存API URL・署名audienceを実loopbackへ揃えてHTTP 401まで確認し直した。patch/各ログはGit管理外 `target/restored-parent/` に保持する。grant revokeは恒久ケース内の境界faultで、次入力の`unknown worker`公開拒否とCのSession snapshot全体不変を毎回assertする。
+
+### 通常選択・検証・未確認
+
+- `cargo test -j 2 -p worker -p yoi-workspace-server`：**2,370 passed / 2既存ignored / 0 failed**、doctestも成功（0件）。外側290秒のうちbuild約103秒、Worker lib21.94秒・Server lib155.38秒。これは通常runner全体の増分や過去の全suiteとの比較ではない。
+- root `cargo check -j 2` 成功（96秒）、`yoi-runtime` と `yoi-server` の製品entry binary build成功（137秒）。fmt/diff・状態契約命名検査も成功。実モデル・稼働更新はない。
+- 通常runnerが使うCargo test artifacts→`rustTestCommands`→実libtest `--list`→`discoverRustCommands`/sharderを実行し、新ケースが実argvに正確に1回含まれることを確認した。選ばれたServer libの通常shard（38件）を本番`execute`で実行し成功、20.30秒。新しいtarget・ignore・test用featureは追加していない。
+- 新ケース単独の最終本体は7.78秒、推定予算内。単発・温まった依存artifactの値でありCI中央値ではない。保守費は実factory/署名/Session/回収のfixture追従で、保存schema・製品APIの追加費用はない。初回test buildは164秒、故障試行などのrebuildは51–136秒だった。追加速度最適化は行っていない。
+- 通常CI workflow/jobはこのtreeで確認できず、Nixの`doCheck = false`も不変。ローカルの通常選択成功をCI実行済みとはしない。全Workspace通常runner、browser/E2E、実モデルは今回未実行。merge/closeは本報告の証明範囲外である。
+- T-744のA〜Dは別Workerが実装中であり、上記表は設計時の最終handoffに基づく値を保持している。今回のtyped再読でも新しい恒久実装の最終費用・結果はまだ返っていなかったため、実装成功や最終コストへ読み替えない。採用統合時にはT-744の公開source・最終結果を同表と照合する。同じ接続ケースの再設計・重複実装、T-725保留解除、T-737変更は行わない。