didi/dmap/sdk-integration

SDK 集成闭环

把 pod-maker 视为制作规则的单一来源，完成“识别 SDK → 制作 Pod → 下载 Framework → :path 接入 → 构建验证”的闭环。本 Skill 的完成态是本地私有 Pod 已接入当前工程；Git、Tag 与私有 Specs 发布属于用户另行指定的交付动作。

1. 锁定工程、工具和输入

1. 以包含目标 Podfile 和 .xcodeproj 或 .xcworkspace 的目录作为宿主工程根；若存在多个候选，依据用户指定的工程或 Target 选择。选择会改变接入目标时，先向用户确认。
2. 使用 rg --files 定位 pod-maker/makePod.sh。要求同目录同时存在 init.sh、README.md 和 templates/downloadSDK.sh.template。
3. 完整读取该 pod-maker 的 README.md、快速接入指南、makePod.sh 与下载脚本模板，以当前文件行为为准。
4. 读取宿主 Podfile、Podfile.lock、工程 Target、最低 iOS 版本和 git status --short；保留所有无关改动。
5. 从现有 pod-maker.json、SDK 交付文件和工程声明中建立 SDK 清单。每项必须解析出 podName、Framework 基础名称、稳定的 HTTPS zip 地址和最低 iOS 版本。下载地址、目标 Target 或 SDK 对应关系无法从工程中确定时，返回 needs_input 并只询问缺失值。

完成标准：宿主根、唯一 Pod Maker、目标 Target、配置路径和每个 SDK 的四项必需值均已确定，且待修改文件与用户已有改动已列清。

2. 生成并校验制作配置

1. 优先维护 Pod Maker 旁已有的批量 JSON；没有配置时运行 init.sh <config-path> 生成模板，再替换全部占位值。
2. 多个 SDK 参数一致时使用 defaults；仅把真实差异留在各 pods[] 中。将 outputDirectory 设为宿主工程内稳定、可用相对路径表达的位置。
3. 使用系统 Ruby 解析 JSON，并逐项检查：Pod 名称唯一、Framework 名称与 zip 内名称对应、URL 使用 HTTPS、最低版本兼容宿主工程、五个 podLibCreateAnswers 与当前 CocoaPods 提问顺序一致。
4. 检查输出目录中的同名 Pod。新配置会覆盖已有目录时，先展示影响并取得明确授权；获得授权后才在 makePod.sh 的覆盖提示中输入 y。

完成标准：JSON 可解析、没有 PodName* 或 example.com 占位值、SDK 清单逐项对应配置，且所有覆盖动作均已获得授权。

3. 制作并准备每个私有 Pod

1. 确认 pod --version、/usr/bin/ruby --version、curl --version 和 unzip -v 可运行。
2. 从 Pod Maker 目录执行 ./makePod.sh <config-path>，记录成功、失败和跳过清单。失败项必须修复或返回 needs_input；只有与当前配置一致的既有 Pod 才可接受为跳过项。
3. 对每个 Pod 验证 <PodName>.podspec、pod-config.json、downloadSDK.sh 和 .gitignore；确认 podspec 的 prepare_command、vendored_frameworks、公开头文件、资源路径及最低 iOS 版本都指向同一个 Framework。
4. 因为本流程使用 :path，在每个 Pod 根目录执行 bash downloadSDK.sh。确认 Framework/<FrameworkName>.framework/Info.plist、主二进制和 Headers 存在；SDK 声明包含 bundle 时同时确认资源存在。
5. 让生成 Pod 的 Framework/ 保持在 .gitignore 中；提交状态只包含配置、Pod 包装文件和宿主接入改动。

完成标准：制作汇总没有失败项；每个 SDK 都有结构完整的私有 Pod 和已下载、名称规范化的 Framework。

4. 以本地私有 Pod 接入宿主

1. 在正确 Target 中为每个 SDK 添加或更新一条声明：

``ruby pod 'PodName', :path => 'relative/path/to/generated/PodName' ``

:path 指向包含 podspec 的 Pod 根目录，并相对 Podfile 解析。沿用该 Target 已有的 inhibit_warnings、modular_headers 等约定，不凭空增加编译选项。

1. 同名声明已存在时原位更新路径和选项；每个 Target 只保留一条有效声明。保留已有 source、post_install 和无关依赖。
2. SDK 之间存在显式依赖时，以 SDK 文档、现有 podspec 或链接错误证据为依据补充依赖；所有被当前二进制引用的私有 Pod 必须出现在解析结果中。
3. 在宿主根执行 pod install。检查 Podfile.lock 中每个私有 Pod 的 EXTERNAL SOURCES 均解析到预期本地目录，并确认生成的 workspace 包含 Pods 工程。

完成标准：Podfile 中声明唯一且路径有效，pod install 成功，锁文件解析到本次生成的全部私有 Pod。

5. 验证真实 Target

1. 使用 xcodebuild -list 从生成的 workspace 读取 scheme；选择与目标应用 Target 对应的共享 scheme。
2. 至少执行一次禁用签名的 Debug 构建。优先使用 SDK 支持的模拟器目标；只有 SDK 不包含模拟器架构时改用 generic iOS device，并明确记录该限制。
3. 检查构建日志不存在缺失头文件、未定义符号、Framework 路径或 bundle 资源错误。工程已有 SDK 调用入口时，同时验证对应源码仍能编译。
4. 复查 git diff 和 git status --short，确认没有改写用户无关文件，也没有把下载的 Framework 加入版本控制。

完成标准：真实应用 Target 构建成功，或返回包含失败命令、首个根因和所需输入的 needs_input。pod install 成功不能替代 Target 构建成功。

6. 交付结果

报告：宿主 Target、Pod Maker 路径、配置路径、生成的 Pod/Framework 清单、Podfile 接入位置、pod install 与构建结果、保留的用户改动。仅在上述五个完成标准全部满足时使用状态 integrated；其余使用 needs_input，不得把“已生成 Pod”表述为“已完成接入”。