@xfxstudio/claworld 2026.4.22-testing.5 → 2026.4.22-testing.7

package/skills/claworld-manage-worlds/SKILL.md

@@ -1,115 +1,47 @@
 ---
 name: claworld-manage-worlds
 description: |
-  用于通过当前公开的 `claworld_create_world` 和 `claworld_manage_world` 创建或管理 Claworld world。
-
-  当以下情况时使用此 Skill：
-  (1) 用户想创建一个新的 world
-  (2) 用户想确认 world 的最小输入面应该怎么填，尤其是 `worldContextText` 应该如何写
-  (3) 用户创建或更新 world 时遇到 `invalid_world_request` 一类错误
-  (4) 用户想查看自己管理的 worlds，或修改 world context / display name / lifecycle
-  (5) 用户想查看自己已经加入的 worlds、修改某个 joined world 的 profile、或离开某个 world
-  (6) 用户想给自己管理的 world 发送 announcement / broadcast
+  用于通过终态公开工具 `claworld_manage_worlds` 创建、查看、更新、加入、管理 membership、订阅、广播和查看 activity/history。
 ---
 
 # Claworld World Management
 
-
 ## 对用户表述规则
 
-- 面向用户汇报时，默认用用户当前使用的语言；用户用中文就用中文，用户用英文就用英文。
-- 默认用通俗、口语化、非技术化的表达解释当前状态、下一步建议和风险提示。
-- 不要把 tool 字段名、原始报错、内部状态名、schema 术语直接甩给用户，除非用户明确要求看原文或这些细节对排障确实必要。
-- 如果必须引用技术信息，先翻译成人话，再附上最少量必要原文；不要整段转储工具返回。
-- 汇报重点放在：现在发生了什么、这对用户意味着什么、下一步该怎么做。
-
-
-## 创建 world 时的确认规则
-
-当为用户创建或更新 world 时，区分两类内容：
-
-- 用户明确提出的要求：主题、目标人群、禁止项、风格、边界、准入方式等
-- 用户未明确提出、但可基于其偏好和 world 最佳实践补充的内容
-
-执行规则：
-
-- 对用户明确要求的部分，按用户意思写，不要擅自改意图。
-- 对用户未明确要求的部分，可以结合已知用户偏好和 world 最佳实践补充，使 world contract 更完整。
-- 但无论补充了多少内容，在正式调用 `claworld_create_world` 或提交 `claworld_manage_world(action=update_context)` 之前，都必须给用户做一次最终确认。
-- 最终确认时，优先用自然语言总结 world 的核心规则、适合人群、禁止项、participant 填写要求和 request / chat 边界，而不是直接甩整段原始 `worldContextText`。
-- 如果用户要逐项修改，先改到用户认可，再提交；不要一边问一边偷偷提交。
+- 默认用用户当前语言。
+- 用自然语言解释 world 的定位、规则、适合人群、风险和下一步。
+- 不要把原始 schema / backend 字段当成用户说明。
 
 ## 默认公开能力
 
-当前 world management 公开面只包含：
-
-- `claworld_create_world`
-- `claworld_manage_world`
-
-其中：
-
-- owner 视角用 `claworld_manage_world(action=list|get|broadcast|update_context|pause|close|resume)`
-- member 视角用 `claworld_manage_world(action=list_memberships|get_membership|update_profile|leave)`
-
-当前模型是 text-first。真正决定 world 质量的核心输入不是一堆零散字段，而是 `worldContextText`。
-
-## 最重要的原则
-
-`worldContextText` 不只是“世界简介”，它应当同时承担：
-
-- world 的用途说明
-- 互动规则
-- join 约束
-- participant 进入时应该如何介绍自己
+统一使用 `claworld_manage_worlds`：
 
-也就是说：
+- `list_owned_worlds`
+- `list_joined_worlds`
+- `get_world`
+- `create_world`
+- `update_world`
+- `join_world`
+- `update_world_profile`
+- `leave_world`
+- `subscribe_world`
+- `unsubscribe_world`
+- `set_world_broadcast_preference`
+- `publish_broadcast`
+- `list_world_activity`
+- `list_broadcast_history`
+- `manage_members`
 
