refactor: migrate interactive prompts from survey to huh

[nf-matt]

Implements the migration proposed in #945.

AlecAivazis/survey is archived (last release June 2023, 61 open issues) and its API blocks features like ESC-to-cancel. This branch replaces it with huh (actively maintained, generically-typed Select, first-class theming, built-in ESC-cancel) behind the existing pkg/testable shim, and drops the survey dependency.

Why one branch instead of the per-package PRs from the RFC: I didn't hear back on #945, so I've consolidated the work here. The commits still follow the RFC's incremental plan — each is behavior-equivalent, self-contained, and independently revertible, so this can be reviewed commit-by-commit.

Commit progression:

1. Close the testable-shim leak (callers bypassing the shim).
2. Add huh v2; introduce a Prompter interface with a huh-backed Confirm; migrate cfaws/env.go.
3. Add Select / Input / Password methods and migrate their callers, package by package.
4. Add validator-accepting Input/Select and migrate validator-using callers.
5. Add SelectWithFilter (bubbles/list) and migrate the assume profile picker — removing the SelectQuestionTemplate monkey-patch and profileNameMap workaround called out in the RFC.
6. Add ConfirmWithHelp/InputWithHelp and migrate Help-using callers.
7. Drop the survey dependency.
8. Theme the huh forms and the filter picker.
9. Add unit tests for the newly introduced logic (see below).

Tests: the last two commits add coverage for the pure logic this migration introduced in pkg/testable, without requiring a terminal:

• Required, testInputAsBool, and testInputAsString (the test-mode input helpers).
• rankFilter (the generic filter ranking).
• selectFilterModel.Update — the filter-picker key handling, including the ESC-clears-filter-then-cancels behavior that motivated moving off survey. A small no-op refactor (refactor(testable): extract rankFilter and newSelectFilterModel) exposes these seams for testing without changing behavior.

Verification: go build ./... clean; go vet ./pkg/testable/ clean; go test ./... passes with no failures.

[meyerjrr]

Thanks for the contribution! Code looks good, only some small nit picks on some unneeded code and a rename.

I'm a fan of charmbracelet and their work as well, really awesome to see it used in here.
There were a couple of usability quirks that I'm curious if can be confgured in huh.

• When using a menu like granted settings set the filter option after initiating with / doesn't display the text being filtered on. Not a huge issue but would be slightly nicer to see what I'm filtering against.
• Another one (honestly not blocking) but when running some commands we display warnings or info messages before the primary CTA, one example is the registry warning commands. Because huh pushes the CTA to the top of the terminal - these info messages can get cut off, see example image (that is the very top of my terminal):

Before:

[meyerjrr]

For the most part the prompter interface is just a indirection to the huh library - we could probably just use each of these methods directly and drop this interface

[nf-matt]

Agreed, dropped it. It went in as scaffolding on the assumption that the survey and huh paths would need to coexist while callers moved over; that never happened, huhPrompter was the only implementation, and the migration ran through the package-level functions instead. It wasn't the test seam either — that's the isTesting branch inherited from the old testable.AskOne.

[meyerjrr]

Not quite what I had in mind, the interface is gone but there are still many instances of passthrough functions bloating the code that we could use without, eg:

func Select(message string, options []string) (string, error) {
	return defaultPrompter.Select(message, options)
}

I understand that this was probably following what already existed in the usage of the testable package but I think we take a different approach here.

The wrapper in prompter is trying to replicate what survey does and it just doesn't compose as well and we are bloating the package with many of the same call signatures to solve it.

But I propose here that we (for now) remove most of what is in this file package, and replace it with an export for the huh form that will be used around the granted app so that things stay consistent:

 // form wraps a single huh field with granted's output, keymap and theme.
 // Output goes to stderr: stdout carries the GrantedAssume line the shell evals.
 func form(field huh.Field) *huh.Form {
 	return huh.NewForm(huh.NewGroup(field)).
 		WithOutput(os.Stderr).
 		WithKeyMap(huhKeyMap).
 		WithTheme(huhThemeOpt)
 }

call sights then use the huh API directly:

var confirm bool
err := prompt.Form(huh.NewConfirm().Title("Use Firefox as default Granted browser?").Value(&confirm)).Run()

This has a couple advantages imo but I am happy to hear any pushback from yourself or any maintainers:

• Nobody has to learn a new granted-specific prompt API they read huh's docs to add.
• Confirm/ConfirmWithHelp/Select/SelectWithValidator/Input/InputWithValidator/
  InputWithHelp/Password all go, along with confirmWith/inputWith/selectWith and the
  huhPrompter type and defaultPrompter global. The package becomes form(), huhKeyMap,
  grantedTheme, NonEmpty.
• The stdout requirement for assume stays enforced in exactly one place, which is the only reason not to call huh.NewForm at each site directly.

[meyerjrr]

