About the Vinaya process
The Vinaya process is the default process, and the default implementation of Dev Process. It plugs into the harness the same way any other process would; its Integration pages document how it fulfils the contract. A team can run it as it is, or bring its own.
In one sentence: work is planned into tasks by someone who read the code first; each task runs alone through the loop under a frozen brief whose facts the harness has checked; two independent reviewers must both report, and the controller derives the outcome from their findings; a person merges.
Every role is an agent except one: the Principal, the engineer driving the work, who approves plans, rules when a run pauses and merges. See Roles.
The four stages
Thinking
What enters execution. The Architect declares a Goal as a milestone, and the Planner writes every task as an Issue an agent can run.
Executing
One Issue in, one mergeable pull request out. The Operator runs the tasks; an agent builds and two fresh reviewers check.
Retrospecting
What shipped and why. Merged work closes itself: the task, the tranche and the milestone.
Self-improvement
How runs become proposals. The Improver reads the Log and proposes changes; the Principal approves.
Gates run across the stages: the checks that refuse unsafe work on your machine, on the pull request and after merge.
How it works
- 1
Thinking
Someone reads the code and writes down what must change. The output is always a GitHub Issue: planned (inside a tranche), backlog (a stand-alone fix) or hot (must change now). Planning happens here: the Planner cuts the work into tasks and you approve the plan.
- 2
Executing
The Operator starts each ready task. A Developer agent builds it in a sandbox, two fresh reviewers judge the pull request, and every gate runs. The run ends with a pull request ready for you, or a pause that names who must act.
- 3
Retrospecting
After you merge, the task, the tranche and the milestone are closed and their record is completed, mostly without anyone starting it.
- 4
Self-improvement
The Improver reads the Log and proposes changes, and the Principal approves.
The gates run across the stages: at commit and push, on the pull request, and after merge.
Each stage is usable without the one before it. You can enter with a Goal, a tranche or one Issue. See the guides in What's next.
How work is shaped
| Unit | What it is | Where it lives |
|---|---|---|
| Goal | A product outcome and the tranches that serve it | A GitHub Milestone |
| Tranche | A set of related tasks with declared dependencies and conflicts, in dispatch order | A vinaya/ label on its Issues |
| Task | One frozen brief, one branch, at most one pull request, one parent branch | A GitHub Issue |
The four flows
Each flow, step by step, in its guide:
Complex work
A milestone, tranches, many tasks
Medium work
One feature, several tasks
Simple work
One backlog Issue
Hot issue
You and one agent, live