@lenso/cli 0.1.30 → 0.2.9

package/README.md

@@ -93,6 +93,119 @@ lenso service dev
 installed services from `.lenso/module-services.json`, then runs the host.
 Workspace reads prefer `lenso.workspace.json` and also accept the older
 `.lenso/services.json` path for compatibility.
+
+For a System v2 graph containing multiple Autonomous Services, use the
+clusterless System Sandbox on macOS or Linux:
+
+```sh
+lenso system dev --dry-run --json
+lenso system dev
+lenso system dev --scenario deadline-timeout --json
+lenso system dev --cleanup
+```
+
+The System graph remains in `lenso.system.json`. Local-only executable details
+live beside it in `lenso.system-sandbox.json`:
+
+```json
+{
+  "protocol": "lenso.system-sandbox.v1",
+  "services": [{
+    "serviceId": "support",
+    "workloads": [{
+      "workloadId": "support-migrate",
+      "command": ["cargo", "run", "--bin", "support-migrate"]
+    }, {
+      "workloadId": "support-api",
+      "command": ["cargo", "run", "--bin", "support-api"],
+      "scenarioCommand": ["cargo", "run", "--bin", "support-scenario-driver"],
+      "endpoint": "http://127.0.0.1:4110",
+      "healthUrl": "http://127.0.0.1:4110/health/ready"
+    }, {
+      "workloadId": "support-worker",
+      "command": ["cargo", "run", "--bin", "support-worker"]
+    }]
+  }],
+  "scenarios": [{
+    "scenarioId": "deadline-timeout",
+    "fault": {
+      "kind": "timeout",
+      "serviceId": "support",
+      "workloadId": "support-api",
+      "delayMs": 100
+    },
+    "callPolicy": {
+      "deadlineMs": 100,
+      "maxAttempts": 2,
+      "idempotent": true
+    }
+  }]
+}
+```
+
+Failure controls are inert during ordinary startup and dry-run. They are read
+only from the local System Sandbox definition and activated only when an
+explicit `--scenario <scenarioId>` is supplied. Supported fault kinds are
+`timeout`, `slow_dependency`, `workload_crash`, `overload`, and
+`partial_unavailability`. Timeout and slow-dependency decisions use controlled
+scenario time; overload uses declared `capacity` and `demand`, never machine
+pressure.
+
+Timeout, slow-dependency, and overload scenarios require the affected
+Workload's `scenarioCommand`. The Sandbox invokes that Workload-owned adapter
+only for an explicit scenario, supplies `LENSO_SANDBOX_*` controlled-time,
+fault, capacity, and Call Policy inputs, and accepts one
+`lenso.sandbox-workload-observation.v1` JSON result. The adapter exercises the
+Service's real local call or dependency path; normal Workload startup never
+receives those failure-control inputs.
+
+Each run emits `lenso.failure-scenario-result.v1` JSON, performs Sandbox-owned
+process and state cleanup, and writes the equivalent durable Story Segment to
+`.lenso/system-sandbox-results/<systemId>/<scenarioId>/story-segment.json`.
+Results include the injected fault, affected Service and Workload, attempt and
+retry evidence, Call Policy and health transitions, outcome, cleanup, and next
+actions. Repeating the same declared scenario overwrites that evidence with an
+equivalent result.
+
+Dry-run performs the same definition, cwd, executable, URL, graph, and
+dependency validation as launch without creating Store directories, state, or
+processes. Launch assigns each Workload an explicit `local-dev://` identity,
+allocates one sandbox-owned Store path per Service, waits for declared health,
+and records correlated endpoint and process state under
+`.lenso/system-sandbox/<systemId>`. This identity is development-only and
+does not claim production authentication. Ctrl-C and `--cleanup` terminate
+only token-proven sandbox processes or their process groups, and remove state
+only when its ownership marker
+matches; Kubernetes, a Host, service mesh, external broker, System Plane, and a
+production identity provider are not required.
+Host and Provider declarations may remain in the System graph for topology
+validation, but the sandbox neither starts nor contacts them.
+
+## Assess linked Module extraction
+
+Report whether one Host-owned linked Module is ready to move behind an
+Autonomous Service boundary:
+
+```sh
+lenso module extraction readiness support-ticket \
+  --module-manifest modules/support-ticket/lenso.module.json \
+  --system-file lenso.system.json \
+  --evidence-file support-ticket.extraction-evidence.json \
+  --json
+```
+
+The CLI scans Rust Module Cargo dependencies, imports, and fully qualified
+in-process calls under `modules/`. The evidence file supplies authoritative
+Service/Event Contract mappings and active Consumer compatibility results;
+omitting or supplying ambiguous evidence produces a blocked report. Human and
+JSON output come from the same `lenso.extraction-readiness-report.v1` artifact.
+Blocked reports exit non-zero so the command can gate CI.
+
+Readiness analysis is read-only: it does not write repository files, start
+Workloads, move data, or change authority. Use `--repo-root` and
+`--modules-root` when the Module sources are not under the current repository's
+default `modules/` directory.
+
 Generated TS and Rust services also support `--check-release` to print the
 development module release descriptor before packaging.
 Before handing a service to another app or deployment pipeline, package-check
