oomi-ai 0.2.49 → 0.2.50

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/README.md CHANGED
@@ -299,22 +299,23 @@ oomi personas scaffold market-analyst --name "Market Analyst" --description "Pri
299
299
 
300
300
  Use:
301
301
  - `oomi personas create <id>` only for repo-local manifest work, not for the normal managed Oomi persona flow
302
- - `oomi personas create-managed --name "Cooking Persona" --description "Private cooking workspace"` for the end-to-end Oomi-managed persona flow
302
+ - `oomi personas create-managed <slug>` to create the backend managed persona record before launch or runtime registration
303
303
  - `oomi personas scaffold <slug>` for an XR-first WebSpatial Oomi app shell with runtime metadata and health documents
304
304
  - `oomi persona-jobs execute --message-file <job.json>` when OpenClaw receives a structured persona orchestration job from Oomi
305
-
306
- Additional persona runtime commands:
307
-
308
- ```bash
309
- oomi personas launch-managed market-analyst --name "Market Analyst" --description "Private app for reviewing my broker positions and risk."
305
+
306
+ Managed runtime and recovery commands:
307
+
308
+ ```bash
309
+ oomi personas launch-managed market-analyst --workspace-root ~/.openclaw/workspace/personas --force-install --json
310
310
  oomi personas status market-analyst
311
311
  oomi personas stop market-analyst
312
312
  oomi personas delete market-analyst
313
+ # recovery only, after create-managed already exists
313
314
  oomi personas runtime-register market-analyst --local-port 4789
314
315
  oomi personas heartbeat market-analyst --local-port 4789
315
- oomi persona-jobs start pj_123
316
+ oomi persona-jobs start pj_123
316
317
  oomi persona-jobs succeed pj_123 --workspace-path ~/.openclaw/workspace/personas/market-analyst --local-port 4789
