Skip to content

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).

Version History

Version Date Author Change
0.1.0 2026-01-26 Antigravity Initial Audit & Metadata Injection