Share & approval pages — live render board

Does it render? Yes. A freshly minted worker share token resolves and shows the worker share card (name, description, trigger, “See files” flip, “Add to workspace”).
UI path to share a worker? No. There is no Share affordance anywhere in the workers UI. The components exist in code (ShareWorkerButton, ShareModal, api.workers.shareLink) but are not wired into the worker detail / list. The share link can only be minted via the API (POST /workers/<id>/share-link).

• Caveat A — wrapped, not full-screen: for the signed-in owner the share card renders inside the dashboard chrome (sidebar + Emily), not as a standalone page. (The approval route does render standalone — see card 04 — so this is an inconsistency.)
• Caveat B — recipient bounce: logged-out, /app/s/<token> and /app/w/<id> redirect to /app/login (see card 05). The “public” worker page is not publicly reachable on the cloud.
• Caveat C — tokens go stale: an earlier-minted token 404’d minutes later; re-minting fixed it.

Does it render? No — 404 “Page not found”. The API mints a run share token (POST /runs/<id>/share-link → entity_type: run), but the public resolver GET /s/<token> returns 404 “Share link not found” for run tokens, and the /s frontend page (StandaloneShareCard) only handles worker / brain_file / brain_pack — never run. So sharing a run is broken on both backend resolve and frontend render.
UI path to share a run? The Runs list has a “Share” button, but it is a stub — clicking it shows a toast “Sharing a run is coming soon (#765).” It does not mint a link.

Is there a UI path to share a file? Yes. The Library/Brain (/library, code in /contexts) has “Share this file” and “Share this folder” actions that copy a share link (api.contexts.shareFileLink / sharePackLink).
Does the shared file page render? No — 404. The mint returns entity_type: brain_file + URL, but GET /s/<token> returns 404 “Context file not found” (tested with a freshly created folder+file). So the file-share render is broken on the cloud (the public resolver can’t locate the minted file).

Does it render? Yes — genuinely full-screen (no sidebar, no Emily). Shows the Floom header, “All approvals” back link, the real pending approval (“Approve before sending” → “draft for Test Prospect Beta”), a comment / drop-image box, and Approve / Reject buttons.
Two entry modes: (1) authenticated owner, ?id=<id> → reviews your pending approval; (2) signed public link, ?id=<id>&token=<token> → login-free review (publicGet). No client method mints the public token — it comes from the backend public_link field (populated when an approval notification is sent), which was null here, so this is the authenticated-owner render.

The share routes are designed as public, no-login pages (root /s, /w in the OS). On the cloud (batch-b) the whole app is mounted under /app and the auth middleware gates /app/*, so a logged-out recipient opening a share link is redirected to /app/login. A worker/run/file share link sent to someone without a Floom account does not show the share — it shows sign-in.