Sync setup-foundation specs to main and archive change.

Promote five capability specs from the completed setup-foundation change into openspec/specs and move the change to archive.

Co-authored-by: Cursor <cursoragent@cursor.com>

openspec/changes/archive/2026-07-28-setup-foundation/specs/internal-authentication/spec.md

@@ -0,0 +1,56 @@
+## ADDED Requirements
+
+### Requirement: Internal users authenticate via Filament panel
+
+The system SHALL provide authenticated access to the internal panel at `/admin` using Laravel's session-based authentication integrated with Filament 5.
+
+#### Scenario: Active admin logs in successfully
+
+- **WHEN** an active user with role `admin` submits valid credentials on the login page
+- **THEN** the system authenticates the user and redirects to the Filament dashboard
+
+#### Scenario: Active assistant logs in successfully
+
+- **WHEN** an active user with role `assistant` submits valid credentials on the login page
+- **THEN** the system authenticates the user and redirects to the Filament dashboard
+
+#### Scenario: Inactive user is denied panel access
+
+- **WHEN** a user with `is_active` set to false submits valid credentials
+- **THEN** the system MUST NOT grant access to the Filament panel
+
+### Requirement: User roles are limited to admin and assistant
+
+The system SHALL store user roles using the `UserRole` enum with exactly two cases: `admin` and `assistant`. The system MUST NOT implement a granular permission system in the MVP.
+
+#### Scenario: User is created with a valid role
+
+- **WHEN** an administrator creates a user with role `admin` or `assistant`
+- **THEN** the role is persisted and enforced on subsequent authorization checks
+
+### Requirement: Email addresses are unique per user
+
+The system SHALL enforce a unique constraint on user email addresses.
+
+#### Scenario: Duplicate email rejected
+
+- **WHEN** a user is created or updated with an email already assigned to another user
+- **THEN** the system MUST reject the operation with a validation error
+
+### Requirement: Password reset is available for internal users
+
+The system SHALL support secure password reset for internal users using Laravel's built-in reset flow.
+
+#### Scenario: User requests password reset
+
+- **WHEN** a user submits a registered email on the password reset form
+- **THEN** the system sends a reset link without revealing whether the email exists
+
+### Requirement: Only admin manages internal users
+
+The system SHALL restrict user management (create, update, deactivate) to users with role `admin`. Users with role `assistant` MUST NOT manage other users.
+
+#### Scenario: Assistant cannot access user management
+
+- **WHEN** an authenticated assistant attempts to access user management in the panel
+- **THEN** the system MUST deny access via authorization policy