How the work moves

The idea is questioned on its value, its return and the five W's. It gets reshaped or killed here, and doing nothing is always one of the options.

The plan names the files, the approach and what done means. Each acceptance criterion becomes a row in a checks table that starts unresolved, and each step of the plan gets an autonomy level.

I explain the plan cold, in my own words, before it is approved. If I can't, it isn't approved.

The code is written to the agreed plan in house style. Anything outside the plan waits for its own ticket.

The diff is read the way a hostile reviewer would read it, then cleaned up: reuse what already exists, cut dead code, pick the simpler form.

I explain how the change works and why it is written this way before it leaves the branch.

The pull request carries the checks table, refreshed on every push and naming the commit it was checked on.

A session that didn't write the code reads it with none of the builder's context, runs the secret and security scans, and grades every finding from Critical to Low.

The end-to-end suite runs against a preview of the exact commit that will merge, never against production. TestProof turns the run into a report someone who doesn't write code can follow.

A Critical or a major finding sends the change back to the code challenge on the new head. A failed check gets three tries, then it comes to me as a blocker.

Green means an approved review, passing tests and a full checks table, all on the same commit. In Dispatch, every merged pull request adds an entry to the app's What's new page, and a test fails if one is missing. A merge that deploys waits for my word.