You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AGENTS.md
+13-4Lines changed: 13 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,7 +24,11 @@ All commands use pnpm. Target a single app with `pnpm --filter <package>`.
24
24
25
25
```bash
26
26
pnpm install # Install
27
+
pnpm --filter @nexu/shared build # Build shared dist required by cold-start dev flows
28
+
pnpm dev start # Start the lightweight local stack: openclaw -> controller -> web -> desktop
27
29
pnpm dev start <service># Start one local-dev service: desktop|openclaw|controller|web
30
+
pnpm dev restart # Restart the lightweight local stack
31
+
pnpm dev stop # Stop the lightweight local stack in reverse order
28
32
pnpm dev stop <service># Stop one local-dev service
29
33
pnpm dev restart <service># Restart one local-dev service
30
34
pnpm dev status <service># Show status for one local-dev service
@@ -67,9 +71,13 @@ This repo is desktop-first. Prefer the controller-first path and remove or ignor
67
71
68
72
## Desktop local development
69
73
70
-
- For script-managed local development, use explicit per-service commands only: `pnpm dev start <desktop|openclaw|controller|web>`, `pnpm dev stop <service>`, `pnpm dev restart <service>`, `pnpm dev status <service>`, and `pnpm dev logs <service>`.
71
-
-`pnpm dev` has no implicit aggregate default and intentionally does not support `all`; start each service deliberately in dependency order when you want the full local stack: `openclaw` -> `controller` -> `web` -> `desktop`.
74
+
- Minimal cold-start setup on a fresh machine is: `pnpm install` -> `pnpm --filter @nexu/shared build` -> copy `scripts/dev/.env.example` to `scripts/dev/.env` only if you need dev-only overrides.
75
+
- Default daily flow is: `pnpm dev start` -> `pnpm dev status <service>` / `pnpm dev logs <service>` as needed -> `pnpm dev stop`.
76
+
- Use `pnpm dev restart` for a clean full-stack recycle; use `pnpm dev restart <service>` only when you are intentionally touching one service.
77
+
- Explicit single-service control remains available through `pnpm dev start <desktop|openclaw|controller|web>`, `pnpm dev stop <service>`, `pnpm dev restart <service>`, `pnpm dev status <service>`, and `pnpm dev logs <service>`.
78
+
-`pnpm dev` intentionally does not support `all`; the full local stack order remains `openclaw` -> `controller` -> `web` -> `desktop`.
72
79
-`pnpm dev logs <service>` is session-scoped, prints a fixed header, and tails at most the last 200 lines from the active service session.
80
+
-`scripts/dev/.env.example` is the source-of-truth template for dev-only overrides. Copy it to `scripts/dev/.env` only when you need to override ports, URLs, state paths, or the shared OpenClaw gateway token for local development.
73
81
- Keep the detailed startup optimization rules, cache invalidation behavior, and troubleshooting notes in `specs/guides/desktop-runtime-guide.md`; keep only the core workflow expectations here.
74
82
- The repo also includes a local Slack reply smoke probe at `scripts/probe/slack-reply-probe.mjs` (`pnpm probe:slack prepare` / `pnpm probe:slack run`) for verifying the end-to-end Slack DM reply path after local runtime or OpenClaw changes.
75
83
- The Slack smoke probe is not zero-setup: install Chrome Canary first, then manually log into Slack in the opened Canary window before running `pnpm probe:slack run`.
- Daily local-dev flow: `pnpm dev start` -> `pnpm dev logs <service>` / `pnpm dev status <service>` when needed -> `pnpm dev restart` for a clean recycle -> `pnpm dev stop`
255
265
- OpenClaw managed skills dir (expected default): `~/.openclaw/skills/`
256
266
- Slack smoke probe setup: install Chrome Canary, set `PROBE_SLACK_URL`, run `pnpm probe:slack prepare`, then manually log into Slack in Canary before `pnpm probe:slack run`
257
267
-`openclaw-runtime` is installed implicitly by `pnpm install`; local development should normally not use a global `openclaw` CLI
258
-
- Local service startup order for the script-managed dev path: `pnpm dev start openclaw` -> `pnpm dev start controller` -> `pnpm dev start web` -> `pnpm dev start desktop`
259
-
- Local service shutdown order for the script-managed dev path: `pnpm dev stop desktop` -> `pnpm dev stop web` -> `pnpm dev stop controller` -> `pnpm dev stop openclaw`
268
+
- Full-stack startup order is `openclaw` -> `controller` -> `web` -> `desktop`; shutdown order is the reverse
260
269
- Prefer `./openclaw-wrapper` over global `openclaw` in local development; it executes `openclaw-runtime/node_modules/openclaw/openclaw.mjs`
261
270
- When OpenClaw is started manually, set `RUNTIME_MANAGE_OPENCLAW_PROCESS=false` for `@nexu/controller` to avoid launching a second OpenClaw process
262
271
- If behavior differs, verify effective `OPENCLAW_STATE_DIR` / `OPENCLAW_CONFIG_PATH` used by the running controller process.
Copy file name to clipboardExpand all lines: scripts/dev/AGENTS.md
+15-7Lines changed: 15 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,17 +25,24 @@ This file captures local guidance for the `scripts/dev` CLI surface.
25
25
## Command surface
26
26
27
27
- Keep the command surface small and intentional.
28
-
- Preferred commands are explicit single-service commands: `pnpm dev start <desktop|openclaw|controller|web>`, `pnpm dev restart <service>`, `pnpm dev stop <service>`, `pnpm dev status <service>`, and `pnpm dev logs <service>`.
29
-
- Do not reintroduce implicit aggregate defaults such as bare `pnpm dev start` or an `all` target.
- Daily full-stack flow is: `pnpm dev start` -> work -> `pnpm dev restart` when you need a clean full restart -> `pnpm dev stop` when done.
30
+
- Bare `pnpm dev start` runs the lightweight full local stack in dependency order: `openclaw` -> `controller` -> `web` -> `desktop`.
31
+
- Bare `pnpm dev restart` restarts that stack by stopping in reverse order and starting again in dependency order.
32
+
- Bare `pnpm dev stop` stops that stack in reverse order: `desktop` -> `web` -> `controller` -> `openclaw`.
33
+
- Explicit single-service control remains available: `pnpm dev start <desktop|openclaw|controller|web>`, `pnpm dev restart <service>`, `pnpm dev stop <service>`, `pnpm dev status <service>`, and `pnpm dev logs <service>`.
34
+
- Do not reintroduce an `all` target or any other alias target name.
30
35
- Validate behavior through the real command surface instead of temporary harness scripts.
31
36
- Acceptance must be run from the repo root through `pnpm dev ...`, not by invoking `scripts/dev` internals directly.
32
-
- The default end-to-end acceptance chain is: `pnpm dev start openclaw` -> `pnpm dev logs openclaw` -> `pnpm dev start controller` -> `pnpm dev logs controller` -> `pnpm dev start web`-> `pnpm dev logs web` -> `pnpm dev start desktop` -> `pnpm dev logs desktop` -> stop each service explicitly.
37
+
- The focused acceptance chain is: `pnpm dev start` -> `pnpm dev status <service>` / `pnpm dev logs <service>` as needed -> `pnpm dev stop`.
33
38
34
39
## Runtime model
35
40
36
41
- Root entrypoint stays `pnpm dev ...`.
37
42
- The CLI executes through `pnpm --dir ./scripts/dev exec tsx ./src/index.ts`.
38
43
-`scripts/dev` may use its own `tsconfig.json` features such as `paths`.
44
+
-`scripts/dev/.env.example` is the source-of-truth template for dev-only overrides. Only create `scripts/dev/.env` when you need local overrides for ports, URLs, state paths, config path, log dir, or the shared OpenClaw gateway token.
45
+
- Keep the repo-level pnpm build-script allowlist tight. Do not add Windows-only packaging tools such as `electron-winstaller` unless the team explicitly wants that behavior on every machine.
39
46
- Logs should live under `.tmp/dev/logs/<run_id>/...`.
40
47
-`pnpm dev logs <service>` should resolve the active session only, prepend a fixed metadata header, and tail at most 200 lines by default.
41
48
- Lightweight state should use per-service pid locks under `.tmp/dev/*.pid`.
@@ -53,10 +60,11 @@ This file captures local guidance for the `scripts/dev` CLI surface.
53
60
54
61
## FAQ
55
62
56
-
- Q: `pnpm dev stop <service>` fails because that side is already down. A: This is currently acceptable. Read the matching `.tmp/dev/*.pid`, kill the remaining supervisor manually if needed, remove stale pid locks, then rerun `pnpm dev start <service>` or `pnpm dev restart <service>`.
57
-
- Q: `pnpm dev status <service>` shows `stale`. A: The pid lock still exists but the supervisor pid is no longer alive. Remove the stale `.tmp/dev/*.pid` file and start that service again.
63
+
- Q: A service will not start. A: Start with `pnpm dev status <service>` and `pnpm dev logs <service>`. If the error says a dependency is missing, start that dependency first; if it says a port is busy, kill the listener and retry.
64
+
- Q: `pnpm dev status <service>` shows `stale`. A: The supervisor pid is gone but the lock survived. Prefer `pnpm dev stop <service>` first; if the lock still remains, remove the matching `.tmp/dev/*.pid` file and start again.
58
65
- Q: `pnpm dev logs web` shows `Port 5173 is already in use`. A: A stale Vite process from an earlier experiment is still listening. Kill the listener on `5173`, remove `web.pid` if present, and restart the dev flow.
59
66
- Q: Which pid is stored in each `.tmp/dev/*.pid` file? A: The pid lock stores the supervisor pid, not the transient worker/listener pid. Worker/listener pids are resolved at runtime via snapshots.
60
-
- Q: Where should logs be inspected first? A: Start with `pnpm dev logs <service>` for the active session. If that is not enough, inspect the backing file under `.tmp/dev/logs/<run_id>/...` or `.tmp/logs/desktop-dev.log` for desktop.
67
+
- Q: Where should logs be inspected first? A: Start with `pnpm dev logs <service>` for the active session. If that is not enough, inspect the backing file under `.tmp/dev/logs/<run_id>/...`.
61
68
- Q: How do I correlate a leaked or suspicious process to a specific dev run? A: Start with `sessionId` from `pnpm dev status <service>` or `.tmp/dev/*.pid`, then search process command lines for `--nexu-dev-session=<sessionId>` and `--nexu-dev-service=<service>`.
62
-
- Q: What is the expected worst-case recovery path? A: Kill the known listener/supervisor pid for the affected service, remove the stale `.tmp/dev/*.pid` file, rerun `pnpm dev start <service>`, and if the local environment is still inconsistent, reboot the machine to clear any orphaned OS-level process state.
69
+
- Q: `pnpm install` warns that `electron-winstaller` build scripts were ignored. A: Keep it out of the shared repo allowlist unless Windows packaging support is intentionally being enabled for the whole team. Use per-machine approval when only one Windows environment needs it.
70
+
- Q: What is the expected worst-case recovery path? A: Run `pnpm dev stop`, kill any leftover listener/supervisor pid for the affected service, remove stale `.tmp/dev/*.pid` files, then run `pnpm dev start` again.
0 commit comments