forge-openclaw-plugin 0.2.60 → 0.2.65

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -18,6 +18,12 @@ Forge correctly, and gather only the structure that still matters.
 - The first question should usually clarify whether the user is trying to understand,
   preserve, decide, schedule, or change something, not just which field or provider
   they want.
+- Before asking, decide the API posture internally: shared batch entity route,
+  specialized CRUD surface, action workflow, or specialized domain route. If that
+  posture is unclear, ask the one user-facing question that will choose it.
+- Do not let API uncertainty leak out as vague wording. With the user, ask about the
+  real thing: the time window, flow, run, feeling, boundary, owner, or decision that
+  would change the action.
 - First identify the user's job when the lane is not already explicit:
   are they trying to add, update, review, compare, navigate, link, or run something?
 - Before every question, decide the one missing thing you are trying to clarify.
@@ -27,6 +33,9 @@ Forge correctly, and gather only the structure that still matters.
 - Prefer one clean question to a stacked sentence with several asks.
 - Reflect briefly when the user gives meaning, ambivalence, or emotionally loaded
   context that matters to the record.
+- Avoid generic reflections such as "that sounds important" unless you name what is
+  important in plain language. A useful reflection should make the next question feel
+  earned.
 - Especially for goals, habits, notes, and updates, reflect what the user is trying to
   preserve, change, or make true before you ask for structure.
 - For emotionally meaningful non-Psyche records such as goals, habits, notes, and many
@@ -105,6 +114,24 @@ With the user, say the human thing:
 The API path still matters, but it should not leak into the question unless the user
 is explicitly asking about implementation.
 
+## Dedicated surface lane translation
+
+Use this when Movement, Life Force, or Workbench work needs a route choice. The route
+choice is an internal classification step, not a user-facing menu.
+
+- Translate "day, month, all-time, timeline, trip detail, or selection" into "which
+  time window or specific stay/trip should we look at?"
+- Translate "overview, profile, weekdayTemplate, or fatigueSignal" into "is this about
+  your current state, a durable assumption, a repeated weekday rhythm, or how you feel
+  right now?"
+- Translate "listFlows, boxCatalog, runDetail, nodeResult, latestNodeOutput, or
+  publishedOutput" into "do you need the saved flow, its inputs, one run, one node, or
+  the public result?"
+- If the user already gave the concrete object, time window, weekday, flow, run, or
+  node, skip the route menu entirely and ask only for the missing product detail.
+- Once the lane is selected, use the exact route key internally and do not invent a
+  friendlier path.
+
 ## Psyche and memory routing
 
 Self-observation is not the default container for psychological material. Use it only
@@ -200,6 +227,9 @@ Use this quick split before the conversation gets too detailed.
   `/api/v1/entities/search`, `/api/v1/entities/create`,
   `/api/v1/entities/update`, `/api/v1/entities/delete`, and
   `/api/v1/entities/restore`.
+- Every normal entity section below inherits that batch-route default unless its own
+  route note says otherwise. Do not invent one-off entity endpoints for ordinary
+  stored records.
 - `wiki_page` and `calendar_connection` are specialized CRUD areas. Use the wiki
   page routes and calendar connection setup or sync routes instead of pretending they
   are simple batch records.
@@ -207,6 +237,10 @@ Use this quick split before the conversation gets too detailed.
   `preference_signal`, and `self_observation` are action workflows. Start from what
   the user is trying to do, then use the dedicated action tool or note-backed write
   model.
+- `sleep_overview` and `sports_overview` are read-model-only surfaces. Use them when
+  the user wants to review nights, workouts, training load, recovery context, or
+  health patterns before deciding whether one stored `sleep_session` or
+  `workout_session` needs enrichment.
 - Movement, Life Force, and Workbench are specialized domain areas. Use their
   dedicated route families for timelines and overlays, energy profile/templates and
   fatigue signals, and Workbench flow execution or result artifacts. When available,
