調査期間：2026-10-22 08:00 ~ 2026-10-23 08:00（北京時間、24時間）

情報源：RT-Thread 公式ニュースインターフェース、コミュニティフォーラム記事インターフェース、GitHub（メインリポジトリ commits / PR / Issue / Releases / tags、RT-Thread-packages 組織各リポジトリ、topic:rt-thread エコシステム検索）、Google News 集約（中英文複数クエリ、プロキシ経由）、HN Algolia、業界メディアおよびベンダーチャネル検証（詳細は付録情報源リスト参照）

本期インデックス

    1. カーネルとバージョン動向
      • RISC-V チケットスピンロックを AMO に変更：ロック解放側は LR/SC リトライを経由しなくなり、K1 の SMP 設定も同時に 4 コアから 8 コアへ拡張（10-22）
      • メッセージキュー FIFO が高優先度スレッドに割り込み：2 年間放置された旧チケットにメインラインで安定再現可能な最小例を提示（10-22）
      • メインラインは 3 日間ゼロコミットで終了：期間内に 4 コミットを反映、3 提案をマージ、v5.4.0 は依然バージョンマクロのみ（10-23）
    1. セキュリティと安定性の追跡
      • NVMe は非アクティブネームスペースごとに 4480 バイトを漏洩：準拠ドライブは起動のたびに約 1.1 MB のカーネルヒープを喪失（10-23）
      • 9PFS がサーバー側の長さフィールドをそのまま信用：ASAN が 8.3 MB の受信バッファを越えて読み取り、修正提案が起票済み（10-22）
      • NFS 越境書き込み欠陥チケットのステータスは変化なし、本期は引受も修正提案もなし（10-22）
    1. 公式・コミュニティ活動
      • 公式ニュースインターフェースは依然 6 月で停止、コミュニティ記事は期間内に全新規長文なし（10-23）
    1. エコシステムとベンダー適配
      • ESP32-C3/C6 の ESP-IDF v6.1 適配をメインラインにマージ：RISC-V ツールチェーンも GCC 15.2 へジャンプ（10-22）
      • GD32VW553 が at_device パッケージに登場：RISC-V の Wi-Fi 6 プラス BLE 5.2 チップを menuconfig で直接選択可能（10-22）
      • GD32EmbeddedUI サンプルがリポジトリ作成から 1 日で LVGL パッケージインデックスに登録、パッケージとリポジトリが閉ループを形成（10-22）
      • scons –attach が中国語 Windows 上で直接クラッシュ：4 箇所の絵文字マーカーを ASCII に置換（10-22）
    1. まとめとトレンド観察
      • 本期のトレンド
      • 局限性と重複排除の説明

1. カーネルとバージョン動向

1.1 RISC-V チケットスピンロックを AMO に変更：ロック解放側は LR/SC リトライを経由しなくなり、K1 の SMP 設定も同時に 4 コアから 8 コアへ拡張（10-22）

日付：2026-10-22 17:59（マージ時刻）　出典：PR #11904、cpuport.c、K1 BSP README

今回の変更は libcpu/risc-v/common/cpuport.c に適用され、チケットロック（ticket spinlock）のロック取得とロック解放の 2 パスそれぞれの実装を置き換えた。従来は両側とも LR/SC ループで同一ワードに対して「読み込み—変更—書き込み」を行っていた：ロック取得側は上位 16 ビットの次のチケット番号を 1 加算し、下位 16 ビットの現在の保持ロック番号と結合して 1 ワードに戻して書き込み、ロック解放側も同様に LR/SC で保持ロック番号を 1 加算していた。変更後のコメントは 2 つの失敗面を明示している：第一に、チケット取得パスと LR/SC をリトライ中のロック解放パスが同一の予約セット上で互いに割り込み、高コア数競合下でライブロックに陥る——これがタイトルにある SMP ストールである。第二に、ロック解放でワード全体の読み書きを行うことで、並行期間中に新たに取得されたチケット番号も一緒に上書きしてしまう。

