---
title: AI config & Test
description: Edit the configuration your app uses and test its behavior.
---

[!nav:main](/nav/main.md)

For the hackathon, use `Croche.open(...)` in TypeScript or React Native. Native [Swift](../sdks/ios.md) and [Kotlin](../sdks/android.md) setup is pending API review.

## Agent edits, human reviews and releases

Studio does not provide a draft editor. The coding agent uses the CLI to author the draft;
the human uses **Running config** to review and approve its release.

The **coding agent** reads and edits the config, then saves a Cloud draft through the CLI:

```sh
croche config get --project PROJECT_ID --output croche.config.json
# Edit croche.config.json, preserving the complete config and every required tool.
croche config save croche.config.json --project PROJECT_ID
```

Read before saving: `get` records the base revision used by `save` to detect conflicts. Keep
the complete project document. If no draft exists, prepare a document with `schema: 2` and the
app's complete config in `config`; do not save the returned `null` value. Saving a draft is not
a production release. On a conflict, preserve the local edit and reconcile the latest draft
rather than overwriting someone else's changes.

1. Run the app with a **debug key**. Every debug key follows the draft automatically.
2. Reopen after the config sync. Changes apply on the **next open after that sync**, never
   mid-session. If the download has not finished, allow sync and reopen again.
3. Test the changed behavior and inspect **Monitoring → Logs**.
4. A **human** opens **Build → AI config → Running config**, reviews the current draft's
   readable cards and diff against the released config, and chooses **Release…**. Type the
   project name to approve, then choose **Approve and publish**.
5. Production installs receive the released config on their **next open after sync**.
   Releasing alone does not prove that an install has applied it.

A draft replaces the entire code config, not just the fields you edited. Include every tool your app uses; handlers remain in app code. See [app config and language](../concepts/config.md) for selection and next-open behavior. Keep credentials and user secrets out of the configuration.

You may see **“Running config reports are not available yet.”** App-code reports are a separate
view; draft review and release remain available below it. A missing report is not evidence that
the app failed, and this guide does not require that report view to be available.

## Test your app

Open **Build → Test**. Check a first conversation, an ongoing conversation, and an action your app should refuse. Continue to enforce authorization in your tool handlers; a successful conversation is not an authorization check.

> TODO verify: the complete test-connection walkthrough for the release. Do not assume that opening Test automatically connects to a running app.