Files

Context shelf review V4

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.

Core restoration, 2026-09-12

The user rejected the unsolicited Core redesign. The review scope is Administration and the global workspace/model shelf only. All three options now keep the same original Core layout:

  • Original F1–F8 circular workflow indicators and processing timer at the top.
  • Original Model activity log opening on the left. At desktop widths it replaces the right session rail while open; closing it restores the rail. Narrow widths use the existing drawer.
  • Original question heading, central response/review widgets and bottom-pinned composer.
  • No replacement hero, four-phase workflow excerpt, artifact tabs, or parallel review column.
  • Workspace/model selection exists only in the global shelf. Thinking and context usage remain in the composer footer; this correction does not redesign those Core controls.

OriginalCorePreview.tsx directly reuses the production WorkflowBar, ModelActivityPanel, CentralStatus, SelectWidget, FreetextWidget and src/index.css. Its local composer callbacks simulate interaction without API calls. A React portal into a prototype-only iframe isolates the original styles from the experimental host styles. This iframe is not a proposed production architecture, and no production Core component was changed by this restoration.

To inspect the response state, type a synthetic question, send it, then choose Demo: finish. Open the arrow beside the phase dots to inspect the log. Switching A/B/C preserves the same Core surface; only the surrounding context/navigation proposal changes.

Verified interactively: new question, operation lock, response widget, activity open/close, all three variants, and 390-pixel host layout. The prototype entry point typechecks independently. Earlier designs remain recoverable in the prototype branch history, including V4 at 41b9fed4.

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:

  1. Use that field's last explicit user choice, if present.
  2. Otherwise use its installation default.
  3. 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.