Location Entry Behavior update (2026-10-25): the former Bunny-specific timer qualification gate and progression state have been removed. Location Entry Behavior applies a selected standard appearance itemset; configured timer locks are passed through to BC. The earlier qualification status below is historical, not a current activation requirement.
The current runtime already has a room-creation path: after login it tries to join BC_ROOM; if BC replies that the room does not exist, it sends ChatRoomCreate using the configured room template, adds the bot account as a room admin, and waits for a room sync before becoming ready. See the room bootstrap in client.ts.
So a second person is not necessarily needed just to create the room: the bot is the first authenticated account attempting to create and enter it. A separate human tester is needed to exercise join/leave, chat, permissions, friendship, and map-position behavior. To avoid relying on the create path during a test session, use the configured test room Veratown2 if it exists and keep a human tester in it. If the bot’s create request is rejected, have a test account create the room through BC and stay there; ensure it has the intended test map, since a manually created room will not automatically get the bot’s copied room template.
The intended code revision and a live BC target. The R133Beta1 pin update is in PR #13; run that revision, or its merged equivalent. Confirm the BC server you are testing against actually serves the version you intend to qualify—the source pin does not update the BC server itself. The test environment guide describes local testing against the configured BC server.
Dedicated accounts and room roles. Use a dedicated prototype bot account, not the production bot account, plus at least one separate test account. Three accounts are preferable: the bot, a room-admin test operator/subject, and an ordinary member/observer. That lets you test both allowed and denied actions and observe targeted messages without treating the bot as its own test partner.
Test-only Mongo configuration. Set RUNTIME_TARGET=test, BC_ROOM=Veratown2, and use only veratown_prototype_test. The target/database pairing is enforced by the config parser. If the test database needs room/map/door configuration, first run the allowlisted configuration-copy script as a dry run and review its output before applying it. It copies selected room, map, location, door, group, and membership configuration—not player profiles, sessions, or audit history. Appearance itemsets are not seeded by the copy script; runtime startup seeds a disabled location-entry behavior baseline when neither the generic location-entry-behavior.rules nor legacy bunny.rules key is present.
A safe room and test data. Keep a human participant in the room for interactive tests. Seed only test map locations, door definitions, groups, memberships, and appearance itemsets in the test database. Use test coordinates and harmless test items. Room map writes affect everyone in that BC room; RUNTIME_TARGET=test isolates MongoDB, not BC-side effects.
A deliberate run plan. Start the bot with the test .env, check that it logs in, receives a room sync, and writes its heartbeat to the test database; then run the live cases below. Never put credentials in chat or logs.
| Area | What to exercise | Important conditions |
|---|---|---|
| Startup, status, and command routing | Login, join/create, room sync, /bot help, /bot prototype, bang-prefixed commands, disconnect/reconnect, and clean shutdown. |
The bot must be room-ready before commands can be meaningfully tested. Verify outcomes in the test database; a dispatched whisper is not proof it was delivered. |
| Map and doors | Location entry and exit, door open/close, code and group access, unauthorized attempts, admin CRUD, map observation, timed expiry, and closure deferral while a non-bot character occupies the configured region. | Requires the test room’s map, locations, doors, groups, and memberships to be configured. Test with both an authorized and an unauthorized member; check observed room state rather than assuming a sent update succeeded. See the map and doors guide. |
| Communications and social | MOTD on character entry, !testcomms <memberId> <text>, friend-request reciprocity, online-friend read-back, and beep. |
The sender of testcomms must be a room admin. Keep a separate target online; beep requires the target to be a bot friend. Status is intentionally skipped because the current BC renderer does not display it, and room-visible tests should use non-sensitive text. See the communications guide. |
| Appearance | Inspect, apply/configure, lock/remove, apply a test itemset, and verify observed state and cleanup. Include allowed, denied, occupied-slot, timeout, and disconnect cases. | Set APPEARANCE_QUALIFICATION_ENABLED=true only for an explicitly approved test-room qualification. Commands are room-admin-only and mutations are restricted to the sender’s own character. The automated live qualification uses separate primary and dedicated test accounts, a clean test slot, local ignored credentials, and explicit live-run flags. Follow the appearance qualification guide; do not leave a browser logged into either test account during the run. |
| Location Entry Behavior | Test type defaults, per-location overrides, standard itemset selection, location transitions, and honest action outcomes in the isolated test database. | Configured itemset timer settings pass through to BC; the feature has no expiry or progression state. Use the optional native timer observation only when live BC behavior needs observation. |
| Persistence and lifecycle | Verify action-journal outcomes, test-database heartbeat, plugin cleanup, restart behavior, and no automatic retries after uncertain writes. | Treat a timeout or local packet dispatch as unconfirmed unless the corresponding live BC observation/read-back occurs. |
A “full test of every feature” cannot mean enabling every planned behavior today. Cage and Release automation are not included. Also, the historical R132 appearance run is not evidence that R133Beta1 has passed the same live qualification.
I have not connected to BC or MongoDB for this answer. Once the test account(s), room availability/map, test database configuration, and approval for live appearance and Location Entry Behavior observations are in place, the test can be run in phases without touching the production bot or runtime database.