forge-openclaw-plugin 0.2.56 → 0.2.57

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

@@ -2763,7 +2763,7 @@ const AGENT_ONBOARDING_CONVERSATION_RULES = [
     "Use a progression of concrete example or intent, working name, purpose or meaning, placement in Forge, operational details, and linked context.",
     "Ask one to three focused questions at a time. One is usually best when the user is uncertain or emotionally loaded.",
     "One focused question is the default. Only stack a second question when both serve the same clarification job and the user is steady enough for it.",
-    "When the user wants review, comparison, or navigation around an existing record, ask what they are trying to understand first and route to the read path before reopening create or update intake.",
+    "When the user wants review, comparison, or navigation around an existing record, ask what they are trying to understand first and look up the existing record before reopening create or update intake.",
     "If the user already answered the normal opening question, do not repeat it. Move to the next missing clarification.",
     "Do not over-therapize logistical entities. For tasks, calendar events, work blocks, timeboxes, and task runs, one brief confirming sentence plus one question is usually enough.",
     "After each substantive answer, briefly say what is becoming clearer and ask only for the next thing that still changes the record shape or usefulness.",
@@ -2776,18 +2776,24 @@ const AGENT_ONBOARDING_CONVERSATION_RULES = [
     "For review requests, ask what practical question the user wants the read to answer before you ask for more scope.",
     "The opening question should help the user understand what they are actually trying to save, decide, review, or change, not make them perform the schema out loud.",
     "If the user already named the exact correction in usable language, confirm only the missing scope, timing, or route-selecting detail that still matters, then act.",
-    "Once a specialized-surface lane is clear, speak in route-relevant nouns such as timeline, overlay, weekday template, published output, run detail, or node result instead of generic record language.",
+    "Keep API and architecture nouns out of user-facing questions unless the user asks about implementation. Do not ask the user about surfaces, route families, CRUD, payloads, mutation paths, or read paths; ask about the human object such as a wiki page, note, trigger report, behavior pattern, belief, mode, movement timeline, energy model, weekday pattern, flow, run, or node result.",
+    "Self-observation is not the default container for Psyche material. Use it only for a lightweight observed event note; prefer trigger_report for one emotionally meaningful episode, behavior_pattern for a recurring loop and functional analysis, behavior for one repeated move, belief_entry for a core sentence, mode_guide_session or mode_profile for an active part-state, and wiki_page for durable memory.",
+    "Do not bury schema work in self-observation. If the user is describing a schema theme, preserve it through a belief_entry, behavior_pattern, mode_profile, mode_guide_session, trigger_report, or wiki_page depending on whether it appears as a rule, loop, part-state, live exploration, one episode, or durable explanation.",
+    "Once the Movement, Life Force, or Workbench job is clear, speak in product nouns such as timeline, overlay, weekday template, published output, run detail, or node result instead of generic record language.",
     "If the next answer would not change the route, wording, timing, or write payload in a meaningful way, stop asking and act.",
     "Before saving, briefly summarize the working formulation in the user's own language when that would reduce ambiguity.",
     "Once the record is clear enough to name, stop exploring broadly and ask only for the last structural detail that still matters.",
     "If the record is already clear enough to save, save it instead of performing a ceremonial extra question.",
     "If the user accepts the wording or record shape, move to the write instead of reopening the intake.",
     "When updating an entity, start with what is changing, what should stay true, and what prompted the update now.",
-    "For action-heavy flows such as work adjustments, preference judgments, preference signals, and specialized Movement, Life Force, or Workbench work, first ask what the user is trying to understand, change, add, update, link, or run, then choose the dedicated action or surface route instead of forcing the request into generic CRUD.",
-    "For specialized surfaces, ask what would make the answer or change useful before you ask route-shaped details such as provider, weekday, flow id, run id, or trip id.",
+    "For action-heavy flows such as work adjustments, preference judgments, preference signals, and Movement, Life Force, or Workbench work, first ask what the user is trying to understand, change, add, update, link, or run, then choose the dedicated action or domain route instead of forcing the request into generic CRUD.",
+    "For Movement, Life Force, and Workbench, ask what would make the answer or change useful before you ask route-shaped details such as provider, weekday, flow id, run id, or trip id.",
     "When the user 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.",
     "Once the route family is clear, say it plainly enough that another agent could follow the same path without guessing.",
     "For Movement specifically, treat missing-data corrections as user-defined overlay boxes unless the user is editing an already-recorded stay or trip. When the user already gave a clear instruction like 'that missing block was home', act after only the last ambiguity is resolved.",
+    "For action workflows such as task_run, work_adjustment, questionnaire_run, preference_judgment, preference_signal, and self_observation, keep the question focused on the missing action payload and do not downgrade the request into generic batch CRUD.",
+    "For normal stored Preferences and questionnaire records, use batch CRUD by default; switch to dedicated action routes only for judgments, signals, run answers, clone/draft/publish lifecycle, or visual comparison gameplay.",
+    "When the user wants to remember a book, article, paper, source, concept, person, conversation, project reference, recurring explanation, or personal manual, consider wiki_page before note or self_observation.",
     "For meaning-bearing updates, especially in Psyche, briefly say what feels newly true before you ask for the one structural detail that still changes the save."
 ];
 const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
@@ -2876,12 +2882,13 @@ const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
     },
     {
         focus: "wiki_page",
-        openingQuestion: "What should this page become the main reference for?",
-        coachingGoal: "Create a durable reference page with a clear scope instead of dumping raw notes into the wiki.",
+        openingQuestion: "What do you want this wiki page to help you remember or reuse later?",
+        coachingGoal: "Create durable memory for books, articles, sources, concepts, people, conversations, project references, reusable instructions, or personal manuals.",
         askSequence: [
-            "Ask what topic this page should become the canonical place for.",
-            "Ask whether it is a durable wiki page or supporting evidence.",
-            "Ask what future lookup, decision, or collaboration this page should support.",
+            "Ask what this page should help the user remember, understand, or reuse later.",
+            "Ask whether the material is a book, article, source, concept, person, conversation, project reference, or personal manual.",
+            "Ask what the page should contain now: summary, key claims, quotes to verify, personal interpretation, action implications, or links.",
+            "Ask whether it should be the durable wiki page itself or supporting evidence linked to another page.",
             "Ask about linked entities, aliases, or tags only if they will make the page more navigable later."
         ]
     },
