chore: remove --classic mode

[bird-m]

Summary

The wizard had four mode branches: agent, CI, classic, and TUI. Classic — interactive prompts without the rich Ink TUI — was a legacy fallback we no longer need. Removing it collapses the mode handler to three branches and lets us drop a couple of small bits of code that only existed to serve it.

Changes

• Drop the public --classic yargs option (src/commands/default.ts) and the hidden AMPLITUDE_WIZARD_CLASSIC env-var passthrough shadow (bin.ts).
• Remove the entire else if (options.classic ...) branch in the default command handler (~30 lines), including its bespoke runDirectSignupIfRequested onSuccess hook that called resolveCredentials({ requireOrgId: false }).
• Drop the onSuccess callback parameter on runDirectSignupIfRequested — agent and CI never used it, so the helper is now a straightforward fire-and-return.
• Drop the !options.classic && AMPLITUDE_WIZARD_CLASSIC !== '1' guards from the agent-detect TTY check (no longer reachable once the branch is gone).
• Comment-only sweep across account-creation-flow.ts, wizard-session.ts, zone-resolution.ts, orchestrator-context.ts, agent-runner.ts, store.ts, store.test.ts — the mode tally that read "agent / CI / classic / TUI" now reads "agent / CI / TUI".

Net diff: 10 files, +24 / -92.

What's preserved

• LoggingUI is kept — CI mode and the login / region / feedback / slack / mcp subcommands still use it.
• getOrAskForProjectData is kept — agent-runner still routes through it for CI mode and the rare TUI-startup-failure fallback.
• ExecutionMode was always 'interactive' | 'ci' | 'agent' (no 'classic' member), so no enum changes were needed.

Test plan

• pnpm tsc --noEmit
• pnpm exec vitest run --pool=forks --maxWorkers=1 — 187 files / 2826 tests passing
• pnpm lint
• Smoke: pnpm try opens the TUI as before
• Smoke: pnpm try --agent emits NDJSON as before
• Smoke: pnpm try --ci --install-dir <fixture> runs non-interactively as before
• Smoke: AMPLITUDE_WIZARD_CLASSIC=1 pnpm try no longer routes to a removed branch (should now fall through to TUI / agent auto-detect, same as no flag)

🤖 Generated with Claude Code

---

Note

Low Risk
Low risk: this mainly removes a legacy execution branch and related flags, with minimal behavioral impact beyond no longer supporting --classic/AMPLITUDE_WIZARD_CLASSIC.

Overview
Removes the legacy classic prompt-based mode from the wizard, collapsing the default command handler down to agent / CI / TUI only.

Drops the public --classic flag and the hidden AMPLITUDE_WIZARD_CLASSIC env passthrough, deletes the classic-mode execution branch, and simplifies runDirectSignupIfRequested by removing its classic-only success callback. Updates comments/tests/docs references to reflect the new three-mode setup.

^{Reviewed by Cursor Bugbot for commit 7275893. Bugbot is set up for automated code reviews on this repo. Configure here.}

[bird-m]

bugbot run

[kelsonpw]

Review

Nice cleanup — removing a legacy mode is the right call and the shape (drop the branch, drop the onSuccess callback that only existed for it, comment-sweep the survivors) is clean.

Main concern: bin.ts shadow removal is likely a regression

The doc comment at bin.ts:465-468 says these hidden shadows exist so .env('AMPLITUDE_WIZARD') + .strict() don't crash on env-var injection. The benchmark-file comment further down (~554-558) is even more explicit: "Without these shadows, .env('AMPLITUDE_WIZARD') auto-maps them to argv keys that .strict() then rejects — crashing every command (including --help) the moment a developer has one of them exported in their shell."

Dropping the classic shadow means a user who currently has AMPLITUDE_WIZARD_CLASSIC=1 in their shell rc — which any prior classic-mode user plausibly does — will hit Unknown argument: classic on every wizard invocation. That contradicts the PR description's last (unchecked) smoke test, which expects the env var to silently fall through to TUI/agent.

Two options:

1. Keep the shadow with a comment like // Backwards-compat: --classic is removed but the env var lingers in users' rc files; this no-op shadow keeps yargs.strict() from crashing them. All call sites already ignore options.classic post-PR.
2. Actually run that smoke test (AMPLITUDE_WIZARD_CLASSIC=1 pnpm try). If it crashes, go with option 1.

