r002 · 迁移 operating model（决策模型）

轮次报告全文 · 逐字真源投影

本页是轮次报告的逐字投影（仅隐私清洗，零改写）。渲染不了的元素退化为代码块原文。

doc_type: migration_operating_model_decision
program: context_infra_migration_20260709
run: r002_20260710_final_solution
decision_status: solid
evidence_class: bounded_design_reasoning
selected_model: staged_managed_root_with_three_method_kernel
created_at: 2026-07-10

Migration Operating Model 决策

1. 目标决策

要决定的不是“下一批搬哪些文件”，而是一个能反复回答以下问题的 operating model：

• 某 Domain 一轮调查结束时，必须裁决什么？
• 裁决后如何只保留选定 priority 的具体可执行内容？
• 为什么固定 prompt 只填 DOMAIN 就能工作？
• 一个工具怎样从“被搬进新目录”升级到“在新环境中真实发挥作用”？
• 旧版本何时可以归档或删除？

2. Design-it-twice

方案 A：directory-first 全树波次

先冻结新根布局，再按目录或 W0-W5 批量 copy/move，最后统一修引用和接线。

优点：物理结果直观，短期能快速看到新树。缺点：目录不是能力边界；大量 built-but-not-consumed 内容会被原样搬过去；验证和回滚跨越太多对象；需要先知道全仓最终形态。它不能满足“每轮决策明确”“固定 Domain session”和“迁入后激活”。拒绝。

方案 B：governance-only managed set

不要求物理迁入；只要对象有 Signature、状态和 residual，就算 check-in。物理位置是可选结果。

优点：统一了仓内既存对象和外部对象，避免把 move 当能力。缺点：没有落实当前用户要求的新文件夹统一目标；一个对象可长期停在原地“已纳管”却仍不可见、不可消费。它适合作为语义底座，不足以作为本 migration campaign 的完成定义。拒绝为单独方案。

方案 C：staged managed root + 三方法共同 kernel（选定）

Check-in 同时要求进入受管状态、落到 staged target root、完成接线并由真实 consumer 验证；旧源在稳定前保留，稳定后才生成独立 check-out Action Unit。三种运行方法共用同一对象记录、priority projection、Action Card、context contract 和 evidence language。

选择理由：

1. 一个 kernel 同时满足信息收集、优先级、窄 session、物理迁入、激活、归档和长期治理，减少三套平行机制。
2. 新目录目标与渐进、可回滚要求兼容，不需要一次性猜出全树终态。
3. Domain 只是路由键，真正 session scope 由 selector 选出的 Action Unit 决定。
4. “先 check-in 并激活目标，再选择 check-out 源”切断了移动失败导致不可恢复的风险。

3. 最小共同模型

3.1 四个实体

一个 Object 只有一个 owner Domain，但可被多个 System 消费。System 状态由其依赖的 Object 状态生成；不维护第二份手写 system status。

3.2 五个正交轴

phase 是证明状态，不能代替 priority；priority 不能改变 destructive HUMAN_GATE；Domain 不能代替 Action Unit。

3.3 对象记录与投影

每个对象有一份权威记录；顶层 Harness、Domain、System 和 ready queue 都由它生成，不手工维护平行表：

object_id: MIG-DDP-001
domain: ddp_design_doc_protocol
systems: [requirement_to_implementation]
kind: protocol
owned:
  authority_intent: canonical_in_target_root
  disposition: CHECK_IN_CANONICALIZE
  priority: PRI-1
  target_location: "${TARGET_ROOT}/tools/ddp"
  desired_effect: "设计任务只消费一个 DDP 正典，并自动带 prompt provenance"
  effect_oracle: "真实设计任务从目标入口运行，产物可定位到唯一正典和 provenance"
  human_gates: [canonical_source_choice]
derived:
  lifecycle: {value: inventoried, recipe: migration_object_lifecycle_v1}
  readiness: {value: await_user, recipe: migration_readiness_v1}
  references: {value: [], recipe: reference_and_external_anchor_scan_v1}
  consumers: {value: [], recipe: runtime_and_static_consumer_scan_v1}
