@@ -150,6 +150,9 @@ function onRequest (props) {
doSearch()
}
-onMounted(doSearch)
+// Don't auto-load all clients — start empty, load only on search or if ?q= is present
+onMounted(() => {
+ if (search.value.trim()) doSearch()
+})
watch(() => route.query.q, (q) => { if (q) { search.value = q; doSearch() } })
diff --git a/docs/CUSTOMER-FLOW-ARCHITECTURE.md b/docs/CUSTOMER-FLOW-ARCHITECTURE.md
index fffc12c..af43275 100644
--- a/docs/CUSTOMER-FLOW-ARCHITECTURE.md
+++ b/docs/CUSTOMER-FLOW-ARCHITECTURE.md
@@ -228,7 +228,25 @@ One-time charges:
4. **Installation preference**:
- Choose from 3 available dates (next 2 weeks, exclude weekends)
- OR "Contactez-moi" (we call to schedule)
-5. **Payment** via Stripe (first month + one-time charges)
+5. **Payment** (Stripe — card registered but NOT charged)
+
+### Payment Strategy
+
+**Website path (self-service)**:
+- Customer registers their card on Stripe (SetupIntent, not PaymentIntent)
+- We create a Stripe Customer + attach the payment method
+- **No charge is taken at checkout** — customer sees: "Aucun frais avant la complétion de l'installation à votre satisfaction"
+- Payment is collected AFTER installation is confirmed complete by the technician
+- On installation completion → auto-charge first month + one-time fees via Stripe
+
+**Agent path (phone order)**:
+- No payment collected upfront
+- Agent creates the order and an invoice is generated
+- Agent can send a **payment link** via email or SMS to the customer:
+ - Stripe Checkout Session or Payment Link → customer pays when ready
+ - SMS via Twilio: "Votre commande est confirmée! Payez ici: {link}"
+ - Email via Mailjet: order summary + payment button
+- Payment can also be collected on-site by tech or post-installation
### What Happens on Submit
@@ -243,7 +261,14 @@ POST /api/checkout
{ sku: "TELEPMENS", type: "phone" }
],
preferred_dates: ["2026-04-07", "2026-04-09", "2026-04-11"],
- stripe_payment_intent: "pi_xxx"
+ payment: {
+ method: "stripe_setup", // website: card registered, not charged
+ stripe_customer_id: "cus_xxx", // Stripe Customer created
+ stripe_payment_method: "pm_xxx", // Card saved for later charge
+ // OR for agent path:
+ method: "invoice_later", // agent: no payment upfront
+ send_payment_link: "email|sms|both" // optional: send link to customer
+ }
}
```
diff --git a/docs/DATA-STRUCTURE-FOUNDATION.md b/docs/DATA-STRUCTURE-FOUNDATION.md
index d88604d..f335169 100644
--- a/docs/DATA-STRUCTURE-FOUNDATION.md
+++ b/docs/DATA-STRUCTURE-FOUNDATION.md
@@ -151,9 +151,20 @@ Output: customer data ready for creation
### Step 4: Payment (Stripe)
```
-Input: card details (Stripe Elements)
-Output: payment_intent confirmed
- First month pro-rated + one-time charges
+WEBSITE PATH:
+ Input: card details (Stripe Elements)
+ Output: SetupIntent confirmed — card SAVED, NOT charged
+ Stripe Customer + PaymentMethod created
+ Customer sees: "Aucun frais avant la complétion de l'installation"
+ Charge triggered AFTER tech confirms installation complete
+
+AGENT PATH:
+ No payment collected upfront
+ Invoice generated → agent sends payment link via email/SMS
+ POST /api/send-payment-link
+ { customer_id, method: "email|sms|both" }
+ → Creates Stripe Payment Link or Checkout Session
+ → Sends via Twilio SMS / Mailjet email
```
### Step 5: Order Creation (atomic — all or nothing)
diff --git a/docs/DESIGN_GUIDELINES.md b/docs/DESIGN_GUIDELINES.md
new file mode 100644
index 0000000..3134666
--- /dev/null
+++ b/docs/DESIGN_GUIDELINES.md
@@ -0,0 +1,67 @@
+# Gigafibre FSM — Design Guidelines
+
+This document outlines the standard design principles and conventions for adding new features and modules to the Gigafibre FSM (Field Service Management) application. Adhering to these guidelines ensures scalability, maintainability, and highly efficient AI-assisted development (by keeping context windows small and token usage low).
+
+## 1. Modular Architecture (Feature-Sliced Design)
+
+To avoid a monolithic `src/` folder that overwhelms both developers and AI tools, organize code by **feature** rather than strictly by technical type.
+
+**Do Not Do This (Technical Grouping):**
+```text
+src/
+ components/ (contains dispatch, inventory, and customer components all mixed together)
+ store/ (one massive pinia store for everything)
+ api/ (one 2000-line api.js file)
+```
+
+**Do This (Feature Grouping):**
+```text
+src/
+ features/
+ dispatch/
+ components/
+ store.ts
+ api.ts
+ types.ts
+ equipment/
+ components/
+ store.ts
+ api.ts
+ types.ts
+ shared/
+ ui/ (generic buttons, dialogs)
+ utils/
+```
+*Why?* When you need AI to build a new dispatch feature, you only need to feed it the `features/dispatch/` folder, drastically reducing token usage and hallucination.
+
+## 2. API & ERPNext Abstraction
+
+Never make raw API calls (`axios.get`) directly inside a Vue component.
+* All ERPNext interactions must go through a dedicated API service file (`features/{module}/api.ts`).
+* **Rule:** Vue components should only dispatch actions (via Pinia) or call cleanly abstracted service functions. They should not care about Frappe endpoints or REST wrappers.
+
+## 3. UI Component Standardization (Quasar)
+
+* **Composition API:** Use Vue 3 `