···8080- `com.atproto.server.requestPasswordReset` and `com.atproto.server.deleteAccount` now follow the reference form-token flow, with focused regression coverage for missing-account and bearerless deletion semantics.
8181- Core no-output account lifecycle procedures now match the official runtime’s empty-body `200` surface instead of returning local JSON `{}` objects: `deleteSession`, `revokeAppPassword`, `deactivateAccount`, `activateAccount`, `requestPasswordReset`, `resetPassword`, `requestEmailConfirmation`, `confirmEmail`, `updateEmail`, `requestAccountDelete`, and `deleteAccount`.
8282- PLC identity success procedures now also match the official runtime’s empty-body `200` surface: `com.atproto.identity.requestPlcOperationSignature`, `com.atproto.identity.updateHandle`, and `com.atproto.identity.submitPlcOperation`.
8383+- Remaining lexicon-void admin/sync/temp procedures now also stay on the empty-body `200` surface instead of returning local JSON `{}` objects, including `com.atproto.admin.updateAccountHandle`, `updateAccountEmail`, `disableInviteCodes`, `updateAccountSigningKey`, `com.atproto.sync.requestCrawl`, `notifyOfUpdate`, `com.atproto.temp.requestPhoneVerification`, `revokeAccountCredentials`, and `com.atproto.repo.importRepo`.
8484+- `app.bsky.actor.putPreferences` and `/oauth/revoke` now also keep their void-style empty-body `200` surface instead of returning local JSON `{}` objects.
8385- Password-bearing account endpoints need the same bounded-length behavior as the official runtime: `createAccount` rejects passwords longer than 256 characters, `createSession` rejects passwords longer than 512 characters with the reset hint, and `resetPassword` / `deleteAccount` reject overlong password inputs with `Invalid password length.`
8486- The executable reference harness now also pins those password-boundary semantics directly, including the official `AuthenticationRequired` error shape for overlong `createSession` requests and case-insensitive `requestPasswordReset` email lookup.
8587- `com.atproto.server.createAccount` with an explicit `did` must behave like an authenticated migration flow: require auth from that same DID, keep the existing DID document, and start the new account deactivated until activation catches the DID document up to the new PDS.