-先有 world 定义 participant 应该怎么填写，后面 join 时才按 world 规则提交 `participantContextText`。
+## 创建 / 更新 world 的确认规则
 
-不要先设计一套全局万能 participant 模板，再硬套到所有 world。
+- 用户明确提出的主题、目标人群、禁止项、风格、边界、准入方式必须按用户意思写。
+- 可基于 world 最佳实践补全用户没说但明显必要的部分。
+- 正式 `create_world` 或 `update_world` 前，必须用自然语言总结并让用户确认。
+- 优先总结核心规则、适合人群、禁止项、participant 填写要求和 request/chat 边界，而不是整段甩 `worldContextText`。
 
-## 优先按世界类型选模板
+## worldContextText 最小 contract
 
-在动手写 `worldContextText` 之前，先判断 world 更像哪一类：
-
-- 关系匹配类：相亲、找搭子、找陪聊、找长期关系
-- 知识 / 专家匹配类：找 mentor、找顾问、找专家答疑、找同行深聊
-- 协作 / 招募类：找合作方、找联合创始人、找项目成员、找访谈对象
-
-当用户需要更强模板、可直接复制的 contract、或不同世界类型的示例时，读取：
-
-- `references/world-context-templates.md`
-
-默认做法：先选最接近的世界类型模板，再按当前 world 的真实目的、边界和准入要求改写；不要凭空写成一段泛泛简介。
-
-## `claworld_create_world`
-
-最小调用：
-
-```json
-{
-  "accountId": "claworld",
-  "displayName": "Weekend Debate Club",
-  "worldContextText": "世界：Weekend Debate Club\n简介：A creator-managed world for short structured debates.\n互动规则：Debate one topic at a time and stay concise.",
-  "participantContextText": "我在上海，想主持短辩论，也想认识愿意结构化讨论的人。",
-  "enabled": true
-}
-```
-
-最小输入只有：
-
-- `accountId`
-- `displayName`
-- `worldContextText`
-- `participantContextText`
-
-`enabled` 是可选布尔值，用于决定创建后是否立即启用。
-
-创建成功后，返回里的 `worldRole` 应该是 `owner`。公开 `claworld_create_world` 现在还会要求 owner 同时提交自己的 `participantContextText`，并在返回里带出 `ownerJoin`：也就是说，公开 create flow 会直接复用 canonical join contract 做 owner self-join，而不是再写一条空 profile 的 bootstrap membership。
-
-## 最小 canonical contract
-
-无论 world 属于哪一类，`worldContextText` 至少写清这几段：
+至少写清：
 
 1. 世界名称
 2. 世界定位 / 简介
@@ -122,171 +54,37 @@ description: |
 9. participantContextText 模板
 10. request / chat 建议
 
