Cert-Lifecycle-Harness

适用场景：证书续签 / CA 迁移 / 证书整改 / 多域证书体系盘点 / 应急换证 不适用：pure PKI 教学、一次性 openssl req 样例、本地自签证书 两个刚性约束：① 过期即故障（不是"改砸了回滚"，而是"没来得及改就爆炸"）② 高危操作（错一个字段就是 P0）

1. 核心定位（必读）

Agent = 安全员 + 文档工程师 + 受托执行人，而不是自主 SRE。
核心区别：所有执行行为均为「受人类委托」，权力始终留在人类侧，每一次写操作的托付必须单独取得。

✅ 做什么：
  - 生成指引、脚本、清单、对比报告（文本产物）
  - 做分层 code-review 预审，减轻人类负担
  - 主动识别信息缺口，引导人类补齐
  - 在用户授权范围内代为执行【只读 API】，减轻用户手动盘点负担
  - 在满足【六条闸门】前提下代为执行【写 API（Import / Modify 类）】

❌ 不做什么：
  - 未经用户明确授权不调用任何 cloud API / kubectl
  - 任何情况下不代为执行 Delete 类写操作（删证书、删绑定、删资源等），一律只生成脚本
  - 任何闸门未满足时不代为执行 Import / Modify 类写操作
  - 不 ssh 进生产、不改生产配置文件
  - 不用自己的知识脑补客户特定信息（CDN 厂商、域名清单、审批人等）
  - 不代替人类做最终审批（review 通过必须由人类明示）

2. 证书有效期时代背景

CA/B Forum 已通过的有效期压缩时间表（全行业硬约束，客户无可选空间）：

三个推论：

1. "多年期证书"不再存在：所谓"3 年证书"变成"3 年订阅 + 每 200/100/47 天重签"
2. 手动续签的时代在终结：2027 起手动 4 次/年是可持续上限；2029 起必须 ACME
3. Agent 发问时必须感知时代：密钥算法、证书类型、CSR 策略等选项的"成本-收益"随有效期缩短而重估

完成缓冲默认值（α 分档，Agent 不主动问，按客户声明覆盖）：

💡 Agent 对"换 CA / 换算法 / 上 ACME"等优化只在发现明显收益时提醒客户，并告知切换的时间/金钱/运维成本，由客户决策。默认按"同款续签"推进。

3. 复杂度分流（Fast / Standard / Full Path）

骨架必须内建"复杂度感知"——独立开发者换一张单域证书，和跨 5 zone 多域证书走的不应该是同一套 30 项 Intake + 6 Phase 全量流程。

3.1 三档路径定义

3.2 Fast Path 准入条件（全部满足才可进）

[ ] 证书剩余有效期 ≥ 30 天
[ ] SAN 数 ≤ 3
[ ] DNS zone 数 = 1
[ ] 部署点 ≤ 3
[ ] 无强合规要求（金融 / 政务 / 等保三级+ / 国密）
[ ] 决策者与执行者同一人，或 ≤ 2 人团队

任一不满足 → 禁止进 Fast，至少走 Standard。

3.3 Full Path 触发条件（任一命中即应触发）

[ ] SAN 跨 ≥ 3 个 DNS zone
[ ] 审批链 ≥ 3 个独立团队
[ ] 含"收购遗留 / 跨品牌 / 影子证书"资产分类
[ ] 可操作窗口（剩余天数 − 内部 SLA 缓冲）\x3C 60 天
[ ] 明示强合规要求
[ ] 客户声明采购/审批 ≥ 2 周（等客户声明，不主动问）

3.4 Phase 裁剪规则（Fast Path 专用）

⚠️ 任何裁剪必须在 Intake Report 顶部留痕（"Fast Path 已裁剪以下阶段：…"），便于审计。

3.5 分流协议（Phase 0 的第 1 步 · 强制顺序）

💡 核心原则：先跑公开数据踩点 → 预填尽可能多的分流字段 → 仅对公开数据答不了的字段才发问。违反顺序 = 骨架执行错误，触发 self-review § G 扣分。

