Jin Yong's Dream

WASM 修复摘要（迁移自 meta.json 的 group_note）

完成了一次中断的转档（多个档案，包括 master.lpc，残留有 static 关键字）；用 read_file+explode+slice 重新实现了 efun::tail()（§6.2）；启动干净。完整 WASM 修复：给 band.lpc 加了本地回环放行；修复了 logind.lpc（create()/make_body()/howmany_user() 都改成 seteuid(ROOT_UID)）里同样的 seteuid(getuid()) 把 euid 重置掉的 bug；修复了 check_legal_name() 过时的 GBK 字节长度界限，去掉了一个毫无意义的 name[j]+=128 变异操作（旧版 GBK 高位字节假设的遗留代码）；给 adm/daemons/securityd.lpc 的 get_status() 加上了防止 wiz_status/wiz_levels 尚未初始化时重入编译崩溃的保护。发现了两个新 bug：cmds/usr/quit.lpc 呼叫 environment(me)->query(...) 没做保护，玩家在环境为空时退出游戏就会崩溃报"*Bad argument 1 to call_other()"（已给全部三处呼叫点加上保护）；adm/simul_efun/message.lpc 的 tell_room(ob,str,exclude) 包装函式把省略的可变参数 exclude 直接以裸整数 0 传给 message() 的第 4 个参数，而不是空数组——导致游戏里第一次 tell_room() 呼叫（欢迎室自己的 create()）就崩溃，这是已收录进 AGENTS.md §7.12 的共享包装函式 bug，已用文档记载的 exclude || ({}) 写法修复。管理员账号播种进了 data/securityd.o 的 wiz_status 映射（这里是 CRLF 配对编码，不是 hy/hy5 那条血统里的纯 CR 逐键编码——出于保险仍用二进制模式编辑）。注册流程到进入游戏世界、look/score/quit、管理员权限识别都干净验证过，没有残留的横幅计时问题。

深度功能测试（第二轮，2026-08-03）

此前的验证只做到"注册→look/score/quit→管理员权限识别"的浅层冒烟测 试。本轮在 boot 之前先主动检查了本次会话已经在 hell/zsdsj 上反 复确认过的两类高价值 bug 模式，直接在源码里发现并提前修复了一处， 随后完整走通了注册、门派加入、quit 全流程。

主动排查发现并修复：feature/command.lpc 的 private command_hook

feature/command.lpc（inherit/char/char.lpc 通过 F_COMMAND 继 承，是真正生效的玩家指令分发中枢）把 command_hook 声明为 private nomask int command_hook(string arg)。这是 AGENTS.md §8.3a 已经记录多次的经典模式：这个驱动上 private 一旦被继承就会降级为 DECL_HIDDEN，导致 add_action("command_hook", "", 1) 这种"捕获全 部指令"的注册方式对 ORIGIN_EFUN（其它物件透过 command() efun 发起的呼叫，比如 NPC 自己说话）静默失效。已去掉 private，保留 nomask，和已确立的标准修法一致。

另有一份 feature/command2.lpc 也带有完全相同的 private nomask command_hook 声明，但确认它是死代码——全代码库里唯一提到 "command2" 的地方是 log/static/editfile.lpc（这不是真正的 LPC 源 码，是一份历史巫师编辑记录日志，纯文本"某巫师在某时间编辑了某文件" 的流水账，文件名后缀 .lpc 是历史遗留的误用），没有任何 inherit 真正引用 feature/command2.lpc——保持原样未做改动，符合"死代码备 份保持原样"的既有惯例。

完整验证：从注册到加入门派

用全新账号在原生驱动上完整走通：GB 编码（默认）→ 英文 id（3-8 个 英文字母，注意上限只有 8 个字符，比很多同类档案的 10-12 上限更 严）→ y 确认建立 → 中文名字（1-4 个汉字）→ 使用密码 + 确认 → 保 密密码（至少 10 位，与使用密码是完全独立的第二套密码，专门用于 密码找回）+ 确认 → 天赋选择（0-4，0 为系统随机，随机结果需要 y/n 二次确认，不满意可以重新摇）→ 电子邮件 → 性别 → 进入"新手的殿堂"。

