Pre-release soak: v0.1.0-rc.12

[Cliftonz]

Soak metadata

• Pre-release tag: v0.1.0-rc.12
• Tag commit: e549181
• Target stable: v0.1.0
• Bump kind: minor (v0.0.5 → v0.1.0)
• Soak start (UTC): TBD (set on Step 5 window open)
• Soak end (UTC, minimum): start + 72h
• Diff: v0.0.5...v0.1.0-rc.12
• Cohort planned: macOS arm64 (this session) + Ubuntu / Fedora / Windows VMs (TBD)
• Trigger-matrix rows matched: essentially the entire v0.1.0 cycle (268 files, +25,762/-2,690 LoC)
• Known issues carried from prior rc: none (first soak under validating-pre-release skill)
• Channels excluded per docs/release-quirks-jarvy.md: Homebrew, install.sh, install.ps1 (tarball pipeline gap)

Validation Progress

• Step 1: Trigger matrix matched
• Step 2: This issue
• Step 3: Pre-soak matrix
  • Path 1 — Fresh install (macOS arm64 via .dmg)
  • Path 1 — Fresh install (Ubuntu 22.04+ x86_64 via .deb)
  • Path 1 — Fresh install (Fedora 40+ x86_64 via .rpm)
  • Path 1 — Fresh install (Windows 11 via .msi)
  • Path 2 — Upgrade from N-1 (v0.0.5 → rc.12)
  • Path 3 — Skip-version (N/A — v0.0.5 is only prior stable)
  • Path 4 — Rollback (rc.12 → v0.0.5)
  • Path 5 — Multi-tool real-world setup (≥10 tools)
• Step 4: Major-only matrix — N/A (minor bump)
• Step 5: Open soak window
• Step 6: Fault-injection drills — N/A (minor bump)
• Step 7: Evaluate promotion criteria
• Step 8: Promote to v0.1.0 OR cut -rc.13
• Step 9: Post-stable propagation (AUR, winget, Chocolatey)

Pre-flight verifications

• Tag signature: ✓ Good ED25519 signature
• isPrerelease: ✓ true
• isLatest: ✓ false
• Release assets: 47 files (binaries + sigstore .bundle/.pem/.sig + SBOMs + SHA256SUMS.txt)
• HEAD drift since tag: 5 commits, all helm-chart-only (no CLI-surface impact)

Soak signal log

(append comments throughout window)

Promotion decision

(filled at Step 7-8)

---

Tracked by validating-pre-release skill against docs/release-testing.md.

[Cliftonz]

Path 1 + Path 5 — macOS arm64 — PASS

Cohort: macOS arm64 (Apple Silicon dev box).
Install method: rc.12 .dmg artifact (the actual shipped binary).
Config: project's jarvy.toml (26 tools across brew + cargo + native — covers Path 5 realistic-load criteria).
Run timestamp (UTC): 2026-05-21T11:06:28Z → 11:08:10Z
Duration: 102 s

Pre-flight on the artifact

• ✓ gh release download v0.1.0-rc.12 --pattern '*aarch64.dmg*' succeeded
• ✓ SHA256 matches SHA256SUMS.txt (ef75a8924708…)
• ✓ Cosign keyless verify OK against bearbinary/Jarvy OIDC identity
• ✓ hdiutil attach mounted; binary extracted from jarvy.app/Contents/MacOS/jarvy

Path 1 pass criteria

Criterion	Result
Install completes without error	✓ — hdiutil + copy, no errors
jarvy --version matches rc tag	✓ — reports jarvy 0.1.0 (matches target stable; version-drift fix 098ff86 is in the tag)
jarvy setup exits 0	✓ — exit 0 in 102 s
state.json written w/ correct shape	⚠ — written to .jarvy/state.json (project-relative), 21 tools tracked, but config_hash is empty string rather than sha256:…. See findings below.
No panics in jarvy.log	✓ — clean structured JSON log, no ERROR/panic entries

