Release Transcripted 1.1.62: version, appcast and cask

[claude]

Requested by Justin · project thread

Before: v1.1.62 is published on GitHub (notarized DMG from Release Candidate run 35923097515), but the Sparkle feed on main and the Homebrew cask still point at 1.1.61. So existing installs don't see the update.

After: merging this puts 1.1.62 at the top of docs/appcast.xml, the live feed that SUFeedURL reads from main via raw.githubusercontent. That means installed apps offer the update, and the cask installs the 1.1.62 DMG.

How: same shape as #1745. The first commit bumps Info.plist to 1.1.62, which is the source the Release Candidate workflow built from (tag v1.1.62 = 388fd34). The last commit adds the metadata from that build.

Why

Justin asked to release 1.1.62 ("release this", 2026-09-23 20:29Z). Every in-scope PR merged to main first: #1767 (with #1771), #1778, #1773, #1768, #1782 and #1781.

Product Impact

• Affects: dictation / meetings
• Lane: release ops
• Why this matters: without this merge, 1.1.62 only reaches people who download it by hand.

What changed

• Info.plist: 1.1.61 → 1.1.62 (both version keys).
• docs/appcast.xml: new 1.1.62 item. The signature, length and pubDate are copied verbatim from the RC artifact's appcast, and every other item is unchanged.
• Casks/transcripted.rb: version 1.1.62, sha256 dd8ec468…9d67 (matches the published asset digest).
• Tests/Fixtures/release-health-github-release-1.1.62.json: new. release-health-github-release-stale-cask.json moves to 1.1.62. The strict-checker references in .agents/test-matrix.yml, NightlySecurityContractTests.swift and transcripted-qa-bench.sh move from 1.1.61 to 1.1.62.

How I checked it

• python3 scripts/ops/nightly-security-check.py --strict ... --github-release-json Tests/Fixtures/release-health-github-release-1.1.62.json: 100/100, exit 0. With the stale-cask fixture it exits 1, as the contract test expects.
• The new fixture's format is byte-identical to the 1.1.61 one apart from the values. docs/appcast.xml parses.
• scripts/dev/agent-preflight.sh
• bash run-tests.sh (Linux session, no Swift toolchain): hosted CI. This commit should turn the 8 expected ReleaseMetadata/NightlySecurity failures green.

Risk Review

• Privacy / local-first behavior reviewed: no code change
• Storage path or migration impact reviewed: none
• Release/update impact reviewed: this IS the live-feed change, published with Justin's go
• No private transcripts, audio, tokens, personal paths, or customer data are included

Notes

• Rollback: revert this PR's appcast item, and point the cask back to 1.1.61 (sha256 88ab813e…d9fa).
• Still after merge: the Sentry release plus dSYM registration on Justin's Mac, and a live check of the appcast, /download and the cask.

🤖 Generated with Claude Code

https://claude.ai/code/session_015njvTLqC9Fao3TMUNouKka

[claude]

checks is red on 812c4ca, as expected for a version-only commit. All 8 failures come from two metadata-parity tests:

• ReleaseMetadataContractTests.swift:69-81 (7 failures): the cask and latest appcast item still say 1.1.61 while Info.plist says 1.1.62.
• NightlySecurityContractTests.swift:208 (1 failure): the strict checker exits 1 on the 1.1.61 release fixture once Info.plist is ahead of the appcast. I reproduced the exit 1 locally.

These can't be fixed from this branch alone. They go green when the notarized 1.1.62 candidate's appcast item, cask sha and release-health-github-release-1.1.62.json fixture land here, the same way #1745 did for 1.1.61. The branch has to stay Info.plist-only until then, or the Release Candidate workflow refuses to build from it. I'm not pushing anything else to it until Justin gives the go.

Correction to the PR body: the strict nightly check does not pass on this commit. It scored 100/100 but exits 1 because of the version-ahead watch item. I've fixed the body.

---

Generated by Claude Code

[claude]

app-build is red on 3b63f03, and it's a new failure, separate from the expected metadata-parity one. The app built, signed and launch-smoked fine. What failed is the Home recent-captures performance benchmark: performance budget failed for 10000 captures: cancel 295.5ms > 100.0ms.

I don't think this PR caused it:

• The source is identical to main at a471505 apart from the two Info.plist version strings.
• main's Swift CI run on that exact tree passed app-build a few minutes earlier (run 35792452049).
• This PR's previous head also passed app-build.
• The benchmark times cancelling a 10,000-file scan on a shared runner, so it's load-sensitive and doesn't read the version at all.

No fix exists or is needed in this branch, and it has to stay Info.plist-only for the Release Candidate workflow anyway. I can't re-run jobs from this session (the API returns 403), so a manual re-run of app-build should clear it. I'm keeping the PR watched. If it fails the same way again, I'll treat it as real and look at the cancel path.

---

Generated by Claude Code

[claude]

spm-tests on d730471 was aborted by XCTest's stall detector in CoreAudioSystemAudioCaptureTests.testAttemptFinishSubscriberCanCancelAcrossBackendQueueWithoutDeadlock (line 193). The process got signal 6 about 20s after the test started, so every suite after it was skipped.

It's not this PR's failure. The diff against main is only the version bump in Info.plist, and the same test passed on #1762's run a few minutes earlier, which also edits that file. The stall looks like the main thread being blocked during the 3s wait, which is the same pattern as the metering-test stalls. Neither test's own code explains that. No fix exists yet, and I can't re-run jobs from here (the API returns 403). The Release Candidate workflow doesn't run the SPM tests, so this doesn't block a release build.

---

Generated by Claude Code