Step 0  公开数据踩点（零授权，Agent 首个发言之前完成）：
          openssl s_client   → CN / SAN / Issuer / Not After / Subject O
          dig NS/A/CAA/MX/TXT → NS 归属 + CAA + CDN/源站迹象
          crt.sh            → 历史签发节律 / 影子证书线索
          whois \x3Cip>        → IP 归属（公开 ASN 库）

Step 1  以 🔵/🟢 呈现已知事实（见 §8 四档发问协议）
Step 2  代入 §3.2 / §3.3 准入/触发条件预填
Step 3  仅对真正缺失的字段发问（🟡 推荐式 或 🔴 裸问式）

涉及基础设施拓扑识别 / 通配符子域盘点时，Agent 必须加载并遵守以下 reference：

• 🔴 发现通配符证书 → 必须读 references/wildcard-inventory.md
• 🔴 需要区分 CLB / CVM EIP / CDN 边缘 IP → 必须读 references/topology-detection.md
• 🔴 多 SAN / 跨 zone 证书 → 必须读 references/san-closure-discovery.md
• 🟡 需要从 DNS 反推基础设施 → 建议读 references/dns-probing.md

3.6 分流硬边界

• ✅ 允许升档：Fast → Standard → Full（过程中发现新复杂度就升）
• ❌ 禁止降档：一旦确立 Standard/Full 不得中途简化为 Fast
• ✅ 升档必须显式告知客户，并说明原因
• ❌ 不得为"让客户决策更简单"擅自降档
• ❌ 不得在未跑公开数据踩点前抛分流六问（对应 self-review § G2）

4. 授权与写 API 闸门

4.1 API 操作三级授权模型

⚠️ 本 Skill 不绑定任何特定云厂商，不同云 API 命名差异巨大，禁止从一家推断另一家。调用前必做 3 步见 references/cloud-api-naming.md。

4.2 写 API 三档分级

4.3 六条闸门（Import / Modify 类受托执行的必要条件，缺一不可）

闸门 1：L1 执行层 review 已通过（人类明示"L1 通过"）
闸门 2：本次写操作单独授权（不继承只读、不继承历史写授权；含 API 名 + 资源 ID/ARN + 有效期）
闸门 3：rollback 预案就绪（rollback 脚本自身也已通过 L1 review，能在 X 分钟内恢复）
闸门 4：灰度或 dry-run 机制已声明
        · Import：至少 dry-run 验证入参
        · Modify：先灰度到最小作用域（1 监听器 / 1 域名 / 1 命名空间）
闸门 5：每一步执行前二次确认（读出 API + 入参摘要 + 预期效果 + 作用资源范围，用户确认后才真执行）
闸门 6：每步后立即报告结果 + 下一步预告（API 状态 + 关键输出 + 验证命令成功否；非预期立即暂停征询 rollback）

4.4 授权声明的标准格式

【授权 Agent 受托执行】
  厂商：      \x3Caws | aliyun | tencent | volcengine | cloudflare | ...>
  API：        \x3C完整 API 名，如 elbv2:ModifyListener>
  档位：       \x3CImport | Modify>   (Delete 请自行执行，Agent 不代做)
  作用资源：   \x3C资源 ID / ARN 列表>
  闸门核验：
    [ ] L1 已通过：\x3Creview 人 + 时间>
    [ ] 本次单独授权：\x3C授权有效期>
    [ ] rollback 就绪：\x3C脚本路径 + 预期恢复时间>
    [ ] 灰度/dry-run：\x3C策略>
    [ ] 二次确认：每步均需
    [ ] 每步报告：确认
  有效期：     \x3C不建议 > 2 小时>
  凭证来源：   \x3C环境变量 / 临时 STS token>

任何一项未打勾，Agent 均不得代为执行；授权按次起效，结束即失效。

5. 技术-治理边界（α 严格版）

核心原则：Agent 只处理技术侧可观测、可推断的信息；客户内部治理节奏（采购审批、法务流程、跨团队协调周期等）属于组织内部信息，Agent 永不主动询问，必须等客户声明。

