light-memory-pm

# 上下文管理、记忆持久化与科研项目管理

## 记忆系统 SSOT 决策表（先查这里，再动手写）
两套记忆系统并存——**跨会话 Light 记忆文件**(user/feedback/project/reference + MEMORY.md 索引)与**项目库 db09**——极易把同一类信息写错地方或两头都写造成漂移。落盘前先按下表定位**唯一权威落点**(SSOT)，再决定是否需 MEMORY.md 索引双写。**铁律**：权威落点只有一个；MEMORY.md 只放**索引行**(指针)，绝不放权威正文。

### 表一：每类信息 → 唯一权威落点 + 是否双写

| 信息类别 | 唯一权威落点(SSOT) | 是否需 MEMORY.md 索引 | 反例(别写这) |
|---|---|---|---|
| 个人偏好(写作风格/工具/格式习惯) | Light **feedback 记忆**文件 | 是(索引行) | 别塞进 db09 project_card |
| 项目背景/进展/状态(idea/数据/实验/版本/投稿) | db09 **project_card.md**(14 字段) | 否(项目内事实不进 MEMORY) | 别写进 feedback/MEMORY 正文 |
| 跨项目过程教训(踩坑/被拒/复现失败/省时避雷) | db09 顶层 **lessons.md** | 否 | 别留在某项目 decision_log 当全局教训 |
| 方法选型事实(某方法适用条件/优劣/基线) | db03 **方法卡** | 否 | 别进 lessons.md(那是过程教训非方法事实) |
| 术语/指标/创新点定名 | db09 项目 **terminology.md** | 否 | 别散落各材料正文 |
| 重大决策时间线 | db09 项目 **decision_log.md** | 否 | 别只记在对话里 |
| 跨会话项目背景/参考资源(供新对话快速恢复) | Light **project/reference 记忆**文件 | 是(索引行) | 别只写 db09(新对话不会自动扫 db09 全库) |

### 表二：边界裁决(易混三对，照此切)

| 看似都能放 | 归属判据 | 落点 |
|---|---|---|
| 偏好 vs 教训 | "我习惯这么做"=偏好；"这么做导致被拒/复现失败"=过程教训 | feedback 记忆 / lessons.md |
| 教训 vs 方法事实 | "三模块纯串联当创新点会被拒"(对任意 CV/ML 成立)=教训；"OC-SORT 适合无 re-id 跟踪"=方法事实 | lessons.md / db03 |
| 项目内决策 vs 跨项目教训 | 带研究方向前提(如"白羊外观同质化弃 re-id")=项目内；剥离方向后仍成立=可上 lessons | decision_log.md / lessons.md(去偏科化后) |

> 写 lessons.md 须**去偏科化**(剥离研究方向前提，抽到对任意学科成立的层面)，a02 起草、归档点由用户拍板(详见下「跨项目教训回写」)。校验工具：`scripts/check_project_card.py`(日期/枚举/行格式/衔接链)、`scripts/version_tag_reconcile.py`(version_history↔git tag 对齐)。

## 持久化（用 Light 记忆系统 + 项目库 db09）
- 跨会话事实写入记忆文件(user/feedback/project/reference)，并在 MEMORY.md 加索引行。其中 **feedback 记忆槽的「跨项目过程教训」部分结构化落地为 db09 顶层 `lessons.md`**（与 `projects/` 平级，格式见下）；feedback 记忆文件本身仍存个人偏好类反馈。
- 项目级状态写入 db09 的 project_card：`project_name, goal, current_stage, confirmed_idea, data_status, method_status, experiment_status, paper_status, ppt_status, code_status, risk_list, next_actions, decision_log, version_history`。
- 相对日期一律转绝对日期再存。
- **两层记忆模型**（借 LangGraph checkpointer/Store 与 mem0 的作用域设计）：会话级状态(≈thread_id，短期、随会话压缩可丢)与项目级状态(≈跨会话的 Store/db09，长期、按"项目"namespace 持久)分开管理。关键事实即使能被自动抽取也要显式写入——自动记忆(mem0 式 LLM 抽取)会漏记，db09 是权威来源。

## 记忆写入机制（招牌功能，硬性定义）
四类记忆文件**存哪、什么格式、何时写、何时读**，照此执行，不得省略。

### 存哪（落盘路径）
全部存到 db09，每个项目一个独立目录（相对本技能目录为 `../../databases/db09-projects/projects/<project_name>/`）：
```
databases/db09-projects/projects/<project_name>/
├── project_card.md       项目卡：14 字段总览（next_actions 在此）
├── terminology.md        术语/指标/创新点统一定义表（供 a07）
├── decision_log.md       重大决策时间线
└── version_history.md    论文/PPT/图表/代码各版本记录
（可选子目录 literature/ reviews/ submissions/ 见 db09 README）
```
`<project_name>` 用短横线英文 slug（如 `dairygoat-detect-track`）。已存在实例可直接参考：`projects/dairygoat-detect-track/`（四文件齐全；version_history.md 在未出正式版本前只记当前态、不编造历史版本）。

