Receptury na Elixira i Phoenix

Receptury na Elixira i Phoenix dla agentów AI to konfiguracja projektu i zestaw promptów, dzięki którym Claude Code, Codex i Cursor dostarczają godne zaufania zmiany w Phoenix 1.8: wygenerowany AGENTS.md i alias mix precommit jako definicja ukończenia, Tidewave jako dostęp do działającej aplikacji, testy pisane przed kodem oraz bramki CI, które padają na ostrzeżeniach kompilatora, naruszeniach typów i znaleziskach bezpieczeństwa.

Ta strona jest dla programistów Elixira, za których większość funkcji pisze już agent, oraz dla tech leadów, którzy chcą, żeby te same bramki obowiązywały cały zespół (zobacz job CI i tabelę akceptacji). Sytuacja, którą rozwiązuje: pull request od agenta jest zielony, tyle że LiveView trzyma wszystkie zamówienia w assigns socketu, test, który „dowodzi” działania GenServera, używa Process.sleep(100), wywołanie płatności siedzi wewnątrz Repo.transaction, a padającą asercję „naprawiono”, zmieniając oczekiwaną wartość. Phoenix daje ci już plik z regułami dla agenta, alias precommit i generatory. Poniższe receptury sprawiają, że agent zderza się z nimi w każdej turze, więc przeglądasz dowody, a nie diffy.

Co zyskujesz dzięki tym recepturom na Elixira

• Projekt Phoenix, w którym AGENTS.md, alias mix precommit i reguły z zależności trzymają agenta przy aktualnych idiomach Phoenix, podpięte do wszystkich trzech narzędzi.
• Skonfigurowany Tidewave MCP, dzięki któremu agent wykonuje kod w działającej aplikacji, czyta jej logi i odpytuje bazę deweloperską, zamiast zgadywać.
• Hook Stop w Claude Code, który nie pozwala ogłosić „gotowe”, dopóki mix precommit nie przejdzie, oraz job CI, który jest mechaniczną bramką dla Codeksa i Cursora.
• Osiem promptów do skopiowania: szkic AGENTS.md, kontekst i API JSON w trybie test-first (najpierw testy, potem kod), LiveView ze strumieniami, limiter zapytań na ETS, transakcja zamówienia w Ecto.Multi, worker Obana i release w Dockerze.
• Tabelę akceptacji, która mówi, które zmiany agenta przegląda człowiek, a które udowadniają bramki.

Jakie wersje Elixira, Phoenix i pakietów Hex zakładają te receptury?

Agenci mieszają API od Phoenix 1.5 do 1.8 i od LiveView 0.x do 1.x, bo tak wyglądają ich dane treningowe. Przypnij wersje (.tool-versions lub mise.toml oraz mix.lock) i wymień je w AGENTS.md. Te były aktualne 2026-09-26:

Komponent	Wersja	Źródło (sprawdzone 2026-09-26)
Elixir / Erlang/OTP	1.20.4 / 29.1.1	tagi obrazu hexpm/elixir w Docker Hub
phoenix / phx_new	1.8.15	hex.pm
phoenix_live_view	1.2.12	hex.pm
ecto / ecto_sql	3.14.2 / 3.14.0	hex.pm
oban / oban_web	2.24.1 / 2.13.0	hex.pm
credo / sobelow / mix_audit	1.7.19 / 0.15.0 / 2.1.5	hex.pm
stream_data	1.4.0	hex.pm
tidewave / usage_rules	0.9.1 / 1.2.8	hex.pm

Opisane tu zachowanie Phoenix (wygenerowany AGENTS.md, alias precommit, phx.gen.release) odczytaliśmy ze źródeł instalatora phx_new 1.8.15. Flagi Elixira pochodzą z dokumentacji tasków Mix w wersji 1.20.4. Hooki i kroki CI są zgodne z dokumentacją każdego narzędzia; uruchom je na swoim projekcie, zanim zaczniesz na nich polegać.

Notatka