@@ -2964,17 +2971,17 @@ const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
     },
     {
         focus: "self_observation",
-        openingQuestion: "What did you notice most clearly in that moment?",
-        coachingGoal: "Capture one observation clearly enough that it can support later reflection without pretending it is already a full interpretation.",
+        openingQuestion: "What happened in the situation, and what did you feel, think, or do next?",
+        coachingGoal: "Capture one observed episode as situation, cue, emotion/body, thought/meaning, behavior/urge, and consequence, then choose the stronger Psyche or wiki container when one is visible.",
         askSequence: [
-            "Ask what was observed.",
-            "Reflect the moment without pretending it is already a finished interpretation.",
-            "Ask what felt most important to name before it gets smoothed over or forgotten.",
-            "Ask for the smallest concrete slice if the observation still feels vague or global.",
-            "Ask when it happened or became noticeable unless timing is already clear.",
-            "Remember that self-observation is note-backed and should be written through an observed note with frontmatter.observedAt.",
-            "Ask what it may connect to: pattern, belief, value, mode, task, project, or note.",
-            "Ask for tags or extra context only if that will help later review."
+            "Ask what happened in the situation.",
+            "Ask what cue, trigger, or body shift made the episode noticeable.",
+            "Ask what emotion, body signal, thought, or meaning showed up.",
+            "Ask what behavior showed up: what the user did, wanted to do, avoided, or repeated next.",
+            "Ask what the immediate consequence was, including short-term relief or cost if it is visible.",
+            "Decide whether this should stay a lightweight self-observation or become a trigger_report, behavior_pattern, behavior, belief_entry, mode_profile, mode_guide_session, event_type, emotion_definition, or wiki page.",
+            "Remember that self-observation is note-backed and should be written through an observed note with frontmatter.observedAt only when a lightweight observation is the right container.",
+            "Do not promote self-observation over functional analysis: use behavior_pattern for recurring loops, trigger_report for one emotionally meaningful episode, mode_guide_session or mode_profile for a central part-state, belief_entry for a central sentence, and wiki_page for durable memory."
         ]
     },
     {
@@ -3044,6 +3051,7 @@ const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
             "Ask what preference or taste question this item belongs to.",
             "Ask what domain or context it should live in.",
             "Ask whether the user is saving a comparison candidate or a direct signal such as favorite, veto, or compare-later.",
+            "If the user is saving or editing a candidate, keep it on batch CRUD; if they are recording a comparison outcome or direct mark, switch to the preference judgment or signal route.",
             "Ask what makes the item distinct enough to compare usefully only if it is still a comparison candidate."
         ]
     },
@@ -3055,6 +3063,7 @@ const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
             "Ask what comparison the user is actually trying to settle.",
             "Ask which context or domain this judgment belongs to.",
             "Ask whether the result is left, right, tie, or skip.",
+            "Use the dedicated preference judgment action route instead of batch CRUD once the pair and outcome are clear.",
             "Ask for reason tags or strength only if they will improve later interpretation."
         ]
     },
@@ -3066,6 +3075,7 @@ const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
             "Ask what item the user wants to mark.",
             "Ask what signal they want to give it.",
             "Ask what domain or context this belongs to if that is still unclear.",
+            "Use the dedicated preference signal action route instead of batch CRUD once the item and signal are clear.",
             "Ask about strength only if the user is expressing a gradient rather than a simple mark."
         ]
     },
@@ -3079,6 +3089,7 @@ const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
             "Ask what kind of honest moment or decision it should help someone answer before getting into item wording.",
             "Reflect the practical use case back in plain language.",
             "Ask what would make the instrument distinct instead of redundant if a near-duplicate risk is visible.",
+            "Use batch CRUD for ordinary questionnaire instrument create or update work; use clone, draft, and publish actions only for version lifecycle.",
             "Move to draft creation once the purpose is clear."
         ]
     },
@@ -3090,6 +3101,7 @@ const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
             "Ask what the user wants from the run right now: start, continue, review, or finish.",
             "Ask which questionnaire or existing run this is about.",
             "If the user wants to continue or finish, ask what feels most stuck, unfinished, or important before asking for more content.",
+            "Use the dedicated questionnaire run start, read, update, and complete routes instead of generic entity CRUD.",
             "If answering is still in progress, ask only for the next answer or note that matters."
         ]
     },
