@wix/himalaya-cli 0.915.0 → 0.917.0

package/dist/cli.mjs

@@ -50953,6 +50953,32 @@ var ServeCliClient = class {
   revoke(app, integrity2, unrevoke = false) {
     return this.request("control", "POST", `/v1/admin/${unrevoke ? "unrevoke" : "revoke"}`, { body: { app, integrity: integrity2 }, headers: this.ctrlHeaders() });
   }
+  /**
+   * OPERATOR-ONLY: bind already-published slugs to an account that never claimed them
+   * (POST /v1/admin/registry/backfill).
+   *
+   * `apply` defaults to false and the route rehearses unless it is exactly `true` — there is no
+   * undo (the ownership store exposes no delete or transfer, and `claim` never reassigns), so
+   * the safe outcome is the one you get by forgetting the flag. Omitting `slugs` backfills every
+   * app the release store lists, bounded server-side.
+   */
+  backfillOwnership(subject, slugs, apply) {
+    return this.request("control", "POST", "/v1/admin/registry/backfill", {
+      body: { subject, ...slugs ? { slugs } : {}, ...apply ? { apply: true } : {} },
+      headers: this.ctrlHeaders()
+    });
+  }
+  /**
+   * Withdraw an app from the serve plane entirely (POST /v1/admin/release/remove).
+   *
+   * Distinct from `revoke`, and the difference matters: revoke is a reversible kill-switch on one
+   * bundle integrity, while this unpublishes the app — which for a template is what "remove it from
+   * the catalog" means. The admin portal's Templates → Manage brokered to this exact route; this is
+   * the same call without the portal in front of it.
+   */
+  removeRelease(app) {
+    return this.request("control", "POST", "/v1/admin/release/remove", { body: { app }, headers: this.ctrlHeaders() });
+  }
   /** Write-through an OTA app-config patch (POST /v1/admin/app-config). */
   setAppConfig(app, patch) {
     return this.request("control", "POST", "/v1/admin/app-config", { body: { app, patch }, headers: this.ctrlHeaders() });

package/guides/releasing-with-himi-serve.md

@@ -80,6 +80,65 @@ traffic until its gateway route was deleted on 2026-09-05; it now 404s with no r
    ```
    Kill-switch a bad bundle: `himi-serve release revoke --app <app> --integrity <sri> --target bo --control-token "$TOK"`.
 
+### Curating templates
+
+A starter template is an app in the reserved `himi-template-<name>` namespace, so it is
+published and promoted like any other. Withdrawing one, or killing it, is addressed by
+**template name** rather than app id — that is what the catalog shows and what
+`himi init --template <name>` takes:
+
+```
+himi-serve template remove   --name <template> --target bo --control-token "$TOK"   # withdraw from the catalog
+himi-serve template revoke   --name <template> --target bo --control-token "$TOK"   # kill-switch its current release
+himi-serve template unrevoke --name <template> --target bo --control-token "$TOK"   # lift it again
+```
+
+All three also take `--app <appId>` instead of `--name`. That exists for one case: a template
+name may legally begin with `himi-template-` (the name pattern is lowercase alphanumerics and
+inner hyphens), and such a name publishes to a **doubly** prefixed app id — so `--name` cannot
+express it without becoming ambiguous. The CLI refuses the ambiguous form and points at `--app`. `--app` only accepts ids inside the
+reserved namespace: a non-template id is refused, so this group cannot unpublish or
+kill-switch an ordinary app by mistake — use the `release` group for those.
+
+`remove` unpublishes the app; `revoke` is the reversible kill-switch, and it resolves the
+bundle integrities from the template's current release manifest so you never paste an SRI. A
+template with no current release, or a release with no bundles, is **refused** rather than
+reported as a successful revocation — a kill-switch that silently switched nothing off is the
+one failure mode worth being loud about.
+
+### Attributing already-published apps (operator only)
+
+Publishing a release and owning the slug are two different writes, and they have not always
+coincided. A self-serve `himi push` claims the slug for you today, but an app published before
+auto-claiming existed — or published by an operator or CI credential, whose scope already covers
+the slug so it claims nothing on anyone's behalf — has a live release and **no owner**. That owner cannot
+fix it themselves either: `claim` refuses a slug that is already published. `apps backfill` is
+the operator door that binds those slugs to the account that should have them:
+
+```
+himi-serve apps backfill --subject <accountGuid> --target bo --control-token "$TOK"
+himi-serve apps backfill --subject <accountGuid> --slugs todo,notes --apply --target bo --control-token "$TOK"
+```
+
+**It rehearses unless you pass `--apply`, and there is no undo.** The ownership store has no
+delete and no transfer, and `claim` never reassigns — so a slug bound to the wrong subject stays
+bound, and its real owner gets `slug_taken` from then on. The safe outcome is therefore the one
+you get by forgetting a flag: without `--apply` the route reports exactly what it *would* claim
+and writes nothing. Omitting `--slugs` means every app the release store lists (bounded
+server-side); an empty or valueless `--slugs` is refused rather than read as "everything", and so
+is any argument the command does not recognise — a stray word or a mistyped flag is usually a
+`--slugs` that went missing, and missing is the spelling that means every app.
+
+It bypasses exactly one refusal — `slug_published` — and keeps every other: reserved names
+(`wix-*`, `himi-template-*`, the platform names) stay unclaimable, an app someone else already
+owns is reported `slug_taken` rather than moved, and a slug nothing has published is reported
+`not_published` rather than reserved. The backfilled claims do not spend the owner's own
+self-serve quota.
+
+The route (`POST /v1/admin/registry/backfill`) is gated on **scope, not role**: a self-serve or
+narrower-than-`*` credential is refused `operator_only_backfill`, which means no cookie caller
+can reach it. That is the difference between a backfill and a land-grab.
+
 ### Registry visibility (public | unlisted)
 
 Whether `GET /v1/apps` (and so the **Himi Player picker**) lists the app is a per-app,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.915.0",
+  "version": "0.917.0",
   "type": "module",
   "description": "himi — the Himalaya authoring CLI. Build a Tier-5 content package on your own machine, push it to the production serve as a draft, preview it on web + Himi Player, and read worker logs back — the remote dev loop. Wraps @himalaya/serve-cli for transport.",
   "keywords": [
@@ -64,5 +64,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "8246d43c3041d1387f510848f691ef7d023c0ac9b2a85d096947e112"
+  "falconPackageHash": "7152abeca53488631b587df6f4efc519c4be90f5ad95fb10c94ee27e"
 }