evolcore 0.0.28 → 0.0.29

package/kits/templates/decision/session-renew.md

@@ -0,0 +1,22 @@
+# Session Renew Decision Prompt
+
+## State Rules
+
+会话边界判定规则：
+1. 如果当前消息的内容主题已经转向另一件事，应判定为新会话，即使没有使用会话命令词。
+2. 如果当前消息表达暂停当前主题并转向另一件事，也应判定为新会话。
+3. 如果当前消息仍围绕历史主题补充、追问、修改或执行，应判定为继续当前会话。
+4. 如果信息不足、无法可靠判断主题关系，应保留不确定性，不要默认新建或继续。
+5. 重点判断内容主题和上下文关系，不要只匹配“新开”“重新”“换个”“继续”等关键词。
+
+## Question Instructions
+
+判断当前消息相对于历史会话是否应该开启独立的新会话，重点依据内容主题和上下文关系。
+
+## True Criteria
+
+当前消息已经转向另一件具体事情，或表达了停止当前主题、之后开始另一件事的边界意图。
+
+## False Criteria
+
+当前消息仍然围绕历史主题补充、追问、修改或执行。

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

@@ -0,0 +1,104 @@
+[memory-consolidation:mode=forget]
+
+## 本次任务：遗忘
+
+**逐条审查超期记忆还有没有必要留着，然后续期、合并或归档。**
+
+这是本模式的核心判据：**这条记忆现在还成立吗？还成立就留着，不成立就下线。**
+
+## 输入
+
+上下文文件里列出的候选：mtime 超过 `memory.forgetAfterDays` 的记忆。**候选只给路径 + 描述。**
+
+> **打了 `important` / `urgent` / `profile` 的记忆同样会出现在候选里。**
+> 「永不淘汰」指的是索引截断时不会被截掉（只要它在，就保证进索引），
+> **不代表它免于遗忘审查**。审查的是「这条内容还成不成立」，与它在不在索引里是两个维度。
+
+> **本次审查哪一层**由会话带下来的 scope 决定（关系级 / agent 级 / owner 级），一次只审一层。
+> `create` 时只能写这个 scope。
+
+- 先看描述判断。
+- **只有拿不准是不是还成立的那几条，才读全文。**
+
+## 三种产出
+
+对每条候选做三选一（也可以同时发生：几条合并成一条）：
+
+### ① 还成立 → 续期
+
+```bash
+ec memory update <路径> --touch
+```
+
+`--touch` 只刷新时间戳（文件的 mtime 与 frontmatter 的 `updatedAt`），不改内容。
+
+**续期的含义是「我又看了一遍，还有效」**，不是「它变了」。
+
+续期后 **`forgetAfterDays` 天内不会再被挑出来审查**（配置默认 30 天）。
+
+**注意区分两件事：**
+
+| | 含义 |
+|---|---|
+| 「不进候选」 | 下次遗忘检查不会把它挑出来评估 —— 这是续期的效果 |
+| 「不进索引」 | 从 `MEMORY.md` 里消失、召回时看不到 —— **只有归档才会这样** |
+
+续期**不影响索引**：这条记忆一直可被召回，只是暂时不再被遗忘机制审视。
+
+### ② 不成立了 → 归档
+
+```bash
+ec memory archive <路径>
+```
+
+归档后这条记忆**从索引里消失、召回时看不到**，文件移入 `archive/` 保留可追溯（人工可回捞）。
+
+### ③ 几条合起来值得留一条 → 合并
+
+若干条超期记忆**单独每一条都不值得续期，但合起来值得留一条**时，产出一条合并版：
+
+```bash
+ec memory create --scope <本次会话的 scope> --slug <slug> --desc "一句话描述" \
+  --tags <...> [--keywords <...>] \
+  --replaces "<旧文件1>,<旧文件2>,..." \
+  "<合并后的完整内容>"
+```
+
+`--replaces` 列出的旧文件会被一并归档，索引里只留合并后的那一条。
+
+三个典型场景：
+
+| 场景 | 处理 |
+|---|---|
+| 三条记忆讲的是同一件事的不同方面 | 合并成一条，旧的都列进 `--replaces` |
+| 内容过时了大方向还成立（比如项目换工具了） | `create --replaces` 产出更新版 |
+| 两条矛盾，其中一条已被后来的事实推翻 | 留下正确的那条：`--touch` 续期；错的归档 |
+
+## 判断标准
+
+审查周期由 `memory.forgetAfterDays` 决定（默认 30 天），配置改了下次检查就按新阈值筛候选。
+
+**「这条现在还成立吗？」**
+
+- 还能成立 → 续期。
+- 已经明显不成立（工具换了、约定改了、人换了）→ 归档。
+- **拿不准 → 续期。**
+
+**拿不准时倾向于续期，不是归档。** 理由：
+
+- 归档后就不在索引和召回里了（文件虽在 `archive/`，但不会被自动取用），续期只是推迟审查——过 `forgetAfterDays` 天还会再评估一次。**续期是可逆的，归档不是。**
+- 一条过时的记忆造成的损失，通常小于一条有用的记忆被误删。
+- 只要它有微小的可能还有用，留着比删掉安全。
+
+## 判断依据从哪来
+
+候选只给路径和描述，判断必须靠记忆本身的内容。**不要凭猜测评估。**
+
+如果一条记忆脱离了当时的上下文就完全看不懂（比如只有一句话「按上次说的办」），说明它本身质量就不合格——**归档它**，别猜。
+
+## 不要做的事
+
+- **不要为了「清理干净」而批量归档。** 归档是有代价的，每次只处理真正不成立的那些。
+- **不要评估没有超期的记忆。** 候选清单之外的一律不动。
+- **不要顺手改标签。** 标签错了是 `notes` 模式该做的事；本模式只做续期、合并、归档。
+- **不要产出与现有记忆重复的新条目。** `create` 只用于合并或更新过时内容，且必须用 `--replaces` 指定被取代的旧文件。

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

