Choose where human acceptance belongs
Running work and accepting its result are different decisions. A team may want a method to prepare changes freely while deciding separately how its results are accepted.
Wildo names the posture that decides this. The companion currently runs under the automatic posture: it commits finished work under its own author name, notifies you, and leaves every change reversible in Git history.
Example — Let the build proceed, keep the decision reviewable
A coding run finishes a build task. The companion commits the files the run wrote and moves to the next ready task. The team reads that commit like any other change and reverts it if the direction is wrong.
For engineers
Read the posture and the policies together
The journey vocabulary names three supervision presets:
export enum Journey_AutonomyPreset {
GUIDED = "guided",
YOLO_LIGHT = "yolo_light",
YOLO = "yolo",
}
The companion holds the decided value, YOLO, and maps each posture and boundary decision to what the lane does. There is no command to change it. The guided posture, where a run would hold for a person at a boundary, is not available: a run started under it is refused before it begins rather than silently treated as automatic.
Per-playbook approval policies are read at the end of a composite, the lane boundary:
export enum MetaWorkflow_ApprovalPolicy {
AUTO = "auto",
NOTIFY = "notify",
APPROVE_RESULT = "approve_result",
APPROVE_BEFORE = "approve_before",
}
AUTO owes nothing, NOTIFY a record, and APPROVE_RESULT or APPROVE_BEFORE one decision to approve, revise or discard. Nothing suspends before a run starts, so APPROVE_BEFORE is honoured at the same boundary. Under the automatic posture that decision is recorded and the lane proceeds. A single playbook run outside a composite has no boundary and is not gated.
| Concern | Meaning |
|---|---|
| Running a method | Permission and readiness to carry out the work |
| Asking a product question | Obtaining information the method needs |
| Reviewing a result | Judging the proposed change and its evidence |
| Accepting a result | A commit: the companion’s under the automatic posture, or a person’s |
Know what the companion commits
The landing service writes artifact changes into the working tree; it does not commit. The companion commits afterwards, through one door that stages only the paths a run’s write register names:
| Work | When it is committed |
|---|---|
| A coding run that ended with a working result | When the run settles |
| A build generation step | When the step’s writes are registered |
| Playbook runs still uncommitted | Before the next build task starts |
| Coding runs that shared the tree in a parallel wave | Once the wave has drained, as one commit naming every run it may carry |
These commits carry the author Wildo development companion, so the history separates them from a person’s. For a single run, the door refuses what it cannot vouch for: a file that was already dirty when the run started, a file edited since, or a path another writer produced stays uncommitted and the task stays unlanded. A wave’s joint commit accepts the tree the runs left together, and still never commits a path another lane produced. A person can still commit a run’s work from the workbench at any time.
Design acceptance around inspectable work
The useful unit for review is the change with its purpose and evidence: which files moved, which checks ran and which product decision the work implements. Commit messages name the run, so git log answers why a change exists.
The Git acceptance workflow and clarification channel describe the mechanisms used for those separate concerns.