Demon Angel II

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

ES2 血统代码库（作者自己的横幅致谢 Annihilator/ES2），游戏内标题为"葫芦Ⅱ/Demon Angel"（"泥潭中国简化版本"）。没有发现 mudlib bug——WASM 下开箱即用，全程零修改；is_chinese()/check_legal_name() 本来就是正确的码点判断，和本次会话处理过的大多数 ES2 衍生分支不同。管理员账号（fluffos/Mud@2026）通过真实注册流程 + adm/etc/wizlist 播种（格式已对照 securityd.lpc 的解析器核实，和本次会话处理过的其它 ES2 血统档案一致）——这个分支的 logind.lpc 把"目前权限："+ wizhood() 状态行显示注释掉当作死代码，所以在对话记录里看不到直接的管理员权限确认，只能从 wizlist 格式正确来推断。

深度功能测试（§10.7，2026-08-04）

此前只验证到注册流程本身，本轮原生 driver（端口 40122）走完了移动、 留言板、商店、战斗的完整会话，并且用真实读代码的方式核实了死亡/复活 系统不属于本项目已归档的 §7.68 类别。

主动检查（对照 AGENTS.md 已归档的 bug 类），发现并修复两个真实 bug：

• §7.34 printf 调试泄漏（新实例）：adm/daemons/logind.lpc get_name() 里，玩家刚输入完中文名字、还没设密码之前，有一行 printf("%O\n", ob);——每一个成功走到这一步的新玩家都会在自己的 屏幕上看到这个连线对象的原始 %O 表示（对象路径、内部字段等调 试信息），是典型的开发期调试输出直接留在了正式登录流程里。已删 除。
• 原始档案自带的字符串损坏（新发现，非转码问题）： adm/daemons/chard.lpc 里骸骨尸体的命名 ob->set_name("一具枯\ 干的骸骨", ...) 在"枯"和"干"之间多了一个游离的反斜杠，编译时报 warning: Unknown escape sequence。用 Python 直接读取 raw 归档 的原始字节核实过——这个反斜杠字节确确实实存在于原始压缩包里（不 是本项目转码流程引入的），推断是原作者当年编辑时的手误。已改回 "一具枯干的骸骨"。

确认不是 bug 的检查项：

• init_new_player() 里 user->set("food", ...)/user->set("water", ...) 两行确实被注释掉了，但和它紧挨着的 potential、以及 enter_world() 里的"目前权限："显示行是同一批被原作者一起注释掉 的行——是这个分支一贯的、成组的功能精简风格，不是 §8.9 那种"查询 了错误对象的 age 导致条件永远为假"的判断失误，本身就没有任何 age 判断逻辑，不在本项目的 bug 修复范围内（游戏内容/平衡决定）。
• command_hook（feature/command.lpc）已经是 nomask，是此前 "Systematic sweep" 那一轮已经处理过的。
• 全文搜索未发现任何 MESSAGE_D-> 调用。
• 死亡/复活系统读代码确认干净，不是 §7.68：feature/damage.lpc 的 die() 只用了一次性的 call_out("delay_move_recall", 13 + random(3), this_object());——不是像其它档案那样"判官/无常"式的 多阶段、需要反复 present(ob) 判断才能继续的对话链，delay_move_ recall() 到点直接无条件把玩家从死亡室移回 START_ROOM，没有任 何可能永久卡死的分支。DEATH_ROOM 宏指向的 /d/special/death.lpc 文件确实存在（不是 §7.75 那种宏指错文件的情况）。玩家被系统 disable_player() 期间无法自行 quit 打断这个流程，进一步降低 了永久卡死的可能性。这类"结构上就不会卡死"的死亡系统在本项目已 处理过的 ES2 血统里是第一次遇到，值得作为反例记录。

