docs(spec): finalize v0.6.0 domains

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

docs/specs/v0.6.0/00-release-scope.md

@@ -85,13 +85,10 @@ v0.6.0 保持三个固定角色：
 3. Playbook 执行可观测性和控制。
 4. Custom Variables。
 5. Worker Health。
-6. Integration Health。
-7. SLA 管理，待详细讨论。
-8. AI 质量评估，待详细讨论。
-9. 抑制规则，待详细讨论。
-10. Operations 页面整合，待详细讨论。
+6. SLA 管理。
+7. AI 质量评估。
 
-SLA、AI 质量评估和抑制规则都是 v0.6.0 正式发布的阻断项，但必须限制为最小可用闭环。
+SLA 和 AI 质量评估是 v0.6.0 正式发布的阻断项。
 
 ## 10. Explicit exclusions
 
@@ -103,6 +100,9 @@ SLA、AI 质量评估和抑制规则都是 v0.6.0 正式发布的阻断项，但
 - 可视化或表单式 Playbook 编排器。
 - Playbook 中途人工审批。
 - 通用 HTTP/Webhook Connector 或统一厂商动作抽象。
+- UI/数据库驱动的 Suppression Rules；抑制逻辑由自定义 Module Python 代码负责。
+- Integration Health 定时探测和统一状态页；保留各 Settings 页手动 Test。
+- Worker/Integration 统一 Operations Center；Worker Health 使用独立实现。
 - 全站 UI 国际化。
 - 旧 CLI/插件兼容层。
 - 自动 Unmerge。

docs/specs/v0.6.0/05-worker-health.md

