@runveric/cli 0.1.1 → 0.2.0

package/README.md

@@ -4,14 +4,14 @@
 production runner image — without pushing anything or signing in.**
 
 ```sh
-npx @runveric/cli@0.1.1 init --id yourteam/restart-web-tier
+npx @runveric/cli@0.2.0 init --id yourteam/restart-web-tier
 ```
 
 ---
 
 ## What this is
 
-[Runveric](https://github.com/Mousling1992/opera-cloud) is a governed cloud-operations control
+[Runveric](https://github.com/runveric/runveric) is a governed cloud-operations control
 plane: it runs operational scripts against your cloud with approvals, least-privilege
 short-lived credentials, an allowlisted network, and a full audit trail.
 
@@ -39,7 +39,7 @@ script outside the platform. Nothing in the product offered that. This does.
 ## Install
 
 ```sh
-npx @runveric/cli@0.1.1 <command>     # no install
+npx @runveric/cli@0.2.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.1 init restart-web-tier \
+$ npx @runveric/cli@0.2.0 init restart-web-tier \
     --id acme/restart-web-tier \
     --interpreter powershell \
     --yes
@@ -79,7 +79,7 @@ $ runveric check
 
   ✓ No problems found.
 
-$ export OPERA_RUNNER_IMAGE=<the image your Runveric runs>   # the Author page shows it
+$ export RUNVERIC_RUNNER_IMAGE=<the image your Runveric runs>   # the Author page shows it
 $ runveric test --phase run --param resourceGroup=rg-prod --dry-run
 ```
 
@@ -127,18 +127,18 @@ They are answered at import.
 
 ### `test`
 
-Runs one phase in the **published runner image**, with the same `/opera/*` layout, the same
-`OPERA_*` environment, and the same `result.json` validator the control plane uses.
+Runs one phase in the **published runner image**, with the same `/runveric/*` layout, the same
+`RUNVERIC_*` environment, and the same `result.json` validator the control plane uses.
 
 ```sh
-export OPERA_RUNNER_IMAGE=<the image your Runveric runs>   # the Author page shows it
+export RUNVERIC_RUNNER_IMAGE=<the image your Runveric runs>   # the Author page shows it
 runveric test --phase validate
 runveric test --phase run --dry-run
 runveric test --phase run --param resourceGroup=rg-prod
 ```
 
 Needs Docker. Uses your own `az login` credential (written to a file at
-`/opera/creds/azure-token`, never an environment variable — the same way production does it).
+`/runveric/creds/azure-token`, never an environment variable — the same way production does it).
 
 Two things are deliberately different from production, and printed on every run so you never
 have to guess:
@@ -151,8 +151,8 @@ have to guess:
 ### `publish`
 
 ```sh
-export OPERA_URL=https://your-opera.example.com
-export OPERA_TOKEN=…
+export RUNVERIC_URL=https://your-runveric.example.com
+export RUNVERIC_TOKEN=…
 runveric publish
 ```
 
@@ -164,6 +164,32 @@ 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 with these two commands:
+
+```sh
+# one action's manifest, verbatim — stdout: <key>=<repository>@<digest>
+npx @runveric/cli@0.2.0 catalog publish-action --manifest catalog.yaml \
+    --to ghcr.io/<org>/action-azure-vm-stop
+
+# 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
+```
+
+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
+makes an artifact available; only a pin makes it live.
+
+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
@@ -175,10 +201,26 @@ installed came from this repository:
 npm audit signatures
 ```
 
+## Upgrading from 0.1.1
+
+0.1.2 renamed the three environment variables the CLI reads:
+
+| 0.1.1 | 0.1.2 |
+|---|---|
+| `OPERA_TOKEN` | `RUNVERIC_TOKEN` |
+| `OPERA_URL` | `RUNVERIC_URL` |
+| `OPERA_RUNNER_IMAGE` | `RUNVERIC_RUNNER_IMAGE` |
+
+The old names are not read. If one is still exported in your shell or CI and the new one is not,
+the CLI stops and names both, so the fix is renaming one line.
+
+0.1.2 also writes packages the current Runveric accepts: 0.1.1's `init` produced an `action.yaml`
+whose `apiVersion` and minimum-version key Runveric now refuses at import.
+
 ## Links
 
-- **Issues:** https://github.com/Mousling1992/opera-cloud/issues
-- **Source:** https://github.com/Mousling1992/opera-cloud/tree/main/packages/action-cli
+- **Issues:** https://github.com/runveric/runveric/issues
+- **Source:** https://github.com/runveric/runveric/tree/develop/packages/action-cli
 
 ## License