完整游玩记录： 1. 用真实中文名"沈牧"（id shenmu）注册成功，落地"中央广场"（葫芦 城），场景里有真正可读的留言板（"留言板(Board)"）和 NPC"小美 女"。 2. 移动：中央广场→西大街→西大街（内部两间不同描述的分段房间）→ 西城门（死路，唯一出口 east）→中央广场→南大街→中央广场→北大 街（recall_n_1）→北大街（recall_n_2，出现真正的商人 NPC）。 沿途确认这批"XX大街"房间是多段拼接的独立房间文件（不同段描述文 字不同），不是同一个房间的重复输出。 3. 留言板测试：read 1 成功读出一条真实的、带分页器的长留言（标 题"给拿到本 MudLib 的人"，作者 bor），分页器的 ENTER/q/b 翻页逻辑正常。 4. 商店测试：北大街的商人（d/gourd/npc/mob1.lpc，inherit MISC_SHOP_NPC）list 正确显示"马豆"和"普通药水"两样商品及库 存；buy bean（注意命令格式是 buy <物品名>，不需要 from <商人>）在零金币情况下被正确拒绝（"你的钱不够。"）。 5. 战斗测试：kill man（商人）触发正常的回合制拳脚对轰，双方都是 1 级新手（con 相同、无武器），大量交换但双方命中率/伤害都极 低（score 显示"最小伤害力 1"），这是新手无武器徒手数值偏低的 内容/数值现象——本次测试没有让任一方在合理时间内真正死亡，改用 代码走读的方式确认了死亡系统本身的实现（见上方）。整场战斗 debug.log 全程没有任何错误。 6. 未能找到"国家制度"玩法（cmds/king//cmds/min/）的可达入口—— 新手初始身份是"冒险者"，购买/继承国家需要走 d/gourd/buy_kingdom.lpc 等专属流程，本轮测试预算内没有深入这 一部分，留给后续更长的会话。

结果：整个测试会话（含一次修复后重启验证）debug.log 全程为 空，没有任何真实的 error:/Bad argument/No program/Too deep recursion 记录。测试角色存档（data/{login,user}/s/）保持未跟 踪；测试期间因为 driver 常驻产生的国家系统共享存档 open/sky/kingdom_data.o 的周期性 churn 已在提交前还原，未计入本 次改动。两处代码改动已用 formatter 校验（{"errors":0}）。

第四轮深度测试（round-four，2026-08-20）

本轮专门补齐第一轮明确留白的两项：国家制度（cmds/king//cmds/min/） 和真实战斗死亡，并顺手对标准 bug 清单做了一次全新（非复查）扫描。

测试帐号：fluffos/Mud@2026 此前只在 adm/etc/wizlist 里被 "播种"过，本轮开局才发现 data/{login,user}/f/fluffos.o 从未真正存 在——第一轮 meta.json 里"管理员账号通过真实注册流程...播种"的说法 其实是推断，不是已完成的动作。本轮走了一次真实注册流程创建了它， score 确认 wizlist 授权生效（goto/call 等巫师指令可用）。这 个帐号按本项目惯例保留（帐号存档已 git add），不是一次性测试角色。

国家制度（buy_kingdom / cmds/king / cmds/min）

• /d/gourd/buy_kingdom.lpc 是一个孤儿房间：全档案搜索确认没有 任何 exits 指向它（d/gourd/recall_s_w.lpc 是一个几乎相同但独 立、不连通的旧版本，本身也没有路通向它），普通玩家在地图上正常 走是永远走不到"买国家"这个房间的——这是第一轮"未能找到可达入口" 的确认与解释，不是新问题，也不打算修（内容/地图连通性决定，不 是编译错误或运行时错误）。用 goto /d/gourd/buy_kingdom 直接传 送过去后，指令本身完整可用。
• 走通了建国全流程：buy_kingdom 测试王国 shice 成功建国（金 钱门槛在原始码里就已被注释掉，buy_kingdom_build 临时旗标门槛也 被注释掉，本身就不需要额外用巫师工具满足前置条件），玩家称谓从 "新手" 变成 "国王"，被自动传送到新生成的王座房 /open/shice/kingdom。
• 验证过的 cmds/king/／cmds/min/ 指令：set_tax 10（成功， 全国频道广播）、kingdom_stat（完整输出国库/税率/人口/房间/武器 /防具等统计）、makeroom north（成功建出新房间并可以正常 north/south 往返，房间内容干净、debug.log 零告警之外的输出）、 build tavern east（被"贵国房间数未达到 15 无法设置"正确拒绝—— 这是设计好的门槛，不是 bug，本轮测试预算内没有再建 14 间房去解锁）。 appoint/teleport/fire 需要第二个同国玩家才能测，本轮没有再 开一个账号去覆盖，其余国王/大臣指令通过读码确认权限门槛（kingdom/id 相符）是自洽的。
• 发现并记录（非编译/运行时错误，不修）：check_legal_name() （buy_kingdom.lpc 与其孤儿姐妹档 recall_s_w.lpc 共用同一段代 码）的长度校验 strlen(name) < 4 || strlen(name) > 12 是按"每个中 文字 2 字节"的旧编码假设写的（配合提示语"2 到 6 个中文字"）。这 个 driver 的 strlen() 是按 Unicode 码点计数，不是按字节——实测 3 字（如"测试国"）被拒绝，4 字（"测试王国"）能通过，说明实际生 效的门槛其实是"4 到 12 个中文字"，把历史上很常见的 2-3 字国号 （"大唐"、"大宋"）全部挡在门外，还允许最长 12 字这种怪异长名。 这属于验证消息不准/门槛偏移，不是崩溃、不是 debug.log 错误、也 没有卡死或状态错乱，按本轮范围规则归类为观察记录，未做修改。