@@ -216,6 +250,65 @@ Use this quick split before the conversation gets too detailed.
 - Once the route posture is clear, keep the questioning focused on the missing detail
   that selects the route or payload. Do not ask route-neutral reflective questions
   after the action path is already obvious.
+- If the tool schema and live onboarding disagree about a specialized route key or
+  path, treat that as a contract mismatch to fix. Do not guess a nearby route.
+
+## Full Route Posture Matrix
+
+Use this as an internal checklist when simulating or handling an entity flow. Do not
+read this table to the user. It exists so the agent can ask natural questions while
+still knowing the exact write/read family before it acts.
+
+- `goal`, `project`, `strategy`, `task`, `habit`, `tag`, `note`, `insight`,
+  `calendar_event`, `work_block_template`, and `task_timebox`: normal stored Forge
+  entities. Search, create, update, delete, and restore through the shared batch
+  entity routes.
+- `preference_catalog`, `preference_catalog_item`, `preference_context`, and
+  `preference_item`: normal stored Preferences records. Use shared batch entity
+  routes for CRUD; switch to Preferences action routes only for judgments, signals,
+  game starts, merges, entity seeding, or explicit score overrides.
+- `questionnaire_instrument`: normal stored questionnaire CRUD for ordinary authoring
+  and edits. Use questionnaire action routes only for clone, draft, and publish
+  state.
+- `sleep_session` and `workout_session`: normal stored health records for ordinary
+  CRUD. Use health overview/read helpers for review and reflective update helpers only
+  when enriching one already-known record after review.
+- `psyche_value`, `behavior_pattern`, `behavior`, `belief_entry`, `mode_profile`,
+  `mode_guide_session`, `trigger_report`, `event_type`, and `emotion_definition`:
+  psychologically meaningful records, but normal stored entities for API purposes.
+  Search and mutate through shared batch entity routes after the formulation is clear.
+- `wiki_page`: specialized CRUD. Use wiki page/search/upsert routes so page rows,
+  backlinks, spaces, aliases, and metadata stay coherent.
+- `calendar_connection`: specialized CRUD. Use provider discovery, connection CRUD,
+  selected-calendar rediscovery, sync, and delete routes rather than batch entity
+  tools.
+- `task_run`: action workflow. Use task-run start, heartbeat, focus, complete, and
+  release routes; never treat status changes as proof of live work.
+- `work_adjustment`: action workflow. Use the signed work-adjustment route for real
+  minutes that happened outside a live run.
+- `preference_judgment` and `preference_signal`: action workflows. Use the dedicated
+  Preferences judgment and signal routes, not batch CRUD.
+- `questionnaire_run`: action workflow. Use questionnaire run start, read, update, and
+  complete routes.
+- `self_observation`: read-model and note-backed workflow. Read the self-observation
+  calendar, then create or update an observed `note` with `frontmatter.observedAt`
+  only when a lightweight episode observation is the right container.
+- `sleep_overview`: read-model-only health surface. Use the sleep overview route or
+  `forge_get_sleep_overview` when the user wants to review recent nights, regularity,
+  score, stages, or recovery patterns before deciding whether a specific
+  `sleep_session` needs reflective enrichment.
+- `sports_overview`: read-model-only health surface. Use the sports overview route or
+  `forge_get_sports_overview` when the user wants to review workouts, training load,
+  effort, type distribution, or recovery context before deciding whether a specific
+  `workout_session` needs reflective enrichment.
+- `movement`: specialized domain surface. Use the dedicated movement routes for day,
+  month, all-time, timeline, places, trip detail, selection aggregates, manual
+  overlays, and repair actions.
+- `life_force`: specialized domain surface. Use the dedicated Life Force routes for
+  overview, profile updates, weekday templates, and fatigue signals.
+- `workbench`: specialized domain surface. Use the dedicated Workbench routes for
+  flow catalog/detail, flow CRUD, execution, run history, published output, node
+  result, and latest-node-output work.
 
 ## Active-listening patterns
 