一进入新手殿堂就有 [1;33m金庸[37;0m（作者本人被拟人化成一个 NPC！） 主动搭话："欢迎光临本ＭＵＤ，本人现在将助你一臂之力"，并列出全部 12 个可加入的门派：丐帮、全真教、武当派、华山派、密宗、星宿派、 白驼山庄、桃花岛、少林派、峨眉派、大理段氏、灵鹫宫——同样是把金庸 小说宇宙里跨多部作品的门派体系（射雕/神雕的全真教丐帮、天龙八部的 星宿派大理段氏灵鹫宫白驼山庄、笑傲江湖的华山派、倚天屠龙记的少林 武当峨眉）揉进同一个游戏世界。join wudang 立即成功，触发一条全服 公共频道广播"在下承蒙金庸先生帮助，现已加入武当派！"，金庸 NPC 确 认"现在我已经给你帮助了"，"身体更新完毕"——这一整条 NPC 对话+全服 广播链路，正是 command_hook bug 最容易静默破坏的那一类 command()-efun 自呼叫路径，本轮完整验证无异常，间接印证了上面那 处修复的必要性。score 显示完整角色面板（膂力/悟性/根骨/身法四项 天赋、精/气/食物/饮水四条状态槽全部正确显示，饮水槽满格，没有类似 zsdsj 那种初始化缺失的问题）。quit 正常触发"开始退出游戏，进行 中..."流程。debug.log 除了驱动自身的启动期诊断信息（找不到旧版二 进制、反向地址解析被拒绝，均为环境噪音，不影响功能）外没有任何来自 本次实际游玩会话的运行时错误。

未覆盖范围（诚实说明）

预算集中在验证 command_hook 修复的必要性和门派加入这条最容易受 影响的 NPC 对话链路，没有走到：门派内部技能学习、战斗、经济系统。 这些留给下一轮，目前的验证边界如上所述。

§7.86 跨库扫描修复（留言板 post 崩溃）

• BULLETIN_BOARD inherit + 多余 replace_program() 致命形状（AGENTS.md §7.86，post 命令崩溃）：全档案 44 处命中，已删除多余的 replace_program(...) 调用（保留 inherit），逐文件保留原有行尾格式（CRLF/LF 按文件原样）。本次为跨库 §7.86 扫描修复（触发原因：该 bug 已在 6+ 个互不相关的血统家族独立确认，属于近乎普遍的拷贝粘贴模式），仅做编译检查（驱动干净启动、端口正常监听），未做完整 §10.7 深度游玩测试。

Round three deep functional test（2026-08-18）

本轮预算集中在第二轮明确留白的范围：门派内技能/经济/留言板/死亡复活， 并主动排查了当天新收录的两类 bug 模式（AGENTS.md §7.111、§7.112）。

§7.111（master.lpc 的 standard_trace() 无条件呼叫 file_name()）：不适用

本档案真正生效的 master 是 adm/single/master/master.lpc（config.fluffos 的 master file 指向这里，adm/single/master.lpc 是未使用的旁支）。 它的 standard_trace() 用 %O 格式化 error["object"]，不是无条件 file_name()，%O 对 0/非物件值都是安全的。确认不受影响，未改动。

§7.112（NPC init() 无守卫地排 call_out() 链，重连会叠加第二条链）：命中并修复

d/death/npc/wgargoyle.lpc、wgargoyle1.lpc、bgargoyle.lpc（鬼门关/ 酆都城门的白无常、黑无常）三个死亡引导 NPC 的 init() 都是这个形状： if (!previous_object() || !userp(...) || wizardp(...)) return; call_out("death_stage", 30, previous_object(), 0); ——没有任何防止玩家重连时 init() 被驱动重新广播、从而叠加第二条独立 death_stage 链的守卫。三个文件都按文档记载的修法加了 previous_object()->query_temp("death_stage_active") 守卫（init() 里排 call_out 前检查+置位），并在 death_stage() 的每个出口 （含 bgargoyle 特有的"阳人闯阴间被赶出"分支）用 delete_temp("death_stage_active") 清除。

现场验证（用 eval 直接检查 call_out_info()）：admin 把测试号 summon 进鬼门关，白无常 init() 触发，call_out_info() 只有一条 death_stage 记录（守卫已置位）；随后让该测试号断线重连（触发 enable_commands() 重新广播 init()），再查 call_out_info()—— 仍然只有一条链在推进，没有叠加第二条。链走完后守卫标志正确清零 （query_temp 归零），玩家被移到 /d/city/wumiao（REVIVE_ROOM） 恰好一次，全程 debug.log 无报错。

主动排查发现并修复两处严重程序缺陷（非目录里的两类模式，是本库独有）

1. adm/daemons/logind.lpc 的 enter_world() 里 ob->save() 被注 释掉（第 907 行，原文 // ob->save();）——新角色完成注册 后，登入身份物件（data/login/<首字母>/<id>.o，含密码/保密密码/ email/registered 等字段）从未被存盘，除非玩家恰好从设了 valid_startroom 的房间正常 quit（会走 cmds/usr/quit.lpc 里 link_ob->save() 的立即存盘分支），或者等到 autosaved.lpc 的 8~108 分钟一轮的心跳存盘赶上。新手殿堂（d/welcome/welcome.lpc） 本身没设 valid_startroom（该行被注释掉了），所以任何在离开新手 殿堂之前断线/退出的新号，登入身份永久丢失——下次再用同一个 id 登入，系统会误判"账号不存在"，提示重新创建新角色（角色本体 data/user/... 即使侥幸存在也对不上）。这也解释了为什么本库此前 两轮播种的 fluffos 管理员账号在本轮开始时已经完全消失（data/ login/f/ 和 data/user/f/ 都没有档案，只剩 securityd.o 里的 wiz_status 授权记录）。修法：去掉注释，让 ob->save() 在 enter_world() 里无条件执行（新号和回头客都会跑到这一行，无害）。 现场验证：修复前，全新注册号在没跳出新手殿堂时 quit 后无法用原密 码重新登入（提示创建新号）；修复后，同样流程的全新注册号可以立 刻正常重连（提示"你距上次退出仅N秒，请稍后再登陆"的防刷屏节流， 证明账号被正确识别）。已按 AGENTS.md §1.5 惯例用标准凭证 fluffos/Mud@2026 重新走完整注册流程播种管理员账号（data/ login/f/fluffos.o、data/user/f/fluffos.o 都已就位，wiz_status 授权原本就还在），此账号文件已提交。

2. include/globals.h（驱动 global include file 自动包含给所有 源文件的全域头）缺少 EDITOR_D 宏定义——inherit/misc/bboard.lpc （BULLETIN_BOARD 的实现，被所有留言板 clone 继承）第 304 行用到 EDITOR_D->get_file_num(...)，但这个宏只在另一个不会被自动包含 的旁支头文件 inherit/misc/globals.h 里定义过，导致 bboard.lpc 编译失败（Error: Undefined variable 'EDITOR_D'）。后果两层：(a) 任何驻留留言板 clone（如客店的 kedian_b）的房间，第一次在某次 驱动会话里被访问、触发房间 create() 尝试 clone 留言板对象时，会 因为 clone 物件"没有程式"而抛出未捕获运行时错误，导致移动指令 （如新手殿堂的 down）整体中断——当事玩家会卡在原地，只看到"你 发现事情不大对了"的模糊提示，摸不着头脑（第二个及以后访问同一房 间的玩家不受影响，因为房间物件已经在内存里创建过一次，不会重新 触发）；(b) 全档案所有留言板永久性地没有实际留言板物件可用， list/post/read 全部静默失效——客店留言板还原后一次性找回了 189 条 2007 年的历史留言（此前完全无法访问）。修法：在 include/globals.h 里按字母序补上 #define EDITOR_D "/adm/daemons/editord"（与 inherit/misc/ globals.h 里的定义完全一致，/adm/daemons/editord.lpc 本来就存 在）。现场验证：修复前，全新驱动会话里第一个走 down 的号必然 触发上述崩溃；修复后，同样全新驱动会话里第一个走 down 的号顺利 进客店，list 能看到 189 条历史留言。

其余深度测试

join wudang 门派加入本轮再次复核无误（与第二轮一致）。留言板 list/post 流程在客店验证可用（list 走分页，ENTER/q/b 翻页； 未继续测 post/discard 全流程，范围已覆盖到功能修复所需的最低验证）。 死亡复活链路（白无常/黑无常引导流程）已在上面 §7.112 段落里连同守 卫修复一起验证。经济系统（铁匠铺等商店 list/buy）、门派内技能学 习/PK 战斗仍未覆盖，留给下一轮。

潜在跨库线索（未在本库外验证，仅标记）

logind.lpc 里 enter_world() 缺失 ob->save() 这个具体行号可能是 本库独有的历史误删，但"新号未经由 valid_startroom 房间正常退出就 会丢失登入凭证"这类问题的排查方法（检查 enter_world/等价函式 里是否存在被注释掉的登入物件 save() 调用）值得在其它库round-three 测试中留意，尤其是那些新手初始房间没设 valid_startroom 的血统。

§7.100 修复（ROOM 基类的同一"多余 replace_program()"形状，全档案扫描第 6 批）

• 删除 work/ 下 2,661 处存活的 standalone replace_program(ROOM); 行 （脚本删除），另外手工修复 clone/misc/roommaker.lpc 建房工具代码 生成模板里的同形状变体，共 2,662 处，与普查记录一致。
• 验证：真实 build-debug 驱动干净开机、端口正常监听，debug.log 中 零 "cannot replace"/"cannot bind" 行。

Round four deep functional test（2026-08-19）

本轮专门补完第三轮明确留白的三大系统：战斗、门派内技能学习、经济系 统（铁匠铺 list/buy）。全程用真实 build-debug 驱动 + 全新注册测试 号（rfourjym）+ admin（fluffos）双连线协同测试（goto/summon/ eval 辅助定位与状态调整），驱动全程干净，debug.log 除编译期警告 外零运行时错误。三项全部验证通过，没有发现任何真实程序 bug。

1. 战斗：通过

在武当柏林用新号空手攻击「野兔」（d/wudang/npc/yetu.lpc），完整走 完多回合攻防：命中/招架/闪避描述随机切换，野兔的状态提示逐步升级 （"力不从心" → "半昏迷" → 摔倒 → 死亡），死亡触发 die() 正确清除 物件并生成"兔肉"战利品，全程无崩溃、无 debug.log 报错。

2. 门派内技能学习：通过

已知加入武当派（join wudang）的角色，其 family/master_id 是欢迎 室里"金庸"NPC（d/welcome/npc/shizhe.lpc）自己，而这个 NPC 没有设 置任何 set_skill()，所以理论上无法直接向他 learn。真正的门派内 授业 NPC 是 kungfu/class/wudang/*.lpc 这批角色（通过 CLASS_D 宏放置在 d/wudang/sanqingdian.lpc 等房间里，例如宋远桥、谷虚道 长、张三丰），都用 bai <NPC> 拜师、ob->attempt_apprentice() 里 按 taiji-shengong 内功等级 + shen（声望）双重门槛决定是否收徒， 门槛因人而异（宋远桥最低：taiji-shengong>=60 且 shen>=35000）。

刚 join wudang 的新号 shen 只有 30000，天然差 5000 达不到宋远桥 门槛——这是内容/设计门槛，不是 bug，符合本项目已反复确认的"声 望/等级门槛拒绝求教"模式。为了验证 bai/recruit_apprentice/ learn/is_apprentice_of 这条机制本身是否work，用 admin eval 把测试号的 shen 临时提到 40000（纯粹测试用途的状态调整，不是代码 修复）。之后：

• bai song → 宋远桥 attempt_apprentice() 检查通过 → 自动 command("recruit "+id) → 你跪了下来向宋远桥恭恭敬敬地磕了四个 响头，叫道：「师父！」恭喜您成为武当派的第三代弟子。（family 正确更新为 master_id=宋远桥、generation=3）
• learn song sword 3 → 你向宋远桥请教有关「基本剑法」的疑问。你 听了宋远桥的指导，似乎有些心得。 → skills 确认 sword 技能的 进度值从 62/0 变为 62/73（尚未跳级，但确认经验值真实累积）。

途中还观察到 bai 指令本身有一个符合设计的行为、不是 bug：对 同一 NPC 连续 bai 两次，第二次会命中"你想拜XX为师，但是对方还没 有答应"的 pending 分支而不重新触发 attempt_apprentice()——必须先 bai cancel 清掉 pending 状态才能让门槛检查重新跑一次。这解释了本 轮测试过程中第一次 boost shen 后立刻重试 bai song 依然被拒的现 象（当时 pending 状态还压着上一次失败的请求）。机制本身完全正常。

3. 经济系统：通过

• 大理铁器铺（d/dali/smithshop.lpc，NPC 南彝商人 d/dali/npc/ironsmith.lpc）：list 正确列出菜刀/铁锤及价格； buy hammer 扣款 150 文（50 两白银 → 48 两白银 + 50 文铜钱），角 色背包正确收到铁锤。该 NPC 只注册了 buy/list 两个 add_action （没有 sell），sell pao 返回"什么？"——这是本项目已反复确认 的"只收不卖"NPC 设计模式，不是 bug，遵照本轮任务说明未做任何改 动。
• 京城打铁铺（d/city/datiepu.lpc，NPC 王铁匠 d/city/npc/tiejiang.lpc）：确认这个 NPC 额外注册了 do_sell/sell（feature/dealer.lpc 标准商人混入），把刚买的 铁锤 sell hammer 成功卖出，你卖掉了一把铁锤给王铁匠。，钱包正 确增加，物品正确移出背包。买卖两条路径均验证通过、无报错。

inherit/room/hockshop.lpc（当铺基类）在全档案里没有任何房间 inherit 它——是完全未使用的死代码，本档案没有可达的当铺型 NPC， 符合"未使用旁支保持原样"的既有惯例。

标准 bug 清单快速复核（全部干净，无异常）

• §7.90（eval cost）：config.fluffos 的 maximum evaluation cost 已是 5000000，符合此前扫描修复记录。
• §7.100（ROOM 冗余 replace_program()）：全档案仅剩 9 处， 全部是已被注释掉的死代码残留（// replace_program(ROOM);），无 一处存活，符合第 6 批扫描"完全清除"的记录。
• §7.111（master.lpc standard_trace()）：本库真正生效的 master 用 %O 格式化 error["object"]，本就安全，不受影响（与 round-three 记录一致）。
• §7.112（NPC init() 重连叠加 call_out 链）：wgargoyle.lpc /wgargoyle1.lpc/bgargoyle.lpc 的 death_stage_active 守卫仍 然完整在位，未被回退。
• §7.113（netdead 重连不恢复 heart_beat）：LOGIN_D （adm/daemons/logind.lpc）的 reconnect() 无条件呼叫 user->reconnect()；clone/user/user.lpc::reconnect() 无条件 set_heart_beat(1)——正确血统，不受影响。
• §7.114（private input_to() 回调经 mixin 失效）： feature/edit.lpc（F_EDIT）里的 input_line() 根本没有 private 修饰，全档案 grep 也找不到任何 private ... input_line 形状——不受影响。
• §7.115（QUEST 宏指向不存在的档案）：本库 include/globals.h /globals2.h 都没有定义 QUEST 宏，cmds/std/give.lpc/ ask.lpc 也完全不引用它——不适用。
• §7.79（裸 2 参数 addn/addn_temp）：全档案 grep addn(/addn_temp( 零命中——本库不存在这个形状，不是新发现。

清理

测试号 rfourjym 的存档（data/login/r/rfourjym.o、 data/user/r/rfourjym.o）已在测试结束后删除，不作为常驻测试凭证保 留。驱动进程按精确 PID kill，未使用模式匹配。work/tmp/（eval 指令写临时文件用的目录，本档案原先没有这个目录）予以保留，纯粹是 运行时基础设施，不含任何游戏状态。

§7.30 uninitialized-mapping accessor sweep (2026-08-20)

Corpus-wide mechanical sweep of the feature/skill.lpc shared-lineage bug (confirmed independently on xiakexing2017/jqxz2015/haiyang2 via round-four testing): 4 accessor(s) in this file returned a raw never-initialized mapping instance variable (defaults to int 0, not ([]), until first assigned), crashing any unguarded keys()/sizeof()/indexing caller for a fresh/untrained character. Fixed at the accessor level (mapp(x) ? x : ([])) per the documented remedy. Verified via lpcc --batch static compile check only (not a live boot) as part of a large mechanical sweep; not individually functionally re-tested live on this lib.

PK 战斗深度测试（2026-08-24）

本轮任务原本列出商店购买/门派内技能学习/PK 战斗三项为"从未测试"， 但复核第四轮记录（见上）后发现前两项其实已经在 round-four （2026-08-19）里完整验证通过（大理铁器铺/京城打铁铺 list/buy/ sell，宋远桥收徒+learn）——本轮不再重复，预算全部集中在真正 的空白：玩家对玩家（PK）战斗。

用真实 build-debug 驱动 + admin（fluffos）+ 全新注册测试号 （pktesty，注册流程改用 raw Python socket 而非 scripts/tmux_mud.sh，因为中文名字节里偶尔含 0xFF，被 telnet 客户端当成 IAC 转义序列吞掉，导致会话意外落入 telnet 本地命令模式 ——这正是任务说明里提到的已知 tmux 伪影，此次确认属实，用 python socket 全程 UTF-8 直连规避）。

• no_fight 房间正确挡下 PK：新手殿堂/客店未设 no_fight 前， kill fluffos 报错"这里不准战斗。"（欢迎室里）。
• 新手保护正确挡下 PK：两个测试号 mud_age 都很小（< 18000）， cmds/std/kill.lpc 第 62-64 行 obj->query("mud_age") < 18000 挡 下攻击，提示"你感到一丝内疚，手突然软了下来！"——这是文档化的新手 保护机制，不是 bug。用 admin eval 把双方 mud_age 临时调到 30000（纯测试用途，不是代码修复）验证挡阀确实是这个字段在起作用。
• kill 的"单方合意"握手机制验证通过：pktesty 先对 fluffos 下 kill，fluffos 收到红字警告"如果你要和皮卡丘性命相搏，请你 也对这个人下一次 kill 指令。"并自动进入非致命对峙（fight_ob）， 此时 fluffos未回敬 kill 前，fluffos 侧 is_killing() 为 false；fluffos 也下 kill 后转为双方真实计入 killer 表的互 杀状态。全程与 cmds/std/kill.lpc/help kill 文档描述一致。
• 真实伤害/晕厥/苏醒循环验证通过：adm/daemons/combatd.lpc do_attack() 里状态提示逐级升级（气喘嘘嘘→十分疲惫→头重脚轻→半 昏迷→"眼前一黑，接著什么也不知道了"晕厥），晕厥后自动苏醒并恢复 战意（"愣了一愣，大叫「我宰了你！」"），期间 debug.log 全程无一 条运行时报错。用 admin eval 调用 remove_all_killer()/ remove_all_enemy() 停战收尾，双方 quit 干净退出（pktesty 昏 迷状态下第一次 quit 被吞掉，苏醒后重发一次即正常触发退出流程， 这是"忙碌/失去意识时指令被打断"的正常行为，不是 bug）。

排查但判定为设计而非 bug：do_attack() 里"非 kill 情形也有极小

真实创伤几率"的布尔表达式

combatd.lpc 第 662-673 行判断是否造成"真实创伤"（receive_wound， 区别于消耗性的 qi 伤害）的条件是 (me->is_killing(...) && P1) || P2，其中 P2 （(!weapon)&&!random(7) || weapon&&!random(4)）没有被 is_killing() 卫护，意味着即使双方只是 fight（切磋，help fight 明文写"这种形式的战斗纯粹是点到为止……不会真的受伤"）理论上也有约 1/7（空手）或 1/4（持械）的几率触发真实创伤，字面上与 fight/ kill 两条帮助文档的措辞矛盾。但这条 combatd.lpc 是 ES2 血统里 逐字复制的共享文件——语料库里至少还有 bmxkx2001/cctx/hy5/ hy2000/jyqxc/jhfy/jhfy3 等几十个互不相关的库带着完全相同的 !random(7)/!random(4) 结构——分布如此广泛、结构一致（两个分支 仅除数不同，不像是本库局部代码腐化），判定为 ES2 原始设计里"切磋 也有极小意外受伤几率"的既有机制，帮助文档只是简化措辞，未在本库或 任何其它库单独改动。

结论

三项任务清单里唯一的真正空白（PK 战斗）已完整验证：房间战斗禁制、 新手年龄保护、kill 单方合意握手、真实伤害/晕厥循环，全部按设计工 作，全程无 debug.log 报错，未发现新程序 bug。测试号 pktesty 存档 （data/login/p/pktesty.o、data/user/p/pktesty.o）已在测试结束 后删除。驱动进程按精确 PID kill，tmux 会话已停止。

§7.19 enable_player() reentrancy fix (2026-09-01)

Corpus-wide mechanical fix (AGENTS.md §7.19, Batch F of 6). Real active wrapper confirmed to be feature/command.lpc via F_COMMAND (inherit/char/char.lpc etc all inherit F_COMMAND -> /feature/command.lpc); a same-named feature/command2.lpc also has an identical enable_player() but is a dead orphan file (nothing inherits it -- its only grep hit was a coincidental substring match inside an unrelated garbled log dump). No pre-existing reentrancy guard: NPC init() reaches setup()/reset_me() -> enable_player() -> enable_commands(), which can synchronously re-invoke the same object's init() (driver docs BUGS note + this project's own live-verified mhxy/wuhanzhan findings), and feature/damage.lpc's revive() / cmds/std/sleep.lpc's wakeup() re-invoke enable_player() while already living(), ruling out a bare living() guard. Fixed with the standard in_enable_player_now true reentrancy flag (mhxy's reference fix), applied to feature/command.lpc only. Verified via single-file lpcc --batch PASS.

深度功能测试（§10.7，2026-10-04）— negative range ends

scripts/lpc_fix_negative_ranges.py: 5 line(s) in 2 file(s) count a range from the end with < (x[a..-1] -> x[a..<1], x[-2..] -> x[<2..]; KB 06 §7.209). In this driver a negative constant end gave "" / ({ }) and a negative start the whole value, so each of these returned the wrong slice; the compile warning A negative constant as the second element of arr[x..y] is gone from the files that compile. Range lvalues (s[0..-1] = text, the prepend idiom) are left alone. A paired compile of the changed files at HEAD and in the working tree showed no new error.

深度功能测试（§10.7，2026-10-04）— compile-warning and load-failure pass (ported from xkx2001)

scripts/lpc_warnings.py jym: 286 distinct diagnostics at the end, 10985 files compile and 213 do not. A load check of every .lpc (12504 files, 700 per VM boot) at HEAD and in the working tree: 10937 PASS -> 10974 PASS, no file that loaded before fails now that is not a random draw. 1710 files changed. The code is the xkx2001 root's, so the pass is its pass (libs/xkx2001/NOTES.md has every class, the typos found through the no-side-effects list and the list of files left alone): lpc_twin_port.py adopt xkx2001 jym carried the fixes of the files whose code is the root's, then lpc_warnings.py --fix, lpc_diamonds.py --fix-redundant, lpc_fix_void_override.py, lpc_fix_macro_redef.py, lpc_fix_prototype_types.py, lpc_move_decl.py, lpc_fix_no_effect.py, lpc_fix_heredoc_terminator.py and (after a rescan) lpc_name_winner.py handled the diagnostics that depend on this lib's own files.

Fixed by hand in this lib (each read first; nothing written new): d/changbai/damk.lpc (a string broken by a raw newline, joined as in the root); kungfu/class_all/shenlong/lu.lpc and class_bak/shenlong/lu.lpc (the same damaged reply as the root's lu.lpc, replaced by the sentence the live kungfu/class/shenlong/lu.lpc of this lib carries); adm/daemons/rankd1.lpc (return "婆婆; lost its closing quote, hc and zhonghua2 carry "婆婆"); kungfu/skill/miaoshouhuichun/lifeheal.lpc (ob was used and never declared: object ob;); d/dali/npc/daobaifeng.lpc (attempt_apprentice(object ob) tested me->query("family/family_name") with me undefined; shenzhou carries ob).

The one file that loaded at HEAD and fails in the load check, kungfu/class_all/generate/chinese.lpc, picks random skills when it is created and raises No such skill for the ones this lib does not have, so it loads or fails by chance (it failed with a different skill name each time); it is not a regression. What is left: dead files (drafts, pasted logs, wizard work, the TMI-2 network daemons without headers), the kungfu/class_bak and class_all copies that never loaded, inherit F_JIEBAI;, F_NATURE, BUNCHER and other macros this lib never defined, and d/heimuya/basket.lpc (an ITEM that calls ::reset() and the undefined check_trigger()).

深度功能测试（§10.7，2026-10-04）— paths named in another case

The archive comes from a case-insensitive host: files are stored as BAGUA0.lpc, longjing.C, d/SHAOLIN/, the code names them in lower case (__DIR__ "bagua0", "tea/longjing", "/d/shaolin/..."), so the rooms, NPCs and items behind them could not be loaded (a .C file is not an .lpc file; KB 03 §4.5). scripts/lpc_case_paths.py --convert --apply jym: 94 file(s) renamed to lower case (.C -> .lpc, .H -> .h) and 0 path reference(s) in 0 file(s) rewritten to the new spelling; 0 skipped, 0 ambiguous. Load check of the 120 objects that were renamed, edited or name a renamed path (HEAD against the working tree, an object is the same under any spelling of its path): 25 PASS -> 106 PASS, 0 that loaded before fail now, 81 more load.

100 files moved in total (94 in the first complete run, 5 in an interrupted one, then d/lingjiu/BAGUA.H once the include resolution of the tool was fixed): 53 .C -> .lpc (the tea items of d/city/npc/tea, rooms of d/dali, the Lingjiu array rooms), 41 files of the wizard directory u/Yefeng (the code names /u/yefeng/...), 4 headers (BAGUA.H, REGIONS.h ...), adm/etc/WELCOME -> welcome (the text the login code prints). Rescan: 290 distinct diagnostics, 11037 files compile and 214 do not (10985 / 213 / 286 before); the eight bagua* rooms compile after the last rename (checked individually).

深度功能测试（§10.7，2026-10-05）— room base survives a raising NPC

scripts/lpc_resilient_room.py --apply: make_inventory() of inherit/room/room.lpc loads each inventory object as if (catch(ob = new(file)) || !objectp(ob)) return 0;. new() of a file that is not there returns 0 (the room just lacks that NPC), but new() of a file whose create() raises (a skill file for set_skill() this archive never had, a carry_object() item that is not there, a header that never shipped) raised inside the room and the room did not load at all. The wrong-case renames of this lib (the section above) make the NPCs behind them reachable for the first time, so a room that holds one with such a content gap would have gone from "NPC missing" to "room missing"; now it loads without that NPC, as it did before. The room base compiles and loads with the change (HEAD against the working tree). KB 03 §4.5.

深度功能测试（§10.7，2026-10-06）— 与 zhonghua2 同源的三处编译警告

• include/npc/indian.lpc 与 masia.lpc 共用全局名 ma_sname/ma_pname；两个头文件被同一个守护进程（npcd 等）一起包含时，后包含的印度名表覆盖马来名表，generate_ma_name() 生成的是印度名字。印度表改名 in_sname/in_pname（KB 04 §6.10）。

验证：改动的文件和包含 npc/indian 的守护进程在 HEAD 与工作树分别加载（scripts/lpc_listcheck.sh，新进程），无回退。

深度功能测试（§10.7，2026-10-08）— 编译警告整理

scripts/lpc_warnings.py jym --fix 加 scripts/lpc_fix_no_effect.py --apply，共改动 3 个 .lpc 和 1 个 .h（多为删去未用的局部变量）。HEAD 与工作树分别加载（新进程）：3 -> 3 通过，无回退；改过的头文件的 17 个包含者 16 -> 16 通过。启动时警告 2 -> 0；新进程登录（输入名字）正常。

• 2026-10-10：/clone/misc/roommaker.lpc 生成新文件用的 here-document 模板（@ROOM_CODE/@OBJ_CODE）里的 inherit 行，被 9246fbacc89 的重复继承清理当成代码删掉了（lpc_diamonds.py 当时不识别 here-document），用它生成的房间/物品会因缺少继承而无法编译。已恢复该行；工具已修正。

• 2026-10-10：编译警告第二轮（按驱动报告逐条修）：按位 & 改逻辑运算 0 处，返回类型/原型 0 处，NPC+F_UNIQUE 的 init() 0 个，带初始化的未用局部变量 6 个，只在 #if 分支用的声明移进分支 0 个文件；改动 6 个文件，HEAD 与工作树各载入一次无回退（6 objects; HEAD PASS 6, tree PASS 6; regress 0; newly loading 0），这些文件的警告 10 -> 4。

深度功能测试（§10.7，2026-10-11）：“无副作用表达式”警告复查（批 4）

• caiyao.h/wayao.h 采药：max1/2; 结果被丢弃，低经验受害者的上限从不减半；改为 max1 /= 2;。
• d/huashan_old/bian.lpc：seed == 1; 应为 seed = 1;（百分之一的机会从不触发）。
• kungfu/skill/*/lifesave.lpc：-= skill_amount; 后残留 -(x) * (x); 无用表达式，删去。
• kungfu/skill/linji-zhuang/youmin.lpc：空 DEBUG 宏改成空函数。
• 改动的对象 HEAD 与工作区都能载入，无回退。

深度功能测试（§10.7，2026-10-11）：dns_master 空 if

• adm/daemons/network/dns_master.lpc query_services()：if (! (mud_svc[mud]["tell"/"finger"] & SVC_KNOWN)) { 里只有 #if PREF_X & SVC_TCP … #endif，选项关闭时 if 体为空（“无副作用”警告）；把 #if/#endif 挪到 if 外面（KB 04 §6.10，2026-10-07 那次扫描漏掉了 ! ( 带空格、大括号另起一行的写法）。载入无回退。

深度功能测试（§10.7，2026-10-11）：dns_master 空 if

• adm/daemons/network/dns_master.lpc query_services()：if (! (mud_svc[mud]["finger"/"tell"] & SVC_KNOWN)) 块里只有 #if PREF_X & SVC_TCP … #endif，选项关闭时 if 为空（“无副作用”警告报在下一句）；把 #if/#endif 挪到 if 外面（KB 04，2026-10-07 那次扫描漏了 ! ( 加括号换行这种写法）。载入无回退。

• 2026-10-12：d/biwu/obj/xiang.lpc、u/landy/xiang.lpc 写着 int remove() { save(); }，盖掉了 feature/move.lpc 的 remove(string euid)——这些存盘箱子/柜子被销毁时不从携带者身上减负重、不清 handing（KB 06 §7.239 变体，nitan_ceshi/tianxiawuxue 同类）。改成 varargs void remove(string euid) { save(); ::remove(euid); }。HEAD 与工作树各载入一次，regress 0（载不进的文件在 HEAD 就载不进）。

编译警告收尾（2026-10-13）

scripts/toolkit_fix.sh 一轮去掉 3 处多余继承，其余手工，能编译的文件警告清零；改动的 10 个对象在 HEAD 与工作树各载入一次，regress 0。

• u/landy/job/npc/old.lpc、qlong.lpc 自己的 leader（神兽任务的领队）与 F_TEAM 的 leader 同名，改名 job_leader。
• d/mirror/npc/boss.lpc、killer.lpc 只有注释掉的掉宝代码用 item、rand，从声明里删去；kungfu/skill/liangyi-jian.bak.lpc 声明行里多出的 level; 删去。
• cmds/usr/time1.lpc 注释块里又一个 /*、kungfu/skill/huagong-dafa/maxsuck.lpc 的 //*** 分隔线被当成嵌套注释，改写（// ***），内容不变。

• 2026-10-14：新驱动（FluffOS 970d9f09）报 Float value truncated to int（#1426）。64 个文件 71 处：赋值、初始化、return 改写成 to_int(...)（值不变，只是写明截断）；x op= 浮点 先把浮点转成整数再运算（系数小于 1 时 x 直接变 0），改为 x = to_int(x op ...)：/d/gumu/skill/yunu-xinjing/xiuxi2.lpc（xj_gain *=）、/d/gumu/skill/yunu-xinjing/xiuxi2.lpc（xj_gain *=）、/kungfu/class_bak/gumu/obj/beehive.lpc（exp *=）、/kungfu/class_bak/gumu/obj/beehive.lpc（qn *=）。改动的对象新进程各载入一次，无回退（scripts/lpc_fix_float_trunc.py，KB 04 §6.10）。

• 2026-10-14：1 个文件用了颜色宏（HIW、NOR）却没有 #include <ansi.h>（首个错误 syntax error, unexpected L_STRING）；开头补上；5 个文件的函数声明为 int（或 void）却返回字符串、对象（int query_seal() { return "…"; }），旧驱动照样把值交给调用者；改为实际返回的类型（scripts/lpc_fix_void_return.py）（KB 04 §6.1、§6.3）。新进程比对 HEAD 与工作树：6 个对象，新增载入 1，回退 0。

• 2026-10-14（更正）：上一条把 auto_perform() 也改成了 mixed/string，其实那里返回值的类型是因为前面的错误（未定义的函数）才变成未知，不是真的返回字符串；恢复为 int。

内力/精力当作伤害种类（2026-10-15，KB 06 §7.241 第二类）

本库 feature/damage.lpc 的 receive_damage() 不接受 jingli/neili/force 等种类，me->receive_damage("jingli", 30) 之类在练功、绝招、吸取时报 F_DAMAGE: 伤害种类错误。1 处改为 add(type, -N)（scripts/lpc_fix_damage_calls.py 第二步）。

无门派玩家的 family 映射（2026-10-15，KB 05 §7.30 第三种）

mapping fam = ob->query("family"); 之后直接 fam["family_name"]：没有门派（新人或叛师后）的玩家在学习、练功、拜师、进入门派房间时报 Value being indexed is zero，而不是作者写好的提示。2 处在声明行加上 if (!mapp(fam)) fam = ([ ]);（scripts/lpc_fix_family_guard.py）。

东方故事/西游记体系的技能文件（2026-10-15，KB 06 §7.241 第三类）

这些 kungfu/skill 文件来自 gin/kee/sen/force 体系，本库人物只有 jing/qi/neili：receive_damage("kee", 30) 报 伤害种类错误，query("force") 永远为 0，技能学不了也练不了。按 kee→qi、gin/sen→jing、force→neili、max_force→max_neili、force_factor→jiali 改了属性名（scripts/lpc_port_es_props.py），共 6 个文件。

其他体系的属性名（2026-10-15，KB 06 §7.241 第三类，--any-file）

另有 2 个文件（绝招、状态、物品、NPC 等，不限于 kungfu/skill）来自 gin/kee/sen/force 体系，同样按 kee→qi、gin/sen→jing、force→neili 改名（scripts/lpc_port_es_props.py --any-file）。

family 映射（补）（2026-10-15）

mapping fam = (mapping)me->query("family");（带类型转换的写法）同样直接取下标，1 处补上 if (!mapp(fam)) fam = ([ ]);。

内力/上限当作伤害种类（补）（2026-10-15）

victim->receive_wound("force", n, me)（兵器吸内力）、receive_damage("max_qi", random(100))（走火入魔扣上限）等本库不接受的种类，1 处改为 add(type, -N)。

message_vision(msg, environment(me), me)（2026-10-15，KB 06 §7.242）

把房间当成了动作者：message_vision() 取房间的 name() 得 0，replace_string(msg, "$N", 0) 报错。在状态（中毒）里，这个错误发生在 apply_condition(name, duration - 1) 之前，状态永不结束，心跳里后面的恢复也每次被跳过。改为 message_vision(msg, me)：/kungfu/condition/laugh、/kungfu/condition/sanpoison、/kungfu/condition/xianglu-du。

family 映射（再补）（2026-10-15，KB 05 §7.30）

mapping fam; fam = (mapping)ob->query("family");（先声明后赋值）和泥潭式的 query("family", me) 同样直接取下标：无门派的新人拜师（attempt_apprentice/recognize_apprentice）、NPC 的 greeting、房间的 valid_leave、ask_me 等报 Value being indexed is zero。9 处补上 if (!mapp(fam)) fam = ([ ]);（刚 recruit_apprentice() 之后的除外）。

技能按另一门武功的等级取招（2026-10-15，KB 06 §7.243）

这些技能文件是从别的武功复制改名来的，query_action() 仍用原武功的等级查招式表：只会本技能的人等级为 0，取不到招，每次出招都报错。改为读本技能自己的等级（scripts/lpc_fix_action_level.py）：shenghuo-lingfa、sppixie-jian。

空手使用兵器绝招（2026-10-15，KB 06 §7.246）

perform 指令允许直接点名招式（如 perform stick.ban），这些绝招读了 me->query_temp("weapon") 却从不检查，空手时 weapon->name() 报错（有的已先扣了内力）。在赋值后补 if (!objectp(weapon)) return notify_fail("你必须手持兵器才能使用这一招。\n");（scripts/lpc_fix_perform_weapon.py）：dagou-bang/ban、dagou-bang/chan、dagou-bang/chuo、dagou-bang/pi、dagou-bang/sansha、dagou-bang/yin、damo-jian/weituo、huashan-jianfa/feilong、huashan-jianfa/kuaijian、huashan-jianfa/yijian、jinshe-zhuifa/huayu、jinshe-zhuifa/tuwu 等 24 个。

把经验、属性、内力当技能读（2026-10-15，KB 06 §7.247）

经验、属性、内力上限不是技能，xkx/ES 的 query_skill() 对它们只返回 0（风云的还会去载入同名技能文件而报错）。改为 query("...")（scripts/lpc_fix_pool_as_skill.py）：驯马的 /d/dali/npc/a、/d/dali/npc/mafu（成功率少了福缘一项）。

妙手回春的银针检查（2026-10-15）

miaoshouhuichun 的 valid_learn() 用了未赋值的 object ob，ob->query_temp("weapon") 每次都报错，谁也学不了；还把兵器对象和字符串 "银针" 比较。照 chidi 的修法改为 ob = me->query_temp("weapon")，再用 id("yin zhen")/id("yinzhen") 判断是否银针。本库没有银针这件兵器（只有君山银针茶、冰魄银针），这门功夫仍学不了，但不再报错，而是提示要先拿起银针。

临济庄 remove 没有运功时报错（2026-10-15）

linji-zhuang/remove 直接 switch (lj_exert["name"])，lj_exert 是 query_temp("lj_exert")；没有正在运用的临济庄功夫时它是 0，exert remove 每次都报 Value being indexed is zero。补上 if (!mapp(lj_exert)) return notify_fail(...)。本库有两个 exert 设置 lj_exert，运功期间 remove 照常收功。

技能名拼错（2026-10-15，KB 06 §7.249）

query_skill() 里的技能名拼错了，或用的是本库改名前的旧名；本库没有这个技能，调用永远得 0：门槛（< N 就拒绝）永远过不去，相关功夫或绝招学不了、用不了；内功互斥（> N 就拒绝）从不生效；公式里这一项一直是 0。经汉字名（提示文字或中文名词典）或纯拼写差异（_/-、少一个连字符、相邻字母颠倒）核对后，改为本库的技能名（scripts/lpc_fix_skill_typo.py）：xiaowu-xiang→xiaowuxiang（liuyang-zhang、liuyang-zhang/qufu、liuyang-zhang/zhongfu、ruyi-dao、ruyi-dao/lianhuan、tianyu-qijian 等 9 个文件）；shenhuo-xuanming→shenghuo-xuanming（/d/kunlun/skill/dafeng-yunfei、dafeng-yunfei、xiaoyao-zhangfa）；jinwu-dao→jinwu-daofa（jinwu-daofa）；qianzhu-wandushou→qianzhu-wandu（/d/miaojiang/obj/huangjinhe）；xiatian-gong→xiantian-gong（/d/zhongnan/skill/chunyang-quan）；yan-fly→yanfly（yanfly）；yinyun_ziqi→yinyun-ziqi（yinyun-ziqi/cure）。

嵩山剑法「蓄力」没穿布衣时报错（2026-10-15）

songshan-jian/xuli 用 cloth = me->query_temp("armor/cloth") 取衣服，随后直接 cloth->query("material") 判断要不要显示“衣袖鼓起”的描写；身上没有布衣时（裸身或只穿铠甲）这里报错，而此时 apply/speed 已经扣掉、复原的 call_out 还没排上，身法就一直少了一截。两处判断前补 objectp(cloth) &&。

技能名拼错：技能文件里拼错自己的名字（2026-10-15，KB 06 §7.249）

技能自己的文件（或它的绝招目录）里，query_skill() 读的是差一个字母的自己的名字，永远得 0：“基本功夫要高过本技能”之类的限制从不生效，按等级取招、计算伤害的那一项一直是 0。改为本技能的名字（scripts/lpc_fix_skill_typo.py 的 self 判据）：baitao-xuangong→bitao-xuangong（bitao-xuangong）。

地图数据库 mapdb 的空档防护（2026-10-15，KB 06 §7.250）

genmap 第一次载入时 if (!restore()) save(); 会在地图建好之前写出只有文件头的 data/npc/map.o；mapdb 读它成功后 map 为 0，所有查询都对 0 取下标（nitan170911、shenzhou 等 10 个库就带着这样的文件）。没有 map.o 时 query_random_room_path() 又对空数组取下标。mapdb（/clone/npc/mapdb.lpc、/clone/obj/mapdb.lpc）加一个 restore()：读档后 map 不是映射就重置为 ([])；地图为空时 query_random_room_path() 返回 0。

随机取房间后不判断就过滤（2026-10-15，KB 06 §7.250）

/d/city/npc/ftb_zhu.lpc、/d/qilian/obj/jinhe.lpc、/d/tianlongsi/npc/jiumozhi.lpc 从 mapdb 随机取一个房间后直接 strsrch(room_path, ...) 排除区域；地图还没生成时取回的是 0，strsrch(0, ...) 报错，护镖等任务就此中断。条件前补 !stringp(room_path) ||，取不到房间时走原有的重试和“cannot find target room”提示。

临济庄「幽冥桩」的两处笔误（2026-10-15，KB 06 §7.245、§7.250）

linji-zhuang/youming：killer->querry(...)、me->querry(...) 调用的是不存在的函数，永远得 0，恶人比值只按 PK 数算，改为 query；visit_room() 先拿 range 作判断、后从参数里取 range，判断时它还是 0，效果遇到没载入的房间就停，两行取值挪到前面。

银索金铃「点穴」对空手的对手报错（2026-10-15，KB 06 §7.246）

yinsuo-jinling/dian 失手时三种描写之一是“真气贯注”加对手兵器的名字，对手空手时 ob 为 0，三次失手有一次报错。改为 (objectp(ob) ? ob->query("name") : "全身")（泥潭一系原本就写作“真气贯注全身”）。

npc_setup 的浮点截断警告（2026-10-15，KB 04 §6.10）

/clone/obj/npc_setup.lpc：level = pow(10 * exp, 0.333334); 把浮点数隐式截成整数，编译时警告；改为 to_int(...)，结果不变。

存档读不出来：转码损坏（2026-10-15，KB 03 §4.4）

/data/login/z/zwren.o、/data/user/b/bada.o、/data/user/b/best.o、/data/user/e/eternal.o、/data/user/j/jason.o、/data/user/j/jymwp.o、/data/user/l/lama.o、/data/user/l/ledsage.o、/data/user/p/passer.o、/data/user/s/savage.o、/data/user/s/simens.o、/data/user/w/went.o、/data/user/x/xie.o、/data/user/z/zwren.o 在转码时坏了：原档里孤立的 GBK 前导字节被 iconv -c 连同后面的引号一起丢掉，restore_object() 报 Illegal mapping format，读档的对象（玩家、留言板、信件、表情）从空白开始，这些玩家无法登录。按 raw/ 原档重新解码（孤立字节丢掉、引号保留），驱动核对全部能读回（scripts/lpc_save_encoding.py --from-raw、scripts/lpc_save_restore_check.py）。

family 映射内联取下标（2026-10-15，KB 05 §7.30）

ob->query("family")["master_name"]、me->query("family")["family_name"]（泥潭式为 query("family", ob)[...]）直接对门派映射取下标：没有门派的人（新玩家、叛师者、大多数 NPC）在 NPC 的打招呼和问话、绝招的门派判断、房间的 valid_leave 里报 Value being indexed is zero，而不是得到拒绝。3 处（2 个文件）改为 dbase 路径查询 query("family/master_name")：有门派时值相同，没有时得 0；原有的判断照常生效（scripts/lpc_fix_family_index.py）。给映射赋值的写法未动。

用兵器的绝招空手施展时报错（内联写法）（2026-10-15，KB 06 §7.246）

绝招不存兵器变量，直接写 (me->query_temp("weapon"))->query("name")（或在拒绝判断里写 (weapon = me->query_temp("weapon"))->query("skill_type")），之前又没检查兵器：空手 perform 时报 Bad argument 1 to EFUN call_other()，内力等往往已经扣掉。在第一次用到它的那条语句前补上“你必须手持兵器才能使用这一招”的拒绝（scripts/lpc_fix_perform_weapon.py）：duanyun-bian/duanyun、feiyu-bian/chanrao、jueqing-bian/sanwu、qilin-dao/qilin、tangshi-jian/luanci。

移进不存在的巫师房间（2026-10-15，KB 06 §7.251）

用完的物品、要“离开”的 NPC、掷在空中的兵器被移进巫师的工作室（/u/aln/、/u/ryu/、/u/wsky/），本库没有这些房间。本库的 move() 用 call_other(dest, "???") 载入目的地，找不到文件就报 call_other() couldn't find object，后面的语句都不执行：药（人参、狐狸皮、虎骨，clone/drug/cb_renshen、clone/drug/hugu、clone/drug/hulipi）吃下后药效已经生效，随后报错：call_out("destroy", 31) 没有排上，药一直留在身上，药效过去后可以再吃；逍遥三笑散（d/xingxiu/npc/obj/sanxiao）弹出之后报错，毒药留在身上，可以一再使用；疯魔杖法的掷杖绝招（kungfu/skill/fengmo-zhang/fengmo）：内力、精力已扣，杖已卸下，随后报错；接回杖的 check_fight 没有排上，fengmo 标记不再清除，重新登录之前不能再用；天山杖法「飞杖」（kungfu/skill/tianshan-zhang/feizhang）：杖“撞到山石上断成无数截”之后报错，杖仍留在身上。6 个文件改为移进本库的虚空房间 VOID_OB（/clone/misc/void），与原作把它们“停放”在巫师房间的用意相同。

NPC 带着本库没有的物品，载入失败（2026-10-15，KB 06 §7.73）

23 个文件、25 处在 create() 里 carry_object("<本库没有的文件>")->wear()（或 wield()、set_amount()）：carry_object() 得 0，接着的调用报 Bad argument 1 to EFUN call_other()，NPC 根本载入不了，该有它的房间里就少了这个人。多是从别的系统搬来的 NPC 用了原系统的物品路径（最常见：/d/kunlun/obj/pao3、/d/shenlong/obj/cloth、/d/xueshan/obj/yinlun）。每处改为 { object carried_ob = carry_object(...); if (carried_ob) carried_ob->wear(); }（scripts/lpc_guard_carry_object.py）：NPC 照常出现，只是不带这件东西；文件补回来（或是虚拟对象）照样会带上。载入检查：改动的文件改前能载入 1 个，改后 21 个（20 个原来载入不了），没有退步；其余 2 个另有原因（多为 set_skill() 了本库没有的武功）。

set_skill() 遇到本库没有文件的武功不再抛错（2026-10-18，KB 06 §7.256）

feature/skill.lpc 里的 set_skill()、map_skill()、prepare_skill() 碰到没有武功文件的名字就 error("F_SKILL: No such skill (…)")，调用它们的 NPC create() 整个中断：NPC 载入不了，刷出它的房间也少一个人。本库有 12 个对象设了本库没有文件的武功（28 个名字，最多的是 jinshe-zhangfa、jiushou-jiushi、shedu-qiqiao）。三处都改成 return：这一门武功不给、不映射，对象照常载入，只是少了它（缺的武功本身仍是内容缺口）。抽样载入这些对象：12 个里 12 个通过。（scripts/lpc_guard_set_skill.py）

通向不存在房间的出口，按对面房间的回头出口改正（2026-10-18，KB 06 §7.257）

房间出口 "west": __DIR__"xxx" 指向的文件本库没有，玩家走过去就被卡住（笔误、改过名的房间，或者没带进档案的编号房间）。对面的房间存在、并且它相反方向的出口正好指回这个房间，说明出口原本就是通向它：/d/murong/qing3 的 east：kufang → nanshi。改动后每个出口都能解析到本库的文件（scripts/lpc_fix_dead_exits.py；目标在运行时本来就能载入的库——虚拟房间——不动）。

补回本库没有的基类文件（2026-10-18，KB 04 §6.15）

下面这些基类本库没有，继承它们的对象（房间、NPC、物品）整批载入不了（inherit XXX; 的宏没定义，或者 inherit "/std/…"; 的文件不在）。同系的库里有同名文件，两库有大量逐字节相同的文件（亲缘关系），所以从那边原样拷来，缺的宏补进全局头文件 include/globals.h：/feature/jiebai（宏 F_JIEBAI）←shenzhou，1 个对象继承它，抽样 1/1 载入。每个基类补回后单独载入、再抽样载入使用它的对象，基类载不进来或者一个用户也载不进来的就撤掉（本库撤掉了它们，不再补）。（scripts/lpc_restore_bases.py）

武功名拼错的 NPC（2026-10-19，KB 06 §7.258）

set_skill("kunlun-shnfa", …)、map_skill("dodge", "shaolin-shnfa") 这样的调用把武功名拼错了：本库没有这个武功文件，有的是拼对的那个。以前这种 NPC 在 create() 里报 No such skill 载入不了；武功缺失时跳过之后它们能载入，可是少了那门武功（set_skill 被跳过，map_skill 映射不到，门派弟子用普通轻功/拳脚）。按核对过的对照表改正，共 23 处、20 个文件：lingji-zhuang→linji-zhuang（7 处）、pudu-chang→pudu-zhang（5 处）、dashouyin→dashou-yin（4 处）、stuff→staff（1 处）、huagu-mainzhang→huagu-mianzhang（1 处）、banrou-zhang→banruo-zhang（1 处）、sanying-zhua→sanyin-zhua（1 处）、jingding-zhang→jinding-zhang（1 处）等共 10 个名字。（scripts/lpc_fix_skill_names.py）

全局头文件丢了 1 个宏（2026-10-19，KB 04 §6.16）

/include/globals.h 里没有定义 REMOVE_CMD，用到它们的物件（名单里 1 个）编译时报 Undefined variable/Undefined function，整个物件载入不了（编译器在第一个未定义的名字上停下，后面的错误和警告都看不到）。同系的库在各自的头文件里都有这几行：照其中和本库共有文件最多的那个库，原样补到 /include/globals.h 最后一个 #define 之后，宏体里出现的路径在本库里都存在。补完后名单里有 1 个载入，其余还差别的东西。（scripts/lpc_restore_defines.py）

出口指向不存在的房间（2026-10-19，KB 06 §7.257）

下列房间的出口写的文件不存在，而对面恰好只有一个房间的出口指回本房间，所以按对面的房间改正（笔误、大小写、路径少了一级）：

• /d/beijing/east/wangfudajie3.lpc 的 southwest 出口：/d/beijing/zijincheng/dongchangan → /d/beijing/zijin/dongchangan
• /d/huangshan/ciguang.lpc 的 south 出口：wengquan → wenquan
• /d/huangshan/tiandu1.lpc 的 up 出口：jiyubei → jiyunbei

改后房间照常载入（与 HEAD 逐个对比，没有退步），出口现在指向存在的房间。

RANK_D 对 0 的称呼（2026-10-19，KB 06 §7.273）

adm/daemons/rankd.lpc 的 query_respect()、query_rude()、query_self()、query_self_rude() 里 6 个函数开头补上 if (!objectp(ob)) ob = this_object();。NPC 在 create() 里写 "…" + RANK_D->query_respect(this_player()) + "…"（inquiry 对话、chat_msg），驱动自己跑 reset() 时没有人在场，this_player() 是 0。旧驱动里 0->query("age") 返回 0，称呼走默认分支；新驱动直接报 Bad argument 1 to EFUN call_other()，房间的 make_inventory() 吞掉错误，被打死的 NPC 再也刷新不回来。用 scripts/lpc_reach_census.py --walk 找到（xkx100 的武当弟子、一灯、汴梁书生…）；修在守护程序里，不动 1,800 个 NPC 文件。

玩家打造兵器模板没有打造者时（2026-10-19，KB 06 §7.275）

/d/npc/m_weapon/weapon/m_blade.lpc、/d/npc/m_weapon/weapon/m_club.lpc、/d/npc/m_weapon/weapon/m_hammer.lpc、/d/npc/m_weapon/weapon/m_staff.lpc、/d/npc/m_weapon/weapon/m_sword.lpc、/d/npc/m_weapon/weapon/m_whip.lpc 等（共 25 个）的 create() 开头 me = this_player(); 之后无条件读 me->query("weapon/name") 等打造数据。房间刷新时没有人在场（me 为 0），或者 NPC 在别的 NPC 的命令环境里 carry_object() 这个模板（NPC 的 weapon 属性是文件名字符串），旧驱动里读出来是 0 或字符串，switch 照样落到 default；新驱动报 Bad argument 1 to EFUN call_other() / Bad argument 1 to switch，NPC 和它所在的房间载入不了（--walk 普查里一个玩家走进房间就触发）。在 //读入数据 之后加 if (!me || !mapp(me->query("weapon"))) { setup(); return; }：没有打造者就留一个没有名字的空模板，玩家打造的流程不变。

x == "a" || "b"：后面的字符串常量永远为真（2026-10-19，KB 06 §7.281）

if (arg == "yuyou" || "yu you") 里的 "yu you" 是非空字符串，永远为真，整个条件对任何 arg 都成立；作者要的是每个字符串都和变量比较。在每个字符串前补上变量和运算符（scripts/lpc_fix_literal_or.py；forrest2.lpc 是 dir == "north" && "south"，手工改成 (dir == "north" || dir == "south") && ...）：/d/gaibang/ml.h（1 处）、/kungfu/skill/huashan-jianfa/kuaijian.lpc（1 处）。

x != "a" || x != "b" 和 x == "a" && x == "b"：同一个值的比较链永远成立/永远不成立（2026-10-20，KB 06 §7.282）

if (arg != "wan" || arg != "丸") return notify_fail(...) 对任何 arg 都为真，dir == "south" && dir == "north" 永远为假：条件下面的守卫要么永远拦、要么永远不拦。作者要的是“既不是 A 也不是 B”（&&）或“是 A 或 B”（||）。!= 链的 || 改成 &&（仅当条件下面是 return 的拒绝/守卫），== 链的 && 改成 ||（scripts/lpc_fix_cmp_chain.py）。改动：/d/mingjiao/shanmen.lpc（1 处）。另有 /d/hangzhou/huagang1.lpc（1 处） 的条件下面做的是别的事（== 和 || 也可能是本意），保持原样。

比较链的人工修正（2026-10-20，KB 06 §7.282）

d/hangzhou/huagang1.lpc：挖泥的判断 arg != "泥" || arg != "mud" 永远为真，随便挖什么词都挖出湿泥，后面的“你要挖什么？”走不到；本意是参数是“泥”或 mud 时才挖，改成 == 和 ||。

if (x = 常量)：条件里写成赋值的比较（2026-10-20，KB 06 §7.290）

if (arg = "button" || arg = "按钮")、if (!arg || arg = "") return 0;、else if (check = 0 && tempB != "")：把 == 写成了 =，条件的值就是那个常量，分支对所有非零数和任何字符串（连 "" 都算）永远成立、对 0 永远不成立，变量还被覆盖；驱动对此没有任何警告。每一处 = 改成 ==（scripts/lpc_fix_cond_assign.py，共 35 处）。改动：/adm/etc/wumiao.lpc（1 处）、/d/city/jiuguan2.lpc（2 处）、/d/city/muoult.lpc（1 处）、/d/city/npc/mj.lpc（3 处）、/d/city/npc/mjxiaosi.lpc（3 处）、/d/city/npc/muou.lpc（1 处）、/d/city/wumiao.lpc（1 处）、/d/city/zuixianlou.lpc（1 处）、/d/heimuya/jiudian.lpc（1 处）、/d/kunlun/luanshiduibak.lpc（2 处）、/d/quanzhou/qzkedian.lpc（1 处）、/d/quanzhou/wglou1.lpc（1 处） 等 16 个文件。

登录密码超过 255 字节：crypt() 抛错（2026-10-20，KB 06 §7.294）

驱动的 crypt() 对超过 255 字节的密钥直接报错（Error in crypt(), check your salt），老驱动则按任意长度散列。在登录提示符下输入 256 字节以上的密码，密码检查那一行就抛错，连线停在一个裸的 > 提示符上，登录走不完（password 指令的旧密码检查同样）；用 300 个 x 当参数的扫描发现的。/adm/single/simul_efun.lpc 里补了一个同名的 simul_efun crypt(key, salt)：只有超长的密钥才被截短（先截到 255 个字符，再逐字符截到 sizeof(to_buffer(key)) <= 255，限制按字节算，一个汉字占三个字节），再交给 efun::crypt()；普通密码原样散列，已存的密码散列不受影响（scripts/lpc_add_sefun.py crypt）。

存档里的 .c 文件名改成 .lpc（2026-10-21，KB 03 §4.2 第 9 项）

存档里写着 "/d/city/npc/wei.c" 这样的文件名；extract 时源文件已经全部改成 .lpc，而驱动对带扩展名的路径只认字面，new() / load_object() / move() 都找不到它，调用方多半把失败当成「没有这个东西」悄悄跳过。本库 3 个存档共 3 处按 scripts/lpc_fix_save_dotc.py 改成 .lpc（只改 .lpc 存在而 .c 不存在的字符串；玩家存档、备份、留言板、巫师目录和文件索引缓存不动）。改动：/drop/user_bak/m/muder.o（1 处）、/kungfu/class/gumu/npc/longnv.o（1 处）、/kungfu/class_all/gumu/npc/longnv.o（1 处）（共 3 个存档）。

巫师命令不带参数时对 0 调用 efun（2026-10-21，KB 06 §7.336）

巫师（管理员）把命令敲成不带参数时，驱动把 0 传给字符串参数；下面的命令第一句就把这个 0 交给 efun，运行时报 Bad argument 1 to ...，这条指令从来没有用过。用 scripts/lpcc_bare.py 不登录、在一次 lpcc 求值里以 0 调用 main() 逐个确认后，由 scripts/lpc_fix_bare_arg.py 在第一处使用参数的语句前加守卫：文件自带 int help(object me) 的，守卫是 if (!arg) return help(me);（help() 定义在 main() 之后的 1 个文件补了原型 int help(object me);，否则编译报 Undefined function help）。改动（1 个文件，括号里是接住 0 的 efun）：/cmds/wiz/test.lpc（present）。加载检查 HEAD 与工作树对照，没有退步。

拼错的 call_out() / input_to() 目标（KB 06 §7.349，2026-10-21）

计时器或输入提示给驱动的函数名和文件里定义的差一个字母；驱动对不存在的函数静默不理，所以对应的计时从来没有触发过。调用和配套的 remove_call_out() 改成已定义的拼法：药炉：burning2 / burning3 → 文件里定义的 buring2 / buring3；do_destroy → 文件里定义的 do_destory。改动：/d/huanghe/npc/tc_wang.lpc、/d/xingxiu/npc/obj/yaolu.lpc、/d/xingxiu/obj/yaolu.lpc。

保护任务的商人 clone/obj/job/job_protect_npc.lpc：两处笔误让整个文件从来没编译过（2026-10-21，KB 04 §6.29）

clone/obj/job/protect.h（保护商人的任务）克隆这个 NPC，但文件有两处笔误：int baohu(string age) 的函数体用的是 arg（Undefined variable 'arg'），而 init() 登记的是 do_baohu，函数名也对不上；query->("id") 多了一个 ->。改成 int do_baohu(string arg) 和 query("id")（if (!player = find_player(...)) 报的 Illegal LHS 只是前面语法错误引出来的连锁错误，这种写法本身是对的，没有动）；文件第一次能编译后带出 7 个 Unused local variable 警告（sacrifice、exp_rate、skill_rate、lmt、menpai、killer、kill_num），按 KB 04 §6.10 删掉。baohu / protect 两个动词现在有处理函数，任务的商人也第一次能出现。改动：/clone/obj/job/job_protect_npc.lpc。

注册到不存在函数的 add_action（2026-10-21，KB 06 §7.349）

add_action("函数", "动词") 绑定的函数，在对象本身、它包含的头文件、它继承的父类和继承它的子类里都没有定义（scripts/lpc_scan_callout_targets.py 静态解析，子类用传递闭包复核，scripts/lpc_verify_handlers.py 运行时 function_exists() 复核）。驱动从玩家最新的一条动作往回找，遇到这样的句子就报 *Function for verb 'drop' not found.，同一个动词的其他处理函数不再尝试（不是最新的一条就悄悄跳过）。删除了 42 条注册（15 个文件，scripts/lpc_fix_dead_add_action.py），动词留给别的处理函数：/d/beijing/obj/kuanglu.lpc（do_look）、/d/city/muoult.lpc（do_enable、do_guo）、/d/kunlun/npc/mingjiao_npc.lpc（do_qingjiao）、/d/quanzhou/npc/gongping-zi.lpc（do_bihua、do_halt）、/d/xiakedao/obj/car.lpc（do_hire）、/d/xingxiu/npc/feng.lpc（do_ketou）、/d/xingxiu/obj/sanxiao.lpc（throw_ob2）、/d/xingxiu/xueling/exit1.lpc（do_ling）、/inherit/misc/fboard.lpc（do_list）、/kungfu/class/gaibang/zhulin3.lpc（do_bake、do_cut、do_kao、do_remove等） 等共 15 个文件。最多的函数名：do_cut 4 处、do_remove 4 处、do_wash 4 处、do_wrap 4 处、do_answer 4 处。没有动（读过）：/clone/obj/job/job_protect_npc.lpc 的 do_baohu（对象本身编译不过，登记留着，等对象能加载再处理）。

基类的 add_action 登记：处理函数只在后代里定义，基类自己被加载时报错（2026-10-21，KB 06 §7.349）

房间、NPC、公告板这类基类，init() 里登记的 add_action("函数", "动词") 的函数只由继承它的后代定义；基类对象自己被直接加载（房间可以走进去、NPC 可以克隆）时，访客输入这个动词，驱动报 *Function for verb 'x' not found.（第一轮扫描把这些当成“有后代定义，是活的”放过了，scripts/lpc_verify_handlers.py 在基类对象上跑 function_exists() 才看出来）。登记前加 if (function_exists("函数", this_object(), 1))（第三个参数 1：默认 function_exists() 把 protected / private 函数当作没有定义），后代照常登记。共 6 处、1 个文件（scripts/lpc_fix_dead_add_action.py --guard）：/d/bwdh/kantai.lpc（do_abandon、do_practice、do_study）。

对象路径里的 ..：new(__DIR__ "../obj/x") 报 Read access denied（2026-10-22，KB 06 §7.351）

__DIR__ 是当前文件所在目录（带结尾斜杠），__DIR__ "../obj/x" 就是 /d/zhiye/npc/../obj/x；驱动的 legal_path() 不接受带 .. 的路径，new() / load_object() 直接抛 *Read access denied.（实测，find_object() 对它答 0）。走库自己的 carry_object() / 房间 objects 表的路径，库的基类会先规范化，能用；直接把路径交给 new() / clone_object() / load_object() / move() 的不行，调用到那一步才报错。改成规范化后的绝对路径（scripts/lpc_fix_dotdot_dir.py --direct）：/d/wudang/npc/xiaocui.lpc（__DIR__ "../obj/nuerxiang" → "/d/wudang/obj/nuerxiang"）。

代码里写死 .c 后缀的路径（2026-10-22，KB 06 §7.356）

carry_object("/x/y.c")->wield()、new("/x/y.c")、inherit "/x/y.c"、出口 "down" : "/x/y.c"、商店货单 "/x/y.c" : 10 这类字符串，压缩包里的文件早已改名成 y.lpc；明确写出的后缀按原样查找（KB 03 §4.2），找不到文件，new() 返回 0，0->wield() 报 Bad argument 1 to EFUN call_other() Got int(0)，NPC 的 create() 中途退出、整个对象加载不了。scripts/lpc_fix_dotc_path.py 把 2 个文件里的 12 处 .c 改成 .lpc（只改文件存在于 .lpc、不存在于 .c 的代码字符串；注释、巫师目录、两种写法都不存在的路径不动）：/kungfu/class/dali/daobaifeng.c、/d/xingxiu/npc/bayi.c、/kungfu/class/xixia/ye.c、/d/foshan/npc/yiming.c、/d/quanzhou/npc/wang.c 等。 加载检查（HEAD 与工作区对比，改动的 2 个文件）：HEAD 能加载 2 个，现在 2 个（新增可加载 0 个，回归 0 个）。

(: 函数 :) 指针指向对象自己没有定义的函数（2026-10-22，KB 06 §7.355）

item_desc / inquiry / chat_msg_combat 里的 (: 函数名 :) 指向本对象（含包含文件、继承的父类）没有函数体的函数：编译不报错，用到时驱动报 *Undefined lfun pointer called: 函数名（look 某物、ask NPC about 话题 直接出错，战斗 / 闲聊里的指针在 NPC 的 chat() 里出错，这一拍心跳的后半段被跳过）。scripts/lpc_scan_callout_targets.py --kinds=lfun。 还剩 15 个函数没有补（chat_msg_combat 10, inquiry 5）：原型还在函数体丢了、或者根本没写过，没有可以直接补回的捐赠（别的库同一路径的文件里没有这个函数，或者它还要用本库没有的辅助函数、签名不同），不编造：/d/city/npc/hua_girl.lpc:ask_me、/d/emei/npc/guide.lpc:ask_job_begin、/d/emei/npc/guide.lpc:ask_job_finish、/d/huanghe/npc/tc_hu.lpc:ask_job、/d/huanghe/npc/tc_you.lpc:ask_join、/d/shenlong/npc/bangzhu_npc.lpc:auto_perform、/d/xiakedao/npc/huang.lpc:auto_perform、/d/xiakedao/npc/laozu.lpc:auto_perform、/kungfu/class/murong/baichuan.lpc:auto_perform、/kungfu/class/shenlong/lu2.lpc:auto_perform 等另外 5 个。

运行期目录 log/nosave 不存在，写日志的 write_file() 直接报错（2026-10-22，KB 03 §4.3 补充）

这个库的 15 个文件里有 30 处 write_file("/log/nosave/...") / log_file("nosave/...")（static 改 nosave 时连字符串里的日志路径一起改了，原来是 log/static/）：nosave/CRASHES、nosave/PURGE、nosave/copyskill 等。压缩包和站点包里没有这个目录，write_file() 在目录不存在时抛 *Wrong permissions for opening file /log/nosave/... for append. "No such file or directory"，调用它的函数（杀人记录、重启记录、call 日志……）当场中断。把 log/nosave 记进 scripts/wasm_keep_dirs.txt（站点和 pristine 树都按它建空目录）；没有把字符串改回 static。证明（scripts/lpcc_eval.py，catch(write_file("/log/nosave/ZZTEST", ...))，fqyy2 / hy5 / bmxkx2001 的新进程）：补目录前报上面的错误，补后写成功。

log/ 下的日志子目录没有人建：写日志的 write_file() / log_file() 报错（2026-10-22，KB 06 §7.358）

这个库的代码往 log/ 的 1 个子目录写日志：log/beijing（d/beijing/helper.lpc）。压缩包、git clone 和站点包里都没有这些目录（本地启动没有写过它们，gen_keep_dirs.py 没记），write_file() 对不存在的目录抛 *Wrong permissions for opening file /log/dlog/money for append. "No such file or directory"，调用它的函数在写日志那一行中断，后面的奖励、标志、步骤都没有执行。本库的 log_file() 是 write_file(LOG_DIR + file, text)，目录不存在就抛同样的错误（实测）。把 log/beijing 记进 scripts/wasm_keep_dirs.txt（scripts/lpc_keep_log_dirs.py；站点和 pristine 树按它建空目录）。证明（scripts/lpcc_eval.py，在 /adm/daemons 这类目录下的求值对象里写 /log/zzdirprobe/...，新进程）见 KB 06 §7.358 的实测表。

(: 函数名 :) 指针指向本库没有的函数：只含这个指针的行加了注释（2026-10-22，KB 06 §7.355 补充）

inquiry / item_desc / chat_msg* 里的 (: 函数名 :) 指向本对象（含包含文件、继承的父类）没有函数体的函数：用到时（ask、look、NPC 闲聊）驱动抛 *Undefined lfun pointer called: 函数名，这一拍心跳的后半段被跳过。这些函数没有可以补回的来源（别的库同一路径的文件里没有，或者它还要用本库没有的东西），所以 14 个文件里 16 行只含这个指针的行（"song": (: ask_me :), "出发": (: ask_job_begin :), "结束": (: ask_job_finish :),）加了注释，原文保留并写明原因，这一项当作没有这个话题 / 物品 / 闲聊条目（scripts/lpc_fix_dangling_lfun.py；#include 的文件在库里缺失的对象、指针不在整行上的写法没动）。 前提（function_exists()）和加载检查（HEAD 与工作区对比，本库改动的 .lpc 文件）的结果见 KB 06 §7.355：没有一个回归。

汉字按字节切片的老写法没有换成按字符：改法名 "澄" + name[2..3]、辈分判断 name[0..1] == "澄" 等 208 处（2026-10-22，KB 06 §7.360）

原档按字节算字符串区间（一个汉字 2 字节）：name[2..3] 是名字的第二个字，name[0..1] == "澄" 问名字是不是以「澄」开头。转成 UTF-8 之后，这个驱动的区间和 strlen() 都按字符算（strlen("澄观") 是 2，"澄观"[0..1] 是两个字），老算术原样留着、意思全变：拜入少林 / 武当 / 峨嵋等派的玩家被改成错误的法名（二字名 张三 变成一个字的 澄，更长的名字取到第三个字）；各派掌门的辈分判断（name[0..1] == "澄"）永远不成立；改名官 zhuce 的长度检查按字节算，合法的名字一个也过不了。

本库 208 处（79 个文件）：拼名字的赋值 164 处、与汉字常量比较 43 处、改名官的长度检查 1 处。例：name[0..01] → name[0..0]（/clone/npc/qiu.lpc:291）；name[4..5] → name[2..2]（/clone/npc/qiu.lpc:291）；name[0..3] → name[0..1]（/d/city/npc/shiye.lpc:130）。scripts/lpc_fix_gbk_slice.py 把下标按字符重算（社区的 UTF-8 版 xkx100utf8 里就是同样的写法，作对照）；没有改的：截断（name = name[0..7]，现在最多 8 个字，只是放宽）、ASCII 的区间（fname[0..3] == "room"、ctime(time())[4..19]）和上下文看不出是汉字的区间。证明（scripts/lpcc_eval.py，bixiecanyang；其余各库是同一份文本）：让澄字辈掌门 attempt_apprentice() 一个名叫「张三」的访客，HEAD 的法名是 慧，改后是 慧三；抽样 28 个库的 HEAD / 工作树加载对比 0 退步。工具不幂等（[0..3] 折半得 [0..1]，又是对齐区间），改过的文件记在 scripts/gbk_slice_converted.txt，不要重跑。

长度检查按字节写，旁边的提示按汉字写：4 处（2026-10-22，KB 06 §7.362）

老档的 strlen() 数字节（一个汉字 2 字节），转成 UTF-8 后它数字符：提示写「必须是 2 到 6 个中文字」的检查还是 strlen(name) < 4 || strlen(name) > 12，于是两三个字的房名、帮会名、群名、聊天室名、称号被提示自己说允许的那句话拒绝，上限却是提示的两倍；留言板的标题检查 i < 4 || i > 24 || i % 2 还会拒绝所有奇数个字的标题（post 你好吗）。本库 4 处（2 个文件）：if( (strlen(name) < 2) || (strlen(name) > 8 ) || i % 2) {（/adm/daemons/Logind.h:724）；if ((strlen(name) < 2) || (strlen(name) > 8) || i % 2) {（/adm/etc/logind.lpc:1120）。scripts/lpc_fix_strlen_gate.py 以提示为准：条件里每个 strlen 门槛都恰是提示所说数字的两倍才折半，存长度的变量（i = strlen(arg);）的门槛和 || i % 2 奇偶项、其后循环的 i % 2 == 0 && 一并处理；提示里有英文 / 字母 / 字节的不动。证明（scripts/lpcc_eval.py，bxsj 的留言板，求值对象继承 NPC 并重写 edit() 记录调用，command("post 标题")）：HEAD 拒绝「你好」和「你好吗」、放行 23 个字的标题；改后接受前两个、拒绝第三个；shenmo 的 named.lpc invalid_new_name("张三")：HEAD 回 名字只能是2-4个中文字。，改后回 0。抽样 24 + 15 个库的 HEAD / 工作树加载对比 0 退步。

按字节写的汉字循环、茶馆猜诗和同盟频道标题（2026-10-23，KB 06 §7.363）

老档按字节做「一个汉字」：while (i--) if (i % 2 == 0 && !is_chinese(name[i..<0])) 只检查偶数下标，奇数位上的拉丁字母（张a）会过；茶馆猜诗 mixup() 用 strlen(str)/2 再 j=j+j、str[k..k+1] 交换两字节；泥潭系 channeld 的 switch (strlen(fname)) case 4/6/8/10 和 strlen(family)==4/6 按字节长度给同盟 / 门派名加空格。本驱动的 strlen() 和区间都按字符算。scripts/lpc_fix_byte_char.py：去掉奇偶项、把区间改成 name[i..i]，按字符重写 mixup() 并把 strlen(first)>=14 折成 7，频道标题的 case / 门派长度改成字符数（对照 aoxiangtianji）。本库 汉字循环 / is_chinese 区间 2 个文件。证明（scripts/lpcc_eval.py）：sjplii 的 check_legal_name 在 HEAD 接受「张a」、改后拒绝，两边都接受「张三」；xkx100 的 clubpoem->mixup("离离原上草") 得到「离离原草上」（真交换汉字）；nitan_san 两字同盟名得到 【 兄 弟 】。关键对象加载通过。

血条 / 表情标题按字节算显示宽度（2026-10-23，KB 06 §7.365）

老档把汉字当两字节：bar_string[0..(val * N / max) * 2 - 1] 把「格数」换成字节下标，半格血条在本驱动（按字符算区间）上会整条画满；巫师表情 edemote 的 repeat_string("─", 13 - (strlen(emotion) / 2)) 也会少减汉字宽度。scripts/lpc_fix_display_pad.py：去掉 CJK 血条 / 空白条上的 * 2（jings/qis 赋值和 blank_string3[0..(23-a)] 的 23→11 一并改），表情标题去掉 / 2；ASCII 空格的 none_string / empty_string 仍保留 * 2（一格两个空格）。本库 5 处（2 个文件）。证明（lpcc_eval.py hhsj）：tribar_graph(6,9,12) 在 HEAD 画出整条 12 个■，改后为 6 个■+3 个□；麻将 strlen(tempB)/2 是两字符牌码，未改。

中文名 / 验证码仍按 GBK 取「两字节一字」（2026-10-23，KB 06 §7.373）

pname = pname[(random(sizeof(pname)) & 0xFFFE)..<1]; pname = pname[0..1]; 在按字符计下标时会取出两个汉字。scripts/lpc_fix_pname_slice.py 去掉掩码并把收尾改成 [0..0]（pname/pname2/sec_name/str/str1）。本库 8 处。证明：nt1 生成名长度 2–4；HEAD 常见 3–5。

对象路径残留 .c 后缀（2026-10-27，KB 06 §7.356 Also）

set("objects"/"exits", …) 与 __DIR__"….c" 在改名为 .lpc 后仍带 .c 时，new/load_object/房间 reset 找不到文件（血池房 inv=0）。凡旁有对应 .lpc 的，去掉 .c 后缀。证明：HEAD stone2 reset 后 inv=0；改后 inv=1（/d/youxia/obj/blood）。

段延庆 yanqing 无法加载（2026-10-27，KB 04 §6.25 Also）

kungfu/class_all/dali/yanqing.lpc：query("PKS) 缺引号、query_respect(ob)、嵌套 void init()，另有 gender) !== 笔误。按 pkuxkx 闭合 attempt_apprentice、并入 init 叛师检查，!==→!=。证明：HEAD 加载失败；改后加载成功。

深度功能测试（2026-10-27，§6.25 one-arg message_vision）

message_vision("…") 补第二参（me / TP / this_player()）。

深度功能测试（2026-10-27，§6.10 未知 pragma save_binary/optimize）

删除本库中 FluffOS 不认的 #pragma save_binary / #pragma optimize… 行。