@volter/world 3.0.184 → 3.0.186

package/dist/src/world.d.ts

@@ -1,3 +1,4 @@
+import { renderDeploymentTemplates, type DeploymentTemplate } from '@volter/world-runtime/deployment-env';
 import { rebaseChangeset, worldBootMarker, type Changeset, type LedgerDelta, type TwinAction, type WorldMarker, type ApplyReceipt, applyTwinWrite, type TwinResource } from '@volter/world-core/runtime';
 import { approveWorldChangeset, createWorldChangeset, downWorld, fetchFromOrigin, pushWorldChangeset, rebaseWorldChangeset, replayWorldChangeset, resetWorld, seedServedWorld, seedWorld, statusWorld, statusWorldChangeset, verifyWorldChangeset, type ServedWorld, type ViewConsole, type WorldView, rootCredentialInput, type DeployTwinOutcome, type ChangesetLocation, type InitOptions, type InitResult, type WorldInstance } from '@volter/world-runtime';
 import { rebaseBranch, type Receipt, type RootConfig } from '@volter/world-core/runtime';
@@ -69,7 +70,7 @@ export declare function parseOriginUrl(url: string, worldRoot?: string): {
 export declare class World {
     /** The branch this handle is on — the instance name in the kernel. */
     readonly name: string;
-    /** The world root: the app repo. */
+    /** The World folder, or the repository holding its `.volter` config. */
     readonly root: string;
     private constructor();
     /** The world of the cwd (or of `ref.root`), on its checked-out branch (or `ref.name`). */
@@ -103,10 +104,7 @@ export declare class World {
     up(opts?: {
         mode?: WorldMode;
         seed?: boolean;
-        cwd?: string;
     }): Promise<WorldInstance>;
-    /** Product startup completes its seed sequence; the runtime owns only the boot. */
-    private finishStartup;
     /** Stop the twins; the branch's state stays (`up` resumes). `purge` forgets it. */
     down(opts?: {
         purge?: boolean;
@@ -115,7 +113,18 @@ export declare class World {
     run(command: string[], opts?: {
         cwd?: string;
         verbose?: boolean;
+        templates?: DeploymentTemplate[];
+        app?: string;
+        appUrl?: string;
     }): Promise<number>;
+    /** Render deployment templates into their selected dotenv files. */
+    env(opts?: {
+        cwd?: string;
+        outputRoot?: string;
+        templates?: DeploymentTemplate[];
+        app?: string;
+        appUrl?: string;
+    }): ReturnType<typeof renderDeploymentTemplates>;
     /** The shell script that activates the world in the current shell: `eval "$(volter world activate)"` — vendor CLIs and curl reach the twins. */
     activateScript(): string;
     /** A subshell with the world active; resolves to its exit code. */

package/dist/src/world.js

@@ -1,3 +1,4 @@
+import { renderDeploymentTemplates } from '@volter/world-runtime/deployment-env';
 // WORLD — the twins an app needs, running together (docs/concepts/the-model.md,
 // docs/concepts/worlds.md#the-config-and-the-running-world): a branch with compute attached. `World.open()` finds the world of the cwd the
 // way git finds its repository; every method is a name for a world-runtime verb, in the words a
@@ -10,7 +11,7 @@ import { activateScript, approveWorldChangeset, branchWorld, clockFile, checkout
 import { existsSync, mkdirSync, readFileSync, rmSync, writeFileSync } from 'node:fs';
 import { dirname, join, resolve } from 'node:path';
 import { requireToken, storeToken } from "./credentials.js";
-import { currentBranch, findWorldRoot, mainBranch, requireWorldRoot, setCurrentBranch, worldConfigRelative, worldEnvPath, worldSeedPath } from "./locate.js";
+import { currentBranch, findWorldRoot, mainBranch, requireWorldRoot, setCurrentBranch, worldConfigPath, worldEnvPath, worldSeedPath } from "./locate.js";
 import { destinationOf, parentEntries, rebaseBranch } from '@volter/world-core/runtime';
 /** One change as `log` shows it: the write, and the receipt the vendor answered with once pushed. */
 /** A twin's branch log as the world reads it: the twin's name, the state service it records under, its control root. */
@@ -44,9 +45,9 @@ export function parseOriginUrl(url, worldRoot = process.cwd()) {
     // a PATH is a world on this machine (git's file transport): its directory, and its served name
     if (!/^[a-z][a-z0-9+.-]*:\/\//i.test(url)) {
         const root = resolve(worldRoot, url);
-        const configPath = join(root, '.volter', 'world.json');
+        const configPath = worldConfigPath(root);
         if (!existsSync(configPath))
-            throw new Error(`Not a remote URL or world directory: ${url} (want https://<host>/<org>/<world>, or a directory holding .volter/world.json)`);
+            throw new Error(`Not a remote URL or world directory: ${url} (want https://<host>/<org>/<world>, or a standard World folder)`);
         const config = loadWorldConfig(configPath, root).config;
         return { url: root, namespace: config.bare?.name ?? `${config.id}/${config.id}` };
     }
@@ -65,13 +66,13 @@ export function parseOriginUrl(url, worldRoot = process.cwd()) {
 export class World {
     /** The branch this handle is on — the instance name in the kernel. */
     name;
-    /** The world root: the app repo. */
+    /** The World folder, or the repository holding its `.volter` config. */
     root;
     constructor(name, root) { this.name = name; this.root = root; }
     // ── finding and making worlds ───────────────────────────────────────────────────────────
     /** The world of the cwd (or of `ref.root`), on its checked-out branch (or `ref.name`). */
     /** The config `loadWorldConfig` resolves for this world: the in-repo world.json, else the world's name. */
-    configRef() { const inRepo = join(this.root, '.volter', 'world.json'); return existsSync(inRepo) ? inRepo : this.name; }
+    configRef() { const config = worldConfigPath(this.root); return existsSync(config) ? config : this.name; }
     static open(ref = {}) {
         const root = ref.root === undefined ? requireWorldRoot() : requireWorldRoot(ref.root);
         return new World(ref.name ?? currentBranch(root), root);
@@ -122,34 +123,25 @@ export class World {
         const existing = this.instance();
         if (existing?.running)
             return existing; // already up: nothing to do
-        const instance = await upWorld(worldConfigRelative(), {
+        const instance = await upWorld(this.configRef(), {
             name: this.name, root: this.root, envFile: existing?.envFile ?? worldEnvPath(this.root),
             ...(opts.mode ? { mode: opts.mode } : existing ? { mode: existing.mode } : {}),
-            ...(existing ? { keepState: true } : {}),
+            ...(existing ? { keepState: true } : {}), seed: opts.seed,
         });
-        await this.finishStartup(instance, existing === null, opts);
         return instance;
     }
-    /** Product startup completes its seed sequence; the runtime owns only the boot. */
-    async finishStartup(instance, fresh, opts = {}) {
-        try {
-            if (fresh && opts.seed !== false && existsSync(worldSeedPath(this.root))) {
-                // a story that fails is a loud failure: the world is up, but not the world the app expects
-                const seeded = await seedWorld(this.name, { root: this.root, cwd: opts.cwd ?? this.root });
-                if (seeded.exitCode !== 0)
-                    throw new Error(`the story failed (${seeded.entry} exited ${seeded.exitCode}); state may be partially seeded — fix the seed, start this World and run \`volter world seed\``);
-            }
-        }
-        finally {
-            // a root set while the world was stopped reaches the twins' state after the default data (which a
-            // fresh boot runs simulated), where the deploy reads it — also when the seed failed
-            materializeRoots(loadWorldConfig(this.configRef(), this.root).config, instance.dirs.data, this.root);
-        }
-    }
     /** Stop the twins; the branch's state stays (`up` resumes). `purge` forgets it. */
     down(opts = {}) { return downWorld(this.name, this.root, opts); }
     /** Run a command inside the world: the app or its tests, with the twins' URLs and fake credentials in its env. */
-    run(command, opts = {}) { return runWithWorldEnv(this.name, command, this.root, { ...opts, cwd: opts.cwd ?? this.root }); }
+    async run(command, opts = {}) {
+        const cwd = opts.cwd ?? process.cwd();
+        const rendered = await renderDeploymentTemplates({ world: { name: this.name, root: this.root }, sourceRoot: cwd, mode: 'process', templates: opts.templates, app: opts.app, appUrl: opts.appUrl });
+        return runWithWorldEnv(this.name, command, this.root, { cwd, verbose: opts.verbose, env: rendered.env });
+    }
+    /** Render deployment templates into their selected dotenv files. */
+    env(opts = {}) {
+        return renderDeploymentTemplates({ world: { name: this.name, root: this.root }, sourceRoot: opts.cwd ?? process.cwd(), outputRoot: opts.outputRoot, mode: 'files', templates: opts.templates, app: opts.app, appUrl: opts.appUrl });
+    }
     /** The shell script that activates the world in the current shell: `eval "$(volter world activate)"` — vendor CLIs and curl reach the twins. */
     activateScript() { return activateScript(this.name, this.root); }
     /** A subshell with the world active; resolves to its exit code. */
@@ -387,7 +379,6 @@ export class World {
     serve(opts = {}) { return serveWorld(this.name, { root: this.root, ...opts }); }
     /** `volter world view`: this World, its twins' screens, its branches and the console on one origin (docs/contributing/architecture.md, "Viewing a World"). */
     async view(opts = {}) {
-        const fresh = this.instance() === null;
         const person = platformPerson();
         const announced = [];
         let ready = false;
@@ -399,7 +390,6 @@ export class World {
             const instance = this.instance();
             if (!instance)
                 throw new Error('the viewer started without a recorded World instance');
-            await this.finishStartup(instance, fresh);
             for (const line of announced)
                 opts.announce?.(line);
             ready = true;

package/examples/customer-onboarding/.env.world

@@ -0,0 +1,3 @@
+STRIPE_SECRET_KEY=${{ stripe.secret_key }}
+RESEND_API_KEY=${{ resend.api_key }}
+DATABASE_URL=postgresql://onboarding:onboarding-local@127.0.0.1:55432/onboarding

package/examples/customer-onboarding/README.md

@@ -6,27 +6,33 @@ title: Customer onboarding with Stripe, email and SQL
 
 Create a Stripe customer, save the application's signup row in PostgreSQL, and request a welcome email with Resend. Inspect each stored outcome through the real SDKs. The browser form and command-line workflow use the same application code.
 
-You need Node 22.6+, npm and registry access during installation. The browser page also prepares public Volter brand assets before entering the World. No platform account or real vendor credential is needed. PostgreSQL is a World-managed application database; its records are application state, separate from SaaS history.
+You need Node 22.6+, pnpm 12.15.0, Docker Compose and registry access during installation. The browser page also prepares public Volter brand assets before entering the World. No platform account or real vendor credential is needed. The app owns PostgreSQL through its [Compose file](./compose.yml). The World starts only Stripe and Resend twins; application SQL state has its own lifetime.
 
 ## Obtain the application
 
 Copy this starter into a new folder:
 
 ```console
-$ npx @volter/world@3.0.184 example customer-onboarding --dir onboarding
+$ npx @volter/world@3.0.186 example customer-onboarding --dir onboarding
 $ cd onboarding
 $ pnpm install
 ```
 
 The command copies source; it neither installs dependencies nor starts a World. Its manifest pins the CLI, core, runtime, console, twins and SDKs. The copied starter retains its native pnpm settings. Its first install creates a lockfile; later installs use `pnpm install --frozen-lockfile`. The [package manifest](./package.json) identifies the selected dependency versions. Keep your own lockfile with the application when sharing it.
 
-Read [onboarding.mjs](./onboarding.mjs) for the application and [run.mjs](./run.mjs) for the command entry. Empty keys in [.env.example](./.env.example) tell init what the app reads; init supplies throwaway credentials. Do not add real keys.
+Read [onboarding.mjs](./onboarding.mjs) for the application and [run.mjs](./run.mjs) for the command entry. The [.env.world template](./.env.world) selects the World-owned Stripe and Resend account keys and the app-owned local SQL connection. Empty names in [.env.example](./.env.example) support discovery. Do not add real vendor keys.
 
 ```console
 $ ./node_modules/.bin/volter world init --name onboarding --twins stripe,resend
 ```
 
-Review Stripe and Resend's exact sources in `.volter/world.json`. The `pg` dependency and `DATABASE_URL` also request a managed PostgreSQL service. Keep it: this app needs SQL. SaaS selection does not exclude a declared native database. `world covers` describes the configured database as part of this workflow.
+Review Stripe and Resend's exact sources in `.volter/world.json`. Start the app's database separately:
+
+```console
+$ docker compose up -d --wait postgres
+```
+
+Compose publishes PostgreSQL 17 on loopback port 55432 with the disposable credentials declared in this app's Compose file. `world covers` reports vendor coverage; it does not allocate or cover this app database.
 
 ## Create and read an account
 
@@ -93,22 +99,17 @@ $ ./node_modules/.bin/volter-world app-url onboarding --root .
 
 `onboarding` is the World name selected by the init command above; use your current branch's name if you have branched. `--root .` selects this application's World. Open the returned URL or the server's printed app URL in your browser. Submit a signup, advance the World clock in another terminal and reload. The page shows the completion state and full stored outcome. [The CLI reference](https://world.volter.ai/docs/reference/cli.html#the-world-itself) describes endpoint discovery and registration.
 
-To have the World start and stop the app with its services, declare `server.mjs` as a process service using [run a full stack](https://world.volter.ai/docs/guides/run-a-full-stack.html#the-app-as-a-service). This server honors the World-assigned `PORT`; use `/` as its HTTP readiness path. The manual command above chooses an available port when `PORT` is absent.
+The server command owns its lifetime. It honors an app-supplied `PORT`, or asks the OS for an available port when absent. The World does not start app processes.
 
-To open the World dashboard, switch the owned compute to the viewer. If you started the app
-manually with `world run`, stop that app with Ctrl-C first. If you declared it as a process
-service, the `down` command below stops it with the World's other services:
+To open the World dashboard, stop the app with Ctrl-C, then switch the World compute to the viewer:
 
 ```console
 $ ./node_modules/.bin/volter world down
 $ ./node_modules/.bin/volter world view --no-open
 ```
 
-The viewer prints the dashboard URL and keeps running. In manual app mode, start
-`world run -- node server.mjs` in a second terminal if you want the application alongside it.
-With a declared process service, the viewer starts the app as part of the World; no second
-app command is needed. Open **Stripe** under **Records**, then select the customer to inspect its name, email and stored ID. Open **Resend** to inspect the accepted email and delivery event. **Board** opens the vendor pages declared by the installed twin; its root workspace may cover settings rather than customers. Provisioning remains in full history even when hidden from the business-activity view. Read the application's combined signup, customer and delivery result with `run.mjs read` or its browser page.
+The viewer prints the dashboard URL and keeps running. Start `world run -- node server.mjs` in a second terminal to use the application alongside it. Open **Stripe** under **Records**, then select the customer to inspect its name, email and stored ID. Open **Resend** to inspect the accepted email and delivery event. **Board** opens the vendor pages declared by the installed twin; its root workspace may cover settings rather than customers. Provisioning remains in full history even when hidden from the business-activity view. Read the application's combined signup, customer and delivery result with `run.mjs read` or its browser page.
 
-Stop app consumers before stopping the viewer. `down` retains vendor and declared application state. [Resume](https://world.volter.ai/docs/guides/resume-a-world.html) explains continuing it; [demo a workflow](https://world.volter.ai/docs/guides/demo-a-workflow.html) uses this same application for a repeatable baseline, refusal and retry. Reset only your disposable example World; it discards that branch's work.
+Stop app consumers before stopping the viewer. `world down` retains vendor state. The app's SQL volume remains under Compose ownership; stop its compute separately with `docker compose down`. Remove that volume only when explicitly resetting your disposable application data (`docker compose down --volumes`). [Resume](https://world.volter.ai/docs/guides/resume-a-world.html) explains continuing it; [demo a workflow](https://world.volter.ai/docs/guides/demo-a-workflow.html) uses this same application for a repeatable baseline, refusal and retry. World reset and branch affect vendor state; they neither reset nor branch this application database. Reset your disposable application SQL separately when repeating the full workflow.
 
 [Source files](./public-files.json) are also in the CLI starter. This page describes the source workflow; it does not inherit execution evidence from another example or an older release.

package/examples/customer-onboarding/compose.yml

@@ -0,0 +1,20 @@
+# Application SQL state; the World supplies only the selected vendor twins.
+name: customer-onboarding
+services:
+  postgres:
+    image: postgres:17
+    ports:
+      - "127.0.0.1:55432:5432"
+    environment:
+      POSTGRES_USER: onboarding
+      POSTGRES_PASSWORD: onboarding-local
+      POSTGRES_DB: onboarding
+    volumes:
+      - application-data:/var/lib/postgresql/data
+    healthcheck:
+      test: ["CMD", "pg_isready", "-U", "onboarding", "-d", "onboarding"]
+      interval: 1s
+      timeout: 5s
+      retries: 60
+volumes:
+  application-data:

package/examples/customer-onboarding/demo.mjs

@@ -9,7 +9,7 @@ try {
     case 'baseline': {
       world.setClock(at);
       const rows = await listSignups();
-      if (rows.length > 1 || rows.some(r => r.name !== 'Grace')) throw new Error('This demo contains customer work; use an explicit reset only in your disposable demo World.');
+      if (rows.length > 1 || rows.some(r => r.name !== 'Grace')) throw new Error('This demo contains customer work; reset both your disposable application database and demo World explicitly.');
       const grace = rows.find(r => r.name === 'Grace') ?? await onboard({ name: 'Grace', email: 'owner@world.test' });
       world.advanceClock('5s');
       console.log('Baseline', JSON.stringify(summarize((await listSignups()).find(r => r.customer_id === grace.customer_id)))); break;

package/examples/customer-onboarding/gitignore.template

@@ -6,3 +6,7 @@ node_modules/
 company.json
 outcomes/
 brand/
+
+.env
+.volter/env-output/
+.volter/env-backups/

package/examples/customer-onboarding/onboarding.mjs

@@ -4,6 +4,7 @@ import pg from 'pg';
 
 const stripe = new Stripe(process.env.STRIPE_SECRET_KEY, { maxNetworkRetries: 0, timeout: 1500 });
 const resend = new Resend(process.env.RESEND_API_KEY);
+if (!process.env.DATABASE_URL) throw new Error('Start the application database from compose.yml and keep DATABASE_URL in the application’s .env.world; World init does not allocate app databases.');
 const db = new pg.Pool({ connectionString: process.env.DATABASE_URL, connectionTimeoutMillis: 1500 });
 export async function initialize() {
   await db.query(`CREATE TABLE IF NOT EXISTS signup (

package/examples/customer-onboarding/package.json

@@ -11,13 +11,13 @@
     "pg": "8.16.3"
   },
   "devDependencies": {
-    "@volter/world": "3.0.184",
-    "@volter/world-core": "3.0.161",
-    "@volter/world-runtime": "3.0.181",
-    "@volter/world-console": "3.0.157",
+    "@volter/world": "3.0.186",
+    "@volter/world-core": "3.0.163",
+    "@volter/world-runtime": "3.0.184",
+    "@volter/world-console": "3.0.158",
     "@volter/twin-stripe": "3.0.2",
     "@volter/twin-resend": "1.0.1",
-    "@volter/world-ui": "1.0.161"
+    "@volter/world-ui": "1.0.162"
   },
   "packageManager": "pnpm@12.15.0",
   "devEngines": {

package/examples/customer-onboarding/public-files.json

@@ -1,7 +1,9 @@
 [
   ".env.example",
+  ".env.world",
   ".gitignore",
   "README.md",
+  "compose.yml",
   "demo.mjs",
   "onboarding.mjs",
   "package.json",

package/examples/index.json

@@ -4,8 +4,10 @@
     "title": "Customer, welcome email and SQL application state",
     "files": [
       ".env.example",
+      ".env.world",
       ".gitignore",
       "README.md",
+      "compose.yml",
       "demo.mjs",
       "onboarding.mjs",
       "package.json",

package/examples/integration-branches/README.md

@@ -13,7 +13,7 @@ Give two workers the same Stripe baseline, let them change different existing cu
 Use an empty parent folder. Create the baseline starter there:
 
 ```console
-$ npx @volter/world@3.0.184 example integration-branches --dir baseline
+$ npx @volter/world@3.0.186 example integration-branches --dir baseline
 $ cd baseline
 $ pnpm install
 $ ./node_modules/.bin/volter world init --name baseline --twins stripe
@@ -38,9 +38,9 @@ The stopped baseline retains its history and can supply local path remotes. Defa
 Create three more copies in the same parent folder:
 
 ```console
-$ npx @volter/world@3.0.184 example integration-branches --dir integration
-$ npx @volter/world@3.0.184 example integration-branches --dir worker-a
-$ npx @volter/world@3.0.184 example integration-branches --dir worker-b
+$ npx @volter/world@3.0.186 example integration-branches --dir integration
+$ npx @volter/world@3.0.186 example integration-branches --dir worker-a
+$ npx @volter/world@3.0.186 example integration-branches --dir worker-b
 ```
 
 In `integration`, then `worker-a`, then `worker-b`, install dependencies and initialize with the folder's name. Before a first boot or app write, link and pull the baseline:

package/examples/integration-branches/package.json

@@ -9,12 +9,12 @@
     "stripe": "17.7.0"
   },
   "devDependencies": {
-    "@volter/world": "3.0.184",
-    "@volter/world-core": "3.0.161",
-    "@volter/world-runtime": "3.0.181",
-    "@volter/world-console": "3.0.157",
+    "@volter/world": "3.0.186",
+    "@volter/world-core": "3.0.163",
+    "@volter/world-runtime": "3.0.184",
+    "@volter/world-console": "3.0.158",
     "@volter/twin-stripe": "3.0.2",
-    "@volter/world-ui": "1.0.161"
+    "@volter/world-ui": "1.0.162"
   },
   "packageManager": "pnpm@12.15.0",
   "devEngines": {

package/examples/workplace-agent/README.md

@@ -19,7 +19,7 @@ The catalog offers current defaults. Keep this example's manifest and installati
 together; its recorded workflow does not establish behavior for a different release.
 
 ```console
-$ npx @volter/world@3.0.184 example workplace-agent --dir workplace
+$ npx @volter/world@3.0.186 example workplace-agent --dir workplace
 $ cd workplace
 $ pnpm install
 $ ./node_modules/.bin/volter world init --name workplace --twins github,linear,slack

package/examples/workplace-agent/package.json

@@ -11,14 +11,14 @@
     "@slack/web-api": "7.19.0"
   },
   "devDependencies": {
-    "@volter/world": "3.0.184",
-    "@volter/world-core": "3.0.161",
-    "@volter/world-runtime": "3.0.181",
-    "@volter/world-console": "3.0.157",
+    "@volter/world": "3.0.186",
+    "@volter/world-core": "3.0.163",
+    "@volter/world-runtime": "3.0.184",
+    "@volter/world-console": "3.0.158",
     "@volter/twin-github": "3.0.9",
     "@volter/twin-linear": "3.0.5",
     "@volter/twin-slack": "3.0.8",
-    "@volter/world-ui": "1.0.161"
+    "@volter/world-ui": "1.0.162"
   },
   "packageManager": "pnpm@12.15.0",
   "devEngines": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@volter/world",
-  "version": "3.0.184",
+  "version": "3.0.186",
   "description": "Run your app against a world of twins. `World` and `Repo` — one method per verb: init, up, run, log, diff, reset, branch, checkout, clone, fetch, changeset, push — and the `volter` command, one client of them.",
   "keywords": [
     "volter",
@@ -31,12 +31,12 @@
   ],
   "dependencies": {
     "@modelcontextprotocol/sdk": "^1.30.1",
-    "@volter/world-core": "3.0.161",
-    "@volter/world-runtime": "3.0.181",
+    "@volter/world-core": "3.0.163",
+    "@volter/world-runtime": "3.0.184",
     "zod": "^4.6.5"
   },
   "peerDependencies": {
-    "@volter/world-console": "3.0.157"
+    "@volter/world-console": "3.0.158"
   },
   "peerDependenciesMeta": {
     "@volter/world-console": {
@@ -44,7 +44,7 @@
     }
   },
   "devDependencies": {
-    "@volter/world-console": "3.0.157"
+    "@volter/world-console": "3.0.158"
   },
   "bin": {
     "volter": "dist/src/cli.js"

package/skills/volter-world/AGENTS.md

@@ -2,7 +2,11 @@
 
 **Owner rules across every repository (2026-10-14, 2026-10-21 and 2026-10-27).** No CI tests or merge gates. Every retained CI workflow must finish within **60 seconds end to end, with no exceptions, in every repository**; per-job limits, retries and skipped runs do not establish compliance. Never ask the user for permission to work, change policy, commit, push or merge to `main`. Main is an autonomous integration branch and is never published. Publication is a separate action through the dedicated `publish` branch. An npm release requires independent review, a clean keys sweep over the exact packed archive and the manager's permission before advancing that branch, dispatching or publishing. A website aimed explicitly at the public requires the owner's word through the manager and account manager. A main merge never advances `publish` and never triggers publication. These owner rules supersede contradictory repository, skill and prior agent guidance.
 
-A World contains only the vendors deliberately selected for substitution in the current workflow.
+A World is a shared simulated internet: selected twins, people and accounts, clock, network names
+and intrinsic seed. Its folder holds world.json, exact runtime/twin pins and lock, and seed; no
+Compose/YAML, app source/settings/database or executable app service. Applications use rendered
+environment or world run. On a machine they run their own command; browser-substrate's Host owns
+Compose and application execution in a tab. A World starts no Docker or VM.
 Review detected vendors before including them. The app uses its real SDKs unchanged;
 environment injection, a Node preload and a scoped HTTPS proxy route configured vendors to twins.
 
@@ -21,20 +25,23 @@ In the app's folder (the [guide](https://github.com/volter-ai/twin-world/blob/ma
 npm install -g @volter/world     # once; `volter agents install` then adds this skill and the MCP server to your agents
 volter world init                # detects the vendors from the app's manifests and env names; writes .volter/world.json
 volter world up
+volter world env                 # renders edited .env.world references to ignored deployment dotenv files
 volter world run -- npm test     # the app's own test command
 volter world log                 # what the app did at each vendor
 ```
 
-Show the person the vendors `init` detected, and why, before keeping them. Keys the app reads
-(named in `.env.example`) for selected twins get throwaway values in the World's env; never
+Show the person the vendors `init` detected, and why, before keeping them. Initialization reads source-held
+example env files, never Compose or ambient live credentials, and scaffolds editable
+`.env.world` templates beside the application's target dotenv files. Rendering resolves their explicit
+references against stable World accounts; `world run` injects those values without writing files. Never
 replace a twin's credential with a real one to get a test past validation. An intentionally
 omitted vendor uses its ordinary production SDK/API and the caller's own credential at launch,
 subject to sandbox and network policy. Remove that vendor's fake values and endpoint overrides;
 keep live credentials out of the config and generated World env. Follow
 [turn a service off](../../docs/guides/turn-a-service-off.md), including its credential-launch order.
 `volter world view --no-open` runs the World with its
-dashboard and prints its link for the person; it keeps running, so start it in the background,
-and stop a World you started with `up` first (`down` keeps its state).
+dashboard and prints its link for the person; it keeps running, so start it in the background.
+It reuses a World already running; closing the viewer stops only compute the viewer started.
 
 ## Share it on a platform
 
@@ -88,8 +95,8 @@ volter-world attach <world> --root <twins-checkout> -- <command...>
 volter-world down <world> --root <twins-checkout>
 ```
 
-The lower-level `volter-world up` starts a fresh instance: reseed after each successful boot.
-Do not confuse this with the resumable `volter world up` API. `up` WRITES the file passed to `--env-out`; it is never an input. Use a new disposable
+The lower-level `volter-world up` starts a fresh instance; both up commands run the standard universe seed
+once for fresh state, unless `--no-seed` is explicit. A resume preserves retained state. `up` WRITES the file passed to `--env-out`; it is never an input. Use a new disposable
 output path, never credentials or custody. An init-generated preview is not the live output. Use `url` and `app-url` to discover endpoints rather
 than parsing env files. Registered commands carry `VOLTER_WORLD`.
 
@@ -135,13 +142,15 @@ Migrate an old installation only after verified teardown with its pinned runtime
 entrypoints to the new version and resume retained state. Never run two runtime versions over
 one instance or erase legacy ownership records to make startup pass.
 
-Worlds own their declared infrastructure. Start, inspect and stop it through World commands;
-never operate its underlying process, container or database separately. Install locked repository
+Worlds own selected twins and their private engines. Start, inspect and stop them through World
+commands; never operate a twin's private process or database separately. App-owned databases and
+Workers stay with the app's command or browser Host. A World gap is fixed in runtime; never add a
+consumer configure/backing/PATH/seed-ordering wrapper or hidden replacement infrastructure file. Install locked repository
 dependencies from the normal registry/cache; use a registry twin only when registry behavior
 needs substitution. Build workspace packages when needed. Do not delete `node_modules` as a World repair.
 
 When booting an app, register its URL as the last step with `app-url --set <url>` (or `--detect`).
-An app declared as a World service supplies its own endpoint record. Consumers read `app-url`.
+The app or browser Host registers a deployment's endpoint; other consumers read its named `app-url`.
 An app that answers as its own production hostnames (`app.example.com`) records them with
 `app-url --host <name>`: inside the World they reach the app with their Host, `x-forwarded-host` and
 `x-forwarded-proto` (https when the caller used TLS).
@@ -153,10 +162,10 @@ An app that answers as its own production hostnames (`app.example.com`) records
 2. Run `doctor`, then `tail --no-follow`, and inspect the twin's `GET /twin` manifest.
 3. Run `covers <world> --repo <app>` for missing vendor coverage.
 4. Determine whether the failure belongs to the app, twin fidelity, scenario, routing or runtime.
-5. A database preparation that fails at image build is fixed in that preparation (`runtime.database.prepare`
-   and what it runs against). `runtime.development.migrateDatabaseAtRuntime` is the app developer's setting for a
-   schema they are changing right now; it is never an operator's route past a failed preparation, and a World
-   that sets it is a development World whose image is not prepared.
+5. A database preparation that fails at image build is fixed in that deployment's Host preparation and
+   source-defined migration. An application's database and preparation receipt belong to the deployment;
+   a twin-private engine receipt or another deployment cannot authorize an app migration. See
+   [application source and Host ownership](../../docs/contributing/architecture.md#application-source-and-host-ownership).
 
 Sandbox mode refuses untwinned destinations in cooperating clients, including Node sockets a
 client opens around the injector. It does not constrain binaries or non-Node processes that