chore: pin FluidAudio 0.15.4 → 0.15.5 (#122) - #142
Conversation
Unblocks #123 / #124 — the Parakeet Unified and TDT-ja models exist only in 0.15.5. #110 flagged DownloadUtils → ModelHub as breaking. It is not breaking for this repo: the rewrite is internal to the download layer and this repo has zero references to it. Both questions the issue left open were answered by compiling rather than by reading release notes — the AsrModels signatures are unchanged, and the Chinese-family managers used here are not the experimental zh-CN CTC / Qwen3 backends dropped in 0.15.3. Accuracy is unchanged: every overlapping before/after pair matches to the precision the report prints, across parakeet, sensevoice and paraformer. Throughput moved, but those are single unaveraged runs and are not evidence either way. Carrying #110's residue: the schema records app_version but not the FluidAudio version, so the two batches are indistinguishable in the store once written and are separated here only by capture time. Refs #122
0b736de to
bd35b9c
Compare
Verify Report — PR #142Enginemanual fan-out (3 lens Agents, model: opus, file-based output) + Codex ( Two deliberate deviations from the default ensemble, both stated rather than silently applied:
Diff-freshness gate (#228): PASS — frozen Process GapsThe Devil's Advocate leg did not run. Two attempts, neither produced output:
Per the skill's second-idle fallback, the coordinator performed the adversarial review in its place and the substitution is recorded here rather than absorbed. This is a lower-quality substitute and should be read as one: the coordinator had already read all four findings files before reviewing, so it lacks the cognitive isolation the role depends on — an adversarial pass works because it does not share the other reviewers' framing, and this one does. The coordinator's contributions are marked Two findings that a real adversarial pass would likely have interrogated further, and did not get to: whether the six bestASR versions between the two batches contain anything that touches the Working-tree contention. One lens ran a before/after warning comparison by flipping AggregateFAIL — 2 blocking, 6 follow-up. The dependency change itself is clean; the security review is a substantive PASS with rigorous method. What fails is the PR's account of itself: three of its factual claims are false as written, and its headline evidence cannot support its headline conclusion. Requirements coverage — issue #122
Findings (merged, deduped; the stacking effect is collapsed — see the note below the table)
On the stacking effect. Three lenses plus the cross-model leg converged hard on "the documentation is false", which makes the count look larger than the problem. The genuinely distinct claims are collapsed above: "models only in 0.15.5", "signatures unchanged" and "consumed surface entirely high-level" are one finding (F2) reported by three sources, not three findings. The evidence problems, by contrast, really are separate — F1(a) is provenance and F1(b) is coverage, and closing one leaves the other open. Adversarial adjudication
|
| corpus | backend | 2026-07-05/06 (app 0.10.0) | 2026-08-02 (app 0.16.0) |
|---|---|---|---|
59dfb9a4acb3 (jfk) |
parakeet | 0.0000 % | 0.0000 % |
29007d2e6418 |
parakeet | 93.5484 % | 93.5484 % |
33dd468f27c6 |
sensevoice | 14.0845 % | 14.0845 % |
af3571b78130 |
sensevoice | 47.2222 % | 47.2222 % |
29007d2e6418 |
sensevoice | 11.2903 % | 11.2903 % |
33dd468f27c6 |
paraformer | 178.8732 % | 178.8732 % |
af3571b78130 |
paraformer | 181.9444 % | 181.9444 % |
This is stronger than the CHANGELOG's own table implies. The cross-model leg's objection — that two differently-rounded numbers cannot establish equality — is correct about what the table shows and wrong about what the data holds.
B. The 2026-07-19 batch (app 0.14.0, 24 rows) shares zero corpora with the after-batch.
Its corpus IDs (12669b3d0de8, 604acbc2d096, c4120b0b7d67, …) and the after-batch's (59dfb9a4acb3, 33dd468f27c6, af3571b78130, 29007d2e6418) do not intersect at all. So the choice of the older, smaller 07-05/06 batches as "before" was forced by overlap, not carelessness — a fact that reads as an implicit accusation in one lens report and should not.
Adjudication. A defuses part of F1(a) and does nothing for F1(b).
The bit-identity is real evidence that the decode paths those corpora exercise are deterministic and unmoved — across six bestASR versions as well as across the FluidAudio bump. So "the comparison confounds six bestASR versions" overstates the practical damage: the confound existed and demonstrably did not materialise. On that basis I record F1 at HIGH rather than CRITICAL, which is a downgrade from the requirements lens's rating.
But it rescues nothing on F1(b), and arguably sharpens it. If the changed branch cannot fire on single-chunk audio or on a language without case, then bit-identity on exactly those corpora is the predicted outcome whether or not 0.15.5 changed anything — it is not evidence about the change, it is evidence about the absence of the change's preconditions. Identity where the code cannot differ says nothing about where it can.
So both statements are true at once, and the honest form of the claim is narrower than either the PR's or the harshest lens reading:
On the seven overlapping corpus/backend pairs, error rates are bit-identical between the 2026-07-05/06 baseline (bestASR 0.10.0) and the post-bump sweep (bestASR 0.16.0). None of those pairs exercises 0.15.5's new seam-duplicate collapse, which requires multi-chunk audio containing case-differing Latin text; the English multi-chunk corpora that would are on disk and were not measured. No pre-upgrade sweep was run, and the store cannot attribute a row to a FluidAudio version.
On the caveat (F4) I also differ from the requirements lens, which rated it CRITICAL partly on the reading that it conceals the real confound. The sentence is false about the pair it names and that is worth correcting, but it is false in the direction of understating the author's own diligence gap rather than overstating a quality claim. MEDIUM.
What the security review establishes (and it is substantial)
Recorded because a FAIL verdict should not flatten a genuinely clean result on the axis where this PR is actually risky.
The pin is correct and the supply-chain posture is unchanged or better. Tag → revision was cross-checked against the GitHub API rather than the local mirror alone, on the stated reasoning that a mirror fetched by this machine would faithfully reproduce upstream tampering — 19600a48… is the real v0.15.5. swift package resolve against the committed tree is a no-op, so the lockfile is what SwiftPM computes rather than a hand edit. Across a large upstream delta (41 commits, 156 files, a wholesale rewrite of the download layer), there are no new transitive dependencies (FluidAudio declares none, and its Package.swift is byte-identical between tags), no network-endpoint change (ModelRegistry is byte-identical), no TLS-verification weakening, no new credential sink, no telemetry — and the offline-egress gate got stronger, gaining per-request re-checks inside FileDownloader and HFTreeLister.
Weight pins were confirmed empirically rather than assumed: hashing the live cache against the committed manifest gives 42/42 files clean across all three pinned repos. And the PR is correct not to re-pin, which is worth stating so a later reviewer does not "fix" it reflexively — re-running the pin script here would have TOFU-laundered any drift, and the check above shows there was none to record. Leaving the manifest untouched is what preserved the ability to detect drift.
Scope check
Clean. Three files, +43/−4. The re-cut that moved Package.swift / Package.resolved here from PR #140 left no inconsistency: CHANGELOG text, manifest pin and lockfile revision now agree, the ### Changed block sits correctly in the unreleased section, and nothing from the old split leaked through. The blocker relationship to #110 is genuinely lifted — ModelGrid still carries only 0.6b-v3, which is correct, since adding tdt-ja / unified rows is #123/#124's work, and an unmapped grid model throws loudly rather than falling back silently.
Next
F1 and F2 gate the merge. F1(b) closes at the cost of a single benchmark run on one English multi-chunk corpus (osr-harvard-1, 33 s); F1(a) closes either by checking out 0.15.4 for a real before-sweep, or by relabelling the table with both app versions and capture dates and weakening the conclusion to the honest form above. F2 is three sentence-level corrections to the PR body and CHANGELOG.
Verify was run at bd35b9c; re-run after the blocking findings are addressed — and note that the Devil's Advocate leg owes this PR a pass it did not get.
1 participant
Unblocks #123 / #124 — the Parakeet Unified and TDT-ja models exist only in 0.15.5.
Refs #122
The "breaking change" is not breaking here
#110 flagged
DownloadUtils → ModelHubas a breaking change. It is an internal rewrite of the download layer, and this repo has zero references to it. The consumed surface is entirely high-level:AsrModels.download(version:)/.load(from:version:),AsrManager(config:models:)ParakeetEngineParaformerManager.load(),SenseVoiceManager.load(precision:)ChineseFamilyEngineDiarizerManager()DiarizationEngine,SpeakerEnrollerASRResult.text/.confidence/.duration/.tokenTimingsParakeetOutputBoth questions the issue left open were answered by compiling, not by reading release notes:
AsrModelssignatures are unchangedAccuracy is unchanged
Every overlapping before/after pair matches to the precision the report prints:
jfk(en)cv-zhtw-4cv-zhtw-1cv-zhtw-2cv-zhtw-4cv-zhtw-1cv-zhtw-2Throughput moved (parakeet on
jfk: 161.6× → 126.5×), but those are single unaveraged runs on a thermally unconstrained laptop — the speed column is not evidence of a change in either direction, and saying otherwise would be reading noise as signal.One thing that looked like a regression and wasn't:
fluid-paraformerproduced no rows in the default sweep. It ispriority: 2and the default ceiling is priority-1, so it correctly does not enumerate — the earlier numbers were captured under--all-grid. Checked before reporting.Comparability caveat (carried from #110's residue)
The measurement schema records
app_version(bestASR's own) but not the FluidAudio version, so once written these two batches are indistinguishable in the store. They are separated here only by capture time. Per the standing rule that a tool-version change constitutes a new condition, rows either side of this bump should not be ranked against each other on the strength of the schema alone. That gap is not fixable inside this issue.Tests
445 tests / 88 suites green.
Package.resolvedpinned to0.15.5(19600a4).