@runveric/cli 0.2.0 → 0.4.0

package/README.md

@@ -4,7 +4,7 @@
 production runner image — without pushing anything or signing in.**
 
 ```sh
-npx @runveric/cli@0.2.0 init --id yourteam/restart-web-tier
+npx @runveric/cli@0.4.0 init --id yourteam/restart-web-tier
 ```
 
 ---
@@ -32,14 +32,14 @@ script outside the platform. Nothing in the product offered that. This does.
 
 ## Requirements
 
-- **Node.js 20 or newer** — for `init`, `check` and `publish`.
+- **Node.js 22 or newer** — for `init`, `check` and `publish`.
 - **Docker** — for `test` only.
 - An **Runveric account** — for `publish` only.
 
 ## Install
 
 ```sh
-npx @runveric/cli@0.2.0 <command>     # no install
+npx @runveric/cli@0.4.0 <command>     # no install
 npm install -g @runveric/cli          # or install the `runveric` bin
 ```
 
@@ -62,7 +62,7 @@ Pin the version your Runveric deployment shows you on its Author page rather tha
 Scaffold a PowerShell action, look at what you got, validate it, and run it locally:
 
 ```sh
-$ npx @runveric/cli@0.2.0 init restart-web-tier \
+$ npx @runveric/cli@0.4.0 init restart-web-tier \
     --id acme/restart-web-tier \
     --interpreter powershell \
     --yes
@@ -168,22 +168,38 @@ Publishing does not adopt. Nobody can run it until somebody chooses to.
 
 Not part of authoring, and not something an author needs. The product's own catalog is pinned
 from immutable artifacts published by its action and catalog repositories, and their workflows
-publish with these two commands:
+publish and verify with these commands:
 
 ```sh
 # one action's manifest, verbatim — stdout: <key>=<repository>@<digest>
-npx @runveric/cli@0.2.0 catalog publish-action --manifest catalog.yaml \
+npx @runveric/cli@0.4.0 catalog publish-action --manifest catalog.yaml \
     --to ghcr.io/<org>/action-azure-vm-stop
 
+# an ENGINE action: its manifest and the image its workflow pushed, by digest, to the same package
+npx @runveric/cli@0.4.0 catalog publish-action --manifest catalog.yaml \
+    --to ghcr.io/<org>/action-azure-publicip-delete-unattached \
+    --image ghcr.io/<org>/action-azure-publicip-delete-unattached@sha256:<digest>
+
 # a release naming each action artifact by digest — stdout: <repository>@<digest>
-npx @runveric/cli@0.2.0 catalog publish-release --from release.yaml --to ghcr.io/<org>/catalog
+npx @runveric/cli@0.4.0 catalog publish-release --from release.yaml --to ghcr.io/<org>/catalog
+
+# what the release workflow may sign: each engine action's image, judged by the server's rule
+# — stdout: one <repository>@<digest> per image that passed
+npx @runveric/cli@0.4.0 catalog verify-image --from release.yaml
+npx @runveric/cli@0.4.0 catalog verify-image <repository>@<digest> --key <action key> --commit <sha>
 ```
 
 An action's package must be named after its key (`azure.vm.stop` → `action-azure-vm-stop`); the
 CLI refuses any other name before pushing, and the server refuses it again when a release is
-planned or pinned. Neither command validates a manifest — the server does, every time. Publishing
+planned or pinned. No command validates a manifest — the server does, every time. Publishing
 makes an artifact available; only a pin makes it live.
 
+An engine action's image must be ONE `linux/amd64` image in the action's own package, carrying the
+OCI `source` and `revision` labels: the repository it was built in, and the commit it was built at —
+the commit its artifact's provenance names.
+`publish-action --image` and `verify-image` refuse anything else with the sentence the server would
+refuse the release with — they run the server's own rule, bundled.
+
 Credentials: `GHCR_TOKEN` (a token with `write:packages`), or in a workflow `GITHUB_TOKEN` with
 `packages: write`. Provenance comes from `--repository`/`--commit`, else GitHub Actions'
 environment, else git.