制作¶
职责¶
crafting 解析 recipe 知识、component/tool requirement、可访问 inventory、批量/时间计算、
选择、工作进度，以及 item 结果的制作或拆解；craft_command 记录已选择的执行计划。
入口点¶
从 src/crafting.h、src/crafting.cpp、src/craft_command.h 开始。角色访问位于
character_crafting.cpp，显示位于 crafting_gui.cpp，静态 recipe 契约位于 recipe
与 requirement loader。
数据所有权¶
注册表拥有 recipe/requirement。Character 和附近容器拥有来源 item，临时 crafting inventory 只是视图；进行中的 craft item 拥有选中 component 与继续工作所需进度。
依赖¶
crafting 依赖 recipe、requirement data、item location/pocket、skill、proficiency、 quality、map/vehicle inventory、activity、热量和时间。
生命周期¶
recipe 加载并 finalize；Character 构建可访问 inventory，检查知识/需求，选择 component， 启动 activity，推进工作，最后完成、取消或恢复制作。
不变量¶
选择满足准确 requirement alternative；被消耗 item 仍有有效 location；批量与进度单位 一致；完成不能重复消耗；resume 数据与 recipe/component 一致。
扩展点¶
recipe 与 requirement 用 JSON 增加。原生扩展应新增可复用 requirement/activity 规则， 而不是按 recipe ID 特判，并覆盖 UI 和非 UI 调用者。
序列化¶
craft_command 选择和进行中 craft data 在原生存档层序列化。保存 ID 与选中 component，
不要保存临时 inventory cache 或 UI filter。
测试¶
使用 crafting、requirements、temporary-inventory、uncraft、GUI、attention、proficiency 和 activity 测试，覆盖互斥选择及中断/恢复。
性能¶
recipe filter 会反复查询大型 inventory。复用有范围的 requirement cache，避免每显示 一条 recipe 都重建全地图 crafting inventory。
CCB 差异¶
即使 recipe ID 相同，CCB 的配方与制作行为也可能不同。移植必须加载 CCB 数据，并 验证 requirement、duration 和 resume 语义。
技术债务¶
需求求解、UI 选择与 activity 执行横跨多层。应保持契约显式，不能让 UI 状态成为执行 权威。