Audit Performance Across All Repositories and Document Proposed Changes Without Implementation

# Global instructions

First, read and analyze:

`C:\myworkspace\holidaylandmarks\holidaylanmark\docs\performance\livewire-hygiene.md`

Use this document as the reference for structure, formatting, and level of detail.

Enter Plan Mode. Inspect all HolidayLandmark repositories and services available in the workspace. Read the applicable `AGENTS.md` and `CLAUDE.md` files before auditing.

Base the audit on actual repository code, installed versions, API contracts, and deployment configuration. Trace relevant flows across services. Identify unavailable repositories or runtime information instead of making assumptions.

**Do not implement changes. Do not modify application code, configuration, databases, caches, deployment scripts, or server processes.**

For every finding, provide:

- Repository, service, affected page, and user action.
- Exact file paths and current line numbers.
- Existing code or configuration.
- **Before:** Current behavior and why it causes overhead.
- **Proposed After:** Recommended behavior, with proposed code or configuration.
- Evidence status: confirmed from code, confirmed by measurement, or needs verification.
- Risks, dependencies, validation, and rollback steps.
- Comparable before/after measurements without invented results or improvement percentages.

Preserve existing functionality, authorization, tenant isolation, validation, and error handling. Avoid unrelated refactoring.

Create a separate audit document under:

`C:\myworkspace\holidaylandmarks\holidaylanmark\docs\performance\`

Use the filename specified below. Read an existing output file before updating it and preserve relevant information. The audit document is the only permitted write. If Plan Mode prevents writing it, present the complete document for review.

Finish with a prioritized, repository-specific implementation plan. Stop and wait for explicit approval. Do not implement anything during this task.

# Specific audit: Queue and worker performance

Act as a senior Laravel performance engineer. Audit only queue and worker handling across the available HolidayLandmark services. Identify email, notification, and FCM work that slows user requests.

**Output filename:** `queue-worker-performance.md`

Verify each service’s Laravel version, queue configuration, and deployment architecture.

Inspect these five areas separately:

1. **Work that delays user requests**
   - Trace invite, role-change, and payment-save flows.
   - Identify synchronous emails, notifications, FCM calls, and related external requests.
   - Separate essential request work from work safe to run in the background.
   - Preserve payment verification, authorization, and required database transactions.

2. **Queue configuration**
   - Inspect queue connections, dispatch calls, queue tables, Redis settings, and environment configuration without exposing credentials.
   - Identify synchronous connections and queues that may lack consumers.
   - Distinguish workers configured in repository files from workers confirmed running on a server.

3. **Jobs and notifications**
   - Inspect jobs, mailables, notifications, listeners, and FCM services.
   - Propose version-compatible queued handling, safe payloads, and appropriate queue names.
   - Dispatch only after successful database commits where required.
   - Preserve recipients, tenant context, permissions, and notification content.
   - Address failed job dispatch after a successful save where reliable delivery is required.

4. **Reliability**
   - Inspect retries, backoff, timeouts, `retry_after` or visibility timeout, and failed-job handling.
   - Identify duplicate delivery risks and propose idempotency where needed.
   - Explain recovery and monitoring for failed deliveries, especially payment-related events.

5. **Worker lifecycle**
   - Inspect Supervisor, systemd, Horizon if installed, and deployment scripts.
   - Propose appropriate service users, concurrency, permissions, logging, monitoring, and safe deployment restarts.
   - Account for resource usage across all services.
   - Mark runtime details that require server verification.

Propose measurements for user response time, queue wait time, job execution time, failures, and duplicate delivery. Measure user response time separately from background delivery time.

Treat saves returning in under 0.5 seconds as a target to evaluate, not a guaranteed result.

Include queue infrastructure, job changes, worker setup, deployment order, validation, and rollback in the proposed plan.