forge-openclaw-plugin 0.3.13 → 0.3.15

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" },
@@ -6152,9 +6156,10 @@ export function buildOpenApiDocument() {
                                     additionalProperties: false,
                                     properties: {
                                         text: { type: "string" },
-                                        imageDescription: { type: "string" },
-                                        loggedAt: { type: "string", format: "date-time" },
-                                        mealLabel: { type: "string" }
+                                        mealTime: { type: "string", format: "date-time" },
+                                        imageRefs: arrayOf({ type: "string" }),
+                                        connectionId: { type: "string" },
+                                        commitCandidate: { type: "boolean" }
                                     }
                                 }
                             }
@@ -6166,6 +6171,7 @@ export function buildOpenApiDocument() {
                             required: [
                                 "candidate",
                                 "log",
+                                "parseSummary",
                                 "clarificationQuestions",
                                 "uncertaintyReasons"
                             ],
@@ -6176,6 +6182,27 @@ export function buildOpenApiDocument() {
                                 log: nullable({
                                     $ref: "#/components/schemas/NutritionFoodLog"
                                 }),
+                                parseSummary: {
+                                    type: "object",
+                                    required: [
+                                        "itemCount",
+                                        "completeNutritionItemCount",
+                                        "catalogResolvedItemCount",
+                                        "chatGptEstimatedItemCount",
+                                        "chatGptValidatedItemCount",
+                                        "elapsedMs",
+                                        "llmCallCount"
+                                    ],
+                                    properties: {
+                                        itemCount: { type: "number" },
+                                        completeNutritionItemCount: { type: "number" },
+                                        catalogResolvedItemCount: { type: "number" },
+                                        chatGptEstimatedItemCount: { type: "number" },
+                                        chatGptValidatedItemCount: { type: "number" },
+                                        elapsedMs: { type: "number" },
+                                        llmCallCount: { type: "number" }
+                                    }
+                                },
                                 clarificationQuestions: arrayOf({ type: "string" }),
                                 uncertaintyReasons: arrayOf({ type: "string" })
                             }

package/dist/server/server/src/repositories/ai-connectors.js

@@ -778,7 +778,7 @@ async function runOpenAiConversationPrompt(input) {
             text: typeof input.profile.metadata.verbosity === "string"
                 ? { verbosity: input.profile.metadata.verbosity }
                 : undefined,
-            max_output_tokens: 1200
+            ...(isCodexProfile(input.profile) ? {} : { max_output_tokens: 1200 })
         })
     });
     if (!response.ok) {

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forge-openclaw-plugin",
-  "version": "0.3.13",
+  "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:
 
@@ -193,6 +206,15 @@ Wiki rule:
 - 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.
+- Ingestion policy for OpenClaw, Hermes, Codex, and Claude Code adapters:
+  - Before ingesting, call `forge_get_wiki_settings` so the agent knows the available spaces, LLM profiles, and embedding profiles. Prefer the shared wiki space for durable shared knowledge unless the current settings or user request clearly require another space.
+  - Use `forge_ingest_wiki_source` for raw text, local files, and URLs. Do not build an ad hoc importer or write raw source pages manually unless the Forge ingest tool is broken; if it is broken, fix the ingest path and tests before proceeding.
+  - Preserve source/evidence artifacts for audit, but do not make the wiki a transcript dump, movement log, release log, or repetitive check-in archive. Evidence supports knowledge; canonical wiki pages should be curated, readable, structured articles.
+  - Detect and propose durable pages for important people, organizations, projects, places, events, concepts, recurring relationship patterns, decisions, preferences, commitments, and timelines. A detected person or important concept should become or update a real wiki page, not disappear into one source note.
+  - Merge duplicates deliberately into one canonical page per real concept/person/project. Do not merely rename a page, hide a duplicate, or keep competing partial pages. Combine the durable information, preserve aliases and backlinks, and link the original evidence/source pages from the canonical page.
+  - Keep normal personal context when it is useful knowledge. Redact or omit actual secrets and security/payment credentials such as passwords, API keys, tokens, private auth links, card numbers, and similar material; do not over-redact ordinary names, relationships, work context, events, or preferences just because they are personal.
+  - After ingest or merge work, run `forge_sync_wiki_vault`, then use `forge_get_wiki_health`, search/list checks, and spot reads to verify created and updated pages, duplicate candidates, unresolved links, missing summaries, evidence links, and whether source material is reachable from canonical pages.
+  - Report what was created, updated, merged, left unresolved, and how evidence is preserved. If the user asked for reviewable candidates, hand off to the Forge UI ingest review instead of pretending the adapter can approve candidates inline.
 
 Wiki navigation and search rule:
 
@@ -249,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
@@ -263,8 +297,18 @@ Entity conversation rule:
 - Do not ask for optional tags, priority, status, dates, color, links, or assignees
   when accepted wording and meaningful body are enough unless that metadata changes
   accountability, retrieval, or execution.
+- After a read returns data and several next actions are plausible, choose the one
+  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.
@@ -279,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.
@@ -334,7 +386,14 @@ 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
+  question that moves toward saving the corrected formulation.
 - 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 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.
 - If several Psyche containers are plausible, do not ask the user to choose from a taxonomy menu first. Reflect the lived difference, offer one careful hypothesis when a concrete example is visible, then distinguish the options in plain language: one episode as a `trigger_report`, a recurring loop as a `behavior_pattern`, one repeated move as `behavior`, one sentence as `belief_entry`, a part-state as `mode_profile` or `mode_guide_session`, or reusable future-labeling as `event_type` or `emotion_definition`.
 - For Psyche updates, start with what feels newly true, newly visible, or newly inaccurate, then ask what should stay true before changing the formulation.
@@ -358,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.
@@ -422,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.
 
@@ -660,6 +722,12 @@ through `forge_create_entities` or `forge_update_entities`.
 - If you are unsure which specialized route family applies, check `forge_get_agent_onboarding` and use its `entityRouteModel.specializedDomainSurfaces` section before guessing.
 - If the truth of the current Movement, Life Force, or Workbench state is still unclear, prefer the dedicated read before the mutation so the correction stays truthful.
 - After a concrete Movement, Life Force, or Workbench correction, mutation, or result-producing run, read the relevant specialized view back when the user is trying to understand the result rather than only store it: timeline or place/settings detail for Movement, the Life Force overview for energy-planning impact, and flow detail, run detail, node result, latest node output, published output, or run history for Workbench.
+- After any dedicated Movement, Life Force, or Workbench 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.
 
 Use live work tools for `task_run`:
 `forge_log_work`, `forge_start_task_run`, `forge_heartbeat_task_run`, `forge_focus_task_run`, `forge_complete_task_run`, `forge_release_task_run`

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -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.
@@ -222,6 +289,13 @@ worked.
 - Ask a follow-up only if it changes the next action: save, update, correct, link,
   schedule, run, publish, enrich, or open the UI. If the read already answers the
   question, close cleanly instead of asking a ceremonial "what next?"
+- If the read produces several possible actions, choose the one that most directly
+  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
@@ -479,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.
@@ -662,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
 
@@ -750,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:
@@ -768,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
 
@@ -2005,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.
@@ -2023,6 +2165,10 @@ Direct action rules:
   object.
 - If the user is asking where they were during one uncertain window, prefer a timeline
   read before you create a correction. Mutate only after the lived truth is clear.
+- After a Movement read, translate the returned data into one next action: no change,
+  a manual overlay, a place boundary correction, a settings change, or a linked note.
+  Ask only for the missing span, place, boundary, or confirmation that enables that
+  action.
 - When the user has already given the real answer, for example "I stayed home during
   that missing block", do not ask a broad review question again. Confirm only the
   interval or place if that is still ambiguous, then act.
@@ -2149,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
@@ -2167,6 +2315,10 @@ Direct action rules:
 - After a fatigue signal, profile patch, or weekday-template edit, verify through the
   Life Force overview when the next planning decision depends on the updated energy
   picture.
+- After a Life Force overview, translate the read into one planning implication before
+  asking for a write: lighter workload, added recovery, protected timebox, meeting
+  change, task-choice change, or no change. Ask for a profile, template, or signal
+  detail only when that implication requires a mutation.
 
 Ready to act when:
 
@@ -2249,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
@@ -2273,6 +2430,11 @@ Direct action rules:
 - If the user wants to understand what inputs a flow can accept before editing or
   running it, read the box catalog or flow detail before asking for structured
   input details.
+- After a Workbench read, translate the returned artifact into one next action:
+  rerun with clearer input, inspect a specific node, edit the saved flow, publish or
+  preserve the output, or stop because the answer is already sufficient. Ask only for
+  the missing input, node, run, preservation choice, or confirmation that would change
+  that action.
 - For new flows, ask what the flow should reliably produce, what input contract it
   should accept, and what first node or box should anchor it. Do not start by asking
   for raw JSON.