@@ -314,8 +407,8 @@ exists.
 - If the next answer would not change the route, wording, timing, links, or useful
   interpretation, stop asking and act.
 - Close cleanly:
-  once the user says the wording or route lands, summarize once and move to the read
-  or write.
+  once the user says the wording or next action lands, summarize once and move to the
+  read or write.
 
 When an adjacent record becomes visible:
 
@@ -344,8 +437,10 @@ Use this quick internal check before every follow-up question.
 1. What is the one thing still unknown?
 2. Does that unknown affect the entity shape, the wording, the placement, or the
    operational detail?
-3. What is the smallest question that would answer that unknown?
-4. If the user already gave enough to act, stop asking and move to a short summary or
+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
    the write.
 
 Useful calibration heuristics:
@@ -360,6 +455,8 @@ Useful calibration heuristics:
   once and then return to the one missing structural detail.
 - If the next question would only decorate the record and not change its usefulness,
   skip it.
+- If the next question would not change the API path, payload, wording, timing, or
+  useful links, skip it.
 
 ## Abstract And Reusable Record Moves
 
@@ -777,6 +874,8 @@ Routing rule:
   book or article, keep a concept, or build a reusable explanation, consider
   `wiki_page` before `note`. Use `note` for temporary evidence, work logs, or linked
   detail; use `wiki_page` for durable memory.
+- Use the wiki tools and `/api/v1/wiki/pages` family for page reads and writes. Do
+  not route `wiki_page` through batch entity CRUD.
 
 Ready to save when:
 
@@ -922,6 +1021,13 @@ Preferred opening question:
 
 - "Which task should I start?"
 
+Route note:
+
+- `task_run` is an action workflow. Start live work with `/api/v1/tasks/:id/runs`.
+  Use `/api/v1/task-runs/:id/heartbeat`, `/focus`, `/complete`, and `/release` for
+  the rest of the run lifecycle. Do not represent live work by only changing task
+  status.
+
 ## Work Adjustment
 
 Aim: correct tracked minutes truthfully without pretending a live run happened.
@@ -939,6 +1045,12 @@ Helpful follow-up lanes:
 - whether the adjustment is positive or negative
 - what truthful reason should stay attached to the correction
 
+Route note:
+
+- `work_adjustment` is an action workflow. Use the dedicated work-adjustment tool or
+  `/api/v1/work-adjustments` path after the target and signed minute correction are
+  clear. Do not create a fake task run or invent a standalone batch CRUD entity.
+
 Ready to act when:
 
 - the target task or project is clear
@@ -987,7 +1099,8 @@ Route note:
 
 - `self_observation` is note-backed. Read the calendar first, then create or update an
   observed `note` with `frontmatter.observedAt` instead of inventing a standalone CRUD
-  write.
+  write. The read path is `/api/v1/psyche/self-observation/calendar`; the stored
+  write is a linked `note` through the shared batch entity route.
 - Do not promote self-observation over functional analysis. If the user is describing
   a loop, use `behavior_pattern`; if they are describing one emotionally meaningful
   episode, use `trigger_report`; if a part-state is central, use `mode_guide_session`
@@ -1062,6 +1175,82 @@ Preferred opening question:
 
 - "What about this workout feels most worth remembering or connecting?"
 