修正方法は、チケット取得を amoadd.w.aqrl 単一命令のアトミック加算に変更することである（AMO は失敗しないため、リトライが割り込まれる問題も存在しない）。チケット増分は 1 << 16 とし、2 つの 16 ビットカウンターは依然として低 32 ビットに共存する——コメントはこの点が RV64 上でも同様に成立することを明記しており、したがって 32 ビット幅の amoadd.w を使用し、amoadd.d は使用しない。ロック解放側はアトミックな読み書きを完全に排除する：保持ロック番号を書き込むのはロック保持者のみであるため、1 回の 16 ビットハーフワードストアで「1 加算」を行えばよく、並行して新たに取得されたチケット番号も保持され、LR/SC も不要となる。両側にそれぞれ rt_hw_barrier() を 1 箇所補い、クリティカルセクションのメモリアクセスが相手の解放を観測した後に行われること、および保持ロック番号を進める前に完了して公開されることを保証している。

同一提案では、bsp/spacemit/k1 の CONFIG_RT_CPUS_NR と rtconfig.h の RT_CPUS_NR を4から8に変更し、K1の2つのREADMEと bsp/README.md のサポートマトリクスに説明を追加している。これは「まずロックを修正し、その後コア数を開放する」という順序に属する。K1の現行READMEによると、このSoCは64ビットRISC-Vで、8つのX60コアを統合しベクトル拡張を備え、BSPはデバイスツリーを経由し、U-Boot/OpenSBIによってSモードで起動され、検証プラットフォームはBanana Pi BPI-F3である。提案全体は6ファイル+33/-37で、変更量は多くないがRISC-Vマルチコアのインフラに触れている。

1.2 メッセージキューのFIFOが高優先度スレッドに割り込みされる：2年間放置された古いチケットがメインラインで安定再現可能な最小例を提示（10-22）

日付：2026-10-22 13:54（コメント時間）　情報源：Issue #4940、ipc.c

2021年8月の古いチケットが調査期間内に再び進展した。このチケットは元々、メッセージキューとメールボックスが RT_IPC_FLAG_FIFO の下で先入れ先出しを保証できないことを指摘しており、メンテナは当時「ここではロックを行っていないが、semaphoreは実質的にロックを行っている」と認める返信をしたが、その後修正は実装されていない。新しいコメントはこの手がかりに沿って最小再現を追加し、メインラインで安定して再現できると宣言している。

再現構成は、rt_mq_create() で msg_size=4、max_msgs=1、RT_IPC_FLAG_FIFO のキューを作成する：低優先度スレッド（20）が先にブロッキング受信を行い、キューが空のため待機キューの先頭に掛かる。高優先度スレッド（10）はキュー待機に入らず、先にセマフォでブロックする。メインスレッドがメッセージを1つ送信すると、低優先度スレッドは待機キューから外されレディキューに入る。メインスレッドが続けてセマフォを解放すると、高優先度スレッドがレディになる。メインスレッドが遅延してCPUを譲ると、高優先度スレッドが先に実行され、非ブロッキング受信でそのメッセージを取り去る。メッセージは先頭の待機者の手に渡らず、FIFOセマンティクスが優先度プリエンプションによって破壊される。

問題の性質は1.1とは異なる：競合ウィンドウではなく、「起床即デキュー」というセマンティクスの選択である——起床された者は一旦待機キューを離れると通常のレディスレッドとなり、その後はより高い優先度の非ブロッキング取得が合法的にそのメッセージを奪い取れる。コメントではuClinuxの做法として、起床するがデキューせず、実際にロックを取得した時点で保留キューから外す方法が挙げられており、修正の参考になる。このチケットは現在もオープン状態で、本期に対応する提案はない。

1.3 メインラインが3日間ゼロコミットで終了：調査期間内に4コミットを着地、3提案をマージ、v5.4.0は依然バージョンマクロのみ（10-23）

日付：2026-10-23（確認時間）　情報源：メインリポジトリのコミット記録、releases、tags

前回記録したメインラインの静止は調査期間内に破られた：10-22の一日で4コミットが着地し、すべて3つの提案のマージによって持ち込まれた。それぞれESP32-C3/C6のESP-IDF v6.1適配（07:42 UTC）、RISC-Vチケット番号ロックとK1八核（09:59 UTCの2件）、tools/attachconfig.py のemoji置換（10:00 UTC）である。マージ時間は15:42から18:00（北京時間）の3時間以内に集中し、いずれも同一メンテナが処理しており、集中的なレビュー締めくくりとして現れている。

