@kindgi/cli 0.2.0-rc.0 → 0.2.0

package/dist/sdk-skills/kindgi-getting-started/SKILL.md

@@ -17,7 +17,7 @@ description: >
 type: core
 library: "@kindgi/sdk"
 version: "0.3.16"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [node]
 ---
 
@@ -346,12 +346,15 @@ running the older version on it.
   runtime 0.1.8 or later): the Cloud Run module's `./upgrade.sh`, as of the
   `@kindgi/sdk@<version>` tag of the release you're upgrading to, since it
   knows the steps up to its own release. Run `./upgrade.sh --dry-run` first:
-  it changes nothing, and lists what a real run would change. The module
-  README's Upgrading section has the rest:
+  it changes nothing, and lists what a real run would change. Its plan also
+  reads every `*.auto.tfvars.json` in the module's folder (the pack's env),
+  and `yes` applies exactly the saved plan it showed. The module README's
+  Upgrading section has the rest:
   https://github.com/kindgi/kindgi-sdk/tree/main/deploy/gcp-cloud-run#upgrading
-- **Any other Cloud Run deployment, or one on Azure Container Apps:** the
-  "Operate it" section of its page,
-  https://docs.kindgi.com/v0.2/deploy/self-hosted/cloud-run/#operate-it or
+- **Any other Cloud Run deployment:** by hand, staging first, as the Cloud
+  Run page's "Upgrade by hand" section says:
+  https://docs.kindgi.com/v0.2/deploy/self-hosted/cloud-run/#upgrade-by-hand
+- **On Azure Container Apps:** the "Operate it" section of its page,
   https://docs.kindgi.com/v0.2/deploy/self-hosted/azure-container-apps/#operate-it.
 - **Otherwise:** the operate page's upgrade steps,
   https://docs.kindgi.com/v0.2/deploy/self-hosted/operate/#upgrade-the-runtime.

package/dist/sdk-skills/kindgi-java-authoring-agents/SKILL.md

@@ -16,7 +16,7 @@ description: >
 type: core
 library: "kindgi-pack (Java)"
 version: "0.1.4"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [java]
 sources:
   - sdks/java/kindgi-pack/README.md

package/dist/sdk-skills/kindgi-java-authoring-flows/SKILL.md

@@ -16,7 +16,7 @@ description: >
 type: core
 library: "kindgi-pack (Java)"
 version: "0.1.2"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [java]
 sources:
   - sdks/java/kindgi-pack/README.md

package/dist/sdk-skills/kindgi-java-authoring-guardrails/SKILL.md

@@ -17,7 +17,7 @@ description: >
 type: core
 library: "kindgi-pack (Java)"
 version: "0.1.2"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [java]
 sources:
   - sdks/java/kindgi-pack/README.md

package/dist/sdk-skills/kindgi-java-authoring-tools/SKILL.md

@@ -14,8 +14,8 @@ description: >
   by kindgi-java-getting-started.
 type: core
 library: "kindgi-pack (Java)"
-version: "0.1.3"
-sdk_version: "0.2.0-rc.0"
+version: "0.1.4"
+sdk_version: "0.2.0"
 pack_languages: [java]
 sources:
   - sdks/java/kindgi-pack/README.md
@@ -240,7 +240,7 @@ public static final Tool<Input, Output> TOOL = Tool.define("my-pack.send-mail")
 - **The token:** `accessToken()` is current for this call only. Never keep, print, log or return it; it never reaches the journal. `account().label()` says whose account it is (`ana@acme.com`).
 - **A 401 from the app:** `throw new ConnectionRejectedException("mail")`, with the connection's name (a second argument can say what the app answered, never the token), or your own exception with it as the cause. The runtime renews the token once and runs the call again; refused again, the call fails with `connection-rejected`.
 - **An HTTP tool** sends the token with no code: `.authorization(new HttpAuthSpec.Connection("mail"))`.
