FluidAudio pin 0.15.4 → 0.15.5（#110 子項 A，B/C 的 blocker）

[kiki830621]

Problem

Original text（父 issue #110）：
「Pin bump 0.15.4 → 0.15.5（處理 ModelHub API 變更），全測試綠。」

Package.swift:16 pin exact: "0.15.4"（6/16），上游 0.15.5（7/7）。這是 #110 拆解後的
第一個子項，也是 B/C/E 的 blocker——新模型都在 0.15.5 才有。

Type

feature

已查證：風險比父 issue 描述小得多

#110 把 DownloadUtils → ModelHub 標為破壞性變更。但本 repo 對該層零使用：

• grep -rn "DownloadUtils" Sources/ → 零命中
• 本 repo 對 FluidAudio 的 API 面全是高階的：AsrModels.download(version:) /
  AsrModels.load(from:version:)（ParakeetEngine.swift:116-118）、
  AsrManager(config:models:)（:119）、ASRResult.text/.confidence/.duration/.tokenTimings、
  DiarizerManager()（DiarizationEngine）

DownloadUtils → ModelHub 是下載層內部重寫，我們不碰下載層。所以 pin bump 的實際
待驗面只有兩點，都比「破壞性變更」聽起來小：

1. AsrModels.download / .load 的 signature 在 0.15.5 有沒有變
2. 0.15.3 移除的實驗性 zh-CN CTC / Qwen3 後端，本 repo 是否有依賴（ChineseFamilyEngine 需確認）

Expected

1. Package.swift pin → 0.15.5，swift build 綠、全套件測試綠
2. 上述兩個待驗面實際確認（非假設）
3. 升級前後各跑一輪 release sweep 作為 before/after 證據——依 global
   common-ocr-toolchain-freshness 例外 2：新版本＝新 condition，舊測量不得與新測量混排
   進同一 ranking

Impact

Package.swift、Package.resolved、可能 ParakeetEngine.swift / ChineseFamilyEngine.swift（若 API 面有變）、測試。

⚠️ 已知的 schema 缺口（承 #110 Residue）

measurement schema 沒有記錄 FluidAudio 版本——只有 app_version（bestASR 自己的版本）。
升級前後的 sweep row 若 bestASR 版本未變，在資料上無法區分。這使「before/after 證據」
的可比性打折。屬 #111/#118 family 的 schema 缺口，非本 issue 可獨力解；執行 sweep 時需
以其他方式（時間戳 / 手動標記）區隔兩批。

Source: decomposed from #110（2026-08-01）。API-面事實由本機 code 探勘查證。

[kiki830621]

