# ALPHA STABILIZATION-004
## Workspace Users Foundation

You are implementing Alpha Stabilization-004 for the INVEETAIRE platform.

This is an architecture refinement.

This is NOT a new feature.

This patch prepares the platform for workspace-scoped users.

Do NOT remove the existing Crew implementation yet.

Backward compatibility is mandatory.

---

Current Status

✅ Sprint 0

✅ Sprint 1

✅ Sprint 2

✅ Sprint 3

✅ Pilot-001

✅ Pilot-002

✅ Pilot-003

✅ Pilot-004

✅ Pilot-005

✅ Pilot-006

✅ Pilot-007

✅ Alpha Patch-001

✅ Alpha Patch-002

✅ DEV PATCH-001

✅ DEV PATCH-002

✅ Alpha Stabilization-001

✅ Alpha Stabilization-002

✅ Alpha Stabilization-003

---

Objective

Introduce Workspace Users.

Keep the current Alpha login operational.

Do NOT break any existing functionality.

---

Architecture

Platform Users

Super Admin

Admin

Workspace Users

Owner

Crew

Only these two workspace roles exist.

Do NOT introduce:

Bride

Groom

Family

Guest

Operator

Those are presentation labels, not permission roles.

---

Workspace User Concept

Every workspace owns its own users.

Each workspace user belongs to exactly one workspace.

Owner has full workspace permissions.

Crew has operational permissions.

Platform users remain outside workspace ownership.

---

Compatibility

Current global Crew login must continue working.

Treat it as a temporary compatibility layer.

Do NOT remove it.

Do NOT break authentication.

Mark compatibility internally for future removal.

---

Workspace User Management

Implement:

Workspace

↓

Users

Allow Owner to:

Create workspace user

Edit workspace user

Deactivate workspace user

Reset password

Assign role:

Owner

Crew

Do NOT implement invitations.

Do NOT implement email verification.

Do NOT implement password recovery.

---

Authentication

Workspace Users continue logging in from:

/couple

Platform users continue logging in from:

/admin

Reuse existing authentication pipeline.

Do NOT duplicate AuthService.

---

Permissions

Owner

Full access to workspace.

Crew

Guest Management

Check-In

Attendance Dashboard

Read-only operational information where appropriate.

No Workspace Settings.

No Invitation Design.

No Message Template editing.

No Theme settings.

---

Session

Continue using:

active_workspace_id

active_workspace_slug

active_workspace_name

active_workspace_status

Do NOT redesign session.

---

Database

Reuse existing user infrastructure if possible.

If a workspace-user mapping table already exists or can be supported cleanly without schema changes, use it.

If schema changes are absolutely required, keep them minimal and isolated.

Do NOT redesign unrelated tables.

---

UI

Add:

Workspace

↓

Users

Simple table.

Columns:

Display Name

Username

Role

Status

Actions

Minimal Tailwind.

Reuse existing admin components.

---

Constraints

Do NOT:

Remove global Crew.

Implement workspace switching.

Implement invitation sending changes.

Modify QR flow.

Modify guest URLs.

Modify messaging.

Modify operation workflow.

Modify WorkspaceService provisioning logic except when creating default Owner users if necessary.

Modify Sprint 3 middleware.

---

Verification

Verify:

Owner can create Crew.

Owner can edit Crew.

Owner can deactivate Crew.

Owner can reset password.

Crew login works.

Existing global Crew login still works.

Admin login unaffected.

Workspace isolation maintained.

Session maintained.

PHP syntax passes.

---

Acceptance Criteria

PASS only if:

Workspace Users foundation exists.

Owner role implemented.

Crew role implemented.

Compatibility layer preserved.

Authentication unchanged.

Workspace isolation maintained.

No regression in Alpha features.

PHP syntax passes.

---

Output

Provide:

1. Files created.

2. Files modified.

3. Workspace User architecture.

4. Authentication compatibility strategy.

5. Permission matrix.

6. Verification.

7. Acceptance checklist.

8. PHP syntax results.

Stop after implementation.

Wait for Human Approval.