Repository navigation
Docs: F37 — the viewer's Environments in the shell, answered by the gateway with the person's own token (direction decided, DEV-6639) - #149
Conversation
…e gateway The rail of every app should show the Environments of the person at the browser. The proposal keeps shell.json per Environment and adds /.lazurio/account.json, answered by the Environment's gateway with the person's own Keycloak token, which never reaches the Launchpad, an app or a Task Agent. Variants, failure modes, open questions and delivery order. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
agentrozjedemeai
left a comment
There was a problem hiding this comment.
Exact-head QA: 78838b4. APPROVED as a proposal, not an implementation or a decision on the two open questions. Dashboard docs/workspace-composition.md §4.4/§7 requires the person's own Keycloak token for GET /api/environment/v1/environments and refuses an Environment credential for this list. F37 respects that boundary by keeping the token at the gateway and returning per-viewer data; it also leaves the F36 local shell document and fork slot intact. Machines#353 reserves account.json as 404 and proves the fork static/document route; the account response is correctly scoped to later work. The visibility of personal Environment names/addresses on a work/Team origin is acknowledged in the proposal and needs Matěj's explicit answer to question 2 before implementation; workstation custody likewise needs question 1 answered. This is not a blocker to reviewing an undecided proposal. Local public-policy tests 6/6; CI check jobs green. No merge/release performed.
…6-10-04) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
agentrozjedemeai
left a comment
There was a problem hiding this comment.
Exact-head re-review on f28ca6a: APPROVED as a decided direction/proposal, not implementation. Compared with the prior approved commit, the F37 proposal body is byte-identical; the merge preserved main's F36 addendum byte-identically and put F37 after it. Matěj's October 4 decision is explicit: first fork-slot publication without the list, workstation local-only for now, web-only rail, ordinary cross-Environment navigation, no single application for all Environments. Question 2 on personal-space visibility remains open and must be resolved before implementing it. In an isolated checkout, 6 publication-policy tests passed; Biome, tsc, publication guard and git diff --check passed. Both provider Platform checks passed on this head, with zero review threads. No merge performed.
agentrozjedemeai
left a comment
There was a problem hiding this comment.
@immakermatty Exact-head corrective re-review: APPROVED on 3a4f95b. This merge has parents f28ca6a (my earlier reviewed tree) and 0bd7776 (main after #150). The binary diff f28..3a4 is byte-identical to the #150 main diff 8fb019d..0bd777 after excluding the sole Git blob-index header difference for docs/decisions.md. All five changed paths and every patch hunk match; the F37 addition remains exactly the same 130 lines against the respective main parents. No conflict resolution or other content was introduced. In a fresh isolated clone at this SHA: six publication-policy tests passed, Biome lint, TypeScript typecheck, public publication guard (469 files), and git diff --check passed. Both macOS and Ubuntu Platform checks on this head completed successfully; zero review threads and no other reviewer requests. This approves the documentation direction/proposal only; personal-space visibility (F37 question 2) remains open before implementation. Previous review #5404859881 is already attached to this SHA but its body names f28; this review records the precise merge comparison to avoid that ambiguity. No merge or release performed.
Status: ready for review. Direction decided by Matěj on 2026-10-04: the layering stands; the first publication of the forks' slot ships without the list; a workstation stays local-only for now; the rail is for web Environments only; a jump to another Environment stays a plain navigation. Open question 2 (the personal space in a work zone) stays open. Branch updated with main (F36 addendum of 2026-10-04).
Why
Matěj asked on 2026-10-04 for foundations rather than a facade. The rail in Apps, Chat (T3 Code fork), Automate (MausBot fork) and module apps should show the Environments of the person signed in at the browser, wired properly through OAuth, so that the forks' slot never changes for it. F36 left exactly this as a facade.
What this proposes (F37, number taken at merge)
/.lazurio/shell.jsonstays per Environment (F36). A second document,/.lazurio/account.json, carries the viewer's spaces and Environments in the same entries.account.json, not the Launchpad. After the unchanged admission it takes the session's access token from its oauth2-proxy and proxies to the Dashboard'sGET /api/environment/v1/environments. The token never reaches the Launchpad, an app, a Task Agent or the browser. The response isno-store, privateand per viewer by construction, Team Environments included.lazurio-environmentswith the Dashboard's audience; the Dashboard accepts it for this one read-only GET./.lazurio/*through the gateway, so the forks' slot stays about 20 lines.It follows the rule already decided in the Dashboard's workspace composition §4.4/§7: the list is authorized only by the person's own token, never by an Environment credential.
Not changed
No code. The F36 contract and the forks' slot are untouched. The F36 shell rework on
claude/DEV-6639-shell-org-rail(another session) is independent; the library side of F37 comes as a follow-up after it.Open questions for Matěj
lazurio-environmentsin the operator's OS custody (recommended), or a local-only rail.Verification
bun testfor the docs tests: 32 pass.check:publicfails locally only because of the local.worktrees/directory, not this change.Follow-ups
Delivery order in the proposal: Dashboard endpoint → issuer scope (Machines realm) → Machines gateway route and proof → Platform contract and merge.
🤖 Generated with Claude Code