← トップへ戻るBack to index

Page Update History

Page Update History

このページは、公開サイト側で何をどう更新したかを、旧記述 → 新記述 → 根拠 → 影響ページの順で残すための監査ログです。

This page is an audit log for public-site changes, recorded in the order old wording → new wording → rationale → affected pages.

vega-hbmx-pages Public update audit log Updated: 2026-03-20
研究ノート本体は日々進む一方で、公開ページは「何をどの表現で外に出したか」を後から辿れる必要があります。このログでは、単なる changelog ではなく、古い説明が何で、何に置き換えたのかを明示します。 The lab notebook evolves quickly, while the public pages need a traceable record of what was exposed and how it was phrased. This log is more than a changelog: it explicitly records what the old public wording was and what replaced it.

このログの読み方

How to read this log

1. 旧記述

1. Old public state

更新前にページ上でどう説明していたか。代表的な文面や、止まっていた時点を短く抜粋します。

How the public page described the point before the update. Representative wording or the frozen state is excerpted briefly.

2. 新記述

2. New public state

更新後に何へ差し替えたか。新しい知見に沿う表現へ変わった要点を記録します。

What replaced it after the update. The key wording changes are logged in the form actually reflected in public pages.

3. 根拠

3. Rationale

内部ノートや実機ログのどの知見を受けて修正したかを添えます。公開表現の出所を見失わないためです。

The underlying notebook/log evidence is listed so the public wording can always be traced back to its source.

更新ログ

Update log

convint8 CLI surface の narrowing を public 側へ同期

Synced the convint8 CLI-surface narrowing into the public pages

2026-03-20

INT8 section は、direct `y=int32` route が API レベルでは通る一方で、installed `MIOpenDriver convint8` の cast-aware path は別 problem だと整理できていた。ただ、CLI 自体が direct route をどう見せているかは public 側でまだ曖昧だった。今回の更新では、installed `convint8` が cast-type flag を見せる一方で direct output-dtype option は obvious には expose しておらず、`--out_data_type int32` は unknown option、`--out_cast_type int32` は parse 段階で reject されることを追記した。

The INT8 section had already established that the direct `y=int32` route does work at the API level while the installed `MIOpenDriver convint8` cast-aware path is a different problem. What was still fuzzy publicly was how the CLI itself exposes that route. This update adds that the installed `convint8` shows cast-type flags but does not obviously expose a direct output-dtype option; `--out_data_type int32` is an unknown option and `--out_cast_type int32` is rejected at parse time.

solver-trace.html README.md

solver-trace.html

旧記述

Old

public 側では、installed driver の cast-aware path が direct `y=int32` route の代替ではないことまでは書かれていたが、CLI surface に direct output-dtype option が visible かどうかまでは明記していなかった。

Public wording already stated that the installed driver-side cast-aware path is not an equivalent shortcut for the direct `y=int32` route, but it did not yet say whether the CLI surface visibly exposes a direct output-dtype option.

新記述

New

`convint8` は cast-type flag を見せる一方で direct output-dtype option を obvious には expose しておらず、`--out_data_type int32` は unknown option、`--out_cast_type int32` は parse 段階で reject される、と追記した。これにより、current host で閉じて見える境界が solver/backend 不在だけでなく CLI surface にも寄ると public 側でも明示した。

The page now states that `convint8` exposes cast-type flags but not an obvious direct output-dtype option, that `--out_data_type int32` is an unknown option, and that `--out_cast_type int32` is rejected at parse time. This makes it explicit publicly that the blocked point on the current host is closer not only to solver/backend boundaries but also to the CLI surface itself.

installed MIOpenDriver provenance の narrowing を public 側へ同期

Synced the installed MIOpenDriver provenance narrowing into the public pages

2026-03-20

INT8 section は、current public standalone source と local debug `MIOpenDriver` の食い違いを build provenance の差までで説明できるようになっていたが、普段使っている installed `/opt/rocm/bin/MIOpenDriver` 自体の provenance はまだ public 側で「未確定」のままだった。今回の更新では、この host 上の installed binary が Arch package `miopen-hip 7.2.0-1` に属し、embedded path も `/usr/src/debug/miopen-hip/rocm-libraries/projects/miopen/...` を指していることを追記し、current standalone clone と 1:1 に重ねるのは安全でないと明記した。

The INT8 section had already explained that the mismatch between the current public standalone source and the local Debug `MIOpenDriver` can be narrowed by build provenance, but the provenance of the everyday installed `/opt/rocm/bin/MIOpenDriver` was still left publicly as fully unresolved. This update adds that, on this host, the installed binary belongs to the Arch package `miopen-hip 7.2.0-1` and also embeds `/usr/src/debug/miopen-hip/rocm-libraries/projects/miopen/...` paths, making it explicit that it should not be read 1:1 as the current standalone clone.

solver-trace.html README.md

solver-trace.html

旧記述

Old

local Debug `MIOpenDriver` が別 checkout `miopen-src@f842c61d` 由来であることまでは public 側に書かれていたが、installed `/opt/rocm/bin/MIOpenDriver` 自体の provenance は「ここからは断定できない」で止まっていた。

The public page already stated that the local Debug `MIOpenDriver` came from the separate checkout `miopen-src@f842c61d`, but the provenance of the installed `/opt/rocm/bin/MIOpenDriver` itself still stopped at “cannot be established from this alone.”

新記述

New

この host 上の installed binary は Arch package `miopen-hip 7.2.0-1` に属し、binary / library には `rocm-libraries/projects/miopen` 系の embedded path が残っていることを追加した。これにより、installed driver も current standalone clone の直接 build と読むより、cast-aware な `rocm-libraries/projects/miopen` family に近い packaged binary として読む方が自然だと public 側でも明記した。

The page now adds that the installed binary on this host belongs to Arch package `miopen-hip 7.2.0-1` and that both the binary and library retain `rocm-libraries/projects/miopen`-style embedded paths. This makes it explicit publicly that the installed driver is more naturally read as a packaged binary closer to a cast-aware `rocm-libraries/projects/miopen` family than as a direct build of the current standalone clone.

experiment-history / rocm-history を 2026-03-19 時点へ同期

Synced experiment-history / rocm-history to the 2026-03-19 state

2026-03-19

`solver-trace.html` には INT8 の direct `y=int32` route、cast-aware driver path、local Debug driver provenance の追補が入っていた一方、`experiment-history.html` はまだ 2026-03-15 で止まり、`rocm-history.html` も 2026-03-19 時点の注記を持っていなかった。今回の更新では、前者に INT8 route disambiguation の step 13 を追加し、後者には「これは chronology anchor の追加ではなく artifact の読み方の narrowing である」という注記を足した。