-- **Unattended runs:** in a run no person started, a tool that uses a `"person"` connection waits for that person's yes, unless it's marked `.mutating(false)` (mark read-only tools so). The agent's own approval settings can't lift it; only a trigger's `toolsAllowedUnattended` can, which a project admin sets, as for `needsApprovalWhenUnattended` (below).
+- **Unattended runs:** in a run no person started, a tool that uses a `"person"` connection waits for that person's yes, reads included: `.mutating(false)` doesn't lift it. The agent's own approval settings can't lift it; only a trigger's `toolsAllowedUnattended` can, which a project admin sets, as for `needsApprovalWhenUnattended` (below). In a run a new mail started, the mail is a stranger's text, so two more calls wait: a call of a tool that isn't `.mutating(false)`, and, when the trigger reads the company's mailbox, a read with the company's connection to that app. The mail trigger's `toolsAllowedUnattended` lifts these too.
 - **In a unit test:** `ToolContext.forTest(Map.of("mail", new ToolConnection("c-1", "google", "Google", "test", new ConnectionAccount("1", "ana@acme.com"), null)))`; the last argument, when the token expires, can be `null`. `ctx.connections()` is empty when the tool declares none.
 
 Docs: https://docs.kindgi.com/v0.2/guides/connections/use-a-connection/
@@ -265,6 +265,10 @@ the tool's approval default: an agent that turns approval gates on
 (`conversationPolicy.hitl`) asks before any tool that isn't read-only on its
 first use.
 
+In a run a new mail started, a call of a tool that isn't read-only waits
+for a person's yes, unless the mail trigger's `toolsAllowedUnattended`
+lists it.
+
 `effect(kind, resource)` declares a side effect, such as
 `.effect("writes", "db:ledger")`. A dry run also stops at a tool with a
 `writes`, `deletes`, `spawns-run`, `emits-event` or `external-side-effect`
@@ -326,11 +330,11 @@ the same way, with the same `HttpToolSpec`.
 
 ## A person's yes when no one is watching: `needsApprovalWhenUnattended`
 
-`needsApprovalWhenUnattended(true)` declares that a person must say yes to every call of the tool in a run no person started: one a schedule, a webhook, an event or a service account's key started. In such a run:
+`needsApprovalWhenUnattended(true)` declares that a person must say yes to every call of the tool in a run no person started: one a schedule, a webhook, a new mail, an event or a service account's key started. In such a run:
 
 - **An agent's call waits** for a person's yes, whatever the agent's `conversationPolicy.hitl.tools` says. The agent's rules can't lift it: agents are reused, and the tool's author knows what it does.
 - **A flow's tool step that calls it is refused.** Put the tool behind an agent step instead, whose call waits.
-- **A trigger can lift both, for its own runs only.** A project admin names the tool in a webhook trigger's or a schedule's `toolsAllowedUnattended` (`--allow-unattended=<tool-id>` on `kindgi webhooks` and `kindgi schedules`). In that trigger's runs, the tool is then as in a run a person started. The tenant's approval rules still apply.
+- **A trigger can lift both, for its own runs only.** A project admin names the tool in a webhook trigger's, a schedule's or a mail trigger's `toolsAllowedUnattended` (`--allow-unattended=<tool-id>` on `kindgi webhooks`, `kindgi schedules` and `kindgi mail-triggers`). In that trigger's runs, the tool is then as in a run a person started. The tenant's approval rules still apply.
 
 In a run a person started (signed in, or with their own API key), the agent's rules decide, as for any tool. Left unset, it counts as `false`. Declare it on a tool that moves money or changes something people rely on:
 
@@ -342,6 +346,10 @@ In a run a person started (signed in, or with their own API key), the agent's ru
 
 Docs: https://docs.kindgi.com/v0.2/guides/approvals/ask-before-a-tool-runs/#when-no-person-started-the-run
 