真实战斗死亡

• 用巫师 call 指令把测试角色 hp 打成负值 （call me->receive_damage("hp",999,man)，man 是北大街商人 NPC），走的是真实的伤害应用函数 feature/damage.lpc:receive_damage()， hp 变负后由 std/char.lpc 的 heart_beat()（if (query_hp() < 0) { ...; die(); }） 在下一个心跳自然触发 die()——不是直接调用 die()/smash 那种 跳过真实检测路径的写法。
• 完整死亡→复活链路全部走通且live 确认（第一轮只读码确认过结构上 不会卡死，本轮是第一次真正跑通）：die() 正确设定尸体 （法炉师的尸体）、把 hp/mp 重设为 30、移动到 DEATH_ROOM （/d/special/death.lpc）、调用 disable_player()（此时任何指令 都收到"什么？"，玩家确实无法自行打断），13～15 秒后 delay_move_recall() 的 call_out 触发，自动把玩家移回 START_ROOM（中央广场）并 enable_player() 恢复指令。全程 debug.log 除了既有的编译期警告外没有任何 error:/Bad argument 等真实错误。

§7.100 全新命中并修复（本档案此前从未被扫描过，低于 100 次的语料库扫描门槛）

grep -c "replace_program(ROOM)" 只有 49 次（其它宏如 HERB_SHOP/ GATE/TAVERN/SMITH 等还有更多），远低于当时 corpus 扫描用的 100 次门槛，因此完全没被那 166 库的批量扫描覆盖到，是本轮第一次真 正检查。确认全部 87 处都是"inherit X; 后又在 create() 里多余 自我 replace_program(X);"的标准 §7.86/§7.100 形状（含 obj/board/wizard_j.lpc 这个真正的留言板实例，和 §7.86 原始症状 完全一致：inherit "/std/jboard" 后又 replace_program("/std/jboard")， 而 jboard.lpc 的 post/回帖流程恰好用闭包 (: done_describe_project, ... :) 绑定 input_to，是典型的"迟早会撞上闭包绑定就崩"的地雷）。

用二进制安全的脚本按"每文件对应的 inherit 目标"精确删除了 87 处独 立房间/建筑档案里的多余调用，另外手工修掉了 4 处把同样毒瘤写进"造 房子"生成模板字符串里的工厂档案（这样以后用这些工具新建的房间不 会带着地雷出生）：

• obj/roommaker.lpc（mkroom/saveroom 两个模板，巫师/玩家在 游戏内建房的工具）
• adm/simul_efun/kingdom.lpc（create_kingdom() 的王座房模板、 save_room()/minister 存房通用模板——直接关系到国家制度， 每个新建国家的王座房和后续用 min saveroom/min build 存下来的 房间都会带着这个地雷）
• cmds/min/build.lpc（大臣"build 特殊建筑"模板）
• cmds/min/makeroom.lpc（大臣"makeroom 造房间"模板）

共 91 个文件、96 处出现全部清理（另有 2 处 d/gourd/choice_class.lpc 和 d/gourd/recall_shop.lpc 里的调用本来就已经被 // 注掉，原样 保留未动）。修复后现场用 min makeroom/min build 亲自建了两间房 （其中一间成功、一间被房间数门槛正常拒绝），走进新建房间验证正常 加载、debug.log 没有出现 §7.100 特征的"cannot replace a program" 告警。

