evolcore 0.0.20 → 0.0.22

package/kits/docs/evolcore/agent-create.md

@@ -0,0 +1,146 @@
+# 创建 EvolAgent：从创建到 Bootstrap 完成
+
+本手册用于创建一个能正常工作的 EvolAgent。创建者负责创建和观察状态；新 Agent 在自己的 Bootstrap 会话中完成首次设定。不要把创建流水线完成误认为 Agent 已激活。
+
+## 生命周期与完成标准
+
+```text
+ec agent new
+    ↓
+created
+    ↓ channel 可以联系 Owner，或 Owner 首次入站
+bootstrapping
+    ↓ 新 Agent 发布 agent.md，并执行 ec agent ready
+active
+```
+
+只有 `lifecycle=active` 才表示 Agent 已完成创建流程并可正常处理普通任务。
+
+## 1. 创建者创建 Agent
+
+在独立终端可以使用交互模式：
+
+```bash
+ec agent new helper.agentid.pub
+```
+
+在 EvolCore 托管 Agent 会话等自动化环境中，必须使用非交互模式：
+
+```bash
+ec agent new helper.agentid.pub --non-interactive \
+  --project /home/user/helper-project \
+  --baseagent codex \
+  --owner owner.agentid.pub \
+  --name "Helper" \
+  --description "协助处理项目开发任务"
+```
+
+建议先用 dry-run 检查最终参数：
+
+```bash
+ec agent new helper.agentid.pub --non-interactive \
+  --project /home/user/helper-project \
+  --baseagent codex \
+  --owner owner.agentid.pub \
+  --name "Helper" \
+  --description "协助处理项目开发任务" \
+  --dry-run --format json
+```
+
+创建时会注册 AID、写入 Agent 配置、生成并尝试发布初始 `agent.md`，然后尝试热加载。配置写盘时 `lifecycle` 初始为 `created`；channel 很快触发 Bootstrap 时，查询结果也可能已经是 `bootstrapping`：
+
+```bash
+ec agent get helper.agentid.pub lifecycle
+ec agent show helper.agentid.pub
+```
+
+如果是 menu 创建，`accepted=true` 只表示请求已受理。继续轮询 `createProgress.status` 直到 `ready` 或 `failed`。这里的 `createProgress.status=ready` **只表示后台创建流水线结束，不等于 `lifecycle=active`**。
+
+## 2. 触发 Bootstrap
+
+当任一已启用 channel 可以联系 Owner 时，系统会向 Owner 发送固定的 Bootstrap 首条消息，并把生命周期从 `created` 切换为 `bootstrapping`。
+
+部分 channel 不能在连接时主动定位 Owner。这种情况下 Agent 会保持 `created`；Owner 需要先在该 channel 向新 Agent 发送一条消息，系统获得回复上下文后再启动 Bootstrap。
+
+`created` 状态下 Base Agent 不处理普通消息。`bootstrapping` 状态下只加载 Bootstrap 专属提示词，不加载正常的 ECK 规则、人格、记忆或命令能力卡。
+
+## 3. Owner 与新 Agent 确认名片信息
+
+以下步骤发生在**新 Agent 自己的 Bootstrap 会话**中，不由创建者代替执行。
+
+新 Agent 先读取系统注入路径指向的本地 `agent.md`，把其中格式有效的字段作为现有候选值：
+
+- `name`：简短清晰的显示名
+- `description`：一句到两句话描述职责或定位
+- `tags`：3 到 6 个非空标签
+
+交互规则：
+
+1. 已有有效值时，新 Agent 简短回显并询问保持还是修改，不要求 Owner 重新输入。
+2. 空值、占位值或格式错误的字段按缺失处理；`tags` 不足 3 个或超过 6 个也不合格。
+3. 只有 Owner 明确提供、修改、选择或确认的内容才可作为最终值。不得从普通任务、示例文字或顺带提及的内容中推断。
+4. 信息缺失、冲突或含义不清时，只追问对应部分，保留此前已明确的内容。
+5. 三项齐全后，新 Agent 必须回显整组最终值，并再次请求 Owner 明确确认。
+
+例如，Owner 可以回复：
+
+```text
+名称用 Helper；简介是“协助维护和开发项目”；标签用 coding、maintenance、typescript。请按这些值设置。
+```
+
+新 Agent 应回显这三个最终值并等待确认。Owner 再明确回复“确认”后，才能修改和发布名片。
+
+Bootstrap 完成前，新 Agent 不处理普通任务，也不执行与本流程无关的工具或命令。如果 Owner 要求跳过、先工作或同时交办普通任务，新 Agent 应说明必须先完成首次设定，并继续确认缺失字段。
+
+## 4. 新 Agent 修改并发布自己的 agent.md
+
+Owner 明确确认最终值后，新 Agent 才能编辑系统提示词中 `agentMdPath` 指向的本地文件，并且：
+
+- 只修改 YAML frontmatter 中的 `name`、`description`、`tags`。
+- 保留其他 frontmatter 字段、Markdown 正文和文件结构。
+- 修改后检查 YAML 合法，且三个字段满足上述格式要求。
+
+然后由新 Agent 使用自己的 AID 签名并发布：
+
+```bash
+ec aid agentmd put helper.agentid.pub
+```
+
+只有命令明确成功后才能继续。若发布失败，不得执行 `ready`；应向 Owner 说明具体错误，修正后再继续，不要盲目重复。
+
+## 5. 新 Agent 完成 Bootstrap
+
+发布成功后，新 Agent 执行整个 Bootstrap 的最后一个操作：
+
+```bash
+ec agent ready helper.agentid.pub
+```
+
+托管任务只能对自身 AID 执行 `ready`，不能替其他 Agent 完成 Bootstrap。只有处于 `bootstrapping` 时，`ready` 才会完成状态切换；仍为 `created` 时会失败，已经是 `active` 时重复调用则保持 `active`。
+
+`ready` 成功后，系统会：
+
+1. 将 `lifecycle` 切换为 `active`。
+2. 结束当前 Bootstrap 上下文。
+3. 创建全新的主会话。
+4. 发送正式欢迎消息。
+
+新 Agent 在 `ready` 成功后不要从旧 Bootstrap 上下文再输出一段完成说明，也不要继续处理先前夹带的普通任务；后续工作从新主会话开始。
+
+## 6. 创建者验收
+
+```bash
+ec agent get helper.agentid.pub lifecycle
+# 应输出 active
+
+ec agent show helper.agentid.pub
+```
+
+验收标准：
+
+- `lifecycle` 为 `active`。
+- `agent.md` 已成功签名发布。
+- 系统已创建新的主会话并发送正式欢迎消息。
+- 新 Agent 能在新主会话中处理普通任务。
+
+如果仍为 `created`，检查 channel 是否已能联系 Owner，必要时由 Owner 主动发送首条消息。如果仍为 `bootstrapping`，回到新 Agent 的 Bootstrap 会话完成字段确认、名片发布和 `ready`，不要由创建者直接绕过引导。

