固定快照
一次体检、一次 PR 审查或一次隔离执行开始时，RepoCare 会把对应的 Git 提交（SHA）记录下来，之后所有的文件读取和引用都基于这个版本。
- 体检锁定所选分支当时的最新提交。
- PR 审查同时锁定 head（待合并的改动）和 base（合并目标）两个提交。
- 复现与验证在 Docker 中检出同一个提交执行，并在每次尝试前重置工作目录。
这样做的好处是结论可以复查：几天后再看报告，引用的文件内容和当时完全一致。代价是结论会过时——仓库有了新提交、Issue 原文被编辑、PR 推送了新代码，或项目规则改了版本，旧结论就只能作为历史参考。页面会明确标出“原文已更新”“版本已过期”“需重新审查”，此时请按新版本重新分析。
证据、建议与确认
RepoCare 把信息分成三层，界面上会分别标注：
| 层次 | 含义 | 界面上的样子 |
|---|---|---|
| 原始事实 | 从 GitHub 或仓库直接读取的内容：Issue 正文、Diff、文件、CI 检查结果 | “原文”“Diff 原文”“可见检查” |
| 机器建议 | 规则或模型基于事实得出的判断：分类、优先级、审查发现、改进草稿 | “AI 建议”“规则估计”“待人工核对”，常用虚线样式 |
| 维护者确认 | 你保存的最终判断和发布决定 | “维护者确认”“已确认”，常用实线样式 |
AI 结论在得到你的确认前不会改变项目状态。确认操作也不会覆盖原始的 AI 分析，两者会同时保留，方便事后回看。
已知、未知与“没有”
RepoCare 区分“确认没有”和“不知道”：
- CI 状态未读取或未返回，显示为 未知，不会当作通过。
- 评论数未知时，不按零计算；优先级未判断时，不按低优先级处理。
- 文件清单被截断时，没读到的文件“不能判定没有问题”。
- 体检中的 无法判断 表示证据不足，需要人工查看。
看到“未知”时，正确的做法是补充证据（刷新、读取文件与检查、补充信息），而不是把它当作好消息或坏消息。
任务与后台服务
耗时的工作以任务形式交给后台服务处理，离开页面不会中断：
| 后台服务 | 负责 |
|---|---|
| 体检 Worker | 项目体检 |
| 维护 Agent Worker | PR 分块审查、维护调查等模型任务 |
| 复现 Worker | Docker 隔离执行：Bug 复现、贡献路径验证、对照验证 |
任务有排队、运行中、完成、失败、已取消等状态。“完成”只表示任务结束，仍需查看覆盖范围和证据。服务离线时，新任务会排队等待，页面会提示“执行服务暂未在线”。部署方式见部署与运维。
草稿与交付
所有对外内容都先成为草稿：
| 草稿类型 | 来源 | 交付到 GitHub 后 |
|---|---|---|
| 文档改进 | 体检报告中的待完善项 | 在独立分支上创建 Draft PR |
| Issue 回复 | Issue 分诊结果 | 作为 Issue 评论发布 |
| PR 评论 | 你筛选后的 PR 审查发现 | 作为 COMMENT 类型的审阅发布 |
草稿可以编辑、比较差异、恢复历史版本、下载。发布需要 GitHub 写入权限和逐次确认；发布结果无法自动确认时，状态会停在“待核对”，而不会自动重试，以免重复发布。详见草稿与交付。
隔离执行
需要运行仓库代码时（复现 Bug、验证贡献路径、对比补丁），RepoCare 不在网页服务进程里执行，而是交给复现 Worker 在 Docker 容器中运行：
- 每次执行前先由你审阅计划中的命令、依赖和预期结果，确认后才会排队。
- 容器使用只读根文件系统、不授予额外 capabilities，并限制 CPU、内存和进程数。
- 验证阶段始终断网；只有管理员允许、且你审阅过的依赖准备阶段可以联网。
- 每个日志和制品都记录 SHA-256，下载时重新校验。
模型与费用
模型只在你主动发起时调用：开始 AI 分诊、开始 AI 审查、生成草稿、内容研判、维护调查、连接测试。浏览页面、读取文件与检查、保存设置都不调用模型。调用会产生服务商费用，用量以服务商返回为准；服务商没有返回费用时，不能视为免费。
项目与身份
工作区数据按“账户 + 当前项目”保存。匿名会话、邮箱账户和 GitHub 账户是不同的身份，数据不会自动合并；切换身份后看不到之前的记录，通常是进入了另一个身份的工作区。外观等偏好只保存在当前浏览器。