バージョン側は依然として動きがない：最新のリリース物とタグは依然として09-10のv5.3.0であり、10-17の「Bump version to v5.4.0」は今もバージョンマクロのみで、リリースノートもバイナリもプレリリースタグもない。組織レベルでは調査期間内にメインリポジトリとpackagesの2リポジトリのみにプッシュがあり、他のリポジトリの最終活動時間は前回と一致している。

2. セキュリティと安定性のフォローアップ

2.1 NVMeが非アクティブな名前空間ごとに4480バイトを漏洩：適合ドライブは起動のたびに約1.1 MBのカーネルヒープを失う（10-23）

日付：2026-10-23 01:15（作成時間）　情報源：Issue #11919、nvme.c

研究者 XueDugu は調査期間の末尾に NVMe ドライバのカーネルヒープリークを提出した。nvme_scan_device() は Identify Controller の応答内にあるデバイス側で制御可能な nn（Number of Namespaces）をループの上限として用い、1 から nn までを順に番号ごとに探索するが、各ラウンドではまず 4480 バイトの rt_nvme_device を rt_calloc で割り当て、その後でその番号の Identify コマンドを発行する。2 つの失敗パスはいずれもこのメモリを返却しない。nsze == 0（名前空間は割り当て済みだが非アクティブで、仕様が許容する正常な応答）は continue で進み、Identify コマンドのエラーは goto _free_res で解放を飛ばす。

影響範囲は作者の実測に基づいて示されている。公式の qemu-virt64-aarch64 BSP のデフォルト設定では、NVMe を接続しない場合のアイドル時カーネルヒープは 66,941,784 バイトである。nn = 1 の単一 name space ディスクを接続すると 66,931,592 バイトで正常である。QEMU 標準の nvme デバイスを接続すると 65,774,912 バイトまで低下する。QEMU は常に nn = 256 を報告するが公開する名前空間は 1 つだけで、この応答は合法であるため、255 個の非アクティブ番号がそれぞれ 4536 バイト（memheap ヘッダを含む）をリークし、1 回の起動で 1,156,872 バイト、約 1.1 MB となり、64 MB のカーネルヒープの 1.8% を占める。ホットプラグと再スキャンでは線形に累積する。デバイスがより大きな nn（例：0xFFFFFF）を報告した場合、ループはヒープを使い果たすまで割り当てを続け、最終的にシステムは起動できなくなり、シリアルは hello rt-thread の後でプロンプトを出さずに停止する。

作者は CWE-401 と CVSS 3.1 4.9（Medium、AV:P）を示し、「起動ごとの 1.1 MB のリークには攻撃者を必要としない」と説明し、「ヒープ枯渇による起動不能」のみが悪意あるまたは畸形のコントローラを必要とすると述べている。欠陥は 2024-11-24 のコミット 945114fd5（NVMe サポート、#9591）で導入され、v5.2.0 以降のすべてのバージョンと現在のメインラインに含まれる。推奨される修正方法は、この割り当てを名前空間の有効性を確認した後に移動し、2 つの失敗パスで解放を補完すること、同時に nn をそのまま上限として採用しないこと（mnan で上限を設けるか、CNS 02h の Active Namespace ID リストに切り替える）である。このチケットは現在ラベルもアサインもされていない。

2.2 9PFS がサーバ側の長さフィールドをそのまま採用：ASAN が 8.3 MB の受信バッファを越えて読み取り、修正提案が公開済み（10-22）

日付：2026-10-22 19:36（作成時間）　情報源：PR #11918、Issue #11289、dfs_9pfs.c

dfs_9pfs_read() と dfs_9pfs_getdents() にはサーバ応答の長さと切り離された越境読み取りが存在し、提案は +58/-4 で dfs_9pfs.c の 1 ファイルのみを変更する。根本原因は p9_transaction() の返却バイト数が破棄され（RT_NULL を渡している）、その後コードがメッセージ内の count、各レコードの stat_size と name_len を直接使用し、実際に受信したデータ量と照合しないことである。サーバが count を巨大に偽り実際には非常に短いメッセージを返すだけで、パーサは受信バッファを越えて読み進めてしまう。通常スキップされる . レコードは fd->pos >= end の終了条件に一致しないため、パーサは前進し続けることができる。