Worth adding a CLI test that asserts a stale AMPLITUDE_WIZARD_CLASSIC=1 env doesn't crash strict-mode parsing — nothing currently covers it.

Quiet behavior change worth noting in the description

src/commands/default.ts:246: pre-PR, a non-TTY env with AMPLITUDE_WIZARD_CLASSIC=1 would fall into the classic branch. Post-PR, the env var is no longer consulted there, so the same env auto-promotes to agent mode via isNonInteractiveEnvironment(). Probably the intended outcome, but anyone scripting around that env var will start getting NDJSON instead of pretty prompts.

Minor / nits

• src/commands/helpers.ts:705 — the deleted comment block ("Scope this catch narrowly so an onSuccess throw below cannot re-emit telemetry...") captured a real invariant about wrapper_exception not being double-emitted. With onSuccess gone the comment is moot, but consider keeping a one-liner — e.g. // Narrow catch: only the wrapper itself; performSignupOrAuth has already emitted its own success/failure telemetry. Otherwise a future refactor won't know why the catch is so tight.

• src/lib/agent-runner.ts:746-747 — TUI fallback is a bit ambiguous as a phrase. Worth specifying which fallback (e.g. "the rare TUI-startup-failure fallback that drops into agent-runner via getOrAskForProjectData", matching CLAUDE.md's language).

• src/commands/helpers.ts — once onSuccess is gone, both remaining callers of runDirectSignupIfRequested (default.ts:279 and :312) pass the same 'cached-token resolution' string. The fallbackLabel parameter is effectively a constant now. Could be inlined in a follow-up — fine to leave as a knob in case CI vs agent diverge later.

Tests

• 187 files / 2826 tests pass per the PR description ✅
• No coverage for the strict-mode env-var graceful-fallthrough claim — see point 1.

Verdict

Low-risk in spirit; the bin.ts shadow removal is the one place this could bite real users. Keep the shadow or verify the smoke before merge.

[kelsonpw]

Following up on the top-level review concern about the bin.ts shadow — I think this is worth fixing before merge. The cost is ~6 lines and the failure mode (yargs .strict() rejects every command, including --help, for any user with AMPLITUDE_WIZARD_CLASSIC=1 still in their shell rc) means an affected user can't self-diagnose by running --help to see what's changed.

Concrete fix

Restore the shadow as a no-op in bin.ts (right after the install-dir shadow at ~line 493, where it lived before this PR). It does not reintroduce any classic-mode behavior — the branch deletion in defaultCommand correctly stays, and options.classic just becomes a parsed-but-unused argv key, which yargs is happy with.

    'install-dir': {
      hidden: true,
      describe: 'internal: AMPLITUDE_WIZARD_INSTALL_DIR env-var passthrough',
      type: 'string',
    },
    // Backwards-compat: --classic was removed but the env var lingers in
    // users' rc files; this no-op shadow keeps yargs.strict() from rejecting
    // AMPLITUDE_WIZARD_CLASSIC when .env('AMPLITUDE_WIZARD') auto-maps it.
    classic: {
      hidden: true,
      describe: 'internal: AMPLITUDE_WIZARD_CLASSIC env-var passthrough (no-op)',
      type: 'boolean',
    },
    // The `apply` subcommand spawns a child wizard process and passes the

Optional: pin the contract with a one-liner

Wherever the existing CLI tests already shell out to the wizard binary:

it('does not crash strict mode on stale AMPLITUDE_WIZARD_CLASSIC=1 env', () => {
  const result = spawnSync('node', [BIN, '--help'], {
    env: { ...process.env, AMPLITUDE_WIZARD_CLASSIC: '1' },
  });
  expect(result.status).toBe(0);
  expect(result.stderr.toString()).not.toMatch(/Unknown argument/);
});

Belt-and-suspenders, but locks in the invariant so the next person dropping a shadow doesn't repeat it.

(Side note: I tried to leave this as an inline suggestion block on the actual line in bin.ts, but GitHub's review-comment API kept returning a generic 422 on every anchor in this PR — known flake.)

[kelsonpw]

Honestly i don't really care if the CLI breaks if you pass --classic, i doubt anyone uses it. Feel free to ignore.