調査期間：2026-09-06 10:18 ~ 2026-09-07 10:18 北京時間 情報源：GitHub（org: flagos-ai 52 リポジトリ + commit search 25 件全量 + デフォルトブランチ per-repo 検証 + PR/tags/releases 日付検証）、Google News RSS（中英文 12 組クエリ、プロキシ経路正常）、HN Algolia、Tavily/web 検索、智源コミュニティ hub.baai.ac.cn、FlagOS CSDN 公式コミュニティアカウント（詳細は付録）

インデックス

    1. オープンソースプロジェクトの進展（GitHub 動向）
      • 1.1 FlagGems-sglang：チャレンジコンテスト初回課題オペレータのマージ——7 つの SGLang Triton オペレータ、3 チーム、付随 benchmark と参考実装を一括投入（09-06）
      • 1.2 build-infra：イメージ tag 記録ブランチの per-backend 一意化、起動ページを納品記録によるゲート制御へ（09-06）
      • 1.3 FlagCX：UIL p2p hang 修復とアクセラレータなし CICD ゲート（09-06）
    1. 報道とエコシステム
      • 2.1 コンポーネント級ニュースは連続 5 回目の平穏な期間、検索は期間内ヒットゼロ（09-06~09-07）
    1. メンバー企業の深掘り
      • 3.1 天数智芯：0.20.2 のデュアル SDK ラインイメージを同日登録、attention 強制パスを env 注入からプラグイン設定へ収束（09-06/09-07）
      • 3.2 燧原：tops1.9.10 で sglang 0.5.18 ラインを開通、依存差異を明示的に pin（09-06/09-07）
      • 3.3 摩尔線程：musa4.3.6 sglang 0.5.18 の納品記録を補完（09-07）
    1. まとめ
  • 付録：完全な情報源リスト

1. オープンソースプロジェクトの進展（GitHub 動向）

期間総覧：org 内 52 リポジトリのうち 8 リポジトリが期間内にプッシュがあり、commit search は期間内コミット 25 件にヒット（FlagGems-sglang 13 件、build-infra 10 件、FlagCX 2 件）、デフォルトブランチへの実質的マージは上記 3 リポジトリに集中；vllm-plugin-FL、sglang-plugin-FL、FlagTree、docs、release-info の pushed_at 変化はデフォルトブランチ commits の検証により、いずれも非デフォルトブランチ（PR ブランチ）上の動作であり、期間内の実質的マージはなし。tags/releases の検証では期間内に新規 tag、新規 release なし（FlagCX v0.14.0-rc0.post1 は 08-27 付与、vllm-plugin-FL v0.3.0-rc0 は 08-24 付与、FlagGems-sglang は v0.1.0-rc0.post1 のみ、build-infra v2.1.1 は 08-03 付与、いずれも期間前）——2.2 リリース安定期が継続。本期間の主線：第一に、FlagGems-sglang が初めて外部コンテスト課題の成果マージを迎えた——「FlagOS X SGLang オペレータ最適化チャレンジコンテスト」（シーズン 2 トラック 1）で生まれた初回 7 オペレータが 3 チームにより規定の PR 形式で公式リポジトリへマージされ、その後メンテナが付随 benchmark/参考実装を一括投入し廃止オペレータを整理、コンテストの「バッチレビュー→攻略→PR マージ」パイプラインが初めて機能；第二に、build-infra 納品記録システム自体の 2 箇所の工程修復（記録ブランチ衝突、起動ページの偽陽性）；第三に、天数智芯 iluvatar 納品パスの方向性修正——前日確定した「アプリケーション層で FlagGems attention 環境変数を注入」する方案が撤回され、確定的な修復は vllm-plugin-FL の進行中 PR #450 のプラグイン設定（silu_and_mul ブラックリスト + PyTorch サンプリングフォールバック + symm-mem guard）へと移行、corex4.4.0 と 4.5.0 が同日に 0.20.2 イメージ登録を完了。

1.1 FlagGems-sglang：チャレンジコンテスト初回課題オペレータのマージ——7 つの SGLang Triton オペレータ、3 チーム、付随 benchmark と参考実装を一括投入（09-06）

