ahmido
e15eee8f26
## 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
48 lines
2.4 KiB
Markdown
48 lines
2.4 KiB
Markdown
# Specification Quality Checklist: Workspace Chooser v1 (Enterprise)
|
|
|
|
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
|
**Created**: 2026-02-22
|
|
**Feature**: [spec.md](../spec.md)
|
|
|
|
## Content Quality
|
|
|
|
- [x] 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.
|
|
- [x] Focused on user value and business needs
|
|
- [x] Written for non-technical stakeholders (user stories are plain language)
|
|
- [x] All mandatory sections completed
|
|
|
|
## Requirement Completeness
|
|
|
|
- [x] No [NEEDS CLARIFICATION] markers remain
|
|
- [x] Requirements are testable and unambiguous
|
|
- [x] Success criteria are measurable
|
|
- [x] Success criteria are technology-agnostic (no implementation details)
|
|
- [x] All acceptance scenarios are defined
|
|
- [x] Edge cases are identified (zero memberships, archived workspace, stale session, forced chooser)
|
|
- [x] Scope is clearly bounded (v1 vs v2 backlog explicit)
|
|
- [x] Dependencies and assumptions identified (existing infrastructure documented in Context section)
|
|
|
|
## Feature Readiness
|
|
|
|
- [x] All functional requirements have clear acceptance criteria
|
|
- [x] User scenarios cover primary flows (auto-resume single, auto-resume last-used, chooser fallback, revoked membership, manual switch, audit)
|
|
- [x] Feature meets measurable outcomes defined in Success Criteria
|
|
- [x] No implementation details leak into specification (behavior-first language throughout)
|
|
|
|
## Constitution Alignment
|
|
|
|
- [x] RBAC-UX: authorization plane stated (workspace /admin scope)
|
|
- [x] RBAC-UX: 404 vs 403 semantics defined (non-member → 404)
|
|
- [x] RBAC-UX: server-side enforcement described (middleware)
|
|
- [x] RBAC-UX: capability registry referenced (Capabilities::WORKSPACE_MANAGE)
|
|
- [x] Audit: audit events defined with payloads
|
|
- [x] UX-001: exemption documented (context selector, not CRUD page)
|
|
- [x] 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`.
|