The tool is not the architect: own the engineering decision

A contribution needs an engineering owner who can explain why it belongs in the game and change it when the surrounding system changes. That requirement survives every tool choice, including an agent that writes the whole patch.

Clowdr's standard asks contributors to explain, revise, integrate, verify, and hand off their work. This position applies that policy to code. It makes no claim that a particular tool determines project success.

Own the boundary before accepting the patch

Name the behavior the task must deliver and the systems it is allowed to change. Explain where state belongs, how failure is handled, and which existing assumptions the change relies on. The explanation should help another contributor modify the work later.

For a hypothetical save change, the owner must account for when data is written, what happens on interruption, and how an older save is read. A generated implementation that appears to work once cannot settle those decisions.

If the owner cannot explain the patch, pause acceptance. Simplify it, inspect the relevant behavior, or replace the implementation until the owner can support it. Passing the task onward does not transfer accountability to the tool.

Verify the behavior the game depends on

Use checks that can reveal a failure of the promised behavior. Focus automated tests on meaningful boundaries and failure cases, then inspect the integrated player path where the change matters.

Unit tests do not establish the entire Build Proof. The Release Candidate must launch, run, and complete its critical path on every stated platform without unresolved Release Blockers. Record what was checked, the build and conditions, the finding, and the limits of coverage.

A save test might confirm round-trip data while an in-build check exposes a menu path that loads the wrong slot. Treat these as different evidence, and resolve the failure before declaring the relevant behavior ready.

Leave a maintainable handoff

Keep the change in version control with its scope, decisions, checks, and known limits. Account for material sources, dependencies, licenses, and credits. Record material AI assistance or deliberate non-use according to the project's AI Production Note.

The next contributor should be able to find the owner, reproduce a relevant check, and see what remains uncertain. Opaque complexity that nobody can revise is not owned work simply because it compiles.

The Clowdr AI standard gives the shared rule; How We Ship explains the release proofs. Use the tool that supports the work, then take responsibility for the engineering decision it helped produce.