docs(cli): a deploy owns a check's intent and automatic repair setting [RED-1193]

cli/checkly-deploy.mdx

@@ -141,7 +141,7 @@ When the plan shows a resource that was edited in the Checkly web app or through
 
 Choosing it writes your account's current values into the construct files and ends the run without deploying, so you can review the result with `git diff` and run `checkly deploy` again. Only what can be written without guessing is written, so a reason found once the file is read (listed below) can still leave nothing to write:
 
-- On every check: `name`, `description`, `activated`, `muted`, `shouldFail`, `tags`, `locations`, `frequency` and `alertEscalationPolicy`; `retryStrategy` on every check except agentic and Playwright checks, which do not take one. Also `degradedResponseTime` and `maxResponseTime` on API checks and URL, TCP, DNS, gRPC, SSL and traceroute monitors; the packet-loss thresholds on ICMP monitors; `period` and `grace` on heartbeat monitors, each written together with its unit; `environmentVariables` and `runtimeId` on API, browser, multistep and Playwright checks (a check that relied on the project-wide runtime gets the value pinned, like any other defaulted property); `sslCheckDomain` and `aiAutoRepairEnabled` on browser checks and `aiAutoRepairEnabled` on multistep checks; `prompt` on agentic checks (a multi-line prompt written as a template literal stays one); the `request` of an API check (`url`, `method`, `headers`, `queryParameters`, `body`, `bodyType`, `basicAuth`, `followRedirects`, `skipSSL`, `ipFamily`), URL monitor (`url`, `followRedirects`, `skipSSL`, `ipFamily`), TCP monitor (`hostname`, `port`, `data`, `ipFamily`), DNS monitor (`query`, `recordType`, `protocol`, and `nameServer` and `port`, written together), ICMP monitor (`hostname`, `pingCount`, `ipFamily`), gRPC monitor (`url`, `port`, `skipSSL`, `timeout`, `ipFamily` and the `grpcConfig` keys, except `metadata`, whose values Checkly never returns), SSL monitor (`hostname`, `port`, `ipFamily` and the `sslConfig` keys) or traceroute monitor (every key); and the `request.assertions` of an API check and of every URL, TCP, DNS, gRPC, SSL, ICMP and traceroute monitor. Agentic checks take no `shouldFail`.
+- On every check: `name`, `description`, `activated`, `muted`, `shouldFail`, `tags`, `locations`, `frequency` and `alertEscalationPolicy`; `retryStrategy` on every check except agentic and Playwright checks, which do not take one. Also `degradedResponseTime` and `maxResponseTime` on API checks and URL, TCP, DNS, gRPC, SSL and traceroute monitors; the packet-loss thresholds on ICMP monitors; `period` and `grace` on heartbeat monitors, each written together with its unit; `environmentVariables` and `runtimeId` on API, browser, multistep and Playwright checks (a check that relied on the project-wide runtime gets the value pinned, like any other defaulted property); `intent` on API, browser, multistep and Playwright checks and on URL, TCP, DNS, ICMP and gRPC monitors; `sslCheckDomain` and `aiAutoRepairEnabled` on browser checks and `aiAutoRepairEnabled` on multistep checks; `prompt` on agentic checks (a multi-line prompt written as a template literal stays one); the `request` of an API check (`url`, `method`, `headers`, `queryParameters`, `body`, `bodyType`, `basicAuth`, `followRedirects`, `skipSSL`, `ipFamily`), URL monitor (`url`, `followRedirects`, `skipSSL`, `ipFamily`), TCP monitor (`hostname`, `port`, `data`, `ipFamily`), DNS monitor (`query`, `recordType`, `protocol`, and `nameServer` and `port`, written together), ICMP monitor (`hostname`, `pingCount`, `ipFamily`), gRPC monitor (`url`, `port`, `skipSSL`, `timeout`, `ipFamily` and the `grpcConfig` keys, except `metadata`, whose values Checkly never returns), SSL monitor (`hostname`, `port`, `ipFamily` and the `sslConfig` keys) or traceroute monitor (every key); and the `request.assertions` of an API check and of every URL, TCP, DNS, gRPC, SSL, ICMP and traceroute monitor. Agentic checks take no `shouldFail`.
 - On a check group: `name`, `activated`, `muted`, `tags`, `locations`, `concurrency`, `environmentVariables`, `runtimeId`, `retryStrategy`, `alertEscalationPolicy`, and `apiCheckDefaults` (`url`, `headers`, `queryParameters`, `basicAuth`, `assertions`).
 - On every alert channel: `sendRecovery`, `sendFailure`, `sendDegraded`, `sslExpiry` and `sslExpiryThreshold`, plus the channel's own properties: `address` on an email channel; `channel` on a Slack channel; `slackChannels` on a Slack app channel; `name`, `webhookType`, `template` and `method` on a webhook channel; `name`, `region` and `priority` on an Opsgenie channel; `account` and `serviceName` on a PagerDuty channel; `phoneNumber` and `name` on an SMS or phone call channel; `name` and `payload` on an MS Teams or incident.io channel; `name` on a Telegram channel. A credential (a webhook or Slack URL, an API key, a service key, a webhook secret, the values of `headers` and `queryParameters`) is never written, since Checkly does not return it; a channel's type, and the webhook type and method the MS Teams, Telegram and incident.io constructs fix, cannot change in the code; Telegram's `chatId`, `messageThreadId`, `payload` and `apiKey` are packed into the message template and URL, which the CLI does not unpack.
 - On a private location: `name`, `slugName` and `icon` (`proxyUrl` is never written).