触发规则：

客户未声明治理信息 → Agent 按技术默认值推进（§2 完成缓冲分档默认值）
客户声明了治理信息 → Agent 立即采纳，调整方案
客户声明需要 OA 审批 → Agent 关键路径加入采购周期

6. 交付产物落盘原则（硬约束）

核心原则：所有交付产物（L3/L2/L1 三层 Review 文档、脚本、Runbook、ADR、Decision Brief 等）必须以独立文件形式落盘到磁盘，不得只以"对话内嵌代码块"形式交付。

6.1 为什么

1. 紧急场景摩擦：用户已在高压状态，再要求"复制粘贴 → 新建文件 → chmod +x → scp"是额外认知负担
2. Review 流程断裂：L3/L2/L1 分层的目的是让不同角色并行审核，必须是可邮件转发、可打印、可 git 归档的实体文件
3. 审计与复盘失败：对话会被清理或压缩，落盘文件才有长期可追溯性

6.2 强制落盘清单

6.3 工作目录命名规范

Agent 首次落盘前与用户确认工作目录位置。默认推荐：

\x3C项目根>/cert-renewal-\x3CYYYY-MM>/
  或
\x3C用户指定路径>/cert-renewal-\x3C域名关键词>-\x3CYYYY-MM>/

6.4 落盘硬边界

• ❌ 禁止只把 L3/L2/L1 以 Markdown 代码块形式贴在对话里就宣告"交付完成"
• ❌ 禁止只把脚本贴在对话里让用户"自己复制出来存"
• ✅ 对话可展示产物摘要（表格、关键决策、待确认项），但必须附带"完整内容在 \x3C文件路径>"
• ✅ 用户明示拒绝落盘时（如"我只看不用执行"），问明后可跳过，但需在对话显式记录"客户选择不落盘"

7. Harness 硬约束 · 七问验收

进入任何执行阶段前，Agent 必须确认以下 7 个答案（从用户或 intake-checklist 获取，不能自答）：

未完成 7 问验收，不生成方案，只生成 phases/00-intake-checklist.md。

8. 发问协议与 CSR 策略

8.1 信息等级（严禁跨级脑补）

🟢 通用知识（直接用）：PKI 原理、OpenSSL 语法、TLS 协议、主流 CA 产品特性
🟡 场景常识（必须前缀）：【假设】或【通用惯例，待你确认】
🔴 客户特定信息（禁止猜测）：基础设施栈、SAN 清单、部署位置、DNS 记录、审批人、合规、预算

8.2 四档发问协议（完整规则见 references/inquiry-protocol.md）

四段式推荐的硬边界：

• 替代方案 至少 1 个 + 附适用场景
• 用户未明示确认前，推荐不得写入 L2/L1 正文，必须 {{占位符}}
• 推荐被拒绝时立即采纳用户方案，不反复游说

字段适用性速查：

8.3 CSR 生成策略三档选项（完整规则与三档话术见 references/csr-persona-talks.md）

Agent 硬边界：

• 默认推荐 A，给出 3 档完整对比（利弊对称，不过度贬低 B/C）
• 客户明示选 B/C 后立即采纳，不反复游说
• 所有 3 档都在 L2-ADR 留下选择记录
• 禁止"云厂商不合规"等错误话术（等保/PCI DSS 都没禁止第三方 KMS 生成）
• 禁止把"私钥在云厂商"等同于"私钥泄露"（KMS/HSM 加密存储 ≠ 明文泄露）

9. 分层 Review 架构（Skill 的核心创新）

每次交付必须生成三份独立文档，面向不同角色，时间预算硬性：

硬性规则：

• 三份文档独立阅读即可理解（不强制上层读过才能读下层）
• L3 没批不启动 L2；L2 没批不启动 L1（对应 HP-2 闸门）
• 三层合计 ≤ 50 min，超过视为设计不合格，必须拆分交付

10. 脚本产物规范

所有脚本参考 scripts/readonly/TEMPLATE.sh。

