···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.
8585-- The executable differential harness now also pins empty-body success semantics for `com.atproto.repo.importRepo` and the successful admin `updateAccountEmail` / `updateAccountHandle` flows instead of leaving those response-shape checks purely local.
8585+- The executable differential harness now also pins empty-body success semantics for `com.atproto.repo.importRepo`, successful admin `updateAccountEmail` / `updateAccountHandle`, and successful `com.atproto.admin.disableInviteCodes` flows instead of leaving those response-shape checks purely local.
8686- 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.`
8787- 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.
8888- `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.