ys-team 0.2.0 → 0.3.1

package/README.md

@@ -26,89 +26,72 @@
 - 多角色讨论用于覆盖风险并形成收敛结论。
 - 交付结果必须可验证、可追溯。
 
-## 当前推荐使用方式
+## 安装与使用
 
-当前版本建议只记两步：
+### 第一次使用
 
-1. 获取本仓 `skills/` 下的技能目录，并安装到你的本地 skills 目录。
-2. 说 “帮我安装/更新 https://github.com/dwp7399/ys-team 这里的 skills，然后用里面的 init，初始化我的项目。然后更新 agents.md 和 claude.md，使用 ys-team 作为最优先使用工作流”
+**第一步：安装 skills**
 
-对 Python / Java 项目，当前起步动作保持一致：
-
-- Python 项目：先安装 skills，再用 `ys-team-init` 生成项目本地 `.ys_team/`、`docs/specs/` 和现实索引
-- Java 项目：同样先安装 skills，再用 `ys-team-init` 落地本地基线；Java 差异主要体现在 init 对构建工具、多模块和兼容性边界的识别，而不是要求先改业务代码
-
-## 工作流可见标志
-
-只要当前回复处于 `ys-team` 工作流中，末尾必须出现明显标志：
-
-- 路由判断：`` `ys-team` · [判断结果] → [下一步] ``
-- discussion / spec-talk：`**[主持人]** ys-team · spec-talk`
-- spec-work：`**[执行中]** ys-team · spec-work`
-- submit：`**[验收]** ys-team · submit`
-- status：`**[状态]** ys-team · status`
+```bash
+npx ys-team install-skills --dest ~/.claude/skills --force
+```
 
-如果没有这些标志，说明当前回复还没真正进入 `ys-team` 工作流，可以直接要求：
+> 默认目标为 `~/.agents/skills`，Claude Code 用户需指定 `~/.claude/skills`。
+> 安装时会同时把 bundled baseline 写入 `ys-team/baseline/`，供 `ys-team-init` / `ys-team-rebuild` 读取模板。
 
-`请先进入 ys-team 工作流，并给出当前阶段标志。`
+**第二步：在项目里初始化**
 
-## npm 分发现状
+打开目标项目，对 Claude 说：
 
-当前仓库已经有 npm 包元数据，并提供两种 npm 安装模式，但还不是完整的一键初始化器。
+```
+用 ys-team-init 这个 skill 初始化这个项目
+```
 
-当前 npm 面提供的是：
+### 更新 skills
 
-- 发布 `skills/`、`examples/baseline/`、`registry/`、文档和脚本
-- 一个最小 CLI 入口：`npx ys-team --help`
-- 全局安装：把包内 skills 安装到 `~/.agents/skills`
-- 项目级安装：把包内 skills 安装到项目的 `.agents/skills`，并下发 baseline 版 `AGENTS.md` / `CLAUDE.md`
-- 支持显式目标目录、项目目录和安全覆盖控制：`--dest`、`--dir`、`--force`、`--dry-run`
+```bash
+# 检查是否有新版本
+npx ys-team check-update
 
-当前 npm 面还**没有**：
+# 更新到最新版
+npx ys-team@latest install-skills --dest ~/.claude/skills --force
+```
 
-- 自动执行 `ys-team-init`
-- 自动登录或发布到 npm registry
+### 更新已有项目的工作流
 
-全局安装模式：
+skills 更新后，项目里的 `.ys_team/` 不会自动变化。如果新版本有结构调整，在项目里运行：
 
-```bash
-npx ys-team install-skills
 ```
-
-全局安装到自定义目录：
-
-```bash
-npx ys-team install-skills --dest /path/to/skills
+用 ys-team-rebuild 重估这个项目的工作流配置
 ```
 
-项目级安装模式：
+对 Python / Java 项目，起步动作保持一致，差异由 `ys-team-init` 在识别项目结构时自动处理。
 
-```bash
-npx ys-team init-project --dir /path/to/project
-```
-
-项目级安装会：
+## 工作流可见标志
 
