Work through Elixir examples of real application boundaries: Keep Phoenix order and audit changes in one Ecto.Multi; Insert an Oban job in the same transaction as the Phoenix order change. Each recipe includes implementation code, integration prerequisites, failure-path tests to add, a Perch rule, and the captured broken/fixed source checks.
Download the Phoenix rule pack ZIP · Inspect the YAML rules
Elixir
Ecto.Multi names each database operation and reports the failed step. Keeping order and audit in one Multi makes an invalid audit roll back the state transition. A successful placeholder callback can accidentally remove that guarantee while preserving the outer transaction shape.
Broken edit flagged · corrected edit passes
Elixir
A queued job belongs in the same database commit as the business change when workers depend on that change. Oban’s Multi integration keeps the job row transactional and preserves Oban-specific insertion behavior.
Broken edit flagged · corrected edit passes
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 Phoenix documentation · All language and framework recipes