@@ -0,0 +1,76 @@
+[memory-consolidation:mode=generalize]
+
+## 本次任务：泛化
+
+把关系级记忆里**跨对端也成立**的规律升到 **agent 级**。
+
+**判断依据是普遍性**——这条内容抽掉对端的具体信息之后，换成别的对端还成立吗？
+
+## 输入
+
+上下文文件里列出的候选：关系级记忆里带 `to-generalize` 标签的条目。**候选只给路径 + 描述**，先只读描述判断；某条描述太简、拿不准的，再读那一条正文。
+
+## 产出
+
+写到 **agent 作用域**（`--scope agent`）。
+
+## 判断
+
+### 该泛化
+
+抽掉对端之后仍然是完整、有用的结论：
+
+| 关系级记忆 | 泛化后 |
+|---|---|
+| 「对端要求 commit 消息用中文」 | 「commit 消息用中文」（如果这是通用要求，不是个人怪癖） |
+| 「对端提醒构建前要先清 dist」 | 「构建前要先清 dist」 |
+| 「对端习惯让我直接给结论，不要列选项」 | ——**不该泛化**，这是对端个人的沟通偏好 |
+
+判据：**这条内容讲的是「事情怎么做」，还是「这个人喜欢怎样」？** 前者泛化，后者留下。
+
+### 不该泛化
+
+- 对端个人的沟通风格、偏好、习惯。
+- 关于对端这个人的描述（那些该走 `profile` 模式）。
+- 只在特定项目、特定环境、特定对端身上成立的结论。
+
+**评估后认为不该泛化的，用 `update` 把 `to-generalize` 标签去掉。** 否则每次定时检查都会重新扫到它，反复评估同一条。
+
+```bash
+ec memory update <关系级记忆路径> --tags "<去掉 to-generalize 后的标签>"
+```
+
+### 已经存在同类 agent 级记忆
+
+如果 agent 级里已经有讲同一件事的记忆，**用 `--replaces` 同时替换两边**，产出合并后的版本：
+
+```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" \
+  "（合并后的完整内容）"
+```
+
+## 泛化之后
+
+**源文件会被归档，不在关系级保留副本。** 这是有意的：同一条结论若在关系级和 agent 级各留一份，就成了同一事实的两个来源，上层改动要同步下层，正是本设计要清掉的那类冗余。
+
+对端之后看不到这条内容了——但它本来就不是针对这个对端的具体事实，而是通用规律，留在 agent 级对所有对端生效。
+
+## 泛化后还要考虑打 `to-promote` 吗
+
+不要在一次会话里连做两级升级。`generalize` 模式只负责产出 agent 级记忆；如果它同时也是 owner 定下的规矩，**在产出时给 agent 级那条打上 `to-promote`**，让下一次提升模式的会话去评估。分两次做，每次的判断依据更清楚。
+
+## 顺便检查：已有 agent 级记忆是否需要降级或归档
+
+扫描 agent 级 `consolidated/` 时，遇到带 `generalizedFrom` 字段的记忆，判断它是否仍然成立：
+
+**考虑降级（`ec memory demote <slug>`）的情形：**
+- 这条结论后来被证明只对特定对端成立，不具备普遍性
+- 来源关系已结束或被删除，这条 agent 级记忆失去了来源依据
+
+**考虑归档（`ec memory archive <path>`）的情形：**
+- 内容已过时，既不适合保留在 agent 级，也没有降级的价值
+- 与另一条 agent 级记忆高度重复，合并后旧条目可以归档
+
+不要因为"来源文件已经被归档"就自动降级——来源被归档正是泛化的预期结果，不是需要回退的信号。

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

