forge-openclaw-plugin 0.3.14 → 0.3.16

package/dist/server/{server → apps/api}/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.",
@@ -5265,7 +5268,7 @@ function buildAgentOnboardingPayload(request) {
                 ],
                 verifyCommands: [
                     `curl -s ${origin}/api/v1/health`,
-                    "openclaw plugins install --link --dangerously-force-unsafe-install ./projects/forge/openclaw-plugin",
+                    "openclaw plugins install --link --dangerously-force-unsafe-install ./projects/forge/plugins/openclaw",
                     "openclaw plugins inspect forge-openclaw-plugin --runtime",
                     "openclaw gateway restart",
                     "openclaw forge onboarding",
@@ -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 → apps/api}/src/connectors/box-registry.js

@@ -8,9 +8,9 @@ import { updateTask } from "../repositories/tasks.js";
 import { getOverviewContext } from "../services/context.js";
 import { searchEntities } from "../services/entity-crud.js";
 import { getWikiHealth, listWikiPages } from "../repositories/wiki-memory.js";
-import { executeCommonWorkbenchTool, mapWorkbenchTools } from "../../../src/lib/workbench/runtime.js";
-import { getWorkbenchNodeCatalog, getWorkbenchNodeDefinition } from "../../../src/lib/workbench/registry.js";
-import { normalizeWorkbenchPortDefinition } from "../../../src/lib/workbench/nodes.js";
+import { executeCommonWorkbenchTool, mapWorkbenchTools } from "../../../web/src/lib/workbench/runtime.js";
+import { getWorkbenchNodeCatalog, getWorkbenchNodeDefinition } from "../../../web/src/lib/workbench/registry.js";
+import { normalizeWorkbenchPortDefinition } from "../../../web/src/lib/workbench/nodes.js";
 function createSnapshotForConnectorOutput(boxId) {
     const outputId = boxId.replace(/^connector-output:/, "");
     const rows = getDatabase()

package/dist/server/{server → apps/api}/src/db.js

@@ -15,10 +15,29 @@ function dateOffsetIso(days) {
     date.setUTCDate(date.getUTCDate() + days);
     return date.toISOString().slice(0, 10);
 }
-const projectRoot = path.resolve(path.dirname(fileURLToPath(import.meta.url)), "..", "..");
-const migrationsDir = path.join(projectRoot, "server", "migrations");
-const monorepoForgeDataRoot = path.resolve(projectRoot, "..", "..", "data", "forge");
+const moduleDir = path.dirname(fileURLToPath(import.meta.url));
+const apiRoot = path.resolve(moduleDir, "..");
+const migrationsDir = path.join(apiRoot, "migrations");
 const userSharedForgeDataRoot = path.join(os.homedir(), ".forge");
+function findSourceProjectRoot(startDir) {
+    let current = path.resolve(startDir);
+    while (true) {
+        if (existsSync(path.join(current, "package.json")) &&
+            existsSync(path.join(current, "apps", "api", "migrations")) &&
+            existsSync(path.join(current, "apps", "web", "src"))) {
+            return current;
+        }
+        const parent = path.dirname(current);
+        if (parent === current) {
+            return null;
+        }
+        current = parent;
+    }
+}
+const sourceProjectRoot = findSourceProjectRoot(apiRoot);
+const monorepoForgeDataRoot = sourceProjectRoot
+    ? path.resolve(sourceProjectRoot, "..", "..", "data", "forge")
+    : null;
 function resolveCanonicalDataDir(root = dataRoot) {
     return path.resolve(root);
 }
@@ -72,7 +91,7 @@ export function resolveDefaultDataRoot(currentWorkingDir = process.cwd()) {
     // Inside the private monorepo, prefer the tracked shared Forge data root so
     // the local app, Hermes, OpenClaw, and repo-managed data all point at the
     // same state by default.
-    if (existsSync(monorepoForgeDataRoot)) {
+    if (monorepoForgeDataRoot && existsSync(monorepoForgeDataRoot)) {
         return monorepoForgeDataRoot;
     }
     return path.resolve(userSharedForgeDataRoot || currentWorkingDir);

package/dist/server/{server → apps/api}/src/health-weight-loss.js

@@ -4,7 +4,7 @@ import { getDatabase, runInTransaction } from "./db.js";
 import { getSettings } from "./repositories/settings.js";
 import { getDefaultUser, resolveUserForMutation } from "./repositories/users.js";
 import { readEncryptedSecret } from "./repositories/calendar.js";
-import { hallNiddkWeeklyRateKgToDailyEnergyAdjustment } from "../../src/lib/weight-loss-energy-model.js";
+import { hallNiddkWeeklyRateKgToDailyEnergyAdjustment } from "../../web/src/lib/weight-loss-energy-model.js";
 const ACTIVE_BASELINE_WINDOW_DAYS = 7;
 const optionalNumberSchema = z
     .union([z.coerce.number().finite(), z.null()])

package/dist/server/{server → apps/api}/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/dist/server/{server → apps/api}/src/questionnaire-seeds.js

@@ -649,7 +649,7 @@ const QUESTIONNAIRE_SEEDS = [
                 },
                 {
                     label: "WHO AUDIT manual PDF",
-                    url: "https://iris.who.int/server/api/core/bitstreams/c57d9855-5450-4c46-84b1-c88a6df4192c/content",
+                    url: "https://iris.who.int/apps/api/api/core/bitstreams/c57d9855-5450-4c46-84b1-c88a6df4192c/content",
                     citation: "World Health Organization. AUDIT manual and self-report questionnaire appendix.",
                     notes: "WHO manual permits free review, reproduction, and translation for non-commercial use."
                 }

package/dist/server/{server → apps/api}/src/repositories/ai-connectors.js

@@ -8,7 +8,7 @@ import { createAiConnectorSchema, aiConnectorConversationSchema, aiConnectorRunR
 import { FORGE_DEFAULT_AGENT_ID, getAiModelConnectionById, listAiModelConnections, readModelConnectionCredential } from "./model-settings.js";
 import { getAiProcessorById, listAiProcessorLinks, listAiProcessors } from "./ai-processors.js";
 import { buildConnectorOutputCatalogEntry, executeForgeBoxTool, resolveForgeBoxSnapshot } from "../connectors/box-registry.js";
-import { normalizeWorkbenchPortDefinition } from "../../../src/lib/workbench/nodes.js";
+import { normalizeWorkbenchPortDefinition } from "../../../web/src/lib/workbench/nodes.js";
 const execFile = promisify(execFileCallback);
 const MAX_TOOL_STEPS = 6;
 const MAX_RUN_HISTORY = 20;

package/dist/server/{server → apps/api}/src/repositories/habits.js

@@ -11,7 +11,7 @@ import { recordActivityEvent } from "./activity-events.js";
 import { filterDeletedEntities, filterDeletedIds, isEntityDeleted } from "./deleted-entities.js";
 import { recordHabitCheckInReward, reverseLatestHabitCheckInReward } from "./rewards.js";
 import { createHabitCheckInSchema, createHabitSchema, habitCheckInSchema, habitSchema, updateHabitSchema } from "../types.js";
-import { formatLocalDateKey } from "../../../src/lib/date-keys.js";
+import { formatLocalDateKey } from "../../../web/src/lib/date-keys.js";
 function todayKey(now = new Date()) {
     return formatLocalDateKey(now);
 }

package/dist/server/{server → apps/api}/src/services/companion-iroh.js

@@ -317,19 +317,22 @@ function candidateIrohBinaries() {
     const binaryName = process.platform === "win32" ? "forge-companion-iroh.exe" : "forge-companion-iroh";
     const platformKey = `${process.platform}-${process.arch}`;
     return candidateIrohAssetRoots().flatMap((root) => [
+        path.join(root, "packages", "companion-iroh", "target", "release", binaryName),
+        path.join(root, "packages", "companion-iroh", "target", "debug", binaryName),
         path.join(root, "companion-iroh", "target", "release", binaryName),
         path.join(root, "companion-iroh", "target", "debug", binaryName),
         path.join(root, "companion-iroh-src", "target", "release", binaryName),
         path.join(root, "companion-iroh-src", "target", "debug", binaryName),
         path.join(root, "dist", "companion-iroh-src", "target", "release", binaryName),
         path.join(root, "dist", "companion-iroh-src", "target", "debug", binaryName),
-        path.join(root, "openclaw-plugin", "dist", "companion-iroh", platformKey, binaryName),
+        path.join(root, "plugins/openclaw", "dist", "companion-iroh", platformKey, binaryName),
         path.join(root, "companion-iroh", platformKey, binaryName),
         path.join(root, "companion-iroh", binaryName)
     ]);
 }
 function resolveCompanionIrohManifestPath() {
     const candidates = candidateIrohAssetRoots().flatMap((root) => [
+        path.join(root, "packages", "companion-iroh", "Cargo.toml"),
         path.join(root, "companion-iroh", "Cargo.toml"),
         path.join(root, "companion-iroh-src", "Cargo.toml"),
         path.join(root, "dist", "companion-iroh-src", "Cargo.toml")

package/dist/server/{server → apps/api}/src/services/doctor.js

@@ -2,9 +2,9 @@ import { access, readdir } from "node:fs/promises";
 import path from "node:path";
 import { fileURLToPath } from "node:url";
 import { getDatabase, runInTransaction } from "../db.js";
-import { GAMIFICATION_CATALOG } from "../../../src/lib/gamification-catalog.js";
-const projectRoot = path.resolve(path.dirname(fileURLToPath(import.meta.url)), "..", "..", "..");
-const migrationsDir = path.join(projectRoot, "server", "migrations");
+import { GAMIFICATION_CATALOG } from "../../../web/src/lib/gamification-catalog.js";
+const apiRoot = path.resolve(path.dirname(fileURLToPath(import.meta.url)), "..", "..");
+const migrationsDir = path.join(apiRoot, "migrations");
 const safeIntegrityRefreshFix = {
     id: "settings.integrity.refresh",
     kind: "safe_auto_fix",

package/dist/server/{server → apps/api}/src/services/gamification-assets.js

@@ -5,7 +5,7 @@ import { access, mkdir, readFile, rm, writeFile } from "node:fs/promises";
 import path from "node:path";
 import AdmZip from "adm-zip";
 import { getEffectiveDataRoot } from "../db.js";
-import { GAMIFICATION_CATALOG, GAMIFICATION_MASCOT_KEYS } from "../../../src/lib/gamification-catalog.js";
+import { GAMIFICATION_CATALOG, GAMIFICATION_MASCOT_KEYS } from "../../../web/src/lib/gamification-catalog.js";
 const assetVersion = "0.2.59";
 const defaultReleaseBaseUrl = "https://github.com/albertbuchard/forge/releases/download/forge-gamification-assets-v0.2.59";
 const styleDefinitions = [

package/dist/server/{server → apps/api}/src/services/gamification.js

@@ -2,7 +2,7 @@ import { getDatabase } from "../db.js";
 import { enqueueGamificationCelebration, getGamificationEquipment, insertGamificationUnlock, listGamificationDailyActivity, listGamificationUnlocks, listUnseenGamificationCelebrations, replaceGamificationDailyActivity, upsertGamificationEquipment } from "../repositories/gamification.js";
 import { getDailyAmbientXp, listRewardRules, recordEntityCreationReward } from "../repositories/rewards.js";
 import { getDefaultUser, listUsers, listUsersByIds } from "../repositories/users.js";
-import { GAMIFICATION_CATALOG, GAMIFICATION_STREAK_AWAY_DAY_KEYS, GAMIFICATION_STREAK_POWER_DAY_KEYS } from "../../../src/lib/gamification-catalog.js";
+import { GAMIFICATION_CATALOG, GAMIFICATION_STREAK_AWAY_DAY_KEYS, GAMIFICATION_STREAK_POWER_DAY_KEYS } from "../../../web/src/lib/gamification-catalog.js";
 import { achievementSignalSchema, gamificationCatalogPayloadSchema, gamificationProfileSchema, milestoneRewardSchema } from "../types.js";
 const XP_CURVE_VERSION = "smith-forge";
 const ENTITY_CREATION_REWARD_SOURCES = [

package/dist/server/{server → apps/api}/src/services/knowledge-graph.js

@@ -12,9 +12,9 @@ import { listTasks } from "../repositories/tasks.js";
 import { listWikiSpaces } from "../repositories/wiki-memory.js";
 import { listProjectSummaries } from "./projects.js";
 import { listAiConnectors } from "../repositories/ai-connectors.js";
-import { buildKnowledgeGraphFacets, buildKnowledgeGraphFocusPayload, filterKnowledgeGraphData, selectKnowledgeGraphVisibleNodeIds } from "../../../src/lib/knowledge-graph.js";
-import { getEntityVisual } from "../../../src/lib/entity-visuals.js";
-import { KNOWLEDGE_GRAPH_RELATION_FAMILY_MAP, buildKnowledgeGraphFocusHref, buildKnowledgeGraphNodeId, getKnowledgeGraphEntityHref } from "../../../src/lib/knowledge-graph-types.js";
+import { buildKnowledgeGraphFacets, buildKnowledgeGraphFocusPayload, filterKnowledgeGraphData, selectKnowledgeGraphVisibleNodeIds } from "../../../web/src/lib/knowledge-graph.js";
+import { getEntityVisual } from "../../../web/src/lib/entity-visuals.js";
+import { KNOWLEDGE_GRAPH_RELATION_FAMILY_MAP, buildKnowledgeGraphFocusHref, buildKnowledgeGraphNodeId, getKnowledgeGraphEntityHref } from "../../../web/src/lib/knowledge-graph-types.js";
 const GRAPH_RANGE = {
     from: "2000-01-01T00:00:00.000Z",
     to: "2100-01-01T00:00:00.000Z"

package/dist/server/{server → apps/api}/src/types.js

@@ -1,6 +1,6 @@
 import { z } from "zod";
-import { LEGACY_WORKBENCH_PORT_KINDS, WORKBENCH_PORT_KINDS, normalizeWorkbenchPortKind } from "../../src/lib/workbench/nodes.js";
-import { formatLocalDateKey } from "../../src/lib/date-keys.js";
+import { LEGACY_WORKBENCH_PORT_KINDS, WORKBENCH_PORT_KINDS, normalizeWorkbenchPortKind } from "../../web/src/lib/workbench/nodes.js";
+import { formatLocalDateKey } from "../../web/src/lib/date-keys.js";
 export const taskStatusSchema = z.enum([
     "backlog",
     "focus",

package/dist/server/{server → apps/api}/src/watch-mobile.js

@@ -11,7 +11,7 @@ import { listProjectSummaries } from "./services/projects.js";
 import { listTasks, updateTask } from "./repositories/tasks.js";
 import { claimTaskRun, completeTaskRun, focusTaskRun, heartbeatTaskRun, listTaskRuns, releaseTaskRun } from "./repositories/task-runs.js";
 import { createTriggerReport, listBehaviorPatterns, listBehaviors, listEmotionDefinitions, listEventTypes, listModeProfiles, listPsycheValues, listTriggerReports } from "./repositories/psyche.js";
-import { formatLocalDateKey } from "../../src/lib/date-keys.js";
+import { formatLocalDateKey } from "../../web/src/lib/date-keys.js";
 const watchHistoryStateSchema = z.enum(["aligned", "unaligned", "unknown"]);
 const watchPromptKindSchema = z.enum([
     "new_place",

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.16",
   "activation": {
     "onStartup": true,
     "onCapabilities": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forge-openclaw-plugin",
-  "version": "0.3.14",
+  "version": "0.3.16",
   "description": "Curated OpenClaw adapter for the Forge collaboration API, UI entrypoint, and localhost auto-start runtime.",
   "type": "module",
   "license": "Apache-2.0",
@@ -8,9 +8,9 @@
   "repository": {
     "type": "git",
     "url": "git+https://github.com/albertbuchard/forge.git",
-    "directory": "openclaw-plugin"
+    "directory": "plugins/openclaw"
   },
-  "homepage": "https://github.com/albertbuchard/forge/tree/main/openclaw-plugin#readme",
+  "homepage": "https://github.com/albertbuchard/forge/tree/main/plugins/openclaw#readme",
   "bugs": {
     "url": "https://github.com/albertbuchard/forge/issues"
   },
@@ -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

@@ -4,10 +4,15 @@ import path from "node:path";
 import { fileURLToPath, pathToFileURL } from "node:url";
 
 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 repoRoot = path.resolve(packageRoot, "..", "..");
+const builtRuntimeEntry = path.join(packageRoot, "dist", "server", "apps", "api", "src", "index.js");
+const devRuntimeEntry = path.join(repoRoot, "apps", "api", "src", "index.ts");
+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";