forge-openclaw-plugin 0.2.68 → 0.2.70

package/server/migrations/062_health_mobile_sync_sessions.sql

@@ -0,0 +1,55 @@
+CREATE TABLE IF NOT EXISTS health_mobile_sync_sessions (
+  id TEXT PRIMARY KEY,
+  pairing_session_id TEXT NOT NULL REFERENCES companion_pairing_sessions(id) ON DELETE CASCADE,
+  user_id TEXT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
+  status TEXT NOT NULL DEFAULT 'running',
+  schema_version TEXT NOT NULL DEFAULT 'healthkit-sync-v2',
+  requested_families_json TEXT NOT NULL DEFAULT '[]',
+  source_metadata_json TEXT NOT NULL DEFAULT '{}',
+  expected_counts_json TEXT NOT NULL DEFAULT '{}',
+  received_counts_json TEXT NOT NULL DEFAULT '{}',
+  byte_totals_json TEXT NOT NULL DEFAULT '{}',
+  affected_workout_ids_json TEXT NOT NULL DEFAULT '[]',
+  error_json TEXT NOT NULL DEFAULT '{}',
+  started_at TEXT NOT NULL,
+  completed_at TEXT,
+  failed_at TEXT,
+  aborted_at TEXT,
+  expired_at TEXT,
+  created_at TEXT NOT NULL,
+  updated_at TEXT NOT NULL
+);
+
+CREATE INDEX IF NOT EXISTS idx_health_mobile_sync_sessions_pairing_status
+  ON health_mobile_sync_sessions(pairing_session_id, status, started_at DESC);
+
+CREATE TABLE IF NOT EXISTS health_mobile_sync_chunks (
+  id TEXT PRIMARY KEY,
+  sync_session_id TEXT NOT NULL REFERENCES health_mobile_sync_sessions(id) ON DELETE CASCADE,
+  chunk_id TEXT NOT NULL,
+  sequence INTEGER NOT NULL,
+  family TEXT NOT NULL,
+  checksum_sha256 TEXT NOT NULL,
+  record_count INTEGER NOT NULL DEFAULT 0,
+  byte_count INTEGER NOT NULL DEFAULT 0,
+  payload_json TEXT NOT NULL DEFAULT '{}',
+  payload_summary_json TEXT NOT NULL DEFAULT '{}',
+  received_at TEXT NOT NULL,
+  applied_at TEXT,
+  created_at TEXT NOT NULL,
+  updated_at TEXT NOT NULL,
+  UNIQUE(sync_session_id, chunk_id)
+);
+
+CREATE INDEX IF NOT EXISTS idx_health_mobile_sync_chunks_session_sequence
+  ON health_mobile_sync_chunks(sync_session_id, sequence);
+
+CREATE TABLE IF NOT EXISTS health_mobile_sync_family_cursors (
+  id TEXT PRIMARY KEY,
+  pairing_session_id TEXT NOT NULL REFERENCES companion_pairing_sessions(id) ON DELETE CASCADE,
+  user_id TEXT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
+  family TEXT NOT NULL,
+  cursor_json TEXT NOT NULL DEFAULT '{}',
+  updated_at TEXT NOT NULL,
+  UNIQUE(pairing_session_id, family)
+);

package/skills/forge-openclaw/SKILL.md

@@ -111,6 +111,10 @@ Concrete route-key examples for internal use:
   `{"routeKey":"selection","query":{"from":"2026-05-01T00:00:00.000Z","to":"2026-05-14T23:59:59.999Z","placeIds":["place_home"],"userIds":["user_operator"]}}`
 - Movement trip detail:
   `{"routeKey":"tripDetail","pathParams":{"id":"trip_123"}}`
+- Movement settings read:
+  `{"routeKey":"settings","query":{"userIds":["user_operator"]}}`
+- Movement settings update:
+  `{"routeKey":"settingsUpdate","body":{"trackingEnabled":true,"publishMode":"draft_review","retentionMode":"aggregates_only"}}`
 - Movement missing-stay correction:
   first `{"routeKey":"userBoxPreflight","body":{"kind":"stay","startedAt":"2026-05-06T13:00:00.000Z","endedAt":"2026-05-06T15:00:00.000Z","placeLabel":"Home","userId":"user_operator"}}`,
   then `{"routeKey":"userBoxCreate","body":{"kind":"stay","startedAt":"2026-05-06T13:00:00.000Z","endedAt":"2026-05-06T15:00:00.000Z","placeLabel":"Home","userId":"user_operator","note":"Manual correction after reviewing the timeline."}}`