constructs/browser-check.mdx

@@ -444,7 +444,7 @@ new BrowserCheck("feature-test", {
 <CheckIntent />
 
 <ResponseField name="aiAutoRepairEnabled" type="boolean | null">
-Requires Checkly CLI 9.4.0 or later. Set `true` to enable automatic repair, `false` to disable it, or `null` to follow your account default. Omit the property to preserve an existing setting when you deploy.
+Requires Checkly CLI 9.4.0 or later. Set `true` to enable automatic repair or `false` to disable it. Left unset, or set to `null`, the check follows your account default.
 
 You also need a valid check intent. See [Configure automatic repair](../resolve/automatic-check-repair#define-intent-with-monitoring-as-code) for a complete example and repair prerequisites.
 </ResponseField>

constructs/multistep-check.mdx

@@ -370,7 +370,7 @@ Multistep checks are only supported on runtime `2023.09` or later. Make sure to
 <CheckIntent />
 
 <ResponseField name="aiAutoRepairEnabled" type="boolean | null">
-Requires Checkly CLI 9.4.0 or later. Set `true` to enable automatic repair, `false` to disable it, or `null` to follow your account default. Omit the property to preserve an existing setting when you deploy.
+Requires Checkly CLI 9.4.0 or later. Set `true` to enable automatic repair or `false` to disable it. Left unset, or set to `null`, the check follows your account default.
 
 You also need a valid check intent. See [Configure automatic repair](../resolve/automatic-check-repair#define-intent-with-monitoring-as-code) for a complete example and repair prerequisites.
 </ResponseField>

resolve/automatic-check-repair.mdx

@@ -37,7 +37,7 @@ You can also write the intent yourself. Use this option when the script does not
 
 ## Define intent with Monitoring as Code
 
-You can also define `intent` and enable repair with `aiAutoRepairEnabled` in your [Monitoring as Code](../cli/overview) configuration using the Checkly CLI. Keep the goal, required outcomes, and guardrails alongside your check definition. See the General Check Options in the [Browser Check](../constructs/browser-check#general-check-options) and [Multistep Check](../constructs/multistep-check#general-check-options) construct references for the `intent` schema and a complete configuration example.
+You can also define `intent` and enable repair with `aiAutoRepairEnabled` in your [Monitoring as Code](../cli/overview) configuration using the Checkly CLI. Keep the goal, required outcomes, and guardrails alongside your check definition. For a check the CLI manages, a deploy writes what the code declares, like every other property, so a value set only in Checkly is cleared by the next deploy of code that does not set it. Before that happens, the deploy plan lists the value and can [update your code with it](../cli/checkly-deploy#updating-your-code-with-changes-made-in-checkly). See the General Check Options in the [Browser Check](../constructs/browser-check#general-check-options) and [Multistep Check](../constructs/multistep-check#general-check-options) construct references for the `intent` schema and a complete configuration example.
 
 Use your existing Browser or Multistep Check test file in these examples.
 
@@ -102,7 +102,7 @@ new MultiStepCheck("authenticated-api", {
 </Tab>
 </Tabs>
 
-Set `aiAutoRepairEnabled` to `true` to enable automatic repair or `false` to disable it for the check. Set it to `null` to follow your account default. Omit the property to preserve an existing setting when you deploy. Defining `intent` alone does not enable repair.
+Set `aiAutoRepairEnabled` to `true` to enable automatic repair or `false` to disable it for the check. Left unset, or set to `null`, the check follows your account default. Defining `intent` alone does not enable repair.
 
 ## Start a manual repair
 

snippets/check-intent.mdx

@@ -1,5 +1,5 @@
-<ResponseField name="intent" type="CheckIntent">
-Describe what your check is intended to verify and the behavior that should be preserved. Checkly uses intent for root cause analysis across all check types. It is separate from `description` and does not replace executable assertions.
+<ResponseField name="intent" type="CheckIntent | null">
+Describe what your check is intended to verify and the behavior that should be preserved. Checkly uses intent for root cause analysis across all check types. It is separate from `description` and does not replace executable assertions. Left unset, or set to `null`, the check has no intent.
 
 <Note>
 Intent is used for [automatic repair](/resolve/automatic-check-repair) only for Browser and Multistep Checks.