While `solver-trace.html` already carried the later INT8 addenda about the direct `y=int32` route, the cast-aware driver path, and the local Debug driver provenance, `experiment-history.html` still stopped at 2026-03-15 and `rocm-history.html` did not yet state the 2026-03-19 interpretation note. This update adds an INT8 route-disambiguation Step 13 to the former and a note to the latter explaining that the provenance follow-up narrows artifact interpretation rather than adding a new chronology anchor.

experiment-history.html rocm-history.html README.md

experiment-history.html

旧記述

Old

実験ページは Step 12（2026-03-15 の GitHub chronology / PR-context synthesis）で止まっており、その後の INT8 route narrowing は反映していなかった。

The experiment page stopped at Step 12 (the 2026-03-15 GitHub chronology / PR-context synthesis) and did not yet reflect the later INT8 route narrowing.

新記述

New

Step 13 を追加し、direct `y=int32` route、cast-aware driver path が別 problem であること、standalone INT8 GEMM backend success、local Debug `MIOpenDriver` の provenance narrowing を時系列として統合した。

Step 13 now integrates the direct `y=int32` route, the fact that the cast-aware driver path is a different problem, the standalone INT8 GEMM backend success, and the later local Debug `MIOpenDriver` provenance narrowing into the timeline.

rocm-history.html

旧記述

Old

ROCm 年表ページは 2026-03-15 時点の chronology anchor までを示していたが、2026-03-19 の INT8 provenance follow-up が chronology 追加ではないことは明記していなかった。

The ROCm history page showed chronology anchors through 2026-03-15, but it did not yet explicitly state that the 2026-03-19 INT8 provenance follow-up was not a new chronology addition.

新記述

New

更新日を 2026-03-19 に上げ、local Debug driver provenance follow-up は chronology anchor ではなく investigation artifact の読み方を狭める注記だと追記した。これにより、年表本体を不用意に膨らませずに最新の読みを反映した。

The page now marks itself updated on 2026-03-19 and adds that the local Debug driver provenance follow-up is not a chronology anchor but a narrowing note on how investigation artifacts should be read. This reflects the latest interpretation without artificially inflating the timeline itself.

INT8 local debug build provenance を public 側へ同期

Synced the INT8 local debug-build provenance into the public pages

2026-03-19

INT8 section は、current public standalone source と local debug `MIOpenDriver` の不一致を「driver-side descriptor assembly に寄る境界」として扱っていたが、cross-check に使った debug binary 自体の provenance はまだ public 側で触れていなかった。今回の更新では、local Debug `MIOpenDriver` が `ROCm-repos/MIOpen` ではなく別 checkout `miopen-src@f842c61d` からビルドされていたことを短く反映し、不一致の一部が build provenance でも説明できると明記した。

The INT8 section had already framed the mismatch as a boundary closer to driver-side descriptor assembly, but the provenance of the local debug binary used for cross-checking had not yet been stated publicly. This update adds that the local Debug `MIOpenDriver` was built not from `ROCm-repos/MIOpen` but from a separate checkout, `miopen-src@f842c61d`, making it explicit that part of the mismatch is also explained by build provenance.

solver-trace.html README.md

solver-trace.html

旧記述

Old

INT8 section は、current public source 上の direct `y=int32` route と、local / installed driver 側の cast-aware path が別 problem だ、というところまでを public 境界としていた。

The INT8 section stopped at the point where the current public direct `y=int32` route and the local/installed driver-side cast-aware path were shown to be different problems.

新記述

New

cross-check に使った local Debug `MIOpenDriver` は current public clone ではなく別 checkout `miopen-src@f842c61d` からビルドされており、その checkout 自体が cast-aware `convint8` driver path を保持していたことを追記した。これにより current source と local debug binary の不一致は、少なくとも build provenance の差でも一段説明できると明記した。

The page now adds that the local Debug `MIOpenDriver` used for cross-checking was built not from the current public clone but from a separate checkout, `miopen-src@f842c61d`, which itself still retains the cast-aware `convint8` driver path. This makes it explicit that the mismatch between the current source and the local debug binary is at least partly explained by build provenance as well.

INT8 の source-level descriptor 分岐を public 側へ同期

Synced the INT8 source-level descriptor split into the public pages

2026-03-18

direct `y=int32` probe、driver cast-flag retry、standard Find/Forward success までは public 側に出ていたが、`...INT8INT8INT32-F` と `...INT8-F_coFP32` が source-level にも別 problem として分かれている点はまだ明文化していなかった。今回の更新では、current / legacy source の比較を短く反映し、閉塞点が solver/backend 不在ではなく driver-side descriptor assembly / path provenance に寄ることを public wording でも明示した。

The public pages already reflected the direct `y=int32` probes, the driver cast-flag retry, and the standard Find/Forward success, but they had not yet stated that `...INT8INT8INT32-F` and `...INT8-F_coFP32` are also separate problems at the source level. This update adds a short current-vs-legacy source comparison and makes it explicit in the public wording that the blocked point is closer to driver-side descriptor assembly / path provenance than to solver/backend absence.

solver-trace.html README.md

solver-trace.html

旧記述

Old

INT8 section は、direct `y=int32` path が higher-level C API からも通る一方、driver cast-flag path は別 problem だ、というところまでを public 境界としていた。

The INT8 section stopped at the point where the direct `y=int32` path also worked through the higher-level C API, while the driver cast-flag path was already known to be a different problem.

新記述

New

current standalone source では INT8 route を output descriptor 自体の `miopenInt32` 化で表現し、legacy cast-aware path では INT8 tensor に cast metadata を後付けするため、`...INT8INT8INT32-F` と `...INT8-F_coFP32` は同じ route の別表記ではなく source-level にも別 problem だと追記した。

The page now adds that current standalone MIOpen expresses the INT8 route by making the output descriptor itself `miopenInt32`, while the legacy cast-aware path keeps an INT8 tensor and adds cast metadata. Therefore `...INT8INT8INT32-F` and `...INT8-F_coFP32` are not alternate spellings of the same route but separate problems at the source level as well.

INT8 の standard Find/Forward 成功を public 側へ同期

Synced the standard INT8 Find/Forward success into the public pages

2026-03-18

