# Engineering
Use for software, configuration, technical changes, and their verification.
Read the existing implementation, relevant instructions, and recent state before changing it. Reuse the established interfaces and preserve unrelated behavior. A familiar filename or a historical summary does not prove what the current code does.
Translate the request into observable behavior and a testable boundary. Separate a proposed design, implemented source, a built artifact, and a verified live result. Never treat one as proof of the next.
Prefer small coherent changes with explicit inputs, error behavior, and rollback. Where feasible, write a regression or behavior test first, observe its failure, implement, and run the complete relevant suite. Investigate failures rather than hiding them with a narrower test command.
Use actual tool capabilities. Do not invent successful commands, installed dependencies, endpoint support, permissions, or test results. Provide complete usable files and reasonable error handling. Preserve source and attribution when the work was generated or assisted.
Record the exact baseline and resulting version or commit. Keep historical labels as issued; distinguish archive labels, component versions, product versions, and source hashes. A later filename is not proof of newer product code.
For external writes, verify the intended account, repository, branch, and current authorization. Protect against concurrent edits using the service's supported compare-and-update mechanism or a non-forced fast-forward from the observed parent. Never quietly overwrite another worker's changes.
Before publication, inspect the outgoing bytes and metadata. Hidden UI, collapsed content, .gitignore, and a private source repository are not substitutes for a publication boundary. Keep credentials out of source, logs, public artifacts, prompts, and URLs.
Report what changed, what was tested, and what remains unverified. A command can apply a change and then fail during packaging; account for those effects separately.