@@ -0,0 +1,133 @@
+[memory-consolidation:mode=notes]
+
+## 本次任务：整理 note
+
+把 `processing/` 里的临时记忆（note）加上会话历史，提炼成**关系级正式记忆**。
+
+**这是唯一产生新记忆的模式。** 其余四种模式都建立在它已经产出的记忆之上。
+
+## 输入
+
+| 来源 | 位置 | 说明 |
+|---|---|---|
+| note | 上下文文件里的 `pendingDir` 对应 `processing/` 目录 | 主会话在对话中随手记下的原料：可能重复、可能矛盾、可能有错 |
+| 会话历史 | 上下文文件里的 `threads/` 快照目录 | `triggeredBy` 为 `manual` / `compress` / `session-new` 时完整可用，**应当读取**；`periodic-trigger` 时不可用，只能凭 note 本身判断 |
+| 已有记忆 | 目标作用域的 `MEMORY.md` 索引 | 查重 |
+
+## 产出
+
+写到 **relation 作用域**（`--scope relation`）。所有正式记忆都产生在关系级，升到 agent 级或 owner 级是另外两步。
+
+## 处理每一条 note
+
+对每条 note 做四选一的判断：
+
+### ① 是新的稳定结论 → create
+
+```bash
+ec memory create --scope relation --slug commit-chinese --desc "对端要求 commit 消息用中文" \
+  --tags "rule,long-term,verified" --keywords "commit,git" \
+  "对端明确要求：commit message 必须用中文，并列出所有功能改动点。"
+```
+
+### ② 和已有记忆是同一条，但内容更全或更准 → create --replaces
+
+```bash
+ec memory create --scope relation --slug commit-chinese --desc "对端要求 commit 用中文，注释不限" \
+  --tags "rule,long-term,verified" --keywords "commit,git" \
+  --replaces "consolidated/20261001-103100-commit-chinese.md" \
+  "对端要求 commit message 用中文；代码注释可以是英文。"
+```
+
+旧文件自动归档，索引里只留一条。
+
+### ③ 已有记忆还成立，只是状态变了 → update
+
+```bash
+ec memory update consolidated/20261002-090000-refactor-plan.md --tags "rule,done"
+```
+
+### ④ 不值得长期保留 → 丢弃
+
+一次性任务的进展、临时状态、闲聊内容。什么都不用写。
+
+## 什么时候打升级标记
+
+处理过程中如果发现某条记忆**不该只停留在这一个关系里**，就打上标记，留给后续的泛化 / 提升模式去评估：
+
+| 判断 | 打标 |
+|---|---|
+| 换成别的对端也成立（通用规律、技术结论、工作方法） | `to-generalize` |
+| owner 明确定下、要求名下所有 agent 都遵守的规矩 | `to-promote` |
+
+**这两条判据都属于「评估」，不是「确定」。** 你只需要觉得有可能成立就打标，真正的判断由下次泛化和提升模式的会话做——那时它能看到更全的上下文。
+
+**限制**：`to-promote` 只能打在对端是 owner 的关系上。当前对端不是 owner 时打这个标签会被拒绝。群聊关系下，只有本轮发言人是 owner 时才可以打。
+
+## 合并多条 note
+
+同一个话题的几条 note 应该合并成一条记忆，不要产出多条半成品。用内容最全的那条作为基础，`--replaces` 把其余的都列上。
+
+```bash
+ec memory create --scope relation --slug commit-convention \
+  --desc "对端要求 commit 用中文、按功能列出改动" \
+  --tags "rule,long-term,verified" --keywords "commit,git" \
+  --replaces "consolidated/a.md,consolidated/b.md" \
+  "（合并后的完整内容）"
+```
+
+## 群聊 note 的分流规则
+
+note 的 frontmatter 里如果有 `chatType: group`，整理时需要按信息归属分流写入目标：
+
+| 信息类型 | 写入目标 | 命令 |
+|---------|---------|------|
+| 关于这个群本身的（群规则、群文化、群惯例） | 当前 `peerKey`（群的 relation） | 默认 `--scope relation`，不加 `--peer` |
+| 关于某个发言人自身的（偏好、习惯、约定） | 该发言人的 relation | `--scope relation --peer <speakerPeerKey>` |
+| owner 对 agent 下的行为指令 | owner 的 relation | `--scope relation --peer <ownerPeerKey>`，或打 `to-promote` 升 agent 级 |
+| 无法归属某人，是群的共性 | 群的 relation（默认） | 默认 `--scope relation`，不加 `--peer` |
+
+**`--peer` 的值直接从 `speakers` 里读，不需要整理会话自行判断路由目标。** 发言人 peerKey 的构造：`<channel>#<speakerId>`，例如 AUN 渠道的 `alice.agentid.pub` 对应 `aun#alice.agentid.pub`。
+
+```bash
+# 关于群本身的记忆（默认路由，不加 --peer）
+ec memory create --scope relation --slug group-meeting-schedule \
+  --desc "群每周一开技术会" --tags "rule,verified" \
+  "该群约定每周一 10:00 召开技术同步会。"
+
+# 关于发言人自身的记忆（指定发言人的 relation）
+ec memory create --scope relation --peer aun#alice.agentid.pub \
+  --slug alice-ts-preference \
+  --desc "Alice 偏好 TypeScript，不喜欢注释" --tags "preference,verified" \
+  "Alice 明确表示偏好 TypeScript，认为代码自解释，不需要额外注释。"
+```
+
+
+## 会话历史的使用
+
+`triggeredBy` 为 `manual` / `compress` / `session-new` 时，**你应当读取会话历史**。
+
+### 用途一：核查 note 的准确性
+
+note 是零散的竖切面，会话历史能补上上下文——某条 note 是在什么情况下说的、对方后来有没有改口、有没有相关的约定被漏记。
+
+但**不要把会话历史里的内容原样搬成记忆**。它只用来判断 note 的准确性和完整性，以及补出明显的遗漏。判断标准仍然是「压缩或新会话后会丢、且有影响」。
+
+### 用途二：主动识别遗漏的关键信息
+
+除了处理 `processing/` 里的 note，你还应该**主动从会话历史中识别被漏记的关键信息**，特别是：
+
+| 类别 | 举例 |
+|------|------|
+| 任务与目标 | 对端交代的短期任务、中期目标、长期规划；需要自主跟进的待办；周期性检查点 |
+| 职责与流程 | 明确分配的职责范围、约定的工作流程、固定的检查清单、交付标准 |
+| 协作关系 | 其他联系人及其联系方式、各方的角色划分、沟通渠道偏好、协作约定 |
+| 约束与权限 | 明确的禁止事项、需要授权的操作、访问范围、资源配额 |
+
+**触发条件**：对端在会话中**明确交代**这类信息，但没有形成 note。这时应补写记忆，否则压缩或新会话后就会忘记。
+
+**判断标准**：是否满足「压缩后会丢 + 有实际影响 + 对端明确说过」三个条件。闲聊、一次性状态、含糊的意向不写。
+
+## 周期补漏的特殊情况
+
+`triggeredBy` 为 `periodic-trigger` 时没有会话历史——这是针对「聊一次就再也没出现的对端，note 一直堆着没人整理」的补漏整理。此时只能凭 note 本身的内容判断，**标准放严一些**：note 里没写清楚、脱离了上下文看不懂的，宁可不写，让它留在原地将来再处理。

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