@@ -126,6 +130,12 @@ Concrete route-key examples for internal use:
   `{"routeKey":"listFlows","query":{"includeArchived":false}}`
 - Workbench box catalog:
   `{"routeKey":"boxCatalog"}`
+- Workbench flow creation:
+  `{"routeKey":"createFlow","body":{"title":"Research digest","slug":"research-digest","description":"Turn a topic into a cited digest with a stable published summary.","nodes":[],"edges":[]}}`
+- Workbench flow edit:
+  `{"routeKey":"updateFlow","pathParams":{"id":"flow_research_digest"},"body":{"description":"Keep the same input contract but add a stronger evidence-check node."}}`
+- Workbench flow deletion:
+  `{"routeKey":"deleteFlow","pathParams":{"id":"flow_research_digest"}}`
 - Workbench run detail:
   `{"routeKey":"runDetail","pathParams":{"id":"flow_research_digest","runId":"run_123"}}`
 - Workbench published output:
@@ -134,6 +144,8 @@ Concrete route-key examples for internal use:
   `{"routeKey":"latestNodeOutput","pathParams":{"id":"flow_research_digest","nodeId":"node_summary"}}`
 - Workbench run execution:
   `{"routeKey":"runFlow","pathParams":{"id":"flow_research_digest"},"body":{"input":{"topic":"question flow quality"}}}`
+- Workbench flow chat follow-up:
+  `{"routeKey":"chatFlow","pathParams":{"id":"flow_research_digest"},"body":{"message":"Refine the summary around API route risks and keep the published output stable."}}`
 
 Preferences rule:
 
@@ -173,11 +185,16 @@ Health rule:
 
 - Sleep and sports records are first-class health surfaces, not generic notes or tasks.
 - Use `forge_get_sleep_overview` and `forge_get_sports_overview` for review and trend reading.
-- In `forge_get_agent_onboarding.entityRouteModel.readModelOnlySurfaces`, the health
-  overview routes are published under both the plain names `sleepOverview` and
-  `sportsOverview` and the entity-style aliases `sleep_overview` and
-  `sports_overview`. Treat those as read-only overview surfaces, not batch CRUD
-  entities.
+- In `forge_get_agent_onboarding.entityRouteModel.readModelOnlySurfaces`, operator,
+  calendar, self-observation, sleep, and sports read models are published with
+  both camelCase names and entity-style aliases where useful, including
+  `operatorOverview`, `operatorContext`, `calendarOverview`, `sleepOverview`,
+  `sportsOverview`, `operator_overview`, `operator_context`,
+  `calendar_overview`, `self_observation`, `sleep_overview`, and
+  `sports_overview`. Treat those as read-only surfaces, not batch CRUD entities.
+- Use `forge_get_operator_overview` for a broad Forge status read, `forge_get_operator_context`
+  for current work and risk, and `forge_get_calendar_overview` before calendar-aware
+  planning or scheduling mutations.
 - Use the shared batch entity tools for ordinary `sleep_session` and `workout_session` create, update, delete, and search work. Do not force agents into a large one-route-per-entity mental model when the batch routes already cover the record cleanly.
 - Use `forge_update_sleep_session` and `forge_update_workout_session` only when the job is reflective enrichment on one existing health record after review, such as attaching notes, tags, mood, meaning, or Forge links.
 - Habit-generated workouts and imported HealthKit workouts belong to the same workout record model, so do not invent a separate storage path for sport sessions.
@@ -486,6 +503,10 @@ through `forge_create_entities` or `forge_update_entities`.
   `/api/v1/movement/day`, `/api/v1/movement/month`, `/api/v1/movement/all-time`,
   `/api/v1/movement/timeline`, `/api/v1/movement/places`,
   `/api/v1/movement/selection`, and `/api/v1/movement/trips/:id`.