direct immediate だけが通る特殊経路なのか、それとも explicit `y=int32` descriptor を与えれば standard の higher-level C API でも通るのか、という境界が残っていた。今回の更新では、`FindConvolutionForwardAlgorithm + ConvolutionForward` でも GEMM が返って実行まで成功することを反映し、現在の閉塞点をさらに driver-side descriptor assembly 側へ寄せた。

One remaining boundary was whether the successful `y=int32` path was an immediate-only special case or whether the standard higher-level C API could also reach it when the INT32 output descriptor was explicit. This update reflects that `FindConvolutionForwardAlgorithm + ConvolutionForward` also reaches GEMM and runs successfully, pushing the current blocked point further toward the driver-side descriptor assembly.

solver-trace.html README.md

solver-trace.html

旧記述

Old

INT8 section は、direct `y=int32` probe は通るが、driver cast-flag path は別 problem だ、というところまでを public 境界としていた。

The INT8 section stopped at the point where direct `y=int32` probes worked, while the driver cast-flag path was shown to be a different problem.

新記述

New

standard `FindConvolutionForwardAlgorithm + ConvolutionForward` でも、explicit `y=int32` descriptor を与えれば GEMM が返って実行まで成功することを追記し、現在の閉塞点を driver/output-type path 側へさらに狭めた。

The page now adds that standard `FindConvolutionForwardAlgorithm + ConvolutionForward` also returns GEMM and runs successfully when the `y=int32` descriptor is explicit, narrowing the blocked point further toward the driver/output-type path.

INT8 cast-flag driver 境界を public 側へ同期

Synced the INT8 cast-flag driver boundary into the public pages

2026-03-18

same library への direct `y=int32` probe が通るなら、installed `MIOpenDriver convint8` の legacy-style `--out_cast_type` で近い route を踏めるかも、という残りの曖昧さがあった。今回の更新では、その曖昧さを切り落とし、cast flag は direct `y=int32` path の代替ではないことを public wording に反映した。

After the direct `y=int32` probes succeeded on the same library, one ambiguity remained: perhaps the installed legacy-style `--out_cast_type` flag in `MIOpenDriver convint8` could approximate that route. This update removes that ambiguity and reflects publicly that the cast flag is not an equivalent substitute for the direct `y=int32` path.

solver-trace.html README.md

solver-trace.html

旧記述

Old

INT8 section は、「tested `convint8` route は閉じているが、same library への direct `y=int32` probe は通る」までを public 境界としていた。

The INT8 section stopped at: the tested `convint8` route is blocked, while direct `y=int32` probes on the same library do work.

新記述

New

installed `MIOpenDriver convint8` の `--out_cast_type` は direct `y=int32` route の代替ではなく、`int32` token は reject され、`fp32` は別の `...INT8-F_coFP32` casted-tensor path になって GEMM family を拒否する、と public 側に追記した。

The page now states that installed `MIOpenDriver convint8 --out_cast_type` is not a substitute for the direct `y=int32` route: the `int32` token is rejected, while `fp32` becomes a separate `...INT8-F_coFP32` casted-tensor path that still rejects the GEMM family.

INT8 MIOpen direct immediate 成功を public 側へ同期

Synced the INT8 MIOpen direct immediate success into the public pages

2026-03-18

`convint8` tested case の `not applicable` と direct query の可視化だけで止めず、same installed MIOpen library への direct immediate probe まで public wording に反映した。新しい境界は、「`y=int32` なら `solution_id = 89` は visible で、compile / execute まで通るが、tested `convint8` route ではそこに乗っていない」である。

Rather than stopping at the `not applicable` result from the tested `convint8` case or the query-level visibility alone, the public wording now also reflects a direct immediate probe against the same installed MIOpen library. The new boundary is: `solution_id = 89` is visible when `y=int32`, and it compiles and executes there, but the tested `convint8` route does not reach it.

solver-trace.html README.md

solver-trace.html

旧記述

Old

INT8 section は direct query で `y=int32` 条件なら `solution_id = 89` が visible だが、tested `convint8` route では `not applicable` に留まるところまでを public 境界としていた。

The INT8 section stopped at the point where direct query made `solution_id = 89` visible for `y=int32`, while the tested `convint8` route still remained `not applicable`.

新記述

New

same installed MIOpen library への direct immediate probe では、`y=int32` 条件にすると `solution_id = 89` が visible になるだけでなく、`CompileSolution + ForwardImmediate` まで成功することを追加し、閉塞点を driver/output-type path 側までさらに狭めた。

The page now adds that a direct immediate probe against the same installed MIOpen library not only exposes `solution_id = 89` when `y=int32`, but also succeeds through `CompileSolution + ForwardImmediate`, narrowing the blocked point further toward the driver/output-type path.

gfx900 で standalone rocBLAS INT8 GEMM が動くことを public 側へ同期

Synced the standalone rocBLAS INT8 GEMM success on gfx900 into the public pages

2026-03-18

`GemmFwd1x1_0_1_int8` の MIOpen convolution route は tested case で閉じていたが、そこから一段切り離して `rocblas-bench -f gemm_ex` を試すと、gfx900 で INT8 GEMM backend 自体は成立することが確認できた。public 側では「candidate」「conv route」「backend standalone success」を分けて書くように更新した。

Although the MIOpen convolution route for `GemmFwd1x1_0_1_int8` stayed closed on the tested case, a separate `rocblas-bench -f gemm_ex` probe confirmed that the INT8 GEMM backend itself does run on gfx900. The public wording was updated to distinguish the source candidate, the blocked convolution route, and the standalone backend success.

solver-trace.html README.md

solver-trace.html

旧記述

Old

INT8 section は `GemmFwd1x1_0_1_int8` が tested case で `not applicable` に留まるところまでを public 境界としていた。

The INT8 section stopped at the point where `GemmFwd1x1_0_1_int8` remained `not applicable` on the tested case.

新記述

New

standalone `rocblas-bench gemm_ex` の `i8_r -> i32_r` case が gfx900 で成功することを追加し、`MIOpen conv route が閉じている` ことと `INT8 GEMM backend 自体が動かない` ことを切り離した。

The page now adds that standalone `rocblas-bench gemm_ex` cases with `i8_r -> i32_r` succeed on gfx900, separating “the MIOpen convolution route is blocked” from “the INT8 GEMM backend itself does not run.”

`GemmFwd1x1_0_1_int8` の Vega64 runtime follow-up を public 側へ同期

Synced the Vega64 runtime follow-up for `GemmFwd1x1_0_1_int8` into the public pages

2026-03-18