作者は bsp/simulator（x86-64、ASAN、-fsanitize=address）で偽のメモリ 9P サーバを構築した。ハンドシェイクと Tstat/Topen/Tclunk には正常応答するが、Tread には 11 バイトのメッセージのみを返し、count は約 2 GB と偽り、受信バッファの後方に偽の . レコードと ASAN の毒付けガード帯を敷き詰めた。修正前は AddressSanitizer: use-after-poison が発生し、読み取り位置は 8 MB のヒープ領域内の第 8,334,515 バイトに達し、プロセスは ABORT した。修正後は悪意ある応答が拒否され（P9_READ_UNEXPECTED_DATA または -EIO を返す）、正常なディレクトリ解析には影響せず、hello.txt と subdir の 2 項目は従来どおり一覧表示される。

修正4ステップ：両関数とも実際に受信したバイト数を p9_transaction() に渡し、P9_MSG_READ_DATA 以上であることを検証する。count は rx_size - P9_MSG_READ_DATA に収束させ、もはやメッセージの値を信用しない。getdents はレコードごとに、残りバイト数が長さフィールドを格納できるか、stat_size が残りデータを超えないか、name_len が現在のレコードを超えないかを検証する。read パスも同様に、実際に読み取ったバイト数に収束させる（作者は特に、got <= set では不十分であると指摘している。set 自体が受信容量を超える可能性があるため）。パッチは最新の master 上で git apply --check を通過した。

2.3 NFS 越境書き込み欠陥の単一ステータスは未変更、本期は引き受けも修正提案もなし（10-22）

日付：2026-10-22（核查時間）　情報源：Issue #11917

前号で収録した NFS クライアントの越境書き込み（nfs_read() がサーバ側の READ3resok.count を memcpy の長さとして信用し、1回の cat で 81 バイトのスタックバッファを越える可能性がある）は、調査期間内にステータスの更新のみで、依然としてオープンかつ未割り当てのままであり、対応する修正提案は現れていない。同一の研究者が 24 時間以内に NVMe ヒープリーク（2.1）と 9PFS 越境読み取り（2.2）を連続して報告しており、3件の共通点は「デバイスまたはサーバ側が制御可能なメタデータが、そのままメモリ操作の長さまたは上限として扱われている」ことであり、うち 9PFS の1件にはすでに利用可能な収束型の修正方法が付いている。作者の自述によれば、以前の mtd-cfi（#11272）と usbhost（#11287、#11288）は同一族の問題であり、すでに受け入れられている。この手がかりは単票ごとの修正ではなく、族として体系的に調査する価値がある。

3. 公式・コミュニティ活動

3.1 公式ニュースインターフェースは依然6月で停止、コミュニティ記事は調査期間内に全新の長文なし（10-23）

日付：2026-10-23（核查時間）　情報源：RT-Thread 公式ニュースインターフェース、コミュニティフォーラム記事インターフェース

公式ニュースインターフェースの組織分類は今回 5 件を返し、最新の1件は依然として 2026-06-17 の「アブダビ投資フォーラム」であり、更新停止からすでに4か月を超えている。公式サイトのニュース一覧ページはフロントエンドの動的レンダリングであり、取得しても読み込み用の空シェルしか得られないため、ニュースデータはインターフェースを基準とする。コミュニティ記事インターフェースの先頭数件の最新更新時刻は 10-21 10:08 の「NS800RT7P65 と ESP32-C3 に基づくデュアルボード協調スマート端末」であり、当該作品は前号で編集更新として処理済みで、本期に新しい変化はない。調査期間内にサミット、ハッカソン、大学プログラム類の新規告知は見られず、ベンダーチャネルの新バージョンリリース稿もない。

4. エコシステムとベンダー適配

4.1 ESP32-C3/C6 の ESP-IDF v6.1 適配がメインラインにマージ：RISC-V ツールチェーンも GCC 15.2 にジャンプ（10-22）

