@runveric/cli 0.1.2 → 0.3.0

package/README.md

@@ -4,7 +4,7 @@
 production runner image — without pushing anything or signing in.**
 
 ```sh
-npx @runveric/cli@0.1.2 init --id yourteam/restart-web-tier
+npx @runveric/cli@0.3.0 init --id yourteam/restart-web-tier
 ```
 
 ---
@@ -39,7 +39,7 @@ script outside the platform. Nothing in the product offered that. This does.
 ## Install
 
 ```sh
-npx @runveric/cli@0.1.2 <command>     # no install
+npx @runveric/cli@0.3.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.1.2 init restart-web-tier \
+$ npx @runveric/cli@0.3.0 init restart-web-tier \
     --id acme/restart-web-tier \
     --interpreter powershell \
     --yes
@@ -164,6 +164,48 @@ Publishing does not adopt. Nobody can run it until somebody chooses to.
 
 ---
 
+## Publishing first-party catalog artifacts (`runveric catalog`)
+
+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 and verify with these commands:
+
+```sh
+# one action's manifest, verbatim — stdout: <key>=<repository>@<digest>
+npx @runveric/cli@0.3.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.3.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.3.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.3.0 catalog verify-image --from release.yaml
+npx @runveric/cli@0.3.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. 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.
+
+---
+
 ## Supply chain
 
 Every release is published from CI on a tag, with [npm