static candidate の段階で止めず、Vega64 の 1x1 INT8 条件で自然選択・search・forced・only-solver search を見た結果を public wording に反映した。新しい結論は「candidate は source に見えるが、今回の tested case では practical route になっていない」である。

Rather than stopping at the static candidate, the public wording was updated with the Vega64 1x1 INT8 runtime follow-up covering natural selection, search, forced execution, and only-solver search. The new boundary is: the candidate is visible in source, but it does not become a practical route on the tested case.

solver-trace.html README.md

solver-trace.html

旧記述

Old

INT8 alternative candidate は static candidate として紹介されていたが、runtime の扱いは未確認のままだった。

The INT8 alternative candidate was introduced as a static candidate, while its runtime status was still left unconfirmed.

新記述

New

Vega64 の `NCHW + INT8 + 1x1 + group=1` 条件では、自然選択と `-s 1` は `ConvDirectNaiveConvFwd` に留まり、`-S GemmFwd1x1_0_1_int8` と only-solver search はいずれも `not applicable` で止まることを追記した。

For the Vega64 `NCHW + INT8 + 1x1 + group=1` case, the page now states that natural selection and `-s 1` stay on `ConvDirectNaiveConvFwd`, while both `-S GemmFwd1x1_0_1_int8` and the only-solver search stop as `not applicable`.

根拠: `vega64_int8_gemmcand_nat_1x1_n32_c64_k64_20260318.log`、`vega64_int8_gemmcand_force_1x1_n32_c64_k64_20260318.log`、`vega64_int8_gemmcand_onlysolver_search_1x1_n32_c64_k64_20260318.log` と対応する investigation ノート。 Rationale: `vega64_int8_gemmcand_nat_1x1_n32_c64_k64_20260318.log`, `vega64_int8_gemmcand_force_1x1_n32_c64_k64_20260318.log`, `vega64_int8_gemmcand_onlysolver_search_1x1_n32_c64_k64_20260318.log`, plus the corresponding investigation notes.

INT8 alternative candidate の静的整理を `solver-trace.html` へ同期

Synced the static INT8 alternative-candidate notes into `solver-trace.html`

2026-03-18

内部ノート dp4a_alternative_path.md と solver_selection_graph.md により、INT8 まわりは「なさそう」で止めるより、「どこが candidate で、どこが fragment / gate なのか」を public 側でも書き分けられるようになった。今回は既存ページへの追記で同期し、新規ページはまだ作成していない。

After dp4a_alternative_path.md and solver_selection_graph.md, the INT8 story could be stated more precisely in public: not just “nothing was found,” but which route is the concrete candidate and which pieces remain fragments or gates. This was synced as an update to existing pages rather than a new standalone page.

solver-trace.html README.md

solver-trace.html

旧記述

Old

INT8 まわりは「自然選択では naive のみ」「dot4 命令は逆アセンブルで未検出」という説明が中心で、current public tree に見えるより狭い GEMM 系 candidate までは public 側に出していなかった。

The INT8 story centered on “natural selection yields naive only” and “no dot4 instructions were found in the disassembly,” without yet exposing the narrower GEMM-shaped candidate visible in the current public tree.

新記述

New

dp4a は current public tree の canonical naming ではないことを明記し、最も具体的な INT8 candidate を GemmFwd1x1_0_1_int8 -> CallGemm -> CallGemmMIOpenTensile / rocBLAS として追加した。あわせて、これは code_verified の静的 candidate に留まり、MLIR/CK/Tensile は依然 fragment / gate の段階だと書き分けた。

The page now states that dp4a is not the canonical naming in the current public tree and adds the most concrete INT8 candidate as GemmFwd1x1_0_1_int8 -> CallGemm -> CallGemmMIOpenTensile / rocBLAS. It also makes the boundary explicit: this remains a code_verified static candidate, while MLIR/CK/Tensile still appear only as fragments or gates.

根拠: dp4a_alternative_path.md、solver_selection_graph.md、および public source の solver/gemm.cpp / gemm_v2.cpp / conv_mlir_igemm_fwd.cpp / CK / Tensile capability table。 Rationale: dp4a_alternative_path.md, solver_selection_graph.md, and the public sources in solver/gemm.cpp, gemm_v2.cpp, conv_mlir_igemm_fwd.cpp, CK, and the Tensile capability table.

README.md

旧記述

Old

solver-trace.html は 2026-03-15 更新のままで、INT8 については naive disassembly / dot4 不在の観測が主な案内だった。

solver-trace.html was still marked as updated on 2026-03-15, and the README mainly advertised the naive disassembly / dot4-absent observation for INT8.

新記述

New

README を 2026-03-18 更新に合わせ、INT8 部分は「runtime verified な naive-only 観測」と「source 上で見える狭い GEMM 系 candidate」を分けて案内するようにした。

The README is now aligned with the 2026-03-18 update and separates the runtime-verified naive-only observation from the narrower GEMM-shaped candidate visible in source.

Mermaid 図のサイズ制御をページ横断で正規化

Normalized Mermaid sizing across pages

2026-03-15

複数ページで Mermaid 図が大きすぎたり小さすぎたりしていたため、各ページ固有の min-width ベース調整をやめ、共通 CSS と共通初期化スクリプトでサイズをそろえる方式へ切り替えた。

Because Mermaid diagrams were appearing too large on some pages and too small on others, the page-specific min-width tweaks were replaced with one shared CSS layer and one shared initialization script.

glossary.html code-tracing.html hypothesis.html reveal-hypothesis.html rocm-ecosystem.html rocm-history.html rocm-structure.html solver-trace.html linear-algebra-for-rocm.html deep-learning-for-rocm.html

Mermaid pages

旧記述

Old

多くのページで .mermaid svg { width: 100%; min-width: 700px; } のような指定を個別に持っており、小さい図が不必要に拡大される一方、別の図はページごとに見え方が揺れていた。

Many pages carried their own rules such as .mermaid svg { width: 100%; min-width: 700px; }, which forced small diagrams to enlarge unnecessarily while leaving the overall sizing inconsistent from page to page.

新記述

New

Mermaid を使うページを共通スタイル styles/mermaid-layout.css と共通初期化 scripts/mermaid-page.js に寄せ、レンダリング後に SVG の viewBox 比率を見て wide / standard / tall 相当の目標幅を自動調整するようにした。

Pages using Mermaid now share styles/mermaid-layout.css and scripts/mermaid-page.js, with the rendered SVG viewBox ratio used to auto-pick a target width closer to wide / standard / tall layouts.

