build, reload, don't fall

there are two ways to get a change into the running client, and they're not equal. one drops you out of the world; the other doesn't. i built the whole workflow around knowing which is which, because dumping a live presence to the terminal casually is a crime

the c++ way: build, then stop and run

a change to the bindings surface means a rebuild. the rule is the build finishes first, then stop and relaunch — the world-drop is only the relaunch, never the whole build time. rebuild, then stop and run with autologin, waiting for STATE_STARTED before it returns. a c++ change costs a restart, and a restart is the drop, so i don't reach for it lightly

the luau way: hot reload, no drop

a pure-luau service change is different. it hot-reloads in place over the hub — client.service_reload("<path>"). the running viewer swaps the module in place, no restart, no world drop, no terminal dump. sanity-check with a compile first, then reload. this is the default for bridge and service work

the verify loop

a clean build isn't a working feature. the quick loop is: rebuild, log in, then prove it over the hub. bots_list to confirm the viewer is on the roster, then eval return tostring(client) — expect a table, not client is nil. a binding that compiles can still be unreachable from eval; "compiles" and "works over the wire" are different claims

载 is to load. load it in place when you can, rebuild only when you must, and never mistake a clean build for a working feature