@lumenflow/cli 5.7.17 → 5.7.18

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@lumenflow/cli",
3
- "version": "5.7.17",
3
+ "version": "5.7.18",
4
4
  "description": "Command-line interface for LumenFlow workflow framework",
5
5
  "keywords": [
6
6
  "lumenflow",
@@ -201,16 +201,16 @@
201
201
  "xstate": "^5.28.0",
202
202
  "yaml": "^2.8.2",
203
203
  "zod": "^4.3.6",
204
- "@lumenflow/initiatives": "5.7.17",
205
- "@lumenflow/agent": "5.7.17",
206
- "@lumenflow/control-plane-sdk": "5.7.17",
207
- "@lumenflow/core": "5.7.17",
208
- "@lumenflow/host": "^5.7.17",
209
- "@lumenflow/memory": "5.7.17",
210
- "@lumenflow/kernel": "5.7.17",
211
- "@lumenflow/packs-software-delivery": "^5.7.17",
212
- "@lumenflow/metrics": "5.7.17",
213
- "@lumenflow/packs-agent-runtime": "^5.7.17"
204
+ "@lumenflow/agent": "5.7.18",
205
+ "@lumenflow/kernel": "5.7.18",
206
+ "@lumenflow/control-plane-sdk": "5.7.18",
207
+ "@lumenflow/core": "5.7.18",
208
+ "@lumenflow/initiatives": "5.7.18",
209
+ "@lumenflow/host": "^5.7.18",
210
+ "@lumenflow/memory": "5.7.18",
211
+ "@lumenflow/metrics": "5.7.18",
212
+ "@lumenflow/packs-agent-runtime": "^5.7.18",
213
+ "@lumenflow/packs-software-delivery": "^5.7.18"
214
214
  },
215
215
  "devDependencies": {
216
216
  "@vitest/coverage-v8": "^4.0.18",
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@lumenflow/packs-agent-runtime",
3
- "version": "5.7.17",
3
+ "version": "5.7.18",
4
4
  "description": "Agent runtime pack scaffold for LumenFlow — governed model-turn execution, pack config, and provider capability baselines",
5
5
  "keywords": [
6
6
  "lumenflow",
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@lumenflow/packs-sidekick",
3
- "version": "5.7.17",
3
+ "version": "5.7.18",
4
4
  "description": "Sidekick personal assistant pack for LumenFlow — 16 tools for task management, typed memory, channels, routines, and audit",
5
5
  "keywords": [
6
6
  "lumenflow",
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@lumenflow/packs-software-delivery",
3
- "version": "5.7.17",
3
+ "version": "5.7.18",
4
4
  "description": "Software delivery pack for LumenFlow — work units, gates, lanes, initiatives, and agent coordination",
5
5
  "keywords": [
6
6
  "lumenflow",
@@ -45,6 +45,23 @@ pnpm lumenflow --client <claude-code | cursor | windsurf>
45
45
 
46
46
  At this point `workspace.yaml` exists but is **untracked**. This is the trap.
47
47
 
48
+ ### Existing LumenFlow Projects: Upgrade First
49
+
50
+ If the project already has LumenFlow files and package dependencies, do not reinstall or
51
+ manually edit dependency versions. Run the managed upgrade command from the integration
52
+ checkout:
53
+
54
+ ```bash
55
+ pnpm lumenflow:upgrade --latest
56
+ ```
57
+
58
+ After upgrade, `package.json` and `pnpm-lock.yaml` should contain the published
59
+ `@lumenflow/*` packages managed by the command, with `@lumenflow/cli` as the CLI
60
+ entrypoint. The old unscoped `lumenflow` wrapper is private/internal and should not
61
+ remain in consumer dependencies or lockfile entries. If the command reports a
62
+ non-fatal `NPM_TOKEN` config warning, set the token for private registry access or
63
+ remove the stale placeholder from `.npmrc`; a successful install is still valid.
64
+
48
65
  ---
49
66
 
50
67
  ## Step 2: Commit the Baseline Before `lane:setup`
@@ -9,11 +9,16 @@ Use this checklist before running `pnpm wu:create`.
9
9
  ## Step 1: Confirm the Lane
10
10
 
11
11
  ```bash
12
+ pnpm lane:setup --template react-vite # or nextjs | node-cli | fastify
13
+ pnpm lane:validate
14
+ pnpm lane:lock
12
15
  pnpm lane:status
13
16
  pnpm wu:infer-lane --paths "packages/@lumenflow/cli/src/init.ts" --desc "Fix init docs drift"
14
17
  ```
15
18
 
16
- The lane should match the real implementation scope, not just the first file you noticed.
19
+ Omit `--template` when you want LumenFlow to infer the stack from `package.json` and visible
20
+ directories. The lane should match the real implementation scope, not just the first file you
21
+ noticed.
17
22
 
18
23
  ---
19
24
 
@@ -33,17 +38,28 @@ The lane should match the real implementation scope, not just the first file you
33
38
 
34
39
  `--id` is optional. If omitted, `wu:create` allocates the next WU ID automatically.
35
40
 
41
+ For `--exposure ui`, include concrete reachability evidence. User-flow features should use
42
+ `navigation_path`, a page route in `code_paths`, or manual wording like
43
+ `"Open /settings and verify ..."`. UI infrastructure/theme WUs can instead use manual wording like
44
+ `"Run pnpm dev at http://localhost:3000 and confirm the component/theme state"`.
45
+
36
46
  ---
37
47
 
38
48
  ## Step 3: Decide Plan Storage
39
49
 
40
- If the work needs a plan, prefer repo-native or `lumenflow://plans/` references:
50
+ If the work needs a plan, prefer repo-native `lumenflow://plans/` references:
41
51
 
42
52
  ```bash
43
53
  pnpm plan:create --id INIT-XXX --title "Plan title"
44
54
  pnpm wu:create --lane "Framework: CLI" --title "..." --plan
45
55
  ```
46
56
 
57
+ Generated WU plans live in the repository plans directory
58
+ (`software_delivery.directories.plansDir`, default `{{DOCS_OPERATIONS_PATH}}/plans`) so
59
+ the same WU number can exist in separate projects without colliding. Older
60
+ plans under `$LUMENFLOW_HOME/plans` still resolve as a compatibility fallback,
61
+ but new WU work should use repo-local plans.
62
+
47
63
  Avoid pointing `--spec-refs` at random local filesystem notes that other agents cannot resolve.
48
64
 
49
65
  ---