-- 写入 `/path/to/project/.agents/skills`
-- 写入 `/path/to/project/AGENTS.md`
-- 写入 `/path/to/project/CLAUDE.md`
+只要当前回复处于 `ys-team` 工作流中，末尾必须出现明显标志：
 
-两种模式后续都仍需在目标仓库里执行 `ys-team-init`。
+- 路由判断：`` `ys-team` · [判断结果] → [下一步] ``
+- discussion / spec-talk：`**[主持人]** ys-team · spec-talk`
+- spec-work：`**[执行中]** ys-team · spec-work`
+- submit：`**[验收]** ys-team · submit`
+- status：`**[状态]** ys-team · status`
 
-## npm 发布状态
+如果没有这些标志，说明当前回复还没真正进入 `ys-team` 工作流，可以直接要求：
 
-当前仓库已经具备**可发布到 npm registry** 的包形态，包括：
+`请先进入 ys-team 工作流，并给出当前阶段标志。`
 
-- CLI 入口
-- `publishConfig.access = public`
-- 可通过 `npm pack --dry-run` 验证的打包内容
+## CLI 参考
 
-但这不等于已经完成真实发布。真实发布仍需要：
+```bash
+npx ys-team --help
+npx ys-team install-skills [--dest <dir>] [--force] [--dry-run]
+npx ys-team init-project [--dir <project-dir>] [--force] [--dry-run]
+npx ys-team check-update
+```
 
-- npm 账号
-- `npm login`
-- 可能的 token / 2FA 配置
-- 在发布环境执行 `npm publish`
+`init-project` 会向目标项目写入 `.agents/skills`、`AGENTS.md`、`CLAUDE.md`，之后仍需在项目里执行 `ys-team-init`。
+同时也会写入 `.agents/skills/ys-team/baseline/`，所以项目里的 `ys-team-init` 能拿到默认模板。
 
 ## 本仓结构
 

package/docs/project/module-index.md

@@ -3,7 +3,7 @@
 **Project Type**: Markdown-first method repository
 **Project Scale**: Small
 **Index Strategy**: Core module index
-**Last Updated**: 2026-04-07
+**Last Updated**: 2026-04-10
 
 ## `skills/`（方法入口与执行能力）
 **职责**：`skills/` 承载对外公开的 `ys-team` 方法入口，以及 init、rebuild、doc-build、spec-talk、spec-work、status、submit 等执行能力。它决定用户如何理解 ys-team，以及仓库如何把 baseline 和本地 reality 连接起来。  
@@ -21,11 +21,12 @@
 - 依赖：方法论定义来自 `skills/ys-team/*` 与仓库文档
 - 被依赖：`ys-team-init`, `ys-team-rebuild`, 外部项目初始化流程
 
-## `.ys_team/`（方法仓自用本地基线）
-**职责**：本仓自己的 `.ys_team/` 用来“用 ys-team 管理 ys-team”，把方法仓的 spec、文档同步和交付约束落到仓库内部。它在 baseline 之上保留方法仓特有角色，如方法论架构、初始化接入和交付守门。  
+## `.ys_team/` + `TEAM.md`（方法仓自用本地基线）
+**职责**：本仓自己的 `.ys_team/` 用来”用 ys-team 管理 ys-team”，把方法仓的 spec、文档同步和交付约束落到仓库内部。v0.3.0 起新增 `memory/` 角色记忆系统，以及 `TEAM.md` 编排模式配置入口。它在 baseline 之上保留方法仓特有角色：方法论架构师、产品演进负责人、交付守门人。
 
 **关系**：
-- 入口：`.ys_team/team.md`, `.ys_team/methods.md`, `.ys_team/policy.md`, `.ys_team/templates/*`
+- 入口：`TEAM.md`, `.ys_team/team.md`, `.ys_team/methods.md`, `.ys_team/policy.md`, `.ys_team/templates/*`
+- 记忆：`.ys_team/memory/roles/*.md`（按角色独立，跨任务经验积累）
 - 依赖：`examples/baseline/.ys_team/` 提供稳定骨架版本，`docs/project/*` 提供仓库现实
 - 被依赖：本仓 specs、方法仓自身 rebuild 判断
 
