yuqei/ai-contract-platform
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
ddd60875a3f8a58be204cfbce9c3caa1feccd56a
ai-contract-platform/project-docs/V2-P1-07.1-pilot-operations-automation-2026-08-25.md
T
yuqei 1d85329a6a
Build and Test Quality Gate / Contract Web typecheck and build (pull_request) Successful in 9m12s
Details
Build and Test Quality Gate / Isolated Alibaba and Tencent KMS gateway (pull_request) Failing after 4m53s
Details
Build and Test Quality Gate / Python tests and Contract API migration (pull_request) Failing after 24m55s
Details
Security Quality Gate / npm audit, Bandit, pip-audit, detect-secrets (pull_request) Failing after 8m42s
Details
feat: deliver governed contract platform and async AI tasks
2026-08-26 12:53:47 +08:00

6.2 KiB
Raw Blame History

V2 P1-07.1 试点运营自动化、SLA 与可靠决策实施说明

实施日期：2026-08-25
状态：已实现，进入发布门禁与隔离 UAT
适用角色：平台超级管理员、试点运营、产品经理、法务运营、SRE

1. 交付结论

P1-07.1 将原先依赖人工刷新的试点后台升级为可持续值守的运营控制面：异常发现由带租约的定时任务执行；首次响应截止时间按平台工作日历计算；超时事件复用经过握手验证的邮件/Webhook 通知适配器；队列采用稳定游标分页并支持最多 100 条批量分派；“可靠合同决策”不再使用审批状态或审查完成数作为代理，而只统计完整证据链形成后的不可变事件。

这次变更保持旁路治理原则：扫描、SLA 和通知不会静默修改合同、审查任务、电子签署或归档源状态。

2. 产品口径

2.1 平台 SLA

  • 默认时区：Asia/Shanghai；
  • 默认工作时间：周一至周五 09:00–18:00；
  • 默认首次响应目标：30 个工作分钟；
  • 支持配置工作日、工作时间、节假日、扫描周期和回看周期；
  • 策略变更会递增版本，并重算所有活跃、尚未首次响应工单的截止时间；
  • 每个工单记录 due_policy_version 和 due_policy_source，历史报表可以解释截止时间来源。

工作日历关闭时回退为自然分钟，页面会显示对应口径，不能把两种口径混为一组 SLA 报告。

2.2 严格“可靠合同决策”

只有同时满足以下四个条件，才写入 reliable_contract_decisions 并计入后台指标：

  1. 存在明确的合同版本；
  2. 存在已完成审查任务；
  3. 当前审查风险集合与确认时完全一致：已应用修复的风险自动计入处置，其余风险必须逐项显式确认；无风险结果也必须显式确认“未发现重大风险”；
  4. 风险确认之后，出现审批通过、合同下载或归档证据。

证据事件包含合同版本、审查任务、风险确认、下游动作和 SHA-256 摘要。后续审查风险集合变化时，旧确认不会被用于新的决策。单纯“审查完成”“合同已审批”或“合同已签署”均不再单独计数。

当前严格口径最初只覆盖已有合同的审查决策旅程。P1-07.2 已增加与合同版本及正文哈希绑定的 draft_generated 证据和四项人工核对；新增口径见《V2 P1-07.2 值班路由、SLO 与版本级起草证据实施说明》。

3. 系统设计

Playbook Governance Worker
  -> 领取平台扫描租约
  -> 扫描失败任务、签署异常、人工复核
  -> 幂等刷新运营工单
  -> 对账风险确认与后续动作，写入可靠决策证据
  -> 查找工作日历 SLA 超时且未响应工单
  -> 写入站内通知和外部投递队列
  -> 既有通知 worker 投递、重试和死信

调度复用 playbook_governance_worker，避免新建第二套轮询、租约、通知重试和死信基础设施。强制手工扫描也经过同一租约和扫描运行证据表，不绕过审计。

3.1 新增数据

  • pilot_operation_policies：平台工作日历、扫描和外部升级策略；
  • pilot_operation_scan_runs：每次调度的领取者、状态、发现/创建/关闭/决策/升级计数；
  • contract_risk_disposition_confirmations：绑定审查风险集合哈希和合同版本的显式确认；
  • reliable_contract_decisions：不可变的最终决策证据；
  • pilot_operation_cases 新增策略版本、截止时间来源和升级投递标识。

3.2 接口

  • GET|PUT /api/v1/admin/pilot-operations/policy
  • GET /api/v1/admin/pilot-operations/scan-runs
  • POST /api/v1/admin/pilot-operations/run-scheduled-scan
  • POST /api/v1/admin/pilot-operations/cases/bulk-assign
  • GET /api/v1/admin/pilot-operations/dashboard?case_cursor=...
  • GET /api/v1/contracts/{contract_id}/reliable-decision/evidence
  • POST /api/v1/contracts/{contract_id}/reliable-decision/risk-confirmations

管理接口仍逐请求校验 platform_admin。合同证据接口分别校验合同查看和编辑权限，并强制租户隔离。

4. 外部升级通知

外部升级复用企业 Playbook 通知通道。只有同时满足以下条件的邮件或 Webhook 通道才会出现在策略选择器中：

  • 通道已启用；
  • 握手测试通过；
  • 订阅事件 pilot_operation_sla_escalated；
  • Webhook 密钥状态满足既有轮换规则。

投递载荷只包含工单标识、租户标识、队列/严重级别、截止时间和后台链接；不包含合同正文、签署账号、临时链接、供应商原始响应或密钥。每条工单只会入队一次，失败由既有投递重试和死信机制处理。

5. 游标与批量运营

  • 工单排序固定为“来源仍活跃优先、截止时间升序、工单 ID 升序”；
  • 游标编码排序键，不接受客户端页码推算；
  • 单页最多 100 条，默认 50 条；
  • 筛选条件变化时必须丢弃旧游标；
  • 批量分派最多 100 条，逐条返回成功与跳过原因，避免一条过期工单回滚整批；
  • 每条成功分派均写入独立工单事件并记录首次响应。

6. 观测与发布门禁

  • 数据库迁移达到 20260825_0066；
  • OpenAPI 必须包含 137 个路径、213 个 schema 且无悬空 $ref；
  • pilot_operation_scan_runs 可查询最近运行、失败码和处理计数；
  • 两个 worker 并发时同一周期只有一个领取扫描租约；
  • 普通租户管理员访问管理 API 返回 403；
  • 同一超时工单不会重复创建外部升级投递；
  • 严格指标测试必须证明：确认前下游动作不计数，确认后新动作并经对账才计数；
  • Contract API 全量测试、Web 测试、类型检查、生产构建与 Chrome UAT 通过。

7. 非目标和后续建议

  1. 平台日历是平台运营级策略，不是每个租户的合同履约日历；两者不得复用同一数据行。
  2. 当前没有面向客户承诺的 7×24 服务等级合同，页面指标用于试点治理而非自动形成赔付依据。
  3. 大规模导出、跨页全选和按班组轮班自动分派不在本阶段范围。
  4. P1-07.2 已实现：值班表/轮班路由、扫描与通知 SLO 看板、严格决策漏斗归因以及版本级起草证据。
Reference in New Issue View Git Blame Copy Permalink