@vmz/plugin 0.0.2 → 0.0.4

package/README.md

@@ -14,19 +14,19 @@ assets without forcing every project to adopt a bespoke compiler fork.
 
 ## The promise to application authors
 
-An extension must not make the application opaque. A VMZ plugin is not an unrestricted `transform(code)` escape hatch
-and not an invitation to mutate the compiler's program graph in place. Contributions are versioned and declared so VMZ
-can continue to reason about ownership, execution placement, SSR, resume, testing, diagnostics, and deployment.
+Extensions stay transparent to the application model. A VMZ plugin is a versioned contribution surface — not an
+unrestricted `transform(code)` escape hatch or an in-place rewrite of the program graph. Declared contributions keep
+ownership, execution placement, SSR, resume, testing, diagnostics, and deployment explainable.
 
 This is the tradeoff: plugin authors gain a stable way to participate in VMZ, while users retain a coherent application
 model after installing the plugin. If an integration requires arbitrary runtime injection or hidden semantic rewrites,
 it belongs outside the core VMZ plugin contract.
 
-| A plugin should contribute...                      | A plugin should not become...                            |
-|----------------------------------------------------|----------------------------------------------------------|
-| A declared capability with known inputs and output | A hidden second application runtime                      |
-| Versioned integration behavior                     | An unrestricted semantic rewrite                         |
-| Assets or adapters VMZ can place and test          | A way around server, lifecycle, or deployment boundaries |
+| A plugin contributes...                            | So that VMZ can still...                           |
+|----------------------------------------------------|----------------------------------------------------|
+| A declared capability with known inputs and output | Keep one application runtime and Program Graph     |
+| Versioned integration behavior                     | Explain ownership, placement, and diagnostics      |
+| Assets or adapters VMZ can place and test          | Honor server, lifecycle, and deployment boundaries |
 
 ## Who should use it
 
@@ -44,10 +44,14 @@ compiler-visible boundaries.
 
 ## Why contribution beats mutation
 
-Mutation is convenient for the first plugin and expensive for the fiftieth. If every plugin can rewrite any source, graph node, or generated artifact, composition order becomes application semantics and no tool can explain the final result.
+Mutation is convenient for the first plugin and expensive for the fiftieth. If every plugin can rewrite any source,
+graph node, or generated artifact, composition order becomes application semantics and no tool can explain the final
+result.
 
-A contribution says what capability is being added, which versioned schema it follows, what it reads, what it emits, and where it may execute. That extra structure is what allows npm extensibility and strong compilation to coexist.
+A contribution says what capability is being added, which versioned schema it follows, what it reads, what it emits, and
+where it may execute. That extra structure is what allows npm extensibility and strong compilation to coexist.
 
 ## The litmus test
 
-If installing the plugin makes `vmz check`, SSR, resume, tests, or deployment less able to explain the application, the integration is using the wrong boundary. A native plugin should leave VMZ more capable, not less coherent.
+If installing the plugin makes `vmz check`, SSR, resume, tests, or deployment less able to explain the application, the
+integration is using the wrong boundary. A native plugin should leave VMZ more capable, not less coherent.

package/index.d.ts

@@ -97,6 +97,45 @@ export interface VmzEngines {
 export interface VmzUserConfig {
     plugins?: Array<string | VmzPlugin | Promise<VmzPlugin>>;
     engines?: VmzEngines;
+    /** Application identity (optional authoring). */
+    application?: { id?: string; [key: string]: unknown };
+    /**
+     * Site delivery (SiteDeliveryContract authoring). Pure data only.
+     * Prefer `defineSite(...)` helper; never a parallel `vmz.site.ts` entry.
+     */
+    delivery?: SiteDeliveryAuthoring;
+}
+
+/** Authoring shape for `defineConfig({ delivery })` — normalized at build to SiteDeliveryContract. */
+export interface SiteDeliveryAuthoring {
+    artifact: string;
+    siteId?: string;
+    sources: Array<{
+        id: string;
+        kind: 'embedded' | 'filesystem' | 'remote';
+        directory?: string;
+        baseUrl?: string;
+        artifact?: string;
+        trust?: string;
+        timeoutMs?: number;
+        priority?: number;
+        integrity?: unknown;
+        signaturePolicy?: string;
+    }>;
+    resolution?: {
+        mode?: 'release';
+        fallback?: string[];
+    };
+    activation?: 'atomic';
+    expectedCompatibility?: unknown;
+    failure?: unknown;
+    failurePolicy?: unknown;
+    update?: unknown;
+    updatePolicy?: unknown;
+    rollback?: unknown;
+    rollbackPolicy?: unknown;
+    security?: unknown;
+    securityPolicy?: unknown;
 }
 
 export type DefinePluginInput = PluginManifest & {

package/index.js

@@ -1,6 +1,5 @@
 /**
  * @vmz/plugin — protocol helpers (no N-API).
- * Design: 规划设计/vmz/14-Node-NAPI与插件宿主.md
  */
 
 import { createHash } from 'node:crypto';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vmz/plugin",
-  "version": "0.0.2",
+  "version": "0.0.4",
   "type": "module",
   "description": "VMZ plugin protocol types and definePlugin / defineConfig helpers (no N-API)",
   "license": "MIT",
@@ -18,7 +18,7 @@
     "README.md"
   ],
   "dependencies": {
-    "@vmz/protocol": "0.0.2"
+    "@vmz/protocol": "0.0.4"
   },
   "keywords": [
     "vmz",