@@ -1,362 +0,0 @@
-# Worker Health
-
-Status: Confirmed
-
-## 1. Purpose
-
-让 Admin 不依赖 Docker CLI 或日志文件，就能判断后台 Worker 是否存活、正在做什么、是否失败以及业务积压情况。
-
-v0.6.0 最终监控六个逻辑 Worker：
-
-1. Agentic Module。
-2. Case Analysis。
-3. Playbook。
-4. ELK Action。
-5. Dashboard Cache。
-6. Integration Health。
-
-监控粒度是逻辑进程类型，不是每个 Module/Playbook definition，也不是 Docker container ID。
-
-## 2. Architecture
-
-Worker Health 基础设施集成进 `apps.common.worker_runner.run_worker()`。
-
-每个 Worker：
-
-- 启动时获取 Redis singleton lease。
-- 启动 daemon heartbeat thread。
-- 主线程在 iteration 边界更新执行状态与计数。
-- 优雅退出时释放 lease并留下安全退出原因。
-
-Admin API 从 Redis 读取当前状态，并按 Worker 类型附加 backlog diagnostics。
-
-## 3. Redis keys
-
-建议：
-
-```text
-worker-health:v1:{worker_type}:lease
-worker-health:v1:{worker_type}:state
-worker-health:v1:{worker_type}:last-exit
-```
-
-### Lease
-
-- value 至少包含随机 instance_id。
-- TTL 30 秒。
-- heartbeat 每 10 秒 compare-and-refresh，只有 owner instance_id 可续租。
-- 第二个同类型 Worker 发现有效 lease 后拒绝启动。
-- lease 过期后新实例可获取。
-- 不允许 last-writer-wins 覆盖。
-
-### State
-
-state 可与 lease 同一个 JSON key，也可独立；必须保证 owner 才能更新。
-
-建议字段：
-
-| Field | Meaning |
-| --- | --- |
-| worker_type | stable logical identifier |
-| instance_id | random UUID per process |
-| hostname | safe host/container hostname |
-| state | Starting/Idle/Running/Degraded |
-| started_at | process start |
-| heartbeat_at | last heartbeat |
-| iteration_started_at | current/last iteration start |
-| last_iteration_success_at | any successful iteration, including idle |
-| last_processed_at | last iteration that processed work |
-| last_failure_at | last failed/partial-failed iteration |
-| last_duration_ms | last iteration duration |
-| consecutive_failures | reset on successful iteration |
-| iteration_count | process-lifetime count |
-| processed_iteration_count | iterations with processed=true |
-| success_count | successful iterations |
-| failure_count | failed or partial-failed iterations |
-| last_message | safe WorkerIterationResult message |
-| last_error | normalized safe error |
-| log_role | log file role |
-
-PID、完整 command、环境变量和 Secret 不通过 API 暴露。
-
-### Last exit
-
-优雅退出时记录短 TTL 或非租约型安全信息：
-
-- instance_id
-- exited_at
-- reason=`graceful`
-
-意外退出没有 last-exit update，API 通过 lease expired 判定。
-
-## 4. Heartbeat
-
-- daemon thread 每 10 秒刷新 lease。
-- 主线程运行长任务或 sleep 时仍持续刷新。
-- heartbeat Redis 写失败应记录安全日志；如果长期失败 lease 会过期。
-- heartbeat thread 不改变业务 iteration 状态。
-- Running 不设最大时长，也没有 Stalled。
-- 只要 heartbeat 存活，任意长任务保持 Running。
-
-线程退出规则：
-
-- Worker 正常 SIGTERM/KeyboardInterrupt 时停止 heartbeat。
-- 释放仅属于自身 instance_id 的 lease。
-- 不能删除新实例已取得的 lease。
-
-## 5. Singleton startup
-
-Worker 启动：
-
-1. 生成 instance_id。
-2. 原子 SET NX 获取 lease。
-3. 失败则抛 CommandError 并退出，Compose 可记录重启失败。
-4. 成功写 Starting state。
-5. 启动 heartbeat thread。
-6. 进入主循环。
-
-这适用于所有六个正式 Worker。`--once` 是运维命令，不应长期占用 singleton lease；如果它会与正式 Worker 并行影响同一数据，需要显式决定是否短暂获取 lease，默认建议获取以避免并发。
-
-## 6. States
-
-API 状态：
-
-| State | Definition |
-| --- | --- |
-| Starting | live lease exists, first iteration not completed |
-| Idle | live lease, last iteration successful, currently no work |
-| Running | live lease, iteration currently executing |
-| Degraded | live lease, latest iteration has any failure |
-| Down | expected Worker has no live lease |
-
-### Never reported
-
-系统知道六种 expected worker type。没有 lease 且没有 state/last-exit 时：
-
-- state=Down
-- reason=`never_reported`
-- UI 显示 Never reported
-
-### Graceful and expired
-
-- 正常退出：Down / graceful。
-- 意外崩溃或进程被杀：30 秒后 Down / heartbeat_expired。
-- Redis 本身不可用不是 Unknown/Down；整个 Worker Health API 返回 503。
-
-### Degraded recovery
-
-- 一次完整失败立即 Degraded。
-- `WorkerIterationResult.failure_count > 0` 的部分失败也立即 Degraded。
-- consecutive_failures 增加。
-- 下一次无失败的 iteration 清零并恢复 Idle 或完成后的健康状态。
-
-## 7. WorkerIterationResult contract
-
-扩展当前 dataclass：
-
-```python
-@dataclass(frozen=True)
-class WorkerIterationResult:
-    processed: bool = False
-    message: str = ""
-    failure_count: int = 0
-```
-
-语义：
-
-- `processed` 表示至少完成一个业务工作项。
-- `failure_count` 表示 iteration 内被捕获的业务失败数。
-- 抛异常是完整 iteration failure。
-- `message` 必须是安全摘要。
-
-### Time semantics
-
-- 正常 idle polling 更新 `last_iteration_success_at`。
-- 只有 `processed=True` 更新 `last_processed_at`。
-- partial failure 不更新 success timestamp；是否同时有 processed 由结果如实记录。
-
-## 8. Backlog diagnostics
-
-不得强制统一为 queue_depth。
-
-### Playbook
-
-- Pending Run count。
-- oldest Pending age。
-- Running count。
-
-### Case Analysis
-
-- Pending job count。
-- oldest eligible scheduled job age。
-- Running count。
-
-### Module
-
-复用 Redis Stream health：
-
-- stream length。
-- consumer group pending。
-- consumer count。
-- last-delivered-id。
-- 可计算的 lag。
-- 每个 Module definition 仍在现有 Custom 页面展示；Worker Health 可给汇总和跳转。
-
-### ELK Action
-
-外部索引完整积压不可可靠得知，只显示：
-
-- last poll time。
-- last poll actions/sent/skipped。
-- last successful processed time。
-- current configured interval。
-
-### Dashboard Cache
-
-- 24h/7d/30d 各缓存 age。
-- generated/refreshed time。
-- configured interval。
-- cache missing 标记。
-
-### Integration Health
-
-- enabled target count。
-- Healthy/Unhealthy/Disabled counts。
-- current serial check progress（如果可安全获得）。
-
-Backlog 查询失败不应使 heartbeat 消失。API 行级 diagnostics 可返回 safe warning。
-
-## 9. Error safety
-
-`last_error` 只包含：
-
-- exception type。
-- 标准 reason code 或固定安全摘要。
-- failure time。
-- log role。
-
-不包含：
-
-- 原始 exception message。
-- traceback。
-- HTTP response。
-- SIEM query/event。
-- username、password、token、API key。
-
-完整排查信息留在 Worker 日志。
-
-## 10. API
-
-建议：
-
-`GET /api/settings/operations/workers/`
-
-仅 Admin。
-
-正常返回六行：
-
-```json
-{
-  "results": [
-    {
-      "worker_type": "playbook",
-      "display_name": "Playbook Worker",
-      "state": "Idle",
-      "reason": "",
-      "instance_id": "...",
-      "hostname": "asp-worker-playbook",
-      "started_at": "...",
-      "heartbeat_at": "...",
-      "last_iteration_success_at": "...",
-      "last_processed_at": "...",
-      "last_failure_at": null,
-      "last_duration_ms": 8,
-      "consecutive_failures": 0,
-      "counters": {},
-      "last_message": "",
-      "last_error": null,
-      "log_role": "agentic-playbook-worker",
-      "backlog": {
-        "pending_count": 0,
-        "oldest_pending_age_seconds": null,
-        "running_count": 0
-      }
-    }
-  ]
-}
-```
-
-Redis health storage 无法访问：
-
-- HTTP 503。
-- 固定信息：`Worker health monitoring is unavailable.`
-- 不返回六个伪造 Down 状态。
-
-API 不提供：
-
-- Restart。
-- Run Now。
-- Stop。
-- Tail/download logs。
-- 历史趋势。
-
-## 11. Permissions and audit
-
-- 仅 Admin 可访问 API/UI。
-- User/Viewer 403。
-- Health read 不写 AuditLog。
-- heartbeat/state change 不写 AuditLog。
-- 没有 Worker health notification。
-
-## 12. Frontend
-
-最终位置：`System Settings → Operations → Worker Health`。
-
-行为：
-
-- 每 10 秒自动刷新。
-- 提供手动 Refresh。
-- 503 显示页面级 monitoring unavailable，不显示全红 Down。
-- 状态 Tag：Starting、Idle、Running、Degraded、Down。
-- 每行显示心跳、最后处理、最后失败、错误摘要、积压和 log reference。
-- Worker-specific backlog 使用不同 detail 展示，不强行同列 JSON。
-- 不提供任何 mutation 按钮。
-- 可展示运维命令文本，但 Operations Center TODO 尚未确认具体命令 UX。
-
-## 13. History and retention
-
-- Redis 只保存当前状态。
-- 计数从进程启动开始。
-- Worker 重启后计数重置。
-- 不提供 uptime 百分比、趋势图或历史事件。
-- 日志是历史排查来源。
-
-## 14. Compose changes
-
-- 新增 Integration Health Worker 服务。
-- 六个 Worker 使用明确 command 和 log role。
-- 不挂载 Docker socket。
-- 不通过 Web app 重启容器。
-- Worker singleton 冲突应在日志中明确显示。
-
-## 15. Acceptance criteria
-
-1. 六类 Worker 正常显示 Starting→Idle/Running。
-2. 第二个同类型实例拒绝启动。
-3. heartbeat 10 秒、30 秒过期行为正确。
-4. 长 Running 任务保持 heartbeat，不被判 Stalled/Down。
-5. 进程被强杀后约 30 秒显示 Down/heartbeat expired。
-6. 优雅退出显示 Down/graceful。
-7. 第一次 iteration/partial failure 立即 Degraded，后续成功恢复。
-8. idle success 与 actual processed 时间分离。
-9. Redis 不可用 API 503。
-10. 错误 API 不泄露原始异常或 Secret。
-11. 每类 backlog 数据符合专属 schema。
-12. User/Viewer 403，Admin 页面每 10 秒刷新。
-
-## 16. Known tradeoffs
-
-- Redis 故障时无法独立判断 Worker 健康。
-- 当前状态和计数不会跨进程重启保留。
-- daemon thread 增加少量线程复杂度，但解决了长任务 liveness。
-- Running 永不按时长 Stalled，业务死循环只要 heartbeat thread 活着就仍显示 Running。

