feat(desktop): relay admin console for the /api/admin/v1 operator surface

[wpfleger96]

Adds a relay admin console under Settings — the single surface for relay-level operator work — replacing the previously unreachable moderation section. Operators authenticate with their own Nostr key over NIP-98 — no browser extension, no bearer token — to view deployment-wide moderation reports and product feedback, resolve/dismiss/escalate/reopen reports, update feedback status, and manage the operator/moderator staffing roster.

Nav reachability

The old moderation section id was defined in settingsSections but never wired into any group in settingsNavGroups, so the sidebar never rendered it — unreachable since #1617. This PR replaces it with a relay-admin section wired into the Communities nav group, pointing at the relay admin console, and drops the separate admin-console section id so a single surface owns relay-level trust & safety.

The Relay admin nav entry is always visible. Auth gates the panel itself; the nav entry is a door, not a credential — hiding it behind discovery state would strand an operator whose relay transiently fails NIP-11 discovery with no path back to the connection settings.

Discovery and connection

On mount the console reads the connected relay's NIP-11 document for the optional admin_api field. When a valid origin is discovered and its host matches the connected relay's host (case-insensitive, host identity only), it is automatically saved and probed — the panel renders immediately with no Save step required. A cross-host advertisement is pre-fill only: it populates the manual origin field under Advanced and is never saved or probed without an explicit Save, so a relay cannot direct an unconsented NIP-98 signature at a third-party origin; residual exposure on the same-host path is bounded by NIP-98's URL/method/payload binding. Saving is only required for manual origin changes. The advertised origin is untrusted input: revalidated through AdminOrigin::parse, falling back to manual entry when absent or invalid. A saved manual origin always takes precedence over discovery.

Auth and transport (Rust, src-tauri/src/commands/admin/)

• AdminOrigin value object: validates scheme + host + optional port, rejects credentials/path/query/fragment; http:// only for loopback. The relay side normalizes its configured admin host at config load and compares inbound Host/Origin hosts case-insensitively.
• AdminRoute closed enum: no IPC surface accepts arbitrary URLs, so the NIP-98-signed URL is byte-identical to the fetched URL.
• Dedicated no-redirect reqwest client as an SSRF guard: a relay 3xx is an error and the NIP-98 header never crosses origins.
• admin_probe signs GET /probe and returns a typed state (nip98Authorized / nip98Denied / tokenMode / disabled / notAdminApi / networkOrIntercepted). The response body is validated against the full relay contract — nip98Authorized only when the complete NIP-98 invariant holds, disabled only on a coherent disabled-mode body; any incoherent or unrelated JSON classifies as notAdminApi, so the console never fails open at the network boundary. Unknown fields are tolerated for forward compatibility.
• NIP-98 signing via AppState::signing_keys(), one retry on 401 with a fresh signed event; response size bounded by a Content-Length preflight and a streaming byte counter; per-pubkey origin storage with atomic 0o600 writes.

Relay admin console

The console is gated behind the relay OPERATOR/MODERATOR roles from #3777; every /api/admin/v1/* route returns 403 to anyone else. Community self-administration (community-members / Invites) and in-channel enforcement (the 9040–9043 signed commands) are a separate axis and are untouched. The previously-duplicate community report queue (ModerationQueueCard, moderationQueue.ts, and three dead hooks) was unreachable dead code and is deleted in its own commit; useBanMemberMutation and the rest of features/moderation/hooks.ts remain in use by the members sidebar and message menu.

Console UI (TypeScript, src/features/admin-console/)

