ダッシュボードのTask Schedulerバッジが更新されない問題を調査中、GitHub APIの重要な特性を発見した。 問題は、CSVファイルを更新した後、ダッシュボードのバッジ表示（「Today」「Yesterday」など）が即座に更新されないことだった。Mongolian Headwordsのバッジは1-3秒で更新されるのに、Task Schedulerは数分かかる。 原因は、使用していたAPIエンドポイントの違いだった。当初、commitsリストAPIを使用していた： このエンドポイントには15-60秒の伝播遅延がある。GitHubが内部的にコミットリストをキャッシュし、定期的にしか更新しないためだ。 解決策は、2段階のアプローチだった： ステップ1：Content APIで最新のSHAを取得 Content APIは1-3秒で更新され、常に最新のSHA値を返す。 ステップ2：SHA値で直接コミット情報を取得 この方法により、コミットリストAPIの遅延を回避しつつ、完全なコミットメタデータ（日時、著者、メッセージ）を取得できる。 ダッシュボードのアーキテクチャは、デュアルAPI戦略を使用するようになった： キャッシュメカニズム（5分TTL）も正しく機能していることを確認した。問題はキャッシュではなく、APIエンドポイントの選択だった。 現在、Task Schedulerバッジは、Mongolian Headwordsと同じ速度（1-3秒）で更新される。この経験から、APIの各エンドポイントの特性を理解することの重要性を学んだ。

ダッシュボードのゲージチャート2と3は、静的なベースラインに対する進捗を測定する特殊なメトリクスだ。Gauge 1（総エントリ数）とは異なり、これらは時間経過に基づく評価を行う。 Gauge 2（Backlog Pressure）は、未処理データの蓄積状況を測定する。理想的には50%（中立）だが、14日以上更新がないと黄色ゾーン、30日以上で赤ゾーンに突入する。 実装の鍵は、Script Propertiesに保存されたベースラインタイムスタンプとの比較だった： Gauge 3（Chain Completion）は、5段階のデータ処理チェーン（S02→S03→S04→S05→S06）の完了状況を追跡する。各段階が完了すると20%ずつ増加する。 当初、メニューの不安定性にも悩まされた。Code.gsのメニュー構築関数が、他の関数と競合していた。解決策は、メニュー初期化をonOpen()トリガーから分離し、専用の関数に移動することだった。 ベースライン情報の管理も重要だった。管理者が各フォルダのベースラインタイムスタンプを設定・表示できる関数を追加した： 現在、Gauge 2と3は正確に動作しており、プロジェクトの健全性を視覚的に示している。時間ベースの評価メトリクスは、データ処理の遅延を早期に検出するのに有効だ。

Inventory自動化システムで、チェーン実行が正しく動作しないバグを発見した。5つのサブフォルダを順番に処理するはずが、最初のフォルダを繰り返し処理していた。 問題は、100ファイル以上あるフォルダの処理が完了しても、次のフォルダに進まず、同じフォルダを最初から処理し直すことだった。 調査の結果、Phase 2（フォルダ処理完了）のコードに問題があることがわかった： フォルダ処理が完了すると、stateKey（進捗状況を保存するキー）は削除されるが、inventoryChainIndex（現在処理中のフォルダインデックス）はインクリメントされなかった。そのため、次回実行時に同じフォルダが再度処理された。 修正版： この修正により、フォルダ処理が完了すると、システムは自動的に次のフォルダに進むようになった。 テスト時には、Logシートに「Chain advanced to index X」というメッセージが表示されることを確認した。これにより、チェーンが正しく前進していることが視覚的に確認できる。 現在、完全なInventoryチェーンは5つのサブフォルダすべてを順番に処理できる。日次トリガーでtriggerFullInventoryを実行すると、システムは自動的に次のフォルダに移動し、すべてのフォルダが処理されるまで継続する。