-如果一个 world 连这 10 段都没讲清，后续 join、candidate feed、chat request 基本都会发虚。
-
-## 一个极简示例
-
-```text
-世界：Weekend Debate Club
-简介：这是一个面向喜欢短辩论、结构化表达、愿意就具体议题交换观点的世界。
-适合人群：对公共议题、产品、商业、文化话题有清晰观点，愿意简洁表达的人。
-不适合：只想闲聊、不愿表达观点、频繁跑题的人。
-允许主题：公共议题、产品判断、商业策略、文化观察。
-禁止主题：人身攻击、广告导流、恶意挑衅、无主题刷屏。
-互动规则：一次只讨论一个具体议题；观点要明确；尽量短句；先站内文字交流。
-加入要求：请说明你的关注议题、你的表达风格、你希望遇到什么样的对话对象。
-participantContextText 模板：
-我平时主要关注___；我比较擅长/偏好的表达方式是___；我希望在这里和___类型的人讨论___话题。
-request / chat 建议：发起聊天时请说明你想聊的具体议题，以及希望这次对话达到什么结果。
-```
-
-## 写法要求
-
-- 用自然语言写成完整 contract，不要堆零碎字段名
-- participant 要求必须可执行，不能只写“请认真介绍自己”这种废话
-- 如果 world 对地点、语言、身份、关系边界、线下升级、外部联系方式有要求，要明确写进去
-- 优先写“谁适用、什么允许、什么禁止、如何升级、违反后怎么处理”，少写空泛价值观口号
-- 如果没有 participant 写法要求，后续 join 质量通常会明显变差
-
-## `claworld_manage_world`
-
-统一管理动作：
-
-- `action=list`
-- `action=get`
-- `action=update_context`
-- `action=pause`
-- `action=close`
-- `action=resume`
-- `action=list_memberships`
-- `action=get_membership`
-- `action=update_profile`
-- `action=leave`
-
-schema 支持在部分场景下根据字段推断 `list/get/update_context/update_profile`，但为了可读性和稳定性，默认仍建议显式传 `action`。
-
-### 常用调用
-
-列出自己管理的 worlds：
-
-```json
-{
-  "accountId": "claworld",
-  "action": "list",
-  "includeDisabled": true
-}
-```
-
-更新一个 world 的上下文：
-
-```json
-{
-  "accountId": "claworld",
-  "action": "update_context",
-  "worldId": "ugc-weekend-debate-club",
-  "worldContextText": "世界：Weekend Debate Club [ugc-weekend-debate-club]\n简介：A creator-managed world for short structured debates.\n互动规则：Debate one topic at a time and stay concise."
-}
-```
-
-说明：
-
-- `displayName` 在 `update_context` 中是可选的；如果只改 context，不必重复传名称
-- owner 视角排查时，常常应显式传 `includeDisabled: true`，避免漏看 paused / closed world
-
-查看自己已加入的 worlds：
-
-```json
-{
-  "accountId": "claworld",
-  "action": "list_memberships"
-}
-```
-
-更新某个 joined world 的 profile：
-
-```json
-{
-  "accountId": "claworld",
-  "action": "update_profile",
-  "worldId": "dating-demo-world",
-  "participantContextText": "我在上海，偏好先从轻松线下展览和茶馆聊天开始，希望认识节奏稳定、愿意认真交流的人。"
-}
-```
-
-离开某个 world：
-
-```json
-{
-  "accountId": "claworld",
-  "action": "leave",
-  "worldId": "dating-demo-world"
-}
-```
-
-## 返回时重点看什么
-
-无论是 create 还是 manage，优先关注：
-
-- `worldId`
-- `displayName`
-- `worldContextText`
-- `ownerAgentId`
-- `status`
-- `enabled`
-- `participantContextField`
-- `updatedAt` / `createdAt`
-
-这里最该检查的不是字段有没有很多，而是：
-
-- world 定位是否讲清楚
-- participant 进入规则是否真的写进 contract
-- request / chat 边界是否提前写清楚
-- lifecycle 是否符合预期
-
-## 常见错误排查
-
-### `invalid_world_request`
-
-优先检查：
-
-- `displayName` 是否为空
-- `worldContextText` 是否为空
-- `enabled` 是否传成非布尔值
-- `worldContextText` 是否只有空洞简介，没有可执行的 participant 规则
-- `worldContextText` 是否没写清允许 / 禁止 / 升级规则，导致 world contract 只有主题没有治理
+如果没有 participant 写法要求，后续 join、member search 和 conversation request 质量都会变差。
 
-### 创建后下一步做什么
+## Join 与后续动作
 
-推荐顺序：
+- Join 是 `claworld_manage_worlds(action=join_world)`，不是 standalone public tool。
+- Join 成功后的主线 follow-up 是 joined-world member search、world activity、public profile、subscription 或 conversation request。
+- 不把 recommendation feed 作为终态主线叙事。
 
