feat(automations,events): add Automations and Events API namespaces

[drish]

As part of these new features, I also took the opportunity to upgrade the minimum required ruby version + CI

• Add Resend::Automations with create, get, update, remove, stop, list
• Add Resend::Automations::Runs with list and get (nested namespace)
• Add Resend::Events with create, get, update, remove, send, list
• Add specs and examples for both namespaces
• Add base64 as explicit runtime dependency (removed from Ruby 3.4 stdlib)
• Move rails to Gemfile development group, remove from gemspec
• Update Dockerfile to bundle install --without development

---

Summary by cubic

Adds Automations and Events API namespaces to build workflows and send custom events. Includes runnable examples, full RSpec coverage, Ruby 3.2+ support (tested through Ruby 4.0), and a leaner Docker image.

• New Features

  • Resend::Automations: create, get, update, remove, stop, list (status filter, pagination).
  • Resend::Automations::Runs: list (pagination), get.
  • Resend::Events: create, get (by ID or name), update, remove, send, list (pagination).
  • Added examples and RSpec tests for both namespaces.

• Dependencies

  • Ruby >= 3.2.
  • Added base64 as a runtime dependency.
  • Moved rails to the Gemfile development group; removed from the gemspec.
  • Dockerfile installs with --without development.
  • Bumped gem version to 1.3.0.

^{Written for commit e81d874. Summary will update on new commits.}

[cubic-dev-ai]

6 issues found across 12 files

Confidence score: 3/5

• There is moderate merge risk because two high-confidence medium-severity issues in examples/events.rb and examples/automations.rb can produce nil IDs/cursors when nested response data is accessed with symbol keys instead of string keys.
• The most severe impact is user-facing example behavior: pagination cursor and nested run ID reads may fail against real API responses, which can mislead integrators using these samples.
• Issues in spec/events_spec.rb and spec/automations_spec.rb suggest tests currently assume the wrong nested key shape and also violate the repository’s test-description rule (should), increasing the chance of brittle or noncompliant test coverage.
• Pay close attention to examples/events.rb, examples/automations.rb, spec/events_spec.rb, and spec/automations_spec.rb - nested string-key access and test naming rules need cleanup to avoid nil IDs/cursors and unreliable specs.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="spec/events_spec.rb">

<violation number="1" location="spec/events_spec.rb:14">
P2: Custom agent: **No `should` in tests**

Test descriptions use the forbidden word `should`; replace with declarative phrasing (e.g., `creates`, `retrieves`, `uses`).</violation>

<violation number="2" location="spec/events_spec.rb:238">
P2: Access nested list items with string keys. Only top-level response keys are symbolized, so this expectation will fail against real API data.

(Based on your team's feedback about nested response keys using strings.) [FEEDBACK_USED]</violation>
</file>

<file name="spec/automations_spec.rb">

<violation number="1" location="spec/automations_spec.rb:25">
P2: Custom agent: **No `should` in tests**

Test descriptions in this new spec repeatedly use the forbidden word `should`, violating the repository rule for declarative test naming.</violation>

<violation number="2" location="spec/automations_spec.rb:166">
P2: Use string keys for nested objects inside `:data` (`["id"]`, `["status"]`) to match this SDK’s response shape.

(Based on your team's feedback about nested response objects using string keys.) [FEEDBACK_USED]</violation>
</file>

<file name="examples/events.rb">

<violation number="1" location="examples/events.rb:76">
P2: Use a string key when reading `id` from items inside `:data`; nested response objects are string-keyed, so `[:id]` can produce a nil pagination cursor.

(Based on your team's feedback about nested response objects using string keys.) [FEEDBACK_USED]</violation>
</file>

<file name="examples/automations.rb">

<violation number="1" location="examples/automations.rb:73">
P2: Use a string key when reading the nested run object ID; nested response objects are not symbolized.

(Based on your team's feedback about nested response keys using strings.) [FEEDBACK_USED]</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[drish]

@cubic-dev-ai

[cubic-dev-ai]

@cubic-dev-ai

@drish I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

1 issue found across 14 files

Confidence score: 4/5

• This PR looks safe to merge with minimal risk; the flagged issue is about build reproducibility rather than an immediate runtime regression.
• The most severe finding is in Dockerfile: using a floating Ruby minor tag can cause non-deterministic image updates, which may introduce unexpected behavior across environments over time.
• Given the issue is concrete but non-blocking, this is a moderate process/stability concern rather than a likely functional break.
• Pay close attention to Dockerfile - pin the Ruby base image to a fully specific version to keep builds reproducible.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="Dockerfile">

<violation number="1" location="Dockerfile:1">
P2: Use a fully pinned Ruby image tag instead of a floating minor tag to keep Docker builds reproducible.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[drish]

@cubic-dev-ai

[cubic-dev-ai]

@cubic-dev-ai

@drish I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

1 issue found across 8 files

Confidence score: 4/5

• This PR is likely safe to merge with low functional risk, since the only reported issue is a test-naming convention violation rather than a runtime behavior bug.
• The most severe finding is in spec/events_spec.rb: descriptions use should, which conflicts with the repository’s declarative test-name rule and may cause lint/policy friction.
• Impact appears limited to test readability/compliance, not production logic, so this is a minor-to-moderate process issue rather than a user-facing regression risk.
• Pay close attention to spec/events_spec.rb - update example descriptions to remove forbidden should phrasing.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="spec/events_spec.rb">

<violation number="1" location="spec/events_spec.rb:14">
P2: Custom agent: **No `should` in tests**

Test descriptions repeatedly use the forbidden word `should`, violating the repository rule requiring declarative test names.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="lib/resend/version.rb">

<violation number="1">
P1: The version constant was changed to an older release (`1.2.0`), which will ship new features under the wrong gem version.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}