情報源：PR #33 silu_and_mul、PR #34 causal_conv1d_fn、PR #37 chunk_local_cumsum_scalar、PR #38 merge_state、PR #39 per_group_transpose、PR #40 mrope_fused、PR #41 fused_moe_gemm、PR #54 batch1 付随リリース、PR #55 クリーンアップ、大会告知（08-21、CSDN 参照）

  • 事象：09-06 20:22～20:25（北京時間）、FlagGems-sglang リポジトリは 4 分間で [FlagOS Competition-Track1] Add ... Triton Kernel for sglang という規約命名の PR を 7 件連続でマージした。情報源は 3 つの独立したコントリビューター fork：yzw1128（silu_and_mul #33、causal_conv1d_fn #34）、xuanzhengdu-eng（chunk_local_cumsum_scalar #37、merge_state #38）、c2flowDS（per_group_transpose #39、mrope_fused #40、fused_moe_gemm #41）。検証の結果、当該リポジトリの全 42 件の closed PR において、これ以前に Competition のマージ記録は一切存在しなかった——これは大会開始（08-21 開賽告知）以来、公式リポジトリに取り込まれた最初の賽題オペレータ群である。
  • 付随リリース：20:35 にメンテナ liuhycs（Hongyu Liu）が内部バッチ PR #54 “Flagos sglang batch1”（7 commits / 30 files / +2947 行）をマージし、7 件の新規オペレータに benchmark テスト（benchmark/test_.py の 7 組）と開発ドキュメント（docs/tasks/.md の 7 篇）を補完し、さらに src/flaggems_sglang/reference/ に参考実装を配置した。22:08 には #55 “Remove deprecated operators and simplify benchmark utilities” を追加マージし、廃止オペレータのクリーンアップとベンチマークツールの簡素化を実施。これより前の 12:08/12:23 には #44 関連の code style と mrope_fused テスト import の修正もあった。
  • 大会ルールの背景（08-23 デイリーレポートで開賽を既報、ここでは闭环要素を補足）：本チャレンジは FlagOS 開放計算グローバル大会シーズン 2 トラック 1 であり、衆智 FlagOS コミュニティ × IEEE の共同主催、SGLang 協賛、沐曦/昆仑芯/超算互聯網などが産業パートナー；200 以上の実在する SGLang 推論オペレータ賽題を 13 バッチに分けて解放（08-17 開発期開始、11-13 締切、標準バッチ周期 7 日）、Triton/Triton-TLE で開発、マルチチップ統一評価で平均加速比により順位付け；大会規約により、各バッチの審査後に「攻占」栄誉を獲得したチームは、ウィンドウ期内に最適コードを規定フォーマットで FlagGems-sglang に PR し、CLA に署名しなければならない。コード一致性は受賞の必要条件である。

解説：これら 7 つのオペレータの意味的カバレッジは非常に典型的である——silu_and_mul（活性化融合）、causal_conv1d_fn / chunk_local_cumsum_scalar / merge_state（SSM/Mamba 系の畳み込みと状態オペレータ）、per_group_transpose / mrope_fused（mRoPE のグループ転置と融合）、fused_moe_gemm（MoE 融合 GEMM）は、SGLang の実際の推論負荷（ハイブリッドアテンション、MoE）と一対一で対応しており、コンペ問題の「実際の推論業務から取得」という設定を裏付けている。FlagOS にとってさらに重要なのはコミュニティ共築パイプラインの初回閉ループである：コンペが 8 月中旬に開幕してから約 3 週間で、初回の成果がコンペ規約に従い統一フォーマット・統一コード規範で公式リポジトリに還元され、メンテナがテスト/ドキュメントを補完した——「開放型コンペ問題→プラットフォーム評価→栄誉インセンティブ→公式リポジトリへの定着」というオペレータ衆智サイクルが産出を始めた；しかも各バッチ（以降 7 日ごとに評価）が新たな PR マージの流れをもたらし、FlagGems-sglang は FlagSparse に代わって「外部貢献密度」を観察する新たな窓口となる（FlagSparse の AlphaSparse 外部キューは既に走り切った別の衆智チャネルであり、09-05 デイリーレポートを参照）。また、yzw1128 が提出した silu_and_mul と build-infra #763 の iluvatar の flag_gems silu_and_mul ブラックリストは同名である（異なるリポジトリ、異なる問題領域であり、単なる偶然の一致である）。

1.2 build-infra：イメージ tag 記録ブランチの per-backend 一意化、起動ページを交付記録でゲート（09-06）

