## Full web integration — agreed foundation

The web app is a full entrance to the same MUD. A **user account** can own multiple **PGs**. A user signs in once, sees the PGs linked to their account, and switches the active PG without logging out. Browser and Telnet connect to the same authoritative character and world state: progress, inventory, location, permissions, and actions persist across both interfaces. The current preview character is temporary; it does not satisfy this requirement.

Web sign-in supports existing MUD credentials, new registration with an email address and password, and social login. Every newly registered user account requires an email address, including an account created through social login. If the social provider does not supply one, registration asks for it. The exact providers and email-verification process remain to choose.

Creating a first PG without choosing an existing user account automatically creates a user account for that player, initially named after the PG. The creation flow must collect the required email address and credentials for that user. A PG created under an existing signed-in user belongs to that user. A player can link additional existing PG accounts after proving ownership of each PG; linking must not let someone claim another player's character. Existing PG credentials need a migration path into this model.

Telnet keeps direct character entry: the player names the PG they want to play and authenticates with the credentials of the user account that owns that PG. This opens the named PG immediately, without a web PG-selection step. The exact prompt format and treatment of old per-PG passwords remain to design while preserving working legacy logins during migration.

The forum is the heart of the web experience, alongside the playable game. The active authenticated PG can move between play, chronicles, discussions, and their own journal without creating a separate forum identity. Switching PG changes the forum author and PG-specific view accordingly. Posts, event participation, and permissions identify the real PG; the player chooses explicitly what private game material to publish. Feature 16 develops the community and storytelling experience.

Administration is integrated into the same web app and account. Staff see the tools allowed for their active PG's actual role or explicit delegation; switching to another PG changes the available permissions. Forum moderation, event preparation, building, publishing, support, and oracle commands use the applicable permissions and attribution. Shod's owner authority follows his authenticated PG identity, not merely ownership of another PG on the same user account, a displayed name, or a rank. A PG without staff rights does not gain administration access by entering an admin URL.

The exact handling of simultaneous web and Telnet sessions, credential migration, account recovery, email verification, and social-login providers needs a separate design. These choices must preserve ownership and avoid giving one PG access to another PG's data or powers.