Design Secure Interface Doors for terminal browser editor and agent workspace UX

[mdheller]

Context

SourceOS Agent Machine needs user-facing secure interface doors for local terminal, browser, and code editor workflows without collapsing the host into the agent runtime.

This repo is the SourceOS shell product/runtime home, while sourceos-spec owns contracts and sourceos-devtools owns the local broker engine. The shell layer should define the UX posture and runtime surface, not the low-level Podman implementation.

Scope

Add a design note for SourceOS shell secure interface doors:

• Terminal Door: operator attach, transcript, redaction, and distinction between operator attach and agent execution.
• Browser Door: isolated browser session, browser automation evidence, and host profile denial by default.
• Editor Door: VS Code / editor launch surface, repo-scoped editing, task/test handoff, and evidence cues.
• Agent Tool Door: OpenCLAW/OpenClaw, Hermes, Codex, Claude Code, local shell, GitHub/CI bots as governed tool surfaces.

Requirements

• Align with SecureHostInterfaceProfile and HostInterfaceGrant once those schemas land in sourceos-spec.
• Treat SourceOS shell as the user-visible control surface, not as the authority for agent grants.
• Keep Agent Registry as authority for non-human participants.
• Keep AgentPlane as governed execution/evidence lane.
• Preserve the repo's current PDF-first implementation boundary; this can be a design + future slice until broader shell UX is unlocked.

Acceptance criteria

• Docs explain the four-door model and route each door to its implementation owner.
• Security posture is explicit: deny-by-default, no raw host secrets, no raw host browser profile sharing.
• Evidence requirements are visible in UX language.
• No Podman engine implementation added here.

Non-goals

• Do not implement the broker here.
• Do not implement VS Code/browser extensions here.
• Do not move sourceos-spec contracts into this repo.
• Do not expand beyond docs/design while PDF-first runtime scope remains the active implementation lane.