Do tej pracy zostań przy domyślnym modelu swojego narzędzia i podnieś poziom wysiłku (effort), zanim zmienisz model. Aktualne modele domyślne i ceny znajdziesz w centrum modeli AI.

Jak przygotować projekt Phoenix do pracy z agentem?

Zacznij od tego, co generuje już mix phx.new. W Phoenix 1.8.15 tworzy on AGENTS.md (pominiesz go flagą --no-agents-md), który łączy wytyczne projektu z regułami dla Elixira, Phoenix, Ecto, HEEx i LiveView. Wśród nich: używaj strumieni LiveView dla kolekcji, unikaj LiveComponentów bez konkretnej potrzeby, uruchamiaj procesy w testach przez start_supervised!/1, nigdy nie używaj Process.sleep/1 w testach i nigdy nie wywołuj String.to_atom/1 na danych od użytkownika. Dodaje też alias, który jest naturalną definicją ukończenia:

mix.exs (generated by phx.new 1.8.15)

def cli do
  [preferred_envs: [precommit: :test]]
end

defp aliases do
  [
    # ...
    precommit: ["compile --warnings-as-errors", "deps.unlock --unused", "format", "test"]
  ]
end

mix precommit kompiluje z ostrzeżeniami traktowanymi jak błędy, usuwa nieużywane wpisy z mix.lock, formatuje kod i uruchamia testy. Pierwszy krok znaczy więcej w Elixirze 1.20: jego system typów wnioskuje typy między klauzulami i zgłasza naruszenia typów oraz martwy kod jako ostrzeżenia kompilatora, więc alias pada na całej klasie błędów, dla których nikt nie napisał testu. Dodaj kontrole, które agent pomija najczęściej, a ich pakiety wpisz do deps z only: [:dev, :test], runtime: false:

mix.exs

precommit: [
  "compile --warnings-as-errors",
  "deps.unlock --unused",
  "format",
  "credo --strict",
  "sobelow --exit Low --skip",
  "test"
]

W aplikacji utworzonej przed Phoenix 1.8 te same reguły wygenerujesz z zależności za pomocą usage_rules: dodaj {:usage_rules, "~> 1.2", only: [:dev]}, ustaw usage_rules: [file: "AGENTS.md", usage_rules: [:elixir, :otp, "phoenix:ecto", "phoenix:liveview"]] w project/0 i uruchom mix usage_rules.sync. Synchronizacja przy każdym uruchomieniu nadpisuje własną sekcję, więc reguły nadążają za mix.lock, gdy zależność dostarczy nowe.

Potem dopisz do AGENTS.md, pod wygenerowanym blokiem, linie specyficzne dla projektu:

AGENTS.md (your additions)

## Commands
- One test or file: `mix test test/shop/orders_test.exs:42`
- Failures from the last run: `mix test --failed`
- Full gate: `mix precommit` (compile, format, Credo, Sobelow, tests)

## Definition of done
`mix precommit` passes. Report the command you ran and its last lines.

## Rules
- Generate contexts, schemas and migrations with `mix phx.gen.*` and `mix ecto.gen.migration`, never by hand.
- Tests are the specification. If a test fails, fix lib/, not test/. Ask before changing an assertion.
- Never call an external service inside `Repo.transaction` or `Ecto.Multi`.
- Money is integer cents or `Decimal`, never float.

Każde narzędzie wczytuje ten plik inaczej:

Claude Code

Utwórz CLAUDE.md, którego pierwsza linia to @AGENTS.md, a poniżej dopisz linie przeznaczone tylko dla Claude. Claude Code od wersji 2.1.277 czyta też AGENTS.md bezpośrednio, gdy projekt nie ma CLAUDE.md (oba kanały wydań, stan na 2026-10-12); import działa w każdej wersji i na każdym kanale.

Codex

Codex czyta AGENTS.md, zanim zacznie pracę. Od codex-cli 0.150.0 projekt, któremu Codex nie ufa, nie dostarcza swojego AGENTS.md, więc oznacz repozytorium jako zaufane, gdy Codex o to zapyta.

Cursor