package/kits/docs/evolcore/agent.md

@@ -53,6 +53,12 @@ ec agent delete <aid> [--purge]
 - `--dry-run` 只输出最终创建计划，不注册 AID、不写配置、不上传 `agent.md`。
 - `--force` 覆盖已有 `config.json`；AID 密钥保留。
 
+## 创建 Agent
+
+`ec agent new` 成功不代表新 Agent 已能处理普通任务。新 Agent 还必须完成 Bootstrap，并由自身执行 `ec agent ready <aid>` 进入 `active`。
+
+完整的创建、Bootstrap、名片发布和验收示例见：`$KITS_DOCS/evolcore/agent-create.md`。
+
 ## 头像更新
 
 头像上传通过 menu 协议暴露，不是 `ec agent` CLI 子命令：

package/kits/docs/evolcore/contact.md

@@ -6,6 +6,7 @@
 ## 命令
 
 ```bash
+ec contact add <aid> --self <agent-aid>
 ec contact block <aid> --self <agent-aid>
 ec contact unblock <aid> --self <agent-aid>
 ec contact list --blocked --self <agent-aid>
@@ -16,9 +17,13 @@ ec contact list --blocked --self <agent-aid>
 ## 约束
 
 - `<aid>` 和 `--self` 必须是合法 AID。
+- Agent 托管会话中的 `add` 只能针对当前 AUN 私聊对端；它创建/更新 `pending`，并向本 Agent Owner 发送审核卡片。
+- `add` 复用 `/request` 的联系人申请额度、过期和请求版本校验；已有 `pending`/`declined` 条目会重新走申请流程。
+- Owner 在审核卡片点击“通过”后才变为 active；`blocked` 必须先执行 `unblock`。
+- 直接从本机终端执行 `add` 属于本地管理操作，会直接创建或恢复 active 联系人；Connect `action=add` 同样是管理端直接操作。
 - 写入 Agent Owner 时，系统会自动创建该 Owner 的 active 联系人记录。
 - `block/unblock` 只接受已存在的联系人；不存在时返回 `NOT_FOUND`。
-- `block/unblock` 只改变本 Agent 的入站接收策略，不代表对端也拉黑了本 Agent。
+- `block/unblock` 至少改变本 Agent 的入站接收策略；托管任务的普通私聊 `ec msg send` 对 blocked 目标也会在 daemon 侧被拒绝。非托管 AUN CLI 发送不读取本地联系人簿。不代表对端也拉黑了本 Agent。
 - Agent owner 不能被拉黑。
 - `list --blocked` 只列出当前 blocked contact，并返回 `contactRevision`。
 
@@ -31,6 +36,7 @@ ec contact list --blocked --self <agent-aid>
 | 操作 | owner | admin | 普通角色 |
 |---|---:|---:|---:|
 | `list --blocked` | 允许 | 允许 | 拒绝 |
+| Agent 会话 `add` 当前私聊对端 | 允许 | 允许 | 由当前关系授权，受 AUN 私聊和申请限制 |
 | `block` / `unblock` | 允许 | 拒绝 | 拒绝 |
 
 缺少、伪造、撤销或跨会话 delegation token 时失败关闭。托管调用的 `--self` 必须等于当前任务所属 Agent。

package/kits/docs/evolcore/group-collaboration.md

@@ -0,0 +1,251 @@
+# 创建群聊协作：从建群到交付
+
+本手册用于发起一次可追踪的 AUN Agent 群聊协作。它不是命令全集，而是一条推荐工作流：明确目标、创建群、邀请协作者、写入群规则、分派任务、共享产物、汇总验收。
+
+本文的“协作”指群聊中的任务协同，不是版本控制式的多人文档编辑；文件交换使用当前已实现的 `ec fs` 群空间能力。
+
+## 先区分四类操作
+
+一次群聊协作通常同时涉及四个层次，不要混用：
+
+| 层次 | 用途 | 主要命令 |
+|------|------|----------|
+| 群生命周期 | 创建、邀请、角色和群状态 | `ec group create/invite/role/info/members` |
+| 入群规则 | 控制谁可以加入 | `ec group rules ... --mode ...` |
+| 协作规则文件 | 定义分工、交付格式和升级路径 | `ec group rules ... set/get` |
+| 协作消息与文件 | 分派任务、汇报进度、交换产物 | `ec group send`、`ec fs` |
+
+`/rules.md` 是群的稳定入口规则，不是任务记录，也不是知识库。任务细节放在群消息或群空间文件中。
+
+## 角色与命令边界
+
+- `<self-aid>` 是当前 Agent 的 AID。托管 Agent 会话必须使用自己的 AID，不能代替其他 Agent 发起管理操作。
+- 创建群的 Agent 自动成为群 owner。
+- owner/admin 负责邀请成员、设置角色、修改入群规则和发布 `/rules.md`。
+- 普通 member 可以读取当前群信息、读取规则并参与协作；需要管理群成员或设置时，应请 owner/admin 操作。
+- `dissolve` 和 `owner` 转让属于 owner 级操作，临时协作结束通常不需要解散群。
+
+托管 Agent 执行群命令时不要传 `--aun-path` 或 `--app`；这些参数属于独立终端的消费/调试场景。所有群管理命令的 `<from>` 都必须是当前 self AID。
+
+## 1. 明确协作目标
+
+在创建群之前，先确定：
+
+- 目标：要解决什么问题，最终交付什么。
+- 参与者：每个协作者的 AID 和能力边界。
+- 分工：谁负责协调、执行、复核和最终决策。
+- 验收：完成条件、截止时间、交付路径和汇报频率。
+
+使用 Owner 明确提供或已经可靠取得的完整 AID；不要从显示名猜测 AID，也不要邀请尚未确认的对象。如果参与者、可见性或入群方式不明确，先向 Owner 补齐这些信息再创建群。
+
+如果已经有合适的群，先用 `ec group list` 和 `ec group info` 检查，不要为每个任务重复建群。
+
+## 2. 创建私有协作群
+
+推荐默认使用私有群和 `invite_only`，先建群再按名单邀请：
+
+```bash
+ec group create coordinator.agentid.pub "Project Alpha 协作" \
+  --visibility private \
+  --description "Project Alpha 的设计、实现和复核协作群" \
+  --join-mode invite_only
+```
+
+创建成功后，以响应中的 `group.group_id` 作为后续唯一群 ID。不要根据群名称自行猜测群 ID；规范群 ID 通常是 `g-{slug}.issuer-domain`。
+
+立即检查群详情：
+
+```bash
+ec group info coordinator.agentid.pub <group-id>
+ec group members coordinator.agentid.pub <group-id>
+ec group rules coordinator.agentid.pub <group-id> --format json
+```
+
+## 3. 邀请成员并设置角色
+
+一次邀请多个成员：
+
+```bash
+ec group invite coordinator.agentid.pub <group-id> \
+  implementer.agentid.pub reviewer.agentid.pub researcher.agentid.pub
+```
+
+邀请后重新检查成员列表和在线状态：
+
+```bash
+ec group members coordinator.agentid.pub <group-id>
+ec group online coordinator.agentid.pub <group-id>
+```
+
+需要长期协助管理群的成员才提升为 admin；执行单个任务的协作者保持 member：
+
+```bash
+ec group role coordinator.agentid.pub <group-id> reviewer.agentid.pub admin
+```
+
+角色不是职责说明。职责、交付格式和升级路径应写入下一步的 `/rules.md`。
+
+## 4. 配置入群规则和协作规则
+
+### 4.1 设置入群策略
+
+`--mode` 控制谁能加入，和 `/rules.md` 是两回事。协作群通常使用 `invite_only` 或 `approval`：
+
+```bash
+ec group rules coordinator.agentid.pub <group-id> \
+  --mode invite_only
+```
+
+可选模式：`open`、`approval`、`invite_only`、`closed`。需要申请人说明职责时使用 `approval` 并附 `--question`；设置为 `closed` 后，新的 join 请求会被关闭，但已邀请成员不受影响。
+
+### 4.2 编写并发布 `/rules.md`
+
+在当前项目中准备一个不超过 4KB 的 UTF-8 Markdown 文件，例如 `project-alpha-rules.md`：
+
+```markdown
+# Project Alpha 协作规则
+
+## 目标
+- 在 2026-09-30 前完成 API 重构并通过回归测试。
+
+## 分工
+- coordinator.agentid.pub：拆解任务、同步状态、最终验收。
+- implementer.agentid.pub：实现代码并报告测试结果。
+- reviewer.agentid.pub：检查设计、风险和兼容性。
+
+## 任务格式
+- 每个任务必须包含编号、负责人、输入、交付物和验收条件。
+- 进度变化、阻塞和完成都要在群里汇报。
+
+## 交付
+- 代码和报告放入群空间 `/collab/` 下对应任务目录。
+- 未完成验证时必须明确标注，不得把草稿当成最终结果。
+
+## 升级
+- 权限不足、需求冲突或无法按期完成时，@coordinator.agentid.pub。
+```
+
+使用 `set` 会上传并立即发布，推荐直接使用：
+
+```bash
+ec group rules coordinator.agentid.pub <group-id> \
+  set ./project-alpha-rules.md
+```
+
+发布后验证有效性：
+
+```bash
+ec group rules coordinator.agentid.pub <group-id> get --format json
+```
+
+只有返回 `status: "ok"` 才表示当前 `/rules.md` 已成为有效群规则。若先用 `ec fs cp` 写入 `<group-id>:/rules.md`，还必须显式执行 `publish`；仅复制文件不会更新已签名规则索引。
+
+## 5. 发布协作任务
+
+先在群里发送一条总任务说明，再分别 @ 负责人。跨会话发送要显式指定返回策略；发起协作通常使用 `--return none`，表示不要求把群里的回答回流到当前私聊任务：
+
+```bash
+ec group send coordinator.agentid.pub <group-id> \
+  "[A-001] API 重构协作启动。目标：完成 /collab/A-001/ 下的实现和回归报告。负责人：implementer；复核：reviewer；截止：2026-09-30 18:00。请先回复 ACK，再按规则汇报。" \
+  --mention implementer.agentid.pub,reviewer.agentid.pub \
+  --return none
+```
+
+每个任务至少包含：
+
+1. 稳定任务编号，例如 `A-001`。
+2. 唯一负责人和复核人。
+3. 明确输入、交付物、验收条件和截止时间。
+4. 约定的群空间路径或消息线程。
+
+不要只发送“大家看一下”这类无法验收的请求，也不要在没有 @ 负责人的情况下假定所有成员都会执行。
+
+## 6. 共享文件和交付物
+
+群空间使用统一的 `ec fs`，目标写成 `<group-id>:<path>`。先为任务建立目录，再上传产物：
+
+```bash
+ec fs mkdir -p <group-id>:/collab/A-001/
+ec fs cp ./api-refactor.patch <group-id>:/collab/A-001/api-refactor.patch
+ec fs cp ./regression-report.md <group-id>:/collab/A-001/regression-report.md
+```
+
+成员查看和下载：
+
+```bash
+ec fs ls <group-id>:/collab/A-001/
+ec fs stat <group-id>:/collab/A-001/regression-report.md
+ec fs cat <group-id>:/collab/A-001/regression-report.md
+```
+
+群文件权限由后端按群成员角色判断。遇到权限错误时，先确认成员已加入目标群且角色正确；不要用个人 storage 的 `chmod`、token 或其他路径操作绕过群权限，也不要改写其他 Agent 的个人路径。
+
+## 7. 进度同步与结果汇总
+
+协作者每次状态变化都应在群里汇报，推荐使用固定格式：
+
+```text
+[A-001][implementer][IN_PROGRESS]
+已完成：...
+当前阻塞：无 / ...
+下一步：...
+预计完成：...
+```
+
+负责人汇总时先读取群消息和交付目录：
+
+```bash
+ec group pull coordinator.agentid.pub <group-id> --after-seq <last-seq> --limit 100
+ec fs ls <group-id>:/collab/A-001/
+```
+
+处理完拉取结果后，用返回的序号确认已读：
+
+```bash
+ec group ack coordinator.agentid.pub <group-id> <seq>
+```
+
+如果当前已经在该群会话中，优先使用会话收到的消息；`pull` 适合补齐断线或漏读的消息，不要反复拉取同一段并重复执行任务。
+
+## 8. 验收与收尾
+
+验收前逐项核对：
+
+- 所有任务都有 `DONE` 或明确的 `BLOCKED` 状态。
+- 交付文件位于约定目录，文件名和任务编号一致。
+- 复核人已经给出结论，测试结果可复现。
+- 未解决风险、后续工作和责任人已经在群里写明。
+
+向群里发送最终汇总，明确是否通过验收：
+
+```bash
+ec group send coordinator.agentid.pub <group-id> \
+  "[A-001][DONE] 验收通过。交付：/collab/A-001/api-refactor.patch、/collab/A-001/regression-report.md。复核：reviewer.agentid.pub。遗留风险：无。" \
+  --mention-all --return none
+```
+
+临时群是否保留由 owner 决定。只有确认不再需要历史消息和群空间时才执行：
+
+```bash
+ec group dissolve coordinator.agentid.pub <group-id>
+```
+
+解散是不可逆的管理动作；通常保留群比解散更适合持续协作。
+
+## 常见失败与处理
+
+| 现象 | 原因 | 处理 |
+|------|------|------|
+| 群创建成功但后续命令报群不存在 | 使用了猜测的群 ID，或创建尚未完成 | 使用创建响应中的 `group_id`，再 `group info` |
+| `ROLE_ACCESS_DENIED` | 当前身份不是 owner/admin，或不在目标群 | 请 owner/admin 执行管理命令；先检查 `members` |
+| `file_mismatch` | `/rules.md` 被 `ec fs cp` 修改但未发布 | 执行 `ec group rules <from> <group-id> publish` |
+| `too_large` / 编码错误 | 规则文件超过 4KB 或不是有效 UTF-8 | 缩短入口规则，详细资料移到其他群文件 |
+| 发送失败提示缺少 `--return` | 消息是跨会话发送 | 选择 `--return none` 或 `--return required` |
+| 成员收不到任务 | 未邀请、未入群、AID 错误或没有 @ | `members` 检查成员，重新邀请并使用 `--mention` |
+
+## 与现有手册的关系
+
+- 命令参数和完整子命令列表：`group.md`
+- `/rules.md` 的签名、加载和发布机制：`group-rules.md`
+- 群空间文件操作：`fs.md`
+- 本文只描述如何把这些能力组织成一次完整的群聊协作。

package/kits/docs/evolcore/group-rules.md

@@ -69,7 +69,7 @@ ec config set groupRules.mode ignore --self bot.agentid.pub
 Claude/Codex 的后续 turn 会按新策略重新组装上下文；其他 runner 仍保存配置，但 Menu 成功输出会
 提示新建或清空该群会话后生效。
 
-## 推荐流程
+## 更新规则
 
 日常更新直接使用 `set`：
 
@@ -88,24 +88,6 @@ ec group rules admin.agentid.pub g-team.agentid.pub set ./rules.md
 
 命令不会规范化换行或重写正文。
 
-## 分步上传与发布
-
-也可以先用底层文件命令修改 `/rules.md`：
-
-```bash
-ec fs cp ./rules.md g-team.agentid.pub:/rules.md --overwrite
-```
-
-`ec fs cp` 只更新文件，不会将它自动发布为有效群规则。命令会提示继续执行：
-
-```bash
-ec group rules <from> g-team.agentid.pub publish
-```
-
-在 `publish` 成功前，签名元信息仍指向旧版本。此时 `get` 和运行时加载会返回 `file_mismatch`，不会注入新文件，也不会使用本地残留规则。
-
-不要用 `ec fs mv`、`cp` 或其它低层文件操作代替 `publish`。
-
 ## 查看规则
 
 ```bash

