@zaip-ai/cli 6.2.0 → 7.5.0

package/templates/.agents/skills/zaip-skill-release-qualification/SKILL.md

@@ -5,7 +5,9 @@ description: Qualify a release candidate after deploy mode resolution or an expl
 
 # Qualify a release candidate
 
-For new release evaluations, use the versioned binary `proportional-acceptance-v1` contract in `@zaip-ai/specs` and `docs/quality/production-readiness.md` through `zaip plan acceptance --input <contract.json>`. This command only checks self-reported data and never authorizes publication; authenticated pipeline receipts remain the gate. Map each mandatory outcome to its origin, applicability, sufficient proof, owner and stop condition; bind release proof to the exact candidate. Optional improvements do not block. The historical technical grade remains informative and unchanged. Local qualification uses the declared Windows host; the GitHub Linux smoke is a remote publication check. Do not require local Docker, WSL or another OS by inference.
+Resolve the committed builder validation policy first. Standard releases selecting `github_actions` follow [remote validation](references/remote-validation.md). An explicitly authorized `local_catalog` policy follows [complete local validation](references/local-catalog.md): the same complete catalog, coverage ratchet and exact-package Linux/Windows matrix, with a separate signed receipt. It supersedes the Actions-only publisher requirement below for this route. The reduced historical profiles cannot substitute for it. Consumers do not inherit builder CI policy.
+
+For new release evaluations, use the versioned binary `proportional-acceptance-v1` contract in `@zaip-ai/specs` and `docs/quality/production-readiness.md` through `zaip plan acceptance --input <contract.json>`. This command only checks self-reported data and never authorizes publication; authenticated pipeline receipts remain the gate. Map each mandatory outcome to its origin, applicability, sufficient proof, owner and stop condition; bind release proof to the exact candidate. Optional improvements do not block. The historical technical grade remains informative and unchanged. The committed qualification policy determines the host matrix: `local-catalog-v1` requires Linux and Windows locally; routes that explicitly select Windows with a remote Linux smoke retain that separate boundary. Do not require Docker, WSL or another OS by inference, or discard an OS expressly required by the selected policy.
 
 Use after `$zaip-skill-github-deploy` resolves release mode, or when local preparation/qualification is explicitly requested. Resolve deploy mode first using [the deployment contract](../zaip-skill-github-deploy/references/deployment-workflow.md). Generic consumer deploy under auto and explicit commits mode use scoped checks and `guarded-commits.mjs`; they do not acquire a release gate from this skill.
 
@@ -42,6 +44,13 @@ the skipped minor. Freeze and all distribution gates still apply.
 
 Local builder preparation defaults to signed `essential-v3`: deterministic source/lock/parity, build/type integrity, dependency audit, prioritized installer/rollback/release regressions, package/SBOM/TGZ binding and one clean installed-consumer doctor/SQLite/API smoke.
 
+Both root and public CLI lint are mandatory early gates after their installations,
+before workflow contracts and builds. The public parity preflight follows public
+lint. Partial rapid passes may survive a later group failure only after the runner
+revalidates candidate, policy inputs, toolchain and installation; the overall run
+still fails and failed/interrupted groups remain ineligible. This does not reuse a
+signed release receipt across changed candidates or waive any required gate.
+
 These dense distribution checks are release gates. Change validation outside release remains targeted, with installer/security checks selected when directly impacted. Do not automatically run the full suite for generic commits, impose a test-count ceiling or classify a Task by wallclock duration.
 
 For a multi-Task delivery, verify changed code and affected dashboard flows by
@@ -52,6 +61,17 @@ valid; later changes revalidate affected proof.
 
 Use `--profile full` for explicitly requested extended `full-v2` qualification, including full source, browser and XLSX coverage. Changed dashboard/export behavior still needs its relevant tests in the current Change. Rapid impact checks emit no signed release receipt and cannot substitute for release qualification.
 
+A verified signed receipt may additionally cover explicitly enrolled complete suites
+with the same runner and configuration. Reuse requires the clean exact candidate,
+matching measured toolchain, installed dependency bytes and environment, trusted
+failure observations, and no unresolved failure or required baseline. Missing or
+non-equivalent measurements mean execution, never an inferred HIT. Each rapid
+group contains at most eight suite files, including signed groups whose reuse is
+vetoed later. This partitions retries without truncating the selected inventory.
+Install/upgrade policy tests may use verified minimal real-template fixtures;
+clean installation, runtime, package integrity and full-upgrade proofs retain the
+complete distributed payload. See docs/quality/v65-validation-cost-review.md.
+
 Post-receipt rapid group reuse follows `docs/quality/v49-deploy-cache-controls.md`. Only a reviewed Git-versioned group proof may yield a HIT; promote a failed result as the latest tombstone before retry. This never replaces signed candidate qualification.
 
 The framework helper uses an isolated exact-SHA clone, builds once, verifies the exact TGZ and signs a receipt. Cache validity requires matching candidate, policy, gate definitions, runtime, channel, version, trusted key, expiry and artifact digests. Failed/timed-out gates emit no successful receipt; changed candidates or invalid evidence require new qualification.
