v0.2.0 fix: 收口 E1 演化审批与凭据安全

[mirror29]

Summary

E1 演化审批闭环

• 冻结 owner-scoped LLM 配置、精确模型计价、费用上限与稳定 digest，并将审批 operation 与幂等创建绑定。
• Dashboard 活动页补齐显式批准/拒绝入口；Evolver 按 run 即时解析 owner 凭据，不持久化明文 API key。

凭据与队列安全

• 使用独立 Ed25519 capability 绑定 owner、operation、config 与 digest；生产环境仅 orchestration 持有私钥。
• grant 首次响应丢失时只允许两分钟内补偿重试一次；queued 最长保留 24 小时，避免授权自然过期后才失败。
• Dashboard/DB 暂不可用时安全重排队并重试状态写入；迁移同步收口遗留 run 与 pending candidates。

项目文档

• README（中英文）、AGENTS、当前状态、Evolver 与部署文档已同步至 D-12 / E1 当前实现与部署要求。

Test Coverage

新增路径覆盖冻结快照、跨服务 grant 契约、owner/config 隔离、审批负向分支、费用审计、重排队与 PostgreSQL 迁移约束。

• Evolver：108 passed；Ruff passed
• Dashboard：47 passed；typecheck 与 production build passed
• Orchestration：最新定向 19 passed；typecheck 与 build passed
• Paper：957 passed（本分支全量回归）
• Migration 0038 / 0041：passed；0041 已在真实 PostgreSQL 上从 0040 升降级验证
• 跨文件一致性：18 passed，0 failed（120 条既有启发式 warning）
• Orchestration 全量曾为 532/533；唯一失败是并行计时阈值波动，失败用例隔离重跑 4/4 passed

Pre-Landing Review

安全复审发现的 grant 契约、私钥隔离、队列 TTL、重试可靠性与迁移收口问题均已修复；最终定向复审未发现 P0/P1 阻塞项。

Design Review

Activity 页新增审批操作已通过组件测试、类型检查与生产构建；本次未执行独立视觉审查。

Eval Results

未修改 agent prompt，跳过 eval。

Scope Drift

Scope Check: CLEAN

Plan Completion

E1 production-closure 计划 8/8 已完成，无延期项。

Verification Results

核心单元、集成、迁移、构建、Compose 解析、shell 语法与文档一致性检查均通过。

TODOS

No TODO items completed in this PR.

Test plan

• Evolver tests pass (108 tests)
• Dashboard tests pass (47 tests)
• Dashboard and orchestration production builds pass
• PostgreSQL migration 0041 upgrade/downgrade test passes
• Cross-file consistency check passes (18 checks, 0 failures)

🤖 Generated with OpenAI Codex

[cloudflare-workers-and-pages]

Deploying inalpha-web with    Cloudflare Pages

Latest commit:	92c6d2b
Status:	✅  Deploy successful!
Preview URL:	https://86a9f65c.inalpha-web.pages.dev
Branch Preview URL:	https://codex-evolution-task27.inalpha-web.pages.dev

View logs

[github-actions]

Review base: 9c27d34

🤖 DeepSeek V4 Pro PR Review

这个 PR 把 E1 Evolver 的审批链路与凭据安全做了收口：冻结 LLM/定价快照、绑定 owner + operation + config_digest 的短时 Ed25519 grant、Dashboard 内部按 owner 即时解密 API key、被拒变异也计入费用，并把文档/环境模板/dev 脚本同步到新服务形态。整体方向符合 CLAUDE.md 的安全边界与金融时效性要求，测试覆盖也比较扎实。

只有一条 medium finding：

[medium] apps/dashboard/src/app/api/permissions/[id]/respond/route.ts:16 — 审批响应 BFF 未在本路由内验证“当前登录用户就是待审批项 owner”，而是仅校验 decision 枚举后透传给 Mastra — 依据：安全（越权）+ CLAUDE.md §3/AGENTS.md 红线“逐用户 JWT / owner scope”。若 backendFetch("mastra", ...) 仍沿用服务级 token 或未从当前 session 抽取并转发用户 JWT，则任何已认证用户只需构造 /api/permissions/{requestId}/respond（requestId 为 UUID，可能从日志/预测/共享 timeline 泄漏）即可批准或拒绝另一 owner 的演化审批，破坏显式审批的 owner 隔离。当前 route.test 只验证了 malformed decision 和转发参数，没有覆盖 owner 匹配失败场景；建议在本路由或 backendFetch 调用点显式获取当前登录 subject，并在转发前/由 Mastra 硬校验 ready 项的 owner 与审批者一致。