Build log
ChaseOS Studio V1.0.8: proving the updater from an older install
Why a new version number was not enough—and how installer identity, public delivery and the real in-app update notification were verified as one release contract.
Journey 2026-08-20 → 2026-08-25
Source: Public ChaseOS release feed and download surface, with privacy-screened release and updater verification
- Signed build accepted
- Public release
- Build identity
20260824-233115-4b2e3974
Technical bibliography record
The build, in five parts.
- 01 Built
- A published Studio V1.0.8 Windows release with an immutable installer, canonical release feed, download route and prior-install update notification.
- 02 Process
- Package, hash and size checks were joined to public redownload verification, browser QA and a real updater run from an older installed version.
- 03 Learned
- Version equality does not prove artifact identity; the feed, download and executable contract must all describe the same installer.
- 04 Skills
- Windows packagingupdate systemsrelease manifestsCloudflare deliveryinstalled-runtime QA
- 05 Saved
- The manifest, immutable artifact identity, test results, public readback and exact user-facing update state required to reproduce the acceptance decision.
Visual QA and product evidence
See the milestone, not only the summary.
Exactly what was built#
Studio V1.0.8 was packaged as a Windows release, exposed through the canonical public feed and download surface, and made discoverable to an existing installation through the application's updater. The release contract identifies one immutable installer across the feed, the downloadable artifact and the update path rather than treating those as loosely related files.
The process#
The candidate was built in an isolated release workspace, checked with focused release and website tests, measured by byte length and SHA-256, and downloaded back from the public route for comparison. Browser QA checked the human-facing download state. The decisive acceptance step then ran the shipped updater code from a prior installed version and confirmed that Studio reported the new release as available inside the application.
What we learned#
A website saying V1.0.8 and an installer carrying V1.0.8 can still describe different payloads. Release confidence comes from matching identity, length, hash, manifest meaning and installed behavior. Misleading duplicate labels should be corrected in the interface without changing the compatibility contract older updaters depend on.
Skills gained#
The release sharpened Windows packaging, updater compatibility, immutable artifact delivery, manifest design, Cloudflare publication, installed-version acceptance and browser-visible release QA.
What was saved#
The retained evidence includes the canonical feed state, installer identity, public delivery checks, focused tests, browser review and the exact update-available result from the older installation. Those records make the next release a repeatable contract rather than a checklist remembered from the previous one.
Into the knowledge loop#
The durable lesson is stored as a release pattern: artifact and executable identity must remain aligned, public redownload is a separate proof state, and an existing install must see the real notification. Future release harnesses can retrieve and enforce that pattern while still requiring human approval for publication.
State repairs that shipped in V1.0.8#
Notification ages, read state, dismissal and acceptance moved into a durable local ledger so old suggestions stopped returning as newly created. Pulse separated current recommendations from decision history, Setup restored recent and default workspace management, and Intake or Research proposals gained inspectable graph destinations. This work began after V1.0.7 was public, so it is recorded here rather than backdated into that release.