@@ -364,3 +477,31 @@ descriptors with a `source` field for new installs.
 lenso module install auth --source linked
 lenso module uninstall auth --source linked
 ```
+
+## M6 GA support operations
+
+The GA commands consume exact versioned evidence and never infer compatibility
+from nearby semantic versions:
+
+```sh
+lenso ga support-check --manifest lenso.ga-support-manifest.v1.json \
+  --component cli:@lenso/cli@0.1.30 \
+  --component runtime:lenso-service@0.1.4 \
+  --state-version service-store.v1 --json
+
+lenso ga manifest-migrate --manifest lenso.ga-support-manifest.v1.json \
+  --source lenso.system.json --target-format lenso.system.v2 \
+  --identity-pointer /systemId --dry-run --json
+
+lenso ga service-upgrade --manifest lenso.ga-support-manifest.v1.json \
+  --input service-upgrade-input.json --json
+
+lenso ga contract-retire --input contract-retirement-input.json --json
+lenso ga failure-evaluate --input failure-scenario.json --json
+```
+
+Manifest migration and Service upgrade are non-mutating plans by default.
+Contract Retirement does not apply without an exact human approval bound to
+the current plan digest. Unknown combinations, stale inputs, active Consumers,
+incomplete deprecation windows, incompatible state, and unexpected failure
+behavior stop with stable issue codes and next actions.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenso/cli",
-  "version": "0.1.30",
+  "version": "0.2.9",
   "description": "Lenso command-line interface for scaffolding and operating Lenso backend projects.",
   "license": "MIT",
   "homepage": "https://github.com/LioRael/lenso-cli",
@@ -18,14 +18,23 @@
   "scripts": {
     "check:npm-publish": "node scripts/check-npm-publish.mjs",
     "check:npm-shim": "node scripts/check-npm-shim.mjs",
+    "check:release-versions": "node scripts/check-release-versions.mjs",
+    "install:hosted-console": "node scripts/install-hosted-console.mjs",
     "package:npm": "node scripts/package-npm.mjs",
     "prepack": "node scripts/package-npm.mjs",
-    "prepublishOnly": "node scripts/check-npm-publish.mjs"
+    "prepublishOnly": "node scripts/check-npm-publish.mjs",
+    "release:intent-check": "node scripts/release-plan.mjs --check-intent",
+    "release:plan": "node scripts/release-plan.mjs",
+    "release:verify": "npm run check:release-versions && node scripts/release-plan.mjs --verify"
+  },
+  "devDependencies": {
+    "tegami": "1.2.5"
   },
   "publishConfig": {
     "access": "public"
   },
   "engines": {
     "node": ">=18"
-  }
+  },
+  "packageManager": "pnpm@11.7.0"
 }