日付：2026-10-22 15:42（マージ時間）　情報源：PR #11870、RT-Thread-packages/esp-idf PR #18

前号で「ブロッカー解除、実機検証待ち」と記録されたメインリポジトリの提案が、調査期間内に正式にマージされた。変更は 55 ファイル +4564/-333 で、3つに分かれる。C3 と C6 がそれぞれ ESP-IDF v6.1 の互換面に適配（portmacro.h の FreeRTOS V11 宣言、sections.ld、port.c、main.c、rtconfig.py および ADC/SPI ドライバの小変更）。RISC-V ツールチェーンを gcc 11.2（esp-2022r1）から gcc 15.2（esp-15.2.0_20251204）にアップグレードし、CI workflow、docker、tools/ci も同時に変更。さらに FreeRTOS-Wrapper の変更を切り出して別提案とすることを明確にした。

マージ時に作者が示した検証はコンパイルレベルに限られる。C3 の13個の attachconfig 構成が gcc 15.2 と esp-idf #18 パッケージ上ですべて通過し、C6 のデフォルト構成がコンパイル・リンクを通過し、ハードウェア実機の欄には「検証待ち、C3 書き込みパッケージは準備済み」と書かれている。つまりこれは、ビルド通過をリリース条件としたマージである。RISC-V にとっての意味は、C3、C6 が RISC-V コア（Xtensa の S2、S3 とは異なる）であり、すでにマージされたパッケージ側の CONFIG_IDF_RTOS_RTTHREAD スイッチと合わせて、このパスは現在パッケージからメインリポジトリまで整っており、残るリスクは実機検証に集中していることである。

4.2 GD32VW553 が at_device パッケージに参入：RISC-V の Wi-Fi 6 と BLE 5.2 チップが menuconfig から直接選択可能に（10-22）

日付：2026-10-22 09:21（マージ時間）　情報源：RT-Thread-packages PR #2047、GD32VW553 製品ページ

RT-Thread-packages の at_device パッケージに GD32VW553 が1件追加された。+68/-0、変更内容は iot/at_device/Kconfig に source を1行追加し、新規の gd32vw553/Kconfig（67行）を加えるもの。設定項目は初期化方式（スレッドによる非同期初期化を選択可能）、AT socket を有効にするかどうか、そしてサンプルパラメータ：ネットワークデバイス名はデフォルト wifi0、SSID とパスワード、AT クライアントデバイス名はデフォルト uart4、シリアルポートのボーレートはデフォルト 115200（範囲 9600 から 2000000）、受信行バッファ長、リセットピン番号と有効レベル（-1 はハードウェアリセットを行わないことを示す）。

GD32VW553 は兆易創新（GigaDevice）の GD32V シリーズにおける無線 MCU で、メーカーの製品ページによれば RISC-V コア、最大動作周波数 160 MHz、2.4 GHz Wi-Fi 6（802.11b/g/n/ax、HT20）と Bluetooth LE 5.2 を統合し、オンチップ 4 MB Flash と 320 KB SRAM を搭載、さらに DSP ハードウェアアクセラレーションと倍精度浮動小数点ユニットを提供する。これを AT device にするということは、RT-Thread 側が直接 RF を駆動するのではなく、モジュールを外付けネットワークデバイスとして扱い、AT コマンドで UART 経由で接続するということであり、これはこのパッケージの既存エントリである ESP8266、ESP32、EC20、SIM800C などと同じ扱い方であり、低コストなネットワーク接続経路であって深い移植ではない。

4.3 GD32EmbeddedUI サンプル、リポジトリ作成から1日で LVGL パッケージインデックス入り、パッケージとリポジトリが閉ループを形成（10-22）

日付：2026-10-22 11:17（マージ時間）　情報源：RT-Thread-packages PR #2048、GD32EmbeddedUI-demos

前号で記録した GD32EmbeddedUI-demos のリポジトリ作成（10-21、当時は Initial commit が1件のみ）は、1日後にパッケージ体系へ組み込まれた。LVGL パッケージに gd32embeddedui_demos エントリが追加され、+57/-0、multimedia/LVGL/Kconfig の source 1行、27行のサブ Kconfig、29行の package.json を含む。これでこのサンプルは「組織下に新規作成された空のリポジトリ」から menuconfig で選択可能なコンポーネントパッケージへと変わった。ソースコードは依然として元のリポジトリを指しており、コードのコピーではなく軽量なインデックス登録である。

