refactor: streamline v3 architecture, unify RCON execution, and remove legacy abstractions

auth-authme-package/README.md

@@ -2,7 +2,7 @@
 
 Reference [plugwright](https://github.com/Drownek/plugwright) authentication plugin for a server running AuthMe, or anything else that asks for a password in chat.
 
-On every bot connection — the first bot of a test, a second bot from `createPlayer()`, every `player.rejoin()`, and the `external` mode's admin-bot console — it waits for the server's prompt and answers it. Registration is followed through to the login it triggers, because a command sent between the two is still rejected as unauthenticated.
+On every bot connection — the first bot of a test, a second bot from `createPlayer()`, and every `player.rejoin()` — it waits for the server's prompt and answers it. Registration is followed through to the login it triggers, because a command sent between the two is still rejected as unauthenticated.
 
 Microsoft (online-mode) accounts go through the same handshake by default — whether AuthMe still puts up a login wall for a premium account is a server-side setting, not something this plugin assumes. Set `skipOnMicrosoftAccount` if you've confirmed yours doesn't.
 

auth-authme-package/index.ts

@@ -73,9 +73,10 @@ const isEnabled = (value: boolean | string): boolean => value === true || value
 
 /**
  * Reference authentication plugin for a server running AuthMe (or anything with the same
- * login/register-by-chat flow). `onPlayerCreate` fires on every bot connection — the initial
- * join and every `player.rejoin()` — and on the `external` mode's admin-bot console too, since
- * that connects through the exact same `PlayerWrapper.join()` path a test bot does.
+ * login/register-by-chat flow). The credentials go straight into the runner's plugin configuration, and the runner manages
+ * the authentication flow. It happens exactly once per bot — on the very first
+ * join and every `player.rejoin()` — before test code ever gets a chance to see
+ * the player.
  */
 export default definePlugin<AuthAuthmeOptions>({
     name: 'authme',

docs/api-reference.mdx

@@ -114,7 +114,7 @@ Executes a command from the server console.
 </ParamField>
 
 ```javascript
-server.execute(`give ${player.username} diamond 64`);
+await server.execute(`give ${player.username} diamond 64`);
 ```
 
 ## Exported Utilities

docs/custom-modes.mdx

@@ -148,10 +148,6 @@ class VelocityEnvironment implements Environment {
         console: true,
         consoleOutput: 'responses',
         op: true,
-        freshState: false,
-        arbitraryUsernames: true,
-        lifecycle: true,
-        cleanupStrategy: 'compensating',
     };
 
     async setup(session: Session): Promise<void> { /* connect, probe, warm up */ }
@@ -163,7 +159,7 @@ class VelocityEnvironment implements Environment {
 }
 ```
 
-Capabilities are a promise the runner holds you to. Tests declaring `requires: ['op']` are skipped when you report `op: false`, so report what is true after `setup()` rather than what the build script hoped for. `consoleOutput` is three-valued (`full`, `responses`, `none`) because a console that answers its own commands still cannot show a test the server log.
+Capabilities are a promise the runner holds you to. Tests declaring `{ requires: { op: true } }` are skipped when you report `op: false`, so report what is true after `setup()` rather than what the build script hoped for. `consoleOutput` is three-valued (`full`, `responses`, `none`) because a console that answers its own commands still cannot show a test the server log.
 
 `accounts()` and `beforeJoin()` are optional. Returning no pool means every bot gets a throwaway `pw_<rand>` username, which is what `local` does. A pool is also what makes `describe.serial('...', { account: 'pw_0001' })` possible: without one, a block asking for a named account fails rather than running as somebody else.