yueyingqiyuan — 月影奇缘 (Moon Shadow Wondrous Fate)

Archive: 月影奇缘.rar (#54). Port: 40048. Status: done (boots clean, full registration flow verified end-to-end into the actual game world).

What this is

Config's own name : field confirms the self-identified title: ★月影奇缘★ ("Moon Shadow Wondrous Fate" / "Moon Love Story", per the lib's own English banner text). Raw archive root is nested at raw/yy/yueying/ (the top-level yy/ wraps the real mudlib dir yueying/); config.cfg's comment says # name of this mud xyj 2000 and the live banner shows 世纪西游 之 月影奇缘 / A Journey to the West / Moon Love Story — a 西游记 (Journey to the West)-themed reskin, credited "XYJ 2000, Copyright 2000-2001 by Moon lOVE Story", with wizard names 巫师协会 crediting "stone"/"fix". The raw archive also ships a generic 小熊泥苑.txt readme (the same "小熊泥苑" hosting-site readme text seen bundled with sjtx2, archive #36) — same distribution site, unrelated codebase, not a lineage signal by itself (consistent with the project's repeated "similar branding ≠ shared lineage" finding).

Lineage: adm/obj/master.c's own header comment says // for ES II mudlib / // original from Lil / // rewritten by Annihilator — the same "ES II" family already seen in es1_win/esI/xkx2001/rzrmud/xo/ xo_final/bmxkx2001. Layout is adm/obj/{master,simul_efun} (not adm/single/ like the Century family, not adm/obj overlapping with custom-ACL securityd.lpc like shujian2008). feature/dbase.lpc (the F_DBASE-equivalent) implements real local set/query/delete/add functions (inherited by std/char.lpc etc.) — the architecturally-correct pattern, confirmed NOT the nitan-family bare-simul_efun dbase bug (§15). ~11,612 raw files, 9,498 renamed to .lpc.

Fixes applied

