Skip to content

Golden Path E2E Integration Strategy

Objective

Establish a set of stable, high-value E2E integration tests that verify critical cross-domain business processes. These tests serve as the "Golden Path" validating that the platform's modular subsystems (Operations, Finance, Governance, Identity, Property) correctly interoperate.

Core Principles

  1. Bridge-Focused: Tests must cross domain boundaries (e.g., Ops -> Finance).
  2. State-Invariant Verification: Each phase transition must verify both UI state and underlying data invariants.
  3. Strict vs. E2E Mode:
    • STRICT_MODE: Default. Enforces all business rules (e.g., compliance docs required, manual approvals).
    • E2E_MODE: Relaxed constraints for testing speed/feasibility (e.g., auto-generated ledger accounts, bypassed insurance checks). Controlled by process.env.E2E_MODE.
  4. Deterministic Harness: Use shared fixtures for consistent data seeding (Seeder Pattern).

Targeted Bridge Flows

Flow A: The "Procure-to-Pay" Cycle (Ops ↔ Finance ↔ Identity)

  • Narrative: A staff member hires a vendor, issues a PO for repairs, the work is done, and the vendor is paid.
  • Entities: Vendor, Purchase Order, Bill, Ledger Entry.
  • Steps:
  • Vendor Onboarding: Register Vendor -> Create Directory Profile (Identity).
  • Procurement: Create PO (Ops) -> Approve PO (Compliance Check).
  • Fulfillment: Mark PO Fulfilled -> Invariant: Bill Auto-Generated (Finance).
  • Payment: Operations Review -> Finance Approve Bill -> Ledger Posting.
  • Reconciliation: Vendor status update.

Flow B: The "Democracy" Cycle (Governance ↔ Identity ↔ Property)

  • Narrative: An owner proposes a policy change, the community votes, and the result is ratified.
  • Entities: Proposal, Vote, Unit (Deed), User (Resident).
  • Steps:
  • Eligibility: Verify User is an "Owner" of a Unit (Property).
  • Proposal: Create "Policy Change" Proposal (Governance).
  • Voting: Cast Weighted Vote (based on Unit SQM or simple count).
  • Tabulation: Close Voting -> Verify Results match expectations.
  • Audit: Verify immutable audit log of the vote.

Flow C: The "Secure Escalation" Cycle (Security ↔ Ops ↔ Finance)

  • Narrative: Assessing a security incident or resident report that escalates to a paid work order.
  • Entities: Service Request, Work Order, Vendor Dispatch.
  • Steps:
  • Incident: Resident reports issue (e.g., "Broken Gate") via Service Request.
  • Triage: Security/Admin escalates to Work Order (Ops).
  • Dispatch: Admin dispatches Vendor.
  • Closure: Vendor completes work -> Request Closed.

Flow D: The "New Resident" Cycle (Property ↔ Directory ↔ Access)

  • Narrative: A new tenant moves in, gets registered, and receives access rights.
  • Entities: Unit, Resident Profile, Access Role.
  • Steps:
  • Unit Setup: Ensure Unit exists (Property).
  • Move-In: Register new Resident (Directory) linked to Unit.
  • Access: Verify Resident inherits "Tenant" permissions (Identity).
  • Verification: Login as Resident -> Verify access to "My Home" dashboard.

Implementation Plan

1. Harness & Utilities

  • Location: apps/platform/e2e/harness/
  • Components:
  • seeder.ts: Deterministic data generators (Vendors, Units, Users).
  • utils.ts: UI helpers (Login, Toasts, Selectors).
  • fixtures.ts: Playwright glue.

2. Test Structure

Tests will be located in apps/platform/e2e/bridges/.

  • A_procure_to_pay.spec.ts
  • B_democracy_flow.spec.ts
  • C_secure_escalation.spec.ts
  • D_resident_onboarding.spec.ts

3. Execution & CI

  • Command: npx playwright test e2e/bridges
  • Env Var: E2E_MODE=true (for CI/Local dev to bypass blocking compliance logic).