Review changes where you already review code
Creation work becomes files in your project: specifications, configuration and implementation that can be inspected together. A commit records the accepted version, whether the companion or a person made it.
That keeps product decisions and the code they guide in the same history. Teams can compare, branch and review their work without maintaining a separate acceptance record for each generated artifact.
Example — Review the plan with the change it explains
A delivery-plan update accompanies an implementation change. Both land as commits in ordinary project history, so the team reviews the plan and the code together and reverts either if it is wrong.
For engineers
Inspect the working tree before committing
Under the current autonomy posture the companion commits finished coding runs and pending playbook runs itself. Work it has not committed yet, and anything you change by hand, is reviewed the usual way. From the application repository, a typical review begins with:
# Inspect both new files and edits to tracked files.
git status --short
git diff --stat
git diff -- specifications/
# After reviewing, stage only the intended paths.
git add specifications/src/vision/index.ts
git diff --cached
git commit -m "Clarify the product direction"
The staged path is illustrative; use the files actually produced by the run. git diff alone does not show the contents of untracked files, so inspect new files identified by git status as well.
Understand what landing does
This source excerpt shows the final render and write step for a structured artifact:
const source = renderApplicationStructuredArtifactFamilySource({
profile: target.renderProfile,
exportedConstantName: target.exportedConstantName,
value: landedValue,
});
if (input.dryRun !== true) {
await mkdir(dirname(absolutePath), { recursive: true });
await writeFile(absolutePath, source);
}
return {
packageRelativePath: target.packageRelativePath,
absolutePath,
byteLength: source.byteLength,
renderedSource: new TextDecoder().decode(source),
existedBefore: previousContent !== undefined,
...(previousContent !== undefined ? { previousContent } : {}),
};
Before this point, the service resolves the registered target and applies schema and semantic validation. dryRun returns rendered output without writing it. The write changes the working tree; it does not create a commit or establish that a reviewer accepted the result.
Use evidence alongside the diff
| Evidence | Review question |
|---|---|
| Proposed file changes | Does this implement the intended decision? |
| Schema and semantic checks | Is the declared model internally meaningful? |
| Coherence report | Do the supported cross-family references agree? |
| Application checks | Does the implementation behave as required? |
| Commit | Which reviewed version did the team accept? |
Git records the accepted bytes, not the truth of every claim inside them. The landing path itself never commits. The companion commits afterwards, through one door that stages only the paths a run’s write register names, and authors those commits as Wildo development companion so they stay distinct from a person’s. A dispatched coding agent is told never to commit: acceptance belongs to the host, not the worker. A person can commit a run’s work from the workbench, which uses the same door.
Keep runtime records in their proper role
The companion records run writes for inspection and recovery. Those records help associate files with a run; they are not a competing accepted version of the application. Review targeted recovery separately from Git history, especially when another edit has changed the same file since the run.