[jayleaton]

Stacked on #233 (copy and names). Merge that first.

Summary

The CLI is now called ada. t3 stays a working alias everywhere it existed, so existing installs, scripts and service units keep running unchanged.

  scripts/install.sh, install.ps1   link `ada` AND `t3` (ada.cmd/t3.cmd) to the same runtime; banner/help say Ada + `ada`
                                    a foreign program on one name -> install the other and say so; fail only if both are taken
  ada install / ada update          install or repoint both names; update repoints the sibling only when it is ours
  desktop app (DesktopCliShim)      writes <home>/bin/ada beside t3, links ~/.local/bin/ada; never replaces a foreign `ada`
  apps/server package.json, npm launcher   bin: { ada, t3 } -> same entry
  CLI help/messages                 `Command.make(CLI_COMMAND)`, "run `ada up`" hints (only when `ada` on PATH is this install)
  Settings → About                  "ada command" row, search entry still matches "t3"
  fork-nightly-release.yml          release title "Ada Nightly $VERSION"; product name falls back to 'Ada'
  test-agents-windows-installer.ps1 shortcut/uninstaller names follow the product name; exe stays `T3 Agents.exe`
  docs/user, README                 teach `ada`; keep `t3` where an older host, upstream, or the MCP server name needs it
  triage (playbook, prompts, TriageService)   files issues on and clones jayleaton/t3code (CLI_RELEASE_REPOSITORY),
                                    says `ada triage` / `ada serve`; PLAYBOOK.md stays byte-identical to TRIAGE_PLAYBOOK
  .github/ISSUE_TEMPLATE/via-triage.yml   "Filed with `ada triage`"
- scripts/upstream-install-commands.test.ts   drop the temporary "CLI copy" and triage allowlist entries, and the triage exclusion from the install-command guard

Deliberately unchanged:

• Service units. They keep running the exact runtime path they run today. The only change is the systemd unit description, now Ada server, which marks an installed unit out of date. The next version update rewrites it.
• Names copied to or matched by another host:
  • The update command copied for a remote host stays t3 update <version>, because that host may be older.
  • servicePreflight names the older t3 that shadows the new one.
  • The desktop launcher marker text stays as it is, because older builds recognise their launchers by it.
  • The MCP server name is still t3.
• Internal file names. Archive file names (t3-<version>-…), the executable inside them, the npm package name t3, and the T3-Agents-* artifact patterns.

Evidence

node apps/server/src/bin.ts --help, on main (97f71b5) and on this branch:

before  Run T3 Code in this terminal and open it in your browser. To use it from your other devices, run `t3 up`.
        USAGE  t3 <subcommand> [flags] [<cwd>]
after   Run Ada in this terminal and open it in your browser. To use it from your other devices, run `ada up`.
        USAGE  ada <subcommand> [flags] [<cwd>]

Tests extended for the alias (existing cases and tables, no new suites):

• scripts/install.test.ts: both links are created, and a foreign ada is left alone.
• scripts/build-npm-launcher.test.ts.
• apps/server/src/cli/{install,invocation,update}.test.ts.
• The desktop shim and command tests: both shims are written, a foreign ada is preserved, and uninstall removes ours.

Checks:

• vp run check:changed: pass: format, lint, knip, typecheck (41 packages), test (236 files: 4,094 passed), react compiler
• node scripts/check-fork-guards.ts: the install-command guard is re-pinned because it no longer exempts the triage prompt. It still fails on a planted npx t3 in triagePrompt.ts.
• install.sh tests run only on Linux CI. The linking and lookup cases also passed on a temporary macOS copy.
• install.ps1 tests run only on Windows CI and were not run here.

Merge Danger

Door: two-way. Reverting removes the ada links on the next install or update, and t3 never stopped working. An ada link that is already installed stays until the user removes it. It is harmless, because it points at the same runtime.

Blast Radius: consumers

• Install scripts and the desktop app now create a second command on PATH.
• Anyone with their own ada keeps theirs. Ours is skipped with a message.
• Release. The nightly release title changes. The FORK_PRODUCT_NAME repo variable is still T3 Agents. When JJ sets it to Ada, macOS builds produce Ada.app for new installs (updates keep the old path), Windows shortcuts and the uninstall entry become "Ada", and the Windows installer test reads the new name from the workflow input.

Model and harness: Claude Opus 5.5 in Claude Code (T3 Code), with an Opus 5.5 subagent for the CLI slice.

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	5.0 KiB	—	6.8 KiB	✅
Codex	Thread snapshot wire	—	3.8 KiB	—	4.9 KiB	✅
Codex	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Codex	Live turn WebSocket decoded	—	21.5 KiB	—	24.4 KiB	✅
Codex	Live turn messages	—	1	—	8	✅
Claude	Total thread wire	—	5.0 KiB	—	6.8 KiB	✅
Claude	Thread snapshot wire	—	3.8 KiB	—	4.9 KiB	✅
Claude	Live turn WebSocket wire	—	1.2 KiB	—	2.0 KiB	✅
Claude	Live turn WebSocket decoded	—	21.9 KiB	—	24.4 KiB	✅
Claude	Live turn messages	—	1	—	8	✅

Baseline: unavailable · PR result: 70c1792 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[jayleaton]

Two blocking issues. Both hit existing installs that have only t3, or where a foreign ada is already on PATH, which is the case the installer deliberately preserves.

1. apps/server/src/cli/update.ts:590 (and ada service restart at :611). The update instructions always recommend ada. On an install that has only t3, or where a foreign ada was kept, following them fails or launches another program, and the service stays on the old version. Resolve the command we own before printing, and fall back to t3 or the quoted launcher path.
2. apps/web/src/components/settings/CliCommandSettingsRow.tsx:59. Settings advertises the ada command, but DesktopCliCommand computes install and PATH status only from t3. When the alias couldn't be installed because of a foreign ada, or an older desktop install has only t3, Settings still reports success without naming the command that works. Expose the actual installed command and the collision state, and show t3 when ada is unavailable.

CI is green, and the changed-file lint, the typechecks for the 7 affected packages and 164 focused tests pass. #233 and #235 have no blocking findings.

[jayleaton]

Fixed in 70c1792: ada update names the command this install owns (ada, then t3, then the quoted runtime path), and Settings shows the name that runs the install, plus any foreign ada that blocked the alias.