Dream Studio

Dream Studio

[](https://github.com/SeayInsights/dream-studio/actions/workflows/ci.yml) [](CHANGELOG.md) [](pyproject.toml)

What Dream Studio Is

**Dream Studio makes an AI agent accountable to a system of record it cannot edit.** An agent working under Dream Studio cannot change source outside an approved work order, cannot close a defect while its symptom still reproduces, cannot self-certify its own work, and cannot silently drift its config away from authority. These are not conventions the agent is asked to follow — they are runtime gates enforced by the SQLite authority and the hooks that guard it. You can watch all four hold, against a throwaway project, in about ten seconds: [`ds prove`](#prove-it).

That accountability is the point; the orchestration is how it is delivered. Underneath, Dream Studio is a **local-first AI orchestration** platform that runs three layers in concert:

• Capability layer — skills, agents, and workflows that encode structured development practices
• Infrastructure layer — an event pipeline, spool system, SQLite authority database, and provisioner that wire AI sessions to persistent state
• Intelligence layer — a project spine with SDLC pipeline, design gates, and session memory that accumulates across every build

When you invoke a Dream Studio skill, you are not calling a function. You are engaging a system that knows your project, your history, your quality standards, and your current work order — and holds execution to them.

**Architecture note (TA0b):** canonical_events is the single authoritative event store. execution_events is a projection rebuilt from canonical events. See docs/architecture/event-store.md.

What it refuses to do

Four refusals, each enforced by code you can read and rep