This entry covers work after yesterday’s report, from the evening of September 9 through today’s completed staging deployment. The focus was navigation: knowing where you are, keeping the same menu across pages, and returning to the system you started configuring.
One consistent menu
We audited all 85 full-page application templates and replaced separate page menus with the shared dashboard header across the authenticated interface. Authentication and recovery screens keep their appropriate minimal layouts. The same user now sees the same ordered main destinations across workspaces, subject to their permissions.
The Hashmedo logo is a blue, rounded dashboard button with white text. Duplicate Dashboard menu entries were removed. Page actions belong beside their content: Create System sits with the systems list, while New causal model and Start analysis remain in the causal workspace. Object Definitions belongs to Inventory, rather than Settings.
The first tablet-dropdown implementation introduced a regression: desktop navigation became vertical. We corrected it so desktop retains its horizontal structure and touch/tablet layouts use the compact presentation. Opening a menu does not push the page content down. Responsive browser checks passed; physical iPad testing remains separate.
Context should come from the page’s identity
Previously, some pages inferred their context from a heading or a back link. That allowed guide text or an upgrade card to become the apparent workspace. We replaced that inference on 75 pages with explicit page declarations, while keeping existing handler-built system, model and component trails authoritative.
Dashboard identifies Dashboard. Mailbox identifies Mailbox, and a conversation adds its subject. Editors and result pages identify their actual record or workflow. A page’s administrative permission requirement does not turn its business context into Settings.
Tabs for the workspace you are using
Systems, models and components now share the same rendering approach for their existing section tabs. Configuration workspaces use their own Draft, Versions/reviews and Environments sections. Parent objects remain in the context trail instead of adding another complete row of ancestor tabs.
The same approach now covers 31 additional templates across Cost Center, reports, integrations, user administration, operator pages and causal workflows. Scoped subjects, selected versions and permission restrictions are retained.
Section selection follows deep links, refresh and browser Back/Forward. Moving between anchors does not reload the document or clear draft fields. In-place updates retain valid sections and fall back appropriately when a section is no longer available. Creation, publication, clone and export actions stay with their relevant content.
Readiness profiles and lifecycle configuration also retain their originating system or model through editing, preview, saves and redirects. Readiness remains an operational workflow.
Keeping the entire configuration journey
A later test exposed a deeper problem. Moving from a system to its model and then opening transitions configuration still lost the original system. Keeping only the immediate parent was insufficient.
We audited the shared mechanism and generalized it across configuration workflows. The existing context bar now preserves paths such as:
- System → Model → Transitions
- System → Model → Component → Configuration
- System → Model → LLM workspace → API clients
- System → Model → Readiness profiles → Selected profile version
The journey survives saves, redirects, search/filter submissions, refresh and new tabs. Clicking an ancestor returns directly to that point in the chain. Entering through the global menu starts a fresh context instead of inheriting an unrelated previous workspace.
The carried context is authenticated, encrypted and scoped to the current user and organization. Entity relationships are checked through existing authorized reads. Navigation metadata does not grant access or replace permission checks. This reuses the existing context bar rather than adding another navigation widget.
On deployed staging, we opened an existing sample system, followed its model to Manage available transitions, refreshed the page, and returned directly to the original system. All three context steps remained visible. No tenant records were created or changed for that acceptance check.
Current organization access
The cell’s shared menu now uses current membership and lifecycle/causal permissions. Restricted destinations remain hidden without their required grants.
We also updated the staging gateway to refresh memberships from Cell Control before forwarding application requests and handling organization selection. The organization-switch option can therefore reflect invitations and removals rather than retaining only the membership snapshot from login.
A removed selection is cleared. Reads go to organization selection or recovery; pending writes receive an access error and are never redirected into another organization. Membership-service failure blocks forwarding, and a concurrent refresh cannot recreate a logged-out session.
Automated tests cover membership changes, revoked choices, interrupted writes, service failures and logout races. Live authenticated invitation/removal permutations remain a separate acceptance task.
What we learned about login
We investigated the reported previous-email behavior and apparent double login. A real staging gateway/Keycloak session test switched between two disposable accounts and back again. Each callback showed the expected account, and login after logout offered an empty editable email field.
The two-screen sign-in sequence comes from Keycloak’s Organization Identity-First flow: email selection followed by password entry, rather than two completed authentications. We committed clearer “Use another account” wording for the native account-switch action in six theme languages, but did not redeploy the identity service in this rollout.
This does not establish that the original browser-specific problem is fixed. Existing tabs, saved-password autofill and logout from an established tenant application session still need further investigation.
Verification and releases
The acceptance inventory covers all 85 full-page templates. A new matrix renders 46 templates in 445 combinations, with 460 page/profile/viewport checks within its browser tests. It includes owner, administrator, member, Viewer and local-administrator menu profiles, six model types, eight component types and configuration capability variants. These dimensions describe coverage; they are not additional independent test-suite totals or proof that every role can access every page.
The audit also fixed headers nested inside content on nine templates, removed an invalid nested logout form, added a missing mobile viewport declaration on Rules, and kept access/service recovery pages independent of failing tenant navigation lookups.
Four Cell-1 releases were delivered after the previous report:
| Release | Main work | Passing browser tests |
|---|---|---|
| 20260909.2 | Tablet navigation, dashboard button and page-action placement | 419 |
| 20260909.3 | Shared menu, explicit context and corrected desktop layout | 449 |
| 20260910.1 | Workspace tabs, permissions, acceptance matrix and paired staging gateway update | 513 |
| 20260910.2 | Generalized navigation journeys | 519 |
These are successive regression-suite results, not counts to add together. The latest release, 20260910.2 / v1.1.0-rc100, passed 519 browser tests with 63 approved optional skips and zero failures. Verification also covered Go, database integration, recovery, scaling, controller and sample-workspace checks. No new database migrations were needed.
During final deployment verification, the worker was still on its previous image. The independent identity check caught the mismatch. We explicitly updated the worker, verified that app and worker were healthy on the same immutable image, and repeated the final encrypted backup after alignment. Verification email, backup health and public readiness checks passed before the old serving slot was retired.
The staging gateway was updated with the paired release. CellPro’s application and worker, and the production application environment, were not deployed.
Next checks
We will complete live organization-membership change acceptance, continue the existing-browser login investigation, and verify Object Definitions and deeper configuration permutations. The installed controller’s worker-update behavior also needs reconciliation with the current packaged implementation.
Wider CellPro rollout, production promotion and tenant-recovery planning remain separate work. This progress improves the shared navigation foundation; it is not a claim that every workflow and permission combination has been exhaustively tested.