317
- oomi persona-jobs fail pj_123 --code JOB_FAILED --message "Scaffold generation failed."
318
+ oomi persona-jobs fail pj_123 --code JOB_FAILED --message "Scaffold generation failed."
318
319
  ```
319
320
 
320
321
  Notes:
@@ -324,16 +325,83 @@ Notes:
324
325
  - If you pass `--endpoint` explicitly, it should be a LAN or relay URL that the client can actually open.
325
326
  - The scaffolded XR route should default directly into a mounted scene component that calls `configurePersonaScene()`, logs `detectSpatialEnvironment()`, and renders multiple authored `enable-xr` panels.
326
327
  - The browser route should remain valid, but the XR entry path should not fall back to a flat marketing or home page.
328
+ - Do not use manual `npm run dev` as the first-time persona launch path for managed Oomi personas.
327
329
 
328
- Recommended agent flow:
329
-
330
- ```bash
331
- oomi personas create-managed --name "Cooking Persona" --description "Private cooking workspace for recipes, meal planning, and kitchen notes."
332
- ```
333
-
334
- That command creates the managed persona record in Oomi using the linked device identity. The backend then enqueues the `persona_job`, and the running bridge consumes that job automatically. The poll path is filtered to `metadata.type = persona_job`, so it does not consume normal queued chat traffic.
335
-
336
- If you want to explicitly host or reuse the persona app on the OpenClaw machine outside the queued-job path, use:
330
+ Exact managed persona creation order:
331
+
332
+ ```bash
333
+ export WORKSPACE_ROOT="$HOME/.openclaw/workspace/personas"
334
+ export SLUG="tokyo-guide"
335
+ export NAME="Tokyo Guide"
336
+ export DESCRIPTION="Personal travel assistant for Tokyo trip planning - itineraries, food, culture, and summer tips for July"
337
+
338
+ # 1. Scaffold the local app workspace
339
+ oomi personas scaffold "$SLUG" \
340
+ --name "$NAME" \
341
+ --description "$DESCRIPTION" \
342
+ --out "$WORKSPACE_ROOT/$SLUG" \
343
+ --force
344
+
345
+ # 2. Verify scaffold actually wrote files
346
+ test -f "$WORKSPACE_ROOT/$SLUG/persona.json"
347
+ test -f "$WORKSPACE_ROOT/$SLUG/oomi.runtime.json"
348
+ test -f "$WORKSPACE_ROOT/$SLUG/package.json"
349
+
350
+ # 3. Create the backend persona record first
351
+ oomi personas create-managed "$SLUG" \
352
+ --name "$NAME" \
353
+ --description "$DESCRIPTION" \
354
+ --json
355
+
356
+ # 4. Launch the managed runtime and register it with Oomi
357
+ oomi personas launch-managed "$SLUG" \
358
+ --workspace-root "$WORKSPACE_ROOT" \
359
+ --force-install \
360
+ --json
361
+
362
+ # 5. Verify local runtime state exists
363
+ test -f "$WORKSPACE_ROOT/$SLUG/.oomi/runtime.json"
364
+ cat "$WORKSPACE_ROOT/$SLUG/.oomi/runtime.json"
365
+
366
+ # 6. Verify Oomi-local status
367
+ oomi personas status "$SLUG" --json
368
+
369
+ # 7. Send a heartbeat using the actual assigned port
370
+ PORT="$(jq -r '.localPort' "$WORKSPACE_ROOT/$SLUG/.oomi/runtime.json")"
371
+ oomi personas heartbeat "$SLUG" \
372
+ --local-port "$PORT" \
373
+ --json
374
+ ```
375
+
376
+ Rules for that flow:
377
+
378
+ - scaffold first
379
+ - verify scaffold wrote files before backend creation
380
+ - create-managed before any runtime registration or heartbeat
381
+ - launch-managed instead of manual `npm run dev`
382
+ - heartbeat only after `.oomi/runtime.json` exists
383
+ - fail fast if any `--json` command does not return success
384
+ - never treat local runtime success as backend registration success
385
+
386
+ Do not do this for first-time creation:
387
+
388
+ ```bash
389
+ oomi personas runtime-register "$SLUG" --local-port 4791
390
+ oomi personas launch-managed "$SLUG"
391
+ npm run dev &
392
+ ```
393
+
394
+ That sequence is wrong because `runtime-register` and `heartbeat` assume the backend persona already exists, `launch-managed` only auto-creates when the persona is missing and `--name` is present, and manual `npm run dev` bypasses the managed runtime state contract.
395
+
396
+ Queued-job shortcut:
397
+
398
+ ```bash
399
+ oomi personas create-managed cooking-persona --name "Cooking Persona" --description "Private cooking workspace for recipes, meal planning, and kitchen notes."
400
+ ```
401
+
402
+ Use that shortcut only when the backend and running bridge are already set up to consume the queued `persona_job` automatically. Do not confuse it with the explicit scaffold + launch flow above.
403
+
404
+ If you want to explicitly host or reuse the persona app on the OpenClaw machine outside the queued-job path, use:
337
405
 
338
406
  ```bash
339
407
  oomi personas launch-managed cooking-persona --entry-url https://your-relay.example/oomi/cooking-persona
@@ -203,12 +203,29 @@ For persona app work, treat the scaffold as a runtime contract, not a disposable
203
203
 
204
204
  When a user asks you in chat to create a new persona for Oomi:
205
205
 
