code-deep-research

name	code-deep-research
description	深度拆解开源 GitHub 仓库的源码架构与核心技术设计。用于需要先拉取并锁定源码、建立代码索引、提出 5–10 个由真实代码牵引的复杂问题、通过 DeepWiki 辅助追问并回到本地源码核验的任务；固定只输出 source_notes、code_index 和 deepwiki 三份研究文档。

代码深度调研

目标

从固定提交的本地源码出发，重建项目的核心抽象、执行路径、状态模型、失败语义与扩展边界，再提出能够牵引出关键设计细节的深度问题。DeepWiki 只用于辅助解释与发现线索，锁定提交的本地源码始终是实现事实的最高优先级证据。

适用范围

在用户要求深度研究 GitHub 仓库、拆解源码架构、理解核心机制，或明确要求“先拉代码再问 DeepWiki”时使用本技能。快速 API 查询、单文件代码审查、已批准方案的编码实现，以及不涉及源码仓库的一般网络调研，不使用本技能。

必读文件

执行前完整阅读 WORKFLOW.md，创建文档前阅读 TEMPLATES.md。不要仅凭本页摘要推断详细步骤。

唯一交付物

对仓库名 <repo_name>，只创建以下三份 Markdown 文档：

文件	责任
<repo_name>_source_notes.md	解释源码中的核心抽象、数据与状态、执行路径、失败处理、扩展点和经核验结论。
<repo_name>_code_index.md	记录固定 SHA、核心目录树、实际阅读文件、关键符号、行号范围、测试与检索覆盖。
<repo_name>_deepwiki.md	保存源码初读后形成的 5–10 个复杂问题、DeepWiki 回答、版本状态及逐项源码复核。

当目标仓库为 Semantica 时，文件名必须是 semantica_source_notes.md、semantica_code_index.md 和 semantica_deepwiki.md。

不要自动创建 meta.md、Gap Analysis、Proposal、Evaluation Plan、采用裁决或其他报告。用户另行要求比较、选型或实施方案时，把必要内容并入三份文件中的相应章节；除非用户明确授权，不增加第四份交付物。

强制顺序

1. 拉取目标仓库到本地工作区，核验远程地址并锁定 commit SHA。
2. 初读仓库结构、公开入口、核心抽象、主执行路径、状态模型、失败处理、扩展点和测试。
3. 基于初读代码提出 5–10 个项目特定的复杂技术问题。每个问题必须引用代码锚点，说明未知点和研究价值；禁止先看 DeepWiki 再反向编造问题。
4. 逐题询问 DeepWiki，并保存回答、引用路径、索引版本和失败状态。
5. 回到锁定源码逐项核验回答，标记 已验证、部分验证、与源码冲突 或 未验证，给出纠正后的结论。
6. 完成三份文档并通过质量门。

深度问题标准

问题必须由已观察到的类、函数、协议、数据结构、配置或测试牵引，不能只问“项目架构是什么”或“有哪些优点”。每个问题应尽量同时追问机制、边界与权衡，并覆盖 5–10 个最相关维度，例如端到端数据流、状态不变量、持久化与一致性、并发与事务、失败恢复、扩展协议、安全边界、性能成本、可观测性或关键设计取舍。

一个合格问题的形式如下：

ContextGraph.add_relation() 同时维护时间字段和图存储状态，而默认后端为内存实现。关系有效期、重复写入和并发更新分别依赖哪些不变量？替换为持久化后端时，哪些一致性语义由接口保证，哪些必须由适配器补充？

证据规则

实现主张必须指向 SHA + 文件路径 + 行号范围 + 符号。README、官方文档和 DeepWiki 可解释意图，但不能替代本地源码。若 DeepWiki 索引提交与锁定 SHA 不一致，必须显式记录版本差异。若 DeepWiki 不可用或未返回有效回答，仍必须创建 <repo_name>_deepwiki.md，保留 5–10 个问题、尝试记录和未验证状态，不得伪造答案。

不要安装全局依赖、执行未知安装脚本、启动付费或破坏性服务、使用真实凭据，或修改被研究项目。需要运行验证时，先取得用户授权，并限制在隔离环境中。

完成条件

只有在仓库已锁定 SHA、六类源码证据已覆盖、5–10 个深度问题均已记录、每个 DeepWiki 回答均已回到源码复核、三份文件相互引用一致且未创建多余交付物时，才能宣布完成。最终回复只需说明锁定版本、三份文件路径、最重要的技术结论与仍未验证事项。