+## Results that are text from outside: `resultIsOutsideData`
+
+`resultIsOutsideData(true)` says the tool's results are text from outside that nobody checked, such as a mail someone sent or a page a search found. An agent reads each result of the tool as data, not instructions, in that turn and in every later turn's history. It changes what the model is told, not what the tool may do: pair it with approvals for anything an agent could do with what it read. Absent means `false`.
+
 ## Testing
 
 `Tool.call(input, ctx)` runs the handler with the input as given (no schema

package/dist/sdk-skills/kindgi-java-getting-started/SKILL.md

@@ -18,7 +18,7 @@ description: >
 type: core
 library: "kindgi-pack (Java)"
 version: "0.1.4"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [java]
 sources:
   - sdks/java/kindgi-pack/README.md
@@ -267,12 +267,15 @@ running the older version on it.
   runtime 0.1.8 or later): the Cloud Run module's `./upgrade.sh`, as of the
   `@kindgi/sdk@<version>` tag of the release you're upgrading to, since it
   knows the steps up to its own release. Run `./upgrade.sh --dry-run` first:
-  it changes nothing, and lists what a real run would change. The module
-  README's Upgrading section has the rest:
+  it changes nothing, and lists what a real run would change. Its plan also
+  reads every `*.auto.tfvars.json` in the module's folder (the pack's env),
+  and `yes` applies exactly the saved plan it showed. The module README's
+  Upgrading section has the rest:
   https://github.com/kindgi/kindgi-sdk/tree/main/deploy/gcp-cloud-run#upgrading
-- **Any other Cloud Run deployment, or one on Azure Container Apps:** the
-  "Operate it" section of its page,
-  https://docs.kindgi.com/v0.2/deploy/self-hosted/cloud-run/#operate-it or
+- **Any other Cloud Run deployment:** by hand, staging first, as the Cloud
+  Run page's "Upgrade by hand" section says:
+  https://docs.kindgi.com/v0.2/deploy/self-hosted/cloud-run/#upgrade-by-hand
+- **On Azure Container Apps:** the "Operate it" section of its page,
   https://docs.kindgi.com/v0.2/deploy/self-hosted/azure-container-apps/#operate-it.
 - **Otherwise:** the operate page's upgrade steps,
   https://docs.kindgi.com/v0.2/deploy/self-hosted/operate/#upgrade-the-runtime.

package/dist/sdk-skills/kindgi-python-authoring-agents/SKILL.md

@@ -16,7 +16,7 @@ description: >
 type: core
 library: "kindgi (Python)"
 version: "0.1.7"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [python]
 sources:
   - sdks/python/src/kindgi/pack/define.py

package/dist/sdk-skills/kindgi-python-authoring-flows/SKILL.md

@@ -17,7 +17,7 @@ description: >
 type: core
 library: "kindgi (Python)"
 version: "0.1.2"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [python]
 sources:
   - sdks/python/src/kindgi/pack/define.py

package/dist/sdk-skills/kindgi-python-authoring-guardrails/SKILL.md

@@ -16,7 +16,7 @@ description: >
 type: core
 library: "kindgi (Python)"
 version: "0.1.5"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [python]
 sources:
   - sdks/python/src/kindgi/pack/define.py

package/dist/sdk-skills/kindgi-python-authoring-tools/SKILL.md

@@ -14,8 +14,8 @@ description: >
   kindgi-python-getting-started.
 type: core
 library: "kindgi (Python)"
-version: "0.1.5"
-sdk_version: "0.2.0-rc.0"
+version: "0.1.6"
+sdk_version: "0.2.0"
 pack_languages: [python]
 sources:
   - sdks/python/src/kindgi/pack/define.py
@@ -236,7 +236,7 @@ def send_mail(message: Message, ctx: ToolContext) -> Sent:
 - **The token:** `access_token` is current for this call only. Never keep, print, log or return it; it never reaches the journal. `account.label` says whose account it is (`ana@acme.com`).
 - **A 401 from the app:** `raise ConnectionRejected("mail")`, with the connection's name (a second argument can say what the app answered, never the token), or raise your own error `from` it. The runtime renews the token once and runs the call again; refused again, the call fails with `connection-rejected`.
 - **An HTTP tool** sends the token with no code: `authorization={"kind": "connection", "connection": "mail"}`.
