How Showrunner Works

Showrunner is easiest to understand when you stop treating it like a single surface.

The current product is made of three layers that can work together:

1. Desktop App

The desktop app is the main operating surface.

It is where the user:

navigates the workspace
opens and restores terminal sessions
works through Git sync and history
inspects files and venture structure
moves through dashboards for tasks, leads, ventures, and observability

In practical terms, this is the daily cockpit.

2. CLI

The CLI exists for bootstrap and runtime control.

Today the most important commands are:

show init - creates the minimum .show contract for a workspace
show run - starts the local runtime stack

This means the product is not only UI-deep. There is an explicit runtime contract for workspaces.

3. Local Core

showrunner-core is the local HTTP service that powers runtime-aware flows when needed.

It exposes endpoints for:

health
status
sessions
commands
heartbeats
tasks
costs
logs

That gives the desktop app and the TUI a shared operational backbone when the runtime is active.

Workspace Model

Showrunner is opinionated about structure. The app is designed around a workspace model with roots like:

00-brain
01-team
02-memory
03-resources
04-ventures
05-clients

That is one of the real differentiators. The product is not just a file browser. It understands that some folders carry different operational meaning.

Git and Terminal

The product also avoids a false tradeoff:

you can use simplified Git surfaces for faster operational work
you can still drop into the terminal when you need direct control

That hybrid model is more honest than pretending every Git workflow should become a shiny abstraction.

Current Boundary

What Showrunner does best today is workspace operations.

That is the current center of gravity. If future AI-facing surfaces become fully mounted and stable, they can earn a bigger role in the story. They should not be used as the primary promise before that.