Suggested change

	var Required = func(s string) error {
	var NonEmpty = func(s string) error {

[nf-matt]

Noted and incorporated.

[nf-matt]

Thanks for reviewing! Your catches deserved thorough answers, and they got me digging into a few things — including the muscle memory a vim-style / filter would break, and a couple of issues in huh itself. The goal was to make things better overall, not just different.

Summary below, since the select code changed shape as a result.

The two quirks you spotted turned out to be one bug, and it's upstream in huh.
huh.Select has a bug where a row that scrolls off the top is the one huh draws the filter text on — which is why the text you were typing wasn't visible. That's charmbracelet/huh#669. I've put a fix up as charmbracelet/huh#804, but it hasn't been merged yet, and the state involved is unexported so it can't be worked around from the outside.

ESC had a related problem I hit while testing that. huh.Select binds it to its filter and I also bound it to the form's Quit, and Form.Update matches Quit before the field ever sees the key. So selects now drive the field directly rather than through a huh.Form, and rebuild it whenever the filter changes. A fresh field starts at the first match with an unscrolled viewport, which sidesteps #669 rather than trying to repair it, putting ESC back within reach: it clears an active filter first and cancels only when there is none.

Two behavioral changes from what you already reviewed:

• Typing filters directly, with no / first. That's what Survey did (select.go appends any typed key to the filter, and explicitly disables vim mode to do it), and what the assume profile picker has always done. Adopting huh's / would have been a silent change to the most-used command, so instead, no letter is bound to navigation — huh binds j/k and g/G by default and those are unbound here so they reach the filter.
• Menus cap at ten options. Without a cap the list grows to fill the terminal, which is what pushed the registry warnings off the top of your screen. The height only ever shrinks, so short prompts render exactly as before.

Separately, I noticed settings set and sso-tokens clear list their menus in a different order on every run — they range over a map. That's pre-existing and unrelated to this PR, so I'll send it as its own small change rather than fold it in here.

Happy to split any of this out if you'd rather review the migration on its own.

[nf-matt]

I fixed the merge conflict.

[meyerjrr]

Hey @nf-matt apologies for the delay in review. Haven't a a lot of time recently!

Again very appreciative for the effort to move granted over to a modern selection library. I have a few more requests in how we are shaping the new survey API. The reason is that this code sits right on the path every assume invocation takes, and it touches many commands, so the shape we land on is one we'll live with for a while and is quite important to the CLI's health and code maintainability.

If you have any pushback I am open to feedback, but my feel here is that we do not want to be maintaining much custom cli logic here and instead would rather lean on existing packages an API's to help granted run!

[meyerjrr]

Why do we want this? ctrl+c is pretty standard for cli applications (granted included). Sorry if its explained elsewhere but esc for quit would be undesirable I think

[nf-matt]

This a quick picker style UI (not unlike the popular fzf). Longer running TUIs tend to use q or F10 or Ctrl+c or vim-style commands. In those tools, it makes sense because you tend to remain in the UI for an extended time. In shorter-running tools focused around a picker, Esc feels more natural, in my opinion.

[meyerjrr]

Going to have to disagree here, most cli tools default to ctrl+c for exiting out of a TUI. esc is more often used as a 'go back' in my opinion but rarely a quit

[meyerjrr]

Not quite what I had in mind, the interface is gone but there are still many instances of passthrough functions bloating the code that we could use without, eg:

func Select(message string, options []string) (string, error) {
	return defaultPrompter.Select(message, options)
}

I understand that this was probably following what already existed in the usage of the testable package but I think we take a different approach here.

The wrapper in prompter is trying to replicate what survey does and it just doesn't compose as well and we are bloating the package with many of the same call signatures to solve it.

But I propose here that we (for now) remove most of what is in this file package, and replace it with an export for the huh form that will be used around the granted app so that things stay consistent:

 // form wraps a single huh field with granted's output, keymap and theme.
 // Output goes to stderr: stdout carries the GrantedAssume line the shell evals.
 func form(field huh.Field) *huh.Form {
 	return huh.NewForm(huh.NewGroup(field)).
 		WithOutput(os.Stderr).
 		WithKeyMap(huhKeyMap).
 		WithTheme(huhThemeOpt)
 }

call sights then use the huh API directly:

var confirm bool
err := prompt.Form(huh.NewConfirm().Title("Use Firefox as default Granted browser?").Value(&confirm)).Run()

This has a couple advantages imo but I am happy to hear any pushback from yourself or any maintainers:

• Nobody has to learn a new granted-specific prompt API they read huh's docs to add.
• Confirm/ConfirmWithHelp/Select/SelectWithValidator/Input/InputWithValidator/
  InputWithHelp/Password all go, along with confirmWith/inputWith/selectWith and the
  huhPrompter type and defaultPrompter global. The package becomes form(), huhKeyMap,
  grantedTheme, NonEmpty.
• The stdout requirement for assume stays enforced in exactly one place, which is the only reason not to call huh.NewForm at each site directly.

[meyerjrr]

Again not sure if we want to be supporting a custom selector toolchain inside of granted. The default / and vim motions for navigation are fine UX and most users might even prefer this.

Again might be keen to grab thoughts from another maintainer here @chrnorm @JoshuaWilkes

[nf-matt]

If there were a bunch of other command keys involved, / would make more sense to me. But the UI here is focused on selecting from lists, without other commands or features to jump to. I originally had / but chose to implement it the way your UI originally worked because it just felt more direct and intuitive to me.

[meyerjrr]

Yeah I totally get where you are coming from by keeping it how it was before. At the end of the day that was just how the library we picked at the time worked.

I am happy with the updated UX that the huh library brings and would rather not include extra custom logic to keep it in parity with how assume worked previously.

[nf-matt]

@meyerjrr I've spent quite a bit of time on this effort, and I like where my fork landed. At this stage I think I'll stick with it and just bring over any upstream changes. Thanks for considering the PR.