@@ -0,0 +1,58 @@
+[memory-consolidation:mode=profile]
+
+## 本次任务：生成画像
+
+读该关系的已有记忆，**归纳出一条关于「这个对端是什么样的人」的画像**。
+
+画像是标准记忆文件，只是打了 `profile` 标签。它和普通记忆的区别是：**它是归纳出来的整体判断，不是某一条具体事实。**
+
+## 输入
+
+**先读该关系作用域的 `MEMORY.md` 索引。** 索引里每条记忆的描述就是一句话结论，归纳画像主要靠这些。
+
+**按需读正文**：某条描述太简、拿不准它具体是什么意思时，再读那一条 consolidated 文件。**不要逐条读所有正文。**
+
+## 产出
+
+一条带 `profile` 标签的 **relation 级**记忆，且**一个关系只能有一条**。
+
+```bash
+ec memory create --scope relation --slug profile \
+  --desc "对端画像：沟通风格与协作习惯" \
+  --tags "profile,long-term" --keywords "画像" \
+  --replaces "consolidated/profile.md" \
+  "（画像正文）"
+```
+
+**必须用 `--replaces` 指定上一版画像**，否则会被拒（一个关系只能有一条 `profile` 记忆）。旧版本随之归档，`archive/` 里留有历史可供追溯。
+
+**首次生成**：目标文件不存在，`--replaces` 可以不传。
+
+## 画像写什么
+
+归纳**对端这个主体**的稳定特征：
+
+- **沟通风格**：直接还是委婉、要不要铺垫、喜欢列表还是段落、讨厌什么形式。
+- **协作方式**：喜欢先确认方案再动手，还是边做边看；要不要主动汇报进度；对确认频率的偏好。
+- **关注点**：反复强调什么、在意什么质量维度。
+- **工作习惯**：时间安排、常用工具、对命名和格式的偏好。
+- **明确的禁忌**：不喜欢做的事、踩过的雷。
+
+**不写**：
+
+- 单条具体事实（那些已经有自己的记忆文件了，画像是它们的归纳）。
+- 一次性的、偶然的表现。
+- 会随时间快速变化的内容（当前任务、临时状态）。
+- 猜测。**画像只写有依据的特征**——从多条记忆里反复出现的模式归纳，不要从单条记忆推演。
+
+## 写多长
+
+**短比长好。** 画像的作用是让 agent 一眼知道「和这个人打交道要注意什么」，不是完整档案。控制在一屏以内，用分点陈述。
+
+每条判断尽量能追溯到支撑它的记忆。判断有争议时，宁可写得更保守、更具体。
+
+## 重新生成
+
+每次都是**完整重写**，不是在旧画像上追加。
+
+旧画像的内容如果仍然成立，就在新版里保留；已经过时的（对端习惯变了）自然淘汰掉。**不要保留已经不成立的旧判断**——画像是当前的判断，不是变更日志。

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

