a dev build installs beside codeaf as devaf and follows the dev channel

[AbirAbbas]

Why

Santosh asked for internal dev usage — downloads and everything around them —
to be separated from the main install. Today a dev build can be installed, but
only over ~/.codeaf/bin/codeaf: its launch check is silent, /update with no
word installs stable over it, and the curl line it offers reinstalls stable.
So a dev daily driver was three surprises away from being a stable binary again.

This makes a dev build a thing you can keep: it installs beside codeaf under its
own file name, it follows the dev channel, and every road it offers back leads to
the file you are actually running.

What changes

The product is still codeaf. devaf is only a file name — every sentence
the program prints still says codeaf, and devaf version prints
codeaf dev-… · go… linux/amd64. Nothing is renamed: not the state root, not the
socket names, not one identifier.

• The installer takes a name. --name WORD and CODEAF_INSTALL_NAME, checked
  against ^[A-Za-z0-9][A-Za-z0-9._-]*$ before anything is written (anything else
  is a usage error, exit 2, naming the rule). The binary, the temporary file, the
  printed line and the closing version run all use that name. INSTALL_NAME sits
  on one unindented line directly under the CHANNEL line so the website proxy can
  rewrite it exactly the way it already rewrites the channel.
• A channel build follows its channel. A dev-* or staging-* build asks its
  channel at launch and gets the same one dim line when that channel has something
  newer; /update and codeaf update with no channel word select it. An explicit
  word or tag still wins — /update stable on a devaf installs stable over that same
  file, because the person asked. Stable and rc behave exactly as before; a source
  build is still silent and still refused.
• Two tags of one channel are ordered by publish moment first, then by the
  YYYYMMDD in the tag, and a same-day tie with a moment missing goes to the release
  the API named. The running build's own moment comes out of the release list the
  check already fetches, so there is no extra request and no build-moment stamp. A
  build ahead of the newest is never silently downgraded.
• The cache is one file per channel. update-check.dev.json and
  update-check.staging.json, cached for one hour because dev publishes several
  times a day and a devaf beside a codeaf must not thrash one file. Stable and rc keep
  update-check.json and 24 hours, byte-for-byte as before.
• The curl line names this file. update.CurlLine(executable, channel) replaces
  the one constant everywhere a road back is offered: a file named devaf is told to
  reinstall from /get/devaf, a codeaf on a channel from /get/codeaf/<channel>,
  and any other name carries CODEAF_INSTALL_NAME=<name>. A source build's refusal
  still prints the CurlCommand constant.
• Shared state. devaf and codeaf share ~/.codeaf — keys, conversations, one
  engine host per workspace — under the existing retire-or-attach law. Nothing here
  changes it.
• Dev release notes carry curl -fsSL https://agentfield.ai/get/devaf | bash and
  one sentence saying what it installs. Only the dev channel gets the block.

Validation contract, and how each line is proven

	Behaviour	Proof
V1	--name devaf --dev writes <dir>/devaf, prints the real file, ends with that file's version line, leaves a sibling codeaf byte-identical; the variable does the same; the flag wins; ../x, -x, "", a bad variable and a bare --name all exit 2 and write nothing	internal/release · TestV1InstallerName
V2	INSTALL_NAME="${CODEAF_INSTALL_NAME:-codeaf}" is one unindented line, exactly once, directly under CHANNEL; --help names both spellings	internal/release · TestV2InstallerNameSeamAndHelp, TestInstallerKeepsTheWebsiteChannelSeam
V3	a dev build one build behind gets exactly one notice and a devaf gets the devaf road; the newest gets none; staging asks the staging list; stable's request and notice are unchanged; source makes no request; one call to releases?per_page=100	internal/update · TestV3LaunchNoticeForChannelBuilds, TestSourceLaunchesNeverReachTheNetwork
V4	the ordering law, both directions, including the cases it left open and the pairs it cannot rank at all	internal/update · TestV4ChannelOrdering, TestV4UnrankablePairsAreNeitherNewerNorAhead
V5	a dev build writes and reads only update-check.dev.json; one hour there, 24 hours on stable; alternating launches in one profile make one request each	internal/update · TestV5ChannelCacheFilesAndLifetimes
V6	/update and codeaf update with no word follow the running build; every explicit override wins; a check across two channels says only what it can order	internal/tui3 · TestV6UpdateChoiceFollowsTheRunningBuildUnlessOverridden; cmd/codeaf · TestV6TerminalUpdateDefaultsToTheRunningDevChannel, TestV6CrossChannelChecksSayOnlyWhatTheyCanOrder
V7	an ahead dev build is refused in both doors with the documented sentence and installs nothing; --check exits 0 with the newest/running line; naming the tag installs it; a publish moment beats the tag's date through the whole door	cmd/codeaf · TestV7TerminalUpdateRefusesAnAheadDevUnlessTheTagIsNamed, TestV7APublishMomentOutranksTheDateInTheTag; internal/tui3 · TestV7ChatUpdateRefusesAnAheadChannelBuildUnlessTheTagIsNamed
V8	the twelve-row curl table, and the line reaching the launch notice, /update's failure, the source refusal and a failed replace	internal/update · TestV8CurlLineTable, TestV8InstallFailureCarriesTheCallersCurlLine; cmd/codeaf · TestV8TerminalFailureUsesTheRunningFilesCurlLine; internal/tui3 · TestV8UpdateNotesUseTheRightCurlLine
V9	"what is devaf", "devaf", "can I run two versions of codeaf side by side", "how do I keep my dev build up to date" and "how do I install the latest dev build beside my codeaf" all reach the terminal page	internal/manual · TestV9DevafQuestionsReachTheTerminalManual and the probe table
V10	the dev notes block spells agentfield.ai/get/devaf and no other channel enters it	internal/release · TestV10DevReleaseNotesNameTheDevafInstaller

