forge-openclaw-plugin 0.3.9 → 0.3.10

package/README.md

@@ -561,7 +561,7 @@ If you explicitly want the old laptop-driven publish path, run the same script w
 `FORGE_RELEASE_MODE=prepare` and it will still publish directly after pushing.
 
 For the exact prerequisites, tags, and GitHub secret names, use
-`docs/release-cheat-sheet.md`.
+`docs/release/release-cheat-sheet.md`.
 
 ClawHub note:
 

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

@@ -5455,7 +5455,9 @@ function buildAgentOnboardingPayload(request) {
             saveSuggestionTone: "gentle_optional",
             maxQuestionsPerTurn: 1,
             psycheExplorationRule: "When a Psyche entity needs understanding first, begin with one exploratory question before any working formulation, replacement belief, suggested title, or save pitch. Keep the opening reflection to one or two short sentences, stay in plain prose instead of bullets or numbered lists, keep that first reply short, do not mention Forge search or save structure yet, avoid colons or list-shaped phrasing, prefer what/when/how over why until the experience is grounded, wait for the user's answer before offering a fuller formulation, ask permission before moving from charged exploration into naming or challenge when needed, make the next question help the user feel more able to name the experience rather than more examined, do not widen into adjacent entities until the current one has a working sentence the user recognizes, and once the lived experience is coherent stop deepening and help the user name it cleanly. After one concrete example is clear and a hypothesis lands or is corrected, translate it into a saveable record shape such as a belief sentence, functional loop, behavior, mode, trigger report, value, event type, or emotion definition; ask one accuracy question instead of reopening broad exploration, then use the shared batch entity routes after the user accepts the wording or explicitly asks to save. When the user is updating a Psyche record because of one fresh episode, anchor in that episode before renaming the durable formulation, begin with the smallest part of the old wording that no longer fits, and do not reopen the full origin story unless the new understanding is truly structural. If the user accepts the wording, move toward the save instead of reopening deeper exploration.",
-            specializedSurfaceRule: "For Movement, Life Force, and Workbench, clarify the job first, then choose the dedicated route family internally and do not guess at a generic CRUD path. Use specializedDomainSurfaces.routeSelectionQuestions when they are present so the next follow-up selects the right route instead of asking generic questions. When available, use forge_call_movement_route, forge_call_life_force_route, or forge_call_workbench_route after the lane is clear. In user-facing language, talk about timeline, overlay, weekday template, published output, run detail, or node result rather than surfaces, payloads, read paths, mutation paths, or CRUD. If the truth of the current state is still uncertain, read the relevant dedicated view before you mutate it. When the user already named a precise correction or review target, confirm only the route-selecting detail that is still missing. After a concrete Movement, Life Force, or Workbench correction, read the relevant view back when the user is trying to understand the result rather than just store it. The canonical runtime routes stay under /api/v1/*, and the OpenClaw HTTP mirror exposes the same families under /forge/v1/movement, /forge/v1/life-force, and /forge/v1/workbench.",
+            progressiveDisclosureRule: "Treat partial answers as progress, not as failed intake. Before asking another question, identify what is already usable: operation, entity or surface, target record or time span, working wording, owner or placement, route lane, and consent. Say the usable part back briefly, then ask only for the first missing detail that changes the action: duplicate disambiguation, hierarchy parent, time window, weekday, flow, run, node, correction, link, or save consent. For normal batch entities, do not ask for optional tags, priority, status, dates, color, links, or assignees when the accepted wording and meaningful body are already enough unless that metadata changes accountability, retrieval, or execution. For Movement, Life Force, and Workbench, if the user's wording already implies the dedicated lane, skip the broad route-family question and ask only for the target span, place, weekday, profile field, flow, run, node, output, correction, or consent that is still missing. For direct Psyche saves or updates, treat an offered belief sentence, functional loop, part voice, trigger episode, value phrase, event kind, emotion signature, or flashcard message as real data; ask one accuracy or consent question instead of reopening origin, evidence, or repair.",
+            writeConfirmationRule: "After create, update, delete, restore, run, read, or repair actions, confirm the user-facing record, action, and result in the user's language instead of reopening intake. For batch creates and updates, confirm the working title or accepted wording, container, and owner or placement only when those changed retrieval, accountability, or execution; if optional tags, priority, status, color, links, dates, or assignees were left provisional, say that plainly once instead of asking for all of them. For action workflows, confirm the real product action such as task run started or completed, work adjustment applied, preference judgment or signal submitted, questionnaire run updated or completed, calendar connection synced, or self-observation note written. For Psyche saves, confirm the accepted wording and whether it was saved as a first version, update, link, archive, or distinct version; do not reopen origin, evidence, repair, or adjacent entity mapping after the save unless that next object is already visible and materially useful. Ask a follow-up only if it changes the next action: correction, link, schedule, run, publish, enrichment, preservation choice, or UI handoff.",
+            specializedSurfaceRule: "For Movement, Life Force, and Workbench, clarify the job first, then choose the dedicated route family internally and do not guess at a generic CRUD path. Use specializedDomainSurfaces.routeSelectionQuestions when they are present so the next follow-up selects the right route instead of asking generic questions. When available, use forge_call_movement_route, forge_call_life_force_route, or forge_call_workbench_route after the lane is clear. In user-facing language, talk about timeline, overlay, weekday template, published output, run detail, or node result rather than surfaces, payloads, read paths, mutation paths, or CRUD. If the truth of the current state is still uncertain, read the relevant dedicated view before you mutate it. When the user already named a precise correction or review target, confirm only the route-selecting detail that is still missing. After a concrete Movement, Life Force, or Workbench correction, mutation, or result-producing run, read the relevant view back when the user is trying to understand the result rather than just store it: timeline or place/settings detail for Movement, the Life Force overview for energy-planning impact, and flow detail, run detail, node result, latest node output, published output, or run history for Workbench. The canonical runtime routes stay under /api/v1/*, and the OpenClaw HTTP mirror exposes the same families under /forge/v1/movement, /forge/v1/life-force, and /forge/v1/workbench.",
             reviewShortcutRule: "When the user is reviewing or correcting an existing record, ask what practical question they want the read or correction to answer, then narrow the saved object, timeframe, or route family first. Use the correct read posture before asking write-shaped questions: shared batch search or read hints for normal entities, wiki/calendar dedicated reads for specialized CRUD, read-model routes for overviews, and Movement, Life Force, or Workbench dedicated reads for those domain surfaces. After the read, answer the practical question before asking for any save, correction, link, run, enrichment, or publish detail. Do not reopen the whole intake unless the user is actually redefining the record.",
             readModelWriteRule: "Self-observation is note-backed and should be written through observed notes with frontmatter.observedAt only when a lightweight episode observation is the right container. Do not use it as the default bucket for Psyche material: prefer trigger_report for one emotionally meaningful episode, behavior_pattern for functional analysis of a recurring loop, behavior for one repeated move, belief_entry for a core sentence, mode_guide_session or mode_profile for a central part-state, and wiki_page for durable memory such as books, articles, concepts, sources, or personal manuals. Sleep and workout sessions stay on batch CRUD by default; use the reflective review helpers only when enriching one already-known record after review.",
             psycheOpeningQuestionRule: "Prefer a concrete opening question tied to the entity: ask when the value mattered, what happened the last time the pattern appeared, what cue or body signal came first before the behavior, what the belief starts saying about self or outcome, what feels most at risk inside the mode, what the part is trying to get the user to do or stop doing, or where the shift began in the incident. Reflect briefly before the question, choose one follow-up lane at a time, say what is becoming clearer before the next deeper question, and if several Psyche entities are visible hold the adjacent ones lightly until the main container is clear.",
@@ -8440,9 +8442,14 @@ export async function buildServer(options = {}) {
     });
     app.post("/api/v1/mobile/healthkit/sync-sessions/:id/chunks", { bodyLimit: 40_000_000 }, async (request) => {
         const { id } = request.params;
+        const startedAt = performance.now();
         const rawPayloadJson = JSON.stringify((request.body ?? {}).payload ?? {});
+        const chunk = ingestMobileHealthSyncChunk(id, mobileHealthSyncChunkSchema.parse(request.body ?? {}), rawPayloadJson);
         return {
-            chunk: ingestMobileHealthSyncChunk(id, mobileHealthSyncChunkSchema.parse(request.body ?? {}), rawPayloadJson)
+            chunk: {
+                ...chunk,
+                serverProcessingMs: Math.max(0, Math.round(performance.now() - startedAt))
+            }
         };
     });
     app.post("/api/v1/mobile/healthkit/sync-sessions/:id/complete", async (request) => {

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

@@ -3347,78 +3347,6 @@ function applyWorkoutChunkImmediately(session, family, workouts) {
         }), workouts.length, createdCount, updatedCount, mergedCount, now, now, runId);
     });
 }
