forge-openclaw-plugin 0.2.91 → 0.2.92

package/dist/server/server/src/app.js

@@ -2960,6 +2960,7 @@ const AGENT_ONBOARDING_ENTITY_CATALOG = [
         ],
         searchHints: [
             "Clarify whether the user wants a behavioral query, one trip or place, a missing-gap overlay, a manual add or update, or a link before choosing the route.",
+            "For known-place creation or cleanup, ask what label, boundary, and future use should make the place recognizable before calling the dedicated place route.",
             "If the user already named a concrete missing span, confirm only the remaining time or place ambiguity, then use the movement overlay route and read the timeline back.",
             "If the user wants to revise or remove an already-saved correction, identify whether it is a user-defined box, automatic box, recorded stay, recorded trip, or trip point before choosing the repair or delete route."
         ],
@@ -2975,6 +2976,7 @@ const AGENT_ONBOARDING_ENTITY_CATALOG = [
         ],
         searchHints: [
             "Clarify whether the user wants explanation, durable model changes, or a real-time tired or recovered signal before choosing the route.",
+            "For profile or weekday-template edits, ask what future planning behavior should change, such as workload, recovery time, timeboxes, meeting load, or task choice.",
             "Separate durable profile assumptions, weekday-template edits, and right-now fatigue signals before choosing the mutation path.",
             "When the user is trying to understand the practical result of a change, read the overview again after the write instead of stopping at the mutation response."
         ],
@@ -2990,6 +2992,7 @@ const AGENT_ONBOARDING_ENTITY_CATALOG = [
         ],
         searchHints: [
             "Clarify whether the user wants flow discovery, editing, execution, published output, run inspection, or node-level output before choosing the route.",
+            "For one-off execution, ask whether the input contract should stay temporary or become a reusable saved flow before creating anything durable.",
             "Distinguish flow contract, published output, run history, latest-node-output, and chat follow-up questions before reaching for a route.",
             "If the user is still deciding how to run or edit a flow, read flow detail or the box catalog before asking them for structured input details."
         ],