206
- 1. Prefer `oomi personas create-managed --name "<name>" --description "<description>"`.
207
- 2. That is the primary end-to-end command for agent-driven persona creation.
208
- 3. It creates the managed persona record in Oomi and relies on the running bridge to consume the queued `persona_job` automatically.
209
- 4. Do not manually scaffold first unless you are recovering a failed persona job or working outside the queued Oomi flow.
206
+ 1. First clarify the persona `name`, `slug`, `description`, permissions, tools, and the ideal work surface.
207
+ 2. After that, use this exact manual creation order on the OpenClaw machine:
208
+ - `export WORKSPACE_ROOT="$HOME/.openclaw/workspace/personas"`
209
+ - `export SLUG="<persona-slug>"`
210
+ - `export NAME="<persona-name>"`
211
+ - `export DESCRIPTION="<persona-description>"`
212
+ - `oomi personas scaffold "$SLUG" --name "$NAME" --description "$DESCRIPTION" --out "$WORKSPACE_ROOT/$SLUG" --force`
213
+ - `test -f "$WORKSPACE_ROOT/$SLUG/persona.json"`
214
+ - `test -f "$WORKSPACE_ROOT/$SLUG/oomi.runtime.json"`
215
+ - `test -f "$WORKSPACE_ROOT/$SLUG/package.json"`
216
+ - `oomi personas create-managed "$SLUG" --name "$NAME" --description "$DESCRIPTION" --json`
217
+ - `oomi personas launch-managed "$SLUG" --workspace-root "$WORKSPACE_ROOT" --force-install --json`
218
+ - `test -f "$WORKSPACE_ROOT/$SLUG/.oomi/runtime.json"`
219
+ - `cat "$WORKSPACE_ROOT/$SLUG/.oomi/runtime.json"`
220
+ - `oomi personas status "$SLUG" --json`
221
+ - `PORT="$(jq -r '.localPort' "$WORKSPACE_ROOT/$SLUG/.oomi/runtime.json")"`
222
+ - `oomi personas heartbeat "$SLUG" --local-port "$PORT" --json`
223
+ 3. Fail fast if scaffold verification fails or if any `--json` command does not return success.
224
+ 4. Treat backend registration as incomplete until `create-managed`, `launch-managed`, `status`, and `heartbeat` all succeed.
210
225
  5. Do not present a localhost URL like `http://127.0.0.1:4789` as the final persona runtime URL for Oomi clients.
211
- 6. If you need to inspect or repair runtime registration manually, prefer `oomi personas launch-managed <slug>` or `oomi openclaw refresh` before dropping to low-level callbacks.
226
+ 6. Do not rely on `launch-managed` auto-creating the backend persona record. Run `create-managed` explicitly first.
227
+ 7. Do not use `oomi personas runtime-register <slug>` or `oomi personas heartbeat <slug>` before `create-managed` succeeds.
228
+ 8. Do not use manual `npm run dev` or any unmanaged dev server as the persona launch path.
212
229
 
213
230
  When generating a managed persona app for Oomi:
214
231
 
@@ -221,11 +238,12 @@ When generating a managed persona app for Oomi:
221
238
  7. Author multiple meaningful XR surfaces with `enable-xr`, `--xr-back`, and `--xr-background-material` values instead of putting one outer `enable-xr` wrapper around the whole page.
222
239
  8. Keep `html.is-spatial` shell styles transparent so the host recedes and the authored panels carry the spatial material.
223
240
  9. Keep `snapdom` and `html2canvas` exposed from `main.tsx` because AndroidXR DOM capture depends on them.
224
- 10. After customization, start the app and register the runtime with Oomi using the current runtime contract.
225
- 11. For normal OpenClaw-hosted persona apps on the same LAN, the runtime registration contract is:
241
+ 10. After customization, bring the persona online through `oomi personas launch-managed <slug> --workspace-root <root> --force-install --json`, then verify `oomi personas status <slug> --json`, then heartbeat using the assigned local port from `.oomi/runtime.json`.
242
+ 11. For normal OpenClaw-hosted persona apps on the same LAN, the managed runtime registration contract is:
226
243
  - backend `entryUrl`: LAN-reachable host such as `http://192.168.x.x:<port>`
227
244
  - backend `healthcheckUrl`: local loopback such as `http://127.0.0.1:<port>/webspatial/avp/oomi.health.json`
228
245
  12. Do not override `--endpoint` with `127.0.0.1` unless the persona is intentionally local-only and not meant to open from Oomi web/XR.
246
+ 13. Do not replace the managed runtime flow with manual `npm run dev`, ad hoc `runtime-register`, or ad hoc `heartbeat` commands during first-time creation.
229
247
 
230
248
  When editing an existing managed persona that is already open in Oomi:
231
249
 
@@ -246,7 +264,8 @@ When executing a structured persona job from Oomi:
246
264
  - `oomi persona-jobs start <jobId>`
247
265
  - `oomi persona-jobs succeed <jobId> --workspace-path <path> --local-port 4789`