+## Sleep Overview
+
+Aim: review sleep patterns before deciding whether one night needs a reflective update
+or a planning follow-up.
+
+Arc:
+
+1. Ask what the user wants to understand from the sleep picture: one night, a recent
+   trend, regularity, recovery, stages, or links to work and Psyche context.
+2. Read the sleep overview before asking the user to reconstruct metrics from memory.
+3. Reflect the practical question the user is trying to answer from the overview.
+4. Move to `sleep_session` enrichment only when one specific night needs context,
+   tags, notes, or links.
+
+Helpful follow-up lanes:
+
+- which night or date range matters
+- whether the question is recovery, regularity, stages, schedule drift, or links
+- what decision the sleep review should help with
+
+Route note:
+
+- `sleep_overview` is a read-model-only surface. Use `forge_get_sleep_overview` or
+  `/api/v1/health/sleep` for review. Do not create, update, or delete
+  `sleep_overview` through batch CRUD.
+- If the review reveals that one night needs reflective context, switch to the stored
+  `sleep_session` batch route or reflective update helper for that known session.
+
+Ready to review when:
+
+- the user's practical sleep question is clear
+- the relevant night or date range is clear enough
+
+Preferred opening question:
+
+- "What are you trying to understand from your sleep picture right now?"
+
+## Sports Overview
+
+Aim: review workout and training-load context before deciding whether one workout
+needs a reflective update or recovery follow-up.
+
+Arc:
+
+1. Ask what the user wants to understand from the sports picture: one workout, a
+   recent training trend, effort, volume, type mix, recovery, or links to mood and
+   goals.
+2. Read the sports overview before asking the user to reconstruct metrics from memory.
+3. Reflect the practical decision the review should support.
+4. Move to `workout_session` enrichment only when one specific workout needs context,
+   tags, notes, or links.
+
+Helpful follow-up lanes:
+
+- which workout or date range matters
+- whether the question is load, effort, activity type, recovery, mood, or links
+- what decision the sports review should help with
+
+Route note:
+
+- `sports_overview` is a read-model-only surface. Use `forge_get_sports_overview` or
+  `/api/v1/health/fitness` for review. Do not create, update, or delete
+  `sports_overview` through batch CRUD.
+- If the review reveals that one workout needs reflective context, switch to the
+  stored `workout_session` batch route or reflective update helper for that known
+  session.
+
+Ready to review when:
+
+- the user's practical training or recovery question is clear
+- the relevant workout or date range is clear enough
+
+Preferred opening question:
+
+- "What are you trying to understand from your workout picture right now?"
+
 ## Calendar Connection
 
 Aim: connect the right provider deliberately without turning setup into a credential
@@ -1076,13 +1265,29 @@ Arc:
    real use case.
 4. Ask only for the next provider-specific step that still matters, such as auth flow,
    label, or calendar selection.
-5. Move into the actual connection flow once the setup goal is clear.
+5. If the user is updating or removing an existing connection, ask which connection
+   and what exact lifecycle action they want before touching credentials or sync.
+6. Move into the actual connection flow once the setup goal is clear.
 
 Helpful follow-up lanes:
 
 - what calendar workflow the user wants to unlock
 - whether writable projection matters
 - whether the provider requires a local sign-in step instead of manual fields
+- whether this is new setup, rediscovery, selected-calendar update, sync, or removal
+
+Route note:
+
+- `calendar_connection` is a specialized CRUD surface, not a batch CRUD entity.
+- Use `GET /api/v1/calendar/connections` to read existing connections.
+- Use `POST /api/v1/calendar/discovery` for Apple or custom CalDAV discovery and
+  `GET /api/v1/calendar/macos-local/discovery` for calendars already configured on
+  this Mac.
+- Use `GET /api/v1/calendar/connections/:id/discovery` before changing selected
+  calendars on an existing connection.
+- Use `POST /api/v1/calendar/connections`, `PATCH /api/v1/calendar/connections/:id`,
+  `POST /api/v1/calendar/connections/:id/sync`, or
+  `DELETE /api/v1/calendar/connections/:id` for the connection lifecycle.
 
 Ready to act when:
 
@@ -1190,6 +1395,9 @@ Direct action rules:
 
 - If the user is clearly talking about a missing-data gap that should become a stay or
   trip, use a user-defined movement box.
