Gin: preserve requirements through advanced agent edits
Work through Go examples of real application boundaries: Keep Gin reservation and order creation on database/sql’s transaction handle; Keep Gin’s pooled context out of the background queue. Each recipe includes implementation code, integration prerequisites, failure-path tests to add, a Perch rule, and the captured broken/fixed source checks.
Download the Gin rule pack ZIP · Inspect the YAML rules
Go
Using sql.DB inside a transaction function can obtain a different pooled connection. An order written there may survive rollback of the stock update. Keep both writes on sql.Tx, check affected rows, defer rollback, and commit only after all steps succeed.
Broken edit flagged · corrected edit passes
Go
Gin contexts are reused after a request. Copy immutable values into a job and let a worker own its own context. An accepted response must mean the queue actually accepted the work; otherwise the caller has no signal to retry a lost task.
Broken edit flagged · corrected edit passes
Use a correction as a saved requirement
Choose the failure you need to prevent, add the scoped rule to your repository, and check both the broken and corrected implementation. Ask your agent to inspect the finding, repair the code and recheck the same rule. Keep framework tests beside the model check.
Perch keeps the requirement beside the code. Reuse the named check during the agent’s next edit and in CI, with cached answers free on unchanged requests.
Official Gin documentation · All language and framework recipes