forge-openclaw-plugin 0.2.45 → 0.2.48

package/dist/server/server/src/watch-mobile.js

@@ -5,6 +5,7 @@ import { HttpError } from "./errors.js";
 import { updateWorkoutMetadata } from "./health.js";
 import { canonicalizeMovementCategoryTags, listMovementPlaces, normalizeMovementCategoryTag, updateMovementPlace } from "./movement.js";
 import { listHabits } from "./repositories/habits.js";
+import { formatLocalDateKey } from "../../src/lib/date-keys.js";
 const watchCapability = "watch-ready";
 const watchHistoryStateSchema = z.enum(["aligned", "unaligned", "unknown"]);
 const watchPromptKindSchema = z.enum([
@@ -56,7 +57,11 @@ export const mobileWatchHabitCheckInSchema = z.object({
     sessionId: z.string().trim().min(1),
     pairingToken: z.string().trim().min(1),
     dedupeKey: z.string().trim().min(1),
-    dateKey: z.string().trim().min(1).default(new Date().toISOString().slice(0, 10)),
+    dateKey: z
+        .string()
+        .trim()
+        .min(1)
+        .default(() => formatLocalDateKey()),
     status: z.enum(["done", "missed"]),
     note: z.string().trim().default(""),
     description: z.string().trim().optional()
@@ -82,24 +87,24 @@ function nowIso() {
     return new Date().toISOString();
 }
 function formatDateKey(date) {
-    return date.toISOString().slice(0, 10);
+    return formatLocalDateKey(date);
 }
 function parseDateKey(dateKey) {
     const [year, month, day] = dateKey.split("-").map(Number);
-    return new Date(Date.UTC(year, month - 1, day));
+    return new Date(year, month - 1, day);
 }
-function startOfUtcDay(date) {
-    return new Date(Date.UTC(date.getUTCFullYear(), date.getUTCMonth(), date.getUTCDate()));
+function startOfLocalDay(date) {
+    return new Date(date.getFullYear(), date.getMonth(), date.getDate());
 }
-function addUtcDays(date, days) {
+function addLocalDays(date, days) {
     const next = new Date(date);
-    next.setUTCDate(next.getUTCDate() + days);
+    next.setDate(next.getDate() + days);
     return next;
 }
-function startOfUtcWeek(date) {
-    const start = startOfUtcDay(date);
-    const offset = (start.getUTCDay() + 6) % 7;
-    start.setUTCDate(start.getUTCDate() - offset);
+function startOfLocalWeek(date) {
+    const start = startOfLocalDay(date);
+    const offset = (start.getDay() + 6) % 7;
+    start.setDate(start.getDate() - offset);
     return start;
 }
 function isAlignedCheckIn(habit, status) {
@@ -125,15 +130,15 @@ function buildHabitHistory(habit, options) {
         ? parseDateKey(options.anchorDateKey)
         : new Date();
     if (habit.frequency === "daily") {
-        const today = startOfUtcDay(now);
+        const today = startOfLocalDay(now);
         return Array.from({ length: 7 }, (_, index) => {
             const offset = index - 6;
-            const date = addUtcDays(today, offset);
+            const date = addLocalDays(today, offset);
             const dateKey = formatDateKey(date);
             const checkIn = habit.checkIns.find((entry) => entry.dateKey === dateKey) ?? null;
             return {
                 id: dateKey,
-                label: ["S", "M", "T", "W", "T", "F", "S"][date.getUTCDay()],
+                label: ["S", "M", "T", "W", "T", "F", "S"][date.getDay()],
                 periodKey: dateKey,
                 current: offset === 0,
                 state: checkIn
@@ -144,13 +149,13 @@ function buildHabitHistory(habit, options) {
             };
         });
     }
-    const thisWeek = startOfUtcWeek(now);
+    const thisWeek = startOfLocalWeek(now);
     return Array.from({ length: 7 }, (_, index) => {
         const offset = index - 6;
-        const weekStart = addUtcDays(thisWeek, offset * 7);
+        const weekStart = addLocalDays(thisWeek, offset * 7);
         const weekKey = formatDateKey(weekStart);
         const weekEntries = habit.checkIns.filter((entry) => {
-            const entryWeek = formatDateKey(startOfUtcWeek(parseDateKey(entry.dateKey)));
+            const entryWeek = formatDateKey(startOfLocalWeek(parseDateKey(entry.dateKey)));
             return entryWeek === weekKey;
         });
         const alignedCount = weekEntries.filter((entry) => isAlignedCheckIn(habit, entry.status)).length;
@@ -375,7 +380,9 @@ function projectionForStoredEvent(event) {
         const categoryCandidate = Array.isArray(event.payload.categoryTags)
             ? event.payload.categoryTags
             : typeof event.payload.category === "string"
-                ? watchCategoryMap.get(event.payload.category) ?? [event.payload.category]
+                ? (watchCategoryMap.get(event.payload.category) ?? [
+                    event.payload.category
+                ])
                 : [];
         const categoryTags = canonicalizeMovementCategoryTags(categoryCandidate.flatMap((value) => typeof value === "string" ? [normalizeMovementCategoryTag(value)] : []));
         try {
@@ -403,12 +410,15 @@ function projectionForStoredEvent(event) {
                 status: "projection_failed",
                 details: {
                     reason: "place_update_failed",
-                    message: error instanceof Error ? error.message : "Unknown place update error"
+                    message: error instanceof Error
+                        ? error.message
+                        : "Unknown place update error"
                 }
             };
         }
     }
-    if (event.eventType === "workout_annotation" && event.linkedContext.workoutId) {
+    if (event.eventType === "workout_annotation" &&
+        event.linkedContext.workoutId) {
         try {
             const workout = updateWorkoutMetadata(event.linkedContext.workoutId, {
                 subjectiveEffort: typeof event.payload.subjectiveEffort === "number"
@@ -449,7 +459,9 @@ function projectionForStoredEvent(event) {
                 status: "projection_failed",
                 details: {
                     reason: "workout_update_failed",
-                    message: error instanceof Error ? error.message : "Unknown workout update error"
+                    message: error instanceof Error
+                        ? error.message
+                        : "Unknown workout update error"
                 }
             };
         }

package/dist/server/src/lib/date-keys.js

@@ -0,0 +1,21 @@
+function readPart(parts, type) {
+    return parts.find((part) => part.type === type)?.value ?? "";
+}
+export function getRuntimeTimeZone() {
+    return Intl.DateTimeFormat().resolvedOptions().timeZone || "UTC";
+}
+export function formatDateKeyInTimeZone(date, timeZone) {
+    const parts = new Intl.DateTimeFormat("en-CA", {
+        timeZone,
+        year: "numeric",
+        month: "2-digit",
+        day: "2-digit"
+    }).formatToParts(date);
+    const year = readPart(parts, "year");
+    const month = readPart(parts, "month");
+    const day = readPart(parts, "day");
+    return `${year}-${month}-${day}`;
+}
+export function formatLocalDateKey(date = new Date()) {
+    return formatDateKeyInTimeZone(date, getRuntimeTimeZone());
+}

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.45",
+  "version": "0.2.48",
   "skills": [
     "./skills"
   ],

package/package.json

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

package/skills/forge-openclaw/SKILL.md

@@ -239,7 +239,8 @@ CRITICAL NEGATIVE-HABIT CHECK-IN RULE:
 - For a `negative` habit, the correct check-in outcome is `missed`.
 - On a `negative` habit, `missed` means the habit was resisted, the user stayed aligned, and the habit earns its XP bonus.
 - Do not treat `missed` on a `negative` habit as failure. In this case, `missed` is the successful outcome.
-- Habit check-ins written through `/api/v1/habits/:id/check-ins` can also include an optional `description`; when present, it replaces the habit's current `description` in the same write.
+- In OpenClaw, official habit outcome logging should go through `forge_update_entities` on `entityType: "habit"` with `patch: { checkIn: { status, dateKey?, note?, description? } }`.
+- Do not bypass the shared tool model with raw habit routes when the batch entity update already covers the write cleanly.
   Ask:
 
 1. What is the recurring behavior in one concrete sentence?
@@ -387,6 +388,7 @@ Use the dedicated domain routes for specialized surfaces that are not simple bat
   `/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.
 - 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.
 
 Use live work tools for `task_run`:

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -56,6 +56,8 @@ Forge correctly, and gather only the structure that still matters.
 - For specialized surfaces, start from the user's real job in plain language, then
   narrow to the route family. Do not open with a route menu unless the user already
   named the exact object and action.
+- For specialized surfaces, if the truth of the current state is still uncertain, read
+  the relevant dedicated view before you mutate it.
 - When the user has already named a precise correction or review target, do not widen
   back out into a meta lane question. Confirm only the missing route-selecting detail
   and then act.
@@ -411,7 +413,7 @@ about linking only after the main record already feels named and steady.
 
 Use this when the user is updating an existing record rather than creating a new one.
 
-1. Ask what feels newly true, newly urgent, or newly clear.
+1. Ask what feels newly true, newly inaccurate, or newly clear.
 2. Ask what should stay true so the record keeps its core meaning.
 3. Ask what prompted the update now if that changes the shape of the record.
 4. Then ask only for the missing structural detail required by the change.
@@ -1017,9 +1019,11 @@ Arc:
 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. Skip the meta lane question when the user already named the exact correction or
+7. 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
    review target and only one ambiguity remains.
-8. Route to the dedicated movement read or write path once the surface is clear.
+9. Route to the dedicated movement read or write path once the surface is clear.
 
 Direct action rules:
 
@@ -1036,6 +1040,8 @@ Direct action rules:
 - If the user wants to inspect one already-saved movement correction before editing
   it, read the box detail first so the follow-up write stays grounded in the saved
   object.
+- If the user is asking where they were during one uncertain window, prefer a timeline
+  read before you create a correction. Mutate only after the lived truth is clear.
 - When the user has already given the real answer, for example "I stayed home during
   that missing block", do not ask a broad review question again. Confirm only the
   interval or place if that is still ambiguous, then act.
@@ -1105,11 +1111,14 @@ Arc:
 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
    when the lane is still blurred.
-6. If the user already named the life-force lane clearly, skip the meta lane question
+6. 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
    and ask only for the specific weekday, profile field, or signal that still matters.
-7. If the user wants to see what changed after a write, read the overview back instead
+8. If the user wants to see what changed after a write, read the overview back instead
    of leaving the result implicit.
-8. Route to the dedicated life-force path once the lane is clear.
+9. Route to the dedicated life-force path once the lane is clear.
 
 Helpful follow-up lanes:
 
@@ -1133,6 +1142,8 @@ Direct action rules:
 
 - If the user is describing a durable baseline such as work capacity, recovery style,
   or action-point assumptions, patch the profile instead of logging a fatigue signal.
+- If the user is describing a repeatable weekday rhythm, update that weekday template
+  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 is describing right-now depletion or recovery, post a fatigue signal and
@@ -1161,12 +1172,16 @@ Arc:
    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.
 3. Ask which flow, slug, run, or node the request is about.
-4. Ask whether they need the flow contract, a run result, a published output, or a node result.
+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
    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
    dedicated reads instead of detouring through run history first.
-7. Route to the dedicated workbench route family once the execution lane is clear.
+7. 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.
 
 Helpful follow-up lanes:
 
@@ -1205,6 +1220,9 @@ Direct action rules:
 - If the user wants to execute a known saved flow, use `/api/v1/workbench/flows/:id/run`.
 - If the user wants payload-first execution without depending on a saved flow id, use
   `/api/v1/workbench/run`.
+- 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.
 - If the user wants one node's latest successful output, do not browse old runs first
   unless they explicitly want historical debugging.
 - If the user wants to understand what inputs a flow can accept before editing or

package/skills/forge-openclaw/psyche_entity_playbooks.md

@@ -383,6 +383,9 @@ If the entity is not yet clear:
   hold and what the new episode or evidence changes.
 - If a recent charged episode is what made the update visible, anchor in that episode
   before you rename the durable belief, pattern, mode, or value.
+- If the user already gives the new sentence in usable language, revise the wording
+  once and save instead of reopening evidence, origin, or repair just because those
+  lanes are available.
 - If another belief, value, pattern, mode, or note becomes visible, name it gently but
   do not switch containers unless the user wants to.