Pure functions for creating audit log entries.

This namespace contains CORE (pure) functions for audit trail management.
In FC/IS architecture, this is the CORE that:
- Contains pure business logic for audit entry creation
- No side effects - returns data structures only
- All I/O is delegated to shell layer (persistence)

Key FC/IS principles:
- Pure functions only - deterministic, no side effects
- Returns data that shell layer will persist
- Business rules for what gets audited and how

Functional Core - Pure authentication business logic.

This namespace contains ONLY pure functions for authentication:
- Credential validation logic
- Authentication decision making
- Login attempt analysis
- Account lockout logic

All functions are pure and deterministic - no I/O operations.
Password hashing and token operations are handled in the shell layer.

Functional Core - Pure MFA business logic.

This namespace contains ONLY pure functions for MFA:
- MFA decision logic (when to require MFA)
- Backup code validation logic
- MFA setup preparation
- MFA status evaluation

All functions are pure and deterministic - no I/O operations.
TOTP generation and cryptographic operations are handled in the shell layer.

Profile-specific UI components for user profile management.

This namespace contains pure functions for generating profile-related Hiccup
structures including profile viewing, editing, password changes, and MFA setup.

Functional Core - Pure session business logic - Minimal working version

User-specific UI components based on User schema.

This namespace contains pure functions for generating user-related Hiccup
structures. Components are derived from the User schema and handle
user-specific business logic for display and forms.

Functional Core - Pure user business logic.

This namespace contains ONLY pure functions with no side effects:
- No I/O operations (no database calls, no logging, no HTTP)
- No external dependencies (time, random generation, etc.)
- Deterministic behavior (same input always produces same output)
- Immutable data structures only

All business rules and domain logic for users belong here.
The shell layer orchestrates I/O and calls these pure functions.

Enhanced domain validation functions for user business rules.

This namespace contains comprehensive validation functions that implement
business rules beyond basic schema validation. All functions are pure
and follow FC/IS architectural principles.

User module port definitions (abstract interfaces).

This namespace defines all ports (abstract interfaces) that the user module
needs to interact with external systems and services. These ports follow
Boundary's hexagonal architecture pattern, allowing core business logic to
remain pure and testable while enabling flexible adapter implementations.

Ports:
- IUserRepository        — user persistence
- IUserSessionRepository — session persistence
- IUserAuditRepository   — audit-log persistence
- IUserService           — user service facade

Each port is implemented by adapters in the shell layer, enabling dependency
inversion and supporting multiple implementations (PostgreSQL, H2, in-memory, etc.).

Cross-cutting concerns (email, notifications, events, audit, time) are NOT
defined here — email lives in libs/email, observability owns logging/metrics/
audit. Previously-dead duplicate protocols were removed in BOU-170.

Shell Layer - Authentication service with side effects.

This is the SHELL layer for authentication operations:
- Password hashing and verification (bcrypt)
- JWT token creation and validation
- Session token generation
- Authentication coordination
- MFA verification

All I/O and side effects happen here. Pure business logic
is delegated to boundary.user.core.authentication.

Authentication persistence layer - manages public.auth_users table.

This namespace handles persistence for global authentication credentials
in the schema-per-tenant multi-tenancy architecture (ADR-004).

Table: public.auth_users (shared across all tenants)
Contains: email, password_hash, mfa_*, failed_login_count, lockout_until, active

Usage:
- Login authentication (verify email + password)
- MFA operations (setup, enable, disable, verify)
- Account security (lockout, failed login tracking)
- Password management (reset, change)

Does NOT contain:
- User profile data (name, role, avatar) → in tenant_<slug>.users
- Tenant-specific settings → in tenant_<slug>.users

CLI commands for user management.

This is the SHELL layer in Functional Core / Imperative Shell architecture.
Responsibilities:
- Parse command-line arguments using tools.cli
- Orchestrate service calls (no business logic here)
- Format output (table or JSON)
- Handle errors and exit codes

All business logic lives in boundary.user.core.* and boundary.user.shell.service.
All observability is handled automatically by interceptors.

User module CLI entrypoint wrapper.

Encapsulates user-specific CLI startup so that the top-level CLI can
remain as module-agnostic as possible and delegate into this module.