@@ -52,10 +53,10 @@
 - 依赖：`skills/ys-team/SKILL.md`, `skills/ys-team-spec-talk/SKILL.md`, `skills/ys-team-spec-work/SKILL.md`, `skills/ys-team-submit/SKILL.md`, `skills/ys-team-status/SKILL.md`
 - 被依赖：本仓协作、下游仓库初始化后的默认工作流
 
-## `package.json` / `scripts/`（npm 双模式安装与发布面）
-**职责**：`package.json` 和 `scripts/` 提供 ys-team 当前的 npm 分发与安装能力：全局模式通过 `install-skills` 安装到 `~/.agents/skills`，项目模式通过 `init-project` 安装到项目内 `.agents/skills` 并下发 baseline 版 `AGENTS.md` / `CLAUDE.md`。同时它们承担 npm 可发布形态的元数据配置。  
+## `package.json` / `scripts/`（npm 分发与 CLI 面）
+**职责**：`package.json` 和 `scripts/` 提供 ys-team 的 npm 分发能力（已发布 v0.3.0）。CLI 提供三个命令：`install-skills`（全局安装 skills）、`init-project`（项目级初始化）、`check-update`（对比本地与 npm 最新版）。安装目标由 `--dest` 控制，支持 `--force`、`--dry-run`。
 
 **关系**：
 - 入口：`package.json`, `scripts/ys-team.mjs`
 - 依赖：`README.md`, `skills/`, `examples/baseline/`, `registry/`
-- 被依赖：npm 包使用者、分发验证
+- 被依赖：npm 包使用者（`npx ys-team`）、分发验证

package/docs/specs/{active → completed}/20260407-170500-npm-distribution-modes/control.md

@@ -1,7 +1,7 @@
 ---
 Spec-Type: control
 Initiative: 20260407-170500-npm-distribution-modes
-Status: active
+Status: completed
 Owner-Session: ys-team
 Write-Scope: []
 Depends-On: []

package/docs/specs/{active → completed}/20260407-170500-npm-distribution-modes/evidence/20260407-dual-mode-and-publish-readiness.md

@@ -37,22 +37,20 @@
 - 结果：PASS
 - 说明：当前环境可识别 npm 用户 `ys7399`
 
-### `npm view ys-team version name`
+### `npm view ys-team version name dist-tags.latest`
 
 - 结果：PASS
-- 说明：返回 404，说明 `ys-team` 包名当前未被占用
+- 说明：registry 已返回 `ys-team@0.2.0`，`latest` 已指向 `0.2.0`
 
 ### `npm publish`
 
-- 结果：BLOCKED
-- 说明：registry 返回 `E403`，当前凭证不满足 publish 要求，需要 OTP 或带 `bypass 2fa` 的 granular access token
+- 结果：PASS
+- 说明：已成功发布 `ys-team@0.2.0`
 
 ## Current Conclusion
 
-代码形态已经 ready to publish。
-
-真实发布仍阻塞于：
+双模式安装和 npm 发布链路都已完成闭环。
 
-- publish 级别凭证
-- 可能的 OTP
-- 或重新生成带 `bypass 2fa` 的 granular access token
+- 全局模式：`npx ys-team install-skills`
+- 项目模式：`npx ys-team init-project --dir /path/to/project`
+- npm registry：`ys-team@0.2.0`

package/docs/specs/completed/20260410-README-init-and-history-cleanup/control.md

