evolcore 0.0.39 → 0.0.40

package/kits/docs/evolcore/agent.md

@@ -105,7 +105,7 @@ ec agent delete <aid> [--purge]
 - `ec agent welcome --text <text>` 用于保存 Bootstrap 中 Agent 自主准备的完整正式文案，不要求 Owner 起草、审稿或确认；命令固定写入当前 Agent 的 `$PERSONAL_DIR/welcome.md`，不接受自定义路径。`welcome show` 读取该文件。
 - welcome 托管写入要求当前 Agent 私聊 Owner；admin 仅可读。模板上限 4 KiB，渲染上限 8 KiB；变量为 `agentName`、`agentDescription`、`agentAid`、`agentTags`、`agentTagsText`、`ownerName`、`ownerAid`、`channel`，支持标签循环和真值条件。写入保留原始文本，投递不附加额外文案。
 - `agent show <target-aid>` 与 `agent get <target-aid> <key>` 的跨 Agent 读取对 owner/admin 开放，但普通 Agent 角色只获得安全摘要；敏感配置值和物理路径仅对 DaemonOwner 返回原值。跨 Agent 写入、启停、删除和 reload 仍遵循各自的目标与 DaemonOwner 权限边界。
-- Agent 配置可包含 `fullaccess.enabled`（默认关闭）。可通过已认证的 EC Web Agent 设置修改；也可通过 Agent AID 的 `name: "agent"` Menu 管理自身，或通过 daemon Control AID 的同名 Menu 指定 `args.aid` 管理目标 Agent。Menu 写入要求请求者同时是目标 Agent Owner 与 daemon Owner；实际运行时也只有满足双 Owner 条件的直接私聊任务才会按调用使用宿主级 fullaccess。群聊、普通 Owner、跨 Agent 和 Trigger 不会因该开关自动提权。`/fa`、`/fullaccess` 和 Fullaccess Trigger 是内置能力，仍分别要求经过认证的 daemon Owner / 持久授权来源。
+- Agent 配置可包含 `fullaccess.enabled`（默认关闭）。Menu 写入要求请求者同时是目标 Agent Owner 与 daemon Owner。`/fa`、`/fa on`、`/fa off`（`/fullaccess` 为别名）只管理当前私聊 EC 会话：主会话写 Agent 级开关，话题会话写自身 session metadata；群聊不支持。实际运行时逐次复核双 Owner、会话绑定和 Runner fullaccess 能力；Trigger 不会因该开关自动提权。
 
 ## 创建 Agent
 

package/kits/docs/evolcore/aid.md

