XiaChangSong/BPOS-TMP-REPO
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
349 Commits 1 Branch 0 Tags
fdcd1f88a702873c9b6fd99be80ceead252eaf1a
Commit Graph
7 Commits
Author SHA1 Message Date
xcsandClaude Opus 5 fdcd1f88a7 docs(w05): 立 Task 7b —— 「新建芯片类型」是 spec 与用户都点名的能力,不能只活在一条顾虑里 
Task 7 交付的件让人从下拉挑已有类型(主路通),但 spec :37 / :261 与用户原话都
明写还要能「新建一个类型 + 它的核心参数字段」。这一半没做。

做不了的原因已核实属实:ViewContainer.addRow 靠克隆最后一行,零行时返回 false,
而 mine:parts.chip_type 每单开局零行。顺带发现平台自相矛盾 —— desk.ts:843 那条
空表闸在教人「先在件上加一行」,而 UI 做不到。

三条候选路各记了代价:①件上摆字面量空白行(零平台改动,但复合主键的跨行自增键
联动待查)②平台补原型行(小改,但动两个共享面要全量回归)③配方种骨架(已否:
人改挑已有类型时那行空骨架会一直卡着闸)。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LKMZDwMbyKzjw6Hembwvet
 2026-08-29 18:38:20 +08:00
xcsandClaude Opus 5 cd88d0e026 docs(w05): Task 11 的共享库处置按用户已给的授权定死 —— 走第①条 
用户已定「走查期间先停掉稳定版」,不必让执行者再停在一个已有答案的问题上。
同时写明:停稳定版是控制端的事(本工作树之外的副作用),执行者只负责确认
:8790 没有监听;还在监听就报上来,不自己动手也不绕过去装。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LKMZDwMbyKzjw6Hembwvet
 2026-08-29 16:21:29 +08:00
xcsandClaude Opus 5 8c125042ba docs(w05): Task 10 的 Step 3/4 跟上 Step 2 —— 摘注册而非标停用,git add 补齐四个文件 
上一笔改了 Step 2 的退役方式(本仓工具没有 enabled 概念),Step 3 还写着
「把注册标成停用」、Step 4 的 git add 也没带上新列进 Files 的四个文件 ——
自己改出来的内部矛盾,一并补齐。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LKMZDwMbyKzjw6Hembwvet
 2026-08-29 16:20:49 +08:00
xcsandClaude Opus 5 89f0be8b81 docs(w05): Task 10 修计划缺陷 —— 退役清单漏四个文件,断言写在不存在的字段上 
Files 清单漏了 container.ts(容器里那行 handler 覆盖)、tools-w05.ts(两枚工具的
契约定义整份)、seed-activities.ts 与 seed-mvp.ts(它的两个消费方)。只改点名的
五个文件,工具会在一处退役、在另几处照常注册。

Step 2 的断言 registry.find(t => t.name...).enabled 三处都不成立:该文件里没有
registry;FIRST_PARTY_TOOLS 是 [name, handler] 元组数组,元素上没有 .name,取它
得 undefined 再 .includes() 当场抛;本仓工具也没有 enabled 这个概念。改成断言
「不在注册表里」,同样拦得住手滑重新注册。

Step 1 的预期由「零命中」改成实测的那几处,并写明冒出清单之外的命中要停下来报。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LKMZDwMbyKzjw6Hembwvet
 2026-08-29 16:15:10 +08:00
xcsandClaude Opus 5 18d7147ebd docs(w05): S1 配方次序改对 —— 案卷排到骨架两笔之后 
gate_reason 引的 parts_profile_missing / parts_parameter_missing 要等
②③ 把骨架行铺出来才有值。排在前面时引擎给它读到 0,卡照样正确发出,
但卡上那句「还差什么」是空白的 —— 恰在人最想要一句解释的时候。

计划与 spec 两处都写着旧次序,不改则下游任务照抄同一个错。
S2/S3/S4 已核,次序都对(投影在前、读它的排在后),病只在 S1 一处。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LKMZDwMbyKzjw6Hembwvet
 2026-08-29 15:21:15 +08:00
xcsandClaude Opus 5 94b664bc85 docs(plan): 发车前扫描三条裁定入计划(帮手真名 / found_pn_ref 去重 / assets 处置前移) 
G2:Task 1 的测试帮手名是我猜的,已查实(MASTER_OBJECTS / MASTER_SAMPLE_ROWS)—— 直接写对。
G1:spec §3.3 已补 found_pn_ref,Task 2 照 spec 写就有了,Task 4 那一步改成「确认在,不在才补」。
G3:assets(dmn / skills / viewTemplates / distillHooks)的处置前移到 Task 2 ——
    不然 Task 2 到 Task 9 之间清单引着已经不存在的东西,包是不自洽的。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LKMZDwMbyKzjw6Hembwvet
 2026-08-29 11:28:57 +08:00
xcsandClaude Opus 5 65a4c7a7dd 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
 2026-08-29 11:15:17 +08:00