diff --git a/README.md b/README.md
index 99bcb20..0686d37 100644
--- a/README.md
+++ b/README.md
@@ -191,7 +191,7 @@ on the menu with the reason; it can never take the arcade down.
 
 The arcade you play with is also the whole dev kit — `termcade dev new
 you/mygame` scaffolds a playable game, `termcade dev build` packages it, and
-`termcade add` puts it on your own menu.
+`termcade dev install build/mygame.tcade` puts it on your own menu.
 
 To put it on everyone else's, attach the `.tcade` to a GitHub release and tell
 the marketplace where it is:
@@ -202,9 +202,11 @@ termcade publish https://github.com/you/mygame v1.0.0 mygame.tcade
 
 The registry fetches that asset once, validates it against the same manifest
 rules the arcade enforces, reads the game's identity and version out of the
-manifest inside it, and records its digest. Nothing you pass here asserts what
-the package is — only where it is. The first publish under an author name
-claims that namespace.
+manifest inside it, and records its digest. Nothing you pass here asserts
+what the package is — only where it is. The author segment of the id must be
+a handle you already control: your username, claimed at signup or with
+`termcade username`, or an org you belong to. Publishing under a name nobody
+has claimed is refused rather than minting it.
 
 A game is a Go package implementing `sdk.Game` — see
 [docs/sdk.md](docs/sdk.md) for the author quickstart,
diff --git a/docs/packaging.md b/docs/packaging.md
index d1829b2..ecaa3b4 100644
--- a/docs/packaging.md
+++ b/docs/packaging.md
@@ -89,23 +89,29 @@ Three consequences worth knowing:
 
 - **`version` must be plain semver** (`1.2.3`, optionally `v`-prefixed). The
   manifest itself only length-checks it, because the arcade never has to sort
-  versions. The registry does — pinning, "latest" and rollback all need an
-  order — so it is enforced at publish time rather than here.
+  versions. The registry does — picking the newest release an arcade can run
+  needs an order — so it is enforced at publish time rather than here.
 - **A version is published once.** Re-publishing `1.0.0` is a conflict, not an
   overwrite.
-- **The first publish under an author name claims that namespace.** Nobody
-  else can publish `you/*` afterwards.
+- **Publishing requires a handle you already control.** The author segment of
+  the manifest id must be your username (claimed at signup or with `termcade
+  username`) or an org you belong to (`termcade org new`). A publish under a
+  name nobody has claimed is refused, and nobody else can publish `you/*`.
 
 ## Installing from the marketplace
 
 ```sh
-termcade add you/mygame          # newest release
-termcade add you/mygame@1.0.0    # pinned
+termcade add you/mygame
 ```
 
-`add` asks the registry where that version lives, downloads it straight from
-GitHub, and checks the sha256 against the digest the registry recorded when it
-fetched and validated the package. A mismatch aborts the install: a release
-asset can be deleted and re-uploaded under the same tag, so the digest is what
-ties what arrives to what was actually reviewed. Nothing installs unverified,
-and the registry token is never sent to GitHub.
+There is no pinning — `termcade add you/mygame@1.0.0` is refused. `add` asks
+the registry to resolve the game, passing the ABI version this arcade speaks,
+and the registry answers with the newest release this binary can actually
+run.
+
+The package itself comes back through the registry, not from GitHub — that is
+what lets an install require an account. `add` checks the sha256 of what
+arrives against the digest the registry recorded when it fetched and
+validated the package. A mismatch aborts the install: a release asset can be
+deleted and re-uploaded under the same tag, so the digest is what ties what
+arrives to what was actually reviewed. Nothing installs unverified.