This document describes the active queue/runtime model only. Historical queue plans and execution queues live in the archive.
The active runtime is queue-first: work is submitted as queue messages, long-running work is polled back through responses or operation lookups, and workspace/session bootstrap data is read through platform clients rather than embedded in the UI.
The portal-side queue helpers live in app-runtime-shell.ts, landing-card-runtime.ts, and the platform/queue modules under apps/portal-web/src/platform/queue.
The current queue contract is built around three actions:
ingest submits a queue messageresponses fetches the follow-up response stream for a message idoperation looks up a long-running operation by idThose methods are implemented by queue-client.ts and used by the runtime shell in app-runtime-shell.ts.
Portal login sessions are initiated from the landing cards and, for queue-backed apps, a session token is requested through the queue rather than being invented locally.
That behavior currently applies to the active queue-backed portal cards in landing-model.ts and landing-card-runtime.ts.
The important policy to document here is not the literal timeout values themselves, but where the policy lives:
platform/queueapp-runtime-shell.tsThat separation is what lets the queue remain a platform service instead of becoming a UI-specific implementation detail.
The queue model is still split across several layers, so this doc should stay focused on the real flow rather than duplicating the implementation:
If those mechanics change, the documentation should change with the queue client and runtime shell first.