forge-openclaw-plugin 0.3.14 → 0.3.15

package/README.md

@@ -255,7 +255,7 @@ openclaw forge health
 openclaw forge ui
 ```
 
-Tested on OpenClaw `2026.5.4`: plain `openclaw plugins install forge-openclaw-plugin` is blocked by the plugin scanner because Forge contains local runtime startup helpers. The documented command uses OpenClaw's explicit approval flag and installs without the old config-edit workaround.
+Tested on OpenClaw `2026.6.9`: plain `openclaw plugins install forge-openclaw-plugin` is blocked by the plugin scanner because Forge contains local runtime startup helpers. The documented command uses OpenClaw's explicit approval flag and installs without the old config-edit workaround.
 
 Check what OpenClaw loaded:
 
@@ -542,7 +542,7 @@ The repo now supports a tag-driven GitHub Actions release path for step 1. The n
 prep flow from a clean checkout on `main` is:
 
 ```bash
-FORGE_RELEASE_MODE=prepare ./scripts/release-forge-openclaw-plugin.sh patch
+FORGE_RELEASE_MODE=prepare ./scripts/release/release-forge-openclaw-plugin.sh patch
 ```
 
 That command bumps the aligned plugin versions, runs the verification suite, commits

package/dist/index.html

@@ -11,10 +11,10 @@
       name="description"
       content="Forge is a premium life operating system for turning long-horizon goals into daily motion."
     />
-    <link rel="icon" type="image/png" href="/forge/assets/favicon-Bai4rhyS.png" />
-    <link rel="icon" type="image/svg+xml" href="/forge/assets/favicon-ERg17ZCd.svg" />
-    <link rel="alternate icon" href="/forge/assets/favicon-B6oXI6k4.ico" />
-    <link rel="apple-touch-icon" href="./apple-touch-icon.png" />
+    <link rel="icon" type="image/png" href="/forge/favicon.png" />
+    <link rel="icon" type="image/svg+xml" href="/forge/favicon.svg" />
+    <link rel="alternate icon" href="/forge/favicon.ico" />
+    <link rel="apple-touch-icon" href="/forge/apple-touch-icon.png" />
     <style>
       :root {
         color-scheme: dark;

package/dist/openclaw/index.d.ts

@@ -1,10 +1,5 @@
+import { type OpenClawPluginDefinition } from "openclaw/plugin-sdk/plugin-entry";
 import { forgePluginConfigSchema, registerForgePlugin, resolveForgePluginConfig } from "./plugin-entry-shared.js";
-declare const pluginEntry: {
-    id: string;
-    name: string;
-    description: string;
-    configSchema: import("openclaw/plugin-sdk/plugin-entry").OpenClawPluginConfigSchema;
-    register: NonNullable<import("openclaw/plugin-sdk/plugin-entry").OpenClawPluginDefinition["register"]>;
-} & Pick<import("openclaw/plugin-sdk/plugin-entry").OpenClawPluginDefinition, "kind" | "reload" | "nodeHostCommands" | "securityAuditCollectors">;
+declare const pluginEntry: OpenClawPluginDefinition;
 export default pluginEntry;
 export { forgePluginConfigSchema, registerForgePlugin, resolveForgePluginConfig };

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

@@ -3105,6 +3105,7 @@ const AGENT_ONBOARDING_CONVERSATION_RULES = [
     "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.",
+    "Before asking a follow-up, know what the user's answer would change: save, update, review, link, schedule, correct, run, publish, preserve, enrich, open the UI, or stop. If no possible answer would change the next action, summarize and act instead of asking.",
     "Use a minimum save-readiness checkpoint before asking another follow-up. For normal batch entities, act when you have accepted wording, meaningful body, and any ownership or placement that changes later use; do not ask for tags, links, priority, dates, assignees, or status just because optional fields exist. For operational records, act when the target action plus the time, object, or state that makes it truthful is clear. For read-model surfaces, read once the practical question and answer-changing scope are clear. For specialized Movement, Life Force, and Workbench writes, act once the lane plus target span/object/weekday/flow/run/node and intended correction or effect are clear.",
     "For strategic, reflective, or emotionally meaningful non-Psyche records, ask what feels important to keep true before you ask for labels, dates, or taxonomy.",
     "For reflection-sensitive non-Psyche records such as questionnaire_instrument, questionnaire_run, self_observation, reflective note, wiki_page, sleep_session, workout_session, preference_judgment, and preference_signal, first ask what the reflection should help the user understand, decide, notice, remember, or change later; then keep the API posture exact: batch CRUD for normal stored records, questionnaire run actions for answer lifecycle, self-observation calendar reads plus observed-note writes, and wiki routes for wiki pages.",
@@ -3116,6 +3117,7 @@ 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.",
     "For review-first requests, 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.",
     "After a review, overview, navigation, or specialized read returns data, first answer the user's practical question in plain language, then name one implication or uncertainty that matters for the next decision. Ask a follow-up only if it changes the next action: save, update, correct, link, schedule, run, publish, enrich, or open the UI.",
+    "After a read, make the read's decision value explicit: what it rules in, what it rules out, and what one uncertainty remains. If no answer-changing uncertainty remains, close cleanly.",
     "Treat userId, owner, and human/bot assignees as accountability and scope, not as opening form fields. Ask whose record or owner scope matters only when it changes visibility, review results, collaboration, automation behavior, or later filtering.",
     "For read and overview requests, ask for human or bot user scope only when the answer would meaningfully differ across owners; otherwise keep the next question focused on the user's practical question.",
     "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.",
@@ -3126,6 +3128,7 @@ const AGENT_ONBOARDING_CONVERSATION_RULES = [
     "Do not minimize functional analysis, trigger chains, behavior patterns, modes, beliefs, or schema themes. After at least one concrete example is clear, offer one careful interpretive hypothesis when it would help the user understand what the reaction may be protecting, predicting, relieving, or costing.",
     "Phrase Psyche interpretive hypotheses as collaborative and testable, not as verdicts. Ask whether the hypothesis lands or needs correction before turning it into a saved belief, pattern, mode, trigger report, or note.",
     "A useful Psyche hypothesis starts from the user's concrete example, names one possible protection, prediction, relief, or cost, and asks for correction before it becomes a saved record shape.",
+    "When the user reports an urge or wants a Psyche flashcard, search flashcards first, show a matching card's message before adding support, and if no card fits create only after the cue or urge sentence and short message are clear; postpone visual style, colors, tags, and optional links until the intervention sentence works.",
     "For Psyche save-readiness, stop deepening once the user recognizes the working formulation and the minimum shape is present: belief sentence, functional loop, behavior move, part-state, trigger episode, value, event type, emotion definition, or flashcard cue/message. Ask one accuracy question at most, then save through shared batch CRUD when the user says yes.",
     "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 shape in a meaningful way, stop asking and act.",
@@ -5486,19 +5489,21 @@ function buildAgentOnboardingPayload(request) {
             saveSuggestionPlacement: "end_of_message",
             saveSuggestionTone: "gentle_optional",
             maxQuestionsPerTurn: 1,
+            depthCalibrationRule: "Before deepening an intake, decide whether this is quick capture, guided formulation, review-first help, or action-first execution. Quick capture means the user already supplied usable wording and wants it saved, remembered, or logged; reflect the working shape once, ask only the one structural, accuracy, or consent detail that changes the write, and do not force full exploration. Guided formulation means the user asks to understand, name, map, decide, or work through unclear or charged material; use active listening, one lane at a time, and Psyche hypotheses when appropriate before saving. Review-first means read the relevant stored entity, overview, or specialized surface before asking write-shaped questions. Action-first means the target task run, work adjustment, preference signal or judgment, questionnaire run, Movement correction, Life Force signal or weekday template, or Workbench run or output is already clear, so act or ask only for the missing target, span, flow, run, node, weekday, correction, or consent. Do not downgrade psychologically meaningful material into quick capture when the user wants exploration, and do not expand a simple storage request into therapy or project planning.",
+            operationLaneRule: "Keep the operation lane explicit before asking for lower-level details. Normal stored entities can be added, updated, reviewed or navigated, linked, or placed. Action workflows use verbs such as start, continue, complete, adjust, judge, signal, publish, sync, or observe. Specialized CRUD surfaces use lifecycle verbs such as create, read, update, sync, reconnect, delete, or browse. Read-model surfaces need a practical read question and scope before any write-shaped follow-up. Movement, Life Force, and Workbench use review, correct, repair, run, inspect, publish, or preserve lanes through their dedicated route keys. Psyche entities need a formulation lane before the storage lane when the user wants understanding; direct saves can move to one accuracy or consent question.",
             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; do not leave the user with interpretation alone, name the primary Forge record it is becoming, and ask one accuracy or consent 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.",
             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. After any dedicated read, translate the result into one next action: no change, Movement overlay/place/settings/link, Life Force workload/recovery/timebox/meeting/task-choice change, or Workbench rerun/node inspection/flow edit/publish/preserve/stop. Ask only for the missing span, place, weekday, flow, run, node, output, correction, preservation choice, or confirmation that would change that action. 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. If several actions are possible, narrow to the one most directly supported by the read instead of handing the user a broad menu. Do not reopen the whole intake unless the user is actually redefining the record.",
+            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. Before every dedicated call, run a route-contract handshake internally: select the product lane in plain language, verify the matching routeKey against live onboarding routeKeys and methodRoutes, fill any placeholders through pathParams, and ask the user only for the missing product noun that fills the placeholder. When available, use forge_call_movement_route, forge_call_life_force_route, or forge_call_workbench_route after the lane is clear. If a route-key tool is unavailable, stale, or missing the needed key, read live onboarding and use the exact specializedDomainSurfaces.methodRoutes entry for the selected lane; cross-check OpenAPI only to confirm the same method and path, do not fall back to generic batch CRUD, do not invent a nearby raw path, and treat schema disagreement as a Forge contract bug to fix. Before calling a specialized route, inspect its methodRoutes entry for placeholders such as :id, :weekday, :slug, :runId, :nodeId, or :pointId, then fill each one through pathParams with the same placeholder name; do not hide IDs in query, body, or routeKey. If the contract is missing a lane the product clearly supports, report a contract bug instead of silently using generic batch CRUD or a nearby route. 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. After any dedicated read, translate the result into one next action: no change, Movement overlay/place/settings/link, Life Force workload/recovery/timebox/meeting/task-choice change, or Workbench rerun/node inspection/flow edit/publish/preserve/stop. Ask only for the missing span, place, weekday, flow, run, node, output, correction, preservation choice, or confirmation that would change that action. 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, and state what the read rules in, rules out, or leaves uncertain. If several actions are possible, narrow to the one most directly supported by the read instead of handing the user a broad menu. 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.",
-            psycheHypothesisRule: "When one concrete Psyche example is visible, a helpful hypothesis should start from evidence in the user's own example, offer one testable interpretation, name the function without blame such as protection, prediction, relief, or cost, and ask whether the danger, need, or wording fits. Use the hypothesis timing checkpoint before asking a second or third deepening question: offer a hypothesis when one concrete episode, body cue, belief sentence, behavior, or mode voice is visible and the hypothesis would change the record shape, wording, links, or next action. Do not keep asking broad exploratory Psyche questions after the cue, meaning, protection, payoff, or cost is already visible. For behavior_pattern, belief_entry, mode_profile, mode_guide_session, and trigger_report, the next helpful move is usually one active formulation plus one correction question, not another passive reflection. Hypotheses should reduce the formulation burden. Do not make the user prove the experience: after one hypothesis, ask one fit-or-correction question rather than a stack of evidence, origin, and repair questions. If accuracy needs grounding, ask for the smallest lived cue or contrast that would change the wording, danger, protection, payoff, cost, or record shape. Do not hypothesize yet when no concrete moment is visible, the user only wants a direct mechanical save, the user is flooded or unsafe, or the only available interpretation would be diagnosis-like, an origin story, or a certainty claim. Do not present schema, mode, belief, or pattern language as a verdict. Do not leave the user with interpretation alone; name the primary Forge record and ask one accuracy or consent question that moves toward saving the corrected formulation. If the user corrects the hypothesis, revise it once and move toward the saveable record shape instead of asking for another broad story.",
+            psycheHypothesisRule: "When one concrete Psyche example is visible, a helpful hypothesis should start from evidence in the user's own example, offer one testable interpretation, name the function without blame such as protection, prediction, relief, or cost, and ask whether the danger, need, or wording fits. Use the hypothesis timing checkpoint before asking a second or third deepening question: offer a hypothesis when one concrete episode, body cue, belief sentence, behavior, or mode voice is visible and the hypothesis would change the record shape, wording, links, or next action. Use the Psyche hypothesis examples when another broad question would make the user do all the interpretation alone: behavior_pattern should test cue, protection, payoff, and cost; belief_entry should test the activated sentence; mode_profile and mode_guide_session should test the part's job and feared danger; trigger_report should test the sequence; event_type and emotion_definition should test future recognition. Do not keep asking broad exploratory Psyche questions after the cue, meaning, protection, payoff, or cost is already visible. For behavior_pattern, belief_entry, mode_profile, mode_guide_session, and trigger_report, the next helpful move is usually one active formulation plus one correction question, not another passive reflection. Hypotheses should reduce the formulation burden. Do not make the user prove the experience: after one hypothesis, ask one fit-or-correction question rather than a stack of evidence, origin, and repair questions. If accuracy needs grounding, ask for the smallest lived cue or contrast that would change the wording, danger, protection, payoff, cost, or record shape. Do not hypothesize yet when no concrete moment is visible, the user only wants a direct mechanical save, the user is flooded or unsafe, or the only available interpretation would be diagnosis-like, an origin story, or a certainty claim. Do not present schema, mode, belief, or pattern language as a verdict. Do not leave the user with interpretation alone; name the primary Forge record and ask one accuracy or consent question that moves toward saving the corrected formulation. For flashcard support, search existing flashcards first and show a matching message before adding coaching; create only after the cue or urge sentence and short message are clear, and postpone visual style, colors, tags, and optional links until the intervention sentence works. If the user corrects the hypothesis, revise it once and move toward the saveable record shape instead of asking for another broad story.",
             mixedIntentSequencingRule: "When one user message combines several Forge jobs, identify the primary job and the order of operations before asking a follow-up. If a read changes the truth of a later write, read first: Movement timeline or box detail before correction, Workbench run or node detail before editing or publishing, and Life Force overview before changing durable assumptions when the current energy picture is uncertain. If the user asks to understand and save Psyche material plus create a support record, formulate the primary Psyche record first, then derive the flashcard, note, link, task, or habit from the accepted wording. If the user already gave the concrete action, do not ask a broad lane question; say the product sequence briefly and ask only for the missing span, wording, flow, run, node, weekday, or link that changes the next action.",
             duplicateDisambiguationRule: "Before creating or updating a normal stored entity when duplicate risk is plausible, search the shared batch entity route by entity type, distinctive title or wording, owner scope, and linked content. If a likely existing record appears, ask whether the user wants to update that record, link to it, or save a separate new record; do not reopen the whole create flow. For Psyche records, a similar belief, pattern, mode, trigger report, value, or flashcard is a formulation choice, not a duplicate error: compare the sentence, cue/payoff/cost, protective job, episode, urge sentence, or message and let the user choose update, link, or new version. For wiki_page and calendar_connection, use dedicated search/list/read routes before creating another page or connection. For Movement, Life Force, and Workbench, use the dedicated read lanes instead of batch duplicate search.",
             destructiveActionRule: "Before deleting, archiving, invalidating, overwriting, disconnecting, or substantially replacing a Forge record or specialized object, confirm the exact target and what should remain understandable. Prefer normal soft-delete for stored entities unless the user explicitly asks for permanent removal. For Psyche records, preserve therapeutic history by asking whether the old belief, pattern, mode, trigger report, value, or flashcard should be updated, linked as history, archived, or kept distinct; do not delete it just because a cleaner formulation exists. For Movement, distinguish user-defined overlay deletion from automatic-box invalidation and stay/trip/point deletion, and read the specific span first when the target is uncertain. For calendar connections, Workbench flows, wiki pages, and questionnaire instruments, ask what downstream sync, published output, backlinks, run history, or completed runs should remain understandable before deleting or replacing the saved object.",
-            followUpQuestionRule: "After a substantive answer, do not restart the opener or jump to the next schema field. First say what became clearer in concrete language, then choose exactly one next lane: wording, boundary, placement, timing, route scope, link, hypothesis, or write confirmation. Ask the smallest question that would change the record shape, route choice, useful wording, timing, or links. If nothing decision-relevant would change, stop asking, summarize the working record, and act with consent.",
-            antiDriftRule: "Avoid vague reflective filler and internal route language. Keep a private action trace: intent, entity or dedicated domain lane, exact read/write/run tool, required target identifiers, and the one missing detail that would change the action. Do not narrate that trace to the user. Replace phrases like 'that sounds important' with the specific stake you heard, and replace API nouns like surface, CRUD, payload, mutation path, route key, or endpoint with user-facing product nouns such as belief, pattern, note, wiki page, timeline, overlay, missing stay, weekday template, flow, run, node result, or published output. Ask one product-language question when the trace is unclear; with the user, ask about the real thing: the span, place, weekday, flow, run, node, belief sentence, parent record, or save confirmation. When reporting actions, say the product result first: saved the belief, corrected the missing stay, updated the weekday energy pattern, or read the failed node. Mention route keys, HTTP paths, payloads, or batch routes only for implementation debugging. If a question would only decorate the intake, skip it.",
+            followUpQuestionRule: "After a substantive answer, do not restart the opener or jump to the next schema field. First say what became clearer in concrete language, then choose exactly one next lane: wording, boundary, placement, timing, route scope, link, hypothesis, or write confirmation. Run the no-question gate before every follow-up: ask only if the answer can change record type, accepted wording, hierarchy placement, owner/accountability, timing, route lane, target object, correction, link, verification read, run/publish/preserve action, or consent. Ask the smallest question that would change the record shape, route choice, useful wording, timing, links, or next action. Before asking, be able to name what a possible answer would change: save, update, review, link, schedule, correct, run, publish, preserve, enrich, open the UI, or stop. If nothing decision-relevant would change, stop asking, summarize the working record, and act with consent. If the question would only add warmth, completeness, optional metadata, or form polish, skip it.",
+            antiDriftRule: "Avoid vague reflective filler and internal route language. Keep a private action trace: intent, entity or dedicated domain lane, exact read/write/run tool, required target identifiers, and the one missing detail that would change the action. Do not narrate that trace to the user. Replace phrases like 'that sounds important' with the specific stake you heard, and replace API nouns like surface, CRUD, payload, mutation path, route key, batch route, or endpoint with user-facing product nouns such as belief, pattern, note, wiki page, timeline, overlay, missing stay, weekday template, flow, run, node result, or published output. Ask one product-language question when the trace is unclear; with the user, ask about the real thing: the span, place, weekday, flow, run, node, belief sentence, parent record, or save confirmation. If you cannot yet name the product noun, ask one grounding question instead of adding reflective filler. When reporting actions, say the product result first: saved the belief, corrected the missing stay, updated the weekday energy pattern, or read the failed node. Mention route keys, HTTP paths, payloads, or batch routes only for implementation debugging. If a question would only decorate the intake, skip it.",
             duplicateCheckRoute: "/api/v1/entities/search",
             uiSuggestionRule: "offer_visual_ui_when_review_or_editing_would_be_easier",
             browserFallbackRule: "Do not open the Forge UI or a browser just to create or update normal entities when the batch entity tools can do the job. Batch CRUD is the default for simple entities; avoid spamming the agent with a large one-route-per-entity mental model.",
@@ -5520,7 +5525,7 @@ function buildAgentOnboardingPayload(request) {
             searchRule: "forge_search_entities accepts searches as an array. Search before create or update when duplicate risk exists.",
             createRule: "Each create operation must include entityType and full data. entityType alone is not enough. This includes calendar_event, work_block_template, task_timebox, sleep_session, workout_session, preference CRUD entities, and questionnaire_instrument alongside the usual planning and Psyche entities.",
             updateRule: "Each update operation must include entityType, id, and patch. For projects, lifecycle changes are status patches: active to restart, paused to suspend, completed to finish. Keep task and project scheduling rules on those same patch payloads. Official habit outcomes can also be logged through forge_update_entities by patching the habit with checkIn: { status, dateKey?, note?, description? } instead of route-hunting. Calendar-event updates still run downstream provider projection sync, and manual health-session field edits belong on the batch route by default rather than on the reflective review helpers.",
-            specializedRouteToolRule: "forge_call_movement_route, forge_call_life_force_route, and forge_call_workbench_route expect { routeKey, pathParams?, query?, body? }. Choose routeKey from the tool schema or entityRouteModel.specializedDomainSurfaces, fill pathParams for placeholders such as id, weekday, slug, runId, nodeId, or pointId, use query for read filters and userIds, and use body only for POST, PATCH, or PUT route keys. The Life Force overview route key maps to GET /api/v1/life-force; do not invent /api/v1/life-force/overview. Normal stored entities still use the shared batch entity tools.",
+            specializedRouteToolRule: "forge_call_movement_route, forge_call_life_force_route, and forge_call_workbench_route expect { routeKey, pathParams?, query?, body? }. Choose routeKey from the tool schema or entityRouteModel.specializedDomainSurfaces, fill every methodRoutes placeholder with pathParams using names such as id, weekday, slug, runId, nodeId, or pointId, use query for read filters and userIds, and use body only for POST, PATCH, or PUT route keys. Do not put required IDs or weekdays inside routeKey, query, or body when the published path has a placeholder. The Life Force overview route key maps to GET /api/v1/life-force; do not invent /api/v1/life-force/overview. Normal stored entities still use the shared batch entity tools.",
             createExample: '{"operations":[{"entityType":"goal","data":{"title":"Create meaningfully"},"clientRef":"goal-create-1"},{"entityType":"goal","data":{"title":"Build a beautiful family"},"clientRef":"goal-create-2"}]}',
             updateExample: '{"operations":[{"entityType":"project","id":"project_123","patch":{"status":"paused","schedulingRules":{"blockWorkBlockKinds":["main_activity"],"allowWorkBlockKinds":["secondary_activity"]}},"clientRef":"project-suspend-1"},{"entityType":"habit","id":"habit_456","patch":{"checkIn":{"status":"missed","note":"Resisted the urge after dinner.","description":"85 sec reset"}},"clientRef":"habit-check-in-1"}]}',
             specializedRouteToolExample: '{"routeKey":"weekdayTemplate","pathParams":{"weekday":"monday"},"body":{"points":[{"hour":13,"freeAp":-4}]}}',

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

@@ -4137,6 +4137,8 @@ export function buildOpenApiDocument() {
                     "saveSuggestionPlacement",
                     "saveSuggestionTone",
                     "maxQuestionsPerTurn",
+                    "depthCalibrationRule",
+                    "operationLaneRule",
                     "psycheExplorationRule",
                     "specializedSurfaceRule",
                     "reviewShortcutRule",
@@ -4158,6 +4160,8 @@ export function buildOpenApiDocument() {
                     saveSuggestionPlacement: { type: "string" },
                     saveSuggestionTone: { type: "string" },
                     maxQuestionsPerTurn: { type: "integer" },
+                    depthCalibrationRule: { type: "string" },
+                    operationLaneRule: { type: "string" },
                     psycheExplorationRule: { type: "string" },
                     specializedSurfaceRule: { type: "string" },
                     reviewShortcutRule: { type: "string" },

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forge-openclaw-plugin",
-  "version": "0.3.14",
+  "version": "0.3.15",
   "description": "Curated OpenClaw adapter for the Forge collaboration API, UI entrypoint, and localhost auto-start runtime.",
   "type": "module",
   "license": "Apache-2.0",
@@ -40,11 +40,11 @@
       "./dist/openclaw/index.js"
     ],
     "install": {
-      "minHostVersion": ">=2026.5.4"
+      "minHostVersion": ">=2026.6.9"
     }
   },
   "peerDependencies": {
-    "openclaw": "2026.5.4"
+    "openclaw": "2026.6.9"
   },
   "dependencies": {
     "@azure/msal-node": "^5.1.2",
@@ -57,6 +57,7 @@
     "@fontsource-variable/sora": "^5.2.8",
     "@fontsource/space-grotesk": "^5.2.10",
     "@hookform/resolvers": "^5.1.1",
+    "@mariozechner/pi-agent-core": "^0.73.1",
     "@mariozechner/pi-ai": "^0.66.1",
     "@radix-ui/react-dialog": "^1.1.14",
     "@reduxjs/toolkit": "^2.11.2",
@@ -80,7 +81,7 @@
     "graphology-layout": "^0.6.1",
     "graphology-layout-forceatlas2": "^0.10.1",
     "lucide-react": "^0.525.0",
-    "node-ical": "^0.20.1",
+    "node-ical": "^0.26.1",
     "qrcode": "^1.5.4",
     "react": "^19.1.0",
     "react-arborist": "^3.4.3",
@@ -105,6 +106,7 @@
     "follow-redirects": "^1.16.0",
     "hono": "^4.12.18",
     "ip-address": "^10.2.0",
+    "markdown-it": "^14.2.0",
     "ws": "^8.20.1",
     "uuid": "^14.0.0"
   },

package/server/index.js

@@ -7,7 +7,12 @@ const packageRoot = path.resolve(path.dirname(fileURLToPath(import.meta.url)), "
 const repoRoot = path.resolve(packageRoot, "..");
 const builtRuntimeEntry = path.join(packageRoot, "dist", "server", "server", "src", "index.js");
 const devRuntimeEntry = path.join(repoRoot, "server", "src", "index.ts");
-const devDataRootWrapper = path.join(repoRoot, "scripts", "with-openclaw-plugin-data-root.mjs");
+const devDataRootWrapper = path.join(
+  repoRoot,
+  "scripts",
+  "dev",
+  "with-openclaw-plugin-data-root.mjs"
+);
 const tsxCliEntry = path.join(repoRoot, "node_modules", "tsx", "dist", "cli.mjs");
 const devModeFlag = (process.env.FORGE_OPENCLAW_DEV ?? "").trim().toLowerCase();
 const useDevRuntime = devModeFlag === "1" || devModeFlag === "true" || devModeFlag === "yes";

package/skills/forge-openclaw/SKILL.md

@@ -103,12 +103,25 @@ any route-key or endpoint detail.
   route-key-to-`METHOD /api/v1/...` source of truth when checking specialized
   methods, especially POST aggregate reads such as Movement `selection` and DELETE
   repair paths. When a route key's exact path contains placeholders such as `:id`,
-  `:weekday`, `:runId`, or `:nodeId`, pass those values in `pathParams` using the
-  placeholder names exactly. Do not place IDs inside `routeKey`, invent a raw route
-  string, or ask the user to choose an endpoint when the lane already selects one. If
-  that schema and live onboarding disagree, trust the live onboarding for the current
-  call and treat the disagreement as a Forge contract bug to fix, not as a reason to
-  guess a nearby route.
+  `:weekday`, `:slug`, `:runId`, `:nodeId`, or `:pointId`, pass those values in
+  `pathParams` using the placeholder names exactly. Do not place IDs inside
+  `routeKey`, `query`, or `body`, invent a raw route string, or ask the user to
+  choose an endpoint when the lane already selects one. If that schema and live
+  onboarding disagree, trust the live onboarding for the current call and treat the
+  disagreement as a Forge contract bug to fix, not as a reason to guess a nearby
+  route.
+- If a specialized route-key tool is unavailable, stale, or missing the needed route
+  key, do not fall back to generic batch CRUD and do not invent a nearby raw path. Read
+  live onboarding, use the exact `methodRoutes` entry for the selected Movement, Life
+  Force, or Workbench lane, and cross-check OpenAPI only to confirm the same method
+  and path.
+- Before every Movement, Life Force, or Workbench call, run a route-contract
+  handshake internally: select the product lane in plain language, verify the matching
+  `routeKey` against live onboarding `routeKeys` and `methodRoutes`, fill any
+  placeholders through `pathParams`, and ask the user only for the missing product
+  noun that fills the placeholder. If the contract is missing a lane the product
+  clearly supports, report a contract bug instead of silently using generic batch
+  CRUD or a nearby route.
 
 Concrete route-key examples for internal use:
 
@@ -258,12 +271,24 @@ Write to Forge only with clear user consent. If the user is just thinking aloud,
 Entity conversation rule:
 
 - For all entity creation or update flows, first use [`entity_conversation_playbooks.md`](./entity_conversation_playbooks.md) to decide the next best question.
+- Calibrate depth before deepening: choose quick capture, guided formulation,
+  review-first, or action-first. For quick capture, use the user's supplied wording,
+  ask only the one structural, accuracy, or consent detail that changes the write, and
+  do not force full exploration. For guided formulation, use active listening and
+  Psyche hypotheses when the user is trying to understand or name charged material.
+  For review-first, read before write-shaped questions. For action-first, act or ask
+  only for the missing target, span, weekday, flow, run, node, correction, or consent.
 - Ask only for what is missing or unclear. Do not walk through every schema field.
 - Before asking another question, run the playbook's minimum save-readiness
   checkpoint: if accepted wording, meaningful body, route lane, target object or
   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.
+- Run the no-question gate before every follow-up: ask only if the answer can change
+  record type, accepted wording, hierarchy placement, owner/accountability, timing,
+  route lane, target object, correction, link, verification read, run/publish/preserve
+  action, or consent. If the question would only add warmth, completeness, optional
+  metadata, or form polish, skip it, summarize what is clear, and act or close.
 - 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
@@ -276,8 +301,14 @@ Entity conversation rule:
   most directly supported by what was learned and ask only for the missing detail
   that would permit that action. Do not hand the user a broad menu after the read has
   already narrowed the work.
+- Make the read's decision value explicit before any follow-up: what the read rules
+  in, what it rules out, and what one uncertainty remains. If no answer-changing
+  uncertainty remains, close cleanly instead of asking another question.
 - 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.
+- Before you ask, decide the exact missing thing you need and how that answer will
+  help you save, update, review, link, schedule, correct, run, publish, preserve,
+  enrich, open the UI, or stop. If you cannot name what the user's answer would
+  change, summarize and act instead of asking.
 - Prefer a progression of:
   concrete example or intent -> working name -> purpose or meaning -> placement in Forge -> operational details -> linked context.
 - Use those same playbooks for action-heavy non-Psyche flows such as `work_adjustment`, `preference_judgment`, `preference_signal`, and specialized `movement`, `life_force`, or `workbench` requests so the conversation starts from what the user is trying to understand, change, add, update, link, or run before you choose the route.
@@ -292,6 +323,14 @@ Entity conversation rule:
 - When the operation is not already explicit, identify the job first:
   add, update, review, compare, navigate, link, or run. Skip that meta question
   when the action is already obvious from the user's wording.
+- Keep the operation lane explicit across every entity family. Normal stored entities
+  can be added, updated, reviewed/navigated, linked, or placed; action workflows use
+  verbs such as start, continue, complete, adjust, judge, signal, publish, sync, or
+  observe; specialized CRUD uses lifecycle verbs; read models need a practical read
+  question and scope; Movement, Life Force, and Workbench use review, correct,
+  repair, run, inspect, publish, or preserve lanes through their dedicated route keys;
+  and Psyche entities need formulation before storage when the user wants
+  understanding rather than direct save.
 - For emotionally meaningful non-Psyche records such as goals, habits, and notes, reflect the meaning before you ask for structure.
 - When the user is vague, ask for one small concrete example, stake, or desired outcome before you ask them to name the record.
 - When the user is clear, say what the record seems to be becoming and ask only for the last missing detail.
@@ -347,6 +386,10 @@ Psyche interview rule:
 - Do not minimize functional analysis, trigger chains, behavior patterns, modes, beliefs, or schema themes. Once at least one concrete example is clear, offer one careful interpretive hypothesis when it would help the user understand the function, protection, cost, belief, mode, or schema theme.
 - Phrase interpretive hypotheses as collaborative and testable, not as verdicts. A good hypothesis says what the reaction may be protecting, predicting, relieving, or costing, then asks whether that lands or needs correction.
 - For Psyche hypotheses, reduce the formulation burden. After one concrete example, offer one tentative function, danger, protection, payoff, or cost hypothesis and ask one fit-or-correction question. Do not make the user prove the experience, list evidence, or design repair before the wording feels held.
+- Use the Psyche hypothesis examples when one concrete episode, belief sentence,
+  behavior, or mode voice is visible and another broad question would make the user do
+  all the interpretation alone. Offer one testable formulation, ask one correction
+  question, and then bridge to the saveable record if it lands.
 - Do not keep asking broad exploratory Psyche questions after the cue, meaning, protection, payoff, or cost is already visible. For `behavior_pattern`, `belief_entry`, `mode_profile`, `mode_guide_session`, and `trigger_report`, the next helpful move is usually one active formulation plus one correction question, not another passive reflection.
 - Do not leave the user with interpretation alone. Once the hypothesis lands or is
   corrected, name the primary Forge record it becomes and ask one accuracy or consent
@@ -374,6 +417,9 @@ Psyche interview rule:
   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.
+- For direct Psyche saves, do not reopen origin, evidence, or repair when the user
+  already supplied usable wording and asked to save it. Reflect the wording, ask one
+  accuracy or consent question, and save when accepted.
 - 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.
@@ -438,7 +484,7 @@ Use these exact entity meanings when deciding what the user is describing.
 
 `flashcard` is a small therapeutic reminder card. Use it when the user wants a sentence or short message that can be shown back during an urge, trigger, mode activation, belief activation, or values-based pivot. The message is the main content; title is optional and compact. Tags, trigger sentence, trigger situation, and Psyche links matter most for retrieval. Styling fields such as colors, typography, layout, visual tone, and image make the card easier to recognize but should come after the therapeutic sentence is clear.
 
-When a user says something like "I feel the urge to drink" or "help me not do this", search existing `flashcard` records first with `forge_search_entities` using `entityTypes: ["flashcard"]` and the user's urge, trigger words, tags, and situation language. If a matching card exists, show the flashcard message first, then add brief psychotherapy-informed support around it: grounding, urge surfing, cognitive defusion, schema/mode-aware reflection, or a values pivot. Do not create a new card until you have checked whether an existing one already fits.
+When a user says something like "I feel the urge to drink" or "help me not do this", search existing `flashcard` records first with `forge_search_entities` using `entityTypes: ["flashcard"]` and the user's urge, trigger words, tags, and situation language. If a matching card exists, show the flashcard message first, then add brief psychotherapy-informed support around it: grounding, urge surfing, cognitive defusion, schema/mode-aware reflection, or a values pivot. If no card fits and the user wants one, create only after the cue or urge sentence and the short message are clear; postpone visual style, colors, tags, and optional links until the intervention sentence works.
 
 `trigger_report` is one specific emotionally meaningful episode described as what happened, what was felt, what was thought, what was done, what happened next, and what would help next time.
 

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -110,6 +110,29 @@ 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.
 
+## Depth calibration
+
+Use this before choosing how much to ask. The goal is to match the user's actual job,
+not to make every entity feel equally deep.
+
+- Quick capture: the user already gave usable wording and says "save this", "remember
+  this", "log this", or otherwise makes storage the job. Reflect the working shape
+  once, ask only the one structural, accuracy, or consent detail that changes the
+  write, and do not force a full exploration.
+- Guided formulation: the user wants to understand, name, map, decide, or work
+  through unclear or charged material. Use active listening, one lane at a time, and
+  Psyche hypotheses when appropriate before saving.
+- Review-first: the user wants to inspect, compare, navigate, or understand something
+  already in Forge. Read the relevant stored entity, overview, or specialized surface
+  before asking write-shaped questions.
+- Action-first: the target task run, work adjustment, preference judgment or signal,
+  questionnaire run, Movement correction, Life Force signal/template, or Workbench
+  run/output is already clear. Act, or ask only for the missing target, span, weekday,
+  flow, run, node, correction, or consent.
+- Do not downgrade psychologically meaningful material into quick capture when the
+  user is asking to understand it. Do not expand a simple storage request into therapy
+  or project planning when a concise save is enough.
+
 ## Plain-language rule
 
 Keep API and architecture nouns inside your own reasoning. Do not ask the user about
@@ -160,6 +183,50 @@ 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 route fallback
+
+Use this when the adapter tool surface is missing, stale, or narrower than live Forge
+onboarding.
+
+- First prefer the route-key tools when they exist:
+  `forge_call_movement_route`, `forge_call_life_force_route`, or
+  `forge_call_workbench_route`.
+- If a route-key tool is unavailable, stale, or lacks the needed route key, read live
+  onboarding and use the exact `methodRoutes` entry for the selected lane. Cross-check
+  OpenAPI only to confirm the same method and path.
+- Do not fall back to generic batch CRUD for Movement, Life Force, or Workbench just
+  because a route-key tool is missing. They remain specialized domain surfaces.
+- Do not invent a nearby raw path, put IDs into the route key, or ask the user to pick
+  an endpoint. Ask only for the missing product identifier or span that fills the
+  published path.
+- Before calling a specialized route, check the selected `methodRoutes` entry for
+  placeholders such as `:id`, `:weekday`, `:slug`, `:runId`, `:nodeId`, or
+  `:pointId`. Every placeholder must be filled through `pathParams` with the same
+  name before the call; never hide one inside `query`, `body`, or `routeKey`.
+- If a required placeholder is missing, ask for the product noun that fills it: the
+  saved place, movement box, trip, weekday, flow, slug, run, node, or trip point.
+- If tool schema, live onboarding, and OpenAPI disagree, trust live onboarding for the
+  immediate call when it names the exact route, then treat the disagreement as a Forge
+  contract bug to fix.
+
+## Specialized route-contract handshake
+
+Use this before every Movement, Life Force, or Workbench call so the route path is
+truthful without turning the user's turn into implementation talk.
+
+- Select the product lane first in plain language: movement span or repair, energy
+  assumption or signal, saved flow/run/node/output, or published artifact.
+- Then verify the matching `routeKey` against live onboarding `routeKeys` and
+  `methodRoutes`. The route key and method/path must come from that contract, not from
+  memory or a guessed URL.
+- If `methodRoutes` contains placeholders, fill every placeholder through
+  `pathParams` with the exact placeholder name before the call. Ask the user only for
+  the missing product noun that fills the placeholder.
+- Cross-check OpenAPI when you are debugging or when a route-key tool looks stale; do
+  not make the user choose between endpoint names.
+- If the contract is missing a lane the product clearly supports, stop and report a
+  contract bug instead of silently using generic batch CRUD or a nearby route.
+
 ## Dedicated surface verification loop
 
 Use this after a Movement, Life Force, or Workbench mutation or result-producing run.
@@ -226,6 +293,9 @@ worked.
   answers the user's practical question and ask only for the missing detail that would
   permit that action. Do not hand the user a broad menu after you just learned enough
   to narrow the next move.
+- Make the read's decision value explicit before any follow-up: what the read rules
+  in, what it rules out, and what one uncertainty remains. If there is no
+  answer-changing uncertainty, do not ask another question.
 - For Movement, Life Force, Workbench, calendar, health, and operator overviews,
   keep the follow-up anchored to the read result: the span that is missing, the
   weekday curve that needs correction, the failed run or node, the overloaded day, or
@@ -483,6 +553,33 @@ Use this before you choose an API path or ask for more structure.
 - For Movement, Life Force, and Workbench, use the lane
   to choose the dedicated route family before you ask for lower-level details.
 
+## Operation coverage checkpoint
+
+Use this as a live handling and simulation check so every entity family is exercised
+as real work, not only as a create form.
+
+- Normal stored entities need four possible lanes in the agent's head: add a new
+  record, update an existing record, review or navigate existing records, and link or
+  place the record in Forge. Ask the lane only when the user's verb does not already
+  choose it.
+- Action workflows need action verbs instead of CRUD verbs: start, continue, complete,
+  adjust, judge, signal, publish, sync, or observe. Once the action verb is clear,
+  ask only for the missing target, answer, comparison, minutes, or consent.
+- Specialized CRUD surfaces need lifecycle verbs: create, read, update, sync,
+  reconnect, delete, or browse. For wiki pages, ask about the durable page or evidence
+  source; for calendar connections, ask about the provider workflow and lifecycle
+  action.
+- Read-model surfaces need a practical read question plus scope. Do not ask
+  write-shaped questions until the read creates a concrete follow-up.
+- Movement, Life Force, and Workbench need their dedicated operation lanes: review,
+  correct, repair, run, inspect, publish, or preserve. After the lane is clear, use
+  the exact dedicated route key internally and ask only for the span, place, weekday,
+  flow, run, node, output, correction, or preservation choice that is still missing.
+- Psyche entities need a formulation lane before the storage lane when the user wants
+  understanding. Direct saves can move to one accuracy or consent question; guided
+  formulation should stay with one lived example, one hypothesis when useful, and one
+  corrected saveable shape.
+
 ## Route posture checkpoint
 
 Use this quick split before the conversation gets too detailed.
@@ -666,9 +763,12 @@ of those things, stop asking, summarize the working record, and act with consent
 
 Do not drift into vague reflection or internal route language. Replace "that sounds
 important" with the specific stake you heard, and replace API words such as surface,
-CRUD, payload, mutation path, or endpoint with product nouns the user recognizes:
-belief, pattern, note, wiki page, timeline, overlay, weekday template, flow, run,
-node result, or published output.
+CRUD, payload, mutation path, route key, batch route, or endpoint with product nouns
+the user recognizes: belief, pattern, note, wiki page, timeline, overlay, missing
+stay, weekday template, flow, run, node result, or published output. If you cannot
+name the product noun yet, ask one grounding question about the real span, place,
+weekday, flow, run, node, belief sentence, parent record, or save confirmation
+instead of adding reflective filler.
 
 ## Steering moves
 
@@ -754,8 +854,10 @@ Use this quick internal check before every follow-up question.
    operational detail?
 3. Does it affect the API posture: batch CRUD, specialized CRUD, action workflow, or
    specialized domain route?
-4. What is the smallest question that would answer that unknown?
-5. If the user already gave enough to act, stop asking and move to a short summary or
+4. What concrete action would a possible answer enable: save, update, review, link,
+   schedule, correct, run, publish, preserve, or stop?
+5. What is the smallest question that would answer that unknown?
+6. If the user already gave enough to act, stop asking and move to a short summary or
    the write.
 
 Useful calibration heuristics:
@@ -772,6 +874,38 @@ Useful calibration heuristics:
   skip it.
 - If the next question would not change the API path, write shape, wording, timing, or
   useful links, skip it.
+- If you cannot say what the user's answer would change, do not ask the question.
+  Summarize what is already clear, take the read/write/run action, or close cleanly.
+- For review-first work, the follow-up must point to one action enabled by the read:
+  no change, save, update, correct, link, schedule, run, publish, preserve, enrich, or
+  open the UI. Do not ask a generic "what do you want to do with this?" after the read
+  already narrowed the practical next move.
+- For Movement, Life Force, and Workbench, the same rule applies through the product
+  object: missing span, place boundary, weekday curve, profile assumption, flow, run,
+  node, output, or preservation choice.
+
+## No-question gate
+
+Use this before every follow-up, especially after partial answers, reads, writes,
+repairs, and Psyche-adjacent material. A polished extra question is still a bad
+question when it cannot change the next action.
+
+- Ask only if the answer can change one of these: record type, accepted wording,
+  hierarchy placement, owner/accountability, timing, route lane, target object,
+  correction, link, verification read, run/publish/preserve action, or consent.
+- Do not ask for optional tags, colors, priority, assignees, dates, aliases, visual
+  style, or related links when the user already gave enough to save, read, run,
+  correct, or close.
+- If the next question would only make the conversation feel warmer, more complete, or
+  more like a form, skip it. Summarize what is clear and act, or close cleanly.
+- For review-first work, answer the practical question first. Ask another question
+  only when the read exposes an answer-changing uncertainty or a concrete action the
+  user has not yet authorized.
+- For specialized domains, do not ask a reflective "why" after the route lane and
+  target are already known; ask only for the span, place, weekday, flow, run, node,
+  output, correction, or preservation choice that permits the action.
+- For Psyche-adjacent work, do not keep exploring once the user has accepted a
+  formulation. Ask one accuracy or consent question, then save or stop.
 
 ## Abstract And Reusable Record Moves
 
@@ -2009,6 +2143,10 @@ Direct action rules:
 - Treat day, month, all-time, timeline, trip detail, and selection as internal read
   lanes. With the user, ask for the useful time window, place, selected span, stay, or
   trip instead of listing route choices.
+- For route keys with placeholders, identify the product object before calling:
+  `boxDetail`, `tripDetail`, `placeUpdate`, `userBoxUpdate`, `userBoxDelete`,
+  `automaticBoxInvalidate`, `stayUpdate`, `stayDelete`, `tripUpdate`, `tripDelete`,
+  `tripPointUpdate`, and `tripPointDelete` all need exact saved IDs in `pathParams`.
 - Treat settings as a separate movement lane for passive capture, publish mode, and
   retention behavior. Ask what operating behavior should change instead of routing it
   through a place, stay, or trip edit.
@@ -2157,6 +2295,8 @@ Direct action rules:
   `GET /api/v1/life-force`. Do not invent `/api/v1/life-force/overview`.
 - If the user is describing a durable baseline such as work capacity, recovery style,
   or action-point assumptions, patch the profile instead of logging a fatigue signal.
+- For the weekday-template route, fill `pathParams.weekday` from the real weekday name
+  or number before sending the update; do not bury the weekday only in the body.
 - If the user is describing a repeatable weekday rhythm, update that weekday template
   instead of treating it as a one-off right-now feeling.
 - If the user is describing how one weekday should usually feel, update that weekday
@@ -2261,6 +2401,11 @@ Direct action rules:
 
 - If the user needs the stable public contract of a flow, prefer the flow detail or
   published-output routes before a run-history read.
+- For Workbench route keys with placeholders, identify the saved flow, slug, run, and
+  node explicitly before calling. `flowDetail`, `flowById`, `flowBySlug`,
+  `publishedOutput`, `runHistory`, `runs`, `runDetail`, `runNodes`, `nodeResult`,
+  `latestNodeOutput`, `updateFlow`, `deleteFlow`, `runFlow`, and `chatFlow` all
+  depend on exact `pathParams`.
 - Treat saved-flow catalog, box catalog, run history, run detail, node result, latest
   node output, and published output as internal read lanes. With the user, ask whether
   they need the saved flow, its input contract, one run, one node, or the public