About Dev Process
Dev Process is the socket a development process plugs into. The harness runs the work; the process says how the team does it.
Dev Process is not a feature. It runs across the features: a process produces the record that the Log keeps, Telemetry counts and Studio shows, and it gets that record by fulfilling one contract. The Vinaya process is its default implementation.
The guarantees are the product. The harness guarantees ten things about work reaching a repository:
- Only a typed fact is a fact. A fact is a typed field with provenance, recomputed before dispatch and again at merge. Unknown is never false.
- A verdict is bound to what it judged. Change the head, base, patch, instructions, criteria, rulings or policy, and the verdict is void.
- A review result is valid or it is nothing. Missing, blank, malformed, stale, wrong-role or wrong-attempt output never approves.
- Declared scope is enforced; semantic scope is judged. A change touching a path outside its declared scope is refused. Whether it does more than asked is a reviewer's judgment.
- One controller, reconciled effects. One process owns a run. An effect whose outcome is unknown is reconciled before anything continues, never replayed blindly.
- A stopped run explains itself. Finished, paused with a reason and who must act, failed, or cancelled. Never silent.
- A ruling reaches a run that can still act. Every pause has a resume path.
- A worker cannot act as the Operator or the Principal. Workers hold no privileged credential and cannot rule, waive, approve or merge.
- The same process runs on two runtimes. The adapter conformance suite proves it.
- Every governed act is kept. One typed, attributed event per act, delivered live. Loss is surfaced, never hidden.
None of these depend on how a team names its work, writes its instructions or decides who reviews. That is what a process supplies.
How it works
- 1
The process declares how the team works
A process package fills in the process contract: its elements, scope, lifecycle, effects, events and extensions.
- 2
The loader installs and pins it
The loader validates the package, selects it and pins a Run in flight to the version it started with.
- 3
The harness runs it
The harness owns the Run, identity and authority. Adapters connect it to your tracker, agents, code host and Log destination.
- 4
The harness records it
The process supplies the identities and payloads; the harness writes every common event to the Log. See Logging.
- 5
Gates decide what may happen next
The generic gates evaluate the contract state at four enforcement points, whichever process is running. A process may add gates of its own; it can never bypass the generic ones.
What a process declares
Through the contract, a process declares:
| It declares | For example |
|---|---|
| What a unit of work is called | A task, a ticket, a release manifest: the process names it |
| What a change description must contain | The sections a pull request or an Issue has to carry |
| What a review verdict may say | Its scale, and what blocks |
| Which reviews are required | One reviewer, two, a conditional one, a non-agent tool |
| When a run stops | Its round cap, its budget, who it waits for |
The tracker is the process's choice; a git code host is required. The contract states which family of processes it supports and refuses the rest precisely.
The default: the Vinaya process
The Vinaya process ships beside the harness. It is loaded through exactly the same contract a team's own process would use. It ships inside the harness package, and vinaya init installs both together.
How Vinaya fulfils each part of the contract is documented under its own Integration pages: Process contract, Adapters, Loader, Conformance and Logging.
In this section
Process contract
What every process must define, including the generic gates
Adapters
Runtime, tracker, code host, Log destination
Loader
Install, pin, upgrade, resume
Conformance
Proving a different process runs unchanged
Logging
What a process supplies so the Log records its runs
Configuration
The contract itself is fixed; a process parameterizes it through its declaration. The adapters are selected in vinaya., for example dispatch.agent for the default agent runtime and logs for the Log destination. See Adapters and Configuration.