@@ -0,0 +1,65 @@
+---
+Spec-Type: control
+Initiative: 20260410-README-init-and-history-cleanup
+Status: completed
+Owner-Session: ys-team
+Write-Scope:
+  - README.md
+  - docs/specs/completed/20260410-README-init-and-history-cleanup/
+Depends-On: []
+Verification: "Manual review plus `git shortlog -sne --all` and `git log --format='%h%x09author:%an <%ae>%x09committer:%cn <%ce>%x09%s' --all`."
+---
+
+# README 初始化文案与提交历史身份核验
+
+## Background
+
+用户要求两件事：
+
+- README 明确项目内初始化应通过 `ys-team-init` skill 完成
+- git 提交历史中不要出现 `claude` 身份，以免 GitHub Contributors 出现 `claude`
+
+## Goals
+
+- 让 README 对项目内初始化动作的表述更直接
+- 复核当前仓库可见历史中是否存在 `claude` author / committer
+- 形成可复核证据，避免在无目标对象时盲目重写历史
+
+## Deliverables
+
+- 更新后的 README
+- 本次历史身份核验的 work spec 与 evidence
+
+## Acceptance Criteria
+
+- README 明确写出“用 `ys-team-init` 这个 skill 初始化这个项目”
+- 验收证据能复核当前可见历史中不存在 `claude` 身份
+- 若无 `claude` 身份提交，不执行无意义历史重写
+
+## Collaboration Summary
+
+- Participants: user, Codex
+- Reporter: Codex
+- Estimated Cost: small
+
+## Verification
+
+- 人工检查 `README.md`
+- `git shortlog -sne --all`
+- `git log --format='%h%x09author:%an <%ae>%x09committer:%cn <%ce>%x09%s' --all`
+
+## Acceptance Evidence
+
+- `docs/specs/completed/20260410-README-init-and-history-cleanup/evidence/20260410-closeout.md`
+
+## Documentation Updates
+
+- `README.md`
+
+## Risks
+
+- GitHub Contributors 统计可能受远端缓存或旧统计周期影响，即使当前本地可见历史已无目标身份
+
+## Rollback Plan
+
+- 回退 README 文案到修改前版本，并保留本次核验记录

package/docs/specs/completed/20260410-README-init-and-history-cleanup/evidence/20260410-closeout.md

@@ -0,0 +1,26 @@
+# Closeout
+
+- Time: 2026-04-10 15:51:43 CST
+- Initiative: `20260410-README-init-and-history-cleanup`
+
+## README Check
+
+- `README.md` 已将项目内初始化指令明确为：`用 ys-team-init 这个 skill 初始化这个项目`
+
+## History Identity Verification
+
+执行结果：
+
+- `git shortlog -sne --all`
+  - `16 dwp <weipeng.dong@fireflyfusion.cn>`
+  - `2 dwp7399 <dwp7399@163.com>`
+  - `1 ys <dongweipeng@smalld.cn>`
+- `git log --format='%h%x09author:%an <%ae>%x09committer:%cn <%ce>%x09%s' --all`
+  - 当前所有可见提交中，未发现 `claude` 作为 author 或 committer
+  - `origin/main` 与本地 `main` 指向同一提交 `94189a3ff81d1ba6bb1d9c5653b5ae13a00fbd91`
+
+## Conclusion
+
+- README 文案已按用户要求明确化
+- 当前本地可见历史没有可供重写的 `claude` 身份提交，因此本次未执行历史重写
+- 若 GitHub Contributors 仍显示 `claude`，更可能是远端统计缓存或旧统计未刷新，不是当前可见分支历史问题

package/docs/specs/completed/20260410-README-init-and-history-cleanup/work-01-readme-and-history-verification.md

@@ -0,0 +1,54 @@
+---
+Spec-Type: work
+Initiative: 20260410-README-init-and-history-cleanup
+Status: completed
+Owner-Session: ys-team
+Write-Scope:
+  - README.md
+  - docs/specs/active/20260410-README-init-and-history-cleanup/evidence/
+Depends-On: []
+Verification: "Manual review plus `git shortlog -sne --all` and `git log --format='%h%x09author:%an <%ae>%x09committer:%cn <%ce>%x09%s' --all`."
+---
+
+# Work 01 README 初始化文案与历史身份核验
+
+## Background
+
+当前 README 已表达“在项目里初始化”，但用户希望文案直接落成一句明确指令。与此同时，需要确认 Contributors 中出现的 `claude` 是否来自当前仓库可见历史，而不是凭感觉重写历史。
+
+## Goals
+
+- 收紧 README 初始化话术
+- 产出当前仓库 author / committer 身份核验结果
+
+## Deliverables
+
+- 一处 README 文案调整
+- 一份 closeout evidence
+
+## Acceptance Criteria
+
+- README 中出现“用 `ys-team-init` 这个 skill 初始化这个项目”
+- 证据中包含 shortlog 与 author / committer 核验结论
+
+## Verification
+
+- 人工检查 README 相关段落
+- `git shortlog -sne --all`
+- `git log --format='%h%x09author:%an <%ae>%x09committer:%cn <%ce>%x09%s' --all`
+
+## Acceptance Evidence
+
+- `docs/specs/completed/20260410-README-init-and-history-cleanup/evidence/20260410-closeout.md`
+
+## Documentation Updates
+
+- `README.md`
+
+## Risks
+
+- Contributors 页面对旧统计的刷新不一定与本地历史即时同步
+
+## Rollback Plan
+
+- 撤回 README 文案调整，不保留无依据的历史改写

