create-astrale-domain 0.3.0-beta.166 → 0.3.0-beta.168

package/README.md

@@ -15,14 +15,11 @@ Every generated Environment is canonical: each `astrale-domain deploy <environme
 immutable deployment of the release, at its own URL, with a signing key generated for it, or reuses
 the deployment of the same release, whose changed secrets are then rewritten in place on that
 deployment only. A generated project names no instance, keeps no signing key file
-(`.astrale/identity.json`), and has no `dev` script: `astrale-domain dev` refuses a canonical
-Environment, so each change is deployed.
+(`.astrale/identity.json`), and has no watch script: each change is deployed.
 
 - Managed generation (the default `astrale` adapter) deploys on Admin's Services. It writes
-  `development`, which deploys on a line of the deploying identity, and `production`, which names
-  the organisation that holds its deployment line: an Identity on the Admin instance, a User or a
-  Shell Group. Replace the generated placeholder with that Identity id before deploying
-  `production`.
+  `development` and `production`, both using the authenticated Astrale CLI identity. There is no
+  organisation placeholder to configure before deploying.
 - Cloudflare generation (`--adapter cloudflare`) deploys into the platform's dispatch namespace,
   where only the platform deploys (Shell, Services and the other platform Domains). It writes
   `development` and `production` in namespace mode; replace the generated namespace placeholders

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-astrale-domain",
-  "version": "0.3.0-beta.166",
+  "version": "0.3.0-beta.168",
   "description": "Scaffold a standalone Astrale domain — npm create astrale-domain",
   "keywords": [
     "astrale",
@@ -30,14 +30,14 @@
     "registry": "https://registry.npmjs.org/"
   },
   "dependencies": {
-    "@astrale-os/adapter-astrale": "0.5.0-beta.166",
-    "@astrale-os/adapter-cloudflare": "0.5.0-beta.173",
+    "@astrale-os/adapter-astrale": "0.5.0-beta.168",
+    "@astrale-os/adapter-cloudflare": "0.5.0-beta.175",
     "@clack/prompts": "^0.11.0"
   },
   "devDependencies": {
     "@astrale-os/kernel-dsl": "0.2.0-beta.46",
     "@astrale-os/ox": "0.1.4",
-    "@astrale-os/sdk": "0.6.0-beta.18",
+    "@astrale-os/sdk": "0.6.0-beta.20",
     "@types/node": "^22.0.0",
     "esbuild": "^0.28.2",
     "oxfmt": "0.63.0",

package/template/CLAUDE.md

@@ -38,10 +38,11 @@ deployment, and prints its URL. A deploy never installs, reads an active instanc
 Worker, Vite server, or tunnel: install the URL it prints with
 `astrale domain install <url> --direct -i <instance>`. There is no watch loop: deploy each change.
 Redeploying the same release reuses its deployment. With the Astrale managed adapter the deployments
-live on Admin's Services, and every Environment other than `development` names its `organization`;
+live on Admin's Services and every Environment uses the authenticated Astrale CLI identity;
 with the Cloudflare adapter they live in the platform's dispatch namespace, where only the platform
 deploys. Do not add a parallel tunnel, install loop, frontend watcher, or shutdown uninstall. Do not
-declare `installation` on a Project Environment, nor `instance` or `signingIdentity` in `astrale()`:
+declare `installation` on a Project Environment, nor `instance`, `signingIdentity`, or `organization`
+in `astrale()`:
 each is refused. On `cloudflare()`, `signingIdentity`, `route` and `workerName` are refused beside
 `namespace` and, without it, select the deprecated direct mode: do not add them.