+- 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.
 - Preflight with `/api/v1/movement/user-boxes/preflight` when overlap or exact timing
   is unclear, then create the overlay with `/api/v1/movement/user-boxes`.
 - Use `kind: "stay"` when the user stayed in one place and `kind: "trip"` when they
@@ -1301,6 +1509,15 @@ Lane-to-route map:
 
 Direct action rules:
 
+- In onboarding, this surface may be keyed as `lifeForce` and also as the entity-style
+  alias `life_force`. Treat both names as the same dedicated Life Force route family,
+  not as batch CRUD.
+- Treat overview, profile, weekday-template, and fatigue-signal lanes as internal
+  route choices. With the user, ask whether this is a current read, a durable
+  assumption, a repeated weekday rhythm, or a right-now state instead of reciting route
+  names.
+- The overview route key is `overview` and the concrete runtime path is
+  `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.
 - If the user is describing a repeatable weekday rhythm, update that weekday template
@@ -1381,6 +1598,13 @@ 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.
+- 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
+  result instead of listing route keys.
+- For flow catalog questions, use `GET /api/v1/workbench/flows`; for available box
+  inputs, use `GET /api/v1/workbench/catalog/boxes`. Do not blur those into one vague
+  "catalog" read when the user needs a runnable flow versus an input-box contract.
 - If the user wants to execute a known saved flow, use `/api/v1/workbench/flows/:id/run`.
 - If the user wants payload-first execution without depending on a saved flow id, use
   `/api/v1/workbench/run`.
@@ -1566,7 +1790,9 @@ Route note:
 
 - `questionnaire_instrument` is normal stored CRUD for ordinary create, update,
   delete, and search work. Use clone, draft, and publish action routes only when the
-  user is working with instrument version state.
+  user is working with instrument version state. Questionnaire action paths live under
+  `/api/v1/psyche/questionnaires`, including `/:id/clone`, `/:id/draft`, and
+  `/:id/publish`.
 
 Ready to act when:
 
@@ -1599,7 +1825,10 @@ Helpful follow-up lanes:
 Route note:
 
 - `questionnaire_run` is an action workflow. Use the questionnaire run start, read,
-  update, and complete routes instead of treating answers as generic batch CRUD.
+  update, and complete routes instead of treating answers as generic batch CRUD:
+  `/api/v1/psyche/questionnaires/:id/runs`,
+  `/api/v1/psyche/questionnaire-runs/:id`, and
+  `/api/v1/psyche/questionnaire-runs/:id/complete`.
 
 Ready to act when:
 
@@ -1612,26 +1841,38 @@ Preferred opening question:
 
 ## Event Type
 
-Aim: create a reusable incident category that will actually help future reports stay
-consistent.
+Aim: bridge into the Psyche playbook for a reusable incident category without
+flattening the lived episode into cold taxonomy. `event_type` is a Psyche taxonomy
+record: use the deeper Event Type guidance in `psyche_entity_playbooks.md` when the
+user is exploring meaning, and keep this section as the route and handoff reminder.
 
 Arc:
 
-1. Ask what kind of moment or incident this label should capture in lived terms.
-2. Reflect the repeated moment back in plain language before narrowing the wording.
-3. Ask how narrow or broad it should be.
-4. Ask what would count as inside versus outside the category if that boundary is
-   still fuzzy.
-5. Offer a concise label if the lived meaning is clearer than the wording.
-6. Ask for a short description only if the label could be ambiguous later.
+1. Ask what kind of emotionally meaningful moment keeps recurring and why naming it
+   consistently would help future trigger reports.
+2. Reflect the repeated moment back in plain language by naming the emotional or
+   relational stake before narrowing the wording.
+3. Ask for one recent example if the boundary is still abstract.
+4. Clarify what belongs inside this event type and what should stay outside it.
+5. Offer one concise candidate label once the repeated moment is clear.
+6. Link it to trigger reports, beliefs, patterns, modes, or emotion definitions only
+   after the category itself feels accurate.
 
 If the user already offered a candidate label, keep the wording provisional and ask
 what kinds of moments belong inside it before you ask whether the label is right.
 
+Route note:
+
+- `event_type` is psychologically meaningful but still uses shared batch CRUD for
+  storage. Search and mutate it through the shared entity routes after the lived
+  category, boundary, and wording are clear enough. Do not treat it as a generic tag
+  or route it through `self_observation`.
+
 Ready to save when:
 
-- the label is stable
-- the intended category is clear enough that future reports will use it consistently
+- the repeated moment is understandable in plain language
+- the boundary is clear enough for future reports to use consistently
+- the label feels accurate enough or has one candidate wording to confirm
 
 Preferred opening question:
 
@@ -1639,25 +1880,42 @@ Preferred opening question:
 
 ## Emotion Definition
 
-Aim: define one reusable emotion entry clearly enough that future reports stay precise.
+Aim: `emotion_definition` is a Psyche taxonomy record, so bridge into the Psyche
+playbook for a reusable emotion entry by its lived signature, not by a dictionary
+definition. Use the deeper Emotion Definition guidance in
+`psyche_entity_playbooks.md` when the user is exploring the feeling.
 
 Arc:
 
-1. Ask what this feeling is like in lived terms when the user says it.
-2. Reflect the felt signature back in plain language before you settle the label.
+1. Ask when this feeling was present recently and what made it recognizable.
+2. Reflect the felt signature back in plain language before asking for category or
+   label polish.
 3. Ask what distinguishes it from nearby emotions if that matters.
-4. Offer a concise label if the felt meaning is clearer than the wording.
-5. Ask for a short description only if later reports would benefit from it.
+4. Ask what the feeling tends to signal, protect, warn about, long for, or demand.
+5. Offer one concise definition in the user's language and invite correction.
+6. Link it to trigger reports, modes, beliefs, or patterns only after the definition
+   feels steady.
 
 Helpful follow-up lanes:
 
 - what tells the user this is that feeling and not a nearby one
+- body signal, urge, image, thought, or relational meaning that identifies it
 - what kind of moments this emotion name should be used for later
+- what the feeling usually warns about, longs for, protects, or demands
+
+Route note:
+
+- `emotion_definition` is psychologically meaningful but still uses shared batch CRUD
+  for storage. Search and mutate it through the shared entity routes after the felt
+  signature, boundary, and wording are clear enough. Do not treat it as a generic
+  dictionary item.
 
 Ready to save when:
 
 - the label is clear
-- the meaning is clear enough to reuse later
+- the felt signature is clear enough to recognize later
+- the boundary from nearby feelings is clear enough when it matters
+- the definition can be written in language the user recognizes
 
 Preferred opening question:
 

package/skills/forge-openclaw/psyche_entity_playbooks.md

@@ -188,6 +188,65 @@ material without a usable formulation.
   defending the formulation.
 - Do not use hypotheses as diagnosis, certainty, or replacement belief work. They are
   collaborative formulations that can be saved, revised, or discarded.
+- Hypotheses are not decorative reassurance. Use them when they help the user see a
+  function, prediction, protection, payoff, cost, or value conflict that their own
+  example already supports.
+- If a user is circling around a behavior pattern, mode, belief, or trigger report
+  after one concrete example is visible, offer one careful hypothesis and then one
+  question that tests or corrects it.
+- Do not make the user supply every interpretation alone. If the sequence is clear
+  enough, do the formulation work in plain language and invite correction.
+
+## Hypothesis To Record Bridge
+
+Once a hypothesis lands or is corrected, turn it into a saveable Forge shape instead
+of leaving it as warm reflective prose.
+
+- Name what the hypothesis is becoming: a belief sentence, functional loop, behavior,
+  mode, trigger report, value, event type, or emotion definition.
+- Translate the accepted hypothesis into the smallest useful record fields: title,
+  core sentence, cue, protection, payoff, cost, preferred response, fear, body signal,
+  or linked episode.
+- Ask one confirmation question about accuracy, not another broad exploration
+  question.
+- If the user corrects the hypothesis, revise the formulation once in their language
+  and then ask whether that corrected version is true enough to save.
+- If adjacent Psyche records became visible, mention them as optional links after the
+  primary record is stable. Do not switch containers midstream unless the user wants
+  that.
+- Save through shared batch entity routes only after the user accepts the working
+  wording or explicitly asks to save.
+
+## Psyche Hypothesis Map
+
+Use these shapes after at least one concrete example is clear. The hypothesis should
+help the user understand function, meaning, protection, cost, or connection. Keep it
+short, tentative, and correctable.
+
+- `psyche_value`: hypothesize about the longing or pain that makes the value alive
+  now, and what ordinary behavior would show movement toward it.
+- `behavior_pattern`: hypothesize about the cue, body/emotion shift, meaning,
+  behavior or urge, short-term payoff, long-term cost, and what a replacement response
+  would still need to protect.
+- `behavior`: hypothesize about the immediate problem the move solves, the cue or
+  urge that pulls it online, and whether it functions as away, committed, or recovery
+  behavior.
+- `belief_entry`: hypothesize about the rule, prediction, or self/other/world sentence
+  the moment seems to activate, then ask whether that wording lands.
+- `mode_profile`: hypothesize about the protective job, feared danger, burden, and
+  possible mode family only after the part's lived voice or posture is visible.
+- `mode_guide_session`: hypothesize about what the active part is trying to stop,
+  force, prevent, or secure right now while keeping candidate mode labels provisional.
+- `trigger_report`: hypothesize about the episode chain only after the situation,
+  felt stake, meaning, action, and consequence are at least partly visible.
+- `event_type`: hypothesize about the repeated emotional or relational stake that
+  makes future reports need the same category.
+- `emotion_definition`: hypothesize about the feeling's body signature, urge, warning,
+  protection, or longing, and what distinguishes it from nearby emotions.
+- schema themes: hypothesize through the concrete container that best fits the
+  material: belief sentence, recurring functional loop, active mode, one trigger
+  episode, or durable wiki explanation. Do not flatten schema work into a loose
+  self-observation.
 
 ## Therapeutic Direction Check
 
@@ -320,6 +379,29 @@ Do not ask the user to pick the container first. Reflect the active meaning in p
 language, ask for one recent moment or one belief sentence, then choose the record that
 will preserve the structure best.
 
+## Psyche API Posture
+
+Psyche records are psychologically meaningful, but they are still normal stored Forge
+entities for API purposes. Once the formulation is clear and the user has consented to
+save or update it, use the shared batch entity routes for `psyche_value`,
+`behavior_pattern`, `behavior`, `belief_entry`, `mode_profile`,
+`mode_guide_session`, `trigger_report`, `event_type`, and `emotion_definition`.
+
+Keep the route decision internal. With the user, keep talking about the lived moment,
+belief sentence, pattern, mode, value, report, event kind, or feeling signature.
+Do not ask them about batch CRUD, payloads, or route families.
+
+Use `forge_search_entities` before creating when a duplicate is plausible. Use
+`forge_create_entities` or `forge_update_entities` after the wording, record type,
+and useful links are clear enough. Preserve nuance in a linked `note` when the
+experience is richer than the normalized fields.
+
+Do not divert Psyche material into `self_observation` just because it started as an
+episode. Use `trigger_report` for one emotionally meaningful incident, use
+`behavior_pattern` for a recurring functional loop, use `belief_entry` for one
+explicit sentence, and use `mode_guide_session` or `mode_profile` when a part-state is
+central.
+
 ## Lane chooser
 
 After each real answer, choose the next best lane. Do not mix several lanes at once.