Elixir New Context

Build a context

Read portal/AGENTS.md and sections 1–5, 7, and 8 of portal/.agent/kb/rules/elixir-layered-contexts.md before scaffolding. Those fictional Widgets templates own the module shapes. Inspect the surrounding implementation for the actual domain; do not duplicate the templates in this skill.

Confirm the concept belongs in a new context rather than an existing one. Preserve the user's requested behavior and continue under their implementation authority.

Create the migration, schema, query, changeset, authorizer, context API, and tests. Honor production-applied migration immutability, UUID keys, soft-delete filtering, DB constraints, composable queries, pure changesets, and fail-closed row scope. Register the authorizer in lib/emisar/auth/permissions.ex so its permissions reach the Subject. Verify existing roles in Emisar.Auth.Role and neighboring authorizers.

Public functions state permission and tagged-return contracts. Required Subject arguments come last; callers authorize and scope through the context. Read the reference's internal/self-service exceptions before choosing a different shape.

Use the real domain-namespaced Fixtures modules in test/support, with separate happy, denial, and cross-account cases for the API behavior. Match existing test order and arrange only the state each case requires.

Use focused tests while implementing. The lead runs ./run gate portal --changed and obtains a trust-boundary review before committing, then runs the complete ./run gate portal before pushing. Complete all requested layers; a context-only request does not itself authorize adding a LiveView.