@@ -82,6 +102,11 @@ The framework release cut uses `node scripts/release-cycle-gate.mjs freeze --rep
 
 For an authorized Task-first request that combines a product fix and its release in one direct Task root, use the explicit `--integrated-task` freeze option with that Task and active root Run. The Task must be critical, target the current release, own the release-cycle config scope and have a delivery Execution bound to its Change. `audit` and `advance` authenticate its committed Task and Run start, while all other current-release work, secondary worktrees and remote branches still block. This route avoids creating a second root Run or asking the user for a new turn solely to publish already authorized work. Do not use it for a delegated SPEC release Task or as a general waiver for release checks.
 
+For authorized continuation of a blocked direct integrated Task while frozen,
+follow [frozen Task recovery](references/frozen-task-recovery.md). Preserve the
+same authenticated graph, prior terminal roots, autonomy ledger and writer data;
+never edit journals/grants or clean unrelated changes to force continuation.
+
 For an authorized SPEC whose final critical Task combines implementation and publication, use the separate explicit `--integrated-spec-task` option with its delegated delivery Run. It requires the exact active macro Run, SPEC, Change and delivery Execution, a unique terminal Task in the committed DAG, all predecessors completed, the current target release and the literal `.agents/config/release-cycle.json` write scope. The persisted `integrated_spec_task` mode is rechecked at audit and advance; unknown modes fail closed. It cannot be combined with `--integrated-task`, which remains exclusive to direct Task roots. Broad product scopes alone never grant this mode. Clean candidate, committed coordinator records, unrelated open-work exclusion, exact-SHA CI, signed artifact and npm gates remain mandatory.
 
 For the one-time 4.5→4.6 recovery, `adopt-published` requires the published 4.5 tag to be an ancestor of remote `main`, remote `main` to be an ancestor of clean local `main`, and observed stable GitHub Release/npm integrity. Pass the exact owner `--owner-spec`, `--owner-execution`, `--owner-run`, planned `--release-task` and active delegated Task orchestrator `--actor-run`. That actor must own the release Task's unique direct predecessor; all earlier DAG Tasks must be completed. Only the actor Task, planned release Task and owner SPEC are exempt from the open-work gate. After review/Evidence and a clean metadata checkpoint, perform adoption while that predecessor Task and its actor Run are still active. Then use `spec retarget-release SPEC --from 4.5 --to 4.6 --run DELEGATED_TASK_RUN` with the same actor Run. Close the predecessor Task through Gui only after retarget; start the release Task afterward. The revision records adoption SHA and actor Run, and the release Task's missing target resolves through its owner SPEC. Do not edit records directly to retarget.

package/templates/.agents/skills/zaip-skill-release-qualification/references/frozen-task-recovery.md

@@ -0,0 +1,47 @@
+# Frozen Task recovery
+
+A blocked direct integrated Task whose release is still frozen can resume through
+`conversation start --intent continue --task TASK --execution EXEC --direct-authorization TEXT`.
+By default the new observed human turn belongs to the same native principal
+thread as the old terminal root, whose independent finalizer recorded blocked.
+For a different native chat in the same registered repository, pass the exact
+terminal coordinator as `--from-run RUN` and the new human release instruction
+(for example, `Faça o deploy da v7.5 neste chat`) as `--direct-authorization`.
+The handoff verifies the original maintainer's GitHub account online, native
+human provenance, release version, blocked graph and exclusive ownership.
+A different clone still needs reconciliation of its own canonical graph.
+Publication authority, writer transfer and exact-candidate qualification are
+checked separately. Task, Change and
+Execution must match the frozen coordinator. The CLI journals canonical pre/post
+images, reserves one successor Run, and updates only the coordinator Run plus its
+recovery history after exact snapshot checks. It keeps the cycle frozen, original
+history, previous roots, plan and autonomy ledger. After an interrupted write,
+repeat the same intake in the same turn: the journal reconciles observed state.
+Concurrent divergence blocks; never edit the journal, reset grants or reopen a
+terminal Run manually. Generic Task starts/resumes remain blocked by the freeze.
+Then run `task workspace TASK --run SUCCESSOR --json`. The shared writer may
+continue the same authenticated Task-first delivery without cleaning product
+files or the index; it preserves the original base and journals the ownership
+change. Different Tasks retain the clean-transfer gate. A divergent journal,
+active prior owner or unrelated authority blocks instead of discarding work.
+
+## Qualification boundary after a resumed coordinator
+
+A frozen resume authorizes the same delivery; it does not extend an existing
+exact-SHA qualification to changed Task or Run records. Publication reports
+`RELEASE_COORDINATOR_CANDIDATE_CHANGED` before assurance replay when its current
+coordinator differs from the qualified candidate. This is not a retryable
+publication failure. Preserve the original candidate, receipt and artifacts.
+
+Checkpoint the authorized current history and active coordinator through the
+Task commit flow, then qualify the new candidate. Evaluate evidence reuse with
+the existing resolver; do not relabel old result SHAs or assume that a
+metadata-only commit preserves the signed tree. Complete qualification and
+publication in the active attempt when possible. If another native turn is
+required, resolve this boundary again before running expensive qualification.
+
+An unsigned local recovery journal is a transaction locator, not independent
+proof of publication authority. Do not admit its paths into publication or
+closure merely because its hashes agree. Historical succession additionally
+requires authenticated human and Gui sources and canonical transition replay;
+without those proofs, use the new-candidate path above.

package/templates/.agents/skills/zaip-skill-release-qualification/references/local-catalog.md

@@ -0,0 +1,136 @@
+# Complete local builder qualification
+
+This is a separately authorized maintainer protocol, selected by committed
+`.github/ci-validation.json` schema 2, mode `local_catalog`, profile
+`local-catalog-v1`. It does not register a self-hosted Actions runner, alter
+billing, or inherit a successful CI identity. Reduced historical profiles cannot
+authorize it. The human contract Decision remains linked to the release Task.
+
+Use two detached, isolated checkouts of the same committed candidate: Linux and
+Windows, Node 24.19.0 and pnpm 11.13.1. WSL2 Linux is acceptable when genuinely
+available; installation must not restart the user's computer. Execute the full
+release catalog and all registered unit files without dropping skipped/failing
+cases. Existing case allowlists remain unchanged. Limit concurrency to the
+committed maximum; one sequential worker on each OS stays within a limit of two.
+
+Prepare the browser system libraries and `xvfb-run` on Linux before qualification,
+using Playwright's `install-deps chromium` on the isolated environment. Run tests
+as a non-root user with the browser sandbox enabled. The controller wraps Linux
+browser shards in Xvfb. Install pnpm 11.13.1 in the host tool directory and set
+`ZAIP_PNPM_CLI` to its absolute `bin/pnpm.cjs` or `bin/pnpm.mjs` entrypoint when it
+is not beside the selected Node runtime. Its actual version is verified before
+use; root `packageManager` alone is not an installed package-manager binary.
+Put the selected Node and the pinned package-manager launcher on PATH, so package
+scripts use that same runtime. These prerequisites carry no publishing secrets.
+
+The committed `scripts/local-catalog-controller.mjs` has explicit phases:
+
+1. `init --session FILE --sha SHA` allocates a local UUID, canonical private report
+   directory and owned `.local/temp/releases` cache. The result prints the durable
+   session path; use it to resume. Explicit `--output DIRECTORY` remains a legacy
+   compatibility route and never makes that existing directory disposable.
+2. `linux-prepare --session FILE` installs locked dependencies, creates the release
+   plan, builds once, authenticates the prepared archive, packs the exact TGZ and
+   runs static/audit gates before either host starts dense test suites.
+3. Copy the plan, session identity, prepared workspace archive/metadata and packed
+   artifacts to the Windows checkout without rebuilding. Adjust only the session
+   output path for that host. `windows-prepare --session FILE` verifies restoration.
+4. `host-test --session FILE --node22 NODE22_PATH` runs every shard for the actual
+   OS and the exact TGZ matrix on Node 22.16.0/24.19.0. Linux also runs all static,
+   audit, packed installer, identity and pinned upgrade gates.
+5. Copy Windows result directories and stage records into the Linux report set.
+   Preserve bytes and reject duplicates/links. `proof --session FILE` recomputes
+   whole-candidate coverage thresholds and historical package ratchet. Missing,
+   stale, failed or duplicate evidence fails closed.
+6. Copy the completed artifacts back to the maintainer host. `sign --session FILE
+   --artifacts DIRECTORY` verifies the entire proof against the committed source
+   before using the existing trusted Ed25519 key. Never copy the private key into
+   a test checkout, WSL environment, package or release.
+
+The signed receipt binds SHA/tree, policy and engine definitions, complete plan,
+per-file outcomes, prepared bytes, actual OS/runtime, coverage measurements and
+the exact package integrity. It expires within seven days. The six assets are
+qualification-receipt.json, local-catalog-proof.json, plan.json,
+release-manifest.json, sbom.cdx.json and the exact TGZ. Failed or interrupted work
+does not produce an approved receipt. Preserve existing successful evidence;
+reuse requires identical candidate, preparation and qualified identity.
+
+The explicit `local-catalog-static-reuse-v1` extension additionally accepts
+unchanged Node builtin-only units with a verified static import closure across
+ancestor commits. It never changes the original result SHA. To prepare it, run
+`node scripts/local-catalog-reuse.mjs --source-root SOURCE_CHECKOUT --source-output
+SOURCE_REPORT_DIRECTORY --plan TARGET_PLAN --output TARGET_REPORT_DIRECTORY/reuse.json`
+from the committed target checkout. Source checkout and immutable report history
+must remain available. Preserve the resulting bundle alongside the target plan;
+copy it byte-for-byte with the other preparation metadata to the second host.
+
+The resolver verifies source and target plans, the complete changed-path inventory,
+runner/lock/manifest/configuration identity, native case reports and matching static
+closures. Its bundle preserves the donor's latest unit outcomes and global stages,
+including failures. An individually valid result does not approve the donor release.
+Only a new complete signed target proof authenticates the combined qualification.
+The bundle hash detects corruption; it is not a donor signature or publication grant.
+
+Filesystem, dynamic imports, subprocesses, external runners, non-root preparations,
+coverage-bearing units and changed/unknown inputs produce MISS. A mixed unit is
+not split to manufacture eligibility. A current failed, running or completed
+attempt takes precedence over an inherited result. Reuse never substitutes old
+coverage counters, static/consumer stages or matrices of a different TGZ.
+Do not execute every MISS automatically when the human request forbids rerunning
+unproven suites: record the missing proof and preserve the blocked delivery.
+Zero eligible units is a valid conservative result, never a reason to broaden
+the boundary. See `docs/quality/local-catalog-cross-commit-reuse.md`.
+
+Retries append immutable per-unit and per-stage attempt directories. The latest
+failed or interrupted attempt supersedes older passes. Reuse checks the plan,
+runtime, prepared archive and raw evidence digests; changed evidence fails closed.
+Keep the same session and output directory to resume completed preparation or
+host tests. A build interrupted before its prepared archive was authenticated
+requires a fresh isolated checkout; preserve its incomplete output for diagnosis.
+Existing artifact files are reused only when their bytes are identical.
+
+A checkout-wide controller lease excludes concurrent preparation, fixture setup
+and test phases. A live owner blocks another invocation. An interrupted owner
+that already dispatched work cannot prove its descendants stopped; retain that
+checkout and its evidence, and recover in a fresh isolated checkout. A completed
+controlled failure may retry while preserving the prior immutable attempt.
+
+Managed sessions preserve reports, assets and the session under
+`.agents/private/state/release-qualifications`; canonical private data is not a
+distribution input. Keep managed artifacts in that session's `artifacts` folder.
+Signing verifies and seals the session; additional execution requires a new
+qualification, while sign/closure replay remains idempotent. Transport to another
+OS must allocate its own owned scratch and preserve original evidence identities;
+never copy a managed storage ID to adopt a directory on another host. Existing
+explicit-output transport remains supported without automatic deletion.
+
+Both closure publishers invoke cleanup only after their final publication
+readbacks. Only sealed registered scratch with unchanged ownership and preserved
+receipt is removed. Failed publication, interruption, changed bytes or unknown
+ownership preserves it. `cleanup.pending` is separate from published status;
+replay closure to reverify and retry cleanup, never republish just to free space.
+Test teardowns should still clean closed, owned temporary resources promptly.
+
+Before publication, record candidate-bound Validation/Evidence, independent review
+and assurance preflight in the same Task. The local publisher rechecks delivery
+authority, clean candidate, frozen coordinator, notes inventory and remote main
+ancestry, then verifies all six uploaded assets and registry integrity/latest.
+It reads an already authorized project-local NPM_TOKEN only inside the publisher,
+uses an ephemeral npm configuration and removes it in finally. Never fabricate
+provenance or weaken 2FA; unavailable registry authority is a real blocker.
+
+Only authenticated GitHub and npm readback authorizes cycle advancement. Gui is
+the last child. A final metadata-only closure commit and remote verification do
+not repeat product qualification. Preserve partial publication for exact recovery;
+never move an existing tag, overwrite an asset or republish conflicting bytes.
+Actions workflows remain manual alternatives and do not run on push/release.
+
+A native orphan with failed official attachment can follow
+[worktree recovery](../../zaip-skill-worktree-recovery/SKILL.md). The explicit
+preservation receipt is independent of this signed qualification receipt.
+Publication and advance revalidate the retained clean ancestor and its backup;
+they never treat preservation as app attachment or successful cleanup.
+Changing recovery code or another candidate input changes the SHA and requires
+qualification of that candidate. Preserve prior results; only the explicit static
+closure extension above can inherit an eligible unit across SHAs. All remaining
+proof must match the new candidate. Never rewrite old result SHAs.

package/templates/.agents/skills/zaip-skill-release-qualification/references/local-preparation.md

@@ -1,5 +1,7 @@
 # Deterministic local preparation
 
+This reference governs historical/local signed qualification and authorized signed patches. For standard builder releases with `.github/ci-validation.json`, use [remote validation](remote-validation.md) instead; do not execute both complete qualification routes.
+
 Resolve mode first using [the deployment contract](../../zaip-skill-github-deploy/references/deployment-workflow.md). This guide applies to release mode or an explicit local preparation/qualification request. Commits mode uses scoped checks and `guarded-commits.mjs`; it does not require release receipts or version changes.
 
 Preparation does not authorize publication. Use guarded delivery only for the resolved authorized route. An already-published candidate SHA is a no-op; do not allocate an empty new Release. Application branches follow their literal configuration, including main, without inferred beta creation.
@@ -172,14 +174,14 @@ actual human deploy request verbatim. After successful signed preparation, place
 reviewed UTF-8 sources at these fixed repository-local, ignored paths:
 
 ```text