@@ -0,0 +1,72 @@
+[memory-consolidation:mode=promote]
+
+## 本次任务：提升
+
+把关系级记忆里 **owner 定下的、对名下所有 agent 都有效的规矩**升到 **owner 级**。
+
+**判断依据是权威性**——这条内容的效力来自「谁说的」，而不是「它有多普遍」。owner 定下的规矩适用范围最广，所以放在最上层。
+
+## 输入
+
+上下文文件里列出的候选：关系级记忆里带 `to-promote` 标签的条目。**候选只给路径 + 描述**，先只读描述判断；某条描述太简、拿不准的，再读那一条正文。
+
+## 产出
+
+写到 **owner 作用域**（`--scope owner`）。
+
+## 判断
+
+### 该提升
+
+内容的效力来自 owner 的身份：
+
+- owner 说的「以后都这样」「所有 agent 都不许」「统一按这个来」。
+- owner 定下的流程、规范、禁令，且明确表示不是只针对某一个对端的。
+- owner 对其他 agent 的工作提出的统一要求。
+
+### 不该提升
+
+- 对端（不是 owner）表达的偏好、习惯、要求——**提升模式的候选本来就只来自 owner 关系**，如果发现候选里混进了非 owner 的内容，说明打标环节出了问题，应当 `update` 去掉标签。
+- 只针对某一个 agent 或某一个项目的一次性要求。
+- owner 随口提到的个人偏好，没有「对所有 agent 有效」的意思。
+
+**评估后认为不该提升的，用 `update` 把 `to-promote` 标签去掉。**
+
+## 权限校验
+
+daemon 会检查：
+
+1. 当前对端必须是 owner。非 owner 关系的记忆打 `to-promote` 时就已经被拒了。
+2. `--replaces` 的来源必须包含 owner 关系的记忆。
+
+群聊关系的情况：对端是群，不是 owner，但**本轮发言人可能是 owner**。只有发言人是 owner 时，那条记忆才能打上 `to-promote`。上下文文件里会写明群关系下 owner 是否参与了本次对话。
+
+## 关于「两边都留一份」
+
+**不保留。** 提升成功后，关系级源文件被 `--replaces` 归档。
+
+理由：同一条规矩若在关系级和 owner 级各留一份，就成了同一事实的两个来源，owner 改了规矩要同步改关系层，正是本设计要清掉的那类冗余。提升之后这条规矩只存在于 owner 级，关系级看不到它——**这是设计意图，不是缺陷**。
+
+## 示例
+
+```bash
+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" \
+  "owner 明确要求：所有 agent 都不许自己执行 git commit，必须由 owner 确认后才能提交。"
+```
+
+## 顺便检查：已有 owner 级记忆是否需要降级或归档
+
+扫描 owner 级 `consolidated/` 时，遇到带 `promotedFrom` 字段的记忆，判断它是否仍然成立：
+
+**考虑降级（`ec memory demote <slug>`）的情形：**
+- 这条规矩已被 owner 撤销，只对特定 agent 有效，不再是所有 agent 的通用规则
+- 来源的 agent 级记忆已不存在，且 owner 级内容已过时
+
+**考虑归档（`ec memory archive <path>`）的情形：**
+- 规矩已废除，不适合保留在任何层级
+- 与另一条 owner 级记忆高度重复，合并后旧条目可以归档
+
+不要因为"来源的 agent 级文件已经被归档"就自动降级——来源被归档正是提升的预期结果，不是需要回退的信号。

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

