Pure permission logic for admin access control.

This namespace contains pure business logic for determining admin access
permissions. All functions are pure (no side effects) and testable without
database or session state.

Week 1 Implementation:
- Simple role-based access control (RBAC) using :admin role
- All permission checks verify user has :admin role
- Foundation for more complex permissions in Week 2+

Week 2+ Roadmap:
- Entity-level permissions (some entities admin-only, others viewable by all)
- Action-level permissions (some users can view but not edit)
- Field-level permissions (hide sensitive fields for certain roles)
- Permission groups and hierarchies

Key responsibilities:
- Determine if user can access admin interface
- Determine if user can perform operations on entities
- Filter entity lists based on permissions
- Provide permission metadata for UI rendering

Pure functions for database schema introspection and entity configuration.

This namespace contains pure business logic for transforming raw database
metadata into UI-friendly entity configurations. All functions are pure
(no side effects) and testable without database connections.

Key responsibilities:
- Parse database column metadata into field configurations
- Infer appropriate UI widgets from database types
- Detect relationships and foreign keys
- Merge auto-detected configuration with manual overrides
- Generate sensible defaults for labels and field ordering

Admin UI components using Hiccup for server-side HTML generation.

This namespace is a thin FACADE: the implementation lives in focused
sibling namespaces under `boundary.admin.core.ui.*`. Every public function
consumers rely on is re-exported here so `admin-ui/entity-list-page`,
`ui/format-field-label`, etc. keep resolving unchanged.

Implementation namespaces:
- `boundary.admin.core.ui.base`           — shared URL/field/column primitives
- `boundary.admin.core.ui.layout`         — shell, sidebar, home, error pages, dialog
- `boundary.admin.core.ui.list`           — entity list page, table, rows, search
- `boundary.admin.core.ui.filters`        — advanced filter builder
- `boundary.admin.core.ui.inline-editing` — inline (double-click) cell editing
- `boundary.admin.core.ui.detail`         — detail/edit page, form, field grouping

See each impl namespace for the original docstrings on these functions.

Shared admin UI primitives used across multiple ui.* sections.

Leaf namespace: URL helpers, field-value rendering, list-column width
heuristics, and small formatting/label utilities. Must NOT require any
other boundary.admin.core.ui.* implementation namespace — it is the
dependency root that the focused sections build on.

Entity detail/edit page components: form widgets, field grouping, the
entity form, parent-context/related-records tables, and the detail page.

Pure Hiccup generators. Depends on `base` for URL and field helpers.

Advanced filter builder components for admin entity lists.

Pure Hiccup generators for the filter UI: operator selection per field
type, value inputs, filter rows, and the overall filter builder.

Inline (double-click) table-cell editing components.

Pure Hiccup generators for the editable-cell display mode, the inline
edit form, and the inline edit form with a validation error.

Admin shell/layout, error pages, confirmation dialog, and URL utilities.

Pure Hiccup generators for the admin chrome: sidebar navigation, the
collapsible shell + topbar, the dashboard home, 403/404 error pages, the
delete-confirmation modal, and the `build-table-url` helper.

Entity list-page components: search form, table rows, table, and the
complete list page (toolbar + filter builder + table).

Pure Hiccup generators. Depends on `base` for URL helpers, field-value
rendering, and column sizing, and on `filters` for the filter builder.

Admin module port definitions (abstract interfaces).

This namespace defines all ports (abstract interfaces) that the admin module
needs to provide auto-generated CRUD interfaces and administrative operations.
These ports follow Boundary's hexagonal architecture pattern, allowing core
business logic to remain pure and testable while enabling flexible adapter
implementations.

Port Categories:
- Schema Introspection Ports (ISchemaProvider)
- Admin Service Ports (IAdminService)
- Action Executor Ports (IActionExecutor)

Each port is implemented by adapters in the shell layer, enabling dependency
inversion and supporting multiple database backends (PostgreSQL, SQLite, MySQL, H2).

Malli schemas for admin module configuration and entities.

This namespace defines all schemas used by the admin module for:
- Admin module configuration and settings
- Entity configuration and metadata
- Field-level configuration
- Validation and transformation

All schemas follow Malli specifications and include documentation
for auto-generated validation and error messages.

HTTP routes for the admin interface.

This namespace wires the admin panel's normalized web routes to their
handlers. Handlers live in `boundary.admin.shell.http.handlers.*` and their
shared plumbing (middleware, error mappings, query/form parsing, handler
helpers) lives in `boundary.admin.shell.http.support`.

The admin UI provides:
- Entity list pages with search, sort, and pagination
- Entity detail/edit pages with forms
- Create and update handlers with validation
- Delete and bulk delete operations
- HTMX fragment handlers for dynamic updates

All routes require authentication and admin role.
Routes follow normalized format for consistent interceptor application.

Create / update entity handlers.

Delete + bulk-delete entity handlers.

Entity detail / edit page handlers (view existing + new-entity form).

Inline editing handlers (Week 2): per-field edit widget, update, cancel.

Admin home + entity list handlers.

Renders the dashboard, the entity list page, and the HTMX table fragment.

Shared plumbing for the admin HTTP layer.

Leaf namespace requiring no handler or route namespaces. Provides the
error mappings, query/form parsing, and handler helpers used by the handler
namespaces and the route definitions in `boundary.admin.shell.http`.

Integrant lifecycle management for admin module.

This namespace defines Integrant initialization and shutdown methods
for all admin module components:
- Schema provider (ISchemaProvider implementation)
- Admin service (IAdminService implementation)
- Admin routes (HTTP routes)

Dependencies are injected via Integrant refs, maintaining FC/IS separation
and enabling testability with mock implementations.

Permission assertions for admin access control.

These wrappers throw typed `ex-info` (`:type :forbidden`) when a permission
check fails, so they live in the shell — the pure decision logic (the
`can-*?` predicates and `explain-admin-access-denial`) stays in
`boundary.admin.core.permissions`. HTTP handlers call these guards; the
platform error interceptor maps `:forbidden` to a 403 response.

Schema repository implementation for database metadata retrieval.

This namespace provides the concrete implementation of ISchemaProvider,
connecting to the database through existing adapter protocols to fetch
table and column metadata.

Responsibilities:
- Fetch raw database metadata using adapter protocols
- Coordinate with pure core functions for parsing and merging
- Cache entity configurations for performance
- Provide entity discovery based on configuration

Caching: computed entity configurations are cached in an atom inside the
long-lived SchemaRepository component (populated on first access). Table
schemas only change at migration/deploy time, so the cache lives as long
as the component. Use `reset-cache!` (or recreate the component via
(ig-repl/reset)) to invalidate after a migration.

Admin service implementation for CRUD operations on entities.

This service provides database-agnostic CRUD operations on any entity
managed by the admin interface. It coordinates between schema providers,
permission checks, and database operations.

Responsibilities:
- Execute CRUD operations with observability
- Apply pagination, filtering, sorting
- Validate permissions and entity access
- Transform data between DB and application formats
- Handle soft/hard deletes based on schema