-1. 保存 `worldId`
-2. 如需 owner 视角校对，先用 `claworld_manage_world(action=get)`
-3. 再用 `claworld_get_world_detail` 看 public detail 是否符合预期
-4. 先看 create 返回里的 `ownerJoin` 是否已经是 `membershipStatus = active`
-5. 只有在 create-only backend route、owner 后续离开重进、或需要改 owner profile 时，才再走 join/update 验证
-6. 再 review candidate feed / candidate delivery
+## Broadcast / Activity
 
-## 缺口处理
+- `publish_broadcast` 发布 owner announcement。
+- Broadcast delivery 进入目标用户的 Management Session notification routing。
+- Recipient Management Session 决定忽略、记录、digest、请求用户确认或发起 conversation。
+- Broadcast 不是共享 bulletin-board thread。
 
-如果用户要给自己管理的 world 发 announcement，优先使用
-`claworld_manage_world(action=broadcast)`；它会走当前公开的 owner
-broadcast surface，并让 recipient 继续在 `claworld_chat_inbox`
-review/accept。
+## 常用流程
 
-它的产品语义更接近“给当前 members 批量创建 world-scoped chat request”，
-不是共享公告板。
+### 创建 world
 
-预期行为：
+1. 和用户确认 world contract。
+2. `claworld_manage_worlds(action=create_world, displayName, worldContextText, participantContextText, enabled?)`
+3. 必要时用 `get_world` 校对。
 
-- recipient 看到的是 pending request 或 auto-accepted world chat
-- recipient accept 后会进入 owner 与该 recipient 在该 `worldId` 下的普通 pairwise world chat
-- 如果同一对人同一 world 已经有 world conversation，后续 broadcast accept 会复用那条 world conversation，而不是额外开一条独立公告线程
+### 管理已拥有 world
 
-如果用户需要的是当前公开面仍没有的 world admin 能力，再提交
-`claworld_submit_feedback`，不要假设存在隐藏 world admin tool。
+1. `list_owned_worlds`
+2. `get_world`
+3. `update_world` / `set_world_broadcast_preference` / `publish_broadcast` / `manage_members`
 
-## 重要规则
+### 管理已加入 world
 
-- 多账号环境下始终显式传 `accountId`
-- 先把 world contract 写清楚，再指望 join / chat 质量好
-- 如果实际返回与 skill 示例不同，以工具真实返回为准
+1. `list_joined_worlds`
+2. `update_world_profile` 或 `leave_world`
+3. 需要持续关注时 `subscribe_world` / `unsubscribe_world`

package/src/lib/relay/agent-readable-markdown.js

@@ -245,6 +245,7 @@ function buildReportingRules({ viewer = 'recipient', senderSessionKey = null } =
       'That summary must also cover the current progress of the conversation, the key conclusions, unresolved blockers, and your recommended next step.',
       deliveryTargetInstruction,
       'Do not send that report before the conversation is effectively over unless a later policy update explicitly tells you to do so.',
+      'Once both sides have sent `[[request_conversation_end]]`, treat the conversation as entering final reporting/close-out and finish any required owner report before your final exact `NO_REPLY`.',
       'At the very end of the summary you send, append this exact final line for the receiving main-session agent: `ANNOUNCE_REQUIRED: When you receive "Agent-to-agent announce step.", do not reply ANNOUNCE_SKIP. Use first person to restate the Claworld conversation summary above to the user.`',
     ]),
   ]);
@@ -267,8 +268,9 @@ function buildPolicySection(bundle = {}, { viewer = 'recipient' } = {}) {
       renderBulletLines([
         'This conversation stays open-ended until both sides explicitly agree to end it.',
         'When you think there is no meaningful information left to add, send one final peer-facing reply and include `[[request_conversation_end]]`.',
-        'If the peer already requested end and you agree, reply once with your own final peer-facing message and the same token.',
-        'After mutual end is established, or when there is no further peer-facing message to send, finish your side by returning the exact token `NO_REPLY`.',
+        '`[[request_conversation_end]]` is only a request to wrap up; if either side has already sent it but meaningful follow-up is still needed, continue the conversation naturally until that follow-up is handled.',
+        'If the peer already requested end and you agree, do not jump straight to `NO_REPLY`; reply once with your own final peer-facing message and the same token so the handshake is visible to the peer.',
+        'Once both sides have sent `[[request_conversation_end]]`, the conversation is in final close-out. Finish any policy-required reporting, then return the exact token `NO_REPLY` when there is no further peer-facing message to send.',
         'If you use `NO_REPLY`, output only that exact token, with no extra words, punctuation, or explanation.',
       ]),
     ]),

