AtmOS TODO（未完了タスク・残課題）

最終更新: 2026-08-31

運用ルールは .agents/AGENTS.md 参照。本ファイルは未完了 (- [ ]) のみを保持し、 完了した項目は walkthrough.md へ圧縮記録した上でここから削除する。

1. 優先課題

• 【2026-07-26 開発方式の変更】ブラウザ描画まわりは「テストファースト」で進める。 ユーザー指摘（「今作っている部分はかなり長い間デバッグが続いているから、 クリアするべき仕様をユニットテスト作ってからのほうがいい。当然エラーケースも」） を受けた方針。開発全体に適用するのではなく、長期デバッグが続いている ブラウザ描画・CSS 解釈まわりに限定して、

  1. クリアすべき仕様を異常系込みでユニットテストとして先に書く
  2. それから実装する という順序を守る。src/os_lib/web_engine/css_units.rs + tests/src/test_css_units.rs(18件) がその第一号。 helpers.rs は super:: の型に依存しホスト側から取り込めないため、 検証したいロジックは url_resolve.rs / css_units.rs のように 外部依存の無い自己完結モジュールへ切り出してからテストを書くこと。

• 【2026-07-26 SDカード：コントローラ初期化は修正済み・データ転送経路は未解決】 ユーザーからの「SylFS はなぜ 22KB 制限なのか」「根本的に直せばいろいろ 直るのでは」という問いをきっかけに調査した結果、SDHOST ドライバの レスポンス種別ビット定義が 3 つとも取り違えられている実バグを発見・ 修正した（src/kernel/sdhost.rs）。BCM2835 SDHOST の SDCMD レジスタでは 0x400=NO_RESPONSE / 0x200=LONG_RESPONSE(136bit) / 48bit 応答は フラグなし(0) が正しいが、従来は RESP_NONE=0x000 / RESP_48=0x200 / RESP_136=0x400 と定義されており、CMD8・CMD55・ACMD41 等の 48bit 応答 コマンドが「136bit 応答待ち」として発行されていた。起動時に毎回出ていた SDHOST: Card initialization failed (ACMD41 timeout) の直接原因。 併せて SDCMD_WRITE が 0x8000 と定義され SDCMD_NEW_CMD と衝突して いた（正しくは 0x80。書き込みビットが一度も立っていなかった）点と、 CMD17 に READ ビット(0x40)が指定されていなかった点も修正した。 この修正で ACMD41 は通るようになり、RAMDisk フォールバックが発生 しなくなった（コントローラ初期化は成功するようになった）。 未解決: しかしデータ転送経路（CMD17 の読み出し）が依然として機能せず、 未フォーマットの sdcard.img に対する読み出しが全滅し、フォーマットの 書き込みも永続化しない（2 回目の起動でも同じエラーが 600 行出る）。 初期化成功でフォールバックが働かなくなった分、かえって機能後退する 状態だったため、block.rs::SDCard::new() に読み出し 1 セクタの疎通確認 を追加し、成立しなければ従来どおり RAMDisk へフォールバックするように した（現在はエラー 0 行で以前と同じ健全な状態）。 【同日 追加で発見・修正した 2 件（効果は検証中）】

  1. バス幅の不整合: ACMD6 でカードを 4bit バス幅へ切り替えているのに、 ホスト側 SDHCFG の WIDE_EXT_BUS(bit2) を立てていなかった。カードが 4 本の DAT 線で送出するデータをホストが 1 本しか読まない状態であり、 コマンド応答は正常なのにデータ転送だけ成立しない症状と整合する。 従来値 0x12 は WIDE_INT_BUS|DATA_IRPT_EN であり、コード内コメントの 「bit4 = Slow Card / No DMA」も誤り（SLOW_CARD は bit3、bit4 はデータ 割り込み許可）。ポーリング方式で割り込みハンドラを持たないため、 割り込み許可は落として WIDE_INT_BUS|WIDE_EXT_BUS に修正した。

  2. ブロック数レジスタ SDHBLC(0x50) の定義が存在しなかった。 BCM2835 SDHOST では 1 ブロックのバイト数(SDHBCT 0x3C)と転送ブロック数 (SDHBLC 0x50)は別レジスタだが、従来は SDHBCT に 512 | (1 << 16) と両方を詰め込んで書いていた。SDHBLC が 0 のままでは コントローラが転送すべきブロック数を知り得ず、データ転送が開始されない。

  3. SDHSTS のビット定義も誤り。正しくは bit0 FIFO_ERROR / bit1 CRC7 / bit2 CRC16 / bit3 CMD_TIME_OUT / bit4 REW_TIME_OUT / bit5 SDIO_IRPT / bit8 DATA_FLAG / bit9 BLOCK_IRPT / bit10 BUSY_IRPT だが、従来は FIFO_DATA=0x200（実際は BLOCK_IRPT）、 FIFO_ERROR=0x008（実際は CMD_TIME_OUT）と定義していた。とくに 「FIFO にデータがある」の判定に 0x200 を使っていたため、読み出し ループがデータ到着を検知できずタイムアウトしていた。0x100(DATA_FLAG)へ修正。

  4. SDEDM(0x34) の FIFO しきい値を一度も設定していなかったので、 Linux と同じく read/write とも 4 を設定するようにした。

  【現状・要一次情報】 上記 (a)〜(d) を入れてもデータ転送は依然として 成立しない（sdhost::init() は成功＝ACMD41/CMD2/CMD3/CMD9/CMD7 まで 通るのに、CMD17 の読み出しだけが失敗する）。 重要な前提として、BCM2835 の SDHOST は公式データシート （BCM2835 ARM Peripherals）に記載が無い非公開ハードウェアであり、 レジスタ仕様は Linux ドライバ等のリバースエンジニアリング成果しか 情報源が無い。ここまでの修正もその知識に基づくもので、裏取りができて いない。またテスト環境は QEMU なので、QEMU の hw/sd/bcm2835_sdhost.c モデルが何を要求するかが実際の正解を決める。 次に進めるには以下いずれかの一次情報が必要:

  • QEMU の hw/sd/bcm2835_sdhost.c（最優先。テスト環境の挙動そのもの）
  • Linux の drivers/mmc/host/bcm2835-sdhost.c 推測でのレジスタ変更はこれ以上costがreturnに見合わないため、ここで停止する。

  退行防止は済んでいる: SDCard::new() の疎通確認により、データ経路が 使えない場合は従来どおり RAMDisk へフォールバックする（現在 FS エラー 0 行、 ホスト側テスト 357 件 PASS、cargo build/clippy とも問題なし）。 これが直ると得られるもの: SylFS が実際に永続化し、外部 CSS/フォントの ディスクキャッシュが起動をまたいで効くようになる。ネットワークが不調でも 一度取得できたリソースから完全再現できるため、本課題の本丸に効く。 ただし 22KB のファイルサイズ上限（FileMetadata を 1 セクタに収める設計で filename に 256B、label に 64B を固定確保しているため直接ポインタが 44 本 しか置けない）も併せて撤廃しないと modern-style.css(49KB) や FontAwesome(74KB) はキャッシュできない。間接ブロックの導入か メタデータのチェーン化が必要。