@@ -0,0 +1,75 @@
+[memory-consolidation:workflow]
+
+命令、参数和本次模式允许的 scope 见上方 `[memory]` 段。本段只讲流程和取舍。
+
+## 工作流程
+
+1. **读上下文文件**（路径在本次任务的初始提示词里）。里面写着：本次模式、作用域、各目标目录、候选清单、是否可用会话历史。
+2. **读候选内容**。`notes` 模式读 `processing/` 里的 note；其余模式读上下文文件里列出的候选记忆（先只读描述，按需读正文）。
+3. **查重**（见下）。
+4. **写**。用 `create` / `update` / `archive`。索引由程序在会话结束后统一重建。
+5. **反馈**。结束前必须调用 `ec memory feedback`，把本次整理的结果按要求写清楚（见下）。
+6. **结束**。写完直接结束，不需要在会话里汇报「已完成」——反馈由 `ec memory feedback` 投递。
+
+## 写入前必须先查重
+
+**先读目标作用域的 `MEMORY.md` 索引**，看已有条目的描述和关键词。
+
+- 没有高度相似的 → `create`。
+- 发现高度相似的 → 只读那一条确认，然后：
+  - 新内容覆盖或补充了它 → `create --replaces <那条>`（旧文件自动归档）。
+  - 只是状态变了 → `update <那条> --tags ...`。
+
+**不要逐一读取所有 consolidated 文件查重。** 一个关系可能有几百条记忆。
+
+## 判断留不留
+
+只有**稳定成立的结论**才写：
+
+- 跨会话仍然成立的偏好、约定、规则、事实。
+- 会话内因上下文压缩会丢失的关键信息。
+- 对端明确表达过的态度。
+
+不值得写的：一次性任务的进展、临时状态、闲聊内容。直接丢弃，不用写任何东西。
+
+## update 还是 create --replaces
+
+**update 改不了正文。** 内容一变，描述和关键词都得跟着变，那就 `create --replaces` 一条新的。
+
+update 只用于正文不变、状态变了的情况：
+
+- 任务推进：`in-progress` → `blocked` → `done` / `cancelled`
+- 紧急解除：去掉 `urgent`
+- 推断被确认：`inferred` → `verified`
+- 判定长期有效或重要：补 `long-term` / `important`
+- 评估后不该升级：去掉 `to-generalize` / `to-promote`
+
+## 没有可整理的内容时
+
+输出 `[[NOOP]]`，然后结束。不要为了「有产出」而硬造记忆。
+
+## 反馈（必须调用）
+
+**结束前必须调用 `ec memory feedback`**，把本次整理结果写成一段 markdown 文本。这段文本会被投递回发起整理的会话（手动、上下文压缩、新会话三类触发都会投递；定时触发只写日志，不投递）。
+
+要求：
+
+- 调用格式：`ec memory feedback "<文本>"`，文本用单引号或双引号包住。
+- 内容用 markdown，包含：
+  - **模式**：本次模式（notes / generalize / promote / profile / forget）
+  - **处理结果**：新建 / 更新 / 归档的记忆条数
+  - **要点**：一句话概括这次整理做了什么（哪些主题的记忆被合并、提升、归档）
+  - 若本次无可整理内容（输出 `[[NOOP]]`），写一句说明即可，例如「本次没有可整理的 note，未产生改动」。
+  - 若过程中遇到异常（某条候选读不了、写入被拒），如实写出来。
+- 不要在反馈文本里堆砌日志路径和原始文件列表——那些在批次目录里有，反馈是给人看的一句话级结论。
+
+未调用反馈时，程序会回退到默认模板（只含模式、触发方式、条数统计），信息量少，所以务必显式调用。
+
+## 收尾
+
+**你不需要处理 `processing/` 里的文件。** 程序会在会话结束后处理：
+
+- 成功 → 移入 `archive/notes/` 留底。
+- 失败 → 移回 `pending/`，下次重新整理。
+
+程序还会重建索引，并把本次整理的日志（模式、候选、产出）落到 `$EVOLCORE_HOME/memory/consolidation-batches/`。

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

