# Vision

## One sentence

Make multiple DSH runtimes explicit, safe, inspectable, composable, and
recoverable for developers working locally.

## The problem

An official DSH, a team-customized DSH, a development fork, and several Agent
Presets can all be valid at the same time. Without a control plane, runtime
identity, Profile selection, Preset selection, Session state, plans, and
knowledge references become scattered across shell commands and private local
configuration.

That scattering makes it difficult to answer basic questions:

- Which runtime owns this Session?
- Which Profile and Preset will reproduce this workflow?
- Which plan and knowledge references belong to the Session?
- Can one runtime be disabled without breaking the others?
- Can the entire setup be inspected and shared without leaking local data?

## Product direction

`dsh-control-plane` is a local-first control plane with two cooperating parts:

1. A runtime-neutral core for registries, references, adapters, health, and
   lifecycle state.
2. A versioned DSH Bundle that presents selected control-plane capabilities
   through additive Host and Client integrations.

The core remains useful outside the DSH UI. The DSH integration remains a
thin, failure-isolated surface rather than a replacement for DSH's root
composition, persistence, model routing, or security policy.

## Non-goals

- Reimplementing or replacing DeepSeek Harness.
- Copying private Harvis knowledge or local memory into a public repository.
- Becoming a default remote orchestration service.
- Executing arbitrary commands supplied by a UI field.
- Serializing complete live Context, Service, Session, or runtime objects.
- Treating an LLM review as a substitute for tests, maintainers, or release
  gates.