worldvm 0.0.0-stage → 0.1.0

package/docs/protocol.md

@@ -0,0 +1,195 @@
+# Operating protocol
+
+The library, HTTP server and operating MCP share one protocol: Effect schemas, inferred
+request/response types, and generated JSON Schema (`requestJsonSchema`,
+`responseJsonSchema`, `resultJsonSchema`).
+
+In process, call `await world.request(verb, input, actor)`. HTTP and MCP return the same
+envelope: `{ "ok": true, "value": ... }` or
+`{ "ok": false, "error": { "code": "human-required", "message": "...", "details": [] } }`.
+The convenience methods (`subject.assert`, `subject.perform`, `subject.propose`,
+`subject.acceptProposal`, `subject.rejectProposal`) return an `Outcome` with `accepted`,
+`codes`, `status` and `change` instead.
+
+## Verbs
+
+Trusted actors accept `kind: "human"`, `"agent"`, `"service"` or `"connector"`.
+A connector can perform connector work only when its id matches the work's assignee,
+for example `{"id":"connector:everify","kind":"connector"}`. It cannot perform
+human interaction work or make human decisions. HTTP accepts the same actor JSON in
+`x-worldvm-actor`; the trusted host still authenticates that identity.
+
+`operations` reports action states `eligible`, `waiting`, `dispatched` and `held`
+while work exists. An action whose target requirements are all NotApplicable reports
+`not-applicable`; a finished action reports `complete`. Decisions report `decision`.
+`work` omits actions whose requirements do not apply.
+
+`type` is an entity type, such as `Vendor`; `subject` is its id. Every mutation requires
+a nonempty command `id`. Retrying the same id and content, including actor, replays the
+original result, even after reopen. Reusing an id for different content returns
+`command-duplicate`. Ids are unique across the account's verbs and subjects.
+
+| Verb              | Input                                                                                                                     | Result value                                                     |
+| ----------------- | ------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
+| `status`          | `type`, `subject`, optional `at`                                                                                          | Status, requirements, outputs, revision, next wake               |
+| `facts`           | `type`, `subject`, optional `at`                                                                                          | Current fact values and assertion provenance                     |
+| `work`            | `type`, `subject`, optional `at`                                                                                          | Work items, including pending proposal reviews                   |
+| `operations`      | `type`, `subject`, optional `at`                                                                                          | Declared actions and decisions with their state                  |
+| `explain`         | `type`, `subject`, optional `requirement`, `at`                                                                           | Requirement rules, citations and proof trees                     |
+| `subjects`        | `type`                                                                                                                    | Recorded subject ids                                             |
+| `assert`          | `type`, `subject`, `id`, `values`, optional `kind`                                                                        | Write outcome; null values retract facts                         |
+| `perform`         | `type`, `subject`, `id`, `operation`, optional `values`, `instance`, `reason`, `signature`, `unsigned`, `amend`, `revoke` | Evidence or decision write outcome; accepts stable work ids      |
+| `signal`          | `type`, `subject`, `id`, `machine`, `state`, optional `instance`                                                          | Machine observation write outcome                                |
+| `propose`         | `type`, `subject`, `id`, `rationale`, `draft`                                                                             | Write outcome; proposal id equals command id                     |
+| `proposals`       | Optional `type`, `subject`, `state`                                                                                       | Durable proposals (`pending`, `accepted`, `rejected`)            |
+| `accept-proposal` | `type`, `subject`, `id`, `proposal`, optional `signature`                                                                 | Human-authorized write outcome                                   |
+| `reject-proposal` | `type`, `subject`, `id`, `proposal`, `reason`                                                                             | Resolution outcome; draft is not written                         |
+| `changes`         | `{}`                                                                                                                      | Current `revision` and `nextWake`; HTTP GET streams live changes |
+
+An assertion draft is `{ "kind": "assert", "values": { "tier": "high" } }`, with
+optional `factKind`. An evidence draft is
+`{ "kind": "evidence", "operation": "submit-questionnaire", "values": { "summary": "Reviewed" } }`,
+with optional `instance`. A draft is unsigned: proposing it does not assert facts or
+create attested evidence. Evidence drafts target interaction work, not decisions or connectors.
+
+Agents propose; they cannot assert facts, attest evidence, signal machines or resolve
+proposals. Acceptance requires a human and rechecks current invariants and operation
+authority under that human's identity. A refused acceptance leaves the proposal pending;
+retry with a new command id after correcting authority or world state. Successful
+acceptance atomically stores the write, resolution and audit citation to the proposal.
+For evidence with an audit policy, the accepting human supplies `signature` with
+`consent`, `intent`, `method` and `device`; this metadata never comes from the agent draft.
+Rejection requires a human and a reason. Pending proposals appear as `kind: "proposal"`
+work with a `proposal` id; clients resolve them with the corresponding verb.
+
+Stable protocol error codes are `invalid-request`, `unauthenticated`, `human-required`,
+`forbidden`, `not-found`, `command-duplicate`, `proposal-resolved`, `write-refused` and
+`internal`. Kernel refusal codes, such as `operation-authority`, appear in `details`.
+Identity is supplied separately from command bodies; body fields such as `by` are rejected.
+
+## HTTP
+
+```sh
+npx worldvm serve node_modules/worldvm/docs/authoring/vendor-risk --db vendor.db --port 3000
+# For deterministic local sessions, add --clock 2026-11-06.
+```
+
+The server binds to `127.0.0.1`. The `x-worldvm-actor` JSON header is a **dev-only,
+trusted identity**, not authentication. The embedding application must authenticate
+callers and supply trusted ids, kinds and groups before exposing it beyond local use.
+There is no read ceiling or per-subject read authorization in this initial adapter.
+
+```sh
+curl http://127.0.0.1:3000/v1/assert \
+  -H 'content-type: application/json' \
+  -H 'x-worldvm-actor: {"id":"connector:crm","kind":"service"}' \
+  -d '{"type":"Vendor","subject":"acme","id":"crm-1","values":{"name":"Acme","tier":"standard"}}'
+
+curl http://127.0.0.1:3000/v1/propose \
+  -H 'content-type: application/json' \
+  -H 'x-worldvm-actor: {"id":"agent:review","kind":"agent"}' \
+  -d '{"type":"Vendor","subject":"acme","id":"proposal-1","rationale":"Handles sensitive data","draft":{"kind":"assert","values":{"tier":"high"}}}'
+
+curl http://127.0.0.1:3000/v1/accept-proposal \
+  -H 'content-type: application/json' \
+  -H 'x-worldvm-actor: {"id":"ana","kind":"human"}' \
+  -d '{"type":"Vendor","subject":"acme","id":"approval-1","proposal":"proposal-1"}'
+
+curl -N http://127.0.0.1:3000/v1/changes \
+  -H 'x-worldvm-actor: {"id":"ana","kind":"human"}'
+```
+
+All verbs accept POST `/v1/<verb>`. GET `/v1/changes` is an SSE stream of `event: change`
+with a JSON `Change` as data. It starts with a comment and carries live events only;
+reconnect by reading current status/work. It has no replay cursor. Disconnecting
+unsubscribes. Time-driven changes use `tick()` scheduled from `nextWake()` with a
+one-minute maximum interval. `--clock` freezes logical time; wall time will not expire
+evidence in that mode. No listening socket is needed to use or test `createHandler(world)`
+from `worldvm/serve`, a plain `(Request) => Promise<Response>`.
+
+Use one owning handle/process per SQLite database. The initial embedded store does not
+coordinate independent HTTP and MCP processes opening the same file; stop one before
+starting the other. Embedders can share one handle between both adapters.
+
+## MCP for Claude Code and Codex
+
+The existing `worldvm mcp` authoring mode is unchanged. Operate mode opens the durable
+world and fixes its actor for the process:
+
+```sh
+npx worldvm mcp \
+  --world /absolute/path/my-world \
+  --db /absolute/path/vendor.db \
+  --actor '{"id":"agent:review","kind":"agent"}'
+```
+
+Claude Code `.mcp.json` entry (substitute absolute paths):
+
+```json
+{
+  "mcpServers": {
+    "worldvm": {
+      "command": "node",
+      "args": [
+        "/absolute/path/node_modules/worldvm/bin/worldvm.mjs",
+        "mcp",
+        "--world",
+        "/absolute/path/my-world",
+        "--db",
+        "/data/vendor.db",
+        "--actor",
+        "{\"id\":\"agent:review\",\"kind\":\"agent\"}"
+      ]
+    }
+  }
+}
+```
+
+Codex `config.toml` entry:
+
+```toml
+[mcp_servers.worldvm]
+command = "node"
+args = ["/absolute/path/node_modules/worldvm/bin/worldvm.mjs", "mcp", "--world", "/absolute/path/my-world", "--db", "/data/vendor.db", "--actor", '{"id":"agent:review","kind":"agent"}']
+```
+
+Agents discover `status`, `facts`, `work`, `operations`, `explain`, `subjects`, `propose`,
+`proposals` and `changes`. Human/service actors also discover `assert`, `perform`,
+`signal`, `accept-proposal` and `reject-proposal`; services still cannot resolve proposals
+or make human decisions. Calling an undiscovered forbidden mutation still returns the
+protocol refusal code. Authoring tools remain available; the source/scenario explanation
+tool is named `authoring-explain` in operate mode to reserve `explain` for live subjects.
+
+## Structured subject reads
+
+`work[].missing` contains objects with canonical `text` and a `kind`: `requirement`,
+`evidence`, `fact`, `machine`, or `other`. Requirement conditions carry `requirement`
+and resolved `instance`; evidence conditions carry `evidence` and `producedBy`, an
+array of `{requirement, instance}` addresses in the subject's scope. Both `attested`
+and `valid` evidence checks name their producers. Fact conditions carry the authored
+`fact` path. Machine conditions carry `machine` and, for `in-state?`, `states` (the authored set of acceptable states).
+Compound conditions (`and`, `or`, `not`) and assignment/hold reasons remain `other`;
+they are not flattened. Consumers can display `text` without interpreting it.
+
+`status.machines` lists `{instance, machine, state, since}` for every declared
+machine instance. `state` and `since` are null before its first accepted signal.
+`since` is the start of the current consecutive run of that state, in the current
+resource generation. A declared initial state is not an observation.
+
+`facts` accepts `{type, subject, at?}` and returns current declared subject facts as
+`{fact, value, by, at, command}`. `fact` is the stored attribute address, `at` is valid
+time, and `command` is the protocol command ID that wrote it (null for imported
+records without a retained command). Retracted facts are absent. The same basis
+projection used by the inspection views selects current assertions; provenance is
+read from the retained assertion, never inferred from timestamps or rule source.
+
+HTTP exposes `POST /v1/facts`; operating MCP exposes the read-only `facts` tool with
+the same schema and response. `explain[].evidence.values` contains the selected
+record's values in addition to its ID, type, status, signer and time.
+
+Hosts can supply `canRead({actor, type, subject})` to `open`/`host`. The protocol
+checks it before `status`, `work`, `operations`, `facts` and `explain`, returning
+`forbidden` on denial, including for evidence values. Without the hook, authenticated
+host actors retain the existing trusted read access. Direct subject methods are
+privileged embedding APIs; a host must authenticate and scope access before exposing
+them. This hook does not replace the separate runtime's `ReadAuthority` policy.