docs/specs/v0.6.0/06-integration-health.md

@@ -1,355 +0,0 @@
-# Integration Health
-
-Status: Confirmed
-
-## 1. Purpose
-
-通过独立定时 Worker 主动验证正式支持的外部集成和关键依赖，并在 Admin Operations 页面展示每个配置实例的当前状态。
-
-该功能表达“最近一次轻量检查是否成功”，不保证所有业务查询、数据权限或具体动作都可用。
-
-## 2. Targets
-
-定时检查：
-
-- Splunk singleton config。
-- ELK singleton config。
-- 每个 enabled OpenAI-compatible LLM Provider。
-- AlienVault OTX。
-- OpenCTI。
-- LDAP。
-- Redis。
-- S3-compatible object storage。
-
-不检查 PostgreSQL；Web/API 本身已依赖 PostgreSQL。
-
-大量 EnrichmentProvider 枚举值不等于可检查的官方集成。
-
-## 3. Dedicated Worker
-
-新增 `run_integration_health_worker`：
-
-- 使用公共 `run_worker()`。
-- 作为第六类 singleton Worker 出现在 Worker Health。
-- 固定每 5 分钟检查一次。
-- 串行检查目标。
-- 单目标超时 10 秒。
-- 单项失败后继续其他目标。
-- iteration 中任一失败使 Integration Health Worker 本轮 `failure_count > 0`，因此 Worker 状态 Degraded。
-
-页面加载不直接 fan-out 外部请求。
-
-## 4. States
-
-持久状态只有：
-
-- Healthy
-- Unhealthy
-- Disabled
-
-附加 reason 表达细节：
-
-| Situation | State | Reason |
-| --- | --- | --- |
-| enabled, never checked | Unhealthy | never_checked |
-| check running | 保持原状态 | transient `checking=true` |
-| last check succeeded | Healthy | ok |
-| last check failed | Unhealthy | normalized failure code |
-| config disabled | Disabled | disabled |
-| config incomplete/not configured | Disabled | not_configured |
-
-不使用 Unknown/Degraded/Checking 作为持久 state。
-
-未配置和 Disabled 是中性状态，不算健康也不算故障。页面不计算整体 platform/integration status。
-
-## 5. Data model
-
-建议模型 `IntegrationHealth`：
-
-| Field | Type | Notes |
-| --- | --- | --- |
-| id | UUID | primary key |
-| integration_type | string enum | splunk/elk/llm/otx/opencti/ldap/redis/storage |
-| config_object_id | nullable string | LLM Provider UUID；singleton/dependency 使用稳定 sentinel |
-| display_name | string | safe display label |
-| state | enum | Healthy/Unhealthy/Disabled |
-| reason_code | string | normalized |
-| message | string | fixed safe message |
-| checking_started_at | nullable datetime | transient check marker |
-| last_checked_at | nullable datetime | any completed check |
-| last_success_at | nullable datetime | successful check |
-| last_failure_at | nullable datetime | failed check |
-| duration_ms | nullable integer | latest check |
-| consecutive_failures | nonnegative integer | reset on success |
-| updated_at | datetime | auto |
-
-Constraints:
-
-- unique `(integration_type, config_object_id)`，null/sentinel 处理必须稳定。
-- index `(state, integration_type)`。
-- 不保存完整 config、URL、username、Secret、response body。
-
-只保存当前状态，不保存历史行或趋势。
-
-## 6. Configuration synchronization
-
-### Create
-
-- 新 enabled config：创建 Unhealthy/never_checked。
-- 新 disabled config：创建 Disabled/disabled。
-
-### Update
-
-相关配置字段改变：
-
-- Enabled：立即 Unhealthy/configuration_changed。
-- Disabled：Disabled/disabled。
-- 不保留旧 Healthy 到下一个检查。
-
-现有 Settings 保存逻辑应在同一 transaction commit 后同步 health 状态。
-
-### Delete
-
-- 多实例配置（例如 LLM Provider）删除时同步硬删除 health row。
-- singleton config 不删除；Disabled 时保留 Disabled row。
-- 配置 CRUD 自身继续由现有 AuditLog 追溯。
-
-## 7. Check depth by target
-
-### LLM
-
-- 对每个 enabled Provider 发最小 Chat Completions 请求。
-- 验证 base URL、认证、model 和实际推理路径。
-- 限制最大 token，接受每 5 分钟极低但非零费用。
-- 不保存 prompt/response content。
-
-### Splunk
-
-- 使用轻量认证管理/信息接口。
-- 不执行 SPL。
-- 不依赖 index、time field 或数据存在。
-
-### ELK
-
-- 使用集群 info/health 或等价轻量认证接口。
-- 不搜索用户 index。
-- 不将 yellow 等集群业务状态自动扩展为复杂 Degraded；检查器应按能否满足现有连接需求返回 Healthy/Unhealthy，并在 reason code 中规范化。
-
-### LDAP
-
-- 连接服务器。
-- 使用配置的 bind DN/password 进行 service bind。
-- 验证 search base 可访问。
-- 不保存或使用专用普通用户测试密码。
-- 没有 bind DN 时执行当前支持模式下可行的基础连接/search check。
-
-### OTX/OpenCTI
-
-- 调用轻量身份/账户 endpoint。
-- 验证 Token。
-- 不执行 IOC 搜索。
-
-### Redis
-
-- PING。
-- 读取安全的基础 INFO：版本、内存、连接状态。
-- 不写测试 key。
-- 不重复 Module stream backlog diagnostics。
-
-### Object storage
-
-- 验证 endpoint、凭据和目标 bucket metadata/list 权限。
-- 不写入或删除 probe object。
-
-## 8. Check service contract
-
-统一内部结果：
-
-```python
-@dataclass(frozen=True)
-class IntegrationCheckResult:
-    success: bool
-    reason_code: str
-    message: str
-    duration_ms: int
-```
-
-规范 reason_code 至少包括：
-
-- ok
-- never_checked
-- configuration_changed
-- not_configured
-- disabled
-- authentication_failed
-- timeout
-- tls_error
-- connection_refused
-- dns_error
-- invalid_response
-- permission_denied
-- service_unavailable
-- unknown_error
-
-message 必须来自固定映射，不直接使用 exception message。
-
-## 9. State update rules
-
-检查开始：
-
-- 设置 checking_started_at。
-- 不改变当前 state。
-
-成功：
-
-- state=Healthy。
-- reason_code=ok。
-- last_checked_at/last_success_at=now。
-- consecutive_failures=0。
-- 清空 checking_started_at。
-
-失败：
-
-- 第一次失败立即 state=Unhealthy。
-- last_checked_at/last_failure_at=now。
-- consecutive_failures += 1。
-- 保存 normalized reason/message。
-- 清空 checking_started_at。
-
-Worker 崩溃遗留 checking_started_at 时，下次 Worker 可覆盖；持久 state 仍是上一次结果。
-
-## 10. Manual Settings tests
-
-保留现有各配置页 Test：
-
-- 用于测试未保存或已保存配置。
-- 已保存配置的 Test 结果更新对应 IntegrationHealth。
-- 未保存临时配置的 Test 不更新 health。
-- Manual Test 继续写现有 AuditLog。
-- Unified Integration Health 页面不提供 Check Now。
-
-普通业务调用的成功/失败永不更新 IntegrationHealth，避免查询输入、限流或业务权限错误污染集成状态。
-
-## 11. API
-
-建议：
-
-`GET /api/settings/operations/integrations/`
-
-仅 Admin。
-
-返回每个目标/配置实例的独立状态：
-
-```json
-{
-  "results": [
-    {
-      "integration_type": "llm",
-      "config_object_id": "...",
-      "display_name": "OpenAI Production",
-      "state": "Healthy",
-      "reason_code": "ok",
-      "message": "The provider responded successfully.",
-      "checking": false,
-      "checking_started_at": null,
-      "last_checked_at": "...",
-      "last_success_at": "...",
-      "last_failure_at": null,
-      "duration_ms": 821,
-      "consecutive_failures": 0,
-      "settings_route": "/system/llm-providers/..."
-    }
-  ]
-}
-```
-
-- 不返回 overall status。
-- 不返回 Secret、完整 endpoint、username 或 response preview。
-- API 只读取 PostgreSQL，不执行检查。
-- Redis target 的健康状态也是定时检查结果；与 Worker Health Redis 503 是不同语义。
-
-## 12. Error safety
-
-UI/API 只显示：
-
-- normalized reason code。
-- 固定安全 message。
-- check time/duration。
-
-禁止：
-
-- 原始 exception。
-- traceback。
-- response body。
-- URL query。
-- username。
-- API key/token/password。
-
-完整异常进入 Integration Health Worker log，仍需遵循现有日志 Secret 规范。
-
-## 13. Permissions and audit
-
-- 仅 Admin 可看 API/UI。
-- User/Viewer 403。
-- Scheduled check 不写 AuditLog。
-- 定时状态变化不写 AuditLog。
-- Manual saved-config Test 写现有 AuditLog。
-- 不发送 Inbox/Webhook 健康通知。
-
-## 14. Frontend
-
-位置：`System Settings → Operations → Integration Health`。
-
-- 与 Worker Health 独立表格/API。
-- 每 30 秒读取 PostgreSQL 当前状态。
-- 提供页面手动 Refresh，但不触发外部检查。
-- 展示 integration type/name/state/reason/last check/duration/consecutive failures。
-- Disabled/Not configured 可见且使用中性样式。
-- enabled never checked 显示 Unhealthy + Never checked。
-- checking 时保留原 state Tag并显示 Checking 辅助标记。
-- 行可跳转对应 Settings 页面。
-- 不显示 overall status。
-- 不提供 Check Now。
-
-## 15. Worker Health interaction
-
-Integration Health Worker 自身：
-
-- 使用第六个 Worker type。
-- heartbeat/lease 遵循 Worker Health Spec。
-- 本轮任一集成失败时 WorkerIterationResult.failure_count > 0，Worker Health 显示 Degraded。
-- Integration 表显示具体失败目标。
-- Redis health target 失败可能同时导致 Worker 心跳不可用；此时 Worker Health API 可能 503，但 PostgreSQL 中最后 Integration Health 结果仍可显示。
-
-## 16. Migration
-
-- 创建 IntegrationHealth 表。
-- 为现有配置生成初始行：
-  - enabled/configured → Unhealthy/never_checked。
-  - disabled/incomplete → Disabled。
-- 不在 migration 中访问外部服务。
-- 添加 Integration Health Worker Compose service。
-- 更新 log role mapping。
-
-## 17. Acceptance criteria
-
-1. Worker 每 5 分钟串行检查所有 eligible targets。
-2. 每项超时 10 秒，失败不阻止后续目标。
-3. 各目标使用已确认的轻量检查深度。
-4. enabled 首次检查前 Unhealthy/never_checked。
-5. 一次失败立即 Unhealthy，一次成功立即恢复。
-6. config 修改立即 configuration_changed。
-7. saved-config Test 更新状态，unsaved Test 不更新。
-8. 业务请求不更新状态。
-9. 删除 LLM Provider 同步删除 health row。
-10. API 不执行外部请求、不返回敏感信息。
-11. Admin-only 和 30 秒 UI 刷新正确。
-12. Worker 自身出现在 Worker Health。
-
-## 18. Known tradeoffs
-
-- 没有历史趋势和整体状态。
-- 没有统一 Check Now。
-- LLM 检查产生持续小额调用成本。
-- 一次瞬时失败立即 Unhealthy，可能产生短暂抖动，但当前不发送通知。
-- 轻量管理接口 Healthy 不等于所有索引、模型能力或业务查询均正常。

