feat(setup): guide users by connection source

CHANGELOG.md

@@ -7,6 +7,7 @@ All notable changes to this project will be documented in this file. The format
 ### Added
 
 - [#204](https://github.com/mohanagy/miftah/issues/204) Added guided multi-account Google Search Console onboarding through the CLI and local Console, including an explicit opt-in first-success check that resolves only the selected target, verifies audit/policy/identity boundaries before its one declared read-only probe, and cancels with the requesting Console session. The check trusts only the catalog's reviewed launch envelope and fails closed without launching a process after execution-affecting customization. It creates named profiles with an explicit durable default and separate upstream-owned OAuth state directories per generated configuration file and profile, while continuing to keep browser login, token-cache contents, reauthentication, revocation, and account identity verification outside Miftah. A returning provider-owned account can now be added atomically through the reviewed adapter contract in either CLI or Console, with a fresh isolated state directory, a redacted fail-closed lifecycle record, and no token-cache access. It also adds a separate returning-user path for a simple local STDIO environment credential binding: CLI and Console accept a variable name rather than a secret, require every existing profile to share the same narrow binding, enforce multi-profile safeguards, use guarded audited replacement, and refuse remote HTTP, provider-adapter, OAuth, named-upstream, mixed-profile, duplicate-source, and arbitrary-override configurations. It also adds explicitly acknowledged local STDIO setup and client-entry import: literal executable plus bounded argument array, no shell, no secret-shaped values, no generic-command launch during onboarding, read-only default policy, destructive handling for unknown tools, and Windows-only direct absolute `.exe`/`.com` requirements to avoid a command-shell fallback. Bare interactive `miftah setup` now also lets a user choose one selected existing client entry: it reads one explicit absolute client file through a bounded verified handle, lists only safe entry names, imports from that same inspected snapshot, and never prints source command, argument, header, environment, or credential values. Returning CLI users can now review the durable default and fixed non-secret account metadata with `profile list`, and rerun only the selected provider adapter's declared, audited read-only readiness check with `profile test`, receiving a redacted report and nonzero outcome for any non-ready state without an arbitrary tool call, browser handoff, configuration mutation, or provider-cache access. It also adds a guarded CLI and local Console flow for setting or explicitly clearing one existing profile's non-secret description. It preserves all other profile fields, durable default, routing, OAuth bindings, credential and provider-cache ownership; writes through the existing audited replacement and exact-recovery transaction; and returns no configuration bytes or submitted label.
+- [#204](https://github.com/mohanagy/miftah/issues/204) Added outcome-first source choices to the interactive CLI and Console: known connector or pinned package, remote HTTPS endpoint, local executable, remote MCP with browser sign-in, or one existing client entry. Each choice reuses the existing hardened setup path; generic remote setup remains network-free and authentication-free, local setup remains no-shell and does not launch the executable, and client settings remain manual and untouched.
 
 ### Changed
 

README.md

@@ -46,7 +46,7 @@ Start with the row that describes how your upstream MCP authenticates.
 | Another exact-pinned npm or container STDIO server | Use `generic-npx` or `generic-docker`, then add profiles around it. |
 | A local executable and argument array you personally reviewed | Use `local-stdio`; it saves literal command and argument-array metadata without a shell. |
 | Remote HTTPS Streamable HTTP with a token or API key | In guided setup, choose `remote`; Miftah creates the strict `streamable-http` configuration with an optional secret-backed header. |
-| Remote HTTPS Streamable HTTP with standards-compatible OAuth | In bare guided setup, choose `remote sign-in`; for scripts, use `miftah setup --native-oauth`. Miftah discovers supported OAuth from the endpoint; use manual `connection add` only when a provider gives you registration details. |
+| Remote HTTPS Streamable HTTP with standards-compatible OAuth | In bare guided setup, choose `browser sign-in`; for scripts, use `miftah setup --native-oauth`. Miftah discovers supported OAuth from the endpoint; use manual `connection add` only when a provider gives you registration details. |
 | Local or provider-specific MCP that opens its own OAuth flow | Use Upstream-owned OAuth. Miftah wraps the process but does not take over its token cache. |
 | Google Search Console | Use the reviewed `google-search-console` adapter preset. OAuth remains upstream-owned. |
 | One account and no need for profile, policy, routing, or audit controls | Keep the direct MCP entry; Miftah may not add value for this case. |
@@ -63,7 +63,7 @@ Shell examples below use POSIX syntax, including `~`, `$HOME`, and `\` line cont
 miftah setup
 ```
 
-On a bare interactive `miftah setup`, first choose `new`, `remote sign-in`, or `import` at `Start from (new, remote sign-in, import) [new]`. Choose `new` and this starts by asking what you have: enter `remote` for a remote HTTPS endpoint, `local` for a reviewed executable and argument array, or a connector name such as `google-search-console`. It then collects the safe metadata that path needs and an output location, and can print an optional client JSON snippet for manual review. Choose `remote sign-in` when the remote MCP opens a browser to authenticate you. Miftah asks for the configuration name, account profile, and exact HTTPS endpoint, then discovers whether it can safely own a supported standards-based OAuth flow. It writes nothing if the endpoint does not prove one supported authorization server with dynamic registration. Keep `miftah setup --native-oauth` for scripted or repeatable setup. The plain `remote` path does not discover OAuth or call the upstream; use it for no-auth or documented API-key/header setup. Choose `import` when you already have one MCP entry in a client JSON file: Miftah asks for that explicit absolute file, lists only entry names, and asks you to select one. It never prints the source entry's command, arguments, headers, environment values, or credentials, and it does not scan or modify the source client file. It never asks for a token, password, or browser cookie. For `local`, it collects one literal argument at a time, shows a no-secret review summary, and requires an explicit acknowledgement. Miftah does not run the local executable during setup. Miftah validates the complete configuration before it writes an owner-restricted file, never overwrites an existing one, and never edits a Claude, Cursor, VS Code, or other MCP client file. Recognized adapters can then offer one explicit, provider-declared read-only readiness check; Miftah never guesses a tool or auto-approves a policy prompt. Use `miftah init` when you want the same catalog in a scripted command.
+On a bare interactive `miftah setup`, Miftah starts with `What do you already have? (connector, remote HTTPS, local executable, browser sign-in, import) [connector]`; choose `connector`, `remote`, `local`, `browser sign-in`, or `import` based on what you already have. At that prompt, enter `remote` for a remote HTTPS endpoint, `local` for a reviewed executable and argument array, or `connector` for a known connector or pinned package. It then collects only the safe metadata that path needs and an output location, and can print an optional client JSON snippet for manual review. Choose `browser sign-in` when the remote MCP opens a browser to authenticate you. Miftah asks for the configuration name, account profile, and exact HTTPS endpoint, then discovers whether it can safely own a supported standards-based OAuth flow. It writes nothing if the endpoint does not prove one supported authorization server with dynamic registration. Keep `miftah setup --native-oauth` for scripted or repeatable setup. The generic `remote` path does not discover authentication or call the endpoint; use it for no-auth or documented API-key/header setup. Choose `import` when you already have one MCP entry in a client JSON file: Miftah asks for that explicit absolute file, lists only entry names, and asks you to select one. It never prints the source entry's command, arguments, headers, environment values, or credentials, and it does not scan or modify the source client file. It never asks for a token, password, or browser cookie. For `local`, it collects one literal argument at a time, shows a no-secret review summary, and requires an explicit acknowledgement. Miftah does not run the local executable during setup. Miftah validates the complete configuration before it writes an owner-restricted file, never overwrites an existing one, and never edits a Claude, Cursor, VS Code, or other MCP client file. Recognized adapters can then offer one explicit, provider-declared read-only readiness check; Miftah never guesses a tool or auto-approves a policy prompt. Use `miftah init` when you want the same catalog in a scripted command.
 
 ## First setup: GitHub with Claude Desktop
 
@@ -227,7 +227,7 @@ If you already have a local or remote Claude Desktop, Claude Code, Cursor, or VS
 miftah setup
 ```
 
-At `Start from (new, import) [new]`, choose `import`. Give the exact absolute client configuration file, then choose one listed entry by number or exact name. This is the simplest first-use path: Miftah lists only entry names and never prints the source entry's command, arguments, headers, environment values, or credentials. It does not scan or modify the source client file.
+At `What do you already have? (connector, remote HTTPS, local executable, browser sign-in, import) [connector]`, choose `import`. Give the exact absolute client configuration file, then choose one listed entry by number or exact name. This is the simplest first-use path: Miftah lists only entry names and never prints the source entry's command, arguments, headers, environment values, or credentials. It does not scan or modify the source client file.
 
 For scripts or a repeatable handoff, use the explicit equivalent: