Fix silent reconnect-mid-wizard stall in sanjiechuanshuo + catalog new §7.37 class

d/wiz/init.lpc: get_start0() (a reconnect-triggered call_out meant to
auto-resume a stalled gift-selection wizard) called me->command("start")
-- but the real command() efun takes no object argument; this is a
call_other to a method named "command" that is not defined anywhere on
the player object. FluffOS silently no-ops an undefined call_other with
no error anywhere, so a player reconnecting mid-wizard saw nothing at
all after "重新连线完毕。" -- no menu, no error, no hint -- while typing
the undocumented "start" command manually worked fine (confirmed live).
Fixed by replicating the target logic directly with tell_object(me, ...)
instead of write() (write() needs this_player() context, unset inside a
call_out) instead of round-tripping through the broken call. Verified
live: reconnecting to a mid-wizard account now auto-displays the gift
menu within seconds. A fresh uninterrupted registration was independently
confirmed to already work correctly end-to-end.

Cataloged as AGENTS.md §7.37 (new class): calling ob->efun_name(...)
where efun_name matches a real driver efun name, but no method of that
name is defined on ob, silently no-ops with zero error trace anywhere --
distinct from §8.3a's DECL_PRIVATE demotion (there was never a function
to dispatch to here at all).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VyQCUoTo1Z93Py9aVFHQi1

Author: thefallentree

AGENTS.md

@@ -2160,6 +2160,56 @@ save/quit that same handler exists to guarantee.
 
 ---
 
