docs: mark the two stale issue references in the coverage reports (#431)

Both reference documents carry claims that stopped being true when the
issues behind them closed, and neither had a record of what replaced them.

`docs/reference/hf-coverage.md` lists five tracked causes from the
2026-09-02 MUSA baseline and still presents all five as open work. Four are
closed: #250/#265 by PR #280 and #282, #262/#268 by PR #398, #266 by PR
#278, #264 by PR #419. Only #263 is still open. A new "What has changed
since this baseline" section records each closure with the issue and the
commit that landed, and states what was actually re-measured: the eight
SDPA nodeids #268 borrowed, with `{"PASS": 8}` under the harness's device
shims and an `allclose` residual without them that belongs with #248. The
baseline's own `Affected tests` counts are deliberately left alone — they
are dated measurements of `64e60dd`, and rewriting them against a later
tree would stop them matching the run they came from, which is what the
dedup parser reads them for.

`docs/reference/operator-support.md` records the 2026-08-30 cohort as
excluding "the known float64 `mm` gap". PR #275 moved `mm` and `mm.out`
onto the FlagGems route on 2026-09-15, so that exclusion is historical; the
later entries in the report count the op. A paragraph after the row says so
and names what replaced the mudnn capability gap — a different defect on
the route that now serves the op, the FlagGems fp64 tile exceeding the
device's 192 KiB of shared memory past `M > 32` and `N > 32`, filed as
#428.

Documentation only; no code, no routing and no test changes.

Verified: `ruff check .` -> All checks passed; `ruff format --check .` ->
311 files already formatted; `pytest tests/unit/test_transformers_automation.py -q`
-> 61 passed; `pytest tests/unit/ -q` -> 6 failed, 761 passed, 131 skipped,
and the same six fail identically with these edits stashed, so they
pre-exist on d5f82ae. `transformers_deduplicate.extract_baseline_fingerprints`
still reads the edited coverage doc without error.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: lvyufeng

docs/reference/hf-coverage.md

@@ -51,6 +51,12 @@ The corrected verification grouped the 20 occurrences into these tracked causes:
 | | `FEATURE_UNSUPPORTED` | TorchInductor/Triton requires CUDA libraries | 2 | [#264](https://github.com/flagos-ai/Torch-FL/issues/264) |
 | | `OP_UNSUPPORTED` | mudnn `TRUEDIV` with `INT64` | 2 | [#266](https://github.com/flagos-ai/Torch-FL/issues/266) |
 
+`Affected tests` is the count this baseline measured on `64e60dd` and is not
+updated here: the table's job is to say which occurrence a re-measurement is
+looking at, so a count rewritten against a later tree would stop matching the run
+it came from. Which rows are still live work is recorded in prose below, where a
+closure can carry the commit that closed it.
+
 The `Fingerprint` column is what deduplication keys on: `transformers_deduplicate.py`
 reads it from each baseline's cause table, and `transformers_file_issues.py`
 fills it in when it records a newly filed issue. The five rows above are left
@@ -75,6 +81,46 @@ suite measurement, but the corrected per-test isolation is the evidence used for
 root-cause filing. Raw JSON remains outside the repository at
 `/tmp/qwen3.json` and `/tmp/qwen3_isolated_results_v2.json`.
 
+### What has changed since this baseline
+
+Four of the five causes have a fix; the fifth is the only reason this baseline is
+not fully resolved.
+
+- **#250, #265** (device context poisoning, and its `test_model_parallelism`
+  trigger) — closed 2026-09-15, the same day PR #280 (`6b2af4b`, "stage
+  cross-device copies in MudnnCopy instead of handing mudnn two devices") landed,
+  with PR #282 ("order the peer device against a cross-device D2D copy") covering
+  the ordering half.
+- **#262, #268** (mudnn softmax rejects non-contiguous input) — PR #398
+  (`6a9c101`, 2026-09-23, "materialize strided softmax operands before mudnn on
+  MUSA"), which closed #262 the same day. #268 was closed three days later, on
+  2026-09-26, against that fix after its borrowed nodeids were re-measured. The eight
+  SDPA nodeids this row borrowed were re-measured on `main @ 48829b8` with the
+  harness's device shims enabled and report `{"PASS": 8}`; the
+  `RuntimeError: _softmax failed: INVALID_PARAMETER` signature the run recorded is
+  raised by none of them. With the shims disabled
+  (`HF_TEST_NO_DEVICE_SHIMS=1`) the same eight fail, but on the 80 % `allclose`
+  check and not in the operator: `tests/test_modeling_common.py:486` falls through
+  to fp32's `atol = 1e-7, rtol = 1e-4` for a device name transformers does not
+  list, which is the fall-through #248 documents for GCU. That residual belongs
+  with #248. Only those eight were re-run.
+- **#266** (mudnn `TRUEDIV` with `INT64`) — PR #278 (`251c9c8`, 2026-09-15, "route
+  MUSA integer division through mudnn and promote true division").
+- **#264** (TorchInductor/Triton requires CUDA libraries) — PR #419 (`48829b8`,
+  "ask torch, not the redirected probe, before aliasing cuda to flagos").
+- **#263** (ProcessGroupGloo rejects `flagos` tensors) — still open. Its six
+  FSDP2 nodeids are the remaining known failures of this baseline, and the failure
+  reproduces today: `RuntimeError: ProcessGroupGloo::allreduce: unsupported device
+  type flagos`.
+
+Because `Affected tests` and the baseline header above describe `64e60dd`, the
+whole table is a dated snapshot and not a statement about the current tree.
+Re-running the baseline is what refreshes it — and is also what fills in the
+`Fingerprint` column, per the note above. The closures above are recorded from the
+issues and the commits that landed; only the #268 re-measurement re-ran any of
+this baseline's tests, and it covers eight nodeids out of twenty, so the other
+four causes are **not revalidated** here.
+
 ### Failed test inventory
 
 The 20 failed tests were grouped for follow-up investigation:
@@ -110,3 +156,11 @@ SDPA-named tests reproduced the same non-contiguous softmax failure rather than
 pure tolerance mismatch. Future measurements must also run with
 `FLAGOS_LOG=fallback` and report any passing operation that used CPU fallback
 as an accelerator coverage gap.
+
+That last clause is worth revisiting now that #398 has landed. With the strided
+operands materialized before mudnn, a tolerance mismatch is exactly what those
+eight show: they pass under the harness's device shims and fail without them, at
+the `allclose` check rather than in the operator (the re-measurement above). The
+baseline's reading was right for the tree it measured — and the behaviour it ruled
+out is what remains once the operator is fixed, which is why the residual is
+tracked by #248 and not as a softmax defect.

docs/reference/operator-support.md

@@ -5257,7 +5257,9 @@ Measured on the eight-device Moore Threads MTT S5000 host with CPU PyTorch 2.10.
 - `tests/integration/ops/test_pow_dispatch.py -m anyplatform`: **22 passed, 4 deselected**; coverage includes both `pow.Tensor_Scalar` and `pow.Tensor_Tensor` empty outputs, empty broadcasting, the zero-length narrow backward path, and non-empty parity.
 - `tests/integration/ops/test_narrow_dispatch.py -m anyplatform`: **17 passed**, including `test_narrow_backward_edge_cases[1-2-0]`, which is no longer deselected in the MUSA CI manifest.
 - `tests/integration/ops/test_musa_dispatch.py -m musa`: **89 passed**.
-- The CI operator cohort (excluding the separately triaged RNG file and the known float64 `mm` gap) reached **480 passed, 14 skipped, and 3 xpassed**; three existing FlagGems configuration-consistency assertions failed because they inspect unrelated generic FlagGems routes, not MUSA native kernels.
+- The CI operator cohort (excluding the separately triaged RNG file and the float64 `mm` gap as it stood on this date) reached **480 passed, 14 skipped, and 3 xpassed**; three existing FlagGems configuration-consistency assertions failed because they inspect unrelated generic FlagGems routes, not MUSA native kernels.
+
+The `mm` exclusion is historical and no longer describes the cohort: PR #275 (`6b978c0`, 2026-09-15) moved `mm` and `mm.out` onto the FlagGems route, so every entry dated from 2026-09-15 onward counts the op. The figure above is therefore a measurement of the 2026-08-30 tree and not a current one; the later entries in this report record the cohort without that exclusion, and their manifests differ from this one, so they are not a correction of the number — they are separate measurements. What replaced the mudnn capability gap is a *different* defect on the route that now serves the op: the FlagGems float64 tile exceeds the device's 192 KiB of shared memory once both `M > 32` and `N > 32`, filed as #428. That does not restore the exclusion this row records, and it is not read from the routing table — the boundary is measured.
 
 The empty-output path stays on `flagos:0` and preserves shape and dtype; no host round trip is used. The MUSA operator support cohort is otherwise unchanged.