修改自托管的证书自动化 Monorepo，同时不泄露机密信息

## 了解证书从申请到部署的流程，以及系统保存的机密信息 将该系统视为一个私有化部署的产品，用于管理证书申请、续期、部署、监控、通知和 API 集成。其核心 pipeline 可能通过 ACME 申请证书，完成 DNS-01、HTTP-01、CNAME proxy 或 provider 特有的 validation，导出 PEM、PFX、DER、JKS、P7B 等格式，并部署到 server、proxy、cluster、CDN、cloud service 或 control panel。 该系统会保存证书、cloud 凭据、SSH 信息、API key 和其他敏感配置。绝不要在 source 更改、log、fixture、screenshot、report 或生成的 metadata 中暴露本地数据或 secret。 ## 分开处理 Monorepo 的各个 Workspace，不碰运行时数据 使用 repository 指定的 package manager、workspace 定义和 lockfile；不要引入其他 package manager 的 lockfile。如果某个 package 是独立的 version-control workspace，应从该 workspace 内部检查其 status 和 diff，并使其中的更改与 root repository 的更改保持分离。 除非 task 明确以其为目标，否则不要修改或 commit runtime data、log、临时 output、生成的 metadata、distribution 或已导出的 plugin manifest。需要理解动态安装的 SDK 时，可以只读检查 runtime dependency directory；但该目录并非 source，不得进入变更集。 ## 把每项改动放进负责该行为的包或插件 编辑前先确定归属：protocol client 负责 account、order 和 challenge 行为；pipeline package 负责执行 model 与 task lifecycle；server module 负责 entity、service、controller、permission 和 migration；client module 负责 view、form、route 和 API adapter；provider plugin 负责 provider 特有的 DNS、deployment 和通知行为。 单一 provider 的缺陷应留在该 provider 的 plugin 中。只有当某项行为表达了各 provider 都必须一致采用的可复用语义时，才将其上移到 pipeline core 或 shared plugin library。优先沿用成熟的 module、service、component 和 plugin pattern，不要创建平行实现。 ## 使用各个包自己的命令，不擅自安装依赖项 运行 validation 前先阅读已记录的 command。使用受影响 package 自身的 unit test、lint、format 和 build command；只有当更改明显跨越 package 边界时，才扩展到更广泛的检查。不要用已知失效的 type check 或占位 test script 代替受支持的文件级 validation。 不要主动安装 dependency。如果 dependency 缺失、terminal 要求或 network access 阻止了必要检查，应停止该次尝试并报告环境限制。对于与版本有关的 SDK 行为，应检查实际安装的 runtime dependency 及其附带 documentation，不要依赖记忆或其他版本。 ## 把处理拆成有名字的步骤，并用说明原因的注释让代码好读 易读性优先于紧凑语法。将复杂条件、嵌套 ternary、长 chain、inline object 和多层 helper call 拆成命名清晰的中间值或职责集中的 method。如果有意义的 local variable 可以揭示处理过程的转换，就不要把一个 method call 直接放进另一个 method 的 argument 中。 当 method 原本需要三个以上 argument 时，改用 object parameter。用 comment 说明 business rule、compatibility 限制、protocol 细节和隐蔽风险背后的原因。小段 logic 应留在使用位置，但当 business rule、field 转换、permission check、repository 选择、transaction 传播或计算的多个副本必须保持同步时，应将其抽取为共享实现。 ## 先写会失败的测试，再用最小改动修复 为主要 business 行为添加聚焦的 unit test。对于新功能或缺陷修复，优先在实现前编写能够复现预期行为且会失败的 test，然后进行最小更改并重新运行 package 级 test。如果后补 test 需要改变既有行为，应在修改前确认该行为属于缺陷，而不是既有需求。 将 pure unit test 放在 source 附近，并确保其不进入 production build。对于 static ESM import，使用合适的 module-mocking tool，不要仅仅为了测试而重构 production code。明确设置 package 的 unit-test environment；只有跨 package 影响使其确有必要时，才运行更广泛的 build。 ## 表结构变更配上 SQL 迁移，并正确传递事务 每项 table 结构更改都必须配套明确的 SQL migration；绝不要依赖 ORM schema synchronization。临时 upload key 在永久保存前必须通过获批的 file service 转换为正式 key，并保留所需 owner 以及公开或私有的可见性。 需要传播 transaction 时，应先传入包含可选 transaction manager 的 context，再传入 request object，并使用 shared repository helper 和 transaction helper。不要向简单 query 或 pure function 添加 transaction context。通过规范的 query helper 构建可选 tenant 或 project predicate，避免 null 或 undefined 变成无效的等值条件。 避免使用会与继承的 base method 冲突的 service method 名称和 signature。选择能够保持 base contract 并明确体现 operation 范围的具体名称。 ## 用现有的 CRUD 框架和表单对话框做管理界面 编辑前先找到负责该功能的 feature view 及其 API module。常规管理、record 搜索和基于 table 的管理应使用获批的 CRUD framework。只有在轻量只读展示、高度交互的 interface，或已有文档说明标准 framework 不适用时，才构建 custom list。 嵌入式 data grid 需要稳定高度，或者一条允许子元素收缩且不间断的 flex chain。对可搜索的 identity field 复用已有的 remote dictionary。简单确认可以使用 confirmation dialog，但任何收集 field、validation input 或提交额外值的 dialog，都必须使用获批的 form-dialog abstraction。 如果已知 repository 的广泛 type check 或 unit command 无效，只对已更改的 client file 运行受支持的 formatter 和 linter。 ## 在正确的层修复证书问题，并保护账户私钥 更改 shared pipeline code 前先检查 provider plugin；当 provider 行为依赖版本时，应检查实际动态安装的 SDK。应用修复前，先判断证书问题属于 ACME client、pipeline 执行、server service、provider plugin、shared certificate utility 还是 client form。 如果 protocol client 支持在不消耗新的 external account binding 材料的情况下取得已有 account URL，应使用现有 account private key 执行仅查询的 account operation。如果 external account binding identifier 发生变化，应生成与该 identifier 绑定的新 account private key；否则必须阻止证书签发，并要求刷新 account key。 不要在 code、log、test、report 或 commit 的 artifact 中包含凭据值。扩展 upload、deployment、通知或 open API flow 时，仍须保持 validation 和 authorization 边界。 ## 让旧配置保持原有行为，并报告实际运行过的检查 添加 plugin parameter 时，应处理已保存的 legacy config 中缺少该值的情况，并保留原有行为，除非 migration 明确改变它。没有已定义的 compatibility branch 时，不要把缺失值重新解释为新 mode。 完成前，检查范围明确的 diff，分别验证 root 和每个嵌套 workspace，运行直接受影响的 test 和文件级 format 或 lint check，并确认所需 migration。确保 runtime data 和生成的 output 仍在变更集之外。 报告更改内容、已通过的检查、无法运行的检查，以及更广泛 validation 被排除在范围之外的原因。