Skip to main content
KHAL has multiple environment rungs. The same command can be harmless in local and dangerous in production, so every proof must name the target.
RungTargetWho uses itMutation rule
1local / dev-localYou and your agentSafe for iteration after local proof
2shared devFDEs after local validationDry-run first, then scoped mutation
3customer dev / HMLCustomer-specific validationStakeholder/operator gate required
4productionOperatorsExplicit approval and rollback plan required

​
CLI identity checks

khal context --target dev --text
khal whoami --target dev --json
khal doctor --target dev
Simulated output: 
KHAL target: dev
Auth: signed in as <fde-email>
Reachability: ok
Repo: <current-repo-or-none>
Mutation: none

​
Dry-run first

khal install <private-khal-gitea-repo-url> --branch <branch> --target dev --scope shared --dry-run --json
Only proceed when the dry-run passes and your agent can explain source repo/ref, target, manifest, required settings/secrets, mutation policy, and rollback.

​
When to stop

Stop and ask for operator help if:
  • the target resolves to customer/HML/prod and you do not have approval;
  • secrets or App Settings are missing;
  • you cannot tell whether the command mutates;
  • logs contradict the CLI summary;
  • your agent is relying on stale memory instead of current command output.
TASK: I am reading `fde-start-here/environments.mdx` (Environment ladder for new FDEs). Use this page as the contract, then verify current CLI/output before you guide me.
CONTEXT: I may be a new KHAL FDE. Prefer read-only checks and dry-runs first. Do not mutate customer, HML, production, credentials, SSH, Gitea, or model-provider state without an explicit GO.
SAFE FIRST COMMANDS: Check versions, identity, target, git source/ref, KHAW doctor/status, KHAL context, and dry-run output. Redact secrets and private URLs.
EVIDENCE: Return command, exit status, sanitized output, what it proves, and the next safe action.