Phase 4 Planning: Next Workbenches
Date: 2026-01-05 Status: PROPOSED
1. Inventory of Candidates
| Module | Location | Current State | Risk | Dependency Value |
|---|---|---|---|---|
| Directory | mod-uni-directory |
Partial UI (/directory), Legacy Actions |
CRITICAL | High (Unlocks RBAC, Ops, Finance) |
| Operations | mod-operations |
Partial UI (/operations), Legacy Actions |
High | High (Core Business Logic) |
| Governance | mod-governance |
Legacy Actions (Votes), UI exists | High | Medium (Seasonal) |
| Finance | mod-finance |
Secured Actions, Legacy UI (/admin/finance) |
Critical | High (Already partially secured) |
| Communications | mod-uni-communications |
Minimal UI, notifications.ts |
Medium | Medium (UX layer) |
| Vendor Portal | app/vendor |
Separate Portal UI | Medium | Low (Depends on Directory/Ops) |
| Knowledge | mod-uni-knowledge |
app/library? |
Low | Medium (Content) |
2. Recommendations (Top 3)
Priority 1: Unified Directory Workbench
Rationale: The "Identity Source of Truth". All other modules (Operations tickets, Finance folios, Governance votes) depend on clean, secure Actor profiles and Unit associations.
- Value: Unblocks definitive RBAC, "Acting For" contexts, and Vendor/Staff management.
- Risk: High (PII, Access Control). Currently relies on legacy requireRole.
- Status: Backend exists (directory.ts, directory_profiles.ts). UI needs standardization.
Priority 2: Operations Command Center
Rationale: The "Operating System" of the building. Maintenance, Security, and Procurement. - Value: High. Direct impact on staff efficiency and resident satisfaction. - Risk: High (Physical access, financial implications of procurement). - Dependency: Needs Directory (for assigning tasks).
Priority 3: Communications Hub
Rationale: Critical for "Closing the Loop" (Notifications, Announcements, Emergency Broadcasts). - Value: High UX impact. - Risk: Medium (Spam, misinformation). - Dependency: Needs Directory (Audience targeting).
3. Deep Dive: Unified Directory Workbench
A. Current Landscape
Routes:
- /directory (DirectoryClient.tsx - 13kb)
- /directory/profiles (Implied)
- /directory/units (Implied)
Server Actions (_actions/directory.ts, _actions/directory_profiles.ts):
- getUnitDetailsAction
- addOccupantAction (Guard: requireRole)
- removeOccupantAction (Guard: requireRole)
- addVehicleAction / addPetAction
- createProfile / updateProfile (Guard: requireRole)
- assignPropertyManagerAction
Missing / Gaps:
- Guards: No verifyContext. Blindly trusts legacy roles.
- Services:
- Invite/Onboarding Flow: No explicit action to generate/redeem invite tokens.
- Credential Management: No server action for managing physical access (fobs/keys).
- Facets: No enforcement of "Unit Owner" vs "Tenant" beyond simple role string.
B. Execution Plan (Three Waves)
Wave A: Enforcement (The Hardening)
Goal: Replace requireRole with verifyContext and Logger.audit.
1. Refactor directory.ts:
- addOccupant: Require Hat: Admin/Staff OR Hat: Owner (of target unit). Scope: building or unit.
- addVehicle/Pet: Context-aware (Self-service for residents).
2. Refactor directory_profiles.ts:
- createProfile: Strict Admin/Staff.
- updateProfile: Owner (Self) or Admin.
- deleteProfile: Admin only.
3. Add Audit Logging: Attempt/Success/Denied pattern for all PII mutations.
Wave B: UI Refactor (The Workbench)
Goal: Standardize /directory using EditorWorkspace and DataPivot.
1. Master View: React Table with Profile and Unit tabs.
2. Detail View: Use ContextState to show/hide sensitive fields (PII).
3. Action Island: "Add Resident", "Move Out", "Issue Credential" buttons using proper Server Actions.
Wave C: Coverage & Verify
Goal: 100% Guard Coverage. 1. Coverage Map: Map every action to a Guard Rule. 2. Test Matrix: Verify Cross-Tenant isolation (Unit A cannot see Unit B details).