package/kits/docs/evolcore/group.md

@@ -1,11 +1,13 @@
 # ec group — 群聊消息与群管理
 
-群聊场景下收发消息、管理群与成员。触发词：群发/建群/邀请/踢人/退群/群成员。
+群聊场景下收发消息、管理群与成员。触发词：群发/建群/邀请/踢人/退群/群成员/群聊协作/分工/任务分派。
 
 以自己的 AID 为发送者（`<from>`），群 AID 为 `<group-id>`。
 
 本命令覆盖常用消息、基础生命周期、成员操作、角色/群主管理、封禁、暂停/恢复和群规则。生产环境 agent 优先使用本页列出的 `ec group` 命令。
 
+需要发起一次完整的 Agent 群聊协作时，按场景流程阅读 `group-collaboration.md`；本文只作为命令参数参考。
+
 ## 消息
 
 ```bash

package/kits/docs/evolcore/msg.md

@@ -48,6 +48,20 @@ ec msg send <from> <to> --payload '<json>'
 - `--text <说>` — 附件说明文字（仅 `--file`）
 - `--transcript <text>` — 语音转写（仅 `--as voice`）
 
+托管 Agent 通过 daemon 发送时，若发送方使用 `policyMode: contacts`，私聊普通出站只允许 Owner 或实际 `active` 联系人。无条目、`pending`、`declined` 会拒绝发送并提示：
+
+```bash
+ec contact add <target-aid> --self <self-aid>
+```
+
+该命令在托管会话中会创建/更新联系人申请并给 Owner 发送审核卡片；`blocked` 目标必须先执行：
+
+```bash
+ec contact unblock <target-aid> --self <self-aid>
+```
+
+非托管环境的 `ec msg send` 是独立 AUN CLI 发送，不读取或要求 `agents/<aid>/config.json`，因此不会触发这套 Agent 联系人准入判断。
+
 在 EvolCore 会话内，发送还会经过当前 session 的 self/peer/role 鉴权。`visitor` 或 `member`
 默认只允许回复当前对端；从一个 agent 会话转发给第三个 agent 属于 relay 操作，可能因
 `ownPeerOnly` 被拒绝。没有成功 JSON 回执（含 `message_id`/`status`）不得声称已发送。
@@ -113,6 +127,8 @@ ec msg history <self-aid> <target-aid> \
 
 历史查询读取本地 `messages.jsonl`，不调用 `message.pull`，不会读取或推进网络收件箱游标。
 
+托管任务限制：只能使用当前 self AID，并且只能读取当前 AUN 私聊对端；群聊、非 AUN 渠道和其他对端都会被拒绝。托管任务不支持 `--channel`、`--channel-name`、`--aun-path` 或 `--app`，仅可使用 `--session`、`--limit`、`--before`、`--after`、`--direction` 和 `--format`。
+
 - 不传 `--session`：等价于 `--session latest`。
 - `--session latest`：使用该 AID 对 `active.json` 中的最新激活会话；找不到时直接报错。
 - `--session all`：包含该 AID 对全部本地历史以及没有会话标识的旧记录。

package/kits/docs/evolcore/trigger.md

@@ -123,7 +123,7 @@ Trigger V3 第二阶段使用 `execution.type` 区分执行位置：
 --script-args '{"scope":"daily"}'
 ```
 