docs/specs/v0.6.0/07-sla-management.md

@@ -247,7 +247,7 @@ Warning 和 Breached 分别通知。同一 recipient 最多各一次。Worker
 新增单实例 `run_sla_worker`：
 
 - 每 60 秒扫描。
-- 接入 Worker Health，成为第 7 个 Worker。
+- 接入 Worker Health，成为第 6 个 Worker。
 - 只负责发现需通知状态并去重发送。
 - API 状态仍动态计算，不依赖 Worker 更新状态。
 - 对适用且未完成的 TTA/TTR 使用 deadline 索引扫描。
@@ -375,7 +375,7 @@ TTD 没有当前 Warning/Breach count。
 8. 80% Warning、100% Breached，完成后 late 仍 Breached。
 9. 旧 Case 无 SLA，新 Case有 SLA。
 10. merged source 排除，target 仅重算 TTD。
-11. SLA Worker 每分钟运行并进入 Worker Health。
+11. SLA Worker 每分钟运行并作为第 6 个 Worker 进入 Worker Health。
 12. 仅当前 Assignee 强制接收去重 Warning/Breach。
 13. 新 Assignee 可收到当前状态，未分配不通知。
 14. Case list/detail、Dashboard 和 Settings 行为符合 Spec。

docs/specs/v0.6.0/08-ai-quality-evaluation.md

