GCLO: the installed application is the product
A repository-management tool has two jobs: help someone work across codebases, and arrive on their machine in a form they can trust to run and update. The second job is easy to underestimate because it lives outside the main application workflow. GCLO's release history makes that boundary unusually concrete.
CTO to Human: what the history tells us
The July 1.0 release provides an initial stable marker. October then includes a withdrawn 1.0.1 release and its 1.1 successor. Keeping the failed release in the record matters: its current warning identifies missing WinUI theme resources and says not to install it. A retrospective should preserve that warning rather than turn the version list into a recommendation list.
Engineer to Engineer: the boundary that matters
A published desktop build can differ materially from the build a developer just ran. Resource indexing, startup, binary replacement and user-data placement all belong to the delivered artifact's contract. Separating user data from the installation folder protects a different boundary from fixing startup resources, even when both changes arrive in one release sequence.
Milestones in the public record
- 2026-07-05 — GCLO reaches its 1.0 release. GCLO 1.0 established a stable release marker for the Windows repository-management application. It followed the July beta sequence, which developed the account and workspace experience. Project journal.
- 2026-10-10 — A withdrawn GCLO release makes packaging part of the story. GCLO 1.0.1 is a historical release that should not be installed. Its current release notes identify a startup crash caused by missing WinUI theme resources and point readers to 1.1.0. Project journal.
- 2026-10-11 — GCLO 1.1 repairs the delivered application boundary. GCLO 1.1 is the stable successor identified by the withdrawn 1.0.1 release. The release history includes packaging fixes and moving user data out of the installation folder. Project journal.
The lesson is to evaluate the thing the user receives. A successful compilation is useful evidence, but it cannot stand in for installing, starting and updating the packaged application. That is the standard I want the project journal to make visible.
Retrospective written on October 12, 2026, covering the public evidence available for October 12, 2025 through October 12, 2026. Linked journal entries use source event dates; this essay is a newly written retrospective. Quiet months do not imply an unrecorded release, and short-lived projects are not presented as having a full year of activity.