wizz-method 2.23.0 → 2.25.0

package/tools/installer/templates.md

@@ -0,0 +1,156 @@
+# Versioned templates with APPLY.md
+
+A template is an inert package of explicit files and instructions. It is a separate
+registry type, not a skill, MCP or CLI installation. The normal installer never
+selects it by area. No package script, dependency installation, paid operation or
+publishing step runs when a template is validated or staged.
+
+## Use
+
+```sh
+wizz templates --list --json
+wizz templates --validate ./my-template --json
+wizz templates --use review-team --template-version 1.0.0 --project . --json
+```
+
+The last command resolves a registered template from the installed Wizz package.
+For an independently obtained local directory, explicitly supply its identity and
+the trusted SHA-256 of its `manifest.json`. The manifest slug must match the
+local id and must differ from every registered template id:
+
+```sh
+wizz templates --use local-review-team --source ./my-template \
+  --sha256 <trusted-manifest-sha256> --template-version 1.0.0 --project . --json
+```
+
+Obtain the expected hash through a trusted channel. `--validate` computes a digest
+for authoring and checks file integrity; computing a hash from an untrusted
+manifest does not authenticate that package. `origin` is attribution, not proof of
+authorship. The CLI does not fetch that URL. This first version accepts local
+unpacked directories only; it has no download, archive extraction or publish path.
+
+Staging creates `.wizz/templates/<slug>/<version>/` inside an existing project and
+returns `instructions` (the absolute path of `APPLY.md`), `provenance`, `policy`
+and `applied: false`. The agent reads that file and adapts the project separately.
+Only listed files, `manifest.json` and a generated `origin.json` receipt are written.
+Other project files stay untouched. All payloads are verified before cache writes.
+Files are prepared with exclusive writes and non-executable permissions in a
+hidden temporary sibling, then published by atomic rename; an existing version
+always causes an error, even if it has identical contents. There is no force flag.
+An interrupted preparation leaves only a hidden staging sibling, so retry can
+succeed without replacing a version. An existing legacy version without
+`origin.json` is diagnosed as incomplete and preserved for inspection; move it
+aside explicitly before retrying. Keep an existing cache until the human
+explicitly decides how to handle it.
+
+## Manifest contract (schema_version 1)
+
+`manifest.json` is UTF-8 JSON with only these fields:
+
+```json
+{
+  "schema_version": 1,
+  "type": "template",
+  "slug": "review-team",
+  "version": "1.0.0",
+  "origin": "https://example.com/templates/review-team",
+  "instructions": "APPLY.md",
+  "policy": {
+    "conflicts": "stop-or-prefix",
+    "provenance": "required",
+    "verification": "required",
+    "execution": "manual"
+  },
+  "files": [
+    { "path": "APPLY.md", "size": 123, "sha256": "<64 lowercase hex characters>" },
+    { "path": "prompts/reviewer.md", "size": 456, "sha256": "<64 lowercase hex characters>" }
+  ]
+}
+```
+
+Sizes and hashes above are placeholders: use the exact byte length and SHA-256
+of each file, including `APPLY.md`. `slug` uses lowercase letters, numbers and
+single hyphens (maximum 64 characters). Versions are exact canonical semver,
+including prereleases when needed; aliases and ranges are rejected. Origin must be
+an HTTPS attribution URL without embedded credentials or semicolon provenance delimiters. Unknown keys are rejected.
+`manifest.json` and `origin.json` are reserved and cannot be listed as payloads.
+
+The uncompressed package limits are 1,000 payload files, 25 MiB per file, 100 MiB
+combined payload and 256 KiB for the manifest. There is no compressed size limit
+because archives are not accepted. Paths are explicit portable relative paths:
+no glob, traversal, absolute path, backslash, empty component, Windows device name
+or trailing dot/space. Duplicate paths (case-insensitive), file/directory collisions,
+symlinks are rejected. Hardlinks are rejected for arbitrary local sources;
+bundled registry packages inside the trusted package root accept hardlinks only
+with the registry manifest pin and per-file hashes verified. Unlisted files are ignored. Source
+and cache directories must not be concurrently modified while validating/staging;
+this CLI is not a sandbox against another process controlling the local filesystem.
+
+## APPLY.md contract
+
+Every `APPLY.md` must start byte-for-byte with the canonical policy exported as
+`APPLY_RULES` by `tools/installer/modules/templates.js`. Authors can prepend it
+without retyping:
+
+```js
+const fs = require('node:fs');
+const { APPLY_RULES } = require('./tools/installer/modules/templates');
+fs.writeFileSync('./my-template/APPLY.md', `${APPLY_RULES}\n## Apply\nDescribe the adaptation here.\n`);
+```
+
+The mandatory preamble tells the agent to:
+
+- Never overwrite an existing project file. On conflict, stop and ask the human,
+  or use a human-approved prefix in both filename and skill `name:` frontmatter.
+- Record the CLI's single provenance line in the adapted project. The line names
+  origin, slug, version and manifest SHA-256; the cached `origin.json` also stores it.
+- Verify the adapted files and relevant project checks at the end, then report
+  passed checks and anything still unverified.
+- Treat installation as inert. Obtain explicit human authorization before paid,
+  expensive, publishing or credential operations.
+
+After that preamble, describe the intended files, how to adapt them, dependencies
+as explanatory text, conflict alternatives and concrete final checks. Include no
+secrets. The CLI enforces the preamble, manifest and cache rules; the agent and
+human enforce project adaptation and approval. It never interprets or executes
+instructions, including the final checks. Review third-party instructions before
+following them.
+
+## Registry contract
+
+The optional root `templates` list in `skills-registry.yaml` accepts entries with
+`type: template`. This is separate from skills/CLI/MCP ids and their relation graph.
+The initial catalog is empty; add a real package only when its files ship alongside
+the Wizz package (files under `tools/installer/` are already included in npm).
+
+```yaml
+templates:
+  - id: review-team
+    type: template
+    when: "Adapt a review team to an existing project."
+    version: "1.0.0"
+    source: "tools/installer/templates/review-team/1.0.0"
+    sha256: "<SHA-256 of manifest.json, 64 lowercase hex characters>"
+    metadata:
+      version: "1.0.0"
+```
+
+`source` is a safe relative directory inside the Wizz package, never a shell command
+or URL. A registry id cannot be combined with `--source`; use a distinct local id
+for a separate package. Local `--validate` works without loading any registry,
+including a missing or invalid one. `id` and `version` must match the manifest;
+`sha256` pins its exact bytes.
+`metadata` is optional and, when supplied, its version must match. Never reuse the
+same slug/version with different contents: publish a new version. The CLI refuses
+to replace existing cached versions. `wizz templates --list` is the discovery
+surface; no template is automatically applied or invoked by the router.
+
+## Checks
+
+```sh
+node test/test-templates.js
+node tools/validate-registry-schema.js --strict
+```
+
+The dedicated suite is also discovered by `npm test`. This is an additive feature
+under governance (MINOR); release numbering is handled by the maintainer.

package/src/skills-lib/wizz-security-audit-pentest/references/stage-5-fusao-plano.md

@@ -1,27 +0,0 @@
-# Estágio 5 — Fusão num plano único
-
-Vou colar abaixo os relatórios das quatro etapas de auditoria
-(validação de entrada, autorização, abuso por volume, vazamento
-por resposta).
-
-Funda os quatro num plano único de correção:
-
-1. Remova duplicatas. O mesmo problema aparece em mais de uma
-   etapa com nomes diferentes — por exemplo, uma chave vazada
-   aparece no MAPA e o efeito dela aparece no ACESSO.
-   Trate como um item só, citando as duas origens.
-
-2. Reordene por ESFORÇO DE CORREÇÃO dividido por GRAVIDADE.
-   Primeiro o que é crítico e se resolve em minutos.
-   Por último o que é médio e exige refatoração.
-
-3. Identifique CADEIAS: onde dois achados de gravidade média
-   se combinam num caminho crítico. Exemplo: enumeração de
-   usuário no login mais ausência de limitador na mesma rota
-   é uma cadeia, e vale mais que a soma das partes.
-
-4. Termine com "AS TRÊS DE HOJE": os três itens que devem ser
-   corrigidos antes de qualquer outra coisa, com a justificativa
-   em uma linha cada.
-
-[colar os 4 relatórios abaixo]