@tomflow/proflow-platform-cli 0.1.19 → 0.1.20

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,11 @@
1
1
  # @tomflow/proflow-platform-cli
2
2
 
3
+ ## 0.1.20
4
+
5
+ ### Patch Changes
6
+
7
+ - Close the frozen seven-command contract: enforce start and install safety gates, align Module result semantics and published documentation, and refresh current test evidence.
8
+
3
9
  ## 0.1.19
4
10
 
5
11
  ### Patch Changes
package/README.md CHANGED
@@ -1,64 +1,68 @@
1
1
  # @tomflow/proflow-platform-cli
2
2
 
3
- Deterministic Workspace-level CLI for ProFlow Platform installation, discovery, knowledge aggregation and lifecycle dispatch.
3
+ Thin Workspace-level orchestration CLI for ProFlow package discovery, dependency ordering, command forwarding, result aggregation and package-manager operations.
4
4
 
5
- ## Frozen CLI
5
+ ## Standard CLI
6
+
7
+ The top-level management surface is exactly seven commands:
6
8
 
7
9
  ```bash
8
- platform modules
9
- platform docs
10
10
  platform install
11
11
  platform uninstall
12
+ platform status
13
+ platform setup
14
+ platform docs
12
15
  platform start
13
16
  platform stop
14
17
  ```
15
18
 
16
- Removed top-level commands: `search`, `plan`, `apply`, `upgrade`, `preflight`, `restart`, `status`, `verify`, `doctor`, `manifest`.
19
+ Removed Platform routes such as `modules`, `preflight`, `verify`, `doctor`, `restart`, `plan`, `apply`, `upgrade` and `manifest` are not routable. Module-specific commands remain owned by their Module and are not proxied by Platform.
20
+
21
+ All seven commands accept `--workspace <path>`; without it, the CLI uses `process.cwd()`.
17
22
 
18
23
  ## Ownership
19
24
 
20
25
  ```text
21
- Module / package owns logic and truth.
22
- Platform CLI owns discovery, dispatch, aggregation and ordering.
23
- Package manager owns npm dependency operations.
26
+ Module owns its behavior, private configuration and operational truth.
27
+ Platform owns discovery, dependency ordering, invocation, aggregation and package-manager orchestration.
28
+ Package manager owns npm dependency mutation.
24
29
  ```
25
30
 
26
- ## Workspace
27
-
28
- `platform install [--workspace <path>]` resolves the explicit workspace or `process.cwd()`. The other five commands operate on `process.cwd()` and do not depend on a global current-workspace binding.
31
+ Platform does not interpret Module-private configuration or recreate a cross-Module configuration bus.
29
32
 
30
- `.proflow` is Workspace/user data and may survive uninstall/reinstall. `platform uninstall` removes ProFlow package dependencies only and never deletes `.proflow`.
33
+ ## Install / Uninstall
31
34
 
32
- ## Install
35
+ `platform install` validates or creates the minimal Workspace metadata, discovers the complete governed package set from the Registry, synchronizes that set, validates the installed descriptors, then invokes `Module.install` in dependency order. It does not perform human setup work.
33
36
 
34
- Install dynamically discovers the complete managed ProFlow package/version set from the private npm scope, synchronizes it in one package-manager transaction where possible, re-observes installed packages, validates descriptors, then initializes/reuses minimal Workspace-local metadata.
37
+ `platform uninstall` invokes `Module.uninstall` in reverse dependency order before package removal. `.proflow` is Workspace/user data and is preserved unless an owning Module explicitly removes its own artifacts.
35
38
 
36
- There is no Core package class, `installRequires`, install closure, Plan/Apply or independent Upgrade flow.
39
+ ## Status
37
40
 
38
- ## Modules
39
-
40
- `platform modules` aggregates Module-owned status observations only:
41
+ `platform status` validates and aggregates only Module-owned observations:
41
42
 
42
43
  ```text
43
- moduleRef
44
- version
45
- configStatus: READY | INCOMPLETE | INVALID
46
- missingConfig? # only when INCOMPLETE
47
- runtimeStatus: RUNNING | STOPPED | FAILED | UNKNOWN
44
+ setupStatus: READY | ACTION_REQUIRED | FAILED
45
+ runtimeStatus: RUNNING | STOPPED | FAILED | NOT_APPLICABLE
48
46
  ```
49
47
 
50
- Platform does not infer private health/config/runtime facts.
48
+ There is no Platform-derived configuration status, missing-input list, overall readiness or verification state.
49
+
50
+ ## Setup
51
+
52
+ `platform setup` scans all discovered Modules in dependency order. It skips `READY` Modules, invokes `Module.setup` for every non-ready Module, continues after `ACTION_REQUIRED` or `FAILED`, and returns one complete aggregate.
53
+
54
+ Targeted `platform setup --module <moduleRef> --input '<json>'` forwards opaque input to the owning Module. Platform neither interprets that input nor creates Module-specific instructions.
51
55
 
52
56
  ## Docs
53
57
 
54
- `platform docs` aggregates each installed Module's `provides`, `requires`, `configSlots` and static documentation. It accepts no module/document positional argument.
58
+ `platform docs` invokes and aggregates `Module.docs`. `DOCS.md` and `SETUP.md` remain Module-owned knowledge.
55
59
 
56
60
  ## Start / Stop
57
61
 
58
- Start builds Runtime dependency order from `provides/requires`, dispatches all applicable Module validate/preflight first (fail-fast), then starts in dependency order (fail-fast). It does not rollback already-started Modules.
62
+ `platform start` first completes the dependency-ordered `Module.status` setup gate. If any applicable Module has `setupStatus != READY`, no `Module.start` call is made. Once every Module is ready, starts run in dependency order and fail fast. A start failure does not trigger automatic rollback.
59
63
 
60
- Stop dispatches Module stop in reverse dependency order and fails fast.
64
+ `platform stop` invokes `Module.stop` in reverse dependency order and fails fast.
61
65
 
62
66
  ## Boundary
63
67
 
64
- The CLI must remain thin: new compliant Modules should become discoverable/observable/startable without adding module-specific business logic here.
68
+ The CLI remains a thin, generic orchestration layer. Adding a conforming Module must not require Module-specific Platform business logic.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@tomflow/proflow-platform-cli",
3
- "version": "0.1.19",
3
+ "version": "0.1.20",
4
4
  "type": "module",
5
5
  "publishConfig": {
6
6
  "access": "public"
@@ -23,7 +23,7 @@
23
23
  "SETUP.md"
24
24
  ],
25
25
  "dependencies": {
26
- "@tomflow/proflow-module-contract": "^0.1.5"
26
+ "@tomflow/proflow-module-contract": "^0.1.6"
27
27
  },
28
28
  "devDependencies": {
29
29
  "@tomflow/proflow-module-template": "^0.1.5",
@@ -3,7 +3,7 @@
3
3
  "contractVersion": "1.0.0",
4
4
  "moduleRef": "platform-cli",
5
5
  "packageName": "@tomflow/proflow-platform-cli",
6
- "moduleVersion": "0.1.19",
6
+ "moduleVersion": "0.1.20",
7
7
  "kind": "cli",
8
8
  "templateVersion": "1.0.0",
9
9
  "platformCompatibility": ">=1.0.0 <2.0.0",