Studio OS

Problem

Personal and product work is spread across daily notes, project repositories, GitHub queues, and changing priorities. A useful operating system must bring that context together without giving an agent unlimited filesystem access, leaking private state into a public demo, or silently taking consequential actions.

My role

I designed the product model, visual system, local-first state layer, private context adapters, GitHub organization queue, agent safety boundaries, and deterministic verification workflow.

What I built

• — A digital-room dashboard with zones for focus, study, building, reset, archives, and long-term direction.
• — A defensive local-first state layer with safe parsing, SSR guards, namespaced keys, and normalised defaults.
• — Bounded server-side workspace readers for registered project metadata, documentation, package scripts, and Git state.
• — A read-only GitHub organization queue for pull requests awaiting review, unassigned issues, and stale branches.
• — A workspace brain that converts evidence into prioritized attention signals and guarded mission candidates.
• — A shared Command Center with human and agent creation modes, evidence-backed lanes, risk signals, review outcomes, and portable handoffs.
• — A public-demo hard guard plus repository, credential-shape, source-map, and build-output privacy checks.

Architecture

Studio OS has two deliberate modes rather than one backendless architecture. In the public demo, a neutral persona and namespaced localStorage provide the interactive experience while live connectors are disabled, private workspace routes fail closed, and synthetic data is labeled. In the private operator, Next.js server routes retrieve bounded evidence from registered local workspaces and a read-only GitHub organization adapter. A shared Command Center routes that evidence through human and agent lanes with explicit review, blocked, and accepted states. Merges, deployments, database changes, security actions, trading actions, and other consequential operations remain human decisions. Missing paths, credentials, or external responses degrade to explicit fallback states rather than invented live data.

A warm digital-room interface backed by defensive browser persistence and a small set of server-only context adapters. The private operator retrieves only the workspace and organization evidence needed for attention planning, while the public demo uses neutral content and synthetic connector results. A repository verifier, dependency audit, lint, strict typecheck, production build, source-map removal, and output privacy scan run as one check.

Backend / deployment

Constraints

• — The public demo must stay neutral, credential-free, and unable to activate live GitHub access
• — Private workspace readers must remain allowlisted, bounded, shallow, and read-only by default
• — Missing connectors must be labeled as demo or degraded rather than presented as live data
• — External writes and high-impact actions must remain behind explicit human approval

Tradeoffs

• — Kept personal state in localStorage for immediate, private daily use, accepting no built-in cross-device synchronization.
• — Used bounded filesystem and Git adapters instead of indexing every file, trading completeness for privacy, speed, and explainability.
• — Used a read-only GitHub connector and synthetic fallbacks before adding any write capability.
• — Maintained one codebase with explicit public/private modes, which requires deterministic checks to prevent the modes from drifting.

What I learned

• — AI-native architecture starts with authority and context boundaries, not model selection.
• — Fallback data must be labeled honestly or it becomes a product correctness problem.
• — Build-time privacy claims need an explicit marker set and output evidence, not assumptions about tree-shaking.
• — Read-only retrieval and human gates are useful product features when a system touches private work.
• — A calm interface can still expose serious engineering evidence without becoming a dense operations dashboard.

Next backend step

Add authentication and authorization before any hosted private-operator deployment, then test connector failure modes with redacted fixtures. Keep live GitHub access disabled in the public demo and add write capabilities only when each action has an explicit approval and audit design.