SCS 交付与运维
版本：v1.0（草案） 状态：草案 权威性：是
目的
本文档定义 SCS 应如何被验证、部署、配置与运行，才能在生产环境中保持修订后的 SCP 语义。
本文档中的协议术语以 SCP 协议概览 与 SCP 核心规范 为准。
它回答：
- 如何验证系统实现的协议一致性
- 如何安全部署运行时模块
- 如何配置版本、存储与下游集成
- 如何在事故、发布与迁移中不破坏协议含义
一致性与测试
实现验证应至少覆盖：
- 模块行为的单元测试与组件测试
- 从 task admission 到 settlement 的端到端生命周期测试
- execution、verification 与 settlement reconstruction 的 replay 测试
- semantic version 与 domain evolution 测试
- epoch window 与 aggregation 行为测试
- reward 可重现性与下游 payout reconciliation 测试
目标不仅是系统正确，更是要在生产条件下保持修订后的 SCP 契约。
部署要求
部署规划应覆盖：
- 在隐私、signer authority 或运行时隔离有要求时，对模块进行分离部署
- coordination、semantic、verification 与 settlement 服务的可用性
- 在需要时提供受保护的 Vault 或 TEE 边界
- 以独立实现配置的方式接入下游 payout 或 treasury 集成
- 对 task、semantic、epoch、verification、settlement、reward 与 payout 路径建立观测能力
SCS 不要求一种固定拓扑，但任何部署拓扑都必须保持相同的协议行为。
配置域
配置应定义：
- identity、endpoint 与 authorization 设置
- mTLS 或 service authentication 设置
- queue、timeout、retry 与 workflow orchestration 设置
- storage、retention 与 audit log 设置
schema_version、semantic_version与policy_version的 rollout 控制- epoch window 与 aggregation 控制
- 在需要时的下游 chain、treasury、signer 或 payout 配置
运维与 Runbook
实现应维护以下 runbook：
- semantic resolution failure 或 registry mismatch
- verification backlog 或 evidence ingestion surge
- settlement finalization failure
- candidate aggregation 或 promotion workflow backlog
- reward finalization failure
- downstream payout submission failure
- payout reconciliation mismatch
runbook 必须始终保持以下区分：
- 哪些内容已经成为 finalized protocol truth
- 哪些只是下游运维工作仍然待处理或失败
发布与迁移
版本化 rollout 必须考虑：
schema_versionsemantic_versionpolicy_version- epoch window 配置变化
- semantic registry 或 compatibility 规则变化
- 下游 integration profile 变化
任何运维变更都不能静默破坏 SCP 定义的 replay、语义解释、settlement finality 或 accounting history。
运维安全规则
从实现角度看，SCS 至少应保持以下安全属性：
- 任何部署变更都不能导致隐式的语义重解释
- 任何迁移都不能原地修改 finalized accounting history
- 任何下游 payout retry 都不能改写 finalized reward state
- 任何事故处理都不能绕过 verification 或 settlement 语义
- 任何观测或恢复流程都不能将明文泄露到授权边界之外
与 SCP 的关系
本文档只描述运维与交付层的实现方式。
关于 replay、语义演化、epoch 行为、settlement truth 与 economics 约束的规范含义，请参见：