Verified by hand

• scripts/install.sh --name '../x' | '-x' | '' each prints
  codeaf: --name / CODEAF_INSTALL_NAME must match ^[A-Za-z0-9][A-Za-z0-9._-]*$
  and writes nothing; --name devaf against the real release service really does
  write <dir>/devaf.
• codeaf version does not create the state root, so moving the installer's
  closing version run after the install-marker block (which is what "the last action
  runs that file's version" asks for) changes no marker behaviour — only the order in
  which the version line and the telemetry notice print.
• Gates run in the worktree: go build ./... && go vet ./... clean, gofmt -l cmd internal
  silent, bash test/installer-telemetry.sh → 35 passed, 0 failed, the four touched
  packages green, and make pr-ready green.
• An adversarial read-only review round against the contract; its one real finding
  (the manual overclaiming what --check does across two channels) is fixed in the
  last commit, with two tests that pin the corrected sentences.

Not verified here

• Windows. CurlLine strips .exe and the installer appends its existing
  extension, both covered by tests, but no native Windows shell run was made.
• The live proxy. agentfield.ai/get/devaf is the other half of this change and
  ships as a separate website2.0 pull request. That route rewrites two lines of this
  installer — the channel and the name — and fails closed with a 502 until this
  pull request reaches the dev branch, because the line it must rewrite does not
  exist there yet. Land this first.

Added after the first review pass

• A release candidate follows stable, so it is offered the stable road. The first
  draft took the curl line from the tag's own channel, which handed an rc build
  …/get/codeaf/rc while the notice beside it named the stable release — it would have
  reinstalled a channel that build's own /update never selects. update.FollowedChannel
  is now the single answer to "which channel is this build on" (dev and staging follow
  themselves, everything else follows stable), and the launch check, the surface and the
  terminal door all take the curl line from it. The two places that spelled the same rule
  out longhand to pick a default channel ask it too. Proven by
  TestTheChannelABuildFollowsIsStableUnlessItIsDevOrStaging,
  TestAReleaseCandidateNoticeOffersTheStableRoad and
  TestAFailedReleaseCandidateUpdateOffersTheStableRoad; all three were checked to fail
  against the old behaviour before the fix, and a real stamped v0.3.0-rc.1 binary was
  driven by hand to confirm it.
• CODEAF_INSTALL_NAME is registered as operator plumbing. CurlLine spells the
  word into the road it offers a binary installed under another name, and the settings
  registry law counts every CODEAF_* word in the tree. It is the installer's pin and
  codeaf never reads it, so it lands on the allowlist rather than becoming a row a person
  could set and this binary could not act on.
• The keys page answers "how do I exit codeaf" again. Two new sections landed in one
  release — this branch's shell-update section and santos/dev: crew family, Pareto crewing and the Model Pool, custom connections #1108's headless exit-code section on
  dev, both genuinely about exit CODES — and between them they pushed the page that
  answers the question out of the results. Neither branch is red alone; the pair is. The
  quitting section was written almost entirely in quit, leave and close, so it now
  opens with the sentence a person actually types and says exit where it said leaves.
  Fixing the page rather than the probe is the rule this corpus is held to.

Verified against the real binary, by an independent lane

Head 1b9eb958d was built six ways (stamped dev-20260917-a0cc22169334 as devaf and as
codeaf, dev-20260921-ffffffffffff, dev-20260918-9258f7052379, v0.2.1, unstamped) and
driven under tmux against a local mirror of the real release list and one real dev asset,
never GitHub. Eleven ledger rows, all passing: the launch line for a behind dev build ends
with the devaf road and only the codeaf-named file gets /get/codeaf/dev; /update on a
devaf downloads, checks, installs at the devaf path and restarts the same transcript
(/status names the new build, /proc/<pid>/exe is the devaf file, sha matches the
asset); an ahead dev build gets no line and both doors refuse the implicit downgrade with
the quoted sentences, --version installs it; an equal build says it is newest; the
stable road is unchanged and writes update-check.json while dev writes
update-check.dev.json; a source build makes no request; the installer with --name devaf --dev writes devaf beside an untouched codeaf, the variable form does the same, and the
three bad names exit 2 writing nothing; three alternating launches of a dev and a stable
build in one profile made two requests. Extras driven: a staging build follows staging, a
file named winner prints the CODEAF_INSTALL_NAME=winner form, /update stable on a
devaf takes the override and a failed download ends with the devaf line. The rc road was
driven at both heads: wrong at 1b9eb958d (/get/codeaf/rc beside a notice naming
v0.3.0), right at 806be7745.

The four manual gaps that drive surfaced — the third curl form and the chat's source-build
refusal unquoted, a wrong clause about cross-channel --check, and "how do I keep my dev
build up to date" ranking behind the dev-server page — are closed in a6d98c596, by heading
vocabulary and quoted strings, never by the probe.

🤖 Generated with Claude Code