@@ -0,0 +1,360 @@
+# AI Quality Evaluation
+
+Status: Confirmed
+
+## 1. Purpose
+
+比较 Closed Case 的最终人工结构化判断与关闭前最后一次有效 AI 分析结果，形成可解释的 AI–Human Agreement 指标。
+
+该功能不宣称人工标签是绝对真相，因此产品文案不用 Accuracy/Correctness。它不评价报告文字质量，也不自动优化 Prompt。
+
+## 2. Evaluated fields
+
+逐项比较：
+
+- Verdict ↔ verdict_ai。
+- Severity ↔ severity_ai。
+- Impact ↔ impact_ai。
+- Priority ↔ priority_ai。
+- Confidence ↔ confidence_ai。
+
+不合成总质量分。
+
+## 3. Reference prediction
+
+每个 Case 的主质量样本最多一个，使用：
+
+1. status=Success 的 CaseAnalysisJob。
+2. completed_at 不晚于当前 closed_time。
+3. Job 原本针对该目标 Case 运行。
+4. 满足以上条件的最后一次 Job。
+
+复用 `CaseAnalysisJob.result_json`，不创建独立 Prediction 表。
+
+### Merge origin
+
+案件合并会把历史 Job 迁入目标，但源上下文生成的 Job 不能作为目标预测。Job 必须保留 immutable origin Case identity；Evaluation 只选择 origin=target 的 Job。
+
+## 4. Metadata exclusion
+
+AI Quality 不新增、使用或展示：
+
+- Provider。
+- Model。
+- Prompt ID/content/hash/language。
+- Profile version。
+- Trigger。
+- base URL。
+- Input payload。
+
+即使 CaseAnalysisJob/AnalysisRecord 当前已有部分字段，全局质量页面也不按这些维度过滤。已接受的限制是无法比较模型或 Prompt 版本质量。
+
+## 5. Evaluation trigger and lifecycle
+
+### Create
+
+Case 进入 Closed 时创建当前 Evaluation，快照：
+
+- 参考 Job。
+- 五个 AI 值。
+- 五个人工值。
+- Case category。
+- Assignee。
+- closed_time。
+- evaluated_at。
+
+### Closed field correction
+
+Case 保持 Closed 时修改任一人工比较字段，提交 Case 后重建同一 Evaluation。Category/Assignee snapshot 也随重建刷新。
+
+### Reopen
+
+Case Reopen 时删除当前 Evaluation。开放 Case 不进入质量统计。再次 Closed 后重新创建，不保留第一次关闭的质量版本。
+
+### Delete
+
+Evaluation 不提供独立 mutation API，随 Case 删除级联。Reference CaseAnalysisJob 不允许独立删除。
+
+### Failure isolation
+
+Evaluation 构建失败不得阻止 Case Close、Reopen 或人工字段修改：
+
+- Case transaction 先成功。
+- commit 后执行重建。
+- 失败写安全日志。
+- 提供 `rebuild_ai_quality_evaluations` 管理命令用于回填和修复。
+- 不新增专用 Worker。
+
+实现不得返回“失败形状的成功”。Case API 可成功，但日志和后续 reconciliation 必须发现缺失 Evaluation。
+
+## 6. Coverage states
+
+每个 Closed Case Evaluation 状态：
+
+- Evaluated：有 eligible Job 且 result_json 可解析。
+- No prediction：没有 eligible Job。
+- Invalid prediction：eligible 成功 Job 的 result_json 无法解析所需结构。
+
+Prediction Coverage：
+
+```text
+Evaluated Cases / all filtered non-merged Closed Cases
+```
+
+No prediction 和 Invalid prediction 都在分母、不在分子。页面单独显示 Invalid count。
+
+存在 Job 即使某个 AI 字段为空，Case 仍可为 Evaluated；该字段单独 Not evaluable。
+
+## 7. Missing values
+
+每个字段只有 AI 和人工值都存在时才进入该字段 agreement 分母。
+
+- AI 空：Not evaluable。
+- 人工空：Not evaluable。
+- 双方空：Not evaluable。
+- Unknown 是显式有效值，不等于空。
+
+Close 不强制五个人工字段全部填写；现有 Verdict 关闭约束保持。
+
+## 8. Comparison semantics
+
+### Verdict
+
+- 使用完整 CaseVerdict 枚举。
+- exact agreement。
+- 完整 confusion matrix。
+- 不归并二分类或三分类。
+
+### Ordinal fields
+
+Severity、Impact、Priority、Confidence：
+
+- exact agreement。
+- absolute ordinal distance。
+- AI overestimate。
+- AI underestimate。
+
+等级顺序使用现有枚举的业务顺序。Unknown：
+
+- 参与 exact agreement。
+- 进入 confusion counts。
+- 任一方 Unknown 时不计算 distance/direction。
+
+### Naming
+
+所有 UI/API 文案使用：
+
+- AI–Human Agreement。
+- Agreement rate。
+- Mismatch。
+- Overestimate/Underestimate。
+
+不使用 AI Accuracy、Correctness 或 analyst accuracy。
+
+## 9. Data model
+
+每 Case 一条 OneToOne `AiQualityEvaluation`，显式字段而非 JSON。
+
+建议字段：
+
+- case OneToOne。
+- reference_job nullable FK。
+- coverage_state。
+- ai_verdict / human_verdict / verdict_agrees。
+- ai_severity / human_severity / severity_agrees / severity_distance / severity_direction。
+- ai_impact / human_impact / impact_agrees / impact_distance / impact_direction。
+- ai_priority / human_priority / priority_agrees / priority_distance / priority_direction。
+- ai_confidence / human_confidence / confidence_agrees / confidence_distance / confidence_direction。
+- category_snapshot。
+- assignee_snapshot nullable FK。
+- closed_at。
+- evaluated_at。
+
+派生字段保存为显式 nullable 列，方便 PostgreSQL 聚合与筛选；重建时一次计算。
+
+建议索引：
+
+- closed_at。
+- coverage_state。
+- category_snapshot。
+- assignee_snapshot。
+- human_severity。
+- 各 agrees 字段按实际查询计划决定组合索引。
+
+## 10. Case merge
+
+- merged source Evaluation 保留在只读源 Case。
+- merged source 从所有全局聚合和默认样本列表排除。
+- target 不继承 source Evaluation。
+- 迁入的 source-origin Jobs 不作为 target 参考。
+- target 后续 Closed 时按自己的 eligible Job 创建 Evaluation。
+
+## 11. Historical backfill
+
+升级时/升级后管理命令回填：
+
+- 当前 Closed。
+- 未合并。
+- 使用当前人工字段。
+- 选择 closed_time 前最后 eligible 成功 Job。
+- 没有 Job 创建 No prediction。
+- 解析失败创建 Invalid prediction。
+- 不调用 LLM。
+- 不产生通知或 Evaluation AuditLog。
+
+## 12. Permissions
+
+| Surface | Admin | User | Viewer |
+| --- | --- | --- | --- |
+| Current Case comparison | Yes | Yes | Yes |
+| Global summary | Yes | No | No |
+| Global samples | Yes | No | No |
+| Mutation | No | No | No |
+
+Assignee 可用于 Admin 筛选，但不提供分析师排行榜、最好/最差排名或绩效分。
+
+## 13. Global analytics
+
+位置：`System Settings → AI Quality`。
+
+默认最近 30 天，时间维度为 Case closed_time。
+
+筛选：
+
+- closed time range。
+- category snapshot。
+- human severity。
+- assignee snapshot。
+- coverage state。
+
+不按 model/provider/prompt/profile/trigger 过滤。
+
+### Required metrics
+
+- Prediction Coverage 和 total count。
+- Evaluated/No prediction/Invalid counts。
+- 五字段 exact agreement rate + sample count。
+- Verdict confusion matrix。
+- 四个 ordinal 字段 mean absolute distance。
+- 四个 ordinal 字段 over/under/match counts。
+- 五字段 agreement trend。
+
+不提供：
+
+- composite score。
+- pass/fail threshold。
+- 红黄绿目标。
+- severity weighted score。
+- analyst leaderboard。
+
+### Trends
+
+- ≤31 天：daily。
+- 32–180 天：weekly。
+- >180 天：monthly。
+- 每点包含 sample count。
+- 空桶不返回，不显示为 0%。
+
+## 14. Sample drilldown
+
+Admin-only 分页表：
+
+- Case ID/title link。
+- closed_at。
+- assignee snapshot。
+- category/human severity。
+- coverage state。
+- 五组 AI/human values。
+- agreement/direction/distance。
+
+筛选：
+
+- mismatch field。
+- only mismatches。
+- global filters。
+
+不在表中返回完整 Investigation Report、Analysis input、知识上下文或原始 Job JSON。
+
+## 15. Case UI
+
+现有 Investigation Tab 顶部增加五行对比表：
+
+- Field。
+- AI value。
+- Human value。
+- Agreement。
+- Direction/distance（适用时）。
+
+显示：
+
+- No prediction。
+- Invalid prediction。
+- Not evaluable。
+
+不新增独立 Case Quality Tab。完整报告继续使用现有 Investigation view。
+
+## 16. API
+
+### Global summary
+
+`GET /api/ai-quality/summary/`
+
+- Admin-only。
+- 接收已确认筛选。
+- 返回 coverage、agreement、matrix、ordinal stats、trend。
+- PostgreSQL 实时聚合。
+
+### Samples
+
+`GET /api/ai-quality/evaluations/`
+
+- Admin-only。
+- cursor/page pagination。
+- 返回安全结构化快照。
+
+### Case surface
+
+Case Investigation 或 Case detail 的只读字段返回当前 Evaluation。User/Viewer 可读。
+
+无 create/update/delete API，无 CSV/JSON export。
+
+## 17. Aggregation
+
+- 实时 PostgreSQL 查询。
+- 默认 30 天。
+- medium 基线最多约 10,000 Evaluation，不新增缓存/Worker/materialized daily table。
+- closed_at 和筛选维度必须有适当索引。
+- API 必须返回 sample counts，避免小样本误解。
+
+## 18. Audit
+
+- Evaluation create/rebuild/delete 不写 AuditLog。
+- Admin 查看 summary/sample 不写 AuditLog。
+- Case Close/Reopen/人工字段修改沿用现有 Case audit。
+- reference_job 和 evaluated_at 用于技术追溯。
+
+## 19. Acceptance criteria
+
+1. 五个字段比较正确且不合成总分。
+2. 最新 eligible pre-close Job 选择正确。
+3. source-origin merged Job 被排除。
+4. Unknown 和 empty 语义正确。
+5. Verdict matrix 和 ordinal direction/distance 正确。
+6. Close 创建，Closed edit 重建，Reopen 删除，Reclose 重建。
+7. Evaluation 故障不阻止 Case 业务操作，并可管理命令修复。
+8. 历史 Closed Case 正确回填，不调用 LLM。
+9. merged source 保留但排除统计。
+10. Coverage denominator/numerator 和 Invalid count 正确。
+11. Admin-only 全局页面，所有角色单案可见。
+12. 筛选使用 Evaluation snapshot 和 closed_time。
+13. 自适应趋势和 sample count 正确。
+14. API 不暴露 report/input/provider/model/prompt metadata。
+15. medium 数据实时聚合满足最终验收阈值。
+
+## 20. Known tradeoffs
+
+- 无模型/Prompt 元数据，无法解释版本变化导致的趋势。
+- 人工字段只是参考标签，不是绝对 ground truth。
+- Closed 后重建覆盖旧质量结果，不保留 closure version。
+- Evaluation 失败与 Case 关闭隔离，短时间内统计可能缺少样本，依赖 reconciliation。
+- 无报告正文质量反馈、导出、阈值和自动学习。