+- Use `GET /api/v1/movement/settings` and `PATCH /api/v1/movement/settings` when
+  the user wants to inspect or change passive capture, publish mode, retention mode,
+  or companion readiness. Do not treat movement settings as a place, stay, trip, or
+  batch entity write.
 - When the user is filling a missing-data gap, the default write path is a user-defined overlay box, not a raw stay or trip patch. Use `POST /api/v1/movement/user-boxes/preflight` if you need to confirm overlap or snap to the nearest missing interval, then `POST /api/v1/movement/user-boxes` with `kind: "stay"` or `kind: "trip"`.
 - When the user is repairing already-saved movement data, use the repair routes that match the saved object:
   `PATCH /api/v1/movement/user-boxes/:id`,
@@ -496,7 +517,7 @@ through `forge_create_entities` or `forge_update_entities`.
 - Use `PATCH /api/v1/movement/stays/:id` or `PATCH /api/v1/movement/trips/:id` only when the user is editing an existing recorded stay or recorded trip. Do not use those routes to fill a missing span.
 - If the user says something as explicit as "that missing block was me staying home", do not reopen broad intake. Confirm the interval or place only if it is still ambiguous, then create the overlay and read the timeline back.
 - Life Force lives under `/api/v1/life-force*`. Use `GET /api/v1/life-force` for the current energy overview, `PATCH /api/v1/life-force/profile` for durable profile changes, `PUT /api/v1/life-force/templates/:weekday` for weekday curve edits, and `POST /api/v1/life-force/fatigue-signals` for real-time tired or recovered signals.
-- Workbench lives under `/api/v1/workbench/*`. Use those dedicated routes for flow catalog reads, flow CRUD, runs, published outputs, node results, and latest-node-output reads instead of trying to force Workbench through the batch entity routes.
+- Workbench lives under `/api/v1/workbench/*`. Use those dedicated routes for flow catalog reads, flow CRUD, runs, saved-flow chat follow-ups, published outputs, node results, and latest-node-output reads instead of trying to force Workbench through the batch entity routes.
 - If you need the OpenClaw HTTP mirror instead of the raw Forge runtime path, the
   same specialized families are exposed under `/forge/v1/movement/*`,
   `/forge/v1/life-force/*`, and `/forge/v1/workbench/*`.
@@ -505,8 +526,16 @@ through `forge_create_entities` or `forge_update_entities`.
   `POST /api/v1/workbench/flows` for flow creation,
   `PATCH /api/v1/workbench/flows/:id` and `DELETE /api/v1/workbench/flows/:id` for saved-flow edits or deletion,
   `/api/v1/workbench/flows/:id/run` or `/api/v1/workbench/run` for execution,
+  `POST /api/v1/workbench/flows/:id/chat` for saved-flow chat follow-ups,
   `/api/v1/workbench/flows/:id/output` for published outputs, and the run/node routes
   under `/api/v1/workbench/flows/:id` for run history and node-level inspection.
+- For Workbench flow creation or edits, clarify the stable input contract, intended
+  published output, and smallest structural change before asking for raw JSON or node
+  payloads. For deletion, confirm the saved flow and whether published outputs or run
+  history need preservation elsewhere before using the delete route.
+- For Workbench flow chat follow-ups, use `POST /api/v1/workbench/flows/:id/chat`
+  only when the user wants flow-specific conversation. Do not turn that follow-up
+  into a new run, note, or generic entity update unless the user asks for that.
 - If you are unsure which specialized route family applies, check `forge_get_agent_onboarding` and use its `entityRouteModel.specializedDomainSurfaces` section before guessing.
 - If the truth of the current Movement, Life Force, or Workbench state is still unclear, prefer the dedicated read before the mutation so the correction stays truthful.
 - After a concrete Movement, Life Force, or Workbench correction, read the relevant specialized view back when the user is trying to understand the result rather than only store it.

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -237,10 +237,11 @@ Use this quick split before the conversation gets too detailed.
   `preference_signal`, and `self_observation` are action workflows. Start from what
   the user is trying to do, then use the dedicated action tool or note-backed write
   model.
-- `sleep_overview` and `sports_overview` are read-model-only surfaces. Use them when
-  the user wants to review nights, workouts, training load, recovery context, or
-  health patterns before deciding whether one stored `sleep_session` or
-  `workout_session` needs enrichment.
+- `operator_overview`, `operator_context`, `calendar_overview`, `sleep_overview`,
+  and `sports_overview` are read-model-only surfaces. Use them when the user wants
+  to understand current Forge state, work risk, calendar commitments, nights,
+  workouts, training load, recovery context, or health patterns before deciding
+  whether a stored entity needs creation or enrichment.
 - Movement, Life Force, and Workbench are specialized domain areas. Use their
   dedicated route families for timelines and overlays, energy profile/templates and
   fatigue signals, and Workbench flow execution or result artifacts. When available,