情報源：#756（961c0fed）、#759（8f012fd4）

  • #756（12:42）：record_app_image_tag.py は従来すべての記録を単一の共有ブランチ auto/app-image-tag に蓄積しており、過去に残った任意の open 記録 PR（任意の app/バックエンド）が rebase コンフリクトで後続のすべての記録をブロックしていた（mthreads-musa4.3.6 の記録は run 34009399235 で一度失敗している）——auto/app-image-tag-<backend>-<app-key> による per-record の独立ブランチ派生に変更し、記録同士を相互に分離した。
  • #759（14:48）：gen_data は従来 configs の deps_app key が出現するかどうかだけで app 起動ページを生成していたが、key は検証完了より前に付与される（ビルドをトリガーするため）ため、未検証のバックエンド（例：vllm0.20.2-iluvatar-corex4.4.0、deps_app は存在するが launch_docs=false、cells は未検証）も起動ページが漏れ出し、すべての app イメージに混入していた——マトリクスの launch_docs 記録をゲートとして用いる方式に変更し、未検証のバックエンドは起動ページを生成しなくなった。

解説：両者はいずれも「交付記録システム自身の信頼性修復」である——前者は記録パイプラインの単一障害点（共有ブランチの相互踏みつけ）を解消し、後者は検証状態とページ公開状態のデカップリングによる偽陽性を解消する（09-05 の寒武紀「意味論ゲートの偽陽性」問題と同源だが異なる層：あちらは実行検証ゲートの欠如、こちらはドキュメント生成ゲートの欠如）。この種のメタエンジニアリング修復が 2.2「検証-打 tag-記録」サイクルにおいて継続的に出現することは、リリース監査面が層ごとに締め付けられていることを示している。

1.3 FlagCX：UIL p2p hang の修復とアクセラレータなし CICD ゲート（09-06）

情報源：PR #542（511cdace、taozhiwei）、PR #568（8737bab4、MC952-arch）

  • #542（20:21 マージ）：[UIL] 通信ドメインが 2 より大きい場合の p2p ハング問題を修復——PR には完全な unittest 再現（マルチ rank の send_receive シナリオ）が添付されており、UIL（統一通信層）がクロスカードトポロジ拡張時に生じる収束性の欠陥修復である。通信ドメイン（communication domain）が 2 より大きいということは、このパスが一対一のデバッグシナリオではなく、マルチカードの実クラスタトポロジを対象としていることを意味する。
  • #568（21:50 マージ）：[CICD] アクセラレータなし環境で API テストをスキップ——CI は GPU/アクセラレータがマウントされていない runner 上ではハードウェア依存の API テストを実行しなくなり、偽の失敗/偽の成功を回避し、テストゲートが実行環境に応じて適応する。

解説：FlagCX は 08-27 に FlagOS Enflame collective の全フロー（#554）を完了し v0.14.0-rc0.post1 をタグ付けした後、本調査期間の2件のコミットはそれぞれ機能的な収束修正（p2p マルチドメインのハング）とCI エンジニアリング（カード無しゲートの適応化）である——build-infra と同じリズム：機能拡張は一時保留し、検証とデリバリ品質を優先する。これは 2.2 rc0 サイクルの「検証-タグ付け-記録」という収束の特徴に合致する。

2. ニュース報道とエコシステム

2.1 コンポーネント級ニュースは連続5回目の静かな調査期間、検索は期間内ゼロヒット（09-06~09-07）

情報源：Google News RSS（中英12組のクエリ、プロキシ経由）、HN Algolia（4組）、Tavily/web 検索（コンテスト、智源動向など複数組）、智源コミュニティ、FlagOS CSDN 公式アカウント（詳細は付録参照）

  • gnews の中英文組み合わせ（FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/FlagAttention/FlagCX/智源研究院 オープンソース/FlagOS コンテスト when:7d~30d など）は調査期間内ゼロヒット；FlagOS when:14d は3件の旧記事（09-01 Day0 転載など、いずれも既報道/除外済み）のみを返し、ギャンブル SEO テンプレート汚染はバッチ全体を除外。
  • HN Algolia（FlagOS/FlagGems/flagos-ai/FlagSparse）はゼロ関連（feature-flag のスペルノイズ）；Tavily で検索されたチャレンジコンテスト告知（SegmentFault/CSDN）と「オペレータ島」争奪戦ライブ配信（09-03）はいずれも調査期間前；CSDN 公式アカウントの最新コンテンツは依然として 09-01（GLM-5.3-Flash Day0）と 09-03（ライブ配信リプレイ）で、調査期間内の更新は無し。
  • 直近3日間のトレンド（GitHub org pushed が裏付け、エンジニアリング側は平穏ではない）：09-05 FlagSparse バックエンドマトリクス拡大（MetaX/MUSA/Ascend、PR #51）；09-05~09-07 build-infra の連続デリバリ登録（寒武紀 0.20.2 文字化け修正の真のデリバリ、天数智芯/燧原/摩尔線程のイメージマトリクスがローリング）；09-06 FlagGems-sglang チャレンジコンテスト初回オペレータ合流（本日 1.1）；FlagCX/FlagTree/vllm-plugin-FL/sglang-plugin-FL はいずれも PR ブランチの動きあり（FlagTree は 09-07 10:14 にもプッシュあり、デフォルトブランチは 09-04 の清微バックエンド合流で停止）。

