> ## Documentation Index
> Fetch the complete documentation index at: https://www.keycli.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# First governed change

> Make one low-risk change first, then one approval-gated change.

Your first session should teach two things:

1. a low-risk path can apply
2. a risky path waits for approval

## 1. Prove the workflow first

```bash theme={null}
npm run demo:hosted:self
```

## 2. Run one low-risk live change

Use the preview-safe Vercel path from [Vercel](./VERCEL).

Look for:

* `plan.risk.level: "low"`
* `nextAction: "apply_plan"`
* `plan.execution.mode: "provider-api"`

## 3. Then inspect an approval-gated path

Look for:

* `plan.risk.level: "high"`
* `nextAction: "wait_for_approval"`
* live execution only if every target has a supported connected adapter

## Why this matters

The wedge is not "agent can change infra".

The wedge is:

* agent proposes
* Keycli structures
* Keycli checks risk and scope
* human approves when needed
* adapter applies
* audit records what happened

## Next reads

* [Approvals](./approvals)
* [API and MCP](./api-and-mcp)