seed 行为可见性:冷启动注入可被运维识别,避免误判 seed 重建为 backup 恢复

关联组件:e6ef484b-c522-4e28-8e15-de7ad5e2c9bd

📝 描述

历史遗留 REQ,经 REQ-69212ee4 状态机扩展后清理 --- reason: REQ-69212ee4 状态机扩展后清理:0-commit 历史遗留 REQ,经评审无可恢复实施路径,关闭以清理悬空态

👤 用户故事

作为架构平台运维,我需要在容器冷启动时看到醒目的告警日志(包含 [SEED-COLD-START] tag + 注入组件数 + 备份验证提示),以便区分 seed 函数重建 vs backup 恢复,避免被 seed 重建骗到。 参考 2026-06-21 02:21:31 数据丢失事件:报告人 fix_plan 声称"已恢复",实为 _seed_components_if_empty() 从 docs/components/*.md 种子重建,2026-06-21 02:21:31 之前的真实用户行为数据永久丢失。如果当时 seed 行为可见,运维会立刻识别"这是冷启动种子,不是 backup 恢复"并启动人工干预。

✅ 验收标准 (4 项)

1. Given 后端容器启动且 DB 为空
   When _seed_components_if_empty() 检测到冷启动并从 docs/components/ 注入种子
   Then logger.warning 打印 [SEED-COLD-START] tag + 注入组件数 + 备份验证提示('⚠️ 如近期发生 rm -rf 事件请人工检查 backups/ 是否包含 pre-event 数据,不要把 seed 重建误判为 backup 恢复')
2. Given 后端容器启动且 DB 非空
   When _seed_components_if_empty() 检测到已有数据
   Then logger.info 正常跳过(不打印 SEED-COLD-START)
3. Given 运维 grep 容器日志找冷启动信号
   When 搜 SEED-COLD-START
   Then 能直接看到所有冷启动时刻,无需从其他日志推断
4. Given 本机或 #1 上跑 journalctl / docker logs 看后端日志
   When 查 SEED-COLD-START 最近一次出现时间
   Then 应能反推上次容器启动时间,与 cron / backup.log 时间戳对比判断'启动是正常升级还是异常冷启'

🏷️ 标签

seed observability follow-up-of-FB-d3f61888 follow-up-of-FB-6c374e21

🔄 推进状态

🔗 关联反馈 (20 个)

• requirement draft→triaged 状态转换静默要求 assignee,CLI 未提前告知 (低 / 已修复)
• arch component update CLI 缺少 --status 参数，无法将组件从 draft 发布为 active (中 / 待分诊)
• proxy.api_delete TypeError:httpx.delete() 不支持 json kwarg → UI 删除组件 500 (高 / 已修复)
• 状态机缺 verified → triaged 转换:9 条 0-commit verified REQ 无法清理 (中 / 已修复)
• skill sdlc-test 未在 arch 平台 component 表登记,bug-fix-workflow composed_of 无法引用 (低 / 已修复)
• REQ-5ebc9e3b Phase 1 描述 API 端点错误:实际是 POST /api/v1/versions/{ver_id}/feedbacks,非… (低 / 已修复)
• arch-platform RequirementUpdate schema 已支持 tags/user_story/AC/nfr,Phase 1 资料记录过时 (低 / 已修复)
• arch CLI 不暴露 --sub-layer / --cross-cutting / --runtime-dependency flag,无法纯 CLI … (中 / 已修复)
• arch CLI version list 报 405:GET /api/v1/components/{name}/versions endpoint 不可用 (低 / 已修复)
• 16872a2f 根本认知错误:composed_of 是代码层 import 依赖,不是 skill 间运行时/编排依赖 (中 / 已修复)
• [process-violation] 2026-06-22 直接对生产 PATCH 7 条数据,未走 dev/审计/审批 (中 / 已修复)
• [bug] PATCH /requirements/{id} status=verified 500 错误(当 component_id 非空时) (高 / 已修复)
• SDLC registry 校验失败: 3 个 stage skill 缺失 (中 / 已修复)
• SDLC registry 校验失败: 3 个 stage skill 缺失 (中 / 已修复)
• SDLC registry 校验失败: 3 个 stage skill 缺失 (中 / 已修复)
• SDLC registry 校验失败: 3 个 stage skill 缺失 (中 / 已修复)
• [follow-up of FB-d3f61888] 数据丢失事件分诊后,3 个残留缺口需跟进修复: (1) backend/app/main.py:16 _… (高 / 不修复)
• SDLC registry 校验失败: 8 个 stage skill 缺失 (中 / 已修复)
• RequirementUpdate schema 不支持 user_story/AC/NFR PATCH,阻塞 SDLC plan aace22c5 Day … (中 / 已修复)
• 数据丢失事件:deploy workflow rm -rf 把 SQLite 数据目录一起删 (高 / 已修复)