[tee8z]

Stack: master ← #24 ← #19 ← #26 ← #27 ← #28 ← #29 ← #30 ← #55 ← this PR. It follows up on the review of #22.

@thebrandonlucas, this refactor touches the credential code from #22 and #55. Please review the pattern.

Summary

The credential functions in auth took the same &Settings, &GlobalFlags, and &SubmissionState on every call. Each caller in pick, api, wallet_currency, and startup passed all three through. This PR adds auth::Resolver, which holds those three values for one command. The functions become its methods.

There is no behavior change. No test changed.

Signatures

Function	Before	After
auth::resolve	(settings, scope, flags, submission)	resolver.resolve(scope)
auth::resolve_organization	(settings, scope, flags, submission)	resolver.resolve_organization(scope)
auth::exchange	(settings, scope, flags, credential)	resolver.exchange(scope, credential)
auth::discover	(settings, scope, flags, what, submission)	resolver.discover(scope, what)
auth::list	(settings, scope, flags, what, token)	resolver.list(scope, what, token)
api::Authorization::resolve	5 parameters	3 parameters
api::execute	7 parameters	6 parameters
pick::fill	5 parameters	4 parameters
pick::ask	6 parameters, fills a &mut Vec<String>	4 parameters, returns Vec<String>
wallet_currency::fill	5 parameters	4 parameters

The pattern

A struct holds the dependencies that stay the same for one command. Values that change during the command stay as method arguments.

#[derive(Clone, Copy)]
pub struct Resolver<'a> {
    pub settings: &'a Settings,
    pub flags: &'a GlobalFlags,
    pub submission: &'a SubmissionState,
}

startup::execute builds one Resolver after it reads the settings and scope. startup::local_command builds one for each discover call, because the other local commands need &mut Settings.

flowchart LR
    X["startup::execute"] -->|builds once| R["auth::Resolver"]
    R --> P["pick::fill"]
    R --> W["wallet_currency::fill"]
    R --> E["api::execute"]
    E --> A["Authorization::resolve"]
    L["startup::local_command"] -->|builds per call| D["Resolver::discover"]

Loading

The repository already uses this pattern. Steps<'a> in api.rs holds "what every step of one command's run shares." Api::new reads timeout, api_url, and the terminal from GlobalFlags one time.

Why the scope is not in the struct

pick::ask changes scope.org between resolve and exchange. If Resolver held a &Scope, pick could not get &mut Scope while the resolver exists. Each method takes the scope as an argument.

Why not one Context struct for everything

A single struct with all shared values is a service locator. docs/quality.md forbids this: "Pass dependencies through constructors. Do not use mutable global state or a service locator."

A context struct also causes these problems:

• It hides each function's real dependencies. Now, exchange does not use SubmissionState, so it cannot change the saved login. A context struct hides that fact.
• It conflicts with borrows. login, logout, import_key, and profiles need &mut Settings. pick needs &mut Scope. A struct with both forces &mut ctx everywhere, or a split back into parts.

What stays outside Resolver

Item	Reason
auth::select	voltage context shares it and never refreshes a login, so it needs no SubmissionState.
auth::login, logout, import_key, status	These are commands. login, logout, and import_key change Settings.
Mutation::execute	It uses settings and submission for the request journal, not for credentials. api::execute passes resolver.settings and resolver.submission explicitly, so Resolver does not become a general context.

pick::ask returns what it picked

Before, fill passed &mut Vec<String> to ask and read it after the call. fill ignored the vector when ask failed. Now ask returns Result<Vec<String>>. Esc, an empty list, or an API key returns the picks so far. An error returns no picks. The "Next time, pass …" hint shows in the same cases as before.

ask also resolves the credential itself now. It does this first, so a missing credential is still reported before a missing scope.

Review exceptions

• Crate-visible item: auth::Resolver. Its fields are public because it is a record with no invariant (docs/quality.md: "Expose fields directly on records"). Callers build it with a struct literal, so it has no constructor.
• No new dependencies, traits, getters, unsafe blocks, or lint exceptions.

Review tip

Most of the auth.rs diff moves five functions into impl Resolver<'_> and indents them. To see only the changed lines, hide whitespace on GitHub, or run:

git diff --color-moved=zebra --color-moved-ws=allow-indentation-change origin/feat/cli-wallet-currency-default...origin/refactor/cli-auth-context

Checks

On f260426, rebased onto #55 (0e6ff88). The rebase conflicted in auth.rs; the resolution keeps #24's expired_login and shell_word, and Resolver::exchange calls require_login, so a revoked session still gets the logout-then-login hint at the token exchange.

• cargo fmt --check, cargo clippy --locked --all-targets -- -D warnings, cargo machete --with-metadata: pass.
• cargo test --locked: 107 unit and 91 integration tests pass, including a_revoked_login_names_the_command_that_renews_it.
• python3 scripts/check-coverage.py: pass.
• CRAP (scripts/crap-report.sh): no function at or above 20. The highest is api::wait_for_payment at 19.24, which this PR does not change. pick::ask and Resolver::exchange are 14.00 at 100% coverage.
• Diff against feat(cli): default a payment's currency to its wallet's, and units to base units #55: 5 files, 224 insertions, 234 deletions.

Not run: VOLTAGE_BLESS=1 cargo test, because no global flag changed. The staging and live tutorials need credentials.

[tee8z]

Closing #60 contains this commit and continues the same pattern across auth, config, api, and startup, for discussion as one PR.