### 什么格式（四文件确切结构，模板见 db09 `project_card_template.md`）
1. **project_card.md** — 顶部 YAML frontmatter（`project_name` / `created` 绝对日期），正文 `# 项目卡：<中文标题>`，再用一个 ```yaml 代码块装 14 字段：`project_name, goal, current_stage, confirmed_idea, data_status, method_status, experiment_status, paper_status, ppt_status, code_status, risk_list, next_actions`，末两字段写 `decision_log: 见 decision_log.md`、`version_history: 见 version_history.md`。多行字段用 `|` 块标量。
2. **terminology.md** — Markdown 表：`| 类别 | 标准叫法 | 缩写 | 英文 | 备注 |`，类别取 方法/数据集/指标/创新点；创新点行标准措辞须与论文/PPT/软著一字对齐。
3. **decision_log.md** — 每行一条：`- [YYYY-MM-DD] 决策 — 理由 — 来源(m03/m04/m14…)`。只追加不改写，保留时间线。
4. **version_history.md** — 每行一条：`- [YYYY-MM-DD] 材料(论文/PPT/图/代码) vN — 变更摘要`，与 git tag 对齐（见下「管理工具映射」）。

## 该记什么
项目背景、研究问题、已确认 idea、数据情况、实验进度、论文/PPT/图表/代码各自版本、投稿与审稿记录、用户偏好(写作风格/工具/格式)、目标期刊、格式要求、重要决策(decision_log)。
**不记**：代码结构、git 历史、能从仓库直接看出的东西。

## 项目阶段拆解
把项目拆成：资料调研→idea 构思→方案确认→数据准备→实验实现→结果分析→论文写作→图表制作→投稿准备→答辩展示→成果转化。每阶段建：
- **任务清单**(可勾选)、**时间线/甘特**、**里程碑**、**风险清单**、**版本记录**。
- 落到工具时：一个阶段=一个里程碑(GitHub milestone，带 due 日期)，阶段内任务=带 `- [ ]` 复选框的条目，风险项打 `risk` 标记。`- [x]` 用于已完成项，便于自动统计进度。

## 管理工具映射（见 a09，具体用法/端点/参数见 references.md）
- **代码/文本/稿件版本→Git**：里程碑用带注释标签 `git tag -a v1.2.0`（注释标签才被 `git describe` 识别），遵循 SemVer，论文/PPT 也打 tag 并与 version_history 对齐；CHANGELOG 按 Keep a Changelog；大文件交 DVC；`git push --tags` 才上传。
- **数据/实验→DVC / MLflow / W&B**：DVC `dvc add` 生指针、`dvc.yaml` 定 stage、`dvc exp run`+`metrics diff`；MLflow `start_run`+`log_param/metric/artifact` 串 run_id；W&B `init/log`+Artifacts 血缘+Sweeps，记 run URL。data_status/experiment_status 挂对应 commit/run。
- **文献→Zotero**、**项目知识→Obsidian/Notion/Logseq/Markdown**、**进展→README+CHANGELOG**：各自的 API 基址、限流、字段映射见 references.md。

## 更新纪律（硬性）
每次完成：资料搜索、idea 修改、实验运行、论文修改、PPT 修改、投稿返修——**立即**更新 db09 对应字段与 decision_log，避免长期项目上下文丢失。

**触发→写入对照**：idea 定稿→改 `confirmed_idea` + 追加 decision_log；实验跑完→改 `experiment_status` + `next_actions`；论文/PPT/代码出新版→改对应 `*_status` + 追加 version_history（并打 git tag）；方案变更/取舍→追加 decision_log；新术语/指标/创新点定名→补 terminology.md。

**B-fact 引用三件套（硬性，禁裸写数值）**：写 decision_log/data_status 引用 **venue 计量(h_index/被引/分区) / 数据集许可/DOI / 外部数值** 时,不当 db09 自带权威,必带三件套——**快照值(可带 ≈) + `[snapshot YYYY-MM-DD, src=dbNN:文件#定位, 用前重核, 冲突信在线]`**(venue 回指 db01:venues.csv、数据集回指 db04 卡、色值回指 db05 DTCG;palette.json 是样板)。**读卡恢复状态时**:带 last_checked 的快照若超期(计量 >90 天/许可 >365 天)给"需重核"提示,不直接当当前值汇报,投稿/用前以在线(venue_signal.py)或官方源重核。

**跨项目教训回写（节制，避免噪声）**：仅当某决策产生了**可跨项目复用的过程教训**——踩坑、被审稿/导师否掉、复现失败、某流程显著省时/避雷——才在追加 decision_log 的**同时**回写一条 lesson 到 db09 顶层 `lessons.md`（格式：`- [YYYY-MM-DD] 阶段/场景 — 做法 — 结果(有效|失败) — 适用条件 — 来源项目slug`）。日常项目内决策**不强制**回写。边界：方法选型事实归 db03 方法卡，个人偏好归 feedback 记忆，二者不进 lessons.md。**去偏科化（回写时）**：lesson 须剥离研究方向前提、抽到对任意学科成立的层面(如"三模块纯串联当创新点会被拒,须有方法层 delta"对任何 CV/ML 成立=可上;"白羊外观同质化弃 re-id"带方向前提=留 decision_log 不上 lessons);a02 起草、归档确认点由用户拍板。

### 写入步骤示例（落地一次实验进展）
刚跑完检测 baseline（项目 `dairygoat-detect-track`）的五步：① **读现状**：Read project_card.md 看 `experiment_status`/`next_actions` 当前值；② **改项目卡**：Edit 把 `experiment_status` 改为带具体指标的实测描述（如「E1 baseline 已跑：YOLOv11@1280，mAP 0.71」），同步勾掉/替换 `next_actions` 首条；③ **追加决策日志**：decision_log.md 末尾加 `- [日期] 决策 — 理由 — 来源`；④ **记版本**：有可复现 tag 则 version_history.md 加行并 `git tag -a`；⑤ **跨会话索引**：涉用户长期偏好/项目背景则写 Light 记忆文件 + MEMORY.md 索引行。日期一律绝对日期（今天=系统 currentDate）。

## 会话开始