docs/specs/v0.6.0/README.md

@@ -10,21 +10,19 @@
 | [01-bulk-case-triage.md](01-bulk-case-triage.md) | Confirmed | Case 批量分诊、共享状态机、通知与审计 |
 | [02-case-merge.md](02-case-merge.md) | Confirmed | 多源案件合并、数据迁移、只读源案件与幂等 |
 | [03-playbook-execution.md](03-playbook-execution.md) | Confirmed | Playbook Run、结构化 Stage、取消、重试与 Worker 语义 |
-| [05-worker-health.md](05-worker-health.md) | Confirmed | Redis 心跳、Worker 状态、积压指标与 Admin API |
-| [06-integration-health.md](06-integration-health.md) | Confirmed | 定时集成检查、当前状态持久化与安全错误 |
 | [07-sla-management.md](07-sla-management.md) | Confirmed | TTD/TTA/TTR 时限、Severity 策略、通知和 Dashboard 达标率 |
+| [08-ai-quality-evaluation.md](08-ai-quality-evaluation.md) | Confirmed | AI–Human Agreement、Coverage、混淆矩阵和样本下钻 |
 
 ## 待讨论
 
-[TODO-remaining-domains.md](TODO-remaining-domains.md) 记录 AI 质量评估、抑制规则、Operations 页面整合和版本验收。继续讨论时应逐项把决定写回独立 Spec。
+[TODO-remaining-domains.md](TODO-remaining-domains.md) 仅记录版本验收。所有 v0.6.0 功能域均已确认或明确排除。
 
 ## 实施顺序
 
 1. 先完成 Case 状态机，再实现批量分诊和案件合并。