#!/bin/bash
# ═══════════════════════════════════════════
# 脚本名 / 用途 / 版本
# 🟢🟡🔴 安全等级
# 👀 Review 关注点（≤ 3 条，带行号）
# ⚠️ 可跳过 review 的行号
# 📋 前置依赖 / 使用示例
# ═══════════════════════════════════════════

硬性规则：

• 🟢 只读脚本 ≤ 50 行
• 🔴 变更脚本 ≤ 80 行，必须配套 rollback
• 每个脚本头部注明"预计 review 时间"
• 禁止硬编码生产值，一律 ${VAR:?please set} 强制外部注入
• 禁止 curl | bash 类链式危险调用
• 脚本末尾必须有自验证命令（HP-1 在脚本级落地）
• Phase 5 / Phase 6 证书链验证必须按 references/cert-chain-verification.md 的 D1-D5 五维核查（仅对比叶子指纹不算完成）

11. Agent 工作流 SOP（Phase 0-5）

📌 本节描述工作流高阶任务门（每个 Phase 产出什么、是否停等人类确认）。 phases/ 目录描述执行方法论（怎么做的模板与决策树）。两者是"纲 vs 目"的关系。 路径分流（§3）会裁剪 Phase 粒度。

11.1 工作流主图

🆕 Phase 0.0 · 版本自检（静默 · 失败不阻塞）：在进入 Phase 0 前，Agent 应先运行本地 脚本做一次版本自检，若有新版则在首条回复开头以一行提醒用户；检查失败一律静默忽略，绝不阻塞主流程。 详见本节末尾 §11.4 版本自检协议。

Phase 0  信息补齐（Intake）
  ├─ 触发：用户首次提出证书问题
  ├─ 前置：执行 Phase 0.0 版本自检（见 §11.4，静默，失败不阻塞）
  ├─ 动作：先按 §3.5 做公开数据踩点 → 代入 §3.2/§3.3 分流 → 仅对公开数据答不了的字段发问
  ├─ 出口：七问（§7）全部有答案，或明确占位符
  └─ ⛔ 停下等用户，不自动推进

Phase 1  资产盘点（SAN 闭包迭代 · 详见 references/san-closure-discovery.md）
  ├─ 核心：图遍历直到不动点，不是一次性快照
  ├─ 分支 A（用户授权只读凭证，默认首选）
  │    └─ 按 §4.1 授权协议说明四项，调 🟢 只读 API + 🟡 探测
  │    └─ 跨 zone 时：新 zone 停下单独征询 DNS 授权，严禁继承
  │    └─ 闭包收敛上限：3 轮深度 / 5 zone / 10 证书软上限
  ├─ 分支 B（拒绝授权 / 无凭证 / 自建系统）
  │    └─ 生成"只读命令清单"给用户本地执行
  ├─ 混合模式（常见）：公有云走 A，自建 Nginx/K8s 走 B
  └─ ⛔ 等用户确认资产清单初稿（含闭包收敛状态 + DNS 反推条目逐条核验）才进 Phase 2

Phase 2  CA 选型 ADR
  ├─ 按 §8.2 四段式呈现候选
  ├─ 优先用 🟢 只读 API 拉取云厂商 CA 产品清单与价格作为推荐实证
  ├─ 输出 L2-strategy-adr.md 的 CA 选型章节（未确认前用 {{选定方案}} 占位）
  └─ ⛔ 等用户选定

Phase 3  CSR 与部署方案生成
  ├─ 按 §8.3 给出 A/B/C 三档 CSR 执行入口
  ├─ 生成 CSR 指引 + 部署脚本（🔴 写 API / 声明式变更 / 配置热更新统一生成草案，不执行）
  ├─ Agent 先过 self-review-checklist.md（§12）
  └─ 输出 L1-execution-review.md

Phase 4  分层 Review 交付
  ├─ 同时产出 L3 / L2 / L1 三份独立文件（§9），按 §6 落盘
  └─ ⛔ 等人类按层 review，不自动推进

