feat(tui): offer the other backend once the first one works - #226
Open
plombeer31 wants to merge 2 commits into
Open
feat(tui): offer the other backend once the first one works#226plombeer31 wants to merge 2 commits into
plombeer31 wants to merge 2 commits into
Conversation
atomic-agent holds local and cloud at the same time and switches between them mid-session. Nothing in the first run ever said so, so an operator who configured one of them left believing that was the choice they had made. After the first backend verifies, the flow offers the other one — once. The rules, all pinned by `decideSecondBackendOffer`: - a custom endpoint never sees it: someone pointing the agent at a server they already run has answered the question by running it; - both configured, no offer — there is nothing left to add; - a skip is not followed by a pitch; - shown once, recorded in `tui.onboarding.proposedSecondBackendAt` at the moment it is *shown*, so a declined offer never comes back. Accepting re-enters the other branch — the model picker, or the providers wizard — and the flow finishes for real when that lands. Declining hands over to the agent and points at ctrl+p.
This was referenced Aug 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #225 → #224 → #223 → #222 → #220.
Why
atomic-agent runs local and cloud side by side and switches between them mid-session. The first run never said so, so an operator who configured one left believing that was the choice they had made — and the second backend is a switch away, not a reinstall.
The screen
Mirrored when local came first ("Set up a cloud model too — an API key and a model, about a minute, for the heavy turns").
When it is not shown
decideSecondBackendOfferis a pure function with the whole rule set, and a test per rule:The stamp is written when the offer is shown, not when it is answered: the offer was made either way, and a declined one must not come back on the next launch.
Flow
Accepting re-enters the other branch — the model picker, or the providers wizard — and the flow finishes for real when that lands (by then
alreadyProposedis set, so it closes rather than looping). Declining hands over to the agent.The decision lives in the host effect rather than the reducer, because it reads config; the reducer stays pure.
Tests
propose-second-backend.test.ts— one case per rule above.onboarding-propose-step.test.tsx— both directions of the offer and the cursor.Full suite: 5196 passed.
fs-glob-realandsend-message-concurrencyfail onmain;bootstrap.test.tsflaked under parallel load and passes in isolation (26/26).