Keep accepted work in the project's history
Product definitions and application code belong in the repository. Git gives the team a shared way to review changes, accept them and understand how the product evolved.
The problem it answers
A separate acceptance ledger can disagree with the files people actually use. Branches move, changes merge and developers edit the project directly. A second account of accepted product content creates another reconciliation task.
Keeping the product’s versioned definitions beside its code makes both available to ordinary review and history tools.
What it rules in, and what it rules out
A commit records the accepted project content. Validation and review help decide what should be committed; the commit itself does not prove that the content is correct.
Operational records have another role. Run outcomes, diagnostics and local recovery data help operate the development process. They should not be mistaken for the authoritative version of a product definition or a substitute for inspecting its diff.
Who accepts is a separate policy choice. The declared guided and automatic postures describe different responsibilities; a preset declaration alone does not implement an automatic commit path.
What it means for someone building with Wildo
Review the application’s definitions and code together. Use branches and history to carry decisions with the project, and keep runtime evidence attached to the claims it actually supports.
The result remains an application repository you can inspect and evolve with ordinary development tools, built on Wildo’s shared framework.
For engineers
Where it lives in the framework
Use Git for the product change
These ordinary read-only commands help inspect a proposal before acceptance:
# See the working changes, including newly created paths.
git status --short
# Review tracked edits in the product definitions.
git diff -- specifications/
# Inspect the committed history of those definitions.
git log --oneline -- specifications/
git diff does not display the contents of an untracked file; inspect newly created files reported by status too. A commit can include unwanted work if its selected changes were not reviewed.
Distinguish inspection from recovery
The coding change set compares the workspace before and after a run. It preserves earlier dirty-file distinctions and identifies ambiguous overlaps; it is not a second accepted-state ledger.
The specification playbook write register saves previous contents for its supported undo action. That local record covers the recorded specification output, export wiring and coherence report, rather than arbitrary coding edits. Existing differing content is refused by a normal revert; deliberate deletion and partial-retry behavior require separate care, as described in the undo guide.
Deleting operational state can lose diagnostics or recovery convenience. It does not remove the committed product content, but that is not a reason to promise that every local record is harmless to discard during active work.
Keep acceptance distinct from validation
The framework evaluates particular properties through schemas, validators, reports and checks. Their findings inform acceptance; none of them makes a commit a universal certificate of product correctness.
The application-creation directive assigns acceptance responsibility by autonomy posture. Verify the actual execution path when using automatic behavior; do not infer that every playbook or coding run performs a commit because an autonomy enum exists.