15 Commits

Include renames

Author	SHA1	Message	Date
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
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	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	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