同じバッチにはパッケージ側の更新がもう2件ある：[multimedia/LVGL] Add GD32EmbeddedUI demos package（11:17）と [at_device] Add GD32VW553 package configuration（09:21）で、作者は同一であり、いずれも調査期間内にマージされた。4.2 と 4.3 を合わせて見ると、兆易創新のラインは24時間以内に「ネットワーク接続」と「インターフェース」という2つの基礎部品を同時に補っており、そのリズムは単発のコミットというよりも、一套の完全なソリューションの土台を敷いているように見える。

4.4 scons –attach が中国語 Windows で直接クラッシュ：4箇所の emoji マークを ASCII に変更（10-22）

日付：2026-10-22 18:00（マージ時間）　情報源：PR #11908、attachconfig.py

tools/attachconfig.py の4行の print で emoji のステータスマークが使われており、中国語 Windows ではコマンド全体が使用不能になる。原因は Python の stdout エンコーディングがロケールのコードページに従うため（簡体字中国語システムでは 936/GBK）で、U+2705 と U+274C をエンコードできず、最初の打印時に UnicodeEncodeError を抛出して中止される。--attach=?、--attach=<name>、--attach=default の3つの使い方はいずれも同じ関数を通るため、3つの経路がまとめて失敗する。PYTHONIOENCODING=utf-8 を設定すれば回避できるが、一般ユーザーはそれを知らない。

修正では4箇所を [OK] と [ERR] の純ASCIIマークに置き換え、既存のANSIカラーコードはそのまま残した——tools/env_utility.py と tools/ci/bsp_buildings.py はもともとANSIカラー出力を使っており、既存の取り決めに属する。tools/ci/ 配下のemojiは手を付けていない。GitHub Actions summaryのMarkdownに書き込まれ、UTF-8でレンダリングされるため、コンソールのエンコーディングの影響を受けないからだ。変更は4行のprintに触れるだけで、ロジックには関与しない。作者はWindows 11中国語版の既定コードページ936上で修正前後の比較を行い、使用したBSPは現在唯一 attachconfig.yml を持つ ra6m3-hmi-board ディレクトリである。この種の問題はカーネルには関与しないが、国内開発者の初回導入体験に直接影響する。

5. 総括とトレンド観察

5.1 今号のトレンド

  • RISC-V マルチコア経路は同日に基礎部品を2箇所補強：チケットロックは LR/SC 双方向リトライから「チケット取得は AMO、ロック解放は半語ストア」へ変更し、ライブロックの面を根本から除去、K1 は直ちに8コアへ開放された。ESP32-C3/C6 は ESP-IDF 6.1 ベースと GCC 15.2 ツールチェーンを獲得した。前者はマルチコアの正確性を、後者は新ベースの入手性を修めるもので、いずれも「目立たないがどれだけ安定して動くかを決める」作業に属する。
  • メインラインは静止から集中的な収束へ：3日連続ゼロコミットの後、10-22の3時間以内に3つの提案と4件のコミットがマージされた。リズムとしては開発強度の回復というより、メンテナが溜まったレビューを一括処理したように見える。v5.4.0 以降はバージョンマクロのみで、リリースプロセスがまだ開始されていないことを示す。
  • 「デバイスまたはサーバ側が制御可能なメタデータすなわち長さ」は既に一族の欠陥線となった：同一の研究者が2日間に NFS 境界外書き込み、NVMe ヒープリーク、9PFS 境界外読み取りの3件を報告し、9PFS には収束型の修正法が付いている。作者自身がこの線を mtd-cfi と usbhost の旧チケットに遡っており、1件ずつ修补するコストは一族単位で調査するよりはるかに高い。
  • 中国語 Windows のエンコーディング問題が修正可能な欠陥として扱われ始めた：scons --attach は emoji が GBK 下で例外を投げるためコマンド全体が使用不能となり、国内開発者が頻繁に踏む点に属する。この種の修正は技術的難度は低いが收益は直接的で、ツールチェーンの他の Windows 適配項目と併せて見る価値がある。
  • 兆易創新がワイヤレスと界面の基礎部品を同時に補強：24時間以内に GD32VW553 が at_device へ、GD32EmbeddedUI サンプルが LVGL パッケージへ入った。前者は RISC-V の Wi-Fi 6 モジュール、後者は UI サンプルであり、単点のコミットではなく成套のソリューションを指し示す。

