Portal Runtime

This document describes the active portal runtime only. Historical planning, analysis, and archived snapshots live in the external documentation-archive tree.

Scope

The portal is the landing surface for the product and the control point for launching workspaces. The current implementation is centered on the manifest-driven card model in landing-model.ts, rendered by landing-card-builders.ts and bound by landing-card-runtime.ts.

What The Portal Does

The portal page:

• renders one card per active workspace/app from APPS
• handles browser autofill and saved credentials
• validates saved sessions where the card manifest requests it
• routes the user into the correct workspace with the correct query parameters
• shows deployment status, recent changes, and debug tooling around the shell

The page shell itself lives in index.html and landing.ts.

The active business-system login cards are:

• statistics
• debtors
• cashier_client
• creditors
• icapv

admin remains a control-plane card without portal login.

Card Model

Each portal card is now configured from a manifest on the app record in landing-model.ts. The manifest carries:

• badge state and badge text
• support copy
• login mode and login strategy
• default credential values
• whether a saved session should be validated on load
• whether an existing saved connection should be cleared on render
• session-tracking behavior
• workspace handoff rules and disabled-state text

That keeps the builder logic generic and makes future cards easier to clone without branching the renderer.

Session And Handoff

Saved connections are stored and revalidated by session-persistence.ts and landing-card-runtime.ts.

The current runtime still has two important behaviors to keep in mind:

• the manifest is the source of truth for whether a card is active, disabled, or under development
• landing.ts derives saved-session validation from the active card manifest so the portal can rehydrate the current session state quickly

That is the behavior the rebuilt docs should assume until the last boot-time coupling is removed.

Deployment And Status

The portal shows deployment state through deployment-edition.ts and the recent changes window through recent-changes.ts.

The deployment strip is global release state. The portal cards are per-app state. Those are related but not the same thing.

Debugging

Shared layout inspection is mounted through layout-debug-tools.ts and styled alongside the shell in layout-debug-tools-style.ts.

The inspector is part of the live portal shell now, so this document treats it as runtime behavior rather than a temporary test harness.