@@ -282,6 +283,19 @@ still knowing the exact write/read family before it acts.
 - `calendar_connection`: specialized CRUD. Use provider discovery, connection CRUD,
   selected-calendar rediscovery, sync, and delete routes rather than batch entity
   tools.
+- `operator_overview`: read-model-only operator surface. Use
+  `forge_get_operator_overview` or `/api/v1/operator/overview` when the user wants
+  the current Forge picture, attention cues, or broad status before choosing a
+  specific entity action.
+- `operator_context`: read-model-only operator surface. Use
+  `forge_get_operator_context` or `/api/v1/operator/context` when the user wants
+  current work, active runs, risks, board context, or next moves before mutating
+  anything.
+- `calendar_overview`: read-model-only calendar surface. Use
+  `forge_get_calendar_overview` or `/api/v1/calendar/overview` when the user wants
+  mirrored events, work blocks, timeboxes, provider state, or availability before
+  creating a `calendar_event`, `work_block_template`, `task_timebox`, or
+  `calendar_connection`.
 - `task_run`: action workflow. Use task-run start, heartbeat, focus, complete, and
   release routes; never treat status changes as proof of live work.
 - `work_adjustment`: action workflow. Use the signed work-adjustment route for real
@@ -1061,6 +1075,81 @@ Preferred opening question:
 
 - "Which task or project should this time correction belong to?"
 
+## Operator Overview
+
+Aim: read the broad Forge state before choosing a specific action, without turning a
+status check into generic intake.
+
+Arc:
+
+1. Ask what the user is trying to understand about Forge overall.
+2. Read the operator overview before asking the user to reconstruct active work,
+   attention cues, or broad status from memory.
+3. Reflect the practical decision the overview should support.
+4. Move into a specific entity flow only when the overview points to a concrete goal,
+   project, task, habit, note, Psyche record, or follow-up action.
+
+Helpful follow-up lanes:
+
+- whether the user wants a broad status read, a priority decision, or a handoff
+- which owner or user scope matters if several humans or bots are involved
+- what decision the overview should help them make next
+
+Route note:
+
+- `operator_overview` is a read-model-only operator surface. Use
+  `forge_get_operator_overview` or `/api/v1/operator/overview`; do not create,
+  update, or delete `operator_overview` through batch CRUD.
+- If the read reveals a specific record that needs work, switch to that record's
+  normal route posture after the user chooses the follow-up.
+
+Ready to review when:
+
+- the broad question is clear enough
+- any owner or user scope that changes the read is clear enough
+
+Preferred opening question:
+
+- "What are you trying to understand about Forge overall right now?"
+
+## Operator Context
+
+Aim: inspect current work, active runs, risk, and next moves before changing records.
+
+Arc:
+
+1. Ask whether the user is checking current work, risk, blockers, active sessions, or
+   the next move.
+2. Read operator context before reopening a create or update intake.
+3. Reflect what the read is meant to decide: continue, stop, reprioritize, update, or
+   create.
+4. Move to task-run, work-adjustment, task, project, or note flow only when one
+   concrete follow-up is visible.
+
+Helpful follow-up lanes:
+
+- current task or active run
+- blocked or stale work
+- next move versus broad review
+- owner or user scope when bot and human work are both present
+
+Route note:
+
+- `operator_context` is a read-model-only operator surface. Use
+  `forge_get_operator_context` or `/api/v1/operator/context`; do not mutate it
+  through batch CRUD.
+- If the user decides to start, complete, release, or adjust work after the read,
+  switch to the dedicated action workflow for that operation.
+
+Ready to review when:
+
+- the current-work question is clear
+- any user or owner scope is clear enough
+
+Preferred opening question:
+
+- "What current work, risk, or next move are you trying to check?"
+
 ## Self Observation
 
 Aim: capture one observed episode in a structured chain without letting a loose note
@@ -1251,6 +1340,46 @@ Preferred opening question:
 
 - "What are you trying to understand from your workout picture right now?"
 