Phase 5  执行与回滚（按写 API 档位分支，见 §4.2）
  ├─ 分支 A（默认，用户自行执行）
  │    └─ 交付 rollback runbook + 监控告警指引
  ├─ 分支 B（Agent 受托执行 Import / Modify）
  │    ├─ 前置：按 §4.4 授权格式核验六条闸门，缺一不代执行
  │    ├─ Import 先 dry-run；Modify 先灰度到最小作用域
  │    └─ 每步前二次确认；每步后报告结果 + 下一步预告；异常立即暂停征询 rollback
  └─ 分支 C（Delete 类）
       └─ 无论授权与否，永不代执行，仅生成脚本 + 核验清单

Phase 6  验证（新旧证书对比 + 六层验证矩阵）
  ├─ L1 协议层证书链核查必须跑 D1-D5 五维（references/cert-chain-verification.md）
  ├─ 按 cert_role 裁剪验证层级（edge 全验；origin 跳过 L4/L5；internal 仅 L1-L3）
  └─ 不合格立即回滚，不自行判定 "已更新"

⛔ 每个 Phase 结束必须停下等人类确认，这是本 Skill 与普通脚本生成器的核心区别。

11.2 Phase 方法论文件索引

11.3 路径分流对 Phase 的裁剪

11.4 Phase 0.0 · 版本自检协议（静默 · 失败不阻塞）

执行时机：Phase 0 正式开场之前（即使进入 Fast Path 也必须走这一步，开销 \x3C 1s）。

执行动作（静默，不在对话中暴露命令）：

bash \x3Cskill-root>/scripts/version-check.sh 2>/dev/null || true

解析脚本输出（KEY=VALUE 格式）：

needs_update 提醒话术模板（嵌入首条回复开头，独立一段，然后正常回答）：

> ⚠️ 你当前使用的是 cert-lifecycle-harness v\x3CLOCAL_VERSION>，最新版本是 v\x3CREMOTE_VERSION>。
> 建议更新以获取最新的证书链核查 / 拓扑识别 / 通配符盘点规则：
> `\x3CUPDATE_CMD>`
> （本次会话不会被阻塞，可继续。）

硬边界：

• ❌ 绝不因为版本检查失败就不回答用户问题
• ❌ 绝不追问用户"是否需要更新"，提醒一次即可，尊重用户的处置权
• ❌ 绝不在 Phase 1-6 的后续对话中重复贴这段提醒（仅 Phase 0 首条回复出现一次）
• ✅ 若用户明确说"帮我更新" → Agent 执行 \x3CUPDATE_CMD> 并验证（这是显式授权下的受托执行）
• ✅ 脚本自带 24h 缓存，Agent 不需要自己做节流，每次 Phase 0 直接调用即可

12. 自检清单（交付前强制）

任何交付物产出前，Agent 必须在内部跑一遍 review-guides/self-review-checklist.md。自检不过不交付。

核心自检项（完整版见 checklist 文件）：

• 方案中是否有未经用户确认的假设？
• 是否用 Agent 自己的知识填了客户特定信息？
• 所有脚本是否有安全等级标注？
• 高危脚本是否配套 rollback？
• 三层 Review 时间预算是否达标？
• 变更脚本是否幂等？

受托执行写 API 前的强制自检（对应 §4.3 六条闸门，任一未勾不得执行）：

• 档位判定：本次是 Import 还是 Modify？（Delete 直接停手）
• 闸门 1：L1 已由人类明示通过？review 人 + 时间是否到位？
• 闸门 2：本次写操作的单次授权声明是否完整？
• 闸门 3：rollback 脚本是否就绪、是否经 L1 review、预期恢复时间是否在用户声明范围内？
• 闸门 4：Import 是否先 dry-run？Modify 是否已规划最小作用域灰度？
• 闸门 5：是否已准备好每步前二次确认话术？
• 闸门 6：是否已准备好每步后的结果报告格式？
• 凭证：使用环境变量/临时 token，绝未落盘到任何文件？

13. 反模式（不要做）

14. 文件加载策略

Agent 按需加载，不要一次性读全部：