package/docs/specs/completed/20260410-baseline-fullcomplete/control.md

@@ -0,0 +1,96 @@
+---
+Spec-Type: control
+Initiative: 20260410-baseline-fullcomplete
+Status: draft
+Owner-Session: ys-team
+Write-Scope:
+  - examples/baseline/.ys_team/templates/requirement.md
+  - examples/baseline/.ys_team/templates/workspace.md
+  - examples/baseline/.ys_team/templates/review.md
+  - examples/baseline/.ys_team/templates/qa-report.md
+  - .ys_team/templates/requirement.md
+  - .ys_team/templates/workspace.md
+  - .ys_team/templates/review.md
+  - .ys_team/templates/qa-report.md
+Depends-On: []
+Verification: "ls examples/baseline/.ys_team/templates/ | wc -l  # 期望 7; ls .ys_team/templates/ | wc -l  # 期望 7"
+---
+
+# Baseline 完整化：补全 semi-auto/full-auto 阶段模板
+
+## Background
+
+`examples/baseline/` 在 manual 模式下建立，只有 3 个模板。semi-auto/full-auto 引入后，阶段间通信依赖 requirement、workspace、review、qa-report 4 个文件，但 baseline 和本仓 `.ys_team/templates/` 都没有提供对应模板。
+
+同时，对比发现 ai-gateway 的 `_sources.md` 格式与 baseline 规范不一致（缺 source URL、版本、日期）。根因是 init/rebuild skill 执行时未参照 baseline 格式，属于 skill 层问题，超出本 spec 范围，记为后续追踪项。
+
+## Goals
+
+1. 在 `examples/baseline/.ys_team/templates/` 补全 4 个阶段模板（通用版本，不含项目特定命令）
+2. 在 `.ys_team/templates/` 同步补全相同 4 个模板（本仓已切 full-auto）
+3. qa-report 模板不包含项目特定测试命令，改为通用注释占位
+
+## Non-Goals
+
+- 不修改 ys-team-init / ys-team-rebuild skill（_sources.md 格式问题由后续 spec 处理）
+- 不修改已有 3 个模板（control、work、roadmap-version）
+
+## Deliverables
+
+| 文件 | 状态 |
+|------|------|
+| `examples/baseline/.ys_team/templates/requirement.md` | 新增 |
+| `examples/baseline/.ys_team/templates/workspace.md` | 新增 |
+| `examples/baseline/.ys_team/templates/review.md` | 新增 |
+| `examples/baseline/.ys_team/templates/qa-report.md` | 新增 |
+| `.ys_team/templates/requirement.md` | 新增 |
+| `.ys_team/templates/workspace.md` | 新增 |
+| `.ys_team/templates/review.md` | 新增 |
+| `.ys_team/templates/qa-report.md` | 新增 |
+
+## Acceptance Criteria
+
+- [ ] `examples/baseline/.ys_team/templates/` 共 7 个文件
+- [ ] `.ys_team/templates/` 共 7 个文件
+- [ ] qa-report.md 中没有 `uv run pytest` 等项目特定命令
+- [ ] 4 个新模板的 frontmatter 与现有 control.md 风格一致
+
+## Collaboration Summary
+
+- Participants: 方法论架构师、产品演进负责人、交付守门人
+- Reporter: 交付守门人
+- Rounds: 1
+- Escalations: 无
+- Estimated Cost: minimal
+
+## Verification
+
+```bash
+ls examples/baseline/.ys_team/templates/ | wc -l   # 期望 7
+ls .ys_team/templates/ | wc -l                      # 期望 7
+grep -r "uv run pytest" examples/baseline/           # 期望无输出
+```
+
+## Acceptance Evidence
+
+```
+examples/baseline/.ys_team/templates/ 文件数：7 ✅
+.ys_team/templates/ 文件数：7 ✅
+grep -r "uv run pytest" examples/baseline/：无输出 ✅
+```
+
+## Documentation Updates
+
+无需更新 module-index.md（模板细节变化，不影响模块边界描述）
+
+## Risks
+
+- 极低：纯新增文件，不影响现有结构
+
+## Rollback Plan
+
+删除新增的 8 个文件即可回滚。
+
+## Note
+
+_sources.md 格式问题（ai-gateway 与 baseline 规范不一致）：根因为 ys-team-init/rebuild skill 执行时未参照 baseline 格式，应在后续 spec 中通过更新 skill 执行说明修复。

