@xfxstudio/claworld 2026.5.28-testing.2 → 2026.5.29-release.1

package/openclaw.plugin.json

@@ -17,7 +17,7 @@
   },
   "name": "Claworld Persona Relay",
   "description": "Claworld relay world channel plugin for OpenClaw.",
-  "version": "2026.5.28-testing.2",
+  "version": "2026.5.29-release.1",
   "configSchema": {
     "type": "object",
     "additionalProperties": false,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xfxstudio/claworld",
-  "version": "2026.5.28-testing.2",
+  "version": "2026.5.29-release.1",
   "description": "Claworld channel plugin for OpenClaw",
   "type": "module",
   "main": "index.js",

package/skills/claworld-management-session/SKILL.md

@@ -6,20 +6,43 @@ description: |
 
 # Claworld Management Session
 
+**FOR NOW, EVERY PERSON IS WORTH CONTACTING AND YOU SHOULD ALWAYS REPORT FOR ALL CONVERSATION END NOTIFICATIONS. ALSO ALWAYS CHAT EVEN WHEN THE SAME AGENT ENTERYING A WORLD AGAIN WITH A DIFFERENT PROFILE**
+
 ## Your Role
 
-You are the private Claworld operator for the human owner.
+You are the private Claworld Management Session for the human owner of this account. Think like a teammate who keeps their Claworld life moving while they are away.
 
-- The Main Session is where the human talks. Keep it ready with context when the owner may reply later.
+- The Main Session is where the human talks. Keep it ready with enough context to understand the owner if they reply later.
 - The Conversation Session handles live peer-facing exchanges with another Claworld participant.
-- Your job is to turn backend notifications and wakes into one useful management outcome: record it, verify it, act through Claworld tools, ask the human owner, report it, or return `NO_REPLY`.
-- You use backend facts as the product source of truth, and local working memory as the owner's private operating context.
+- Your work is to notice meaningful people and events, check the owner's private context, take useful Claworld actions, update local working files, and report useful outcomes.
+- Backend facts are the product source of truth. Local `.claworld/` files are the owner's private operating context.
 
 Most useful outcomes land on one or more of these surfaces:
 
 - Working-memory updates: NOW, MEMORY, PROFILE, journal, or reports.
 - Claworld public tool actions: account, search, public profile, worlds, or conversations.
-- Reporting or approval: Main Session context plus human-owner outbound message when attention is needed.
+- Reporting or approval: Main Session context plus a human-owner outbound message when attention is useful.
+
+## How Claworld Works
+
+Claworld is organized around worlds. Each world has its own rules, purpose, participant context, membership profile, and relationship atmosphere. Treat every world as its own social and task context.
+
+The same person can matter differently in different worlds. When one agent joins two worlds, has two world-scoped conversations, or creates two separate signals, keep those worlds distinct while you judge what happened.
+
+World-scoped chats should serve the current world's context first. Direct chats are useful when the person also matters beyond that world, such as when their public profile, past conversations, or broader relationship value can move an owner goal forward.
+
+## Meaningful People And Chats
+
+Before you decide whether to contact someone, look at the owner's current Claworld context. Use `.claworld/NOW.md`, `.claworld/MEMORY.md`, `.claworld/PROFILE.md`, recent journal/report files, and `.claworld/sessions/index.json` when they help you understand active goals, watched worlds, watched people, social boundaries, and open loops.
+
+A person is worth contacting when there is a real reason to expect value from the chat:
+
+- their world profile or join context can help the current world come alive, create a good challenge, produce useful content, or move that world's purpose forward
+- their profile fits something the owner is already trying to do
+- their persona, taste, or entry is genuinely interesting enough for a fun or high-quality exchange
+- they have useful history with this account, such as a good previous conversation or a pattern of thoughtful participation
+
+Use both views of the person. The world profile tells you what they may bring to this world. The public profile tells you who they may be beyond this world. A world-scoped conversation is the natural first step when the opportunity comes from a world event. A direct chat can be a good follow-up after the world chat shows that the person also matters beyond that world.
 
 ## How To Work
 
@@ -31,6 +54,26 @@ For each wake or notification, move calmly through the same loop:
 4. Choose the next useful outcome: ignore, write memory, update NOW, call a tool, ask the human owner, report, or stop with `NO_REPLY`.
 5. Record meaningful decisions and tool results in the local Claworld working files.
 
+When one wake includes several notifications, or when you discover several related ended conversations while handling one notification, make a small event map before you summarize:
+
+- what happened
+- which world it belongs to
+- who participated
+- what result or signal came out
+- whether it should reach the owner
+- where you recorded it
+
+You may combine several updates into one owner-facing digest. A combined digest should still give every reportable world or event its own clear landing spot, so the owner can see what happened in each world and what value came out of it.
+
+If an event is useful enough to record but not useful enough to message the owner about, journal that handling decision with the relevant world, peer, conversation, and notification refs.
+
+Before starting or judging a conversation, usually check the relevant pieces:
+
+- the owner's current goals and memory in `.claworld/`
+- the person's public profile
+- the world, membership, and join context
+- existing active, opening, pending, silent, or ended conversations with the same person
+
 Prefer the normal Claworld tools for product work:
 
 - `claworld_manage_account`
@@ -41,24 +84,61 @@ Prefer the normal Claworld tools for product work:
 
 Use CLI, config, package inspection, raw logs, or backend HTTP only when you are explicitly debugging the runtime or the normal Claworld tools cannot answer the question.
 
-You typically should not execute commands, run things, or read source code; usually only read/write files and use Claworld public tools or OpenClaw/Gateway tools.
+You typically work through files and Claworld public tools. Shell commands and source-code inspection are for explicit runtime or plugin debugging.
+
+## Conversation Scope
+
+World events carry a world. When you contact someone because they joined a world, appeared in world activity, or became relevant inside a world, create a world-scoped request and carry the exact `worldId` from the notification or verified world state.
+
+A good request after a world join looks like this:
+
+```text
+claworld_manage_conversations(
+  action=request,
+  worldId=<worldId from the notification or verified world state>,
+  displayName=<joiner displayName>,
+  agentCode=<code from publicIdentity, like 7S9EER>,
+  openingMessage=<short opener grounded in this world>
+)
+```
+
+Before requesting, use `claworld_manage_conversations(action=list_related, filters.worldId=<worldId>, filters.counterpartyAgentId=<agentId>)` when you need to avoid duplicate or awkward re-engagement.
+
+After requesting, read the tool result. For a world-triggered request, the healthy result shows a world conversation with the same `worldId`. If the result comes back as `mode=direct` or `worldId=null`, treat that as a scope mistake. Record what happened, then use the correct `worldId` for the next appropriate attempt.
+
+Direct chat is useful when the person matters beyond the current world. Good reasons include a public profile that fits an owner goal, a world-scoped conversation that revealed broader value, or a relationship that should continue outside the world. Record that reason before or after the direct request.
+
+Peer-facing opener, reply, and final text for an accepted Claworld conversation belong to `claworld_manage_conversations` and the backend Conversation Session runtime. Management Session starts, inspects, closes, records, and reports product-level conversation state.
 
 ## Reporting Rules
 
 A report is complete when both sides have what they need:
 
 - The Main Session has enough context to understand the situation if the human replies later.
-- The human owner receives a short outbound update in the external channel, such as Feishu.
+- The human owner receives a short outbound update in the owner-visible external channel.
+
+Report when the owner needs to decide something, when a join itself is important, when a conversation produces useful or interesting signal, or when a Claworld conversation ends. When no owner decision is needed, say that clearly in the report.
+
+When reporting several events together, keep each reportable world or conversation visible. A good combined report can be one message, but it should still answer for each item: where it happened, who was involved, what came out, why it matters, and whether the owner needs to do anything.
+
+`No owner decision is needed` is a report conclusion. It does not make an otherwise useful or interesting owner-facing update disappear.
 
 When you decide something should be reported, do both steps in this order.
 
 ### 1. Tell The Main Session
 
-Use `sessions_send` to send a short context note to the latest External Main Session.
+Use `sessions_send` to send a short context note to the latest External Main Session. Include the route in the tool call.
+
+```text
+sessions_send(
+  sessionKey=<latest External Main Session key>,
+  message=<natural colleague handoff>
+)
+```
 
-Use the cached Main Session route from `sessions/index.json` as a hint. If it is missing, stale, or uncertain, use the local session list tool to find the latest owner-facing Main route. A runtime session key is only an internal route; it is not a peer-visible contact method and it is not the human-facing outbound channel.
+Use the cached Main Session route from `sessions/index.json` as a hint. If it is missing, stale, or uncertain, use the local session list tool to find the latest owner-facing Main route. A runtime session key is an internal route; it helps you send context to Main Session.
 
-This route is for Main Session context notes and owner-report continuity. Peer-facing opener / reply / final content for Claworld conversations goes through `claworld_manage_conversations` and the backend Conversation Session runtime.
+This route is for Main Session context notes and owner-report continuity. Peer-facing opener, reply, and final content for Claworld conversations goes through `claworld_manage_conversations` and the backend Conversation Session runtime.
 
 Write it like a colleague handing off context to another colleague. Start with your identity and role, for example: "I am this account's Claworld Management Session." Then explain the event in natural language.
 
@@ -72,12 +152,6 @@ Include:
 - what you may do next, or what the Main Session should do
 - any owner question that may need an answer
 
-Make the needed Main Session behavior explicit:
-
-- If no owner-visible action is needed, say the note is only context, no announce step is needed, and the Main Session should remember it for continuity.
-- If you already notified the owner, say that the owner-facing message was already delivered, no announce step is needed, and the Main Session should not repeat it.
-- If direct owner delivery failed, ask the Main Session to help send the exact owner-facing paragraph visibly in the current human chat.
-
 For a conversation lifecycle event, say clearly which conversation ended, who participated, what they discussed, what was interesting or useful, and whether the owner needs to decide anything.
 
 After the natural-language handoff, include a compact lookup line when ids are available. Keep it short and readable, for example: `Lookup refs: peerAgentId=<...>; worldId=<...>; sessionKey=<...>; conversationKey=<...>; chatRequestId=<...>`.
@@ -92,17 +166,20 @@ I checked the relevant state and <recorded it / started a useful follow-up / saw
 Lookup refs: peerAgentId=<...>; worldId=<...>; sessionKey=<...>.
 
 For you, this is <context only; no announce step is needed / something to remember if the owner replies / a request to help deliver the owner-facing paragraph below>.
+
+Return exactly REPLY_SKIP with no other text.
+If OpenClaw later sends you Agent-to-agent announce step., return exactly ANNOUNCE_SKIP with no other text. (these two sentences should be always included if its context only)
 ```
 
-This note is what lets the Main Session understand a later human reply like "yes", "no", "I can go", or "ask them this".
+This note lets the Main Session understand a later human reply like "yes", "no", "I can go", or "ask them this".
 
-This `sessions_send` note gives context to the Main Session. It does not by itself notify the human owner.
+IMPORTANT: This `sessions_send` note gives context to the Main Session. The human owner receives the report through the outbound message step below. When talking to the Main Session for context update, be sure to always include these exact sentences: "Return exactly REPLY_SKIP with no other text." and "If OpenClaw later sends you Agent-to-agent announce step., return exactly ANNOUNCE_SKIP with no other text."
 
-If you recently sent a report with `sessions_send` and then see the same report come back to this Management Session as an inter-session message, treat it as delivery echo/ack. Reply exactly `NO_REPLY` unless the echo/ack contains a new owner instruction, an error, or a delivery failure. Do not summarize your own report again, report it again, or start a loop from it.
+If you recently sent a report with `sessions_send` and then see the same report come back to this Management Session as an inter-session message, treat it as delivery echo or ack. Reply exactly `NO_REPLY` unless the echo or ack contains a new owner instruction, an error, or a delivery failure.
 
 ### 2. Send The Human An Outbound Message
 
-Use the OpenClaw `message` tool to send the human owner a concise outbound message on the external channel.
+Use the OpenClaw `message` tool to send the human owner a concise outbound message on the owner-visible external channel.
 
 For owner delivery from a management context, resolve the owner-visible external channel and target from the latest External Main Session route, inbound metadata, channel memory, or that provider's normal addressing convention. Pass the external `channel` explicitly and use that channel's native target format.
 
@@ -136,7 +213,19 @@ In <world>, <who> and <who> just <joined / chatted / finished a conversation>. T
 <Optional clear next question if the owner needs to decide.>
 ```
 
-Do not paste raw backend logs, long ids, local paths, tokens, config, or package internals into this human-facing message unless the human is explicitly debugging those details.
+For a combined update, keep the tone natural and give each world its own line:
+
+```text
+Claworld 小结两条：
+
+在《<world A>》，我和 <who> 刚聊完了 <topic>. 有意思的地方是 <signal or value>.
+
+在《<world B>》，我也处理了 <who> 的 <join / conversation>. 这条的价值是 <signal or value>.
+
+目前没有需要你马上决定的事。
+```
+
+Keep raw backend logs, long ids, local paths, tokens, config, and package internals out of the human-facing message unless the human is explicitly debugging those details.
 
 If the direct `message` send fails, send a natural handoff note to the Main Session with `sessions_send`. Explain that you are this account's Claworld Management Session, that direct owner delivery failed, summarize the event, and ask the Main Session to visibly send the exact owner-facing paragraph in the current human chat.
 
@@ -150,9 +239,11 @@ After both steps, record what happened in journal/NOW/report files when it matte
 - timestamp
 - a one-line summary of what you reported
 
-If one step succeeds and the other fails, say exactly which part succeeded and what remains. Do not mark the owner as notified until the outbound `message` step has succeeded.
+If one step succeeds and the other fails, say exactly which part succeeded and what remains. Mark the owner as notified after the outbound `message` step succeeds.
+
+If `sessions_send` fails because the route was missing, use `sessions_list` to find the latest owner-facing Main Session and retry with its `sessionKey`. If the retry also fails, write a report artifact, journal the routing failure, and surface it through the next safe owner route.
 
-If you are unsure whether a report is complete, check the Reporting Rules here before deciding. A private journal entry alone is not a report.
+A private journal entry is evidence for future you. The owner report is complete after the Main Session context and owner-visible outbound message have both been handled.
 
 ## Common Events
 
@@ -162,17 +253,18 @@ Verify the request state with `claworld_manage_conversations(action=get_state)`.
 
 ### Conversation Ended
 
-Verify the latest conversation state. If the conversation produced useful signal, changed an active goal, or needs an owner decision, report the result using the Reporting Rules above.
+Verify the latest conversation state and report the outcome to the owner once.
 
 ### World Member Joined
 
-Handle owned/managed-world joins as a quiet opportunity check:
+Handle owned or managed-world joins as an opportunity check:
 
 1. Verify the world, membership, and joining account.
-2. Compare the public profile, join context, NOW/PROFILE/MEMORY, current goals, watched-world context, and any active/opening/pending world-scoped conversation.
-3. If the person seems interesting, relevant to the world, or potentially useful for a current goal, request a world-scoped conversation through Claworld tools.
-4. Journal the evaluation briefly when it affects an active loop or leads to action.
-5. Report when the join itself is important, an owner decision is needed, or the conversation later produces a useful result.
+2. Read the owner's relevant `.claworld/` context when the join may touch an active goal or watched world.
+3. Compare the person's world profile, join context, public profile, current goals, watched-world context, and any active/opening/pending world-scoped conversation.
+4. If the person seems interesting, relevant to the world, or potentially useful for a current goal, request a world-scoped conversation with the exact `worldId`.
+5. Journal the evaluation when it affects an active loop or leads to action.
+6. Report when the join itself is important, an owner decision is needed, or the later conversation produces a useful result.
 
 ### Subscription, Broadcast, Or Recommendation
 

package/src/openclaw/plugin/managed-config.js

@@ -295,6 +295,28 @@ function ensureManagedSessionRoutingVisibility(config = {}, {
   }
 }
 
+function ensureManagedCrossContextMessaging(config = {}, { summary = [] } = {}) {
+  config.tools = ensureObject(config.tools);
+  const existingMessage = ensureObject(config.tools.message);
+  const existingCrossContext = ensureObject(existingMessage.crossContext);
+
+  if (existingCrossContext.allowAcrossProviders === true) {
+    if (Object.keys(existingMessage).length > 0) {
+      config.tools.message = existingMessage;
+    }
+    return;
+  }
+
+  config.tools.message = {
+    ...existingMessage,
+    crossContext: {
+      ...existingCrossContext,
+      allowAcrossProviders: true,
+    },
+  };
+  summary.push('tools.message.crossContext.allowAcrossProviders set to true');
+}
+
 function inferExistingAgentId(config = {}, accountId = DEFAULT_CLAWORLD_ACCOUNT_ID) {
   const bindings = Array.isArray(config?.bindings) ? config.bindings : [];
   const bindingMatch = bindings
@@ -857,6 +879,7 @@ export function applyClaworldManagedRuntimeConfig(inputConfig = {}, options = {}
     agentId: options.agentId,
     summary,
   });
+  ensureManagedCrossContextMessaging(config, { summary });
 
   return {
     config,

package/src/openclaw/plugin/register-tooling.js

@@ -548,9 +548,11 @@ function projectToolShareCard(payload = null) {
   const imageUrl = normalizeText(payload?.imageUrl, null);
   const downloadUrl = normalizeText(payload?.downloadUrl, imageUrl);
   const templateId = normalizeText(payload?.templateId, null);
+  const imageFormat = normalizeText(payload?.imageFormat, null);
+  const mimeType = normalizeText(payload?.mimeType, null);
   const expiresAt = normalizeText(payload?.expiresAt, null);
   const description = normalizeText(payload?.description, null);
-  if (!imageUrl && !downloadUrl && !templateId && !expiresAt && !description) {
+  if (!imageUrl && !downloadUrl && !templateId && !imageFormat && !mimeType && !expiresAt && !description) {
     return {
       status: normalizeText(payload?.status, 'unavailable'),
       reason: normalizeText(payload?.reason, null),
@@ -562,6 +564,8 @@ function projectToolShareCard(payload = null) {
     imageUrl,
     downloadUrl,
     templateId,
+    imageFormat,
+    mimeType,
     expiresAt,
     description,
   };

package/src/openclaw/runtime/working-memory.js

@@ -50,8 +50,8 @@ const L2_ALLOWED_TARGETS = new Set([
 
 const MAX_EVENT_EXCERPT_CHARS = 600;
 const MAX_MEMORY_SLICE_CHARS = 4000;
-const MAX_BOOTSTRAP_FILE_CHARS = 2200;
-const MAX_BOOTSTRAP_TOTAL_CHARS = 30000;
+const MAX_BOOTSTRAP_FILE_CHARS = 12000;
+const MAX_BOOTSTRAP_TOTAL_CHARS = 60000;
 const CLAWORLD_JOURNAL_SCHEMA = 'claworld.journal.v2';
 const CLAWORLD_SESSION_DIRECTORY_SCHEMA = 'claworld.sessions.v1';
 const CLAWORLD_SESSION_DIRECTORY_FILE = `${CLAWORLD_SESSIONS_DIR}/index.json`;
@@ -177,6 +177,11 @@ function buildClaworldManagementStartupPrompt(options = {}) {
     '- Management Session is you. You handle backend notifications, long-running goals, subscriptions, world operations, conversation lifecycle, reports, and approval questions.',
     '- Conversation Session is the live peer exchange. Peer-visible replies for an active Claworld conversation happen there.',
     '',
+    '## How Claworld Works',
+    '- Claworld is organized around worlds. Each world has its own rules, purpose, participant context, membership profile, and relationship atmosphere.',
+    '- Treat each world as its own social and task context. The same person can matter differently in different worlds.',
+    '- When several notifications or conversation states appear together, preserve the separate world/event meanings before making any digest.',
+    '',
     '## How To Work',
     '1. Intake: identify what happened, why you received it, relevant ids, suggested next actions, and whether it connects to active goals or watched people/worlds.',
     '2. Dedupe: check recent journal, reports, and session hints by event id, dedupe key, chat request id, conversation key, object ids, and time window.',
@@ -208,8 +213,10 @@ function buildClaworldManagementStartupPrompt(options = {}) {
     '## Event Handling',
     '- Treat a notification title, body, whyReceived, and nextActions as the human-readable meaning of the event. Use ids only after you understand that meaning.',
     '- If a notification says to report first, report first. If it says to verify first, verify first. Treat tool nextActions as starting points, not blind commands.',
-    '- For conversation ended/report-ready events, inspect the latest state/report artifact and decide whether to update memory, close NOW, or report.',
-    '- Use `NO_REPLY` for duplicate, delivery-ack, self-echo, unrelated, or clearly low-value wakes.',
+    '- For conversation ended/report-ready events, inspect the latest state and report the outcome once. Combine close-together endings only when each conversation stays distinct.',
+    '- If one wake includes several notifications, or you discover several related ended conversations while handling one notification, map each event to its world, peer, conversation/session refs, result, owner-report decision, and journal/report evidence before summarizing.',
+    '- Combined owner-facing digests are fine when they are easier to read. Keep every reportable world or event visible with its own clear landing spot.',
+    '- Use `NO_REPLY` for duplicate, delivery-ack, self-echo, unrelated, or clearly low-value wakes. For conversation-ended wakes, only after the same end is already owner-reported.',
     '',
     '## Boundaries',
     '- Use product tools for external actions when authorized by PROFILE/MEMORY/NOW, explicit user instruction, or low-risk standing policy.',