@zaip-ai/cli 2.2.0 → 2.6.0

package/templates/.agents/runtime/checksums.sha256

@@ -1,11 +1,11 @@
 b146bd0c7c60b1ab43c4f71e0b1d2262c6df6da6f7053a0425f834ccb77a6b48  LICENSE
 bc02cba77e8d51e5c580f43668863dc868eda66f1ff663bfaa49fcf3ca16320e  THIRD_PARTY_NOTICES.md
-c4a2383a03bdb6739d16a0e24058e4b9c7da4e63d203e0be2f448868cc03c530  VERSION
-69de029dc9c40ea63988c9dc862833928c80d65b211818ec757be36f19f1e334  bin/zaip.mjs
-a110baef708470429aaf722e962c5698903380404b86113d3d5cd2bf04592f38  manifest.json
+6693435eadb673dda297a0652d241e293e361200bc40db949cf2501d18dd01ee  VERSION
+d0f72331e6ecf333e014dc5754b277167f905543324d6d94938d2b1af4c18718  bin/zaip.mjs
+d0a3d5ade8b74dc85716a279e433dea7c2ace641e334ca6b28f11a79d0d15d40  manifest.json
 7f89219d7c567c82a51679ad136d84364bded7ac659492537e125d33b1d58a7a  migrations/001-layout-v1.json
 5f8c48b286d0b44d8fbb57a9a5d009a8a500439aa3148d750b8f193f72995c9f  migrations/002-layout-v2.json
-ddc100b4d4ce1b96d27a50d1e66c1514636aceb36e72157dee07e2b12a5df2bd  pnpm-lock.sha256
-49097573922f2c330f5b1211b03a87a86db87243223ed9a38bd248f4f72f70f7  provenance.json
-fbfcc610258c437829e75846957255cc96202e585b4447dd3df14f2217ea734d  sbom.cdx.json
+12aa001df694e40b5bfbacea33d0e7ea5fe4b28e17396ec640aaa52ede0371a3  pnpm-lock.sha256
+655631d84ef9c9d1fc763031f2510027b5bedcbe31933434b141bb811924b78a  provenance.json
+ea7aaa398e7ba981ec7b583059734ee05a085170da10b30118c900d23da7c4e2  sbom.cdx.json
 b3ffedf9e146be802a15b4009f33e031dec3071ca1525e12c67606fd964a3067  schemas/contracts.schema.json

package/templates/.agents/runtime/manifest.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 2,
   "name": "zaip-aios",
-  "version": "2.2.0",
+  "version": "2.6.0",
   "node": ">=22",
   "files": [
     "LICENSE",

package/templates/.agents/runtime/pnpm-lock.sha256

@@ -1 +1 @@
-55e20a2b6d9239d9b31eace160d0e4ba08bc9b4641806639cab429d8a1e4076f  pnpm-lock.yaml
+4a8b304fd8e27ed71d0d2c91a5e692e34fc240b477e3037b02a42301685c5601  pnpm-lock.yaml

package/templates/.agents/runtime/provenance.json

@@ -2,10 +2,10 @@
   "schema_version": 1,
   "statement_type": "self_reported_build_integrity",
   "authenticity": "unverified",
-  "version": "2.2.0",
+  "version": "2.6.0",
   "source_origin": "zaip-aios:local-build",
-  "lockfile_sha256": "55e20a2b6d9239d9b31eace160d0e4ba08bc9b4641806639cab429d8a1e4076f",
-  "sbom_sha256": "fbfcc610258c437829e75846957255cc96202e585b4447dd3df14f2217ea734d",
-  "runtime_sha256": "2f75214582b6e6a333cadd62a2d20236c59dd44a771f912e7ab22a8b090b3bb1",
-  "statement_sha256": "7977cc341adf229d5189b03d73c4b27b5f3c3f52d87f24b6092495c1fe2eb2b5"
+  "lockfile_sha256": "4a8b304fd8e27ed71d0d2c91a5e692e34fc240b477e3037b02a42301685c5601",
+  "sbom_sha256": "ea7aaa398e7ba981ec7b583059734ee05a085170da10b30118c900d23da7c4e2",
+  "runtime_sha256": "3a46f3bdbb6a04372c76f7b1ac6949056b690ba950e5ad412ef46b8e67f277ca",
+  "statement_sha256": "d6d5244320a24c2fcf48255f769796a862671609e3663240eb372606a5aa8c18"
 }

package/templates/.agents/runtime/sbom.cdx.json