1. AGENTS.md §15h (is_chinese / check_legal_name GBK byte-range bug) — confirmed present, fixed both sites: - adm/simul_efun/chinese.lpc's is_chinese(str): was str[i] < 161 || str[i] == 255 plus an i%2==0-gated secondary GBK lead-byte range check, and strlen(str) < 2 as the minimum-length gate. Replaced with a single CJK Unified Ideographs codepoint range check per character (str[i] < 0x4e00 || str[i] > 0x9fff) and strlen(str) < 1 (character-count equivalent of "at least 1 full GBK char"). - adm/daemons/logind.lpc's check_legal_name(name): bound strlen(name) < 2 || strlen(name) > 12 (byte counts, message says "一到六个中文字" = 1-6 Chinese characters) halved to < 1 || > 6; the sliding-window loop's i%2==0 && !is_chinese(name[i..<0]) gate had the i%2==0 && dropped (every index is already one character under UTF-8 — harmless redundancy with the fixed is_chinese(), not a behavior change, per the catalog's documented pattern). 2. AGENTS.md §15p (proactive DNS/intermud daemon preload exclusion) — /adm/daemons/network/dns_master was present in adm/etc/preload; removed it before the first boot attempt. Confirmed via source read that nothing else in the registration path references it. Driver booted in well under 20 seconds with no hang. 3. New: message.lpc's tell_room() passes a raw int 0 to message()'s 4th (exclude) argument when called with only 2 args (the overwhelmingly common call shape — ~578 call sites in this lib use the 2-arg form). This driver's message() efun 4th arg is typed void | object | object * (see src/packages/core/core.spec) and rejects a plain int 0 at runtime: Bad argument 4 to EFUN message() Expected: object, array, Got: int(0). Found live on first boot — a preloaded room (/d/wusheng/room1.lpc)'s ambient sounding() heartbeat called tell_room(where, msg) (2-arg) every ~10s and errored every time. Fixed at the single shared root cause (adm/simul_efun/ message.lpc's tell_room), not per call-site: exclude || ({}). This is a genuinely new bug class for the catalog — the "ES II" lineage's own message.lpc implementation, not previously exercised by a boot that had a preloaded ambient-sound room reaching this exact code path this early. 4. AGENTS.md §14 (valid_override 2-arg → 3-arg) — master.lpc's valid_override(file, name) only checked file == SIMUL_EFUN_OB, but adm/simul_efun/object.lpc (one of several fragments #included into adm/obj/simul_efun.lpc) does efun::destruct(ob) — for a fragment, file is the physical file, never equal to SIMUL_EFUN_OB itself. Upgraded to the 3-arg signature and also check main_file == SIMUL_EFUN_OB || main_file == MASTER_OB. Per the catalog's own caveat, this may never actually surface on a real boot (nothing in debug.log suggests it did here either) — applied proactively since it's free and correct, matching the documented pattern exactly.

Confirmed NOT needed (checked by reading the actual source, not assumed)

• §4 (master.lpc lazy load_object(SECURITY_D) inside valid_read/ valid_write recursion): master.lpc's valid_write/valid_read just do if (ob = find_object(SECURITY_D)) return ...; return 0/1; — no lazy load_object() call at all, so no recursion-on-failed-load possible. Not needed.
• §7 (missing get_root_uid/get_bb_uid): both already implemented in master.lpc, returning ROOT_UID/BACKBONE_UID. Not needed.
• §8c (this_player()-override footgun in valid_read/valid_write): securityd.lpc (the real ACL here, adm/daemons/securityd.lpc) never does if (this_player()) user = this_player(); — it takes user as given throughout. Not needed.
• §8d (<local.h> next to its own file, needs get_include_path()): every #include <x.h> in this lib resolves to a file that actually lives in the global include/ directory (weapon.h, armor.h, name.h, etc. all confirmed present under include/), not a same-directory "flavor" header. convert_lib.sh's automated local-angle-bracket-to-quotes pass also converted 308 genuinely-local #include <x.lpc>-style references to quotes as a safety net. Not needed as a master.lpc fix.
• §15n/§15o (custom securityd ACL blocking driver's own compile-time reads / missing get_include_path for mid-connection compiles): read securityd.lpc's valid_read in full — its very first check is if (func != "read_file" && func != "file_size" && func != "stat" && func != "read_bytes" && func != "tail" && func != "ed_start") return 1; — i.e. load_object/recompile_object/include (and everything else) are auto-allowed BEFORE the ACL tables are even consulted. This architecture is already immune to the §15n class of bug. Not needed.
• §15l (master.lpc create() destructing SIMUL_EFUN_OB): master.lpc create() is just write("master: loaded successfully.\n"); — no destruct/reload trick. Not needed.
• §8e (tail() missing efun): only one call site, cmds/wiz/tail.lpc (an unused admin command, not on any preload/login path) — left as-is per the catalog's own precedent (dead code, not worth reimplementing).
• §3 (static on functions): only 3 genuine function-level occurrences in the whole lib (master.lpc's crash(), cmds/wiz/ data.lpc's sort_keys()/filter_props()) — all mechanically fixed by convert_lib.sh's blanket \bstatic\b→nosave pass (82 total replacements counting variable-level static too). Verified no leftover function-level static remains.
• **§8f (TYPE * a, b; array-modifier-doesn't-propagate)**: zero matches for the pattern — this is a Dead-Souls/English-lineage-specific habit, not present here. Not needed.
• §15f (bare array type declaration): zero matches. Not needed.
• §15r (check_config.lpc driver-version self-check): no check_config/checkconfig/verify_driver-shaped file anywhere in the archive. Not needed.

Known, non-blocking issues (not fixed — documented per AGENTS.md §12/§13/§15m precedent)

• Corrupted pre-existing save data: data/emoted.o (the emote-phrase daemon's save file) throws restore_object(): Illegal mapping format while restoring emote. on every boot. Confirmed NOT an artifact of our UTF-8 conversion (the file was not flagged "LOSSY" by convert_lib.sh, and a raw-byte scan shows a genuine unbalanced-parenthesis-shaped truncation deep in the mapping literal, in the original archive). This is the exact same emoted.o corruption pattern AGENTS.md's §1 already documents as a known example from the pilot lib. master.lpc's preload() wraps every preload target in catch(), so this is fully non-fatal — the error prints once at boot and the emote daemon simply starts with an empty phrase table. emoted is not referenced anywhere in the login/registration path, so it has zero effect on character creation.
• One corrupted room-NPC content file: d/qujing/start/24/12.lpc (raw 12.c) ends mid-statement in raw binary garbage in the ORIGINAL archive (confirmed via xxd on the pre-conversion file — the last ~15 bytes are non-text binary, truncating a carry_object(...) call with no closing paren/semicolon/brace). Not #included, inherited, or preloaded — a real, pre-existing one-off content gap (§12-style), not something to fabricate a fix for.
• Intermittent driver crash observed twice during interactive testing, not reliably reproduced: during the first ~10 minutes of manual mudclient.py testing, the driver process died twice with zero trace anywhere (no Segmentation fault/Fatal line in debug.log, no entry in dmesg/journalctl -k, master.lpc's own crash() apply never fired — no log/static(nosave)/CRASHES file was ever created). Both times followed a connection that answered the post-registration "talent/attribute" mini-game (/d/wiz/init-driven) with an unusual input pattern (repeatedly resending invalid answers to its [0-3]/[9] menu, or disconnecting right after sending 9 without following up with the y/n confirmation it then asks for). After enabling ulimit -c unlimited and restarting, 8+ subsequent full registration attempts — including 3 complete, clean runs all the way from gb through y/look into an actual game room — never reproduced it again, and no core file was ever produced (the 2 crashes both predated the ulimit change). Root cause not confirmed — flagged here as a known, apparently-rare/non-deterministic issue for whoever next touches this lib, rather than something fixed. It did not block reaching "done" criteria since the flow completes correctly and repeatably in the large majority of attempts.
• Cosmetic side-effect of the blanket static→nosave conversion: this lib's original code uses a bare English word static as a log subdirectory name convention in dozens of log_file("static/X", ...) calls (static/CRASHES, static/using, static/promotion, static/ give, static/SUICIDE, etc. — completely unrelated to the LPC static keyword). convert_lib.sh's \bstatic\b→nosave regex has a word boundary on both sides of the string content too (bounded by / and "), so it renamed all of these path strings to nosave/X as a side effect. This is harmless in practice (log_file() just writes wherever it's told, self-consistently, across every call site) but worth noting for the shared script/catalog: the static→nosave fix, as currently implemented, is not scoped to code context and will also silently rewrite string literals that happen to contain the bare word static (not just this lib's log_file("static/...") convention — any lib that uses "static" as an in-string token is at risk of the same cosmetic corruption). Confirmed self-consistent here (no broken references), so left as-is.

Interactive test result — full registration flow

Read adm/daemons/logind.lpc's full logon()→encoding()→if_young()→ get_id()→get_new_id()→confirm_id()→get_name()→new_password()→ confirm_password()→get_email()→get_gender()→confirm_gift()→enter_world() callback chain before scripting the test (per the task's explicit instruction) — confirmed the shape: a GB/BIG5 encoding prompt (GB_AND_BIG5 is #defined in include/mudlib.h, so this prompt is live, not compiled-out), then a "still have unfinished work? (yes/no)" age/distraction gate (any non-n answer ends the session), then an English id prompt where literally typing new branches into new-account registration (a already-used/banned id just re-prompts, no separate "new" confirmation step), then a fresh English id (3-8 lowercase letters, checked against banned_id), then — with no y/n confirmation in between — straight to the Chinese-name prompt, then password (twice), then email (custom ???@ccb-substring requirement), then gender (m/f), then automatic confirm_gift("n", ...) → enter_world(), which moves a fresh no_gift-flagged character straight to /d/wiz/init (a talent-point allocation mini-game: reroll one of 4 stats via [0-3], or [9] to accept — 9 itself asks a second y/n confirmation before actually finishing).

Full clean transcript, one continuous connection, id zhongfen / real Chinese name 秦风终:

gb                        -> GB encoding selected
no                        -> not a distracted worker
new                       -> new-player registration
zhongfen                  -> English id accepted
秦风终                     -> Chinese name accepted (no rejection message)
test12345                 -> password
test12345                 -> password confirmed
[email protected]           -> email accepted
m                          -> gender: male
9                          -> accept default talent allocation
y                          -> confirm talent allocation
  好！祝你西天取经早成正果！
  只见眼前霞光一闪，你已经来到了一个陌生的世界（ｌｏｏｋ）．．．
  【月影奇缘】: 听说来了一位叫做秦风终的少年英雄。
look
quit

Player landed in the actual game world (server-wide announcement "听说来了一位叫做秦风终的少年英雄" — "heard a young hero named Qinfeng-Zhong has arrived" — confirms enter_world()/confirm_gift() completed and the character object is live). A second full run (qfsan/秦风三, qinfeng/秦风六) reached the actual starting room (南城客栈 / South-City Inn) with visible exits, a bulletin board, and 3 NPCs (店小二, 邮差 千里眼, 唐僧), including an NPC greeting message — confirming the room itself, not just the character-creation flag, is fully live. Driver process remained alive and responsive after every one of these tests.

lpcc sweep

9,498 files, 9,220 pass / 278 fail (97.06%). Failure categories triaged (not fixed individually, per AGENTS.md §6b — breadth over exhaustive depth):

• 84 "Undefined variable" — dominated by std/skill_model_*.lpc (SKILL_CH_NAME/SKILL_EN_NAME): these are templates, not real LPC objects — cmds/std/meskills.lpc/editskill.lpc read them as raw text and replace_string() the placeholder tokens to generate real per-skill files. Compiling the template standalone is expected to fail; this is not a bug (§6b's "#include-only fragment" pattern's cousin — a text-template pattern instead).
• ~40 "Illegal character 0xNN" plus assorted syntax errors — spans several unrelated content files; spot-checked a few and found ordinary pre-existing typos (missing closing quotes, fullwidth punctuation in code position) of the same shape already catalogued in §9/§10 — not a systemic issue, just the normal long tail of pre-existing authoring bugs in a large, old, hand-edited content tree.

- 12 "Invalid UTF8 codepoint in string literal": worth a note for whoever revisits — these are real conversion casualties that slipped past convert_lib.sh's heuristics on this particular archive; not chased further given the sweep's job here is signal, not an exhaustive per-file fix pass, and none of the affected files are on the boot/login path (confirmed: the whole registration+game-entry flow booted and ran with zero such errors in debug.log).

• 5 "Cannot #include uid.h" (mail_serv.lpc/ms.lpc/pingtcp.lpc/ telnetd.lpc, all under adm/daemons/network/): a genuine missing- header content gap in the intermud/network subsystem (confirmed uid.h/config.h/daemons.h/mailer.h don't exist anywhere in this archive) — none of these files are in preload or reachable from registration; a real archive gap (§13), not fabricated.
• Remaining categories (call_other-target-not-found clusters, "Unable to find the inherited function" on a handful of files, etc.) match the standard "isolated single-file compile lacks the real room/ preload graph" noise already documented in §6b — spot-checked a sample, none appear in the real boot's debug.log.

Memory stayed healthy throughout (~19GB available at completion, peaked around 2.5GB RSS on the lpcc process mid-sweep — small relative to the ~9,500-file count, no pressure requiring an early kill despite 2-3 other agents' concurrent sweeps running on the same host at the time).

Housekeeping

Driver was killed after testing; verified no driver config.fluffos process remains with cwd under libs/yueyingqiyuan/ before finishing.

Re-verification pass: driver rebuild + formatter + WASM (2026-07)

• LPC formatter applied to all .lpc under work/ via tools/lpc-syntax/bin/format-corpus.mjs (9,498 total, 9,361 written, 115 unchanged, 22 self-checked errors left untouched — expected on legacy code, not chased).
• Native re-test against the freshly rebuilt driver (~/src/fluffos/build-debug/src/driver, rebuilt from latest upstream master): clean boot, zero fatal errors in debug.log (only the pre-existing benign emoted.o restore warning and ordinary compile warnings). Full registration flow re-verified end-to-end with a fresh real Chinese name (秦风试/Zfretwo) through look/score/quit, all correct.
• NEW bug found during this pass (pre-existing, not caused by the reformat or driver rebuild): adm/etc/banned_name — the static, read-only Chinese name-blocklist file check_legal_name() in adm/daemons/logind.lpc reads via explode(read_file(BANNED_NAME), "\n") — was entirely missing from work/, present in raw/ (500 GBK-encoded lines) and confirmed never written to anywhere in the codebase (grep for BANNED_NAME — only the one read_file() call site). read_file() on a missing path returns 0, and explode(0, "\n") throws Bad argument 1 to explode(), uncaught, aborting every Chinese-name submission during registration — this silently blocked all new-character creation. Root cause traced: the repo-wide QA sweep commit that added libs/*/work/adm/etc/banned_name to .gitignore (intending to stop tracking *runtime-churn* ban-lists that some OTHER libs' code generates/appends to at runtime) also deleted this lib's already-committed copy — but here the file is genuine static shipped content (an authored blocklist), never runtime-written, so the blanket path-based .gitignore rule doesn't distinguish the two cases and this lib got its real content silently deleted. Fixed by regenerating it from raw/yy/yueying/adm/etc/banned_name via iconv -f GBK -t UTF-8 (matches the same encoding-conversion the rest of the archive underwent). Flagged for the orchestrating session: the shared .gitignore rule libs/*/work/adm/etc/banned_name is unsafe as a blanket pattern and should be re-scoped or the other 90 libs re-checked for the same false-positive wipe (checked the other 7 libs in this batch — yxcs uses a differently-named BANNED_NAMES file that IS genuinely runtime-managed via write_file() in band.lpc, so that one gitignore hit is correct; the remaining 5 libs in this batch have no BANNED_NAME-shaped gate at all).
• WASM test (scripts/wasm_client.js against build-wasm/src): boots cleanly (only the expected non-fatal "sockets package not available"-class preload messages). Full registration flow completed end-to-end under WASM too — real Chinese name 秦风瓦/Zfrewasm reached the actual starting room (南城客栈), look/score/quit all produced correct output. This lib's registration path does not gate on query_ip_number()'s format — the only WASM-side artifact observed was cosmetic: the "你现在从 ... 连线进入" banner line prints an empty IP substring (known WASM-mode query_ip_number() limitation, driver-side, not a mudlib bug) instead of 127.0.0.1. Does not affect login/registration/gameplay in this lib.

WASM-enablement pass (2026-07): loopback gates + admin seeding

Standard four-change pass per AGENTS.md §1.3b/§1.3e/§1.5:

• adm/daemons/band.lpc: new is_local_site(site) helper (loopback / empty / malformed-IP ⇒ local) short-circuits is_banned(), create_char_banned(), is_strict_banned() — all return 0 for local.
• adm/daemons/logind.lpc:

- logon() (~line 100): per-IP concurrent-login-attempt cap (login_cnt > 3 destruct) now skipped for loopback. - encoding() (~line 185): the no-query_ip_name destruct and the IP-must-be-numeric character-scan destruct are skipped for loopback/malformed IPs (the WASM garbage-IP case). - get_id()'s MAX_LOGIN per-IP multi-login cap (~line 375): loopback exempt. - get_passwd()'s 20-second relogin load throttle (~line 585): loopback exempt (kept for remote connections).

• adm/daemons/securityd.lpc match_wiz_site(): loopback/malformed IP always matches (wizard site locks can't block local logins).
• No uptime() startup-grace gate exists in this lineage's login path (only cosmetic uptime uses in cmwhod/httpd) — nothing to bypass.
• Admin seeded per §1.5: fluffos / Mud@2026 / 浮浮, registered via the real flow (gb → no → new → id → 中文名 → 密码×2 → email 必含 "ccb" ([email protected]) → gender m → talent 9 → y), then fluffos (admin) appended to adm/etc/wizlist. Verified on re-login: banner shows 目前权限：(admin), lands in /d/wiz/wizroom, and update /d/city/kezhan.lpc recompiles successfully.
• Retest: fresh normal registration (wasmtest/秦风测) end-to-end into 南城客栈 with look/score/quit correct; debug.log clean (warnings only). Test char saves removed; note the lib runtime-appends every new player name to adm/etc/banned_name (name-reservation) — test-churn lines were reverted, the single 浮浮 line is kept intentionally.

WASM long-sit boot-watch pass (2026-07)

200s scripts/wasm_boot_watch.sh sit: no new failures beyond the already-documented ftpd.lpc/socket-efun sockets-absent preload error (caught by master.lpc's preload catch(), cosmetic — FTP feature unavailable under WASM, not on any login/gameplay path) and the already-documented emoted.o restore warning. Proactively fixed adm/simul_efun/object.lpc's file_owner() (return name → return dir — misattributes 3-level-deep /u/<wiz>/<subdir>/<file> log_error writes to a bogus path) as part of a repo-wide port of the fix found live on sibling zhonghua2; did not fire in this lib's own sit, fixed proactively since it's the identical shared file. Retest: fresh registration (yysanit/秦风检) end-to-end through look/score/quit, clean, no regressions.

深度功能测试 / Deep functional test (2026-07-24)

Round-two deep-playthrough pass (per AGENTS.md §10.7; see libs/bxsj/NOTES.md's and libs/xiyouji/NOTES.md's "深度功能测试" sections for the worked examples this pass follows). Read doc/help/newbie in full first — it directly named the fight-vs-kill safety distinction (help combat gives the full contract: fight stops at unconsciousness/surrender/flight and doesn't carry a grudge; kill fights to the death and ignores quit), the apprentice/learn syntax, wimpy, and the general command set, exactly as the methodology predicts. Played as an ordinary new player through registration, exploration, safe combat, organic skill-learning and sect-joining, a real quit, a real-wall-clock-gap reconnect, and a shop-purchase attempt, native driver (build-debug).

Test characters (both kept, as representative playthrough evidence):

• id qinzf, Chinese name 秦振风, password Test12345, male — the main playthrough character. State: apprenticed to 秦富 (Qin Fu, 将军府/ Grand-Marshal's-Mansion sect, 4th generation — 将军府第四代弟子), learned force (内功心法) to level 1 via the organic teacher-NPC path, survived a fight against 疥顶小僧 (a wandering monk NPC, non-lethal, auto-surrendered at low HP), quit once (dropping its starting sect spear per this lineage's item-drop-on-quit design, see below), and was round-tripped through both persistence paths: a silent reconnect (disconnect without quit, then reconnect — resumed in place, no full login) and a real quit → 35-real-second wall-clock wait → full relogin (title/sect/skill all intact). Saves: work/data/user/q/ qinzf.o, work/data/login/q/qinzf.o.
• id shenqf, Chinese name 沈青枫, password Test12345, male — a second character used specifically to walk /d/jjf/gate → front_yard → front_yard2 (the exact crash site below) on a freshly rebooted driver, confirming clean room population and correct, uncorrupted NPC titles after the fix. Saves: work/data/user/s/shenqf.o, work/data/ login/s/shenqf.o. (A third character, id shenqing/沈青, was used only to reproduce the crash pre-fix; its save files were removed after the fix was verified since its story is fully captured in this writeup and it added nothing shenqf doesn't already demonstrate more cleanly.)

Bug found and fixed: this is AGENTS.md §7.17, not a new class — confirmed present via the shared "ES II" lineage, not independently discovered

yueyingqiyuan and xiyouji are documented siblings in the same "ES II / 西游记" mega-family (AGENTS.md §11; both this lib's own NOTES.md lineage note and xiyouji's independently confirm adm/obj/master.c's // for ES II mudlib // original from Lil // rewritten by Annihilator header). Per §7.17's own instruction to "check documented siblings for the same pattern before moving on," std/room.lpc was read first and found structurally identical to xiyouji's pre-fix copy — setup() calls this_object()->reset() synchronously as the last line of every room's create() (std/room.lpc:211-213), and reset() only marks a room's NPC population done on its very last line (set_temp("objects", ob), std/room.lpc:104 pre-fix) — and d/jjf/npc/zhangmen.lpc's init() calls a local create_identity() whose where-resolution does the exact same forced call_other(where, "???"); where_ob = find_object(where); idiom when where isn't already an object. This whole shape — 16 structurally-identical copies of a "sect entrance" NPC file (one per sect: d/jjf, d/nanhai, d/wusheng, d/xueshan, d/moon, d/sea, d/death, d/lingtai, d/fenghuang, d/pansi, d/shushan, d/xuyi, plus 4 under d/qujing/{kusong,wudidong,wuzhuang, xuanyuan}) each calling me->create_identity(<master path>, <own room path>) from init() — is the same copy-pasted pattern §7.17 documents for xiyouji's 9 sect-entrance NPCs, just with 16 sects instead of 9.

• Live reproduction (before applying the fix, fresh driver boot, debug.log cleared first): registered a fresh character and walked 南城客栈 → 朱雀大街 → 十字街头 → 青龙大街 ×2 → answer 拜师 → 将军府(gate) → south into front_yard(练武场, 秦富's courtyard) → south again into front_yard2(练武场, the crash site — logs/pits/ weapon rack, holding npc/guard and npc/zhangmen), its first-ever visit since the driver booted. Player-visible symptom: the second south command silently failed to move — the client displayed the same front_yard room a second time (identical description and NPC list, 秦富/小童×2) instead of front_yard2, with no error visible on screen. log/debug.log showed the real story: 7 "Too deep recursion." traces in a single connection — 6 blamed on /adm/daemons/securityd.lpc:175 and the last one squarely on program: /d/jjf/npc/zhangmen.lpc, object: /d/jjf/npc/zhangmen#217, file: /d/jjf/npc/zhangmen.lpc:38 (the create_identity(...) call inside init()) — the blamed file:line shifting between calls is exactly §7.17's documented signature of a genuine reentrant cycle rather than one bad line.
• Root cause: identical to §7.17's documented mechanism — reset() can fire twice on front_yard2's first-ever compile (once synchronously from setup() at the end of create(), once more from the driver's own standard reset-pass triggered by the same player move()), a reentrant second call sees query_temp("objects") still empty and clones a second full set of guard/zhangmen, and cloning + moving the second zhangmen synchronously fires its init() → create_identity() → the forced call_other("/d/jjf/front_yard2", "???") self-locate, which can itself re-trigger the room's own compile — closing the cycle until "Too deep recursion." aborts it.
• Fix (ported directly from §7.17, applied lib-wide, not just to the one reproduced site): 1. std/room.lpc: added nosave int resetting_now; (declared at top, std/room.lpc:10), checked/set at the top of reset() (std/room.lpc:42-43) and cleared on every return path (both the early !mapp(ob_list) return and the normal end of the function, std/room.lpc:65 and :105). A reentrant call is now a safe no-op; the original (outer) call still runs to completion exactly once. Lib-wide — every room inherits std/room.lpc — but provably inert for the normal non-reentrant case (re-verified several already-known-good multi-NPC rooms, e.g. d/city/kezhan with its 3 NPCs, after the fix and saw identical, correct population). 2. All 16 <sect>/npc/zhangmen.lpc files: added a nosave int in_init_now; flag (declared just above init()) guarding the entire body of init() the same way (if (in_init_now) return; in_init_now = 1; at entry, in_init_now = 0; at every fall-through exit — none of these 16 init() bodies had an early return, so each needed exactly one flag-clear line before the closing brace). Applied identically to d/death, d/fenghuang, d/jjf, d/lingtai, d/moon, d/nanhai, d/pansi, d/qujing/{kusong, wudidong,wuzhuang,xuanyuan}, d/sea, d/shushan, d/wusheng, d/xueshan, d/xuyi — confirmed each file still diffs cleanly against its siblings aside from the expected per-sect content (master/room paths, inquiry text). d/npc/zhangmen.lpc (a generic, unplaced template — its own init() never calls create_identity() and it's not referenced live from any room's "objects" mapping; the one call site that looks like it, d/nanhai/guangchang.lpc, is fully commented out) was deliberately not touched — dead code, left alone per the catalog's own precedent. 3. Belt-and-suspenders in all 16 files' create_identity(): since where is, at every real call site in this lineage, always the room the NPC was just cloned into, resolve it via environment(this_object()) first (falling back to the original forced call_other(where, "???"); find_object(where) only if that doesn't already resolve to where).
• Verified: reproduced live pre-fix as above (fresh driver boot, debug.log cleared, 7 "Too deep recursion." traces from one connection). Post-fix: killed and rebooted the native driver fresh again, registered a brand-new character (shenqf/沈青枫) and walked the identical route through front_yard2 on its first-ever visit — the second south now correctly rendered front_yard2's own description (木桩/沙坑/兵器架, distinct from front_yard's 沙袋) with its own NPCs (大唐天下兵马大元帅 朝廷兵马大元帅(Zhang men) and 校尉(Xiao wei)) — no duplicate-room artifact, no corrupted 0-prefixed title (zhangmen's title/name come from its own reset_me(), which ran cleanly exactly once). debug.log showed zero "Too deep recursion.", error:, or Fatal lines for the entire post-fix session. Re-verified again with the main qinzf playthrough (different route, through front_yard only, apprenticing under 秦富) across multiple reconnects — clean throughout.
• Scope note: only /d/jjf/front_yard2 was live-reproduced and live-verified fixed (both pre- and post-fix). The other 15 sects' entrance rooms were fixed proactively by the identical code-shape match (per AGENTS.md's "port the sibling's proven fix" pattern, §2.1) — each of the 16 source files was read and confirmed to have the exact vulnerable shape before fixing, but a live walk-through of all 16 sect-entrance rooms was not pursued given the time budget. The std/room.lpc-level resetting_now guard is lib-wide and structural — it independently closes the reentrancy cycle for every room in the game regardless of which NPC's init() would otherwise re-touch it, so the un-walked 15 sects are protected even without their own live verification. A future pass reaching any of the other 15 sects should spot-check its own zhangmen.lpc's entrance room on first visit anyway.

What was tested and confirmed working

• Registration: real Chinese name (秦振风), full flow (gb encoding → distracted-worker gate → new → English id → Chinese name → password ×2 → email → gender → talent roll/accept), landing directly in 南城客栈 (bypassing the /d/welcome/welcome routing lobby below — new-player registration routes through /d/wiz/init's talent-roll minigame, which moves the character straight into the city on completion, independent of the startroom-based routing that ordinary relogins use).
• Movement/exploration: walked 南城客栈 → 朱雀大街 → 十字街头 → 青龙大街 ×2 → answer 拜师 → 将军府(gate) → 练武场 (front_yard, 秦富/小童×2) → 练武场(front_yard2, the crash site, now fixed, via shenqf). Room descriptions, exits, and day/night flavor text all correct throughout; read the underlying .lpc room files to plan the route (§10.7's explicit instruction) rather than guessing — this is how the /d/jjf/gate's answer 拜师 gate (d/jjf/ npc/qinan.lpc's do_answer()) was found before blindly walking into a "你胡说什么呀？" rejection.
• Character info: score (仙衔/职位 title line, attributes, 气/神 bars, kill/death counts) and hp (气/神/食物/饮水/内力/法力 bars) both correct at every stage (fresh, post-fight, post-apprentice, post-skill-learn). i correct throughout, including the □ equipped-item marker convention (same ES2-family convention seen in sibling libs).
• Combat: help combat documents fight (not kill) as this lineage's own safe-sparring contract — battles stop at unconsciousness/ surrender/flight and don't carry grudges, matching xiyouji's finding for the same lineage. A genuine stat-mirroring training-dummy object (muren.lpc, accept_fight() copies the attacker's own skills/skill-map) does exist at d/shushan/obj/muren.lpc (placed, ×4, in d/shushan/{w,e}-lianwu.lpc) but is a real trek from the starting zone; a second, byte-similar copy at d/city/obj/muren.lpc is orphaned (confirmed via grep -rn "city/obj/muren" work/d: zero hits — not referenced by any room's "objects" mapping anywhere in the archive), the same "dead training-dummy content" pattern xiyouji documented for its own lineage. Used fight xiaoseng (阿疥顶 小僧, a wandering peaceful monk NPC one step from the starting inn, combat_exp comparable to a starting character) instead — produced a normal turn-by-turn exchange with narration, correctly auto-surrendered at low HP ("你向後退了几步，说道：这场比试算我输了，佩服，佩服！"), no crash, hp/score both showed partial-but-recovering气血/精神 afterward. Note: the NPC's set id is the full alias "jieding xiaoseng"/"xiaoseng"/"seng" (not "jieding", which is only part of its display name) — fight jieding alone correctly fails with "你想攻击谁？", a correct target-not-found rejection, not a bug.
• Skills: the organic path is learn <skill> from <teacher> (cmds/std/learn.lpc), gated on family/apprentice status for most teachers but not this lib's low-tier stewards — used after apprenticing (below); learn force from qin fu succeeded ("你的「内功 心法」进步了！"), skills correctly listed the new 内功心法 (force) entry at 若有若无 1/0. skills <teacher> (skills qin fu) correctly listed the teacher's full 9-skill roster with ★-marked specials.
• Menpai/sect: the organic path is apprentice <master> (cmds/std/apprentice.lpc) → the NPC's own attempt_apprentice()/ recruit_apprentice(). Two sect NPCs were checked in 将军府: d/jjf/npc/qinqiong.lpc (秦琼, the sect's actual master, gates recruitment behind a combat_exp threshold like bxsj/xiyouji's equivalent high-tier teachers — not visited live here since qinfu already demonstrates the mechanism, and qinqiong's own save data was deliberately left untouched, see Housekeeping below) vs. d/jjf/npc/ qinfu.lpc (秦富, the steward, no threshold), which accepted immediately: apprentice qin fu → 你想要拜秦富为师。秦富决定收你为 弟子。 → score's title updated to 将军府第四代弟子 秦振风, 师承 line correctly showed 将军府秦富, and a 师门点钢枪 (sect spear) was auto-granted. A direct/shortcut sect-join path was checked for and NOT found: d/city/npc/shizhe.lpc (「不知情愁枉少年」月影使者, placed in the /d/welcome/welcome routing lobby every full login passes through) looks, by name and placement, exactly like xiyouji's documented newbie-gift-envoy shortcut, but its only actual effect (ask shizhe about 月影奇缘) is a one-time food/water top-up ("小的已经对您施过法力了" on repeat) — no sect grant, no stat boost. This lib's only join mechanism is the organic apprentice path, matching xiyouji's own conclusion for its sibling lineage (not every ES II derivative kept the shortcut).
• Persistence: confirmed at both layers this lineage has — (a) *silent reconnect* (disconnect without quit, reconnect with the same id/password — "重新连线完毕", resumed in the exact same room with full HP/inventory state, no fresh look printed automatically); (b) *full quit → 35-real-second wall-clock wait (backgrounded sleep, per the standing methodology note on not idling a live connection) → relogin*: title (将军府第四代弟子), 师承 (秦富), and the learned force skill (若有若无 1/0) all round-tripped correctly. Location after a full relogin is /d/welcome/welcome(混沌之初), NOT wherever quit was called from or even the game's actual starting room — this lineage's START_ROOM constant (include/login.h) is itself this routing lobby, which requires typing oldplayer (→ /d/city/kezhan) or newbie to proceed; a player's own startroom property is never set to anything else by ordinary play (only registration's separate /d/wiz/init flow bypasses this lobby entirely on the FIRST login). Confirmed oldplayer correctly lands back in 南城客栈 with the world otherwise unaffected. This is a real, deliberate, one-more-hop variant of the same "location resets on full relogin" design already documented for sibling libs — not a bug, just implemented as an extra routing room instead of a direct room jump. Item-drop-on-quit, same class as bxsj/xiyouji's documented behavior: cmds/usr/quit.lpc drops every non-query_autoload() item on a real quit — confirmed live (the 师门点钢枪 sect spear, present in i right before quit, was gone after relogin; a fresh 皮靴/紫蟒袍 outfit appeared instead, granted by the login flow's own get_cloth()- equivalent re-grant). Deliberate original-archive design, not a persistence defect.
• Shops/economy: d/city/kezhan.lpc's 店小二 (d/city/npc/ xiaoer.lpc, F_VENDOR_SALE) — list correctly showed the documented menu (炸鸡腿/水晶球/挑战金牌/红烧狗肉/花生豆/下棋指南/桂花酒袋). buy jiudai from xiao er was attempted live with a fresh character's starting money (0 — no starting-money grant found anywhere in the registration/talent-roll path) and correctly rejected with "你的钱不够" — a real, correct exercise of the economy gate, matching help newbie's own text ("新手：没有钱怎么办？不要问巫师，向老玩家讨"). No successful purchase was completed live — flagged honestly as an incomplete verification (no in-game income source was pursued within the time budget), not silently skipped, matching the xiyouji pass's own precedent for the same gap.
• Death/respawn: not live-tested. feature/damage.lpc:275's die() was read (environment alternative_die hook, wizard-immortal guard, rulaitask quest-death special-case, corpse/reward handling) and looks structurally sound — no obvious bug. cmds/usr/suicide.lpc was checked as a possible low-risk trigger: bare suicide (no arg) turned out to be flavor-text-only (prints a message, does not actually call die() or reincarnate); suicide -f is a genuine, real death trigger but permanently deletes the character (30-second countdown, password-gated) — deliberately not used since it would destroy the kept evidence character. No genuine kill-to-death fight was pursued either, given the time budget was prioritized toward chasing the confirmed, live, reproducible front_yard2 recursion crash (above) to a verified fix. Concrete to-do for a future pass on this lib.

Housekeeping

Driver killed by exact PID after testing (kill 1385155, confirmed via ps/ss -tlnp that both the process and the port-40048 listener were gone) — verified no driver config.fluffos process remains with cwd under libs/yueyingqiyuan/ before finishing. work/data/zhangmen/ zhangmen_qin_qiong.o (秦琼's own save file, touched by restore() calls made from testing create_identity()/apprenticeship in the 将军府 zone) was reverted to its committed content after confirming the diff was a pure key-reordering + .c→.lpc header self-normalization from a restore()+save() round-trip, not a real state change. work/adm/etc/ banned_name (this lib's runtime name-reservation append target, see the "Re-verification pass" section above) picked up entries for the two kept test characters (沈青枫, 秦振风) — kept, since they correspond to real kept save files — and one entry for the discarded shenqing/沈青 character, which was removed along with that character's save files. No other scratch/diagnostic files were created outside /tmp (removed).

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

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

深度功能测试第二轮 / Deep functional test round 2 (2026-08-15, post driver-upgrade re-test)

Round-two re-verification against the current native build-debug driver (post-upgrade — pulls in PRs #1343/#1344 and the corpus-wide %-operator float-crash fix). Standard checklist + live playthrough-style verification.

Findings:

1. AGENTS.md §7.108 (obj/user.lpc's reconnect() missing enable_commands()): this lib has the kick-duplicate-login pattern (adm/daemons/logind.lpc calls user->reconnect() on the character body after exec(old_link, user)). Fixed by adding enable_commands(); as the first statement. Live-verified with two concurrent telnet sessions: session 2 logged in as fluffos, confirmed the "赶出去， 取而代之吗？(y/n)" prompt with y, and the resulting session correctly dispatched look (real room description) and score (real stat panel). (Other exec(old_link/reconnect() copies under www/cgi-bin, www/relative, and u/yxm/obj/logind.lpc are stray/dead per-user or web-tree copies, not the active LOGIN_D — confirmed via include/globals.h's LOGIN_D define — left untouched.) 2. adm/simul_efun/file.lpc: log_file() never called assure_file() before write_file(); added the call (plus a forward declaration). cat()'s write(read_file(file)) had no null-guard; changed to write(read_file(file) || ""). 3. Already correct, no change needed: cmds/wiz/update.lpc (only update.lpc in this lib) already guards with environment(me) &&. adm/obj/master.lpc's log_error() already uses the case-agnostic "arning:" filter (AGENTS.md §7.10). No adm/daemons/closed.lpc exists, so AGENTS.md §7.107 does not apply. maximum evaluation cost was already 30000000.

Live verification summary: booted the native driver on port 40048 (clean boot aside from pre-existing unused-variable/unknown-pragma warnings, no fatals; Initializations complete / Accepting telnet connections both printed). Logged in as the seeded fluffos admin (Mud@2026, via the gb-encoding prompt then the internal-network "还有好多工作没有做完？" gate answered no), confirmed real write access via update /adm/simul_efun/file (recompiled successfully). The lib's own boot-warning notifier ("有新文件update错误，立即查看 /log/log") fired as expected — checked /log/log, confirmed it's just the routine pre-existing compile warnings, not a new error. Ran the two-session kick-duplicate-login reconnect test described above and confirmed the §7.108 fix live. No fatal errors in the driver's console output. Killed the driver by exact PID when done.

本轮修改的文件 / Files modified this round:

• libs/yueyingqiyuan/work/obj/user.lpc
• libs/yueyingqiyuan/work/adm/simul_efun/file.lpc

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

Standard §10.7 round-three pass, going deeper than rounds one/two per the task brief: pushed through a real death→gate→reincarnation cycle with a netdead reconnect *during* the reincarnation chain, completed a full shop purchase (round two flagged this as untested), live-verified board post+read, and ran the five standing checklist items from the task (§7.111/§7.112/§7.113/§7.90/logind.lpc enter_world() save).

Standing checklist results

1. §7.111 (master.lpc's standard_trace() calling file_name(error["object"]) unconditionally): not present. Both call sites in adm/obj/master.lpc (standard_trace() line ~244 and report_error() line ~338) already guard with (undefinedp(error["object"]) || !error["object"]) ? "(none)" : file_name(error["object"]). No fix needed. 2. §7.112 (NPC/room init() scheduling an unguarded call_out() chain, exploitable via a netdead reconnect re-broadcasting init()): found and fixed, see below. 3. §7.113 (netdead reconnect not restoring heart_beat): not present. obj/user.lpc's reconnect() (the one actually invoked — confirmed via adm/daemons/logind.lpc:1175's user->reconnect();, itself called from the real reconnect(object ob, object user, int silent) handler at lines 625/702, not dead code here) already does enable_commands(); set_heart_beat(1); ... as its first two statements. This predates the round-two §7.108 fix (which only added enable_commands(); set_heart_beat(1) was already there per git log on this file). Live-verified below rather than trusting the code read alone, per the task's own "call's query_heart_beat() is unreliable" warning — used a real health-regen signal instead. 4. §7.90 (maximum evaluation cost stuck at the risky 700000 default): not applicable, already 30000000 (set in the round-two pass). 5. logind.lpc's enter_world() missing/commented-out ob->save(): not applicable, enter_world() calls ob->save(); at line 1027.

Bug found and fixed: §7.112, this lib's own 4-file instance of the death/reincarnation init()-call_out() race

Grepped every init() body in the archive for an unguarded call_out( (481 hits total, the overwhelming majority ordinary one-shot NPC chat/ greeting timers where a duplicate is harmless). Narrowed to the death/reincarnation-themed directory the task flagged as the highest-risk shape: d/death/npc/{b,pang,bgargoyle,wgargoyle}.lpc — all four are 阴间判官-style "psychopomp" NPCs placed in the death-zone rooms a player's character is moved into on death (feature/damage.lpc's die() → this_object()->move(DEATH_ROOM), DEATH_ROOM = /d/death/gate, which places npc/pang; the other three sit in new-out*-linked rooms further into the zone). All four have the identical shape: init() unconditionally does call_out("death_stage", 5, previous_object(), 0); with no guard against being re-triggered, and death_stage()'s final stage calls ob->reincarnate() and ob->move(REVIVE_ROOM) — i.e. exactly the "duplicate reincarnation chain" hazard the task describes. Since a netdead reconnect re-broadcasts init() to every object in the reconnecting player's environment (the same mechanism the round-two §7.108 fix depends on), reconnecting while standing in one of these rooms mid-chain would schedule a second, independently-ticking death_stage chain overlapping the first — duplicate/interleaved psychopomp dialogue at minimum, and a real risk of a second ob->reincarnate()/ob->move(REVIVE_ROOM) racing the first.

Fix (ported from the task's reference shape, libs/sj/work/d/death/ npc/wgargoyle.lpc, extended slightly — see below): added a per-target "death_stage_active" set_temp()/query_temp()/delete_temp() guard. init() now checks if (previous_object()->query_temp ("death_stage_active")) return; before setting the flag and scheduling the first call_out. death_stage() clears the flag on every exit path (not just the two the sj reference clears) — including the "turned out not to be a ghost, attack/kick them instead" branches in b.lpc/bgargoyle.lpc/wgargoyle.lpc and the max_gin/kee/sen <= 0 early-return in bgargoyle.lpc, which the sj reference's own fix leaves un-cleared (a latent gap there — if that branch fires, the flag would stay set forever for that player object, permanently blocking any *future* legitimate death_stage chain for the same login session). Applied identically across all four files; confirmed each diff is minimal (git diff --stat, 9-17 lines changed per file, all plain-LF files so no CRLF risk).

Live reproduction and verification (single script, deterministic timing, native build-debug driver, fresh debug.log):

• Triggered a real death via call qintan->die() as the seeded admin (exercises the actual die() apply combat calls too — not a synthetic path) — confirmed qintan moved to /d/death/gate (阴阳界) with npc/pang (崔珏, 朱笔判官) present, matching feature/damage.lpc's documented DEATH_ROOM/start_death() flow (DEATH_ROOM->start_death(this_object()) is itself a pre-existing, harmless no-op — no start_death() function exists anywhere in the codebase, and LPC's call_other()-to-undefined-function silently returns 0 rather than erroring; not fixed, dead but non-fatal, noting for the record).
• Closed the qintan socket ~0.6s after the death-move (simulating a network drop) and reconnected ~1.5s later — the reconnect landed during the ~5-10s window (confirmed via wall-clock timestamps in the test script), i.e. squarely between death_stage stage 0 (fired ~5s after entry, its message text arrived mid-login) and stage 1 (due ~5s later). This is exactly the race window the fix closes. Watched the full remaining chain: stages 1, 2, and 3 (崔判官's four dialogue lines) each printed exactly once, at the correct ~5-second cadence, with no duplicate or interleaved text — confirming the guard blocked the second init() broadcast (triggered by the reconnect's enable_commands()) from scheduling a competing chain.
• debug.log (freshly cleared at boot) stayed completely empty through the whole death→reconnect→chain→revive sequence — no errors, no "Too deep recursion.", nothing.
• A follow-up connection confirmed the chain completed correctly exactly once: qintan ended up in the real revive room (荒郊小店, "Wilderness Small Shop") with its own corpse and board present, score showed 被杀 incremented to 二 (2, correct — two real deaths this session), and hp showed 气血 56/200 recovering (not stuck at the post-death floor of 1) — direct live evidence heart_beat resumed correctly after the reconnect (confirms the §7.113 code-read finding above without relying on the unreliable call-based query_heart_beat() check the task warned about).

Economy: completed a real purchase (round-two gap closed)

Round two flagged "no successful purchase completed live" as an honest gap. This round closed it: discovered live that score's "存款" (bank deposit, the "balance" property) is not the currency cmds/std/ buy.lpc's can_afford()/pay_money() check — those check for actual money *objects* carried in inventory (feature/finance.lpc, presence- checks coin_money/silver_money/gold_money/gold-coin_money/ thousand-cash_money), a deliberate two-tier economy (bank deposit vs. cash-in-hand), not a bug. Used the seeded admin to clone /obj/money/ silver, set_amount(50), and give it to qintan; buy jiudai from xiao er then succeeded correctly (你向店小二买下一个桂花酒袋。, inventory and remaining silver both updated correctly, 49 taels left). Confirms the vendor/purchase code path is sound.

Board post/read: live-verified end to end

南城客栈留言板 (obj/board/nancheng_b.lpc, a BULLETIN_BOARD instance — the same class the corpus-wide §7.86 sweep touched in this lib, previously only compile-checked, never live-played) — read new and post <title> (via the real ed-editor flow, <body text> then . to end) both worked correctly as the seeded admin (posting requires either wizard status or literate skill ≥ 10, a real, intentional gate — a fresh player correctly gets "还是先去学点读书写字吧！" instead, not a bug). Confirms the §7.86 fix (dropping the redundant replace_program() call) did not break the underlying post/read mechanism it was applied to. (Test churn: reverted the board's own save file, data/board/nancheng_b.o, after confirming the post worked — kept the fix, not the test data.)

Other things tested, no issues found

• Registration (fresh char, qintan/秦探三): clean, same flow as prior rounds.
• goto, call, clone, give wizard commands: all work correctly for the seeded fluffos admin account.
• Reconnect while netdead (silent, no quit): resumes in place, per prior rounds' findings — reconfirmed here as a side effect of the death-chain test's own reconnect step.

Housekeeping

Driver killed by exact PID (kill 102769; verified via ps and ss -tln that both the process and port 40048's listener were gone) after confirming readlink /proc/102769/cwd matched this lib's work/ directory. Reverted incidental save-file churn that wasn't real test evidence: data/board/nancheng_b.o (the test board post) and the seeded admin's data/login/f/fluffos.o / data/user/f/fluffos.o (pure key-reordering + last_on timestamp bump from login activity, no real state change). Kept qintan's save files (data/user/q/qintan.o, data/login/q/qintan.o) as playthrough evidence, consistent with prior rounds' convention — it demonstrates a full death→reincarnation→revive cycle survived two real deaths cleanly. adm/etc/banned_name picked up 秦探三's name-reservation entries (kept, since the character save is kept). No scratch files were left in the lib's own directory (test scripts lived under the session scratchpad, not the repo).

本轮修改的文件 / Files modified this round:

• libs/yueyingqiyuan/work/d/death/npc/b.lpc
• libs/yueyingqiyuan/work/d/death/npc/pang.lpc
• libs/yueyingqiyuan/work/d/death/npc/bgargoyle.lpc
• libs/yueyingqiyuan/work/d/death/npc/wgargoyle.lpc

§7.100 sweep (2026-08-19)

Fixed the corpus-wide inherit ROOM; ... replace_program(ROOM); redundant-replace bug (AGENTS.md §7.100). 369 live occurrences deleted: 365 via scripted sweep (fix_710_room.py), plus 4 hand-fixed roommaker-tool templates across 4 separate tool copies (obj/roommaker.lpc, d/wiz/roommaker.lpc, u/misc/roommaker.lpc, u/stone/obj/roommaker.lpc — all simple string-builder variant). 8 already-commented-out instances (incl. 2 in u/wiz/citymaker/citymaker.lpc) left untouched. No real .lpc source found under work/data/. Verified via build-debug driver boot: clean compile, port 40048 listening, zero new "cannot replace"/"cannot bind" debug.log lines.

§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.

AGENTS.md §7.19: enable_player() reentrancy guard (2026-09-01)

Same corpus-wide bug class as mhxy/wuhanzhan: feature/command.lpc's enable_player() wraps enable_commands() and is unconditionally reachable from an NPC's init() via setup()/reset_me() (confirmed on this lib's own d/*/npc/zhangmen*.lpc-family NPCs, matching mhxy's originally-documented d/xueshan/npc/zhangmen.lpc pattern). Calling enable_commands() on an object that's already living() makes the driver re-invoke that object's init() as a side effect; since init() calls back into enable_player(), that is genuine same-call-stack reentrancy that repeats until "Too deep recursion" aborts a room's first-ever visit.

Fixed with a true reentrancy flag (nosave private int in_enable_player_now;), NOT a bare if (living(this_object())) return; guard — this lib's feature/damage.lpc revive() and cmds/std/sleep.lpc wakeup()/wakeup2() all legitimately re-invoke enable_player() while the object is still living() (that's how a fainted/asleep character gets commands back), so a living()-gated guard would silently break every one of those real re-enables. enable_player()'s single body has no early return statements, so the flag is set at entry and cleared once, before the function's fall-through end. Verified with a single-file lpcc compile check (exit 0, no errors) against feature/command.lpc.

深度功能测试（§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）— undefined macro and simul_efun gaps

• 2 file(s) inherit F_SSERVER; and no header defines it (1 did not compile: syntax error, unexpected L_IDENTIFIER, expecting L_STRING or '('). #define F_SSERVER SSERVER in include/globals.h (KB 04 §6.2, scripts/lpc_alias_macro.py). 0 still fail.

深度功能测试（§10.7，2026-10-05）— here-document terminators

scripts/lpc_fix_heredoc_terminator.py --all --apply: 1 here-document block(s) repaired (1 with the terminator glued to the last text line, 0 with it indented), so End of file in text block no longer hides the room or object behind them: d/moon/bedroom.lpc. The terminator must start its line (the lexer's own test, KB 04 §6.10); a glued one lost its newline in the GBK -> UTF-8 conversion together with a half character, which stays out.

深度功能测试（§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 yueyingqiyuan: 1 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 2 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): 1 PASS -> 2 PASS, 0 that loaded before fail now, 1 more load.

1 files moved (1 .C); mostly under d/shushan/xianjing.C (1). A rescan with scripts/lpc_warnings.py yueyingqiyuan is still due: the renamed files are compiled for the first time.

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

scripts/lpc_resilient_room.py --apply: make_inventory() of std/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-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）— 任务表里的 .c 路径与任务守护进程的防护

scripts/lpc_dynamic_rows.py：d/obj/quest/dynamic_location、d/obj/quest/dynamic_quest 里 3084 行写的是原档案的 .c 路径。转档时文件已改名 .lpc，而显式后缀按原样解析，load_object("/d/x.c")、new("/d/obj/quest/x.c") 返回 0 且不报错（KB 03 §4.2，KB 06 §7.220），所以 adm/daemons/questd.lpc 读到的每一行都加载不出来：随机任务和任务物品从未生成，在 create() 里直接对结果调用 tar->set() 的版本还会崩溃，连带加载它的 cron 守护进程和 give 的任务钩子。这些行已改为 .lpc；另有 3 行指向的文件两种后缀都不存在（档案缺内容），保持原样。 scripts/lpc_dynamic_quest_guard.py：1 处 spread_quest() 调用（init_dynamic_quest() 的循环里）包进 catch()，缺失的任务物品或编译不过的房间只跳过那一个任务，守护进程照常加载、其余任务照常生成；cmds/std/look.lpc 夜间检查的 !present("fire", this_player()) 前加 objectp(this_player()) &&（房间 reset() 销毁物品时 /feature/move.lpc 的 remove() 会调用 look_room()，此时没有 this_player()，present(…, 0) 报 Bad argument 2 to present()）。 验证：adm/daemons/questd.lpc和 cron 守护进程在新进程里加载（HEAD 一次，工作树三次，选房是随机的）：HEAD 通过 2 个，工作树三次分别通过 2、2、2 个（共 2 个），无回退。 验证：改动过的 adm/daemons/questd.lpc、cmds/std/look.lpc 在新进程里加载，HEAD 通过 2 个、工作树通过 2 个（共 2 个），无回退。

深度功能测试（§10.7，2026-10-05）— 房间列出的物件缺档时房间照常加载

房间基类 std/room.lpc：reset() 的 case 1: 拿到 0 就跳过这一项（if (!objectp(ob[list[i]])) break;）。档案里没有的 NPC 或物品（或 create() 出错的物件）原先会让列出它的房间整个加载失败（Bad argument 1 to environment()，或对 0 的 call_other()），连带这个房间后面的区域；现在房间照常加载，只是少了那个物件，下次 reset() 再试（KB 05 §7.25；scripts/lpc_resilient_room.py、scripts/lpc_room_reset_guard.py）。 验证：探针（scripts/lpc_room_reset_probe.py：房间基类列出一个不存在的物件，再调用 reset()）HEAD 单件 崩溃、多件 OK，工作树 单件 OK、多件 OK。

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

scripts/lpc_warnings.py yueyingqiyuan --fix：无用局部变量 1697 个、varargs 60 处、转义 64 处、nosave 函数 12 个改 protected、裸 return 7 处，共改动 888 个 .lpc。这些文件在 HEAD 与工作树分别加载（新进程）：842 -> 842 通过，无回退；scripts/lpc_audit_removed_locals.py HEAD 的 24 条候选都是声明被重建（仍在用的名字保留；有 #if 的只有 d/city/piggy*.lpc，与被删的名字无关）。手工：adm/daemons/natured.lpc update_day_phase() 的 for (i; ...)（初始化部分无作用）改为 for (; ...)，i 在上一行已置 0。启动时警告 613 -> 0；新进程启动后登录界面（gb/big5 选择、"工作没做完"问答、英文名校验）正常。剩下 407 条诊断都在本来就不能编译的 224 个文件里。

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

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

• daemon/skill/*-archery.lpc practice_skill()：(: throw_weapon :); 只造函数指针不调用（练习本就不该射箭），删去。
• 改动的对象 HEAD 与工作区都能载入，无回退。

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

• daemon/skill_wiz/archery/xuanyuan-archery.lpc practice_skill()：(: throw_weapon :); 只造函数指针不调用，删去。
• 改动的对象 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-14：新驱动（FluffOS 970d9f09）报 Float value truncated to int（#1426）。2 个文件 6 处：赋值、初始化、return 改写成 to_int(...)（值不变，只是写明截断）。改动的对象新进程各载入一次，无回退（scripts/lpc_fix_float_trunc.py，KB 04 §6.10）。
• 2026-10-14：同一次重扫的其余 45 条（xiyouji 同源，照 wuhanzhan/hxxtjqb 的修法）：obj/npc/ghost.lpc 自己声明 int ghost = 1;，而 feature/damage.lpc 有同名的 int ghost = 0;，基类读的始终是 0，鬼魂 NPC 从不算鬼魂；去掉叶子的声明，在 create() 里给基类的 ghost 赋 1。www/relative/dns_master.lpc 的 #if PREF_TELL & SVC_TCP 放在 if { } 里面，选项关闭时剩个空块，移到 if 外面。d/wudang/npc/newplace.h 的房间表 path 与 feature/command.lpc 的指令路径同名，改名 move_dirs（含三个包含它的 NPC）。其余：kaifeng ground.h 守卫、jiasha 两个 init() 都调用、yaoguai_type 重复、colors.h 防重复包含、alias.lpc 的 last_time 改 last_cmd_time（sanhua-counter 自己存档的同名字段）、die/unconcious/kill_ob 改 void、7 个文件多余的 inherit F_CLEAN_UP。改动及受影响的对象（33 + 18）新进程各载入一次，无回退。

• 2026-10-14：1 个文件的函数声明为 int（或 void）却返回字符串、对象（int query_seal() { return "…"; }），旧驱动照样把值交给调用者；改为实际返回的类型（scripts/lpc_fix_void_return.py）（KB 04 §6.1、§6.3）。新进程比对 HEAD 与工作树：1 个对象，新增载入 1，回退 0。

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

本库 feature/damage.lpc 的 receive_damage() 不接受 jingli/neili/force 等种类，me->receive_damage("jingli", 30) 之类在练功、绝招、吸取时报 F_DAMAGE: 伤害种类错误。4 处改为 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，而不是作者写好的提示。1 处在声明行加上 if (!mapp(fam)) fam = ([ ]);（scripts/lpc_fix_family_guard.py）。

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

22 个文件（技能、绝招、兵器、书籍、区域 NPC 等）来自侠客行体系（qi/jing/neili），而本库人物是 gin/kee/sen/force：receive_damage("qi", ...) 报 伤害种类错误，query("neili") 永远为 0。按 qi→kee、jing→sen（本库学习/读书指令消耗的就是它）、neili→force、max_neili→max_force、jiali→force_factor 改名（scripts/lpc_port_es_props.py --any-file）。

治疗/疗伤的属性名（2026-10-15，KB 06 §7.241）

receive_heal()/receive_curing() 也只接受本库的种类。1 个文件（多为只调用 receive_heal/receive_curing 的药物、NPC）来自侠客行体系，按 qi→kee、jing→本库学习指令消耗的池、neili→force 改名（scripts/lpc_port_es_props.py --any-file）。

转码吃掉的引号（2026-10-15，KB 03）

原档在右引号前有一个孤立的 GBK 前导字节，转 UTF-8 时连引号一起丢了（如 return name + HIM "发作身亡了;），字符串一直延续到后面，文件编译失败：/d/obj/books-nonskill/hmeng014、/d/wusheng/shijie5。补回引号（scripts/lpc_fix_eaten_quote.py）。

->query_( 笔误（2026-10-15，KB 06 §7.245）

调用不存在的函数 query_，call_other 静默返回 0，相关判断永远按 0 计算。改为 ->query(：fuhu、fuhu、lianhuan、buhui。

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

16 个文件、21 处在 create() 里 carry_object("<本库没有的文件>")->wear()（或 wield()、set_amount()），多是从别的系统搬来的 NPC 用了原系统的物品路径（最常见：/d/city/npc/obj/choupao、/d/city/npc/obj/bingfu、/d/liwu/obj/jiericloth）。本库 NPC 基类 std/char/npc.lpc 的 carry_object() 第一句是 if (file->query_unique())，对不存在的文件直接 call_other，驱动在这里报 call_other() couldn't find object，new() 来不及返回 0，所以只要 NPC 带着一件本库没有的物品就载入不了（调用处加判断对它无效）。在它前面补 if (!objectp(load_object(file))) return 0;（--base），缺的物品就跳过，NPC 照常载入；上面那些调用处同样改成带判断的块（基类以后改回去也不怕）。载入检查：改动的文件改前能载入 1 个，改后 15 个（14 个原来载入不了），没有退步；其余 2 个另有原因（多为 set_skill() 了本库没有的武功）。

去掉的预定义宏 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。netmail 是网络邮件守护进程（本库缺 mailer.h 等头文件，改后仍载入不了）。改后用 lpcc 逐个载入这些对象：0 个通过，1 个还有别的错误（adm/daemons/network/netmail：/adm/daemons/network/netmail.lpc:17: error: Cannot #include mailer.h）。

蓬莱三星的 ref() 是保留字（2026-10-18，KB 04 §6.14）

福星、禄星、寿星（d/penglai/npc/）里有一个函数叫 int ref ()，call_out("ref", 20) 去调它；ref 在 FluffOS 里是关键字（引用），unexpected L_REF，三个 NPC 都载入不了。函数和 call_out 都改叫 reff（本系里 dtxyzjb、zitengzhan 早就这么改，call_out 却没跟着改）：d/penglai/npc/luxing.lpc、d/penglai/npc/shouxing.lpc。改后载入：2/2 通过。

d/moon/obj/poem 两句诗丢了收尾的引号（2026-10-18，KB 03 §4.6）

string *poem 数组里 "不放玉花飞堕地，留在广寒宫阙。, 和 "把酒送春春不语，黄昏却下潇潇雨。, 的收尾引号没了（转码时跟半个汉字一起丢了），下一行的开引号把字符串合上，后面的诗句成了代码：Illegal character 0xe6，整个物件载入不了。补回 ",。载入：通过。

d/shendian/obj/niepan 的收尾引号变成了私用字符（2026-10-18，KB 03 §4.6）

set("long", HIR"……五种符号<U+E4D4>NOR); 里本该是 " 的位置是一个私用区字符（转码时半个汉字加引号被换成了它），Illegal character 0xee，整个物件载入不了。换回 "。载入：通过。

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 载入不了，刷出它的房间也少一个人。本库有 18 个对象设了本库没有文件的武功（28 个名字，最多的是 fumozhang、magic、sevensteps）。三处都改成 return：这一门武功不给、不映射，对象照常载入，只是少了它（缺的武功本身仍是内容缺口）。抽样载入这些对象：18 个里 16 个通过，其余 2 个停在别的错误上（d/dntg/yunlou/npc/yg-phoenix：*Bad argument 1 to EFUN call_other()；d/dntg/yunlou/npc/yg-wusheng：*Bad argument 1 to EFUN call_other()）。（scripts/lpc_guard_set_skill.py）

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

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

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

下面这些基类本库没有，继承它们的对象（房间、NPC、物品）整批载入不了（inherit XXX; 的宏没定义，或者 inherit "/std/…"; 的文件不在）。同系的库里有同名文件，两库有大量逐字节相同的文件（亲缘关系），所以从那边原样拷来，缺的宏补进全局头文件 include/globals.h：/std/weapon/unarmed（宏 UNARMED）←sjsh，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 映射不到，门派弟子用普通轻功/拳脚）。按核对过的对照表改正，共 31 处、21 个文件：fumozhang→fumo-zhang（6 处）、sevensteps→seven-steps（4 处）、dagonforce→dragonforce（4 处）、ningxie-force→ningxue-force（4 处）、hellfire_whip→hellfire-whip（3 处）、yange_blade→yange-blade（2 处）、huxing-step→huxing-steps（2 处）、lahua-shou→lanhua-shou（2 处）等共 12 个名字。（scripts/lpc_fix_skill_names.py）

调用了父类没有的函数的对象（2026-10-19，KB 06 §7.259）

::create();、::init();、return ::buy_object(who, item); 这类调用写的是父类里有这个函数的版本；本库的父类没有，旧驱动把它当空操作（返回 0），现在的驱动在编译时就报 Unable to find the inherited function，整个对象载入不了。单独成句的调用删掉，return ::f(...) 改成 return 0;（void 函数里是 return;），与旧驱动的行为一致。共 1 处、1 个文件：::buy_object()（1 处）。只改了出错原因全是这一类的文件；还带着别的错误（多半是父类本身没了）的文件没动，等父类补回后再看。（scripts/lpc_fix_dangling_super.py）

同一个函数原样贴了两遍（2026-10-19，KB 06 §7.264）

同一个文件里同一个函数被原样贴了两遍（除空白外逐字相同），驱动报 Redeclaration of function，整个物件载入不了。删掉第二份及以后的副本，共 1 处：/daemon/skill/huitian-shenjue.lpc 的 exert_function_file()。（scripts/lpc_fix_dup_functions.py）

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

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

同一个 init() 写了两遍、内容不同（2026-10-19，KB 06 §7.265）

d/xuyi/npc/maihuanu1 里 init() 定义了两次（一个加 buy/work 之类的指令，另一个再加 list/block_cmd），驱动报 Redeclaration of function 'init'，整个物件载入不了。两处作者本来都要：把第二个 init() 里的 add_action(...) 并到第一个 init() 末尾，删掉第二个。（scripts/lpc_merge_dup_init.py）

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

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

• /d/shushan/zhenyaota/bamboo.lpc 的 south 出口：houshan → bamboo2

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

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 文件。

被注释吞掉的 inherit / include（2026-10-19，KB 06 §7.274）

/daemon/class/moon/moonshentong/shiyue.lpc：inherit SSERVER;。这些指令接在上一行 // 注释的末尾（档案里丢了换行），成了注释的一部分，驱动看不到：缺 inherit 的技能报 Undefined function offensive_target，缺 #include <weapon.h> 的兵器报语法错误。scripts/lpc_fix_swallowed_directive.py 把换行放回去。载入检查 1 个文件，1 个原来编译不过、现在载入，没有退步。

补回丢失的标点（2026-10-19，KB 03 §4.6）

转换时丢掉的分号、逗号、引号或文件末尾的 }，共 5 个文件，修前 HEAD 载入失败。别的库里同路径的完好副本只比这里少几个标点，按它补回（括号里是那个库）：/d/jz/npc/jiang.lpc（dtxyzjb）。文件末尾少了 }（最后一个或两个字节丢了），补上：/u/bmw/room/workroom.lpc（2 个）、/u/stone/zhuxian/xiaolu5.lpc、/u/stone/zhuxian/xiaolu6.lpc、/u/stone/zhuxian/xiaolu7.lpc。修后与 HEAD 逐个对比载入：这 5 个物件全部载入，没有退步（scripts/lpc_restore_from_twin.py、lpc_fix_eaten_quote.py --comma、lpc_fix_eof_braces.py）。

call_out_info() 的每一项只有 3 个元素（2026-10-20，KB 06 §7.287）

驱动返回的是 ({ 物件, 函数, 延迟 })，不带 call_out 的参数，旧代码读第 4 项 info[i][3]（callouts 指令、calloutd、cod 工具）一读就报 Array index out of bounds，指令从第一行起什么也打印不出来。改为 (sizeof(info[i]) > 3 ? info[i][3] : 0)（scripts/lpc_fix_callout_info.py）。改动：/cmds/wiz/callouts.lpc（1 处）。

浩劫系统 verdict_time()：领头玩家已经离线时 lead->name() 报错，戒严不解除（2026-10-20）

三十分钟后收场时 lead（接战书的玩家）若已退出游戏就是 0，lead->name() 在宣布战果的 message() 里报错，后面的 LOGIN_D->set_madlock(0) 不再执行，戒严一直保持，quit 指令因此对所有人关闭。改为 (lead ? lead->name() : "各派豪杰")。改动：/feature/disaster.lpc（2 处）。

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，共 16 处）。改动：/cmds/wiz/dns.lpc（1 处）、/d/city/mjlady3.lpc（3 处）、/d/city/npc/jing.lpc（3 处）、/d/fenghuang/npc/mj.lpc（3 处）、/d/obj/medicine/liushen.lpc（1 处）、/d/shendian/babu/obj/longzhua.lpc（4 处）、/www/cgi-bin/board_h.lpc（1 处）。

callouts：sizeof(info[i]) == 4 把每一行都挡掉了（2026-10-20，KB 06 §7.287）

驱动的 call_out_info() 每项只有 3 个元素，输出行前的守卫 if (sizeof(info[i]) == 4) 永远不成立，指令只打印表头。改为 >= 3。改动：/cmds/wiz/callouts.lpc（1 处）。

socket / dumpsocket 指令：dump_socket_status() 驱动里没有（2026-10-20，KB 06 §7.291）

这些巫师指令 write(dump_socket_status());，MudOS 的 efun 在 FluffOS 里不存在，指令编译不过。在模拟 efun 文件里补了 dump_socket_status()：用 socket_status() 排出同样的表（没有 sockets 包的构建，比如 WASM，只有表头；scripts/lpc_add_sefun.py dump_socket_status）。

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

访客计数 howmany_visitor() 读文件不检查（2026-10-20，KB 06 §7.301）

howmany_visitor() 读访客计数文件（VISITORS / COUNTER / BBSVISITOR，只有运行中的 mud 才会写；.gitignore 把它排除在仓库之外），新检出的树里没有，read_file() 回 0，sscanf(0, ...) 报错。这份副本登录时不一定走到它，但调用时同样会出错。在读文件之后加了 if (!stringp(content)) return 0;（xkx100、xiakexing100、zzfy 早先的写法，scripts/lpc_fix_visitor_count.py）。改动：/www/cgi-bin/logind.lpc、/www/relative/logind.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 个文件）。

巫师命令不带参数时对 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/adm/dumpprog.lpc（new）。加载检查 HEAD 与工作树对照，没有退步。

cron.lpc：emery() 用循环外的下标，第一次越界就让 cron 停摆（2026-10-21，KB 06 §7.345）

怪兽入侵事件 emery()（/adm/daemons/cron.lpc）末尾 for (m = 0; m < sizeof(user); m++) user[i]->set("kill_guaishou", 1);：i 是前面随机选的地区下标，循环变量 m 没用上，同一个玩家被标记 sizeof(user) 次，在线人数不到 i + 1 时下标越界（Array index out of bounds，yueyingqiyuan 管理员扫描里的控制台行；call /adm/daemons/cron->emery() 一个人在线时四次里三次抛错）。init_cron() 在 15 分钟的整点调用 emery()，之后才 call_out("init_cron", 60) 重新排自己：抛错之后重排没有执行，玩家自动存盘（autosave()）、动态任务刷新（TASK_D->init_dynamic_quest()）和后面所有事件在这次启动里都停了。改成 user[m]（yueyingqiyuan 上实测：连续六次 emery() 都正常返回）。这个标记档案里没有任何地方读它（go.lpc 里的用法是注释掉的）。

观礼台 d/city/under.lpc：wait_and_start() 里的 fan 没赋值，比武开不了（2026-10-21，KB 06 §7.346）

接受挑战（defend）两秒后 wait_and_start() 调用 fan->command("chat ...比武开始")，object fan; 声明了却没有 fan = load_object(__DIR__ "npc/fan");（dtxywzxzb 的同一份文件有），抛错之后两条 kill 和 call_out("finish_match", 300) 都不执行，比赛不开始。补上这一句（npc/fan.lpc、ground.lpc 本库都有）。

ccast、ssteal、jji、pperform：新手保护检查贴在目标赋值之前（2026-10-21，KB 06 §7.346）

/cmds/std/ccast.lpc、/cmds/std/jji.lpc、/cmds/std/pperform.lpc、/cmds/std/ssteal.lpc：vikee 加的“本站暂时保护新手”检查 if (userp(target) && target->query("age") < 16)（以及后面两句 ... && userp(target)）贴在 target = present(...) 之前。老驱动里 userp(0) 是 0，这几句从来不会触发；这里 userp(0) 抛错，指令一用就死。保持原来的（不触发）效果：赋值之前的 userp(target) 改成 objectp(target) && userp(target)。pperform 的检查还写着没声明的 obj->query("target")（整条指令编译不了），改成 target->query("age")，和其他几条一致。

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

计时器或输入提示给驱动的函数名和文件里定义的差一个字母；驱动对不存在的函数静默不理，所以对应的计时从来没有触发过。调用和配套的 remove_call_out() 改成已定义的拼法：find_seal：disapprear → disappear（法术产生的封印十分钟后从不消失）。改动：/d/jjf/obj/find_seal.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.，同一个动词的其他处理函数不再尝试（不是最新的一条就悄悄跳过）。删除了 25 条注册（16 个文件，scripts/lpc_fix_dead_add_action.py），动词留给别的处理函数：/d/changan/pinqiting.lpc（do_pass、do_resign）、/d/city/liwu/npc/spiriter.lpc（do_buy、do_list）、/d/city/npc/duguoyin.lpc（do_vendor_list）、/d/city/npc/spiriter.lpc（do_buy、do_list）、/d/city/zhuxian/npc/guard.lpc（do_bian）、/d/city/zhuxian/npc/guard1.lpc（do_bian）、/d/eastway/npc/petboss.lpc（do_cost、do_list、do_upgrade）、/d/eastway/petboss.lpc（do_cost、do_list、do_upgrade）、/d/guzhanchang/shuitan.lpc（do_jump）、/d/kaifeng/leitai12.lpc（do_action） 等共 16 个文件。最多的函数名：do_list 4 处、do_bian 4 处、do_buy 2 处、do_cost 2 处、do_upgrade 2 处。没有动（读过）：/d/update/stone/obj/guo.lpc 的 do_eat（对象本身编译不过，登记留着，等对象能加载再处理）。

(: 函数 :) 指针指向对象自己没有定义的函数（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。 还剩 2 个函数没有补（inquiry 1, chat_msg_combat 1）：原型还在函数体丢了、或者根本没写过，没有可以直接补回的捐赠（别的库同一路径的文件里没有这个函数，或者它还要用本库没有的辅助函数、签名不同），不编造：/d/death/npc/yanluowang.lpc:ask_cancel、/d/xueshan/obj/hufabird.lpc:saysth。 另有 3 处函数体被作者整段注释掉（指针没跟着删），是有意关掉的，没动。

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

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

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

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

本库 2 处（1 个文件）：拼名字的赋值 2 处。例：name[0..1] → name[0..0]（/d/nanhai/npc/tidu.lpc:128）。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，不要重跑。

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

vikee 新手门在 present 之前（2026-10-27，KB 06 §7.348 Also）

ssteal / pperform / jji / ccast（及同族 steal/cast）里 vikee 加的年龄 / 经验 / 道行门用 objectp(victim|target)，却写在 present() 赋值之前：局部仍是 0，门永远不进。挪到 present 与空指针检查之后，并去掉多余的 objectp。证明：HEAD ssteal 仍在 present 前有 objectp(victim)；改后在其后且对象加载成功。

家丁 CLOTH_OB()/WEAPON_OB() 调用式宏（2026-10-27，KB 04 §6.16 Also）

d/wuguan/npc/jiading.lpc（及 jiading1，xlqy 系在 d/dntg/hgs/wuguan/npc/）写 carry_object(CLOTH_OB("cloth")) / WEAPON_OB("changjian")：库中没有带参的 CLOTH_OB，WEAPON_OB 在 globals.h 只是裸路径 "/d/obj/weapon/"，展开成 "/d/obj/weapon/"("changjian") 语法错误，NPC 无程序。同目录其它 NPC 用 __DIR__ "obj/cloth"；剑在 /d/obj/weapon/sword/changjian。改成这两条（目标文件均在树内）。证明：HEAD Undefined function CLOTH_OB；改后 new() 成功且 inventory 为 2。

黑风山 pusa1 用未声明的 ob 且函数外残留 call_out（2026-10-27，KB 06 §7.348 Also）

d/qujing/heifeng/npc/pusa1.lpc 的 announce_success(object who) 写成 if (!ob->query("obstacle/hf"))（Undefined variable 'ob'），同目录 pusa.lpc 是 who->query("obstacle/hf") == "done"；who->save(); } 之后还残留 call_out("die"...); return; }，落在函数外（unexpected L_STRING），对象无程序。改成与 pusa 相同的门，并删掉残留语句。证明：HEAD 加载失败；改后加载成功。

雪山 obj/hufabird set_level 缺 }（2026-10-27，KB 04 §6.28 Also）

d/xueshan/obj/hufabird.lpc 的 set_level 在 setup(); 后少了一个 }，后面的 int heal_up() / leave / invocation / die 都嵌进了 set_level（unexpected '('），对象无程序；同目录 npc/hufabird.lpc 正常关闭。顺带：messege_vision→message_vision，return : die()→return ::die()，以及无 saysth 的 (: saysth :) 按 7.355 注释掉。证明：HEAD 加载失败；改后加载成功。

洗衣盆 is_container 映射缺值编不过（2026-10-27，KB 04 §6.28 Also）

d/gao/obj/pen.lpc（或 d/qujing/gao/obj/pen）的 is_container() 写成 set("objects", ([ "/u/bula/gao/obj/kaoji" ]));：映射只有键没有值（unexpected ']'），对象无程序。同族 hy5 / xyj2000 已把该函数注释掉。改成标准的 return 1;。证明：HEAD 加载失败；改后加载成功。

月宫 quest/road 模板缺 index（2026-10-27，KB 06 §7.348 Also）

d/moon/quest/road.lpc（及误放在 npc/road.lpc 的副本）出口写 sprintf("%d", index ± 1)，却没有像 road1…road10 那样声明 int index = N;（Undefined variable 'index'），对象无程序。补上 int index = 5;（中间段，东西出口都能落到已有房间）。证明：HEAD 加载失败；改后加载成功。

星君/罗汉模板缺 ID 宏（2026-10-27，KB 06 §7.348 Also）

d/dntg/sky/stars/star.lpc 与 d/nanhai/luohan/npc/luohan.lpc 用 title[ID] / first_name[ID]，真正带号的副本是 #define ID N 再 #include 本文件；单独编译模板时 Undefined variable 'ID'。加 #ifndef ID / #define ID 0 / #endif，带号 include 仍用各自的 N。证明：HEAD 模板加载失败；改后模板与 stars/5、luohan5 均加载成功。

雷神 check 在 stop_fight 定义之前调用且 call_out 缺逗号（2026-10-27，KB 04 §6.28 Also）

d/qujing/start/24/1.lpc 的 check() 里调用 stop_fight(who)，函数却写在后面（Undefined function stop_fight）；call_out("lost", 1 who) 少了逗号（unexpected L_DEFINED_NAME）。把 stop_fight 挪到 check 之前，并改成 call_out("lost", 1, who)。证明：HEAD 加载失败；改后加载成功。

toy 旁缺 message.h（2026-10-27，KB 04 §6.23 Also）

obj/toy/*.lpc（及少数 obj/obj/toy、嵌套副本）写 #include "message.h"，引号 include 只解析同目录；本 lib 的 d/obj/misc/message.h 有同内容副本，toy 目录没有。玩具对象无法编译（Cannot #include message.h）。从本 lib 的 d/obj/misc/message.h 复制到缺失的 toy 目录旁。证明：HEAD buwawa 加载失败；改后加载成功。

玉皇 yuhuang1 去引号无法加载（2026-10-27，KB 04 §6.25 Also）

d/dntg/sky/npc/yuhuang1.lpc：字符串与路径几乎全部丢掉引号（set_name(玉皇大帝,…)、carry_object(/d/obj/cloth/mangpao)、setup() 后无 ;），下一句 int promote_me() 成语法错误。同目录手足 yuhuang.lpc 完好；用本库 yuhuang 字节覆盖 yuhuang1。证明：HEAD 加载失败；改后加载成功。

悬空 ::init / unique::init（2026-10-27，KB 06 §7.259 Also）

kugu-1/2/3、kunxian-suo 写 ::init();，tianyi 写 unique::init();，而 F_UNIQUE / ITEM / feature/unique 没有 init；本驱动编译报 Unable to find the inherited function 'init'（tianyi 带 in file 'unique'），物件无法加载。老驱动把空父调用当返回 0。lpc_fix_dangling_super.py 删掉这些语句；cloth::init() 保留。证明：HEAD 加载失败；改后加载成功。

dami 误调 init_unarmed（2026-10-27，KB 04 §6.25 Also）

d/obj/food/dami.lpc 继承 ITEM+F_FOOD 却调用 init_unarmed(5)（并 #include <weapon.h>），未继承空手兵器基类，驱动报 Undefined function init_unarmed。手足 hymud 已注释该行。删掉该调用与无用的 weapon 头。证明：HEAD 加载失败；改后加载成功。

book-qujing 缺 obstacle.h（2026-10-27，KB 04 §6.23 Also）

d/obj/books-nonskill/book-qujing.lpc #include "/d/qujing/obstacle.h"，档案未带该头，驱动报 Cannot #include。从手足 sjsh 拷入同内容 mapping。证明：HEAD 加载失败；改后加载成功。

深度功能测试（2026-10-27，§6.25 tell_object 参数顺序）

tell_object("…", me/who) 参数颠倒（消息当对象）；改为 tell_object(me/who, "…")（guest.lpc）。证明：残渣 0；抽样 guest/rukou/forest_c 加载。

深度功能测试（2026-10-27，§6.25 tell_object 缺 me（自动放弃/愿否））

一参 tell_object("…") 在已有 me 时改为 tell_object(me, "…")（city.lpc）。证明：抽样 city / xiaolongnv 加载。

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

yuzu：tell_object("钟馗…") → tell_object(criminal, …)。

深度功能测试（2026-10-27，§6.25 tell_object 路径当房间）

tell_object("/…", …) → tell_room(load_object("/…"), …)（去掉 .lpc）。

深度功能测试（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… 行。