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 keeping the decision to adopt them in human hands.
Wildo’s autonomy design distinguishes guided work, lighter supervision and automatic acceptance. These are intended supervision postures; the current workflow leaves acceptance with the person reviewing and committing the changes.
Example — Delegate preparation, retain the decision
A team lets a creation method revise its delivery plan. It reviews the resulting changes before committing them, keeping the proposed work separate from the accepted direction.
For engineers
Read the policy as a design contract
The journey vocabulary describes the intended supervision presets:
export enum Journey_AutonomyPreset {
GUIDED = "guided",
YOLO_LIGHT = "yolo_light",
YOLO = "yolo",
}
Per-playbook approval policies describe where attention could be requested:
export enum MetaWorkflow_ApprovalPolicy {
AUTO = "auto",
NOTIFY = "notify",
APPROVE_RESULT = "approve_result",
APPROVE_BEFORE = "approve_before",
}
These enums are source declarations, not an installation example for an enforced mode switch. Setting autonomyPreset or approval does not install a dispatch gate or grant an agent permission to commit.
| 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 | Committing the reviewed changes in the project |
Keep the effective behavior explicit
The landing service writes proposed artifact changes into the working tree. It does not commit them. The current runtime does not interpret these approval policies as gates, so an APPROVE_BEFORE declaration must not be relied on to prevent execution.
A host integrating creation work should preserve the distinction between its own permissions, clarification handling and the application’s Git review workflow. The supervision vocabulary describes a future policy layer; it is not a substitute for controls the host actually enforces.
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. Preserve that information when adding supervision so a request for approval is a meaningful decision.
The Git acceptance workflow and clarification channel describe the mechanisms used for those separate concerns.