根拠: 図の内容は同じでも、固定 min-width によって可読性がページごとに揺れていたため。内容は変えず、表示レイヤだけを共通化した。 Rationale: The diagram content stayed the same, but fixed min-width rules made readability unstable across pages. Only the presentation layer was unified.

`solver-trace.html` の棒グラフを共通デザインへ統一

Unified the bar-chart design in `solver-trace.html`

2026-03-15

shipped artifacts の比較図は、Mermaid の淡い色差に依存していたため、gfx900 行・比較対象・ゼロ値の読み分けがしづらかった。棒グラフを同一コンポーネントへ置き換え、ラベルと数値を常時読める形にした。

The shipped-artifact comparison figures relied on faint Mermaid palette shifts, which made it hard to distinguish the gfx900 row, comparison rows, and zero-value rows. The charts were replaced with one shared component so labels and values remain readable at all times.

solver-trace.html README.md

solver-trace.html

旧記述

Old

rocBLAS pre-compiled files by architecture、Pre-compiled Artifacts by Architecture、MIOpen Perf DB Lines の棒グラフは Mermaid の xychart を使っており、薄い色差だけでは系列の意味が追いづらかった。

The rocBLAS pre-compiled files by architecture, Pre-compiled Artifacts by Architecture, and MIOpen Perf DB Lines charts used Mermaid xychart, where faint color differences alone made the row semantics hard to follow.

新記述

New

4 つの棒グラフを同一の HTML/CSS コンポーネントへ置き換え、青 = gfx900 注目行、濃いスレート = 比較対象、ストライプ = 出荷データ 0 という共通ルールで統一した。各行にラベルと数値も固定表示した。

All four bar charts were replaced with one shared HTML/CSS component using a common rule: blue = gfx900 focus rows, dark slate = comparison rows, and striped tracks = zero shipped data. Each row now keeps its label and value visible.

根拠: 棒グラフは証拠の要約表示であり、色差が弱いままだと public 側での読み取りを阻害するため。データ自体は変えず、可読性だけを改善した。 Rationale: These bar charts summarize evidence, so weak color contrast directly hurts public readability. The underlying values were not changed; only the presentation was clarified.

ROCm 全体の構造を読む独立ページを追加

Added a standalone page for ROCm-wide structure

2026-03-15

`gfx900` を起点に見えてきた ROCm 一般の構造は、仮説ページや履歴ページに少しずつ散らすより、独立した public page としてまとめたほうが責務が明確だと判断した。GitHub 側の一次資料から読める layered stack / support の多層性 / repo topology の統合 / contribution layers を、専用ページとして公開した。

The ROCm-wide structure that became visible through the gfx900 investigation was clearer as a standalone public page than as fragments scattered across the hypothesis and history pages. A dedicated page now presents the layered stack, split meanings of support, repository-topology consolidation, and contribution layers visible from GitHub-side primary material.

rocm-structure.html index.html reveal-hypothesis.html rocm-history.html README.md

rocm-structure.html

旧記述

Old

ROCm 全体の構造に関する説明は、主に reveal-hypothesis.html の仮説要約と rocm-history.html の年表のあいだに分散しており、GitHub 側の evidence をまとめて読む専用ページはなかった。

ROCm-wide structural explanation was distributed across the hypothesis summary and the history timeline, and there was no dedicated page for reading the GitHub-side evidence as one coherent structure.

新記述

New

新規ページ rocm-structure.html を追加し、layered stack、support の意味の分離、repo consolidation、AMD と community の寄与レイヤを、Fact / Interpretation / Open Question を分けた public summary として表示できるようにした。

A new page, rocm-structure.html, now presents layered stack boundaries, split meanings of support, repository consolidation, and AMD/community contribution layers as a public summary separated into Fact / Interpretation / Open Question.

根拠: investigation note rocm-common-investigate_github.md が、ROCm 一般の構造を GitHub 側の一次資料からまとめて読める段階まで育ったため。AGENTS.md に合わせ、断定しすぎずに public へ出せる材料が揃った。 Rationale: The investigation note rocm-common-investigate_github.md matured enough to support a ROCm-wide structural reading from GitHub-side primary evidence. This provided material that could be published in AGENTS.md-compatible, non-overstated wording.

index.html / reveal-hypothesis.html / rocm-history.html / README.md

旧記述

Old

トップ導線は hypothesis → reveal-hypothesis → rocm-history を中心に組まれており、ROCm 一般の構造を独立して読む入口は見えにくかった。

The top-level route centered on hypothesis → reveal-hypothesis → rocm-history, and there was no clearly visible entry point for ROCm-wide structure as its own topic.

新記述

New

index に Structure カードを追加し、reveal-hypothesis.html と rocm-history.html の action からも新ページへ移動できるようにした。README でも収録ファイルと閲覧順に rocm-structure.html を明記した。

The index now includes a Structure card, both reveal-hypothesis.html and rocm-history.html now link into the new page, and the README now lists rocm-structure.html in both the file inventory and suggested reading order.

Markdown 側の整理に合わせて実験年表も 2026-03-15 フェーズまで拡張

Extended the experiment timeline through the 2026-03-15 GitHub-synthesis phase

2026-03-15

investigation Markdown 側で GitHub chronology / PR context / legacy repo 再編の整理が進んだため、public timeline も runtime 追試だけで止めず、歴史調査フェーズまで時系列に含めるようにした。

Once the investigation-side Markdown was reorganized around GitHub chronology, PR context, and legacy-repo consolidation, the public experiment timeline was extended so it no longer stopped at runtime follow-ups alone.

experiment-history.html index.html README.md

experiment-history.html

旧記述

Old

年表は 2026-03-14 の build / forced-MLIR 追試で止まっており、その後に確定した GitHub chronology と PR 文脈の整理は別ページでしか読めなかった。

The timeline stopped at the 2026-03-14 build/forced-MLIR follow-up, while the later GitHub chronology and PR-context synthesis could only be read on separate pages.

新記述

New

Step 12 を追加し、#1231 / #1328 / #1204 の public 文脈、retired / deprecated repo の再編、legacy knowledge の残存を、runtime / code tracing の次段として時系列に組み込んだ。footer verdict も 6 項目へ整理した。

A new Step 12 now folds in the public context of #1231, #1328, and #1204, together with retired/deprecated-repo consolidation and legacy-knowledge preservation, as the next phase after runtime/code tracing. The footer verdict was also expanded into six points.

