Eastern Story II v1.3b

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

ES2 血统代码库（台湾，1994-2000，Annihilator），繁体中文。重大编码发现：最初的 convert_lib.sh 转档流程把这份档案当成 GB18030 解码——GB18030 几乎涵盖所有字节序列，即使这份档案实际是 BIG5 编码也会"成功"解码，只是产生完全的乱码（落在注音符号 Unicode 区段的垃圾字元，比如 BIG5 本该解码成"使用者"的地方变成了"ㄏノ祅祘"），而不是一个转换流程可以拦截到的解码错误。已改用 BIG5 重新跑一遍完整的 raw->work 转换（套用前先用 Python 对照 big5/gbk/gb18030/cp950 四种编码试解码原始 .c 档案，确认 BIG5 才是正确答案）。另外还需要：（1）master.lpc 的 connect(int port) 用 switch 比对一个写死的 MUD_PORT（4000，泥潭原始默认值），而不是本项目实际分配的端口（40144）——不管在不在 WASM 下，每一个连线都会被拒绝（驱动记录："Can not accept connection ... due to error in connect()"），已改为更新 MUD_PORT 宏；（2）master.lpc 的 valid_read/valid_write 递归呼叫 load_object(SECURITY_D) 却没有防递归机制——经典的 §7.1，第一次真正的安全检查就触发"Too deep recursion"，已用文档记载的防递归旗标手法修复；（3）adm/daemons/userid.lpc（identd/RFC1413 反查服务，纯 socket 功能）按 §7.52 掏空处理；（4）is_chinese() 的经典 GBK 字节配对判断（要求 strlen>=2）在 Unicode 码点模型下会拒绝单字符或奇数长度的名字切片——已改成 CJK 码点区间判断。重新套用了一个之前已提交、但这次 BIG5 重新转换（从 raw 重新生成 work/）不慎覆盖掉的原生修复（移除一个和这个驱动自动预定义的 MUD_NAME 冲突的 #define MUD_NAME，§7.39）——先查过 git 记录确认那次提交还动过什么其它地方，只有 globals.h。管理员账号（fluffos/Mud@2026）通过真实注册流程 + 全新创建的 adm/etc/wizlist 播种（原始压缩包里没有附带这个档案）。

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

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

深度功能测试 / Deep functional test (AGENTS.md §10.7)

先读 README 和本文件（WASM 修复摘要已确认之前一轮播种了 fluffos/Mud@2026 管理员账号，透过真实注册流程建立）。本档案的名字本身就是「東方故事II」， 经内容比对（d/snow/ 只有一个「雪村」示范村，没有门派/公会系统，doc/help/ topics/ 是空目录，cmds/std/ 没有 join 指令）确认这很可能就是 AGENTS.md §11 lineage map「ES II / 东方故事 mega-family」这一支的literal ES II 引擎 本身（不是某个分支重新命名的衍生品），kxkj/kxkj1/xkxz2/xiyouji/ rzrmud 等库的 feature/dbase.lpc 很可能都是从这里的同一份代码分叉出去 的——本轮的核心发现（见下）直接命中这份共享代码，值得作为标准清单条目提 醒后续同宗测试。

kxkj 血统先验 vs. 本档案实测结果（务必逐条核对，不要假设直接适用）

