mir-backend-beam-phoenixlisted

Make It Right (Phoenix module). Phoenix + LiveView + Ecto + PostgreSQL specific reliability augmentation. Use alongside mir-backend and mir-backend-beam when the target stack is Phoenix — it carries the mechanical footguns that the framework-agnostic tiers deliberately omit: LiveView per-connection process memory scaling and temporary_assigns/streams for large collections, blocking the LiveView process in handle_event freezing the client, Ecto N+1 with unloaded associations raising DetachedInstanceError, migration safety on populated tables (create index concurrently, disable_ddl_transaction!, expand/contract for NOT NULL), PubSub fan-out backpressure, and idempotent handle_event for double-click races. TRIGGER only when the BEAM backend stack is Phoenix — building, reviewing, or debugging a Phoenix controller, LiveView, Ecto query, or migration. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-beam (BEAM runtime concerns: supervision, mailbox growth, GenServer bottlenecks, ETS, distributed
anantbhandarkar/make-it-right · ★ 12 · API & Backend · score 85

Install: claude install-skill anantbhandarkar/make-it-right

# /mir-backend-beam-phoenix · Make It Right (Phoenix) Bottom tier of the chain: `mir-backend` (generic gates) → `mir-backend-beam` (BEAM/Erlang VM process model) → **this** (Phoenix/Ecto/LiveView library mechanics). Run the gates first; load the BEAM runtime tier for supervision, mailbox, and ETS concerns; reach for *this* at Gate 5 (design mechanics), Gate 6 (implementation), and Gate 7 review. **Runtime-level concerns (supervision trees, unbounded mailboxes, GenServer bottlenecks, ETS, distributed Erlang) live in `mir-backend-beam` — not here.** **Stack assumed:** Phoenix 1.7+ · LiveView 0.20+ · Ecto 3.x · PostgreSQL · PubSub. If the project uses Ecto with a different adapter, note the divergence before applying migration-safety items. ## The Phoenix footguns AI walks into most ### 1. LiveView state is per-connection — memory scales with concurrent users Each connected LiveView client is a **stateful process** holding all socket assigns in its heap. Storing large collections (a paginated list of thousands of records, a full dataset) in assigns means that memory multiplies by the number of connected users. - **Use `temporary_assigns`** (Phoenix 1.6 and earlier patterns) to tell LiveView that a key should be reset to its default after each render — the data is not kept in the socket between diffs. - **Use LiveView streams** (Phoenix 1.7+ `stream/3` and `stream_insert/4`) for large, dynamically updating collections. Streams keep only the rendered DOM diff state server-si