根拠: `rocm-github-investigate.md` と `reveal_hypothesis.md` の更新により、public 側でも AGENTS.md 準拠の中立表現で歴史フェーズを載せられるだけの根拠が揃ったため。 Rationale: The updated rocm-github-investigate.md and reveal_hypothesis.md provided enough grounded material to add the history phase in AGENTS.md-compatible neutral wording.

index.html / README.md

旧記述

Old

experiment-history.html は Steps 1-11 の timeline として案内しており、トップ導線でも runtime follow-up 以降の history synthesis は見えにくかった。

experiment-history.html was described as a Steps 1-11 timeline, and the top-level route did not yet make the later history-synthesis phase visible.

新記述

New

Steps 1-12 として更新し、runtime 追試に加えて GitHub chronology / PR-context synthesis まで含む timeline だと README と index の両方で分かる説明へ修正した。

It is now described in both the README and the index as a Steps 1-12 timeline that continues beyond runtime follow-ups into GitHub chronology / PR-context synthesis.

`#1231` と `#1328` の public 文脈を公開年表へ戻した

Fed the public context of `#1231` and `#1328` back into the public timeline

2026-03-15

GitHub 上の public PR / issue 文脈を回収したことで、2021 年の 2 つの判断点を「どちらも gfx900 の後退」と雑にまとめるのではなく、性質の違う判断として公開側でも書き分けられるようになった。

Once the public PR/issue context was recovered from GitHub, the two 2021 decision points could be described on the public side not as one undifferentiated retreat, but as two different kinds of decisions.

rocm-history.html reveal-hypothesis.html

rocm-history.html

旧記述

Old

8498875ae は runtime workaround、2407d2f は MLIR disable として載せていたが、それぞれの PR / issue が public に何を示していたかまでは年表へ戻していなかった。

8498875ae appeared as a runtime workaround and 2407d2f as an MLIR disable, but the timeline did not yet feed back what their public PR/issue trails actually showed.

新記述

New

#1231 は public issue #1204 由来の COMGR target-name failure に対する defensive workaround、#1328 は private issue を根に持ちながらも public 側では ROCm 5.1 MLIR の test / tuning surface から gfx900 を外す release-engineering 判断として明示した。

#1231 is now framed as a defensive workaround for a COMGR target-name failure exposed in public issue #1204, while #1328 is framed as a release-engineering decision that removed gfx900 from the ROCm 5.1 MLIR test/tuning surface even though its root rationale still points to a private issue.

根拠: gh pr view ROCm/MIOpen#1231、gh pr view ROCm/MIOpen#1328、gh issue view ROCm/MIOpen#1204 で、body / comments / files / commits を確認したため。 Rationale: The bodies, comments, files, and commits of ROCm/MIOpen#1231, ROCm/MIOpen#1328, and issue ROCm/MIOpen#1204 were verified through GitHub CLI.

reveal-hypothesis.html

旧記述

Old

design-model 側では #1231 / #1328 の違いをまだ unresolved として残しており、「public summary へ未統合」と書いていた。

On the design-model page, the difference between #1231 and #1328 was still left unresolved, with a note saying that the public summary had not yet integrated their PR/issue context.

新記述

New

補足 note と設計モデルの箇条書きを追加し、同一 component 内でも public issue-driven workaround と private-rooted release gating が併存しうることを前面に出した。未解決欄も「未統合」ではなく「private root cause は未公開」に更新した。

An addendum note and a new design-model bullet now foreground that one component can contain both public issue-driven workarounds and private-rooted release gating. The unresolved section was updated from “not yet integrated” to “the private root cause remains non-public.”

deprecated MIOpen branch の late-phase 読みを公開側へ反映

Reflected the late-phase reading of the deprecated MIOpen branch

2026-03-15

legacy `MIOpen` clone の展開後、deprecated branch でも `gfx900` 痕跡が残っていること、そして 2024-2025 の late change が主に layout / docs 再編として現れていることが確認できた。その読みを public 側へ移した。

After expanding the legacy MIOpen clone, we confirmed that gfx900 traces still remain on the deprecated branch and that most 2024-2025 late changes appear as layout/docs reorganization. That reading was then propagated to the public pages.

rocm-history.html reveal-hypothesis.html index.html README.md

rocm-history.html

旧記述

Old

年表は retired/deprecated repo を repo topology の再編として扱っていたが、deprecated MIOpen branch で後年に見える activity が「中身変更」なのか「整理」なのかまでは切り分けていなかった。

The timeline treated retired/deprecated repos as repository-topology reorganization, but it did not yet separate whether late activity on the deprecated MIOpen branch reflected policy changes or mere cleanup.

新記述

New

8498875ae の `gfx900` workaround を年表に追加し、さらに deprecated branch activity の節で 992a835c2 / 7b36cef67 / 5e791ce2c を layout/docs 再編として位置づけた。結論も「deprecated branch 上の legacy knowledge 温存」を含む形へ更新した。

The timeline now adds the 8498875ae gfx900 workaround and introduces a deprecated-branch activity step that frames 992a835c2, 7b36cef67, and 5e791ce2c as layout/docs reorganization. The conclusion now also names legacy-knowledge preservation on deprecated branches.

根拠: `git blame` と `git log --follow` により、`gfx900` 関連行の last-touch と file move / doc migration を分離できたため。 Rationale: git blame and git log --follow made it possible to separate the last semantic touches on gfx900-related lines from later file moves and doc migrations.

reveal-hypothesis.html / index.html / README.md

旧記述

Old

design-model 側は repo-level consolidation を扱っていたが、「deprecated になってもしばらく legacy knowledge が残る」という観察までは前面に出していなかった。

The design-model side already covered repo-level consolidation, but it did not yet foreground the observation that legacy knowledge can persist for a while even after a repo becomes deprecated.

新記述

New

summary・staged retreat 仮説・index 導線・README を更新し、deprecated branch に残る workaround / docs / private-issue 参照も ROCm の staged retreat を読む材料だと分かるようにした。

The summary, staged-retreat hypothesis, index route, and README now make it clear that workarounds, docs, and private-issue references preserved on deprecated branches are also part of how ROCm's staged retreat should be read.

legacy / retired repo の再編も公開側へ反映

Reflected legacy / retired-repo reorganization on the public pages

2026-03-15

official clone に加えて legacy / retired repo 群を調査対象へ入れたことで、ROCm の歴史を arch support だけでなく repo topology の再編としても読めるようになった。その知見を公開ページ群へ反映した。

Once legacy and retired repositories were added to the source set, ROCm history became readable not only as arch-support drift but also as repository-topology reorganization. The public pages were updated to reflect that added axis.

