forge-openclaw-plugin 0.2.28 → 0.2.29

package/dist/server/server/src/types.js

@@ -45,7 +45,8 @@ export const calendarProviderSchema = z.enum([
     "google",
     "apple",
     "caldav",
-    "microsoft"
+    "microsoft",
+    "macos_local"
 ]);
 export const calendarConnectionStatusSchema = z.enum([
     "connected",
@@ -59,8 +60,16 @@ export const calendarEventOriginSchema = z.enum([
     "apple",
     "caldav",
     "microsoft",
+    "macos_local",
     "derived"
 ]);
+export const macosCalendarAccessStatusSchema = z.enum([
+    "not_determined",
+    "denied",
+    "restricted",
+    "full_access",
+    "unavailable"
+]);
 export const calendarAvailabilitySchema = z.enum(["busy", "free"]);
 export const calendarEventStatusSchema = z.enum([
     "confirmed",
@@ -792,7 +801,13 @@ export const calendarDiscoveryCalendarSchema = z.object({
     isPrimary: z.boolean(),
     canWrite: z.boolean(),
     selectedByDefault: z.boolean(),
-    isForgeCandidate: z.boolean()
+    isForgeCandidate: z.boolean(),
+    sourceId: trimmedString.nullable().default(null),
+    sourceTitle: trimmedString.nullable().default(null),
+    sourceType: trimmedString.nullable().default(null),
+    calendarType: trimmedString.nullable().default(null),
+    hostCalendarId: trimmedString.nullable().default(null),
+    canonicalKey: trimmedString.nullable().default(null)
 });
 export const calendarDiscoveryPayloadSchema = z.object({
     provider: calendarProviderSchema,
@@ -802,6 +817,19 @@ export const calendarDiscoveryPayloadSchema = z.object({
     homeUrl: z.string().nullable(),
     calendars: z.array(calendarDiscoveryCalendarSchema)
 });
+export const macosLocalCalendarSourceSchema = z.object({
+    sourceId: nonEmptyTrimmedString,
+    sourceTitle: trimmedString,
+    sourceType: trimmedString,
+    accountLabel: trimmedString,
+    accountIdentityKey: trimmedString,
+    calendars: z.array(calendarDiscoveryCalendarSchema)
+});
+export const macosLocalCalendarDiscoveryPayloadSchema = z.object({
+    status: macosCalendarAccessStatusSchema,
+    requestedAt: z.string(),
+    sources: z.array(macosLocalCalendarSourceSchema)
+});
 export const calendarSchema = z.object({
     id: z.string(),
     connectionId: z.string(),
@@ -814,6 +842,12 @@ export const calendarSchema = z.object({
     canWrite: z.boolean(),
     selectedForSync: z.boolean(),
     forgeManaged: z.boolean(),
+    sourceId: trimmedString.nullable().default(null),
+    sourceTitle: trimmedString.nullable().default(null),
+    sourceType: trimmedString.nullable().default(null),
+    calendarType: trimmedString.nullable().default(null),
+    hostCalendarId: trimmedString.nullable().default(null),
+    canonicalKey: trimmedString.nullable().default(null),
     lastSyncedAt: z.string().nullable(),
     createdAt: z.string(),
     updatedAt: z.string()
@@ -2358,6 +2392,15 @@ export const createCalendarConnectionSchema = z.discriminatedUnion("provider", [
         label: nonEmptyTrimmedString,
         authSessionId: nonEmptyTrimmedString,
         selectedCalendarUrls: z.array(nonEmptyTrimmedString.url()).min(1)
+    }),
+    z.object({
+        provider: z.literal("macos_local"),
+        label: nonEmptyTrimmedString,
+        sourceId: nonEmptyTrimmedString,
+        selectedCalendarUrls: z.array(nonEmptyTrimmedString.url()).min(1),
+        forgeCalendarUrl: nonEmptyTrimmedString.url().nullable().optional(),
+        createForgeCalendar: z.boolean().optional().default(false),
+        replaceConnectionIds: z.array(nonEmptyTrimmedString).optional().default([])
     })
 ]);
 export const discoverCalendarConnectionSchema = z.discriminatedUnion("provider", [
@@ -2834,6 +2877,7 @@ export const updateTaskSchema = z.object({
     title: nonEmptyTrimmedString.optional(),
     description: trimmedString.optional(),
     status: taskStatusSchema.optional(),
+    completedAt: dateTimeSchema.optional(),
     priority: taskPrioritySchema.optional(),
     owner: nonEmptyTrimmedString.optional(),
     userId: nonEmptyTrimmedString.nullable().optional(),

package/dist/server/src/lib/api-error.js

@@ -3,6 +3,7 @@ export class ForgeApiError extends Error {
     code;
     details;
     requestPath;
+    response;
     constructor(input) {
         super(input.message);
         this.name = "ForgeApiError";
@@ -10,6 +11,7 @@ export class ForgeApiError extends Error {
         this.code = input.code;
         this.details = input.details ?? [];
         this.requestPath = input.requestPath;
+        this.response = input.response ?? null;
     }
 }
 export function describeApiError(error) {

package/dist/server/src/lib/api.js

@@ -130,7 +130,12 @@ async function request(path, init) {
                         ? body
                         : `Request failed: ${response.status}`,
             requestPath: path,
-            details
+            details,
+            response: typeof body === "string"
+                ? body
+                : body && typeof body === "object"
+                    ? body
+                    : null
         });
     }
     return body;
@@ -161,7 +166,12 @@ async function requestBlob(path, init) {
                     ? maybeBody.message
                     : `Request failed: ${response.status}`,
             requestPath: path,
-            details: []
+            details: [],
+            response: typeof body === "string"
+                ? body
+                : body && typeof body === "object"
+                    ? body
+                    : null
         });
     }
     const disposition = response.headers.get("content-disposition");
@@ -1109,6 +1119,33 @@ export function discoverCalendarConnection(input) {
         discovery: dedupeCalendarDiscoveryPayload(response.discovery)
     }));
 }
+export function getMacOSLocalCalendarStatus() {
+    return request("/api/v1/calendar/macos-local/status");
+}
+export function requestMacOSLocalCalendarAccess() {
+    return request("/api/v1/calendar/macos-local/request-access", {
+        method: "POST"
+    });
+}
+export function discoverMacOSLocalCalendarSources() {
+    return request("/api/v1/calendar/macos-local/discovery").then((response) => ({
+        ...response,
+        discovery: {
+            ...response.discovery,
+            sources: response.discovery.sources.map((source) => ({
+                ...source,
+                calendars: dedupeCalendarDiscoveryPayload({
+                    provider: "macos_local",
+                    accountLabel: source.accountLabel,
+                    serverUrl: "forge-macos-local://eventkit/",
+                    principalUrl: null,
+                    homeUrl: null,
+                    calendars: source.calendars
+                }).calendars
+            }))
+        }
+    }));
+}
 export function startGoogleCalendarOauth(input) {
     return request("/api/v1/calendar/oauth/google/start", {
         method: "POST",

package/dist/server/src/lib/calendar-name-deduper.js

@@ -16,6 +16,8 @@ function shortCalendarProviderLabel(provider) {
             return "Apple";
         case "microsoft":
             return "Microsoft";
+        case "macos_local":
+            return "Mac";
         case "caldav":
         default:
             return "CalDAV";

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

package/package.json

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

package/server/migrations/044_macos_local_calendar_provider.sql

@@ -0,0 +1,21 @@
+ALTER TABLE calendar_calendars
+ADD COLUMN source_id TEXT;
+
+ALTER TABLE calendar_calendars
+ADD COLUMN source_title TEXT;
+
+ALTER TABLE calendar_calendars
+ADD COLUMN source_type TEXT;
+
+ALTER TABLE calendar_calendars
+ADD COLUMN calendar_type TEXT;
+
+ALTER TABLE calendar_calendars
+ADD COLUMN host_calendar_id TEXT;
+
+ALTER TABLE calendar_calendars
+ADD COLUMN canonical_key TEXT;
+
+UPDATE calendar_calendars
+SET canonical_key = remote_id
+WHERE canonical_key IS NULL OR TRIM(canonical_key) = '';

package/skills/forge-openclaw/SKILL.md

@@ -57,9 +57,15 @@ Entity conversation rule:
 - Prefer a progression of:
   concrete example or intent -> working name -> purpose or meaning -> placement in Forge -> operational details -> linked context.
 - Use those same playbooks for action-heavy non-Psyche flows such as `work_adjustment`, `preference_judgment`, `preference_signal`, and specialized `movement`, `life_force`, or `workbench` requests so the conversation starts from what the user is trying to understand, change, add, update, link, or run before you choose the route.
+- When the operation is not already explicit, identify the job first:
+  add, update, review, compare, navigate, link, or run. Skip that meta question
+  when the action is already obvious from the user's wording.
 - For emotionally meaningful non-Psyche records such as goals, habits, and notes, reflect the meaning before you ask for structure.
 - When the user is vague, ask for one small concrete example, stake, or desired outcome before you ask them to name the record.
 - When the user is clear, say what the record seems to be becoming and ask only for the last missing detail.
+- When the user wants to review, compare, inspect, or navigate an existing Forge
+  record, ask what they are trying to understand first and prefer the read path 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.
 - The quick intake prompts later in this file are fallback checkpoints, not a script to read aloud.
@@ -261,8 +267,9 @@ Minimum field: `label`
 Usually useful: `description`
 Ask:
 
-1. What should this event type be called?
-2. What kind of incident does it represent?
+1. What kind of repeated moment or incident do you want future reports to name the same way?
+2. What would count as inside this category, and what should stay outside it?
+3. If the meaning is clear but the wording is not, would you like me to suggest a concise label?
 
 `emotion_definition`
 Use for a reusable emotion vocabulary entry.
@@ -270,9 +277,9 @@ Minimum field: `label`
 Usually useful: `description`, `category`
 Ask:
 
-1. What emotion label do you want to reuse?
-2. How would you describe it?
-3. Does it belong to a broader category?
+1. When this feeling is present, what tells you it is this feeling and not a nearby one?
+2. What would you want a later trigger report to mean when it uses this label?
+3. If the felt meaning is clear but the wording is not, would you like me to suggest a concise label or broader category?
 
 Use these rules when choosing tools.
 
@@ -296,11 +303,20 @@ Use the dedicated domain routes for specialized surfaces that are not simple bat
 
 - Movement lives under `/api/v1/movement/*`. Treat it as a dedicated timeline of `stays` and `trips`, not as generic batch CRUD. A `stay` means the user remained in the same place for a span of time. A `trip` means the user traveled between places. Use the movement routes when the user wants to understand time in place, travel behavior, specific stays or trips, known places, or selected-span aggregates such as "how long was I at home in the past 2 weeks?" or "when did I travel last month?".
 - Movement user actions are: query movement behavior, add a place or manual stay/trip overlay, update an existing stay/trip/place, or link a specific movement item to another Forge entity. Keep the explanation user-facing: where they stayed, when they traveled, what changed, and what this movement should be linked to.
+- Movement read lanes map cleanly to the dedicated routes:
+  `/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`.
 - 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"`.
 - 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 lane hints:
+  use `/api/v1/workbench/flows` for flow catalog and CRUD,
+  `/api/v1/workbench/flows/:id/run` or `/api/v1/workbench/run` for execution,
+  `/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.
 
 Use live work tools for `task_run`:

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -15,6 +15,8 @@ Forge correctly, and gather only the structure that still matters.
   naming what you think the user is trying to preserve, clarify, decide, schedule, or
   make easier.
 - Ask only for what is missing or still unclear.
+- First identify the user's job when the lane is not already explicit:
+  are they trying to add, update, review, compare, navigate, link, or run something?
 - Before every question, decide the one missing thing you are trying to clarify.
 - Ask first for the missing thing that would change the record shape, title, or next
   action most, not just the easiest field to fill.
@@ -78,6 +80,21 @@ Most good Forge intake flows follow this sequence:
 
 That sequence is not a script. Skip steps the user already answered.
 
+## Operation lane checkpoint
+
+Use this before you choose an API path or ask for more structure.
+
+- If the user has not made the operation explicit yet, clarify the job first:
+  add, update, review, compare, navigate, link, or run.
+- Ask the lane question only when it changes the route family or the next question.
+- Skip the meta lane question when the user already gave both the entity and the
+  action clearly, such as "pause this project", "add a home stay for that missing
+  block", or "run this flow again".
+- For simple stored entities, once the lane is clear, fall back to the shared batch
+  CRUD flow.
+- For specialized surfaces such as Movement, Life Force, and Workbench, use the lane
+  to choose the dedicated route family before you ask for lower-level details.
+
 ## Active-listening patterns
 
 Use one of these shapes when the user is not yet precise.
@@ -158,6 +175,21 @@ When an adjacent record becomes visible:
 - name it gently and ask whether it should be linked now, saved separately later, or
   left alone for now
 
+## Review And Navigation Moves
+
+Use this when the user wants to inspect, compare, review, or navigate existing Forge
+records rather than create something new.
+
+- Start by asking what they are trying to understand, decide, compare, or check.
+- Ask only for the scoping detail that changes the read path most:
+  entity, owner, timeframe, context, or comparison target.
+- If the record already exists and the user wants review, do not reopen a creation
+  intake. Route to search, list, overview, or detail first.
+- For review-heavy questions, the useful progression is:
+  user goal -> scope -> read path -> interpretation -> optional follow-up write.
+- Only drift back into create or update intake if the user actually wants the record
+  changed after the review.
+
 ## Question Calibration Loop
 
 Use this quick internal check before every follow-up question.
@@ -913,6 +945,21 @@ Helpful follow-up lanes:
   distribution, versus an edit
 - whether the edit is a missing-gap overlay versus a true recorded stay/trip patch
 
+Lane-to-route map:
+
+- review one day or month:
+  `/api/v1/movement/day` or `/api/v1/movement/month`
+- review long-range behavior or dominant places:
+  `/api/v1/movement/all-time`, `/api/v1/movement/places`, or `/api/v1/movement/selection`
+- inspect the full life timeline:
+  `/api/v1/movement/timeline`
+- inspect one trip:
+  `/api/v1/movement/trips/:id`
+- fill a missing span:
+  `/api/v1/movement/user-boxes/preflight` then `/api/v1/movement/user-boxes`
+- edit an already-recorded stay, trip, or trip point:
+  `/api/v1/movement/stays/:id`, `/api/v1/movement/trips/:id`, or `/api/v1/movement/trips/:id/points/:pointId`
+
 Ready to act when:
 
 - the movement surface is clear
@@ -941,6 +988,17 @@ Helpful follow-up lanes:
 - what part of the energy model feels off or useful
 - what durable assumption versus real-time state is being changed
 
+Lane-to-route map:
+
+- understand the current energy picture:
+  `GET /api/v1/life-force`
+- change durable profile assumptions:
+  `PATCH /api/v1/life-force/profile`
+- change one weekday curve or template:
+  `PUT /api/v1/life-force/templates/:weekday`
+- log a real-time tired or recovered signal:
+  `POST /api/v1/life-force/fatigue-signals`
+
 Ready to act when:
 
 - the life-force lane is clear
@@ -969,6 +1027,27 @@ Helpful follow-up lanes:
 - what exact flow or run is in scope
 - whether they need whole-flow output or node-level detail
 
+Lane-to-route map:
+
+- discover or inspect flows:
+  `/api/v1/workbench/flows`, `/api/v1/workbench/flows/:id`, or `/api/v1/workbench/flows/by-slug/:slug`
+- create, update, or delete a flow:
+  `POST/PATCH/DELETE /api/v1/workbench/flows`
+- run a known flow:
+  `/api/v1/workbench/flows/:id/run`
+- run from a payload-first contract:
+  `/api/v1/workbench/run`
+- 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:
+  `/api/v1/workbench/flows/:id/runs/:runId`,
+  `/api/v1/workbench/flows/:id/runs/:runId/nodes`,
+  `/api/v1/workbench/flows/:id/runs/:runId/nodes/:nodeId`
+- inspect the latest successful node output:
+  `/api/v1/workbench/flows/:id/nodes/:nodeId/output`
+- inspect available box inputs:
+  `/api/v1/workbench/catalog/boxes`
+
 Ready to act when:
 
 - the workbench lane is clear
@@ -1145,10 +1224,12 @@ consistent.
 Arc:
 
 1. Ask what kind of moment or incident this label should capture in lived terms.
-2. Ask how narrow or broad it should be.
-3. Ask what would count as inside versus outside the category if that boundary is
+2. Reflect the repeated moment back in plain language before narrowing the wording.
+3. Ask how narrow or broad it should be.
+4. Ask what would count as inside versus outside the category if that boundary is
    still fuzzy.
-4. Ask for a short description only if the label could be ambiguous later.
+5. Offer a concise label if the lived meaning is clearer than the wording.
+6. Ask for a short description only if the label could be ambiguous later.
 
 If the user already offered a candidate label, keep the wording provisional and ask
 what kinds of moments belong inside it before you ask whether the label is right.
@@ -1169,8 +1250,10 @@ Aim: define one reusable emotion entry clearly enough that future reports stay p
 Arc:
 
 1. Ask what this feeling is like in lived terms when the user says it.
-2. Ask what distinguishes it from nearby emotions if that matters.
-3. Ask for a short description only if later reports would benefit from it.
+2. Reflect the felt signature back in plain language before you settle the label.
+3. Ask what distinguishes it from nearby emotions if that matters.
+4. Offer a concise label if the felt meaning is clearer than the wording.
+5. Ask for a short description only if later reports would benefit from it.
 
 Helpful follow-up lanes: