create-astrale-domain 0.3.0-beta.13 → 0.3.0-beta.131

package/README.md

@@ -5,18 +5,28 @@ Official scaffolder for a new Astrale Domain project.
 During the SDK beta program, generate a project from the beta package set explicitly:
 
 ```bash
-npx -y create-astrale-domain@beta my-domain --yes
+npx -y create-astrale-domain@beta my-domain --yes --instance development
 ```
 
 The generated project must resolve the SDK and deployment adapters from npm; it must not retain
 workspace links or repository-only source paths.
 
+Managed generation requires an explicit Astrale instance and writes one installed `development`
+Environment; authors add staging and production only when their distinct instances exist.
+Cloudflare generation does not accept `--instance` and creates deploy-only development and
+production Environments. In both cases `pnpm dev` watches and deploys `development` remotely; no
+active instance, local Worker, Vite server, or tunnel is part of the standard Domain-author journey.
+An installed frontend Environment still opens its default View through generic Project tooling;
+stopping development closes only that local View session and retains the remote deployment and
+installation.
+
 Generated projects have one package journey:
 
 ```bash
 pnpm pack
 ```
 
-The existing `astrale-domain package` command compiles the public Schema and independently loadable
-Runtime, normalizes emitted declarations to semantic SDK facades, and verifies the archive boundary.
-Deployment adapters remain development dependencies and are not part of the published Domain runtime.
+The existing `astrale-domain package` command compiles only the public Schema contract, normalizes
+emitted declarations to semantic SDK facades, and verifies the package boundary. Runtime, handlers,
+Providers, frontend code, and deployment adapters remain implementation inputs and are not part of
+the published Domain contract package.