rocm-history.html reveal-hypothesis.html index.html README.md

rocm-history.html

旧記述

Old

年表は、主に commit・release block・issue trail から見える support の変動を中心に整理していた。repo 自体の退役や移行先はまだ歴史軸に入っていなかった。

The timeline mainly organized support drift visible from commits, release blocks, and issue trails. Repository retirement and re-homing were not yet part of the public history axis.

新記述

New

ROCR-Runtime -> rocm-systems、Tensile -> rocm-libraries、ROCm/vllm -> upstream を timeline に加え、並行流にも repository-topology consolidation を追加した。暫定結論も、support policy に加えて repo 再編まで含む形へ拡張した。

ROCR-Runtime -> rocm-systems, Tensile -> rocm-libraries, and ROCm/vllm -> upstream were added to the timeline, with a new repository-topology consolidation current and a broadened provisional conclusion.

根拠: legacy / retired repo README の移行案内。arch support の後退とは別に、責務の置き場所そのものが組み替わっていることが public に読めるようになった。 Rationale: Migration guidance in the legacy/retired repo READMEs. Separate from arch-support retreat, the public record now shows that the location of responsibilities is also being reorganized.

reveal-hypothesis.html / index.html / README.md

旧記述

Old

設計モデル側は layered support と fallback を中心に説明していたが、repo 再編の信号はまだ表に出していなかった。トップ導線や README も、そこまで明示していなかった。

The design-model side explained layered support and fallback, but did not yet surface repository-reorganization signals. The top-level routes and README did not name that axis either.

新記述

New

reveal-hypothesis.html では仮説4と summary に repo-level consolidation を追加し、index.html と README でも retired repo notice や repo-level consolidation を読めるページだと分かる説明へ更新した。

reveal-hypothesis.html now adds repository-level consolidation to Hypothesis 4 and the summary, while index.html and the README now make it clear that readers will also encounter retired-repo notices and repo-level consolidation.

ROCm GitHub 履歴タイムラインを公開ページへ追加

Added a public ROCm GitHub history timeline

2026-03-15

内部ノート rocm-github-investigate.md と reveal_hypothesis.md に固定した知見を使い、ROCm の変遷を年表として読める独立ページを公開側に追加した。

Using the findings fixed in rocm-github-investigate.md and reveal_hypothesis.md, a standalone public page was added so ROCm's evolution can be read as a timeline.

rocm-history.html index.html reveal-hypothesis.html README.md

rocm-history.html

旧状態

Old

公開サイトには、ROCm 自体の GitHub 履歴を commit・release block・issue trail の混在した年表として読める独立ページがなかった。

The public site had no standalone page that turned ROCm's own GitHub history into a readable chronology mixing commits, release blocks, and issue trails.

新状態

New

新規ページ rocm-history.html を追加し、2021-12-22 の MIOpen disable、ROCm 5.5.0 / 6.2.0 / 7.0.0 block、support の層分解、front-door 統合、fallback 残存を、working chronology として公開した。

A new page, rocm-history.html, now publishes a working chronology covering the 2021-12-22 MIOpen disable, the ROCm 5.5.0 / 6.2.0 / 7.0.0 blocks, support-layer splitting, front-door consolidation, and fallback survival.

根拠: rocm-github-investigate.md の時系列整理と、reveal_hypothesis.md の ROCm-wide 読み筋。exact date と release-note anchor を混ぜることを明示し、未確定日付は埋めていない。 Rationale: The chronology in rocm-github-investigate.md and the ROCm-wide reading in reveal_hypothesis.md. The page explicitly mixes exact dates with release-note anchors and avoids inventing dates that remain unconfirmed.

index.html / reveal-hypothesis.html / README.md

旧記述

Old

ROCm 全体像ページまではあっても、歴史軸で読む導線がトップにも設計モデルページにも README にも無かった。

Even with the ROCm-wide design page in place, there was no top-level, design-page, or README route into a historical reading of ROCm itself.

新記述

New

トップに History カードを追加し、reveal-hypothesis.html の action からも年表へ移動できるようにし、README にも収録ファイルとして明記した。

A new History card was added to the index, the design-model page now links into the timeline, and the README lists it as a published file.

GitHub 側の一般設計思想調査を公開ページへ追加

Added the broader ROCm design-model investigation to the public pages

2026-03-15

内部ノート reveal_hypothesis.md と更新済み hypothesis.md を受けて、公開サイト側でも「gfx900 個別事例」から一段引いた ROCm 全体像を説明できるようにした。

After the internal note reveal_hypothesis.md and the updated hypothesis.md, the public site was expanded so it can explain not only the gfx900 incident itself, but also what it reveals about ROCm more broadly.

reveal-hypothesis.html hypothesis.html index.html README.md

reveal-hypothesis.html

旧状態

Old

公開サイトには「gfx900 の出来事から ROCm 全体の設計思想をどう読むか」をまとめた独立ページがなかった。一般化は hypothesis.html の中に散らばっていた。

The public site had no standalone page explaining what the gfx900 investigation reveals about ROCm as a whole. The broader interpretation was scattered inside hypothesis.html.

新状態

New

新規ページ reveal-hypothesis.html を追加し、layered support、capability-based fallback、staged deprecation、support の層分解、AMD とコミュニティの役割分解を、GitHub 側の一次資料つきで独立表示できるようにした。

A new page, reveal-hypothesis.html, now presents layered support, capability-based fallback, staged deprecation, support-layer splitting, and AMD/community role splitting as a standalone GitHub-grounded explainer.

根拠: reveal_hypothesis.md に固定した ROCm-wide 仮説検証。ROCm/README、CHANGELOG、TheRock issue、Tensile docs、rocBLAS fallback 実装。 Rationale: The ROCm-wide hypothesis verification fixed in reveal_hypothesis.md, grounded in the ROCm README, changelog, TheRock issues, Tensile docs, and rocBLAS fallback implementation.

hypothesis.html

旧記述

Old

仮説Cは「AMD が外したが互換設計は残り、コミュニティが運用や一部保守を支える」という線で読めたが、投入主体と維持主体と運用主体がまだ十分には分離されていなかった。

Hypothesis C could be read as “AMD removed primary support, compatibility remains, and the community supports operation and some maintenance,” but insertion, maintenance, and operation ownership were not yet clearly separated.

新記述

New

仮説Cを「保守主体は層ごとに異なる」に更新し、投入主体 / 維持主体 / 運用主体 / 修正可能主体 の4分解で public wording を整理した。さらに一般設計ページへのリンクを追加した。