@@ -31,18 +31,18 @@ ec aid avatar <当前 self AID> (--file <path> | --url <https-url>) [--format js
 ## 控制 AID 的非交互注册邀约
 
 `ec init --non-interactive --owner <aid> --format json` 首先按普通 host 类型注册控制 AID，
-完成主机名片和配置落盘后，通过独立 CLI slot 的一次性长连接连接控制 AID，
-再调用与 `ec agent create` 相同的 Owner 绑定服务显式发起邀约。
-init 不等待人工审批、不启动 daemon，也不把该目标写入 `daemon.json.owner/owners`。
-容器入口随后启动 daemon，由 SDK 恢复同一任务，审批事件触发新鲜共识核验后才产生协议 Owner 权限。
+完成主机名片和配置落盘后，通过独立 `ownership-UUID` slot 的短连接调用 SDK `bindOwneraid` 发起邀约。
+该注册调用不等待人工审批、不启动 daemon，也不把目标写入 `daemon.json.owner/owners`。
+SDK 不持久化 Ownership task/WAL；`OwnershipTaskResult` 只是本次调用结果。
+提交后应以当前 NS 状态和 `checkOwnershipConsensus` 为准，不依赖重启后恢复相同 operation ID。
 
 `bindingStatus` 为 `submitted` 仅表示 SDK 已确认邀约 `message.send` 回执；它不代表 Owner 已审批。
 
-`already_bound` 必须经过当前共识核验。旧版本留下的注册意图会由 SDK 恢复原任务，
-初始化复用原 `operation_id`，不重新注册身份或创建第二个绑定任务。
+`already_bound` 必须经过当前共识核验。旧版本留下的注册意图只用于识别原注册目标，
+不再代表一个可恢复的 Ownership task；新调用按 SDK 当前远端关系重新判断。
 提交超时返回 `unknown`，错误结果中的 `initialized: true` 表示配置和控制身份仍然保留；
 部署方应解析结果并按恢复策略启动 daemon，不能仅用 `init && start` 处理部分成功。
-相同注册意图复用原 operation_id，不同目标返回冲突，`--force` 不覆盖协议 Owner。
+不同目标与已有注册意图冲突，`--force` 不覆盖协议 Owner。
 实现与验证说明见 `docs/init-control-aid-owner-registration.md`。
 
 ## 收到绑定邀约后确认或拒绝
@@ -60,15 +60,30 @@ ec aid bind reject <operationId> --subject <接收方本地AID> --reason '用户
 待确认绑定任务，包括 `operation_id`、`sub_aid`、`owner_aid`、`requester_aid`、本端 `local_role` 和关系版本。
 本端既可以是拟任 Owner，也可以是接受 Owner 绑定的 sub；转移、解绑及未验证请求不通过该入口审批。
 
-CLI 经 daemon 已有的 SDK 客户端调用 `acceptOwnershipRequest` / `rejectOwnershipRequest`，不新建连接。
+CLI 优先经 daemon 已有的 SDK 客户端调用 `acceptOwnershipRequest` / `rejectOwnershipRequest`；
+宿主 CLI 指定的本地 AID 没有已连接的 daemon client 时，daemon 会加载该 AID 的本地身份，
+用独立短连接完成操作后关闭。托管 Agent 仍只能操作当前已挂载的 self AID。
 请求的真实性、当前关系、固定参与方和决定一致性由 SDK 在执行时复核。未处理的邀约保持待审批。
-请求摘要只保存在当前客户端的内存中，daemon 重启或更换客户端后由 SDK 从持久任务重新发出事件恢复。
+`requests` 是当前进程的内存投影，不是持久任务库。SDK 可在决定时从正常消息历史重新取回并验证原始请求；
+如果原始认证请求已不可用，SDK 会返回 `operation_not_found`，需要重新发起邀约。
 
-审批回执的 `decisionTask` 是这次提交决定的任务；`pending` 表示仍在推进，`completed` 表示 SDK 已核验任务完成。
-接受回执本身不授予权限，Owner 权限仍由新鲜 Ownership 共识确定。后续 SDK 事件更新当前进程的 `decisionTask`。
+审批回执的 `decisionTask` 是这次调用结果，不是后台任务；`pending` / `completed` 仅描述 SDK 本次动作。
+`decisionConsensus` 是 SDK 对邀约 sub 的独立新鲜查询，只有它显示目标 owner、sub、版本和 `locked` 匹配时才表示关系已成立。
+接受回执本身不授予权限，Owner 权限仍由 `checkOwnershipConsensus` 返回的当前 owner、sub、关系版本和 `locked` 状态确定。
+只有 SDK 事件会更新当前进程的请求投影。
 托管会话审批需要当前 Agent Owner 或 daemon Owner，以及 `request` / `bypass` 任务；admin 仅可查询。
 选择另一个本地 AID 需要 daemon Owner。Fullaccess 执行不额外授予协议绑定或审批权限。
 
+## 本地双身份绑定
+
+执行 `ec aid bind <ownerAid> --subject <subAid>` 时，如果本机同时有两份身份的有效私钥、证书，
+且两个身份都是不同的普通 `agent` 并已有可验证的 `agent.md`，EvolCore 调用 SDK 原生
+`ownerClient.bindLocalSubaid(subClient)`。SDK 自行创建两个身份专属的短连接，完成本人文件发布和 NS 验收后关闭连接；
+不发送 P2P 邀约，也不要求人工确认。EvolCore 再次调用 `checkOwnershipConsensus` 核对目标 Owner、sub、关系版本和锁。
+
+缺少任一身份材料、身份类型不符或不是普通 agent 时，普通在线 sub 回退到 `bindOwneraid` 邀约流程；
+人类 Owner 仍须通过 `accept` / `reject` 明确决定。SDK 返回的 `completed` 不单独证明关系已成立。
+
 ## Ownership 共识缓存
 
 Agent 的首个配置 Owner 可在该 Agent 的 AUN 私聊中发送纯 `/bind`，由 Agent
@@ -79,9 +94,11 @@ Ownership 共识不再每 15 秒轮询。普通消息、控制消息、查询和
 
 Ownership 任务事件、修改本地 Owner 配置、相关名片或 Owner 关系材料变更立即失效缓存并触发一次复核；连接首次就绪或断线后恢复也复核一次。相同任务事件和连接通知去重，无关对端、普通文件变更不触发。远端 Owner 的 Storage 事件只在本机确实收到时生效，不能假定事件完整覆盖远端变化。Owner 绑定提交前及修改 Owner 的授权不复用缓存；其它敏感操作接受最长 5 分钟的协议状态陈旧窗口。
 
+普通 Agent 任务遇到网络、Gateway 或客户端短暂中断时，可在最近一次成功共识后的 5 分钟内沿用已验证 Owner；系统会限频重试刷新。5 分钟窗口按处理刷新失败时的缓存年龄判断。明确返回 `invalid`、`unbound`、`released`、`single_sided`、关系不匹配或锁状态不匹配时立即拒绝，不使用暂态 fallback。Ownership bind、accept/reject、transfer、release、绑定状态查询及 Owner 配置变更始终要求当前刷新成功。
+
 SDK 临时断线只更新连接状态，不清除已核验且仍在有效期内的共识缓存；普通读取仍按 30 分钟、敏感授权仍按 5 分钟窗口使用，断线不会延长有效期。断线前尚未完成的查询结果丢弃；缓存到期后若仍无法复核，不继续授权。客户端解绑或替换仍立即失效缓存。
 
-同一 subject 的并发刷新复用进行中的请求；事件发生前启动的旧查询不能覆盖事件后的结果。刷新失败不使用旧协议 Owner 授权，下次调用再重试，不启动后台周期重试；本地配置 Owner 和已认证 ECWeb 等独立授权来源不受此缓存替代。单次请求超时仍为 8 秒，不是 5 分钟或 30 分钟。
+同一 subject 的并发刷新复用进行中的请求；事件发生前启动的旧查询不能覆盖事件后的结果。暂态失败且缓存仍在 5 分钟窗口内时，普通授权可沿用该共识；窗口过期后仍无法刷新则拒绝。连接可用时刷新失败会限频后台复查，最短间隔 60 秒；断线恢复和所有权事件仍会立即触发复查。本地配置 Owner 和已认证 ECWeb 等独立授权来源不受此缓存替代。单次请求超时仍为 8 秒，不是 5 分钟或 30 分钟。
 
 关系快照与授权状态分离：`relation` 保留进程内最后一次确认的关系（Owner、核验时间、关系版本或已解除/未绑定状态），缓存过期、断线、事件失效或复核失败不会删除它。授权缓存仅在上述有效期和失效规则内可用，历史关系快照不用于补足已失效的授权。确认转移后替换 Owner，确认解除或未绑定后清除当前关系中的 Owner；仅凭超时、验签失败或单边声明不推断关系已经解除。历史快照不落盘，进程启动后重新确认。
 

package/kits/docs/evolcore/config.md

@@ -166,12 +166,14 @@ ec config set baseagents.codex.enableRequestUserInput false \
   --self bot.agentid.pub --peer aun#alice.agentid.pub
 ```
 
-该字段不是权限审批或 `request_user_input_async` 的关闭开关。异步问题由
-`agentMessage.questions` 事件自动映射为可回答卡片，允许选择选项或自由输入；
-Agent 可继续处理不依赖答案的工作。回答通过 Codex 原生 question-reply envelope
-提交：活动 turn 使用 `turn/steer`，已结束则通过持久队列恢复同一 Session 和 Codex thread。
-问题默认保留 24 小时，重启后恢复未回答卡片；会话绑定或授权变化后拒绝旧卡片回答。
-提交结果不明时不自动重发，避免重复回答。
+该字段不是权限审批或 `request_user_input_async` 的关闭开关。`agentMessage.questions`
+事件会映射为可回答卡片；问题默认 `blocking=true`，模型必须等用户主动选择或输入后才继续
+当前 turn。模型可显式设置 `blocking=false` 发送后台问题；这种问题不影响当前 turn。
+模型还可设置 `recommendedOption` 展示建议项，但建议不会产生用户答案。阻塞问题不设超时，
+卡片投递失败、取消或会话终止都不会自动选择选项。回答通过 Codex 原生 question-reply
+envelope 提交：活动 turn 使用 `turn/steer`，已结束则通过持久队列恢复同一 Session 和 Codex thread。
+问题重启后恢复未回答卡片；会话绑定或授权变化后拒绝旧卡片回答。提交结果不明时不自动重发，
+避免重复回答。
 
 支持卡片的客户端沿用 `action_card` / `action_card_reply`，自由输入沿用 `compose`。
 命令入口为 `/ask <问题ID> <回答>`；只有一个待回答问题时也可 `/ask <选项编号或回答>`。
@@ -240,7 +242,7 @@ Menu 批量请求遇到真实权限拒绝仍整体拒绝并停止执行，不会
   `role` 由角色分配服务维护；`permissionMode` 仅在角色策略中维护
 - **兼容字段**：`enable_rich_content` 仍可读取旧值，但已废弃且不再产生运行时效果
 - **群规则策略**：`groupRules.mode` 仅当前 Agent 的实际 owner 可 set/unset；DaemonOwner 不继承群或 relation 写权限，其他角色可读取当前 relation 的有效值
-- **Agent fullaccess 策略**：Agent 配置中的 `fullaccess.enabled` 缺失时关闭。已认证的 EC Web Agent 设置可修改；Menu 可经 Agent AID 管理自身，或经 daemon Control AID 以 `args.aid` 指定目标 Agent，Menu 写入要求同一请求者同时是目标 Agent Owner 与 daemon Owner。CLI 和托管任务的 set/unset 均拒绝。双 Owner（Agent Owner + daemon Owner）条件在实际私聊任务执行时再次校验。`/fa`、`/fullaccess` 和 Fullaccess Trigger 不依赖此 Agent 级开关，而由各自的 daemon Owner 鉴权与批准链控制。
+- **Agent fullaccess 策略**：Agent 配置中的 `fullaccess.enabled` 缺失时关闭。Menu 写入要求请求者同时是目标 Agent Owner 与 daemon Owner。`/fa`、`/fa on`、`/fa off`（`/fullaccess` 为别名）只管理当前私聊 EC 会话；主会话写 Agent 配置，话题会话写 session metadata，群聊拒绝。每次 Runner 执行仍复核双 Owner、会话绑定和 fullaccess 能力；CLI 和托管任务不能直接 set/unset Agent fullaccess。Fullaccess Trigger 使用独立的持久授权链。
 - **源码诊断白名单**：`readonlySourceDiagnostics` 默认关闭；开启后只读会话仅可在项目源码目录执行受限、可证明只读查询，配置/证书/快照/session/锁文件仍禁止访问
 - **仅人可写**：channels / owners / admins / 凭证 / aid / enabled / projects / aun / models.allowed
 - Agent 托管环境写仅人字段被拒

package/kits/docs/evolcore/memory-architecture.md

@@ -27,12 +27,11 @@ relation 是所有记忆的唯一出生地，agent 级和 owner 级都由它升
 |------|------|
 | 上下文压缩前 | 自动。反馈回压缩时的会话和话题 |
 | renew / 新会话创建时 | 自动。反馈回发起时的会话和话题 |
-| 定时检查 | 自动。由 evolcore trigger 的 `script` 模式周期执行，检查 pending 堆积、待泛化 / 待提升 / 超期记忆 / 画像超期五类候选；**不反馈** |
+| 关系空闲 / 兜底 | 自动，**主路径**。一个关系空闲 `idleHours`（默认 1 小时）或最早未整理入站满 `maxUnconsolidatedHours`（默认 8 小时），对该关系依次跑 notes → generalize → promote → profile → forget；**不反馈** |
+| 定时检查 | 自动。只管 agent 层 / owner 层 forget，外加 pending 堆积兜底（转成该关系的整理链）；**不反馈** |
 | 手动 | `ec memory consolidate [--mode ...]`。反馈回当前会话的当前话题 |
 
-所有触发路径都收口到统一入口 `launchConsolidation()`，它负责完整生命周期：启动前把 `pending/` 移入 `processing/` 加锁、序列化上下文、直接创建整理会话、会话结束后收尾（归档 note、写 checkpoint、定稿重建索引、反馈）。
-
-触发方分两层：**定时检查**由 trigger 的 `script` 模式承担，只做候选判断，不管理生命周期；**手动 / compact / renew / `/new`** 直接调用 `launchConsolidation()`。
+**整理一律以关系为单位**，一个会话只处理一个关系；群聊按群算一个关系。所有触发路径都收口到统一入口 `launchConsolidation()`，它负责完整生命周期：启动前把 `pending/` 移入 `processing/` 加锁、序列化上下文、直接创建整理会话、会话结束后收尾（归档 note、写 checkpoint、定稿重建索引、反馈）。
 
 **并发与排队**：同一 agent 同时只能有一个整理会话；全局最多 5 个 agent 并发。超出的请求排队，前一个结束后自动启动下一个。
 

package/kits/docs/evolcore/memory-consolidation.md

@@ -35,11 +35,12 @@
 
 **它是唯一能产生正式记忆的地方。** 主会话只能写 note（原料），正式记忆的增删改全部由整理会话完成。
 
-**统一入口 `launchConsolidation()`**：所有触发路径——手动调用、定时检查、上下文压缩、renew / `/new`——都收口到这一个函数。它负责整理的完整生命周期：启动前把 `pending/` 加锁移入 `processing/`，序列化上下文文件，**直接创建整理会话**，会话结束后通过 `onConsolidationComplete` 处理收尾（归位、checkpoint、定稿索引、反馈）。
+**统一入口 `launchConsolidation()`**：所有触发路径——关系整理链、手动调用、定时检查、上下文压缩、renew / `/new`——都收口到这一个函数。它负责整理的完整生命周期：启动前把 `pending/` 加锁移入 `processing/`，序列化上下文文件，**直接创建整理会话**，会话结束后通过 `onConsolidationComplete` 处理收尾（归位、checkpoint、定稿索引、反馈）。
 
-**触发方分两个层次**：
-- **定时检查**：由 evolcore trigger 的 `script` 模式每小时执行一次，检查五类候选（notes / generalize / promote / profile / forget），符合条件就拉起整理会话。检查器只做判断，不承载生命周期。
-- **手动 / compact / renew / `/new`**：直接调用 `launchConsolidation()`，不经检查器。
+**整理一律以关系为单位**，一个会话只处理一个关系。触发方：
+- **关系整理链**（主路径）：每个关系一个计时器。最后一条入站后空闲 `idleHours`（默认 1 小时），或最早一条未整理入站满 `maxUnconsolidatedHours`（默认 8 小时），对该关系依次跑 notes → generalize → promote（仅 owner 关系）→ profile → forget，每步收尾后再判定下一步，没有候选就跳过。触发来源 `relation-idle`，**不反馈**。只计真实入站（含群里未被 @ 的消息；owner 插话不算）。
+- **定时检查**：evolcore trigger 的 `script` 模式每小时执行，只管不属于任何关系的部分——agent 层、owner 层的 forget；外加兜底，pending 堆积超过 `backlogHours` 的关系转成该关系的整理链。
+- **手动 / compact / renew / `/new`**：直接对当前关系调用 `launchConsolidation()`。
 
 **并发与排队**：同一 agent 同时只能有一个整理会话在跑；全局最多 5 个 agent 并发。超出的请求排队，前一个结束后自动启动下一个。
 
@@ -69,13 +70,27 @@
 
 ```bash
 ec memory create --scope <relation|agent|owner> --slug <slug> --desc '一句话描述' \
-  --tags '<tag1>,<tag2>' [--keywords '<kw1>,<kw2>'] [--replaces '<路径1>,<路径2>'] '<正文>'
+  --tags '<tag1>,<tag2>' [--keywords '<kw1>,<kw2>'] [--replaces '<路径1>,<路径2>'] \
+  [--reason '<为什么>'] [--generalized-from '<路径>'] [--promoted-from '<路径>'] '<正文>'
 ```
 
 - 程序负责写入 `consolidated/`、登记完整性台账、重建索引。
 - `--replaces` 指定的旧文件会被自动归档——**合并、纠正内容、升格作用域都走这条路径**，一次调用完成，不会出现「新的写了、旧的没归档」的重复记忆。
 - **目标 slug 已存在且未在 `--replaces` 里列出 → 拒绝**，报错回传已有文件路径。这是防止漏用 `--replaces` 导致静默覆盖的闸门。
 - **正文上限 10KB**，超出报 `MEMORY_TOO_LARGE`。这不是技术限制，而是记忆的性质决定的：一条记忆应当是**一句话能说清的结论**。内容确实那么多时，拆成多条分别 `create`，或把细节留在归档文件里、记忆只记结论。
+- `--reason` 写进批次目录的 `ops.jsonl` 操作流水，不进记忆正文。结论属于记忆，判断依据属于过程记录。
+
+### 跨层路径
+
+generalize / promote 的产出在 agent / owner 层，候选（源文件）在本关系。候选清单里的路径形如 `<peerKey>/consolidated/xxx.md`，直接照抄即可：
+
+| 写法 | 解析到 |
+|---|---|
+| `slug` / `<slug>.md` | 本作用域 `consolidated/` |
+| `consolidated/xxx.md` | 本作用域 `consolidated/` |
+| `<peerKey>/consolidated/xxx.md` | 本次会话所属关系的 `consolidated/`（peerKey 必须是本次会话所属关系） |
+
+带前缀的形态是在产出层操作本关系源文件的方式。不带前缀的 `consolidated/xxx.md` 一律指本次产出所在层——两者不会混淆。归档**跟随源文件所在层**：关系级记忆进关系自己的 `archive/consolidated/`，所以 `ec memory restore` 能按作用域捞回来。
 
 ### update — 只改标签
 
@@ -84,6 +99,8 @@ ec memory update <路径> --tags '<tag1>,<tag2>'       # 整体替换标签
 ec memory update <路径> --touch                   # 刷新 mtime 与 updatedAt，用于续期
 ```
 
+`--reason '<为什么>'` 同样可加，进 ops 流水。
+
 **update 不能改正文。** 内容一变，描述和关键词都得跟着变，那就应该 create 一条新的。它剩下的场景都是正文不变、只有状态变的：
 
 | 场景 | 改法 |
@@ -97,11 +114,13 @@ ec memory update <路径> --touch                   # 刷新 mtime 与 updatedAt
 ### archive — 归档
 
 ```bash
-ec memory archive <路径...>
+ec memory archive <路径...> [--reason '<为什么>']
 ```
 
 **没有删除，只有归档。** 文件移入 `archive/`，可人工回捞。用于：合并后多出来的旧文件、已经过时的记忆。
 
+归档落点跟随**源文件所在层**：关系级记忆进 `relations/<peerKey>/memory/archive/consolidated/`，agent 级进 `personal/memory/archive/consolidated/`。这样 `ec memory restore` 按作用域就能找到它。
+
 ---
 
 ## 四、权限校验
@@ -120,6 +139,8 @@ daemon 按整理会话的模式校验 `--scope`：
 
 **其他写入限制**：
 
+- **整理一律以关系为单位：带前缀的路径里 peerKey 必须是本次会话所属关系**，所有模式都一样。整理会话的可读根只含当前关系的 `consolidated/`，允许写别的关系等于对读不到的目录做归档，绕过 grants 边界。没有所属关系的会话（owner 层 / agent 层 forget）不接受带前缀的路径。
+- 唯一的例外是群聊 notes 的 `--peer`：按发言人把记忆写进发言人自己的关系。被写入的关系在群的整理链结束后会各补一轮整理。
 - `profile` 标签的记忆，一个关系只能有一条。重新生成必须用 `--replaces` 指定旧的那条。
 - `to-promote` 只能打在对端是 owner 的关系上。群聊关系额外检查发言人身份，owner 本人说的话可以打。
 - 全局总开关是 `memory.enableRelation`。它关闭时，五种模式和手动调用全部拒绝。
@@ -135,7 +156,7 @@ daemon 按整理会话的模式校验 `--scope`：
 **`notes` 模式**的输入是：
 
 - `pending/` 里的全部 note
-- 会话历史（`triggeredBy` 为 `compress` / `session-new` / `manual` 时可用；`periodic-trigger` 触发的补漏整理没有会话历史，只能凭 note 本身判断）
+- 会话历史（整理会话带了该关系的路由时生成话题快照：`compress` / `session-new` / `manual`，以及关系整理链 `relation-idle`；没有路由的补漏整理没有会话历史，只能凭 note 本身判断）
 - 现有的 `MEMORY.md` 索引（查重用）
 
 **`launchConsolidation()` 在拉起整理会话之前会把 `pending/` 整体 rename 到 `processing/`**，相当于加锁声明认领。整理过程中主会话新写的 note 落在 `pending/`，不会被这次整理误伤，也不会被误删。

package/kits/docs/evolcore/memory-tags.md

@@ -60,6 +60,6 @@ tags: [important, long-term, rule, verified]
 **清标的两种方式**：
 
 - 升级成功 —— 源文件被 `--replaces` 归档，标签随文件一起消失。
-- 评估后认为不该升级 —— 用 `update` 去掉标签，否则每次定时检查都会重新扫到它。
+- 评估后认为不该升级 —— 用 `update` 去掉标签，否则该关系下次整理还会扫到它。
 
 **限制**：`to-promote` 只能打在对端是 owner 的关系上。其他对端打这个标签会被拒绝——否则它会永远挂在磁盘上没人处理。群聊关系下额外检查发言人身份，owner 本人说的话可以打。

package/kits/docs/evolcore/memory.md

@@ -73,7 +73,7 @@ ec memory consolidate [--mode <notes|generalize|promote|profile|forget>]
 | `generalize` | 关系级 → agent 级 | 对端说「不管跟谁聊你都要记得这个」 |
 | `promote` | 关系级 → owner 级 | owner 说「让我所有 Agent 都记住这个」 |
 | `profile` | 生成/重建当前对端画像 | owner 说「重新生成一下画像」 |
-| `forget` | 评估超期记忆续期或归档 | 一般不手动，由定时检查发起 |
+| `forget` | 评估超期记忆续期或归档 | 一般不手动：关系层由关系整理链发起，agent / owner 层由定时检查发起 |
 
 **命令是异步的**：`launchConsolidation()` 在拿到整理会话的 base agent 会话 ID 后命令即退出，不等整理会话完成。输出示例：
 

package/kits/docs/evolcore/menu-client.md

@@ -23,7 +23,7 @@ ec menu-client request <from-aid> <daemon-aid> \
 
 ## 鉴权入口
 
-- 默认授权是远端 `daemon.json.owners` 对发送 AID 的校验。
+- 默认授权是远端 `daemon.json.owner` 对发送 AID 的校验。
 - `--remote-token <token>` 使用 daemon 签发的远程访问 token，权限与 daemon-owner 一致。CLI 审计日志不会记录 token 明文。
 - `--ecweb-token <token>` 是 `--remote-token` 的兼容别名。
 - `system/paircode` 例外：仅接受加密的 daemon-owner 请求，已有 remote token 不能换取新配对码。

package/kits/docs/evolcore/menu-protocol.md

@@ -126,6 +126,12 @@ Menu Protocol 是 EvolCore 在 AUN `message.send` 之上建立的**应用层协
 `idleSeconds`。查询使用 `menu.query`、`name="session"`、`args.view="loop"`，返回值会标明
 实际目标级别 `relation-main` 或 `topic-session` 及 `sessionId`。
 
+`name="session"` 且 `args.resource="fullaccess"` 时，`value` 必须是 JSON boolean。
+它只作用当前私聊 EC 会话：主会话写入 Agent 级 `fullaccess.enabled`，话题会话写入
+该 session 的 `sessionFullAccess` metadata；群聊拒绝。查询使用
+`menu.query`、`name="session"`、`args.view="fullaccess"`。写入要求同一请求者同时是
+当前 Agent Owner 与 daemon Owner。
+
 ### `menu.action`
 
 触发动作类命令（如创建 agent、重启、生成配对码）。**不自动重试**。

package/kits/docs/evolcore/msg.md

@@ -84,7 +84,7 @@ 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` 默认只允许回复当前对端；要联系当前对端以外的对象，必须通过话题路由：先 `ec thread list <对方AID>` 选话题（没有就 `ec thread create`），再用 `ec msg send '<text>' --thread <threadId> --check-every <时长>` 发送；from/to 由话题推断，无需手写。不带 `--thread` 直接改目标会被拒绝。`--check-every` 到期后，系统会向**目标话题**投递一条【跨话题复查】通知（不新建会话），由目标话题侧的 agent 在自己的上下文里决定结束、调整周期或继续。完整话题路由操作序列见 `[memory-and-thread]` 段。没有成功 JSON 回执（含 `message_id`/`status`）不得声称已发送。
+在 EvolCore 会话内，发送会经过当前 session 的 self/peer/role 鉴权。`visitor` 或 `member` 默认只允许回复当前对端；要联系当前对端以外的对象，必须通过话题路由：先 `ec thread list <对方AID>` 选话题（没有就 `ec thread create`），再用 `ec msg send '<text>' --thread <threadId> --check-every <时长>` 发送；from/to 由话题推断，无需手写。不带 `--thread` 直接改目标会被拒绝。`--check-every` 到期后，系统会向**目标话题**投递一条【跨话题复查】通知（不新建会话），由目标话题侧的 agent 在自己的上下文里决定结束、调整周期或继续。完整话题路由操作序列见 `[thread]` 段。没有成功 JSON 回执（含 `message_id`/`status`）不得声称已发送。
 
 成功输出：`✓ 已发送 <message_id> seq=<n> status=<status>`
 

package/kits/eck_manifest.json

@@ -348,9 +348,9 @@
       "description": "客户端环境文档"
     },
     {
-      "id": "memory-and-thread",
+      "id": "thread",
       "type": "file",
-      "file": "$KITS_RULES/07-memory-and-thread.md",
+      "file": "$KITS_FRAGMENTS/thread.md",
       "order": 46,
       "needsInjection": false,
       "when": {
@@ -368,7 +368,7 @@
           }
         ]
       },
-      "description": "记忆与话题：持久化上下文的两套机制（memory + thread）"
+      "description": "话题系统：话题列表/历史、跨话题发送、命名、摘要与状态"
     },
     {
       "id": "reply-contract",

package/kits/rules/04-relation.md

@@ -66,8 +66,9 @@ relations/
 | none | — | — | 无有效关系角色，拒绝访问 |
 
 角色实际存储在 `relations/<peerKey>/config.json` 的 `role` 字段。进程级 `daemon-owner` 与这里的
-Agent/relation 角色正交，不会在 auth 层提升为 `owner`；只有 Agent 自身的 owner 配置和关系解析
-结果可以授予 `owner`。DaemonOwner 仅获得明确列入进程控制面的操作权限。
+Agent/relation 角色正交，不会在 auth 层提升为 `owner`；AUN 的 Owner 只能由当前 Agent AID 的
+Ownership 2.1 新鲜共识确认，daemon/Agent 根配置和手写 relation.role 都不授予 Owner。
+DaemonOwner 仅获得明确列入进程控制面的操作权限。共识未知时不回退旧配置；非 AUN 渠道保持现有规则。
 
 **兜底链**：无匹配角色 → 回落内置 `visitor`（即 `readonly`）；只有角色注册表本身缺失、
 或 `visitor` 未注册时才落到 `none` 拒绝访问。所以正常配置下几乎总是降权到只读，而不是拒绝。

package/kits/schemas/agent-config.schema.13.json

@@ -603,7 +603,11 @@
         },
         "idleHours": {
           "type": "number",
-          "description": "空闲时长阈值（小时），超过此值才允许定时触发整理。默认 4。"
+          "description": "关系空闲时长（小时）：一个关系最后一条入站后这么久没有新入站，触发该关系的整理链。默认 1。"
+        },
+        "maxUnconsolidatedHours": {
+          "type": "number",
+          "description": "关系兜底整理时长（小时）：一个关系最早一条未整理的入站满这么久，即使仍在聊也触发整理链。默认 8。"
         },
         "checkIntervalHours": {
           "type": "number",

package/kits/templates/memory-consolidation/generalize.md

@@ -39,10 +39,13 @@
 - 关于对端这个人的描述（那些该走 `profile` 模式）。
 - 只在特定项目、特定环境、特定对端身上成立的结论。
 
-**评估后认为不该泛化的，用 `update` 把 `to-generalize` 标签去掉。** 否则每次定时检查都会重新扫到它，反复评估同一条。
+**评估后认为不该泛化的，用 `update` 把 `to-generalize` 标签去掉。** 否则该关系下次整理还会扫到它，反复评估同一条。
+
+关系级记忆的路径要带上来源关系前缀（`<peerKey>/consolidated/<文件名>`，就是候选清单里给的那个路径）：
 
 ```bash
-ec memory update <关系级记忆路径> --tags '<去掉 to-generalize 后的标签>'
+ec memory update '<peerKey>/consolidated/20261002-xxx.md' --tags '<去掉 to-generalize 后的标签>' \
+  --reason '评估后认为只对该对端成立，不具普遍性'
 ```
 
 ### 已经存在同类 agent 级记忆
@@ -52,16 +55,39 @@ ec memory update <关系级记忆路径> --tags '<去掉 to-generalize 后的标
 ```bash
 ec memory create --scope agent --slug commit-chinese --desc 'commit 消息用中文' \
   --tags 'rule,long-term' --keywords 'commit,git' \
-  --replaces 'consolidated/20260901-120000-commit.md,$RELATIONS_DIR/<peerKey>/memory/consolidated/20261002-103100-commit-chinese.md' \
+  --replaces 'consolidated/20260901-120000-commit.md,<peerKey>/consolidated/20261002-103100-commit-chinese.md' \
+  --generalized-from 'relations/<peerKey>/memory/consolidated/20261002-103100-commit-chinese.md' \
+  --reason '该结论抽掉对端后仍成立，与已有 agent 级条目合并' \
   "（合并后的完整内容）"
 ```
 
+`--replaces` 里两种路径可以混用：不带前缀的是 agent 级（本次产出所在层），带 `<peerKey>/` 前缀的是该关系的记忆。关系级那条会被归档到**它自己那一层**的 `archive/consolidated/`。
+
+`--generalized-from` 记录来源，写的是相对 `agents/<selfAid>/` 的路径；`ec memory demote` 靠它把这条记忆退回关系级。
+
 ## 泛化之后
 
 **源文件会被归档，不在关系级保留副本。** 这是有意的：同一条结论若在关系级和 agent 级各留一份，就成了同一事实的两个来源，上层改动要同步下层，正是本设计要清掉的那类冗余。
 
 对端之后看不到这条内容了——但它本来就不是针对这个对端的具体事实，而是通用规律，留在 agent 级对所有对端生效。
 
+### 泛化实际会做哪些文件动作
+
+泛化不是"复制一份到上层"，而是**由你重写正文 + 归档源文件**。系统只有三个原子操作，合并/拆分都是组合出来的：
+
+| 你要的效果 | 怎么组合 |
+|---|---|
+| 单条升格 | `create --scope agent` + `--replaces '<peerKey>/consolidated/x.md'` + `--generalized-from` |
+| 合并多条 | `create` 时 `--replaces` 列出全部来源（可跨层混写），一次调用完成 |
+| 拆分多条 | 多次 `create`，最后 `archive` 掉原来那条 |
+| 单纯下线 | `archive` |
+
+没有"复制"这一步，也没有删除——`archive/` 里留底，可人工回捞。
+
+**正文必须重写，不能照抄。** 关系级记忆里常有"对端要求…""这个项目里…"这类限定，泛化后要抽掉对端的具体信息，只留通用的结论；否则升上去的仍是一条带条件的记忆，对别的对端不成立。
+
+每次写操作都带 `--reason '一句话说明为什么'`，它进 `ops.jsonl` 的操作流水。理由不写进记忆正文——结论属于记忆，判断依据属于过程记录。
+
 ## 泛化后还要考虑打 `to-promote` 吗
 
 不要在一次会话里连做两级升级。`generalize` 模式只负责产出 agent 级记忆；如果它同时也是 owner 定下的规矩，**在产出时给 agent 级那条打上 `to-promote`**，让下一次提升模式的会话去评估。分两次做，每次的判断依据更清楚。
@@ -70,10 +96,12 @@ ec memory create --scope agent --slug commit-chinese --desc 'commit 消息用中
 
 扫描 agent 级 `consolidated/` 时，遇到带 `generalizedFrom` 字段的记忆，判断它是否仍然成立：
 
-**考虑降级（`ec memory demote <slug>`）的情形：**
+**考虑降级的情形**（本会话做不了，记录后交给主会话执行 `ec memory demote <slug>`）：
 - 这条结论后来被证明只对特定对端成立，不具备普遍性
 - 来源关系已结束或被删除，这条 agent 级记忆失去了来源依据
 
+降级要同时搬动两层索引，不适合在泛化会话里顺手做——整理会话只有 create / update / archive 三个写命令。
+
 **考虑归档（`ec memory archive <path>`）的情形：**
 - 内容已过时，既不适合保留在 agent 级，也没有降级的价值
 - 与另一条 agent 级记忆高度重复，合并后旧条目可以归档

package/kits/templates/memory-consolidation/notes.md

@@ -11,7 +11,7 @@
 | 来源 | 位置 | 说明 |
 |---|---|---|
 | note | 上下文文件里的 `pendingDir` 对应 `processing/` 目录 | 主会话在对话中随手记下的原料：可能重复、可能矛盾、可能有错 |
-| 会话历史 | 上下文文件里的 `threads/` 快照目录 | `triggeredBy` 为 `manual` / `compress` / `session-new` 时完整可用，**应当读取**；`periodic-trigger` 时不可用，只能凭 note 本身判断 |
+| 会话历史 | 上下文文件里的 `threads/` 快照目录 | 上下文文件列出了「话题快照文件」时可用，**应当读取**（`manual` / `compress` / `session-new` 以及多数 `relation-idle`）；没列出时（`periodic-trigger` 补漏、没有入站记录的关系）只能凭 note 本身判断 |
 | 已有记忆 | 目标作用域的 `MEMORY.md` 索引 | 查重 |
 
 ## 产出
@@ -130,4 +130,4 @@ note 是零散的竖切面，会话历史能补上上下文——某条 note 是
 
 ## 周期补漏的特殊情况
 
-`triggeredBy` 为 `periodic-trigger` 时没有会话历史——这是针对「聊一次就再也没出现的对端，note 一直堆着没人整理」的补漏整理。此时只能凭 note 本身的内容判断，**标准放严一些**：note 里没写清楚、脱离了上下文看不懂的，宁可不写，让它留在原地将来再处理。
+上下文文件里没有话题快照时（`periodic-trigger` 的 pending 堆积补漏、没有入站记录的关系）没有会话历史可读。此时只能凭 note 本身的内容判断，**标准放严一些**：note 里没写清楚、脱离了上下文看不懂的，宁可不写，让它留在原地将来再处理。

package/kits/templates/memory-consolidation/promote.md

@@ -58,18 +58,26 @@ daemon 会检查：
 ec memory create --scope owner --slug no-self-commit \
   --desc '任何 agent 都不许自己提交代码' \
   --tags 'prohibition,important,long-term' --keywords 'commit,权限' \
-  --replaces '$RELATIONS_DIR/<ownerPeerKey>/memory/consolidated/20261002-153000-no-self-commit.md' \
+  --replaces '<ownerPeerKey>/consolidated/20261002-153000-no-self-commit.md' \
+  --promoted-from 'relations/<ownerPeerKey>/memory/consolidated/20261002-153000-no-self-commit.md' \
+  --reason 'owner 明确要求所有 agent 都遵守，属于 owner 级规矩' \
   "owner 明确要求：所有 agent 都不许自己执行 git commit，必须由 owner 确认后才能提交。"
 ```
 
+关系级源文件的路径带 `<ownerPeerKey>/consolidated/` 前缀（就是候选清单里给的那个路径），归档会落到该关系自己那一层的 `archive/consolidated/`。
+
+`--promoted-from` 记录来源，写相对 `agents/<selfAid>/` 的路径；`ec memory demote` 靠它把这条记忆退回 agent 级。
+
 ## 顺便检查：已有 owner 级记忆是否需要降级或归档
 
 扫描 owner 级 `consolidated/` 时，遇到带 `promotedFrom` 字段的记忆，判断它是否仍然成立：
 
-**考虑降级（`ec memory demote <slug>`）的情形：**
+**考虑降级的情形**（本会话做不了，记录后交给主会话执行 `ec memory demote <slug>`）：
 - 这条规矩已被 owner 撤销，只对特定 agent 有效，不再是所有 agent 的通用规则
 - 来源的 agent 级记忆已不存在，且 owner 级内容已过时
 
+降级要同时搬动两层索引，不适合在提升会话里顺手做——整理会话只有 create / update / archive 三个写命令。
+
 **考虑归档（`ec memory archive <path>`）的情形：**
 - 规矩已废除，不适合保留在任何层级
 - 与另一条 owner 级记忆高度重复，合并后旧条目可以归档

package/kits/templates/system-fragments/baseagent.md

@@ -12,3 +12,8 @@ modelFallbackActive: true # evolcore 配置的模型不可用，当前正在使
 {{?agentSessionId}}
 agentSessionId: {{agentSessionId}} # 底层引擎的会话 ID（区别于 evolcore sessionId）
 {{/}}
+
+当运行时支持结构化用户问题时：`questions[].blocking` 省略时按 `true` 处理；只有当前工作可以独立
+继续且不依赖用户选择时才显式设为 `false`。阻塞问题会一直等待，直到用户选择/输入或会话被取消，
+没有等待超时。可用 `questions[].recommendedOption` 标注一个与选项文本完全相同的建议项；建议仅作
+展示提示，绝不能视为用户选择，也不能自动回答或继续依赖该答案的操作。

package/kits/templates/system-fragments/memory.md

@@ -11,8 +11,9 @@
 -   偏好/习惯：我喜欢、我不喜欢、我偏好、我习惯
 -   约束/禁止：不要、禁止、避免、别再、不允许
 -   规则/注意：注意、当心、以后、每次、必须、务必
--   纠错反馈：错了、不对、应该是、你搞错了  
-    不写：会话内临时信息；隐私信息。  
+-   纠错反馈：错了、不对、应该是、你搞错了
+-   自己发现的规律：对端的工作方式、反馈模式等跨会话有用的观察  
+    不写：会话内临时信息；隐私信息；当前话题的进展（写话题摘要，见 `[thread]` 段）；代码结构、文件路径、git 历史（代码库本身就记录了）。  
     **每轮审查（静默）**：每轮结束前扫描完整会话上下文（含历史轮次），检查有无通过判据但未记录的信息，或已有 note 需更新。  
     **命令**（`--slug` 必填，字母/数字/连字符，1-64 字符，当前关系内唯一）：
 
@@ -44,12 +45,17 @@ slug 撞名改用 `update`。完整用法见 `$KITS_DOCS/evolcore/memory.md`。
 
 ```bash
 ec memory create --scope <relation|agent|owner> --slug <slug> --desc '一句话描述' \
-  [--peer <peerKey>] --tags '<tag1>,<tag2>' [--keywords '<kw1>,<kw2>'] [--replaces '<路径1>,<路径2>'] '<正文>'
+  [--peer <peerKey>] --tags '<tag1>,<tag2>' [--keywords '<kw1>,<kw2>'] [--replaces '<路径1>,<路径2>'] \
+  [--reason '为什么'] [--generalized-from '<路径>'] [--promoted-from '<路径>'] '<正文>'
 ec memory update <路径> --tags '<tag1>,<tag2>'      # 整体替换标签，不是追加；改不了正文
 ec memory update <路径> --touch                  # 只刷新时间戳（遗忘续期）
 ec memory archive <路径...>                      # 下线记忆，移入 archive/
 ```
 
+泛化 / 提升专用：`--generalized-from <路径>`（scope=agent）、`--promoted-from <路径>`（scope=owner）记录来源，供 `ec memory demote` 回退。值为相对 `agents/<selfAid>/` 的路径。
+
+**跨层路径**：候选清单里的路径形如 `<peerKey>/consolidated/xxx.md`，直接照抄即可——它解析到本次会话所属关系的记忆，归档也落在该关系自己的 `archive/`。peerKey 只能是本次会话所属关系。不带前缀的 `consolidated/xxx.md` 一律指本次产出所在层。
+
 整理结束后，把本次整理的整体反馈写入任务书里指定的**反馈文件路径**。未写入则收尾时回退到默认统计模板（模式、触发方式、耗时、新建/更新/归档条数等）。
 
 自由文本参数（`--desc`、正文、`--keywords`）用**单引号**包住（`'…'`）；
@@ -63,6 +69,9 @@ ec memory archive <路径...>                      # 下线记忆，移入 archi
 | --tags | 必填，取值见 $KITS_DOCS/evolcore/memory-tags.md |
 | --keywords | 可选，串起相关记忆的内容关键词 |
 | --replaces | 可选，要替换的旧文件，自动归档。合并、纠正、升格作用域都走它，是唯一的防重复手段 |
+| --reason | 可选但应当写：一句话说明为什么做这个操作。进 ops.jsonl 的操作流水，不写进记忆正文 |
+| --generalized-from | 仅 scope=agent：泛化来源，相对 `agents/<selfAid>/` 的路径，供 demote 回退 |
+| --promoted-from | 仅 scope=owner：提升来源，相对 `agents/<selfAid>/` 的路径，供 demote 回退 |
 
 `--tags`、`--keywords`、`--replaces` 的值写成单引号包住、逗号分隔：`--tags 'rule,long-term'`、`--replaces 'consolidated/a.md,consolidated/b.md'`。
 

package/kits/templates/system-fragments/session.md

@@ -38,7 +38,7 @@ readonly: true — 禁止写入项目目录及临时目录；如需生成文件
 {{/}}
 # 决定响应后：
 # 命令速查：
-# 每次工具调用只执行一条完整的 ec 命令；禁止 command -v。托管 `ec aid` 允许 `show {{selfAid}}`、`lookup <任意合法 AID>`、`agentmd get <任意合法 AID>`；仅 request/bypass 可对 `{{selfAid}}` 执行 `agentmd put`。可选后缀仅限 --format json；禁止 &&、||、;、|、重定向、子 shell、bash -lc/sh -c 或其它脚本与其串联。
+# 每次工具调用只执行一条完整的 ec 命令；禁止 command -v。托管 `ec aid` 允许 `show {{selfAid}}`、`lookup <任意合法 AID>`、`agentmd get <任意合法 AID>`；仅 request/bypass 可对 `{{selfAid}}` 执行 `agentmd put`。可选后缀仅限 --format json；禁止 &&、||、;、子 shell、bash -lc/sh -c 或其它脚本与其串联。Bash 下输出过长时，可在 ec 后接只读 stdin 的过滤管道收窄输出，或用 `> $TMPDIR/<新文件>` 存盘后另行处理；PowerShell/cmd 下两者都不支持。
 # 审批拒绝时原样报告并停止；必须收到包含 message_id/status 的成功回执后才能声称已发送。
 {{?chatType=group}}
 #   群内公开发送用 ec group send；语法与选项见 [channel] 段。