Project Profile：把项目当前形态讲清楚

Ponytail 风格：最短但足够完整的项目说明，不是最全面的源码百科。 让读者先形成整体认识，再按任务深入相关代码与记忆；不靠打开十几个链接才拼出基本概念。

1. 维护一份入口，不另造知识系统

• 先读项目指令，确认已有画像或等价架构说明；能承担当前整体说明的文档就原位完善，不按名字另建副本。目录树、日志或纯链接清单不算完整画像。
• StrictDoc 项目默认使用 docs/handbook/project-profile.sdoc；项目已有布局与格式优先，不为画像安装依赖、迁移文档或改变版本控制规则。
• 在项目 AGENTS.md 或已有接手入口留下实际路径，让 load-mem 能找到；那里只放指针，不复制整篇画像。
• 画像是当前事实与认识的说明，不是第二套规范：现行意图按有效决策解释，实现按当前源码／配置核实，研究判断按推导、观察和实验等证据限定，运行状态按实测记录。冲突并列说明，不凭画像替换原有权威或偷偷改变决策。
• 只维护授权范围；多个仓库共同构成项目时，讲清归属与跨仓接口，不把外部库写成本仓实现。不越权扫描无关目录、私密配置或原始数据。

2. 先建立整体认识，再写正文

1. 找主线：从项目目标、README、已有研究说明和有效决策识别问题、交付物、边界及当前阶段；科研主线可为问题，多条求解路线并行，不先选唯一赢家。
2. 追真实流程与证据：工程沿入口 → 调用／数据／状态流转 → 输出核对实现；科研沿问题 → 路线 → 推导／观察／实验核对认识。目录和代码图用于导航，不能代替理解；无代码的研究不硬套调用链。
3. 定位设计与方法：找影响项目的模块边界、接口、约束、研究假设和取舍；理由不明时标未知，不编造意图。历史仅补理由，不直接充当现状。
4. 写一份说明：用下面的问题检查覆盖，按真实项目取舍章节；不要求每个模块一节，不硬凑对称模板。

• 正文足以解释整体，链接用来深入而不是补齐基本认识。优先短语、列表、紧凑表格与短流程；加载 readable-docs，不贴完整目录树、接口清单或聊天历史。
• 重要设计可多写，简单模块一句即可；不设固定字数或压缩率，不为简短省掉条件、负结果、边界与未知。
• 代码只摘解释设计所必需的片段，并标注相对路径与函数／类型名；源码摘录与解释性伪代码明确区分。主要按路径和符号定位，不依赖会漂移的行号；实现改变时同步检查摘录，避免第二份源码。
• 敏感值、临时令牌和个人环境不抄进画像；运行前提指向既有配置入口，不把当前机器特例写成项目通则。

重要设计：解释保护什么，不只列出功能

• 用具体场景串起 要保证什么 → 什么情况下会出问题 → 当前机制与代码位置 → 代价、适用边界或重议条件。这是解释线索，不是每个模块必填的模板；不为每个保护分支新增决策。
• 画像保留理解整体所必需的理由；复杂机制、跨模块约束在已有 handbook／专题说明中按主题展开。短说明与详细记录可以重叠，但不维护几份完整副本；知识分工按 save-mem，重要理由不能只靠拼接 journal 才能找到。
• 依据有效决策、历史证据和相关实现解释设计；推断标为推断，理由未知就留未知。记录设计意图不等于证明实现已经保证它；前提已变也不意味着可以未经确认删掉既定保护。

科研画像：研究地图与实现地图并存

• 先讲研究问题与要获得的认识，再讲主要路线如何贡献；路线可竞争、互补、依赖或分条件适用。理论推导、方法探索、诊断测量都可属于主线，不以有没有代码或最近跑得多来排序。
• 每条主要路线简述：核心思路／假设、当前证据及适用边界、推进状态、关键未知与下一步；关联已有推导、代码、配置、结果和说明位置。用现有路线名称保持对应，不新增路线文件或登记系统。
• 推进状态与认识状态分开：正在做／暂停／阶段完成，分别可能对应尚属假设／局部支持／证据冲突／条件性否定。沿用项目词汇，不强制枚举；实验完成不等于假设成立，暂停不等于证伪。
• 画像保留路线全景与有价值的分歧，不只列当前领先方法；细节与原始证据留已有专题和产物。无证据的想法如实标明，不为表格完整编造实验、推导或结论。

3. 持续维护，不每轮重建

• 形态变化包括目标／阶段、模块职责、主流程、公开接口、关键设计、运行方式或重要能力边界的变化。重构移动入口、合并职责或改变保护机制时，局部更新相关定位与设计解释；仅函数内部精简、整体认识未变时不刷新画像，也不为此追加流水。使用方式变化另同步原有 README／手册，不把全部文档搬进画像。
• 研究路线加入／暂停／重开、关键假设被推翻或证据强度实质变化，即使代码目录未变也局部更新；普通运行进度、单次指标波动不机械刷新。
• 更新前核对受影响实现或研究证据，保留仍有效内容；缺少画像时不要在普通保存中自动扩大任务，可提示用本 skill 建立。
• 文件头简记最近核对日期、依据的版本或工作区状态及覆盖边界。局部更新只说明本次核对部分，不把旧段落一起标成已全面验证；无 Git 项目按实际来源记录，不制造提交号。
• 发现漂移时先核实与当前任务相关的部分，再据权限修正或报告；不因发现一处旧路径就全仓重建。画像帮助定位，修改前仍须读取相关真实实现。

4. 核对与停止

• 事实核对：路径／符号确实存在，核心流程有源码依据；摘录仍匹配，链接可达；没有把计划、历史方案或静态检查写成当前运行能力。
• 设计核对：关键保护目的、条件与实现是否对应？说明能否解释看似多余的结构为何仍有必要，或哪些前提已失效？重要理由未只留在历史中，未知与未验证仍可辨认。
• 研究核对：各主要路线的假设、证据、推进状态与结论边界是否仍一一对应？共同问题、路线关系、分歧和关键未知可见，未执行、暂停、证据不足与条件性失败没有混为“已放弃”。
• 接手核对：仅从画像能否解释主要工作方式与边界？拿真实任务推演，能否指出该看哪些实现或研究材料、为什么、哪些关联约束不能漏？若仍要漫游全仓才能作答，补缺少的关系，不堆更多文件名。
• 维护核对：是否只有一个当前入口？是否把历史细节、重复规范或流水搬进画像？只保留帮助后续判断的内容，深入证据留在原处。
• StrictDoc 使用现有 grammar，按 save-mem 的格式指引写入；运行 strictdoc export . 并检查相关导出正文。格式通过不等于事实正确或接手效果已经实测。
• 达到本次范围就停。短答交付路径、建立／更新范围和实际验证，说明未覆盖部分；不新增画像生成器、扫描服务、报告或管理台账。