@@ -6,7 +6,7 @@
     "component": {
       "type": "application",
       "name": "zaip-aios",
-      "version": "2.2.0"
+      "version": "2.6.0"
     }
   },
   "components": [

package/templates/.agents/sales/playbook.md

@@ -0,0 +1,3 @@
+# Playbook de Sales
+
+Em construção.

package/templates/.agents/skills/zaip-aios/SKILL.md

@@ -1,11 +1,13 @@
 ---
-# zaip-managed generated-do-not-edit source=discovery-skill version=2.2.0 sha256=d530dbf54b4fc554a533e0ac300d6c148b598a82f1dcc0680b9d9bdaf4103696
+# zaip-managed generated-do-not-edit source=discovery-skill version=2.5.0 sha256=76f3edc1dc8dfecc8c1b3c5b789557a515d05e270c044bf35e758923dff0aa0f
 name: zaip-aios
 description: Discover and apply the repository-local ZAIP-AIOS framework.
 ---
 
 # ZAIP-AIOS adapter
 
-Keep this native client bootstrap. After reading project configuration, load the applicable `.agents/requirements/`, `.agents/rules/`, and `.agents/skills/` from their canonical locations.
+This compatibility bootstrap is retained in native client skill directories; its metadata keeps implicit invocation. It routes to canonical `.agents/` guidance and does not duplicate Rules or skills.
 
-Read `.agents/config/project.yaml` first. Apply ZAIP only for literal boolean `zaip.enabled: true`; otherwise ignore it except maintenance or `zaip enable`. When enabled, capture once: analysis is `conversation`, continuation reuses focus, and independent edits use semantic `new-work`. Thinking about PRD/SPEC is conversation; explicit creation persists complete draft artifacts and PreparedPlan blueprints under interaction telemetry, with Tasks materialized only at ready/execute. Ask at most five critical questions per turn and stop after three turns, then record delegable AI decisions. Resolve finalize/implement/develop using target plus persisted status, and create a linked rework successor instead of reopening cancelled PRDs. Read `.agents/rules/core.md`, then only applicable context from runtime projections and explicit records—never normal history. Publication is Git-only.
+Read `.agents/config/project.yaml` first. Apply ZAIP only for literal boolean `zaip.enabled: true`; otherwise ignore it except maintenance or `zaip enable`. When enabled, read `.agents/rules/core.md`, Rules marked `always`, and only applicable Rules, Requirements in .agents/requirements/ and canonical skills in .agents/skills/, selected by explicit ID, phase, path or domain. Do not preload the corpus, lifecycle history or Run payloads. Follow the applicable canonical workflow for execution.
+
+Before delegation, use `context agents` for discovery and `context agents --agent <id>` for the selected canonical contract; the resolver validates provenance and recomputes invalid discovery locally. Purpose never authorizes. For agent context, prefer `context build --view compact` with the known ID, role and phase: it is one view of the governing pack. Follow `zaip-skill-context` and validate continuity with `context handoff`; preserve required content and references.

package/templates/.agents/skills/zaip-skill-adapt-stack/SKILL.md

@@ -9,3 +9,4 @@ description: Adapt the ZAIP profile when the default stack or repository shape d
 2. Define extensions, layer/module detection, parser, commands, storage boundaries and composition roots.
 3. Add positive and negative fixtures for every critical rule.
 4. Validate the profile contract and commands; mark supported only after offline evals pass.
+5. Compare declared stack components with installed manifests and runtime evidence. Report unsupported, unavailable, and drifted components separately; do not infer a capability from a dependency name.

package/templates/.agents/skills/zaip-skill-api-contracts/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: zaip-skill-api-contracts
+description: Define and validate stable Hono API request, response, error, authorization, and compatibility contracts.
+---
+
+# Define API contracts
+
+Use for a new or changed HTTP endpoint consumed beyond its implementation.
+
+1. Specify route ownership, authentication, input validation, status codes, error body, pagination, idempotency, and versioning behavior.
+2. Keep Hono routing thin; dispatch use cases through module contracts and avoid leaking database rows.
+3. Decide compatibility before implementation. Additive changes are preferred; make breaking changes explicit with consumer migration evidence.
+4. Test valid, malformed, unauthorized, forbidden, empty, and failure responses using the app request path.
+5. Generate or update an OpenAPI artifact only when it is a supported consumer contract, then test it against the implementation.

package/templates/.agents/skills/zaip-skill-api-contracts/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "API Contracts"
+  short_description: "Define stable Hono API behavior contracts"
+  default_prompt: "Use $zaip-skill-api-contracts to define and test this HTTP API contract."

package/templates/.agents/skills/zaip-skill-application-observability/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: zaip-skill-application-observability
+description: Instrument application logs, metrics, traces, dashboards, and alerts with actionable correlation and ownership.
+---
+
+# Observe application behavior
+
+Use when adding or repairing runtime observability for APIs, workers, jobs, or integrations.
+Read `references/signal-design.md` before adding metric labels or correlation fields.
+
+1. Define the user or operational question before choosing logs, metrics, or traces. Include owner, threshold, and expected response for each alert.
+2. Correlate request, job, and integration work with safe identifiers; exclude secrets, credentials, and sensitive payloads.
+3. Measure service level signals, dependency failures, queue depth, retries, and resource saturation where they affect behavior.
+4. Verify a controlled error and a successful flow appear in the intended signals and can be traced to the affected operation.
+5. Keep telemetry availability distinct from a fabricated zero or presumed healthy value.

package/templates/.agents/skills/zaip-skill-application-observability/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Application Observability"
+  short_description: "Instrument actionable application runtime signals"
+  default_prompt: "Use $zaip-skill-application-observability to instrument this API or worker flow."

package/templates/.agents/skills/zaip-skill-application-observability/references/signal-design.md

@@ -0,0 +1,3 @@
+# Signal design
+
+Prometheus metrics use bounded labels such as route, status family, worker, and queue. Grafana panels answer an owner question. Correlation IDs belong in structured logs and traces, not metric labels. Verify a request that enqueues a job by following request correlation to job correlation, duration, retry, and final effect. An unavailable measurement remains unavailable.

package/templates/.agents/skills/zaip-skill-application-readiness/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: zaip-skill-application-readiness
+description: Assess application readiness across configuration, security, data, jobs, capacity, observability, and recovery evidence.
+---
+
+# Assess application readiness
+
+Use before a first production rollout or a material production-affecting change.
+Use the `references/evidence-matrix.md` fields for the final assessment.
+
+1. Build a candidate-specific checklist from actual requirements: artifact, configuration, authorization, data migration, queues, performance, monitoring, backup, and rollback.
+2. Consume evidence from specialized skills rather than recreating their checks. Mark each item passed, pending, not applicable, or unavailable with a locator.
+3. Verify that runtime and environment identities match the candidate under review.
+4. Escalate unknown critical dependencies and missing recovery evidence; never convert absence into a passing status.
+5. Readiness is an assessment only and never authorizes deployment or final lifecycle approval.

package/templates/.agents/skills/zaip-skill-application-readiness/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Application Readiness"
+  short_description: "Assess evidence for production application readiness"
+  default_prompt: "Use $zaip-skill-application-readiness to assess this release candidate readiness."

package/templates/.agents/skills/zaip-skill-application-readiness/references/evidence-matrix.md

@@ -0,0 +1,3 @@
+# Evidence matrix
+
+Record one row per readiness condition: candidate, environment, check, expected result, observed result, status, and evidence locator. State the rollout conclusion separately. Missing or unavailable checks remain pending and cannot be self-approved.

package/templates/.agents/skills/zaip-skill-architecture-design/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: zaip-skill-architecture-design
+description: Design application modules, boundaries, data ownership, and runtime flows before structural implementation.
+---
+
+# Design architecture
+
+Use when a new capability needs module boundaries, a cross-cutting design, or a documented tradeoff before code changes.
+
+1. Read the declared stack, active Requirements, existing module inventory, and `.agents/architecture/software-architecture.md`. Treat that architecture file as a generated projection; change approved config or Decisions, then regenerate it through the relevant workflow.
+2. Identify actors, commands, queries, owned data, public contracts, synchronous calls, and asynchronous handoffs.
+3. Assign every dependency direction and infrastructure concern to a module boundary. Record assumptions and unresolved decisions with `$zaip-skill-decisions`.
+4. Produce a concise boundary map with failure, authorization, tenancy, and rollback implications. Use `$zaip-skill-enforce-architecture` to check a proposed implementation.
+5. Keep design separate from execution authority; create a SPEC or Task only on an explicit request.

package/templates/.agents/skills/zaip-skill-architecture-design/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Architecture Design"
+  short_description: "Design modules and runtime boundaries"
+  default_prompt: "Use $zaip-skill-architecture-design to design the modules, ownership, and flows for this capability."

package/templates/.agents/skills/zaip-skill-async-jobs/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: zaip-skill-async-jobs
+description: Design and verify BullMQ producers and workers with idempotency, retries, recovery, and observable failure handling.
+---
+
+# Operate asynchronous jobs
+
+Use for BullMQ queues, jobs, workers, retries, scheduling, or cancellation.
+
+1. Define a versioned payload schema, ownership, tenant context, actor or validated authorization snapshot, idempotency key, success effect, retry policy, concurrency, and dead-letter handling. A worker validates it and re-authorizes in a fresh transaction unless snapshot semantics are explicitly defined and validated.
+2. Persist or derive enough state to make a repeated delivery safe. Never use a queue job as the sole source of durable business truth.
+3. Ensure workers perform bounded work, shut down cleanly, and emit correlation identifiers without secrets.
+4. Test duplicate delivery, partial failure, retry exhaustion, worker restart, cancellation, missing/forged/stale/mismatched authorization payload, and tenant A job followed by tenant B job where supported.
+5. Report operational limits and manual recovery steps; do not silently discard failed work.

package/templates/.agents/skills/zaip-skill-async-jobs/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Async Jobs"
+  short_description: "Build reliable BullMQ jobs and workers"
+  default_prompt: "Use $zaip-skill-async-jobs to design this queue producer and worker safely."

package/templates/.agents/skills/zaip-skill-auth-tenancy/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: zaip-skill-auth-tenancy
+description: Design and verify identity, authorization, tenant isolation, and role propagation across application boundaries.
+---
+
+# Secure identity and tenancy
+
+Use for login, roles, accounts, organizations, authorization, or tenant-scoped resources.
+
+1. Discover the project tenant naming and trace identity from authenticated request to account context, API authorization, database query, queue payload, cache key, and storage policy. Read `references/data-access-paths.md` before deciding Supabase policy is effective.
+2. Define permitted actions and ownership rules before route or policy changes. Never infer tenancy from a request parameter alone.
+3. Direct Kysely application and worker roles must be non-`BYPASSRLS`; isolate migration or break-glass administration in a separately selected privileged role that normal runtime paths cannot assume.
+4. Keep authorization decisions near application use cases and database policy as a defense-in-depth boundary. For an async worker, validate a versioned payload then re-authorize actor, tenant membership, and action in a fresh transaction, or document and validate authorization-snapshot semantics.
+5. Test observed role attributes, allowed access, denied access, and cross-tenant attempts through the effective application connection and relevant Supabase policy. Fail if the runtime role has `BYPASSRLS`, if a forged/missing/stale/mismatched job payload mutates state, or if tenant A state reaches a subsequent tenant B job.
+6. Redact tokens and identity claims from artifacts and logs; record only the minimum evidence needed. Use `references/worker-scenario.md` for the minimum forward-use proof.

package/templates/.agents/skills/zaip-skill-auth-tenancy/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Auth and Tenancy"
+  short_description: "Verify identity, roles, and tenant isolation"
+  default_prompt: "Use $zaip-skill-auth-tenancy to design authorization and tenant isolation for this flow."

package/templates/.agents/skills/zaip-skill-auth-tenancy/references/data-access-paths.md

@@ -0,0 +1,9 @@
+# Data access paths
+
+Discover whether the application uses the Supabase Data API or a direct PostgreSQL connection through Kysely. Data API requests can propagate the authenticated JWT to Row Level Security; direct Kysely connections normally do not. For direct access, set a transaction-local tenant or role context through a reviewed adapter and verify reset at pool release.
+
+Read `rolbypassrls`, superuser status, and tenant-table ownership for the exact application and worker connections. Runtime roles must have `rolbypassrls = false`, be non-superuser, and not own tenant tables. Where ownership is unavoidable, use `FORCE ROW LEVEL SECURITY` and prove enforcement through the effective application or worker path. A privileged migration or admin role may have elevated access only when it is isolated from normal app and worker credentials, composition roots, pools, and job paths.
+
+This role behavior follows [PostgreSQL Row Security §5.9](https://www.postgresql.org/docs/current/ddl-rowsecurity.html).
+
+Test the actual query path with a normal runtime role, a deliberately rejected `BYPASSRLS` role, and reused pooled connections. A proof must show tenant A cannot read or mutate tenant B after a prior tenant A request, including a worker or job path. Do not treat a browser JWT test as proof for a direct database connection.

package/templates/.agents/skills/zaip-skill-auth-tenancy/references/worker-scenario.md

@@ -0,0 +1,5 @@
+# Worker forward-use scenario
+
+Queue a version `1` action for tenant A and actor A. The worker validates schema and version, loads membership and permission in a new transaction, then writes only tenant A state. Immediately process tenant B with a different actor and assert that no tenant A context, rows, cache key, or authorization decision is reused.
+
+Repeat with a missing actor, forged tenant, stale membership, unsupported version, a runtime role with `rolbypassrls = true`, a superuser, or a tenant-table owner without `FORCE ROW LEVEL SECURITY`. Each case must be rejected before mutation. The test fails if any denied case writes data or if effective-path enforcement is absent for normal application or worker roles.

package/templates/.agents/skills/zaip-skill-auth-tenancy/scripts/worker-contract.test.mjs

@@ -0,0 +1,27 @@
+import assert from "node:assert/strict";
+import { readFile } from "node:fs/promises";
+import { resolve } from "node:path";
+import test from "node:test";
+
+const root = resolve(import.meta.dirname, "..");
+test("tenancy guidance requires non-bypass runtime roles and worker reauthorization", async () => {
+  const [skill, paths, scenario] = await Promise.all(
+    ["SKILL.md", "references/data-access-paths.md", "references/worker-scenario.md"].map((path) =>
+      readFile(resolve(root, path), "utf8"),
+    ),
+  );
+  const source = `${skill}\n${paths}\n${scenario}`;
+  for (const requirement of [
+    "non-`BYPASSRLS`",
+    "rolbypassrls",
+    "non-superuser",
+    "tenant tables",
+    "FORCE ROW LEVEL SECURITY",
+    "fresh transaction",
+    "forged",
+    "tenant A",
+    "tenant B",
+    "before mutation",
+  ])
+    assert.ok(source.includes(requirement));
+});

package/templates/.agents/skills/zaip-skill-author-skills/SKILL.md

@@ -19,4 +19,6 @@ description: Create and audit portable ZAIP skills, triggers, resources, and rel
 10. Valide links relativos, encoding UTF-8, placeholders, tamanho, políticas de invocação, triggers sobrepostos e comandos citados.
 11. No framework source, rode `pnpm sync:framework-lock`, validação, testes relevantes, sync do template público, build e parity; no consumer, rode somente validação da skill, `zaip doctor` e adapters aplicáveis.
 
+Para orientar uma pessoa entre skills de engenharia, consulte `references/engineering-skill-index.md`.
+
 Não copie paths pessoais, portas, credenciais, integrações específicas do projeto ou runners inexistentes para uma skill core.

package/templates/.agents/skills/zaip-skill-author-skills/references/engineering-skill-index.md

@@ -0,0 +1,9 @@
+# Engineering skill index
+
+Use `architecture-design` before a cross-module capability; `dev-environment` for checkout prerequisites; and `module-scaffold` for a minimal owned module. Use `data-modeling`, `database-migrations`, and `auth-tenancy` before persistent tenant data changes.
+
+Use `api-contracts`, `async-jobs`, `cache-strategy`, `external-integrations`, `storage-uploads`, and `frontend-data-flows` for their named runtime boundaries. Use `testing-strategy`, `test-data`, `systematic-debugging`, `performance-engineering`, and `dependency-upgrade` for verification and maintenance.
+
+Use `container-runtime`, `deployment-pipeline`, `application-observability`, `disaster-recovery`, and `application-readiness` for application operations. These skills assess or prepare their domain; they do not authorize deployment, production mutation, or lifecycle approval.
+
+Use [github-actions-setup](../../zaip-skill-github-actions-setup/SKILL.md) for guided GitHub Actions onboarding: npm trust/tokens, Cloudflare Pages credentials or Hostinger VPS SSH, exact secret names, workflows and end-to-end verification. Use `github-deploy` for an explicitly requested GitHub publication; installing the setup skill does not activate any pipeline.

package/templates/.agents/skills/zaip-skill-author-skills/scripts/audit-skill-catalog.mjs

@@ -9,9 +9,8 @@ const skillDirectories = (await readdir(skillsRoot, { withFileTypes: true }))
   .map((entry) => entry.name);
 const knownSkills = new Set(skillDirectories);
 const errors = [];
-const catalog = parseYaml(
-  await readFile(resolve(root, ".agents/config/agents/catalog.yaml"), "utf8"),
-);
+const catalogPath = process.argv[2] ?? resolve(root, ".agents/config/agents/catalog.yaml");
+const catalog = parseYaml(await readFile(catalogPath, "utf8"));
 
 for (const agent of catalog.agents ?? []) {
   for (const skill of agent.skills ?? []) {
@@ -20,8 +19,11 @@ for (const agent of catalog.agents ?? []) {
 }
 for (const [agentId, requiredSkill] of [
   ["agent-frontend", "zaip-skill-frontend"],
+  ["agent-frontend", "zaip-skill-frontend-componentization"],
   ["agent-backend", "zaip-skill-backend"],
   ["agent-designer", "zaip-skill-design-system"],
+  ["agent-designer", "zaip-skill-frontend-componentization"],
+  ["agent-website-developer", "zaip-skill-frontend-componentization"],
 ]) {
   const agent = (catalog.agents ?? []).find((entry) => entry.id === agentId);
   if (!agent?.skills?.includes(requiredSkill))

package/templates/.agents/skills/zaip-skill-author-skills/scripts/author-skill-scripts.test.mjs

@@ -1,8 +1,11 @@
 import assert from "node:assert/strict";
 import { execFile } from "node:child_process";
+import { mkdtemp, readFile, rm, writeFile } from "node:fs/promises";
+import { tmpdir } from "node:os";
 import { resolve } from "node:path";
 import test from "node:test";
 import { promisify } from "node:util";
+import { parseDocument, stringify } from "yaml";
 
 const run = promisify(execFile);
 const root = resolve(import.meta.dirname, "..", "..", "..", "..");
@@ -25,3 +28,27 @@ test("skill catalog audit validates the checked-in catalog and technical contrac
   });
   assert.match(stdout, /Audited \d+ skills and \d+ agents/);
 });
+
+test("skill catalog audit rejects missing componentization bindings by agent id", async () => {
+  const temporary = await mkdtemp(resolve(tmpdir(), "zaip-skill-audit-"));
+  const catalog = resolve(temporary, "catalog.yaml");
+  try {
+    const source = await readFile(resolve(root, ".agents/config/agents/catalog.yaml"), "utf8");
+    const parsed = parseDocument(source).toJS();
+    const requiredAgents = ["agent-frontend", "agent-designer", "agent-website-developer"];
+    for (const agentId of requiredAgents) {
+      const agent = parsed.agents.find((entry) => entry.id === agentId);
+      assert.ok(agent, `expected ${agentId} in the catalog fixture`);
+      agent.skills = agent.skills.filter(
+        (skill) => skill !== "zaip-skill-frontend-componentization",
+      );
+    }
+    await writeFile(catalog, stringify(parsed));
+    await assert.rejects(
+      run(process.execPath, [resolve(scripts, "audit-skill-catalog.mjs"), catalog], { cwd: root }),
+      /agent-frontend: must load zaip-skill-frontend-componentization[\s\S]*agent-designer: must load zaip-skill-frontend-componentization[\s\S]*agent-website-developer: must load zaip-skill-frontend-componentization/,
+    );
+  } finally {
+    await rm(temporary, { force: true, recursive: true });
+  }
+});

package/templates/.agents/skills/zaip-skill-backend/SKILL.md

@@ -9,3 +9,7 @@ description: Implement backend APIs, persistence, and integration boundaries ins
 2. Preservar a direção de dependências e manter detalhes de infraestrutura atrás da fronteira do módulo.
 3. Aplicar arquitetura e CQRS proporcionalmente ao contrato alterado: não introduzir camadas, migrações ou gates pesados quando a mudança local não os exige. Cobrir o comportamento alterado com testes focados e registrar incompatibilidades, migrações ou riscos de integração.
 4. Aplicar [o contrato de prova observável](../zaip-skill-change/references/observable-evidence.md): metadados para estrutura/migração, fluxo autorizado e registros específicos para persistência, logs correlacionados para correções e observação direta de API/fila/cache/integração. SQL não é obrigatório quando inaplicável. Correlacionar UI e backend quando o AC exigir o fluxo completo; registrar ambiente, versão, limitações e fallback finito sem expor dados sensíveis.
+5. Para uma fronteira recorrente, carregue somente a especialização pertinente: `$zaip-skill-api-contracts`, `$zaip-skill-database-migrations`, `$zaip-skill-auth-tenancy`, `$zaip-skill-async-jobs`, `$zaip-skill-cache-strategy` ou `$zaip-skill-external-integrations`.
+6. Para Supabase, migrações, branch de deploy ou consultas de ambiente, aplicar o [contrato de ambientes e acessos](references/deployment-environments.md). READ-ONLY-BETA e READ-ONLY-PROD são consultas separadas; migrations de banco são beta-only, enquanto backend segue `deploy.backend.branch`, inclusive `main` quando configurada.
+7. Quando uma mudança de persistência exigir schema Supabase em repositório separado, prepare a proposta e valide o [contrato de migrations](references/supabase-migration-contract.md) com `zaip supabase migration plan`. Use `prepare`/`submit` para o pedido revisável; ele identifica o `owner/repository` solicitante e não aplica SQL. A execução no repositório de banco segue a autorização e as regras daquele repositório. `deploy.database.branch` não admite `main` nem fallback de produção: sem beta configurada, informe o bloqueio e não provisione uma branch hospedada ou integração automaticamente. Depois da promoção humana, `zaip supabase migration validate --evidence PATH` separa a SHA e os checks candidatos da observação `trust: unverified` do histórico de migrations. Grants, RLS e exposição Data API exigem evidências próprias e a Data API permanece opt-in.
+8. Se o usuário recusou explicitamente a beta hospedada, siga o [modo manual](../zaip-skill-database-migrations/references/manual-mode.md). Ele exporta a migration futura para `/db-migrations/YYYY-MM-DD-HH-mm-nome.sql`; uma pessoa a executa no Supabase SQL Editor e o trabalho dependente aguarda a evidência humana do resultado.

package/templates/.agents/skills/zaip-skill-backend/references/deployment-environments.md

@@ -0,0 +1,75 @@
+# Ambientes de deploy e acesso Supabase
+
+Este contrato separa validação e produção para qualquer projeto ZAIP-AIOS. Ele orienta agentes, mas não substitui as proteções do GitHub, do provedor de deploy ou do Supabase.
+
+## Branches e promoção
+
+- `deploy.frontend.branch` e `deploy.backend.branch` são autorizações persistidas de publicação para cada aplicação. O padrão é `beta`; se o usuário configurar `main`, a publicação da aplicação pode seguir para `main` sem nova confirmação.
+- `deploy.database.branch` é literalmente `beta`. Banco nunca herda `deploy.branch`, frontend ou backend, e nunca faz fallback para `main`.
+- `deploy.branch` é legado e serve exclusivamente ao release/npm do framework.
+- `deploy.production_branch` é a branch de produção. O padrão é `main`.
+- Banco de dados nunca faz deploy automatizado para `main`. Frontend e backend seguem seus campos próprios, inclusive `main` quando foi configurado pelo usuário.
+- Produção exige promoção humana por PR/merge, com as proteções e aprovações definidas no repositório remoto. A branch atual e o upstream local não decidem o destino.
+- Para um banco compartilhado, o repositório central de migrações é uma convenção documentada do projeto, não um campo implícito de `project.yaml`. Cada contribuição é integrada nele pela branch de validação configurada. Não se envia o histórico inteiro de outro repositório para esse destino.
+- Frontend e site publicam a própria versão de validação a partir da branch de validação. A promoção de seus ambientes de produção continua humana.
+
+## Configuração esperada
+
+```yaml
+deploy:
+  frontend: { branch: beta }
+  backend: { branch: beta }
+  database: { branch: beta }
+  branch: beta
+  production_branch: main
+```
+
+O nome `beta` é um padrão, não um requisito semântico. O mesmo valor configurado deve ser usado por preflight, workflow e provedor de hospedagem. Uma instalação legada que só tenha `deploy.branch: main` continua legível em runtime, mas o deploy automatizado fica bloqueado até que uma escolha segura seja registrada: uma branch de validação diferente da branch de produção.
+
+## READ-ONLY-BETA e READ-ONLY-PROD
+
+Os dois acessos são contextos distintos de consulta. O exemplo `.mcp.json` abaixo é para Claude Code ou outro cliente compatível; ele não é configuração nativa do Codex. Para Codex, use o exemplo `.codex/config.toml` seguinte. Ambos seguem o [MCP oficial do Supabase](https://supabase.com/docs/guides/getting-started/mcp) e são placeholders: eles **não criam uma conexão autenticada**, não incluem segredo e não concedem acesso por si mesmos.
+
+`.mcp.json` para Claude Code ou cliente compatível, com os dois servidores no mesmo arquivo:
+
+```json
+{
+  "mcpServers": {
+    "supabase-read-only-beta": {
+      "type": "http",
+      "url": "https://mcp.supabase.com/mcp?project_ref=<BETA_PROJECT_REF>&read_only=true&features=database,docs"
+    },
+    "supabase-read-only-prod": {
+      "type": "http",
+      "url": "https://mcp.supabase.com/mcp?project_ref=<PROD_PROJECT_REF>&read_only=true&features=database,docs"
+    }
+  }
+}
+```
+
+`.codex/config.toml` para Codex, com os dois servidores:
+
+```toml
+[mcp_servers.supabase-read-only-beta]
+url = "https://mcp.supabase.com/mcp?project_ref=<BETA_PROJECT_REF>&read_only=true&features=database,docs"
+enabled = true
+
+[mcp_servers.supabase-read-only-prod]
+url = "https://mcp.supabase.com/mcp?project_ref=<PROD_PROJECT_REF>&read_only=true&features=database,docs"
+enabled = true
+```
+
+Antes de habilitar qualquer um deles, confirme todos os pontos abaixo:
+
+1. O parâmetro `project_ref` está definido para os dois ambientes e os valores são distintos.
+2. A credencial de consulta tem somente as permissões mínimas de leitura e é diferente da credencial usada pelo pipeline de migração/deploy.
+3. A identidade do pipeline só é disponibilizada ao pipeline do ambiente correspondente; ela não é compartilhada com o agente de consulta.
+4. Os manifests e políticas do MCP permitem somente `database` e `docs` no contexto read-only, sem ferramentas de escrita, DDL, migração ou deploy.
+
+Se faltar uma referência, se as duas referências forem iguais, ou se a capacidade read-only não puder ser demonstrada, o estado é **não configurado**. Não há fallback de beta para produção, de produção para beta, nem para um projeto padrão. O agente deve relatar a lacuna e parar a consulta dependente, sem inferir o destino ou usar credenciais de pipeline.
+
+## Operação de banco compartilhado
+
+Vários repositórios podem propor mudanças para o repositório central de banco. Cada mudança deve ter uma migração própria, ordenada e revisável, com testes executados em validação antes da promoção humana. O PR inclui `[owner/repo]`, SHA de origem e ID estável para deduplicação. A integração deve ser serializada quando houver dependência ou conflito de schema. O agente pode consultar READ-ONLY-BETA e READ-ONLY-PROD para diagnóstico autorizado, mas não aplica DDL, dados ou migrações com essas identidades. A branch beta persistente pode gerar custo no Supabase; instalação/configuração não a cria, e qualquer provisionamento exige confirmação informada separada.
+
+Após uma recusa explícita da beta, o [modo manual](../../zaip-skill-database-migrations/references/manual-mode.md) é o único caminho alternativo: SQL futuro é exportado no repositório solicitante, uma pessoa o executa no SQL Editor e confirma o resultado antes de liberar dependências. Não há fallback de deploy nem criação de custo.

package/templates/.agents/skills/zaip-skill-backend/references/supabase-migration-contract.md

@@ -0,0 +1,23 @@
+# Contrato de migrations Supabase
+
+O ZAIP-AIOS pode coordenar a entrega de frontend e backend no mesmo repositório. Quando a mudança exige schema, ela produz uma proposta de migration para o repositório de banco configurado; este contrato não executa SQL, não edita o repositório de banco e não publica commits.
+
+Ative o contrato copiando os valores abaixo para `supabase_migrations` em `.agents/config/project.yaml`. O caminho é absoluto e local de propósito: cada consumidor informa sua própria cópia de `zaip-db-supabase`; não inclua caminhos pessoais no template distribuído.
+
+```yaml
+supabase_migrations:
+  repository:
+    id: zaip-db-supabase
+    path: C:/workspace/zaip-db-supabase
+    origin: git@github.com:zaip-ai/zaip-db-supabase.git
+    branch: beta
+  hosted_applicator: github-integration
+```
+
+`zaip supabase migration plan --json` confirma a identidade, caminho, origin e branch. `zaip supabase migration validate --evidence .agents/evidence/migration.json --json` também exige uma migration catalogada e rastreada, SHA candidato igual ao `HEAD` limpo de `beta`, checks passados e uma observação separada do histórico de migrations do Supabase. A observação local declara `trust: unverified`: ela é evidência reportada, não uma confirmação remota por esta CLI.
+
+Git registra arquivos de migration; o Supabase mantém separadamente as versões aplicadas. O GitHub Integration é o único aplicador hospedado automatizado autorizado e só aplica arquivos pendentes. No modo manual, uma pessoa pode executar o SQL exportado no SQL Editor após recusar explicitamente a beta hospedada. Um SHA enviado ou presente em `beta` nunca prova que a migration foi aplicada. Grants, RLS e alcance da Data API são evidências independentes; a exposição na Data API continua opt-in.
+
+A CLI também lê `refs/remotes/origin/beta` sem executar `fetch`, push ou outra operação remota. Mesmo quando essa ref coincide com a SHA candidata, ela é uma observação local que pode estar desatualizada. Por isso `validate` permanece pendente com `origin-beta-unverified`; a confirmação de publicação depende de uma observação externa fresca e autorizada.
+
+`zaip tool copy --task TASK --run RUN` resolve os escopos canônicos de uma Task ativa vinculada à Run e usa o guard antes de escrever, incluindo a resolução física de symlinks. Ele protege apenas esta API controlada do ZAIP. Prompts, `apply_patch`, shell do host e permissões de sandbox não fornecem por si só isolamento de escrita no nível do sistema operacional.

package/templates/.agents/skills/zaip-skill-brand-governance/SKILL.md

@@ -36,3 +36,5 @@ Use as referências para montar ou enriquecer a plataforma e pergunte somente pe
 5. Não gere imagens, mockups ou outros ativos visuais sem solicitação explícita.
 
 Consulte [padrões de Brandbook](references/brandbook-standards.md) e o [framework de domínios](references/brandbook-framework.md) ao estruturar entregáveis internos ou externos.
+
+Para aplicar conteúdo já aprovado em uma entrega editorial simples, delimitada e de baixo impacto, use o [perfil editorial `lite`](../zaip-skill-task/SKILL.md#assurance-proporcional) e selecione `--risk lite`. Ele não se aplica à criação ou mudança estratégica de plataforma, identidade, arquétipo ou Brandbook.

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

@@ -0,0 +1,14 @@
+---
+name: zaip-skill-cache-strategy
+description: Design safe Redis cache keys, lifetime, invalidation, tenant isolation, and degradation behavior.
+---
+
+# Design caching
+
+Use before adding or changing Redis caching. It does not govern BullMQ job semantics.
+
+1. State the source of truth, cached representation, key namespace, tenant identity, TTL, invalidation trigger, and staleness tolerance.
+2. Never share account-scoped values across tenants or use cached authorization as the only access control.
+3. Design for cache miss, eviction, unavailability, and concurrent regeneration without corrupting source data.
+4. Measure or test hit/miss behavior, write invalidation, expiration, and degraded operation.
+5. Keep Redis server assumptions separate from the client package version declared in the stack.

package/templates/.agents/skills/zaip-skill-cache-strategy/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Cache Strategy"
+  short_description: "Design Redis cache isolation and invalidation"
+  default_prompt: "Use $zaip-skill-cache-strategy to define caching behavior for this data flow."

package/templates/.agents/skills/zaip-skill-change/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: zaip-skill-change
-description: Maintain Change narrative, decisions, evidence, rollback, and results.
+description: Maintain a materialized Change's decisions, evidence, rollback, and observed result.
 ---
 
 # Manter a Change

package/templates/.agents/skills/zaip-skill-cloud-engineering/SKILL.md

@@ -5,6 +5,13 @@ description: Design, provision, and validate infrastructure as code inside decla
 
 # Engenharia de cloud
 
+Para uma pessoa começando uma VPS/Hostinger, conduza primeiro o [guia inicial de VPS e Terraform](../zaip-skill-hostinger-cloudflare-terraform/references/guia-iniciante-hostinger-vps.md). Faça no máximo três perguntas simples e avance uma etapa por vez: objetivo, ação humana, ação do Codex, resultado observável e retomada segura. O guia não autoriza compra, SSH, API, Terraform apply ou deploy.
+
 1. Delimitar ambiente, recurso, provider, estado atual e rollback antes da mudança.
 2. Preferir infraestrutura declarativa e revisável; não aplicar deploy, credenciais ou mudança externa sem autorização explícita.
 3. Validar sintaxe, plano ou build aplicável e registrar impacto, dependências e caminho de reversão.
+4. Para AWS, exigir `account_id`, região e profile explícitos. SSO é preferível: preparar com `aws configure sso`, autenticar com `aws sso login --profile PERFIL` e confirmar com `aws sts get-caller-identity --profile PERFIL --region REGIAO`. Profile existente, OIDC ou role já autorizada também são válidos quando a identidade STS corresponde ao contrato; nunca assumir que o profile padrão é o alvo.
+5. Quando a execução usar role, validar ARN, conta destino e sessão limitada. Preferir profile AWS com `role_arn` e `source_profile` ou OIDC; se `aws sts assume-role` for inevitável, não imprimir nem persistir seu stdout. A identidade que acessa o backend Terraform pode ser diferente da identidade/role do provider: declarar, autenticar e verificar cada uma separadamente.
+6. Para state remoto AWS, usar backend S3 com bucket e key aprovados, região explícita, `encrypt = true` e `use_lockfile = true` em Terraform >= 1.10. Versionamento, IAM mínimo e recuperação do bucket são requisitos do ambiente; não use DynamoDB para novo locking.
+7. Nunca rastrear segredos em `backend-config`, state, planos binários/JSON ou credenciais; configuração de backend sem segredos pode ser versionada. Durante preparação executar `terraform init`, `fmt`, `validate` e `plan` revisável. A Task AWS ativa e explicitamente autorizada pode cobrir bootstrap e provisionamento com AWS CLI/Terraform somente sob contrato AWS delimitado e plano salvo revisado; `apply` consome exclusivamente aquele plano.
+8. Para aplicações, mantenha containers de API e worker separados de assets estáticos de Vite/Astro; use `$zaip-skill-container-runtime`, `$zaip-skill-application-observability` e `$zaip-skill-disaster-recovery` conforme a fronteira alterada.

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

@@ -0,0 +1,37 @@
+---
+name: zaip-skill-cloudflare-github-deploy
+description: Configure and review GitHub Actions deployments to Cloudflare Workers Static Assets or Pages when a repository needs automatic Cloudflare delivery.
+---
+
+# Deploy Cloudflare via GitHub
+
+Use for an authorized change that creates or changes a GitHub Actions workflow which deploys a built application to Cloudflare. It configures delivery; it does not authorize a push, a provider deployment, credential exposure, DNS changes, or Cloudflare account changes.
+
+## Choose the target
+
+1. Read the repository's `deploy.frontend.branch` or `deploy.backend.branch`, package manifest, lockfile, build output, and existing `wrangler` configuration before writing. The persisted application branch may be `main`; database migrations never use this workflow and remain beta-only. Follow the shared [environment and read-only contract](../zaip-skill-backend/references/deployment-environments.md).
+2. Select **Workers Static Assets** when existing Worker configuration uses static assets, whether it has Worker code or is pure static. Select **Pages** when existing Pages configuration is the target; Pages can also use Functions. Declare one deployment owner: either this workflow or the provider's Git integration, never both.
+3. Start from the matching [workflow template](references/workflow-templates.md). Keep repository-root install, package filter/build location, application deployment cwd, lockfile, build output, and Cloudflare project or Worker identifier distinct. Resolve `wrangler` config paths relative to its deployment cwd. Never copy account IDs, domains, routes, email addresses, project names, or secret values from another repository.
+
+## Workflow contract
+
+- The workflow uses `push` on `deploy.branch`, `workflow_dispatch`, least-privilege `permissions: { contents: read }`, and one concurrency group with `cancel-in-progress: true`. Its deploy job accepts either trigger only when `github.ref` is the configured validation branch, rejecting `main`, the configured production branch, and every other ref.
+- A Workers workflow deploys an explicit validation environment and target; it never falls through to Wrangler's default production environment. A Pages workflow publishes a preview branch equal to `deploy.branch`, which must differ from `deploy.production_branch`; production stays a human promotion.
+- Pin actions to reviewed immutable commit SHAs and pin Node, the package-manager release, and Wrangler. A floating major reference such as `@v4` is only a review-time convenience, never a final deployment reference. Install with the declared frozen-lock option (`pnpm --frozen-lockfile`, `npm ci`, or equivalent).
+- Keep bundled public variables (for example, `VITE_*`) separate from runtime secrets; a public build variable is never a server secret. Pass only the scoped Cloudflare API-token secret and account identifier to the deployment command; put runtime secrets in the Cloudflare target's secret store through a separately authorized operation.
+- Default to a scoped `CLOUDFLARE_API_TOKEN` with only the deployment permissions required by the selected account and target. Accept `CLOUDFLARE_API_KEY` plus email only when the Task explicitly selects a documented legacy mode. If a separately authorized operation needs a local credential, follow `$zaip-skill-local-credentials` and pass it only to the minimal authorized subprocess; never expose, migrate, or automatically reauthorize it.
+- In a monorepo, install from the workspace root, run the app's package filter/build command from its declared location, and deploy from the application cwd. Optional filters include root lockfiles, workspace manifests, shared packages, and the workflow itself whenever they affect the selected application.
+
+## Workers Static Assets
+
+Read [the Workers configuration contract](references/workers-static-assets.md) before creating its `wrangler` file. Its configuration must explicitly decide `main`, `assets.directory`, an assets `binding`, SPA fallback, and optional `run_worker_first`; `_redirects` is supported for asset routing. Do not invent a Worker entrypoint when the project is only Pages-compatible.
+
+## Verify and hand off
+
+1. Render the workflow from repository facts, validate YAML locally, and run the repository build with a frozen install when dependencies are available. Use `wrangler deploy --dry-run` only when it is supported for the selected target and does not require credential inspection; it is not a deployment claim.
+2. After an authorized push and provider deploy, collect the exact GitHub run URL/SHA, selected target, and Cloudflare deployment URL or version as remote evidence. A green build alone does not prove publication.
+3. Document the rollback before enabling delivery: redeploy the prior known-good Git SHA or Cloudflare version through the same single owner, then verify the target. Do not execute rollback without authorization.
+
+## Sources and comparison
+
+Use the current [setup-node cache guidance](https://github.com/actions/setup-node), [Workers Static Assets guide](https://developers.cloudflare.com/workers/static-assets/get-started/), and [Pages Functions guide](https://developers.cloudflare.com/pages/functions/) when a provider detail changes. The local `zaip-ai` comparison workflow last changed at `f11bea0ed58978763c2a604060c73ab43a7719d1`; separately, [GitHub Actions run 34074776525](https://github.com/zaip-ai/zaip-ai/actions/runs/34074776525) succeeded for SHA `81c602ded4a45bd9174ccc22279981b9fd34a57d`.

package/templates/.agents/skills/zaip-skill-cloudflare-github-deploy/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "Cloudflare via GitHub"
+  short_description: "Configura CI Cloudflare segura e verificavel"
+  default_prompt: "Use $zaip-skill-cloudflare-github-deploy para criar ou revisar um workflow GitHub Actions para Cloudflare Workers Static Assets ou Pages."
+policy:
+  allow_implicit_invocation: true