A component now declares its ways of being built in one list -- `modes:
["release", "debug"]`, the first the default -- and every command it runs
is handed the mode as its last argument, so a project whose script takes
`release` or `debug` names that script once. A field may instead be
written per mode, which is the escape hatch for the commands that cannot
take the word: cargo takes `--release` or nothing, and its profile for
the unoptimised build is called `dev` while the directory it writes is
called `debug`, so no single word serves as both the flag and the path.
A command written per mode is not handed the word as well; it already is
the answer, and a stray argument to a service binary is a process that
will not start.
One list rather than gathering names from whichever fields happened to
mention them is what makes a mode missing from one part unsayable: every
per-mode map is checked against it, so a gap is named rather than
resolved to some other mode's command.
Which mode to build in and whether to strip are the build machine's --
there is one checkout and one set of outputs, so a per-device mode would
have two phones rebuilding over each other silently. Which of the
finished builds a phone installs stays that phone's. Neither choice is
part of the acceptance gate, so both have to be carried across the
components list being rewritten, by acceptance and by the self entry's
startup reconciliation alike; without the second a mode chosen for this
server's own component would not survive the restart that applies it.
A mode switch moves no commit, so `builtMode` is recorded beside
`builtFrom`. Without it a component built in debug and switched to
release reads as current and serves the debug build for ever -- and for
an APK nothing else notices, because the "never built at all" check finds
any variant under the component's directory.
Each component card gains a settings sheet behind a gear at the row's
right-hand end, holding the mode, which build to install, strip, and an
Enrol button. The variant picker moved into it: on the card the two read
as one choice, both saying debug and release, and they are not. The row's
text is now bounded and truncates, so a long status can no longer push
the log and settings buttons off the edge.
`enroll:` is a declared command whose one line of stdout is a URL for the
phone to open after installing -- generic on purpose, run per press since
such a link is one-shot and carries a credential, and in the acceptance
gate because it runs on the build machine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The two-APK case had no fixture: it was verified against a scratch project
that was not kept, so the shape three recent bugs came out of was covered
only by a tempfile unit test. test-projects/two-clients is two Apk
components in one checkout, each with its own cwd and its own package --
what tdep-survey looks like, and what service-and-app cannot stand in for,
since only one of its two components produces an APK.
tablet is slow on purpose (six seconds of pretending to cross-compile,
reporting its own progress) beside a phone that builds in two, because that
is what makes ?component= visible rather than merely asserted: building one
finishes while the other has not started.
Verified live against a throwaway server rather than reasoned about.
build?component=phone ran phone alone; afterwards phone reported built and
tablet did not, which is the sibling-masking bug -- under the root-anchored
"never built at all" check the tablet would have read as current and been
refused its own first build. prepare?component=tablet then ran tablet
alone and it did build. Each component resolved its own APK under its own
directory, with its own size and mtime, so nothing reports the first
match for both.
Also corrects a sentence in that README that went stale when discovery
moved per-component: find_apks is anchored at project.join(cwd), not at
the project path. The conclusion it supports is unchanged -- every other
fixture declares no cwd, so the anchor is still the project root for them,
and building into app/ is still what keeps a stub APK from being offered
as a build of Dev Updater itself. Re-ran the check command in that section:
only the updater's own APK is reachable from the repository root.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A Rust backend that discovers Android projects under configured roots,
builds one on request, and serves the APK over pinned TLS on a WireGuard
interface; an Android client that lists what is buildable, watches a build,
and installs the result. Enrolment carries the token and the CA, so the
phone trusts exactly the machine that issued it and nothing else.
`AGENTS.md` is the working guide and `README.md` the configuration
reference. The shared tunnel-and-TLS code lives in `vendor/wg-app-link`,
which ai-app uses too.
History before this point was squashed away, and a stale `config.json` went
with it: nothing had read that file since the config moved to RON outside
the checkout, and what it still held was one machine's absolute paths and
the names of projects on it.
irisandClaude Opus 5