2026-09-12. C is the chosen direction; C1/C2/C3 remain under review. Throwaway, development-only UI. No production API calls or server configuration changes. Existing V1, V2 and V3 prototypes are retained.

Run

From frontend/, run npm run prototype:context-shelf.

The URL keys A/B/C identify the three descendants of C in this new review, not the old context-bar/context-rail/context-shelf alternatives. Switch in the bottom review bar without reloading, or with arrow keys outside interactive controls.

What this iteration compares

All variants have one collapsible panel at the top of the entire ThothII app. The panel is collapsed when valid selections have been resolved, but opens when the required context is incomplete. A visible summary always identifies workspace and interaction model. Opening the panel reveals both selectors and their origins.

Proposal	Top panel	Session rail
C1: Compact strip	A compact workspace/model summary; two side-by-side selectors when expanded	Administration precedes the session tabs, closest to the previous navigation order
C2: Context ribbon	Separate labelled workspace/model areas aligned with the expanded fields	Sessions first, with compact divided rows; administration below
C3: Workspace heading	Workspace is the main heading, model a secondary read-only label; expanded panel has explanation beside stacked fields	Sessions first, with individually bounded rows and administration below

On narrow containers, fields stack and sessions/navigation expand inline above the main content. The illustrative left navigation belongs to Omics Portal, not to the ThothII application. Warm surfaces, Manrope controls, Fraunces headings and the red portal frame continue the prior Impeccable direction.

Session management restored to the right rail

Remove the central “Continue where you left off” area and its separate session navigation link. Access sessions from the right rail in every proposal.
Restore My sessions / All sessions tabs, with an explicit selected tab and keyboard Left/Right/Home/End navigation. Search and paused/archived groupings are represented with synthetic records.
All sessions is an authorized administrator view, not a cross-workspace selector. Both tabs use the globally selected workspace. The administrator fixture adds a colleague-owned archived record; the analyst fixture hides All sessions and administration. Actual production permissions remain backend-owned.
Resume stays behind a review of the session's original workspace/revision and the globally selected model. Genuine archives remain read-only pending the already-asked archive/restoration clarification.
This is a layout study, not authorization to remove original session grouping, rename, archive, bulk operations or other existing behavior from production. Those must be retained and verified in the eventual implementation.

Default and last-choice audit

The concepts already exist in current code, but in different places:

Value	Existing source	Finding
Installation workspace default	`Settings.workspace`, read from `SETTINGS_FILE`, normally `backend/data/settings.json` in local development	The inspected local file has `workspace: "psd"`. It is not a newly introduced YAML field.
Session model default	`modelCatalog.defaults.session` in the installation YAML	The PSD configuration has `zai/glm-5.3`.
Metadata model default	`modelCatalog.defaults.metadataGeneration` in the same YAML	The PSD configuration also has `zai/glm-5.3`; the schema allows the two defaults to differ.
Last personal choice	`frontend/src/workspaces/preferences.ts`	Currently module-level memory only, not durable browser storage. A page reload loses it.

Evidence: backend/src/settings/settings-store.ts, backend/src/routes/settings.ts, backend/src/app.ts (settings resolution), backend/src/config.ts (file location), frontend/src/shell/SteerInput.tsx, frontend/src/workspaces/preferences.ts, tools/tht/internal/config/model_catalog.go, and deploy/psd/thothii-installation.yaml.

The backend currently falls back to the first active registry workspace when the settings file has no workspace. The frontend validates the returned workspace against selectable revisions. This fallback is not an explicitly authored default in the workspace repository. V4 does not invent a new YAML field or modify this production behavior; its fixtures represent an explicit configured default.

The actual deployed settings and registry were not inspected. The local value psd must not be confused with the synthetic prototype ID psd-clinical.

For the unified model preference, V4 represents the existing common PSD default. If session and metadata defaults diverge in another installation, the production spec must choose a single initial interaction preference explicitly; it must not silently switch to a second model on entering administration. Eligibility gates from V3 continue to prevent unsupported metadata AI operations.

Requested resolution rule

Resolve workspace and model independently:

Use that field's last explicit user choice, if present.
Otherwise use its installation default.
Validate the resolved ID. If a remembered choice is unavailable, leave that field unselected, explain the problem and open the panel. Do not silently select a different workspace or model.

Defaults populate the selectors, so valid defaults satisfy the required-context gate without an extra confirmation. Resolving a default does not mark it as an explicit user choice. Changing just the model does not freeze the default workspace as a remembered choice. Cancelling a dirty-workspace transition does not persist it. An explicit confirmed resume adopts and remembers the session's workspace; the global model remains independent. Page-history navigation does not restore an obsolete workspace selection. Last-choice/default resolution takes precedence over a stale workspace query parameter on a fresh visit.

Prototype-only persistence

Only selected identifiers are persisted, using localStorage key thothii:prototype:context-shelf-v4:demo-user. It is separate from production keys and shared by these three variants on port 5177. Reload or reopening the same browser restores the choices. There is no cross-device or authenticated-user profile synchronization. No secrets, records or clinical data are stored.

The review bar exposes Forget saved choices, which removes only this prototype's key and reloads with defaults. If browser storage is unavailable, selections work for the current visit and the UI reports that they could not be remembered. Drafts, record edits and the simulated operation remain ephemeral.

Production persistence must be scoped to installation and authenticated user; the fixed demo-user key is not a production storage design. It must not update shared server installation defaults with a person's choices.

Retained operation rule

Exactly one core or administrative operation at a time. Both selectors and all other operation starts are disabled until the running operation completes, stops or fails. Browsing another page does not release this lock. This prototype does not implement backend exclusion, reconnect recovery or persistent running jobs.

Verification

Isolated strict TypeScript check and whitespace check passed.
C1/C2/C3: first visit resolves configured defaults without saving them as user choices; model-only choice retains independent workspace default; reload restores the last model and workspace; source labels reflect the correct precedence.
C1/C2/C3: session tabs, owner filtering, keyboard tab navigation, removal of the former central recent-sessions area, and operation locking/unlocking verified.
Additional checks: unavailable saved workspace fails closed; rejected context change preserves draft and storage; forgetting choices restores defaults; analyst fixture hides All sessions and administration.
96 Chromium layout checks: 3 variants, 4 viewport widths (1600/1280/960/390), open/closed panel plus core and all five administrative pages. No root overflow or runtime errors; page and rail containment checked on the content pages.
390 px embedded host inside a 1600 px browser also checked, with a 368 px main region and no host overflow. Desktop and mobile screenshots visually reviewed.
No physical-device, Safari/WebKit, real Omics/Bootstrap or deployed-server acceptance is claimed. Core and administrative actions use synthetic fixtures.

Next: choose the V4 arrangement, resolve any outstanding domain questions, then continue the agreed to-spec / to-tickets process on Gitea. No new implementation agents or tickets were started during this prototype review. Final integration remains on the server, not the local Omics Portal checkout.