• AdminConsoleSettingsCard: discovery + probe flow, honest copy for every probe state, manual origin under an Advanced disclosure at the bottom. The role (operator/moderator) is rendered in the connection status line as plain text ("Connected as operator") — no badge-shaped elements above the tab row. The origin provenance (relay config / database) appears inside the Advanced card as small muted text. Section title changed to Admin.
• AdminConsolePanel with Reports / Feedback / Staffing tabs (Staffing gated on role === "operator"); reports and feedback grouped by community for cross-community triage.
• Reports: always requests scope=all so the existing resolve/cancel/reopen controls can reach every status (open, processing, resolved, dismissed, escalated). The relay's omitted-scope default is escalated-only (the platform-safety backstop); scope=all is explicit and scoped to this console. Full action matrix per target_kind (event → delete/kick/ban/timeout/dismiss/escalate; pubkey → ban/timeout/dismiss/escalate; blob → dismiss/escalate); kick is suppressed when the report carries no channelId. A processing row stays navigable — enforcement state lives in the detail view. A failed action (always pre-mutation) offers a single Cancel & reopen via POST /reports/{id}/cancel with {actionId} fencing; there is no client-side retry. pending/enforcing actions belong to the relay recovery worker and offer no button; a 409 reloads detail. Lists refetch on back-navigation after a mutation.
• Report failure UX: reportErrorMessage() strips 4xx/5xx status prefixes and surfaces the relay's own error reason in the toast (e.g. relay returns "400: you cannot report this content" → toast shows "you cannot report this content"). Self-report blocking UI removed — the relay has no self-report gate, and the failure was purely client-side error surfacing.
• Reason audience disclosure: the Reason (optional) field shows exact copy under the input based on selected action — Delete discloses that reason is sent verbatim to the affected user and posted publicly in the room; Kick/Ban/Timeout disclose affected-user only; Dismiss/Escalate disclose reporter only. These mirror the actual relay notice paths.
• Enforcement history: the report detail carries the governing action even after the report leaves processing — a report enforced then reopened is open yet still shows its succeeded action as executed history alongside the resolve form; a reopen does not un-happen a ban. The resolve form gates on open status alone.
• Reopen: terminal reports (resolved/dismissed/escalated) can be returned to open for re-triage via POST /reports/{id}/reopen. Reopen never reverses applied enforcement, and the copy says so.
• Feedback: list, detail, and status control (new/reviewed/archived) with a generation-fenced attachment viewer. A purged source community severs provenance to null rather than deleting the row; severed rows bucket under a "source community removed" heading.
• Staffing: Add is create-only with display names resolved via useUsersBatchQuery and npub cross-fade on hover (HoverStaffingIdentity). An entered key that already appears in the authoritative roster (config, owner-fallback, or DB) is rejected locally with an inline duplicate-key message and no request is issued; a config-backed principal targeted by add, role change, or remove returns the relay's 409 Conflict, classified via the typed relayStatus (never by matching message text) and rendered with config-backed copy. Roster with config/owner_fallback/db source labels; config-backed entries disable remove client-side. In-place role change via <select> calling putAdminOperator; the relay responds with the effective OperatorEntry (pubkey, effectiveRole, sources) in the same shape as the roster list. Read-only badge for config-managed entries.
• Timeout expiry: useTimeoutState clears the store when derived state is INACTIVE but the store is still active; the 1s tick is scoped to entries with a known expiresAtMs and owned by ComposerTimeoutBanner (mounted only while a timeout is active), while ChannelPane subscribes to the boolean useTimeoutActive() — the pane re-renders when a timeout starts or ends, not every second. useMembersSidebarModeration ticks nowMs only while the sidebar is open, the viewer can moderate, and some member has a future mutedUntil; the tick after the last expiry stops the interval.
• Mutations confirm via sonner toasts; failures surface the relay's parsed error message, not raw JSON. tokenMode and disabled auth modes render read-only.

Mutation idempotency

Resolve and reopen carry a per-attempt requestId. On first submit the whole command ({requestId, action, reason, expirationSecs}) is frozen; after an ambiguous failure (409, 5xx, transport error, truncated response) the snapshot is retained, action/reason/duration controls are locked, and the retry sends the exact same payload byte-for-byte. A definitive pre-commit rejection (non-409 4xx with bodyComplete: true) discards the snapshot, unlocks controls, and the corrected submit uses a fresh payload. On success the toast derives from the authoritative AdminReportResolution (activeAction.action when present; otherwise status for decision-only outcomes) — never from the mutable form selection.