Verify (via PR #142)

Result: FAIL — 2 blocking, 6 follow-up. Engine: 4 verifiers, not the usual 6 — 3 lens Agents (opus) + Codex gpt-5.6-sol. The logic lens was deliberately not dispatched (the diff is two version strings plus prose), and the Devil's Advocate leg did not run: one instance died on ECONNRESET, the retry hit the account session limit. The coordinator substituted for it and the report says so. Diff-freshness gate PASS at bd35b9c.

Full report: #142 (comment)

This issue's requirement 1 (pin, build, tests) is MET — 445 tests / 88 suites green. Requirement 3 (run a release sweep before AND after) is NOT MET: only the after-sweep exists. The "0.15.4" column of the accuracy table reconciles to store rows from 2026-07-05/06 under app_version 0.10.0; the store holds no fluid-* batch between 2026-07-19 and the post-bump run.

Two blocking findings:

• F1 — the accuracy evidence cannot support its conclusion, for two independent reasons: no pre-upgrade sweep was run, and the corpora measured (jfk at 11.0 s, single-chunk; Chinese corpora, no case) cannot exercise 0.15.5's new seam-duplicate collapse, which needs multi-chunk audio with case-differing Latin text. The English multi-chunk corpora that would are on disk and unmeasured.
• F2 — three false claims in the permanent record: TDT-ja and the Unified managers are present in 0.15.4 (what changed is the Unified frontend, not availability — which also puts Parakeet TDT Japanese 納入 model grid（#110 子項 C） #124's blocker premise in doubt); the AsrModels signatures did change (progressHandler type); and the "entirely high-level" consumed surface omits DiarizerModels.downloadIfNeeded(), a download-layer entry point.

The report also records an adjudication the ensemble did not reach: the seven compared pairs are bit-identical in the raw store, not merely equal after rounding — which partly defuses the app-version confound and does nothing at all for the coverage gap, since identity where the changed code cannot fire is the predicted outcome either way.

Separately, the security review is a substantive PASS on the axis where a dependency pin is actually risky: no new transitive dependencies, no endpoint/TLS/credential/telemetry change, a stronger offline gate, tag→revision cross-checked against the GitHub API, and 42/42 weight pins confirmed against the live cache.

[kiki830621]

Verify Round 2 (via PR #142)

Result at 69916b8: FAIL — 3 blocking. Engine degraded: 4 verifiers, not 6 — the cross-model leg returned HTTP 429 usage_limit_reached (~5 days to reset). That matters here: in round 1 Codex produced this PR's two sharpest findings, and neither came from a Claude lens.

Full report: #142 (comment)

The dependency change is clean. What failed, for the third consecutive round, is the account of it.

F2 is closed — all three false claims corrected, each replacement independently verified. F1 was closed and then re-opened: the A/B is real and both lenses reproduced it (one in a fresh clone with a per-pin build), but the entry's claim about what the run exercised does not hold.

Three successive drafts each mis-stated the change surface, in different directions. Round 1 named one behavioural change. The correction named two commits and asserted the second's fallbacks were exercised. The actual surface is five changes across two commits — including one nobody named: caseVariantCanonicalIds is threaded into the overlap matcher, where tokensMatch moved from exact token-ID equality to case-folded equality, changing where the seam is cut rather than what is removed after it.

And the fallbacks were not exercised. They are strictly conditional, and two independent lines say none fired: the transcripts are byte-identical (any real entry would have kept content 0.15.4 dropped), and upstream's own instrumentation in that commit message reports ~67 adversarial seams with zero fall-throughs. Asserting the enclosing function ran is not asserting the changed branch was taken — the same category error the original "structurally blind" sentence made.

Two other things worth carrying:

• "with no fluid-* batch in between" was false — 24 rows sit at 2026-07-19 — and the accurate fact it displaced was the one that defended the choice of baseline (zero corpus overlap). Established in round 1, then compressed into a falsehood.
• The A/B wrote two indistinguishable rows into the measurement store, the 0.15.4 one stamped app_version 0.16.0. First real instance in 384 rows of the confound this entry documents — created by the run documenting it. Row removed, backup retained, measurement now committed at benchmarks/evidence/issue-122-fluidaudio-ab.json.

Fixes are in 9172f4b. 445 tests green; pin, lockfile and weight manifest untouched.

Carried out of this PR: a round-1 HIGH — the regression gate is WhisperKit-only and has zero FluidAudio coverage, undisclosed — never reached the round-1 master findings table. The synthesis step lost it, so it was never actioned. It belongs in its own issue.

[kiki830621]

Round-3 verify of PR #142 (9172f4b): FAIL — 3 blocking. Four verifiers; the cross-model leg was available again, which is the reason round 2 set this gate.

The dependency change itself is clean and can be stated categorically for the first time: every changed line under Sources//Tests/ is a comment (19 lines, verified mechanically then read by hand). Most of round 2's corrections landed and were independently reproduced.

What fails is the third consecutive account of what the code did — and this round measured it rather than arguing about it:

round	claim about the five upstream changes	measured
1	accuracy is unchanged	false
2	"it exercises 0ac0e414's fallbacks"	false — those three never ran
3	"none of the five was reached"	false — two ran, one changed its answer

Both of round 2's and round 3's claims are currently in the tree at once, contradicting each other. All three verifiers correctly called that blocking; none asked which side was true, and the answer is neither.

The headline ("the transcripts are byte-identical") is true, and was proven for the first time — identical SHA-256 on both pins in SRT and txt, plus a determinism control nobody had run in three rounds. The evidence file could not have supported it: two equal WERs do not imply equal transcripts.

Full report: #142 (comment)

[kiki830621]

Round-3 verify of PR #142 (9172f4b): FAIL — 3 blocking. Four verifiers; the cross-model leg was available again, which is the reason round 2 set this gate.

The dependency change itself is clean and can be stated categorically for the first time: every changed line under Sources//Tests/ is a comment (19 lines, verified mechanically then read by hand). Most of round 2's corrections landed and were independently reproduced.

What fails is the third consecutive account of what the code did — and this round measured it rather than arguing about it:

round	claim about the five upstream changes	measured
1	accuracy is unchanged	false
2	"it exercises 0ac0e414's fallbacks"	false — those three never ran
3	"none of the five was reached"	false — two ran, one changed its answer

Round 2's and round 3's claims are both in the tree right now, contradicting each other. All three lens verifiers correctly called that blocking; none asked which side was true, and the answer is neither. The case-folded matcher was entered twice and matched a token pair 0.15.4 would have rejected; collapseSeamWordDuplicates was called; the three word-boundary fallbacks were never entered. Neither entry changed the merge output — measured by counterfactual inside the same binary.

The headline ("the transcripts are byte-identical") is true and was proven for the first time: identical SHA-256 on both pins, in SRT and txt, plus a determinism control nobody had run in three rounds. The evidence file could not have supported it — two equal WERs do not imply equal transcripts.

Full report: #142 (comment)