@zaip-ai/cli 2.0.0 → 2.6.0

package/templates/.agents/skills/zaip-skill-github-deploy/scripts/validate-release-notes.mjs

@@ -0,0 +1,184 @@
+import { execFile } from "node:child_process";
+import { readFile } from "node:fs/promises";
+import { resolve } from "node:path";
+import { parseArgs } from "node:util";
+
+const categoryHeadings = new Map([
+  ["feat", "Novidades"],
+  ["added", "Novidades"],
+  ["fix", "Correções"],
+  ["perf", "Desempenho"],
+  ["refactor", "Alterações internas"],
+  ["build", "Alterações internas"],
+  ["ci", "Alterações internas"],
+  ["test", "Alterações internas"],
+  ["chore", "Alterações internas"],
+  ["changed", "Alterações internas"],
+  ["security", "Segurança"],
+  ["breaking", "Alterações incompatíveis e migrações"],
+  ["migration", "Alterações incompatíveis e migrações"],
+  ["removed", "Alterações incompatíveis e migrações"],
+  ["deprecated", "Alterações incompatíveis e migrações"],
+  ["docs", "Documentação"],
+]);
+const releaseHeadings = new Set([
+  "Novidades",
+  "Correções",
+  "Desempenho",
+  "Alterações internas",
+  "Segurança",
+  "Alterações incompatíveis e migrações",
+  "Documentação",
+]);
+const { values } = parseArgs({
+  options: {
+    repository: { type: "string" },
+    from: { type: "string" },
+    initial: { type: "boolean", default: false },
+    to: { type: "string" },
+    "notes-file": { type: "string" },
+    "inventory-file": { type: "string" },
+  },
+  strict: true,
+});
+for (const option of ["repository", "to", "notes-file", "inventory-file"]) {
+  if (!values[option]) throw new Error("--" + option + " is required");
+}
+if (values.initial === Boolean(values.from))
+  throw new Error("use exactly one of --from <previous-tag> or --initial");
+if (!/^[a-f0-9]{40}$/i.test(values.to))
+  throw new Error("--to must be an explicit immutable 40-character candidate SHA");
+
+const repository = resolve(values.repository);
+const [notesBytes, inventoryBytes, candidate] = await Promise.all([
+  readFile(resolve(repository, values["notes-file"])),
+  readFile(resolve(repository, values["inventory-file"])),
+  gitText(repository, ["rev-parse", "--verify", values.to + "^{commit}"]),
+]);
+if (candidate.trim().toLowerCase() !== values.to.toLowerCase())
+  throw new Error("--to must resolve to the supplied immutable candidate SHA");
+if (!values.initial)
+  await gitText(repository, ["merge-base", "--is-ancestor", values.from, values.to]);
+const changed = values.initial
+  ? await gitBytes(repository, ["ls-tree", "-rz", "--name-only", values.to])
+  : await gitBytes(repository, [
+      "diff",
+      "--name-only",
+      "-z",
+      "--no-renames",
+      "--diff-filter=ACMRTD",
+      values.from + ".." + values.to,
+    ]);
+const notes = new TextDecoder("utf-8", { fatal: true }).decode(notesBytes);
+const inventory = JSON.parse(new TextDecoder("utf-8", { fatal: true }).decode(inventoryBytes));
+validate(notes, inventory, values, nulPaths(changed));
+process.stdout.write(
+  JSON.stringify({
+    status: "passed",
+    files: inventory.files.length,
+    topics: inventory.topics.length,
+    semantic_review: "required",
+  }) + "\n",
+);
+
+function validate(notes, inventory, values, actualFiles) {
+  const visible = stripFencedCode(notes);
+  if (visible.trim().length === 0) throw new Error("release notes body is empty");
+  const visibleBullets = bulletLines(visible);
+  if (/^\s*(?:full changelog|compare changes)\s*:/im.test(visible) && visibleBullets.length === 0)
+    throw new Error("release notes cannot be compare-only");
+  if (/--generate-notes|\bTBD\b|\bN\/A\b/i.test(visible))
+    throw new Error("release notes contain a generated-notes flag or placeholder");
+  if (!Array.isArray(inventory.files) || !Array.isArray(inventory.topics))
+    throw new Error("inventory must contain files and topics arrays");
+  if (inventory.from !== (values.initial ? null : values.from) || inventory.to !== values.to)
+    throw new Error("inventory range must exactly match the immutable candidate selection");
+  const inventoryFiles = unique(inventory.files);
+  if (!inventoryFiles.every(isPath) || !sameSet(actualFiles, inventoryFiles))
+    throw new Error("inventory files must exactly cover the changed Git range");
+  if (inventory.topics.length === 0)
+    throw new Error("inventory must describe at least one release topic");
+  const mappedFiles = [];
+  const mappedBullets = new Set();
+  for (const topic of inventory.topics) {
+    if (!categoryHeadings.has(topic?.category)) throw new Error("topic category is invalid");
+    if (typeof topic?.bullet !== "string" || !visibleBullets.includes(topic.bullet))
+      throw new Error("every inventory topic bullet must appear outside fenced examples");
+    if (mappedBullets.has(topic.bullet)) throw new Error("inventory topic bullets must be unique");
+    mappedBullets.add(topic.bullet);
+    if (!Array.isArray(topic.files) || topic.files.length === 0 || !topic.files.every(isPath))
+      throw new Error("every topic must map to at least one changed file");
+    mappedFiles.push(...topic.files);
+  }
+  if (!sameSet(inventoryFiles, unique(mappedFiles)))
+    throw new Error("release topics must exactly cover every inventoried file");
+  const headings = [...visible.matchAll(/^## (.+)$/gm)].map((match) => ({
+    name: match[1],
+    index: match.index,
+  }));
+  if (headings[0]?.name !== "Resumo")
+    throw new Error("release notes must open with a Resumo heading");
+  const firstCategory = headings.find((heading) => releaseHeadings.has(heading.name));
+  if (
+    visible.slice(headings[0].index + "## Resumo".length, firstCategory?.index).trim().length === 0
+  )
+    throw new Error("Resumo must contain plain-language release context before categories");
+  if (!headings.some((heading) => releaseHeadings.has(heading.name)))
+    throw new Error("release notes need at least one categorized heading");
+  const categoryBullets = new Map();
+  for (let index = 0; index < headings.length; index += 1) {
+    const heading = headings[index];
+    if (!releaseHeadings.has(heading.name)) continue;
+    const section = visible.slice(
+      heading.index + heading.name.length + 3,
+      headings[index + 1]?.index,
+    );
+    const bullets = bulletLines(section);
+    if (bullets.length === 0)
+      throw new Error("every recognized category section must contain a bullet");
+    categoryBullets.set(heading.name, bullets);
+  }
+  const expected = new Set(inventory.topics.map((topic) => topic.bullet));
+  const actual = new Set([...categoryBullets.values()].flat());
+  if (!sameSet([...expected].sort(), [...actual].sort()))
+    throw new Error("category bullets must exactly match inventory topics");
+  for (const topic of inventory.topics) {
+    if (!categoryBullets.get(categoryHeadings.get(topic.category))?.includes(topic.bullet)) {
+      throw new Error("topic bullet must appear under its mapped category heading");
+    }
+  }
+}
+function stripFencedCode(source) {
+  return source.replace(/^ {0,3}(\`\`\`|~~~)[\s\S]*?^ {0,3}\1\s*$/gm, "");
+}
+function bulletLines(source) {
+  return (source.match(/^\s*-\s+.+$/gm) ?? []).map((line) => line.trim());
+}
+function nulPaths(bytes) {
+  return unique(
+    new TextDecoder("utf-8", { fatal: true }).decode(bytes).split("\0").filter(Boolean),
+  );
+}
+function unique(values) {
+  return [...new Set(values)].sort();
+}
+function sameSet(left, right) {
+  return left.length === right.length && left.every((value, index) => value === right[index]);
+}
+function isPath(value) {
+  return typeof value === "string" && value.length > 0;
+}
+function gitText(cwd, args) {
+  return git(cwd, args, "utf8");
+}
+function gitBytes(cwd, args) {
+  return git(cwd, args, "buffer");
+}
+function git(cwd, args, encoding) {
+  return new Promise((resolveResult, reject) => {
+    execFile("git", args, { cwd, encoding }, (error, stdout, stderr) => {
+      if (error) reject(new Error("git " + args.join(" ") + " failed: " + String(stderr).trim()));
+      else resolveResult(stdout);
+    });
+  });
+}

package/templates/.agents/skills/zaip-skill-github-deploy/scripts/validate-release-notes.test.mjs

@@ -0,0 +1,109 @@
+import assert from "node:assert/strict";
+import { execFile as run } from "node:child_process";
+import { mkdtemp, writeFile } from "node:fs/promises";
+import { tmpdir } from "node:os";
+import { resolve } from "node:path";
+import test from "node:test";
+
+const script = resolve(import.meta.dirname, "validate-release-notes.mjs");
+
+test("accepts categorized reviewed notes that fully cover the exact range", async () => {
+  const root = await repository();
+  await writeFile(
+    resolve(root, "notes.md"),
+    "## Resumo\n\n- A release improves publication quality.\n\n## Novidades\n\n- **Feature:** Adds a useful capability for release reviewers.\n",
+    "utf8",
+  );
+  await writeFile(
+    resolve(root, "inventory.json"),
+    JSON.stringify({
+      from: "v1.0",
+      to: (await command("git", ["rev-parse", "HEAD"], root)).trim(),
+      files: ["feature.md"],
+      topics: [
+        {
+          category: "feat",
+          bullet: "- **Feature:** Adds a useful capability for release reviewers.",
+          files: ["feature.md"],
+        },
+      ],
+    }),
+    "utf8",
+  );
+  await expectValidation(root, 0);
+});
+
+test("rejects a compare-only body and incomplete range inventory", async () => {
+  const root = await repository();
+  await writeFile(
+    resolve(root, "notes.md"),
+    "Full Changelog: [v1.0...v1.1](https://example.test)\n",
+    "utf8",
+  );
+  await writeFile(
+    resolve(root, "inventory.json"),
+    JSON.stringify({
+      from: "v1.0",
+      to: (await command("git", ["rev-parse", "HEAD"], root)).trim(),
+      files: [],
+      topics: [],
+    }),
+    "utf8",
+  );
+  const result = await expectValidation(root, 1);
+  assert.match(result.stderr, /release notes cannot be compare-only/);
+});
+
+async function repository() {
+  const root = await mkdtemp(resolve(tmpdir(), "zaip-release-notes-"));
+  await command("git", ["init", "--quiet"], root);
+  await command("git", ["config", "user.email", "test@example.com"], root);
+  await command("git", ["config", "user.name", "Test"], root);
+  await writeFile(resolve(root, "feature.md"), "before\n", "utf8");
+  await command("git", ["add", "feature.md"], root);
+  await command("git", ["commit", "--quiet", "-m", "initial"], root);
+  await command("git", ["tag", "v1.0"], root);
+  await writeFile(resolve(root, "feature.md"), "after\n", "utf8");
+  await command("git", ["commit", "--quiet", "-am", "feature"], root);
+  return root;
+}
+
+function expectValidation(cwd, expectedCode) {
+  return new Promise((resolveResult, reject) => {
+    command("git", ["rev-parse", "HEAD"], cwd)
+      .then((sha) =>
+        run(
+          process.execPath,
+          [
+            script,
+            "--repository",
+            cwd,
+            "--from",
+            "v1.0",
+            "--to",
+            sha.trim(),
+            "--notes-file",
+            "notes.md",
+            "--inventory-file",
+            "inventory.json",
+          ],
+          { cwd },
+          (error, stdout, stderr) => {
+            const code = error?.code ?? 0;
+            if (code !== expectedCode)
+              reject(new Error(`expected ${expectedCode}, got ${code}: ${stderr}`));
+            else resolveResult({ stdout, stderr });
+          },
+        ),
+      )
+      .catch(reject);
+  });
+}
+
+function command(file, args, cwd) {
+  return new Promise((resolveResult, reject) => {
+    run(file, args, { cwd, encoding: "utf8" }, (error, stdout) =>
+      error ? reject(error) : resolveResult(stdout),
+    );
+  });
+}

package/templates/.agents/skills/zaip-skill-github-setup/SKILL.md

@@ -18,6 +18,11 @@ Support these independent modes:
 5. Create the first local commit.
 6. Publish only when the user also explicitly requests deploy/push.
 
+When one selected absolute parent folder must govern several child repositories,
+route to `$zaip-skill-github-setup-ssh-folder`. It owns the conditional-include,
+selected-parent dotenv, child-repository and GitHub-creation safeguards; do not
+apply the single-repository procedure below across an inferred folder tree.
+
 Before creating remote state, require the repository owner/name and visibility. Before generating a key, require the intended identity, key path, and passphrase policy. These choices materially affect security and cannot be guessed.
 
 ## Inspect before mutation

package/templates/.agents/skills/zaip-skill-github-setup-ssh-folder/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: zaip-skill-github-setup-ssh-folder
+description: Configure SSH and Git identity for child repositories under one selected parent folder; use for multi-repository setup, never to publish.
+---
+
+# Configurar SSH e Git por pasta
+
+Use quando uma pessoa selecionar uma pasta pai absoluta que contém vários
+repositórios filhos e precisar de uma identidade Git e SSH limitada a ela. A
+pasta pai cobre seus descendentes; não descubra outras pastas, repositórios,
+dotenvs ou identidades.
+
+Um pedido explícito de **configurar** autoriza a configuração local, limitada à
+pasta pai escolhida: Git, SSH e o `.env` explicitamente indicado nela. Não peça
+novamente essa autorização. Pergunte somente os fatos ainda ausentes: pasta pai
+absoluta, conta GitHub, chave selecionada ou pedido de criação de chave, e
+política de passphrase. Criação remota de repositório e push exigem pedido
+explícito, que pode já constar na mesma mensagem do usuário.
+
+Conduza uma etapa por vez: dados da pasta e conta, chave local, cadastro público
+no GitHub, `.env`, configuração e verificação. Explique o próximo passo e aguarde
+somente a intervenção humana necessária; não peça segredos no chat.
+Use o [modelo de dotenv](assets/.env.example) para preparar o arquivo escolhido,
+preservando seu conteúdo existente. O modelo não contém credenciais utilizáveis.
+
+1. Inspecione somente a pasta pai selecionada e cada repositório filho que a
+   pessoa indicar. Não faça busca recursiva de `.env`; leia ou altere somente o
+   `.env` explicitamente nomeado na pasta pai, como limite autorizado deste fluxo.
+2. Para configurar ou diagnosticar `includeIf`, chave, alias SSH, clone, acesso
+   GitHub ou criação de repositório, leia o [procedimento operacional](references/operational-procedure.md).
+3. Aplique uma única estratégia: `includeIf` com `core.sshCommand` ou alias SSH
+   existente. Confirme o comando efetivo com Git no repositório real; um teste
+   SSH isolado não prova o transporte Git.
+4. Cada repositório filho independente recebe seu próprio `.gitignore` ou
+   `info/exclude` revisado antes de qualquer stage. Pare e relate override,
+   política organizacional, autorização ou escopo ambíguo.
+
+## Proteção contra deleção de repositório
+
+Nunca exclua repositórios locais ou remotos, diretórios `.git`, a pasta pai, nem
+o diretório de um clone parcial como rollback. Preserve o clone parcial e
+reporte a falha. Esta restrição cobre somente esses alvos de repositório; ela não
+proíbe alterações de arquivos locais que a pessoa autorizou expressamente dentro
+do escopo selecionado. A proibição cobre CLI, REST, GraphQL, SDK, navegador,
+scripts e delegação; não contorne a trava por outra ferramenta. Na criação via
+API, aceite somente a credencial verificada sem permissão de excluir conforme
+o procedimento. Não teste a proteção tentando uma exclusão real.
+
+Esta skill oferece orientação e não concede permissões no sistema operacional,
+nem substitui controles do GitHub. A seleção por `includeIf` escolhe identidade
+por caminho; a permissão real continua confinada à conta, chave e permissões do
+repositório no GitHub. Para setup Git/GitHub de um único repositório, use
+`$zaip-skill-github-setup`; para publicação explicitamente solicitada, use
+`$zaip-skill-github-deploy`.

package/templates/.agents/skills/zaip-skill-github-setup-ssh-folder/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ZAIP SSH por Pasta"
+  short_description: "Configura SSH e Git por pasta com seguranca"
+  default_prompt: "Use $zaip-skill-github-setup-ssh-folder para configurar SSH e Git sob uma pasta pai absoluta selecionada."

package/templates/.agents/skills/zaip-skill-github-setup-ssh-folder/assets/.env.example

@@ -0,0 +1,9 @@
+# Copie para a pasta pai escolhida como .env; nunca publique esse arquivo.
+ZAIP_SSH_PARENT_PATH=C:/Repos/Cliente A/
+GITHUB_ACCOUNT=conta-selecionada
+GIT_USER_NAME=Nome da Pessoa
+GIT_USER_EMAIL=nome@exemplo.com
+# Somente caminho local; nunca coloque o conteúdo privado da chave aqui.
+SSH_PRIVATE_KEY_PATH=C:/Chaves SSH/cliente-a_ed25519
+# Deixe vazio enquanto a criação remota autorizada não precisar de token.
+GITHUB_TOKEN=

package/templates/.agents/skills/zaip-skill-github-setup-ssh-folder/references/operational-procedure.md

@@ -0,0 +1,137 @@
+# Procedimento operacional
+
+Leia esta referência depois de a pessoa selecionar uma pasta pai absoluta e um objetivo. Um pedido explícito de configurar autoriza a configuração local de Git, SSH e do `.env` pai indicado. A skill orienta a ação, mas não altera permissões do Windows ou do GitHub por si só. Push e criação remota exigem pedido explícito, inclusive na mesma mensagem; não repita autorização concedida.
+
+## Limite e dotenv
+
+1. Resolva o caminho físico da pasta pai absoluta, incluindo junctions/symlinks, e use barras `/` e barra final. Valide containment físico de cada destino; para um novo clone, valide o ancestral existente mais próximo antes de criar o filho. Não pesquise credenciais em pais, irmãos ou `.env` de filhos. A leitura pontual dos arquivos Git/SSH do usuário que participam dessa configuração é necessária; não faça varredura global.
+2. Inspecione só repositórios filhos explicitamente selecionados. Para clone bootstrap, a pessoa informa o diretório filho alvo absoluto. Preserve diretório parcial quando o clone falhar e reporte a falha.
+3. Trate **todo** valor de dotenv como dado: nunca o interpole em shell, nem use `source` ou `eval`. Leia apenas o `.env` pai explicitamente indicado; não faça varredura global ou recursiva. Antes de um valor compor `core.sshCommand`, valide e canonicalize o `SSH_PRIVATE_KEY_PATH` selecionado: rejeite NUL, quebra de linha e metacaracteres de controle do shell, inclusive `&`, `|`, `;`, `<`, `>`, `(`, `)`, `$`, crase, aspas simples e aspas duplas; exija caminho absoluto local permitido e confira que ele aponta à chave selecionada. Só então construa o argumento SSH com o caminho entre aspas duplas, para suportar espaços com segurança. O dotenv guarda caminho de chave, nunca a chave privada.
+
+```dotenv
+# Pasta pai selecionada; use barras / e barra final.
+ZAIP_SSH_PARENT_PATH=C:/Repos/Cliente A/
+GITHUB_ACCOUNT=conta-selecionada
+GIT_USER_NAME=Nome da Pessoa
+GIT_USER_EMAIL=nome@exemplo.com
+# Caminho local: nunca cole o conteúdo da chave privada aqui.
+SSH_PRIVATE_KEY_PATH=C:/Chaves SSH/cliente-a_ed25519
+# Opcional e em branco. Use apenas para criação remota explicitamente autorizada.
+GITHUB_TOKEN=
+```
+
+Adapte os valores com os dados já fornecidos e preserve variáveis existentes. O `.env` é uma entrada lida pela IA: Git e SSH não o carregam automaticamente. Guarde-o fora dos repositórios filhos, quando possível. Se a pasta pai também for um repositório, proteja-o no ignore desse repositório; cada filho independente precisa de seu próprio `.gitignore` ou `info/exclude` antes de stage. Ignore não retira segredos já rastreados: se houver algum, pare a publicação e trate a exposição. Proteja o `.env` com ACL apropriada ao usuário no Windows, não o faça commit e não procure dotenvs fora do caminho selecionado. O GitHub não pode fornecer uma chave privada: ela é criada e fica localmente sob controle da pessoa.
+
+## Chave SSH: fluxo iniciante no Windows
+
+Depois de confirmar conta, destino da chave e política de passphrase, uma pessoa que pediu explicitamente a criação pode seguir estes passos. Nunca exponha o arquivo privado criado.
+
+1. Confira `git --version`, `ssh -V` e a disponibilidade de `ssh-keygen`. Confirme um diretório de chaves existente ou crie o diretório escolhido dentro do setup autorizado; ele deve ficar fora de repositórios versionados. Abra PowerShell e crie a chave em um caminho novo:
+
+   ```powershell
+   ssh-keygen -t ed25519 -C 'nome@exemplo.com' -f 'C:\Chaves SSH\cliente-a_ed25519'
+   ```
+
+   Defina a passphrase conforme a política confirmada. Não sobrescreva chave existente nem presuma passphrase vazia.
+2. Copie **somente** o conteúdo do arquivo público terminado em `.pub`:
+
+   ```powershell
+   Get-Content -Raw 'C:\Chaves SSH\cliente-a_ed25519.pub' | Set-Clipboard
+   ```
+
+3. No GitHub, abra o perfil da conta: **Settings > SSH and GPG keys > New SSH key**. Em **Key type**, selecione **Authentication Key**, dê um título reconhecível, cole a chave pública e clique em **Add SSH key**.
+4. Volte com confirmação não secreta: conta usada, título da chave e caminho público, ou apenas que o cadastro foi concluído. Nunca envie chave privada ou passphrase.
+
+Mantenha ACL restritiva no arquivo privado e use passphrase quando a política ou o risco exigir. Não eleve privilégios nem inicie/configure `ssh-agent` sem autorização específica. Antes do primeiro uso, verifique a impressão digital do host com a fonte oficial do GitHub e confira a chave apresentada antes de aceitá-la; não aceite impressão nova apenas por um prompt.
+
+Use a chave selecionada para conferir a conta: `ssh -T -i 'C:/Chaves SSH/cliente-a_ed25519' -o IdentitiesOnly=yes git@github.com`. A saudação deve conter a conta esperada; o GitHub normalmente retorna código 1 mesmo após autenticação bem-sucedida. Não confunda nome/e-mail de commit com autenticação. A pessoa digita a passphrase localmente; nunca a salve no `.env` nem em argumentos. Se o agente SSH já estiver disponível, `ssh-add` pode carregar a chave no contexto do usuário; se indisponível, a digitação interativa continua possível. Git for Windows e Windows OpenSSH podem usar agentes distintos: verifique o executável usado por Git antes de diagnosticar falha.
+
+## Identidade dedicada e includeIf
+
+Escolha uma estratégia e mantenha-a consistente:
+
+- **Configuração condicional:** uma entrada `includeIf` global referencia arquivo dedicado com `user.name`, `user.email` e `core.sshCommand`.
+- **Alias SSH existente:** a URL remota usa `git@github-identidade:` e a configuração SSH existente escolhe a chave. Não misture alias e `core.sshCommand` sem motivo comprovado.
+
+`includeIf` seleciona identidade pelo diretório Git; não impede que a chave seja usada fora dessa pasta por outro comando e não concede acesso a repositórios sem permissão na conta. A chave de conta atende múltiplos repositórios; uma deploy key é ligada a um repositório e não é o padrão deste fluxo. Use `gitdir/i` no Windows e `gitdir` em sistemas com caminhos sensíveis a maiúsculas. Inspecione a condição exata e reutilize-a se corresponder à pasta normalizada. Adicione somente a entrada ausente. Faça backups com nomes únicos, somente dos arquivos editados que já existam, preservando entradas sem relação. Um Git global novo não exige copiar um arquivo inexistente. Consulte a origem efetiva, incluindo configuração XDG, antes de escolher o arquivo global a editar.
+
+Depois da validação descrita acima, use o caminho canonicalizado como dado no argumento. Em PowerShell, aspas simples preservam caminhos com espaços e aspas duplas dentro de `$sshCommand` protegem o caminho para o SSH; o valor não é executado por PowerShell:
+
+```powershell
+$parent = 'C:/Repos/Cliente A/'
+$identityConfig = 'C:/Git Config/cliente-a.gitconfig'
+$keyPath = 'C:/Chaves SSH/cliente-a_ed25519' # caminho já validado e canonicalizado
+$condition = "includeIf.gitdir/i:${parent}.path"
+$sshCommand = 'ssh -i "' + $keyPath + '" -o IdentitiesOnly=yes'
+
+git config --global --get-regexp '^includeIf\..*\.path$'
+git config --file $identityConfig user.name 'Nome da Pessoa'
+git config --file $identityConfig user.email 'nome@exemplo.com'
+git config --file $identityConfig core.sshCommand $sshCommand
+# Após os backups e a verificação: somente se $condition ainda não existir:
+git config --global $condition $identityConfig
+```
+
+Crie o diretório do arquivo de identidade quando necessário; faça os backups antes de executar o bloco. A condição deve ser aplicada depois de preparar o arquivo dedicado com sucesso. Em seguida, verifique origem e valor efetivo em repositório filho real:
+
+```powershell
+git -C 'C:/Repos/Cliente A/repo' config --show-origin --get user.name
+git -C 'C:/Repos/Cliente A/repo' config --show-origin --get user.email
+git -C 'C:/Repos/Cliente A/repo' config --show-origin --get core.sshCommand
+git -C 'C:/Repos/Cliente A/repo' ls-remote origin HEAD
+```
+
+`includeIf` corresponde ao diretório Git. Em worktrees, confirme `git rev-parse --git-dir`; se ele estiver fora da árvore, explique a exceção e adapte somente dentro do escopo autorizado. Diagnostique overrides locais, `GIT_SSH_COMMAND`, `GIT_SSH` e URLs HTTPS (que não usam SSH). Preserve remotos existentes; migre para SSH somente quando isso fizer parte do pedido. Um teste `ssh -T` não lê `core.sshCommand`; `git ls-remote` no filho prova o transporte efetivo. Um repositório remoto vazio pode responder sem referências com sucesso. Verifique pelo menos dois filhos, se existirem, e um repositório fora da pasta para demonstrar alcance; não crie nem clone repositórios reais apenas para testar.
+
+## Clone bootstrap por SSH
+
+Um clone exigido explicitamente pode usar o comando SSH selecionado apenas nessa operação; não grave override local persistente. O alvo deve ser filho absoluto da pasta pai e não pode ser removido se o clone falhar.
+
+```powershell
+# Reutilize somente o $sshCommand construído anteriormente com $keyPath validado.
+$target = 'C:\Repos\Cliente A\novo-repo'
+git -c "core.sshCommand=$sshCommand" clone git@github.com:OWNER/REPO.git $target
+```
+
+Se falhar, preserve `$target`, inspecione e reporte seu estado. Após sucesso, prove que `includeIf` foi selecionado no clone e que nenhum override local persistiu:
+
+```powershell
+git -C $target config --show-origin --get core.sshCommand
+git -C $target config --local --get core.sshCommand
+```
+
+O segundo comando não deve retornar valor. Não use clone para criar, publicar ou alterar repositório remoto.
+
+## GitHub e criação de repositório
+
+SSH autentica transporte Git, não a API do GitHub. Não troque autenticação global de `gh`. Sem token autorizado, clone SSH pode prosseguir quando solicitado; criação remota espera autorização manual ou token selecionado.
+
+Para criação automática explicitamente solicitada, escolha token somente do `.env` pai indicado. Um PAT clássico é o caminho prático: no GitHub, abra **Settings > Developer settings > Personal access tokens > Tokens (classic) > Generate**, escolha expiração e conceda `public_repo` para criação pública ou `repo` para criação privada. Rejeite `delete_repo` e escopos desconhecidos. Se a organização proibir PAT clássico, entregue a etapa manual; não use token fine-grained com **Administration (write)** para criação automatizada sem deleção, porque essa permissão pode permitir exclusão.
+
+Depois de gerar o PAT, a pessoa o salva localmente em `GITHUB_TOKEN` no `.env` escolhido e informa apenas que terminou. Reutilize o procedimento de [credenciais locais](../../zaip-skill-local-credentials/SKILL.md) com a pasta pai explicitamente escolhida como limite; não imprima, registre ou passe o token em argumentos. Parseie dotenv como dados, sem executar seu conteúdo. A chave privada permanece em seu arquivo, não nesse campo.
+
+Crie um ambiente somente para cada subprocesso mínimo de verificação/criação. Remova credenciais GitHub e overrides herdados (`GH_TOKEN`, `GITHUB_TOKEN`, variantes Enterprise, `GH_HOST`, `GH_REPO`, `GH_DEBUG` e tracing); injete apenas o token escolhido como `GH_TOKEN` e o host esperado. Não altere o ambiente global, não use `gh auth switch`, não salve o token com `gh auth login` e não use `gh auth token` em diagnóstico. Descarte as referências em `finally`.
+
+Antes da criação, consulte `GET /user` nesse contexto e confira a conta esperada. Leia somente o cabeçalho de escopos `x-oauth-scopes` de forma sanitizada: aceite apenas `public_repo`/`repo` suficientes para o alvo e sem `delete_repo`; não confunda `x-accepted-oauth-scopes` (o que o endpoint aceita) com escopos concedidos. Tipo ou escopos não verificáveis bloqueiam apenas criação automática; não recorra à credencial global. Nunca confirme proteção enviando DELETE. Esta restrição do PAT vale para ele, não para outras sessões da conta ou para o navegador.
+
+Antes de criar, resolva owner, nome e visibilidade a partir do pedido; pergunte apenas o que falta. Consulte a existência: repositório existente é reutilizado conforme autorização, não apagado/recriado. Um 404 também pode ser falta de acesso; confirme conta/owner e não repita criação após erro ambíguo sem consultar o estado. No subprocesso autenticado, execute `gh repo create OWNER/REPO --private` ou `--public` conforme a visibilidade escolhida, sem `--push`. Depois clone a URL SSH no filho escolhido pelo procedimento anterior. Se já houver repositório local, adicione `origin` somente quando ausente e valide qualquer remoto existente.
+
+Quando o token estiver ausente ou a organização proibir o fluxo, oriente criação manual: GitHub **+ > New repository**, selecione owner, nome e visibilidade, clique **Create repository** e volte com a URL SSH. Isso não exige PAT da IA; o clone pode continuar após a criação humana. Políticas de SSO e organização devem ser atendidas, nunca contornadas. Não use outras credenciais para driblar a trava.
+
+## Proteção contra deleção
+
+Nunca exclua repositórios locais ou remotos, diretórios `.git`, a pasta pai ou clones parciais. Aplique a proibição a CLI, REST, GraphQL, SDK, navegador, scripts, delegação e rollback; não ofereça comandos executáveis de exclusão. Não tente substituir a exclusão por esvaziamento destrutivo, force-push ou remoção de todas as referências. A trava não bloqueia edições normais de arquivos já autorizadas. Em falha de configuração, restaure somente os trechos próprios a partir do backup e preserve mudanças concorrentes; em falha de clone ou criação, preserve o repositório e relate o estado.
+
+Ao concluir, informe pasta abrangida, caminhos de configuração alterados, conta SSH verificada, origem da identidade Git e estado separado de clone/criação/publicação. Diferencie validação local, teste Git/SSH e criação remota efetivamente observada. Nunca afirme que configurar SSH publicou algo.
+
+## Fontes oficiais
+
+- [Git conditional includes](https://git-scm.com/docs/git-config#_conditional_includes)
+- [GitHub: testar conexão SSH](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/testing-your-ssh-connection)
+- [GitHub: fingerprints SSH](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints)
+- [GitHub: adicionar nova chave SSH](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)
+- [GitHub: escopos de PAT clássico](https://docs.github.com/en/developers/apps/scopes-for-oauth-apps#available-scopes)
+- [GitHub: permissões de fine-grained PAT](https://docs.github.com/en/rest/authentication/permissions-required-for-fine-grained-personal-access-tokens)
+- [GitHub CLI: ambiente](https://cli.github.com/manual/gh_help_environment)
+- [GitHub: criar e excluir repositórios e escopos exigidos](https://docs.github.com/en/rest/repos/repos)
+- [GitHub: gerenciamento de tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)

package/templates/.agents/skills/zaip-skill-growth-strategy-revops/SKILL.md

@@ -3,24 +3,14 @@ name: zaip-skill-growth-strategy-revops
 description: Guide data-driven growth strategy, RevOps decisions, experiments, and financial-impact recommendations. Use for cross-funnel growth or operating decisions; not for raw data analysis, campaign production, or external commercial action.
 ---
 
-# Orientar Growth e RevOps
+# Growth e RevOps proporcionais ao pedido
 
-## Localização canônica
+- Responda uma pergunta delimitada diretamente, usando apenas métricas, período e contexto necessários; não imponha diagnóstico completo ou plano integral.
+- Separe fato observado, cálculo, hipótese e recomendação. Para números, declare fórmula, unidade, premissas e lacunas. Não prometa receita/economia nem atribua causalidade sem evidência adequada.
+- Pergunte somente pela informação que muda a decisão; silêncio não é resposta. Preserve estratégias e fontes aprovadas sem duplicá-las.
+- Para diagnóstico, decisão estratégica, recomendação financeira, desenho de experimento ou entrega persistente, carregue [o fluxo progressivo](references/extended-workflow.md). Artefatos vivem em `.agents/growth/`; `strategy.md` centraliza decisões.
+- Dados e significância exigem método reproduzível; marca, campanha e playbook comercial vão aos respectivos especialistas. Esta skill não autoriza campanha, alteração comercial ou experimento externo.
 
-Salve diagnósticos, estratégias, decisões de RevOps, hipóteses de experimento e recomendações de Growth em `.agents/growth/`. Não salve esses artefatos em `docs/`, na raiz do repositório ou em diretórios de brand, marketing ou sales.
+Uma interaction read-only não materializa Task/Change. Entrega persistente segue lifecycle, Requirements/AC e assurance proporcionais; só trabalho técnico carrega engenharia.
 
-O arquivo central da área é `.agents/growth/strategy.md`; atualize-o quando uma decisão mudar a estratégia de Growth ou RevOps. Diagnósticos e experimentos específicos podem ser arquivos adicionais na mesma pasta.
-
-## Descoberta e entrega progressivas
-
-1. Comece pelas referências acessíveis fornecidas — texto, site, PDF, PPT, planilha, arquivo ou imagem. Registre cada fonte com locator e classifique seu conteúdo como fato, decisão aprovada, hipótese, dado ou lacuna. Reutilize os artefatos aprovados; não recrie sua fonte central nem duplique seu conteúdo em outro arquivo.
-2. Se o trabalho começar do zero ou o contexto for insuficiente, faça no máximo cinco perguntas críticas por turno, por até três turnos. Pergunte somente por lacunas que mudam a decisão: objetivo, período, segmentos, funil, métricas, restrições ou impacto financeiro. Espere as respostas antes de avançar nas partes que delas dependem; silêncio não é resposta nem aprovação. Após três turnos, prossiga somente com hipóteses delegáveis rotuladas e lacunas explícitas, sem inventar decisões, autoridade, métricas ou datasets.
-3. Um pedido pontual com contexto suficiente deve ser respondido diretamente, sem questionário obrigatório nem plano integral.
-4. Aplique somente as partes necessárias ao escopo solicitado: `diagnóstico do funil e handoffs` → `prioridades` → `experimento` → `estratégia consolidada`. Identifique a parte em construção e só consolide em `.agents/growth/strategy.md` quando o contexto sustentar uma decisão estratégica. Mantenha diagnósticos e experimentos específicos como arquivos complementares, sem duplicar a estratégia central; não exija todos os módulos ou formatos.
-5. No diagnóstico, examine aquisição, qualificação, conversão, receita, retenção, expansão, custos e capacidade. Separe fatos observados, cálculo determinístico, hipótese e recomendação; não declare causalidade sem desenho ou evidência adequados.
-6. Priorize oportunidades por impacto potencial, confiança, esforço, dependências e reversibilidade. Para recomendações financeiras, explicite fórmula, premissas, sensibilidade e lacunas; não prometa receita nem economia.
-7. Para cada experimento, registre hipótese, população, métrica primária, guardrails, duração, critério de decisão, risco e responsável. Não execute campanhas, alterações comerciais externas ou experimentos sem a autorização e o escopo correspondentes.
-8. Em conselho ou planejamento de negócio, priorize portfólio, modelo de negócio, opções e handoffs de execução. Solicite análise reprodutível de Gabi quando houver dataset, cálculo, qualidade de dados ou significância. Encaminhe plataforma de marca à Sarah, campanha/copy a Lúcia e playbook/processo sales-facing a Aaron.
-9. Produza uma recomendação consultiva: decisão, evidência, incerteza, opções, impacto esperado, próximo experimento e dono da próxima ação. Não produza campanha, Brandbook ou playbook comercial como substituto da recomendação.
-
-Consulte o [framework de decisão](references/growth-revops-framework.md) para planejar diagnóstico ou experimento.
+Para resumo salvo ou documento de contexto simples, delimitado e de baixo impacto com fontes fornecidas, use o [perfil editorial `lite`](../zaip-skill-task/SKILL.md#assurance-proporcional) e selecione `--risk lite`. Diagnóstico estratégico, recomendação financeira, experimento, alteração operacional ou ação externa permanecem fora desse perfil.

package/templates/.agents/skills/zaip-skill-growth-strategy-revops/references/extended-workflow.md

@@ -0,0 +1,21 @@
+# Orientar Growth e RevOps
+
+## Localização canônica
+
+Salve diagnósticos, estratégias, decisões de RevOps, hipóteses de experimento e recomendações de Growth em `.agents/growth/`. Não salve esses artefatos em `docs/`, na raiz do repositório ou em diretórios de brand, marketing ou sales.
+
+O arquivo central da área é `.agents/growth/strategy.md`; atualize-o quando uma decisão mudar a estratégia de Growth ou RevOps. Diagnósticos e experimentos específicos podem ser arquivos adicionais na mesma pasta.
+
+## Descoberta e entrega progressivas
+
+1. Comece pelas referências acessíveis fornecidas — texto, site, PDF, PPT, planilha, arquivo ou imagem. Registre cada fonte com locator e classifique seu conteúdo como fato, decisão aprovada, hipótese, dado ou lacuna. Reutilize os artefatos aprovados; não recrie sua fonte central nem duplique seu conteúdo em outro arquivo.
+2. Se o trabalho começar do zero ou o contexto for insuficiente, faça no máximo cinco perguntas críticas por turno, por até três turnos. Pergunte somente por lacunas que mudam a decisão: objetivo, período, segmentos, funil, métricas, restrições ou impacto financeiro. Espere as respostas antes de avançar nas partes que delas dependem; silêncio não é resposta nem aprovação. Após três turnos, prossiga somente com hipóteses delegáveis rotuladas e lacunas explícitas, sem inventar decisões, autoridade, métricas ou datasets.
+3. Um pedido pontual com contexto suficiente deve ser respondido diretamente, sem questionário obrigatório nem plano integral.
+4. Aplique somente as partes necessárias ao escopo solicitado: `diagnóstico do funil e handoffs` → `prioridades` → `experimento` → `estratégia consolidada`. Identifique a parte em construção e só consolide em `.agents/growth/strategy.md` quando o contexto sustentar uma decisão estratégica. Mantenha diagnósticos e experimentos específicos como arquivos complementares, sem duplicar a estratégia central; não exija todos os módulos ou formatos.
+5. No diagnóstico, examine aquisição, qualificação, conversão, receita, retenção, expansão, custos e capacidade. Separe fatos observados, cálculo determinístico, hipótese e recomendação; não declare causalidade sem desenho ou evidência adequados.
+6. Priorize oportunidades por impacto potencial, confiança, esforço, dependências e reversibilidade. Para recomendações financeiras, explicite fórmula, premissas, sensibilidade e lacunas; não prometa receita nem economia.
+7. Para cada experimento, registre hipótese, população, métrica primária, guardrails, duração, critério de decisão, risco e responsável. Não execute campanhas, alterações comerciais externas ou experimentos sem a autorização e o escopo correspondentes.
+8. Em conselho ou planejamento de negócio, priorize portfólio, modelo de negócio, opções e handoffs de execução. Solicite análise reprodutível de Gabi quando houver dataset, cálculo, qualidade de dados ou significância. Encaminhe plataforma de marca à Sarah, campanha/copy a Lúcia e playbook/processo sales-facing a Aaron.
+9. Produza uma recomendação consultiva: decisão, evidência, incerteza, opções, impacto esperado, próximo experimento e dono da próxima ação. Não produza campanha, Brandbook ou playbook comercial como substituto da recomendação.
+
+Consulte o [framework de decisão](growth-revops-framework.md) para planejar diagnóstico ou experimento.

package/templates/.agents/skills/zaip-skill-hostinger-cloudflare-terraform/SKILL.md

@@ -1,17 +1,25 @@
 ---
 name: zaip-skill-hostinger-cloudflare-terraform
-description: Operate Terraform for scoped Cloudflare DNS and Hostinger VPS with target-bound credentials, state safety, and truthful validation.
+description: Operate scoped Cloudflare/Hostinger Terraform and prepare AWS CLI/Terraform environments with target-bound credentials, state safety, and truthful validation.
 ---
 
-# Terraform Cloudflare e Hostinger
+# Terraform Cloudflare, Hostinger e preparação AWS
 
-Use para criar, importar, ler, alterar ou validar VPS Hostinger e DNS Cloudflare por Terraform. Leia o contrato de infraestrutura indicado pela Task, [o procedimento operacional](references/operational-contract.md) e [o guia do runner autônomo](references/autonomous-runner.md).
+Use para criar, importar, ler, alterar ou validar VPS Hostinger e DNS Cloudflare por Terraform, ou preparar/provisionar AWS com AWS CLI e Terraform dentro de uma Task autorizada. Primeiro escolha o fluxo pela Task:
 
-1. Delimite o perfil `autonomous-cloud`, conta+zona Cloudflare, conta Hostinger, IDs das VPS e fingerprints SSH. Credenciais de dotenv não concedem autoridade nem permitem novo alvo. Use `.env` da raiz primeiro e `.agents/.env` somente quando selecionado pela execução.
+Para alguém iniciando a contratação ou configuração de VPS, comece pelo [guia inicial Hostinger VPS e Terraform](references/guia-iniciante-hostinger-vps.md). Comece pelo estágio já conhecido e faça no máximo três perguntas somente quando faltar contexto; prossiga sem reautorização nas ações já delimitadas. A preferência é a oferta apresentada pela Hostinger como VPS gerenciada por IA; ela facilita o hPanel, terminal Web e assistência Kodee, mas continua sendo VPS KVM com root SSH e administração do cliente. Não peça token de API para o primeiro acesso SSH e não execute ação remota sem a autorização e o contrato exigidos abaixo.
+
+- **Cloudflare/Hostinger:** leia o contrato de infraestrutura indicado pela Task, [o procedimento operacional](references/operational-contract.md) e [o guia do runner autônomo](references/autonomous-runner.md). Preserve o runner existente e seus requisitos.
+- **AWS:** leia somente o contrato AWS declarado na Task e [o contrato AWS CLI/Terraform](references/aws-cli-terraform.md). Não leia, exija ou derive `operational-contract`, `autonomous-runner`, conta/zona Cloudflare, conta/VPS Hostinger ou inputs SSH. Não use `cloud-runner.mjs` para AWS.
+
+1. No fluxo Cloudflare/Hostinger, delimite o perfil `autonomous-cloud`, conta+zona Cloudflare, conta Hostinger, IDs das VPS e fingerprints SSH. Credenciais de dotenv não concedem autoridade nem permitem novo alvo. Use `.env` da raiz primeiro e `.agents/.env` somente quando selecionado pela execução.
    Quando uma Task já registra mandato permanente e o `.env` raiz possui identificadores deliberados, faça descoberta somente de leitura para derivar o contrato de alvo; não exija JSON manual ou reautorização. Não generalize essa exceção a outro projeto.
-2. Aplique `$zaip-skill-local-credentials` e injete a credencial mínima por subprocesso: Cloudflare para DNS, Hostinger para VPS, backend de state quando aplicável, e referência de chave+fingerprint para SSH. Nunca mostre token, senha, state, plano binário ou material de chave.
-3. Cloudflare controla DNS e edge; Hostinger controla apenas VPS. Nunca chame ou modele DNS Hostinger. Preserve Pages como destino web separado da origem VPS.
-4. Exija VPS 1 como ingress público e VPS 2 como aplicação privada. Não exponha Redis, BullMQ, exporters, painéis ou observabilidade; declare transporte privado, firewall e executor de configuração antes de afirmar que existem.
-5. Antes de `apply`, exija backend remoto criptografado, versionado e com locking. Rode `init`, `fmt`, `validate` e plano salvo/revisado. Apply usa somente o plano revisado; importação exige ID explicitamente aprovado e revisão de state sem segredo.
-6. Depois de escrever, faça refresh/read-after-write e testes de DNS, TLS, saúde, negação de portas, isolamento beta/produção e restore. Sem execução observada contra os alvos delimitados, registre somente prova estática/local.
-7. Em criação, confirme nomes, plano, região, template e teto aprovados, vincule IDs observados e verifique fingerprint antes de SSH. Dentro desse escopo, portas aprovadas, firewall, rotação de chave e DNS são autônomos. Troca de conta/zona/VPS/fingerprint, expansão de orçamento, destino ou recurso desconhecido, ou efeito irreversível ainda não aprovado bloqueia até que a Task atualize o escopo.
+2. No fluxo Cloudflare/Hostinger, aplique `$zaip-skill-local-credentials` e injete a credencial mínima por subprocesso: Cloudflare para DNS, Hostinger para VPS, backend de state quando aplicável, e referência de chave+fingerprint para SSH. Nunca mostre token, senha, state, plano binário ou material de chave.
+3. No fluxo Cloudflare/Hostinger, Cloudflare controla DNS e edge; Hostinger controla apenas VPS. Nunca chame ou modele DNS Hostinger. Preserve Pages como destino web separado da origem VPS.
+4. No fluxo Cloudflare/Hostinger, exija VPS 1 como ingress público e VPS 2 como aplicação privada. Não exponha Redis, BullMQ, exporters, painéis ou observabilidade; declare transporte privado, firewall e executor de configuração antes de afirmar que existem.
+5. No fluxo Cloudflare/Hostinger, antes de `apply`, exija backend remoto criptografado, versionado e com locking. Rode `init`, `fmt`, `validate` e plano salvo/revisado. Apply usa somente o plano revisado; importação exige ID explicitamente aprovado e revisão de state sem segredo.
+6. No fluxo Cloudflare/Hostinger, depois de escrever, faça refresh/read-after-write e testes de DNS, TLS, saúde, negação de portas, isolamento beta/produção e restore. Sem execução observada contra os alvos delimitados, registre somente prova estática/local.
+7. No fluxo Cloudflare/Hostinger, em criação, confirme nomes, plano, região, template e teto aprovados, vincule IDs observados e verifique fingerprint antes de SSH. Dentro desse escopo, portas aprovadas, firewall, rotação de chave e DNS são autônomos. Troca de conta/zona/VPS/fingerprint, expansão de orçamento, destino ou recurso desconhecido, ou efeito irreversível ainda não aprovado bloqueia até que a Task atualize o escopo.
+8. No fluxo AWS, delimite `account_id`, região, profile de origem, principal do backend, principal/role do provider, bucket/key S3 e recursos Terraform antes de usar a CLI. SSO é preferível: `aws configure sso`, `aws sso login --profile` e `aws sts get-caller-identity --profile --region`. Profile existente, OIDC ou role já autorizada também podem cumprir o contrato se a identidade STS conferida corresponder; não use profile padrão implícito.
+9. No fluxo AWS, separe o principal que faz bootstrap/inicializa/acessa o backend S3 do principal/role que o provider AWS usa. O contrato deve nomear os dois, suas contas e regiões, e a verificação STS de cada um. Prefira `role_arn` com `source_profile` ou OIDC; se `aws sts assume-role` for inevitável, não exponha stdout de credenciais. Credenciais ou cache SSO não entram em `.env`, backend-config secreto, plano, state, Git ou evidência.
+10. No fluxo AWS, para Terraform >= 1.10, exija bucket e key aprovados, `region` explícita, `encrypt = true` e `use_lockfile = true`. Faça bootstrap zero-environment separado pelo AWS CLI/Terraform autorizado para criar somente o bucket S3 de state, habilitar versionamento, recovery, encryption e lockfile; `terraform init` não cria o bucket. Exija IAM de menor privilégio e procedimento de recuperação; não configure DynamoDB para novo locking. `backend-config` sem segredo pode ser versionado. Sem lockfile, faça bootstrap com `terraform init`, revise o lock gerado e só então use `terraform init -lockfile=readonly`. A preparação executa `fmt`, `validate` e `plan -out` revisável. A Task AWS ativa, explicitamente autorizada, pode cobrir bootstrap e provisionamento AWS delimitado via AWS CLI/Terraform sem confirmação repetida; `apply` somente consome o plano salvo revisado e contrato delimitado.