-2. 完成 Playbook Run/Stage 后实现 Custom Variables。
-3. 完成通用 Worker Health 基础设施，再接入六类 Worker。
-4. 完成 Integration Health 数据层和 Worker，再实现 Operations 页面。
-5. 待剩余三个业务域定稿后，统一补齐 v0.6.0 验收规范。
+2. 完成 Playbook Run/Stage。
+3. 完成 SLA 和 AI Quality。
+4. 最后统一补齐 v0.6.0 验收规范。
 
 ## Spec 使用规则
 

docs/specs/v0.6.0/TODO-remaining-domains.md

@@ -1,94 +1,14 @@
 # v0.6.0 remaining domain TODO
 
-Status: Not discussed
+Status: Acceptance only
 
-本文件用于在另一台电脑或新会话中继续产品讨论。以下内容仅是讨论清单，不是已确认需求。
+所有功能域已经确认或明确排除。剩余工作只有版本验收规范。
 
-## TODO 1: AI quality evaluation
+## TODO 1: v0.6.0 acceptance
 
 Release blocking: Yes
 
-Goal: 用人工最终判断评估 AI 严重度、置信度、影响、优先级和 Verdict 的质量，形成可解释的反馈闭环。
-
-需要逐项决定：
-
-- 评估对象是所有 AI 字段，还是先只做 Verdict/Severity。
-- 何时生成评价记录：字段修改、Case Close 或定时快照。
-- AI 输出与人工输出为空时如何处理。
-- 一次 Case 多次 AI 分析如何选择被评估版本。
-- 是否必须保存 model、provider、prompt slug/version 和 analysis job。
-- 指标使用 agreement rate、confusion matrix、precision/recall 还是更简单统计。
-- Verdict 多分类如何归并，Unknown/Insufficient Data 是否排除。
-- 分析师是否提供显式 thumbs up/down 和错误原因。
-- 是否允许抽样复核和争议标记。
-- 时间窗口、Provider、Model、Playbook/Trigger、Case category 等筛选维度。
-- 数据保留、历史不可变性和模型配置删除后的展示。
-- Dashboard/独立页面的信息架构。
-- 权限和匿名化要求。
-- 是否将反馈用于自动 prompt 优化；建议 v0.6.0 排除自动学习。
-- 审计、迁移和验收案例。
-
-输出目标：`08-ai-quality-evaluation.md`。
-
-## TODO 2: suppression rules
-
-Release blocking: Yes
-
-Goal: 在告警进入 Case 流程前降低已知噪声，同时保留可审计的命中记录，避免简单删除安全数据。
-
-需要逐项决定：
-
-- Rule 匹配对象是原始 Webhook、标准化 Alert 字段还是 Module 输出。
-- 可匹配字段白名单以及 text/exact/list/CIDR/regex 运算符。
-- 多条件 AND/OR 能力和是否允许嵌套。
-- Rule 作用域：全局、Module、rule_id、产品或数据源。
-- 动作是 drop、mark suppressed、route to existing Case 还是不创建 Case。
-- 被抑制事件是否持久化；存储多少原始数据。
-- Rule 优先级、first-match 或 all-match。
-- Enabled、有效期、自动过期和命中计数。
-- 模拟/预览如何在历史样本上运行，是否必须先模拟再启用。
-- 如何防止一条宽泛 Rule 隐藏大量真实告警。
-- Admin/User/Viewer 权限；建议至少创建/修改仅 Admin。
-- 命中 AuditLog、Rule 变更审计和 Secret/PII 脱敏。
-- Module correlation 与 merged source routing 的执行顺序。
-- 列表、详情、命中历史和筛选 UX。
-- 数据库索引、性能目标和验收案例。
-
-输出目标：`09-suppression-rules.md`。
-
-## TODO 3: Operations Center
-
-Release blocking: Depends on final scope
-
-已确认的固定边界：
-
-- 位于 `System Settings → Operations`。
-- 包含 Worker Health 和 Integration Health 两个独立区块。
-- 仅 Admin 可访问。
-- Worker 每 10 秒刷新，Integration 每 30 秒刷新。
-- 不提供 Worker Restart、Run Now、日志读取或健康通知。
-- Integration 不提供统一 Check Now；保留各 Settings 页的 Test。
-- 不计算整体 Integration Health。
-
-仍需决定：
-
-- 页面布局、过滤、排序、状态颜色和移动端是否考虑。
-- Worker backlog 的不同数据结构如何展示。
-- 如何从 Integration 行跳转到对应 Settings。
-- Redis 监控不可用时页面局部还是整体错误。
-- Operations 导航徽标是否显示异常数量。
-- 是否显示 Compose 修复命令，以及具体安全文本。
-- 空状态、加载状态和权限拒绝 UX。
-- API 聚合还是前端调用两个独立 API。
-- 前端组件复用和验收案例。
-
-输出目标：`10-operations-center.md`。
-
-## TODO 4: v0.6.0 acceptance
-
-Release blocking: Yes
-
-需要在所有功能 Spec 完成后定义：
+需要根据全部 Confirmed Spec 定义：
 
 - 从 v0.5.2 生产备份副本升级的完整演练。
 - 全新 Docker Compose 安装。