-- **Unattended runs:** in a run no person started, a tool that uses a `"person"` connection waits for that person's yes, unless it's marked `mutating=False` (mark read-only tools so). The agent's own approval settings can't lift it; only a trigger's `toolsAllowedUnattended` can, which a project admin sets, as for `needs_approval_when_unattended` (below).
+- **Unattended runs:** in a run no person started, a tool that uses a `"person"` connection waits for that person's yes, reads included: `mutating=False` doesn't lift it. The agent's own approval settings can't lift it; only a trigger's `toolsAllowedUnattended` can, which a project admin sets, as for `needs_approval_when_unattended` (below). In a run a new mail started, the mail is a stranger's text, so two more calls wait: a call of a tool that isn't `mutating=False`, and, when the trigger reads the company's mailbox, a read with the company's connection to that app. The mail trigger's `toolsAllowedUnattended` lifts these too.
 - **In a unit test:** `ToolContext.for_test(connections={"mail": ToolConnection(connection_id="c-1", app="google", app_name="Google", access_token="test", account=ConnectionAccount(id="1", label="ana@acme.com"))})`, all from `kindgi`. `ctx.connections` is empty when the tool declares none.
 
 Docs: https://docs.kindgi.com/v0.2/guides/connections/use-a-connection/
@@ -263,6 +263,10 @@ approval gates on (`conversation_policy={"hitl": {"tools": {...}}}`)
 and has neither an override for the tool nor a `default` doesn't ask
 before a read-only tool, and asks before any other on first use.
 