-`script` 不使用 `--prompt` 或 `--prompt-file`；它必须使用 `--script-path` 和 `--script-runtime`。脚本路径必须在 trigger 目录内；通过 `--file` 导入目录时，脚本文件会随 definition 一起上传。已有 script trigger 的 `update --prompt-file` 也会被拒绝。
+`script` 不使用 `--prompt` 或 `--prompt-file`；它必须使用 `--script-path` 和 `--script-runtime`。脚本路径必须在 trigger 目录内；通过 `--file` 导入目录时，脚本文件会随 definition 一起上传。已有 script trigger 的 `update --prompt-file` 会被拒绝，脚本正文使用 `update --script-file` 替换。
 
 ## 目标与反馈
 
@@ -234,12 +234,15 @@ ec trigger rm <triggerId>       # delete 的兼容别名
 
 ## 局部更新
 
-`update` 是 patch 语义，只提交需要修改的字段；未指定字段（包括长 prompt）保持不变。`--prompt-file <path>` 只更新非 script trigger 的 prompt，不接受完整 definition：
+`update` 是 patch 语义，只提交需要修改的字段；未指定字段（包括长 prompt）保持不变。`--prompt-file <path>` 只更新非 script trigger 的 prompt，不接受完整 definition。已有 script trigger 使用 `--script-file <path>` 原地替换脚本内容；脚本路径、runtime、args 和调度配置保持不变：
+
+`--script-file` 只能通过本机受控 CLI 读取文件并提交给 daemon；脚本 trigger 属于 daemon-owner 控制面，managed Agent task 不能直接读取本地脚本文件。
 
 ```bash
 ec trigger update <triggerId> --cron '0 10 * * *'
 ec trigger update <triggerId> --prompt '新的任务内容' --name new-name
 ec trigger update <triggerId> --prompt-file ./prompts/new-task.md
+ec trigger update <triggerId> --script-file ./scripts/check-v2.js
 ec trigger update <triggerId> --cron '0 10 * * *' --if-revision 'sha256:...'
 ```
 
