Documentation Index
Documentation is grouped by the question it answers:
| Area |
Contents |
| Architecture |
Runtime composition, BC interfaces and acknowledgements, shared plugin/command conventions |
| Features |
Feature behavior, operator guidance, diagrams, and feature-specific plans |
| Operations |
Environment setup, database isolation, deployment, and runbooks |
| Proposals |
Pending designs and plans; completed implementation proposals are kept in a dated archive |
| Testing |
Test-specific investigations and temporal/qualification notes |
Architecture
Features
- Veratown User Guide — player and room-administrator overview of available features and command entry points
- Appearance foundation — pinned-catalog itemsets, observed prerequisite evaluation, and conditional variants
- Shared economy
- Shop region — region-gated drinks, recipient-consented gifting/releases, self-service favors, and optional helper-a shopkeeper flavor
- Hot Seat — opt-in room-scoped bluffing game, disabled by default
- Staged Table — opt-in five-card-draw game with simulated solo opponents, pinned avatar stages, and recoverable release
- Trick-or-Treat — configurable map-location game with participant-only emote door unlocks, observed-costume reward doubling, and opt-in timed consequences
- Dilemma prediction game — disabled-by-default fictional choice game with per-round opt-in and idempotent rewards
- Location Entry Behavior guide
- Location Entry Behavior implementation
- Casino wallet and revised games — rolling entry funding and approved slots/roulette with fail-closed location-based access
- Casino games and rewards implementation plan — approvals, release gates, and later phases
- Roulette wheel helper presentation — optional helper-avatar Chat/Emote stages with supervisor-owned wagering, settlement, and private reports
- Truth or Dare — operator-approved gameplay gate; each room config remains disabled by default
- Communication and social features
- Anonymous Whisperer — Variant B implementation; disabled by default
- Veratown map and doors
- Location entry messages — configurable private messages with observed player and room context
- Delayed location appearance — apply an existing appearance itemset after a player stays in a location for a configured delay
- Emergency release — native-only self-service application of the configured appearance set
- Shower system — opt-in, disabled by default; accepts BC room observations and requires wardrobe permission
- Shower system implementation plan — implementation and remaining qualification status
- Prototype status
- Helper Bots — leased, location-scoped public communications from separately deployed BC accounts
- ABCL Region Feature — separate runtime, database-required active region, helper-only communication, and participant opt-in; see the player guide for in-room consent and gameplay
- World administration
Feature-specific user guides
Each feature has a directory. Use README.md for the detailed behavior and
operator reference, and USER_GUIDE.md for its player or room-administrator
guide. Keep related design or implementation plans beside these guides using a
descriptive name such as IMPLEMENTATION_PLAN.md.
Operations
- Configuration management web service — versioned BC room settings and bot-instance profiles, visual stored-map editing, MOTD scheduling, recovery, database-backed operator accounts, and FIDO2 passkeys
- BC source compatibility review, 2026-10-22 — R133 source repin, teleport-pad preservation, refreshed catalogs, and qualification limits
- BC source compatibility review, 2026-10-29 — R133 item color schema, refreshed asset/map catalogs, protocol type updates, and qualification limits
- BC source compatibility review, 2026-11-03 — R133 tether declarations and map metadata, refreshed appearance catalog, and qualification limits
- Offline map analysis and isometric images
- Standalone local map-draft review GUI
- Standalone Railway map analysis service
- Runtime environments
- Railway deployment
- HOWTO: Configure Railway supervisor and helper bots
- HOWTO: Enable supervisor-managed ABCL
Proposals
Completed proposals are retained as design history in
the dated archive:
Testing
Adding or moving documentation
- Put shared runtime and protocol contracts in
architecture/.
- Put feature-owned behavior and plans in
features/<feature>/.
- Put deployment, environment, and operator runbooks in
operations/.
- Put unadopted cross-cutting designs in
proposals/; keep a feature-specific
proposal in that feature’s directory.
- Move completed proposal records to
proposals/archive/ with an explicit
archive date; keep current runtime behavior in the feature or architecture
guide and link back to the archived design record where useful.
- Put test investigations and test workflow notes in
testing/.
- Preserve concise existing filenames unless a feature guide is being made the
directory’s
README.md or a plan is being normalized to
IMPLEMENTATION_PLAN.md.
- Update links in the root
README.md, this index, affected docs, and
.github/instructions/ whenever a document moves. Prefer relative links
between docs and verify their targets after reorganizing.