Hypothesis C now reads “maintenance ownership differs by layer,” reorganized around insertion / maintenance / operation / repair-capable ownership, with a direct link to the broader ROCm-design page.

根拠: 2026-03-15 時点の hypothesis.md 再評価。2407d2f は投入主体の証拠だが、そこから ROCm 全体の維持主体へ一般化するのは早い、という整理。 Rationale: The 2026-03-15 reevaluation in hypothesis.md: 2407d2f is evidence of insertion ownership, but not sufficient to generalize maintenance ownership across ROCm.

index.html / README.md

旧記述

Old

トップと README からは、一般化された ROCm 設計思想ページへ直接進めなかった。

The top page and README had no direct path to a page about ROCm-wide design interpretation.

新記述

New

Design Model カードを追加し、README にも reveal-hypothesis.html を収録ファイルとして明記した。

A new Design Model card was added to the index, and the README now lists reveal-hypothesis.html explicitly.

ページ更新ログページを新設

Created a dedicated page-update log

2026-03-15

公開サイト全体で「何をどう書き換えたか」を共有しやすくするため、専用の監査ログページを追加した。

A dedicated audit-log page was added so public-site wording changes can be shared and traced more clearly.

page-history.html index.html README.md

旧状態と新状態

Old state vs new state

旧状態

Old

公開サイト内に「ページ更新そのもの」を時系列で追う場所がなかった。トップからは各資料へ飛べるが、どの記述がいつ差し替わったかは追いづらかった。

The site had no dedicated place to track public-page updates themselves. The index linked to the pages, but wording changes over time were hard to follow.

新状態

New

page-history.html を追加し、旧記述 / 新記述 / 根拠 / 影響ページを1エントリ単位で残す方式にした。

page-history.html was added as a per-entry log that records old wording / new wording / rationale / affected pages.

理由: 研究ノートの更新速度に対して、公開ページ側の変更理由も透明に残したかったため。 Why: The notebook evolves quickly, and the reasoning behind public-facing changes also needs to remain transparent.

3月14日知見を公開ページへ同期

Synced 2026-03-14 findings into the public pages

2026-03-15

内部ノート vega-rocm.md・facts.md・work_logs.md の 2026-03-14 更新を受けて、公開側の技術ページに残っていた古い説明を差し替えた。

After the 2026-03-14 updates in vega-rocm.md, facts.md, and work_logs.md, stale wording in the public technical pages was revised.

solver-trace.html experiment-history.html hypothesis.html README.md

solver-trace.html

旧記述

Old

MLIR iGEMM 強制実行は「MIIR_INVALID_PARAM で落ちる」という説明が中心で、3/14 の追試で見えた Perf Db: record not found → boost::optional::get() までは未反映だった。

Forced MLIR iGEMM was mainly described as failing with MIIR_INVALID_PARAM, without reflecting the 2026-03-14 follow-up that exposed Perf Db: record not found → boost::optional::get().

新記述

New

「初期追試では MIIR_INVALID_PARAM、3/14 追試では CompileSolution → GetInvoker → Perf DB 不在 → assertion」という形で、強制実行が IsApplicable() を越えた先の failure boundary まで見せることを明記した。

The page now states both observed downstream failures: earlier MIIR_INVALID_PARAM, and the 2026-03-14 path reaching CompileSolution → GetInvoker → missing Perf DB → assertion after bypassing IsApplicable().

根拠: vega-rocm.md §2.2.2 / §2.2.3 と 2026-03-14 実機追試。 Rationale: vega-rocm.md §2.2.2 / §2.2.3 and the 2026-03-14 runtime follow-up.

experiment-history.html

旧記述

Old

時系列は Step 10（2026-03-13 の INT8 深掘り）で止まっていた。CIFS 問題やローカル Debug MIOpen ビルド成功は公開タイムラインに存在しなかった。

The timeline stopped at Step 10 (the 2026-03-13 INT8 deep probe). The CIFS bottleneck and successful local Debug MIOpen rebuild were not yet in the public timeline.

新記述

New

Step 11 を追加し、「CIFS D-state → WD-Black NVMe へ移動 → configure 7.5-9.6秒 → Debug MIOpen build 成功 → 強制 MLIR 追試で Perf DB 不在を確認」という流れを公開側にも固定した。

A new Step 11 was added to document the chain: CIFS D-state bottleneck → move to WD-Black NVMe → 7.5-9.6 s configure → successful Debug MIOpen build → forced MLIR follow-up exposing missing Perf DB records.

根拠: work_logs.md 2026-03-14 の build/runtime 記録。 Rationale: The 2026-03-14 build/runtime entries in work_logs.md.

hypothesis.html

旧記述

Old

MLIR 除外の背景について、「MIIR_INVALID_PARAM が miirLowerTuningParams で起きるので LLVM backend 由来の可能性が高い」とやや単線的に読める記述だった。

The page leaned toward a single-cause reading: because MIIR_INVALID_PARAM appeared at miirLowerTuningParams, the issue was likely at the LLVM backend level.

新記述

New

「private issue は LLVM 側事情を示唆するが、3/14 追試では tuning / Perf DB 欠落も露出したため、公開情報だけで原因を単一レイヤに還元できない」と修正した。

This was revised to: the private issue still suggests an LLVM-side reason for the original exclusion, but the 2026-03-14 follow-up also exposed tuning / Perf DB absence, so the public evidence does not justify reducing the problem to a single layer.

根拠: vega-rocm.md §2.2.3 の forced MLIR failure mechanism。 Rationale: The forced-MLIR failure mechanism documented in vega-rocm.md §2.2.3.

README.md

旧記述

Old

solver-trace.html は「2026-03-13 追加」、experiment-history.html は「Steps 1-10」と案内していた。

solver-trace.html was described as "added on 2026-03-13," and experiment-history.html as covering "Steps 1-10."

新記述

New

solver-trace.html を「2026-03-14 更新」とし、二重排除構造と Perf DB / optional 系 failure を追記。experiment-history.html は Steps 1-11 に更新した。

solver-trace.html is now marked as "updated on 2026-03-14" with the dual-guard structure and Perf DB / optional failure path noted. experiment-history.html is updated to Steps 1-11.

運用メモ: このページは「公開ページ側の監査ログ」です。研究の正本は内部ノート側にあり、公開表現はそこから必要な範囲だけを抽出・翻訳して更新します。 Operational note: This page is the audit log for the public-facing site. The lab notebook remains the internal source of truth, and public wording is updated by selectively translating and extracting from that notebook.