The native mutation commands — including operator delete — reject with a typed AdminMutationError carrying the relay's HTTP status (relayStatus, null when no verdict exists) and a bodyComplete flag that is true only when the full response body was read.

Related: #3777 (relay OPERATOR/MODERATOR role model + NIP-98 auth + admin_api NIP-11 advertisement — provides the runtime and the discovery field this console consumes)
Related: bb-public#339 (Phase 4 rollout config)

Screenshots

Captured headless at 197f0ba0c against the mock bridge (1280×720).

Setup

Origin setup — Advanced disclosure open, idle state

Authorized console — all three tabs

Reports

Reports queue — open, processing, resolved across two relay groups

Open report detail — reporter, target, message snapshot, resolve form

Processing report — PROCESSING/HARASSMENT, ban enforcing state

Resolve form — Delete selected, audience disclosure copy

Resolved report — enforcement history block

Feedback

Feedback list — community grouping with status badges

Feedback detail — mutable status control (operator mode)

Feedback detail — passive status badge (read-only/disabled mode)

Staffing

Staffing roster — config/owner_fallback/db source labels

Add form — new pubkey filled, ready to submit

Duplicate rejection — inline error for existing principal

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested

• [P1] Do not auto-probe an unrestricted relay-advertised origin — desktop/src-tauri/src/commands/admin/mod.rs:938-949

  admin_api is explicitly untrusted NIP-11 data, but discovery applies the same permissive policy as manual operator input: HTTP loopback is accepted and every HTTPS host is accepted. Both the nav resolver and settings card then probe that value automatically without confirmation (hooks.ts:45-56, AdminConsoleSettingsCard.tsx:303-316). A malicious connected relay can therefore make the native client contact http://localhost:<port> (the client pins localhost to 127.0.0.1) or HTTPS private/link-local targets. If the target returns 401 WWW-Authenticate: Nostr, the app sends it a fresh app-key signature, adding a signing oracle and pubkey-ownership disclosure to the SSRF. Separate advertised-origin validation from manual configuration: do not auto-probe loopback/private/link-local advertised destinations, and account for DNS resolution/rebinding, or require explicit operator confirmation before any cross-origin probe. Keep the loopback HTTP carve-out only for manual origins.

• [P2] Actually make disabled-auth mode read-only — desktop/src/features/admin-console/AdminConsoleSettingsCard.tsx:397-480

  disabled currently renders the same AdminConsolePanel as an authorized principal, with only the staffing tab hidden. The report resolve/reopen/cancel controls and feedback status controls remain enabled, although the related relay contract intentionally rejects every mutation in disabled mode with 403. This contradicts the PR’s stated read-only behavior and presents controls guaranteed to fail. Pass a read-only capability into the panel and suppress/disable all mutation affordances when the probe result is disabled.

The command registration/API seams, identity and async fencing, report lifecycle/idempotency paths, attachment cleanup, navigation, staffing gating, and legacy-surface removal were otherwise coherent in this read-only diff review. GitHub currently exposes only a passing DCO check for this head; PR code was not executed locally under the automation trust policy.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Two security/resource-boundary blockers remain on this head:

1. Do not auto-probe a relay-advertised admin origin under the manual-origin trust policy. The NIP-11 admin_api value is explicitly untrusted, but admin_origin_from_nip11 passes it through the same AdminOrigin::parse policy used for operator-entered values. That policy accepts loopback HTTP and unrestricted HTTPS hosts. Both the navigation resolver and the settings card then automatically probe the advertised origin, and the probe performs a native GET before sending a fresh NIP-98 signature when the target replies with 401 WWW-Authenticate: Nostr. A malicious connected relay can therefore advertise http://127.0.0.1:<port> / localhost (the client explicitly pins localhost to 127.0.0.1) or an HTTPS private/link-local target and trigger zero-click native SSRF; a cooperating target also gets an attacker-triggered signing oracle and proof of the app pubkey. This is not hypothetical policy drift: mod_tests.rs currently asserts that a loopback origin from NIP-11 is accepted and returned for automatic probing. Please separate advertised-origin validation from explicit manual configuration: never auto-probe loopback/private/link-local advertised destinations, and account for DNS rebinding, or require an explicit operator confirmation before any cross-origin probe. Keep loopback HTTP only for a manually entered origin.

