feat(setup): two-step wizard

[Behnam-RK]

Stacked on #51 → #50 → #49.

Implements the two-step shape you described: step 1 countries, step 2 an automatic-detection tickbox that reveals the self-hosted options when unticked, with configureVPN dropped.

The shape

dezhban setup --questions now emits exactly:

blockedCountries | group 1 | multiselect | gate —
otherCountries   | group 1 | list        | gate —
autoMode         | group 2 | bool        | gate —
tunnels          | group 2 | multiselect | gate autoMode=false
profileFiles     | group 2 | list        | gate autoMode=false
endpoints        | group 2 | list        | gate autoMode=false

Both wizards read this one set, so dezhban setup changes with the app.

Dropping configureVPN needed two guards

That question was what kept a re-run from touching a working VPN config (Apply returned early when it was false). Removing it means a run always writes the VPN keys, so:

1. autoMode's default is seeded from the config. A config with pinned vpn.tunnelInterfaces starts on manual. Without this, a re-run would default to automatic, and Apply clears TunnelInterfaces under AutoMode on purpose — so pressing Enter through the wizard would have silently unpinned interfaces someone chose deliberately. Pinned by TestAutoModeSeedsFalseWhenInterfacesArePinned on both sides.

2. Input.Endpoints becomes *[]string, nil when the question was never shown. On macOS the endpoint question is gated behind "not automatic", so someone re-running setup to change their blocked-country list — leaving detection on, as recommended — reaches Apply with no endpoint answer at all. Writing that as an empty list would delete their server. Nil rather than empty for exactly the reason the existing AutoDiscover *bool is a pointer, and its doc comment already says so: an empty slice cannot be told apart from "asked, and cleared on purpose". The Swift side already had this property for free via shouldAsk.

One thing worth flagging

Off macOS the endpoint question is ungated. There is no live discovery on Linux or Windows, so an endpoint is required whichever detection mode is chosen — gating it would let a Linux user finish the wizard with a config that cannot enforce. TestEndpointsAreUngatedWhereThereIsNoDiscovery pins it.

The CLI renders step 2 as two prompts

A huh form binds every field before any of them is answered, so a question gated on another question in the same group would be decided by that question's seeded default rather than by what the user just ticked. The app has no such problem — it re-evaluates gates as answers change, which is what makes step 2 a single screen there.

Rather than split the shared question set to suit one renderer, the terminal now asks a group in waves: the ungated questions first, then re-evaluate, then whatever that opened up. Documented in cli.md so the difference is not a surprise.

Verification

• go build ./..., go vet ./..., go test ./... — pass. internal/setup gains five tests: the two-group shape across all three platforms, the pinned-interface seed both ways, the unasked-endpoint rule, the gating, and the off-macOS ungating.
• swift test — 248 tests pass (199 when this was opened; the rebase onto main and the review-loop rounds below added the rest). The SetupQuestionsTests JSON fixture is updated to the real emitted shape, and gains theWizardIsTwoSteps, anUnaskedQuestionWritesNoKey, and aSeededManualModeReWritesItsPins.
• dezhban setup --questions output inspected directly (above).

On-host checks added to docs/contribute/testing.md, the important two being: a re-run on a pinned config keeps its pins, and a re-run under automatic detection keeps configured endpoints. Also fixes a stale defaults delete com.dezhban.menu in the first-run checklist — that domain has been com.behnam-rk.dezhban.app for a while.

---

Rebase onto main

This branch was stacked on #51 and carried its own copy of that work as f75954c. #51 merged as f834f8f after review, and the two are not the same change — main's version renamed removeLoginItem to retractLoginItem(), moved uninstallerPath/uninstallerCommand into DezhbanCore/UninstallDecision.swift, and dropped the Step.removed flag deliberately. The local commit was the earlier draft, so the rebase drops it and keeps main's. Only the wizard commit replays.

Review loop

Four rounds of read-only review, with every fix applied by the orchestrator and covered by a test that fails against the unfixed code.

Round	Findings	Pre-existing	Loop-introduced	Headline
1	10	10	0	The CLI wave loop's deferral never fired
2	8	4	4	The app imported profile files the user had withdrawn
3	3	2	1	The "Two steps" on-host check was written for macOS only
4	1	0	1	A comma inside an option label read as two options

Stopped after round 4: it produced no new pre-existing defects, and its single finding was the loop's own.

The two that mattered

The wave loop shipped step 2 as one form. asked[q.ID] was set inside the same pass that read asked[q.RequiresID], so a question gated on one appearing earlier in the set — which is how autoMode sits relative to its three manual fields — was never held back. The fresh-config path looked right for the wrong reason: autoMode seeds true there, so the manual fields fail their gate outright. On a re-run against a pinned config, where autoMode seeds false, all four questions arrived on one huh form — and ticking automatic detection on that form retracted the gate for the endpoint field beside it, so wasAsked returned false and the endpoint that same form had just collected was silently dropped. That is the failure Input.Endpoints became a pointer to prevent, reproduced one layer up. It also made three docs describe a two-prompt step 2 that a pinned config never got.

The app imported withdrawn profile files. Round 1 gated the Go wizard's import on "was this question shown?" and left Swift ungated, so the two wizards disagreed for identical answers. Because the app reveals step 2 in place and re-evaluates gates live, unticking automatic detection, choosing files, then ticking it again makes the field vanish while its answer stays in the dictionary — and save() ran dezhban vpn import on it.

Regressions the loop caused and then fixed

Named rather than absorbed, since they are not the branch's:

• The Go-only import gate above, which created the Go/Swift divergence round 2 found.
• The tunnel pick list put an undetected interface into a list headed "Detected tunnels", with no marker.
• TestEveryGatedQuestionIsReachable as first written could not fail; its fixture answered autoMode false, which every plausible implementation gets right.
• Printing option labels put prose containing a comma into a comma-joined list.

Settled by decision

• On macOS, endpoints stays gated behind manual mode. A path to a hand-set server under automatic tunnel detection does exist and validates — untick automatic, leave the tunnel list blank, type the endpoint, giving tunnelInterfaces=[] plus your endpoint. vpn.autoDiscoverEndpoints defaults to true, so the gap only reaches someone who explicitly disabled discovery, and they still have config set vpn.endpoints. An OR-gate would mean adding a second condition to the shared Question JSON and honouring it in both wizards; not worth it for that case.

Not examined

• The prose. docs/usage/cli.md, docs/contribute/testing.md and the changelog entry total roughly 90 changed lines. A reviewer summarizes prose rather than citing lines in it, so no round genuinely examined the writing. Its factual claims were checked against the code — that is what caught the macOS-only on-host check and the unqualified "two consecutive prompts" — but a human read is still outstanding.
• internal/vpnimport, ConfigApply.apply, and the huh rendering internals, all unchanged by this branch.

Deferred to a separate PR

setup.Apply writes vpn.autoDiscoverEndpoints=true for a brand-new macOS config; Swift's configPairs never emits that key. So the app's first-run wizard and dezhban setup produce different configs on the same fresh host. Pre-existing and outside this diff, so it was left alone.

🤖 Generated with Claude Code