Neural Labs v0.3.2 release record

• Release date: 2026-09-03
• Version transition: 0.3.1 → 0.3.2
• Release type: patch version jump
• Theme: immediate account feedback and quieter Alshival conversations

Release intent

This patch makes successful passkey registration visible immediately. The control plane already committed the passkey and returned its safe public record, but Personalization relied on one local state append and did not reconcile the list afterward. In the affected UI path, the enrollment form continued to look unchanged until a full browser refresh loaded the stored credential again.

v0.3.2 treats the registration response as an immediate optimistic update and then refreshes the authoritative account list. It also synchronizes multiple Personalization views within the current desktop and displays the exact local creation date and time returned by the server.

The same patch cleans up Alshival's conversation lifecycle. A dedicated animated state now covers private-session creation and subscription, while routine Gateway status frames stay out of the work transcript. Explicit progress commentary is retained, but it is grouped into the collapsed Work details card so the main chat reads as the user's prompt followed by Alshival's final answer.

User experience

After the browser or operating-system WebAuthn ceremony completes:

1. the new passkey row appears without reloading Settings;
2. the row shows its label, backup/device type, and localized creation date and time;
3. the enrollment controls change from Create a passkey to Add another passkey; and
4. Neural Labs performs a no-cache GET of the signed-in user's passkey list to confirm server state.

Creation and removal emit a browser-local account-change event. If the same desktop has more than one Settings window mounted, every Personalization panel refreshes from the account API. This is intentionally lighter than a new server WebSocket: the initiating browser already receives the committed record in the mutation response, and the follow-up account read provides authoritative state.

If that follow-up read temporarily fails, Neural Labs keeps the passkey record returned by the successful registration instead of falsely reverting to an empty list. A later account-change event or Settings mount performs another authoritative refresh.

Alshival startup and transcript behavior

Starting a private chat now transitions through one continuous readiness experience:

1. Starting a new chat is shown while OpenClaw creates the private session;
2. Getting Alshival ready is shown while Neural Labs subscribes to that exact session and loads its recent context; and
3. the empty conversation and enabled composer appear only after the live subscription and history reconciliation complete.

The loader uses the existing paper-and-spectrum visual language and respects the operating system's reduced-motion setting. The toolbar mirrors the current creation or synchronization state, and the previous conversation composer is temporarily hidden while a new chat is being created so input cannot target the wrong session.

During a run, transport status such as starting_model still establishes the active run ID and keeps steering and FIFO queue controls accurate. It no longer creates a synthetic thinking step. Meaningful plans, commands, tools, file operations, and safe progress commentary remain available in the compact timeline.

OpenClaw assistant messages explicitly marked with the commentary phase are projected as completed Progress update activities. The same projection is applied to live session.message commits and to chat.history, so refreshing the app does not turn prior progress narration back into full chat bubbles. When the final answer arrives, the accumulated activities attach to that answer under a collapsed Work details card.

For compatibility with older or unphased projections, assistant text is also folded after a later tool, plan, or assistant answer proves that text was an intermediate preamble. Durable consecutive assistant output within one user turn keeps the last textual answer visible and moves earlier text into the same work card. This avoids guessing before evidence exists while still cleaning up older transcripts.

Data and security review

• The control-plane API and PostgreSQL schema are unchanged.
• The browser-local event contains no payload; listeners independently read the current account through the existing authenticated, no-cache endpoint.
• The visible timestamp is the existing createdAt public field. It is not generated from WebAuthn credential data in the browser.
• The authenticator private key never enters Neural Labs. Public credential storage, one-use challenges, user verification, origin/RP binding, and CSRF enforcement are unchanged.
• No credential ID, public key, challenge, transaction token, tenant state, deployment address, new route, new port, or new container permission is added to the repository or desktop event.
• This patch does not change the passkey trust boundary documented by ADR 0014, so no new architecture decision record is required.
• The Alshival changes use the existing authenticated Gateway WebSocket and do not add a route, listener, scope, agent permission, or credential flow.
• Progress text comes from OpenClaw's explicit display-safe commentary phase or from visible assistant text later superseded within the same turn. Raw reasoning blocks remain replaced by a generic label rather than exposed.

Validation coverage

The passkey UI regression test now verifies all of the following in one successful enrollment flow:

• both ceremony requests still carry the session CSRF token;
• the browser WebAuthn registration function is invoked once;
• the new row is visible immediately;
• the row identifies a synced passkey;
• the localized creation date and time are rendered;
• the authoritative passkey endpoint is read again after registration; and
• the form switches to Add passkey after the first credential appears.

The standard make validate gate continues to cover the desktop TypeScript build, all desktop tests, control-plane passkey verification tests, database integration coverage when configured, production bundles, repository boundary checks, documentation links, shell syntax, and Compose rendering.

Alshival regression coverage additionally verifies that:

• the startup loader spans both session creation and live subscription;
• the composer appears only after history synchronization;
• routine status frames do not add a synthetic work step;
• live commentary never becomes a standalone assistant bubble;
• commentary attaches to the final answer's collapsed work details; and
• durable commentary is reconstructed the same way after history reload.

Deployment and rollback

No database or persistent-state migration is needed. Rebuild and recreate the workspace service so the new desktop bundle is served. Existing passkeys, accounts, sessions, personal OpenAI state, files, skill drafts, and code-server data remain in their existing stores.

To roll back, deploy the prior reviewed workspace image and recreate the workspace service. Passkeys created while v0.3.2 is active remain valid because the database and WebAuthn verification formats are unchanged. The prior UI may again require a manual refresh after enrollment, but no passkey data needs to be removed or transformed.