docs(plan): 第二份实施计划 —— ACT-WORK-05 活动重写(12 个任务)

spec 的 §3 数据模型 / §4 四步案例模型 / §6 三张件 / §7 判据 / §8 退役 / §9 测试 / §10 迁移次序。
自查时同步补了 spec §3.3 的 found_pn_ref —— 「在不在库」要是一次 lookup 的结果,不是一句断言,
计划的 S1 配方靠它,spec 是权威,不能两处不一致。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LKMZDwMbyKzjw6Hembwvet

docs/superpowers/specs/2026-08-29-act-work-05-rewrite-design.md

@@ -97,6 +97,7 @@ A–AE 发现表里,八条事故落在「本来就该是确定的」那几步上
 **`sub_eval.part` · 本单两颗料**,`kind: record`,`caseKey: eval_ref` —— 一单**恰两行**
 
 `eval_ref`(主键)· `internal_pn`(主键)· `role` 必填 tally `original`/`candidate` ·
+**`found_pn_ref`**(`refersTo parts.profile.internal_pn`,`requiredWhen exists_status = found`)·
 `exists_status` 必填 tally `found`/`absent` · `chip_type_id` integer **必填** · **`distinct: true`**
 (「两颗料是不是同一个类型」于是成了基座数得出来的数:不同取值恰好 1 种)
 
@@ -105,6 +106,8 @@ A–AE 发现表里,八条事故落在「本来就该是确定的」那几步上
 `eval_ref`(主键)· `chip_type_id`(本单锁定的类型)· `gate_reason`(入参未就绪的原因,件上摆的就是它)·
 `summary`(结论一句话)
 
+**`found_pn_ref` 是「在不在库」的依据**:判 `found` 就得拿得出一个基座查得到的料号,
+`refersTo` 让查无此值当场拒 —— 「在库」从此是一次 `lookup` 的结果,不是一句断言。
 `exists_status` 与两处 `chip_type_id` **每一拍由 `lookup` 重算** —— 人把料建好之后自己变 `found`,
 不设 `created` 档、不靠谁记账。