+### 7.37 Calling `ob->efun_name(...)` where `efun_name` matches a real driver efun, but no method of that name is actually defined on `ob`, silently no-ops
+
+Found on `sanjiechuanshuo`'s deep functional test (§10.7): a room's
+reconnect-triggered `call_out` tried to automatically resume a stalled
+gift-selection wizard via `me->command("start")` — but the real
+`command()` efun (`core.spec`: `int command(string)`) takes NO object
+argument; it always operates on the current command-giver context.
+`ob->command(str)` is call_other syntax, which requires `ob` to define
+its OWN function literally named `command`, which nothing in this lib
+did anywhere (confirmed via a lib-wide grep). This driver raises NO
+error for a call_other to an undefined function — not to the caller,
+not to debug.log, nowhere — it just silently returns 0. The result was
+a completely silent dead end: a player reconnecting mid-wizard saw
+"重新连线完毕。" and then nothing else, forever, with zero indication
+anything was wrong, while the SAME verb typed directly by the player
+(going through the driver's own normal command dispatch, which doesn't
+depend on this broken call) worked perfectly fine — a discrepancy that
+made this easy to initially misdiagnose as "the add_action registration
+must be broken" when in fact it was fine.
+
+This is a distinct trap from §8.3a (`private`→`DECL_HIDDEN` demotion
+breaking a real, DEFINED function's dispatch) — here there was never
+any function to dispatch to in the first place; the bug is confusing
+"an efun that happens to share this name" with "a method call," a
+mistake the compiler cannot catch because call_other targets are
+resolved dynamically at runtime, not statically.
+
+Detection: whenever you see `ob-><efun_name>(...)` for any of this
+project's common efuns (`command`, `write`, `tell_object`, `message`,
+etc. — check the real signature in `core.spec` or the relevant
+package's `.spec` file), verify the target object actually defines a
+same-named method (grep the whole lib, not just the obvious base
+classes) before assuming the call does what its name suggests.
+Reproduce live by exercising the actual caller path (here: reconnect
+while mid-wizard, not just fresh registration) and watching for
+complete silence with no debug.log trace — that combination (call
+succeeds with no error, but visibly does nothing) is the tell.
+
+Fix: replace the broken round-trip with a direct call to the underlying
+logic using the already-available explicit target object, being
+careful that anything relying on implicit `this_player()` context
+(`write()`, and similarly `tell_object`-adjacent, ambient-target efuns)
+gets rewritten to take the explicit target instead — `write()` and
+friends silently target `this_player()`, which is typically unset
+inside a `call_out`, so simply removing the broken `ob->command(...)`
+call without ALSO auditing what it was trying to reach just moves the
+silent-failure point one level deeper.
+
+---
+
 ## 8. Login and registration flow bugs
 
 Registration is where restoration succeeds or fails: it exercises the

libs/sanjiechuanshuo/NOTES.md

@@ -125,3 +125,69 @@ python3 ../../scripts/mudclient.py 127.0.0.1 40097 --timeout 15 \
   --send "you@example.com" --send "m" --send "9" --send "y" \
   --send "look" --send "score" --send "quit"
 ```
+
+## 深度功能测试 / Deep functional test (round two, AGENTS.md §10.7)
+
+Native driver, port 40097, tested via raw socket (finer control over
+timing than `mudclient.py` for this lib's charset→age-check→id/New→
+Chinese-name→password×2→email→gender→gift-selection wizard). Test
+characters: `qfthree`/秦风三 (password `TestPassA`) is a clean, fully-
+completed registration used for the main playthrough; `qftester` and
+`qftwo` are two earlier registrations deliberately left stuck mid-gift-
+wizard (see bug below) and kept as before/after evidence.
+
+**Bug found and fixed, live-reproduced and re-verified**: `d/wiz/init.lpc`'s
+`init()` schedules `call_out("get_start0", 0, me)` on every reconnect
+while the account's gift-selection wizard is still incomplete
+(`no_gift` still set), meant to automatically re-show the gift menu so
+the player isn't left wondering what happened. `get_start0()` tried to
+do this via `me->command("start")` — but the real `command()` efun
+(`core.spec`: `int command(string)`) takes no object argument, so this
+is a call_other to a method named `command` that is not defined
+anywhere on the player object (confirmed via a lib-wide grep). FluffOS
+silently no-ops an undefined call_other with no error raised anywhere
+(not even in debug.log), so this reconnect path produced **zero visible
+output**: a player reconnecting mid-wizard saw nothing at all after
+"重新连线完毕。" — no menu, no error, no hint — and the only way out
+was to already know to type the undocumented `start` command
+themselves (confirmed live: typing `start` manually DID correctly
+redisplay the menu, since that add_action registration itself works
+fine). Root-caused by directly inspecting `data/user/q/*.o` for
+`no_gift`, then confirming live with a raw-socket test that showed
+identical silence even after a genuine 10-second wait.
+
+Fixed by rewriting `get_start0()` to replicate `get_start1()`'s body
+directly (using `tell_object(me, ...)` instead of `write()`, since
+`write()` implicitly targets `this_player()`, which is unset inside a
+call_out) and calling `get_start(me)` directly instead of round-
+tripping through the broken `command()` call. Also fixed `show_gift()`
+the same way (`write()` → `tell_object(me, ...)`), since it's reached
+via the same call_out path. Verified live: after the fix, reconnecting
+to a mid-wizard account (`qftwo`) auto-displays the full gift menu
+within seconds with no manual `start` needed, matching the intended
+"重新连线完毕" → immediate resume UX. A fresh, uninterrupted
+registration (id → New → Chinese name → password ×2 → email → gender →
+gift accept `9`+`y`) was independently confirmed to already work
+correctly end-to-end (lands cleanly in 南城客栈/South City Inn per the
+newbie doc), so this bug specifically affects the reconnect-while-
+mid-wizard path, not first-time registration.
+
+**Verified working**: full registration flow, `look`/`score`/`hp` all
+render correctly with rich, properly-escaped ANSI formatting (no
+orphaned escape sequences), clean `quit`. debug.log/driver stdout show
+only pre-existing harmless compile warnings (unused locals, unknown
+`#pragma`) throughout — no new runtime errors from any of this session's
+testing.
+
+**Not verified live this pass** (time budget went to the reconnect-
+wizard investigation above): net-dead disconnect/reconnect after actual
+gameplay has begun, skill learning, sect/faction join, shop purchase,
+combat. Given the newbie doc's own detailed skill/combat/shop
+instructions, this lib very likely has full playable content beyond
+the registration wizard — a future pass should pick up from a
+`qfthree`-style completed character and continue the rest of the §10.7
+checklist.
+
+**Files modified**: `libs/sanjiechuanshuo/work/d/wiz/init.lpc` (the fix
+above). Test character saves kept as before/after evidence rather than
+removed.

libs/sanjiechuanshuo/work/d/wiz/init.lpc

@@ -65,8 +65,34 @@ void init()
 void get_start0(object me)
 {
     if(!me) return;
-    
-    me->command("start");
+
+    // BUG FIX (deep functional test, AGENTS.md §10.7): this call_out fires
+    // on every reconnect while no_gift is still set, meant to automatically
+    // re-show the gift-selection menu. me->command("start") is a call_other
+    // to a "command" method that is NOT defined anywhere on the player
+    // object -- the real command() is a bare driver efun (int command
+    // (string), see core.spec), not something callable via ->. FluffOS
+    // silently no-ops an undefined call_other with no error, so this
+    // reconnect path produced no output at all: the player saw nothing
+    // and had no clue that typing "start" themselves (the only other
+    // add_action bound to this verb) would actually work. Confirmed live:
+    // a raw socket test showed zero output even after a 10s wait, while
+    // manually sending "start" correctly redisplayed the full gift menu.
+    // Fixed by replicating get_start1()'s body directly here with
+    // tell_object(me, ...) instead of write() (write() implicitly targets
+    // this_player(), which is not set inside a call_out) and calling
+    // get_start(me) directly instead of round-tripping through the
+    // broken command() call -- get_start() is already player-explicit.
+    tell_object(me, "\n\n欢迎你来到三界传说!!\n");
+    tell_object(me, @LONG
+
+在开始你的MUD历程之前，首先要为自己所创造的人物选择一个合适
+的天赋，因为这将对你今后的发展有重大的影响。本站中的人物天
+赋共有四项（详见 help gifts ），每项由一个十到三十之间的整数
+来表示，一般数值越大越好，但各项的总和是固定不变的。
+LONG
+	);
+    get_start(me);
 }
 
 int get_start1(string arg)
@@ -136,7 +162,13 @@ void get_finish(string arg, object me)
 
 void show_gift(object me)
 {
-    write(_show_gift(me));
+    // BUG FIX (deep functional test, AGENTS.md §10.7): write() implicitly
+    // targets this_player(), which is unset when show_gift() is reached
+    // from get_start0()'s call_out context (see that function's own
+    // comment) -- tell_object(me, ...) targets the explicit parameter
+    // instead, correct in both the call_out path and the normal
+    // player-typed "start" path.
+    tell_object(me, _show_gift(me));
 }
 
 string _show_gift(object me)

libs/sanjiechuanshuo/work/data/login/q/qftester.o

@@ -0,0 +1,2 @@
+#/obj/login.lpc
+dbase (["email":"qftester@test.local","last_from":"127.0.0.1","password":"$6$HtC9zcufalxpWvLh$0lP/lTGioQZZK469alFqUDad7iwzWJaAIWxc5PnQ/9y/MJe8LcP/Fs8D7AkeOTwnI5LPdOzJxnxSDxADPoSyv/","id":"qftester","last_on":1784996495,"body":"/obj/user","name":"秦风",])

libs/sanjiechuanshuo/work/data/login/q/qfthree.o

@@ -0,0 +1,2 @@
+#/obj/login.lpc
+dbase (["email":"qfthree@test.local","password":"$6$jbIhI9rWaXql5CMy$e9xKkDm7E8UxQ9e8BXLnGzqObQiH6jesoNlLBiVxiUFkexNL33Ii35M4mAdmzQiZVnHBVw/ftNpajowfE0XmJ0","last_from":"localhost","id":"qfthree","last_on":1784997215,"body":"/obj/user","name":"秦风三",])

libs/sanjiechuanshuo/work/data/login/q/qftwo.o

@@ -0,0 +1,2 @@
+#/obj/login.lpc
+dbase (["email":"qftwo@test.local","last_from":"127.0.0.1","password":"$6$B0daUVjP9ljZZUi8$U/6QI2aU7FEX29S6mDpcjE.SA3cyqT01BJoXfHtSwaVIWSuI1FIIRHJ5rFy87zF.u5RDPi.VSHV159WS7EpGq/","id":"qftwo","last_on":1784997102,"body":"/obj/user","name":"秦风二",])

libs/sanjiechuanshuo/work/data/user/q/qftester.o

@@ -0,0 +1,3 @@
+#/obj/user.lpc
+dbase (["int":25,"eff_gin":100,"sen":250,"title":"三界侠客","id":"qftester","no_gift":1,"no_magic":1,"actions":,"attitude":"peaceful","water":345,"cps":25,"limbs":({"头部","颈部","胸口","后心","左肩","右肩","左臂","右臂","左手","右手","腰间","小腹","左腿","右腿","左脚","右脚",}),"channels":({"chat","rumor","sldh","es","job",}),"birthday":1784996380,"per":25,"life":(["life_time":92,"init_life_time":92,]),"default_actions":,"food":345,"race":"人类","kee":250,"kar":25,"gender":"男性","con":25,"eff_sen":250,"unit":"位","age":14,"eff_kee":250,"can_speak":1,"max_gin":100,"cor":25,"str":25,"potential":0,"spi":25,"max_sen":250,"max_kee":250,"mud_age":108,"gin":100,"name":"秦风",])
+autoload ({})

libs/sanjiechuanshuo/work/data/user/q/qfthree.o

@@ -0,0 +1,3 @@
+#/obj/user.lpc
+dbase (["quit_time":1784997215,"int":25,"eff_gin":100,"sen":250,"title":"三界侠客","id":"qfthree","no_magic":1,"actions":,"attitude":"peaceful","water":347,"cps":30,"limbs":({"头部","颈部","胸口","后心","左肩","右肩","左臂","右臂","左手","右手","腰间","小腹","左腿","右腿","左脚","右脚",}),"channels":({"chat","rumor","sldh","es","job",}),"birthday":1784997179,"per":22,"life":(["life_time":82,"init_life_time":82,]),"default_actions":,"food":347,"race":"人类","kee":250,"kar":26,"gender":"男性","con":25,"eff_sen":250,"unit":"位","age":14,"eff_kee":250,"can_speak":1,"max_gin":100,"added_title":"无名","cor":22,"str":25,"potential":0,"spi":25,"max_sen":250,"max_kee":250,"mud_age":31,"gin":100,"name":"秦风三",])
+autoload ({})

libs/sanjiechuanshuo/work/data/user/q/qftwo.o

@@ -0,0 +1,3 @@
+#/obj/user.lpc
+dbase (["sen":250,"title":"三界侠客","no_magic":1,"water":335,"per":25,"birthday":1784996593,"channels":({"chat","rumor","sldh","es","job",}),"default_actions":,"race":"人类","kee":250,"gender":"男性","con":25,"max_gin":100,"cor":25,"spi":25,"potential":0,"max_kee":250,"name":"秦风二","mud_age":235,"int":25,"eff_gin":100,"id":"qftwo","no_gift":1,"attitude":"peaceful","actions":,"cps":25,"limbs":({"头部","颈部","胸口","后心","左肩","右肩","左臂","右臂","左手","右手","腰间","小腹","左腿","右腿","左脚","右脚",}),"life":(["init_life_time":79,"life_time":79,]),"food":335,"kar":25,"eff_sen":250,"unit":"位","age":14,"can_speak":1,"eff_kee":250,"str":25,"max_sen":250,"gin":100,])
+autoload ({})