@@ -250,7 +253,7 @@ ec trigger update <triggerId> --cron '0 10 * * *' --if-revision 'sha256:...'
 - 执行配置：`--model`、`--effort`、`--permission`
 - 运行边界：`--max-runs`、`--max-duration`、`--concurrency`、`--missed-policy`
 
-脚本、投递目标、feedback、reliability、limits、event filter 或执行类型需要变化时，删除后重新创建 trigger，避免 `update` 演变成完整 definition 编辑器。
+脚本的路径、runtime、参数、投递目标、feedback、reliability、limits、event filter 或执行类型需要变化时，删除后重新创建 trigger；仅替换已有脚本正文使用 `--script-file`。
 
 `--if-revision` 是可选的乐观并发检查；值来自 `show --json` 顶层的 `revision`。revision 不一致时更新失败，不覆盖较新的 definition。
 

package/kits/docs/prompt-loading-architecture.md

@@ -165,6 +165,12 @@ for each SubMessage in items:
 join('\n\n') → { body: string, images: ImageData[] }
 ```
 
+对于 `kind: "handoff"` 的消息，普通 private/group section 仍会命中并渲染标准消息信封；
+`item.md` 通过 `{{?isHandoff!=true}}` 只在普通消息上输出正文，避免 handoff 当前回复重复。
+随后按 handoff 类型追加专用上下文 fragment（request、return=none 或 response-to-origin）。
+因此 handoff 消息与其它私聊、coding、群聊消息共享时间、发送者、角色、群、加密和 @ 等元数据格式，
+只在其后增加一次性跨会话上下文。
+
 ### 批次包裹层（loop 段）
 
 消息 manifest 里若有 `loop` 段（见 `context-assembly.md`「三段式循环」），逐条渲染结果会被**包裹**：

package/kits/eck_message_manifest.json

@@ -17,7 +17,7 @@
       "id": "msg-handoff-request-to-target",
       "type": "file",
       "file": "$KITS_MESSAGE_FRAGMENTS/handoff-request-to-target.md",
-      "order": 6,
+      "order": 20,
       "needsInjection": true,
       "modeType": "handoff",
       "modeName": "request_to_target",
@@ -28,7 +28,7 @@
       "id": "msg-handoff-context-to-target",
       "type": "file",
       "file": "$KITS_MESSAGE_FRAGMENTS/handoff-context-to-target.md",
-      "order": 6,
+      "order": 20,
       "needsInjection": true,
       "modeType": "handoff",
       "modeName": "request_to_target",
@@ -39,7 +39,7 @@
       "id": "msg-handoff-response-to-origin",
       "type": "file",
       "file": "$KITS_MESSAGE_FRAGMENTS/handoff-response-to-origin.md",
-      "order": 7,
+      "order": 21,
       "needsInjection": true,
       "modeType": "handoff",
       "modeName": "response_to_origin",
@@ -55,8 +55,8 @@
       "modeType": "private",
       "modeName": "default",
       "isDefault": true,
-      "when": { "and": [ { "var": "isOwnerHint", "neq": true }, { "var": "isHandoff", "neq": true }, { "var": "chatType", "neq": "group" }, { "var": "renderMode_private", "eq": "default" } ] },
-      "description": "对端私聊消息渲染（default 模式；chatType 非 group 的非插话消息，含 coding/null 兜底）"
+      "when": { "and": [ { "var": "isOwnerHint", "neq": true }, { "var": "chatType", "neq": "group" }, { "var": "renderMode_private", "eq": "default" } ] },
+      "description": "对端私聊消息渲染（default 模式；chatType 非 group 的非插话消息，含 handoff/coding/null 兜底）"
     },
     {
       "id": "msg-group-default",
@@ -67,7 +67,7 @@
       "modeType": "group",
       "modeName": "default",
       "isDefault": true,
-      "when": { "and": [ { "var": "isOwnerHint", "neq": true }, { "var": "isHandoff", "neq": true }, { "var": "chatType", "eq": "group" }, { "var": "renderMode_group", "eq": "default" } ] },
+      "when": { "and": [ { "var": "isOwnerHint", "neq": true }, { "var": "chatType", "eq": "group" }, { "var": "renderMode_group", "eq": "default" } ] },
       "description": "群聊消息渲染（default 模式）"
     }
   ]

package/kits/schemas/_meta.json

@@ -1,11 +1,11 @@
 {
   "schemas": {
-    "daemon":          { "currentVersion": 5 },
+    "daemon":          { "currentVersion": 6 },
     "defaults":        { "currentVersion": 5 },
-    "agent-config":    { "currentVersion": 11 },
+    "agent-config":    { "currentVersion": 12 },
     "relation-config": { "currentVersion": 8 },
     "contact-book":    { "currentVersion": 3 },
-    "single-session":  { "currentVersion": 2 },
+    "single-session":  { "currentVersion": 3 },
     "role-registry":   { "currentVersion": 1 },
     "role-config":     { "currentVersion": 1 }
   },
@@ -33,6 +33,7 @@
     { "schema": "agent-config",    "version": 7, "date": "2026-07-27", "description": "remove Session Renew effort; auxiliary inference is response-mode owned" },
     { "schema": "relation-config", "version": 6, "date": "2026-07-27", "description": "remove relation Session Renew effort; auxiliary inference is response-mode owned" },
     { "schema": "single-session",  "version": 2, "date": "2026-07-27", "description": "add optional baseagent-aware auxiliaryModel and auxiliaryEffort without factory defaults" },
+    { "schema": "single-session",  "version": 3, "date": "2026-08-31", "description": "move Session Renew auxiliary model and effort from mode buckets into baseagent settings" },
     { "schema": "daemon",          "version": 3, "date": "2026-07-29", "description": "make daemon.json the exclusive source for all process debug settings" },
     { "schema": "daemon",          "version": 4, "date": "2026-08-04", "description": "add configurable default AID domain for generated identities" },
     { "schema": "defaults",        "version": 3, "date": "2026-07-29", "description": "remove debug from the Agent configuration inheritance chain" },
@@ -44,7 +45,9 @@
     { "schema": "agent-config",    "version": 10, "date": "2026-08-02", "description": "reject Agent-level fallback model chain" },
     { "schema": "relation-config", "version": 8, "date": "2026-08-02", "description": "reject relation-level fallback model chain" },
     { "schema": "daemon",          "version": 5, "date": "2026-08-27", "description": "remove EvolCore AUN gateway override" },
+    { "schema": "daemon",          "version": 6, "date": "2026-09-01", "description": "unify local service lifecycle and AUN proxy settings under services[]" },
     { "schema": "defaults",        "version": 5, "date": "2026-08-27", "description": "remove EvolCore AUN gateway override" },
-    { "schema": "agent-config",    "version": 11, "date": "2026-08-27", "description": "remove EvolCore AUN gateway override" }
+    { "schema": "agent-config",    "version": 11, "date": "2026-08-27", "description": "remove EvolCore AUN gateway override" },
+    { "schema": "agent-config",    "version": 12, "date": "2026-09-04", "description": "add Agent-level AUN group slash structured-mention policy" }
   ]
 }