@@ -4776,6 +4779,7 @@ function buildAgentOnboardingPayload(request) {
                     ],
                     routeSelectionQuestions: [
                         "Is the user asking for a day, month, all-time, timeline, place, trip detail, selected-span, or settings answer?",
+                        "If this is known-place creation or cleanup, what label, boundary, or future-use distinction is still missing?",
                         "Is this a missing-gap overlay, a saved-overlay repair, or an edit to one already-recorded stay, trip, or trip point?",
                         "If this is about operating behavior, is the change about passive tracking, publish mode, retention, or companion readiness?",
                         "If the target is already known, what one time, place, or saved-object detail is still missing before acting?"
@@ -4837,6 +4841,7 @@ function buildAgentOnboardingPayload(request) {
                         "Route-selection questions are internal. User-facing questions should ask for the useful time window, place, selected span, stay, or trip instead of reciting day/month/all-time/timeline/selection route keys.",
                         "Use /api/v1/movement/day, /month, /all-time, /timeline, or /selection when the user wants behavioral answers such as how long they stayed at home, when they traveled, which places dominated a period, or what happened across a selected span.",
                         "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 route settings changes through stays, trips, places, or batch CRUD.",
+                        "For known-place creation or cleanup, ask for the place label, boundary, and future use, then use POST /api/v1/movement/places or PATCH /api/v1/movement/places/:id instead of tags or generic entity writes.",
                         "Use the movement write routes when the user wants to add a place or manual overlay, update a specific stay or trip, repair one recorded movement span, or attach movement context to another Forge record. If the user is filling a missing-data gap, the usual write path is a user-defined overlay box rather than a raw stay or trip patch.",
                         "If the user is revising or removing an existing correction, first identify whether the saved object is a user-defined box, automatic box, recorded stay, recorded trip, or trip point so the repair or delete path stays truthful.",
                         "For an explicit statement like 'that missing block was me staying home', do not reopen broad intake. Preflight only if timing overlap is unclear, then create a user-defined `stay` box for that interval and read the updated timeline back."
@@ -4849,6 +4854,7 @@ function buildAgentOnboardingPayload(request) {
                     routeKeys: ["overview", "profile", "weekdayTemplate", "fatigueSignal"],
                     routeSelectionQuestions: [
                         "Is the user trying to understand the overview, change durable profile assumptions, change a weekday curve, or log a right-now fatigue signal?",
+                        "What planning decision should the overview or correction change: workload, recovery, timeboxes, meetings, or task choice?",
                         "Are they describing a repeatable weekly shape or a one-off current state?",
                         "If the lane is already clear, what one weekday, profile field, or signal detail is still missing?"
                     ],
@@ -4871,6 +4877,8 @@ function buildAgentOnboardingPayload(request) {
                         "Route-selection questions are internal. User-facing questions should ask whether this is a current read, durable assumption, repeated weekday rhythm, or right-now state instead of reciting overview/profile/template/signal route keys.",
                         "Use GET /api/v1/life-force for the current overview payload with stats, drains, recommendations, and current-curve state.",
                         "Patch the profile only for durable personal settings, update weekday templates only for the curve itself, and post fatigue signals for real-time tired or recovered observations.",
+                        "If the user only needs an explanation or planning read, use the overview first and do not turn the conversation into a profile or template mutation.",
+                        "For profile or weekday-template edits, ask what future planning behavior should change, such as workload, recovery time, timeboxes, meeting load, or task choice, so the write is not just a nicer description.",
                         "If the user says something like 'I always dip on Tuesdays after lunch', treat that as a weekday-template change rather than a one-off fatigue signal.",
                         "If the user is asking what changed after a profile, template, or fatigue write, read the overview back so the effect stays visible.",
                         "If the user already knows they want a profile change, weekday-template edit, or right-now fatigue signal, skip the broad lane question and ask only for the missing weekday, profile field, or signal detail."
@@ -4883,6 +4891,7 @@ function buildAgentOnboardingPayload(request) {
                     routeKeys: ["overview", "profile", "weekdayTemplate", "fatigueSignal"],
                     routeSelectionQuestions: [
                         "Is the user trying to understand the overview, change durable profile assumptions, change a weekday curve, or log a right-now fatigue signal?",
+                        "What planning decision should the overview or correction change: workload, recovery, timeboxes, meetings, or task choice?",
                         "Are they describing a repeatable weekly shape or a one-off current state?",
                         "If the lane is already clear, what one weekday, profile field, or signal detail is still missing?"
                     ],
@@ -4906,6 +4915,8 @@ function buildAgentOnboardingPayload(request) {
                         "Route-selection questions are internal. User-facing questions should ask whether this is a current read, durable assumption, repeated weekday rhythm, or right-now state instead of reciting overview/profile/template/signal route keys.",
                         "Use GET /api/v1/life-force for the current overview payload with stats, drains, recommendations, and current-curve state.",
                         "Patch the profile only for durable personal settings, update weekday templates only for the curve itself, and post fatigue signals for real-time tired or recovered observations.",
+                        "If the user only needs an explanation or planning read, use the overview first and do not turn the conversation into a profile or template mutation.",
+                        "For profile or weekday-template edits, ask what future planning behavior should change, such as workload, recovery time, timeboxes, meeting load, or task choice, so the write is not just a nicer description.",
                         "If the user says something like 'I always dip on Tuesdays after lunch', treat that as a weekday-template change rather than a one-off fatigue signal.",
                         "If the user is asking what changed after a profile, template, or fatigue write, read the overview back so the effect stays visible.",
                         "If the user already knows they want a profile change, weekday-template edit, or right-now fatigue signal, skip the broad lane question and ask only for the missing weekday, profile field, or signal detail."
@@ -4935,6 +4946,7 @@ function buildAgentOnboardingPayload(request) {
                     ],
                     routeSelectionQuestions: [
                         "Is the job flow discovery, flow creation, flow editing, flow deletion, execution, run history, published output, run detail, node result, latest node output, or flow chat follow-up?",
+                        "If this is execution, is it a known saved flow, a one-off input run, or a flow that should become reusable?",
                         "Does the user need a stable public contract or one execution artifact?",
                         "For flow CRUD, what stable input contract, expected output, or lifecycle effect must stay true?",
                         "For flow chat follow-up, which saved flow should receive the message and what should the message accomplish?",
@@ -4984,6 +4996,7 @@ function buildAgentOnboardingPayload(request) {
                         "Use the flow routes when the agent needs stable public input contracts, published outputs, node-level results, or reusable execution history.",
                         "If the user is still figuring out inputs or editable structure, read flow detail or box catalog before asking them to reconstruct structured inputs from memory.",
                         "For flow creation, clarify what the flow should reliably produce, which input contract it should accept, and which first node or box anchors the flow before asking for structured input details.",
+                        "For one-off execution, do not create a saved flow unless the user wants reuse. Ask whether the input contract should stay temporary or become durable, then use POST /api/v1/workbench/run for the temporary case.",
                         "For flow edits, ask what behavior should change while preserving the public contract unless the user explicitly wants the contract changed.",
                         "For flow deletion, confirm the saved flow and whether published outputs or run history need preservation elsewhere before using the delete route.",
                         "For saved flow chat follow-ups, use POST /api/v1/workbench/flows/:id/chat only when the user wants to continue a flow-specific conversation. Do not turn that into a new run, note, or generic entity update unless the user asks.",

package/dist/server/server/src/health.js

@@ -2735,6 +2735,97 @@ function mobileSyncSessionProgress(syncSessionId) {
         receivedBytes: chunks.reduce((sum, chunk) => sum + chunk.byte_count, 0)
     };
 }
+function finiteNumberFromUnknown(value) {
+    if (typeof value === "number" && Number.isFinite(value)) {
+        return value;
+    }
+    if (typeof value === "string" && value.trim().length > 0) {
+        const parsed = Number(value);
+        return Number.isFinite(parsed) ? parsed : null;
+    }
+    return null;
+}
+function nestedRecord(value) {
+    return value && typeof value === "object" && !Array.isArray(value)
+        ? value
+        : {};
+}
+function expectedWorkoutEvidenceCounts(derived) {
+    const syncCursor = nestedRecord(derived.syncCursor);
+    const captureQuality = nestedRecord(derived.captureQuality);
+    const syncTimeSeriesCount = finiteNumberFromUnknown(syncCursor.timeSeriesSampleCount);
+    const captureHeartRateCount = finiteNumberFromUnknown(captureQuality.heartRateSamples);
+    const syncRoutePointCount = finiteNumberFromUnknown(syncCursor.routePointCount);
+    const captureRoutePointCount = finiteNumberFromUnknown(captureQuality.routePoints);
+    const expectedTimeSeriesSamples = Math.max(0, Math.ceil(Math.max(syncTimeSeriesCount ?? 0, captureHeartRateCount ?? 0)));
+    const expectedRoutePoints = Math.max(0, Math.ceil(Math.max(syncRoutePointCount ?? 0, captureRoutePointCount ?? 0)));
+    return {
+        expectedTimeSeriesSamples,
+        expectedRoutePoints,
+        hasEvidenceMetadata: syncTimeSeriesCount !== null ||
+            captureHeartRateCount !== null ||
+            syncRoutePointCount !== null ||
+            captureRoutePointCount !== null
+    };
+}
+function mobileHealthWorkoutImportState(userId) {
+    const rows = getDatabase()
+        .prepare(`WITH time_series_counts AS (
+         SELECT workout_id, COUNT(*) AS time_series_count
+         FROM health_workout_time_series
+         GROUP BY workout_id
+       ),
+       route_counts AS (
+         SELECT workout_id, COUNT(*) AS route_point_count
+         FROM health_workout_routes
+         GROUP BY workout_id
+       )
+       SELECT
+         w.external_uid,
+         w.derived_json,
+         COALESCE(time_series_counts.time_series_count, 0) AS time_series_count,
+         COALESCE(route_counts.route_point_count, 0) AS route_point_count
+       FROM health_workout_sessions w
+       LEFT JOIN time_series_counts ON time_series_counts.workout_id = w.id
+       LEFT JOIN route_counts ON route_counts.workout_id = w.id
+       WHERE w.user_id = ?
+         AND w.source = 'apple_health'
+         AND w.external_uid IS NOT NULL
+         AND w.external_uid <> ''
+       ORDER BY w.started_at DESC`)
+        .all(userId);
+    const alreadyUploadedWorkoutExternalUids = [];
+    let incompleteWorkoutCount = 0;
+    let timeSeriesSampleCount = 0;
+    let routePointCount = 0;
+    for (const row of rows) {
+        const derived = safeJsonParse(row.derived_json, {});
+        const evidenceCounts = expectedWorkoutEvidenceCounts(derived);
+        const actualTimeSeriesCount = Math.max(0, row.time_series_count ?? 0);
+        const actualRoutePointCount = Math.max(0, row.route_point_count ?? 0);
+        const evidenceComplete = evidenceCounts.hasEvidenceMetadata
+            ? actualTimeSeriesCount >= evidenceCounts.expectedTimeSeriesSamples &&
+                actualRoutePointCount >= evidenceCounts.expectedRoutePoints
+            : actualTimeSeriesCount + actualRoutePointCount > 0;
+        if (evidenceComplete) {
+            alreadyUploadedWorkoutExternalUids.push(row.external_uid.toLowerCase());
+            timeSeriesSampleCount += actualTimeSeriesCount;
+            routePointCount += actualRoutePointCount;
+        }
+        else {
+            incompleteWorkoutCount += 1;
+        }
+    }
+    return {
+        alreadyUploadedWorkoutExternalUids,
+        alreadyUploadedWorkoutCount: alreadyUploadedWorkoutExternalUids.length,
+        existingWorkoutCount: rows.length,
+        incompleteWorkoutCount,
+        timeSeriesSampleCount,
+        routePointCount,
+        capturedAt: nowIso()
+    };
+}
 function mobileSyncSessionUploadPayload(session, receivedChunkIds) {
     return {
         syncSessionId: session.id,
@@ -2747,6 +2838,7 @@ function mobileSyncSessionUploadPayload(session, receivedChunkIds) {
         supportsCompression: true,
         acceptedFamilies: safeJsonParse(session.requested_families_json, []),
         receivedChunkIds,
+        workoutImportState: mobileHealthWorkoutImportState(session.user_id),
         progress: mobileSyncSessionProgress(session.id)
     };
 }

package/openclaw.plugin.json

@@ -2,7 +2,7 @@
   "id": "forge-openclaw-plugin",
   "name": "Forge",
   "description": "Curated OpenClaw adapter for the Forge collaboration API, UI entrypoint, and localhost auto-start runtime.",
-  "version": "0.2.91",
+  "version": "0.2.92",
   "activation": {
     "onStartup": true,
     "onCapabilities": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forge-openclaw-plugin",
-  "version": "0.2.91",
+  "version": "0.2.92",
   "description": "Curated OpenClaw adapter for the Forge collaboration API, UI entrypoint, and localhost auto-start runtime.",
   "type": "module",
   "license": "Apache-2.0",

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -1537,9 +1537,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, change movement operating
-settings, or link movement context to another Forge record before choosing the
-dedicated route family.
+behavior, add or update a stay or trip, create or clean up a known place, change
+movement operating settings, or link movement context to another Forge record before
+choosing the dedicated route family.
 
 Arc:
 
@@ -1548,17 +1548,19 @@ Arc:
 2. Ask whether the user is trying to query behavior, add something manually, update
    an existing movement item, or link movement to another Forge entity.
 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. If the user is changing movement operating behavior, ask whether the change is
+4. If this is place creation or cleanup, ask what label, boundary, and future use
+   should make the place recognizable later.
+5. Ask for the time window, place, or movement item that makes the question concrete.
+6. Ask what they are trying to notice, preserve, or answer through that movement context.
+7. 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,
+8. 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
+9. If the truth of one uncertain span is still unclear, read the timeline or saved-box
    detail before you mutate it.
-9. Skip the meta lane question when the user already named the exact correction or
+10. Skip the meta lane question when the user already named the exact correction or
    review target and only one ambiguity remains.
-10. Use the dedicated movement route once you know whether the user needs timeline
+11. 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:
@@ -1591,12 +1593,17 @@ Direct action rules:
   interval or place if that is still ambiguous, then act.
 - When you do act on a concrete missing-gap correction, create the overlay and read
   the relevant timeline back instead of leaving the correction ungrounded.
+- For known-place creation or cleanup, ask what the place should be called, what
+  counts inside its boundary, and how future movement reads should use it. Use the
+  dedicated place routes, not a tag or batch entity write.
 
 Helpful follow-up lanes:
 
 - whether the user wants time-in-place, travel history, one specific stay or trip, a
   place summary, or a link
 - what time window, place, stay, trip, or selection is in scope
+- what label, boundary, or future-use distinction makes a known place worth saving or
+  renaming
 - whether the question is behavioral, such as time at home, travel frequency, or place
   distribution, versus an edit
 - whether the edit is a missing-gap overlay versus a true recorded stay/trip patch
@@ -1649,7 +1656,8 @@ Preferred opening question:
 ## Life Force
 
 Aim: clarify whether the user wants to review current energy state, change durable
-profile assumptions, edit weekday curves, or log a real-time fatigue signal.
+profile assumptions, edit weekday curves, log a real-time fatigue signal, or make a
+planning decision based on the energy model.
 
 Arc:
 
@@ -1657,22 +1665,25 @@ Arc:
    you reduce it to one life-force lane.
 2. Ask whether the job is overview, profile change, weekday-template change, or fatigue signaling.
 3. Ask what part of the current energy picture feels most important or inaccurate.
-4. Ask what should stay true if they are changing profile or template assumptions.
-5. Ask whether the user is describing a stable weekly shape or just how today feels
+4. Ask what planning decision should change if the model is corrected: workload,
+   recovery, timeboxing, meeting load, or task choice.
+5. Ask what should stay true if they are changing profile or template assumptions.
+6. Ask whether the user is describing a stable weekly shape or just how today feels
    when the lane is still blurred.
-6. If the user describes a repeatable day-shape such as "Mondays crash after lunch",
+7. If the user describes a repeatable day-shape such as "Mondays crash after lunch",
    treat that as a weekday-template question before you reach for profile or
    fatigue-signal routes.
-7. If the user already named the life-force lane clearly, skip the meta lane question
+8. If the user already named the life-force lane clearly, skip the meta lane question
    and ask only for the specific weekday, profile field, or signal that still matters.
-8. If the user wants to see what changed after a write, read the overview back instead
+9. If the user wants to see what changed after a write, read the overview back instead
    of leaving the result implicit.
-9. Route to the dedicated life-force path once the lane is clear.
+10. Route to the dedicated life-force path once the lane is clear.
 
 Helpful follow-up lanes:
 
 - whether the user wants explanation, editing, or signaling
 - what part of the energy model feels off or useful
+- what planning decision the overview or correction should change
 - what durable assumption versus real-time state is being changed
 - whether the user is describing a stable weekly shape or just how today feels
 
@@ -1704,6 +1715,11 @@ Direct action rules:
   instead of treating it as a one-off right-now feeling.
 - If the user is describing how one weekday should usually feel, update that weekday
   template instead of editing the profile.
+- If the user only needs an explanation or planning read, use the overview first and
+  do not turn the conversation into a profile or template mutation.
+- For profile or weekday-template edits, ask what future planning behavior should
+  change, such as workload, recovery time, timeboxes, meeting load, or task choice,
+  so the write is not just a more polished description.
 - If the user says something like "I always dip on Tuesdays after lunch", treat that
   as a weekday-template edit, not as a one-off fatigue signal.
 - If the user is describing right-now depletion or recovery, post a fatigue signal and
@@ -1737,18 +1753,20 @@ Arc:
 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
+6. If the user wants one-off execution, clarify whether this should stay a one-time
+   input run or become a reusable saved flow before creating anything durable.
+7. 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
+8. 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
+9. 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.
-9. If the user wants a stable public input contract or published output, prefer those
+10. If the user wants a stable public input contract or published output, prefer those
    dedicated reads instead of detouring through run history first.
-10. If the user is debugging one failed run, ask whether the useful artifact is the run
+11. 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.
-11. Route to the dedicated workbench route family once the execution lane is clear.
+12. Route to the dedicated workbench route family once the execution lane is clear.
 
 Helpful follow-up lanes:
 
@@ -1756,6 +1774,7 @@ Helpful follow-up lanes:
 - what exact flow or run is in scope
 - whether they need whole-flow output or node-level detail
 - whether they need a public input contract or a published output instead of a debug trace
+- whether a requested execution should remain one-off or become a reusable saved flow
 
 Lane-to-route map:
 
@@ -1796,6 +1815,9 @@ Direct action rules:
 - If the user wants one-off input execution without depending on a saved flow id, use
   `POST /api/v1/workbench/run` through the dedicated one-off execution lane and keep
   the user-facing question about the one-off input contract.
+- For one-off execution, do not create a saved flow unless the user wants reuse. Ask
+  whether the input contract should be temporary or durable, then route to
+  `POST /api/v1/workbench/run` for the temporary case.
 - If the user wants to debug one failed execution, narrow whether they need the run
   detail, one node result, the latest node output, or the published output before you
   ask for flow changes.