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 version you accept.
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. The team reviews both diffs and commits the accepted result, preserving the reasoning and implementation in ordinary project history.
For engineers
Inspect the working tree before committing
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 creation runtime’s landing path does not commit on the person’s behalf. A host or coding agent’s permission to commit must be explicit in its own workflow.
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.