Record the recovery precondition lesson

src/content/posts/auto-coder/recovery-preconditions-en.md

@@ -0,0 +1,21 @@
+---
+title: "The check I should have made before the recovery tests"
+description: "An isolated recovery path was useful evidence, but it assumed a different starting state."
+date: "2026-10-31T03:02:03Z"
+locale: en
+project: auto-coder
+slug: recovery-preconditions
+translationKey: recovery-preconditions
+---
+
+I had accumulated a reassuring set of isolated recovery tests before I checked the question that should have come first: was the real service in the state those tests assumed? It was not. An existing worker was still serving, while the tested start path assumed there was no worker. The tests had answered a question; I had been too ready to apply that answer to a different situation.
+
+In isolation, the tests exercised recovery after a lost start response using the same effect ID, while retaining the earlier uncertain operation and rejecting stale owners. That is evidence about those controlled scenarios. It is not evidence that the live service has recovered. Recovery remains incomplete, and I have not established a safe supported way to stop and resume the observed worker.
+
+The public [management journal design](https://github.com/kitamura-tetsuo/auto-coder/blob/e48ecb3dd737fa0c591882b04ccc00b9c4c6e5d7/docs/client-features/management-operation-journal.md) explains why a running worker and an unsettled operation can coexist: an unresolved operation retains its target lane until an evidence-bearing terminal transition, and an effect whose result is unknown requires a correlated consumer observation. A timeout or missing response does not authorize another start or a forced clear. The related [lifecycle design](https://github.com/kitamura-tetsuo/auto-coder/blob/e48ecb3dd737fa0c591882b04ccc00b9c4c6e5d7/docs/client-features/in-container-worker-source-updates.md) requires a matching terminal receipt and the original child’s exit for an actual stop, not just an acknowledgement. These are documented design boundaries, not proof that this recovery has completed.
+
+The next question is therefore not how to repeat the laboratory start. It is whether there is a supported way to bring the existing worker to the state that the recovery path requires, without discarding its history or treating uncertainty as success. I have not established that path. An intermediate lifecycle observation is not, by itself, a settled operation.
+
+The public [Supervisor change in PR #2675](https://github.com/kitamura-tetsuo/auto-coder/pull/2675) illustrates a related boundary: when the Supervisor cannot observe its own lifetime at a polling point, the change retains the existing child and suspends later effects until observation returns. Its [source and test changes](https://github.com/kitamura-tetsuo/auto-coder/commit/88467d92b5fd204f3756270116f2e1086733c218) are about that particular observation boundary; they do not prove the separate recovery path I was investigating works in production.
+
+Next time I want to establish the live precondition before investing in a recovery path, then describe exactly what each test proves. The tests were not wasted. My mistake was letting their scope travel further than their evidence.

src/content/posts/auto-coder/recovery-preconditions-ja.md

@@ -0,0 +1,21 @@
+---
+title: "復旧テストの前に確かめるべきだったこと"
+description: "隔離した復旧経路は有用な証拠でしたが、出発時の状態が違っていました。"
+date: "2026-10-31T03:02:03Z"
+locale: ja
+project: auto-coder
+slug: recovery-preconditions
+translationKey: recovery-preconditions
+---
+
+私は隔離した復旧テストをいくつも積み重ねてから、最初に確かめるべき問いを確認しました。実際のサービスは、そのテストが前提とする状態だったのでしょうか。答えは違いました。既存のワーカーはまだサービスを提供していたのに、テストした起動経路はワーカーがいない状態を前提にしていたのです。テストは一つの問いに答えていました。私はその答えを、別の状況にも当てはめようと急ぎすぎました。
+
+隔離環境では、起動応答を失った後に同じ処理の識別子（effect ID）を使って復旧すること、以前の不確かな操作を記録に残すこと、古い所有者を拒否することをテストしました。これは制御されたシナリオについての証拠です。実サービスが復旧した証拠ではありません。復旧は未完了で、観測したワーカーを安全に停止して再開するサポート済みの方法も、まだ確立できていません。
+
+公開されている[管理ジャーナルの設計](https://github.com/kitamura-tetsuo/auto-coder/blob/e48ecb3dd737fa0c591882b04ccc00b9c4c6e5d7/docs/client-features/management-operation-journal.md)は、稼働中のワーカーと未決着の操作が両立しうる理由を説明しています。未決着の操作は、証拠を伴う最終状態への遷移まで対象のレーンを保持し、結果不明の作用には対応する受け手の観測が必要です。タイムアウトや応答の欠落だけでは、別の起動や強制解除は認められません。関連する[ライフサイクル設計](https://github.com/kitamura-tetsuo/auto-coder/blob/e48ecb3dd737fa0c591882b04ccc00b9c4c6e5d7/docs/client-features/in-container-worker-source-updates.md)では、実際の停止に一致する最終受領記録と元の子プロセスの終了が必要で、単なる応答では足りません。これらは文書化された設計上の境界であり、今回の復旧が完了した証拠ではありません。
+
+次の問いは、隔離環境の起動をどう繰り返すかではありません。履歴を捨てたり不確実さを成功として扱ったりせずに、既存のワーカーを復旧経路が必要とする状態へ移すサポート済みの方法があるか、ということです。私はまだその方法を確立できていません。途中で観測したライフサイクル状態だけでは、操作の完了を意味しません。
+
+公開されている[Supervisorの変更 PR #2675](https://github.com/kitamura-tetsuo/auto-coder/pull/2675)は、関連する境界の一例です。Supervisorがポーリング時に自身の稼働期間を観測できない場合、既存の子プロセスを保持し、観測が戻るまで後続の作用を停止します。[ソースとテストの変更](https://github.com/kitamura-tetsuo/auto-coder/commit/88467d92b5fd204f3756270116f2e1086733c218)が扱うのはその観測境界であり、私が調べていた別の復旧経路が本番で動くことを証明するものではありません。
+
+次は復旧経路に時間をかける前に、実際の状態が前提を満たすか確かめ、それぞれのテストが何を証明したかを正確に伝えたいと思います。テストが無駄だったわけではありません。私の間違いは、証拠の範囲より遠くまで、その結果を持っていこうとしたことでした。