248
266
  - `oomi persona-jobs fail <jobId> --code <code> --message "<text>"`
249
- 4. If you use the low-level `runtime-register` or `heartbeat` commands, prefer `--local-port` by itself and let `oomi-ai` derive the LAN-reachable endpoint automatically.
250
- 5. If you must pass `--endpoint` explicitly, it must be the LAN-reachable host or a relay URL, not `127.0.0.1`.
267
+ 4. Before any low-level `runtime-register` or `heartbeat` recovery command, make sure the backend persona already exists via `create-managed`.
268
+ 5. If you use the low-level `runtime-register` or `heartbeat` commands, prefer `--local-port` by itself and let `oomi-ai` derive the LAN-reachable endpoint automatically.
269
+ 6. If you must pass `--endpoint` explicitly, it must be the LAN-reachable host or a relay URL, not `127.0.0.1`.
251
270
 
252
271
  When the Oomi bridge is running on the machine, queued persona jobs from Oomi are now polled and executed automatically through the filtered control-message lane. You should still use the explicit commands above for manual retries, recovery, or direct operator workflows.
package/bin/oomi-ai.js CHANGED
@@ -262,11 +262,11 @@ Commands:
262
262
  personas create <id>
263
263
  Create a new persona manifest for local or repo work. For managed Oomi personas prefer create-managed.
264
264
  personas create-managed [slug]
265
- Create a managed persona in Oomi and enqueue its build job for the linked device.
265
+ Create the managed persona record in Oomi. Run this before manual launch-managed, runtime-register, or heartbeat flows.
266
266
  personas launch-managed [slug]
267
- Launch or reuse a managed persona runtime on this OpenClaw machine and register a client-reachable runtime URL.
268
- personas scaffold <slug>
269
- Create an Oomi-managed persona app scaffold for agent customization.
267
+ Launch or reuse a managed persona runtime on this OpenClaw machine and register a client-reachable runtime URL. Prefer scaffold + create-managed first.
268
+ personas scaffold <slug>
269
+ Create an Oomi-managed persona app scaffold for agent customization.
270
270
  personas status <slug>
271
271
  Show local managed persona runtime state for a persona slug.
272
272
  personas stop <slug>
@@ -274,9 +274,9 @@ Commands:
274
274
  personas delete <slug>
275
275
  Stop a managed persona runtime and remove its workspace from this OpenClaw machine.
276
276
  personas runtime-register <slug>
277
- Register a running persona runtime with the Oomi backend. Prefer --local-port so the CLI can derive a reachable endpoint.
277
+ Register a running persona runtime with the Oomi backend. Recovery-only after create-managed. Prefer --local-port so the CLI can derive a reachable endpoint.
278
278
  personas heartbeat <slug>
279
- Send a persona runtime heartbeat to the Oomi backend. Prefer --local-port so the CLI can derive a reachable endpoint.
279
+ Send a persona runtime heartbeat to the Oomi backend. Recovery-only after launch-managed wrote .oomi/runtime.json.
280
280
  personas runtime-fail <slug>
281
281
  Report persona runtime failure to the Oomi backend.
282
282
  persona-jobs start <jobId>