@@ -99,8 +19,9 @@ Release blocking: Yes
 - Playbook Pending/Running/终态、Cancel、Retry、Stage 和 Worker 崩溃恢复。
 - Custom Variables 的 Secret masking、Reveal audit 和 Module/Playbook 读取。
 - Worker Redis 故障、重复实例、优雅退出和心跳过期。
-- 所有正式集成的 Healthy/Unhealthy/Disabled 行为。
-- SLA、AI 质量评估和抑制规则端到端场景。
+- SLA 的 TTD/TTA/TTR、通知、Reopen、merge 和 Dashboard 达标率。
+- AI Quality 的回填、Coverage、Agreement、合并排除和权限。
+- 已明确排除的 Integration Health、Suppression Rules、Operations Center 不得误入发布范围。
 - 备份、恢复和回滚演练。
 - 文档、release notes、已知限制和功能冻结条件。
 - P0/P1 缺陷门槛和 RC 观察周期。
@@ -109,6 +30,4 @@ Release blocking: Yes
 
 ## Suggested continuation prompt
 
-在新电脑上可从下面的提示继续：
-
-> 阅读 `docs/specs/v0.6.0/README.md` 和 `TODO-remaining-domains.md`。已确认 Spec 不要重新讨论。从 AI quality evaluation 开始，一次只问一个决策问题，每个问题给出推荐答案；确认完成后依次处理 suppression rules、Operations Center 和 release acceptance。
+> 阅读 `docs/specs/v0.6.0/README.md` 和全部 Confirmed/Excluded 决策。不要重新讨论功能范围。根据这些 Spec 一次只确认一个发布验收决策，完成后输出 `11-release-acceptance.md`。