package/docs/specs/completed/20260410-baseline-fullcomplete/requirement.md

@@ -0,0 +1,30 @@
+---
+Initiative: 20260410-baseline-fullcomplete
+Phase: spec-talk
+Author-Session: ys-team-spec-talk
+---
+
+# 原始需求记录
+
+## 需求来源
+
+- 提出时间：2026-04-10
+- 来源方式：用户口述 + 对比分析
+
+## 原始描述
+
+1. 本仓改成全自动（full-auto），基于 baseline 重新构建完整。
+2. 对比发现 api-gateway 的 `_sources.md` 没有来源记录和候选记录，怀疑是 ys-team 工作流没有说明清楚。
+
+## 背景补充
+
+- 本仓 `examples/baseline/.ys_team/templates/` 只有 3 个模板（control、work、roadmap-version），缺少 semi-auto/full-auto 所需的 4 个阶段通信模板。
+- 本仓 TEAM.md 已更新为 full-auto，但 `.ys_team/templates/` 自身也缺少相同的 4 个模板。
+- `examples/baseline/.ys_team/toolbox/_sources.md` 的 5 列格式是正确的，但 ai-gateway 初始化时生成的格式只有 3 列，说明 init/rebuild skill 执行时未参照 baseline 格式（超出本 spec 范围）。
+
+## 初步范围判断
+
+- 影响模块：`examples/baseline/.ys_team/templates/`、`.ys_team/templates/`
+- 是否跨模块：否
+- 是否涉及 DB 变更：否
+- 是否涉及对外 API 行为变化：否

package/docs/specs/completed/20260410-baseline-fullcomplete/workspace.md

@@ -0,0 +1,26 @@
+---
+Initiative: 20260410-baseline-fullcomplete
+Current-Phase: qa
+Last-Updated: 2026-04-10 10:00
+---
+
+# 工作记忆
+
+## 当前状态
+
+spec-talk 已完成，control.md 和 requirement.md 已产出，等待进入 spec-work。
+
+## 关键决策记录
+
+- qa-report.md 中的项目特定测试命令改为通用注释占位 — 原 ai-gateway 版本有 `uv run pytest`，不适合通用 baseline
+- _sources.md 格式问题不纳入本 spec — 根因在 init/rebuild skill 执行逻辑，超出当前范围，记为 Note
+- 两个目录同步补全 — 本仓已切 full-auto，本仓 .ys_team/templates/ 也必须同步
+
+## 遗留问题
+
+- _sources.md 格式一致性（init/rebuild skill 执行问题）— 优先级：中，由后续 spec 处理
+
+## 阶段输出摘要
+
+- spec-talk → PASS，产出 control.md + requirement.md + workspace.md
+- spec-work → PASS，8 个模板文件写入完成，验收通过

package/examples/baseline/.ys_team/VERSION

@@ -1 +1 @@
-0.2.0
+0.3.0

package/examples/baseline/.ys_team/memory/policy.md

