Activities: module-owned definitions with a workflow-side call surface.

defmodule Bookings.Activities do
  use Temporalex.Activity, start_to_close_timeout: 30_000

  defactivity charge(amount), name: "bookings.charge" do
    {:ok, PaymentGateway.charge(amount)}
  end
end

# inside a workflow — a plain call; policy lives at the definition:
receipt = Activities.charge!(amount)

# call-site overrides are keyword options, validated against what the
# backend actually honours:
Activities.charge!(amount, timeout: 10_000)

The generated name/N dispatch returns {:ok, value} or {:error, error} (a cancelled activity is {:error, %Temporalex.Failure.CancelledError{}}); name!/N unwraps success and raises failures. The implementation body runs on the worker — unit-test it directly with Temporalex.Testing.run_activity/4, no Temporal anywhere.

Options given to use Temporalex.Activity become module-wide defaults; per-activity options override them key by key. Declared options are part of a scheduled activity's replay identity, so treat module defaults as values you will not change while runs are in flight — editing one shifts the identity of every activity in the module at once. local: true marks a local activity (runs inside the workflow task) and narrows the allowed options — local activities cannot heartbeat or target another task queue.

Declaring ctx (or context) as the first argument opts the implementation into a Temporalex.Activity.Context — invisible to workflow-side callers.

See docs/rfcs/0003-activity-surface.md.