rename: the application ships as maxplayer, buyers are racers

[orveth]

The application ships as maxplayer, buyers are racers, sellers are runners. 40 files, no Cargo.lock change.

A textual rename of mobee would touch 141 files and collide with all nine open PRs — 35 of the 50 files under review. So this renames the surface and leaves the substrate: the binary, npm packages, release assets, repo references and the CLI's own output move; crates, the state directory and internal identifiers do not.

Second push — the blast radius my own predicate missed

Bounced on gate-fail, correctly. My acceptance pattern was release/mobee, which covers the cargo output path and nothing else. The nix output path is result/bin/mobee, the verifiers stage to $SHIPDIR/mobee and invoke /b/mobee, and the flake names it in meta.mainProgram and apps.default.program. One pattern, one form, six missed sites — and nix run github:MakePrisms/maxplayerai was a shipped regression, pointing at a path that no longer exists.

CI could never have caught it: the release workflow passes release.yml an explicit maxplayer path, so a green run is necessary and not sufficient, and specifically blind to every other reference to the same binary.

Fixed in 731b2b0. Two further couplings surfaced only because I enumerated forms instead of grepping one:

• each artifact verifier stages the binary under a fixed name and then invokes that name inside a container — renaming the staged file alone fails at runtime, not at build
• verify-arm64-artifact.sh greps the version output for ^mobee <semver>, which the renamed binary no longer prints

Now evaluated rather than asserted — nix eval on a real flake evaluation, no build required:

apps.x86_64-linux.default.program  ->  /nix/store/…-mobee-0.1.0/bin/maxplayer
packages.…default.meta.mainProgram ->  "maxplayer"

The store path stays mobee-0.1.0 because that is the package name, correctly unchanged.

Third push — rebased onto dev, and a string-level collision a file-list audit can't see

#204 rewrote scripts/crossmint-smoke.sh (561 lines) and #236 added to RELEASE.md. RELEASE.md auto-merged; the smoke script was the one conflict.

Resolved by taking dev's file byte-identically (proven with cmp, not asserted) and then re-applying the rename by rule — a command a human types or a path on disk moves; this script's own internals and the state directory do not. Six lines:

• the binary path default, which was the conflict itself
• two parser fixtures whose trailing text quotes the binary's own output
• two help-text lines naming maxplayer job / maxplayer collect <job_id>
• the no maxplayer binary at $MOBEE guard message

Left alone: every MOBEE_* var, ~/.mobee, the MOBEE= variable, and mobee_at() — plus the three prose lines about mobee_at(), since renaming the noun while the helper keeps its name reads worse, not better.

The collision worth naming: dev's new fixtures quote `mobee wallet mint-complete` — and this PR changes the Rust that prints that string (wallet_cli.rs:284). A file-list audit found the file; it could not have told me a fixture string was coupled to a Rust change. To be precise about the size of it: nothing would have failed. The fixture feeds parse_quote_id, which stops at whitespace and never reads that token. But its documented purpose is fidelity to real output, so it follows the binary.

That is checkable here rather than in CI, because the script ships its own parser suite:

MOBEE=/bin/true scripts/crossmint-smoke.sh --self-test   →  13/13 ok, incl. both edited fixtures
bash -n                                                  →  clean

What makes the binary rename separable

There was no [[bin]] section anywhere in the workspace, so Cargo was deriving the executable name from the package — which is why the application rename looked like it forced a crate rename. It doesn't:

[[bin]]
name = "maxplayer"
path = "src/main.rs"

Crates stay mobee deliberately — 81 of the 141 files live there, nothing publishes to crates.io, so users never see those names. A comment in crates/mobee/Cargo.toml says so, so the next reader doesn't file it as an oversight.

npm

The ruled layout: launcher unscoped as maxplayer, payloads as @maxplayerai/linux-x64|arm64 as optionalDependencies.

Directories under npm/ keep their paths. Nothing derives from the launcher directory name, but seven sites hardcode the literal path (release.yml:51/301/302, npm-pack-local.sh:24, verify-release-version.sh:67/71/72). "Nothing depends on it" ≠ "nothing references it" — a rename is only free when both hold. The payload dirs must keep the cli-<platform> shape regardless: the publish guard globs npm/cli-*/ and derives the platform from the basename.

The payloads stay scoped, so --access public in the publish job remains load-bearing rather than vestigial.

The artifact name is now an argument

package-release-asset.sh takes the name as $5 instead of hardcoding it. The release matrix is about to ship a second binary from this same script — the runner, built --features acp,wallet — and hardcoding maxplayer here would mean un-hardcoding it in the very next PR. Making the next change's premise true is naming work.

Proven locally, including the negative legs:

omitted          -> maxplayer-0.1.0-linux-x64.tar.gz
explicit         -> maxplayer-runner-0.1.0-linux-x64.tar.gz, member name follows
empty            -> REFUSED
a/../b           -> REFUSED  (the name lands in a path and a tar member)
two runs, custom -> byte-identical, so #247's determinism survives parameterization

${5-default} and not ${5:-default} on purpose: the colon form substitutes for an argument passed-but-empty, which is exactly how an unset caller-side variable arrives — and defaulting there would quietly produce a racer-named archive for a caller that thought it named something else. My first version used the colon form, which made the empty-name check unreachable; the red leg caught it.

An invariant now stated at its site