3. メンバー単位の深掘り

3.1 天数智芯（iluvatar）：0.20.2 デュアル SDK ラインイメージを同日登録、attention 強制パスを env 注入による収束からプラグイン設定へ（09-06/09-07）

情報源：build-infra #763（23e9681f、revert #753）、#765（bc18d971）、#766（7497b65b）、vllm-plugin-FL PR #450（tengqm、進行中）

  • パス修正（#763、09-06 23:27）：09-06 09:44 に corex4.4.0 向けに注入したばかりの VLLM_FL_USE_FLAGGEMS_ATTN=1（すなわち #753、昨日のデイリーレポート 1.2 で報道した「F パス定型」の一環）を撤回。撤回理由は明確：env のベイクは「統合環境変数」という旧来の発想であり、flag_gems attention 自体の決定性問題はすでに反証済み——決定性の修正はプラグイン設定層（flag_gems silu_and_mul ブラックリスト、vllm-plugin-FL PR #450 head 71b9482 に位置）に落とすべきであり、かつ 4.5.0 のゲートテストで silu ブラックリストのみで両ラインとも決定性が得られることを確認。
  • デュアル SDK ラインが同日に登録・納品（#765/#766、09-06 23:51/23:59）：corex4.4.0 と corex4.5.0 が同時に vllm app イメージタグ 2.1.2-0.2.1_g71b9482.d20260906 を登録（g71b9482 = vllm-plugin-FL PR #450 head のソースコードフィンガープリント）——0.20.2 が両ツールチェーンラインで正式に納品；#765 は同時に旧注記「corex4.4.0 F パスは納品不可（triton フロントエンド gap）」を削除し、「4.4.0 0.20.2 納品済み（guarded wheel）」に変更。
  • 進行中の修正（vllm-plugin-FL PR #450、tengqm@BAAI、09-05 作成、09-06 23:11 更新）：タイトルは fix(iluvatar) pytorch sampler fallback + torch<2.8 symm_mem guard for corex (0.20.2)。内容は二点：587e2fe は symm-mem stub guard をバックポート（メインライン #434 の修正）し、apply_top_k_top_p を PyTorch サンプリングフォールバック（iluvatar と metax と同型のパターン）に強制し、iluvatar/patches 経由で backend import 時にロード——昨日 #745 の build-infra wheel 層における host-side パッチを、プラグイン内蔵パッチへ収束させる；ec9fded はサンプリングフォールバックを corex triton 3.1 fork でゲート（影響を受けるパスのみで使用し、4.5.0/torch 2.10 は native パスを保持）、四路分配の分類は検証済み。corex4.4.0 と 4.5.0 をカバー（wheel を共有）。

解読：天数智芯は今週 build-infra 側で最も動きの密なベンダーであり、その納品パスは二日間で一度の方向性収束を経験した：09-05～09-06 朝の形態は「旧メンテナンスライン app + アプリケーション層 env 注入 FlagGems attention + wheel 層 symm-mem guard」（昨日のデイリーレポート 1.2 に記録済み）；09-06 夜にはゲート実測（4.5.0 silu ブラックリスト単変量検証）によりenv 注入が冗長であることを証明し、#753 をロールバックし、修正をプラグイン設定（ブラックリスト）とプラグイン補丁（sampler フォールバック/symm-mem stub）へ収束させた——修正箇所は「納品の外層」（env/wheel patch）から「プラグイン本体」（PR #450）へ内移し、ひとたび #450 がマージされれば、build-infra 側の wheel host-patch は退役可能となる。これは同時に次を説明する：「F は納品可能、T は修正待ち」という分化判断は変わっていない（topk_topp は依然として corex triton fork が native kernel を拒否する根因）、変わったのは修正の落点と組み合わせ方のみである。

