Feature Request: Environment profiles + secrets to run the same test on stage and prod

[Akanshsin]

Summary

Add first-class environment profiles so the same test can be executed against multiple environments (e.g. stage and prod) by switching a single flag, with each environment supplying its own variables and secrets.

Problem

kane-cli already supports variables and secrets (--variables, --variables-file, ~/.testmuai/kaneai/variables/*.json, {cwd}/.testmuai/variables/*.json, and secret: true). What's missing is a way to bind a named environment to a set of those values.

Today, running one test against both stage and prod means either:

• maintaining two near-duplicate variable files and remembering to pass the right --variables-file each time, or
• overriding values inline with --variables '{...}' per run (easy to get wrong, and secrets end up on the command line / in shell history).

There's no single switch that says "run this exact test, but point it at prod." This matters most for environment-specific values: base URLs, API endpoints, tenant/account, and per-environment credentials.

Proposed solution

Introduce environment-scoped variable sets and an --env <name> selector.

1. Environment-scoped variable files / sections. Either dedicated files or a top-level environments block, e.g.:

{
  "environments": {
    "stage": {
      "baseUrl": { "value": "https://stage.example.com" },
      "username": { "value": "qa@stage" },
      "password": { "value": "stage-secret", "secret": true }
    },
    "prod": {
      "baseUrl": { "value": "https://app.example.com" },
      "username": { "value": "qa@prod" },
      "password": { "value": "prod-secret", "secret": true }
    }
  }
}

2. An --env <name> flag on kane-cli run and kane-cli testmd run that selects which environment's values populate {{variables}}:

kane-cli testmd run tests/checkout_test.md --env stage --agent
kane-cli testmd run tests/checkout_test.md --env prod  --agent

Same test file, same {{baseUrl}} / {{username}} / {{password}} references — only the bound environment changes.

3. Resolution rules. --env selects the active environment; existing loading order (global → local → --variables-file → inline --variables) still applies for overrides, and per-environment secret: true continues to route to the TestmuAI secrets store and stay masked in logs. A default environment (or KANE_ENV env var) would be convenient for CI.

Why this helps

• One test definition, validated against stage before promoting the run to prod — no copy/paste drift between environments.
• Secrets stay out of the command line and shell history; each environment carries its own masked credentials.
• Cleaner CI: pipelines just set --env/KANE_ENV per stage instead of swapping variable files.

Alternatives considered

• Multiple --variables-file per environment — works but is manual and error-prone; nothing ties a file to an environment name, and it doesn't give a single ergonomic switch.
• Inline --variables overrides — leaks secrets to the shell/history and doesn't scale beyond a couple of values.