顺手修复：cmds/min/build.lpc 里 3 处原始档案自带的反斜杠损坏

和第一轮 adm/daemons/chard.lpc 那处"一具枯\干的骸骨"同一类损坏 （编译期直接触发 Warning: Unknown escape sequence，本轮修 §7.100 时在这个文件里现场读到的）：训练厅描述"有许\多人"、马厩描述"马厩\ ，"和"马厩\被"三处游离反斜杠，已按上下文改回正常标点（"有许多人"、 "马厩，"、"马厩被"）。语料库里还有其它 8 个档案有同样"许\多"/"厩\" 字样（combatd.lpc、feature/liquid.lpc 等），但本轮只修了实际测 试路径上现场读到警告的这一处，其余留给未来专门扫描，不在本轮范围 内主动展开。

标准 bug 清单全新排查结果（本档案此前未被任何一次语料库扫描覆盖）

• §7.90（eval cost）：config.fluffos 已经是 maximum evaluation cost : 5000000，无需修改。
• §7.79（裸 addn/addn_temp 2 参数调用）：全档案 0 命中，不 是那个受影响血统家族（xfbhh/hhsj/nitan 系列），不适用。
• §7.111（standard_trace() 空 object 崩溃）：adm/obj/master.lpc 已经是 objectp(error["object"]) ? file_name(error["object"]) : "(driver)" 的写法，本来就是安全的，无需修改。
• §7.112（init() 里无条件 call_out 链，reconnect 触发重复调 度）：全档案排查了所有定义 init() 且带 call_out 的文件（都 是店铺/婚礼/发誓/训练室这类靠 add_action 注册指令的房间型 init()，call_out 都挂在玩家指令触发的处理函数里，不是 init() 本身直接排程），std/char/npc.lpc 完全没有 init()/ call_out，NPC 基类本身不存在这个模式，不适用。
• §7.113（reconnect 不恢复 heart_beat）：obj/user.lpc 的 reconnect() 已正确调用 set_heart_beat(1)，net_dead()/ reconnect() 配对完整，不适用。
• §7.114（private input_to 字符串回调经 mixin 失效）： feature/edit.lpc 用的是闭包 input_to((: input_line :), ...) 而不是字符串名 input_to("input_line", ...)，且 input_line() 本身没有 private 修饰——架构上和 §7.114 的成因完全不同，不适用。
• §7.115（QUEST 宏指向不存在文件）：全档案没有 QUEST 宏定 义，不适用。

清理

open/shice/（测试国家的房间、kingdom_data.o 等）、 data/{kingdom,nuke/kingdom}/shice/ 全部删除；测试账号 fluffos 的 kingdom/home/cwd 属性已清空并显式 save()，hp/mp 重设为满值 并 save()（战斗死亡测试用 call 把 hp 打成负值后，die() 虽然 在内存里正确把 hp 复原到 30 并持续自然回血，但期间没有任何一次显 式 ->save()，driver 关闭前的最后一次磁盘落地反而是负值——这是测 试方法本身的副作用，不是死亡/复活系统的 bug，已经手工修正并确认 后续重连不再触发误报死亡）；测试遗留的尸体对象已用 dest 清除； git checkout 还原了测试期间因 driver 常驻产生的两处共享存档周期 性 churn（data/chinese.o、open/sky/kingdom_data.o，后者的字段 重排序/sky 王国自身经济模拟数值漂移，和第一轮记录的同一份文件同 一种 churn）。

结果：本轮修复的所有文件均在真实 build-debug driver 上验证 过干净编译和干净启动（debug.log 全程无编译警告之外的 error:）， 国家制度和真实战斗死亡两条主线均现场跑通。

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

• BOARD、BULLETIN_BOARD inherit + 多余 replace_program() 致命形状（AGENTS.md §7.86，post 命令崩溃）：全档案 15 处命中，其中含 1 处运行时代码生成模板（write_file() 动态生成新留言板源码的字符串模板里嵌了同样的致命形状，已同步从模板字符串中删除，否则玩家用该功能新建的留言板也会一出生就带病），已删除多余的 replace_program(...) 调用（保留 inherit），逐文件保留原有行尾格式（CRLF/LF 按文件原样）。本次为跨库 §7.86 扫描修复（触发原因：该 bug 已在 6+ 个互不相关的血统家族独立确认，属于近乎普遍的拷贝粘贴模式），仅做编译检查（驱动干净启动、端口正常监听），未做完整 §10.7 深度游玩测试。

