6 Commits

Include renames

Author	SHA1	Message	Date
Bryan Van Deusen	6e524ec616	guard: an empty channel killed the lane instead of passing it ... The first merge to `main` took the Android lane down (run 4857): the decide job exited 1 in 0.16 seconds with no output at all, and the image build skipped behind it because a failing lane must not publish. `stable` had never published an APK, which the guard treats as a pass — there is nothing to go backwards from, and `[ -z "$published" ]` says so in a branch of its own. That branch was unreachable. `published="$(published_for ...)"` under `set -e` dies on the substitution before it, and everything the pipeline would have printed goes into the capture rather than the log. What decided which lookups had the bug is the last command in the pipeline. `sed` on empty input exits 0; `grep` exits 1. Three of the four end in `sed`. Android's version_code ends in `grep -oE '[0-9]+$'`, so it was the only one — and only on a channel with nothing on it, which is why a week of dev pushes never saw it. The tests now reach the half of the guard that talks to a feed, with `curl` shadowed on PATH so they stay hermetic: an empty channel passes and builds, a lower published version passes, a higher one fails the lane, and an equal Android code is refused because Android will not install it.	2026-08-29 13:45:26 -04:00
bvandeusenandClaude Opus 5	c2fdc05e5c	release: a tag builds nothing and carries a changelog instead ... Step 7 of M314, the last one. Rule 22 — the old path comes out completely. ## A release stops building `desktop.yml` no longer triggers on `v*`, and its two `Publish release` steps are gone. `ci.yml` lost its tag trigger in step 6. So a tag now reaches exactly one lane: the new `release.yml`, which builds nothing. That is not a simplification for its own sake. The merge to `main` already published everything a user can receive — `:latest` + `:<sha>`, both channel feeds, the updater manifest. A tag rebuilding that source produces identical artifacts under identical names and re-pushes `:<sha>` with different bytes, which rule 145 forbids even when they match. ## So what a release is FOR The changelog (note 3127 §5). Two halves to "what am I running", and the version answers only the first: which build is this (the footer, /api/config, the APK's versionName) and what is in it that was not in the one I ran last month (nothing, until now). `packaging/release-notes.sh` derives it from git rather than a hand-maintained CHANGELOG, which drifts into recording what someone MEANT to ship. Capped at 60 entries with the omitted count stated — the first dated release spans 181 commits since `v0.1.0`, and a truncated list that does not say it is truncated is a lie. It publishes through `publish-release.sh` rather than making its own API calls, for the create-or-PATCH-on-409 path: a fixed-tag release that only ever POSTs keeps whatever body its first run wrote, which is #2182, and reimplementing that correctly in a second place is how it comes back. ## Retired `MANIFEST_TAG` and the whole branch behind it. It let the manifest live on a `stable` pointer release while the bundles sat on a versioned one — a split step 3 removed when `stable` started holding its own bundles. Nothing had passed it since; a parameter that can only ever receive its own default is a branch nobody exercises and a comment that goes stale, and its stale text was still telling readers the installable builds live on the versioned releases. `desktop/src-tauri/Cargo.toml`'s version and `thoughtsync/__init__.py`'s both now say out loud that they are not shipped values. The Cargo one carries the history worth keeping: the old scheme took its base from that line, so `0.2.<run>` on dev outranked a bare `0.2.0` on main, and the remedy was "remember to bump the minor before tagging" — documented in a comment, enforced nowhere. #2183 is what that looked like in the field. **That ritual is now formally dead**, and this is the deliberate act of killing it rather than a side effect. ## Still there on purpose `install.sh`'s transitional stable fallback. It cannot go until `main` has published to `stable` at least once, and that is gated on an operator request. Removing it now would break the DEFAULT install channel. #3147 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 00:43:21 -04:00
bvandeusenandClaude Opus 5	22a9a279b1	ci: one definition of what ships decides both the version and whether to build ... Step 6 of M314. Two changes that only make sense together. ## The image tag set rule 145 mandates dev push -> :dev main push -> :latest + :<sha> a v* tag -> nothing; the trigger is gone `:<sha>` was going out on EVERY branch — a rollback target nobody has ever pulled, accumulating forever, for a channel whose entire contract is that it moves. It is on main only now, where rollback matters and where gated merges (rule 2) make it dozens per year rather than one per push. No version-shaped image tag in any lane. Verified the way rule 145 asks — by looking for a CONSUMER, not for whether one is imaginable: `docker-compose.yml` is parameterised for a pin and the docs describe the option, but no compose file, deploy script or CI job reads one. ## Skip-if-exists, adapted, because §4 assumes a registry §5 removed Note 3127 §4 says to ask the registry whether that exact version exists. There is no `:<version>` tag to ask about any more. What there IS, for both clients, is a channel that publishes the version it serves — and that answers the same question: if the channel already serves what this source derives, the artifact would be byte-identical. So the `paths:` filters are gone from the desktop and Android lanes, replaced by a `decide` job reading the real file set. That duplication is not theoretical: `packaging/` was added to the sets and not to the filters, so the commit that fixed a derivation bug never ran on the two lanes it fixed (85ead4d). One definition, one reader. The cost is that both workflows now start on every push rather than a matching one — a ~15s container for a decision, against a lane that cannot silently fail to run. ## The server always builds, deliberately Its image is ~15 seconds against 6 and 9 minutes for the clients, so there is little to save. And always building is strictly BETTER for something that can face the internet: it picks up `python:3.12-slim` base updates on every push. That also dissolves §4's base-image tension for this project rather than deciding it — the artifact most exposed to base staleness is the one that never skips. Resolving a base digest at derive time was the alternative and it is forbidden: §7's corollary bars an external lookup, because two lanes would then derive different values for one source. ## The guard runs on the skip path It moved into `decide`, ahead of the decision. §6.3 is explicit that skipping because "this version already exists" is indistinguishable from "we derived a stale value that happens to match" unless something checks. It also now runs once per lane instead of once per job. ## Two defects found while wiring this `ci.yml`'s gate greps a path list that MUST match Android's file set, and `packaging/` was missing from it. A packaging-only push would have had the Android lane build and dispatch while the gate ALSO let the image through — two images for one commit, and on main a second push of the same `:<sha>` with different bytes. Rule 145's exact prohibition. `guard-forward.sh` ends every fetch in `|| true`, so a runner image without curl would have read as "nothing published yet" and passed without checking anything. Missing curl is now fatal. #3146 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 00:19:16 -04:00
bvandeusenandClaude Opus 5	0ab7d94294	versioning: refuse to publish a version below what the channel already serves ... Step 5 of M314, note 3127 §6.3. Everything else in this milestone derives a number and trusts it; this compares the derived value against what the channel is actually serving and fails the lane if it went down. Too-low is the unrecoverable direction: every installed client reports "up to date" forever, and no later build fixes it until one climbs back above the bad number. #2183 and #2993 are both that symptom. ## Two hazards, two mechanisms A shallow clone is now tested DIRECTLY, in `version.sh`, via `--is-shallow-repository`. The empty-result guard only caught the case where nothing matched — and run 4796 showed the worse one, where a partial match returned a real six-days-stale answer. Asking the question outright costs no network and covers artifacts with nothing published to compare against. `guard-forward.sh` handles the rest: a squash or rebase merge rewriting the committer date, a rebuild of an older commit, and clock skew between runners. ## The comparison is per artifact, and the operator differs desktop derived >= published commit time, so equality is the ORDINARY no-change case and `<=` would fail every build that changed nothing android derived > published build time, so equality means two builds in one minute — and Android refuses to install an APK whose versionCode does not RISE The server is deliberately unguarded: nothing compares its version, `:latest` moves regardless, and rule 145 removed the version tags that would be the published list. A too-low value there is a wrong date in a footer, not a stranded client. It still gets the shallow-clone check. ## Proved to fire, not assumed Cloned the repo, checked out a commit eight back, ran the guard against the LIVE dev feed: at the tip derived 1.0.3502151, published 1.0.3502151 -> pass eight back derived 1.0.3501535, published 1.0.3502151 -> FAILS android tip derived 3502171, published 3502152 -> pass stable derived 1.0.3502151, published 0.2.0 -> pass That last row is worth keeping: stable still advertises the bare `0.2.0` from the old Cargo.toml scheme, so the transition orders upward on BOTH channels, not just the one being exercised. A channel with nothing published passes rather than failing — otherwise the first publish to a new channel could never happen. The guard runs BEFORE the build in all three lanes, so a bad derivation costs seconds rather than a five-minute compile and a publish to undo. `compare` is exposed as an explicit mode so the ordering is testable without a network and inspectable without a push — 16 cases including `1.0.9 < 1.0.10`, which a string compare gets exactly backwards. #3145 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 21:33:00 -04:00
bvandeusenandClaude Opus 5	85ead4d66b	versioning: anchor at the repo root — a pathspec is relative to the caller's cwd ... Three failures on c504433, two root causes, and the interesting one is that `git log -- <paths>` resolves pathspecs against the CURRENT DIRECTORY. Callers run from wherever suits them: the desktop build from `desktop/src-tauri`, the Android build from `android`, the manifest job from the root. So one push produced THREE versions: desktop build 1.0.3494522 <- six days stale pacman packager 1.0.3502131 manifest job 1.0.3502131 The build's pathspec had matched `desktop/src-tauri/Cargo.toml` — a real file — so git answered with the newest commit touching THAT. Non-empty, so the shallow-clone guard could not fire; the manifest then found no bundle matching its own answer and the lane went red two steps from the cause. The Android job failed loudly in the same run only because ITS pathspec happened to match nothing from `android/`. Same bug, luckier symptom. The script `cd`s to `git rev-parse --show-toplevel` before doing anything now, and the test asserts every artifact answers identically from four directories. ## And a third instance of the trap that bit yesterday The unit test caught it: `version.sh display nope` printed "unknown artifact" to stderr and then answered `2026.08.28.0900` with exit 0. `paths_for` is reached through `$(paths_for "$1")`, so its `exit 2` ended the subshell, returned an EMPTY pathspec — and an empty pathspec matches everything. That is now three occurrences of one mistake in one file: the shallow-clone guard on `key` (emitted `1.0.-26297280`, exit 0), the same guard on `display` (which failed only because `date` then choked on the empty string), and this. Each was found by a different mechanism and none by reading the code. The artifact is validated in the parent shell now, and the file says so where the next guard would be written. Both tests assert on STDOUT as well as the exit code. The exit code alone passed for `display nope` while stdout carried a lie. #3144 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 21:03:04 -04:00
bvandeusenandClaude Opus 5	c5044339a1	versioning: each artifact derives from its own files, with the clock picked per value ... Step 4 of M314. `desktop/packaging/build-version.sh` was one generator feeding the desktop bundles AND the Android APK off `GITHUB_RUN_NUMBER`, so a Kotlin-only commit re-versioned the desktop and a Rust-only commit re-versioned the phone. Note 3127 §3 cites this repo as its example of that failure. It is replaced by `packaging/version.sh` — one definition of HOW to derive, three file sets, and the sets in one place. Lives at the repo root rather than under desktop/, because it serves three artifacts now and a shared thing filed under one consumer ends up owned by it. ## Two values, and the clock chosen per value (§2) desktop key 1.0.<minutes since 2020-01-01> commit time desktop display 2026.08.28.0900 commit time (#3181 shows it) android versionName commit time android versionCode <minutes since 2020> BUILD time server version 2026.08.28.0900 commit time, no ordering key Every human-readable version in the repo is now one shape. The two exceptions are not version names at all — they are bare monotonic integers a comparator reads and nobody quotes. The desktop needs a separate key because Tauri parses `latest.json` with the semver crate and `2026.08.28.0900` fails it twice (four segments, and `08` is a leading zero). `1.0.` and not `0.0.`: the minor has to clear the installed `0.2.466` line or every dev user is stranded on "up to date" permanently. Android's code comes from BUILD time while the desktop's key comes from COMMIT time, deliberately. Android hard-fails a downgrade with INSTALL_FAILED_VERSION_DOWNGRADE and leaves a channel you cannot get out of, so its key must be monotonic by construction; the desktop merely declines to offer an update, which a guard can catch. ## The bug this found in itself The shallow-clone guard `exit 1`-ed inside a function called as `$(...)` — which ends the SUBSHELL, not the script. `display` still failed, but only because `date` then choked on the empty string. `key` printed the error to stderr, emitted `1.0.-26297280`, and exited ZERO. That is precisely the failure the guard exists to prevent: a too-low version on a green lane, and too-low is the direction you cannot recover from. It resolves into a global in the parent shell now. The test is parametrized over both requests, because one path was covered and the other was broken in exactly the way the covered one was meant to rule out. ## Also `fetch-depth: 0` on every job that derives — four of them, and only ci.yml's gate had it. Depth-1 is silently wrong rather than loudly broken (§6.1). The file sets include each artifact's BUILD RECIPE (its workflow, and `packaging/`). A workflow file is not shipped, but change a Gradle flag and the bytes change while the source does not — and once step 6 skips a build whose version already exists, that serves the OLD artifact on a green run. The base images are deliberately NOT resolved at derive time: that is an external lookup, which §7's corollary forbids. `Dockerfile` is already in the server's set, so pinning `FROM` by digest in step 6 puts the base inside the set for free. `build-version.sh` is deleted, its last consumer (the pacman packager) moved over, and the one finding worth keeping out of its header — why not a `-dev.N` prerelease — is preserved in the successor. #3144 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 20:51:39 -04:00