Note: boundary.config is loaded lazily via requiring-resolve so this
namespace compiles cleanly when boundary/src is not on the classpath
(e.g. when using zzp-guard's :dev-local alias during REPL development).

HTTP routing and handlers for user module - provides structured route definitions.

This namespace implements the REST API and Web UI for user and session management.

Route Structure:
----------------
The module exports routes in a structured format {:api [...] :web [...] :static [...]}
for composition by the top-level router, which applies appropriate prefixes:

API Endpoints (mounted under /api):
- POST   /api/users           - Create user
- GET    /api/users/:id       - Get user by ID
- GET    /api/users           - List users (with filters)
- PUT    /api/users/:id       - Update user
- DELETE /api/users/:id       - Soft delete user
- POST   /api/sessions        - Create session (login)
- GET    /api/sessions/:token - Validate session
- DELETE /api/sessions/:token - Invalidate session (logout)
- POST   /api/auth/login      - Authenticate with email/password

Web UI Endpoints (mounted under /web):
- GET    /web/users           - Users listing page
- GET    /web/users/new       - Create user page
- GET    /web/users/:id       - User detail page
- POST   /web/users           - Create user (HTMX fragment)
- PUT    /web/users/:id       - Update user (HTMX fragment)
- DELETE /web/users/:id       - Delete user (HTMX fragment)

Static Assets (mounted at root):
- GET    /css/*                - CSS assets
- GET    /js/*                 - JavaScript assets
- GET    /modules/*            - Module-specific assets
- GET    /docs/*               - Documentation

All observability is handled automatically by interceptors.

HTTP-level interceptors for user module authentication, authorization, and audit.

These interceptors work with the HTTP interceptor architecture (ADR-010) and operate
on HTTP contexts with enter/leave/error semantics.

Key Differences from Domain Interceptors:
- Domain interceptors (user.shell.interceptors) handle validation/transformation pipelines
- HTTP interceptors (this namespace) handle cross-cutting HTTP concerns (auth, audit, rate-limit)

HTTP Context Shape:
{:request       Ring request map
 :response      Ring response map
 :route         Route metadata
 :system        {:logger :metrics-emitter :error-reporter}
 :attrs         Additional attributes
 :correlation-id UUID
 :started-at    Instant}

Usage in Normalized Routes:
{:path "/users"
 :methods {:post {:handler create-user-handler
                  :interceptors ['user.http-interceptors/require-authenticated
                                 'user.http-interceptors/require-admin
                                 'user.http-interceptors/log-action]}}}

User-specific interceptors for the user creation pipeline.

These interceptors handle user domain-specific concerns like:
- User input validation (required fields, types)
- User data transformation (normalization, type conversion)
- User business logic invocation (register-user service call)
- User-specific response formatting

Shell Layer - MFA operations with side effects.

This is the SHELL layer for MFA operations:
- TOTP secret generation
- TOTP code verification
- Backup code generation (secure random)
- QR code generation for authenticator apps

All I/O and side effects happen here. Pure business logic
is delegated to boundary.user.core.mfa.

Cryptographic protection for MFA secrets at rest.

The TOTP secret is *reversible* — it must be recovered to compute one-time
codes — so it is AES-256-GCM encrypted under a key derived from JWT_SECRET.
Backup codes are *one-way* — only ever compared against — so they are
bcrypt-hashed (constant-time verification, self-salting).

A DB read (SQL injection, backup leak, insider) therefore yields neither a
usable TOTP seed nor usable recovery codes.

Authentication and authorization middleware for HTTP endpoints.

This middleware provides:
- JWT token validation
- Session-based authentication
- Role-based authorization
- Request context enrichment with user information

Integrant wiring for the user module.

This namespace owns all Integrant init/halt methods for user-specific
components so that shared system wiring does not depend directly on
user shell namespaces.

Shell layer for user module - implements user ports using database storage.

This namespace contains the SHELL (I/O) implementation that handles database persistence.
In FC/IS architecture, this is the SHELL that:
- Handles all I/O operations (database reads/writes)
- Manages external system interactions
- Contains side effects and impure operations
- Implements boundary.user.ports interfaces
- Transforms between domain entities and database records

Key FC/IS principles:
- ALL business logic stays in boundary.user.core.*
- This is ONLY for I/O and persistence concerns
- No business decisions made here - only data transformation
- Shell coordinates with core for business logic

This provides proper FC/IS separation where:
- Core contains pure business logic (no I/O)
- Shell handles all I/O and external systems
- Clean boundary between functional and imperative code

FC/IS Shell Layer - User module service coordination.

This is the SHELL layer in Functional Core / Imperative Shell architecture.
The shell coordinates between:
- Pure functional CORE (boundary.user.core.*)
- I/O SHELL persistence (boundary.user.shell.persistence)

Shell responsibilities:
1. Coordinate calls between core and persistence layers
2. Manage external dependencies (time, UUIDs, logging)
3. Handle all side effects and I/O operations
4. Orchestrate transaction boundaries
5. Transform between external and internal representations

The shell does NOT contain business logic - that lives in core.*
The shell does NOT handle database operations - that lives in persistence.*

Web UI handlers for user module.

This namespace implements Ring handlers that return HTML responses
for user-related web pages, either full pages or HTMX partial updates.

Handler Categories:
- Page Handlers: Return full HTML pages for initial browser requests
- HTMX Handlers: Return HTML fragments for dynamic updates

All handlers use the shared UI components and user shell services.