3.2 燧原（enflame）：tops1.9.10 で sglang 0.5.18 ラインを開通、依存差異を明示的に pin（09-06/09-07）

出典：build-infra #761（9113bbda）、#768（1fb6c0c5）、#769（79cc0937）

  • #761（09-06 22:15）：enflame-tops1.9.10 の sglang app config を新規追加——1.9.10 系は「greedy topk 修正」（sglang-plugin-FL PR #91）を経て F/T 通過を検証した上で sglang 側のデリバリを開始；env.app.sglang 設定は意図的にflashinfer を無効化し、shim チェックをスキップし、warmup 3600（1.10.6 系のミラーと整合）；また 1.9.10 runtime には compressed-tensors が欠落しているため（1.10.6 は enflame-modelopt 経由で取得可能）、deps_app に CT 依存を明示的に pin——同一ベンダーの 2 本の SDK 系における依存差異が明示的に文書化された。
  • #768（09-07 00:01）：enflame-tops1.9.10 sglang app イメージタグ 2.1.2-0.1.dev1_g32eabf40e を登録；#769（00:17）：docs に enflame-tops1.9.10 sglang 0.5.18 デリバリを記録。

解釈：燧原の sglang 0.5.18 デリバリ系が正式に開通（これ以前の 09-05 #742/#743 は vllm 側 2 本の SDK 系イメージのみ登録）。特筆すべきは build-infra の「同一ベンダー・デュアル SDK 系の依存ドリフト」への対処パターンである：1.9.10 と 1.10.6 の差異（compressed-tensors の有無、modelopt の提供経路）は、大まかに設定をコピーするのではなく、項目ごとに明示的に pin——マルチチップデリバリマトリクスの設定差異化の粒度は依存レベルに到達している。

3.3 摩尔線程（mthreads）：musa4.3.6 sglang 0.5.18 デリバリ記録の補完（09-07）

情報源：build-infra #767（b2c4799f）、#770（726e21fa）

  • #767（00:00）：mthreads-musa4.3.6 sglang app イメージタグ 2.1.2-0.1.dev1_g607b9672c を登録；#770（00:24）：docs に mthreads-musa4.3.6 sglang 0.5.18 デリバリを記録——これ以前の 09-05 の #749/#751 でデリバリ内容と compressed-tensors 設定（#747/#755）は既にマージ済みであり、本調査期間はイメージタグとデリバリドキュメントにより記録のクローズドループを完成（昨日 #756 で修正されたのは、まさに摩尔線程のこの記録が共有ブランチによってブロックされていた障害である）。

解釈：3 本のベンダー系（天数智芯 vllm、燧原/摩尔線程 sglang）のデリバリ記録が 09-06 22:15 ～ 09-07 00:24 の間に集中的にリポジトリへ反映され、#756 の記録ブランチデカップリング修正と合わせて、build-infra のデリバリ登録が「マルチバックエンド並行ローリング」の常态化リズムに入ったことを示す——2.2 rc0 サイクルではコンポーネントコードの変更は多くないが、デリバリマトリクスは継続的に右へシフトしている。

四、まとめ