§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): 3 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.

§10.7 deep functional test, round three (2026-09-01): genuine two-account multiplayer nation testing

This pass deliberately covered the angles the two prior passes explicitly left untested: a SECOND real player account interacting with the king account inside the nation system (appoint/teleport/fire), currency persistence across a real quit+reconnect, adversarial/malformed kingdom-system input, and a real board post. Standing admin account fluffos/Mud@2026 played the king; a brand-new throwaway account xiaolong/王小龙 (deleted afterward, not committed) played the citizen/minister. Native driver on port 40122, driven via a two-socket Python script (not committed, scratch-only), debug.log checked after every state-changing command.

Two real bugs found and fixed, both verified live:

• §7.11 instance (missing /log/nosave/ directory): adm/simul_efun/ file.lpc's log_file() was the exact same "unguarded write_file() sitting next to its own already-correct, unused assure_file() helper" shape documented dozens of times elsewhere in AGENTS.md §7.11. Live-triggered on the very first wizard call targeting the second player (call xiaolong->move("/open/ceshitwo/kingdom.lpc"), used to physically place the second account into the orphan throne room since no walkable exit reaches it — see round-four's notes above): *Wrong permissions for opening file /log/nosave/CALL_PLAYER for append. "No such file or directory", thrown from call.lpc's own audit-log line BEFORE it ever reached call_other(), so the wizard tool completely failed to affect another player object at all, every single time. Fixed identically to every other instance of this bug class: forward- declared assure_file() and called it immediately before the write_file() in log_file(). This simul_efun.lpc is #include- based (not inherit-based), so — like fy2005's instance — the fix required a full driver restart to take effect, not a hot update. Verified live post-restart: the identical call now succeeds (/obj/user#N ("王小龙")->move(...) = 1), and /log/nosave/ CALL_PLAYER is created on demand with no further crash on any later call in the session.

• NEW bug, not previously seen in this corpus: cmds/king/fire.lpc's offline-target branch (load_player()) can NEVER succeed, because it incorrectly gates on userp(ob), which is structurally always false for a load_player() result. fire <大臣> first tries find_player(arg); if the minister is offline it falls back to flag = -1; ob = load_player(arg); — a bare new(LOADUSER_OB) clone that reads the target's save file directly, specifically so a king can fire a minister who isn't currently connected. But the very next line, if (!userp(ob)) return notify_fail(ob->name() + "他不是玩家。\n");, rejects it unconditionally: userp() per this driver's own doc ("如果参数物件曾是互动物件，传回 1") reports whether an object has EVER been a real interactive connection, and a load_player() clone never is one — it's a pure in-memory data-reader, by design, never exec()'d to any socket. So this check silently aborts the whole offline-fire attempt before it ever reaches the actual kingdom_data(...,"power","sub","minister",...) removal or destruct(ob) cleanup, with a confusing message that implies the target isn't a real player when they demonstrably are (just offline). Confirmed this is a copy-paste/logic mismatch specific to this file by comparing sibling commands that use the identical find_player()-else-load_player() pattern: cmds/min/banish.lpc has NO userp() check at all on its load_player() result (works correctly offline), and cmds/min/arrest.lpc's only userp() check sits on a completely different, online-only code path (its pardon branch), never applied to its own load_player() result. Fix: gate the check on flag == 1 (i.e. only require userp() when ob actually came from find_player()) — if (flag == 1 && !userp(ob)) .... Verified live end-to-end, twice: (1) fired a minister who had just abruptly disconnected (TCP close, not quit — still "net-dead" but not destructed) succeeded even on the UNFIXED code, because userp() is true for life once an object has ever been interactive, confirming the bug is specific to the fully-offline load_player() path, not net-dead players; (2) after hot-updateing this file (an ordinary inherit-based cmds file, unlike the simul_efun fix above), re-appointed the same test citizen as minister, had them run a real quit (full destruct, no in-memory object left at all), and fire xiaolong from the king then correctly succeeded — the correct channel broadcast fired, and the target's on-disk save file confirmed kingdom/minister and home both removed while kingdom/id (ordinary citizenship) was correctly left intact, exactly matching the command's intended "demote minister to citizen" semantics. This is a new bug shape for this corpus (not seen in prior §7.x entries) — filed as a candidate for its own AGENTS.md catalog entry if it recurs elsewhere, but not enough evidence yet of a shared-lineage sibling to justify a corpus-wide sweep on its own (this lib has no confirmed close siblings).

Confirmed clean / no bug found, despite active testing:

• Cross-player appoint/teleport both worked correctly once both accounts were physically brought into the same room (teleport doesn't require same-room, only same-kingdom + a valid environment; appoint/accept/join all use present(arg, environment(me)) and correctly require it). One non-bug trap worth recording: founding a kingdom does NOT change where enter_world() places you on your next login — adm/daemons/logind.lpc's enter_world() always uses user->query("startroom"), never home, so a king who reconnects lands back at 中央广场 (their fixed spawn point) every time, not their throne room. This is exactly what cmds/min/home.lpc's home command is for (confirmed by its own help text: "国王与大臣用的瞬间传送指令, 可以传送回自己的家"). Cost real test time the first attempt (chased a false "king and citizen are in different rooms" symptom before realizing home was simply never invoked after reconnecting) — worth remembering for any future session testing this lib's kingdom system.
• Currency persistence across a real quit+reconnect: the actual economy currency (the gold/bank_gold numeric character properties, read by score and by feature/finance.lpc's pay_money()/deposit_bank()/withdraw_bank()) persists correctly. Funded a test citizen with call xiaolong->add("gold",777), confirmed score showed 777, did a real quit, reconnected, and score still showed 777. This lib's std/money.lpc — the PHYSICAL coin object class — was also checked per this session's explicit brief (the sibling fysjmb/§7.199 "query_autoload() commented out while autoload() stayed live" shape): not applicable here, query_autoload() is fully active (string query_autoload() { return query_amount() + "";}, not commented out). Separately (not a bug, a design observation): physical coin objects you're merely carrying (not equipped) DO get lost on quit — but this is because cmds/usr/ quit.lpc's main() explicitly, unconditionally drops every non-equipped() inventory item for any non-wizard player before saving (if (!wizardp(me)) { ... if (!inv[i]->query("equipped")) DROP_CMD->do_drop(me, inv[i]); }) — a deliberate, internally consistent design choice (matches §10.7's "death dropping items" example of a non-bug) applied uniformly to ALL unequipped items, not a money-specific persistence bug; the actual currency wallet bypasses this entirely since it's a character property, not an inventory object.
• §7.19-class NPC init() reentrancy via enable_commands()/ enable_player() from a room's setup()/reset_me(): not applicable. Full-tree grep found only two enable_commands() call sites in the whole lib (obj/user.lpc's own player-login path and feature/command.lpc's command_hook() mixin) — no NPC in this lib calls enable_commands() itself, so the reentrancy shape this bug class depends on structurally cannot occur here.
• Adversarial/malformed kingdom-system input, all handled cleanly, no debug.log errors: appointing a nonexistent player, fireing yourself, fireing the king, a second buy_kingdom from an already-kinged player (建国必须平民才行), negative/non-numeric/ absurdly-large set_tax values (-10, abc, 999999999999999999999 — all correctly rejected by the existing 5–50% range check, no overflow crash), and — via a third throwaway account at the (unreachable-by-normal-walking, goto-only) buy_kingdom room — too-short Chinese kingdom names, a 30-character Chinese name, a 100-character English id, uppercase letters in the English id, and an embedded space in the English id. Every case was rejected with the expected in-game message and zero uncaught errors.
• Real board post+read round-trip: posted a real multi-line message via the line editor (post <title> → lines → . to finish) to the central-plaza board, confirmed it appeared in read new alongside the original archive post, and confirmed ~q correctly cancels a post-in-progress (including with a 200+ character title) without creating a stray entry. The test post itself was reverted (git checkout) before committing, since it was pollution on a board every real player sees, not evidence worth keeping.

Cleanup: driver restarted once mid-session to pick up the #include-based simul_efun fix (§10.9-documented debug.log-goes-dead convention followed: log inspected via work/log/debug.log after every state change, both before and after the restart). Test kingdom ceshitwo (work/open/ceshitwo/, work/data/{kingdom,nuke/kingdom}/ ceshitwo/) and both throwaway accounts (xiaolong, and a third validation-only account ceshimin that never actually founded anything) deleted, not committed. fluffos's kingdom/home/cwd/ cwf properties cleared and hp/mp reset to full via explicit set() + save() (a testing mistake along the way — first attempt used a wizard call me->set("hp", me->query("base_hp")), which the call command's own simplistic argument parser treats as a literal string, not a nested expression, corrupting hp/mp into a broken string that then crashed heart_beat()'s >= comparison every tick; caught via the very same debug.log-after-every-command discipline this methodology requires, and fixed immediately with plain integer literals instead — recorded here as a reminder that this driver's wizard call command does not evaluate nested -> calls in its arguments). Ambient save-churn from this session (data/chinese.o's kingdom-name lookup dict gaining a stale ceshitwo entry, open/sky/kingdom_data.o's known pre-existing periodic economic-simulation drift, login-timestamp noise) reverted via git checkout before committing; only the two real .lpc fixes plus fluffos's own cleaned-up save file are included in the commit. A final fresh driver boot + login/score/look/ quit cycle confirmed a clean debug.log throughout.

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

scripts/lpc_fix_negative_ranges.py: 6 line(s) in 3 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-05）— tail() simul_efun

scripts/lpc_add_tail.py --apply: cmds/wiz/tail.lpc calls tail(file), an efun of the MudOS this archive ran on that FluffOS does not have (Undefined function tail: the command did not compile). adm/simul_efun/file.lpc now defines void tail(string file): the last 10 lines of the file, written to the player. Load check (HEAD against the working tree): 1 of the 1 tail command file(s) failed to load at HEAD, all load now, and the simul_efun file loads. KB 04 §6.2.

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

scripts/lpc_warnings.py gjzddmudda --fix 加 scripts/lpc_fix_no_effect.py --apply，共改动 154 个 .lpc。HEAD 与工作树分别加载（新进程）：142 -> 142 通过，无回退。

启动时警告 34 -> 0；新进程登录（新人物确认）正常。

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

scripts/lpc_twin_port.py adopt demonangel gjzddmudda 搬来 demonangel 同日整理（8f6d5cc3823）的改动，与本库逐 token 相同，能编译的文件警告清零；改动的对象在 HEAD 与工作树各载入一次，regress 0。

• std/char.lpc 同时继承 F_ATTRIBUTE 和 F_DAMAGE，两者的 query_hp/query_mp/query_base_hp/query_base_mp 一字不差；写明用驱动原先选的 damage:: 版本。
• include/net/ftpdsupp.h 的 check_access() 只在 #ifdef GUEST_WIZARD_FTP 分支用 file，声明移进该分支。

• 2026-10-14：新驱动（FluffOS 970d9f09）报 Float value truncated to int（#1426）。1 个文件 1 处：赋值、初始化、return 改写成 to_int(...)（值不变，只是写明截断）。改动的对象新进程各载入一次，无回退（scripts/lpc_fix_float_trunc.py，KB 04 §6.10）。

去掉的预定义宏 SAVE_EXTENSION（2026-10-18，KB 04 §6.11）

老版 MudOS 给每个 LPC 对象预先定义了 SAVE_EXTENSION（".o"）；FluffOS 的 ChangeLog（COMPAT_BUSTER 一条）把它删了，改用 __SAVE_EXTENSION__。本库没有自己 #define 这个宏，用到它的文件一律 Undefined variable 'SAVE_EXTENSION'，整个对象载入不了。改成 __SAVE_EXTENSION__（scripts/lpc_fix_predefined_macro.py）：adm/daemons/network/netmail.lpc、include/net/ftpdsupp.h、obj/token.lpc。token 是帮派领袖信物；netmail 是网络邮件守护进程（本库缺 mailer.h 等头文件，改后仍载入不了）。改后用 lpcc 逐个载入这些对象：1 个通过，1 个还有别的错误（adm/daemons/network/netmail：/adm/daemons/network/netmail.lpc:21: error: Cannot #include mailer.h）。

cmds/min/develop 里 "马厩\",（2026-10-18，KB 03 §4.6）

"stable" : "马厩\", 的收尾引号前多了一个反斜杠，把引号转义掉了，字符串连到下一行，命令载入不了。去掉反斜杠。载入：通过。

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 载入不了，刷出它的房间也少一个人。本库有 1 个对象设了本库没有文件的武功（1 个名字，最多的是 move）。三处都改成 return：这一门武功不给、不映射，对象照常载入，只是少了它（缺的武功本身仍是内容缺口）。抽样载入这些对象：1 个里 1 个通过。（scripts/lpc_guard_set_skill.py）

找不到父类函数的 ::fn() 调用（2026-10-19，KB 06 §7.259）

/adm/daemons/virtual/template/room.lpc共 1 个物件里写着 ::create();、::init(); 这类调用，而它们继承的基类并没有这个函数。老驱动把这种调用当成什么都不做、返回 0 的空调用，本驱动在编译时报 Unable to find the inherited function 'init'.，整个物件载入不了。这些物件的错误只有这一种（其他错误清掉之后才露出来的），逐个删掉这些调用（return ::fn(...) 改成 return 0;）。（scripts/lpc_fix_dangling_super.py）

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

adm/daemons/rankd.lpc 的 query_respect()、query_rude()、query_self()、query_self_rude() 里 4 个函数开头补上 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 文件。

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，共 1 处）。改动：/adm/daemons/fingerd.lpc（1 处）。

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

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

sefun cat()：缺文件时 write(0) 报错（2026-10-20，KB 06 §7.297）

void cat(string file) { write(read_file(file)); }：文件不存在（压缩包没带的欢迎/公告文件，或只有运行中的 mud 才会写的日志）时 read_file() 回 0，write(0) 在本驱动里报 Bad argument 1 to receive()，调用者（登录对话、cat 指令）被中断；老驱动什么也不打印。改成 write(read_file(file) || "");（scripts/lpc_fix_cat_unchecked.py）。改动：/adm/simul_efun/file.lpc。

翻页器 start_more(read_file(...))：文件缺失时 explode(0)（2026-10-20，KB 06 §7.300）

东方故事系的翻页器 void start_more(string msg) { ... explode(msg, "\n") ... } 被这样调用：start_more(read_file(HELP_DIR + "help/topics"))、start_more(read_file(NEWS))。压缩包没带的文件使 read_file() 回 0，explode(0, ...) 在本驱动里报 Bad argument 1 to explode()（不带参数的 help 指令就是这样出错的），老驱动把 0 当空文本。在 start_more 开头加了 if (!stringp(msg)) return;（scripts/lpc_fix_start_more.py）。改动：/feature/more.lpc。

NPC 的 chat() 在 chat_msg 为空数组时下标越界（2026-10-21，KB 06 §7.334）

NPC 基类的 chat() 是 if (arrayp(msg = query(...))) { if (random(100) < chance) { rnd = random(sizeof(msg)); if (stringp(msg[rnd])) ...，不检查列表是否为空。本库现有的 NPC 文件里没有字面写成空 chat_msg 的（扫描只认 set("chat_msg", ({ }))）；守卫挡的是运行时才为空的列表和以后新增的 NPC。在 random(100) < chance 前面加 sizeof(msg) &&（scripts/lpc_fix_chat_empty.py；if (random(100) > chance) return 0; 的写法是 !sizeof(msg) ||）。改动：/std/char/npc.lpc（共 1 个文件）。

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

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

巫师命令不带参数时对 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 与工作树对照，没有退步。

长度检查按字节写，旁边的提示按汉字写：8 处（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 你好吗）。本库 8 处（4 个文件）：if ((strlen(name) < 2) || (strlen(name) > 12)) {（/adm/daemons/logind.lpc:448）；if ((strlen(name) < 4) || (strlen(name) > 12)) {（/cmds/usr/chfn.lpc:39）。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 区间 6 个文件。证明（scripts/lpcc_eval.py）：sjplii 的 check_legal_name 在 HEAD 接受「张a」、改后拒绝，两边都接受「张三」；xkx100 的 clubpoem->mixup("离离原上草") 得到「离离原草上」（真交换汉字）；nitan_san 两字同盟名得到 【 兄 弟 】。关键对象加载通过。

blue_cloth F_CLOTH → BODY（2026-10-27，KB 04 §6.25 Also）

d/obj/npc/wp/blue_cloth 写 inherit F_CLOTH，本库无该宏。改为本库的 inherit BODY，护甲 2 写入 armor_prop/armor。证明：HEAD 失败；改后加载成功。

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

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