+## Calendar Overview
+
+Aim: review commitments, work blocks, provider state, and existing timeboxes before
+creating or changing calendar records.
+
+Arc:
+
+1. Ask what the user is trying to understand or decide from the calendar picture.
+2. Ask for the date range or owner scope only if it changes the read.
+3. Read the calendar overview before asking the user to recreate availability from
+   memory.
+4. Reflect the practical decision the overview should support.
+5. Move to `calendar_event`, `work_block_template`, `task_timebox`, or
+   `calendar_connection` only when a specific follow-up action is visible.
+
+Helpful follow-up lanes:
+
+- which day, week, or date range matters
+- whether the question is availability, conflicts, provider health, work blocks, or
+  existing timeboxes
+- what scheduling or planning decision the review should support
+
+Route note:
+
+- `calendar_overview` is a read-model-only calendar surface. Use
+  `forge_get_calendar_overview` or `/api/v1/calendar/overview`; do not create,
+  update, or delete `calendar_overview` through batch CRUD.
+- If the review reveals a concrete scheduling action, switch to the stored
+  `calendar_event`, `work_block_template`, or `task_timebox` batch route, or to the
+  specialized `calendar_connection` lifecycle route.
+
+Ready to review when:
+
+- the user's practical calendar question is clear
+- the relevant date range or owner scope is clear enough
+
+Preferred opening question:
+
+- "What are you trying to understand or decide from your calendar picture?"
+
 ## Calendar Connection
 
 Aim: connect the right provider deliberately without turning setup into a credential
@@ -1370,8 +1499,9 @@ Preferred opening question:
 ## Movement
 
 Aim: clarify whether the user wants to understand time in place, review travel
-behavior, add or update a stay or trip, inspect one place, or link movement context to
-another Forge record before choosing the dedicated route family.
+behavior, add or update a stay or trip, inspect one place, change movement operating
+settings, or link movement context to another Forge record before choosing the
+dedicated route family.
 
 Arc:
 
@@ -1382,14 +1512,16 @@ Arc:
 3. Ask whether the focus is a stay, a trip, a place, a timeline window, or a selected span.
 4. Ask for the time window, place, or movement item that makes the question concrete.
 5. Ask what they are trying to notice, preserve, or answer through that movement context.
-6. Choose the dedicated day, month, all-time, timeline, places, trip-detail, or
-   selection route once the question shape is clear.
-7. If the truth of one uncertain span is still unclear, read the timeline or saved-box
+6. If the user is changing movement operating behavior, ask whether the change is
+   about passive tracking, publish mode, retention, or companion readiness.
+7. Choose the dedicated day, month, all-time, timeline, places, trip-detail,
+   selection, or settings route once the question shape is clear.
+8. If the truth of one uncertain span is still unclear, read the timeline or saved-box
    detail before you mutate it.
-8. Skip the meta lane question when the user already named the exact correction or
+9. Skip the meta lane question when the user already named the exact correction or
    review target and only one ambiguity remains.
-9. Use the dedicated movement route once you know whether the user needs timeline
-   review, overlay, place or trip detail, selection summary, or repair.
+10. Use the dedicated movement route once you know whether the user needs timeline
+   review, overlay, place or trip detail, selection summary, settings, or repair.
 
 Direct action rules:
 
@@ -1398,6 +1530,11 @@ Direct action rules:
 - Treat day, month, all-time, timeline, trip detail, and selection as internal read
   lanes. With the user, ask for the useful time window, place, selected span, stay, or
   trip instead of listing route choices.
+- Treat settings as a separate movement lane for passive capture, publish mode, and
+  retention behavior. Ask what operating behavior should change instead of routing it
+  through a place, stay, or trip edit.
+- Use settings reads before settings writes when the current capture or publish state
+  is uncertain.
 - Preflight with `/api/v1/movement/user-boxes/preflight` when overlap or exact timing
   is unclear, then create the overlay with `/api/v1/movement/user-boxes`.
 - Use `kind: "stay"` when the user stayed in one place and `kind: "trip"` when they
@@ -1427,6 +1564,8 @@ Helpful follow-up lanes:
 - whether the edit is a missing-gap overlay versus a true recorded stay/trip patch
 - whether the user is trying to repair one recorded movement item versus fill a
   missing span
+- whether they are changing passive capture, publish mode, retention, or companion
+  readiness rather than movement history
 
 Lane-to-route map:
 
