金庸文字版.exe → jinyongwenzi (TRIAGE ONLY — not converted)

• Archive: archives/金庸文字版.exe (5,310,958 bytes — archive #90 in TODO.md, flagged "may not be an LPC mudlib at all — triage first" since it's a Windows self-extracting exe, not a normal archive container).
• Duplicate: archives/金庸文字版 (1).exe is a byte-identical duplicate (md5sum 6054d74e855aa660559ee1efc5065287 for both, same size) — only the primary was processed, matching the existing "Duplicate archives" table in AGENTS.md which already lists this pair.
• file: PE32 executable (GUI) Intel 80386, for MS Windows, UPX compressed, RAR self-extracting archive — confirms AGENTS.md's existing note.

Extraction — two attempts, one silently-broken

1. 7z x "succeeded" but is a trap: it printed ERROR: Unsupported Method for 6,409 individual members (exactly the total file count) and Sub items Errors: 6409, yet exited having created every single file anyway — all 6,409 files landed on disk at 0 bytes, correct names/ timestamps, zero content. If you don't check file sizes after a 7z extraction of this SFX, you'd wrongly conclude the archive is full of empty stub files (or, worse, a fake/empty installer). 2. unrar x extracts it correctly — reports All OK, and 6,392 of the 6,409 files came out non-empty (17 zero-byte files appear to be genuinely empty in the source, e.g. some feature/*.c stubs — not an extraction artifact, sizes match plausible real content elsewhere). Lesson for future self-extracting .exe archives in this project: verify with find <dest> -type f -size +0c | wc -l vs total file count after EITHER tool, don't trust a clean exit code alone — 7z's "Unsupported Method" here is a real, silent-failure-mode method 7z's implementation of whatever RAR compression variant this SFX uses doesn't support, but it still writes placeholder files and doesn't propagate a nonzero process exit in a way that's obviously fatal.

Extracted to libs/jinyongwenzi/raw/ (via unrar x).

What's actually inside — THREE bundled things, not one

金庸文字版/
├── shujian/              <- genuine LPC MudOS mudlib (35MB, ~4,915 .c + 130 .h)
├── PZmud462/              <- bundled "PZMUD" (zmud-like) Windows telnet client (4.0MB)
├── hy/                    <- client-side menu/trigger text files for that client (60K)
├── MudOS.exe, mudos.dll   <- prebuilt Windows MudOS 0.9.20 driver binary
├── cmud.exe               <- a second bundled telnet client
├── 金庸文字版(zmud).bat   <- launcher: `start mudos.exe config.sj` + `start PZmud462\zmud.exe`
├── 金庸文字版(cmud).bat   <- launcher: `start mudos.exe config.sj` + `start cmud.exe`
├── config.sj, mudos.ini   <- driver config (config.sj is a genuine MudOS 0.9.20 runtime config)
├── *.mid, MudRoom.INI, MUDCHAR.DAT, ...  <- client-side sound/UI assets for the bundled clients
└── color.c                <- loose file at top level, unrelated to shujian/ (not investigated further)

This is the "bundles multiple things (client + server)" pattern AGENTS.md's pipeline step 2 already warns about, taken to its fullest extent seen so far in this project: a complete turnkey Windows package — driver binary + mudlib source + TWO alternative bundled telnet clients + auto-launch .bat scripts — clearly meant to be double-clicked and immediately play as a "local" experience, which is almost certainly why AGENTS.md's original triage note speculated it might be "a standalone single-player text game, not an LPC/FluffOS mudlib at all." That speculation is not correct — see below.

Determination: GENUINE LPC MUDLIB (do not convert without a dedicated pass — reporting only, per task instructions)

The shujian/ subtree is unambiguously a real, playable-over-the-network MudOS/LPC mudlib, not a single-player game:

• shujian/config.sj is a standard MudOS 0.9.20 runtime config (identical directive set/format to every other lib in this project — mudlib directory : ./shujian, master file : /adm/single/master, simulated efun file : /adm/single/simul_efun, etc.), decodes cleanly as GBK (name : 书剑2002 — "Book and Sword 2002"; 书剑 = 《书剑恩仇录》, one of Jin Yong's novels, consistent with the archive's "金庸" (Jin Yong) framing).
• It declares real network listener ports: port number : 5555 plus external_port_1..5 : telnet 5555/2000/2002/2003/2004 — a networked multi-user telnet server, the opposite of a single-player game.
• MudOS.exe/mudos.dll is a prebuilt Windows MudOS driver binary (mudos.ini → config=config.sj), and both .bat launchers start mudos.exe config.sj FIRST, then separately launch a bundled telnet client (PZmud462\zmud.exe or cmud.exe) to connect to it as a second step — i.e. the "single-player feel" is just a convenience wrapper auto-launching a real client against a real locally-hosted server, not evidence the game itself is single-player.
• shujian/adm/single/master.c is a genuine MudOS master object: real applies (connect(), compile_object(), crash(), catch/log_file/ write_file usage) matching every other lib's master file in this project.
• Directory tree under shujian/ is fully mudlib-shaped: adm/{daemons,etc, simul_efun,single,tmp}, cmds/{adm,app,arch,ass,debug,imm,leitai,skill, std,usr,wiz}, d/ (23 zone/domain dirs: baituo, city, dali, emei, hengshan, hmy, huashan, kunlun, mingjiao, shaolin, songshan, taishan, wudang, xiangyang, xingxiu, xueshan, etc. — Jin-Yong-novel sect/location names), data/{board,group,login,npc,sos,user,wenxuan}, doc/{applies, build,cefuns,efuns,help,html,LPC,skill,story,wizhelp}, feature/, help/, include/{net,race}, inherit/{armor,char,food,item,medicine, misc,room,skill,weapon}, kungfu/{class,condition,skill}, log/.
• 123 files matched grep '^inherit' in a spot sample, and room files under d/ use the standard set("short", ...) idiom — real LPC object definitions, not compiled/opaque data.
• shujian/adm/daemons/ has the exact daemon roster seen across this whole project's lib family (securityd.c, logind.c, chinesed.c, combatd.c, channeld.c, commandd.c, moneyd.c, network daemons, etc.) — same MudOS-lineage architecture as every already-converted lib here.
• Coincidental naming note: libs/bxsj (archive #4, archives/bxsj.rar, already DONE) is a *different* codebase that also self-identifies as "书剑" (there: "书剑天下"/"ShuJian MUD", mudlib root also literally named shujian/). This archive's mud calls itself "书剑2002" — related lineage/ naming convention (both wuxia MUDs riffing on the same Jin Yong novel title), almost certainly NOT the same underlying codebase snapshot (different config port, different top-level bundle shape/client tooling), but worth cross-referencing if this archive is converted later.

**The PZmud462/, hy/, cmud.exe, MudOS.exe/mudos.dll, *.mid, .bat, .INI/.DAT client-and-driver-binary material is NOT mudlib source** and should be excluded/ignored the same way this project already ignores bundled prebuilt drivers/clients in other archives (per AGENTS.md pipeline step 2) — only shujian/ (and its config.sj) is relevant to any future conversion pass.

Per task instructions: STOPPING HERE

Per the triage task's explicit instruction, since shujian/ is genuine LPC mudlib source in a mudlib-shaped tree, no conversion, work/ copy, config.fluffos, port assignment, or driver boot attempt was made — this NOTES.md is a triage report only. If the main session decides to proceed, the next steps would follow the standard pipeline (AGENTS.md pipeline steps 2-7): confirm shujian/ as mudlib root (already done here), assign a port, copy to work/, run the encoding/.c→.lpc/static→nosave passes, then compile/boot per usual. Not attempted in this pass.

Recommendation for TODO.md (left to the main session to apply, superseded below)

Suggest updating archive #90's row from "not started / may not be an LPC mudlib at all, triage first" to reflect the actual finding: it IS a genuine LPC MudOS mudlib (书剑2002, root shujian/) bundled inside a self- extracting exe alongside driver + 2 client binaries; ready for a normal conversion pass whenever scheduled. libs/jinyongwenzi/raw/ currently holds the unrar-extracted tree (7z's extraction of this file is NOT usable — see "Extraction" above, don't reuse a 7z-produced raw/ for this archive).

Conversion pass (this session) — Port 40083. Status: DONE — boots clean, full registration + post-login commands confirmed working over telnet

Lineage confirmation against libs/bxsj (archive #4) — SAME codebase, not just "related naming"

The triage pass above flagged this as "related lineage/naming convention, almost certainly NOT the same underlying codebase snapshot" based only on directory-shape/name similarity. A direct byte comparison proves that call wrong — this is the literal same codebase as bxsj (书剑天下), just saved with different line endings at some point in its history:

• md5sum on adm/single/master.c, inherit/char/master.c, adm/daemons/securityd.c, adm/simul_efun/chinese.c, cmds/arch/chinese.c differ raw (CRLF vs LF), but diff <(tr -d '\r' ...) between bxsj's raw archive and this archive's raw shujian/ is EMPTY (0 lines) for every one of those files — 100% byte-identical content once line-ending noise is stripped out.
• Whole-tree comparison: 5,245 files exist at the same relative path in both raw trees; of those, 3,501 (66.7%) are byte-identical (CRLF-normalized) and 1,744 differ. bxsj also has 6,469 files this archive's shujian/ doesn't have at all (bxsj is a larger, later-grown snapshot — same relationship bxsj1 already has to bxsj, just a different branch/point in time), and this archive has 1,071 files bxsj doesn't have.
• Conclusion: same lineage as the bxsj/bxsj1 family (archives #4/#5), a genuinely different point-in-time snapshot/fork rather than a from-scratch "book and sword"-themed rewrite. Applied the exact 3 known bxsj fixes proactively per the playbook TODO.md already documents ("Once a lib's lineage is recognized ... apply known catalog fixes PROACTIVELY before the first boot attempt") — and found this snapshot has TWO further bugs that bxsj/bxsj1 also have, unfixed and completely undetected there (see "New findings" below — this is the important part of this pass for the rest of the project, not just this one lib).

What was applied proactively, before ever booting (ported directly from bxsj/AGENTS.md, confirmed present via identical-file diff first)

1. adm/single/master.lpc log_error() (AGENTS.md §4 family): added the logging_error reentrancy guard + catch() around CHANNEL_D->do_channel(...). Confirmed the identical unguarded call was present (byte-identical source to bxsj's pre-fix version). 2. adm/single/master.lpc valid_override() (AGENTS.md §14): added the 3rd main_file parameter, plus the shout/write/tell_object/tell_room/say allow-list, exactly as in bxsj. 3. adm/daemons/securityd.lpc valid_read() (AGENTS.md §8c): was if (this_player()) user = this_player(); unconditionally — same bug/same file as bxsj, wrongly attributes a system-initiated load_object() (e.g. master lazily loading an unpreloaded daemon) to whatever player happens to be connected at the time, denying /adm reads a real root-euid caller was always allowed. Fixed to only fall back to this_player() when user has no resolvable euid/uid of its own. 4. adm/simul_efun/chinese.lpc is_chinese() (AGENTS.md §15h, applied here proactively for the first time instead of post-hoc): was checking GBK lead/trail-byte ranges (0xa1-0xfe etc), which silently never match now that str[i] returns a Unicode codepoint on this driver. Replaced with a CJK Unified Ideographs block check (str[0] >= 0x4e00 && str[0] <= 0x9fff). Note: this codebase's own check_legal_name() (which also has the GBK-byte-length-bound half of this bug, per bxsj's NOTES) turned out to have its ONE call site commented out in logind.lpc here — registration never actually invokes it in this snapshot, so that half of the fix was moot for registration specifically, but is_chinese() itself is still called live from several gameplay files (artname.lpc, uweapon.lpc, bboard.lpc, ling.lpc, zhao.lpc, tiejiang.lpc) so the fix was applied anyway.

Routine per-lib mechanical steps (via convert_lib.sh)

• Encoding: 5,579 converted, 669 already UTF-8/ASCII, 34 skipped binary, 33 lossy (spot-checked a sample of the lossy list — control-byte/name glitches in save-data .o/.ppp/.w files and a couple of NPC/map source files with stray invalid bytes; none were in the master/login/ security compile path).
• .c → .lpc: 4,915 files. 0 uppercase .C stragglers (checked). 0 un-converted GBK masquerading as .lpc/.h (checked with the file -b straggler sweep from AGENTS.md's Encoding section).
• 417 literal .c" refs auto-fixed, 0 left over.
• 6 local #include <x.lpc> angle-bracket includes converted to quoted form (AGENTS.md §8d), 0 absolute-path or ..-relative angle includes found (checked, none present).
• static → nosave: 80 files.
• No extensionless-file/.c-backup pairs found (AGENTS.md §15ak checked explicitly across the whole raw tree — 0 hits, doesn't apply here).
• No nosave/protected compatibility-macro redefinition collision (§15z), no bare array declarations (§15f), no LONELY_IMPROVED-style flag (§15v), no phone-home license check (§15u), no ed_start/ ed_cmd/query_ed_mode calls outside doc/cefuns/ documentation stubs (§15ag) — all checked and confirmed absent/not applicable.

§15c: /adm/etc/preload bare .c refs (found and fixed)

Two of the 14 preload entries were bare paths with a literal .c suffix (/adm/daemons/questd.c, /adm/daemons/cron.c) — not caught by the quote-anchored .c" auto-fixer since this is an unquoted plain-text data file (exactly AGENTS.md §15c's documented shape). master.lpc's preload() does file_size(file + ".lpc") before loading, so "questd.c" + ".lpc" = questd.c.lpc, which never exists — the daemon would have silently never loaded, with zero error anywhere (preload() just returns early). Fixed both entries to bare questd/cron (matching every other entry in the file).

§15p: excluded network/dns_master from preload

Removed proactively per standing policy, before the first boot attempt.

§6: log directory — created libs/jinyongwenzi/log/ (sibling of config.fluffos, not inside work/)

The shipped config.sj used log directory : /adm/log; simplified to /log in config.fluffos (matching every other converted lib's convention) and created libs/jinyongwenzi/log/ at the driver's actual launch CWD. Also proactively created a log/nosave/ subdirectory (missing from the raw archive, present in bxsj's copy — AGENTS.md §15ah: master.lpc's crash()/log_error() both write there) to avoid a silent write_file()/log_file() failure if the driver ever crashes.

New findings this pass — TWO bugs bxsj/bxsj1 ALSO have, unfixed and undetected there

Both were only caught because this pass followed §15ae's standing policy literally (test a real post-login command, not just reaching the world) — bxsj's own NOTES.md explicitly stops at "reached ... the password prompt", never tests a command after entering the game, which is exactly the blind spot §15ae warns about. Confirmed by direct file comparison that bxsj's shipped work/ has the *identical* unfixed source for both of these:

1. feature/command.lpc's command_hook() was private nomask (AGENTS.md §15ae, textbook case) — inherited into the player body via F_COMMAND, registered with add_action("command_hook", "", 1), and on this driver a private function is unreachable by add_action's external dispatch. Registration completed fine (driven by input_to, not add_action), the character reached the game world, and then every single typed command — look, score, quit, everything — silently produced the default fail message (什么?), with zero debug.log entry, indistinguishable from a hung connection. Fixed by dropping private (kept nomask). Also found and fixed the identical pattern in one NPC file, d/city/npc/zhao.lpc's change_name() (registered via add_action("change_name", "zhuce")) — same fix. Confirmed bxsj's work/feature/command.lpc still has this exact private nomask on command_hook today — bxsj (and almost certainly bxsj1, same lineage) is very likely ALSO completely command-dead post-registration; flagging for the main session to decide whether to re-open those libs, out of scope for this task to fix directly. 2. adm/daemons/commandd.lpc's rehash() filters get_dir() output with sscanf(cmds[i]+"$", "%s.c$", cmds[i]) — a NEW bug pattern not yet in AGENTS.md's catalog, a variant of the classic .c→.lpc rename fallout but invisible to every existing detection method (it's not a quoted string literal §2's auto-fixer or grep-for-.c" would catch, and it's not a bare-line data file §15c's preload fix pattern covers either — it's a live sscanf format string that silently matches nothing once every command file is named .lpc instead of .c). Effect: rehash() filtered its OWN get_dir() listing down to zero files every time (nothing ends in literal .c anymore), so search[dir] was NEVER populated, and find_command() returned 0 for every verb, forever — which combined with bug #1 above to produce the exact same "every command does nothing" symptom via TWO independent, compounding root causes. Fixed by matching "%s.lpc$" instead. Grepped the whole tree for the same sscanf(...,"%s.c$"/"%s.c",...)-shaped pattern — only this one instance exists. bxsj's shipped work/adm/daemons/commandd.lpc has the byte-identical unfixed "%s.c$" pattern too — same flagging-for-the-main-session note as bug #1; recommend adding this as a new AGENTS.md catalog entry (proposed §15ar) since it's a genuinely new class of .c→.lpc fallout distinct from §2/§15c, and checking every already-"done" lib in this lineage family for it.

Both of the above were root-caused by first restarting the driver after the master/securityd fixes, completing a full interactive registration, observing look/score/quit all silently returning 什么?, then reading feature/command.lpc's dispatch chain end-to-end (find_command → commandd.lpc → rehash) rather than assuming it was one bug — the two compounded, and fixing only one of them (either one) would still have left the lib completely uncommandable after registration.

Cosmetic bug also fixed (not fatal, but noisy on every login/logout)

adm/daemons/logind.lpc's enter_world() and clone/user/user.lpc's net_dead() both called CHANNEL_D->do_channel() passing a non-player object as the "who" argument (this_object() = the logind daemon itself, and load_object(LOGIN_D) respectively, instead of the real player) — neither defines query("channel_id"), so channeld.lpc's fallback path (me->query("name") + "(" + capitalize(me->query("id")) + ")") crashed on capitalize(0) on literally every single login and every single disconnect (caught by the driver's own error handler, non-fatal, but spammed debug.log and the "err" channel on every connect/disconnect). Fixed both call sites to pass the actual player object, matching every other correctly-written do_channel() call site elsewhere in the same tree.

Confirmed NOT needed (checked, found absent/inapplicable)

• §15l (SIMUL_EFUN_OB destruct/reload bootstrap trick in master create()) — not present, create() is a one-line write(). §15o (get_include_path()) — missing from master, same as bxsj/bxsj1 (neither needed it either); no #include failures observed in any mid-connection compile during testing, so not added speculatively.
• §15n (securityd valid_read blocking compile-time reads) — the ported §8c fix already handles the relevant shape; no compile-time read denials observed.
• §8e (tail efun) — cmds/app/tail.lpc defines its own tail() function, unrelated to the (nonexistent) efun of the same name.
• §7 (get_root_uid()/get_bb_uid()) — both already present and correct in master.lpc.
• §15ao (switch with only default:) — none found.
• §15t (#include absolute-path/..-relative/inherit-ordering failures) — none of the three shapes found.

Boot result

Clean boot, zero fatal errors. debug.log shows only expected compile *warnings* (unused locals, "Illegal to declare nosave function" on functions that are legitimately nosave-annotated per this codebase's own convention — cosmetic, harmless).

Update (2026-07-24, WASM long-sit boot-watch, AGENTS.md §7.9 class, FIXED): a previous pass of this note logged questd.lpc's read_table() explode()-on-0 preload error as a MySQL-environment gap and left it unfixed — that diagnosis was a guess, not verified against the source (questd.lpc has no MYSQL/__USE_MYSQL__ reference anywhere, and its create() has no catch() of its own; the error was only ever caught by master.lpc's generic preload() wrapper). The real root cause: read_table("/quest/dynamic_quest") and a second unguarded call two lines later (roomlines = explode(read_file("/quest/dynamic_location"), "\n")) both feed read_file()'s result straight into explode() with no stringp() guard — classic AGENTS.md §7.9 shape. /quest/ doesn't exist ANYWHERE in this archive (not a fresh-checkout gitignore gap, a genuine missing directory), so both calls always error, on every single boot, every time. Fixed both sites in adm/daemons/questd.lpc (read_table()'s line = ... assignment and create()'s roomlines = ... assignment) to guard with stringp() and fall back to ({}) — matches read_table()'s own natural "no data" return shape, and init_dynamic_quest()'s for (i = 0; i < sizeof(quests); i++) loop already no-ops cleanly on an empty quests array (never reaches the roomlines[random(...)] indexing that would otherwise need roomlines to be non-empty). Verified: fresh WASM long-sit boot-watch (200s) shows zero runtime errors of any kind (previously the one caught questd hit); native registration + look + score + quit (id qinfengw, Chinese name 秦风) still works end-to-end with no new regressions. Quest-spreading itself (spread_quest()) simply never fires without the missing /quest/dynamic_quest seed data — same as before, but now via a clean early return instead of a caught runtime error on every boot.

Full registration + post-login test transcript (ONE continuous connection)

cd libs/jinyongwenzi
~/src/fluffos/build-debug/src/driver config.fluffos
python3 ../../scripts/mudclient.py 127.0.0.1 40083 --timeout 30 --idle 0.5 \
  --send "qinfengc" --send "y" --send "秦风" --send "" --send "y" --send "1" \
  --send "look" --send "score" --send "quit"

• ID prompt: qinfengc (a fresh, letters-only 3-8-char English ID; the lib requires this specifically — a numeral in the ID, e.g. qinfeng2, is correctly rejected: "对不起，您的英文名字只能用英文字母").
• y confirms creating a new character under that ID.
• Chinese name prompt (您的中文名字：) — sent the real Chinese name 秦风, accepted with no rejection/mojibake.
• An empty "" send is required next (this codebase's select_gift() ignores its own input and immediately shows the first random stat roll — a quirk of this snapshot's flow, not a bug).
• y accepts the offered stat roll (膂力/悟性/根骨/身法).
• 1 selects a starting skill ("一阳指" — One Finger Zen, an actual Jin Yong kung-fu technique, confirming the wuxia theming is intact).
• Character lands in the actual game world (第一关 — "Level One", a real starting room with a full description, visible exits, and ambient items).
• look correctly redisplayed the full room description (matches the auto-shown description on room entry, confirming the command actually dispatched rather than coincidentally matching).
• score correctly displayed the full character sheet (书剑个人资料卡) with the real registered name 秦风(Qinfengc), stats (膂力/根骨/身法/悟性), age (十四岁), gender (男性), etc. — genuine dynamic output, not a static string.
• quit correctly began logout (正在退出游戏……).
• debug.log for this session shows zero new errors (only the pre-existing questd preload one, from before this connection even started).

lpcc_check.sh sweep

total=4915 pass=4866 fail=49 (99.0% pass). Failure categories, all matching known pre-existing-content-gap shapes already seen across this project (none in the master/login/security compile path, none newly introduced by this pass's fixes):

• 9 optional network/intermud daemon files (adm/daemons/network/* — ms, userid, pingtcp, name_server, mail_serv, netmail, telnetd, pingd, inetd) — expected, these are exactly the family dns_master belongs to (AGENTS.md §15p), never preloaded, never reachable from the live game.
• 2 expected #include-fragment false positives (adm/simul_efun/ message, adm/simul_efun/object — AGENTS.md §6b, meant to be #included INTO simul_efun.lpc, not compiled standalone; harmless, confirmed by the clean real boot).
• 5× Bad type for argument 1 of is_killing (object vs string) — same shape as bxsj/bxsj1's identical un-triaged category.
• 12× Undefined variable 'skill2', 4× 'look_feng', and similar — scattered kungfu-skill/NPC content-specific gaps (missing shared variable definitions in a handful of kungfu/skill/* and d/*/npc/* files), consistent with AGENTS.md §13 (missing zone/room content is a real archive gap, not a conversion bug).
• 7× Undefined function set / 5× Undefined function query — the known simul_efun-based generic property-storage architecture gap (AGENTS.md §15).
• 5× Cannot #include uid.h, 3× config.h, 2× mailer.h, 2× daemons.h — missing optional headers for features not wired up in this snapshot (mail/postal system: member_group, data_netmail_file, POSTAL_D, MAILDIR, DIR_POSTAL all undefined — same optional-mail- daemon-cluster gap already seen on other libs in this family).
• Remainder: isolated one-off content typos in individual NPC/room/skill files (/feature/vi, /feature/sadjust2, several d/wudang/taoyuan/ tyroad*, d/dali/job/*, etc.) — not individually triaged, matching this project's stated breadth-over-depth policy for a ~100-archive batch job.

Full failure list: libs/jinyongwenzi/lpcc_fail.log (49 entries, 1317 lines with full compiler output).

Re-verification pass: driver rebuild + LPC formatter + WASM build

• LPC formatter: ran format-corpus.mjs over all 4,915 .lpc files — 4,873 reformatted in place, 30 already-idempotent, 12 refused (nonzero errors expected/fine per the tool's own contract).
• Native retest against rebuilt driver (~/src/fluffos/build-debug/ src/driver, freshly rebuilt from upstream master): booted clean, zero fatal errors (only the pre-existing, already-documented non-fatal questd.lpc read_table() catch() hit and routine compile warnings). Full registration re-verified with a fresh real name (秦风丁) via the documented flow (letters-only id → confirm → Chinese name → empty send → accept stats → pick skill → arrives in 第一关); look/score/quit all produce correct dynamic output. No regressions from the rebuilt driver or the reformat pass; nothing to fix. (Also double-checked: qinfengc2-style numeral-containing ids still correctly get rejected and desync the scripted send sequence — same pre-existing id-validation behavior/test pitfall as before, not a regression.)
• WASM build test (scripts/wasm_client.js against build-wasm/src): boots cleanly in-process, only ordinary compile warnings. Full registration/login flow completed successfully under WASM too (fresh name 秦风戊, same flow as native), look/quit also correct — this lib has no IP/site-gating daemon on its login path, so it is not affected by the documented query_ip_number() WASM limitation and is fully playable under WASM.

How to run

cd libs/jinyongwenzi
~/src/fluffos/build-debug/src/driver config.fluffos
python3 ../../scripts/mudclient.py 127.0.0.1 40083 --timeout 30 --idle 0.5 \
  --send "someid" --send "y" --send "真实中文名" --send "" --send "y" --send "1" \
  --send "look" --send "score" --send "quit"

WASM-enablement pass (loopback-allow / uptime / throttle / admin seed)

Standard pass per AGENTS.md §1.3(b)/(e), §1.5.

Gates patched:

• adm/daemons/logind.lpc logon() (~line 92): per-IP anti-flood cap (login_cnt > 3 same-IP login objects → silent destruct) now skipped for strict loopback (127.0.0.1/localhost/::1/127.*) only.
• adm/daemons/band.lpc is_banned() (~line 39): strict-loopback short-circuit return 0 (defensive; called on login path in sibling builds).
• adm/daemons/sited.lpc is_valid() (~line 126): strict-loopback short-circuit return 1 (replaces the original commented-out loopback block which DENIED non-wiz loopback).
• Fail-closed correction (retrofit): all three gates above were initially written with a !stringp(ip)/ip == "" "treat malformed IP as loopback" fallback per the original (pre-driver-fix) instructions. Since query_ip_number()/resolve() are now fixed upstream and always return a clean 127.0.0.1 for loopback, that fallback was tightened to strict equality/prefix checks only — a malformed/non-string IP now falls through to the original gate logic (fail closed) instead of being waved through.
• Uptime startup gates: none in this lib (rankd uptime uses are content timers, kept).

Cold-relogin fix (real pre-existing bug exposed while seeding admin): adm/daemons/securityd.lpc valid_read() — added an own-save-file exception for func == "restore_object" mirroring valid_write()'s save_object exception. Without it, the cold-relogin path (logind.lpc get_passwd → make_body → user->restore(), body has uid but no euid until enter_world()'s exec/setup) got "restore_object: read permission denied: /data/user/...o", and the returning player landed in a body whose command path was never set (every command answered "什么?"). Hot/netdead reconnect was unaffected, which is why earlier passes (which only tested reconnect) never saw it.

Admin account: id fluffos, pw Mud@2026 (this snapshot does not verify passwords on login — original upstream edit), name 浮浮, granted (admin) via adm/etc/wizlist (rewrote file LF-only; the old CRLF endings made every parsed level end in \r and match nothing). Verified: relogin as fluffos, update /adm/daemons/band → 成功, admin-channel tag 【仙人】 shown. Save files (untracked but NOT gitignored — orchestrator must add): work/data/user/f/fluffos.o, work/data/login/f/fluffos.o.

Retest: fresh registration (id ceshiyi, name 秦风壬) end-to-end OK — look/score/quit all correct; test char saves removed afterwards. Only pre-existing caught questd preload error in debug.log; no new errors.

Proactive fix (2026-07-24): rank-decay loop crashed every quit (AGENTS.md §7.16/§10.7)

Found while pattern-matching a bug discovered on lineage sibling bxsj during that lib's first deep functional playthrough (AGENTS.md §10.7 methodology), before ever booting this lib for the check. cmds/usr/top.lpc's add_rank() decays a stale rank entry's score via while (ranks[i]["time"] + 3600 < t) { ... } with no iteration cap. The shipped work/log/rank.o carries a real timestamp from 2007 ("time":1181487290), so any boot against today's wall clock runs the loop ~170,000+ times and blows the eval-cost limit. cmds/usr/quit.lpc:139 calls TOP_CMD->add_rank(me) unconditionally on every quit — so every quit was silently crashing (driver's error handler swallows it; the player-visible "正在退出游戏……" message looks normal). Fixed the same way as bxsj: cap the loop at 240 iterations (~10 days of decay, enough to crush any stale score near zero) and unconditionally advance the stored timestamp to t afterward regardless of whether the cap was hit. Compile-checked clean via lpcc --batch; not re-verified live in this lib specifically (verified live on bxsj, the source of the pattern) — flagging per §10.7 point 6 rather than silently claiming a live retest.

深度功能测试 / Deep functional test (2026-08-06)

第一次完整游玩测试（原生驱动 build，ASAN/UBSAN debug 构建）。测试角色 id jyxtest，中文名 云飞扬，起手绝学选择「太极拳」（选项 4）。本轮 WASM 未重新验证：emsdk 工具链下载硬编码指向 storage.googleapis.com， 本次会话的出口代理策略性拒绝该域名（403，已用 curl $HTTPS_PROXY/__agentproxy/status 确认是策略拒绝而非临时故障），本地无 法构建 WASM 驱动。

发现并修复：natured.lpc 的 event_morning() 缺失 objectp() 守卫，导致日夜循环心跳永久停摆（新 AGENTS.md §7.63 追加实例）

• 症状：真实游玩触发（连续通过「第一关」监狱越狱剧情的 3 场剧情战 斗后），debug.log 出现 *Bad argument 1 to EFUN call_other() Expected: object, string, array, Got: int(0)，栈追踪指向 adm/daemons/natured.lpc 第 386 行（event_morning()）由 update_day_phase() 第 132 行通过 call_other() 触发。
• 根因：event_morning() 的 15 个 if (random(8) == N) { ... } 天气事件分支各自生成 2-8 个「外敌奸细」NPC（badguy = new("/quest/weiguo/<国家>/<文件>N")）。每个分支里第一个 new() （boss 变体）都正确用 objectp(badguy = new(...)) && badguy->move(room) 守卫，但同一分支后续的 2-6 个小兵变体 一律是裸 badguy = new(X); badguy->move(room);（全档案共 40 处）。 find work/quest/weiguo 确认这整棵目录树在这份快照里根本不存在 ——new() 必然返回 0，紧接着的 ->move() 崩溃。因为这次 call_other() 崩溃发生在没有 catch() 包裹的调用里， update_day_phase() 自己在崩溃点之后的收尾代码 （remove_call_out/重新 call_out("update_day_phase", ...)）根本没 机会执行——也就是说，只要 event_morning 某次 random(8) 抽中任何一 个未存档的分支，整个驱动的日夜循环心跳就会永久停摆，不只是这一次生 成失败。
• 修复：机械化地把所有 40 处裸 badguy = new(X); badguy->move(room); 改写为 if (objectp(badguy = new(X))) badguy->move(room);，与同一 代码块里本来就有守卫的兄弟调用保持一致写法。修复后用 find ... -name '*.lpc' | node .../format-corpus.mjs 跑过§9格式化 自检（unchanged，无需改动），并逐行 grep 确认 event_morning() 范围 内不再有任何裸 badguy = new(...) 紧跟 badguy->move 的组合。 event_afternoon() 里对应的清场逻辑用的是 children()，本身对不存 在的文件天然安全，未改动。
• 验证：修复前先用真实游玩重现了一次崩溃（debug.log 有完整栈追 踪）；修复后 lpcc/驱动重启编译干净（这份档案里 natured 常驻且总 有未完成的 call_out，update 指令的向导会直接拒绝热更新常驻精 灵——cmds/imm/update.lpc:40-44 检测到 pending call_out 就直接 return 1 放弃编译——所以走的是完整重启驱动来加载新代码，而不是热 update）。重启后确认无新增运行时错误；event_morning() 本身要等游 戏内真实经过一次「早晨」阶段才会被再次调用（day_phase 配置的阶段 长度以真实秒计，累计要等相当长时间），这次会话的时间预算内没有等到 再次触发同一分支来现场复现"修复后不再崩溃"——但修复本身是严格机械 化的、且与同一函数里另一处已经在正常工作的守卫写法完全一致，可信度 高，如实记录未能重新触发验证这一点，而不是假装已验证。
• 已在 AGENTS.md §7.63（"one caller of new(X) missing the guard that every sibling call site already has"）追加了这个实例，因为它是同一 个错误模式在更大规模下的例子（40 处而非 1 处），且根因（整棵内容目 录缺失）比 §7.63 原案例（原因不明的 new() 失败）更容易在其它档案 里复现和识别。

发现并修复：回车一次即可进入提示与实际代码行为矛盾——按提示操作反而进不去

• 症状：已注册账号重新连线时，adm/daemons/logind.lpc 明确提示 "回车一次即可进入"（本档案密码校验代码已被原作者删除，任意输入均 可登录，这是保留的历史设计——见 README），但真的只按回车（空字符 串）时，代码却把你送回"您的英文名字(ID)是："重新输入 ID，不会登录。 用任意非空字符（哪怕一个字母）代替空回车则能正常登录——与 README 文档的"任意输入均可登录"部分相符，只有"空输入"这一种情况被排除在 外，而这恰好是提示语言唯一明确建议的操作。
• 根因：get_passwd(string pass, object ob)（logind.lpc:211）开 头有 if (pass == "") { ob->delete("id"); write("您的英文名字(ID) 是："); input_to((: get_id :), ob); return; }——这段代码在整个文件 里只有唯一一个调用方（logind.lpc:183 的 input_to("get_passwd", 1, ob)，紧跟在打印"回车一次即可进入"之 后），逻辑上明显是删除密码校验之前遗留下来的旧分支：那时这个函数大 概率还承担"输入密码"职责，空输入自然应该打回重新输入。密码校验被 整段删除、调用方文案也改成"按回车即可"之后，这个旧的空输入特判没 有同步移除，从而和新提示的意图直接相反。grep 确认同目录下 logind2.lpc 有完全相同的死代码副本，但全档案没有任何地方 inherit/引用 logind2.lpc（真正生效的 LOGIN_OB 只解析到 logind.lpc），故未改动这份从未被使用过的重复文件。
• 修复：删除 logind.lpc 里这段孤立的 if (pass == "") {...} 分支，让空输入和其它任意输入一样直接往下走正常的登录/重连流程。
• 验证：用管理员账号 fluffos 现场复现了修复前的问题（按提示裸 回车 → 弹回 ID 重新输入提示 → 超时踢出）；update /adm/daemons/logind 热更新编译成功后，用新连接重新尝试裸回车登 录，正确进入"人物目前正在游戏当中，是否取代"确认流程（因为原会话 仍连着），证明修复后空输入确实按提示所说的那样被当作"确认登录"处 理，不再被踢回 ID 输入。

测试内容与结果

• 注册：英文 ID（jyxtest）、密码不校验（原始设计，未改动）、中文 名（云飞扬）、天赋随机摇点（回车确认）全程无错误，注册流程与 bxsj/bxsj1 系同源但独立实现（没有 BIG5 编码选择提示）。
• 起手绝学：新角色开局即可从"一阳指/九阳神功/易筋经/太极拳/白手起 家"中任选其一（本轮选太极拳），立即获得对应的基础技能组 （cuff/dodge/force/parry 四项基本技能 + piaoyi-shenfa/ taiji-quan/yinyun-ziqi 三项特殊武功）——skills 命令确认发放正 确，非 bug。
• 剧情战斗（"第一关"越狱情节）：连续三场由房间/剧情驱动的强制战斗 （分别对阵 1 名、3 名、2 名"监狱第六代狱卒"），全部靠角色自身技能 （无需玩家手动 fight/kill 指令，走到房间即自动触发对战）胜利， 过程中气血最低降到约 64%，未出现死亡风险；战斗系统本身（招式描述、 闪避/格挡/命中判定、经验/潜能结算）全程无崩溃、无异常。
• 持久化：完整 quit（在非战斗状态下，is_fighting() 守卫按预期 正常放行）之后重新登录，正确恢复到退出时所在的房间（却日殿）——一开 始怀疑这是"每次重连都被强制送回起点"的持久化 bug，追踪 enter_world()/quit.lpc 的 startroom 读写逻辑并现场复现后确 认：房间本身会在有角色进入时（含重连復位）重新生成守卫 NPC，与地点 持久化无关，是设计内的"守卫巡逻/重生"机制，不是 bug。
• 管理员账号：fluffos/密码任意非空字符串均可登录，显示"您目前的 权限是：(admin)"（README 已注明本档案密码不校验）。
• 经济/商店、门派/师承、死亡/复活：未覆盖——这份快照走的是剧 情驱动的越狱关卡开局，而非 bxsj 系那种一开始就在武馆自由活动的沙 盒式新手村，传统的 bai/menpai 拜师系统在测试范围内的场景没有出 现（起手绝学替代了拜师流程，见上）；商店与死亡系统留给后续测试覆 盖，如实标注为未覆盖而非默认判定为正常。

Round-four re-test (2026-08-20): economy/shops, sect apprenticeship, death/resurrection

Targeted the three areas the 2026-08-06 deep functional test explicitly left uncovered. Fresh build-debug driver boot, port 40083, tested via a raw Python telnet-negotiation-stripping socket script (two concurrent connections: a real registered player + the fluffos admin account, driven with goto/summon/clone/give/smash/update) rather than tmux_mud.sh, per this session's standing tooling preference.

Death/resurrection: WORKS CLEANLY, no bugs found

Registered a fresh character (jysidie, 秦风肆), used the admin's summon + smash (smash calls ob->die() directly — a real death, not a scripted low-HP retreat) to kill it. Full cycle confirmed:

• score immediately after death shows 死亡次数：一次 (deaths: 1) and 上次遇害：被闪电劈死了 (last killed by lightning), stats reset to full (精血/精力/气血/内力 all at max) — the revival-on-death behavior this codebase uses (see "New findings" above: START_ROOM and DEATH_ROOM are literally the *same room*, /e/9/shanmen = "第一关", by design — death drops the character back into the opening prison-break level, narratively "you wake up back at square one").
• The room only lists north as an exit; walking north correctly moves the character out into 殿前广场, which immediately re-triggers the documented prison-break combat encounter (监狱第六代狱卒) — confirms the death→respawn→replay-the-opening loop is a real, working, repeatable mechanic, not a soft-lock. No debug.log entries from this whole sequence (only pre-existing harmless compile warnings).
• start_death() is called on the numbered DEATH_ROOMx constants in feature/damage.lpc's die() but is never defined anywhere in the archive — every one of those 10 call sites is silently a no-op (call_other() to an undefined function returns 0 without error on this driver). Since the actual room-move (me->move(DEATH_ROOM)) happens on the line before and always succeeds regardless, this dead code doesn't block anything — documented here as an observation, left untouched (matches the "no crash, no debug.log line" bar for content vs. bug).

Sect apprenticeship (bai/apprentice): CONFIRMED PRESENT, coexists with the signature-skill starter

Traditional sect-joining is NOT replaced/absent — cmds/skill/apprentice.lpc implements a full bai <master> / apprentice <master> flow (kneel-and-kowtow kowtow-to-join-family logic, expell/betrayal handling, generation tracking), and adm/daemons/aliasd.lpc maps "bai": "apprentice". Found real sect-master candidate NPCs (d/sld/npc/*.lpc etc. carrying set("family", ...) / family_name) — not live-tested end-to-end this round (would need a wizard escort to a specific sect NPC plus meeting its family/generation prerequisites), but the code path is unambiguously wired and reachable; the signature-skill picker at character creation is an *additional* starter mechanic on top of this, not a replacement for it.

Economy/shops: found and fixed 2 real bugs; bank/pawnshop mechanism is present in code but unplaced (unreachable) in this snapshot

Architecture: two parallel vendor mixins exist — feature/dealer.lpc (older, array-of-file-paths vendor_goods, buy/sell/value/list) and feature/vendor.lpc (F_VENDOR, array-of-(["name":file,"number":count]) mappings vendor_goods, buy/list only — no player-facing sell, matching this session's now-familiar "buy-only shop, separate buyback/pawnshop NPC" design pattern, not a bug). A survey of every F_DEALER/F_VENDOR NPC file found most of the 16 F_DEALER NPCs and several F_VENDOR NPCs are never referenced by any room's "objects" mapping anywhere in the archive — orphaned content, unreachable in actual gameplay, not something to "fix" by inventing a placement (that would be authoring new world content, out of scope). Two F_VENDOR NPCs *are* genuinely room-placed and reachable: d/hmy/pingding/npc/xiaoer2.lpc (跑堂, in d/hmy/pingding/xiaochidian.lpc, food/drink) and d/hmy/pingding/npc/huoji.lpc (药铺伙计, in d/hmy/pingding/yaopu.lpc, medicine).

Bug #1 (real, fixed): vendor_goods declared as the wrong data shape. feature/vendor.lpc's do_list()/do_buy()/is_vendor_good() all do if (arrayp(goods = query("vendor_goods"))) and then index goods[i]["name"]/goods[i]["number"] — expecting an ARRAY of one-entry MAPPINGS. d/hmy/pingding/npc/xiaoer2.lpc and d/hmy/pingding/npc/huoji.lpc instead set vendor_goods as a single MAPPING keyed by item path ((["/d/city/obj/jitui": 11, ...])), the shape feature/dealer.lpc uses, not feature/vendor.lpc's — an apparent copy-paste from the older mixin's convention. arrayp() on a mapping is false, so do_list/do_buy/ is_vendor_good all silently fall through with zero output, not even a fail message — a completely dead list/buy on two live, reachable, correctly-add_action-wired NPCs. (4 more F_VENDOR files elsewhere have the same wrong shape — d/sld/npc/chuzi.lpc, d/dali/npc/mafu.lpc, d/taishan/npc/shangren.lpc — but their list/buy add_action() calls are themselves commented out, so the shape bug is inert there; and d/taishan/npc/xiao-fan.lpc, which does have buy wired, is itself never room-placed — left untouched, no live impact.) Fixed: converted both xiaoer2.lpc and huoji.lpc to the correct ({ (["name":file,"number":count]), ... }) array-of-mappings shape.

Bug #2 (real, fixed, found only after fixing #1): huoji.lpc referenced 3 nonexistent/wrong-path item files. Once the shape was fixed, do_list/ do_buy proceeded far enough to actually resolve each vendor_goods entry via call_other()-on-string-path — and 4 of huoji.lpc's 6 entries pointed at files that don't exist: __DIR__ "obj/jinchuang" and __DIR__ "obj/yangjing" (real items exist, just at /clone/medicine/jinchuang.lpc and /clone/medicine/yangjing.lpc, not under this NPC's own directory), /clone/medicine/baiwei and /clone/medicine/baizhi (real items exist at /clone/medicine/drug/baiwei.lpc / drug/baizhi.lpc, wrong subpath), and /clone/medicine/badou (searched the whole archive incl. raw source — this item never existed anywhere, not just misplaced; dropped the entry rather than inventing a substitute). Each bad entry produced a real, live debug.log "*call_other() couldn't find object ..." runtime error on every list/buy at this NPC — a driver-level error, squarely in scope to fix. Fixed: repointed jinchuang/yangjing to their real /clone/medicine/ paths, repointed baiwei/baizhi to their real drug/ subpath, dropped the phantom badou entry.

Live verification (both fixes, fresh driver boot, naturally room-spawned NPCs — not wizard-cloned instances, which lack the startroom property the room's own make_inventory() sets on spawn): registered jyshopvi (秦风捌), admin summoned it to each shop, cloned + give-gifted gold. At 跑堂: list showed all 5 wares with real prices/stock; buy jitui completed a real purchase (money deducted, item received, "讨价还价" trade-skill XP awarded, inventory confirmed). At 药铺伙计: list showed all 5 (now-corrected) wares; buy jin (金创药) and buy dan (养精丹) both completed real purchases, confirmed via inventory + remaining coin/silver count. debug.log after the full session: zero runtime errors (only the routine boot-time compile warnings already documented above).

Bank/pawnshop (two-tier currency): feature/banker.lpc (shared mixin: check/convert/deposit/withdraw, a balance property separate from physical gold/silver/coin objects — the same two-tier-currency pattern already confirmed on several other libs this session) is well-formed code, hosted by d/city/npc/old-qian.lpc (银号/钱庄, deposit/cun, withdraw/qu) plus several sibling banker NPCs across other zones. None of them are referenced by any room's "objects" mapping anywhere in the archive — like most of the F_DEALER shops, the entire banking mechanic is orphaned/unplaced content in this snapshot, unreachable in actual gameplay even though the code itself looks sound. Not fixed (placing NPCs in the world is a content/design decision, not a bug fix); documented here as a genuine "untested because unreachable" finding rather than assumed fine.

Standing checklist sanity pass (this lib was NOT covered by either corpus sweep before this pass)

• §7.100 (redundant self-replace_program(ROOM) in create(), poisoning future closure-binding on that object): 10 live occurrences found and fixed — all under work/data/group/groom/*.lpc (10 player guild-hall/group-headquarters room files: jiuer, nan, rabaggio, llj, youyou, shaer, tomy, tiantian, xiongjj, leontt), each with the exact inherit ROOM; ... setup(); replace_program(ROOM); shape. None currently contain a closure-creating call (no create_door(), no (:...:)), so the replace always silently succeeds and sets the permanent "pending replace" flag — a dormant landmine matching §7.100's documented shape exactly. Fixed by deleting the redundant replace_program(ROOM); line in all 10 files (kept inherit ROOM;). Grepped work/ afterward: 0 remaining occurrences.
• §7.79 (bare 2-arg addn()/addn_temp() self-targeting the wrong object): 0 occurrences — grep -rn "addn(" across work/ finds nothing at all. Not applicable to this lib.
• §7.90 (eval-cost too low for this lineage's NPC-creation cost): already fine — config.fluffos has maximum evaluation cost : 50000000, well above the documented danger threshold.
• §7.111 (standard_trace() crashing on file_name(error["object"]) when the object is 0): not applicable — this lib's adm/single/master.lpc::standard_trace() uses %O mapping-print formatting for error["object"], never calls file_name() on it.
• §7.112 (init() unconditionally scheduling a call_out() chain, duplicated by enable_commands() re-broadcast on reconnect): the one file in this archive with the vulnerable-shaped death-stage chain, d/shaolin/npc/yu-zu2.lpc, already has the correct guard (death_stage_active temp flag checked before scheduling, cleared at every exit point) — already fixed/clean, nothing to do. The other candidate-named files present (mengpo.lpc, bgargoyle.lpc, wgargoyle.lpc, yanluo.lpc) have no init()/call_out at all in this snapshot (decorative NPCs only).
• §7.113 (netdead reconnect never restoring heart_beat): already fine — adm/daemons/logind.lpc::reconnect() calls user->reconnect(), and clone/user/user.lpc::reconnect() unconditionally does set_heart_beat(1) on the player body itself — the known-correct lineage shape.
• §7.114 (private input_to() recursive-callback mixin function silently failing to re-arm when inherited): already fine — feature/edit.lpc's input_line() (the F_EDIT mixin inherited by inherit/char/char.lpc, driving board post/mail/chfn) is declared public, not private.
• §7.115 (QUEST macro pointing at a never-delivered file, crashing give/ask): not applicable — no QUEST macro is defined anywhere in this lib's include/*.h.

Cleanup

All player test-account saves created this round (jysidie, jyshopr, jyshoptw, jyshopvi) removed from work/data/{user,login}/j/ after verification. The fluffos admin account's own save files changed slightly (routine inventory/login-timestamp churn from using clone/ give/summon during testing) — left as-is, matching this project's standing practice of not hand-editing the persistent admin account's save data between sessions. Driver killed by exact PID after testing (never pkill -f).

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

此前被错误标记为某个不存在于本项目任何档案的原始压缩包文件名的 duplicate_of；这里的内容其实是完全独立、可游玩的游戏（有自己的 -N 变体编号、自己的端口、自己的 README）——duplicate_of 已清除。

§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 fix: enable_player() reentrancy from init()

feature/command.lpc's enable_player() (wrapper around enable_commands()) was reachable from an NPC's init(): the shared inherit/char/char.lpc setup() (called from every character's create()) itself calls enable_player(), and d/gb/npc/xixia-wushi.lpc redundantly calls setup() again from inside its own init() (on top of the setup() its create() already made) -- same shape as the originally-documented mhxy zhangmen.lpc case. enable_commands() is only safe to call from create(): calling it again on an object already living() makes the driver re-invoke that same object's init() as a side effect, which recurses back into enable_player() on the same call stack until "Too deep recursion" aborts the boot on a room's first-ever visit. Fixed with a true reentrancy flag (in_enable_player_now), NOT a living() guard (which would break legitimate re-enables from revive() in feature/damage.lpc and wakeup()/wakeup2() in cmds/std/sleep.lpc, both confirmed to re-invoke enable_player() on this lib while the object is still living()). Verified via lpcc --batch single-file compile check (PASS). Part of the corpus-wide §7.19 sweep (Batch E).

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

scripts/lpc_fix_negative_ranges.py: 1 line(s) in 1 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

• message_combatd(msg, me, you) is called by 2 file(s) (the perform files) and defined nowhere in this archive (a simul_efun of the original server): 2 of them did not compile (Undefined function message_combatd). adm/simul_efun/message.lpc now has varargs void message_combatd(string msg, object me, object you, mixed extra) calling message_vision(), placed after message_vision's definition (KB 04 §6.2). All callers compile.

深度功能测试（§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/dali/yuxu/yuxuguanmen.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-05）— 任务表里的 .c 路径与任务守护进程的防护

scripts/lpc_dynamic_quest_guard.py：1 处 spread_quest() 调用（init_dynamic_quest() 的循环里）包进 catch()，缺失的任务物品或编译不过的房间只跳过那一个任务，守护进程照常加载、其余任务照常生成。 验证：改动过的 adm/daemons/questd.lpc 在新进程里加载，HEAD 通过 1 个、工作树通过 1 个（共 1 个），无回退。

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

房间基类 inherit/room/room.lpc：make_inventory() 用 catch() 包住 unew(file)（缺档时它在 simul_efun 里对 0 调用 query("unique")），else 分支只在确有克隆时才取 [<1]。档案里没有的 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。

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

scripts/lpc_warnings.py jinyongwenzi --fix 加 scripts/lpc_fix_no_effect.py --apply，共改动 138 个 .lpc（多为删去未用的局部变量）。HEAD 与工作树分别加载（新进程）：132 -> 132 通过，无回退。手改 adm/daemons/logind.lpc：get_id() 的 ip、get_passwd() 的 ip_number 只剩被注释掉的旧密码校验在用（原作者删掉的校验，见上文，不恢复），删去声明。启动时警告 38 -> 0；新进程登录（新人物确认）正常。

深度功能测试（§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/skill/verify.lpc）；改动的文件 HEAD 与工作树分别加载（新进程），无回退。

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

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

scripts/toolkit_fix.sh 一轮去掉 d/shaolin/npc/obj/mu-ren.lpc 多余的 F_CLEAN_UP；照 jh2006（1cb92f951d8）：毒虫 d/xingxiu/obj/duchong.lpc 的 kill_ob() 改 void（与 feature/attack.lpc 一致），cmds/usr/news.lpc、cmds/usr/wenxuan.lpc 里只有被注释掉的数据库代码用的 mysql、rows 删去。能编译的文件警告清零；改动的 4 个对象在 HEAD 与工作树各载入一次，regress 0。

• 2026-10-14：新驱动（FluffOS 970d9f09）报 Float value truncated to int（#1426）。10 个文件 10 处：赋值、初始化、return 改写成 to_int(...)（值不变，只是写明截断）；x op= 浮点 先把浮点转成整数再运算（系数小于 1 时 x 直接变 0），改为 x = to_int(x op ...)：/d/mr/npc/murong-fu.lpc（bouns *=）、/kungfu/skill/force/qi.lpc（q *=）、/kungfu/skill/force/recover.lpc（q *=）、/kungfu/skill/jieshou-jiushi/foguang.lpc（damage *=）、/kungfu/skill/jiuyang-shengong/zhen.lpc（damage *=）、/kungfu/skill/taiji-quan/jueji1.lpc（p *=）、/kungfu/skill/taiji-quan/zhen.lpc（damage *=）、/kungfu/skill/taiji-quan/新建文件夹/jueji1.lpc（p *=）、/kungfu/skill/zhen.lpc（damage *=）。改动的对象新进程各载入一次，无回退（scripts/lpc_fix_float_trunc.py，KB 04 §6.10）。

负数伤害当作消耗（2026-10-15，KB 06 §7.241）

receive_damage("neili", -52)、receive_damage("qi", -12) 之类把 add() 的负数写进了 receive_damage()：本库 feature/damage.lpc 对负数伤害报错（或归零），练功/运功时报 F_DAMAGE: 伤害值为负值 或消耗失效。已改为正数伤害，内力/精力类改为 add(type, -N)（scripts/lpc_fix_damage_calls.py）：/kungfu/skill/huntian-qigong/powerup、/kungfu/skill/lanhua-shou。

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

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

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

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

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

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

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

当前内力、精这类名字有时指的是内功技能，逐处读过后手改：longxiang-boruo 的 ob_hit() 用 query_skill("neili") 比较双方内力，恒为 0 对 0，只会走“化去一部分”的分支，改为 query("neili")。

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

query_skill() 里的技能名拼错了，或用的是本库改名前的旧名；本库没有这个技能，调用永远得 0：门槛（< N 就拒绝）永远过不去，相关功夫或绝招学不了、用不了；内功互斥（> N 就拒绝）从不生效；公式里这一项一直是 0。经汉字名（提示文字或中文名词典）或纯拼写差异（_/-、少一个连字符、相邻字母颠倒）核对后，改为本库的技能名（scripts/lpc_fix_skill_typo.py）：xixing-dafa→xixin-dafa（qiantian-yiyang、tianlong-shengong）；jinshe-zhang→jinshe-zhangfa（jinshe-jianfa/kuangwu）。

太极拳绝招依赖的 yinyun-ziqi/taiji 缺失（2026-10-15）

taiji-quan 的 gangrou、jueji2、jueji3、zhannian 都用 "/kungfu/skill/yinyun-ziqi/taiji"->check_force() 判断对手的内功，但本库 yinyun-ziqi/ 里没有 taiji.lpc（原档就缺），这四招一用就报 couldn't find object。本库的 yinyun-ziqi.lpc 与 jh2006 的逐字节相同，从 jh2006 补回 yinyun-ziqi/taiji.lpc（只依赖 <ansi.h>）。perform 探针复查 0 错误。

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

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

燃木刀法「焚天」的效果一秒就消失（2026-10-15，KB 06 §7.246）

每秒检查的 check_fight() 声明了 object weapon; 却从不赋值，条件里的 !weapon 永远为真，效果在第一次检查时就被撤掉。把这一项改为 !objectp(weapon = me->query_temp("weapon"))，先存兵器再判断刀的种类。

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

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

NPC 带着不存在的物品：simul_efun unew() 报错（2026-10-18，KB 06 §7.73）

adm/simul_efun/object.lpc 的 unew(str)（带 unique 判断的 new()）先 ob = new(str)，紧接着就读 ob->query("unique")。物品文件不存在时 new() 返回 0，读 0 的属性报 Bad argument 1 to EFUN call_other()，从 carry_object() 一路带出去：create() 里带着缺失物品的 NPC 载入不了（jh2006 的苗疆何铁手一类，该有 NPC 的房间少了人）。读属性之前补 if (!ob) return ob;（int i = ob->query("unique"), j, k; 拆成声明和赋值两句），缺的物品跳过，NPC 照常载入（scripts/lpc_guard_carry_object.py --unew）。载入检查：改动的文件改前能载入 1 个，改后 2 个，没有退步。

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 载入不了，刷出它的房间也少一个人。本库目前没有对象设了缺失的武功；三处都改成 return：这一门武功不给、不映射，对象照常载入，只是少了它（缺的武功本身仍是内容缺口）。（scripts/lpc_guard_set_skill.py）

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

房间出口 "west": __DIR__"xxx" 指向的文件本库没有，玩家走过去就被卡住（笔误、改过名的房间，或者没带进档案的编号房间）。对面的房间存在、并且它相反方向的出口正好指回这个房间，说明出口原本就是通向它：/d/mingjiao/didao/shuling2 的 west：/d/mingjiao/muqi → /d/mingjiao/didao/shuling5。改动后每个出口都能解析到本库的文件（scripts/lpc_fix_dead_exits.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 映射不到，门派弟子用普通轻功/拳脚）。按核对过的对照表改正，共 24 处、24 个文件：shaolin-shnfa→shaolin-shenfa（12 处）、kunlun-shnfa→kunlun-shenfa（6 处）、yijinjing→yijin-jing（2 处）、banrou-zhang→banruo-zhang（2 处）、huashen-shenfa→huashan-shenfa（1 处）、weiituo-gun→weituo-gun（1 处）。（scripts/lpc_fix_skill_names.py）

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

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

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

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

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

if (arg == "yuyou" || "yu you") 里的 "yu you" 是非空字符串，永远为真，整个条件对任何 arg 都成立；作者要的是每个字符串都和变量比较。具体是：吃任何东西都会吃掉鱼油。在每个字符串前补上变量和运算符（scripts/lpc_fix_literal_or.py；forrest2.lpc 是 dir == "north" && "south"，手工改成 (dir == "north" || dir == "south") && ...）：/clone/food/yuyou.lpc（4 处）。

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

if (arg != "wan" || arg != "丸") return notify_fail(...) 对任何 arg 都为真，dir == "south" && dir == "north" 永远为假：条件下面的守卫要么永远拦、要么永远不拦。作者要的是“既不是 A 也不是 B”（&&）或“是 A 或 B”（||）。!= 链的 || 改成 &&（仅当条件下面是 return 的拒绝/守卫），== 链的 && 改成 ||（scripts/lpc_fix_cmp_chain.py）。改动：/kungfu/skill/yiyang-zhi/jueji1.lpc（1 处）。

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，共 12 处）。改动：/cmds/leitai/bwdh/ctrl.lpc（3 处）、/d/city/obj/budai.lpc（1 处）、/d/sld/npc/stt.lpc（1 处）、/kungfu/skill/qiankun-danuoyi.lpc（7 处）。

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

mcheck：query_ip_rport() 驱动里没有（2026-10-20，KB 06 §7.291）

指令要显示连线的远端端口，MudOS 时代的 query_ip_rport() 在 FluffOS 里不存在（query_ip_port() 给的是本地端口），指令编译不过。文件里加了一个返回 "?" 的占位函数（dtsl 的同名指令早就这么做）。改动：/cmds/wiz/mcheck.lpc。

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

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

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

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

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) ||）。改动：/inherit/char/npc.lpc（共 1 个文件）。

昆仑派 banshuxian、hetaichong、血刀门 laozu 的 ask_me()：ob 从来没赋值（2026-10-21，KB 06 §7.346）

/kungfu/class/kunlun/banshuxian.lpc、/kungfu/class/kunlun/hetaichong.lpc：object ob; 之后直接 ob->query("gender") / ob->query_skill(..)，根上的 xkx100 在声明后有一句 ob = this_player();，这个派生库把它丢了，ask <师傅> about <秘籍> 一律抛 call_other() ... Got: int(0)。补上这句。

注册到不存在函数的 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.，同一个动词的其他处理函数不再尝试（不是最新的一条就悄悄跳过）。删除了 8 条注册（7 个文件，scripts/lpc_fix_dead_add_action.py），动词留给别的处理函数：/d/dali/wuliang/anbian.lpc（do_tiao）、/d/dali/wuliang/muwu1.lpc（do_tiao）、/d/dali/wuliang/shanlin-6.lpc（do_tiao）、/d/huashan/jinshe/obj/haigu.lpc（do_move）、/d/huashan/npc/yaba.lpc（do_follow、do_kill）、/d/mr/obj/chahua3.lpc（do_chu）、/inherit/misc/fboard.lpc（do_list）。最多的函数名：do_tiao 3 处、do_move 1 处、do_follow 1 处、do_kill 1 处、do_chu 1 处。

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

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

(: 函数 :) 指针指向对象自己没有定义的函数（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。 已补回 /d/tiezhang/npc/qqren.lpc 的 ask_qiubai()（原型还在、函数体丢了；bixiecanyang 里同一文件有完整函数，原样补到文件末尾，scripts/lpc_port_function.py --lfun；真机会话里 ask qiu about 上官剑南：HEAD 报上面的错误，改后正常输出）。 还剩 13 个函数没有补（inquiry 13）：原型还在函数体丢了、或者根本没写过，没有可以直接补回的捐赠（别的库同一路径的文件里没有这个函数，或者它还要用本库没有的辅助函数、签名不同），不编造：/clone/npc/1/qqren.lpc:ask_qiubai、/clone/npc/1/qqren.lpc:do_change、/clone/npc/1/qqren.lpc:ask_job1、/d/shaolin/npc/xuan-du.lpc:ask_me、/d/tiezhang/npc/qqren.lpc:do_change、/d/tls/npc/kurong.lpc:ask_xingyue、/d/tls/npc/kurong.lpc:ask_dudan、/d/tls/npc/kurong.lpc:ask_liumai2、/d/tls/npc/kurong.lpc:ask_liumai1、/kungfu/class/gumu/sun.lpc:ask_job 等另外 3 个。

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

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

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

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

本库 47 处（24 个文件）：拼名字的赋值 19 处、与汉字常量比较 18 处、改名官的长度检查 7 处、对切片赋值 1 处、两个名字切片互比 1 处、query("name")[..] 1 处。例：name[2..3] → name[1..1]（/d/shaolin/npc/fangsheng.lpc:150）；old_name[2..3] → old_name[1..1]（/d/shaolin/npc/rong.lpc:66）；old_name[0..3] → old_name[0..1]（/d/thd/npc/yaoshi.lpc:349）。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，不要重跑。

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

从末尾按字节取汉字、书剑开帮长度（2026-10-23，KB 06 §7.364）

§7.360 只折了数字下标的 [a..b]，从末尾取的 [<2..<1]（GBK 下一个汉字）和 [<4..<1]（两个字）还留着：开帮 gcreate 的帮助写「二至六个汉字 / 3到8个英文字母」，检查却是 (strlen%2)==1 || <4 || >12，末字对 ({ "帮","会",… }) 用 gname2[<2..<1] 永远对不上；少林 / 峨嵋法名 "明" + name[<2..<1]、死讯 killer[<2..<1] != "。"、兵器改名的 can_name 同样坏掉。scripts/lpc_fix_tail_slice.py 只改汉字语境（对照非 ASCII 字面量、can_name / valid_group_name、拼名字），ASCII 补零 / ctime / 复数词尾 / .lpc 不动；[<2..<1]→[<1..<1]，[<4..<1]→[<2..<1]，开帮门槛按帮助改写。本库 从末尾切片 5 个文件。证明（scripts/lpcc_eval.py bxsj）：HEAD 上 斧头帮[<2..<1] 对不上「帮」；改后 [<1..<1] 对上；长度放行 斧头帮/fut；"明"+"张三"[<1..<1] 得「明三」。

丐帮长老 gb_nz 无法加载（2026-10-27，KB 04 §6.25 Also）

d/gb/npc/gb_nz.lpc：mixed wherei=({ 少了内层 ({（手足 xkxz2 / xkxc98sj 的 d/gaibang/npc/gb_nz 有），query_temp("promotion_target) 缺收尾引号，accept_object 在注释掉的备用奖励块前多了一个 }。补内层数组、补引号、去掉多余 }，并删掉未用的 fam。/u/hunthu/ 路径未动（内容）。证明：HEAD 加载失败；改后加载成功。

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

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