Dodaj zawsze stosowaną regułę projektu (format opisuje strona reguły projektu w Cursorze), która powtarza sekcje Commands, Definition of done i Rules oraz wygenerowane reguły LiveView i Ecto, na których polegasz. Zacommituj regułę razem z repozytorium.

Prompt do skopiowania: szkic AGENTS.md dla istniejącej aplikacji Phoenix

Read mix.exs, mix.lock, .tool-versions (or mise.toml), config/config.exs, config/test.exs, test/test_helper.exs, test/support/*.ex and .credo.exs if present, and list the directories under lib/ and test/. Write AGENTS.md with: (1) one line naming the Elixir, OTP, Phoenix, LiveView and Ecto versions and the database; (2) the exact commands for one test, failed tests only, format, and the full gate, as they work in THIS repo; (3) a "Definition of done" line that names mix precommit (add the alias if it is missing: compile --warnings-as-errors, deps.unlock --unused, format, test); (4) at most eight rules, each a convention you can see this codebase follows and a generic Elixir model would get wrong. Do not restate what mix format or Credo already enforce. Run every command you list and tell me which ones failed.

Wspólne reguły agentów wyjaśniają, jak utrzymać jedno źródło prawdy, gdy zespół używa wszystkich trzech narzędzi.

Jak dać agentowi dostęp do działającej aplikacji Phoenix?

Agent, który umie tylko czytać pliki, zgaduje, co zwraca Orders.list_orders/1 i co zalogowało ostatnie żądanie. Tidewave to otwartoźródłowy serwer MCP od Dashbit, który działa wewnątrz twojej aplikacji Phoenix w środowisku deweloperskim. Udostępnia project_eval (wykonanie kodu Elixira w działającej aplikacji), execute_sql_query (na bazie deweloperskiej), get_logs, get_source_location oraz get_docs, który czyta dokumentację dokładnie tych wersji, które są w mix.lock.

Zainstaluj go poleceniem mix igniter.install tidewave (po mix archive.install hex igniter_new) albo dodaj {:tidewave, "~> 0.9", only: :dev} i wstaw plug Tidewave w blok if Mix.env() == :dev do tuż nad if code_reloading? do w lib/my_app_web/endpoint.ex. Uruchom serwer poleceniem mix phx.server, a potem podłącz swoje narzędzie (4000 to domyślny port Phoenix):

Claude Code

claude mcp add --transport http tidewave http://localhost:4000/tidewave/mcp

Sprawdź połączenie poleceniem /mcp w sesji. Tidewave 0.9.1 nie ma uwierzytelniania (domyślnie przyjmuje tylko połączenia z localhost), więc nie wybieraj Authenticate.

Codex

codex mcp add tidewave --url http://localhost:4000/tidewave/mcp

codex mcp list pokazuje wpis, ale nie testuje połączenia; uruchom /mcp w TUI, żeby zobaczyć narzędzia.

Cursor

.cursor/mcp.json

{
  "mcpServers": {
    "tidewave": { "url": "http://localhost:4000/tidewave/mcp" }
  }
}

Otwórz nowy czat i poproś agenta o listę narzędzi Tidewave.

Różnica „przed i po” jest konkretna. Bez Tidewave agent czyta stack trace, poprawia changeset i ponownie uruchamia testy. Z nim wywołuje Shop.Orders.create_order/2 z problematycznymi danymi w działającej aplikacji, czyta powstałą linię logu i wiersz w tabeli orders, a potem poprawia kod raz. Tidewave domyślnie przyjmuje tylko połączenia lokalne i nigdy nie może działać na produkcji.

Jak powstrzymać agenta przed ogłoszeniem „gotowe”, zanim testy przejdą?

Instrukcja w AGENTS.md to rada. Hook albo kontrola w CI to bramka. Claude Code dostaje lokalną bramkę w postaci hooka Stop. Konfiguracje Codeksa i Cursora poniżej to wciąż instrukcje, więc dla nich jedyną mechaniczną bramką jest job CI pod zakładkami.

Claude Code

Hook Stop uruchamia się, gdy Claude kończy odpowiedź. Kod wyjścia 2 blokuje zakończenie i pokazuje Claude’owi stderr hooka, więc Claude pracuje dalej:

.claude/hooks/elixir-gate.sh

#!/usr/bin/env bash
# Refuse "done" until mix precommit passes.
input=$(cat)
# Already continuing because of this hook: stop and report instead of looping.
[ "$(echo "$input" | jq -r '.stop_hook_active')" = "true" ] && exit 0
cd "$CLAUDE_PROJECT_DIR" || exit 0
# Nothing under lib, test, config or priv changed: nothing to check.
[ -z "$(git status --porcelain -- lib test config priv mix.exs mix.lock)" ] && exit 0
if ! out=$(mix precommit 2>&1); then
  echo "mix precommit failed. Fix lib/, never test/. Re-run failures with mix test --failed:" >&2
  echo "$out" | tail -40 >&2
  exit 2
fi
exit 0

Zarejestruj skrypt w .claude/settings.json w hooks → Stop jako handler typu command wskazujący na ${CLAUDE_PROJECT_DIR}/.claude/hooks/elixir-gate.sh z "timeout": 600 i nadaj mu prawo wykonywania. Skrypt wymaga jq. Ponieważ kończy się kodem 0, gdy stop_hook_active ma wartość true, padająca bramka wymusza jedną poprawkę, a potem Claude raportuje, zamiast krążyć w pętli nad testem, który nie może przejść, na przykład gdy PostgreSQL nie działa. mix precommit uruchamia format, więc hook przy okazji przeformatowuje pliki. Automatyzacja hookami pokazuje pełny blok ustawień i sposób na więcej prób.

Codex

Zanim uruchomisz codex exec, otwórz repozytorium raz w interaktywnym codex i oznacz je jako zaufane, inaczej przebieg nie wczyta AGENTS.md. Pobierz zależności poza agentem (Hex potrzebuje sieci), a potem uruchom pętlę:

mix deps.get
codex exec --approve-for-me "Implement Shop.Orders so every test in test/shop/orders_test.exs passes. Do not modify anything under test/. Finish only when 'mix precommit' passes; print its last lines."

--approve-for-me uruchamia sesję w sandboksie workspace-write i kieruje prośby o zgodę, na przykład na polecenie, które musi połączyć się z bazą testową poza sandboksem, do automatycznego przeglądu Codeksa, zamiast czekać na ciebie. Prompt pozostaje instrukcją: nic nie powstrzyma sesji przed zakończeniem na czerwono. Mechaniczną bramką dla Codeksa jest job CI poniżej.

Cursor

Wklej prompt implementacyjny do agenta, najpierw w Plan Mode, jeśli zmiana dotyka naraz kontekstu, schematu i migracji. Wpisz definicję ukończenia do reguły projektu, żeby agent uruchomił mix precommit, zanim zgłosi wynik. Reguła to też tylko rada. Mechaniczna bramka Cursora działa po otwarciu pull requesta: to job CI poniżej oraz Bugbot, jeśli twój zespół używa go do przeglądów.

Niezależnie od tego, co działało lokalnie, decyduje CI. Uruchom tam te same kontrole z tokenem tylko do odczytu i jednorazową usługą PostgreSQL:

.github/workflows/elixir-gates.yml

name: elixir-gates
on:
  pull_request:
    types: [opened, synchronize, reopened, labeled, unlabeled]
permissions:
  contents: read
jobs:
  gates:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:17
        env:
          POSTGRES_HOST_AUTH_METHOD: trust  # disposable CI database, no credential
        ports: ["5432:5432"]
        options: --health-cmd="pg_isready" --health-interval=10s --health-timeout=5s --health-retries=5
    env:
      MIX_ENV: test
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
          fetch-depth: 2   # the PR merge commit and its base parent
      - name: Existing tests unchanged
        if: ${{ !contains(github.event.pull_request.labels.*.name, 'test-change-approved') }}
        run: |
          changed=$(git diff --name-only --diff-filter=MDR HEAD^1 HEAD -- test/)
          if [ -n "$changed" ]; then
            echo "Existing tests modified, moved or deleted; a reviewer must add the test-change-approved label:"
            echo "$changed"
            exit 1
          fi
      - uses: erlef/setup-beam@v1
        with:
          otp-version: "29.1.1"
          elixir-version: "1.20.4"
      - uses: actions/cache@v6
        with:
          path: |
            deps
            _build
          key: mix-${{ runner.os }}-${{ hashFiles('mix.lock') }}
      - run: mix deps.get
      - run: mix deps.unlock --check-unused
      - run: mix hex.audit      # retired packages
      - run: mix deps.audit     # known advisories (mix_audit)
      - run: mix format --check-formatted
      - run: mix compile --warnings-as-errors
      - run: mix credo --strict
      - run: mix sobelow --exit Low --skip
      - run: mix ecto.create && mix ecto.migrate && mix ecto.rollback --step 1 && mix ecto.migrate
      - run: mix test --warnings-as-errors

Krok „Existing tests unchanged” pada, gdy pull request modyfikuje, przenosi lub usuwa plik, który już istnieje w test/; nowe pliki testów przechodzą. Gdy człowiek przejrzy zmianę testu, dodaje etykietę test-change-approved, co uruchamia nowy przebieg z pominięciem tego kroku (ponowne uruchomienie starego joba nie zadziała, bo używa pierwotnego zdarzenia). Krok jest bramką tylko wtedy, gdy pull request nie może go usunąć: GitHub uruchamia plik workflow z samego pull requesta, więc obejmij /.github/ regułą CODEOWNERS i wymuś tę recenzję przez ochronę gałęzi lub ruleset. Krok z rollbackiem dowodzi, że najnowsza migracja jest odwracalna. Wygenerowane aplikacje Phoenix domyślnie łączą się jako użytkownik postgres, którego usługa z metodą trust akceptuje.

Które receptury Phoenix warto przekazać agentowi?

Każdy prompt poniżej zakłada AGENTS.md i bramkę opisane wyżej. Każdy zaczyna od testów, bo test napisany przez agenta przed kodem to najtańsza wyrocznia, jaką masz.

Zbuduj kontekst i API JSON w trybie test-first

Poproś o polecenie generatora i wyłącznie o padające testy, sprawdź, czy nowe testy padają z właściwego powodu, a o implementację poproś w drugim prompcie. Rozdzielenie tur powstrzymuje agenta przed pisaniem testów dopasowanych do własnego kodu.

Prompt do skopiowania: padające testy dla kontekstu Tasks i API JSON

We are adding a Tasks context and JSON API. Do not hand-write anything under lib/ in this turn. First propose the exact mix phx.gen.json command for a Task schema (title string, status enum todo/in_progress/done/cancelled, priority enum low/medium/high, due_date date) and wait for my OK. After I approve and you run it, add ONLY tests for the behaviour the generator does not cover: in test/shop/tasks_test.exs cover title required and 3..200 characters, the status transition done -> todo returning {:error, changeset} with an error on :status, due_date not in the past, and list_tasks/1 filtering by status and priority. In test/shop_web/controllers/task_controller_test.exs cover 201, 422 with errors rendered as {"errors": {"title": ["can't be blank"]}}, and 404. Run mix test on both files and show me each failure message. Stop there.

Prompt do skopiowania: implementuj, aż bramka przejdzie

Implement the Tasks context, schema changeset and controller so every test in test/shop/tasks_test.exs and test/shop_web/controllers/task_controller_test.exs passes. Do not modify anything under test/. Put the status-transition rule in a custom changeset validation, not in the controller. Build list_tasks/1 from small composable query functions (filter_by_status/2, filter_by_priority/2) that each take and return a queryable. Use mix test --failed while iterating. Finish only when mix precommit passes, and paste its last lines.

Zachowaj w pierwszym prompcie krok zatwierdzenia: mix phx.gen.json tworzy naraz kontekst, schemat, migrację, kontroler i testy, a zatwierdzenie jednego polecenia kosztuje mniej niż przegląd plików, które ono wygeneruje.

Zbuduj LiveView, który nie rośnie bez ograniczeń

Starszy kod trzyma listy w assigns albo używa temporary_assigns; reguły generowane przez Phoenix 1.8 każą agentowi używać strumieni dla kolekcji i unikać LiveComponentów bez konkretnej potrzeby. Egzekwuj je.

Prompt do skopiowania: panel zamówień na żywo ze strumieniami

Build ShopWeb.OrdersDashboardLive at /admin/orders. In mount/3, subscribe to the "orders" PubSub topic only when connected?(socket), assign counts as plain assigns, and put the 20 most recent orders in a stream (stream(socket, :orders, orders)). Handle {:order_created, order} in handle_info/2 with stream_insert(socket, :orders, order, at: 0, limit: 20). Add a search input with phx-change and phx-debounce="300" that re-fetches and re-streams with reset: true. Use function components, not LiveComponents. Give every element a test needs a DOM id. Tests in test/shop_web/live/orders_dashboard_live_test.exs: the page renders the latest orders; broadcasting {:order_created, order} makes #orders-#{order.id} appear; search filters the list. Use has_element?/2 and element/2, never assertions on raw HTML. Finish when mix precommit passes.

Pisz kod OTP, któremu testy mogą ufać

Problemem rzadko jest sam GenServer; problemem jest test. Agent, który czeka za pomocą Process.sleep/1, tworzy zestaw testów przechodzący na laptopie i niestabilny w CI.

Prompt do skopiowania: limiter zapytań na ETS bez wąskiego gardła w GenServerze

Implement Shop.RateLimiter for per-user limits. A GenServer owns a public named ETS table (read_concurrency and write_concurrency on) and runs a cleanup message every 60 seconds; callers increment with :ets.update_counter/4 in their own process, so the GenServer is not on the request path. API: check(user_id, limit, window_ms) returns :ok or {:error, :rate_limited, retry_after_ms}. Take the current time from an injectable clock function so tests control it. Start it under the application supervisor. Add ShopWeb.Plugs.RateLimit that returns 429 with a Retry-After header. Limits are per node; say so in the moduledoc. Tests: start the limiter with start_supervised!/1, never Process.sleep/1; synchronise with :sys.get_state/1 before asserting on cleanup; cover the limit, the window reset (advance the fake clock) and the 429 response. Finish when mix precommit passes.

Trzymaj wywołania zewnętrzne poza transakcjami Ecto

Transakcja, która woła bramkę płatności, trzyma połączenie z bazą przez cały sieciowy round trip i nie potrafi wycofać obciążenia, które się powiodło. Powiedz agentowi, gdzie przebiega granica.

Prompt do skopiowania: tworzenie zamówienia z Ecto.Multi

Implement Shop.Orders.create_order(user, items) with Ecto.Multi and Repo.transaction/1. Steps: insert the order with status :pending_payment; insert the items with unit prices copied from the products; decrement stock for each product with one Repo.update_all per product whose query has where: p.id == ^id and p.stock >= ^qty, and fail the Multi with {:out_of_stock, product_id} when the returned row count is 0. Do not call the payment gateway inside the Multi. After the transaction commits, enqueue Shop.Workers.ChargeOrder (Oban) with the order id; that worker charges and marks the order paid or cancelled and restocks. Map Multi failures to {:error, :out_of_stock, product_id} or {:error, changeset}. Tests: happy path, insufficient stock rolls back every insert, and two concurrent orders for the last unit (Task.async in a non-async test with the sandbox in shared mode) where exactly one succeeds. Finish when mix precommit passes.

Dodaj zadania w tle z Obanem

Prompt do skopiowania: worker Obana z unikalnymi zadaniami

Add Oban to this app if it is not configured: queues default: 10, mailers: 5; in config/test.exs set testing: :manual. Write Shop.Workers.OrderEmail (queue :mailers, max_attempts: 5) that sends the order confirmation through the existing Swoosh mailer, with unique: [period: 60, keys: [:order_id, :template]] so a retry storm cannot double-send. Return {:cancel, reason} when the order no longer exists instead of raising. Enqueue it in the same Multi that marks an order paid (Oban.insert/3 as a Multi step), so the job exists only if the transaction commits. Tests: use Oban.Testing, repo: Shop.Repo; perform_job/3 for the success and cancel paths; assert_enqueued/1 after the order is paid; a second insert inside 60 seconds does not create a second job. Finish when mix precommit passes.

Wydaj release, o którym agent udowodni, że się uruchamia

mix phx.gen.release --docker generuje lib/my_app/release.ex, rel/overlays/bin/migrate, rel/overlays/bin/server, Dockerfile i .dockerignore. Dockerfile buduje się z debianowego obrazu hexpm/elixir przypiętego do wersji Elixira i OTP, z którymi go wygenerowano. Pozwól generatorowi napisać pliki, a od agenta zażądaj dowodu, że działają. Utwardzanie kontenera wykraczające poza to opisują wzorce Dockera.

Prompt do skopiowania: wygeneruj i zweryfikuj release w Dockerze

Run mix phx.gen.release --docker. Do not rewrite the generated Dockerfile; only add a HEALTHCHECK that calls GET /health, and add that route (plain 200, no database call). Check config/runtime.exs raises a clear error when DATABASE_URL, SECRET_KEY_BASE or PHX_HOST is missing. Then prove it: build the image, start a throwaway postgres container on a user-defined network, run the image's /app/bin/migrate, start /app/bin/server, and curl /health until it returns 200 or 60 seconds pass. Paste the commands you ran, the migrate output and the curl result. Remove the containers afterwards.

Skąd wiesz, że testy agenta złapałyby błąd?

Zielone testy napisane przez agenta dowodzą tylko tego, że kod zgadza się z agentem. Trzy tanie kontrole podnoszą poprzeczkę bez czytania każdej linii:

• Testy właściwości dla changesetów i czystych funkcji. Dodaj {:stream_data, "~> 1.4", only: :test} i poproś: „For Task.changeset/2, write ExUnitProperties properties: any title shorter than 3 characters is invalid; any valid attrs round-trip through create_task/1 and get_task!/1; no status transition out of :done except to :cancelled is valid.” Właściwości generują dane wejściowe, o których agent nie pomyślał. Metodę opisuje strona testy oparte na właściwościach.
• Zepsuj kod celowo. W osobnej sesji poproś agenta, żeby wprowadził po jednym błędzie w każdej funkcji kontekstu (odwrócone porównanie, usunięty where, pominięta walidacja) i po każdym uruchomił testy. Każdy błąd, którego testy nie złapią, oznacza brakujący test; zatrzymaj testy, odrzuć błędy.
• Polowanie na niestabilne testy. mix test --repeat-until-failure 50 test/shop/rate_limiter_test.exs (Elixir 1.17+) powtarza plik, aż test padnie, co ujawnia wyścigi z Process.sleep i współdzielonym stanem, które zostawił agent.

Potem zdecyduj, co nadal przegląda człowiek:

Zmiana	Czym udowodniona	Akceptacja człowieka
Funkcje kontekstu, changesety, kontrolery, LiveView	Testy napisane przed kodem, mix precommit, CI	Niepotrzebna, gdy bramki przechodzą, a istniejące testy są nietknięte
Zmodyfikowane istniejące testy	Etykieta test-change-approved	Tak: osoba, która dodaje etykietę
Migracje, które usuwają, zmieniają nazwy lub uzupełniają dane	Krok rollbacku w CI	Tak: sprawdź czas blokad i utratę danych (zobacz wzorce migracji)
Drzewo nadzoru i strategia restartu	Testy, które zabijają proces potomny i sprawdzają, że rodzeństwo przetrwało	Tak: zła strategia wychodzi dopiero pod obciążeniem
Uwierzytelnianie, autoryzacja, raw/1 w szablonach	Sobelow, testy ścieżek odmowy	Tak

Dołącz wynik mix precommit i przebieg CI do pull requesta jako jego pakiet dowodów, żeby recenzent sprawdzał dowody, a nie kod.

Co się psuje, gdy agenci piszą kod w Elixirze?

Test przechodzi lokalnie i pada w CI

Objaw: test GenServera lub LiveView jest zielony na laptopie i czerwony co jakiś czas w CI. Przyczyna: Process.sleep/1 użyte do synchronizacji albo proces uruchomiony przez start_link poza start_supervised!/1, który przecieka do następnego testu. Naprawa: ponów prompt słowami „Replace every Process.sleep in test/ with Process.monitor plus assert_receive, or :sys.get_state/1; start every process with start_supervised!/1”, a potem udowodnij poprawkę przez mix test --repeat-until-failure 50 na tym pliku.

Pamięć LiveView rośnie z każdym podłączonym użytkownikiem

Objaw: pamięć procesu LiveView rośnie z każdym nowym zamówieniem. Przyczyna: agent trzyma listę w assigns albo dopisuje do niej w handle_info/2. Naprawa: „Move the collection to a stream with a limit, keep counts as separate assigns, and re-stream with reset: true for filters.” Wygenerowane reguły LiveView już to mówią, więc sprawdź, czy agent wczytał AGENTS.md.

Równolegli agenci kolidują na bazie testowej lub porcie 4000

Objaw: dwóch agentów w osobnych worktree dostaje błędy database ... already exists, losowe błędy własności połączeń albo eaddrinuse. Przyczyna: obaj używają tej samej bazy shop_test i tego samego portu deweloperskiego. Naprawa: wygenerowany config/test.exs dokleja MIX_TEST_PARTITION do nazwy bazy testowej, więc daj każdemu worktree własną wartość (MIX_TEST_PARTITION=2 mix test) i własny PORT. Dla Tidewave w wielu worktree README proponuje mix tidewave.proxy jako serwer MCP typu stdio, który dodaje parametr portu do każdego narzędzia.

Tidewave wykonuje kod poza sandboksem agenta

Objaw: żaden, dopóki nie zacznie to mieć znaczenia. Przyczyna: project_eval i execute_sql_query wykonują się w procesie twojego serwera Phoenix, a nie w sandboksie Claude Code czy Codeksa, więc agent w sandboksie wciąż może przez nie zapisywać do bazy deweloperskiej albo wołać zewnętrzne API. Naprawa: trzymaj Tidewave tylko w :dev, kieruj konfigurację deweloperską na lokalne usługi i testowe dane dostępowe oraz wymagaj zgody na te dwa narzędzia (na przykład regułą uprawnień ask dla mcp__tidewave__project_eval w Claude Code).

Test zmieniony tak, żeby pasował do błędu

Objaw: diff dotyka test/ w tym samym commicie, który poprawia lib/, i oczekiwana wartość się przesunęła. Przyczyna: agent optymalizował pod zielony wynik. Naprawa: zachowaj krok CI „Existing tests unchanged”, oddaj test/ pod CODEOWNERS i trzymaj zdanie „Do not modify anything under test/” w każdym prompcie implementacyjnym. Pozostałe mechaniczne opcje opisuje ochrona wyroczni.

Wyciszenia zamiast poprawek

Objaw: bramki są zielone, a diff dodaje # credo:disable-for-next-line, wpis w .sobelow-skips albo @dialyzer :nowarn_function. Naprawa: przypisz te pliki i wzorce właścicielowi-człowiekowi w CODEOWNERS i ponów prompt: „Remove the suppression you added and fix the underlying issue. If it is a false positive, explain why in the pull request.”

Dokąd dalej z Elixirem i agentami

Receptury backendowe Pozostałe stosy backendowe z tym samym podejściem: najpierw bramki.

Ochrona wyroczni Nie pozwól agentom edytować testów, które je oceniają.

Wzorce migracji baz danych Zmiany expand-and-contract i rollbacki dla migracji Ecto.

Wzorce Dockera Utwardź i przeskanuj wygenerowany obraz release'u.

Pakiet dowodów Co pull request od agenta musi udowodnić przed przeglądem.

Receptury Ruby on Rails Te same bramki i pętle dla Rails.