@@ -1579,21 +1579,21 @@ async function handlePersonaLaunchManagedCommand(flags = {}, positionalSlug = ''
1579
1579
  const client = createCliPersonaApiClient(flags);
1580
1580
  const safeName = String(flags.name || '').trim();
1581
1581
  const safeDescription = String(flags.description || '').trim() || safeName;
1582
- const safeSlug = String(flags.slug || positionalSlug || (safeName ? slugifyPersonaName(safeName) : '')).trim();
1583
- if (!safeSlug) {
1584
- throw new Error('Persona slug or name is required. Usage: oomi personas launch-managed [slug] --name "<name>"');
1585
- }
1582
+ const safeSlug = String(flags.slug || positionalSlug || (safeName ? slugifyPersonaName(safeName) : '')).trim();
1583
+ if (!safeSlug) {
1584
+ throw new Error('Persona slug or name is required. Usage: oomi personas launch-managed [slug] --name "<name>". Prefer `oomi personas create-managed <slug> --name "<name>" --description "<description>"` first.');
1585
+ }
1586
1586
 
1587
1587
  const shouldCreate = !isTruthyFlag(flags['no-create']);
1588
1588
  let createdPersona = false;
1589
1589
  let personaPayload = await findExistingManagedPersona(client, safeSlug);
1590
- if (!personaPayload) {
1591
- if (!shouldCreate) {
1592
- throw new Error(`Managed persona ${safeSlug} does not exist in Oomi. Remove --no-create or create it first.`);
1593
- }
1594
- if (!safeName) {
1595
- throw new Error('Persona name is required when creating a new managed persona.');
1596
- }
1590
+ if (!personaPayload) {
1591
+ if (!shouldCreate) {
1592
+ throw new Error(`Managed persona ${safeSlug} does not exist in Oomi. Remove --no-create or create it first with \`oomi personas create-managed ${safeSlug} --name "<name>" --description "<description>"\`.`);
1593
+ }
1594
+ if (!safeName) {
1595
+ throw new Error('Persona name is required when creating a new managed persona implicitly. Prefer running `oomi personas create-managed <slug> --name "<name>" --description "<description>"` first instead of relying on launch-managed auto-create.');
1596
+ }
1597
1597
  personaPayload = await client.createManagedPersona({
1598
1598
  slug: safeSlug,
1599
1599
  name: safeName,
@@ -2,7 +2,7 @@
2
2
  "id": "oomi-ai",
3
3
  "name": "Oomi Channel Plugin",
4
4
  "description": "Managed Oomi channel integration for OpenClaw.",
5
- "version": "0.2.49",
5
+ "version": "0.2.50",
6
6
  "author": "Oomi",
7
7
  "license": "MIT",
8
8
  "openclawVersion": ">=0.5.0",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "oomi-ai",
3
- "version": "0.2.49",
3
+ "version": "0.2.50",
4
4
  "description": "Managed Oomi chat, voice bridge, and XR-first persona scaffolding for OpenClaw",
5
5
  "bin": {
6
6
  "oomi": "bin/oomi-ai.js"
@@ -33,13 +33,24 @@ The scaffold is considered healthy only when all of the following stay true:
33
33
  - Manifest: `/manifest.webmanifest`
34
34
  - Default dev port: `4789`
35
35
 
36
- ## Local Development
37
-
36
+ ## Local Development
37
+
38
38
  ```bash
39
39
  npm install
40
40
  npm run dev:avp
41
41
  ```
42
42
 
43
+ ## Managed Launch Contract
44
+
45
+ This scaffold is meant to be launched through the managed Oomi flow, not as an ad hoc dev server:
46
+
47
+ - scaffold the workspace with `oomi personas scaffold`
48
+ - create the backend record with `oomi personas create-managed`
49
+ - launch and register through `oomi personas launch-managed`
50
+ - verify `.oomi/runtime.json`, `oomi personas status --json`, and `oomi personas heartbeat --json`
51
+
52
+ Do not replace that flow with `npm run dev` when reporting persona creation success back to Oomi.
53
+
43
54
  ## Notes
44
55
 
45
56
  - Preserve the WebSpatial/Vite shell, the runtime metadata files in `public/`, and the XR-specific route split between browser and scene modes.
@@ -5,5 +5,6 @@ export const personaNotes = [
5
5
  "Keep using the vendored AndroidXR-enabled WebSpatial fork instead of switching back to the stock npm packages.",
6
6
  "Author multiple meaningful surfaces with explicit enable-xr, --xr-back, and --xr-background-material values so the app reads as spatial instead of one captured webpage.",
7
7
  "Keep html.is-spatial shell styles transparent so the host recedes and the panels carry the visual material.",
8
+ "Keep the managed runtime compatible with `oomi personas launch-managed`; do not require manual npm run dev for Oomi to consider the persona live.",
8
9
  "Do not remove public/oomi.runtime.json, public/oomi.health.json, or public/manifest.webmanifest.",
9
10
  ];