package/docs/reference.md

@@ -0,0 +1,258 @@
+# Core world-language reference
+
+A world is a directory of `.forma` files: a library with roles and components, entities
+and an account that binds them, plus scenarios and properties. Start with `worldvm init`;
+loop `worldvm check .`, `worldvm test .`, `worldvm coverage . --mutate`.
+
+Syntax below uses `…` for repetition and `[optional]` for optional syntax; those markers
+are not source. The fenced examples **together form one complete world**, in order.
+Synthetic policy and data; illustrative only. This page is compiled and tested.
+For the deeper guide, see `AUTHORING.md` in the installed package
+(`node_modules/worldvm/AUTHORING.md`). In a scaffold, this file is `REFERENCE.md`; the examples stand alone.
+
+The **core forms** are `source`, `entity`, `evidence`, `component`, `requirement`,
+`action`, `output`, `decision`, `scenario` and `property`. `worldvm check . --core`
+adds an `I_EXTENDED_FORM` info diagnostic at each extended declaration or child form;
+it does not reject a valid world. LSP clients can set `initializationOptions.core: true`. The surrounding declarations shown below (`library`,
+`role`, `interaction`, `layout`, `account`, plus their children) are **extended**.
+All forms outside the ten-name core set are extended, including `attest`, `step`,
+`field`, `sign` and `for-each`; expression calls and scenario data are not declarations.
+
+First declare the library that owns the forms:
+
+```lisp
+(library example.training "Annual safety training." :version "1.0" :subject training/worker)
+```
+
+| Form          | Syntax                                                                                                                            | Common mistakes                                                                                                                             |
+| ------------- | --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
+| `source`      | `(source name "doc" :kind :policy :url "url" :as-of "YYYY-MM-DD")`                                                                | Cite a declared name, not a URL; use a real calendar date.                                                                                  |
+| `role`        | `(role ns/name "doc" {:field Type …})`                                                                                            | Roles describe interfaces, not stored records; include every field components read.                                                         |
+| `entity`      | `(entity Name "doc" :ns :pkg.name :display field :implements {role {role-field field}} {:field Type …})`                          | Namespace must start with the account package; map every role field with the same type.                                                     |
+| `evidence`    | `(evidence Name "doc" :of Component [:expires date-expr] {:field Type …} (attest …))`                                             | Declare it at top level; use `valid` for expiring evidence (`attested` ignores expiry); expiry may only read signed fields and `signed-on`. |
+| `interaction` | `(interaction Name "doc" :actor who :produces Evidence :layout Layout)`                                                           | Actor must resolve to a person or group; evidence fields belong in the evidence declaration.                                                |
+| `layout`      | `(layout Name "doc" (step id "Label" (field field) … (sign)))`                                                                    | Use declared evidence fields; include a signing step for attested evidence.                                                                 |
+| `component`   | `(component Name "doc" :key [input …] :inputs {:input Type …} children …)`                                                        | Put an entity-reference input first in the key; requirements go inside this form; list callable actions/decisions in `:operations`.         |
+| `requirement` | `(requirement name :cites [(source "clause")] [:applies-when truth] :satisfied-by truth)`                                         | Child of a component, never top level; conditions use Kleene Truth with `and`, `or`, `not`; `satisfied?` is false for NotApplicable.        |
+| `action`      | `(action name :advances requirement :assignee who :via (interaction Name))`                                                       | Child of a component; match the interaction actor and signer; an action does not itself set arbitrary facts.                                |
+| `output`      | `(output name (all-of requirement-or-output …))`                                                                                  | Child of a component; `all-of` accepts NotApplicable, unlike conjoining `satisfied?` checks; read locally as `self.name`.                   |
+| `decision`    | `(decision name "doc" :of Component :applies requirement :by who :effect :approve :reason String [:expires duration] :cites […])` | Top level, not a component child; name a requirement of that component; approval requires the declared authority.                           |
+| `account`     | `(account name "doc" :requires {library "version"} :package pkg (for-each role Component))`                                       | Require the exact library version; map roles with entities' `:implements` before running components.                                        |
+| `scenario`    | `(scenario name "doc" :world account (given …) (at "date" …) (do …) …)`                                                           | `:world` names an account; time must advance; `given` is trusted history, `do` exercises command checks.                                    |
+| `property`    | `(property name "doc" :world account :at "date" :for-all (x Entity) predicate)`                                                   | Quantify an entity, not a role; use Bool `and`/`or`/`not` and `=`/`!=` here; a reference is not an assertion.                               |
+
+## Library forms
+
+`source`, `role`, `evidence`, `interaction` and `layout`, respectively:
+
+```lisp
+(source safety-policy "Synthetic annual safety policy."
+  :kind :policy :url "https://example.invalid/safety" :as-of "2026-11-01")
+```
+
+```lisp
+(role training/worker "A worker and their reviewing group." {:name String :reviewers Group})
+```
+
+```lisp
+(evidence Completion "Signed course completion." :of Training
+  :expires (months-after signed-on 12)
+  {:course String}
+  (attest :signer worker :covers :all :method :otp))
+```
+
+Evidence can contain `(rule name :when condition :requires fields)`. The optional
+`:when` reads signed evidence fields and uses three-valued Truth. An omitted condition
+always applies; a false condition skips the rule, and Unknown prevents attestation.
+`:requires` accepts a single `field`, `(one-of a b …)` to require at least one filled
+field, or `(all-of a b …)` to require every listed field. Groups must be nonempty
+and contain declared field names. For example,
+`(rule documents :when (= document-choice :list-b-and-c) :requires (all-of list-b list-c))`
+requires both document fields for that signed choice. The interaction's layout must
+show required fields whenever the rule applies; a `one-of` group needs a visible alternative.
+
+For a signal-driven protocol, declare `(machine Protocol … :signal updated …)` and
+a `(connector provider … :capabilities [] :signals [updated] :owns [Protocol])`.
+An inbound-only connector uses an empty capabilities vector. A `component-contract`
+may omit `:capabilities`; it defaults to `[]`.
+
+```lisp
+(interaction CompletionEntry "Record the finished course."
+  :actor worker :produces Completion :layout CompletionLayout)
+```
+
+An interaction can supply signed evidence fields with `:fixes`, for example
+`:fixes {:examination :remote}` for an evidence field typed `(Union :in-person :remote)`.
+Fixed values must be scalar literals matching the evidence field type. Omit these
+fields from the layout; they count as covered by the interaction. They cannot also
+use `:binds`, `:prefill` or `:proposes`. Conflicting submissions are refused, including
+unsigned drafts. The stored evidence and signature include the fixed values, so
+evidence rules and explanations read them as signed fields. Two actions can share
+one evidence type through different interactions; a remote action can use `:needs`
+to require enrollment before that interaction is eligible.
+
+```lisp
+(layout CompletionLayout "Record and sign."
+  (step record "Record" (field course) (sign)))
+```
+
+`component` contains `requirement`, `action` and `output`. This single fence keeps the
+parentheses and child scope visible:
+
+```lisp
+(component Training "Track one worker's training."
+  :key [worker] :inputs {:worker (Id training/worker)} :operations [complete waive-training]
+  (requirement completed
+    :cites [(safety-policy "1: workers complete training every year")]
+    :satisfied-by (valid Completion))
+  (action complete :advances completed :assignee worker :via (interaction CompletionEntry))
+  (output done (all-of completed)))
+```
+
+Explanations follow the branch that decides a condition, in source order. A passing
+`or` reports the first passing branch and that branch's evidence. A failing `and`
+reports the first failing branch. A failing `or` reports every branch's failure;
+a passing `and` reports every branch's success. Combined details do not select a
+single evidence record. If no `or` branch passes and at least one is Unknown, the
+result is Unknown and the explanation includes the unresolved branches and the
+failed branches. An `and` with no failing branch and at least one Unknown likewise
+reports all branches. Every branch is evaluated, including its dependencies and
+time cutoffs; choosing an explanation does not short-circuit evaluation.
+
+`decision` records a judgment; it affects satisfaction only when a rule reads it with
+`(decided waive-training)`. This example deliberately keeps completion evidence required:
+
+```lisp
+(decision waive-training "Record a reviewer's approval."
+  :of Training :applies completed :by (members worker.reviewers)
+  :effect :approve :reason String :expires (months 6)
+  :cites [(safety-policy "2: reviewers document exceptions")])
+```
+
+## Account and proof
+
+A machine declared inside a component can anchor a case clock:
+`:due (business-days-after (entered-at case :referred) 10 :calendar us-federal)`.
+Declare the calendar and the machine's protocol state. This works for plain signal-driven
+machines, including connector-owned machines, without a resource or a separate date fact.
+`entered-at` returns the UTC Date of the first observation in the latest visit to the state.
+Consecutive duplicate states preserve it; leaving and re-entering resets it. After departure
+the last entry date remains available; before an observed entry it is Unknown. Managed-resource
+machines restrict history to the current acquisition generation. `resource-generation` and
+`attested-for` require a managed resource.
+
+`entity` and `account` bind stored records to the library:
+
+```lisp
+(entity Person "A synthetic worker." :ns :example.person :display name
+  :implements {training/worker {:name name :reviewers reviewers}}
+  {:name String :reviewers Group})
+```
+
+```lisp
+(account example "A synthetic training account."
+  :requires {example.training "1.0"} :package example
+  (for-each training/worker Training))
+```
+
+`scenario` tests missing, current and expired evidence through the action:
+
+```lisp
+(scenario completes-and-expires "Training lasts twelve months." :world example
+  (given (entity Person ana {:name "Ana" :reviewers "Safety"}) (actor ana))
+  (at "2026-11-02" (expect (status (Training ana) completed) :Open))
+  (do (perform (Training ana) complete :by ana :values {:course "Safety 101"}))
+  (at "2026-11-03" (expect (status (Training ana) done) :Satisfied))
+  (at "2027-11-03" (expect (status (Training ana) completed) :Open)))
+```
+
+`property` explores generated worlds at a fixed instant:
+
+```lisp
+(property done-needs-evidence "Completion requires signed evidence."
+  :world example :at "2026-11-03" :for-all (p Person)
+  (given (entity Person p {:name "Synthetic worker" :reviewers "Safety"})
+    (evidence Completion :for (Training p) :requirement completed :by p
+      :values {:course "Safety 101"}))
+  (implies (= (status (Training p) done) :Satisfied)
+    (attested (Training p) Completion)))
+```
+
+An optional `given` block before the predicate uses scenario entity, evidence and
+signal records. It must declare the quantified alias with the quantified entity type.
+Each generated case keeps those entities and explicit facts and varies unspecified
+fields. Seeded evidence and signals are retained; random history does not replace
+the same evidence type or machine on the same occurrence. As in scenarios, `given`
+is trusted history, not an exercise of action eligibility.
+Counterexample shrinking preserves the authored seed facts and records.
+
+`test` and `coverage`, in text and JSON, count the generated cases in which each
+`implies` antecedent was true, once per case even with multiple quantified entities.
+Zero produces `W_PROPERTY_VACUOUS`. This is a warning: vacuity alone does not fail
+either command. A false or Unknown property still fails. Add seed facts and evidence
+that reach the antecedent to test the claim.
+
+Use calendar `(months N)` and `(months-after signed-on N)` for calendar periods. Comparisons use `=` and `!=` everywhere. Logic uses `and`, `or`, `not`: Kleene Truth
+in conditions and ordinary Bool in properties. Write `(and a b)` or `(or a b)`;
+Truth contexts also accept a collection as a single argument. To roll up
+optional requirements use an `all-of` output and read it with `(met? self.done)`.
+`worldvm explain W_ATTESTED_EXPIRING` explains why expiry requires `valid`.
+
+## Structured host reads
+
+The operating protocol exposes `facts` alongside `status`, `work`, `operations` and
+`explain`. Facts include the asserting actor, valid time and retained command ID.
+Work prerequisites are structured addresses derived from IR, with canonical display
+text; evidence prerequisites name their producing requirements. Compound conditions
+remain opaque display reasons. Status includes observed machine states and entry
+times. Explanations include selected evidence values. Hosts can gate subject reads
+with `canRead`; see `docs/protocol.md` in the installed package ("Structured subject reads") for schemas
+and the trusted embedding boundary.
+
+## CLI: impact on a live world
+
+Deploy checked source, then serve the stored release without the source directory:
+
+```sh
+worldvm deploy deployed-world --db world.db --account example
+worldvm serve --db world.db
+# In another terminal, while serve is running (or after it stops):
+worldvm snapshot --db world.db --account example --out snapshot.json
+worldvm impact deployed-world proposed-world --world snapshot.json --at 2026-11-10
+worldvm explain deployed-world --world snapshot.json --subject hire-123 --at 2026-11-10
+```
+
+`snapshot` reads committed state in one read transaction without changing the database.
+`--account` must name the account used by the server. Deploy stores that account with the release.
+Without `--out`, the JSON goes to stdout. The `worldvm/world@1` snapshot contains
+`accounts`, `world` and an optional `release` identifying the release that last wrote
+the records. The evaluation instant is supplied to `impact` or `explain` with `--at`.
+
+Stop `serve` before deploying another release. One process per SQLite file is required;
+a busy SQLite write lock is refused with a message to stop `serve`, but an idle server
+cannot be detected. Snapshot export is a read-only exception to this rule.
+
+```sh
+worldvm deploy proposed-world --db world.db --account example --at 2026-11-10 --dry-run
+worldvm deploy proposed-world --db world.db --account example --at 2026-11-10 --json
+worldvm serve --db world.db --clock 2026-11-11 --ui
+worldvm mcp --db world.db --actor '{"id":"agent:ops","kind":"agent"}'
+```
+
+Deploy refuses the same compile and authoring errors as `check`, before opening SQLite.
+It reports old and new release IDs, requirement and work changes, and every changed
+subject. `--at` controls impact evaluation and defaults to now. `--dry-run` checks and
+previews without changing or creating the database. Deployment retains compiled IR,
+account and deployment timestamp in the `releases` table, in deployment order. The last
+row is active, including when an earlier release is deployed again. Records, receipts
+and proposals are preserved; statuses are recomputed under the new rules, with no data
+migration. The SQLite format is `worldvm/sqlite-store@3`; older files are refused and
+require a new database.
+
+`serve <directory> --db world.db` is a development shortcut for deploy, then serve;
+it requires a world with one account. `serve --db` and `mcp --db` use stored IR.
+Embedders can use `open({ store: sqlite("world.db") })` for the deployed release.
+Explicit `open({ source, store })` still refuses records from another release unless
+`activate: true` is supplied. That embedding option recomputes status and preserves
+records; use CLI deploy to retain deployment history. Time passing requires a tick or
+a later server clock, not another deployment.

