TenantAtlas/specs/107-workspace-chooser/checklists/requirements.md
ahmido e15eee8f26 fix: consolidate tenant creation + harden selection flows (#131)
## Summary
- Removes the legacy Tenant CRUD create page (`/admin/tenants/create`) so tenant creation is handled exclusively via the onboarding wizard.
- Updates tenant selection flows and pages to prevent Livewire polling/notification-related 404s on workspace-scoped routes.
- Aligns empty-state UX with enterprise patterns (avoid duplicate CTAs).

## Key changes
- Tenant creation
  - Removed `CreateTenant` page + route from `TenantResource`.
  - `TenantResource::canCreate()` now returns `false` (CRUD creation disabled).
  - Tenants list now surfaces an **Add tenant** action that links to onboarding (`admin.onboarding`).
- Onboarding wizard
  - Removed redundant legacy step-cards from the blade view (Wizard schema is the source of truth).
  - Disabled topbar on the onboarding page to avoid lazy-loaded notifications.
- Choose tenant
  - Enterprise UI redesign + workspace context.
  - Uses Livewire `selectTenant()` instead of a form POST.
  - Disabled topbar and gated BODY_END hook to avoid background polling.
- Baseline profiles
  - Hide header create action when table is empty to avoid duplicate CTAs.

## Tests
- `vendor/bin/sail artisan test --compact --filter='Onboarding|ManagedTenantOnboarding'`
- `vendor/bin/sail artisan test --compact --filter='ManagedTenantsLivewireUpdate'`
- `vendor/bin/sail artisan test --compact --filter='TenantSetup|TenantResourceAuth|TenantAdminAuth|ListTenants'`
- `vendor/bin/sail artisan test --compact --filter='BaselineProfile'`
- `vendor/bin/sail artisan test --compact --filter='ChooseTenant|TenantMake|TenantScoping|AdminTenantScoped|AdminHomeRedirect|WorkspaceContext'`

## Notes
- Filament v5 / Livewire v4 compatible.
- No new assets introduced; no deploy pipeline changes required.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #131
2026-02-22 19:54:24 +00:00

2.4 KiB

Specification Quality Checklist: Workspace Chooser v1 (Enterprise)

Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-02-22 Feature: spec.md

Content Quality

  • No implementation details (languages, frameworks, APIs)
    • Note: Spec references existing codebase components by name for context (WorkspaceContext, AuditActionId) but requirements are behavior-focused. Framework names appear in UI Action Matrix as required by template.
  • Focused on user value and business needs
  • Written for non-technical stakeholders (user stories are plain language)
  • All mandatory sections completed

Requirement Completeness

  • No [NEEDS CLARIFICATION] markers remain
  • Requirements are testable and unambiguous
  • Success criteria are measurable
  • Success criteria are technology-agnostic (no implementation details)
  • All acceptance scenarios are defined
  • Edge cases are identified (zero memberships, archived workspace, stale session, forced chooser)
  • Scope is clearly bounded (v1 vs v2 backlog explicit)
  • Dependencies and assumptions identified (existing infrastructure documented in Context section)

Feature Readiness

  • All functional requirements have clear acceptance criteria
  • User scenarios cover primary flows (auto-resume single, auto-resume last-used, chooser fallback, revoked membership, manual switch, audit)
  • Feature meets measurable outcomes defined in Success Criteria
  • No implementation details leak into specification (behavior-first language throughout)

Constitution Alignment

  • RBAC-UX: authorization plane stated (workspace /admin scope)
  • RBAC-UX: 404 vs 403 semantics defined (non-member → 404)
  • RBAC-UX: server-side enforcement described (middleware)
  • RBAC-UX: capability registry referenced (Capabilities::WORKSPACE_MANAGE)
  • Audit: audit events defined with payloads
  • UX-001: exemption documented (context selector, not CRUD page)
  • UI Action Matrix completed

Notes

  • Spec deliberately uses users.last_workspace_id (existing column) instead of proposing a new user_preferences table, aligning with current codebase patterns.
  • Middleware algorithm is specified in detail because it's the core business logic of the feature; still expressed as behavior rules, not code.
  • All items pass. Spec is ready for /speckit.plan.