Change control
Make every production change explainable and recoverable
The workflow should be lightweight enough to use consistently and strict enough to protect the branch that defines production.
Start state
Update from the canonical branch and understand local changes.
- Record
- Base commit and clean or intentional diff
- Risk
- Generated work starts from stale unmerged code
- Proof
- Explicit status before generation
Focused branch
Give one outcome an isolated review and rollback path.
- Record
- Task name, scope and owner
- Risk
- Weeks of features accumulate in one branch
- Proof
- Small diff tied to acceptance evidence
Meaningful commits
Capture verified milestones, not arbitrary file batches.
- Record
- Imperative summary and reason
- Risk
- One commit contains feature, formatting and data rewrite
- Proof
- Each commit builds or has a documented dependency
Protected integration
Require the checks and review appropriate to production consequence.
- Record
- Required tests, reviewers and resolved discussions
- Risk
- Generated changes push directly to production branch
- Proof
- Ruleset or branch protection
Release trace
Bind the deployed artifact to reviewed source and configuration.
- Record
- Commit, build, environment and release time
- Risk
- Dashboard redeploy cannot identify source
- Proof
- Immutable deployment metadata
Operating principle
Keep generated changes small enough to review
An agent can alter many files faster than a reviewer can reconstruct intent. Large diffs invite superficial approval and make later rollback remove unrelated behavior.
Ask for a focused slice, review the diff before adding the next layer and commit only after the relevant tests pass. Preserve user changes already present in the worktree.
- Inspect status before editing
- Protect the production branch
- Require relevant checks
- Tag or record deployed commits
Applied example
Change-control example: one commit, three migrations
A generated feature changes authentication, rewrites the database schema and updates the landing page in one commit. Production login fails after deployment.
- The failing boundary is difficult to isolate
- Reverting also removes unrelated content
- Migration reversal may be unsafe
- Review evidence was not separated by consequence
Plain answers
Questions to resolve before shipping
Does a solo founder need pull requests?+
A lightweight self-review branch can still provide diff inspection, checks and a deliberate integration point. Add independent review for consequential boundaries.
Should generated files be committed?+
Commit artifacts required for reproducible operation when the project convention calls for it; otherwise generate them deterministically in the build.
Can I squash all commits?+
Squashing can create a clear final change, but preserve enough review and release evidence to investigate and recover safely.