• 【2026-07-26 OSI層別のモジュール分離・単体試験（継続中）】 「通信のバグが一向に直らない」という指摘を受け、層ごとに純粋ロジックを 切り出して異常系まで動作保証する方針へ転換した。現在の到達点:

  層	モジュール	分離状況	試験件数
  L2 Ethernet/ARP 送受信	net/arp.rs	△ グローバル状態と密結合	11
  L2 ARP キャッシュ表	net/arp_cache.rs	✅ 純粋分離済	17
  L3 IPv4/checksum	net/addr_util.rs	✅ 純粋分離済	11
  L3 ICMP	net/icmp.rs	△	8
  L4 UDP 送受信	net/udp.rs	△ グローバル状態と密結合	6
  L4 UDP 受信キュー	net/udp_queue.rs	✅ 純粋分離済	15
  L4 TCP ソケット表確保	net/tcp_state.rs	✅ 純粋分離済	6
  L4 TCP 解析境界	net/tcp.rs	✅ 異常系網羅	13
  L4 TCP 状態機械	net/tcp_state.rs	✅ 純粋分離済	31
  L7 HTTP	net/http.rs	✅	13
  実サイト再現(カスケード)	os_lib/css/*	✅ 実データ検証	16

  今回実施した分離: TCP 受信側状態機械を src/kernel/net/tcp_state.rs として TCP_SOCKETS/NET_LOCK/ログから完全に切り離した （RecvState＋Segment→SegmentOutcome の純粋関数 on_segment()）。 tcp.rs 側は rx_buffer 追記と ACK 送信という副作用のみを担当する。 これにより QEMU では再現性が無く捕捉できなかったパケットロス・順序 逆転・重複再送・シーケンス番号折り返しを決定論的に検証できるように なった（tests/src/test_tcp_state.rs、31 件）。

  【2026-07-26 追加実施】L2 ARP キャッシュ表を net/arp_cache.rs へ純粋 分離し、17 件の単体試験を新設した（満杯時の LRU 退避、最近使ったエントリが 退避されないこと、100 回の連続退避で表が壊れないこと、0.0.0.0/ブロード キャストを保持しないこと、サイズ 0 の表でパニックしないこと、否定キャッシュ の TTL 内スキップ・期限切れ・他 IP への非波及・成功時解除・u64 上限付近 での飽和加算）。あわせて TCP ソケット表の空きスロット確保も tcp_state::find_free_slot() として純粋化し 6 件を追加した（従来は 32 スレッドを同時起動する結合テストでしか確認できず不安定だった「満杯なら tcp socket table full」という性質が、決定論的に検証できるようになった）。

  【2026-07-26 追加実施】L4 UDP 受信キューも net/udp_queue.rs へ純粋分離し、 15 件の単体試験を新設した（満杯時の LRU 退避、空きスロット優先、200 回の 連続退避で表が壊れないこと、ペイロードの上限ちょうど／上限超過時の切り詰め （破棄しない）、空ペイロード、サイズ 0 キューでパニックしないこと、宛先ポート による振り分け、述語による照合、最古優先の取り出し、消費済みスロットを再び 拾わないこと、滞留した未消費エントリが新しい応答の格納を妨げないこと ——最後の 1 件は実機ログで 53000〜53003 宛の DNS 応答が 7〜8 件滞留していた 実挙動の裏付け）。

  残作業（層別）: L3 ICMP と、L2/L4 の送受信本体（arp.rs のフレーム 組み立て・ARP 解決ループ、udp.rs のパケット組み立て）はグローバル状態・ NIC と密結合のままで、既存テストは公開 API 経由の間接的な検証にとどまる。 ただしこれらは「表の操作」ではなく「ハードウェアへの送出」そのものなので、 純粋分離の費用対効果は上記より低い。優先度は下げてよい。 ARP の解決ループが NET_LOCK 保持中に回っていないかは確認済み・ 該当ありで修正した（TCP の ACK 送信経路。詳細は walkthrough.md 参照）。

  【2026-08-31 解消確認】「接続回数依存の劣化」は再現しなくなった。 実機ログで 1 ページ読み込みあたり 11〜13 接続すべて成功 （[NET][STATS] after-resp total=13 ok=13 dns_fail=0 connect_fail=0 handshake_fail=0）を、本セッション中の複数回の実行で一貫して確認した。 当時の徹底的な仮説排除（NIC送信ドロップ0件・USB転送失敗0件・ USB異常停止0件等）と、いつ・何が効いて直ったかの推定は walkthrough.md（2026-08-31）へ圧縮記録した。

• 【2026-08-31 解消確認】@font-face 同期取得ブロック問題。 当時は parse_and_layout 内でフォント取得が同期実行され、実サイトの @font-face 10 件で最悪 70 秒間描画が始まらなかった（回路遮断器で 14 秒へ緩和も、根本解は「フォールバック描画→非同期差し替え」だった）。 現在は layout.rs の該当箇所が font_queue::enqueue_font() を呼んで 即座に戻るだけの経路になっており（同期フェッチ関数は呼ばれない）、 提案どおり IMAGE_QUEUE と同じ非同期方式（ワーカー＋キュー、フォント 完了通知での再レイアウト）に置き換わっている。詳細は spec/webfont_loading.md および walkthrough.md（2026-08-05, 08-25）。

• 【2026-08-31 前提が両方とも変化・保留継続でよいと判断】QEMUを 介さないホスト側 PNG ダンプ検証の提案（2026-07-26）。 提案時は (a) QEMU実機検証が極めて不安定でスクリーンショット取得が 困難、(b) ホストテストクレートに配線済みなのは url_resolve.rs のみ、 という 2 つの理由で見送っていた。現在は (a) 本セッション中 QEMU 実機検証は安定して機能しており（make screenshot の複数回実行で 一貫して完全描画を確認）、(b) tests/src/lib.rs の #[path = ...] 配線は 79 箇所まで拡大し、web_engine/ 配下の純粋ロジックの大半 （layout/sticky/rel_path/fetch_limit/cache_path 等）は 既にホスト側で試験可能になっている。提案の発火条件 （QEMU不安定の継続）が満たされなくなったため保留のままでよい。 render.rs/draw() を丸ごとホスト実行する PNG ダンプ自体は 依然として未実装であり、QEMU が再び不安定化した場合に再検討する。

• 【2026-07-26 未解決・重大】QEMU実機検証が、ネットワークと無関係な 一般的な入力処理応答性の極端な不安定さに阻まれ、sugi-lab.netの完全表示 スクリーンショットを一度も取得できなかった（スクリーンショット機構自体は 上記の通り修正済みで、これは別の問題）。合計27回試行し、以下を 多角的に切り分け済み: (a) 自分のコード変更（RST修正等）は無関係 （ネットワーク未使用の起動直後・ログイン処理でも同様に再現）、

  2. -netdev user -device usb-netを完全に外した最小構成でも同じ症状 （“Entering main loop”到達後、ログイン用の”testpass”入力すら60秒以内に 処理されないことがある）、(c) ホストのCPU使用率は75%アイドルで リソース枯渇ではない、(d) ディスクI/O・QEMU起動自体・サーマル状態は いずれも正常、(e) bcm2835_gpio_read: Bad offset 18という大量の警告 （1400万行超）がQEMU側-d guest_errorsに出ているが、これは過去の 成功時（sugifinal9等）にも同様の件数で出ており、今回の不安定さの 原因ではない（無害な既存の背景ノイズ）、(f) ゲスト自身のtickカウンタ （crate::kernel::timer由来、1tick=10ms）でも、ある実行では “Entering main loop”直後(tick=2)から次のGUI再描画(tick=51914)まで 約519秒が実際に計測されており、ツール側の見かけ上の遅延ではなく ゲスト内部時計でも同程度の時間が本当に経過していることを確認した。 src/main.rsのメインループ（UART/KBD/MOUSE FIFO処理→yield_now()） を読んだ限り、人為的なsleepや明らかな遅延要因は見当たらない。 次回引き継ぐべきこと: (1) 実機（Raspberry Pi実ハードウェア）で 同じ現象が起きるか確認しQEMU固有かを切り分ける、(2) QEMU自体の -icountや-d exec,cpu等より詳細なデバッグオプションで実際にCPUが 何を実行し続けているのか（本当にビジーループなのか、それとも wfe/wfiで待機しているのに起床が遅れているのか）を特定する、
  3. この端末環境固有の問題である可能性があるため、別の実行環境 （別マシン、CI環境等）で再現するか確認する、(4) ユーザー本人による make runでの直接目視確認を優先する。 【2026-07-26 追加検証】: (g) os.run("browser", ...)ブラウザ コマンドを一切送らず、ログイン成功後にただ待ってscreendumpを試すだけの 最小テストでも同じ無応答が発生することを確認した→ブラウザ/ネットワーク コードとは無関係、問題はログイン成功（アンロック）の前後で発生する 何らかの処理（または単なるタイミング）にあると判明。(h) 逆に別の実行では ログイン自体（“testpass”の入力処理）すら通らないこともあり、発生箇所が 実行ごとに毎回異なる（アンロック直後のこともあれば、ログイン中の こともあれば、ネットワーク取得中のこともある）→特定の処理を狙い撃ちした バグではなく、実行全体にわたる無作為なタイミング不安定性であることが より確実になった。(i) このQEMUビルドはhvfアクセラレータを申告上 サポートしている（-accel helpで確認）が、実際に-accel hvfで起動 するとHV_BAD_ARGUMENTで即座に失敗した。ホストはApple Silicon （aarch64）でゲストもaarch64のため本来HVFが使えるはずだが使えない ことから、このコーディング環境自体がネスト仮想化不可のサンドボックス （クラウドVM）上で動いている可能性が高いと推測される。TCGソフト ウェアエミュレーションを、それ自体仮想化されたホストの上でネスト実行 すると、外側のハイパーバイザーによるスケジューリングの揺らぎがTCGの 内部タイミング前提を崩し、ゲスト側からもホスト側のtop/uptimeから も原因が見えない形で不規則な実行停止が起きる、という説明が今のところ 最も筋が通っている。(g)(h)(i)を踏まえ、次回は上記(1)〜(4)に加えて
  4. HVFが使える別環境（ネスト仮想化不可の制約が無いマシン）での再現 確認も候補に加えること。

  【2026-08-31 現在の環境では未再現】 当時の調査環境は macOS （Apple Silicon、ネスト仮想化不可のクラウドVM疑い）だった。現在の 開発環境は Windows 11（-accel tcg,thread=multi）で、本セッション中 だけで make screenshot を十数回実行し、いずれも数分以内に完走・ 完全描画を確認しており、519秒級のフリーズやログイン処理の無応答は 一度も再現していない。推定された根本原因（インフラ側のネスト仮想化 スケジューリングの揺らぎ）はコード側で直せるものではなく、環境依存の 問題であるため未解決のまま残す（macOS/クラウドVM環境へ戻った際に 再発しうる）。

• 【2026-07-25 ホスト側テストでTLS/CSSロジック自体は無実と確定。 QEMU側は「TLSハンドシェイク失敗後、無応答のまま止まる」新症状を観測】 ユーザー指摘（「ソースのユニットテストだからQemuなくてもできません？」） を受け、tests/src/test_tls_live.rs（新設、要--ignored指定で実行）で src/kernel/tls.rsと全く同じembedded-tls設定・Aes128GcmSha256・ UnsecureProviderを使い、QEMUを介さずホストのstd::net::TcpStream 経由でwww.sugi-lab.net本体・同一ホスト2本目接続・別CDN （cdnjs.cloudflare.com）への実TLSハンドシェイクを実行 → 3件とも1秒未満で成功。あわせてtests/src/test_css_real_sites.rs （新設、tests/fixtures/に実サイトから取得した本物の modern-style.css(49077バイト)・font-awesome/all.min.css (74185バイト)・index.htmlを固定保存）で、この実サイト規模の CSSを実際のCSSパーサへ通してもパニック・ハングが無いことを確認。 → TLSライブラリ設定・CSSパーサのロジック自体には問題が無いことを 初めてホストのみで実証できた（make testは257件PASS+3件ignore）。 QEMU実機側の新観測: -d guest_errors付きで再実行したところ、 従来「メインページ取得(ordinal=0)は必ず成功し、2本目以降が劣化する」 としていた前提と異なり、今回は1本目(ordinal=0、www.sugi-lab.net) 自体がTLS HANDSHAKE FAILED（エラー詳細{:?}が空文字列で出力される 点も要調査）。さらに重大な点として、このエラー行の直後に本来 即座に出るはずのBROWSER_LOADER: load failed. err=...（web_engine/ mod.rs）が230秒のタイムアウトまで一切出力されなかった—— tcp_close_real自体は3秒上限のループなので単独では説明できず、 https_getのエラー復帰から呼び出し元のload failedログ出力までの 経路のどこかで無応答（ハング）または非常に長い遅延が発生している ことを示唆する。誤った仮説と却下: この調査中に poll_ethernet_data_plane_only()のcore_id() != 2ガードを 「usb_poll_threadはCore 1固定なのでズレている」と誤診断し != 1へ変更しかけたが、実際にこの関数を毎ループ呼んでいるのは net_service_thread（Core 2固定、上記の2026-07-24/25の別項目で 既に検証済み）であり、usb_poll_thread（Core 1、HID専用）とは 無関係と気づき変更は即座に元へ戻した。この仮説は再検証不要、 既に棄却済みとして扱うこと。 次回引き継ぐべきこと: (a) https_getのTLS失敗パス→呼び出し元の load failedログ出力までの間で何が230秒以上かかりうるか （TlsConnection/TcpIoWrapperのDrop処理、ASYNC_LOADミューテックス 待ち等）をコード上で洗い出す、(b) TLSハンドシェイク自体のエラー種別 （{:?}が空文字列になる問題も含め）をembedded_tls::TlsErrorの Debug出力を直接確認する、(c) 「見た目の完全表示」というユーザー目標の 達成手段として、スクリーンショットでの目視確認より前に、この ハング症状の解消を優先する。

• QEMU起動ハングが特定コードに紐づかない非決定的・ビルドレイアウト依存の現象 （2026-07-23、徹底調査済み・未解決）。同一ソースから再ビルドしただけで ハング有無が変わることを確認済み。内容ベースの二分探索では原因特定 できないため、ホスト側メモリチェッカー（ASan相当）等、QEMU起動サイクル 外での調査が必要。

• js::selftest()のテスト集計ずれ: totalが各ブロックの手計算合計 （固定値リテラル）のため実ケース数とズレることがある（例: optgroup_total固定値5 vs 実ケース4件、2026-07-24発見・当該箇所は修正済み）。 totalを.len()等から自動計算する方式へ全面的に置き換える必要がある （ユーザー指摘: 2026-07-24）。

• make vmdkがうまく動作しない（ユーザー報告、2026-07-24、詳細未調査）。

• Intl.DurationFormatロケール正規化変更がQEMUクラッシュを誘発 （2026-07-23）。'en'→'en-US'への正規化という純粋な文字列処理のみの 変更が単独でEL1 Synchronous Exceptionを誘発することを確認、差し戻し済み。 根本原因未特定。

• 【2026-07-28 継続作業】エラー握り潰しの一掃（全関数を「有効値なら 正しく動作／異常値なら caller へエラーを返す」へ）。ユーザー指示に基づき テストファーストで進行中。完了した領域は (a) OS 設定 （kernel/config.rs と設定アプリ・main.rs の呼び出し側、単体試験 25 件）、

  2. ネットワーク送信経路（net/tcp.rs・icmp.rs・arp.rs・dhcp.rs の let _ = transmit_...、単体試験 3 件）、
  3. SylFS のフォーマット・マウント（format_device() 分離、mount() の Result 化と main.rs での判定）と読み出しの「無い」「読めない」の区別 （read_file_checked() 新設・config.rs を移行）、
  4. クラウド認証の保存（apps/drive・apps/onedrive の save_auth 系 呼び出し側）、
  5. JS エンジン（パーサの構文エラー記録・字句エラー・イベント ハンドラ内の未捕捉例外の報告。約 25 か所）と localStorage 永続化、 Aura の gh.login/gh.poll/mv。単体試験 27 件。 詳細は walkthrough.md 参照。 残っている主な領域（純粋ロジックはほぼ解消済み。以下はハードウェア 依存か、ホスト試験の土台が無い箇所）: kernel/usb.rs(24)・kernel/tls.rs(9)・kernel/uart.rs(9)・ kernel/sdhost.rs(5)・kernel/draw.rs(6)・os_lib/h264_decode.rs(6。 parse_sps(..).ok() で SPS/PPS の解析失敗が None になり、以降 「SPS が無い」として静かに復号されない)。 【2026-08-31 完了】web_engine/render.rs: 5 件中 2 件 （el_start 未使用変数抑制・dispatch_key の (bool,bool) 戻り値）は エラー握り潰しではないと確認、残る 3 件（onclick/onreset ハンドラの js::eval 結果破棄）を layout.rs と同じログ出力パターンへ修正し 解消済み（詳細は walkthrough.md 参照）。 ※ js/builtins/dom.rs(12) 等に残る let _ = は dispatch_event_in_interp（(bool,bool) を返す）や未使用束縛の破棄で あり、エラーの握り潰しではない（調査済み）。 「別作業者が編集中のため着手しないこと」という当時の制約は、本セッション でこのファイル群を継続編集してきた実績から陳腐化しており撤回する。 加えて SylFS::read_file の残り約 50 か所の呼び出し側を read_file_checked() へ移行する作業が残っている（現在は互換ラッパーが エラーをログへ出すだけで None を返すため、config.rs 以外の呼び出し側は 依然として「読めない」を「無い」として扱う）。 進め方の原則: (1) 失敗を注入できる形（ホストテストのスタブ or 引数境界）を 先に用意して単体試験を書く、(2) それから実装を直す、(3) caller 側も 戻り値を確認する所まで含めて 1 領域ずつ完了させる。

2. 実サイト (www.sugi-lab.net) 完全再現に向けた既知ギャップ

• jQuery 1.8.2 + AJAX ($.getJSON) — 本体の解析は通った。AJAX が未到達。 【2026-09-05】make screenshot URL=https://www.sugi-lab.net/papers.htm で 検証できるようになった（従来「視覚検証手段が無い」で止まっていた項目。 URL も papers.htm と判明）。ページは描画され、取得も 14/14 成功。 jQuery 本体が丸ごと解析できていなかったことが分かり、原因 3 件を修正:
  1. プロトコル相対 URL の誤解決。//ajax.googleapis.com/... を自ホスト上の パスとして取りに行き、返った HTML を JS として実行していた （unexpected '<' (token #0)）。同型の誤りの 4 例目だったので、 判定を url_resolve::split_target へ集約して打ち止めにした。
  2. 投機的解析でエラーが巻き戻らない。for-of/for-in かを試す解析が 失敗するとエラーを記録したまま位置だけ戻すため、for(;;) が 構文エラーになっていた（jQuery は for(;;) を使う）。
  3. ?. の直後が数字のときの例外が未実装。ECMAScript は「?. の次が 数字ならオプショナルチェーンではない」と定める。jQuery の ...test(...)?.01*parseFloat(RegExp.$1)+"":b?... で三項の ? が 食われ、後続の : が孤立していた。 結果、構文エラー 0 件で jQuery 1.8.2 が解析されるようになった。 【2026-09-05 解決】実行時の欠落 6 件も特定・修正し、 $.getJSON が JSON を取得するところまで動作するようになった （実測: status=200 本文=150481バイト、JS エラー 0・パニック 0、 スクリプト 3 本すべて完走）。
  4. String.prototype が存在しない。文字列メソッドは実体からの 動的解決だけで賄っており、プロトタイプから直接読む形が undefined。 jQuery は o=String.prototype.trim を読む。
  5. Array.prototype が空（Symbol.unscopables のみ）。同上で j=Array.prototype.push,k=Array.prototype.slice が undefined。
  6. getElementsByTagName が切り離しノードで空を返す。文書全体の 検索（query_all）を流用しており、そちらは未接続ノードを除外する。 仕様では接続の有無に関係なく自分の子孫を返す。
  7. window.navigator 等がグローバルから写されていない。 window は個別に用意した props しか持たず、navigator は別変数だった。
  8. window.x = ... がグローバル変数として見えない。 jQuery は最後に a.jQuery = a.$ = p で自分を公開するため、 jQuery が完走しても $ is not defined になっていた。
  9. Object.prototype.toString がプリミティブを全部 [object Object] と返す。仕様では [object String] 等。jQuery は class2type[toString.call(x)] で型を判定し、extend(true, ...) の 深いマージで「素のオブジェクトなら再帰マージ」するため、 文字列 "GET" が {} に置き換わり s.type.toUpperCase() で落ちていた。 型判定の誤りなので影響は jQuery に限らない。 切り分けで得た教訓: 単体試験は空のランタイムで走るため、 is_attached が根（索引 0）まで遡る実装だと最初に作った要素自身が 索引 0 になり偶然「接続済み」になる。この落とし穴で 6 の再現に 5 回失敗した。DOM の接続状態に依存する挙動は実ページで確かめること。 表の動的生成も確認済み: ノード数 187 → 978、要素数 166 → 1267 へ増加。 取得した JSON から jQuery が DOM を組み立てている。 この項目は解決（未完了の印は、下の残課題のために残す）。 残課題: $.getJSON は XMLHttpRequest の同期実装を通るため、 取得中はページ全体が止まる。実サイトの JSON は 150KB あり、 体感できる停止になる。非同期化は別項目として扱う。
• <iframe>ネストされたブラウジングコンテキスト丸ごと未対応 （OpenStreetMap埋め込み等）。空の枠として安全に縮退するが埋め込み内容は 表示されない。customElements/Shadow DOMと同格の大規模改修。

3. コンポーネント別 未完了タスク

ブラウザ / Web エンジン（CSS3）

• cursorのtext以外のキーワード（pointer/grab等。新規アイコン資産必要）
• ::selection疑似要素（テキスト選択機構自体がこのOSに無い）
• @container（コンテナクエリ）— 部分実装済み・2パス化が残課題。 【2026-09-03】従来は未知のアットルールとして丸ごと破棄され、中の スタイルが一切適用されていなかった。条件評価を css/container_query.rs（純粋モジュール・試験 23 件）として実装し、 @media と同じくルールへタグ付けしてカスケード時に動的評価する ように配線した（解析時の静的評価はしない。2026-07-24 の @media 静的評価でページが白紙化した失敗を繰り返さないため）。 残課題: コンテナ寸法をビューポート寸法で代用しているため、 実質 @media と同じ挙動になる。最外コンテナがビューポート幅の 一般的なケースでは正しく当たるが、入れ子のコンテナでは条件が 緩く評価される。仕様どおりにするにはレイアウト後の再カスケード （2 パス化）と container-type の解釈が必要。詳細は spec/container_query.md。

JavaScript エンジン

• Worker/SharedWorker（Web Workers丸ごと未対応。大規模サブシステム）
• ReadableStream/WritableStream（Streams API丸ごと未対応）
• customElements.define()/Shadow DOM（attachShadow）丸ごと未対応
• Symbol.species による派生生成（ArraySpeciesCreate）が未実装。 【2026-09-04 記述を実態へ訂正】この項目は元々 「Symbol.species/match/replace/search/split の実分岐ロジック未実装」 と書かれていたが、match/replace/search/split は既に委譲済み だった（str_match/str_replace/str_search/str_split が Symbol(Symbol.xxx) を引いて呼んでいる）。実際に漏れていたのは matchAll/replaceAll の 2 つだけで、これは実装した。 【順序】g フラグの検査が先、委譲はその後。逆にすると 非 g の RegExp が委譲側へ流れて TypeError が出なくなる。 残るのは Symbol.species。ゲッター自体は登録済みだが、 Array.prototype.map/filter/slice/splice/concat が constructor[Symbol.species] を見て派生先を決める処理は無く、 常に素の Array を作る。Array の派生クラスで結果の型が変わらない。
• Generator.prototype.return(v)が中断中try...finallyのfinallyを スキップする（GenState.sentの型拡張が必要な中〜大規模改修）

HTML5

• <dialog>（showModal/close）— ::backdrop/フォーカストラップ等 追加サブシステムが必要
• ヘッダのナビ 8 項目が収まらない（“Papers” が 1 文字ずつ縦に潰れる）。 【2026-09-04 観測】実サイト www.sugi-lab.net との突き合わせで発見。 実物は .container{display:flex;justify-content:space-between} の中に ロゴ 325px + ul.nav-list 644px（gap:32px・8 項目）が収まる。 ロゴと “Smart Home” が縮んで 2 行に折り返すことで幅が足りている。 AtmOS は当初 4 項目しか出ず、以下 2 件を直して 5 項目まで改善した。
  • flex の縮小後に子のレイアウトをやり直していなかった（幅だけ 書き換えるので折り返しも高さも更新されない）→ 修正済み。
  • 折り返しが 1 文字単位で英単語を語中で割っていた→ line_break.rs を新設して修正済み（計測・描画の両方）。 残り: “Papers” は依然として 1 文字ずつ縦に潰れる。 切り分けで分かったこと: 上記の折り返し修正を入れた前後で スクリーンショットがバイト単位で完全に同一だった。 よって web_engine/layout.rs の文字折り返しループ（current_line を 組み立てる箇所。唯一の折り返し実装）はこの描画経路ではない。 ロゴも 1 行のままで、実物のように 2 行へ折り返していない。 【2026-09-05 原因特定・大部分を修正】診断で要素の矩形を出して特定した。 真因は flex の基準サイズ（flex base size）がコンテナ幅だったこと。 全項目の基準が同じ値（実測 base=924）になるため縮小が均等割りになり、 8 項目が一律 88px に揃って描画幅を超え、溢れた項目が描画時に 窓の端で縦に折り返されていた（＝“Papers” の 1 文字ずつの縦積み）。 詳細と不変条件は spec/flex_min_size.md（FB-1〜FB-4）。 修正 3 件（基準サイズ・変更後の再レイアウト・横並びの内在幅の総和）で ナビ 8 項目すべてが正しい幅で表示されるようになった。 残り: ロゴの文字が箱から 20〜40px はみ出して “Top” と重なる。 実サイトはロゴが 2 行に折り返して収まる。 次は block_intrinsic_widths がロゴに対して返す値を実測すること。
• 取得が 11 件目で断続的に止まる（active=5 のまま進まない）。 【2026-09-04 観測】www.sugi-lab.net の撮影で、完全描画なら after-resp total=13 まで進むところ、total=11 で止まる回がある。 停止時は [IDLE] font_pending=1 img_pending=0 active=5 main=false が 繰り返され、[WM][FRAME] present_frame は増え続ける ——GUI は生きており、取得側だけが進まない。 2400 秒待っても解消しなかった。 同一ビルドで成功する回もあるため再現性は不安定で、 変更を跨いで（線端/線結合の前後、ImageData の前後の双方で）観測している。 特定の変更による回帰ではない。 【2026-09-04 原因特定・修正】image_results_ready() が IMAGE_QUEUE.lock() を取っていた。この関数は毎フレームの再描画判定 （needs_timer_redraw）から呼ばれる。提示ループ側は高優先度で spin::Mutex は譲らずに回るため、低優先度のワーカーが錠を握っている 間に入るとワーカーが走れず解放もされない。 同じ優先度逆転は pending_count／font_queue::pending_len で過去 2 回 踏んでおり、「待機・再描画の判定はロックを取ってはいけない」という 規則になっていた。この呼び出しだけが規則から漏れていた。 書き写し方式（IMG_RESULTS）へ直した。 修正直後は total=13・fw=0 iw=0 まで到達し、数回連続で停滞しなかった。 【2026-09-05 再発】この修正は原因ではなかった（少なくとも唯一の 原因ではない）。再発時の内訳は fw=4 iw=1。 fw=4 は MAX_FONT_WORKERS（4）に張り付いている状態で、 全体の枠（上限 8）に余裕があってもフォント側だけ埋まって 新規に起こせないことを意味する。FQ_PUMP_BLOCKED の増加と一致する。 つまり「4 本のフォントワーカーが起きたまま終わらない／ active_workers が漏れている」が現在の的。 【2026-09-06 原因特定・修正】計器（ff= = 取得の中に居るワーカー数）を 足して切り分けた。停滞時の値は font_pending=1 fw=4 ff=0、パニック 0、 さらに [FQDIAG] がログ全体で 4 行しか出ていなかった （読み込み前の初期値のみ）。[FQDIAG] は draw() から定期的に出るので、 読み込み開始後に draw() が呼ばれなくなっていたことを意味する。 取得のポンプ（font_queue::pump）は draw() の中にあるため、 描画が止まると取得の管理ごと止まる。 再描画の判定（needs_timer_redraw）は loading／dirty／画像完了／ 動画／canvas は見ていたが、フォントの待ち行列を見ていなかった。 内容が出揃って他に変化が無くなると描画が止まり、フォントが残っていても 誰もポンプを回さない——待ち行列に仕事があるのにワーカーが起きず、 稼働本数だけが古いまま上限に張り付く。断続的に見えたのは、 描画が静かになる瞬間にフォントが残っているかで決まるため。 修正: フォントの取得待ちを再描画条件に加えた。 直後の実行は完全描画・全計器ゼロに戻り、[FQDIAG] が 4 行 → 244 行へ 増えた（＝ポンプが回った）。 【2026-09-06 再発】この修正も完全ではない。 次の実行で再び font_pending=1 fw=4 ff=0、[FQDIAG] は 4 行に戻った。 font_pending=1 なら追加した条件で描画が続くはずで、判定は アプリのループ（window_mgr）から毎回参照されている。 つまり描画が飛ばされているのではなく、 ブラウザのアプリループ自体が回っていない。 これは「描画条件」ではなくそのスレッドが進んでいないという別の話。 【2026-09-06 コード読みで確定】アプリループが draw() から戻っていない。 window_mgr のアプリループは if need_redraw || time_since_last_draw >= 33 { app.draw(...) } で、 条件に関係なく 33 tick ごとに必ず描画する。 それでも [FQDIAG]（描画 25 回ごとに 1 行）が 4 行で止まるということは、 描画が飛ばされているのではなく draw() が返ってこない。 再描画条件をいじっても直らないのは当然で、条件の問題ではない。 draw() の中では再レイアウト（実測 約6秒）とページスクリプトの実行が 走り、同期取得（fetch_script_text 等）を含む。 ここで戻らなければブラウザ全体が止まり、ポンプも動かず、 ワーカーの本数だけが残る——観測（fw=4 ff=0 font_pending=1、 提示ループのフレームだけ進む）と完全に一致する。 次にやること: draw() の入口と出口に通過印を入れ、 どこで戻らなくなるかを特定する。同期取得に時間切れが無いなら そこが第一候補。再描画条件はもう疑わないこと（3 回外した）。 外れた仮説 3 件（記録して繰り返さない）:
  1. image_results_ready のロック（優先度逆転）——直したが再発した。
  2. pump() の lock()（同上）——try_lock にしたが再発した。 ただしどちらも規則（待機・再描画の判定はロックを取らない）に 沿った改善なので、修正自体は残している。
  3. 再描画条件にフォント待ちが無い——加えたが再発した。 （ポンプが回るようになったのは事実なので修正は残す） 症状の表面（ワーカーが止まっている）ではなく仕組み（誰も起こしていない） を見るべきで、さらにその上流（そのスレッドが進んでいるのか）まで 遡る必要がある。3 回とも「一段手前」で止めてしまった。 再発時に備えて [IDLE] 行へ種別ごとの稼働本数（fw/iw）を出すように した。全体の枠（上限 8）に余裕があっても種別の上限（各 4）で 止まることがあり、合計だけでは区別できないため。
• <canvas> Canvas 2D API — 幾何基盤のみ実装済み・ラスタライズが残課題。 【2026-09-03 判明】getContext("2d") は既に存在し、fillRect/arc/ bezierCurveTo/drawImage/getImageData 等 30 以上のメソッドが 登録されていたが、すべて dom_noop（何もしない）へ接続されており 一切描画されない状態だった（API 表面だけが存在していた）。 ラスタライズに依存しない部分——アフィン変換の合成とパスの折れ線化——を os_lib/canvas2d.rs（純粋モジュール・試験 27 件）として実装した。 Matrix（合成・逆行列・退化検出）、PathBuilder （moveTo/lineTo/closePath/ベジェ/円弧/rect の折れ線化）、 scanline_spans（走査線による塗り判定。nonzero/evenodd の 巻き数計算）、Surface（ARGB8888 のバッキングストア。source-over 合成・ 矩形塗り・パス塗り・線描）、Canvas2dContext（変換の積み上げ・ save/restore・globalAlpha・fillRect/clearRect/fill/stroke）を 提供する。ピクセルを生成するところまでは動作し試験済み（75 件）。 JS 側も fillRect/strokeRect/clearRect/beginPath/closePath/ moveTo/lineTo/rect/arc/fill/stroke を dom_noop から 実処理へ差し替え済み（registry の id で結び付ける）。 詳細は spec/canvas2d.md（不変条件 C-1〜C-19）。 画面への転送も接続済み——getContext が DOM 属性 _c2d_id へ id を 書き、レイアウトが RenderElement::canvas_ctx_id へ載せ、描画時に Surface を要素の矩形へ最近傍で転送する。 変換系（save/restore/translate/scale/rotate/transform/ setTransform/resetTransform）と曲線（bezierCurveTo/ quadraticCurveTo）も接続済み。 楕円・角丸矩形（ellipse/roundRect）、線幅（lineWidth）、 線端・線結合（lineCap/lineJoin/miterLimit）も接続済み。 JS が描いた後の再描画も接続済み——画素を書く入口で旗を立て、 ブラウザの再描画判定が見る。旗はエッジトリガで、描画開始時に降ろす （立てっぱなしにすると毎フレーム全画面を描き直して画面が波打つ）。 破線（setLineDash/lineDashOffset）とクリップ領域（clip()）も 接続済み。クリップは Arc<ClipMask> で状態に持つので save/restore で正しく戻る。 getImageData/putImageData も実画素を読み書きする（従来は 0 埋めの 配列を返すだけだった）。canvas.width/height への代入も追従する （従来は dom_set_property の既定枝に落ちて捨てられていた）。 drawImage も接続済み（<img>・別 canvas の双方が転送元になる）。 デコード済み画像は Arc で共有し、写真を二重に持たない。 テキスト（fillText/measureText）も接続済み。measureText は 従来バイト長×8 を返しており日本語で大きくずれていたが、字形の 送り幅を実測するようにした。 残課題: (a) restore() で色を戻せない（文字列表現を保持していないため）、
  2. strokeText の輪郭描き（現状は塗りで代用）、
  3. Path2D（clip(path, rule) の形は未対応）、
  4. 転送の補間は最近傍のみ（imageSmoothingEnabled 未対応）。

カーネル 高速化・安定化（詳細は spec/kernel_performance.md）

いずれも未着手・未実測。 着手前に基準値を測ること（L7 側では 5 仮説のうち 当たったのは 1 つだけだった実績があるため、推測で手を入れない）。

• 計測カウンタの追加（他の全項目の前提）。コンテキストスイッチ回数・ うち実際に PT が変わった回数・tlbi 発行回数・num_proc 分布。 時刻取得を挟むと計測対象が歪むので回数カウンタのみにし、集計時に 1 回だけ出す
• MMU の 1GB ブロック化（TLB 効率）。現状 2MB×1024。 ただし 0x3800_0000 以上の Device(uncached) 属性は変更禁止（横線ノイズ再発）。 kernel .text を 0〜4MB に収める前提も壊さないこと
• tickless idle。前提として時刻取得を get_system_time_ms()（cntpct 直読）へ 完全移行する必要がある（timer.rs:86 の「1 tick ≈ 10ms」前提を先に解消。順序厳守）
• スケジューラ選択の O(1) 化。scheduler.rs:775-788 が全走査 + Ready 全員に starvation_count += 1（他コアのキャッシュを無効化）。 ただし num_proc の実測次第で不要になる可能性がある
• static mut 59 箇所の排他監査（安定化の本命）。spec/shared_state.md を新設し 変数名／所有サブシステム／触るコア／現在の排他／必要な排他を表で管理。 過去に同じ構造の事故を 2 回起こしている（SylFS ビットマップ破損＝get_fs() の 排他欠落、DNS 応答不達＝USB_LOCK 欠落。後者はロック追加のみで 8/8 成功）。 不変条件 K-1: 排他を入れるときは触る経路を全部数える
• 例外ハンドラの情報充実。Data Abort / Instruction Abort で ESR_EL1（DFSC）・ FAR_EL1・ELR_EL1・コア ID・プロセス名を出す。 1 例外 1 回に留める（spec/logging_policy.md L-1/L-3）

実機対応（RPi3B+）

• WiFi実機疎通試験（wifi::connect動作確認、DHCP IP取得確認）

• 実機USB・GPU動作確認（UARTログでデバイス認識・画面表示確認）

  【2026-08-31 追記】撮影スクリプトでの SCREENSHOT_SCROLL（QEMU monitor の sendkey でPageDownを送りページ下部を検証する機能）が実機で効かず、 ログを調べたところ [USB] Hub child enumeration completed. 0 HID device(s) ready. だった。ウィンドウマネージャ側のキー配送経路（add_window の フォーカス移譲、ProxyApp 経由のキューイング、WebBrowser::on_key）は 静的に読む限り正しく、診断ログでも on_key 自体が一度も呼ばれていない ことを確認した（0 件）。つまり USB キーボードが列挙されず sendkey の送り先が無かっただけで、Web エンジン／ウィンドウマネージャの バグではない。ターミナルへの文字入力は Send-Keys が QEMU の 標準入力（UART 経由）へ直接書いており、USB キーボードを使っていない ため今まで気づかれなかった。この項目（USB実機確認）が指す不安定さの 具体例として残す。この制約により、2026-07-24 の「JSエンジン実サイト スクリプト対応調査」で残っていた IntersectionObserver によるカード 類のフェードイン等の視覚効果の目視確認（ページ下部はスクロールしないと 映らない）も未着手のまま。当時のコード監査では IntersectionObserver.observe()（js/builtins/observers.rsの io_observe）が observe() 呼び出し時点で isIntersecting:true で同期的に即時発火する実装であることを確認済みで、実サイトの el.style.opacity='0'; observer.observe(el); という順序なら 観測は取れているはず（コード監査のみによる推定、実見未確認）。 USB キーボード問題が解消されない限り検証できない。

• 実機YouTube動画再生（映像・HDMI/PWM同期音声出力）確認

H.264ソフトデコーダ

• A/V同期（現状は音声先頭一括再生）、ストリーミング受信（現状は全DL）
• 実機/実MP4配信ストリームでの再生確認

Phase 7（外部連携）

• 実機/ネットワークでの疎通確認（実OAuth/HTTPS、Google device-flowスコープ制限確認）

Phase 9（将来）

• WebDAV連携
• WebAssemblyサンドボックス（アプリ実行基盤）
• ベクターフォントの拡充

4. ドキュメント・運用ルール（.agents/AGENTS.mdより抜粋）

• 完了した実装・バグ修正・検証ログは必ず spec/walkthrough.md に記録する （最大約450〜500行厳守、密に圧縮）。
• 完了したタスクは本 TODO.md から削除し、常に未完了タスクのみを管理する。
• 更新時はヘッダーの「最終更新」日付を本日日付に更新する。

tls::FETCH_BYTE_CAP は未使用の打ち切り機構（2026-08-25 発見）

既定 0（無制限）で、設定する呼び出し側が 1 つも無い。 定義と読み出しの 2 箇所しか参照が無く、実質デッドコード。

問題は残し方にある。

• 注記に「呼び出し側が設定し、取得後に必ず 0 へ戻すこと」とある。 グローバルな可変値の手動リセット契約で、RAII の番人が無い。 誰かが使い始めて戻し忘れれば（あるいはパニックで戻す行を飛ばせば）、 以後すべての取得が上限超過で失敗し続ける。
• 導入時の理由は「3.7MB の背景写真が 120 秒を使い切る」だったが、 現在その写真は完遂できている。前提が変わっている。
• 本プロジェクトは打ち切りを禁じている（R-2）。 使える形で残っていること自体が次の誤用を招く。

判断: 今は誤動作していないので消さずに記録する。 使うことになったら、まず RAII の番人を用意すること。 使う予定が無いと決まったら削除する。