@@ -0,0 +1,66 @@
+# 记忆管理策略
+
+## 结构
+
+```
+.ys_team/memory/
+  ├── roles/           ← 角色独立记忆（跨任务经验）
+  │   └── <role>.md    ← 每个角色一个文件
+  └── policy.md        ← 本文件
+```
+
+工作记忆（workspace.md）不在此目录，而是跟随 spec 生命周期，位于 `docs/specs/<id>/workspace.md`。
+
+## 角色独立记忆
+
+- 每个角色只读写自己的记忆文件，互不可见
+- 记录跨任务的经验积累，不记录当前任务的临时状态
+- 长度上限由 TEAM.md 的 `memory.role_memory_limit` 配置（默认 2k）
+
+### 写入时机
+
+每个阶段结束时，角色回顾本次工作，决定是否有值得记住的经验。使用以下判断标准：
+
+1. 是否发现了非显而易见的技术陷阱或模式？
+2. 是否有需要在未来同类任务中注意的点？
+3. 是否有关于这个项目/模块的特殊知识？
+
+无新认知时不写入。
+
+### 压缩策略
+
+读取记忆时发现超限，结合本次要写入的新内容一起压缩：
+
+- 保留所有仍然相关的经验
+- 合并相似条目
+- 删除已过时或被后续经验覆盖的条目
+- 保留具体的文件路径、错误信息、配置值，不泛化
+- 压缩后不超过配置上限
+
+### 记忆格式
+
+```markdown
+# <role> 经验记忆
+
+## <主题 1>
+- 具体经验条目（含日期标记）
+
+## <主题 2>
+- 具体经验条目（含日期标记）
+```
+
+按主题分组，每条经验附日期，便于判断时效性。
+
+## 工作记忆（workspace.md）
+
+- 位于 `docs/specs/<id>/workspace.md`
+- 记录当前任务的实时状态：进度、阻塞、决策、各阶段间传递的上下文
+- 长度上限由 TEAM.md 的 `memory.workspace_limit` 配置（默认 2k）
+- spec 关闭后自动归档（随 spec 目录保留）
+
+## 健康检查
+
+rebuild 时检查：
+- 角色记忆文件是否超限
+- 是否有角色记忆文件对应的角色已从 TEAM.md 移除（标记为归档，不删除）
+- 是否有新角色缺少记忆文件（自动创建空文件）

package/examples/baseline/.ys_team/memory/roles/delivery-guard.md

@@ -0,0 +1,3 @@
+# delivery-guard 经验记忆
+
+（暂无记录）

package/examples/baseline/.ys_team/memory/roles/doc-spec-steward.md

@@ -0,0 +1,3 @@
+# doc-spec-steward 经验记忆
+
+（暂无记录）

package/examples/baseline/.ys_team/memory/roles/domain-integrator.md

@@ -0,0 +1,3 @@
+# domain-integrator 经验记忆
+
+（暂无记录）

package/examples/baseline/.ys_team/memory/roles/project-architect.md

@@ -0,0 +1,3 @@
+# project-architect 经验记忆
+
+（暂无记录）

package/examples/baseline/.ys_team/memory/roles/qa-guard.md

@@ -0,0 +1,3 @@
+# qa-guard 经验记忆
+
+（暂无记录）

package/examples/baseline/.ys_team/memory/roles/spec-reviewer.md

@@ -0,0 +1,3 @@
+# spec-reviewer 经验记忆
+
+（暂无记录）

package/examples/baseline/.ys_team/roles/internal/qa-guard.md

@@ -0,0 +1,30 @@
+# qa-guard
+Title: 质量保障守门人
+subagent_policy: local_only
+
+独立验证落地效果是否符合 spec。读取 spec、代码变更和测试结果，不参与执行过程，确保验证客观性。
+
+## 职责
+
+- 对比 control.md 的 verification 条目与实际落地结果
+- 执行或检查测试命令，验证功能正确性
+- 检查 write-scope 内的代码变更是否符合 spec 要求
+- 识别遗漏的验收点、未覆盖的边界条件
+- 输出 qa-report.md（result card 格式：PASS / REJECT + issues）
+
+## 输入
+
+- `docs/specs/<id>/control.md`（spec 定义）
+- `docs/specs/<id>/work.md`（执行记录）
+- `docs/specs/<id>/workspace.md`（工作记忆）
+- 项目代码（write-scope 范围内）
+
+## 输出
+
+- `docs/specs/<id>/qa-report.md`
+
+## 约束
+
+- 只读 + 可执行测试命令，不修改业务代码
+- 不参与执行过程的讨论或决策
+- 验证意见必须具体到哪个 verification 条目、实际结果是什么、差异在哪