+In a run a new mail started, a call of a tool that isn't read-only waits
+for a person's yes, unless the mail trigger's `toolsAllowedUnattended`
+lists it.
+
 ```python
 @tool(id="acme.find-citations", mutating=False)
 def find_citations(query: CitationQuery) -> Citations:
@@ -278,11 +282,11 @@ policy and review; declare what the tool really does.
 
 ## A person's yes when no one is watching: `needs_approval_when_unattended`
 
-`needs_approval_when_unattended=True` declares that a person must say yes to every call of the tool in a run no person started: one a schedule, a webhook, an event or a service account's key started. In such a run:
+`needs_approval_when_unattended=True` declares that a person must say yes to every call of the tool in a run no person started: one a schedule, a webhook, a new mail, an event or a service account's key started. In such a run:
 
 - **An agent's call waits** for a person's yes, whatever the agent's `conversation_policy` says in `hitl["tools"]`. The agent's rules can't lift it: agents are reused, and the tool's author knows what it does.
 - **A flow's tool step that calls it is refused.** Put the tool behind an agent step instead, whose call waits.
-- **A trigger can lift both, for its own runs only.** A project admin names the tool in a webhook trigger's or a schedule's `toolsAllowedUnattended` (`--allow-unattended=<tool-id>` on `kindgi webhooks` and `kindgi schedules`). In that trigger's runs, the tool is then as in a run a person started. The tenant's approval rules still apply.
+- **A trigger can lift both, for its own runs only.** A project admin names the tool in a webhook trigger's, a schedule's or a mail trigger's `toolsAllowedUnattended` (`--allow-unattended=<tool-id>` on `kindgi webhooks`, `kindgi schedules` and `kindgi mail-triggers`). In that trigger's runs, the tool is then as in a run a person started. The tenant's approval rules still apply.
 
 In a run a person started (signed in, or with their own API key), the agent's rules decide, as for any tool. Left out, it counts as `False`. Declare it on a tool that moves money or changes something people rely on:
 
@@ -299,6 +303,10 @@ def refund(request: RefundRequest) -> Refunded:
 
 Docs: https://docs.kindgi.com/v0.2/guides/approvals/ask-before-a-tool-runs/#when-no-person-started-the-run
 
+## Results that are text from outside: `result_is_outside_data`
+
+`result_is_outside_data=True` says the tool's results are text from outside that nobody checked, such as a mail someone sent or a page a search found. An agent reads each result of the tool as data, not instructions, in that turn and in every later turn's history. It changes what the model is told, not what the tool may do: pair it with approvals for anything an agent could do with what it read. Absent means `false`.
+
 ## HTTP tools — one request, no code
 
 A tool that is a single HTTP request needs no handler. `http_tool(...)`

package/dist/sdk-skills/kindgi-python-getting-started/SKILL.md

@@ -17,7 +17,7 @@ description: >
 type: core
 library: "kindgi (Python)"
 version: "0.1.10"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [python]
 sources:
   - sdks/python/README.md
@@ -316,12 +316,15 @@ running the older version on it.
   runtime 0.1.8 or later): the Cloud Run module's `./upgrade.sh`, as of the
   `@kindgi/sdk@<version>` tag of the release you're upgrading to, since it
   knows the steps up to its own release. Run `./upgrade.sh --dry-run` first:
-  it changes nothing, and lists what a real run would change. The module
-  README's Upgrading section has the rest:
+  it changes nothing, and lists what a real run would change. Its plan also
+  reads every `*.auto.tfvars.json` in the module's folder (the pack's env),
+  and `yes` applies exactly the saved plan it showed. The module README's
+  Upgrading section has the rest:
   https://github.com/kindgi/kindgi-sdk/tree/main/deploy/gcp-cloud-run#upgrading
-- **Any other Cloud Run deployment, or one on Azure Container Apps:** the
-  "Operate it" section of its page,
-  https://docs.kindgi.com/v0.2/deploy/self-hosted/cloud-run/#operate-it or
+- **Any other Cloud Run deployment:** by hand, staging first, as the Cloud
+  Run page's "Upgrade by hand" section says:
+  https://docs.kindgi.com/v0.2/deploy/self-hosted/cloud-run/#upgrade-by-hand
+- **On Azure Container Apps:** the "Operate it" section of its page,
   https://docs.kindgi.com/v0.2/deploy/self-hosted/azure-container-apps/#operate-it.
 - **Otherwise:** the operate page's upgrade steps,
   https://docs.kindgi.com/v0.2/deploy/self-hosted/operate/#upgrade-the-runtime.

package/dist/sdk-skills/kindgi-scala-authoring-agents/SKILL.md

@@ -17,7 +17,7 @@ description: >
 type: core
 library: "kindgi-pack-scala"
 version: "0.1.4"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [scala]
 sources:
   - sdks/scala/README.md

package/dist/sdk-skills/kindgi-scala-authoring-flows/SKILL.md

@@ -17,7 +17,7 @@ description: >
 type: core
 library: "kindgi-pack-scala"
 version: "0.1.2"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [scala]
 sources:
   - sdks/scala/README.md

package/dist/sdk-skills/kindgi-scala-authoring-guardrails/SKILL.md

@@ -18,7 +18,7 @@ description: >
 type: core
 library: "kindgi-pack-scala"
 version: "0.1.2"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [scala]
 sources:
   - sdks/scala/README.md

package/dist/sdk-skills/kindgi-scala-authoring-tools/SKILL.md

@@ -15,8 +15,8 @@ description: >
   kindgi-scala-getting-started.
 type: core
 library: "kindgi-pack-scala"
-version: "0.1.3"
-sdk_version: "0.2.0-rc.0"
+version: "0.1.4"
+sdk_version: "0.2.0"
 pack_languages: [scala]
 sources:
   - sdks/scala/README.md
@@ -226,7 +226,7 @@ val tool: Tool[Input, Output] = Tool[Input, Output]("my-pack.send-mail")
 - **The token:** `accessToken` is current for this call only. Never keep, print, log or return it; it never reaches the journal. `account.label` says whose account it is (`ana@acme.com`). `ToolConnection`, `ConnectionAccount` and `ConnectionRejectedException` come with `com.kindgi.pack.scaladsl._`.
 - **A 401 from the app:** `throw new ConnectionRejectedException("mail")`, with the connection's name (a second argument can say what the app answered, never the token), or your own exception with it as the cause. The runtime renews the token once and runs the call again; refused again, the call fails with `connection-rejected`.
 - **An HTTP tool** sends the token with no code: `.authorization(new HttpAuthSpec.Connection("mail"))`.
-- **Unattended runs:** in a run no person started, a tool that uses a `"person"` connection waits for that person's yes, unless it's marked `.readOnly` (mark read-only tools so). The agent's own approval settings can't lift it; only a trigger's `toolsAllowedUnattended` can, which a project admin sets, as for `needsApprovalWhenUnattended` (below).
+- **Unattended runs:** in a run no person started, a tool that uses a `"person"` connection waits for that person's yes, reads included: `.readOnly` doesn't lift it. The agent's own approval settings can't lift it; only a trigger's `toolsAllowedUnattended` can, which a project admin sets, as for `needsApprovalWhenUnattended` (below). In a run a new mail started, the mail is a stranger's text, so two more calls wait: a call of a tool that isn't `.readOnly`, and, when the trigger reads the company's mailbox, a read with the company's connection to that app. The mail trigger's `toolsAllowedUnattended` lifts these too.
 - **In a unit test:** `com.kindgi.pack.ToolContext.forTest(java.util.Map.of("mail", new ToolConnection("c-1", "google", "Google", "test", new ConnectionAccount("1", "ana@acme.com"), null)))`; the last argument, when the token expires, can be `null`. `ctx.connections` is empty when the tool declares none.
 
 Docs: https://docs.kindgi.com/v0.2/guides/connections/use-a-connection/
@@ -250,6 +250,10 @@ the tool's approval default: an agent that turns approval gates on
 (`conversationPolicy.hitl`) asks before any tool that isn't read-only on its
 first use.
 
+In a run a new mail started, a call of a tool that isn't read-only waits
+for a person's yes, unless the mail trigger's `toolsAllowedUnattended`
+lists it.
+
 `effect(kind, resource)` declares a side effect, such as
 `.effect("writes", "db:ledger")`. A dry run also stops at a tool with a
 `writes`, `deletes`, `spawns-run`, `emits-event` or `external-side-effect`
@@ -304,11 +308,11 @@ pages or filters, not one that returns everything.
 
 ## A person's yes when no one is watching: `needsApprovalWhenUnattended`
 
-`needsApprovalWhenUnattended(true)` declares that a person must say yes to every call of the tool in a run no person started: one a schedule, a webhook, an event or a service account's key started. In such a run:
+`needsApprovalWhenUnattended(true)` declares that a person must say yes to every call of the tool in a run no person started: one a schedule, a webhook, a new mail, an event or a service account's key started. In such a run:
 
 - **An agent's call waits** for a person's yes, whatever the agent's `conversationPolicy.hitl.tools` says. The agent's rules can't lift it: agents are reused, and the tool's author knows what it does.
 - **A flow's tool step that calls it is refused.** Put the tool behind an agent step instead, whose call waits.
-- **A trigger can lift both, for its own runs only.** A project admin names the tool in a webhook trigger's or a schedule's `toolsAllowedUnattended` (`--allow-unattended=<tool-id>` on `kindgi webhooks` and `kindgi schedules`). In that trigger's runs, the tool is then as in a run a person started. The tenant's approval rules still apply.
+- **A trigger can lift both, for its own runs only.** A project admin names the tool in a webhook trigger's, a schedule's or a mail trigger's `toolsAllowedUnattended` (`--allow-unattended=<tool-id>` on `kindgi webhooks`, `kindgi schedules` and `kindgi mail-triggers`). In that trigger's runs, the tool is then as in a run a person started. The tenant's approval rules still apply.
 
 In a run a person started (signed in, or with their own API key), the agent's rules decide, as for any tool. Left unset, it counts as `false`. Declare it on a tool that moves money or changes something people rely on:
 
@@ -320,6 +324,10 @@ In a run a person started (signed in, or with their own API key), the agent's ru
 
 Docs: https://docs.kindgi.com/v0.2/guides/approvals/ask-before-a-tool-runs/#when-no-person-started-the-run
 
+## Results that are text from outside: `resultIsOutsideData`
+
+`resultIsOutsideData(true)` says the tool's results are text from outside that nobody checked, such as a mail someone sent or a page a search found. An agent reads each result of the tool as data, not instructions, in that turn and in every later turn's history. It changes what the model is told, not what the tool may do: pair it with approvals for anything an agent could do with what it read. Absent means `false`.
+
 ## Testing
 
 `tool.call(input, ctx)` runs the handler with the input as given (no schema

package/dist/sdk-skills/kindgi-scala-getting-started/SKILL.md

@@ -18,7 +18,7 @@ description: >
 type: core
 library: "kindgi-pack-scala"
 version: "0.1.4"
-sdk_version: "0.2.0-rc.0"
+sdk_version: "0.2.0"
 pack_languages: [scala]
 sources:
   - sdks/scala/README.md
@@ -283,12 +283,15 @@ running the older version on it.
   runtime 0.1.8 or later): the Cloud Run module's `./upgrade.sh`, as of the
   `@kindgi/sdk@<version>` tag of the release you're upgrading to, since it
   knows the steps up to its own release. Run `./upgrade.sh --dry-run` first:
-  it changes nothing, and lists what a real run would change. The module
-  README's Upgrading section has the rest:
+  it changes nothing, and lists what a real run would change. Its plan also
+  reads every `*.auto.tfvars.json` in the module's folder (the pack's env),
+  and `yes` applies exactly the saved plan it showed. The module README's
+  Upgrading section has the rest:
   https://github.com/kindgi/kindgi-sdk/tree/main/deploy/gcp-cloud-run#upgrading
-- **Any other Cloud Run deployment, or one on Azure Container Apps:** the
-  "Operate it" section of its page,
-  https://docs.kindgi.com/v0.2/deploy/self-hosted/cloud-run/#operate-it or
+- **Any other Cloud Run deployment:** by hand, staging first, as the Cloud
+  Run page's "Upgrade by hand" section says:
+  https://docs.kindgi.com/v0.2/deploy/self-hosted/cloud-run/#upgrade-by-hand
+- **On Azure Container Apps:** the "Operate it" section of its page,
   https://docs.kindgi.com/v0.2/deploy/self-hosted/azure-container-apps/#operate-it.
 - **Otherwise:** the operate page's upgrade steps,
   https://docs.kindgi.com/v0.2/deploy/self-hosted/operate/#upgrade-the-runtime.

package/dist/sdk-skills/kindgi-using/SKILL.md

@@ -15,8 +15,8 @@ description: >
   with the person.
 type: core
 library: "@kindgi/sdk"
-version: "0.1.1"
-sdk_version: "0.2.0-rc.0"
+version: "0.1.2"
+sdk_version: "0.2.0"
 pack_languages: [node, python, java, scala]
 ---
 
@@ -97,6 +97,7 @@ decided one opens its own page.
 | Guardrails | `guardrails`, one: `guardrails/<guardrailId>` | each rule's settings, the agents it checks, what it caught |
 | Flows | `flows`, one: `flows/<flowId>` | the flows and their steps |
 | Schedules | `schedules`, one: `schedules/<triggerId>` | when each runs next, and its past runs |
+| Mail triggers | `mail-triggers`, one: `mail-triggers/<triggerId>` | the mailbox each watches and what it starts; its latest mails, and the run each started |
 | Conversations | `conversations`, one: `conversations/<conversationId>` | each conversation's turns |
 | Cost | `cost` | what the project's model calls cost, by agent, model, flow or kind |
 | Quality | `quality` | answers waiting to be rated, rating rules, trends |
@@ -224,6 +225,17 @@ say there were none.
   `status`, and its answer, `output.response.content`.
 - In the console: `schedules/<triggerId>`, and the run's `runs/<runId>`.
 
+**"What did the support inbox do with that mail?"**
+- In the CLI: `kindgi mail-triggers list` finds the trigger; `kindgi
+  mail-triggers fires <triggerId>` lists each new mail it found, newest
+  first, with its `outcome` (`started`, `pending`, `skipped`, `refused` or
+  `failed`), a `detail` saying why, and the `runId` it started. A
+  `refused` mail never runs: staff handle it in the mailbox.
+- In the console: `mail-triggers/<triggerId>` lists its latest mails, up
+  to 50, what happened to each, and the run it started; an older one is
+  in the CLI's `fires`. `runs?trigger=<triggerId>` is every run it
+  started. The run is `runs/<runId>`.
+
 **"Is Kindgi healthy?"**
 - In the CLI: `kindgi health` (`"ok": true` when the server answers) and
   `kindgi doctor` (each part, with a fix for any that fail).
@@ -260,6 +272,7 @@ say there were none.
 - Connections: https://docs.kindgi.com/v0.2/guides/connections/use-a-connection/
 - Memory: https://docs.kindgi.com/v0.2/guides/agents/give-an-agent-memory/
 - Schedules: https://docs.kindgi.com/v0.2/guides/runs/run-on-a-schedule/
+- Mail triggers: https://docs.kindgi.com/v0.2/guides/runs/start-runs-from-new-mail/
 - People and keys: https://docs.kindgi.com/v0.2/deploy/people-and-keys/
 - Cost: https://docs.kindgi.com/v0.2/guides/observability/cost-per-run/
 - Rating answers: https://docs.kindgi.com/v0.2/guides/evals/judge-a-runs-output/

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kindgi/cli",
-  "version": "0.2.0-rc.0",
+  "version": "0.2.0",
   "description": "Command-line interface for Kindgi™. Create a pack, run it on your machine (`kindgi dev`), build, sign and deploy it, and work with a running Kindgi API from the terminal.",
   "license": "Apache-2.0",
   "repository": {
@@ -37,18 +37,18 @@
     "provenance": true
   },
   "dependencies": {
-    "@kindgi/agents": "0.2.0-rc.0",
-    "@kindgi/client": "0.2.0-rc.0",
-    "@kindgi/dotenv-file": "0.2.0-rc.0",
-    "@kindgi/crypto": "0.2.0-rc.0",
-    "@kindgi/env-schema": "0.2.0-rc.0",
-    "@kindgi/flow": "0.2.0-rc.0",
-    "@kindgi/handler-runtime": "0.2.0-rc.0",
-    "@kindgi/log": "0.2.0-rc.0",
-    "@kindgi/secrets-dotenv": "0.2.0-rc.0",
-    "@kindgi/platform": "0.2.0-rc.0",
-    "@kindgi/sdk": "0.2.0-rc.0",
-    "@kindgi/types": "0.2.0-rc.0",
+    "@kindgi/agents": "0.2.0",
+    "@kindgi/client": "0.2.0",
+    "@kindgi/dotenv-file": "0.2.0",
+    "@kindgi/crypto": "0.2.0",
+    "@kindgi/env-schema": "0.2.0",
+    "@kindgi/flow": "0.2.0",
+    "@kindgi/handler-runtime": "0.2.0",
+    "@kindgi/log": "0.2.0",
+    "@kindgi/secrets-dotenv": "0.2.0",
+    "@kindgi/platform": "0.2.0",
+    "@kindgi/sdk": "0.2.0",
+    "@kindgi/types": "0.2.0",
     "esbuild": "^0.24.0",
     "semver": "^7.8.5",
     "smol-toml": "^1.9.0",