Mushin Docs / Concepts

Concepts

Mushin brings together a few distinct ideas. This page defines them in plain language so the rest of the documentation reads clearly. You do not need to memorize them — refer back as you go.

The building blocks

Project — one application you are building. A project has a name, a type (see below), and everything that describes the app.

Project type — how you work with a project. A Conversational project is built through a chat with the assistant; a Mushin project is built as a versioned specification. See Projects .

Design stream — an active line of work in which the AI, playing a defined role, develops part of your application’s design. You have a conversation or exchange within a design stream, and it contributes to the design. (In conversational projects this is simply the chat with the assistant.)

The versioned specification (Mushin projects)

Blackboard — the evolving design document for a piece of your application: the shared “source of truth” that the AI and you build up together. It is called a blackboard because more than one contributor writes to it.

Branch and commit — version control for the blackboard, working like a familiar source-control system. A branch is a line of development; a commit is an immutable snapshot of the blackboard at a moment in time. You can review the history of commits and go back to an earlier one.

Feature — a named slice of your application (say, “billing” or “user profiles”). Splitting the design into features keeps each part’s requirements separate and lets the AI focus on one at a time. A feature has its own blackboard.

The Mushin Cycle — the rhythm of building a Mushin project: check out the current design, generate the next contribution, review the difference, commit it, and let the structured metadata sync. See Design Streams & Version Control .

How the AI is guided

Prompt — reusable instructions that shape how the AI behaves. Two kinds guide a Mushin design stream: a persona prompt (the role the AI plays — for example a data architect) and a delta prompt (how it should express changes to the design). You can view and refine prompts from the Prompts panel.

AI model — the language model that does the generation. You configure which model Workbench uses, including a model running on your own hardware. See AI Model Configuration .

The structured layer

KenshoProtocol — the structured, machine-readable form of your design. As the AI produces natural-language design, that design is distilled into KenshoProtocol commands — precise statements like “add this table,” “add this field,” “add this page” — which become the exact specification your application is generated from. See The Metadata Knowledge Base .

Metadata knowledge base — the accumulated, versioned set of facts about your application (its tables, fields, relationships, pages, services) built from the KenshoProtocol commands. This is what the code generator reads.

Orchestration and output

BrainChain — a visual, node-based pipeline that orchestrates the work of turning a design into structured metadata and, ultimately, code. You can watch it run and inspect each step. See BrainChain .

Code generation — the step that turns your specification into a working application: a Go backend and a TypeScript/React frontend. See Code Generation & Templates .

Templates — the blueprints the generator fills in. They encode Nandeshou’s backend and frontend conventions, so generated code follows the same patterns a hand-written Nandeshou application would.

← PreviousGetting Started