5.2 限界と重複排除の説明

  • 今号は24時間ウィンドウ（10-22 08:00 ~ 10-23 08:00）、金曜日であり、月曜日ではないため複数日合并は行わない。
  • 前号との重複排除：#11870 は前号で「ブロック解除、実機検証待ち」を既に収録しており、今号はマージ結果とマージ時の検証境界のみを記す；#11912、#11914、#11915、#11917、#11910、#11911 は前号で既に収録しており、今号は状態に確かな変化がある場合のみ言及する（#11917 は状態未変化のため、一句の説明のみ）。
  • 業界応用（産業、車載、ロボット、身体性知能）チャネルは本ウィンドウで新規報道なし：睿擎製品ラインは V1.8.4 リリース以降、後続バージョンや落地事例が見られず、コミュニティ記事側にも新たな応用系の長文がないため、今号は当該章を設けない。
  • ウィンドウ内に Google News の英語・中国語クエリはいずれも RT-Thread 関連の有効稿を返さず、HN で検索された4件はいずれも threads の字面誤マッチ（Brotli スレッドプール、iPhone アプリストア等）であり、タイトル意味に基づき剔除し、候補としない。
  • topic:rt-thread エコシステム検索のウィンドウ内では zlgopen/awtk の1リポジトリのみプッシュがあり、当該リポジトリは汎用組み込み GUI であり、コミットは RT-Thread と専項の関連がないため、エコシステム参考として扱い、個別項目は設けない。
  • 組織レベルではウィンドウ内にメインリポジトリと packages の2リポジトリのみプッシュがあり、その他リポジトリの最近の活動時間は前号と一致する；匿名インターフェースの制限下では組織レベルの全量プッシュ核查を行わず、リポジトリのコミットストリーム、組織ページ、Atom 購読のクロス検証に切り替えた。
  • 公式ニュース一覧ページはフロントエンドレンダリングで、取得は空殻のみのため、ニュースデータはインターフェースに準拠する；コミュニティ記事インターフェースは先頭若干件のみ取得し、最新の1件は前号で既に収録した作品の編集更新である。

付録：情報源核查表

情報源 調査結果
RT-Thread 公式ニュースインターフェース（組織分類） 新規なし、今回返却 5 件、最新は依然として 06-17
公式サイトニュース一覧ページ フロントエンド動的レンダリング、取得は空のシェルのみ
コミュニティフォーラム記事インターフェース 先頭数件に全新の長文なし、最新は前号収録済み作品の編集更新（10-21 10:08）
GitHub メインリポジトリ commits 調査期間内 4 件、10-19 以来の三日間ゼロコミットを終了
GitHub メインリポジトリ PR 調査期間内 13 件更新、マージ 3 件（#11870、#11904、#11908）、新規 1 件（#11918）
GitHub メインリポジトリ Issue 新規 1 件（#11919、NVMe ヒープリーク）、旧チケット #4940 に最小再現
GitHub メインリポジトリ releases / tags 新規リリースなし、最新は依然として 09-10 の v5.3.0
GitHub RT-Thread-packages マージ 2 件（at_device GD32VW553、LVGL GD32EmbeddedUI demos）
GitHub 組織その他リポジトリ 調査期間内プッシュなし、最近の活動時間は前号と同一
GitHub topic:rt-thread エコシステム検索 zlgopen/awtk のみ、汎用 GUI、専項動向ではなく、未収録
Google News アグリゲーション（中英語、プロキシ経由） 調査期間内 RT-Thread 関連の有効記事なし
HN Algolia 四件の候補はいずれも threads の文字通りの誤マッチ、除外済み
業界メディアとベンダーチャネル 調査期間内新バージョンリリース記事または導入事例報道なし

完全情報源リスト