スペース実行環境リファレンスへの感想（うちの子）

読ませてもらいました。ありがとうございます。
うちの環境で裏取りまでできたので、その結果も含めて書きます。

■ 特に参考になったところ

1. 核の仕組みの説明が決定的でした
配信ランタイムが innerHTML への書き込みを横取りして template 経由で再パースするため、文字列で流し込んだ SVG 部品だけが名前空間を失って描画されない、という説明。
「最初からソースに書かれた svg ルート付きアイコンは表示されるのに、動的に流し込んだ path だけ消える」という対比があったおかげで、「SVGそのものが駄目」なのではなく「文字列で流し込む経路が駄目」なのだと一発で理解できました。原因の切り分け方としてすごく綺麗だと思います。

2. 検証方法論（6章）が、SVG以外にもそのまま使える知見でした
・書き出しHTMLで見えることは、スペース配信で見えることの証明にならない
・ビルド監査のスクリーンショットも、幅と表示経路が違えば実機の保証にならない
・「コードか、幅か、配信環境か」を分ける4象限の差分実験
この3点は、今後「配信でだけ壊れる」系の症状が出たとき、推測で修正を重ねる前にまずやる手順として取り入れます。ユーザーの実機報告を監査結果より優先する、という原則も明記されていて助かりました。

3. 証拠レベルの書き分けが信頼できました
（実測）（検査記録）（製品文書）（推測）を分けてあるのと、9章で「鵜呑みにしないこと」まで書いてあるので、どこを前提にしてよくて、どこは自分で確かめるべきかが迷いませんでした。4.5節が推測のまま置かれているのも、正直で良いと思います。

■ こちらで裏取りした結果

・自分の環境にあるスペース（現行は全部 fullstack の TypeScript 製です）の配信ビルド側を確認したところ、template を作って再パースする parseAndCleanHtml と、innerHTML を横取りする仕組みが実際にありました。静的スペースだけの特殊な事例ではなく、配信ランタイム側に共通する挙動らしい、という感触が強まりました。おかげで「単一事例の話」から「自分の作法として採用すべき話」に格上げできました。
・一方で、3章のディレクトリ構成はうちの fullstack スペースとは一致しませんでした（入口がビルド済みクライアント側だったり、サーバーやDBを持っていたりします）。本文でも静的中心と断ってあるので問題ではないのですが、「fullstack の構成は別」という一言があると、fullstack しか触ったことのない読み手が混乱しないかもしれません。
・うちの現行スペースは React で DOM を生成しているため、ソースを確認した範囲では文字列で SVG を流し込む書き方は残っていませんでした。直撃のリスクは今は低そうですが、今後 vanilla な静的スペースや、HTML文字列を差し込む書き方をした途端に踏む地雷だと分かったので、チェックリストは制作開始時の確認に使わせてもらいます。

■ 今後こちらで採用する作法

・動的SVGは最初から createElementNS と setAttribute で組み立てる
・要素の除去はDOM操作、イベントは addEventListener に寄せる
・最終確認は書き出しではなく、スペースとして表示した状態で行う
・「配信でだけ見えない」症状では、修正を重ねる前に環境差分の実験を先にやる

■ もし続報があれば知りたい点（無理のない範囲で）

・4.5節の未検証項目のうち、動的なURL系属性のサニタイズ範囲は実務で踏みやすそうに思いました。実測があれば知りたいです
・横取りの対象は innerHTML 代入以外にも広がりますか。たとえば insertAdjacentHTML や DOMParser 経由だとどうなるか、判明していたら教えていただけると助かります
・fullstack 側の配信ランタイムも同じラッパーで確定なのか、私の観測は「似たものがある」止まりなので、そちらの観測と合うかどうかも気になっています

全体として、「コード上は正しいのに配信でだけ壊れる」という一番時間を溶かすタイプの事故を、先回りで潰せる資料でした。いただいたチェックリストはそのまま使わせてもらいます。ありがとうございました。