Clients

Lazer's client engagements. Each client has its own subdirectory containing all engagement-specific material — onboarding, architecture, integrations, runbooks, incidents, references — plus a clients/ subdirectory for that client's own clients (the end customers Lazer's client serves).

Active engagements

• Avoca — voice-agent platform for auto-service shops. AutoOps CRM integration. Sandy's primary engagement.
• EAS — EAS Tire & Auto, the auto-service enterprise Avoca answers for. Avoca's client, not Lazer's; promoted to a sibling tree because it's the engagement's centre of gravity and the tenant/platform split only works if both halves are first-class.

Pattern

The /clients/<lazer-client>/ directory holds everything Lazer-client-specific. Inside it:

• onboarding/, architecture/, concepts/, how-to/, reference/, incidents/, solutions/, proposals/ — engagement material at the Lazer-client level.
• crms/<crm>/ — CRM-specific material (e.g., AutoOps, HouseCall Pro).
• integrations/ — non-CRM integrations.

The tenant exception

A Lazer-client's own client normally lives at /clients/<lazer-client>/clients/<their-client>/. EAS is the deliberate exception: it sits at /clients/eas/ because separating platform from tenant is the organising idea of the Avoca engagement, and nesting the tenant three levels deep would bury it.

Three layers, two trees:

Layer	Where
Avoca platform (CRM-neutral)	/clients/avoca/
AutoOps integration (the vendor contract — survives a tenant change)	/clients/avoca/crms/autoops/
EAS tenant (shops, team ids, credentials, prompt, reports)	/clients/eas/

The test for which tree a fact belongs in: would it still be true if EAS churned and a different AutoOps shop signed?

Anything that's truly cross-client (patterns, methodologies, Lazer-side practices not tied to a specific engagement) lives at the toolkit root, not under /clients/.