Path 5 pass criteria

Criterion	Result
26 tools across 3+ package managers	✓ — brew + cargo + native
Default-hook tool included	✓ — delta (custom hook + git config write), zoxide/fzf/lazygit/ripgrep (default hooks)
Parallel installs complete cleanly	✓ — jobs=4 (per log), no lockfile / PATH corruption observed
Hooks run; user hooks override defaults	✓ — delta user post_install hook ran, post_setup hook printed the expected banner
Telemetry events fire when enabled	not exercised (telemetry off for soak run)

Sandbox auto-detection (PRD-053)

• Log shows seamless mode active, provider=Claude Code, forced=false. Auto-detect path working as designed.

Findings

Finding 1 — sev-2 candidate: state.json.config_hash is empty.
After jarvy setup on a config with no [drift] block, the rendered state file has "config_hash": "" (vs the documented shape "config_hash": "sha256:…" in CLAUDE.md). If jarvy drift check compares hashes by equality, two different configs with empty hashes would compare equal → silent drift-bypass. Need to confirm whether this is intentional (no [drift] block → no hash captured) or a bug. Repro:

JARVY_HOME=/tmp/x jarvy setup --file /path/to/jarvy.toml   # toml with no [drift] section
python3 -c "import json; print(repr(json.load(open('./.jarvy/state.json'))['config_hash']))"
# ''

Finding 2 — sev-3: jarvy drift check --file <path> rejects with unexpected argument '--file' found.
jarvy setup accepts --file; jarvy drift check does not. Inconsistent CLI surface. Workaround: cd to the dir containing jarvy.toml. Track as follow-up; does not block promotion.