-.local/deploy-request-v46.txt
-.local/release-notes-v4.6.md
-.local/release-notes-v4.6.inventory.json
+.agents/private/state/release-inputs/deploy-request-v46.txt
+.agents/private/state/release-inputs/release-notes-v4.6.md
+.agents/private/state/release-inputs/release-notes-v4.6.inventory.json
 ```
 
 For subsequent minor releases, use the same reviewed-input procedure with version-bound names:
-`.local/deploy-request-vNN.txt`, `.local/release-notes-vN.N.md`, and
-`.local/release-notes-vN.N.inventory.json`; the private policy is
+`.agents/private/state/release-inputs/deploy-request-vNN.txt`, `.agents/private/state/release-inputs/release-notes-vN.N.md`, and
+`.agents/private/state/release-inputs/release-notes-vN.N.inventory.json`; the private policy is
 `policy-vN.N-essential.json` and the candidate is `vN.N-essential-<sha8>-<YYYYMMDD>`.
 The stage helpers validate the explicit current version, prior minor tag, signed receipt,
 human release intent and full candidate inventory. A direct instruction such as

package/templates/.agents/skills/zaip-skill-release-qualification/references/remote-validation.md

@@ -0,0 +1,147 @@
+# Deterministic builder validation on GitHub Actions
+
+This route applies only to the verified framework builder with committed
+`.github/ci-validation.json` selecting `github_actions` and `ci-catalog-v1`.
+Consumers retain their own checks. Historical signed receipts and corrective
+patches retain their existing policy; never convert an old receipt to CI proof.
+
+## Local versus remote
+
+Local: preserve the index and concurrent edits, resolve the Task/cycle and writer
+claim, inspect changed behavior, run focused regression and workflow contract
+tests, review secrets/scopes, synchronize distributed sources and commit the
+candidate. Native Codex session/hook integration, actual OS permissions and
+consumer-authorized credentials need observation on the relevant host. A CI
+fixture cannot certify those capabilities. No real VPS, account or credential
+belongs in framework tests.
+
+Release Actions: the complete deterministic test catalog, Linux/Windows path boundaries,
+loopback SSH with ephemeral keys, isolated browser/UI/API/SQLite fixtures,
+type/lint/source-size/lock/parity/audit/commit checks, one build and one pack,
+exact-TGZ installations on Node 22.16.0 and 24.19.0, full consumer identity/XLSX,
+upgrade from the pinned npm 6.2.0 fixture and rollback. The same Vitest executions
+produce coverage; a separate job merges measurements and applies the existing
+global thresholds and per-package ratchet. No second complete coverage run.
+
+Weekly and on every release: dependency vulnerability audit, whose external data changes over time.
+Large-transcript and 100000-row performance probes require the explicit
+`extended-quality.yml` performance input. They are not ordinary release proof.
+
+The source checkout stays strict before build and for delivery/receipt verification.
+Only the prepared CI route accepts regeneration of the dashboard frontend `dist`
+and its managed manifest. A frozen snapshot checks every generated file, source
+immutability and the manifest against actual files. Its archive digest binds each
+unit, the successful preparation job and the final proof. USTAR entries and physical
+targets are checked before extraction; only the fixed generated frontend directory
+is replaced. Windows CI uses LF checkout bytes in its disposable runner. This is
+not an exception for local edits, arbitrary generated directories or runtime source.
+
+## Candidate and evidence
+
+1. Resolve existing publication authorization separately. Implementation or
+   local qualification alone never authorizes a push, Release or npm upload.
+2. Commit reviewed changes and frozen cycle. Save the existing real human
+   publication request in a project-local file and resolve it with the canonical
+   `deploy-contract.mjs --repository ROOT --request-file REQUEST --plan-file PLAN`.
+   With publication authority, run
+   `node scripts/ci-validation-delivery.mjs submit --repository ROOT --sha SHA --version N.N --request-file REQUEST --plan-file PLAN`.
+   This audits the existing cycle and fast-forwards only the existing `main`.
+   It never creates a branch, tag, Release or npm version. The exact remote SHA
+   is inspected before retrying an uncertain write; an existing SHA is reused.
+3. Pushes in an open cycle run impact validation against the previous main SHA.
+   Frozen-cycle pushes select `release-pending` and retain main-candidate checks;
+   they wait for one complete release dispatch instead of duplicating impact work.
+   Neither route produces publication proof. When Actions are available and the candidate is final,
+   explicitly dispatch `qualify-cli.yml` on the existing `main` with the intended
+   `npm_channel` (normally `latest`); check its exact SHA before accepting its run.
+   The manual dispatch runs the complete release profile. Missing tests,
+   unknown runners and changed deduplication mappings fail closed. At most eight
+   files form a reporting unit; at most twelve compatible units share one job's
+   preparation, and at most twelve jobs run concurrently. Platform and preparation
+   boundaries remain separate. Compatible Vitest files share one literal invocation
+   with explicit isolation and native reports attributed to every selected file.
+   One authenticated coverage measurement covers that exact batch. Node and
+   Playwright retain per-file invocations. Missing cases,
+   all-skipped files and unapproved skips cannot become PASS. Windows-only suites
+   run on Windows; documented mixed-suite Windows cases are N/A only on Linux.
+4. Read the exact run. For an unchanged candidate use `gh run rerun RUN --failed`;
+   never repeat a successful complete battery without a changed input or finding.
+   A failed shard retries its bounded group, including any successful units inside
+   that job. Successful jobs and dependency artifacts retain their original attempt. Newest
+   failure supersedes older PASS. Logs/JUnit/results include SHA, unit and attempt.
+   If a source fix requires a new SHA, commit the correction and submit it to
+   `main` with the same authorization. Preserve failed runs and commits; never
+   create another branch or reuse a different SHA's approval. Historical
+   `retire` supports only cleanup of a prior controlled branch after all its
+   runs are terminal; it cannot create refs or delete main.
+5. With successful authenticated proof, run
+   `node scripts/ci-validation-delivery.mjs verify --repository ROOT --sha SHA --version N.N --run-id RUN --output NEW_LOCAL_DIRECTORY --request-file REQUEST --plan-file PLAN`.
+   The verifier checks GitHub repository/workflow/ref/run/jobs, the API artifact
+   digest, regenerated plan, receipt and TGZ digests. Main must still match the
+   tested SHA before and after verification. This operation never pushes.
+   Use a fresh local output directory for each inspection.
+   Request/plan inputs must be project-local and cannot traverse symlinks or
+   junctions. The helper rechecks canonical authority before remote mutations;
+   it needs no access to signing keys and does not expand hook secret exceptions.
+6. Only after successful exact-main qualification, publish reviewed Release notes/tag through the authorized
+   GitHub route, then let `publish-cli.yml` verify the same CI bundle before npm.
+   Source is not rebuilt or retested by the publisher. Registry integrity and
+   channel confirmation remain mandatory; additional registry installation is opt-in.
+
+## Publication closure without duplicate product tests
+
+Publish the six authenticated CI bundle files as Release assets: qualification
+receipt, manifest, SBOM, exact TGZ, plan and CI proof. Verify the clean candidate,
+then record candidate-bound Validation/Evidence and run assurance preflight before
+publication. After npm and integrity are confirmed, advance the cycle from the
+published SHA using its separate successful `main-candidate-qualification` run.
+Pass `--evidence EVD-ID[,EVD-ID]` to retain only new, untracked, typed assurance
+artifacts of that Task/Change/Execution and SHA; the command checks their identity,
+reruns canonical assurance preflight and rejects changes to existing files,
+unrelated paths, links or hardlinks. It never cleans or moves records. Then run
+Gui and commit the exact closure metadata. Clean historical routes remain valid.
+
+Use the existing `local-release-deploy.mjs push-closure` with the verified CI
+receipt, TGZ, reviewed notes and exact metadata inventory. The CI route omits
+`--policy` and `--trust-store`; signed releases and patches still require them.
+It reauthenticates the GitHub artifact in a temporary detached Git snapshot,
+checks Release asset digests/body, npm integrity/latest and the direct parent,
+then pushes only main. It never creates a branch or reruns product tests.
+
+The qualifier authenticates this one metadata-only closure before skipping its
+product engine. Cycle history must be preserved with one exact advance; source
+edits, links, merges, a missing publication or stale proof fail closed. Main's
+candidate/commit checks still run. Confirm both the main-candidate check and
+the closure route before reporting remote closure. A closure workflow success
+is not qualification of a new product SHA. Open-cycle product pushes select impact
+tests and the mandatory baseline; frozen-cycle pushes wait for qualification.
+The explicit release dispatch retains the complete
+catalog, coverage ratchet, exact TGZ matrix and consumer/upgrade gates. Only obsolete
+impact runs are cancelled; release runs are isolated from push concurrency.
+
+Intermediate artifacts retain seven days and use compression; the authenticated
+publication bundle retains fourteen days. These settings apply to new artifacts,
+not existing evidence. Resume failed jobs within artifact retention. If required
+artifacts expire, report that condition before planning a replacement qualification;
+never fabricate missing proof. GitHub Free quota is shared with the owner's other
+private repositories. Fewer jobs and less retained data reduce consumption, but
+do not restore an exhausted allowance or establish that billing has been unblocked.
+
+Before preparation, the plan checks a 1800-minute planning envelope for one
+validation attempt, including matrix instances and wrapper jobs. Linux=1 and
+Windows=2 are conservative planning weights, not billing observations. The Free
+monthly allowance is shared; this check does not know the account balance or
+artifact storage and excludes retries, other runs and publication. See
+`docs/quality/v65-github-actions-validation.md` for measurements and limits.
+
+The committed CI policy takes precedence over the old repository variable for
+standard releases. Missing policy retains the old local/legacy routes. Invalid
+policy blocks instead of silently falling back. Signed patch policy remains
+separate. No private release key is uploaded to ordinary test jobs; npm credentials
+are available only to the protected publication step.
+
+On an unavailable API, missing artifact, exhausted retention or failed job,
+preserve candidate/history and report the exact condition. Do not lower gates,
+reuse another SHA, reopen terminal records or clean unrelated work. Runtime task
+resume/rework and the mandatory finalizer still govern acceptance. A successful
+fixture is not a successful live GitHub workflow, active Codex hook or deployment.

package/templates/.agents/skills/zaip-skill-sales-methodology/SKILL.md

@@ -11,6 +11,7 @@ description: Design evidence-backed sales processes, qualification playbooks, an
 - Esta skill orienta trabalho interno. Contato com prospects, proposta, pagamento, preço/desconto, assinatura ou outro ato externo exige autorização específica vigente.
 - Para processo, qualificação, negociação, roteiro por etapa ou entrega persistente, carregue [o fluxo progressivo](references/extended-workflow.md), com SPIN/BANT, handoffs e limites. Artefatos vivem em `.agents/sales/`; `playbook.md` centraliza o processo.
 - Campanha pertence a Marketing; estratégia empresarial/RevOps a Growth; decisão de marca a Branding; dados e políticas aos respectivos especialistas.
+- Para descoberta BANT configurável por empresa e formulário de mensuração, use [entrevista e aprovação](references/bant-discovery.md) e o [contrato v2 opt-in](../zaip-skill-lead-measurement/references/bant-contract.md). Fixtures draft são sintéticas e não autorizam adoção, qualificação real ou envio.
 
 Uma interaction read-only não materializa Task/Change. Entrega persistente segue lifecycle, Requirements/AC e assurance proporcionais; só trabalho técnico carrega engenharia.
 

package/templates/.agents/skills/zaip-skill-sales-methodology/references/bant-discovery.md

@@ -0,0 +1,28 @@
+# Descoberta BANT por empresa e oferta
+
+Contrato de entrevista v2, origem: kit BANT da auditoria de 2026-10-29 (F02/F09), C02 da SPEC de mensuração. Responsável pela proposta: Sales; aprovação comercial real: responsável designado pela empresa, ainda não informado. Esta referência de framework não altera o playbook de empresa alguma.
+
+## Entrevista antes do formulário
+
+Registrar cada resposta como fato com fonte/locator, decisão aprovada com aprovador/data, hipótese ou lacuna. Não preencher lacunas com outra empresa, fixture ou silêncio. Perguntas adaptativas, sem pressão; dividir a entrevista em até cinco perguntas críticas por turno.
+
+| Bloco | Perguntas e decisões a registrar |
+| --- | --- |
+| Empresa/oferta | O que vende, para quem, regiões, B2B/B2C, unidades/ofertas com critérios distintos? Qual ciclo, canal, dono e SLA de atendimento? |
+| Significado comercial | O que é cadastro válido, perfil completo, MQL, SQL e oportunidade? Que evidência justifica cada transição? |
+| Budget | Total, mensal ou por projeto? Moeda/unidade, mínimo viável, faixas e limites inclusivos/exclusivos? Desconhecido ou proposta pendente exige qual atendimento? |
+| Authority | Quem compra, usa, influencia e aprova? Pode decidir em conjunto? É multi_choice? Registrar papéis sem nomes de terceiros. Ausência de decisor pede revisão ou bloqueio específico? |
+| Need | Quais problemas, objetivos, múltiplas necessidades e exclusões demonstram fit? Que condição requer análise humana? Qual finalidade justifica cada campo? |
+| Timing | Prazo de início, compra ou conclusão? Unidade, disponibilidade, sazonalidade, data-base/timezone e sem prazo definido? Urgência cabe na capacidade? |
+| Operação | Obrigatoriedade/ramificação, promoção/rebaixamento, override, responsável/carteira/tags preservados, recorrência e match? Nova resposta recalcula quando? |
+| Dados/destinos | Retenção por categoria, finalidades/consentimento separados e projeções mínimas por destino? Cadastro/perfil/qualified são eventos distintos da mesma solicitação raiz. |
+
+## Aprovação e handoff
+
+Sales prepara matriz `question_code → tipo/unidade/opções → finalidade → obrigatoriedade/branch → regra/reason → CRM → allowlist de mensuração`. O responsável comercial aprova questionário e regra, com identidade, data, vigência, versões e exemplos positivos/negativos/fronteira/override. Técnico revisa tipos/limites/aliases; privacidade e operador aprovam seus próprios contratos. Aprovação comercial não concede SQL, publicação, envio ou alteração de CRM.
+
+Separar versões de contrato técnico, questionário, regra, consentimento e mapping. Alterar semântica cria código/versão; corrigir rótulo preserva código e mantém revisão. Histórico é append-only: respostas, avaliação, motivo, versões e override são snapshots; reavaliação cria novo registro ligado à raiz e requer campanha autorizada. Nunca recalcular histórico na leitura ou reenviar publicidade por uma regra nova.
+
+Ausência de resposta ≠ `unknown` ≠ `not_applicable` ≠ `withheld`; nenhum vira zero, false ou opção default. Decisão compartilhada não reprova globalmente. Regra MQL de decisão solo pertence somente ao consumidor que a aprovou; não é a métrica Meta.
+
+Saída: handoff SDR→closer com evidência, lacunas, motivo e próximo passo/SLA aprovados; caminhos `pending`, `human_review` e `not_qualified` preservados. Só ativar após aprovações reais e gates de [autoridade](../../zaip-skill-lead-measurement/references/authority.md). Os exemplos do [contrato BANT](../../zaip-skill-lead-measurement/references/bant-contract.md) são draft/opt-in, com aprovação explicitamente simulada, sem poder de adoção.

package/templates/.agents/skills/zaip-skill-screenshot-intake/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: zaip-skill-screenshot-intake
+description: Collect screenshots in batches of up to ten when the user sends multiple visual references; persist per-image notes and wait for explicit completion.
+---
+
+# Collect screenshot batches
+
+Use this entry to receive and resume screenshot batches, regardless of the eventual
+report/implementation mode. Ten is the chosen batch size; the total is unknown until
+reported by the user. Intake does not authorize implementation.
+
+1. Read the shared contracts below. Resume only the workspace/session explicitly linked
+   to this conversation; never pick the latest global intake.
+2. Receive at most ten images per batch. Retain order, batch/image IDs, receipt,
+   revision and observed timestamps; distinguish replay from intentional repetition.
+3. Examine each available image and persist its own note: visible components, readable
+   text, spatial relations, visible state, differences and uncertainty. Label crop,
+   zoom and approximate OCR. Unviewed images cannot receive completed observations.
+4. For a visually available chat attachment without exportable bytes/path, retain the
+   observed attachment reference and notes; set available_bytes:false and hash/bytes/path
+   to null with unavailable_reason. State explicitly that the asset was not preserved.
+5. Confirm receipt only when manifest and notes are verified. Durable byte preservation,
+   atomic stage/journal recovery and revision checks require the intake runtime's real
+   receipt; writing notes alone does not prove runtime persistence or an asset round-trip.
+6. Continue collecting until explicit finish. A partial report is allowed only when
+   requested and labeled partial. Finalization requires all viewed notes and a manifest/
+   notes snapshot; never derive finish from silence, ten images, or a small last batch.
+7. New input after finalized requires explicit reopen and preserved revision. Export
+   only to an authorized destination, with sensitive data sanitized.
+
+Read [runtime workflow](references/runtime-workflow.md) for the portable Node CLI,
+request shape, explicit namespace, receipts, correction/reopen and tested recovery
+protocol. Verify the installed runtime exists before claiming execution capability.
+Use the report entry for the final detailed synthesis after its verified evidence base.
+
+## Shared contracts
+
+Read [source-contract](../zaip-skill-visual-report/references/source-contract.md),
+[intake-state](../zaip-skill-visual-report/references/intake-state.md) and
+[fidelity-proof](../zaip-skill-visual-report/references/fidelity-proof.md) before using this entry.

package/templates/.agents/skills/zaip-skill-screenshot-intake/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "ZAIP Screenshot Intake"
+  short_description: "Keep traceable notes across screenshot batches."
+  default_prompt: "Use $zaip-skill-screenshot-intake to collect screenshot batches with stable IDs, viewed notes and explicit finish."
+policy:
+  allow_implicit_invocation: true

package/templates/.agents/skills/zaip-skill-screenshot-intake/references/request-example.json

@@ -0,0 +1,36 @@
+{
+  "request_id": "batch-001",
+  "expected_revision": 1,
+  "batch_id": "batch-001",
+  "received_at": "2026-10-11T22:00:00-03:00",
+  "images": [
+    {
+      "id": "screen-001",
+      "source": {
+        "locator": "replace-with-observed-attachment-locator",
+        "path": null,
+        "unavailable_reason": "Pixels visible in chat; bytes/path unavailable"
+      },
+      "note": {
+        "viewed": false,
+        "observations": [
+          {
+            "id": "obs-001",
+            "kind": "unknown",
+            "subject": "Visible components",
+            "value": null,
+            "reason": "Structural example only; image not examined",
+            "provenance": {
+              "origin": "user-attachment",
+              "locator": "replace-with-observed-attachment-locator",
+              "observed_at": "2026-10-11T22:00:00-03:00",
+              "viewport": null,
+              "method": "Replace with actual observation method"
+            }
+          }
+        ],
+        "uncertainty": ["No actual visual observation in this example"]
+      }
+    }
+  ]
+}