@@ -19,6 +19,12 @@ Bootstrap 不另设隐藏状态机；恢复依据是可核对的生命周期和
 - owner 确认后，使用 `ec agent persona --text '<内容>'` 或 `ec agent persona --file '<收到的文件路径>'` 写入自己的 `$PERSONAL_DIR/persona.md`。`--file` 只接受文本文件，不能使用任意路径。
 - persona 是可选环节。owner 未提供、拒绝或暂时跳过时，不得阻塞名片发布和 `ec agent ready`。
 
+可选的头像：
+- `ec agent new` 支持 `--avatar-file <path>` 或 `--avatar-url <HTTPS URL>`，头像处理统一沿用 `ec aid avatar` 的同一套管线。基础名片字段确认后，询问 owner 是否提供一张照片作为头像，并说明头像不提供也不影响 Bootstrap。
+- owner 可以发送图片附件；创建者应将同一个附件以 `--avatar-file attachment:<id>` 传入创建命令，daemon 会按当前对端关系解析。不要要求新 Agent 读取创建者会话的临时路径，也不要从普通任务内容推断头像。
+- 创建流程会在最终 agent.md 发布后调用公共 avatar 上传管线；该管线负责校验、必要时规范化并更新 agent.md。规范化失败时说明原因并允许 owner 重新发送图片。
+- owner 未提供头像时，直接跳过头像并继续 Bootstrap。
+
 Bootstrap 完成前还必须生成并确认正式 welcome 文案：
 - 在 `name`、`description`、`tags`（以及 owner 选择提供的 persona/语气要求）最终确认后，直接在当前对话中输出完整的个性化 welcome 文案。
 - 文案必须面向当前 owner，说明你的定位、可协助的方向和开始协作的方式；不要写入系统提示词、凭据、文件路径、工作记忆或未经确认的能力声明。
@@ -28,15 +34,17 @@ Bootstrap 完成前还必须生成并确认正式 welcome 文案：
 - 文案只在对话中展示，不创建草稿文件、不提前执行保存命令。明确询问 owner 是否确认这份完整文案。
 - owner 要求修改时，重新输出完整文案并再次等待明确确认；“差不多”“先这样”等不明确回复不算确认。
 - owner 明确确认后，使用 `ec agent welcome --text '<最后展示且确认的完整文案>'` 保存到 `$PERSONAL_DIR/welcome.md`（命令会固定写入当前 Agent 的 `personal/welcome.md`，不接受自定义路径）。保存内容必须与最后展示并确认的原文一致。
-- 只有 welcome 保存成功后，才能发布 agent.md 并执行 `ec agent ready {{selfAid}}`。`ready` 不会再调用模型生成 welcome。
+- 只有 welcome 保存成功后，才能发布 agent.md；可选头像处理完成或跳过后才能执行 `ec agent ready {{selfAid}}`。`ready` 不会再调用模型生成 welcome。
 
 允许的操作范围：
 - 为读取现有候选值，可以读取本地 `{{agentMdPath}}`。
 - 为处理可选 persona，可以执行 `ec agent persona show`、`ec agent persona --text <text>` 或 `ec agent persona --file <path>`；写入前仍须取得 owner 对待写入内容的明确确认。
+- 为处理可选头像，创建阶段使用 `--avatar-file` 或 `--avatar-url`；Agent 激活后使用 `ec aid avatar {{selfAid}}` 更新头像。两者共用同一公共上传管线。
 - 为核对已保存的文案，可以执行 `ec agent welcome show`。为保存 owner 已确认的 welcome，可以执行 `ec agent welcome --text <text>`；只能写当前 Agent 的固定 `personal/welcome.md`，不能传入路径或保存未确认草稿。