• 新手引导：不适用。本档案没有 8 项天赋点数分配、没有「狂想空间新手入 门房间」，注册流程是英文 id → 密码 → 邮箱 → 种族 → 性别 → 中文名字（与 README 已记录的一致），落地在 /d/snow/inn_hall（小客栈）。
• fight 的安全陪练分流：分流依据不同，但结论相容。本档案 cmds/std/ fight.lpc 判断的是 civilized 属性（不是 kxkj 的 can_speak），而 civilized 由 std/race/humanoid.lpc 的 create() 无条件设成 1，且 d/snow/npc/*.lpc 里目前唯一出现的种族是 human（set_race("human")） ——也就是说这个示范村目前没有任何非人形/非文明生物，fight 分支恒定安 全（点到为止），kxkj 提醒的「挑对象」问题在本档案暂时不构成风险，但 kill_ob() 真杀分支代码本身还在，未来加入动物 NPC 时要留意。现场用 fight child（d/snow/npc/child1.lpc，accept_fight() 恒定 return 1） 验证：形体全程 90/90→70/70 只随时间自然消耗，未见战斗掉血，"加油！加油！ 加油！"提示符合"点到为止"预期。
• join 公会 + apprentice 拜师两段式：不适用，机制不同。全档案没有 join 指令，cmds/std/apprentice.lpc 也没有 kxkj 那种 me->query("class") == ob->query("class") 强制关卡——直接 apprentice <对象> 由该 NPC 自己的 accept_apprentice() 决定要不要收徒。全档案只 有一个 NPC 实现了 accept_apprentice()：d/snow/npc/alchemist.lpc（陈 维侠，私塾 /d/snow/school）。现场验证：apprentice chen 前几次被随机 拒绝对白挡下，命中 set_flag() 后再次 apprentice chen 成功磕头拜师， init_apprentice() 设 class="alchemist"、title="龍圖丹派弟子"， score 面板称谓正确更新为「龍圖丹派弟子 王小明」。
• 管理员技能快捷指令：结论相同，仍然没有。搜遍 cmds/adm//cmds/wiz// cmds/imm//cmds/arch/ 未找到任何直接 set_skill()/improve_skill() 的管理员命令；本档案连 skillpass/skilldel 都没有（kxkj 有，这里没 有）。如实记录：本库同样没有技能快捷路径。
• quit 无新手宽限期：结论相同，且额外确认 quit.lpc 在 #ifdef SAVE_USER（include/login.h 里确实定义了）下会调用 me->save()——不同于 kxkj「quit 从不写存档、只有净断线才写」的既有发 现，本档案的 quit 会正常持久化状态（属性、称谓、位置除外——quit 后重新登入回到起始的小客栈，不是净断线时才回到的「上次所在位置」，这是 这份代码本身的既有设计：obj/user.lpc 的 reconnect() 才使用 last_location，quit 路径没有）。现场验证：apprentice 拜师后 quit，重新登入称谓「龍圖丹派弟子」与属性值都正确保留，只有位置回到小 客栈（符合预期）。另外用真实的原始 socket 断线（不送 quit，直接让连线 中断）模拟净断线，等待约 75 秒真实挂钟时间后重连，reconnect() 正确把 角色放回断线前所在的房间（广场/square_n）。

修复的程序性 bug

• feature/dbase.lpc 的 query()/query_temp() 对多层 "a/b" 属性路 径永远静默传回 0，与 AGENTS.md §7.29 是完全同一种 bug（已在该条追加本 库为第二个独立确认实例，附带诊断细节）：match_path() 是 ACL 风格的 「同层最长前缀比对」efun，不会像 set() 那样真的递迴钻进巢狀 mapping； 但 query()/query_temp() 原本直接对完整的 "exits/east" 呼叫 match_path(dbase, prop)，永远找不到 dbase["exits"] 这个巢狀 mapping 本身。现场用 call here->query("exits")（正确返回巢狀 mapping）对比 call here->query("exits/east")（返回 0）锁定问题。影响面极广： cmds/std/go.lpc 的 env->query("exits/"+arg) 恒定失败（"这个方向没有 出路"，玩家完全无法在房间间移动，游戏事实上不可玩）；alchemist.lpc 的 query_temp("pending/alchemist") 恒定读到 0（拜师流程的两段式确认失 效）；score.lpc/std/char.lpc 的 query_score()/query_target_score() 同样受影响。修复：把 query()/query_temp() 改成逐层递迴（比对 set()/ set_temp() 自己建出的真正巢狀 mapping 形状），不再依赖 match_path() 处理多层路径。已在两处补充中文注释说明成因。修复后现场复测：go/单字 母方向指令（e/s/w/n）全部正常在雪村地图移动，apprentice 拜师 两段式确认流程正常完成。
• std/char.lpc 的 rank() 在没有掛载对应 class daemon 时把 int 0 泄 漏进 score 的中文叙述句：daemond.lpc 的 query_daemon() 在找不到 对应档案时会回传自己（DAEMON_D 本身，一个真正的 object，objectp() 测不出来）而不是 0；DAEMON_D 没有定义 query_rank()，call_other 在 call other type check 关闭下不会报错而是静静传回 int 0，score 里 %s 格式化整数 0 变成字面上的 "0" 混进中文叙述（例如"你是一位十四歲 的 1 級男性人類0"）。这份档案本身就没有出货任何 daemon/class/*.lpc （register_class_daemon() 从未被任何文件呼叫过，grep query_rank 全档 案只有 std/char.lpc 自己的呼叫端，属于既有的内容缺口，不是本次要补的 游戏内容）——修复的是"呼叫一个不存在/没有该函式的 daemon 时静默漏出错误 类型数据"这个程序性缺陷本身：改用 objectp() + function_exists() 双 重检查，daemon 不存在或没有 query_rank 时比照没有 class 的角色，退回 纯粹姓名式的 ::rank()（与本档案原本处理"没有 class"时完全相同的分 支）。现场复测：score 不再出现字面 "0"，拜师后正确显示 "龍圖丹派弟子 王小明"。
• data/chinese.o 内嵌 13 处孤立反斜线，导致整个中文翻译词典 restore_object() 失败、to_chinese() 全面失效：chinesed.lpc 的 create() 呼叫 restore() 载入 dict 这份 mapping 存档，但档案里有 13 处形如 "...功\"," 的孤立反斜线（原始 1994-2000 年代 BIG5 档案本身带的 作者年代产物，和这一轮 BIG5 重新转换无关——同样的反斜线也大量出现在 .lpc 原始码字串里，例如 alchemist.lpc 的"陳維俠擺\了擺\手"，只是 LPC 编译器对字串常值里的非法跳脱只给警告并悄悄丢弃反斜线本身，不影响显 示；但 restore_object() 解析 mapping 常值时是严格模式，直接报 *restore_object(): Illegal mapping format while restoring dict.， create() 里未包 catch() 的 restore() 因此整个失败，dict 停留在 空 mapping ([])，之后所有 to_chinese() 呼叫都直接原样传回输入字串）。 现场用 call /adm/daemons/chinesed->chinese("human") 确认修复前传回字 面 "human"（应为「人類」）。属于 AGENTS.md §7.7（未防护的 restore() 遇到损坏存档）的一个新变体（这次损坏源头是资料档本身的位元组内容，不是 格式不兼容）。修复：用 tr -d '\\' 删掉全档案仅有的 13 个反斜线位元组 （档案里除了这 13 处不存在任何其它反斜线，逐一人工核对过每一处上下文， 全部是"XX功\"或"穀\衣"这种紧贴在字之间/字尾的孤立反斜线，没有任何一处 是合法跳脱如 \n/\" 的一部分）。现场复测：call ...->chinese("human") 正确传回「人類」，score 的种族/性别栏位正确显示中文。
• config.fluffos 的 maximum evaluation cost : 700000（AGENTS.md §7.90 已收录的项目模板默认值）在冷启动后第一次真正登入时不够用：全新 重启驱动后第一个连线（无论是哪个角色）触发 *Can't catch eval cost too big error.（logind.lpc:659 enter_world）以及后续 write_prompt 的 *Too long evaluation. Execution aborted.，角色被摆进保底的 /obj/void（"最後樂園"）而不是正 常的出生点，需要重新连线一次（此时相关档案已被前一次连线编译过、走过缓 存）才能正常进新手小客栈。已按 §7.90 的标准做法把 maximum evaluation cost 提到 5000000（本项目已有 30+ 库使用这个 值）。修复后现场复测：全新重启驱动 + 第一次连线（不是第二次），全程无 eval-cost 相关的运行时错误，debug.log 干净。

发现但判定为既有设计、未改动的现象

• fight.lpc 里"你對著$n說道﹕«自稱敬语»«自己名字»，領教這位«對方尊称» 的高招﹗"这句提示，在没有 class daemon 内容（见上）的角色身上会显示成 名字重复两次（例如"王小明王小明"）——因为 rank("self") 修好之后正确 退回到姓名式的 ::rank()，但 fight.lpc 这句提示原本假设 rank("self") 会返回一个独立的自称敬语（比如"小生"/"晚生"），不是名字 本身。这是"class daemon 内容本身没有出货"这同一个内容缺口的下游表现， 不是本次程序修复引入的新问题（修复前这个位置显示的是字面 "0"，同样不 正确，只是形状不同）；补齐敬语系统属于游戏内容而非程序缺陷，未改动。
• data/chinese.o 之外，.lpc 原始码里还有大量类似"某某功\"、"某某\了 某某"的孤立反斜线（编译期"Unknown escape sequence"警告），但因为 LPC 编 译器对这类跳脱只警告、悄悄丢弃反斜线本身、不影响实际显示或执行，比对 AGENTS.md §6.6"只在编译器/扫描实际标记出问题的地方手动修"的原则，未逐一 清理（只修了唯一真正造成功能失效的 data/chinese.o 那一处）。

WASM 未验证说明

按本 session 约定：emsdk 固定从 storage.googleapis.com 拉取，被本 session 出站代理策略拒绝，WASM 编译/运行验证本轮继续跳过，仅做原生驱动 （linux-debug 预设，ASAN/UBSAN）下的完整 §10.7 测试，全程 debug.log 干净 （仅编译期无害警告）。

Deep functional test round two (2026-08-14)

Independently re-verified against current code rather than trusting the round-one writeup above. Found and fixed one new bug (a real, live- reachable instance of AGENTS.md §7.10, not previously caught here); all 4 of round one's fixes re-confirmed live, not just via diff.

New fix: adm/obj/master.lpc's log_error() had no severity gate at all — broadcast every compile WARNING (not just real errors) to whichever player happened to trigger a lazy compile

Distinct from the more common §7.10 case-mismatch shape this session has been checking for ("Warning:" vs "warning:") — this lib's log_error() had no gate concept whatsoever:

// BEFORE:
if (this_player(1)) efun::write("編譯時段錯誤﹕" + message);
// AFTER:
if (this_player(1) && strsrch(message, "arning:") == -1)
  efun::write("編譯時段錯誤﹕" + message);

No wizardp() check either — this fires for whichever player is this_player(1) at compile time, which for a lazy first-visit room compile can be an ordinary player, not just a wizard running update. Live- verified the fix: update /adm/daemons/enterd (a file with a real, harmless "Unused local variable" warning, confirmed present in the boot log) now completes with only "成功。" on screen — pre-fix this would have dumped the raw compiler warning text at whoever was connected. The underlying write_file(home + "log", ...) call that persists the compile record has its own separate, lower-severity gap (no assure_file() guard on home, so the write can silently no-op if that wizard's log directory doesn't exist) — left alone this pass, out of scope: it doesn't affect players, isn't part of this session's established checklist, and touching it wasn't necessary to fix the actual player-facing leak.

Re-verified live: all 4 of round one's fixes still hold

• §7.29 dbase.lpc multi-level path bug (query()/query_temp() doing a flat match_path() instead of recursing into nested mappings, which made go/movement commands fail entirely via query("exits/east")): code-confirmed the recursive-descent rewrite is still present (the match_path(dbase, prop[0..r-1]) shape plus the explanatory Chinese comments), then live-confirmed by actually walking east from 小客棧 to 广场 as admin — worked cleanly, exactly the command path that was completely broken before the fix.
• std/char.lpc's rank() int-0 leak: code-confirmed the function_exists("query_rank", cd) guard is still present.
• data/chinese.o stray-backslash corruption (broke restore_object() for the whole Chinese dictionary): confirmed zero backslash bytes remain in the file, and live-verified via call /adm/daemons/chinesed->chinese("human") returning "人類" (not the raw "human" fallback the corrupted dict would have produced).
• §7.90 eval-cost bump (300000usec original config trips a "Can't catch eval cost too big error" on the very first cold-boot login): confirmed config.fluffos still has maximum evaluation cost : 5000000, and live-verified the FIRST login attempt after a fresh driver boot completed cleanly with zero eval-cost errors (not the second, which round one's own writeup noted was the only clean path pre-fix).

Standard checklist gap found and fixed

adm/simul_efun/file.lpc had the common §7.11-class gap: log_file() called write_file() with no assure_file() guard, and cat() had no null-guard on read_file(). Fixed both, matching the pattern applied across this session's other libs. No §8.9 food/water wrong-object read, no printf debug leak in logind.lpc.

Verification method

Booted native build-debug driver, admin login (fluffos/Mud@2026) — clean on the very first attempt (confirming the §7.90 fix). update /adm/daemons/logind and update /adm/daemons/enterd as real privileged- action checks. Two rapid consecutive admin reconnects, both clean. Driver killed by exact PID after testing; incidental fluffos.o/data/daemon.o save-timestamp churn reverted before commit.

Files modified this pass

• work/adm/obj/master.lpc — new fix: log_error() severity gate (§7.10-class, previously entirely absent).
• work/adm/simul_efun/file.lpc — log_file() assure_file() guard, cat() null-guard.

Round three deep functional test (2026-08-19)

Went deeper than rounds one/two, which only tested "safe sparring" combat and never pushed a character through an actual death. This pass did a full death→ghost→reconnect→admin-resurrect cycle, real economy transactions (buy from a vendor NPC), and re-checked the AGENTS.md checklist items current at the time of this session (§7.111, §7.112, §7.113, §7.90, §7.11 class, logind.lpc registration-save).

Checklist items — all clean, no action needed

• §7.111 (master.lpc's standard_trace() calling file_name(error["object"]) unconditionally): does not apply here — this lib's standard_trace() formats error["object"] with %O (sprintf), never calls file_name() on it at all. Different shape, not the same bug.
• §7.112 (gargoyle/judge-lineage death NPCs with unguarded call_out() chains in init()): find for the full filename list in AGENTS.md §7.112 found only d/snow/egate.lpc and d/snow/wgate.lpc present in this archive — both are plain gate rooms (inherit ROOM), not NPCs, and contain no call_out()/death_stage_active code at all. Not applicable.
• §7.113 (netdead reconnect never restoring heart_beat): checked the actually-invoked path — obj/user.lpc's reconnect() (called from LOGIN_D->reconnect()) does enable_commands() + set_heart_beat(1) + remove_call_out("user_dump") correctly. Verified live in round two already (rapid reconnects) and reconfirmed by code read this round; no fix needed.
• §7.90 (eval-cost): config.fluffos's maximum evaluation cost is still 5000000 (the round-one fix); confirmed clean cold-boot logins.
• §7.11 class (log_file()/write_file() into a runtime dir the archive never shipped): adm/simul_efun/file.lpc's log_file() still has its round-two assure_file() guard.
• logind.lpc enter_world()'s ob->save(): present and reachable (#ifdef SAVE_USER / user->save() right after setup(), before the startroom move) — a newly-registered account is saved immediately on first login, not silently dropped.

New fix: feature/npc/vendor.lpc's affirm_merchandise() corrupted

multi-word item names, breaking buy <item> from <vendor> for any item whose primary/full name has a space in it

Live-reproduced at /d/snow/herb_shop (the only working vendor NPC in this archive, 藥鋪掌櫃/Herbalist): buy pill from herbalist (single-word alias) succeeded, but buy black pill from herbalist (the item's actual full name, "black pill") always failed with the generic "對方好像不願意 跟你交易" decline — even though "black pill" is a directly registered alias on /obj/medication/black_pill.lpc. This is a live, easily-hit bug: a player who types the item's real name (as printed by list, e.g. "Black pill") rather than guessing a shorter alias gets a false rejection every time.

Root cause: affirm_merchandise() uses sscanf(what, "%s %d", what, index) to split an optional trailing item-index number (buy sword 2) off the item name — but LPC's %s stops at the *first* embedded space, not the last, so for "black pill" the match attempt sets what = "black" and then fails to parse "pill" as %d, so the overall sscanf() returns 1 (not 2). The old code only guarded the index variable on failure (if (sscanf(...) != 2) index = 1;) but never restored what, so the corrupted "black" was used for the subsequent item->id(what) lookup — which fails to match any of black_pill.lpc's aliases ("烏心丹", "black pill", "pill"), even though the correct full name was typed. Confirmed the exact sscanf() truncation behavior with a throwaway diagnostic wizard command (sscanf("black pill 1", "%s %d", what, index) → n=1, what="black" — even with a valid trailing index number it only manages to peel off the first word, not the whole multi-word name before it).

Fix: parse into a separate temp variable and only commit it to what when sscanf() actually matched both pieces (return value == 2); otherwise leave what untouched.

// BEFORE:
if (sscanf(what, "%s %d", what, index) != 2)
  index = 1;
// AFTER:
if (sscanf(what, "%s %d", base, index) == 2)
  what = base;
else
  index = 1;

Live-reverified after a fresh driver restart: buy black pill from herbalist now succeeds (money deducted, item delivered), and a subsequent purchase attempt that's correctly short on funds (buy wild ginseng from herbalist) now fails with the correct "你身上的錢不夠" (can't afford) message instead of the misleading "won't trade with you" one — confirming the item-name match itself now works and the failure path is the genuinely-intended one. debug.log stayed clean throughout.

Same buggy sscanf(arg, "%s %d", arg, index) != 2 → index = 1 idiom (without restoring arg/what on failure) also exists in std/room/hockshop.lpc's do_buy() and obj/clan_symbol.lpc — left unfixed this pass because neither is reachable from any room actually shipped in this archive's d/snow map (no hockshop room instance exists, and obj/CLAN is an empty directory) — a content gap, not a live bug here. Flagging in case either becomes reachable in a future content addition, or as a pattern worth checking on other libs that build on the same ES2-family feature/npc/vendor.lpc/hockshop.lpc lineage.

Deeper death-cycle testing (new ground, not covered by rounds one/two)

Forced a real death via call me->consume_stat("HP",9999) as admin (round one/two only ever tested harmless point-to-point sparring against a civilized child NPC, never an actual death). Full cycle exercised and confirmed clean end to end, debug.log empty throughout:

• Death correctly transitions life_form from "living" to "ghost" (CHAR_D->make_ghost()), with the expected in-game death message and stat-panel change (精/神 shown at reduced-but-full ghost values, 氣/kee row temporarily absent from score while a ghost — this is make_ghost()'s intentional clear_temp_dbase()/stat-remap behavior, not a display bug).
• As a ghost: look, movement (west/east), and say all work normally; inventory is correctly empty (nothing carried over).
• quit while a ghost, then reconnect: life_form correctly persists as "ghost" across save/restore (confirms ghost state isn't silently lost on disconnect/reconnect — a plausible failure mode this round specifically wanted to rule out).
• resurrect <name> (the only player-reachable-by-proxy revival path in this archive — see below) correctly flips life_form back to "living" and applies the intentional death penalty (kee/氣 30 → 27, matching chard.lpc's make_living()'s documented "corpse-less revival loses 10% of max" logic).

Content-gap finding, not a bug, left alone: the *only* code path that calls CHAR_D->make_living() (the ghost→living transition) in this archive is cmds/adm/resurrect.lpc, an admin-only command — there is no player-facing temple/prayer/NPC mechanism to self-resurrect in d/snow's content, and no hostile/non-civilized NPC exists there either (per round two's finding), so in practice a mortal player who somehow dies (there is currently no reachable way to, since all d/snow NPCs are civilized) would need a wizard to resurrect them by hand forever, or be killed again as a ghost to trigger LOGIN_D->reincarnate() (karma-based character reset). This matches the same "missing daemon/class content" gap class already documented in round one (no player-facing progression content shipped beyond the single demo village) — the death/ghost/revival *machinery itself* is sound and bug-free, it's just missing a player-reachable front door in this content-limited archive.

Board/guild system investigation — confirmed unreachable, but for a

benign content-gap reason (not a crash)

Tried board/list/post at /adm/guild/guildhall (the only bulletin board room this archive references) — all returned "什麼？" (unknown command). Traced this to guildhall.lpc's create() calling load_object("/daemon/board/wizard"), but /daemon/board/ doesn't exist anywhere in this archive (confirmed via update: "沒有 /daemon/board/wizard.lpc 這個檔案"). Since the board object never loads, its add_action("do_post","post") etc. never registers, so post/read correctly fall through to "unknown command" rather than crashing — graceful degradation, no uncaught error, debug.log stayed clean through this. /adm/guild/ itself is confirmed (again) to be the OOC wizard-workshop area (巫師公會/巫師學院/會議廳, all (admin)-flavored text about researching LPC), not a player-facing sect/guild system — consistent with round one/two's finding that d/snow ships no player guild/sect content. academy.lpc has the identical load_object("/daemon/board/lpc") gap. Not fixed: missing shipped file (content gap), not a programming defect, and it doesn't affect any player-facing system.

Verification method

Booted native build-debug driver fresh (debug.log removed first). Admin login (fluffos/Mud@2026). Tested: board/guild area (unreachable, traced to missing shipped file), store/herb_shop economy exploration (list correct), real buy transactions (multi-word bug found + fixed + reverified), full death→ghost→quit→reconnect→resurrect cycle (twice — once pre-fix baseline, once post-fix on a fresh restart). Used a throwaway wizard diagnostic command (cmds/wiz/sstest.lpc) to directly confirm sscanf()'s truncation behavior; deleted before commit, not part of the mudlib. Driver killed by exact PID after testing (single SIGTERM sufficed, no respawn this time). Incidental .o save-timestamp churn on data/daemon.o and the fluffos login/user saves (from cloning test money/items and the death/resurrect cycle) reverted via targeted git checkout -- before commit; boot.log and work/log/debug.log (gitignored scratch) removed.

Files modified this pass

• work/feature/npc/vendor.lpc — affirm_merchandise(): don't let a failed sscanf("%s %d", ...) truncate the item name being looked up (new fix, breaks buy for any multi-word item name).

§7.114 fix: private input_line() broke multi-line to/board/mail/chfn input (2026-08-19)

Same ES2-ancestry bug as zzhj/shzs/huoying/dfgs2 (AGENTS.md §7.114): work/feature/user/edit.lpc (this lib's F_EDIT mixin, inherited by obj/user.lpc) declared its input_to() re-arm target private: private void input_line(string line, string text, function callback). The recursive re-arm from inside input_line() silently failed to register once reached through the inherited mixin, so any multi-line .-terminated input session (board post, to, mail, chfn) dropped everything after the first line. Fix: dropped private.

Live-verified on a fresh driver boot (port 40144), fresh character (秦肆八/qinsiba, human/male): to say → two lines of text → . → resulting say output showed both lines (你說道﹕test line one\ntest line two), not truncated after line 1. Killed the driver by exact PID when done.

Files modified this pass:

• libs/dfgsiiv13b/work/feature/user/edit.lpc — dropped private from input_line().

§7.100 sub-threshold instance (2026-08-20)

Found during the §7.100 tail-sweep (below the original 166-lib survey's

=100-occurrence threshold, never checked). Sibling of dfgs2: 30 live

replace_program(ROOM); occurrences across 29 d/snow/*.lpc and adm/guild/*.lpc room files plus this lib's own room-building tool obj/roommaker.lpc's string-builder template (mixed tab/space-indent variant, \n\tsetup();\n replace_program(ROOM);\n}\n", hand-fixed). A full post-fix grep confirms 0 live occurrences remain. Verified via a clean native driver boot (zero new debug.log errors, port listening, killed by exact PID after ~8s).

深度功能测试（§10.7，2026-10-04）— commented-out #pragma no_warnings removed

include/weapon.h carried //#pragma no_warnings (already disabled); the line is deleted so a grep for the pragma finds nothing in this lib.

深度功能测试（§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-05）— 主控 author_file()/domain_file()

驱动的 mudlib_stats 包在主控载入时各调用一次 author_file(<主控文件>) 和 domain_file("/")。本库主控没有这两个 apply，所以每次启动都打印 author_file() in the master file does not work, using root_uid as fallback 和 domain_file() in the master file does not work, using bb_ui as fallback 两行，网页版每位访客的终端里都看得到。adm/obj/master.lpc 补上了这两个 apply：作者返回 get_root_uid()，域返回 get_bb_uid()，正是驱动缺少它们时所用的值。域名等于 backbone 域时，驱动让对象沿用创建者的域，与没有这个 apply 时相同（KB 06 §7.222）。两个新函数不加 nosave（本主控其余函数的 nosave 会触发 Illegal to declare nosave function 警告，属于本库尚未做的警告清理）。用 lpcc config.fluffos /nonexistent.lpc 前后对比，主控载入段只少了这两行。

深度功能测试（§10.7，2026-10-05）— 编译警告清理，以及 tell/reply/who 无法编译

1. 编译警告：启动时 约 40 条 → 0，整树扫描 239 条 → 0。scripts/lpc_warnings.py --fix：24 个 nosave 函数改 protected（被别处按名调用的 5 个去掉 nosave 保持 public）、删 CD/MudOS 专用 #pragma、删 120 个未用局部变量、53 处无效转义（BIG5 第二字节 0x5C 转码后残留的 \，如 不允許\你，KB 03）、10 处补 varargs；lpc_audit_removed_locals.py 复核 195 个被删声明，标出的 apply 是本文件的 apply() 函数调用，不是被删的变量。手工：logind 的 #if 0 分支变量移入同条件声明块，httpd 删无用的 q = query_ip_port()。 2. tell、reply、who 三个基本指令无法编译。 它们 #include <net/dns.h> 并引用网际互联守护 GTELL/RWHO_Q，而本档案里根本没有 net/dns.h 和这些守护（raw/ 中也没有），于是玩家打 tell/reply/who 都是指令编译失败。同源的 huoying 已把这段注掉；这里改为 #ifdef GTELL/#ifdef RWHO_Q 包住 名字@站名 分支，本站内的私聊、回答、在线列表照常工作。fingerd 的 mud 变量同理放进 #if 0。 3. version 用了旧驱动的 __DRIVER__ 宏（本驱动没有，指令编译失败），改为只印 __VERSION__（内容已是 fluffos <版本>）。cmds/adm/socket.lpc 调用 MudOS 的 dump_socket_status()，本驱动没有，改用文档中的 socket_status() 列出各套接字，并按 KB 01 §1.3(c) 以 #ifdef __PACKAGE_SOCKETS__ 保护（网页版没有套接字包）。 4. 验证：全新启动 0 警告；fluffos 登录 → look、who、version（fluffos 20260830-… / Eastern Stories 2.1.3a）、tell fluffos hello、reply hi、socket、score、quit 全部正常。无参数的 who 只列与自己等级相差 5 以内的非巫师玩家，所以管理员看到 0/1 是设计如此。

深度功能测试（§10.7，2026-10-08）— .lpc 后缀的定宽切片

.c 改名 .lpc 时只改了字符串没改切片宽度：f[<2..] == ".lpc" 拿两个字符比四个字符，永远不成立（!= 永远成立），按后缀筛文件、去后缀的代码因此从不运行或截成 x.l（KB 06 §7.238）。scripts/lpc_lpc_suffix_slice.py --apply 改了 1 处比较、0 处去后缀（如 cmds/wiz/update.lpc）；改动的文件 HEAD 与工作树分别加载（新进程），无回退。

• 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）。

move() 的目标房间文件不存在时不再抛错（2026-10-18，KB 06 §7.96）

feature/move.lpc 的 move() 把 err = catch(dest = load_object(dest)) 当存在检查，可目标文件不存在时 load_object() 返回 0、catch 不触发，接着 dest->receive_object() 抛出 Bad argument 1 to EFUN call_other()。留言板 std/bboard.lpc 的 setup() 把自己 move() 到 location 房间，那是巫师的私人房间时（档案里没有这个文件），留言板连同刷出它的房间一起载入不了。catch 之后补上 if (!objectp(dest)) return 0;（kxkj 系是 ob），移动失败、对象留在原处。抽样的留言板原本就能载入，这一句只是防御。

登录密码超过 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）。

翻页器 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/user/more.lpc。

chpass：先把参数写进日志，再对它 sscanf（2026-10-21，KB 06 §7.336）

管理员扫描里 chpass 不带参数报 Bad argument 1 to sscanf() Expected: string Got: 0.（cmds/adm/chpass.lpc）：指令先 log_file("nosave/CHPASS", ... arg)（%s 吃得下 0），再 sscanf(arg, "%s %s", userid, new_passwd)。静态扫描只看第一次提到参数的语句，现在会越过这种只是打印或记录的提及；在记录之前加 if (!arg) return notify_fail("指令格式：chpass <使用者代号> <密码>\n");。

注册到不存在函数的 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.，同一个动词的其他处理函数不再尝试（不是最新的一条就悄悄跳过）。删除了 1 条注册（1 个文件，scripts/lpc_fix_dead_add_action.py），动词留给别的处理函数：/obj/clan_symbol.lpc（help）。最多的函数名：help 1 处。

按字节写的汉字循环、茶馆猜诗和同盟频道标题（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 区间 1 个文件。证明（scripts/lpcc_eval.py）：sjplii 的 check_legal_name 在 HEAD 接受「张a」、改后拒绝，两边都接受「张三」；xkx100 的 clubpoem->mixup("离离原上草") 得到「离离原草上」（真交换汉字）；nitan_san 两字同盟名得到 【 兄 弟 】。关键对象加载通过。

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

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