residuals:
  - residual_id: MIG-DDP-01
    state: open
    blocks: readiness
    anchor: canonical_source_choice
evidence: []

实现载体采用最少层次：

• campaign.yaml：只存 target root、当前 ACTIVE_PRIORITY、稳定窗口和已批准风险门。
• objects/<object_id>.yaml：对象 identity、owned 决策、derived recipe/value、residual 和 evidence 的唯一真源。
• generated/ready_queue.json、generated/domain_status.md、generated/system_status.md、generated/action_cards/*.yaml：全部由前两者生成，禁止手写。

不另造总 TODO。task-local residual 放在对象记录中，同时回链 requirement/meaning/design/implementation 行；全局 TODO 只保存跨 program 的调度指针。

4. 三种运行方法

三种方法的内部 kernel 都是：收集事实 → 独立检查 → 裁决/执行允许动作 → 效果验证 → 回写对象与 residual → 重算队列。

M1 — Domain Survey & Decision

输入：DOMAIN、Domain registry、对象记录、现有代码/文档/Git/Trace/runtime 接线。
允许动作：只读取证、创建或更新对象决策与 Action Cards；不改生产文件。
每个对象唯一 disposition：

• CHECK_IN_MOVE
• CHECK_IN_IMPORT
• CHECK_IN_CANONICALIZE
• CHECK_IN_IN_PLACE（仅过渡或明确例外）
• KEEP_GOVERNED
• CHECK_OUT_ARCHIVE
• CHECK_OUT_REMOVE
• DEFER_EVIDENCE
• AWAIT_USER

终态决策：每个对象的 disposition + readiness + priority + desired_effect + effect_oracle + rollback + residual；Domain 运行结果只能是 SURVEY_COMPLETE、NEEDS_MORE_CONTEXT 或 AWAIT_USER。

M2 — Check-in & Activate

输入：selector 返回的一个 READY check-in Action Unit。
事务：

1. fresh verify source/authority/consumers/references/target/human gates；
2. 建源快照与反向切换清单；
3. copy/stage 到 target root，先不签出源；
4. 建 canonical authority、registry、top-level use/when、routing 和 reference 接线；
5. 切换一个真实 consumer；
6. 跑真实任务；
7. 独立 verifier 只读客观产物判 desired effect；
8. 通过稳定窗口后标 ACTIVE，否则 rollback 或保留 STAGED residual。

终态决策：ACTIVE、STAGED、ROLLED_BACK 或 AWAIT_USER。文件已复制/移动只支持 STAGED，不支持 ACTIVE。

M3 — Check-out & Recover

输入：目标已 ACTIVE 或独立批准的 archive/remove Action Unit。
事务：确认 successor/archive class、live consumers 清零、引用处理、manifest/integrity/recovery package、destructive gate、延迟验证；再 supersede/archive/remove。
终态决策：SUPERSEDED、ARCHIVED、REMOVED、CHECKOUT_PENDING 或 ROLLED_BACK。

首次 check-in 和源 check-out 永不放在同一个 Action Unit；物理 move 实际由“目标 check-in → 稳定窗口 → 源 check-out”组成。

5. Priority 与只剩一个 slice 的机制

5.1 Priority 语义

泄露、安全或磁盘红线可把 cleanup 提升至 PRI-0/1，但必须写 promotion evidence；不能只因最近被讨论就升优先级。

5.2 Readiness filter 和同级排序

selector 只接受 readiness=READY。AWAIT_USER、EVIDENCE_GAP、DEPENDENCY_BLOCKED 留在 blocked projection，不阻塞同级其他 READY 项。

同级排序固定为：

dependency fan-out
→ blocked downstream count
→ activation value
→ higher reversibility
→ stable action_id

5.3 Active-priority 闭环

1. M1 产生跨 priority 的对象与 Action Units。
2. consolidator 选择最高的非空、可安全执行 priority，写入 campaign.yaml: ACTIVE_PRIORITY。
3. Domain prompt 只加载 DOMAIN + ACTIVE_PRIORITY + READY 的下一张 Action Card。
4. 每次运行重算五个视图：completed、active_ready、active_blocked、await_user、lower_priority。
5. session feed 只显示 active_ready；因此用户看到的正式处理内容只剩某个 priority 下的具体 Action Units。
6. 当 active_ready=0：
• 若同级仍有 blocking await_user，生成一次只含会改变路线的问题；
• 若只有显式 deferred/waived 项，关闭本 priority；
• 重算并晋级下一 priority。

6. 固定 Domain prompt contract

每种 method 有一份固定 prompt；调用时只改首行：

DOMAIN={{DOMAIN}}

其余输入由 prompt factory 自动注入：campaign、ACTIVE_PRIORITY、Domain registry、下一张 Action Card、对象记录、所需 rules/skills、read/may-read/forbidden-read、源与目标路径、验收 oracle、rollback、残差回写位置。

selector 规则：

next_ready_action(
  domain=DOMAIN,
  priority=campaign.ACTIVE_PRIORITY,
  method=current_prompt_method,
  order=dependency_topology_then_action_id
)

返回 0 张卡时，session 只能输出 NO_READY_ACTION 和 blocker projection；不得自行换 priority、method 或 Domain。返回多张卡时只取第一张；仅当它们同 Domain、同 root cause、同 effect oracle 且容量门通过，才允许生成一个小 cluster。

7. 当前具体 residual queue

初始 ACTIVE_PRIORITY 冻结为 PRI-0。这不是生产迁移授权，而是首个实现 slice：

PRI-1 预登记：File System archive/recovery 语义、DDP canonicalization + provenance、Task/Phase/Session/Dispatch 真实装配、Trace query/retention、fs_patrol review 消费链。第一个物理 check-in 在 FS preflight 通过后选 DDP canonicalization，因为可逆、已知三份现场且不要求先删除源。

PRI-2 预登记：新根最小 Harness 的 Git → TODO/DDP → runtime/trace → provider routing → orchestrator/dispatch → quality gate/final report → evolvable workflow 依赖链。

PRI-3 预登记：config/tests→tools 的接口迁移、CBE import、其余 14 域和域外 systems、top-level use/when 与结构图。

PRI-4 预登记：benchmarks、leaked files、历史产物、大对象/Git history、receipt/trace retention；风险证据可触发 promotion。

8. 现有能力的 reuse / adapt / missing / retire

9. 新机制四问与反过度工程化审计

1. 同时满足哪些需求：同一 kernel 满足 CUR-02..CUR-11，并承载 Signature、residual、priority、Domain prompt、激活、归档与系统投影。
2. 由哪些模块承担：migration_control 只拥有对象/投影/selector/prompt；现有 phase、dispatch、reference、eval、record 工具保持各自职责。
3. 是否可复用：kind extension 覆盖 tool/skill/protocol/project/automation/data/directory；相同 M1-M3 contract 对 14 域和域外系统成立。
4. 单 Unit 与长链是否都有效：Action Card 是单 Unit 接口；generated queue、residual 和 phase cursor 是长链交接接口。

删除测试：去掉独立 Action Unit，Domain prompt 会吞域；去掉 readiness filter，高优先级阻塞项会卡死队列；去掉 activation oracle，移动会冒充完成；去掉 generated projection，会出现第二份手写状态。四者均承重。其余角色名、旧波次编号和全能 orchestrator 均不进入最小模型。

10. 决策边界

本文件冻结 operating model、三种 method、priority 语义、初始 PRI-0 residual 和 staged check-in-first 顺序。它不证明这些新组件已经实现，也不授权生产 move/archive/delete。实施后仍须用真实 Domain run、负对照和独立 effect oracle提升 claim。

DECISION_MODEL_STATUS=solid