release.yml's npm publish step constructs the asset filename rather than globbing dist/. Once the runner artifact exists, a glob there would publish whichever archive sorted first — which is how a seller binary ends up on the registry under the racer's package name. There is now a comment saying so, because the constructed form looks like something a later cleanup would "simplify".

asset-<platform> → asset-racer-<platform>, and verify-buyer-surface.sh → verify-racer-surface.sh, so the runner PR is purely additive: it adds a matrix dimension and a sibling verifier, renaming nothing.

Two renames deliberately NOT made

1. The buyer and sell subcommand tokens stay.

sell cannot become run — run already exists as a different command (agent execution). runner was rejected as too close to run for a money CLI.

buyer is the sharper one. cli.rs matches Some("buyer") and daemon.rs passes .arg("buyer") to spawn itself — a string-to-string pairing the compiler cannot check. Rename one and the buyer daemon fails to spawn at runtime, having compiled cleanly.

⚠ And the tests that would catch it never run. CI runs cargo test -p mobee-core four times and cargo test -p mobee zero times, so crates/mobee/tests/cli_e2e.rs and mcp_daemon.rs — the latter being the connect-or-spawn acceptance test — are never executed. Filed separately; it is not this PR's to fix, but it is why the token rename waits for a PR whose correctness someone can actually demonstrate.

How this surfaced is worth a line: I had already written maxplayer run into a Dockerfile comment as a substitution for mobee sell, because the rename made them sound like the same command. They aren't. That is a rename inventing a behaviour change, and it would have shipped as a one-word comment edit.

2. MOBEE_HOME and ~/.mobee are untouched. 34 MOBEE_* variables, plus ENV MOBEE_HOME=/data in the Dockerfile and live seats. That directory holds the 0600 key, buyer.sqlite and the spend ledger. A MAXPLAYER_HOME defaulting to ~/.maxplayer would silently start every existing install with an empty wallet while real balances sat at the old path. That is a migration needing old-var fallback and a balance read either side of it — not a rename.

Same principle covers the Dockerfile's -p mobee build flag and its unix service account, both substrate.

Also here

RELEASE.md records the version scheme, because it is forced rather than preferred: plain 0.x.y, no -rc suffix. Any hyphen makes the workflow treat the release as a pre-release, and a pre-release publishes under the rc dist-tag only — leaving latest unset and npx maxplayer with nothing to resolve. The dist-tag branch's own reasoning assumes a stable already exists; the first release is the one case it doesn't cover. The doc keeps the caveat that the latest-unset half is npm's documented behaviour and has not been executed here, along with the one-command repair if it ever bites.

The docs also stop advertising npx mobee — that package was never published (registry.npmjs.org/mobee → 404, against an express → 200 control), so we were documenting an install path that could not work.

Acceptance

Every clause measured, both directions, before and after:

Re-measured on the rebased tree, not carried over from the previous push. Each row states the predicate, because a count alone proves you counted — not that you counted the right set.

ZERO expected — every form the binary is NAMED by
  release/mobee            0*  cargo output path   (*1 verbatim CI-error quote in a guard comment)
  result/bin/mobee         0   nix output path
  /b/mobee                 0   container invocation
  $SHIPDIR/mobee           0   staged filename
  bin/mobee                0   npm + nix manifest entries
  mainProgram = "mobee"    0   flake meta
  program = …/bin/mobee    0   flake apps
  ^mobee <semver>          0   verify-arm64's version assertion
  MakePrisms/mobee         0   repo references
  npx mobee                0   an install path that was never published

UNCHANGED expected — substrate, stated as a predicate over the DIFF
  -p mobee                18 occurrences; 1 diff line contains one and PRESERVES it
  name = "mobee*"          4 crates; 0 diff lines touch one — 0 renamed, 1 [[bin]] ADDED
  MOBEE_*                 33 distinct; 1 diff line contains one and PRESERVES it
  cli.rs Some("buyer")     1 ) still paired — the money-path self-spawn is untouched
  daemon.rs .arg("buyer")  1 )
  Cargo.lock               0 files changed by this branch
  [[bin]] name             1 = maxplayer — the name asserted POSITIVELY, not as an absence

The both-directions check is the point: a blanket s/mobee/maxplayer/ would have broken the build via -p mobee and silently kept old binary paths elsewhere. Either half alone is a half-verified rename.

The two diff lines that touch substrate are the interesting ones, not exceptions to wave past — both carry a moving token and a staying one on the same line:

-  "mobee run requires rebuilding with the acp feature: cargo run -p mobee --features acp -- run …"
+  "maxplayer run requires rebuilding with the acp feature: cargo run -p mobee --features acp -- run …"

-  # A scratch home, unconditionally. With MOBEE_HOME unset, mobee falls back to ~/.mobee — a real
+  # A scratch home, unconditionally. With MOBEE_HOME unset, maxplayer falls back to ~/.mobee — a real

⚠ Two numbers in the previous version of this body were wrong, both true measurements of a set I hadn't defined: -p mobee read 6 where the tree has 18, and MOBEE_* read 34 against 33 distinct. Neither was load-bearing, which is exactly why they went unchecked — so the rows above are now predicates over the diff rather than counts of the tree.

⚠ Not verifiable here: nothing was compiled. There is no Rust toolchain on this box (nix only), so the [[bin]] change is asserted from Cargo's documented behaviour, not from a build. CI proves it — Verify the version matches the release takes the binary path as an argument and dies with no executable at … if the name is wrong. If it fails, the fallback is renaming the crate.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
mobee	Ready	Preview	Jul 29, 2026 11:03pm