45 Commits

Include renames

Author	SHA1	Message	Date
Bryan Van Deusen	ff6e99eb62	image: bake every client in, not just the phone ... ~104 MB on top of ~85 MB, almost all of it the AppImage. That is what the product being complete costs (rule 23): a self-hoster gets a working app for their machine from the server holding their notes, with no account on a forge that is private. The AppImage is not optional within that — it is the only bundle that can replace itself in place, so a server without one cannot serve in-app updates to anybody. `packaging/fetch-clients.sh` replaces the inline fetch and writes the fixed names and sidecars `client_dist.py` reads. It never fails: a platform with nothing published means the server advertises nothing for it and the UI hides that download, and eight fetches must not become eight ways to redden a green lane. THE VERSION IS FETCHED, NOT DERIVED, and this is the part that would have been wrong the easy way. The obvious shortcut is `version.sh display desktop` in the image job — it has the checkout. But this commit may not be the commit the channel is serving: a push touching only `src/` does not rebuild the desktop, so the channel still holds an older build and a locally-derived version would describe those bytes with this commit's number. `client_dist.py`'s size check could not catch it, because size IS measured from the real file — it would sail through and lie about the version alone. So `write-manifest.sh` now publishes `thoughtsync-desktop.json` beside `latest.json`, from the same two values in the same breath, and only size/sha256 are measured at bake time. Which needed the prune's keep-list, or the sidecar would have been uploaded and deleted again in the same run — a fixed name is self-limiting, which is exactly why that list exists. `version_code` is NOT uniformly an integer, and coercing it was a leftover from the days when Android was the only platform. Android's must stay a JSON number: `ClientRelease` in core declares it `i64` and a string fails to deserialize on every phone in the field. The desktop's is Tauri's semver key `1.0.<minutes>` — the value its updater actually compares — and `int()` would have rejected every desktop sidecar CI writes. The table now says which is which, and tests pin both directions. Also retires the comment above the fetch step, which claimed the APK came from "always the rolling dev release" and mentioned `:<version>` images. M314 step 3 made the channel conditional in the code directly below it, and step 6 removed version-shaped image tags entirely. Verified against the live dev channel before pushing: the Android half resolves and exits 0, the desktop half degrades with a warning because the sidecar does not exist yet, and all five constructed bundle filenames return 200.	2026-08-30 13:11:04 -04:00
Bryan Van Deusen	f992439588	version: every surface can say which build it is, and two of them were lying ... Note 3127 §5 removed version tags, so an artifact's self-report is now the only answer to "which build is this?" — and nothing exists to contradict it when it is wrong. Three surfaces gain a dim build line: the foot of the web rail, the login screen, and the foot of Sync on Android. The login screen because "I can't sign in" is a bug report like any other, and requiring an account to read a build number withholds it from exactly the people who can't get past that page. `/api/config` is already public. Two of the values it was going to show were wrong, which is the part worth knowing about. The DESKTOP reported `env!("CARGO_PKG_VERSION")` from `config_get` and from the startup log. `cargo tauri build --config '{"version": ...}'` overrides tauri.conf.json, not Cargo's own metadata — so both read the literal `0.2.0` in Cargo.toml, on every build ever shipped. They now read a display version baked in by the lane through `option_env!`, hoisted to the crate root because two readers of one fact is how this repo keeps producing 2181-2183. Not the ordering key either: `1.0.<minutes>` is the opaque value Tauri's updater compares and must never be shown to a person, and `update.rs` still reads it because a comparator is exactly what it is (rule 149). The SERVER fell back to `__version__` when APP_VERSION was absent, so a server run from a checkout reported `0.2.0` — a real-looking version naming no build anybody could obtain. `__init__.py` already asserted the honest answer was "APP_VERSION being missing, which app.py already handles"; it did not, and a comment claiming a behaviour two files away is how that stayed true-sounding. Now an explicit "unknown", with the packaging version left where "unknown" is not a legal value. Android reads the INSTALLED package's versionName rather than BuildConfig, so it reports what is actually on the phone. Everything renders "unknown" rather than blank when it cannot say. A blank looks like a layout bug; a plausible default cannot be caught by anything. build.rs gets `rerun-if-env-changed` for the baked value: cargo does not track an `option_env!` variable on its own, and the desktop lane having no cache today is what makes that easy to forget the day one is added.	2026-08-29 23:07:29 -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	fa43c2f4e9	ci: a docs-only merge to main produced no image, so no :<sha> for that commit ... Rule 145 promises every push to `main` publishes a `:<sha>`, so any production commit is addressable without a release ceremony. `ci.yml`'s `paths:` filter quietly broke that: a commit touching only docs never triggered the lane, so that commit had no image and no sha tag. Pre-existing — the filter has always been there — but it is rule 145's guarantee and step 6 is where the tag set is being made to match the rule, so it is this step's to close. Confirmed live on a0c789b: a docs-only push produced two runs, both client lanes skipping correctly, and NO image at all. The server image now always builds. It is the cheap one — ~15 seconds against 6 and 9 minutes for the clients, which is exactly why they skip and it does not — and always building is what keeps `python:3.12-slim` fresh on something that can face the internet. That is also why §4's base-image tension does not bite this project: the artifact it would apply to is the one that never skips. #3146 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-29 00:32:27 -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	6e891357ff	ci: the deriver is in the file sets but was not in the path filters ... `85ead4d` changed `packaging/version.sh` — the script that decides what every artifact claims to be — and the desktop and Android lanes did not run at all. Only CI & Build fired, and only because it happens to watch `tests/**`. So the fix in that commit is unverified on exactly the two lanes whose bug it was fixing. `version.sh` lists `packaging` in all three file sets; the workflows' `paths:` filters did not. Two places holding one decision, with one of them updated — the failure this subsystem keeps producing (#2181-2183, and again in step 3 where `install.sh` still expected stable's bundles on a versioned release). The script's own header already warned about this: "a change here that is not mirrored there means a lane that does not fire — check both." Written, then not followed, in the same commit. Step 6 removes the duplication for real by replacing these filters with skip-if-exists. This is the stopgap until then, and it says so at each site. #3144 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 21:11:26 -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
bvandeusenandClaude Opus 5	c268ae4f23	ci: main publishes, so a tag stops being required — and :latest stops shipping a dev client ... Step 3 of M314. Note 3127 §0's diagnostic is "is `main` publishing sufficient for a user to receive the build" — and here it was not. The desktop and Android lanes BUILT on main and published nothing: `Publish release` was gated on `refs/tags/v*`, the channel publishes on `refs/heads/dev`, the manifest job on dev-or-tag. So the stable channel moved only when somebody cut a tag, which made a `v*` tag load-bearing rather than the optional bookmark the model wants. Both channels are rolling fixed-tag releases now. `dev` from dev, `stable` from main, same machinery — `publish-release.sh` already took RELEASE_TAG, `write-manifest.sh` already pruned, and both already PATCHed a stale description on 409 (#2182). This is wiring, not new mechanism. ## The defect this carried `ci.yml`'s "Fetch the Android client to bake in" read `releases/download/dev` UNCONDITIONALLY, on every branch. Every image baked in the dev APK — `:latest` included — so a stable server served a dev-channel client to anyone who downloaded it from there. That has nothing to do with versioning; it is fixed here because this is the step that finally gives `stable` an APK to point at. It also means Android needs no channel machinery of its own. The APK is served FROM the image, so the channel is already a property of which image you run — note 3127 §7's "nothing to hand off" shape, arrived at here by accident. One branch-conditional line, not a second channel in `client_dist.py` as this milestone first assumed. ## The break this nearly shipped `install.sh --channel stable` read the version out of `stable/latest.json` and then fetched `releases/tags/v<version>` for the bundles — correct while stable was a manifest-only pointer, and broken the moment stable holds its own. Stable is the DEFAULT channel, so `curl … | sh` would have failed for everyone between this commit and the first merge to main. Both channels are one lookup now: fetch the fixed-tag release, install what is on it. A transitional fallback covers the window where `stable` still has no bundles, marked for deletion in step 7 — without it the default channel is broken for however long it takes to merge, and that window is gated on an operator request rather than on this lane. ## The two writers problem `stable`'s manifest was written by tag builds. It is written by main now, and the tag path stops writing it — two writers for one channel is a race with no winner worth having. A `v*` tag still writes its own versioned manifest; its build consequence goes entirely in step 7. Also corrected: `update.rs`'s header still described stable as following `v*` tags. Nothing in that file moved — it only ever read `<channel>/latest.json` — but the comment was a lie, and it is the file somebody reads to understand the feed. #3143 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-28 18:22:31 -04:00
bvandeusenandClaude Opus 5	77c5422951	ci: a failing lane must not publish an image ... build gated on lint + typecheck only, so run 4293 failed its test lane and pushed :dev and :09b5f87 regardless — the deployed server was running a build whose tests were red. The comment justified this by saying DB-backed testing happened manually against the dev image rather than on every push. That was true when it was written and stopped being true at 6f21db8, which added the integration lane. The reason went away; the exception didn't. Gate on test and integration too. A :<sha> image is the rollback unit for its commit (family rule 46) — one publishable from a failing run is not something you can roll back to. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-23 16:52:59 -04:00
bvandeusen	6f21db85a1	ci: an integration lane, so the migrations are finally run by something ... 26 Alembic revisions and none had ever been executed by CI. `alembic upgrade head` ran for the first time when the operator's container started, and the schema the migrations build had never been checked against the models that read it. M13 dropped three columns and rebuilt a STORED GENERATED column with nothing watching but a server boot. Copied from FabledScribe's `integration` job, which had already solved the parts that are easy to get wrong — and which are family rules precisely because they were: a separator-free job key with no `name:` (act_runner derives the service container name from the truncated display name, and the discovery step filters `docker ps` by it), bridge-IP resolution because service hostnames aren't routable on this runner, and a Python readiness wait because `run:` is busybox sh with no `/dev/tcp`. `postgres:16-alpine` to match the production compose. The schema is built by real migrations, never metadata.create_all — that step IS the migration test. Six tests, each pinning something that has only ever been checked by hand: - an ORM insert against the migrated schema, which is the model/migration agreement nothing has verified until now; - `notes.title`, `notes.kind` and `note_revisions.title` are actually gone, and `note_links` with them — a silently no-op migration shows up here; - the rebuilt `search_vector` indexes both the name and the body, which matters because 0026 had to DROP and recreate a generated column rather than alter it; - a note keeps its body AND its items, the shape step 2 made normal; - `_apply_note_items` leaves items alone when a change doesn't mention them — the data-loss path step 2 removed, pinned so its return would be caught; - a note with no body is still named by its first item, the hole that made removing the title unsafe until checklists stopped being their own kind. Runs for visibility; does not gate the build, matching `test` and Scribe. No local equivalent: running it means standing up Postgres on the workstation, which rule 12 reserves for an explicit request. Documented in ci-requirements alongside the Rust, Kotlin and frontend gates.	2026-08-23 00:24:57 -04:00
bvandeusen	0cf77336d4	ci: build the server image after the Android lane, not alongside it ... Baking the newest client into every image left two holes, both raised by the operator. **An Android-only push never rebuilt the image.** `ci.yml` does not trigger on `android/**`, so a new APK could be published and no image would ever pick it up until some unrelated server change came along. **A push touching both raced.** Both workflows start at once; the image build would fetch the PREVIOUS client and there would be no second build to correct it — `:<sha>` is the immutable rollback unit (rule 46), so rebuilding it with different content would make it neither immutable nor a rollback unit. Ordering now runs the other way: the Android lane finishes, then calls the image build. `ci.yml` gains a `gate` job that stands down on any push touching the Android app, and `android.yml` dispatches `ci.yml` when it is done. One image per commit, containing the client from that commit. Cases: - **server only** — ci builds immediately; the newest published client is already the right one. - **Android only** — ci does not trigger at all; the Android lane dispatches it afterwards. - **both** — ci's push run stands down, the Android lane dispatches it. Exactly one image. - **tag** — always builds. The Android lane does not run on tags, so waiting for a call that never comes would mean a release tag with no image. The dispatch is `always()`, so a FAILED Android build still lets the server image through with the previous client. The alternative is a broken Android lane silently blocking server delivery, which is a worse failure than a slightly old APK. Two details that would each have made this quietly wrong: The gate diffs the whole PUSHED RANGE (`event.before..HEAD`, full fetch), not `HEAD^..HEAD`. A three-commit push whose Android change sat in the first would otherwise have looked Android-free and raced anyway — silently, which is the worst version of this bug. The dispatch is `curl -fsS`, not `|| true`. If that call ever stops working the symptom is server images silently never being built for Android pushes, which nobody would notice until wondering why the app stopped updating. The gate's path list has to match android.yml's trigger, and two places holding one decision is the recurring failure in this repo (issues 2181-2183). It is a `git diff` rather than a config precisely so the decision is visible in the log, and both sides carry a comment pointing at the other.	2026-08-20 21:46:05 -04:00
bvandeusen	010e9a2f85	server: bake the newest Android client into every image (operator call) ... Reverses the placement decision made an hour ago. That one put the APK only on the data volume, reasoning that ~55 MiB should not be charged to installs that never touch Android. The operator's call is that ending the manual copy is worth the megabytes, and it is their deployment. CI now fetches the newest published client into the build context immediately before the image build, so `:dev`, `:latest` and `:<version>` all ship one and a `docker compose pull` delivers a new server and a new client together. **Always the rolling `dev` release — the newest build there is.** A versioned image therefore carries the newest client rather than one pinned to that version. Deliberate: the two negotiate a sync protocol version before linking, so a mismatch is caught by the handshake, and pinning would buy nothing the handshake does not already provide. **Fetched by the JOB, never by the Dockerfile.** The release is private, and a token used inside a build ends up in the context or a layer. **It cannot fail the image build.** No release yet, a network blip, a first-ever build — all of them log a warning and produce an image with no client, which is a state the server already supports. Half a pair is cleaned up rather than shipped: a sidecar without its APK is worse than neither, because the server would be describing something it cannot serve. **The volume still wins.** `DATA_DIR/client/` is checked first and the baked copy second, so an operator who deliberately drops a build in gets that build — and a BROKEN drop-in falls through to the image's copy rather than taking the feature offline, which is what makes the copy-order advice survivable instead of load-bearing. Three tests cover the precedence, including that last case. The baked copy lives inside the package, not under DATA_DIR: that path is a volume mount, and anything the image wrote there would disappear behind it the moment one is attached. `client/.keep` is tracked so `COPY client/` cannot fail on a tree where the CI step never ran; the artifacts themselves are gitignored, since a 55 MiB binary does not belong in git history and is re-fetched on every build anyway.	2026-08-20 21:19:47 -04:00
bvandeusen	d77a79859c	server: hand out the Android client this server syncs with (2726) ... A self-hoster should not need an account on someone else's forge to get the app for their own notes. The Fabled-Git instance is private — which is why `install.sh` already cannot fetch for anyone but the operator — so a release page is no use as a distribution point. The server holding the notes is something the person already trusts and already reaches. It also keeps the pair in step by construction. Client and server negotiate a sync protocol version before linking, so a server that also serves the client cannot hand out a phone it is unable to talk to. **Two files, and both must be present**: `thoughtsync.apk` and a `thoughtsync-android.json` sidecar carrying `{version_name, version_code, size, sha256}`. The sidecar exists because an APK keeps its version in a binary AXML manifest, which Python cannot read and which is not worth putting `aapt` on a Quart server to reach. CI writes it beside the APK, where the values are already known — including the digest, computed over the same bytes it uploads, so a phone can tell a truncated download from a complete one before handing it to the installer. Not a trust anchor; the signature is that. **Under DATA_DIR, not baked into the image.** Baking charges ~55 MiB to every self-hoster including everyone who never touches Android. `/var/thoughtsync` is already the mounted volume that holds attachments, so a build dropped there survives container recreation. **Absence is an ordinary state, not an error.** No APK means the key is absent from `/api/config` — absent rather than null, so a client testing for it cannot confuse "this server has no client" with "this server predates the field" — the web UI hides the card instead of offering a button that 404s, and the metadata route answers 404. A server whose owner does not use Android is not misconfigured. **A mismatched pair also counts as no client.** If the sidecar's recorded size does not match the file on disk, the two did not arrive together; serving one build while advertising another is worse than serving none, because the phone would compare versions against a promise the bytes do not keep. That makes the copy order in docs/android-distribution.md load-bearing, and it is written down there: APK first, sidecar last. **The version is public, the bytes are not.** An updater has to be able to ask "is there something newer?" cheaply and before it has done anything; 55 MiB is not for anyone who can reach the port. `login_required` already accepts either a session cookie or a device bearer token, so the browser and a linked phone both work with no second auth path. The Android lane now publishes both files to the same rolling `dev` release the desktop bundles use, reusing `publish-release.sh` — its nullglob asset list was already built for several jobs in separate workspaces publishing to one release, which is exactly this. Signed builds only: publishing an unsigned APK would offer people something they cannot install over what they already have. Nine tests, DB-free like the rest of the suite — this lane runs no Postgres, so the advertisement is asserted through `advertisement()` rather than through `/api/config`, whose other half needs a database. Both routes ARE exercised, because neither opens a session.	2026-08-20 20:11:32 -04:00
bvandeusen	6589be2b0f	android: unit tests are a debug-only task, and the artifact name says variant ... Run 4082: `Task 'testReleaseUnitTest' not found`. AGP creates unit-test tasks only for `testBuildType`, which is debug — so pairing the test task with the packaged variant was wrong from the start. It was only paired to stop two Gradle invocations asking for different Cargo profiles and paying the four-minute cross-compile twice. With the profile pinned to debug (#2810) that reason is gone, so the step goes back to `testDebugUnitTest` unconditionally. Costs one extra Kotlin compile and buys the type-check on the variant an emulator build would actually use. Also: the artifact was named from the Cargo profile, which is now always "debug" — so a signed release APK would have been uploaded as `thoughtsync-android-debug-<sha>`. Same word, two different things. It is named from the APK's variant now, and the two outputs are kept separate so they cannot be confused again.	2026-08-20 19:23:53 -04:00
bvandeusen	cae9888eb9	android: build the release APK with a debug-profile .so, for now ... `d0a9c73` switched the lane to a release Cargo profile alongside the release variant. The variant was the point; the profile was mine, and it broke the build (run 4077): `generateUniffiBindings` fails with "No UniFFI metadata found" on the release `.so`. The workspace release profile sets `strip = true`, and uniffi's `--library` mode finds its interface metadata through symbols. That is the obvious suspect and it is recorded as a suspect, not a finding — `lto = true` dropping the metadata statics would print the identical message and the two have not been told apart. Backed out to the debug profile rather than guessing at a fix, because the two halves of that commit are not equally important. Signing and a rising versionCode are what make an install replace the last one instead of wiping the notes; the Rust profile only makes the result faster. The APK this produces is no worse than every previous build, all of which shipped a debug-profile `.so`. Recorded as Scribe #2810 with the four candidate fixes and, more usefully, the instruction to establish the cause on a host build before spending another four-minute cold cross-compile on a guess.	2026-08-20 19:16:03 -04:00
bvandeusen	d0a9c73bf9	android: sign the release build, and give it a version that rises ... Two separate reasons updates were impossible, both fixed here. **Every CI build was signed with a different key** (issue #2803, measured with `apksigner --print-certs` across two runs). No signing config meant AGP's debug keystore, which AGP GENERATES when absent — and every job starts from a fresh container. So no build could ever be installed over another: the only way through was uninstall-then-install, which deletes the app's database and every local note with it. **versionCode was hardcoded to 1.** `build.gradle.kts` has read a `THOUGHTSYNC_VERSION_CODE` property since the skeleton landed; nothing ever passed it. Even with signing fixed, every APK would have claimed to be the same version and nothing could tell a newer one existed. It now comes from `GITHUB_RUN_NUMBER` — the same monotonic counter the desktop's version scheme already uses, needing no state between runs and immune to the shallow checkout that makes a commit count useless here. The version NAME comes from the desktop's `build-version.sh`, so both surfaces report one product version rather than two that can disagree. **The alias is hardcoded, not a secret.** It is fixed for the life of the app and already written into the certificate every install carries; hiding it would buy nothing and stop this file describing its own signing. Two secrets, not three — and PKCS12 cannot hold a key password distinct from the store password anyway, so `keyPassword` is the same value by necessity rather than by shortcut. **The lane now builds RELEASE when it can sign, debug when it cannot.** That is not cosmetic. A debug APK is `debuggable`, which on a phone holding personal notes and a device sync token means anyone with adb can read both. Which meant confronting something the release path would have shipped quietly: `cargoNdkDebug` was hardcoded to the debug Cargo profile and every variant took its `.so` from it, so `assembleRelease` would have packaged an UNOPTIMISED store and sync engine. Now one `cargoNdk` task takes its profile from a property, and the whole run uses one profile. A debug/release task pair would have been the tidier shape and would have made a run that both type-checks and packages pay the four-minute cross-compile twice — this runner has no working Gradle or Cargo cache, so that cost is real on every push. The run prints the signing certificate after assembling, so the fingerprint can be compared against the one recorded at generation. Signing with the wrong key produces a perfectly valid APK that simply refuses to install — a failure that otherwise surfaces on the device, long after the run is green. `.gitignore` learns `*.jks`, `*.keystore`, `*.p12`, `*.b64` first, so generating a keystore anywhere near this tree cannot go wrong. Also corrects the record: the comment this replaces cited "Scribe task 2136" as though it were a standing rule. It is not one — none of the 46 always-on rules mentions signing keys. 2136 is a desktop-updater task whose REASONING got repeated until it sounded like policy. The reasoning holds, and holds harder on Android where a key cannot be rotated without the original, so the practice is unchanged; the citation is now honest about what it is.	2026-08-20 19:03:57 -04:00
bvandeusenandClaude Opus 5	f179928c57	android: run ktlint and detekt from the image, not as Gradle plugins ... First Android run failed at plugin resolution: Plugin [id: 'io.gitlab.arturbosch.detekt', version: '2.0.0-alpha.3'] was not found in any of the following sources That version is published to neither Maven Central nor the plugin portal — the latest detekt anywhere is 1.23.8. It was copied from Minstrel's catalog, where it presumably resolves from a cached artifact; copying a pin without checking it exists is what made it my problem. Rather than chase a working plugin version, the analyzers now run from the CLIs ci-rust-android already ships. That was the point of putting them in the image in step 3, and going through Gradle plugins would have meant a SECOND pinned version of each tool, resolved at build time, kept in lockstep with the image's by hand. One less resolution step, and step 3's decision finally earns its keep. Also replaces the source-ordering hack while here. Kotlin has to compile after the bindings are generated, and the usual `tasks.withType<KotlinCompile>` cannot be written in this build at all — AGP 9's built-in Kotlin means that class is not on the buildscript classpath. Passing the TASK PROVIDERS to srcDir instead lets Gradle read their @OutputDirectory and infer the ordering itself, which is the idiomatic form and removes the dependsOn entirely. Good news from the failed run: the Gradle wrapper check passed, so Gradle 9.1.0 on the image's JDK 25 works — the toolchain decision from step 3 holds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 15:35:17 -04:00
bvandeusenandClaude Opus 5	20907abf6e	android: a Kotlin/Compose app that drives the Rust core (M12 step 5) ... The skeleton, and the lane that builds it. Gradle invokes cargo-ndk to cross-compile thoughtsync-ffi for four ABIs, generates the Kotlin bindings from the resulting .so, and packages both. BUILT ON MINSTREL'S TOOLCHAIN, not a fresh guess. Gradle 9.1.0 / AGP 9.0.1 / Kotlin 2.3.21 on JDK 25 is the combination already proven in this family on ci-android, including the JDK 22+ native-access opt-in the launcher JVM needs and the artifact-upload action pinned by SHA (issues 2255 / 2270). It also independently confirms the JDK 25 call made on ci-rust-android in step 3. Gradle wiring worth noting: * ExecOperations, not project.exec — the latter was REMOVED in Gradle 9, and touching `project` at execution time is also what breaks the configuration cache this build enables. * The cargo task's inputs are the Rust SOURCES, not the workspace directory. Declaring the directory would make Gradle hash target/, which is gigabytes. * Bindings are generated with `--library` against the built .so, so they can never describe a different version of the Rust than the one being packaged. * cargo runs --locked, so an Android build cannot silently re-resolve the lockfile the desktop lanes are gated on. JNA is a real dependency, with the @aar classifier. The plain jar builds fine and fails at runtime with UnsatisfiedLinkError, which is the worst way to learn it. R8 keep rules for JNA and the bindings are in for the same reason — that failure would otherwise appear only in a minified release. The UI is a working board, not a debug screen: capture field, note list, empty state, error banner, and an honest failure screen for a store that won't open. Rules 23/24 — a surface ships at quality from the first commit. Capture uses the IME action key because the north star is a thought captured in under a second, and leaves the title empty so the core derives it from the first body line. Every core call runs on Dispatchers.IO: they are blocking FFI into synchronous SQLite, and running them on the main thread is exactly the jank going native was meant to avoid. The launcher icon reuses frontend/public/icon-maskable-512.png as an adaptive foreground on the brand #F5C518 — the same asset and colour the web app already ships, so the three surfaces wear one face. No signing config. A release keystore that has passed through an agent session or shell history is compromised by construction (task 2136); it has to be generated by the operator and reach CI only as a secret. CI builds debug. CI can only prove this BUILDS — a Linux runner cannot execute an APK, so feel and on-device correctness remain an operator pass on an emulator. Scribe #2739. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 15:24:30 -04:00
bvandeusenandClaude Opus 5	b3309e29f8	ci: the Rust lane was only ever checking one crate of three ... The Clippy, Test and fmt steps ran with `working-directory: desktop/src-tauri`, so cargo scoped them to the desktop PACKAGE. That was right while the desktop was the only Rust in the repo. Extracting the core (M12 step 1) made it wrong and nothing said so: * the core's 89 tests have not run in CI since that extraction. They used to, as part of the desktop crate, and moving the files out of that directory quietly took them out of the lane. * `android/ffi` was never compiled at all. I claimed the previous commit was verified by this lane; it wasn't. Run 3928 went green without the word "uniffi" appearing anywhere in its log. Both crates still COMPILE, because the desktop depends on the core — which is precisely why the hole was invisible. A green run kept meaning less than it looked like it meant, and the tell was there to be read: the test output listed `thoughtsync_desktop_lib` and nothing else. Now run from the repo root with `--workspace` / `--all`. The lockfile gate keeps its place on the first cargo invocation. ci-requirements gains the rule and the reason, plus a note to check a new member actually appears in the `cargo test` output rather than trusting the green. Also corrects the lockfile procedure there to `cargo fetch` rather than `cargo generate-lockfile`: both update the lockfile, but generate re-resolves from scratch and bumps unrelated crates, turning a two-line manifest edit into an unreviewable diff. fetch resolves minimally. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 11:18:54 -04:00
bvandeusenandClaude Opus 5	f90b9203a7	android: bind the core to Kotlin through uniffi (M12 step 4) ... `android/ffi` is to Android what `desktop/src-tauri/src/commands/` is to the desktop: a shim over the shared core holding no logic of its own. Third workspace member, so the desktop lane's `cargo clippy --all-targets` compiles and lints it — which until the Android lane lands (step 5) is the only thing that does. Three decisions worth stating. MIRRORED RECORDS, NOT DERIVES ON THE CORE. The core's model structs are serde shapes contracted with the shared Vue frontend, and one of them holds a serde_json::Value, which has no uniffi representation. Hanging uniffi derives on them would couple two unrelated consumers to one definition. The cost of mirroring is drift — an Android client quietly missing a field the desktop gained — so every conversion destructures the core struct exhaustively. Add a field to core::local::models::Note and this crate stops compiling until Android is told what to do with it. NoteEdit IS A LIST, NOT A STRUCT OF NULLABLE FIELDS. The store's patch format distinguishes three states: leave alone, set, and clear to null. Kotlin cannot express the third with a nullable field — `title = null` in a data class is indistinguishable from `title` unset — so the editor could never clear a title. Explicit Clear* variants say it out loud and give Kotlin a sealed class. ASYNC IS TOKIO-BACKED, AND CANCELLATION ALREADY WORKED. Exported async methods become Kotlin suspend functions. When a coroutine is cancelled uniffi drops the future, and no async path in the core holds the store lock across an await — a std MutexGuard isn't Send, so the compiler has been enforcing that all along. A cancelled sync leaves the store consistent and simply hasn't stamped last_sync_at, which is only written after both halves of a cycle succeed. Also here: * core gains Db::conn(). Every consumer was writing `db.0.lock().map_err(|e| e.to_string())?` by hand, and worse, any helper returning the guard had to NAME rusqlite::Connection — which would have made rusqlite a dependency of a layer whose whole point is not knowing what the store is made of. Same trap as the update.rs test module in step 1. * The uniffi `cli` feature is gated behind our own `bindgen` feature. It drags in clap, askama and goblin for a three-line binary, and the desktop lane should not compile a code generator it never runs. * The bindgen binary lives in this workspace on purpose: generated bindings and the linked uniffi runtime are two halves of one ABI, and compiling the generator against the same dependency keeps them in step by construction. That is why ci-rust-android ships no uniffi-bindgen. Tests cover the round trip the Android skeleton needs (open a store in a directory that does not exist yet, write a note, read it back), that a body-only note still has a display_title, that set and clear are genuinely different edits, and that an unlinked app reports NotLinked rather than an error. Known and deliberate: the workspace sets panic = "abort", so a panic crossing the FFI aborts instead of arriving in Kotlin as an exception. Same behaviour the desktop already has; noted in the crate header rather than silently changed. Scribe #2733. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 11:09:52 -04:00
bvandeusenandClaude Opus 5	0a7480cf9b	core: extract the store and sync engine into a shared crate (M12 step 1) ... Android becomes a native Kotlin client over this same code (Scribe note 2730), so the local store and sync engine stop being modules of the desktop app and become `thoughtsync-core`, a crate with no UI framework in it at all. This is a move, not a rewrite, and the measurement is why: every file in local/ and sync/ already carried ZERO Tauri references — 4,980 of 6,372 lines. The coupling was 473 lines of command shim, which stays behind in the desktop crate as src/commands/. Kept as git renames so history follows the files. The desktop imports them under their old names (`use thoughtsync_core::{local, sync}`) so every call site reads exactly as before. What moved is where they live, not what they are. Two things a workspace changes that are easy to miss, both caught before pushing: [profile.release] now lives at the workspace ROOT. Cargo silently ignores profiles declared by a non-root member — leaving it in the desktop crate would have dropped lto/strip/opt-level from every release build with only a warning. And a workspace shares ONE target dir, so the bundles moved from desktop/src-tauri/target to target/. Thirteen references across publish-release, debundle-graphics, verify.sh, package-prebuilt and the workflow now point there. Pinning target-dir back would have been the smaller diff, but the Android lane also produces Rust artifacts and they do not belong under desktop/. Also retires the Tauri Android lane in the same push rather than leaving a path that is being replaced: gen/android, android.yml and docs/android-dev.md are gone, the mobile_entry_point attribute with them, and the lib drops to rlib — staticlib/cdylib existed for Tauri mobile, and the .so Android loads will be built from the core crate instead. Rule 22, no parallel path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 23:12:26 -04:00
bvandeusenandClaude Opus 5	40cb463be7	android: build the x86_64 ABI too, so an emulator can run it (task 1864) ... arm64 is every real device, but a desktop emulator is x86_64 — an arm64-only APK installs there and then dies unable to load its native library. A build nobody can try on an emulator is a build nobody checks, which defeats the point of producing an artifact at all while there is no phone in the loop. armv7 and i686 stay out: 32-bit hardware we do not target, and the image carries all four targets if that ever changes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 22:01:42 -04:00
bvandeusenandClaude Opus 5	1f140c7457	android: scaffold the Tauri mobile lane and build a debug APK in CI ... The phone client is Tauri v2 mobile (operator decision), so it reuses the Vue frontend and the Rust store and sync engine that already exist rather than becoming a third implementation to keep in step by hand. gen/android is committed. tauri android init generated it, its own .gitignore already excludes the build outputs and every keystore file, and CI must not have to regenerate a project that manifest edits will accumulate in. What the scaffold confirms is that the image's JDK pin was load-bearing rather than incidental: Tauri templated Gradle 8.14.3 with AGP 8.11.0, and CI-android's versions.env records that JDK 25 needs Gradle 9.1.0+ and that anything older fails with an opaque "25.0.3" message. Picking 17 for ci-tauri-android avoided exactly that. namespace and applicationId came out as com.fabledsword.thoughtsync, matching the desktop identifier, so the app-data story stays consistent. The lane builds a DEBUG APK for arm64 only. Release APKs need signing, and the keystore has to be generated by the operator and never pass through CI logs or an agent session — the constraint recorded for the updater key applies unchanged. Gradle's throwaway debug keystore needs nothing from anyone, so this can prove the app compiles and packages today and grow a signed job when a key exists. arm64 is every real device; the image carries the other three ABIs, so widening is a word. Triggered by frontend/** as well as desktop/**, because generate_context! compiles the frontend into the app — the same reasoning that widened desktop.yml. Android, desktop and web are peers on one quality bar, and a frontend commit that skipped this lane would ship a stale phone build. Green here will mean it BUILT. A Linux runner cannot execute an APK, so nothing in this lane proves the app runs, renders, or is usable by finger. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 23:01:32 -04:00
bvandeusenandClaude Opus 5	3a1496e5fa	frontend: honor prefers-reduced-motion, and let frontend work reach the desktop ... Two halves of the same gap. The app had no reduced-motion handling at all — the setting appeared nowhere in the frontend — and the desktop build didn't rebuild on frontend changes, so shared UI work shipped to the web and silently never reached the desktop app. The CSS guard is global and blunt so it catches every Tailwind `transition` already scattered through the components, and catches M7's motion work without each new component having to remember. Near-zero durations rather than `none`, so transitionend/animationend still fire and nothing waiting on them hangs. useReducedMotion covers what CSS can't reach: JS-driven motion, where the honest response to the preference is no animation at all rather than a faster one. It's reactive because the setting can change while the app is open. The path filter was narrowed to the adapter/bridge directories against a "~20-40 min" build cost recorded in the header. Measured runs are 4-5 minutes, so that cost isn't there, and the frontend is compiled into the binary by generate_context! — any part of it changing means the shipped desktop app is stale. Desktop, web and Android are peer surfaces on one quality bar, so shared frontend work has to reach all of them by construction rather than by whichever directory it happened to touch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 11:51:07 -04:00
bvandeusenandClaude Opus 5	5c1ae574f6	desktop: commit Cargo.lock and gate CI on it (issue 2102) ... The desktop crate is a binary, and binaries commit their lockfile. Without one every run re-resolved the graph: a tagged .deb/.AppImage/.exe couldn't be rebuilt from its tag, any semver-compatible upstream release landed automatically on the next build — the failure mode hardest to read, because the commit that broke it changed nothing relevant — and Renovate had no lockfile to bump, leaving Rust dependency movement invisible to the Dashboard. Generated with cargo generate-lockfile inside ci-tauri:1.97, the same image CI builds in, so the format and the picked versions are what CI would have chosen itself. That takes the artifact-upload round-trip the issue proposed off the table: ci-requirements.md already blesses the image for cargo fmt, and resolving a dependency graph is no more a build than formatting is. 503 packages. Enforcement goes on each job's FIRST cargo invocation rather than the bundle build: cargo clippy --locked on Linux, and its own cargo fetch --locked step on Windows, whose only crate-graph command is otherwise the cross-compile itself. Drift fails in the first thirty seconds instead of thirty minutes in, and everything after the gate in that job compiles the recorded versions anyway. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-16 10:41:18 -04:00
bvandeusenandClaude Opus 5	505904b1e5	ci: swap artifact upload to the mirrored action (issue 2270) ... Both desktop upload steps used actions/upload-artifact@v3, which reports success while Gitea stores the result in a format its v4-only artifact API will never serve back — 110 artifacts on this repo are on disk, have valid DB rows, and are invisible to the REST API, the web download route and the MCP tools alike. Green jobs producing nothing retrievable. Point both at bvandeusen/upload-artifact (pull mirror of the Forgejo project's fork, GHES refusal disabled), pinned by SHA because the mirror auto-syncs. Not actions/upload-artifact@v4: its isGhes() throws on the hostname before opening a connection, so no server-side change reaches it. Also drop continue-on-error and set if-no-files-found: error on both steps. Between them, a failed or empty upload was reported as a green run — the same silence that let this go unnoticed for a month. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 15:27:57 -04:00
bvandeusenandClaude Opus 5	6f47af8d96	ci: point the manifest at THIS build, and stop the dev release growing forever ... Two halves of one mistake, both visible on the dev release right now: the manifest said 0.1.134 and pointed at ThoughtSync_0.1.132_amd64.AppImage. The rolling channel accumulates every build's assets, and the manifest picked its bundle by file extension with `head -1` — the OLDEST match. A client would have been told 0.1.134 was available, downloaded 0.1.132, installed it, and been offered 0.1.134 again. Forever. Signature verification could not have caught it. The old bundle's signature is perfectly valid for the old bundle; nothing about it says "this isn't the build the manifest claims". Selection is now matched on the build's own version string, so the manifest can only ever describe the binary it was written for. The accumulation is the other half. Nothing can reach a superseded build once the manifest moves on, and an AppImage is ~100 MB — three pushes had already left 300 MB of unreachable binaries on the Git host. A rolling channel now prunes everything but the current build once the manifest points at it. Versioned releases are untouched: that IS the archive, and the stable pointer's URLs aim into it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-27 15:40:54 -04:00
bvandeusenandClaude Opus 5	acff95f920	ci: re-sign the AppImage after de-bundling, or Linux updates can never verify ... The de-bundle step deletes the AppImage and repackages it without the host graphics libraries — necessary, and it runs AFTER tauri signed the original. So the .sig published on the release described a file that no longer existed, and every Linux in-app update would have failed signature verification. Worth naming the failure mode: the error would have said the signature didn't match, which points at the key, the manifest, or the download — anywhere except "a later build step rewrote the file after signing it". The Windows lane hid it too, because nothing post-processes the NSIS installer, so the one platform already verified working was the one platform that couldn't reveal the bug. Signs the file that actually ships, and fails the build if no .sig comes out rather than quietly publishing an unverifiable bundle. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-27 15:16:13 -04:00
bvandeusenandClaude Opus 5	02c932260e	Updater signing key, a rising dev version, and a production compose ... Three things, all needed before the update loop can be tested. The public signing key is committed. Verified before trusting it: algorithm `Ed`, key ID 90E96FEA2F6D9B6A matching its own comment, 32-byte Ed25519 key. Dev builds now carry a version that RISES. Every build took its version from Cargo.toml, so each one was 0.1.0 — an installed 0.1.0 would read a manifest advertising 0.1.0, conclude it was current, and never update. The rolling channel would have looked broken while working exactly as written. Dev builds are now 0.1.<ci-run-number>, from one helper shared by both bundle jobs and the manifest writer, because three separate derivations of "what version is this" is three chances for the binary and the manifest to disagree. Plain semver, not a `-dev.N` prerelease: prerelease versions sort BELOW the release they qualify, so a tagged build would never update to a newer dev one, and Windows installer metadata wants a numeric X.Y.Z regardless. Bumping the minor still beats any dev build on the old line — 0.2.0 > 0.1.2932. The Windows job also gets the signing environment it was missing, so its NSIS installer is signed too. Without that the manifest would have had a Linux entry and nothing for the platform actually being tested. docker-compose.yml is now the production stack, per request: it pulls the published image instead of building, keeps Postgres OFF the host network, sets restart policies, health checks and log rotation, and refuses to start without a POSTGRES_PASSWORD rather than shipping a known one. Volume names are deliberately unchanged so an existing deployment upgrades in place instead of silently coming up against an empty database. Development keeps its own clearly-named file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-27 10:33:17 -04:00
bvandeusenandClaude Opus 5	d6734cf7a0	desktop: in-app updates, two channels, signed, fed by fixed-tag releases ... There was no in-place update anywhere. The app never checked, downloaded or applied anything, and the only published release predates the whole sync arc — so `install.sh` would hand out a build with no sync in it. Installing from per-run CI artifacts, which is what's been happening, is not something an updater can point at: ephemeral, auth-gated, no stable URL. Two channels, switchable in the app: `stable` follows tagged releases, `dev` follows every green push. The feed is a Fabled-Git release asset, not a ThoughtSync server route. This reverses the lean recorded in task 1998, and the reason matters — a server-hosted feed can only reach a desktop that has linked a server, and local-first-with-no-server is the whole premise. An unlinked install has to be able to update itself. Each channel reads a `latest.json` on a release whose TAG NEVER MOVES. That's forced, not stylistic: Forgejo has no /releases/latest/download/<asset> route (verified — it 404s with no redirect), so "newest" cannot be named in a URL. `dev` carries the rolling bundles; `stable` is a pointer release holding only the manifest, whose URLs aim at the versioned release's assets, so nothing is duplicated. The manifest is written by a third job that runs after both bundle jobs. They build in separate workspaces and neither can see the other's output, but one manifest has to describe both platforms — generating it inside either job would silently omit the other, and a missing platform reads to a user as "no update available" rather than as a broken feed. It reads what actually landed on the release, so it can never advertise a bundle that failed to upload. Signing is gated on the secret existing, in the script rather than an `if:` (the secrets context isn't reliably available to step conditions). No key means no updater artifacts and no publish: a feed the app would refuse to verify is worse than no feed, because it looks like it works. CI stays green until the key lands. On Linux the updater can only replace an AppImage — a deb or pacman install is owned by its package manager and must never be overwritten underneath it. The app detects that case up front and says so, instead of failing halfway through with a permissions error nobody can read. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-26 19:03:12 -04:00
bvandeusenandClaude Opus 5	2e32ecda6e	desktop: rustfmt the pull tests; run fmt after clippy/test ... Two macro-argument splits and a stray blank line, applied verbatim from run 2900's cargo fmt --check diff. Also reorders the Linux job so `cargo fmt --check` runs AFTER clippy and the tests. Fail-fast ordering would normally put the cheapest check first, but there is no Rust toolchain on the workstation, so this lane is verified entirely in CI — and a formatting nit failing first SKIPS clippy and the tests, making a whole cycle teach nothing but whitespace. That has now cost four cycles in this session alone. It still runs before the 20-40 minute bundle build, so a fmt failure doesn't burn that either. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-26 00:09:07 -04:00
bvandeusenandClaude Opus 5	5b471f5dd4	desktop: generate the Windows icon set in the cross-compile job ... tauri-build needs icons/icon.ico to emit the Windows Resource file, and the repo only carries the PNG set the Linux bundles use — run 2881 failed with "icons/icon.ico not found". Generated in-job from the committed 1024px app-icon.png rather than committing a hand-made .ico, so there stays one icon of record that can't silently drift from the brand art. Scoped to the windows job; the Linux bundles don't need it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 20:37:33 -04:00
bvandeusenandClaude Opus 5	ab961f13ce	desktop: cross-compiled Windows NSIS installer lane (task 2015) ... Adds a `windows` job to desktop.yml on the new ci-tauri-win image, producing a Windows -setup.exe without any Windows hardware. A Windows container can't run on a Linux host, so cross-compilation is the only route: --runner cargo-xwin supplies the MSVC CRT/SDK (pre-warmed into the image) and links with lld-link, and makensis builds the installer. NSIS only. .msi needs WiX v3, a Windows program — per Tauri, ".msi installers can only be created on Windows". It comes back if a Windows node ever exists. Kept as a separate job so a Windows-side failure can never block the Linux artifacts, which are the primary product today. publish-release.sh now globs the windows target root too; nullglob means each job uploads only what its own workspace contains, and the release is created once and reused via the 409 path, so both jobs can publish to the same release safely. No app code changes were needed. The AppImage self-integration UI already gates on is_appimage (AccountView.vue:131, DesktopIntegrationPrompt.vue:22), and $APPIMAGE is never set on Windows, so the OOBE prompt and Settings toggle hide themselves. Recorded plainly in ci-requirements.md that this is the weakest-verified lane we have: Tauri calls Linux->Windows cross-compilation "not tested as much" and a last resort, and a Linux runner cannot execute a Windows binary. Green means it built. A real Windows machine check is mandatory before trusting a release, and installers are unsigned until a certificate exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 20:14:55 -04:00
bvandeusenandClaude Opus 5	85ca7c2a2d	desktop: drop the redundant deb depends, correct the pacman docs ... Follow-up to 8a8b2b1, driven by what run 2872's new checks actually printed. The .deb verification did its job on its first run: tauri already infers exactly libwebkit2gtk-4.1-0 + libgtk-3-0, so declaring the same two in tauri.conf.json produced a control file listing each of them twice. Removed the declaration — verify.sh is the real guard, and it fails the build if inference ever stops covering what the binary links. The pacman step revealed ci-tauri carries neither zstd nor bsdtar, so packages currently ship as .pkg.tar.xz with no .MTREE. Both are working outcomes (pacman reads xz; only `pacman -Qkk` needs .MTREE), but the docs promised .zst, so the README, the release notes and ci-requirements.md now describe what the build actually produces. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 18:26:24 -04:00
bvandeusenandClaude Opus 5	8a8b2b17e6	desktop: prebuilt pacman package + verified .deb (tasks 2022, 2074) ... Native packages the installer can actually fetch, before task 2014 wires up the fetching. Arch (task 2022, re-scoped): the source PKGBUILD is gone — asking every user to install rust+node and compile for minutes isn't distribution. Replaced by desktop/packaging/arch/package-prebuilt.sh, which wraps the binary the Linux job already built into a .pkg.tar.zst. No second Rust build, no Arch CI image: the binary bundles nothing and resolves webkit/gtk/soup by soname, identical on both distros, with SQLite compiled in and glibc used in the safe built-old/run-new direction. CI is Debian and has no pacman, so the step logs .PKGINFO plus the full file listing for audit instead of pretending to verify. Debian (task 2074): install.sh hands the .deb to every Debian/Ubuntu user and nothing had ever inspected it. tauri.conf.json now declares libwebkit2gtk-4.1-0 + libgtk-3-0 explicitly rather than trusting inference — and deliberately declares no appindicator or sqlite dep, since tauri is built with features=[] and rusqlite is "bundled". desktop/packaging/deb/verify.sh prints the generated control file, cross-checks it against what the ELF actually needs via dpkg-shlibdeps, confirms every declared dep exists in apt, and clean-container installs when a docker CLI is available. Both artifacts join the run artifact and the tagged release; install.sh grows a pacman branch so Arch/CachyOS gets a native install instead of the AppImage fallback. Still no release cut (rule 2). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi	2026-07-25 18:19:30 -04:00
bvandeusenandClaude Opus 4.8	36c05f5029	desktop: release-publish pipeline + one-command Linux installer ... Phase A of the desktop Release + install path (M10 / tasks 2014, 1998): - .forgejo/workflows/desktop.yml: tag-gated "Publish release" step + contents:write. On a v* tag the build now publishes a Fabled-Git Release with the de-bundled AppImage + .deb attached — a stable, versioned fetch target (Actions artifacts are ephemeral/test-only). Dormant on dev/main. - desktop/packaging/publish-release.sh: creates/reuses the Release via the Forgejo API using the runner-injected token; idempotent asset replace. - desktop/packaging/install.sh: curl|sh one-command installer — native .deb on Debian/Ubuntu, de-bundled AppImage everywhere else (installed to ~/Applications/ThoughtSync.AppImage, matching src/integration.rs so the app sees itself integrated). AppImage path needs no sudo. Plumbing only — no release cut (rule 2); activates on the operator's first v* tag. In-app self-update (tauri-plugin-updater + signed latest.json) is Phase B, gated on the operator's signing key. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-25 14:13:50 -04:00
bvandeusenandClaude Opus 4.8	41cf4b3598	desktop M10.5: wire the offline local source; boot to board with no server ... adapters/local.ts implements the repository seam over the M10.4 Tauri commands via invoke (camelCase args -> the commands' snake_case params); adapters/index.ts now selects local when running in the desktop shell, rest on web. bridge.ts exports invoke for it. This is the commit that resolves the black screen: a fresh desktop launch reads config + session + notes from the on-device SQLite core, so the router's auth gate passes with a synthetic local user and the board renders with zero server and zero account. Account auth, device linking, attachment upload, URL unfurl and file import reject with a "connect a server" message (no offline meaning yet); everything else — board, editor, capture, search, filters, labels, checklists, reminders — works fully offline. desktop.yml also now rebuilds the app on frontend adapter/bridge changes, since the desktop bundle embeds the frontend. Task 1994. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 23:05:04 -04:00
bvandeusenandClaude Opus 4.8	b08cdb92b5	desktop AppImage: de-bundle host-coupled graphics libs (fixes black window) ... Tauri's AppImage bundles the build host's graphics/display stack (libEGL/libGL/libdrm/libgbm/libwayland-* + Mesa dri drivers) into usr/lib. On many end-user systems (Arch/CachyOS, NVIDIA, Wayland) those clash with the running kernel driver + Mesa and abort with EGL_BAD_PARAMETER -> a black window (issue 2021). They load before any renderer choice, so the runtime env fallbacks can't rescue it; per the AppImage excludelist they must come from the host. Add a CI-only post-build step (desktop/packaging/appimage/debundle-graphics.sh) that extracts the built AppImage, strips exactly that graphics/display subset (keeping webkit/gtk bundled for portability), and repackages in place so the app falls through to the system's graphics libs. Wired into desktop.yml between the Tauri build and the artifact upload. Task 2023. Makes the AppImage the zero-install taste-test vehicle. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 18:10:02 -04:00
bvandeusenandClaude Opus 4.8	98d918dda2	M10 (task 2022, issue 2021): Arch pacman package + commit icon set (native, system libs) ... Native-first fix for the AppImage black window: a PKGBUILD that builds from source, linked against SYSTEM graphics libs, so it renders on the host driver. - desktop/packaging/arch/{PKGBUILD,thoughtsync.desktop,README.md}: `makepkg -si` installs /usr/bin/thoughtsync + .desktop + icon; deps webkit2gtk-4.1/gtk3/...; builds the frontend + `cargo build --release` (no tauri-cli). Uses the host graphics stack -> avoids EGL_BAD_PARAMETER. - Commit the icon set (desktop/src-tauri/icons/*.png, un-gitignored) so BOTH `cargo build` (pacman) and `cargo tauri build` (deb/appimage) work without a generate step; bundle.icon -> the 4 committed PNGs; drop the `cargo tauri icon` step from desktop.yml. - Broaden the WebKit software-render hardening (lib.rs) to ALL Linux (was AppImage-scoped) so the native build also renders if system WebKit is finicky. Can't CI-test the PKGBUILD (Arch-only; CI is Debian) -- operator builds locally. desktop.yml re-verifies the deb+AppImage build with the committed icons. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 17:02:40 -04:00
bvandeusenandClaude Opus 4.8	7ca09e9a01	desktop CI: pin upload-artifact@v3 (Forgejo rejects v4 protocol) ... The build produces the .deb + .AppImage fine; upload-artifact@v4 failed with GHESNotSupportedError (Forgejo has no v4 artifact API). v3 uses the older protocol the instance accepts, so the bundles become downloadable from the run for hand-testing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 13:33:06 -04:00
bvandeusenandClaude Opus 4.8	877a6a572f	M10 (task 2013): integrated AppImage — app self-integration (OOBE + Account toggle) ... The Linux AppImage can now install itself into the applications menu, so it behaves like an installed app instead of a loose file. - Rust (desktop/src-tauri/src/integration.rs): integration_status / integrate_desktop / unintegrate_desktop commands — detect $APPIMAGE, copy the AppImage to ~/Applications, write ~/.local/share/applications/thoughtsync.desktop + embedded icon, update-desktop-database. Registered in lib.rs. - Frontend: withGlobalTauri exposes window.__TAURI__.core.invoke; desktop/bridge.ts (isDesktop + typed invoke, NO @tauri-apps/api dep -> web bundle unaffected); DesktopIntegrationPrompt (first-run OOBE, remembered) mounted in App.vue; AccountView "Desktop app" add/remove control. All desktop-guarded -> no-ops on web. - desktop.yml: upload the .deb + .AppImage as a run artifact (continue-on-error) so the build is downloadable for hand-testing. Verified by CI: ci.yml (vue-tsc) for the frontend, desktop.yml (cargo + tauri build) for the Rust + AppImage. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 13:24:20 -04:00
bvandeusenandClaude Opus 4.8	1607c77ee5	M10.8: desktop CI lane (.forgejo/workflows/desktop.yml) + app-icon source ... Separate workflow (not ci.yml) so the ~20-40min Rust/AppImage build only runs on desktop/** changes, not every backend/frontend push. Builds on the ci-tauri:1.97 image: frontend build -> `cargo tauri icon app-icon.png` (from a committed 1024px source PNG, sidestepping SVG-input questions) -> cargo fmt --check -> clippy -D warnings -> cargo test -> `cargo tauri build` (deb + AppImage). APPIMAGE_EXTRACT_AND_RUN=1 for FUSE-less CI containers. Verifies the M10.2 scaffold end-to-end and is the foundation for the integrated-AppImage work (task 2013). Also updates ci-requirements.md with the desktop lane. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-24 12:26:24 -04:00
bvandeusenandClaude Opus 4.8	05d5249e20	M0 CI: derive registry username from github.repository_owner ... The registry login needed a REGISTRY_USER secret that couldn't be set/read on this fresh repo (harness blocks secret writes; the value never surfaced via the API). The username is the repo owner and is public (it's in the image path), so derive it from github.repository_owner instead of a secret. REGISTRY_TOKEN remains the actual credential. Removes an entire class of setup friction. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-19 13:32:37 -04:00
bvandeusenandClaude Opus 4.8	af8aa25464	M0: Docker + Fabled-Git CI (typecheck + lint + test + build) ... - 2-stage Dockerfile (node:22 build Vue -> python:3.12-slim runtime); CMD runs `alembic upgrade head` then hypercorn (rule 82). - .forgejo/workflows/ci.yml on ci-python:3.14: typecheck (vue-tsc) + lint (ruff check src/) + test (uv venv + pytest, DB-free) + gated buildx push with the rule-46 tag scheme (:dev/:latest/:<sha>). No local integration lane yet. - ci-requirements.md (rule 39); docker-compose for a local app+Postgres stack. - Real README with layout, dev instructions, and the milestone arc. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FRgehjoz7Yv8LkUfADxACm	2026-07-19 13:17:38 -04:00