package/package.json

@@ -1,6 +1,84 @@
 {
   "name": "worldvm",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
+  "version": "0.1.0",
+  "description": "A requirement runtime for declarative worlds, evidence and actions.",
+  "keywords": [
+    "declarative",
+    "evidence",
+    "requirements",
+    "runtime",
+    "worldvm"
+  ],
+  "homepage": "https://worldvm.com/worldvm/",
+  "license": "UNLICENSED",
+  "bin": {
+    "worldvm": "./bin/worldvm.mjs"
+  },
+  "files": [
+    "bin/worldvm.mjs",
+    "dist/**/*.js",
+    "dist/**/*.d.ts",
+    "dist/ir-schema.json",
+    "AUTHORING.md",
+    "docs/**/*.md",
+    "docs/authoring/**/*.forma"
+  ],
+  "type": "module",
+  "exports": {
+    ".": {
+      "types": "./dist/world.d.ts",
+      "import": "./dist/world.js"
+    },
+    "./sqlite": {
+      "types": "./dist/sqlite.d.ts",
+      "import": "./dist/sqlite.js"
+    },
+    "./serve": {
+      "types": "./dist/serve.d.ts",
+      "import": "./dist/serve.js"
+    },
+    "./cli": {
+      "types": "./dist/cli.d.ts",
+      "import": "./dist/cli.js"
+    },
+    "./authoring": {
+      "types": "./dist/authoring.d.ts",
+      "import": "./dist/authoring.js"
+    },
+    "./diagnostics": {
+      "types": "./dist/diagnostics.d.ts",
+      "import": "./dist/diagnostics.js"
+    },
+    "./durable-object": {
+      "types": "./dist/durable-object.d.ts",
+      "import": "./dist/durable-object.js"
+    },
+    "./ir-schema.json": "./dist/ir-schema.json",
+    "./http": {
+      "types": "./dist/http.d.ts",
+      "import": "./dist/http.js"
+    }
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "devDependencies": {
+    "@worldvm/forma": "0.0.0",
+    "@worldvm/forma-tools": "0.0.0",
+    "@worldvm/protocol": "0.0.0",
+    "@worldvm/reconciler": "0.0.0"
+  },
+  "peerDependencies": {
+    "@forma-language/forma": "^0.6.0",
+    "effect": "^4.1.1"
+  },
+  "engines": {
+    "node": ">=22.5.0"
+  },
+  "scripts": {
+    "build": "tsc -p tsconfig.json && node scripts/bundle-internal.mjs && node scripts/copy-docs.mjs",
+    "typecheck": "tsc -p tsconfig.check.json",
+    "test": "vitest run --no-file-parallelism --testTimeout=20000",
+    "docs:catalogue": "node scripts/authoring-catalogue.mjs"
+  }
 }