Module env_wizard 

Bare --env wizard (operator-surface PR-6): author or gap-fill a greentic.env-manifest.v1 manifest interactively, persist it, and hand off to the deployer’s env-apply engine via crate::env_mode.

greentic-setup --env demo (explicit --env, no bundle positional, no --answers, TTY) drives the deployer-owned manifest_form_spec() through the existing FormSpec prompt loop (crate::qa::prompts::prompt_form_spec_answers_with_existing — advanced gating and table rows come free), converts the answers with the deployer’s answers_to_manifest, writes the manifest file (the durable artifact — commit it), and runs the engine: plan rows, TTY confirmation, execute. Re-running against an existing manifest pre-loads it via manifest_to_answers: satisfied questions are kept (gap-fill mode); for full edits, hand-edit the file and re-apply with --answers <file>.

Secrets are the exception to the pure-form flow: this wizard drops the generic secrets table from the prompt loop and handles it last as a derived step. Once the bundles are known it reads each bundle’s packs’ secret-requirements.json (via the deployer’s greentic_deployer::runtime_secrets::bundle_secret_requirements, scoped to the bundle’s route tenant) and, for each required secret, asks whether the value comes from a named environment variable (the operator enters the NAME; apply reads it from the env / dev-store) or is pasted in now (collected with a masked prompt and handed to apply, which writes it to the env’s secrets store). The path is always auto-derived, and the pasted value is never written to the manifest. So the operator only enters the secrets the configured bundles actually need.

Basic vs advanced: by default the wizard asks only the everyday fields. The optional row columns an operator almost always leaves empty (customer_id, config_overrides, route_hosts on bundles; the welcome_* trio and secret_refs on endpoints) are hidden until --advanced is passed — the same flag that already reveals the optional top-level questions. The route path/tenant/team and endpoint links stay in the basic flow; the common multi-bundle setup needs them.

Functions

manifest_to_answers

Inverse of the deployer’s answers_to_manifest — manifest → wizard answers, for pre-loading an existing manifest into the prompt loop.

run_env_wizard

Wizard entry: prompt for the manifest path, pre-load or seed the answers, run the form, persist the manifest, and hand off to the engine. dry_run stops after the plan preview; otherwise the engine’s own TTY confirmation gates execution (no second confirm here).