browser_session is sealed in api.v1 but NOT implemented in the 0.12 core — no runtime profile; capability regressed in prod at the 0.12 cutover

[DmitriyG228]

Where we are (hosted production on v0.12.14 hc11; owner-reported, root cause pinned)

The 0.10 dashboard starts a browser session by POSTing /bots with body {"mode": "browser_session"} — no platform, no meeting_url (a browser session has neither; 0.10 meeting-api synthesized them). Source: 0.10.6 services/dashboard/src/app/meetings/page.tsx:104-121.

Since the #792/#794 intake hardening (v0.12.13+), POST /bots unconditionally requires platform + (native_meeting_id | meeting_url) — reproduced live on prod: the dashboard's shape gets 422 'platform' and 'native_meeting_id' (or 'meeting_url') are required. Browser sessions cannot be created from the dashboard at all.

The #794 fix was right for meetings (it kills orphan rows); it just never carved out the session mode that legitimately has no meeting address. browser_session rows exist in prod data (e.g. meeting 24311, a customer's 2.6h session from 07-18, created on 0.10) — the capability is real and in use.

Prepared solution + forks

• Core: intake accepts a browser-session request as a first-class shape (e.g. platform: browser_session or mode: browser_session, no URL required; server mints the session identity as 0.10 did) — typed 422 stays for actual meetings.
• Client boundary (hosted-compat or the Deprecated dashboard: give it a bounded, off-by-default home in the stack (SoC) while it is still load-bearing #813 dashboard profile): translate the dashboard's legacy {mode: browser_session} body to the core shape — 'core owns its contracts; clients adapt'.
• Likely both: core gains the honest shape; the compat seam maps the legacy body onto it.

Acceptance

• Dashboard 'Start browser session' produces a running session (noVNC reachable) on the 0.12 core — human-witnessed.
• API-level: the browser-session create shape documented + 201 with a stable session address; meetings without URL/id still 422 (negative control — fix(meeting-api): POST /bots derives native_meeting_id from meeting_url or refuses typed 422 — no more orphan meetings (#792) #794's guarantee intact).
• CI: compose stack-test leg creating a browser_session via the API (autonomously testable, same class as vexa#815's webhook leg).

Origin: owner report → prod repro → 0.10 dashboard source trace.

[DmitriyG228]

Owner ruling on fix direction (2026-07-19): core defines the contract; the dashboard adapts. Drop the 'compat seam translates the legacy {mode: browser_session} body' fork from the prepared solution — we will NOT teach core or gateway the deprecated dashboard's conventions. The fix is: (1) core's intake gains an honest, architecture-native browser-session create shape (designed from principles — sessions have no meeting address, so the contract says so explicitly); (2) the dashboard is fixed to speak that shape (its browser-session POST body changes), as part of the bounded dashboard work in #813. Same ruling applies to the authenticated-session path (#790 testing): dashboard adapts to core, never the reverse.

[DmitriyG228]

Correction + a bigger finding: this is not a #794 regression — browser sessions are not implemented in the 0.12 core at all

I traced it properly instead of trusting my first read. Retracting my earlier framing ("regressed by the #794 intake"): #794 only made the absence visible as a typed 422.

What actually exists in 0.12:

• api.v1 seals browser_session into the Platform enum, with native_meeting_id and meeting_url both optional — so POST /bots {"platform":"browser_session"} is a contractually valid request.
• lifecycle/stop_router.py:69 accepts the platform; the concurrency cap explicitly excludes it as infra (bot_spawn/adapters.py:243,399).
• But the runtime kernel registers exactly two profiles — meeting-bot and agent. There is no browser-session profile, no spawn path, no invocation shape (invocation.py hardcodes profile="meeting-bot" and its schema requires meetingUrl).

So the contract advertises a capability the implementation cannot serve. I confirmed this by fixing intake locally (mint bs-<hex>, as 0.10 did) — the request then gets past the guard and dies deeper in the invocation builder with 'meetingUrl' is a required property.

Production impact — a real capability regression, and I own it

Browser sessions worked on 0.10 and stopped working when I cut prod over to 0.12. Evidence: meeting 24311 is a customer's (michael@roadworthy.co.uk) 2.6-hour browser session on 2026-07-18 19:39, hours before the cutover; the 0.10 core minted bs-720ec335 and ran a browser-session-24311-… workload. Post-cutover, the same request is a 422. Three sessions exist in prod history (24311, 23196, 23116), all 0.10-era.

Why I am NOT shipping the intake fix alone

It would convert a clean, typed 422 into a confusing 500 from the invocation builder — strictly worse for callers. The intake change is correct and belongs to the eventual implementation, not to a standalone PR.

What this actually needs (product decision + real work)

The building blocks exist: core/meetings/modules/remote-browser already carries persistent-context launch (VNC/CDP), session persistence and logged-in validation. Missing is the runtime browser-session profile + its spawn/invocation path + lifecycle. Two honest options:

1. Implement it — restore the capability the contract promises (and that a paying customer used two days ago).
2. Remove browser_session from the sealed api.v1 Platform enum and document the drop — the contract stops lying, but a customer workflow ends.

This is a scope call, not something to guess at. Related: the authenticated-session path (#790) rides the same module, and the dashboard's entry point is in vexa-platform#813/#74.

[DmitriyG228]

Restore map (mechanism reconstructed from the working v0.10.7 implementation; corrects two earlier wrong framings — this was neither "never implemented" nor retire-able: ~30 external users, 68 completed sessions, worked through 2026-07-15).

How 0.10 worked: dashboard posts mode: browser_session → meeting-api mints session_token + bs-<hex> id, row ACTIVE immediately, per-user S3 prefix users/{uid}/browser-userdata → runtime profile browser-session (image ${BROWSER_IMAGE}, ports 6080/9223, idle_timeout 0) → pod runs x11vnc+websockify+noVNC + a persistent Chromium with 60s auto-save to S3 → human reaches it via nine gateway /b/{token} routes (VNC by token unguessability, CDP by API-key+ownership) → DELETE /bots/browser_session/{id} with zero stop delay.

0.12 gaps (minimal restore, ordered):

1. runtime profile browser-session (runtime_kernel/profiles.py — profile is an open string in runtime.v1, no seal impact) — S
2. bot entrypoint mode switch: VNC stack (image already ships it; escalation.ts:85-98 starts it) + run provisionLogin from the already-carved @vexa/remote-browser instead of the join worker — M
3. intake + spawn branch around build_invocation (the WIP fix/816-browser-session-intake is the right seam for the intake half; must not touch invocation.v1) — M
4. address discovery: kernel.py:197 always emits ports={} — populate from the backend, or a status lookup meeting-api polls as 0.10 did — M
5. gateway /b/{token} routes ported from api-gateway/main.py:1736-2088, preserving the split auth model; reclassify the mislabeled owned_elsewhere /b row in KNOWN_GAPS.json — L
6. per-user userdata prefix (also fixes today's BOT_AUTHENTICATED one-bot-per-deployment serialization at service.py:247-255) — M
7. save-then-stop completion — S

Validation: everything except the actual Google login is hermetic (localStorage-marker roundtrip over CDP substitutes for a login: write → save → destroy → recreate → read back). The login leg + the authenticated-join payoff need one operator session + one solo meeting.

Landed now (v0.12.15, PR #829): the gap tells the truth — typed 422 at intake (no more 500+orphaned row), join layer refuses unknown platforms. Target for the restoration: v0.12.16. The dashboard profile (#813/PR #828) is the UI leg this flow will be walked through.

[DmitriyG228]

Witness-walk observation (v0.12.15, prod, owner): the dashboard's browser-session button fails as expected (known-open for this release) — but with the WRONG error. The user sees the generic

'platform' and 'native_meeting_id' (or 'meeting_url') are required

not #829's typed refusal pointing here. Cause, confirmed against v0.10.7: the 0.10 dashboard posts {mode: "browser_session"} with no platform field (join-modal.tsx:223), so the required-fields guard fires before the SPAWNABLE_PLATFORMS guard ever sees a platform string. #829's refusal is reachable only by API callers who send platform: browser_session explicitly.

Consequence for the restoration plan: the intake item must decide where the 0.10 mode field is translated. Per the core-owns-contracts rule the core should keep expressing this via the sealed Platform enum, and the CLIENT adapts — i.e. the dashboard (or the hosted-compat edge, as an interim carry) maps mode: browser_session → platform: browser_session at the boundary. Until then, even the honest refusal is invisible to the one surface users actually click.

Filed from the walk; the receipt records the #790/#816 row as known-open with this message-quality note attached.