forge-openclaw-plugin 0.2.92 → 0.2.94

package/server/migrations/064_health_workout_time_series_identity.sql

@@ -0,0 +1,161 @@
+CREATE TEMP TABLE health_workout_time_series_dedupe AS
+SELECT
+  workout_id,
+  metric_key,
+  source_sample_uid,
+  MIN(rowid) AS survivor_rowid,
+  (
+    SELECT latest.rowid
+    FROM health_workout_time_series AS latest
+    WHERE latest.workout_id = grouped.workout_id
+      AND latest.metric_key = grouped.metric_key
+      AND latest.source_sample_uid = grouped.source_sample_uid
+    ORDER BY latest.updated_at DESC, latest.created_at DESC, latest.rowid DESC
+    LIMIT 1
+  ) AS latest_rowid,
+  (
+    SELECT latest.series_index
+    FROM health_workout_time_series AS latest
+    WHERE latest.workout_id = grouped.workout_id
+      AND latest.metric_key = grouped.metric_key
+      AND latest.source_sample_uid = grouped.source_sample_uid
+    ORDER BY latest.updated_at DESC, latest.created_at DESC, latest.rowid DESC
+    LIMIT 1
+  ) AS latest_series_index
+FROM health_workout_time_series AS grouped
+WHERE source_sample_uid IS NOT NULL
+  AND source_sample_uid != ''
+GROUP BY workout_id, metric_key, source_sample_uid
+HAVING COUNT(*) > 1;
+
+UPDATE health_workout_time_series
+SET
+  label = (
+    SELECT latest.label
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  category = (
+    SELECT latest.category
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  unit = (
+    SELECT latest.unit
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  value = (
+    SELECT latest.value
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  started_at = (
+    SELECT latest.started_at
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  ended_at = (
+    SELECT latest.ended_at
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  source_device = (
+    SELECT latest.source_device
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  source_bundle_identifier = (
+    SELECT latest.source_bundle_identifier
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  source_product_type = (
+    SELECT latest.source_product_type
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  capture_method = (
+    SELECT latest.capture_method
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  quality_flags_json = (
+    SELECT latest.quality_flags_json
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  metadata_json = (
+    SELECT latest.metadata_json
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  provenance_json = (
+    SELECT latest.provenance_json
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  ),
+  updated_at = (
+    SELECT latest.updated_at
+    FROM health_workout_time_series AS latest
+    JOIN health_workout_time_series_dedupe AS dedupe
+      ON dedupe.latest_rowid = latest.rowid
+    WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+  )
+WHERE rowid IN (
+  SELECT survivor_rowid
+  FROM health_workout_time_series_dedupe
+);
+
+DELETE FROM health_workout_time_series
+WHERE rowid IN (
+  SELECT duplicate.rowid
+  FROM health_workout_time_series AS duplicate
+  JOIN health_workout_time_series_dedupe AS dedupe
+    ON dedupe.workout_id = duplicate.workout_id
+   AND dedupe.metric_key = duplicate.metric_key
+   AND dedupe.source_sample_uid = duplicate.source_sample_uid
+  WHERE duplicate.rowid != dedupe.survivor_rowid
+);
+
+UPDATE health_workout_time_series
+SET series_index = (
+  SELECT dedupe.latest_series_index
+  FROM health_workout_time_series_dedupe AS dedupe
+  WHERE dedupe.survivor_rowid = health_workout_time_series.rowid
+)
+WHERE rowid IN (
+  SELECT survivor_rowid
+  FROM health_workout_time_series_dedupe
+);
+
+DROP TABLE health_workout_time_series_dedupe;
+
+CREATE UNIQUE INDEX IF NOT EXISTS idx_health_workout_time_series_sample_identity
+  ON health_workout_time_series(workout_id, metric_key, source_sample_uid);

package/skills/forge-openclaw/SKILL.md

@@ -116,9 +116,17 @@ Concrete route-key examples for internal use:
   `{"routeKey":"settings","query":{"userIds":["user_operator"]}}`
 - Movement settings update:
   `{"routeKey":"settingsUpdate","body":{"trackingEnabled":true,"publishMode":"draft_review","retentionMode":"aggregates_only"}}`
+- Movement known-place creation:
+  `{"routeKey":"placeCreate","body":{"label":"Home","centerLat":46.2044,"centerLon":6.1432,"radiusMeters":120,"userId":"user_operator","note":"Primary home boundary for future time-in-place reads."}}`
+- Movement known-place update:
+  `{"routeKey":"placeUpdate","pathParams":{"id":"place_home"},"body":{"label":"Home office","radiusMeters":90,"note":"Tighten the boundary so clinic visits do not count as home."}}`
 - 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."}}`
+- Movement saved-overlay update:
+  `{"routeKey":"userBoxUpdate","pathParams":{"id":"box_manual_123"},"body":{"endedAt":"2026-05-06T15:30:00.000Z","note":"Extended after checking the timeline detail."}}`
+- Movement saved-overlay delete:
+  `{"routeKey":"userBoxDelete","pathParams":{"id":"box_manual_123"}}`
 - Life Force overview:
   `{"routeKey":"overview"}`
 - Life Force profile edit:
@@ -139,6 +147,10 @@ Concrete route-key examples for internal use:
   `{"routeKey":"deleteFlow","pathParams":{"id":"flow_research_digest"}}`
 - Workbench run detail:
   `{"routeKey":"runDetail","pathParams":{"id":"flow_research_digest","runId":"run_123"}}`
+- Workbench run nodes:
+  `{"routeKey":"runNodes","pathParams":{"id":"flow_research_digest","runId":"run_123"}}`
+- Workbench node result:
+  `{"routeKey":"nodeResult","pathParams":{"id":"flow_research_digest","runId":"run_123","nodeId":"node_summary"}}`
 - Workbench published output:
   `{"routeKey":"publishedOutput","pathParams":{"id":"flow_research_digest"}}`
 - Workbench latest node output:
@@ -187,14 +199,16 @@ Wiki navigation and search rule:
 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.
+- Use `forge_get_sleep_overview`, `forge_get_sports_overview`, and
+  `forge_get_training_load_overview` for health review and trend reading.
 - In `forge_get_agent_onboarding.entityRouteModel.readModelOnlySurfaces`, operator,
-  calendar, self-observation, sleep, and sports read models are published with
+  calendar, self-observation, sleep, sports, and training-load 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.
+  `sportsOverview`, `trainingLoad`, `operator_overview`, `operator_context`,
+  `calendar_overview`, `self_observation`, `sleep_overview`,
+  `sports_overview`, and `training_load`. 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.
@@ -224,6 +238,7 @@ Entity conversation rule:
   before you reopen create or update intake.
 - When updating an entity, start with what is changing, what should stay true, and what prompted the update now.
 - When enough is clear, briefly summarize what you heard in the user's own language before asking for the last missing structural detail.
+- Treat `userId` and human/bot assignees as accountability and scope, not as opening form fields. Ask whose human or bot record it is only when ownership changes visibility, review scope, collaboration, automation behavior, or later filtering; for read requests, ask user scope only when the answer would differ across owners.
 - The quick intake prompts later in this file are fallback checkpoints, not a script to read aloud.
 
 Forge data location rule:
@@ -249,6 +264,7 @@ Psyche interview rule:
 - After the first real answer, choose one follow-up lane at a time: situation, sequence, meaning, protection, cost, longing/value, or tentative name.
 - Do not minimize functional analysis, trigger chains, behavior patterns, modes, beliefs, or schema themes. Once at least one concrete example is clear, offer one careful interpretive hypothesis when it would help the user understand the function, protection, cost, belief, mode, or schema theme.
 - Phrase interpretive hypotheses as collaborative and testable, not as verdicts. A good hypothesis says what the reaction may be protecting, predicting, relieving, or costing, then asks whether that lands or needs correction.
+- If several Psyche containers are plausible, do not ask the user to choose from a taxonomy menu first. Reflect the lived difference, offer one careful hypothesis when a concrete example is visible, then distinguish the options in plain language: one episode as a `trigger_report`, a recurring loop as a `behavior_pattern`, one repeated move as `behavior`, one sentence as `belief_entry`, a part-state as `mode_profile` or `mode_guide_session`, or reusable future-labeling as `event_type` or `emotion_definition`.
 - For Psyche updates, start with what feels newly true, newly visible, or newly inaccurate, then ask what should stay true before changing the formulation.
 - If a fresh episode is what made a Psyche update visible, anchor in that episode before renaming the durable belief, pattern, mode, or value.
 - If the user says they want help understanding a Psyche issue before saving it, ask one orienting question first instead of jumping straight into a full interpretation, diagnosis-like label, save suggestion, replacement belief, or suggested title.
@@ -510,7 +526,7 @@ Use the wiki tools for SQLite-backed memory work:
 `forge_get_wiki_settings`, `forge_list_wiki_pages`, `forge_get_wiki_page`, `forge_search_wiki`, `forge_upsert_wiki_page`, `forge_get_wiki_health`, `forge_sync_wiki_vault`, `forge_reindex_wiki_embeddings`, `forge_ingest_wiki_source`
 
 Use the health tools for review and reflective enrichment, not as the default CRUD architecture:
-`forge_get_sleep_overview`, `forge_get_sports_overview`, `forge_update_sleep_session`, `forge_update_workout_session`
+`forge_get_sleep_overview`, `forge_get_sports_overview`, `forge_get_training_load_overview`, `forge_update_sleep_session`, `forge_update_workout_session`
 
 Use the dedicated domain routes for specialized surfaces that are not simple batch entities:
 
@@ -665,9 +681,10 @@ Use the health tools when the request is about sleep or sports review:
 
 - `forge_get_sleep_overview` to inspect recent nights, averages, regularity, stage breakdown, and linked reflective context
 - `forge_get_sports_overview` to inspect training volume, workout types, effort trends, habit-generated sessions, and linked context
+- `forge_get_training_load_overview` to inspect cardiovascular load, HR zone balance, acute/chronic stress, high-intensity pressure, VO2max context, and training target fit
 - `forge_update_sleep_session` to add sleep-quality notes, tags, or links back to Forge entities after review
 - `forge_update_workout_session` to add subjective effort, mood, meaning, tags, or links on one workout after review
-- remember that the UI route is `/sports` while the backend overview route is `/api/v1/health/fitness`
+- remember that the UI route is `/sports` while the backend overview route is `/api/v1/health/fitness`; the dedicated training-load UI is `/training-load` and its backend route is `/api/v1/health/training-load`
 
 Use these exact health batch payload shapes when the user is creating or editing the stored records themselves:
 
@@ -762,6 +779,7 @@ When the user asks which Forge tools are available, list exactly these tools:
 `forge_get_current_work`
 `forge_get_sleep_overview`
 `forge_get_sports_overview`
+`forge_get_training_load_overview`
 `forge_update_sleep_session`
 `forge_update_workout_session`
 `forge_get_preferences_workspace`

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -204,6 +204,25 @@ When placement matters, prefer one hierarchy-aware linking question that can
 select or create the right goal, project, issue, or parent work item from the
 same search-first flow.
 
+## Owner And User-Scope Checkpoint
+
+Most normal stored Forge entities can carry `userId`, and many planning records can
+also carry human or bot assignees. Treat ownership as accountability and useful
+visibility, not as the first field in the form.
+
+- Do not open with "who owns this?" unless the user is explicitly delegating,
+  comparing human and bot work, or creating a record for someone else.
+- Ask whose human or bot record it is only when ownership changes accountability,
+  visibility, review scope, automation behavior, or later filtering.
+- For collaborative planning records, ask about assignees only after the outcome,
+  hierarchy placement, and owner are clear enough.
+- For reviews and overviews, ask which user or owner scope matters only when the
+  answer would change across humans or bots.
+- If the user's wording already names the owner or bot actor, use that as the
+  `userId` direction internally and ask only for any ambiguity that remains.
+- When owner scope is irrelevant, stay with the entity's meaning, timing, route, or
+  links instead of adding an administrative question.
+
 ## Operation lane checkpoint
 
 Use this before you choose an API path or ask for more structure.
@@ -238,10 +257,10 @@ Use this quick split before the conversation gets too detailed.
   the user is trying to do, then use the dedicated action tool or note-backed write
   model.
 - `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.
+  `sports_overview`, and `training_load` are read-model-only surfaces. Use them
+  when the user wants to understand current Forge state, work risk, calendar
+  commitments, nights, workouts, cardiovascular 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,
@@ -313,9 +332,17 @@ still knowing the exact write/read family before it acts.
   score, stages, or recovery patterns before deciding whether a specific
   `sleep_session` needs reflective enrichment.
 - `sports_overview`: read-model-only health surface. Use the sports overview route or
-  `forge_get_sports_overview` when the user wants to review workouts, training load,
-  effort, type distribution, or recovery context before deciding whether a specific
-  `workout_session` needs reflective enrichment.
+  `forge_get_sports_overview` when the user wants to review workouts, effort, type
+  distribution, or recovery context before deciding whether a specific
+  `workout_session` needs reflective enrichment. Use
+  `forge_get_training_load_overview` or `/api/v1/health/training-load` for
+  cardiovascular load, HR zone balance, acute/chronic stress, VO2max context, or
+  training target questions.
+- `training_load`: read-model-only health surface. Use
+  `forge_get_training_load_overview` or `/api/v1/health/training-load` when the
+  user wants training-load trends, acute/chronic ratio, HR zone distribution,
+  threshold exposure, VO2max/resting-HR context, or optimization targets before
+  deciding whether a specific `workout_session` needs notes or links.
 - `movement`: specialized domain surface. Use the dedicated movement routes for day,
   month, all-time, timeline, places, trip detail, selection aggregates, manual
   overlays, and repair actions.
@@ -1341,14 +1368,15 @@ Preferred opening question:
 
 ## Sports Overview
 
-Aim: review workout and training-load context before deciding whether one workout
-needs a reflective update or recovery follow-up.
+Aim: review workout context before deciding whether one workout needs a
+reflective update, and route deeper cardiovascular load questions to the
+training-load read model.
 
 Arc:
 
 1. Ask what the user wants to understand from the sports picture: one workout, a
-   recent training trend, effort, volume, type mix, recovery, or links to mood and
-   goals.
+   recent training trend, effort, volume, type mix, recovery, zone balance, or
+   links to mood and goals.
 2. Read the sports overview before asking the user to reconstruct metrics from memory.
 3. Reflect the practical decision the review should support.
 4. Move to `workout_session` enrichment only when one specific workout needs context,
@@ -1363,8 +1391,12 @@ Helpful follow-up lanes:
 Route note:
 
 - `sports_overview` is a read-model-only surface. Use `forge_get_sports_overview` or
-  `/api/v1/health/fitness` for review. Do not create, update, or delete
+  `/api/v1/health/fitness` for session review. Do not create, update, or delete
   `sports_overview` through batch CRUD.
+- For cardiovascular load, HR zone distribution, acute/chronic load, VO2max
+  context, or training target questions, use `forge_get_training_load_overview`
+  or `/api/v1/health/training-load`. Treat `training_load` as read-model-only,
+  not a batch CRUD entity.
 - If the review reveals that one workout needs reflective context, switch to the
   stored `workout_session` batch route or reflective update helper for that known
   session.
@@ -1378,6 +1410,50 @@ Preferred opening question:
 
 - "What are you trying to understand from your workout picture right now?"
 
+## Training Load
+
+Aim: review cardiovascular load and training targets before deciding whether one
+workout needs reflective enrichment or a recovery/target adjustment.
+
+Arc:
+
+1. Ask what practical decision the user wants to support: build aerobic base,
+   control overload risk, preserve hard-day quality, understand combat-sport
+   intensity, or compare recent load against chronic base.
+2. Read the training-load overview before asking the user to reconstruct zones,
+   VO2max, or recent hard sessions from memory.
+3. Reflect the load signal with explicit confidence: HR coverage, sensor limits,
+   recent sample count, and whether kickboxing/wrist HR may be noisy.
+4. Move to `workout_session` enrichment only when one specific workout needs
+   notes, tags, context, or links.
+
+Helpful follow-up lanes:
+
+- whether the question is adaptation, overload risk, zone target, VO2max trend,
+  sport contribution, or one recent session
+- which date range matters if the default 7-day and 28-day windows are not enough
+- whether the user is optimizing health, performance, recovery, or a specific
+  upcoming training block
+
+Route note:
+
+- `training_load` is a read-model-only surface. Use
+  `forge_get_training_load_overview` or `/api/v1/health/training-load` for
+  cardiovascular load, HR zone distribution, acute/chronic load, VO2max context,
+  and training target analysis. Do not create, update, or delete `training_load`
+  through batch CRUD.
+- If one workout needs subjective effort, meaning, social context, or links,
+  switch to the stored `workout_session` batch route or reflective update helper.
+
+Ready to review when:
+
+- the user's practical adaptation or recovery question is clear
+- the relevant time window or default 7-day/28-day comparison is acceptable
+
+Preferred opening question:
+
+- "What training-load decision are you trying to support right now?"
+
 ## Calendar Overview
 
 Aim: review commitments, work blocks, provider state, and existing timeboxes before

package/skills/forge-openclaw/psyche_entity_playbooks.md

@@ -251,6 +251,41 @@ short, tentative, and correctable.
   episode, or durable wiki explanation. Do not flatten schema work into a loose
   self-observation.
 
+## Entity Contrast Check
+
+Use this when the user's material could fit several Psyche records. Do not ask the
+user to choose from a taxonomy menu before you have reflected what the material is
+doing.
+
+- Choose `trigger_report` when the important thing is one charged episode and the
+  useful record is the sequence of situation, feeling, meaning, action, and
+  consequence.
+- Choose `behavior_pattern` when the same cue -> body/emotion -> meaning ->
+  behavior/urge -> payoff -> cost loop repeats across situations and needs a
+  functional analysis.
+- Choose `behavior` when one recurring move is the main object, even if the wider
+  loop is not mapped yet.
+- Choose `belief_entry` when the live center is a sentence, rule, prediction, or
+  self/other/world assumption.
+- Choose `mode_profile` when a recurring part-state has a stable voice, posture,
+  job, fear, or burden.
+- Choose `mode_guide_session` when the user is inside the reaction and needs guided
+  present-moment exploration before a durable mode, belief, or pattern is clear.
+- Choose `event_type` or `emotion_definition` when the reusable category or feeling
+  label will make future trigger reports more precise.
+
+If two containers are genuinely plausible, say the distinction in plain language
+after a reflection. For example: "We could save this as the episode if the meeting
+itself is what matters, or as the recurring loop if this same freeze-and-overwork
+sequence keeps happening. Which would help you more right now?" Ask that only after
+the lived example is clear enough that the choice is meaningful.
+
+After one concrete example is visible, it is often helpful to offer one careful
+hypothesis before the contrast question: what the reaction may be protecting, what it
+predicts, what short-term relief it creates, and what it costs. If the user corrects
+the hypothesis, revise it once and then choose the record shape from the corrected
+meaning.
+
 ## Therapeutic Direction Check
 
 Before each follow-up, quickly decide what therapeutic job the next question should do.