brownfield-adopter

Skill: Brownfield Adopter（存量项目逆向建基线）

显式可选的存量项目 eager seed 加速器：用户或宿主明确要求预扫全库时，由 AI 会话/driver 逆向扫描可验证代码事实，经 openlogos baseline-seed 两阶段事务落盘。它不是 openlogos adopt 后的默认下一步，不决定项目能否创建 change；完全跳过本 Skill 时，change-writer 仍按 S39 在每次变更中补齐触达场景的正式规格。

触发条件

• 用户明确要求「建立现状 seed」「预扫全库」「运行 baseline-seed」；或宿主明确选择 eager seed 作为扫描优化。
• 用户对安全的 open run / 未提交 staging 明确要求续做或重扫。
• 不得触发：仅因 openlogos adopt 完成、baseline_seed_state: required|partial、next/status 展示 seed 状态而自动派发。三态均不构成 change/plan/delta/merge/verify 前置。

前置依赖

1. logos/logos.config.json 存在，目标模块可解析；通常为 bootstrap: adopted，但显式重扫不以 bootstrap 值替代用户意图。
2. 具备用户/driver 授权的代码库读取能力。
3. CLI 支持 openlogos baseline-seed begin|commit|status。
4. 任一资源/索引读取前，先在模块锁内检查并恢复未终结 commit journal；无法恢复立即报 baseline_commit_in_progress，不得开始扫描或读取半新 resources。

核心原则（不可违反）

1. 只写可从代码忠实验证的事实：system-map（模块图/入口/依赖）+ 场景候选清单；绝不写 PRD/历史 Why。
2. verified:false 冻结：不存在确认升级、verified:true、confirmed_*、JIT advisory 或 baseline warning。
3. 只写 run 私有 staging：不得直接改 logos-project.yaml 或目标 logos/resources/；唯一提交者是 baseline-seed CLI。
4. 能力缺失不伪造且不阻断 change：显式 seed 失败可重试；用户仍可直接创建 change。
5. 安全 partial 与未终结事务分流：open run/未提交 staging 可排除后继续；prepared|committing journal 必须恢复，失败是硬操作错误，不能降级为“seed 证据不可用”。
6. 存量代码 grandfather 边界不变：seed 是未确认事实快照，方法论硬门只约束新意图；候选按 active/tombstone/alias 维护。

执行步骤

Step 1: 确认显式意图与恢复门

确认当前请求确实要求 eager seed，而非普通 adopt→change。随后在项目根调用 seed status/恢复入口；读取目标、索引或 coverage 必须位于「取模块锁 → 检查/恢复 journal → 读取」同一锁区间。若返回 baseline_commit_in_progress，停止本 Skill，不得以代码重扫绕过可能半新的标准 resources。

Step 2: 逆向扫描并规划逻辑 manifest

仅在恢复门通过后扫描代码库，规划无内容 hash 的逻辑产物计划；必需 kind 至少含 system-map 与 scenario-candidates：

{
  "module": "core",
  "expected": [
    { "kind": "system-map", "target_path": "logos/resources/prd/3-technical-plan/1-architecture/core-system-map.md", "candidate_keys": ["core::<hash>"] },
    { "kind": "scenario-candidates", "target_path": "logos/resources/prd/3-technical-plan/2-scenario-implementation/core-scenario-candidates.md", "candidate_keys": ["core::<hash>"] }
  ]
}