-function mobileSyncWorkoutRowsByExternalUid(userId, externalUids) {
-    const uniqueExternalUids = [...new Set(externalUids.filter(Boolean))];
-    const rowsByExternalUid = new Map();
-    const chunkSize = 500;
-    for (let lowerBound = 0; lowerBound < uniqueExternalUids.length; lowerBound += chunkSize) {
-        const chunk = uniqueExternalUids.slice(lowerBound, lowerBound + chunkSize);
-        if (chunk.length === 0) {
-            continue;
-        }
-        const placeholders = chunk.map(() => "?").join(", ");
-        const rows = getDatabase()
-            .prepare(`SELECT *
-         FROM health_workout_sessions
-         WHERE user_id = ?
-           AND source = 'apple_health'
-           AND external_uid IN (${placeholders})`)
-            .all(userId, ...chunk);
-        for (const row of rows) {
-            rowsByExternalUid.set(row.external_uid, row);
-        }
-    }
-    return rowsByExternalUid;
-}
-function applyWorkoutEvidenceChunkImmediately(session, payload) {
-    const timeSeries = payload.workoutTimeSeries ?? [];
-    const routes = payload.workoutRoutes ?? [];
-    if (timeSeries.length === 0 && routes.length === 0) {
-        return;
-    }
-    const pairing = mobileSyncSessionPairing(session);
-    runInTransaction(() => {
-        const rowsToRecompute = new Map();
-        const rowsByExternalUid = mobileSyncWorkoutRowsByExternalUid(pairing.user_id, [
-            ...timeSeries
-                .filter((entry) => entry.samples.length > 0)
-                .map((entry) => entry.externalUid),
-            ...routes
-                .filter((entry) => entry.routePoints.length > 0)
-                .map((entry) => entry.externalUid)
-        ]);
-        for (const entry of timeSeries) {
-            const row = rowsByExternalUid.get(entry.externalUid);
-            if (!row || entry.samples.length === 0) {
-                continue;
-            }
-            upsertWorkoutTimeSeries({
-                workoutId: row.id,
-                userId: pairing.user_id,
-                samples: entry.samples
-            });
-            rowsToRecompute.set(row.id, row);
-        }
-        for (const entry of routes) {
-            const row = rowsByExternalUid.get(entry.externalUid);
-            if (!row || entry.routePoints.length === 0) {
-                continue;
-            }
-            upsertWorkoutRoutePoints({
-                workoutId: row.id,
-                userId: pairing.user_id,
-                points: entry.routePoints
-            });
-            rowsToRecompute.set(row.id, row);
-        }
-        for (const row of rowsToRecompute.values()) {
-            recomputeAndStoreWorkoutAnalytics(row);
-        }
-        for (const dateKeyValue of new Set([...rowsToRecompute.values()].map((row) => dayKey(row.started_at)))) {
-            summarizeUserHealthDay(pairing.user_id, dateKeyValue);
-        }
-    });
-}
 function markMobileHealthSyncChunkApplied(input) {
     const now = nowIso();
     getDatabase()
@@ -3474,8 +3402,10 @@ function applyMobileHealthSyncChunkImmediately(session, family, payload) {
             return "workout_progressive_apply";
         case "workout_time_series":
         case "workout_routes":
-            applyWorkoutEvidenceChunkImmediately(session, payload);
-            return "workout_evidence_progressive_apply";
+            // Evidence chunks can be very large. Applying them here made the phone wait
+            // for route/sample upserts plus analytics recomputation before each chunk
+            // response. Store them quickly and apply once during completion instead.
+            return null;
         case "movement":
             return applyMovementChunkImmediately(session, payload)
                 ? "movement_progressive_apply"
@@ -3733,8 +3663,10 @@ function mergeMobileHealthSyncChunks(session, chunks, options = {}) {
     const workoutsByExternalUid = new Map();
     const tombstones = [];
     for (const chunk of chunks.sort((left, right) => left.sequence - right.sequence)) {
+        const keepWorkoutSummaryForDeferredEvidence = chunk.family === "workout_summaries" || chunk.family === "workout_archive";
         const skipRecords = options.skipImmediatelyApplied === true &&
-            mobileHealthSyncChunkWasImmediatelyApplied(chunk);
+            mobileHealthSyncChunkWasImmediatelyApplied(chunk) &&
+            keepWorkoutSummaryForDeferredEvidence === false;
         if (skipRecords) {
             continue;
         }
@@ -3967,7 +3899,10 @@ function listMobileSyncCompletionChunks(syncSessionId) {
         .prepare(`SELECT id, payload_json
        FROM health_mobile_sync_chunks
        WHERE sync_session_id = ?
-         AND applied_at IS NULL`)
+         AND (
+           applied_at IS NULL
+           OR family IN ('workout_summaries', 'workout_archive')
+         )`)
         .all(syncSessionId);
     if (payloadRows.length === 0) {
         return chunks;

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.3.9",
+  "version": "0.3.10",
   "activation": {
     "onStartup": true,
     "onCapabilities": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forge-openclaw-plugin",
-  "version": "0.3.9",
+  "version": "0.3.10",
   "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/SKILL.md

@@ -243,6 +243,14 @@ Entity conversation rule:
   time scope, and any ownership/placement that changes later use are already clear,
   summarize once and write, read, run, or update instead of collecting optional
   fields.
+- Treat partial answers as progress. Before another follow-up, identify what is
+  already usable: operation, entity or surface, target record or time span, working
+  wording, owner or placement, route lane, and consent. Ask only for the first missing
+  detail that changes the action: duplicate disambiguation, hierarchy parent, time
+  window, weekday, flow, run, node, correction, link, or save consent.
+- Do not ask for optional tags, priority, status, dates, color, links, or assignees
+  when accepted wording and meaningful body are enough unless that metadata changes
+  accountability, retrieval, or execution.
 - Let each question have one job. Know what you are trying to clarify before you ask it.
 - Before you ask, decide the exact missing thing you need and how that answer will help you name, place, or save the record.
 - Prefer a progression of:
@@ -271,6 +279,19 @@ Entity conversation rule:
   Movement, Life Force, or Workbench dedicated reads for those domain surfaces. After
   the read, answer the practical question before asking for any save, correction,
   link, run, enrichment, or publish detail.
+- After create, update, delete, restore, run, read, or repair actions, confirm the
+  user-facing record, action, and result in the user's language instead of reopening
+  intake. For batch creates and updates, confirm the working title or accepted wording,
+  container, and owner or placement only when those changed retrieval, accountability,
+  or execution; if optional tags, priority, status, color, links, dates, or assignees
+  were left provisional, say that plainly once. For action workflows, confirm the real
+  product action: task run started or completed, work adjustment applied, preference
+  judgment or signal submitted, questionnaire run updated or completed, calendar
+  connection synced, or self-observation note written. For Psyche saves, confirm the
+  accepted wording and whether it was saved as a first version, update, link, archive,
+  or distinct version; do not reopen origin, evidence, repair, or adjacent entity
+  mapping after the save unless that next object is already visible and materially
+  useful.
 - 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.
@@ -320,6 +341,10 @@ Psyche interview rule:
 - If the user already offers a usable belief sentence, value phrase, or mode name,
   refine from their wording first instead of replacing it with a cleaner label too
   early.
+- If the user already offers a usable belief sentence, functional loop, part voice,
+  trigger episode, value phrase, event kind, emotion signature, or flashcard message,
+  treat it as real data and ask one accuracy or consent question instead of reopening
+  origin, evidence, or repair.
 - When the conversation reveals an adjacent entity such as a linked belief, mode, value, pattern, or note, name that gently and ask whether the user wants to map it too.
 - If nuance matters, preserve it in a linked Markdown `note` instead of forcing every detail into normalized fields.
 - If the user shows imminent risk of self-harm, suicide, violence, inability to stay safe, or severe disorientation, stop normal intake and prioritize urgent human support or emergency help instead.
@@ -621,7 +646,7 @@ through `forge_create_entities` or `forge_update_entities`.
   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.
+- After a concrete Movement, Life Force, or Workbench correction, mutation, or result-producing run, read the relevant specialized view back when the user is trying to understand the result rather than only store it: timeline or place/settings detail for Movement, the Life Force overview for energy-planning impact, and flow detail, run detail, node result, latest node output, published output, or run history for Workbench.
 
 Use live work tools for `task_run`:
 `forge_log_work`, `forge_start_task_run`, `forge_heartbeat_task_run`, `forge_focus_task_run`, `forge_complete_task_run`, `forge_release_task_run`

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -101,6 +101,10 @@ Forge correctly, and gather only the structure that still matters.
   opener. Move straight to the next missing clarification.
 - After a substantive answer, briefly say what is becoming clear so the user can
   correct the direction early.
+- Treat partial answers as progress. Before asking again, mark what the user already
+  supplied: the operation, container, target record or span, working wording, route
+  lane, placement, and consent. Ask only for the first missing detail that would
+  change the save, read, run, correction, or link.
 - Once the record is clear enough to name, stop exploring broadly and ask only for the
   last missing structural detail.
 - When the record is already clear enough to save, save it instead of performing a
@@ -138,6 +142,28 @@ choice is an internal classification step, not a user-facing menu.
 - Once the lane is selected, use the exact route key internally and do not invent a
   friendlier path.
 
+## Dedicated surface verification loop
+
+Use this after a Movement, Life Force, or Workbench mutation or result-producing run.
+The dedicated route family is not finished just because a write returned `ok`.
+
+- After Movement overlays, place edits, settings changes, stay/trip repairs, or
+  deletion/invalidation work, read back the timeline, place list, settings, box
+  detail, or selection view that proves the user's practical question was answered.
+- After Life Force profile edits, weekday-template edits, or fatigue signals, read
+  the overview back when the user is making a planning decision or wants to understand
+  the practical impact of the change.
+- After Workbench flow creation/edit/deletion, saved-flow execution, one-off
+  execution, chat follow-up, or publish-related work, read back the flow detail, run
+  detail, node result, latest node output, published output, or run history that
+  matches the user's real goal.
+- Do not perform a read-back as ceremony when the user only asked for a narrow save
+  and the write response already gives enough confirmation. Use it when it changes
+  understanding, verifies a repair, or grounds the next decision.
+- In user-facing language, say what you checked: the corrected span, the weekday
+  energy picture, the flow result, the node output, or the published artifact. Keep
+  route keys and HTTP paths internal unless the user asks for implementation detail.
+
 ## Mixed-intent sequencing
 
 Use this when one user message combines several Forge jobs, such as "review this and
@@ -187,6 +213,30 @@ worked.
   write at all. Do not widen into a new taxonomy choice unless the read made the
   container genuinely ambiguous.
 
+## Write/read/run confirmation loop
+
+Use this after create, update, delete, restore, run, read, or repair actions. The
+agent should close the loop in the user's language instead of reopening intake.
+
+- Confirm the user-facing record, action, and result, not the internal route. Mention
+  the route family only if the user asked for implementation detail or the agent is
+  reporting an API-contract problem.
+- For batch creates and updates, confirm the working title or accepted wording, the
+  container, and the owner or placement only when those changed later retrieval,
+  accountability, or execution.
+- If optional tags, priority, status, color, links, dates, or assignees were left
+  provisional, say that plainly once instead of asking for all of them.
+- For action workflows, confirm the real product action: task run started or
+  completed, work adjustment applied, preference judgment or signal submitted,
+  questionnaire run updated or completed, calendar connection synced, or
+  self-observation note written.
+- For specialized Movement, Life Force, and Workbench actions, pair the confirmation
+  with the dedicated verification loop only when the read-back changes understanding,
+  proves a repair, or grounds the next decision.
+- Ask a follow-up only if it changes the next action: a correction, link, schedule,
+  run, publish, enrichment, preservation choice, or UI handoff. If the action is
+  complete and no decision-relevant next step is visible, stop cleanly.
+
 ## Review-before-write checkpoint
 
 Use this when the user asks to review, guide, inspect, compare, or understand before
@@ -269,6 +319,35 @@ but not necessarily a full Psyche formulation: `questionnaire_instrument`,
   uses questionnaire run actions; `self_observation` is note-backed; `wiki_page` uses
   the wiki routes.
 
+## Progressive disclosure after partial answers
+
+Use this when the user has already given part of the answer. The next question should
+show that you heard what is already settled.
+
+- First identify what is already usable: operation, entity or surface, target record,
+  time span, working wording, owner or placement, route lane, and consent.
+- Say the usable part back briefly, then ask only for the first missing detail that
+  would change the action: duplicate disambiguation, hierarchy parent, time
+  window, weekday, flow, run, node, correction, link, or save consent.
+- For normal batch entities, if the accepted title or distinctive wording and the
+  meaningful body are present, do not ask for tags, priority, status, color, links,
+  dates, or assignees unless that metadata changes accountability, retrieval, or
+  execution.
+- For specialized Movement, Life Force, and Workbench work, if the user's wording
+  already implies the lane, skip the route-family question and ask only for the
+  target span, place, weekday, profile field, flow, run, node, output, correction, or
+  consent that is still missing.
+- For review-first work, once the practical question and scope are clear, read before
+  asking about the possible write. Do not ask the user to design a report shape unless
+  the answer would change the read.
+- For direct Psyche saves or updates, if the user has already given a usable belief
+  sentence, functional loop, part voice, trigger episode, value phrase, event kind,
+  emotion signature, or flashcard message, ask one accuracy or consent question
+  instead of reopening origin, evidence, or repair.
+- If the remaining unknown is only decorative optional metadata, state the provisional
+  choice and act with consent. The flow should feel like progressive clarification,
+  not a restarted form.
+
 ## Conversation arc
 
 Most good Forge intake flows follow this sequence:
@@ -1934,6 +2013,9 @@ Direct action rules:
 - 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.
+- After a Movement repair, known-place edit, settings change, overlay deletion, or
+  automatic-box invalidation, verify through the relevant dedicated read when the
+  user is trying to understand whether the movement picture is now truthful.
 
 Helpful follow-up lanes:
 
@@ -2064,6 +2146,9 @@ Direct action rules:
   then read the overview back if they want to see the updated picture.
 - After a profile or weekday-template change, read the overview back when the user is
   trying to understand the practical impact of the change, not just store it silently.
+- After a fatigue signal, profile patch, or weekday-template edit, verify through the
+  Life Force overview when the next planning decision depends on the updated energy
+  picture.
 
 Ready to act when:
 
@@ -2176,6 +2261,10 @@ Direct action rules:
 - 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.
+- After Workbench execution, flow edits, chat follow-ups, or publish-related work,
+  verify through the matching dedicated read: run detail, node result, latest node
+  output, flow detail, run history, or published output. Do not leave a run or edit
+  as an abstract success message when the user asked to inspect or use the result.
 
 Ready to act when:
 

package/skills/forge-openclaw/psyche_entity_playbooks.md

@@ -276,6 +276,28 @@ of leaving it as warm reflective prose.
 - Save through shared batch entity routes only after the user accepts the working
   wording or explicitly asks to save.
 
+## Psyche progressive disclosure
+
+Use this when the user has already supplied meaningful Psyche material. The next move
+should preserve momentum instead of making them retell the whole story.
+
+- Treat an offered belief sentence, value phrase, part voice, urge sentence, trigger
+  episode, event kind, emotion signature, or functional loop as real data, not as a
+  prompt to restart intake.
+- Say what is already usable in plain language, then ask only for the missing detail
+  that changes the record: accuracy, the cue or situation, payoff or cost, protective
+  job, linked episode, whether it is a new version or an update, or save consent.
+- If the user's wording is serviceable, keep it and refine at most one phrase. Do not
+  replace it with a prettier formulation before the user feels recognized.
+- If the user asks to update a Psyche record and already gives the new wording, ask
+  what part of the old formulation it replaces or whether it should stand as a new
+  version. Do not reopen origin, evidence, or repair unless the new meaning is still
+  unclear.
+- If the working material is already accurate enough, ask one accuracy or consent
+  question instead of reopening origin, evidence, or repair.
+- If the remaining unknown is optional therapeutic metadata, save a provisional
+  version after one accuracy check and preserve nuance in a linked note when needed.
+
 ## Psyche save-readiness checkpoint
 
 Use this before asking another deepening question. Psyche work should feel careful,
@@ -307,6 +329,23 @@ save the record instead of reopening the whole story.
 - After the minimum is present, ask one accuracy question at most: "Is this true
   enough to save as a first version?" If yes, save through shared batch CRUD.
 
+## Psyche after-save close
+
+Use this after a Psyche record is created or updated. The user should feel the
+formulation was held accurately, not that a new worksheet has started.
+
+- Confirm the accepted wording, primary container, and whether it was saved as a
+  first version, update, link, archive, or distinct version.
+- Do not reopen origin, evidence, repair, or adjacent entity mapping after the save.
+  Only offer a flashcard, note, value link, task, or habit when that next object is
+  already visible and would materially help retrieval or action.
+- If nuance was preserved in a linked note or left provisional, say that briefly and
+  keep the door open for later correction without asking another broad exploration
+  question.
+- For belief, pattern, mode, trigger report, value, event type, emotion definition,
+  or flashcard saves, the clean close is one accurate sentence plus any concrete next option
+  that genuinely follows from the user's request.
+
 ## Psyche Hypothesis Map
 
 Use these shapes after at least one concrete example is clear. The hypothesis should