flydb-analysis

Flydb Analysis

围绕用户提出的变更开展调查，回答哪些地方需要同步处理、证据是什么、哪些问题尚无法确定。由宿主模型选择搜索路径；以实际读取的材料约束结论。

开始调查

从对话和当前项目提取拟议变更、目标对象、分析目录及可用材料。先查项目事实，再询问影响判断所必需的缺失信息。

• 目标至少落实到表与字段或一段具体 SQL。用户只给出同名字段且无法确定所属表时，列出具体候选，集中问一个问题；可以继续做不依赖该选择的项目识别。
• 没有数据库连接、没有 Flydb、缺少构建工具，都不阻止已有材料的分析。根据实际能力选择 材料与工具接入。
• 先简短说明已理解的变更和可见范围。用户已给出的路径、目标和授权不重复询问。
• 首版重点完成删列、改名的影响分析。类型、可空性和默认值变更可以分析，但依赖实际数据、隐式转换或厂商版本的结论要列出待核验条件。

调查流程

1. 建立目标身份与材料清单

确认 catalog/schema/table/column 中已知的部分、引号和大小写规则，分别记录数据库实际名称、SQL 别名、应用属性。未知部分保持未知，不能把不同 schema 的同名字段合并。

识别项目中的持久化方式、SQL/XML/源码、任务脚本和数据库定义。优先使用宿主搜索或 rg，读取能解释关系的上下文；发现外部目录、子模块、被忽略的 SQL 或部署产物时记录访问范围，不把搜索默认排除项当作已扫描。

区分当前代码、历史迁移、用户提供的快照和实时数据库查询。记录仓库修订与未提交状态，或非 Git 材料的版本/来源；不要为取得这些信息初始化仓库。

完成条件： 目标可辨认，可用材料与缺口已列明，知道从哪些入口开始追查。

2. 沿引用追查影响

围绕目标提出可检查的假设，执行“搜索 → 读上下文 → 关联下一处证据 → 核验或保留假设”的循环。SQL/ORM/动态调用的调查要点按需读 引用与影响调查。

先找直接引用，再沿映射、调用者和消费字段追到能够解释影响的地方。别名、共用片段、物理命名、动态列名和 SELECT * 都可能需要扩展搜索词。已有工具能给出的事实直接复用；工具缺位时可用宿主脚本完成局部提取，无需先建设全项目解析器。

• 将每条重要发现关联到亲自读取的来源位置，保留目标身份、映射关系和中间证据。
• 搜索结果只用于定位；没有读取上下文的命中不作为确认引用。
• 用实际调用关系判断影响范围。存在某个服务方法，并不证明生产一定执行该路径。
• 对动态标识符追查其值来源。可枚举的常量或白名单能缩小范围；来源缺失或由外部输入决定时保留条件与未知范围。
• 排除与目标不同 schema、不同表的同名对象，以及无调用证据的历史脚本；记录关键排除理由，避免用户再次怀疑漏项。

完成条件： 每个已发现的重要候选已归为有证据的引用、有条件的推断、已排除或待核验；相关入口仍未检查时继续调查或明确留下缺口。

3. 校验发现与覆盖范围

按 报告约定 整理事实、推断和未知项。复查重要引用的位置与目标一致性，确认推断中的每个关键跳转是否有材料支撑。

对每类可见材料记录检查范围、未检查部分、失败和截断原因。文件读取数量只说明材料处理进度，不能证明语义覆盖率；工具查询为空，也可能受权限、对象类型或 schema 范围限制。

证据冲突时并列记录来源、环境和时间，按来源分别给出结论；只有身份与范围可比时才讨论漂移。没有实时证据时使用“在提供的快照中”，避免将快照当作当前数据库。

完成条件： 结论可回查；未知项与剩余核验动作可操作；没有把“未发现”转成“安全”或“没有依赖”。

4. 交付与继续

先告诉用户最需要同步处理的地方，再说明依据、限制和最小的后续核验动作。默认提供简洁摘要及 Markdown 报告；用户只要口头判断时直接在回答中使用同样的证据语义。

输出目录遵循用户指定位置或项目已有产物约定；都没有时使用 artifacts/flydb-analysis/<时间戳>-<短标识>/impact-report.md。创建新目录避免覆盖旧报告，搜索时排除本次输出目录。不自动修改忽略规则或提交产物。用户要求机器消费时才按报告约定额外输出 JSON。

调查较长或即将中断时，在输出目录保存 investigation-notes.md，记录目标、材料版本、已核验引用、剩余候选和下一步。恢复时先检查修订和文件是否变化，重新核验受影响证据；旧结论不是本次读取的替代品。

停止条件： 相关候选都已处理或有具体阻塞原因，用户限定范围已完成；达到用户给定时间/成本边界时交付部分结果。若范围开放且持续扩张，先交付当前结果和明确剩余范围，不自行启动无限制扫描或后台任务。