Stratum Care — mock launcher Demo scaffolding
Theme
Text

This page is demo scaffolding. It is not a screen the product ships.

It exists so a reviewer can reach every plane and vertical from one place. The product itself must never offer this. A care user belongs to exactly one agency and one vertical (SCR-114), each vertical is its own deployment (SCR-116), and the cross-vertical and care→ops links that once existed in the mocks were deliberately removed — 155 files lost their agency <select> and 54 “Operations” anchors were reverted.

So this file sits above care/, platform/ and mobile/ and belongs to none of them. It wears no app chrome and carries no agency selector of any kind — the selector is the control it replaces.

Care plane — the three verticals

Three separate deployments (SCR-116). Crossing between them is crossing services, which is why only this page does it.
RVPPEC Rio Vista Pediatric Centre · PPEC · Rio Grande Valley, TX Prescribed pediatric extended care — the centre’s day board, transport runs, authorizations and claims. Its index catalogues the whole PPEC set. care/ppec-index.html care planeno roster row reaches it MCALR Millbrook Cove · Assisted living · Boulder County, CO Colorado assisted living residence — the daily loop, clinical record, facility compliance, portfolio and the resident portal. Its index catalogues the whole ALR programme. care/alr-index.html care plane2 roster rows MVHCBS Mesa Verde Home Care · HCBS · CO · TX · CA Home and community-based services — authorizations, EVV, claims, credentials, and the client / representative / lay-employer portals. Its index catalogues the whole HCBS set. care/hcbs-index.html care plane17 roster rows

The kernel screens

Not a fourth vertical.
KMy Work — the kernel door Millbrook Cove · Home Care Agency The signed-in user’s landing surface. Chosen as the door because it is the one base-wave screen whose subject is what you have to do rather than one function — and it carries the same nav spine as the rest, so billing, admin, entity, documents, reporting and the audit viewer are all one click on from here. care/my-work.html kernelmetadata-driven
Why these are not a vertical. The base-wave care/ screens — billing, admin, documents, scheduling, entity, integrations, reporting — are the kernel, not a fourth programme. RENDER-MANIFEST.md § “The generic-engine judgment” records the app’s functional core as “metadata-driven generic screens (Summary/list, Detail/edit, Create via RJSF) parameterized at runtime by app/module/entity”, rendered once as representative named screens rather than exploded per entity. That is the kernel-vs-packs split SCR-116 deploys: one kernel, three vertical packs on top of it.

Count, stated as mine and not the manifest’s: 69 care/*.html files carry no alr-, ppec- or hcbs- prefix. They have no index of their own; my-work.html’s nav tree is the closest thing to one, which is the second reason it is the door.

Platform / ops plane

The elevated realm. Different chrome, on purpose.
OPSTenant roster (CP-03) Platform operations · cross-tenant This is where an operator legitimately sees every tenant — the one plane on which cross-tenant scope is correct rather than a leak. Its rows now link into the care apps, so the roster is the product’s own route from ops into a tenant’s vertical. platform/cp-03-tenant-list.html cross-tenant19 rows link into care CPOperator sign-in (CP-01) Platform operations · the operator’s front door The ops plane’s own entry, linked here because a reviewer wanting the control plane wants its door as well as its roster. platform/cp-01-provider-login.html ops plane
The roster does not reach PPEC, and this page is the practical way in. I counted cp-03-tenant-list.html’s outbound care links: 17 go to hcbs-index.html, 2 go to alr-index.html, and 0 go to PPEC. There is no vertical column on the roster and no row names a pediatric service. One inbound anchor to PPEC does exist elsewhere in the corpus — hcbs-index.html carries a “The PPEC set, for comparison” button — but that is a reviewer’s comparison affordance on an index page, not a route a user of the product has. Until the owner rules on a recast of the roster, this launcher is the only direct way to PPEC.

Mobile

Two delivered artifacts, not one.
SFstratum-field — first launch Phone, 390×812 · a caregiver’s own or issued handset Activation: the invitation carries the endpoint, so the app learns which care deployment it belongs to before anyone signs in. Start here to see the phone from the beginning. mobile/activate.html delivered artifactstratum-field SFstratum-field — Today Phone, 390×812 · the caregiver’s landing surface The day’s visits as a card feed — the phone app’s home once it is activated and signed in. The natural entry if you want the app in use rather than in setup. mobile/today.html delivered artifactstratum-field SCstratum-cart — med-pass round Landscape cart tablet, 1180×800 · Millbrook Cove, second floor east wing The ALR cart tablet — a shared, institution-owned station on a med cart, not a shrunk phone. The round is its first screen; see the note below for why there is no sign-in to send you to instead. mobile/alr-med-pass.html delivered artifactstratum-cart
Why two artifacts, and why the cart has no door. The phone and the cart run on devices with different owners and therefore incompatible session models — a personal handset against a shared station where an unlocked station is the normal case. The cart’s seven routes are all clinical: there is no /login and no /activate on it, which the design pass records as its own defect (D-25) and routes as WL-9067 (station activation) and WL-9068 (shared-device shift sign-in). Nothing is minted here to fill that gap: the round is linked because it is the entry that exists.

What the screens actually say about who the tenants are

Every name above is quoted from the linked screen’s own agency-identity chip. They do not divide one agency per vertical, and this page does not tidy them up.
Millbrook Cove wears two different subtitles across those four screens alone — an assisted living residence in Boulder County on one, a home care agency on another. Whether the cast should be recast so each vertical has its own tenant is a decision in front of the owner right now, and pre-empting it by inventing a clean one-agency-per-vertical set here would be minting (I-9). So the launcher shows the corpus as it is.

Not in RENDER-MANIFEST.md, deliberately. The manifest says “if a screen is not here it does not get rendered”, and it has no convention for declaring something that is not a screen. This page follows the precedent of the three shared shells (care/_hcbs-shell-web.html, mobile/_hcbs-shell-mobile.html, platform/_hcbs-shell-ops.html), each of which sits in the tree undeclared and states on its own face “Not a screen — it discharges no obligation.” Neither does this one. A convention for declaring non-screens is owed and is not invented here.

Every link on this page was checked to resolve to a file that exists; nothing is linked that does not. Synthetic data only — no PHI.