Finding 3 — informational: post-install hooks write to $HOME/.zshrc regardless of JARVY_HOME.
JARVY_HOME=/tmp/jarvy-soak-rc12/state was set, but zoxide, fzf, lazygit, delta default hooks still edited ~/.zshrc directly (idempotent — re-runs don't duplicate). Expected behavior since the hook scripts use $HOME not $JARVY_HOME, but worth documenting for soak isolation purposes.

Outstanding work for promotion

• Path 1 on Ubuntu 22.04+ x86_64 via .deb
• Path 1 on Fedora 40+ x86_64 via .rpm
• Path 1 on Windows 11 via .msi
• Path 2 (upgrade v0.0.5 → rc.12) — needs N-1 install on a cohort host
• Path 3 — N/A (no N-2; v0.0.5 is the only prior stable)
• Path 4 (rollback rc.12 → v0.0.5) — needs N-1 + jarvy update flow
• Triage Finding 1 — confirm empty config_hash is intentional or fix in -rc.13

[Cliftonz]

Finding 1 — Triage Update (downgraded sev-2 → sev-3)

Re-ran setup with the default jarvy.toml filename in CWD (no --file). Result:

config_hash: 'sha256:7efb646a9308e6d00e26681dce3d54da0adeae630cc1eeab632462b55a771ebe'

Confirms the empty config_hash is scoped to the --file <path> code path when the file is named anything other than jarvy.toml. Default-name installs (the vast majority of users) get a correct hash.

Root cause: src/commands/setup_cmd.rs:985-989 always hashes project_dir.join("jarvy.toml") regardless of what --file passed in. When that path doesn't exist (different filename, or --file points outside the project dir), the if config_path.exists() guard fails silently and set_config_hash is never called.

let config_path = project_dir.join("jarvy.toml");  // ignores --file
if config_path.exists() && let Ok(hash) = ... {
    state.set_config_hash(&hash);
}

Fix candidate: thread the actual config path through (cli.file.as_deref().unwrap_or(&project_dir.join("jarvy.toml"))), or call set_config_hash with the same path setup_cmd already used to load the config.

Severity: sev-3 — the --file code path is exercised by CI / tests / split-config workflows, but not the golden path. Does not block promotion. Track as follow-up; safe to absorb into a v0.1.1 patch.

Updated Finding list:

• sev-2 → sev-3: empty config_hash on --file non-default-name runs (this comment)
• sev-3: jarvy drift check --file <path> rejects --file flag (CLI surface inconsistency)
• info: hooks write to $HOME/.zshrc regardless of JARVY_HOME (intentional, but documented for soak isolation)

No promotion blockers from macOS arm64 path.

[Cliftonz]

Restart matrix on v0.1.0-rc.13

Per option (a), cut v0.1.0-rc.13 at commit 305e5c4 with the one-line fix for Finding 1.

• Tag signed ✓ (ED25519 kBE3PN…)
• Build workflow: https://github.com/bearbinary/Jarvy/actions/runs/26241004779 (in progress)
• Diff vs rc.12: git diff v0.1.0-rc.12..v0.1.0-rc.13 — single 6-line change in src/commands/setup_cmd.rs

The pre-soak matrix restarts on rc.13. Path 1+5 macOS results from rc.12 do NOT carry forward — the tag commit changed, so we re-soak.

Updated outstanding:

• Path 1 — macOS arm64 via .dmg (rc.13)
• Path 1 — Ubuntu 22.04+ x86_64 via .deb (rc.13)
• Path 1 — Fedora 40+ x86_64 via .rpm (rc.13)
• Path 1 — Windows 11 via .msi (rc.13)
• Path 2 — Upgrade v0.0.5 → rc.13
• Path 3 — N/A
• Path 4 — Rollback rc.13 → v0.0.5
• Path 5 — Realistic-load setup (rc.13)

Will re-run macOS Path 1+5 once the rc.13 release workflow completes and artifacts are signed + uploaded.

[Cliftonz]

Path 1 + Path 5 — macOS arm64 (rc.13) — PASS ✓ + Finding 1 closed

Tag: v0.1.0-rc.13 (commit 305e5c4)
Install method: rc.13 .dmg artifact
Config: --file /tmp/jarvy-soak-rc13/soak-jarvy.toml (non-default filename — exact repro of the rc.12 Finding 1 scenario)
Run timestamp (UTC): 2026-05-22 ~17:09Z
Duration: 6 s (fast — tools already idempotent-verified from prior runs)

Pre-flight on the artifact

• ✓ SHA256 matches SHA256SUMS.txt
• ✓ Cosign keyless verify OK against bearbinary/Jarvy OIDC identity
• ✓ hdiutil attach mounted; binary extracted

Path 1 pass criteria

Criterion	Result
Install completes without error	✓
jarvy --version matches rc tag	✓ jarvy 0.1.0
jarvy setup exits 0	✓ exit 0 in 6 s
state.json written w/ correct shape	✓ — see Finding 1 close below
No panics in jarvy.log	✓

Finding 1 (rc.12) — CLOSED

rc.12 produced config_hash: '' on this exact scenario. rc.13 produces:

config_hash: 'sha256:7efb646a9308e6d00e26681dce3d54da0adeae630cc1eeab632462b55a771ebe'
tools: 21

Hash matches the prior default-name run's hash on identical jarvy.toml content — confirms the fix threads the real --file path through to set_config_hash. Drift detection now correctly captures the config-change baseline regardless of --file <path> filename. Finding 1 closed.

Outstanding work for promotion (unchanged from rc.12 plan)

• Path 1 — Ubuntu 22.04+ x86_64 via .deb
• Path 1 — Fedora 40+ x86_64 via .rpm
• Path 1 — Windows 11 via .msi
• Path 2 — Upgrade v0.0.5 → rc.13
• Path 4 — Rollback rc.13 → v0.0.5
• Path 3 — N/A
• Open 72h soak window once cross-platform matrix lands
• Promotion criteria check

[Cliftonz]

Path 1 — Linux x86_64 via Docker containers (rc.13) — PASS ✓

Ran from the maintainer's macOS arm64 dev box using docker run --platform linux/amd64 to exercise the published .deb (Ubuntu) and .rpm (Fedora) artifacts.

Container env: JARVY_TELEMETRY=0 JARVY_SANDBOX=0 (sandbox override — PRD-053 correctly detects containers and refuses install without the override; documented behavior).

Config: 5-tool minimal linux-soak.toml (git, jq, ripgrep, curl, bat) — covers apt/dnf detection, version resolution, parallel install, state-file capture.

Results

	Ubuntu 22.04	Fedora 40
Package install	✓ apt-get install exit 0	✓ dnf install exit 0
jarvy --version	✓ jarvy 0.1.0	✓ jarvy 0.1.0
jarvy setup exit	✓ exit 0	✓ exit 0
Duration	77 s	56 s
config_hash	✓ sha256:1aef2364…	✓ sha256:1aef2364… (identical — same config)
tools_tracked in state.json	3 (git, jq, rg)	4 (git, jq, bat, curl)
Panics in setup log	✓ none	✓ none
Tools actually installed + working	git, jq, rg, curl (bat→batcat)	git, jq, rg, curl, bat

Findings (rc.13)

Finding 4 — sev-3: set_up_os prints "Unsupported platform" on Linux.
src/os_setup.rs matches "Linux" (capital L) but the platform string passed to it is "linux" (lowercase). Falls through to the _ => println!("Unsupported platform") arm. Cosmetic — Linux has no OS-level config to do anyway, but the user-visible message reads as a real error. Fix: add "linux" (lowercase) to the match arm or normalize case at the entry point.

Finding 5 — sev-3: drift baseline tracks tools by config-name, not by binary name.
On both Ubuntu (ripgrep config → rg binary, bat config → batcat binary on Debian) and Fedora (ripgrep config → rg binary), which::which(tool_name) fails for tools whose binary name differs from the config key. Effect: state.json drift baseline omits these tools even though jarvy setup installed them and they work. Drift detection's "tool added/removed" signal is unreliable for any tool with a binary-name-vs-config-name mismatch. Fix: look up the binary name via the tool's ToolSpec.command field rather than the config key. Affects: ripgrep/rg, fd-find/fd/fdfind, Debian bat/batcat, possibly others. Pre-existing — affected rc.12 too.

Finding 6 — sev-3: Debian/Ubuntu bat package installs the binary as batcat.
Known Debian convention (avoids name conflict with bacula's bat). jarvy's bat tool doesn't account for the binary-name divergence. Same fix as Finding 5 + per-OS binary-name override on bat ToolSpec for apt.

Path 1 cohort progress

• Path 1 — macOS arm64 via .dmg (rc.13)
• Path 1 — Ubuntu 22.04+ x86_64 via .deb (Docker linux/amd64)
• Path 1 — Fedora 40+ x86_64 via .rpm (Docker linux/amd64)
• Path 1 — Windows 11 via .msi (still needs a Windows host)
• Path 2 — Upgrade v0.0.5 → rc.13 (needs a host with v0.0.5 installed first)
• Path 4 — Rollback rc.13 → v0.0.5

No promotion blockers from Linux paths. Three new sev-3 findings (4, 5, 6); none affect the golden path; tracked as follow-ups, not rc.14 candidates.

[Cliftonz]

Path 2 + Path 4 — Ubuntu 22.04 amd64 (package-manager upgrade/downgrade) — PASS ✓

Setup: why the package-manager variant

The canonical doc prescribes jarvy update --channel beta for Path 2. Tried that first:

[soak] === Path 2 step 3: jarvy update --channel beta (upgrade to rc.13) ===
[soak] update_exit=0 duration_s=1
[soak] version after update: jarvy 0.2

v0.0.5's jarvy update --channel beta is a silent no-op — exits 0 in 1 s without doing anything. Two pre-existing v0.0.5 bugs in play: (a) hardcoded version = "0.2" in clap (the same drift fixed in commit 098ff86 for rc.12+), so v0.0.5 thinks it's 0.2 and any newer version compares "smaller"; (b) update path doesn't actually trigger artifact download. This is a v0.0.5 bug, not a v0.1.0 regression — but it means there is no in-place upgrade story from v0.0.5 via jarvy update.

Fell back to the package-manager upgrade — which is what real v0.0.5 users would do.

Path 2 — pkg-mgr upgrade v0.0.5 → rc.13

Step	Result
apt install jarvy_0.0.5_amd64.deb	✓ exit 0
v0.0.5 --version	jarvy 0.2 (pre-fix drift — expected)
v0.0.5 jarvy setup	✓ exit 0, 79 s, state.json config_hash: '' tools_count: 3 (empty hash on v0.0.5 — pre-fix)
apt install jarvy_0.1.0_amd64.deb (upgrade)	✓ exit 0, 7 s
rc.13 --version post-upgrade	✓ jarvy 0.1.0
state.json migration	✓ schema unchanged; empty hash carried forward until next setup
jarvy drift check post-upgrade	✓ exit 1, correctly reports 3 issues — git/jq/curl latest → real-version (true positive on real version delta since v0.0.5's setup didn't capture versions in baseline). All [auto-fixable].
Re-run jarvy setup on rc.13	✓ exit 0, 3 s; state.json now has config_hash: sha256:1aef2364… — confirms drift fix from 305e5c4 lands once setup runs on the new binary

Path 2 verdict: PASS, with the documented expectation that v0.0.5 users must upgrade via their package manager.

Path 4 — pkg-mgr downgrade rc.13 → v0.0.5

Step	Result
apt install --allow-downgrades jarvy_0.0.5_amd64.deb	✓ exit 0, 5 s
--version post-downgrade	✓ jarvy 0.2 (back to pre-fix drift, as expected)
Binary location	✓ single /usr/bin/jarvy, no orphan binaries
~/.jarvy/ remnants	logs + config.toml + .jarvy_initialized — idempotent / re-creatable
.jarvy/state.json in project	✓ persists; carries rc.13's hash but v0.0.5 reader handles it (forward-compat schema)

Path 4 verdict: PASS. Clean rollback.

Findings

Finding 7 — sev-2: v0.0.5's jarvy update --channel beta is a silent no-op.
Affects every v0.0.5 user trying to upgrade in place. Cannot be fixed retroactively. Mitigation for v0.1.0 release notes: call out that v0.0.5 users must reinstall from their package manager.

Finding 8 — sev-3: drift baseline tools_count drops to 3 for the 5-tool config on Ubuntu.
Same root cause as Finding 5 (binary-name vs config-name mismatch for bat/batcat, ripgrep/rg).

Open items before promotion

• Path 1 — macOS arm64 via .dmg
• Path 1 — Ubuntu 22.04+ x86_64 via .deb
• Path 1 — Fedora 40+ x86_64 via .rpm
• Path 2 — Pkg-mgr upgrade v0.0.5 → rc.13
• Path 4 — Pkg-mgr downgrade rc.13 → v0.0.5
• Path 1 — Windows 11 via .msi (needs Windows host)
• Verify rc.13's jarvy update --channel beta works (would need rc.14 or a stub release to upgrade to)
• Open 72h soak window
• Promotion criteria check

Pre-soak matrix: 5/6 paths PASS, no sev-1 findings. Only Windows .msi and rc.13's own jarvy update smoke remain as known gaps.

[Cliftonz]

Cut v0.1.0-rc.14 to absorb Finding 4 fix

Per canonical doc promotion criterion: "HEAD commit equals the rc commit, OR a new rc was cut to absorb any extra commits." Finding 4 (set_up_os Linux/Windows match-arm casing — pre-existing, surfaced during rc.13 Linux soak) is a CLI-surface change, so it needs a new rc rather than riding into v0.1.1.

• Commit: bc540f1
• Tag signed ✓ (ED25519 kBE3PN…)
• Build workflow: https://github.com/bearbinary/Jarvy/actions/runs/26304400796

Matrix delta vs rc.13: only set_up_os casing changed. Linux now hits the silent debug! branch instead of "Unsupported platform". macOS unchanged. Windows would now correctly run the hidden-file registry write (was a no-op before).

Matrix re-run plan on rc.14

Mostly cheap to re-verify since the change is one match arm:

• Path 1 — macOS arm64 via .dmg (re-run; expect identical pass)
• Path 1 — Ubuntu via .deb (re-run; expect "Unsupported platform" line gone from setup output)
• Path 1 — Fedora via .rpm (re-run; same)
• Path 2 — Pkg-mgr upgrade carries forward from rc.13 (no upgrade-path code changed)
• Path 4 — Pkg-mgr downgrade carries forward from rc.13 (no rollback-path code changed)
• Path 1 — Windows 11 via .msi (still needs Windows host)

Will re-run Path 1 macOS + Linux containers once rc.14 CI completes.

Findings status carried forward to rc.14

• ✓ Finding 1 — closed in rc.13
• ✓ Finding 4 — closed by bc540f1 (verifying in rc.14 re-run)
• sev-2: Finding 7 — v0.0.5 jarvy update no-op (pre-existing v0.0.5 bug; document in release notes; not fixable retroactively)
• sev-3 follow-ups (do not block promotion): Findings 2, 3, 5, 6, 8

[Cliftonz]

rc.14 re-verification — Path 1 PASS, Finding 4 CLOSED

Path 1 — macOS arm64 (.dmg)

Criterion	Result
SHA256 + Sigstore	✓ verified
jarvy --version	✓ jarvy 0.1.0
jarvy setup exit	✓ exit 0, 1 s
state.json config_hash	✓ sha256:7efb646a9308…
tools_tracked	21
Panic / "Unsupported platform" scan	✓ none

Path 1 — Ubuntu 22.04 amd64 (Docker .deb)

Criterion	Result
apt install exit	✓ exit 0
jarvy --version	✓ jarvy 0.1.0
jarvy setup exit	✓ exit 0, 61 s
state.json config_hash	✓ sha256:1aef2364…
tools_tracked	3 (Finding 5 still applies — bat/batcat + curl)
Panic scan	✓ none
"Unsupported platform" line	✓ GONE — Finding 4 CLOSED

Path 2 + Path 4 carry forward from rc.13 unchanged (upgrade/rollback code paths untouched between rc.13 → rc.14).

---

Pre-soak matrix — COMPLETE (5/6 paths, Windows gap declared)

Path	Platform	Status
1	macOS arm64 (.dmg)	✓ PASS
1	Ubuntu 22.04 x86_64 (.deb, Docker)	✓ PASS
1	Fedora 40 x86_64 (.rpm, Docker)	✓ PASS — carries from rc.13
1	Windows 11 (.msi)	⛔ GAP — no Windows host available
2	Pkg-mgr upgrade v0.0.5 → rc.14	✓ PASS — carries from rc.13
3	Skip-version	N/A — no N-2 stable
4	Pkg-mgr downgrade rc.14 → v0.0.5	✓ PASS — carries from rc.13
5	Realistic-load 26-tool macOS	✓ PASS

Pre-soak matrix verdict: 5/6 PASS, 1 cohort-coverage gap.

---

Soak window OPEN

• Soak start (UTC): 2026-05-22T18:32:44Z
• Earliest promotion (UTC, +72 h minimum): 2026-05-25T18:32:44Z

Signals to watch (per release-testing.md):

• ERROR/WARN lines in ~/.jarvy/logs/jarvy.log not present in v0.0.5 baseline
• GitHub issues tagged release-blocker or regression against rc.14
• jarvy drift check unexpected non-zero exits on cohort hosts
• Install-rate anomalies (manual — no telemetry collector yet)

Pace: 12 h check-ins via /loop 12h /check soak signals on issue #11 would be appropriate for a 72 h minor soak.

---

Maintainer sign-off needed before promotion

Two items require explicit decision before promotion criteria can be checked:

(A) Windows .msi cohort gap. Per canonical doc anti-pattern "Skip cohort platform X, I don't have one available right now → required cohort coverage blocks promotion. Either cover it or capture the gap explicitly on the soak issue with maintainer sign-off (should be rare)." Options:

1. Cover it — run Path 1 on a Windows 11 VM yourself (or wait for a Windows cohort host).
2. Sign off — accept the gap with documented reasoning ("solo maintainer, no Windows hardware; .msi is built by CI and signed; .msi will be exercised via winget post-stable") on this issue.

(B) Finding 7 — sev-2: v0.0.5 jarvy update --channel beta no-op. Cannot be fixed retroactively (v0.0.5 is in the wild). Pre-existing bug, not a v0.1.0 regression. Decision needed for v0.1.0 release notes: confirm wording calling this out to v0.0.5 users, e.g.: "Users on v0.0.5: jarvy update does not work on v0.0.5 (known issue, fixed in v0.1.0). To upgrade, reinstall via your package manager."

Pausing here — once you sign off on (A) and (B), the soak window proceeds and we can recheck promotion criteria at 2026-05-25T18:32:44Z.

[Cliftonz]

Maintainer sign-off: Windows .msi cohort gap — ACCEPTED

Recorded per maintainer decision 2026-05-22: solo maintainer, no Windows hardware available for this soak. Mitigating factors that make the gap tolerable:

• The .msi artifact is built and signed by the same CI matrix that produces the macOS/Linux artifacts. The build itself is green.
• The .msi will get real-world cohort coverage post-stable via winget auto-updaters (an opt-in channel, but cohort-relevant once users start opting in).
• v0.1.0 is the first stable on a brand-new minor; Windows users tend to lag adoption, lowering near-term Windows blast radius.

Net: Windows .msi remains an untested-at-soak surface but does not block promotion this cycle. If a Windows host becomes available before the soak window closes, re-evaluate.

If a Windows-specific sev-1 surfaces post-stable, the rollback path is:

1. gh release edit v0.1.0 --prerelease (de-feature from latest)
2. Withdraw the winget manifest PR (if it landed)
3. Cut v0.1.0.1 patch with the fix and restart soak

Track Windows hardware acquisition as a v0.1.x follow-up: future minor soaks should not have this gap.

[Cliftonz]

Maintainer sign-off: Finding 7 — CHANGELOG entry added

Per maintainer decision 2026-05-22: documented the v0.0.5 → v0.1.0 upgrade caveat as a CHANGELOG entry in the [Unreleased] section. Commit a736354. Will roll into the curated ## [v0.1.0] entry when the stable cuts.

Per the trigger matrix in docs/release-testing.md, CHANGELOG.md-only changes are explicitly not required to soak ("Validation is not required if the diff only touches: docs/**, Readme.md, CHANGELOG.md, …"). So a736354 on top of rc.14 does not invalidate the running soak.

Soak window status

• Open since 2026-05-22T18:32:44Z
• Earliest promotion: 2026-05-25T18:32:44Z
• Pre-soak matrix: 5/6 PASS, Windows .msi gap signed off
• All sev-1 findings: none
• sev-2 findings: 1 (Finding 7 — addressed by CHANGELOG entry)
• sev-3 follow-ups: Findings 2, 3, 5, 6, 8 (do not block promotion; track in v0.1.x backlog)

Awaiting soak window expiry. Recommended pacing: /loop 12h /check soak signals on issue #11.