本調査期間（09-06 10:18 ～ 09-07 10:18）は、ニュース側が連続 5 回目の平穏な期間（gnews/HN/Tavily でゼロヒット、SEO 汚染と旧記事の転載のみ）、GitHub 側は 25 件のコミット、3 リポジトリで実質的マージ、4 本の主要ライン：

  1. FlagGems-sglang、コンテスト初の成果を迎え、衆智パイプラインが初めて閉ループに（09-06 20:22~20:35）：チャレンジカップ（シーズン2トラック1、08-21開幕）の初回7競技課題オペレータが、3チーム（yzw1128、xuanzhengdu-eng、c2flowDS）により競技規則に従ってPRを公式リポジトリへマージ——silu_and_mul、causal_conv1d_fn、chunk_local_cumsum_scalar、merge_state、per_group_transpose、mrope_fused、fused_moe_gemm、SSM/融合アクティベーション/mRoPE/MoEの典型的負荷をカバー；メンテナは同日中にbenchmark、開発ドキュメント、参照実装を補完（#54、+2947行）し、廃止オペレータを整理（#55）。これは同リポジトリ史上初のCompetitionマージであり、「開放課題→プラットフォーム評価→栄誉獲得→公式リポジトリ定着」パイプラインが初めて走通した、以後13バッチが継続的にマージの流れをもたらす。
  2. 天数智芯のデリバリ経路が2日以内に方向性収束：#753の「アプリケーション層env注入FlagGems attention」（昨日確定）は当晚に#763によりゲート実測で覆されロールバック、確定的修正はvllm-plugin-FL PR #450のプラグイン設定（flag_gems silu_and_mulブラックリスト）+プラグインパッチ（topk_topp PyTorchサンプリングフォールバック、symm-mem stub guard、いずれもcorex triton 3.1 forkの影響経路に限定）へと沈下；corex4.4.0と4.5.0は同一イメージフィンガープリントg71b9482で同日登録 0.20.2正式デリバリ——修正の落点は「デリバリ外層」から「プラグイン本体」へ内移し、#450マージ後はbuild-infraのwheel host-patchが退役可能となる。
  3. sglang 0.5.18デリバリラインの横展開：燧原tops1.9.10開通（#761/#768/#769、1.9.10はcompressed-tensors欠如の依存差異を明示的にpin）、摩尔線程musa4.3.6記録閉ループ（#767/#770）；build-infra記録システム自身が2箇所の信頼性修正を完了（#756記録ブランチper-backendデカップリング、#759起動ページのlaunch_docsゲート準拠）。
  4. FlagCXの収口リズム継続：#542通信ドメイン>2のUIL p2pハング修正（unittest再現付き）、#568アクセラレータ無しCICDゲート適応。

予測：昨日と一致、2.2 rc0周期は「検証-タグ付け-記録」の収口段階にあり、次のリリースシグナルは依然としてcommunityリストリポジトリの動きとbuild-infra version bumpを注視；新規観察点：チャレンジカップ各バッチ（7日一評）の競技課題オペレータPRマージがFlagGems-sglangの安定的な外部貢献流となる、13バッチで11-13まで、そのマージリズムとオペレータ種別分布から競技品質を判断可能；vllm-plugin-FL PR #450がiluvatarメインラインにマージされた後、天数智芯4.4.0/4.5.0の設定化修正が初めて閉ループとなる。

付録：完全情報源リスト

情報源 検証結果
GitHub org repos API（flagos-ai、52 リポジトリ） 8 リポジトリで期間内にプッシュあり。vllm-plugin-FL/sglang-plugin-FL/FlagTree/docs/release-info はデフォルトブランチの commits で検証した結果、PR ブランチの動作と確認（FlagTree 09-07 10:14 プッシュ、デフォルトブランチは 09-04 で停止）
GitHub commit search（org 全量、25 件） FlagGems-sglang 13、build-infra 10、FlagCX 2。committer の時刻と内容を一件ずつ検証済み
GitHub PR API（FlagGems-sglang 全量 + vllm-plugin-FL #450 + FlagCX #542/#568） 42 件の closed PR のうち Competition へのマージは 7 件（すべて 09-06、第1弾に該当）。#54/#55 がセット。#450 は進行中で open
GitHub tags/releases API + 日付検証 期間内に新規 tag/release なし（FlagCX v0.14.0-rc0.post1=08-27、FlagGems-sglang v0.1.0-rc0.post1、build-infra v2.1.1=08-03、vllm-plugin-FL v0.3.0-rc0=08-24）
build-infra commits #756-770 10 件を一件ずつ検証（納品記録のエンジニアリング修正 + 3日間のチップ納品登録 + パス収束のロールバック）
大会公告（CSDN/SegmentFault、08-21）と大会規約 1.1 大会背景と PR 命名規範の裏付けを提供（期間前、新規ニュースではない）
Google News RSS（中英 12 組、プロキシ経由） 期間内のヒットはゼロ。ギャンブル SEO テンプレートによる汚染はバッチ全体を除外。09-01 Day0 の旧記事転載は新規内容ではない
HN Algolia（4 組のクエリ） 関連ヒットはゼロ（feature-flag のノイズ）
Tavily/web 検索（大会、智源、メーカー各組） 期間内の FlagOS 報道なし。チャレンジ大会公告と「オペレータ島」ライブ配信（09-03）はいずれも期間前
智源コミュニティ hub.baai.ac.cn / FlagOS CSDN 公式アカウント CSDN の最新 09-01/09-03 内容（前日記録済み）、期間内の更新なし