forsakesoul 提炼项目面试知识
把已经实现或真实发生的工程工作整理成可追问、可核对的面试知识。输出是教学与面试叙事，不是现状文档、功能规格或代码审查；默认只修改目标知识库中的文档，不修改源项目实现，不 commit、push 或发布。
1. 固定输入
确定源项目、目标知识库、范围（项目/MR/决策/事故）和基线。将分支、Tag 或 MR HEAD 解析为完整 commit SHA，记录源工作区与目标工作区已有修改并保留它们。
分别读取两个仓库的 AGENTS.md、文档入口、索引/catalog 规则和验证命令。用户未指定目标结构时，先查找已有项目知识、相邻主题和仓库模板；能补现有主题时不新建重复章节。
完成标准：源事实绑定不可变 SHA，输出位置与仓库原生接入方式明确，现有用户改动已区分。
2. 追踪真实工程链路
从用户入口或故障症状沿真实调用链阅读相关源码、测试、类型/schema、CI、部署/发布文档和必要 Git 历史。按业务 seam、关键决策或故障根因聚类，不按目录或语言机械分章，也不预设章节数量。
给每项重要主张标记证据等级：
Source：当前基线源码、类型、schema 或配置直接证明。Test：自动化测试证明指定 interface；只说明测试实际覆盖的范围。CI：Pipeline/Job 证明构建或自动化在该 snapshot 运行。Deployment：Tag、镜像、清单或环境版本证明交付身份。Runtime：真实环境、浏览器、日志或用户验收证明运行行为。Inference：证据支持但未直接验证的推断。Unknown：现有材料无法确定。
Source、Test、CI、Deployment 和 Runtime 不能互相替代。历史记录只用于定位，容易漂移的结论必须回到当前基线核对。
完成标准：每个主题都能指出核心矛盾、真实 interface、关键不变量、错误模式和证据边界。
3. 选择值得写的主题
优先保留能产生有效追问的内容：
- 一个真实工程矛盾及其约束；
- 为什么把 seam 放在这里，而不是逐调用点修补；
- 安全、并发、恢复、兼容、性能或发布不变量；
- 失败尝试如何暴露根因，最终方案怎样验证；
- 可迁移到其他项目的判断方法，以及不能泛化的边界。
跳过目录导览、依赖清单、提交流水账、没有证据的项目包装和只会背答案的术语堆砌。敏感实现脱敏后若失去技术价值，则不公开该主题。
4. 写项目索引和主题文档
复用目标仓库现有模板和语气。没有模板时，每篇主题至少包含：
面试定位
项目事实与基线
核心矛盾
链路或设计
源码锚点
验证与证据边界
可出题方向
回答框架
边界、权衡与反思
源码锚点使用稳定格式 repo@SHA:path::symbol；同时写明符号承担什么责任，不只罗列行号。事故主题还应包含触发条件、根因链、错误恢复、回归检查和仍未验证的风险。
回答框架给出思考顺序和证据，不生成夸大影响的标准答案。区分“当前实现”“历史背景”“被拒绝方案”和“未来可能方向”，不得从最终代码编造当时的设计理由。
项目索引按业务链路组织主题并提供一行定位。普通 Markdown 已能被仓库自动发现时，不新增第二套 catalog、路由或生成脚本；只有目标仓库现有规则要求时才更新原生索引。
5. 脱敏与所有权
- 删除内部域名、账号、人员、Token、Cookie、Secret、可重放 URL、真实业务数据和个人绝对路径。
- 公开文档中的项目名、角色名或架构细节若本身不公开，改成不损失技术含义的通用名称；无法安全泛化时停止并报告。
- 跨仓主题在拥有该契约的项目保留完整说明，消费方只写自身视角并链接权威来源，避免两份可独立漂移的全文。
- 不读取或复制未授权的私有聊天、原始日志和生产数据；使用脱敏摘要与源码事实。
6. 验证
逐项检查：
- 所有
repo@SHA:path::symbol在对应基线可解析，正文与符号责任一致； - Markdown 相对链接、项目索引和主题文件一一对应；
- 目标仓库原生 catalog/content 测试、lint 或 build 按影响范围通过；
git diff --check通过，最终变更只包含获准的知识文档与必要原生索引；- 没有敏感值、内部链接、个人路径或把未执行 Runtime 验收写成已验证。
最终报告源基线、创建/更新主题、实际验证、未执行环境、Inference/Unknown 和已有工作区修改。除非用户明确授权，不提交或发布。