2. Bound attachment preview work across the whole feedback item, not only per response. parseImetaAttachments accepts and returns every valid imeta tag, FeedbackDetail mounts an AttachmentViewer for every result, and each image/* viewer immediately starts its own native fetch. The Rust command caps each response at 10 MiB, but there is no attachment-count, aggregate-byte, or concurrency bound. The relay’s feedback ingest bounds serialized tags to 64 KiB but does not cap the number of imeta entries, so an admitted feedback event can fan out many simultaneous image reads and retain their blob URLs until navigation. The existing test explicitly blesses multiple tags but covers no aggregate/concurrency ceiling. Please impose a small count plus aggregate-byte budget before rendering/fetching, avoid unbounded parallel auto-load, and add a regression showing excess attachments are not requested.

The closed route construction, exact-body NIP-98 binding, no-redirect client, mutation idempotency/recovery fences, and identity/origin React state fences otherwise held in this read-only diff review. GitHub currently exposes only the passing DCO check for this head; I did not execute PR code under the automation policy.

Accidental duplicate from a concurrent automated recovery. The earlier marked review 5032499207 is authoritative.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested

• [P1] Do not automatically probe an unrestricted relay-advertised origin — desktop/src-tauri/src/commands/admin/mod.rs:938-950

  admin_api is untrusted NIP-11 data, but discovery runs it through the manual-entry policy, which accepts loopback HTTP and every HTTPS host (origin.rs:64-90). With no saved origin, both the settings surface and navigation resolver automatically probe the advertised value (AdminConsoleSettingsCard.tsx:284-316, hooks.ts:41-56). The native probe first GETs that attacker-selected destination and, if it answers 401 WWW-Authenticate: Nostr, sends a fresh NIP-98 signature to it (mod.rs:160-215). A malicious or compromised connected relay can therefore target localhost, private/link-local addresses, or an attacker hostname that resolves there; no-redirect handling does not constrain this initial destination. Separate advertised-origin trust from explicit manual configuration: require an explicit confirmation or prove/bind the advertised endpoint to the connected relay, and reject resolved loopback/private/link-local/reserved targets with rebinding-safe connection handling. Add advertised-origin tests for loopback, RFC1918/link-local, and a public hostname resolving privately. The existing discovery test currently blesses automatic loopback probing (mod_tests.rs:872-916).

• [P1] Bound attachment fan-out across the feedback item — desktop/src/features/admin-console/AdminConsolePanelHelpers.tsx:243-272

  parseImetaAttachments returns every valid imeta tag, FeedbackDetail mounts every result (AdminConsoleFeedbackTab.tsx:420-465), and each image/* viewer immediately starts its own native fetch on mount (AdminConsoleFeedbackTab.tsx:215-224). The 10 MiB native cap is per response, with no attachment-count, aggregate-byte, or concurrency ceiling. A single admitted feedback event can therefore trigger many simultaneous native reads and retain all resulting blobs until navigation. Impose a small item-wide count/aggregate budget and bounded fetch concurrency (or explicit loading), then add a regression proving excess attachments are not requested.

• [P2] Keep disabled-auth mode read-only as documented — desktop/src/features/admin-console/AdminConsoleSettingsCard.tsx:470-480

  A coherent disabled probe mounts the same panel as an authorized principal without passing a read-only capability. Report resolve/reopen/cancel and feedback status controls therefore remain live, although the relay rejects mutations in this mode. This contradicts the documented contract that disabled mode renders feedback status read-only (docs/admin/README.md:267-276) and the PR description. Pass the auth capability into the panel and hide or disable every mutation affordance while preserving reads.

• [P2] Expose the selected feedback status programmatically — desktop/src/features/admin-console/AdminConsoleFeedbackTab.tsx:352-375

  The current status is communicated only through button styling (variant and ring classes). The three ordinary buttons have no aria-pressed, radio semantics, or textual current-value output, so a screen-reader user cannot determine the active status before changing it. Add a programmatic selected state and assert that semantic contract rather than only the visual class.

The closed route construction, exact URL/body NIP-98 binding, no-redirect client, response caps, identity/origin async fences, report lifecycle and request-ID recovery contract, role-gated staffing, and legacy moderation-surface removal were otherwise coherent in this read-only exact-head review. Desktop, Rust, build, and desktop integration checks are green; PR code was not executed locally under the automation trust policy.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested at exact head 63db828a09b270239d5e56bf82c3f5e8468cea43 and exact base a3730784fc851bb1125b40cca9b0a30788a293c1.

P1: require confirmation before removing an operator

The Staffing trash button calls handleRemove directly, which immediately invokes deleteAdminOperator (desktop/src/features/admin-console/AdminConsoleStaffingTab.tsx:105-121,203-224). One stray click therefore deletes a DB-backed operator, potentially the acting operator, without a confirmation, target/role recap, or undo. That can remove administrative access and may require another operator or out-of-band configuration to recover.

Put this destructive authorization change behind an explicit confirmation dialog. Make self-removal especially clear, and add cancel/confirm behavior tests. The current event suite only checks whether staffing controls are rendered; it does not exercise removal confirmation.

P2: recover when the active Staffing tab becomes unauthorized

activeTab persists independently of role (AdminConsolePanel.tsx:832-843). If the same mounted panel changes from operator to moderator/unknown while Staffing is selected, the tab button disappears and the content is suppressed (AdminConsolePanel.tsx:859-887), leaving an empty panel with no selected visible tab. Reset an invalid active tab to Reports when role/capabilities change and cover that prop transition.

The previous advertised-origin SSRF, attachment fan-out, disabled-mode mutation, and feedback-status accessibility blockers are otherwise closed at this head. Relay discovery is now prefill-only until an operator explicitly saves the origin; item-wide attachment limits, read-only mutation gating, and aria-pressed are present. Hosted substantive checks are green. This was a read-only review of immutable GitHub source/diffs; no PR code was checked out or executed.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Review clear: prior blockers resolved

Reviewed head 21f34f0138a4e00782f914d28a90346b994b650c against base 42aeb1571cc1f1ed4d73f05b420474be970021ab, including the corrections since review 5073088157. No remaining blocking finding in the reviewed paths and agreed delivery contract.

• Staffing: Add now requires a loaded roster and rejects normalized existing keys before PUT. The actual form/IPC regression checks zero PUTs for an existing operator and a successful new-moderator add with roster refresh. This closes the demonstrated accidental-demotion path; the API remains an upsert, so this is snapshot-based duplicate prevention, not atomic server-side create-only behavior.
• Manual localhost: http://admin.localhost:<port> is accepted and pinned to loopback without rewriting the hostname used for Host or NIP-98 signing. The added production-client/probe test inspects the signing URL and both wire Host headers. Discovery still requires explicit Save before contacting an advertised admin origin.
• Integration: Read-only feedback detail now shows its status. The “Relay admin” rename preserves the old moderation URL token in route validation and AppShell. Report scope, frozen resolve retries, cancel/reopen semantics, and operator/moderator authorization remain consistent with the previously reviewed contract.

Non-blocking follow-ups: the staffing regression does not explicitly exercise uppercase/whitespace, self-key, or pending/failed roster loading. Discovery’s reserved-domain check omits .localhost, so failed system DNS can allow a loopback prefill; explicit Save still prevents automatic access. These do not reopen the agreed fixes.

Validation: immutable source/diff and existing-test inspection only, with independent native and staffing/feedback reviews integrated. No checkout, builds, tests, or PR-code execution; no runtime-pass claim. Separate community moderation, mobile/web operator UX, deployment configuration, and unrelated merged-main changes were outside this corrective review. This is a COMMENTED review, not approval.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: two regressions since the previous clear review

Reviewed head b0b5d6467ea6f87c58f86f62b796a13a319e761c against exact base 88687876f7808a2fd742b7eb2e4b9f87d999ad8d, with a source-level delta from previously cleared head 21f34f0138a4e00782f914d28a90346b994b650c.

P1: Do not automatically trust and probe the advertised admin origin

desktop/src/features/admin-console/AdminConsoleSettingsCard.tsx:322–335 now persists discovery into the manual-origin store and calls runProbe without confirmation. The unchanged native discovery implementation was safe only as a prefill: discovery.rs:50–55 rejects bare localhost but not .localhost, and lines 75–79 accept DNS lookup errors expressly because the operator would still have to Save.

Concrete path: on a platform where system DNS does not resolve .localhost, let the connected relay advertise http://admin.localhost:<port> and open Admin with no saved origin. Discovery accepts the lookup failure; the new effect saves the origin; the dedicated admin client then deliberately resolves .localhost to 127.0.0.1 (dns.rs:34–41). The client reaches that loopback service without the user choosing it. If it answers 401 with WWW-Authenticate: Nostr, mod.rs:199–217 signs and sends a NIP-98 probe with the active app key. The route/method are fixed; this is unauthorized local-network access and a signed identity disclosure, not private-key extraction. Disabling redirects does not protect the initial destination.

This was explicitly non-blocking in the prior review only because explicit Save prevented all contact. Removing Save makes it reachable. The new jsdom success test (adminConsolePanelEvents.jsdom-test.mjs:1677–1750) mocks discovery returning literal loopback and bypasses the native checks, so it cannot establish the advertised-origin security contract.

Smallest exit: restore discovery as prefill-only until explicit Save, preserving manually trusted internal origins. If zero-confirmation discovery is intentional, it needs a separately secured advertised-origin transport policy, including .localhost/DNS failure and connection-time address binding; the manual syntax parser alone is not sufficient. Cover the real discovery-to-probe boundary, not just the IPC success mock.

P2: Reconcile the active principal after an in-place self-demotion

The new role selector calls handleRoleChange (desktop/src/features/admin-console/AdminConsoleStaffingTab.tsx:383–400), whose successful PUT only increments the local roster generation (209–211). With DB operators A and B, sign in as A and change A’s row to moderator. The mutation commits because B remains an operator (crates/buzz-db/src/store/relay_operators.rs:168–179). The subsequent roster GET correctly rejects A as a moderator (crates/buzz-relay/src/api/admin/auth.rs:285–307,325–333; admin/mod.rs:913–924).

But the console still says Connected as operator, retains Staffing as the selected/visible tab, and replaces the roster with an error. The parent SettingsCard owns the probe and is never updated (AdminConsoleSettingsCard.tsx:363–383,434–442); Panel’s existing operator-to-moderator reset cannot fire because its role prop has not changed (AdminConsolePanel.tsx:929–943). This is incorrect post-mutation state, not an authorization bypass. Re-probing/remounting repairs presentation; only another operator can restore A’s staffing authority.

Exit: after successfully changing the current principal’s role, refresh the parent authorization state and move to an allowed tab rather than only reloading the operator-only roster. Exercise the real SettingsCard mutation-to-probe path with A/B, assert moderator status and Reports/Feedback without Staffing. The existing test manually supplying a changed role prop proves only the downstream reset; the new test covers another user’s promotion (adminConsolePanelEvents.jsdom-test.mjs:6101–6184). Consider the same explicit self-access warning already used by Remove, but the stale principal transition is the concrete blocker. Add duplicate rejection and server last-operator protection remain intact.

Coverage and limits

The relay remains authoritative for authorization, enforcement, provenance and audit, separately from community owner/admin moderation. Reviewed Settings/navigation/identity/origin transitions; native discovery/signing/transport; report list/detail/resolve/cancel/reopen and retry contracts; feedback lifecycle; staffing; timeout/sidebar/report-error deltas; and command registration. Checked duplicated report/action/target/feedback/role/source/probe/settings closed sets. Report lifecycle, feedback, native admin transport and auth blobs remain identical to the prior clear where noted; the Panel change is presentation-only. Prior report scope, frozen resolve retries, manual .localhost support, read-only feedback status, and Add duplicate fixes remain intact.

Non-blocking coverage follow-up: the added timeout tests exercise imperative store/pure helpers, not the changed reactive hooks. Hook-level fake-timer tests would make expiry and interval cleanup regressions falsifiable. No concrete new runtime failure was established there. Existing raw staffing error presentation and snapshot-based Add concurrency are not additional merge gates.

Validation was immutable source/diff and existing-test inspection only, with independent review lanes integrated. No PR checkout, build, test execution, or live app/relay run. Separate community moderation as a whole, mobile/web operator interfaces, deployment configuration, and unrelated rebase changes were excluded.

[wesbillman]

Carl, an automated reviewer, commenting via Wes’s GitHub account.

Changes requested: two P2 Staffing defects

Reviewed head efa68d25829d357b7b557cbe92eb2e48cd094be0 against base 3c7f288c60d67df78577b237e27c3dfc8831aaa1, focusing on changes since reviewed head b0b5d6467ea6f87c58f86f62b796a13a319e761c and the agreed integration contracts. Relay operator/moderator authority remains separate from community administration; the relay is authoritative for permissions and mutation outcomes.

P2: Refresh the active principal after successful self-demotion (unresolved)

Staffing’s successful role change only increments its roster generation. With two effective DB operators A and B, sign in as A and change A to moderator. The PUT succeeds, then the operator-only roster reload returns 403, but Settings still says Connected as operator and retains Staffing. The parent’s role comes exclusively from its previous probe; no mutation callback refreshes it. This is stale authorization presentation, not a server authorization bypass. Successful self-removal has the same reconciliation gap.

Exit: after changing/removing the current principal, refresh the parent probe and reconcile visible tabs/access. Exercise the actual Settings → Staffing mutation → principal transition, asserting moderator status and Reports/Feedback without Staffing (or denied state after removal). The existing role-downgrade test manually supplies a new role prop, so it cannot catch the missing upstream update.

P2: Preserve the last-operator conflict’s recovery instruction (new regression)

The new role-change 409 branch and remove branch classify every typed 409 as a config-backed key. With no effective config operator and one DB operator, attempt to demote or remove that operator. The relay correctly rejects it with “add a replacement operator first” (PUT, DELETE). The UI instead claims this mutable DB row is config-backed, hiding the supported recovery and directing the operator toward the wrong cause.

Exit: display the relay’s parsed error message for these conflicts, or distinguish a stable conflict reason rather than treating HTTP status as one. No broader transport redesign is needed. Cover both immutable-config and last-operator responses for role change/removal; the new 409 tests currently encode only the immutable interpretation.

Fixes, boundaries, and validation

Cross-host discovery now requires explicit Save, closing the prior automatic cross-host/.localhost signing path. Intentional same-host discovery, including another port, is not a finding. The discovery DNS check is not connection-time address binding, but the proposed additional proof-disclosure scenario requires a TLS endpoint valid for the already-trusted hostname; no additional credential capability was established. Treat that as non-blocking hardening, preserving manually trusted internal origins.

The report extraction preserves the prior implementation and frozen retry/action contracts. Inspected timeout/banner/sidebar lifecycle changes and new reactive tests; no additional defect established. Native bodyless DELETE retains its wire/signing contract. Independent lanes were integrated. Validation was exact-source/diff and test-source inspection only: no PR checkout, build, test execution, or live workflow. Unrelated rebase changes, separate community moderation as a whole, and mobile/web operator interfaces were excluded.