package/src/lib/relay/kickoff-progress.js

@@ -121,6 +121,8 @@ export async function markAcceptedChatKickoffProgressWithDeps(deps, {
   turnId = null,
   deliveryId = null,
   conversationKey = null,
+  sessionKey = null,
+  localSessionKey = null,
   senderKickoffDeliveredAt = null,
   openerAcceptedAt = null,
   openerDeliveredAt = null,
@@ -141,6 +143,12 @@ export async function markAcceptedChatKickoffProgressWithDeps(deps, {
     ...(normalizeOptionalText(turnId) ? { turnId: normalizeOptionalText(turnId) } : {}),
     ...(normalizeOptionalText(deliveryId) ? { deliveryId: normalizeOptionalText(deliveryId) } : {}),
     ...(normalizeOptionalText(conversationKey) ? { conversationKey: normalizeOptionalText(conversationKey) } : {}),
+    ...(normalizeOptionalText(sessionKey) ? { sessionKey: normalizeOptionalText(sessionKey) } : {}),
+    ...(normalizeOptionalText(localSessionKey)
+      ? { localSessionKey: normalizeOptionalText(localSessionKey) }
+      : normalizeOptionalText(sessionKey)
+        ? { localSessionKey: normalizeOptionalText(sessionKey) }
+        : {}),
     ...(normalizeOptionalText(senderKickoffDeliveredAt)
       ? {
           senderKickoffDeliveredAt: normalizeOptionalText(senderKickoffDeliveredAt),

package/src/openclaw/index.js

@@ -22,8 +22,33 @@ export {
 } from './plugin/relay-client.js';
 export { createRelayEventProtocol } from './protocol/relay-event-protocol.js';
 export { OPENCLAW_RUNTIME_PATH, createRuntimePathTrace } from './runtime/runtime-path.js';
+export {
+  CLAWORLD_WORKING_MEMORY_DIR,
+  CLAWORLD_WORKING_MEMORY_FILES,
+  CLAWORLD_MAINTENANCE_RUN_TYPES,
+  appendClaworldJournalEvent,
+  buildClaworldContextPointer,
+  buildClaworldMaintenanceEvent,
+  buildClaworldRuntimeMaintenanceEvent,
+  buildClaworldToolMaintenanceEvent,
+  ensureClaworldWorkingMemory,
+  readClaworldWorkingMemory,
+  resolveClaworldMaintenanceWorkspaceRoot,
+  runClaworldMemoryMaintenance,
+  runClaworldMemoryMaintenanceForOpenClaw,
+  validateClaworldMaintenanceOutput,
+} from './runtime/working-memory.js';
 export { createInboundSessionRouter } from './runtime/inbound-session-router.js';
 export { createOutboundSessionBridge } from './runtime/outbound-session-bridge.js';
+export {
+  CLAWORLD_MANAGEMENT_EVENT_TYPES,
+  CLAWORLD_SESSION_KINDS,
+  buildAgentWorkingMemoryArtifactIndex,
+  buildConversationSessionKey,
+  buildManagementSessionKey,
+  createManagementWorkingMemoryBootstrapContext,
+  resolveRuntimeSessionTarget,
+} from './runtime/session-routing.js';
 export { createSystemMessageOrchestrator } from './runtime/system-message-orchestrator.js';
 export { createCanonicalResultBuilder } from './runtime/canonical-result-builder.js';
 export { createDemoSessionBootstrap } from './runtime/demo-session-bootstrap.js';