feat: Feature Recovery Pack，在 compact/接管时自动恢复编排现场

## 使用场景 / Use case

在 Cindy 的 Lead + Orca Worker 长任务中，一个 Feature 往往跨越多个 Task、PR、Watcher 事件和 Worker session。Lead 对话自动 compact、重新打开会话或更换 Lead 后，需要快速、可靠地恢复当前现场，而不是让用户重新解释，或重新阅读整段聊天。

典型恢复信息：

- 当前 Feature 目标；
- Task 依赖链；
- 已完成、正在执行、等待中的唯一 Task；
- 当前 Worker/session 及真实运行状态；
- 当前 blocker 与恢复条件；
- 最新有效裁决和证据链接；
- 禁止事项；
- 下一步唯一动作及 owner。

## 当前问题 / Current limitation

现在的 compact、聊天摘要和 Memory 更适合保存语义信息，不足以恢复编排现场：

1. 状态散落在 GitHub Issue/PR、Orca 名册、Watcher 事件和聊天里。
2. 普通模型摘要可能保留已经过期的 BLOCKED、遗漏已合入 PR，或把 Worker 自报当成系统事实。
3. Lead 压缩后容易重复派工、串 Feature、重新盘点，用户也需要重复提醒约束。
4. 长期规则可以放在 Memory/项目文件，但“当前正在做什么”是易变化状态，不适合当永久记忆维护。
5. 单纯加长 compact 摘要会继续消耗上下文，也无法解决多来源冲突。

## 期望方案 / Proposed solution

增加 **Feature Recovery Pack / Feature 恢复包**：由 Cindy Host 从外部权威状态机械派生一份短、可验证、可丢弃重建的恢复包，在自动 compact 后、新 Lead/新会话接管 Feature 时自动注入。

建议 MVP 先只支持 `GitHub Feature → Task/PR + Orca Worker + Watcher`，不抽象成新的通用项目管理平台。

### 建议结构

```yaml
schema: cindy-feature-recovery-pack/v1
feature:
issue: 1591
objective: <用户目标>

task_chain:
done: [1900, 1903]
running: [1904]
waiting: [1905, 1906]

current_task:
issue: 1904
worker: i1904
session_id:
runtime_status: running
latest_evidence_url:

blocker:
state: none | blocked | conflict
reason:
evidence_url:
recovery_condition:

latest_decisions:
- summary:
source_url:

prohibitions:
-

next_action:
owner: i1904
action:

generated_at:
source_revisions:
github_updated_at:
orca_roster_revision:
watcher_delivery_id:
```

### 数据和信任规则

- Recovery Pack 是**派生缓存，不是新的事实源**；随时可以从 GitHub、Orca、Watcher 重建。
- 每个易变字段必须带来源、时间或 revision，不能只保存模型文字。
- 建议事实优先级：宿主/Watcher 可观察事实与 Git 状态 > GitHub Issue/PR 权威状态 > Orca Worker 自报 > 聊天摘要。
- 来源冲突时输出 `conflict` 和冲突来源，不允许模型自行选择一个答案。
- 普通 Worker 进度、重复 DONE、待命消息不能进入恢复包；只消费有效状态跃迁、正式裁决和证据链接。
- Recovery Pack 建议控制在 500–1000 tokens；详细内容保留在来源链接。
- 用户最新明确指令优先于恢复包；恢复包应显示生成时间，避免被误认为实时事实。

### 触发点

- 自动或手动 compact 完成后；
- 新 Lead/session 接管已有 Feature 时；
- 用户手动点击“刷新恢复包”；
- 可选：Feature 发生有效状态跃迁时后台更新缓存，但无需把每次变化都注入当前上下文。

### MVP 验收标准

1. 给定一个含 3 个以上 Task、至少一个 Orca Worker 和 PR/Watcher 事件的 Feature，可稳定生成结构化恢复包。
2. Compact 或新会话后，Lead 无需读取旧聊天，即可说出当前目标、唯一执行 Task、blocker、禁止事项和下一步。
3. 已合入 PR、已关闭 Task、异常终止 Worker不会被恢复为“仍在执行”。
4. 制造 Issue、Watcher、Orca 状态冲突时，恢复包输出 `conflict`，不会静默猜测。
5. 同一来源 revision 下重复生成结果稳定、可去重。
6. 生成失败不阻止会话启动；明确提示恢复包不可用，并保留手动刷新入口。
7. 可以查看每个字段的来源链接或来源标识，方便用户核验。

### 非目标 / Non-goals

- 不取代 GitHub Issue、PR、Orca 或 Watcher。
- 不把整段聊天重新摘要一遍。
- 不自动修改 Issue/PR 状态。
- MVP 不支持任意 Jira/Linear/自定义工作流。
- 不把 Recovery Pack 写成需要用户手工维护的另一份台账。

## 已考虑的替代方案 / Alternatives considered

1. **只优化 compact prompt**：实现最简单，但依赖模型从聊天猜当前状态，容易保存过期或冲突事实。
2. **只依赖 Memory/AGENTS.md**：适合长期规则和偏好，不适合高频变化的 Feature 运行状态。
3. **每次新会话重新扫描全部 Issue/PR/Worker**：正确但慢、费 token，且每次都重复做相同编排工作。
4. **维护一份人工状态文件**：会产生新的可漂移事实源，增加用户和 Lead 的维护成本。

推荐方案是：Host 机械生成短恢复包，模型只消费；权威状态仍留在现有系统中。

Start by locating the existing compact flow, Lead/session handoff entry points, and integrations for GitHub, Orca Worker state, and Watcher events; the issue does not name files or tests. Define the MVP around mechanically deriving the specified recovery-pack fields, conflict handling, source revisions, and refresh triggers. Done means the listed acceptance scenarios pass without blocking session startup or replacing the existing sources of truth.

Written by the indexing model from the issue text.