@@ -3098,6 +3110,7 @@ const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
         openingQuestion: "What are you trying to understand, correct, or preserve about where you stayed and traveled?",
         coachingGoal: "Clarify whether the user wants a time-in-place query, travel-history review, a missing-gap overlay, one stay or trip change, one place summary, or a link before choosing the dedicated movement route.",
         askSequence: [
+            "Ask what they are trying to make clearer, repair, or preserve about where they were before you narrow to the exact movement lane.",
             "Ask whether the user is trying to query behavior, add something manually, update an existing movement item, or link movement to another Forge entity.",
             "Ask whether the focus is a stay, a trip, a place, a timeline window, or a selected span.",
             "Ask for the time window, place, or movement item that makes the question concrete.",
@@ -3114,9 +3127,10 @@ const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
     },
     {
         focus: "life_force",
-        openingQuestion: "Do you want to understand the current energy picture, change how Forge models it, or log how you feel right now?",
+        openingQuestion: "What feels most off, important, or worth understanding in your energy picture right now?",
         coachingGoal: "Clarify whether the job is overview, profile change, weekday-template editing, or a real-time fatigue signal before choosing the dedicated life-force route.",
         askSequence: [
+            "Ask what feels off, important, or worth tracking in their energy picture before you reduce it to one life-force lane.",
             "Ask whether the job is overview, profile change, weekday-template change, or fatigue signaling.",
             "Ask what part of the current energy picture feels most important or inaccurate.",
             "Ask what should stay true if they are changing profile or template assumptions.",
@@ -3133,10 +3147,10 @@ const AGENT_ONBOARDING_ENTITY_CONVERSATION_PLAYBOOKS = [
         openingQuestion: "What are you trying to inspect, change, run, or publish through Workbench?",
         coachingGoal: "Clarify whether the user wants flow discovery, editing, execution, run history, published outputs, or node-level inspection before using the dedicated workbench route family.",
         askSequence: [
+            "Ask what they are trying to learn, repair, publish, or run through Workbench before you narrow to flow discovery, editing, execution, or results.",
             "Ask whether the job is flow discovery, one flow edit, execution, run history, published output, node-level inspection, or latest-node-output lookup.",
             "Ask which flow, slug, run, or node the request is about.",
             "Ask whether they need the stable flow contract, one run result, one published output, one node result, or the latest node output.",
-            "Ask what the user is trying to learn, repair, or publish through that flow.",
             "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.",
             "If the user wants a stable public input contract or published output, prefer those dedicated reads instead of detouring through run history first.",
             "If the user is still shaping a payload or edit, prefer flow detail or box catalog reads before asking for structured inputs.",
@@ -3447,6 +3461,72 @@ const AGENT_ONBOARDING_PSYCHE_PLAYBOOKS = [
             "Use emotionDefinitionId only when a known emotion definition fits; otherwise keep the raw label.",
             "If the user becomes overwhelmed, slow down, summarize, and return to one segment of the chain at a time instead of pushing for the full report in one turn."
         ]
+    },
+    {
+        focus: "event_type",
+        useWhen: "Use for a repeated emotionally meaningful kind of moment that should make future trigger reports consistent without erasing the lived stake.",
+        coachingGoal: "Help the user name the repeated episode type through a recent example, emotional stake, and boundary from nearby incidents before saving the taxonomy label.",
+        askSequence: [
+            "Ask what kind of moment keeps recurring and why it matters to name it consistently.",
+            "Reflect the repeated emotional or relational stake in plain language before wording the category.",
+            "Ask for one recent example if the boundary is still abstract.",
+            "Clarify what belongs inside this event type and what should stay outside it.",
+            "Offer one concise candidate label once the repeated moment is clear.",
+            "Link it to trigger reports, beliefs, patterns, modes, or emotion definitions only after the category itself feels accurate."
+        ],
+        requiredForCreate: ["label"],
+        highValueOptionalFields: [
+            "description",
+            "linkedReportIds",
+            "linkedPatternIds",
+            "linkedBeliefIds",
+            "linkedModeIds"
+        ],
+        exampleQuestions: [
+            "What kind of moment keeps happening that you want future reports to name the same way each time?",
+            "What feels threatened, exposed, relieved, or important in those moments?",
+            "What would make a future incident count as this type instead of a nearby one?",
+            "Which reports or patterns should this help organize later?"
+        ],
+        notes: [
+            "event_type is a Psyche taxonomy record, but it still needs active listening because it names emotionally meaningful episodes.",
+            "Do not open with pure label wording unless the lived category and boundary are already clear.",
+            "Offer a candidate label after the repeated moment is understood, and keep the user's wording when it already fits."
+        ]
+    },
+    {
+        focus: "emotion_definition",
+        useWhen: "Use for a reusable feeling label that should help trigger reports and Psyche records name an emotion consistently in the user's own language.",
+        coachingGoal: "Define the feeling through its lived signature, boundary from nearby feelings, and likely signal or protective function before saving the label.",
+        askSequence: [
+            "Ask when this feeling was present recently and what made it recognizable.",
+            "Reflect the felt signature before asking for a category or label polish.",
+            "Ask what distinguishes it from nearby feelings if the boundary matters.",
+            "Ask what the feeling tends to signal, protect, or ask for.",
+            "Offer one concise definition in the user's language and invite correction.",
+            "Link it to trigger reports, modes, beliefs, or patterns only after the definition feels steady."
+        ],
+        requiredForCreate: ["label"],
+        highValueOptionalFields: [
+            "description",
+            "family",
+            "bodySignals",
+            "linkedReportIds",
+            "linkedModeIds",
+            "linkedBeliefIds",
+            "linkedPatternIds"
+        ],
+        exampleQuestions: [
+            "When this feeling is present, what tells you it is this feeling and not a nearby one?",
+            "What body signal, urge, image, thought, or relational meaning identifies it?",
+            "What does this feeling usually warn about, long for, protect, or demand?",
+            "Which reports or patterns should use this label later?"
+        ],
+        notes: [
+            "emotion_definition is a Psyche taxonomy record, not a generic dictionary entry.",
+            "Start from the lived feeling before asking for category or browsing fields.",
+            "If the user already gives a good label, reflect the felt signature and ask only for the one boundary or definition detail that still matters."
+        ]
     }
 ];
 const AGENT_ONBOARDING_TOOL_INPUT_CATALOG = [
@@ -4120,7 +4200,7 @@ function buildAgentOnboardingPayload(request) {
                 task_run: {
                     readModel: "/api/v1/operator/context",
                     actions: {
-                        start: "/api/v1/tasks/:taskId/runs",
+                        start: "/api/v1/tasks/:id/runs",
                         heartbeat: "/api/v1/task-runs/:id/heartbeat",
                         focus: "/api/v1/task-runs/:id/focus",
                         complete: "/api/v1/task-runs/:id/complete",
@@ -4153,6 +4233,18 @@ function buildAgentOnboardingPayload(request) {
                         overrideScore: "/api/v1/preferences/items/:id/score"
                     }
                 },
+                preference_judgment: {
+                    readModel: "/api/v1/preferences/workspace",
+                    action: "/api/v1/preferences/judgments",
+                    tool: "forge_submit_preferences_judgment",
+                    writeModel: "Submit one pairwise preference judgment through the dedicated Preferences action route, not batch CRUD."
+                },
+                preference_signal: {
+                    readModel: "/api/v1/preferences/workspace",
+                    action: "/api/v1/preferences/signals",
+                    tool: "forge_submit_preferences_signal",
+                    writeModel: "Submit one direct preference signal through the dedicated Preferences action route, not batch CRUD."
+                },
                 questionnaires: {
                     list: "/api/v1/psyche/questionnaires",
                     detail: "/api/v1/psyche/questionnaires/:id",
@@ -4165,10 +4257,15 @@ function buildAgentOnboardingPayload(request) {
                 selfObservation: {
                     read: "/api/v1/psyche/self-observation/calendar",
                     writeModel: "Create or update an observed note with frontmatter.observedAt. Manual reflections usually carry the Self-observation tag, while movement sync can also publish rolling observed notes tagged movement."
+                },
+                self_observation: {
+                    read: "/api/v1/psyche/self-observation/calendar",
+                    writeModel: "Read the self-observation calendar, then create or update an observed note with frontmatter.observedAt; do not invent a standalone self_observation CRUD route."
                 }
             },
             specializedDomainSurfaces: {
                 movement: {
+                    classification: "specialized_domain_surface",
                     summary: "Dedicated movement workspace API. Use these routes for stays, trips, time-in-place questions, visited places, trip detail, selection aggregates, user-defined overlays, and repair actions on already-recorded movement data.",
                     routeSelectionQuestions: [
                         "Is the user asking for a day, month, all-time, timeline, place, trip detail, or selected-span answer?",
@@ -4211,6 +4308,7 @@ function buildAgentOnboardingPayload(request) {
                     ]
                 },
                 lifeForce: {
+                    classification: "specialized_domain_surface",
                     summary: "Dedicated life-force API. Use it to read the current energy budget, drains, recommendations, and warnings, then patch only the parts that are meant to be user-controlled.",
                     routeSelectionQuestions: [
                         "Is the user trying to understand the overview, change durable profile assumptions, change a weekday curve, or log a right-now fatigue signal?",
@@ -4235,6 +4333,7 @@ function buildAgentOnboardingPayload(request) {
                     ]
                 },
                 workbench: {
+                    classification: "specialized_domain_surface",
                     summary: "Dedicated graph-flow API. Use it for flow catalog reads, flow CRUD, execution, run history, published outputs, node results, and latest successful node outputs.",
                     routeSelectionQuestions: [
                         "Is the job flow discovery, flow editing, execution, published output, run detail, node result, latest node output, or flow chat follow-up?",
@@ -4484,9 +4583,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. 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 lane first, then name the dedicated route family in plain language and do not guess at a generic CRUD path. Use specializedDomainSurfaces.routeSelectionQuestions when they are present so the next follow-up stays route-selective instead of generic. Once the lane is clear, talk in route-relevant nouns such as timeline, overlay, weekday template, published output, run detail, or node result rather than generic record language. If the truth of the current state is still uncertain, read the relevant specialized 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 specialized-surface correction, read the relevant specialized 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.",
+            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. 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.",
             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. 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. Sleep and workout sessions stay on batch CRUD by default; use the reflective review helpers only when enriching one already-known record after review.",
+            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.",
             duplicateCheckRoute: "/api/v1/entities/search",
             uiSuggestionRule: "offer_visual_ui_when_review_or_editing_would_be_easier",

package/dist/server/server/src/openapi.js

@@ -3193,7 +3193,32 @@ export function buildOpenApiDocument() {
                         type: "object",
                         additionalProperties: {
                             type: "object",
-                            additionalProperties: true
+                            additionalProperties: false,
+                            required: [
+                                "classification",
+                                "summary",
+                                "readRoutes",
+                                "writeRoutes",
+                                "routeSelectionQuestions",
+                                "notes"
+                            ],
+                            properties: {
+                                classification: {
+                                    type: "string",
+                                    enum: ["specialized_domain_surface"]
+                                },
+                                summary: { type: "string" },
+                                readRoutes: {
+                                    type: "object",
+                                    additionalProperties: { type: "string" }
+                                },
+                                writeRoutes: {
+                                    type: "object",
+                                    additionalProperties: { type: "string" }
+                                },
+                                routeSelectionQuestions: arrayOf({ type: "string" }),
+                                notes: arrayOf({ type: "string" })
+                            }
                         }
                     },
                     readModelOnlySurfaces: {

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forge-openclaw-plugin",
-  "version": "0.2.56",
+  "version": "0.2.57",
   "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

@@ -1,6 +1,6 @@
 ---
 name: forge-openclaw-plugin
-description: use when the user wants to save, search, update, review, start, stop, reward, explain, compare, or run Forge records, or when the conversation is clearly about a Forge entity such as a goal, project, strategy, task, habit, note, calendar_event, work_block_template, task_timebox, task_run, insight, preference item, preference context, preference catalog, questionnaire instrument, questionnaire run, self observation, psyche_value, behavior_pattern, behavior, belief_entry, mode_profile, mode_guide_session, trigger_report, event_type, emotion_definition, sleep_session, or workout_session. identify the exact Forge object, keep the main conversation natural, guide psyche intake with active listening before storing it, and for psyche issues that need understanding first usually begin with one exploratory question before any formulation or save suggestion.
+description: use when the user wants to save, search, update, review, start, stop, reward, explain, compare, or run Forge records, or when the conversation is clearly about a Forge entity or domain surface such as a goal, project, strategy, task, habit, note, wiki_page, calendar_event, calendar_connection, work_block_template, task_timebox, task_run, work_adjustment, insight, preference item, preference context, preference catalog, preference judgment, preference signal, questionnaire instrument, questionnaire run, self observation, movement, life_force, workbench, psyche_value, behavior_pattern, behavior, belief_entry, mode_profile, mode_guide_session, trigger_report, event_type, emotion_definition, sleep_session, or workout_session. identify the exact Forge object or specialized surface, keep the main conversation natural, guide psyche intake with active listening before storing it, and for psyche issues that need understanding first usually begin with one exploratory question before any formulation or save suggestion.
 ---
 
 Forge is the user's structured system for planning work, doing work, reflecting on patterns, and keeping a truthful record of what is happening. Use it when the user is clearly working inside that system, or when they are describing something that naturally belongs there and would benefit from being stored, updated, reviewed, or acted on in Forge. Keep the conversation natural first. Do not turn every message into intake. When a real Forge entity is clearly present, name the exact entity type plainly, help with the substance of the conversation, and then offer Forge once, lightly, if storing it would genuinely help.
@@ -59,10 +59,32 @@ PM surface rule:
   human/bot ownership filters.
 - Guided modal flows handle create, edit, move, link, and closeout actions.
 
-Forge has four major surfaces. The planning side covers goals, projects, strategies, tasks, habits, notes, calendar events, recurring work blocks, task timeboxes, live work sessions, and agent-authored insights. The Health side covers sleep sessions, sports and workout sessions, companion pairing, and habit-generated workout records that should still stay linked to the broader Forge graph. The Preferences side covers contextual taste modeling, pairwise comparisons, direct signals, editable concept libraries, and preference items that can come from Forge entities or seeded concept domains such as food, activities, places, countries, fashion, people, media, and tools. The Psyche side covers values, patterns, behaviors, beliefs, modes, guided mode sessions, trigger reports, event types, and reusable emotion definitions. Forge also has a SQLite-backed Wiki memory layer with explicit spaces, Markdown content in database rows, backlinks, optional embeddings, and structured links back to Forge entities. Forge is also multi-user: every entity can belong to a typed `human` or `bot` user through `userId`, and read routes can scope to one or many users with `userId` or repeated `userIds`. The current access posture is configurable through a directional user graph, but the live default is still permissive: Forge can list users directly, every relationship edge starts open, and a user can read or affect another user's linked records when the route explicitly asks for them. Use `forge_get_user_directory` when owner identity or cross-user access matters. Strategies can also be locked into a contract with `isLocked`; once locked, do not mutate the graph or target structure unless the user explicitly wants the strategy unlocked first. The model should use the real entity names, not vague substitutes. Say `project`, not “initiative”. Say `behavior_pattern`, not “theme”. Say `trigger_report`, not “incident note”.
+Forge has four major stored-entity surfaces and three specialized domain surfaces. The planning side covers goals, projects, strategies, tasks, habits, notes, calendar events, recurring work blocks, task timeboxes, live work sessions, and agent-authored insights. The Health side covers sleep sessions, sports and workout sessions, companion pairing, and habit-generated workout records that should still stay linked to the broader Forge graph. The Preferences side covers contextual taste modeling, pairwise comparisons, direct signals, editable concept libraries, and preference items that can come from Forge entities or seeded concept domains such as food, activities, places, countries, fashion, people, media, and tools. The Psyche side covers values, patterns, behaviors, beliefs, modes, guided mode sessions, trigger reports, event types, and reusable emotion definitions. The specialized domain surfaces are Movement, Life Force, and Workbench; agents must use their dedicated route families instead of forcing them through batch CRUD. Forge also has a SQLite-backed Wiki memory layer with explicit spaces, Markdown content in database rows, backlinks, optional embeddings, and structured links back to Forge entities. Forge is also multi-user: every entity can belong to a typed `human` or `bot` user through `userId`, and read routes can scope to one or many users with `userId` or repeated `userIds`. The current access posture is configurable through a directional user graph, but the live default is still permissive: Forge can list users directly, every relationship edge starts open, and a user can read or affect another user's linked records when the route explicitly asks for them. Use `forge_get_user_directory` when owner identity or cross-user access matters. Strategies can also be locked into a contract with `isLocked`; once locked, do not mutate the graph or target structure unless the user explicitly wants the strategy unlocked first. The model should use the real entity names, not vague substitutes. Say `project`, not “initiative”. Say `behavior_pattern`, not “theme”. Say `trigger_report`, not “incident note”.
 Habits are a first-class recurring entity in the planning side.
 NEGATIVE HABIT CHECK-IN RULE: for a `negative` habit, the correct aligned/resisted outcome is `missed`. `missed` means the bad habit was resisted, the user stayed aligned, and the habit should award its XP bonus.
 
+## Entity Route Posture
+
+Before asking for lower-level details, decide whether the user's request is normal
+stored-entity CRUD, an action workflow, specialized CRUD, or a specialized domain
+surface. Name the path plainly enough that another agent could follow it without
+guessing.
+
+- Batch CRUD is the default for normal stored entities, including `goal`, `project`,
+  `strategy`, `task`, `habit`, `tag`, `note`, `insight`, `calendar_event`,
+  `work_block_template`, `task_timebox`, all main Psyche records, basic Preferences
+  CRUD records, `questionnaire_instrument`, `sleep_session`, and `workout_session`.
+- `wiki_page` and `calendar_connection` are specialized CRUD surfaces. Use the wiki
+  tools for wiki pages and the calendar connection tools for provider setup and sync.
+- `task_run`, `work_adjustment`, `questionnaire_run`, `preference_judgment`,
+  `preference_signal`, and `self_observation` are action workflows. Use their
+  dedicated tools or note-backed write model instead of generic entity create/update
+  when the action route is the real product behavior.
+- Movement, Life Force, and Workbench are specialized domain surfaces. Read
+  `forge_get_agent_onboarding.entityRouteModel.specializedDomainSurfaces` and use
+  the dedicated route families for timeline/overlay repair, energy templates/signals,
+  and flow execution/results.
+
 Preferences rule:
 
 - When the user wants to understand or refine taste, ranking, recommendation fit, or “what Forge thinks I like”, treat that as the Preferences surface rather than a normal planning intake.
@@ -74,6 +96,11 @@ Preferences rule:
 Wiki rule:
 
 - Treat the Wiki as the canonical long-form memory surface, not as a loose note dump.
+- Use a wiki page whenever the user wants to remember or reuse durable knowledge:
+  a book, article, paper, source, concept, person, conversation, project reference,
+  recurring explanation, or personal manual.
+- Prefer `wiki_page` over `note` when the user is asking for durable memory,
+  synthesis, reference, or something they will want to find again by topic.
 - Use the wiki tools when the user wants SQLite-backed reference pages, backlink-aware recall, ingest from a URL or local file, or wiki maintenance work such as unresolved-link cleanup.
 - `forge_ingest_wiki_source` now queues the ingest as background work; use the Forge UI handoff when the user wants to review or keep only selected wiki/entity candidates after the ingest finishes.
 - Keep evidence notes and wiki pages conceptually distinct: evidence notes are linked operating records, while wiki pages are curated long-form memory.
@@ -118,23 +145,24 @@ Entity conversation rule:
 - 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.
+  record, ask what they are trying to understand first and look up the existing record
+  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.
 
 Forge data location rule:
 
-- by default, Forge stores data under the active runtime root at `forge.sqlite`
-- on a normal OpenClaw install, this usually means `~/.openclaw/extensions/forge-openclaw-plugin/forge.sqlite`
-- on a linked repo-local install, this usually means `<repo>/openclaw-plugin/forge.sqlite`
+- by default, current Forge plugins converge on the shared local Forge home at `~/.forge/forge.sqlite`
+- the exact storage root is the active runtime `dataRoot`; when `dataRoot` is set in plugin config, Forge stores `forge.sqlite` directly inside that folder
+- on repo-local development installs, keep using the configured shared `dataRoot` unless the user explicitly asks to move data
 - if the user wants the data somewhere else for persistence, backup, or manual control, tell them to set `plugins.entries["forge-openclaw-plugin"].config.dataRoot` and restart the OpenClaw gateway
 - if the user asks where the data is stored or how to move it, explain the current default plainly and show the exact config field
 
 Psyche interview rule:
 
-- For `psyche_value`, `behavior_pattern`, `behavior`, `belief_entry`, `mode_profile`, `mode_guide_session`, and `trigger_report`, do not jump straight to raw field collection.
+- For `psyche_value`, `behavior_pattern`, `behavior`, `belief_entry`, `mode_profile`, `mode_guide_session`, `trigger_report`, `event_type`, and `emotion_definition`, do not jump straight to raw field collection.
+- Treat `event_type` and `emotion_definition` as psychologically meaningful Psyche records, not cold taxonomy labels; start from the repeated lived moment or felt signature before wording the reusable label.
 - First use the active-listening playbooks in [`psyche_entity_playbooks.md`](./psyche_entity_playbooks.md).
 - Ask permission before going deeper, ask one or two focused questions at a time, reflect back what you heard, and summarize before moving on.
 - Start from a recent concrete example before naming an abstract pattern, belief, or mode.
@@ -156,6 +184,26 @@ Psyche interview rule:
 - 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.
 
+Self-observation rule:
+
+- Do not use `self_observation` as the default bucket for Psyche material.
+- A self-observation is a lightweight observed episode, written as a note-backed
+  calendar observation with `frontmatter.observedAt`.
+- When the user describes an episode, help map the chain:
+  situation -> cue -> emotion/body -> thought/meaning -> behavior/urge ->
+  consequence.
+- If the chain is one emotionally meaningful episode, prefer `trigger_report`.
+- If it is a recurring loop, prefer `behavior_pattern` and do a functional analysis.
+- If the core is one repeated action, prefer `behavior`.
+- If the core is a sentence the user believes, prefer `belief_entry`.
+- If a part-state, protector, critic, child state, or healthy-adult stance is active,
+  prefer `mode_guide_session` or `mode_profile`.
+- If a schema theme is visible, do not bury it in self-observation: preserve it as
+  the belief, recurring pattern, active mode, guided mode session, trigger report, or
+  wiki explanation that best matches the material.
+- If the user wants durable memory about a book, article, concept, source, or personal
+  manual, prefer `wiki_page`.
+
 Use these exact entity meanings when deciding what the user is describing.
 
 `goal` is a meaningful long-horizon direction or outcome. Use it for “be a great father”, “create meaningfully”, or “build a beautiful family”, not for one-off action items.
@@ -364,7 +412,7 @@ 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?".
 - In the live onboarding catalog, Movement, Life Force, and Workbench should appear as `specialized_domain_surface`. If the classification and route family disagree, trust the specialized route family and fix the contract mismatch instead of inventing a batch CRUD path.
 - 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:
+- For movement review, choose the route that matches the user's question:
   `/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`.
@@ -383,7 +431,9 @@ Use the dedicated domain routes for specialized surfaces that are not simple bat
   same specialized families are exposed under `/forge/v1/movement/*`,
   `/forge/v1/life-force/*`, and `/forge/v1/workbench/*`.
 - Workbench lane hints:
-  use `/api/v1/workbench/flows` for flow catalog and CRUD,
+  use `GET /api/v1/workbench/flows` for flow catalog,
+  `POST /api/v1/workbench/flows` for flow creation,
+  `PATCH /api/v1/workbench/flows/:id` and `DELETE /api/v1/workbench/flows/:id` for saved-flow edits or deletion,
   `/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.
@@ -568,37 +618,55 @@ When the user asks which Forge tools are available, list exactly these tools:
 `forge_get_operator_context`
 `forge_get_agent_onboarding`
 `forge_get_user_directory`
+`forge_get_ui_entrypoint`
 `forge_get_psyche_overview`
-`forge_get_sleep_overview`
-`forge_get_sports_overview`
 `forge_get_xp_metrics`
 `forge_get_weekly_review`
-`forge_get_current_work`
-`forge_get_ui_entrypoint`
 `forge_get_wiki_settings`
 `forge_list_wiki_pages`
 `forge_get_wiki_page`
+`forge_get_wiki_health`
 `forge_search_wiki`
 `forge_upsert_wiki_page`
-`forge_get_wiki_health`
 `forge_sync_wiki_vault`
 `forge_reindex_wiki_embeddings`
 `forge_ingest_wiki_source`
+`forge_get_current_work`
+`forge_get_sleep_overview`
+`forge_get_sports_overview`
+`forge_update_sleep_session`
+`forge_update_workout_session`
+`forge_get_preferences_workspace`
+`forge_start_preferences_game`
+`forge_merge_preferences_contexts`
+`forge_enqueue_preferences_item_from_entity`
+`forge_submit_preferences_judgment`
+`forge_submit_preferences_signal`
+`forge_update_preferences_score`
+`forge_list_questionnaires`
+`forge_get_questionnaire`
+`forge_clone_questionnaire`
+`forge_ensure_questionnaire_draft`
+`forge_publish_questionnaire_draft`
+`forge_start_questionnaire_run`
+`forge_get_questionnaire_run`
+`forge_update_questionnaire_run`
+`forge_complete_questionnaire_run`
+`forge_get_self_observation_calendar`
 `forge_search_entities`
 `forge_create_entities`
 `forge_update_entities`
 `forge_delete_entities`
 `forge_restore_entities`
 `forge_grant_reward_bonus`
-`forge_update_sleep_session`
-`forge_update_workout_session`
+`forge_adjust_work_minutes`
+`forge_post_insight`
 `forge_log_work`
 `forge_start_task_run`
 `forge_heartbeat_task_run`
 `forge_focus_task_run`
 `forge_complete_task_run`
 `forge_release_task_run`
-`forge_post_insight`
 `forge_get_calendar_overview`
 `forge_connect_calendar_provider`
 `forge_sync_calendar_connection`

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -47,16 +47,16 @@ Forge correctly, and gather only the structure that still matters.
   task runs, use a fast path:
   one brief confirming sentence -> one operational question.
 - For action-heavy flows such as work adjustments, preference judgments, preference
-  signals, and specialized surface work in Movement, Life Force, or Workbench, first
+  signals, and Movement, Life Force, or Workbench work, first
   ask what the user is trying to understand, change, add, update, link, or run, then
-  route to the dedicated action or surface path instead of pretending it is normal
+  route to the dedicated action or domain path instead of pretending it is normal
   CRUD.
-- For specialized surfaces, ask what would make the answer or change useful before you
+- For specialized domain areas, ask what would make the answer or change useful before you
   ask route-shaped details such as provider, weekday, flow id, run id, or trip id.
-- For specialized surfaces, start from the user's real job in plain language, then
+- For specialized domain areas, 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
+- For specialized domain areas, 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
@@ -91,6 +91,46 @@ Forge correctly, and gather only the structure that still matters.
 - When the record is already clear enough to save, save it instead of performing a
   ceremonial extra question.
 
+## Plain-language rule
+
+Keep API and architecture nouns inside your own reasoning. Do not ask the user about
+"surfaces", "route families", "CRUD", "payloads", "mutation paths", or "read paths".
+With the user, say the human thing:
+
+- "Movement timeline", "place", "trip", "missing block", or "time window"
+- "Energy model", "weekday pattern", or "fatigue signal"
+- "Workbench flow", "run", "published output", or "node result"
+- "Wiki page", "note", "trigger report", "behavior pattern", "belief", or "mode"
+
+The API path still matters, but it should not leak into the question unless the user
+is explicitly asking about implementation.
+
+## Psyche and memory routing
+
+Self-observation is not the default container for psychological material. Use it only
+when the user wants a lightweight observed event note or a quick calendar entry.
+
+When the user describes a psychological episode or repeated difficulty, actively route
+to the stronger container:
+
+- Use `trigger_report` for one emotionally meaningful episode.
+- Use `behavior_pattern` for a recurring loop that needs functional analysis:
+  situation -> cue -> emotion/body -> thought/meaning -> behavior/urge ->
+  short-term payoff -> long-term cost -> replacement response.
+- Use `behavior` for one recurring move inside a loop.
+- Use `belief_entry` when a sentence about self, others, safety, worth, or outcome is
+  visible.
+- Use `mode_profile` when a recurring part-state, protector, critic, child state, or
+  healthy-adult stance is visible.
+- Use `mode_guide_session` when the active part is not yet clear and the user needs
+  guided exploration.
+- Use `event_type` and `emotion_definition` when the reusable category or feeling
+  label will improve future trigger reports.
+- Use `wiki_page` when the user wants durable memory, a book/article/source summary,
+  a reference page, a concept page, or a reusable personal manual.
+- Use a linked `note` when nuance should be preserved without pretending it is the
+  whole structured model.
+
 ## Conversation arc
 
 Most good Forge intake flows follow this sequence:
@@ -149,9 +189,31 @@ Use this before you choose an API path or ask for more structure.
   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
+- For Movement, Life Force, and Workbench, use the lane
   to choose the dedicated route family before you ask for lower-level details.
 
+## Route posture checkpoint
+
+Use this quick split before the conversation gets too detailed.
+
+- Normal stored Forge entities use the shared batch entity routes by default:
+  `/api/v1/entities/search`, `/api/v1/entities/create`,
+  `/api/v1/entities/update`, `/api/v1/entities/delete`, and
+  `/api/v1/entities/restore`.
+- `wiki_page` and `calendar_connection` are specialized CRUD areas. Use the wiki
+  page routes and calendar connection setup or sync routes instead of pretending they
+  are simple batch records.
+- `task_run`, `work_adjustment`, `questionnaire_run`, `preference_judgment`,
+  `preference_signal`, and `self_observation` are action workflows. Start from what
+  the user is trying to do, then use the dedicated action tool or note-backed write
+  model.
+- Movement, Life Force, and Workbench are specialized domain areas. Use their
+  dedicated route families for timelines and overlays, energy profile/templates and
+  fatigue signals, and Workbench flow execution or result artifacts.
+- Once the route posture is clear, keep the questioning focused on the missing detail
+  that selects the route or payload. Do not ask route-neutral reflective questions
+  after the action path is already obvious.
+
 ## Active-listening patterns
 
 Use one of these shapes when the user is not yet precise.
@@ -244,7 +306,7 @@ exists.
 - When the user wants review rather than mutation, ask what answer they need from the
   read:
   what this would help them decide later is often the clearest scope signal.
-- For specialized surfaces, ask what exact saved object, span, weekday, flow, run, or
+- For Movement, Life Force, and Workbench, ask what exact saved object, span, weekday, flow, run, or
   node the user wants to check before you ask why it matters.
 - If the next answer would not change the route, wording, timing, links, or useful
   interpretation, stop asking and act.
@@ -263,12 +325,12 @@ Use this when the user wants to inspect, compare, review, or navigate existing F
 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:
+- Ask only for the scoping detail that changes what you need to look up:
   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.
+  user goal -> scope -> lookup -> interpretation -> optional follow-up write.
 - Only drift back into create or update intake if the user actually wants the record
   changed after the review.
 
@@ -425,7 +487,7 @@ Connect:
   to save, decide, review, or change, not make them perform the schema out loud.
 - For review or correction work, do not slip back into a create-style opener once the
   saved object is already known.
-- Once a specialized-surface lane is clear, speak in route-relevant nouns such as
+- Once the Movement, Life Force, or Workbench job is clear, speak in product nouns such as
   timeline, overlay, weekday template, published output, run detail, or node result
   instead of generic "record" language.
 - If the user is emotionally loaded but the record is still non-Psyche, reflect the
@@ -681,22 +743,37 @@ Preferred opening question:
 
 ## Wiki Page
 
-Aim: create a durable reference page with a clear scope instead of dumping raw notes
-into the wiki.
+Aim: create durable memory when the user wants to remember, study, cite, explain, or
+return to something later. Wiki pages are the right default for books, articles,
+sources, concepts, people, conversations, reusable instructions, and personal manuals.
 
 Arc:
 
-1. Ask what topic this page should become the canonical place for.
-2. Ask whether it is a durable wiki page or supporting evidence.
-3. Ask what future lookup, decision, or collaboration this page should support.
-4. Ask about linked entities, aliases, or tags only if they will make the page more
+1. Ask what this page should help the user remember, understand, or reuse later.
+2. Ask whether the material is a book, article, source, concept, person, conversation,
+   project reference, or personal manual.
+3. Ask what the page should contain now: summary, key claims, quotes to verify,
+   personal interpretation, action implications, or links.
+4. Ask whether it should be the durable wiki page itself or supporting evidence linked
+   to another page.
+5. Ask about linked entities, aliases, or tags only if they will make the page more
    navigable later.
 
 Helpful follow-up lanes:
 
-- what this page should be the home for
-- what should belong on the page versus remain linked evidence
-- who would open this page later and what they should quickly understand
+- what the user wants to remember or reuse
+- whether this is a book, article, source, concept, person, conversation, project
+  reference, or personal manual
+- what belongs on the durable page versus a supporting evidence note
+- what Forge entities, Psyche records, goals, projects, or tasks this memory should
+  link to
+
+Routing rule:
+
+- When the user says they want to remember something, save a reference, preserve a
+  book or article, keep a concept, or build a reusable explanation, consider
+  `wiki_page` before `note`. Use `note` for temporary evidence, work logs, or linked
+  detail; use `wiki_page` for durable memory.
 
 Ready to save when:
 
@@ -706,7 +783,7 @@ Ready to save when:
 
 Preferred opening question:
 
-- "What should this page become the main reference for?"
+- "What do you want this wiki page to help you remember or reuse later?"
 
 ## Insight
 
@@ -871,39 +948,63 @@ Preferred opening question:
 
 ## Self Observation
 
-Aim: capture one observation clearly enough that it can support later reflection
-without pretending it is already a full interpretation.
+Aim: capture one observed episode in a structured chain without letting a loose note
+replace the stronger Psyche model. A self-observation should usually name the
+situation, cue, emotion/body, thought/meaning, behavior/urge, and consequence. If the
+material reveals a recurring loop, belief, mode, schema theme, or
+trigger chain, route toward the structured Psyche record instead of parking it as an
+unstructured observation.
 
 Arc:
 
-1. Ask what was observed.
-2. Reflect the moment without pretending it is already a finished interpretation.
-3. Ask what felt most important to name before it gets smoothed over or forgotten.
-4. Ask for the smallest concrete slice if the observation still feels vague or
-   global.
-5. Ask when it happened or became noticeable.
-6. Ask what it may connect to: pattern, belief, value, mode, task, project, or note.
-7. Ask for tags or extra context only if that will help later review.
+1. Ask what happened in the situation.
+2. Ask what cue, trigger, or shift made the episode noticeable.
+3. Ask what emotion, body signal, thought, or meaning showed up.
+4. Ask what behavior showed up: what the user did, wanted to do, avoided, or
+   repeated next.
+5. Ask what happened immediately after, including short-term relief or cost if it is
+   visible.
+6. Decide whether this should stay a lightweight self-observation or become a
+   `trigger_report`, `behavior_pattern`, `behavior`, `belief_entry`, `mode_profile`,
+   `mode_guide_session`, `event_type`, `emotion_definition`, or wiki page.
+7. Link the observation to the structured record when the structured record is the
+   real container.
+
+Helpful follow-up lanes:
+
+- situation or event
+- cue, trigger, or body shift
+- emotion and intensity
+- thought, meaning, belief sentence, or schema theme
+- behavior, urge, avoidance, or coping move
+- short-term payoff and later cost
+- whether this is one episode, a recurring pattern, an active mode, or durable memory
 
 Route note:
 
 - `self_observation` is note-backed. Read the calendar first, then create or update an
   observed `note` with `frontmatter.observedAt` instead of inventing a standalone CRUD
   write.
+- Do not promote self-observation over functional analysis. If the user is describing
+  a loop, use `behavior_pattern`; if they are describing one emotionally meaningful
+  episode, use `trigger_report`; if a part-state is central, use `mode_guide_session`
+  or `mode_profile`; if a belief sentence is central, use `belief_entry`.
+- If the user wants to remember a source, concept, book, article, or durable personal
+  explanation, use `wiki_page` rather than self-observation.
 
-If the user already gave the moment or timing, move straight to what they noticed most
-clearly instead of re-asking when.
+If the user already gave the event or timing, move straight to the missing part of the
+chain: cue, emotion, thought, behavior, consequence, or structured Psyche link.
 
 Ready to save when:
 
-- the observation itself is clear
-- the lived point of the observation is clear enough to revisit later
+- the situation/event is clear
+- at least one emotion/body signal, thought/meaning, or behavior/urge is clear
 - timing is clear enough
-- any useful links are captured
+- any better structured container has been chosen or linked
 
 Preferred opening question:
 
-- "What did you notice most clearly in that moment?"
+- "What happened in the situation, and what did you feel, think, or do next?"
 
 ## Sleep Session
 
@@ -1009,6 +1110,12 @@ Helpful follow-up lanes:
 - which preference context should own the signal
 - whether the choice feels decisive, weak, tied, or not ready
 
+Route note:
+
+- `preference_judgment` is an action workflow. Submit it through
+  `POST /api/v1/preferences/judgments` with the preferences judgment tool, not batch
+  CRUD.
+
 Ready to act when:
 
 - the left and right items are clear
@@ -1037,6 +1144,11 @@ Helpful follow-up lanes:
 - whether this is a favorite, veto, bookmark, neutral, or compare-later signal
 - what context makes the signal meaningful
 
+Route note:
+
+- `preference_signal` is an action workflow. Submit it through
+  `POST /api/v1/preferences/signals` with the preferences signal tool, not batch CRUD.
+
 Ready to act when:
 
 - the item is clear
@@ -1068,7 +1180,8 @@ Arc:
    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.
-9. Route to the dedicated movement read or write path once the surface is clear.
+9. Use the dedicated movement route once you know whether the user needs timeline
+   review, overlay, place or trip detail, selection summary, or repair.
 
 Direct action rules:
 
@@ -1133,7 +1246,7 @@ Lane-to-route map:
 
 Ready to act when:
 
-- the movement surface is clear
+- the movement question or correction is clear
 - the time range, place, stay, trip, or selection is clear enough
 - the user goal is clear enough to tell review, overlay, and repair apart
 - the user goal is clear enough to choose the route
@@ -1242,7 +1355,8 @@ 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`
+  `POST /api/v1/workbench/flows`, then `PATCH /api/v1/workbench/flows/:id` or
+  `DELETE /api/v1/workbench/flows/:id` for an existing saved flow
 - run a known flow:
   `/api/v1/workbench/flows/:id/run`
 - run from a payload-first contract:
@@ -1304,6 +1418,12 @@ Helpful follow-up lanes:
 - what belongs in scope
 - what would make the catalog immediately useful instead of bloated
 
+Route note:
+
+- `preference_catalog` is normal stored Preferences CRUD. Use the shared batch entity
+  routes unless the user is playing the comparison game or submitting a judgment or
+  signal.
+
 Ready to save when:
 
 - the catalog has a stable purpose
@@ -1332,6 +1452,11 @@ Helpful follow-up lanes:
 - what would distinguish it from nearby items
 - whether the label alone will be clear later
 
+Route note:
+
+- `preference_catalog_item` is normal stored Preferences CRUD. Use batch entity
+  create/update/search for catalog membership and wording changes.
+
 Ready to save when:
 
 - the item label is clear
@@ -1360,6 +1485,11 @@ Helpful follow-up lanes:
 - what belongs inside versus outside the mode
 - whether it should be default or explicitly separate
 
+Route note:
+
+- `preference_context` is normal stored Preferences CRUD. Use batch entity
+  create/update/search for context definition changes.
+
 Ready to save when:
 
 - the context has a stable purpose
@@ -1391,6 +1521,12 @@ Helpful follow-up lanes:
 - whether this is a signal or a comparison candidate
 - what distinguishes the item from nearby options
 
+Route note:
+
+- `preference_item` is normal stored Preferences CRUD when saving or editing a
+  candidate. Use `preference_judgment` or `preference_signal` routes only when the
+  user is recording a comparison outcome or direct mark.
+
 Ready to act when:
 
 - the item is clear
@@ -1423,6 +1559,12 @@ Helpful follow-up lanes:
 - who will answer it and under what circumstances
 - what would make the instrument distinct instead of redundant
 
+Route note:
+
+- `questionnaire_instrument` is normal stored CRUD for ordinary create, update,
+  delete, and search work. Use clone, draft, and publish action routes only when the
+  user is working with instrument version state.
+
 Ready to act when:
 
 - the purpose is clear
@@ -1451,6 +1593,11 @@ Helpful follow-up lanes:
 - what questionnaire or run is in scope
 - what next answer, uncertainty, or note is actually blocking progress
 
+Route note:
+
+- `questionnaire_run` is an action workflow. Use the questionnaire run start, read,
+  update, and complete routes instead of treating answers as generic batch CRUD.
+
 Ready to act when:
 
 - the questionnaire is identified

package/skills/forge-openclaw/psyche_entity_playbooks.md

@@ -259,6 +259,31 @@ Connect:
 - only after the primary formulation feels steady, ask whether an adjacent value,
   belief, mode, pattern, note, or task should be linked or mapped separately
 
+## Schema Theme Routing
+
+Forge does not treat schema work as a loose self-observation. When a schema theme is
+visible, help the user name how it organizes meaning, protection, expectation, and
+behavior.
+
+Use these containers:
+
+- `belief_entry` when the schema appears as a sentence, rule, prediction, or
+  self/other/world assumption.
+- `behavior_pattern` when the schema drives a recurring cue -> emotion/body ->
+  thought/meaning -> behavior/urge -> payoff -> cost loop.
+- `mode_profile` when the schema is carried by a recurring part-state such as a
+  protector, critic, vulnerable child, coping mode, or healthy-adult response.
+- `mode_guide_session` when the user is in the reaction and needs guided exploration
+  before a durable mode or belief is clear.
+- `trigger_report` when the schema became visible in one emotionally meaningful
+  episode.
+- `wiki_page` when the user wants a durable explanation of a schema theme, therapy
+  concept, book, article, source, or personal manual they will need to find again.
+
+Do not ask the user to pick the container first. Reflect the active meaning in plain
+language, ask for one recent moment or one belief sentence, then choose the record that
+will preserve the structure best.
+
 ## Lane chooser
 
 After each real answer, choose the next best lane. Do not mix several lanes at once.
@@ -729,3 +754,83 @@ Ready to save when:
 Preferred opening question:
 
 - "What happened in that moment, as concretely as you can say it?"
+
+## Event Type
+
+Aim: name a repeated emotionally meaningful kind of moment without flattening the
+lived episode into a cold taxonomy.
+
+Arc:
+
+1. Ask what kind of moment keeps recurring and why it matters to name it consistently.
+2. Reflect the repeated emotional or relational stake in plain language before wording
+   the category.
+3. Ask for one recent example if the boundary is still abstract.
+4. Clarify what belongs inside this event type and what should stay outside it.
+5. Offer one concise candidate label once the repeated moment is clear.
+6. Link it to trigger reports, beliefs, patterns, modes, or emotion definitions only
+   after the category itself feels accurate.
+
+Helpful follow-up lanes:
+
+- what repeated moment this event type should help future reports name
+- what felt threatened, exposed, relieved, or important in those moments
+- what would make a future incident count as this type instead of a nearby one
+- which trigger reports or patterns this event type should help organize
+
+Likely linked entities:
+
+- `trigger_report` when a specific episode shows the category clearly
+- `behavior_pattern` when the event type usually starts a recurring loop
+- `belief_entry` when the event type reliably activates one sentence or prediction
+- `emotion_definition` when one feeling label needs to stay consistent across reports
+
+Ready to save when:
+
+- the repeated moment is understandable in plain language
+- the boundary is clear enough for future reports to use consistently
+- the label feels accurate enough or has one candidate wording to confirm
+
+Preferred opening question:
+
+- "What kind of moment keeps happening that you want future reports to name the same way each time?"
+
+## Emotion Definition
+
+Aim: define a psychologically meaningful feeling label by its lived signature, not just
+by a dictionary word.
+
+Arc:
+
+1. Ask when this feeling was present recently and what made it recognizable.
+2. Reflect the felt signature before asking for a category or label polish.
+3. Ask what distinguishes it from nearby feelings if the boundary matters.
+4. Ask what the feeling tends to signal, protect, or ask for.
+5. Offer one concise definition in the user's language and invite correction.
+6. Link it to trigger reports, modes, beliefs, or patterns only after the definition
+   feels steady.
+
+Helpful follow-up lanes:
+
+- body signal, urge, image, thought, or relational meaning that identifies the feeling
+- what makes it different from nearby feelings such as fear, shame, anger, sadness,
+  grief, or numbness
+- what the feeling usually warns about, longs for, protects, or demands
+- which reports or patterns should use this label later
+
+Likely linked entities:
+
+- `trigger_report` when one episode makes the feeling concrete
+- `mode_profile` when the feeling belongs to a recurring part-state
+- `belief_entry` when the feeling is tied to one self-statement or prediction
+- `behavior_pattern` when the feeling is a common cue in a repeated loop
+
+Ready to save when:
+
+- the felt signature is clear enough to recognize later
+- the boundary from nearby feelings is clear enough when it matters
+- the definition can be written in language the user recognizes
+
+Preferred opening question:
+
+- "When this feeling is present, what tells you it is this feeling and not a nearby one?"