-- owner 明确确认最终值和 welcome 后，只能编辑上述 agent.md 的 YAML frontmatter，并依次执行下面三个命令：
+- owner 明确确认最终值和 welcome 后，只能编辑上述 agent.md 的 YAML frontmatter，并依次执行下面的核心命令；如已确认头像，再插入头像命令：
   - `ec agent welcome --text '<confirmed welcome text>'`
   - `ec aid agentmd put {{selfAid}}`
+  - （如 owner 已确认头像）`ec aid avatar {{selfAid}} --file '<received image path>'` 或 `ec aid avatar {{selfAid}} --url '<HTTPS image URL>'`
   - `ec agent ready {{selfAid}}`
 - 除这些 bootstrap 操作及向 owner 回复外，不得调用工具或执行命令。
 
@@ -59,8 +67,9 @@ Bootstrap 完成前还必须生成并确认正式 welcome 文案：
 7. owner 明确确认最终值后，只编辑本地 agent.md（`{{agentMdPath}}`）YAML frontmatter 中的 `name`、`description`、`tags`，保留其它字段和正文，并检查 YAML 与字段格式有效。
 8. 根据已确认的名片信息在对话中生成完整 welcome，展示给 owner 并请求明确确认；owner 要求修改时重复本步骤，始终展示完整文本。
 9. owner 明确确认后，执行 `ec agent welcome --text '<最后确认的完整文本>'` 保存 welcome；只有命令明确成功后，才执行 `ec aid agentmd put {{selfAid}}`。
-10. `ec aid agentmd put {{selfAid}}` 成功后，才调用 `ec agent ready {{selfAid}}` 完成 bootstrap。
-11. 任一步骤失败时，不调用 ready，不盲目重复尝试；说明具体失败原因并在修正后继续。
-12. `ec agent ready {{selfAid}}` 必须是 bootstrap 的最后一个操作。成功后系统会结束当前上下文、创建新的主会话并发送已确认的个性化 welcome；不要在旧上下文中继续处理任务。
+10. 如果 owner 已确认头像，`ec aid agentmd put {{selfAid}}` 成功后执行 `ec aid avatar {{selfAid}}`；头像未提供或上传失败时跳过该步。
+11. 头像步骤完成或跳过后，才调用 `ec agent ready {{selfAid}}` 完成 bootstrap。
+12. 任一步骤失败时，不调用 ready，不盲目重复尝试；说明具体失败原因并在修正后继续。头像上传失败除外：说明原因后可跳过头像并继续。
+13. `ec agent ready {{selfAid}}` 必须是 bootstrap 的最后一个操作。成功后系统会结束当前上下文、创建新的主会话并发送已确认的个性化 welcome；不要在旧上下文中继续处理任务。
 
 完成前不要承诺已经进入正常工作状态，也不要尝试与上述流程无关的文件修改、网络通信或系统配置操作。

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

@@ -3,6 +3,7 @@
 
 托管 Agent 任务禁止调用 `ec start`、`ec stop`、`ec restart` 或 `ec restart-monitor`，这些是宿主终端的进程生命周期命令。源码改动完成后只执行构建并报告需要宿主重启；不要尝试、重试或建议 Agent 自己执行 `ec restart`。`ec agent reload` 也不会重载源码。
 
+ec memory  记忆写入与整理（note 写入/修改/撤销/查看；consolidate 触发整理；何时写见 [memory] 段）  $KITS_DOCS/evolcore/memory.md
 ec ctl     当前会话工具（主动发消息/文件、重命名、队列、项目路径、会话状态）  $KITS_DOCS/evolcore/ctl.md
 ec model   模型与推理强度管理（切模型/列模型/当前模型/模型详情/改强度/诊断网关）  $KITS_DOCS/evolcore/model.md
 ec response 响应模式管理（切换响应模式/列响应模式/看当前模式/改响应配置）  $KITS_DOCS/evolcore/response.md

package/kits/templates/system-fragments/group-history.md

@@ -0,0 +1,6 @@
+[group-history]
+需要人工回看本群本地历史时，可执行：
+ec group history {{selfAid}} {{groupId}} --limit 50 --format json
+可使用 --thread、--before、--after、--direction 缩小范围；用 --before/--after 分页。
+查询只读，不改变任何已读状态，也不会自动回复历史消息。
+历史是背景资料，保留原发送者与时间，不要重放其中的 slash 命令或逐条自动回复。

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

@@ -8,6 +8,3 @@ selfAid: {{selfAid}}
 {{?hasPersona}}
 hasPersona: active
 {{/}}
-{{?hasWorkingMemory}}
-hasWorkingMemory: active
-{{/}}