chore: memory-sync — 归档 memcore-shared/lint_report 保活/Base commit 兜底等决策

- decisions.md 新增 3 项：memcore-shared 共享层、lint_report 增量保活、Phase 1 锚点兜底
- feedback_plugin_dev.md 新增 2 项：skill 不重写 MCP 参数表、签名变更全量扫描
- project_overview.md：memcore 技能数 3→4，新增 memcore-shared
- AUTO-FIX：feedback#skill-不重写MCP参数表 补反向引用至 decisions
- 引用列：decisions/project_overview/feedback 均为 1，lint_report 为 0
- CLAUDE.md 元数据更新（commit 38beecb），引导区块刷新

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

.claude/memory/feedback_plugin_dev.md

@@ -2,8 +2,8 @@
 name: 插件开发协作反馈
 description: 在此 marketplace 项目中开发插件时需遵守的协作规范和经验教训
 type: feedback
-last_updated: 2026-05-01
-commit: 0c46ed0
+last_updated: 2026-06-12
+commit: 38beecb
 ---
 
 # 插件开发协作规范
@@ -55,3 +55,33 @@ commit: 0c46ed0
 **Why**：本次发现 huanxi-shared 工具索引中 report_submit/withdraw 用了旧名，leader_report_submit/withdraw 缺必填参数，weekly_report_save 参数名用 week 而非 week_number，这些都是 MCP 升级后 skill 未同步导致的。
 
 **How to apply**：每次 MCP server 工具链升级后，运行 plugin-validator 对照检查 skill 中的工具调用。
+
+---
+
+## skill 不要重写 MCP 参数表，引用 docstring 为单一真相
+
+**规范**：MCP 工具的参数细节（字段名、必填、枚举值、类型）以后端 Python 函数 docstring 为**单一真相来源**。skill 文档不要重画完整字段表，最多给一个 happy path 的调用示例 + 历史踩坑说明，在 reference 文档顶部统一声明"参数细节以 MCP `<tool_name>` 的 docstring 为准"。
+
+**Why**：本次发现 `huanxi-report/references/report-draft.md` 的字段表与后端 `report_save_draft` docstring 大幅漂移（缺 module_id 必填、progress 字段名错为 progress 应为 progress_update、虚构 status 字段），直接导致用户日报频繁报"参数缺失"。skill 一旦重画参数表，就和 MCP docstring 形成两套真相 —— 任一处改动另一处就漂移。同类漂移在 weekly（week→week_number）、task（due_date→end_date / urgent→critical / todo→not_started）、org（user_id→id）系列均出现，呈系统性问题。
+
+**How to apply**：
+1. 写 skill 时不画字段表；如非要列字段，必须在文末加"以 MCP docstring 为准"声明
+2. 给 LLM 的提示是"调 MCP 时直接信任 docstring"而非"按本文档调用"
+3. MCP 工具签名变更时**不需要**改 skill（只要 skill 没硬编码参数表）
+
+**See Also**：[[feedback_plugin_dev.md#plugin-validator 和 skill-reviewer 审查之后要对照实际代码修正工具签名]] [[feedback_plugin_dev.md#MCP 后端工具签名变更后必须全量扫描所有 skill]] [[decisions.md#memcore-shared：路径锁定 + 全局常量的单一来源]]
+
+---
+
+## MCP 后端工具签名变更后必须全量扫描所有 skill
+
+**规范**：MCP server 的工具签名（参数名、必填项、枚举值、返回字段）变更后，必须对引用该 MCP 的所有 skill 做全量 grep 扫描，找到漂移点逐一对齐。不要依赖单元测试或调用时报错来"被动发现"。
+
+**Why**：本次扫描发现 huanxi 的 6 个 skill + 7 个 reference 中漂移密度极高：4 类典型模式（字段名错 / 枚举值错 / 缺必填 / 缓存示例与后端返回结构不一致）覆盖所有 huanxi-* 系列。漂移源于后端 docstring 在多次迭代中演进，但 skill 未同步审查。这种漂移在调用时才会被发现（"参数缺失"、"字段不存在"），对用户体验是慢性损耗。
+
+**How to apply**：
+1. 后端 PR 中涉及 MCP 工具的，PR 描述必须列出签名变更点
+2. 合并后立即在 marketplace 仓库做对照扫描（grep 漂移关键词，如旧字段名）
+3. 漂移修正与签名变更在同一 sprint 完成，不留尾巴
+
+**典型扫描点**（针对 huanxi）：参数名 `progress` vs `progress_update`、`due_date` vs `end_date`、`week` vs `week_number`；枚举值 `todo` vs `not_started`、`urgent` vs `critical`；返回字段 `user_id` vs `id`。