@@ -1436,6 +1575,8 @@ Lane-to-route map:
   `/api/v1/movement/all-time`, `/api/v1/movement/places`, or `/api/v1/movement/selection`
 - inspect the full life timeline:
   `/api/v1/movement/timeline`
+- inspect or change passive capture and publishing settings:
+  `GET /api/v1/movement/settings` or `PATCH /api/v1/movement/settings`
 - create or revise one saved place:
   `/api/v1/movement/places` or `/api/v1/movement/places/:id`
 - inspect one trip:
@@ -1461,6 +1602,7 @@ Ready to act when:
 - the time range, place, stay, trip, or selection is clear enough
 - the user goal is clear enough to tell review, overlay, and repair apart
 - the user goal is clear enough to choose the route
+- for settings changes, the intended tracking, publish, or retention behavior is clear
 
 Preferred opening question:
 
@@ -1550,18 +1692,25 @@ Arc:
 
 1. Ask what they are trying to learn, repair, publish, or run through Workbench
    before you narrow to flow discovery, editing, execution, or results.
-2. Ask whether the job is flow discovery, one flow edit, execution, run history, published output, node-level inspection, or latest-node-output lookup.
+2. Ask whether the job is flow discovery, one flow edit, execution, run history, published output, node-level inspection, latest-node-output lookup, or a follow-up message in a saved flow chat.
 3. Ask which flow, slug, run, or node the request is about.
 4. Ask whether they need the stable flow contract, one run result, one published
    output, one node result, or the latest node output.
-5. If the user already named the flow and action clearly, skip the meta lane
+5. If the user is creating or editing a flow, clarify the flow's job, stable inputs,
+   expected public output, and the smallest structural change before asking for node
+   details.
+6. If the user wants to delete or archive a flow, ask which saved flow is affected
+   and what future run, published output, or public contract should no longer exist.
+7. If the user wants to continue a saved flow chat, ask which flow should receive the
+   follow-up and what the message should accomplish.
+8. If the user already named the flow and action clearly, skip the meta lane
    question and ask only for the missing run, node, or output scope.
-6. If the user wants a stable public input contract or published output, prefer those
+9. If the user wants a stable public input contract or published output, prefer those
    dedicated reads instead of detouring through run history first.
-7. If the user is debugging one failed run, ask whether the useful artifact is the run
+10. If the user is debugging one failed run, ask whether the useful artifact is the run
    summary, one node result, the latest node output, or the published output before
    you start asking for edits.
-8. Route to the dedicated workbench route family once the execution lane is clear.
+11. Route to the dedicated workbench route family once the execution lane is clear.
 
 Helpful follow-up lanes:
 
@@ -1582,7 +1731,7 @@ Lane-to-route map:
 - run from a payload-first contract:
   `/api/v1/workbench/run`
 - send one follow-up message into a saved flow chat:
-  `/api/v1/workbench/flows/:id/chat`
+  `POST /api/v1/workbench/flows/:id/chat`
 - inspect published output or run history:
   `/api/v1/workbench/flows/:id/output` or `/api/v1/workbench/flows/:id/runs`
 - inspect one run or node result:
@@ -1617,12 +1766,24 @@ Direct action rules:
   unless they explicitly want historical debugging.
 - If the user wants to understand what inputs a flow can accept before editing or
   running it, read the box catalog or flow detail before asking for a payload.
+- For new flows, ask what the flow should reliably produce, what input contract it
+  should accept, and what first node or box should anchor it. Do not start by asking
+  for raw JSON.
+- For flow edits, ask what behavior should change and how the public contract stays
+  stable, unless the user explicitly wants to change the contract.
+- For flow deletion, confirm the saved flow and whether published outputs or run
+  history still need to be preserved elsewhere before calling delete.
+- For flow chat follow-ups, use the saved flow chat route only when the user wants to
+  continue a flow-specific conversation. Do not turn a chat follow-up into a new flow
+  run, note, or generic entity update unless that is what the user asks for.
 
 Ready to act when:
 
 - the workbench lane is clear
 - the flow, run, or node is clear enough
 - the requested read or mutation is clear enough to choose the route
+- for flow CRUD, the intended stable input, output, or lifecycle effect is clear
+- for flow chat, the saved flow and follow-up message aim are clear
 
 Preferred opening question: