OpenMetadata Connector Audit 实施阶段P7实战指南从重构计划到可验证的修复提交【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata导读本文讲解 OpenMetadata 开源仓库中connector-audit技能体系的最后一个环节——Prompt 7「Implementation」在完成 P1P5 深度调查与 P6 重构评估之后如何把.claude/audit-results/06-refactor-plan.md中的每一项修复按优先级落地为真实代码、可运行的 pytest 测试和规范的 git 提交并借助静态分析器与评分基线验证修复效果。读完本文你将掌握完整模式默认实施与--dry-run计划模式两条执行路径、单连接器与共享代码的提交边界策略以及如何用 before/after 评分量化审计修复的产出。一、P7 在整条审计流水线中的位置connector-audit技能定义见 skills/connector-audit/SKILL.md是一套七阶段的深度可靠性审计流程Setup → P1-P5并行调查→ P6综合与重构计划→ P7实施P0 Setup00-setup.md负责确定被审计连接器并把连接器名、服务类型、源码路径写入上下文文件.claude/connector-audit.json格式为{ connector_name: name, service_type: type, source_path: ingestion/src/metadata/ingestion/source/type/name/ }P1P5分别聚焦元数据与摄取完整性、错误处理与韧性、连接与认证、血缘、规模与性能各 prompt 报告按固定文件名落盘到.claude/audit-results/例如01-metadata-ingestion.md、02-error-handling.md评级校准规则可见 01-metadata-ingestion.md 与 02-error-handling.md。P6 Refactor Assessment06-refactor-plan.md把所有报告交叉校验、聚类根因、按「就地修复 / 共享基类修复 / 抽取共享逻辑 / 架构重构 / 新增功能」分类并估算工作量S/M/L与风险低/中/高最终输出带 PR 切分顺序的.claude/audit-results/06-refactor-plan.md。P7 Implementation07-implementation.md读取 P6 计划并严格执行是整条流水线唯一真正产出代码与提交的阶段。P7 报告按约定保存为.claude/audit-results/07-implementation.mddry-run 模式下为07-dry-run-implementation.md与 P1P6 报告共同构成可追溯的完整审计记录。二、两种执行模式默认实施 vs--dry-runP7 支持两个入口决定「写不写代码」模式行为产出默认不带参数实际写代码、跑测试、创建 git 提交.claude/audit-results/07-implementation.md实施报告--dry-run只产出详细实施计划精确的 before/after 代码 diff、完整可运行的测试代码、风险标记与缓解措施、提交信息不写任何代码、不创建提交.claude/audit-results/07-dry-run-implementation.md--dry-run的价值在于给用户一个「零风险预览」在真正改动代码前先就每一个工作项确认改动方向、测试方案与提交粒度尤其适合高风险架构改动如更换基类、补充 mixin或涉及共享代码的变更。dry-run 计划经用户确认后才可进入实际实施。无论哪种模式都必须严格遵循 P6 计划的 PR 结构与工作项顺序。若对某个工作项的处理方式有异议须先说明理由再改变若决定放弃计划中的可选工作项必须记录省略项并解释原因。实施前通过/connector-standards加载连接器标准标准文件位于 skills/connector-review/standards/ 及 skills/connector-review/standards/source_types/。三、动工前的前置检查worktree 与测试基线进入实施前有两步强制检查确认身处 worktree 分支执行git branch应当位于task/[connector]-reliability分支。审计修复不应污染主开发线worktree 隔离是 OpenMetadata 连接器修复的常规实践。先跑既有测试建立基线cd ingestion python -m pytest tests/unit/[relevant_test_files] -v基线测试结果用于两件事一是确认改动前已有哪些失败本 PR 不修与发现无关的既有失败二是在实施完成后对照基线验证「无回归」。四、逐项修复的标准化流程P6 计划中的工作项按优先级排列Priority 1 为 ❌ Gaps功能损坏或缺失Priority 2 为 ⚠️ Partial既有功能的改进。对每个工作项执行以下五步先解释再动手——说明改什么、为什么改、预期行为是什么最小化实施——改动保持聚焦不做无关重构关注点分离——bug 修复与重构即使触碰同一文件也要分属不同提交为一切行为变更补测试——必须是完整、可运行的测试代码不允许占位注释或伪代码使用 pytest 风格普通assert不用TestCase包含 imports、fixtures 与断言格式与 lint——改动后在 ingestion 目录执行make py_format make py_format_check这两个目标在 ingestion/Makefile 中定义py_format用 ruff 自动 lint 修复并格式化py_format_check校验格式是否符合规范。五、提交策略与多连接器修复边界提交策略一个逻辑变更一个提交不捆绑无关修复提交信息格式固定fix([connector]): [what]或refactor([connector]): [what]共享代码变更单独提交若改动了common_db_source.py、builders.py这类共享模块必须与连接器专属改动分属不同提交——这也是 P6 PR 切分「共享代码先行」原则在提交粒度的延伸。多连接器修复当同一个缺陷出现在多个连接器例如共享基类中的模式问题时本 PR 只在共享代码中修复一次记录哪些其他连接器受益于该共享修复记录哪些其他连接器需要连接器专属的后续跟进不在本 PR 修复其他连接器——每个连接器独立成 PR避免大而杂的改动面。六、What NOT to Do实施红线清单P7 明确列出了禁止事项这些约束本质上是把 P6 计划边界延续到代码层面不为了风格偏好改动运行正常的代码不给自己没改过的代码加注释不重构与审计发现无关的代码不在本 PR 修复其他连接器的问题不跳过测试——如果某项改动无法测试必须标记为需人工验证而不是默默跳过。七、实施完成后的验证闭环默认模式验证与评分更新所有修复实施并通过测试后1. 展示 before/after 汇总并逐条列出每个发现的处置Before: 5.8/10 — 3 blockers, 6 warnings, 4 suggestions After: 8.6/10 — 0 blockers, 1 warning, 2 suggestions#1 HIGH SSL config not wired to driver → FIXED: added ssl_args extraction in connection.py #2 HIGH IAM token no refresh → FIXED: added pool event listener for token regen #3 MEDIUM hostPort not validated for IAM → FIXED: added format validation with clear error2. 重跑静态分析器验证修复python skills/connector-review/scripts/analyze_connector.py {service_type} {name}静态分析器analyze_connector.py提供机械化的基线检查是 P7 验证的关键工具。它能自动发现的问题类型包括分页缺陷client.py中返回列表的方法没有next_link/offset/has_more等分页模式可能造成静默数据丢失内存风险无大小检查的.read()/.download_as_string()OOM 风险、无clear()的无界缓存、yield方法中的列表累积、list(...)包裹yield_per()/partitions()等流式原语被物化、存储型连接器缺失gc.collect()Schema 与安全verifySSL/sslConfig定义在 schema 中但connection.py未解析、client.py未设置session.verifySonarQube Security Review 会失败、HTTPS 连接器缺 SSL 配置、username/password未列入required、schema 缺$id/javaType/additionalProperties: falsePydantic 模型使用Field(alias...)但缺少model_config ConfigDict(populate_by_nameTrue)测试质量空测试桩pass方法体、无断言的测试文件、CONNECTOR_CONTEXT.md被 git 跟踪血缘精度table_name*通配符血缘搜索导致全库表错误关联。3. 提出评分更新建议——列出哪些标准评级会因修复而变动及理由Connection Setup: ⚠️ → ✅ (SSL wired, all auth methods tested) Fault Tolerance: ❌ → ⚠️ (token refresh added, still no query retry)4. 保存实施报告到.claude/audit-results/07-implementation.md包含PR 级概览改了什么、哪些文件、测试结果、偏离计划的工作项及原因、延期的工作项及原因、带验证步骤的风险标记。保存前先征询用户确认。dry-run 模式只呈现计划dry-run 模式对计划中每个工作项产出before/after 代码 diff精确到文件路径与行号、完整可运行的 pytest 代码非伪代码、风险标记及验证/缓解步骤、符合fix([connector]): [what]格式的提交信息。随后给出汇总PR 级概览、与计划的偏离点及原因、计划新增的测试覆盖说明、需人工验证的风险项最后询问是否保存到07-dry-run-implementation.md。八、源码视角P7 产出的代码形态参考P7 要求「行为变更必须配可运行的 pytest 测试」而测试断言的对象正是 OpenMetadata 连接器源码中的核心模式。以数据库类连接器为例实体级错误处理依赖Either模式定义于 ingestion/src/metadata/ingestion/api/models.py 引用的metadata.ingestion.api.models共享基类 common_db_source.py 中的yield_table是标准示范成功路径yield Either(righttable_request)失败路径用yield Either(leftStackTraceError(nametable_name, errorerror, stackTracetraceback.format_exc()))包裹实体名、错误信息与完整堆栈——这正是 P2「Error Clarity」标准要求、P7 需要补齐/保持的模式。从源码结构看所有 P7 生成的修复测试都应围绕这类Either[right, left]返回值、yield_*生成器以及connection.py/client.py的 SSL 与 token 处理展开断言。九、与 connector-review 技能的协同P7 的验证手段静态分析器、评分更新与 connector-review 技能共享同一套标准与工具analyze_connector.py在 connector-review 中用于 PR 广度审查的机械基线在 connector-audit 中则作为 P7 修复后的回归验证。两个技能的分工是connector-audit面向「大修前的深度可靠性调查」7 个 prompt、小时级分析、产出 7 份报告connector-review面向「PR 评审时的广度检查」5 个并行 agent、分钟级、只覆盖改动文件。修复完成后若连接器进入 PR 流程connector-review 会再次以同一标准把关形成「审计→修复→评审」的闭环。十、小结P7 Implementation 把抽象的重构计划变成可验证的工程产出其关键纪律可概括为四句话严格遵循 P6 计划及其 PR 顺序一个逻辑变更一个提交共享代码改动单独成提交并只修一次任何行为变更都必须有可运行的 pytest 测试。配合--dry-run的零风险预览、静态分析器的机械回归验证以及 before/after 评分对修复成效的量化呈现P7 保证了审计发现最终以高质量、可回滚、可追溯的方式合入 OpenMetadata 的连接器代码库。【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenMetadata Connector Audit 实施阶段（P7）实战指南：从重构计划到可验证的修复提交
OpenMetadata Connector Audit 实施阶段P7实战指南从重构计划到可验证的修复提交【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata导读本文讲解 OpenMetadata 开源仓库中connector-audit技能体系的最后一个环节——Prompt 7「Implementation」在完成 P1P5 深度调查与 P6 重构评估之后如何把.claude/audit-results/06-refactor-plan.md中的每一项修复按优先级落地为真实代码、可运行的 pytest 测试和规范的 git 提交并借助静态分析器与评分基线验证修复效果。读完本文你将掌握完整模式默认实施与--dry-run计划模式两条执行路径、单连接器与共享代码的提交边界策略以及如何用 before/after 评分量化审计修复的产出。一、P7 在整条审计流水线中的位置connector-audit技能定义见 skills/connector-audit/SKILL.md是一套七阶段的深度可靠性审计流程Setup → P1-P5并行调查→ P6综合与重构计划→ P7实施P0 Setup00-setup.md负责确定被审计连接器并把连接器名、服务类型、源码路径写入上下文文件.claude/connector-audit.json格式为{ connector_name: name, service_type: type, source_path: ingestion/src/metadata/ingestion/source/type/name/ }P1P5分别聚焦元数据与摄取完整性、错误处理与韧性、连接与认证、血缘、规模与性能各 prompt 报告按固定文件名落盘到.claude/audit-results/例如01-metadata-ingestion.md、02-error-handling.md评级校准规则可见 01-metadata-ingestion.md 与 02-error-handling.md。P6 Refactor Assessment06-refactor-plan.md把所有报告交叉校验、聚类根因、按「就地修复 / 共享基类修复 / 抽取共享逻辑 / 架构重构 / 新增功能」分类并估算工作量S/M/L与风险低/中/高最终输出带 PR 切分顺序的.claude/audit-results/06-refactor-plan.md。P7 Implementation07-implementation.md读取 P6 计划并严格执行是整条流水线唯一真正产出代码与提交的阶段。P7 报告按约定保存为.claude/audit-results/07-implementation.mddry-run 模式下为07-dry-run-implementation.md与 P1P6 报告共同构成可追溯的完整审计记录。二、两种执行模式默认实施 vs--dry-runP7 支持两个入口决定「写不写代码」模式行为产出默认不带参数实际写代码、跑测试、创建 git 提交.claude/audit-results/07-implementation.md实施报告--dry-run只产出详细实施计划精确的 before/after 代码 diff、完整可运行的测试代码、风险标记与缓解措施、提交信息不写任何代码、不创建提交.claude/audit-results/07-dry-run-implementation.md--dry-run的价值在于给用户一个「零风险预览」在真正改动代码前先就每一个工作项确认改动方向、测试方案与提交粒度尤其适合高风险架构改动如更换基类、补充 mixin或涉及共享代码的变更。dry-run 计划经用户确认后才可进入实际实施。无论哪种模式都必须严格遵循 P6 计划的 PR 结构与工作项顺序。若对某个工作项的处理方式有异议须先说明理由再改变若决定放弃计划中的可选工作项必须记录省略项并解释原因。实施前通过/connector-standards加载连接器标准标准文件位于 skills/connector-review/standards/ 及 skills/connector-review/standards/source_types/。三、动工前的前置检查worktree 与测试基线进入实施前有两步强制检查确认身处 worktree 分支执行git branch应当位于task/[connector]-reliability分支。审计修复不应污染主开发线worktree 隔离是 OpenMetadata 连接器修复的常规实践。先跑既有测试建立基线cd ingestion python -m pytest tests/unit/[relevant_test_files] -v基线测试结果用于两件事一是确认改动前已有哪些失败本 PR 不修与发现无关的既有失败二是在实施完成后对照基线验证「无回归」。四、逐项修复的标准化流程P6 计划中的工作项按优先级排列Priority 1 为 ❌ Gaps功能损坏或缺失Priority 2 为 ⚠️ Partial既有功能的改进。对每个工作项执行以下五步先解释再动手——说明改什么、为什么改、预期行为是什么最小化实施——改动保持聚焦不做无关重构关注点分离——bug 修复与重构即使触碰同一文件也要分属不同提交为一切行为变更补测试——必须是完整、可运行的测试代码不允许占位注释或伪代码使用 pytest 风格普通assert不用TestCase包含 imports、fixtures 与断言格式与 lint——改动后在 ingestion 目录执行make py_format make py_format_check这两个目标在 ingestion/Makefile 中定义py_format用 ruff 自动 lint 修复并格式化py_format_check校验格式是否符合规范。五、提交策略与多连接器修复边界提交策略一个逻辑变更一个提交不捆绑无关修复提交信息格式固定fix([connector]): [what]或refactor([connector]): [what]共享代码变更单独提交若改动了common_db_source.py、builders.py这类共享模块必须与连接器专属改动分属不同提交——这也是 P6 PR 切分「共享代码先行」原则在提交粒度的延伸。多连接器修复当同一个缺陷出现在多个连接器例如共享基类中的模式问题时本 PR 只在共享代码中修复一次记录哪些其他连接器受益于该共享修复记录哪些其他连接器需要连接器专属的后续跟进不在本 PR 修复其他连接器——每个连接器独立成 PR避免大而杂的改动面。六、What NOT to Do实施红线清单P7 明确列出了禁止事项这些约束本质上是把 P6 计划边界延续到代码层面不为了风格偏好改动运行正常的代码不给自己没改过的代码加注释不重构与审计发现无关的代码不在本 PR 修复其他连接器的问题不跳过测试——如果某项改动无法测试必须标记为需人工验证而不是默默跳过。七、实施完成后的验证闭环默认模式验证与评分更新所有修复实施并通过测试后1. 展示 before/after 汇总并逐条列出每个发现的处置Before: 5.8/10 — 3 blockers, 6 warnings, 4 suggestions After: 8.6/10 — 0 blockers, 1 warning, 2 suggestions#1 HIGH SSL config not wired to driver → FIXED: added ssl_args extraction in connection.py #2 HIGH IAM token no refresh → FIXED: added pool event listener for token regen #3 MEDIUM hostPort not validated for IAM → FIXED: added format validation with clear error2. 重跑静态分析器验证修复python skills/connector-review/scripts/analyze_connector.py {service_type} {name}静态分析器analyze_connector.py提供机械化的基线检查是 P7 验证的关键工具。它能自动发现的问题类型包括分页缺陷client.py中返回列表的方法没有next_link/offset/has_more等分页模式可能造成静默数据丢失内存风险无大小检查的.read()/.download_as_string()OOM 风险、无clear()的无界缓存、yield方法中的列表累积、list(...)包裹yield_per()/partitions()等流式原语被物化、存储型连接器缺失gc.collect()Schema 与安全verifySSL/sslConfig定义在 schema 中但connection.py未解析、client.py未设置session.verifySonarQube Security Review 会失败、HTTPS 连接器缺 SSL 配置、username/password未列入required、schema 缺$id/javaType/additionalProperties: falsePydantic 模型使用Field(alias...)但缺少model_config ConfigDict(populate_by_nameTrue)测试质量空测试桩pass方法体、无断言的测试文件、CONNECTOR_CONTEXT.md被 git 跟踪血缘精度table_name*通配符血缘搜索导致全库表错误关联。3. 提出评分更新建议——列出哪些标准评级会因修复而变动及理由Connection Setup: ⚠️ → ✅ (SSL wired, all auth methods tested) Fault Tolerance: ❌ → ⚠️ (token refresh added, still no query retry)4. 保存实施报告到.claude/audit-results/07-implementation.md包含PR 级概览改了什么、哪些文件、测试结果、偏离计划的工作项及原因、延期的工作项及原因、带验证步骤的风险标记。保存前先征询用户确认。dry-run 模式只呈现计划dry-run 模式对计划中每个工作项产出before/after 代码 diff精确到文件路径与行号、完整可运行的 pytest 代码非伪代码、风险标记及验证/缓解步骤、符合fix([connector]): [what]格式的提交信息。随后给出汇总PR 级概览、与计划的偏离点及原因、计划新增的测试覆盖说明、需人工验证的风险项最后询问是否保存到07-dry-run-implementation.md。八、源码视角P7 产出的代码形态参考P7 要求「行为变更必须配可运行的 pytest 测试」而测试断言的对象正是 OpenMetadata 连接器源码中的核心模式。以数据库类连接器为例实体级错误处理依赖Either模式定义于 ingestion/src/metadata/ingestion/api/models.py 引用的metadata.ingestion.api.models共享基类 common_db_source.py 中的yield_table是标准示范成功路径yield Either(righttable_request)失败路径用yield Either(leftStackTraceError(nametable_name, errorerror, stackTracetraceback.format_exc()))包裹实体名、错误信息与完整堆栈——这正是 P2「Error Clarity」标准要求、P7 需要补齐/保持的模式。从源码结构看所有 P7 生成的修复测试都应围绕这类Either[right, left]返回值、yield_*生成器以及connection.py/client.py的 SSL 与 token 处理展开断言。九、与 connector-review 技能的协同P7 的验证手段静态分析器、评分更新与 connector-review 技能共享同一套标准与工具analyze_connector.py在 connector-review 中用于 PR 广度审查的机械基线在 connector-audit 中则作为 P7 修复后的回归验证。两个技能的分工是connector-audit面向「大修前的深度可靠性调查」7 个 prompt、小时级分析、产出 7 份报告connector-review面向「PR 评审时的广度检查」5 个并行 agent、分钟级、只覆盖改动文件。修复完成后若连接器进入 PR 流程connector-review 会再次以同一标准把关形成「审计→修复→评审」的闭环。十、小结P7 Implementation 把抽象的重构计划变成可验证的工程产出其关键纪律可概括为四句话严格遵循 P6 计划及其 PR 顺序一个逻辑变更一个提交共享代码改动单独成提交并只修一次任何行为变更都必须有可运行的 pytest 测试。配合--dry-run的零风险预览、静态分析器的机械回归验证以及 before/after 评分对修复成效的量化呈现P7 保证了审计发现最终以高质量、可回滚、可追溯的方式合入 OpenMetadata 的连接器代码库。【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
