Develop

docs/documentation/customers/customer-segments.md

@@ -39,4 +39,4 @@ No storefront code is needed to make segment-restricted discounts work: the cust
 
 - [Customer Management](customer-management.md) -- how customers themselves are created and linked to Umbraco Members
 - [Discounts Overview](../discounts/discounts-overview.md) -- how segments feed `DiscountEligibilityType`
-- [Architecture-Diagrams Section 2.8](../../Architecture-Diagrams.md) -- full service map for customers and segments
+- [Architecture-Diagrams Section 2.8](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md) -- full service map for customers and segments

docs/documentation/discounts/discounts-overview.md

@@ -219,4 +219,4 @@ Discount rules are created and managed in the Merchello backoffice. Configuratio
 - [Checkout Discounts](../checkout/checkout-discounts.md) -- service-level integration (`ICheckoutDiscountService`)
 - [Customer Segments](../customers/customer-segments.md) -- how segments gate discount eligibility
 - [Multi-Currency Overview](../multi-currency/multi-currency-overview.md) -- currency invariants that affect discount math
-- [Architecture-Diagrams Section 2.9](../../Architecture-Diagrams.md) -- discount service map and calculator notes
+- [Architecture-Diagrams Section 2.9](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md) -- discount service map and calculator notes

docs/documentation/multi-currency/multi-currency-overview.md

@@ -40,7 +40,7 @@ For example, if the store currency is USD and the customer shops in GBP with a s
 - **Display** uses multiply: `amount * rate`
 - **Checkout/payment** uses divide: `amount / rate`
 
-The two directions are intentional and non-negotiable. Display and checkout use **the same stored rate** but in opposite directions because display and invoice-conversion paths have different input/output currencies. See [Architecture-Diagrams Section 5.4 and 5.5](../../Architecture-Diagrams.md) for the full worked examples, including tax-inclusive math.
+The two directions are intentional and non-negotiable. Display and checkout use **the same stored rate** but in opposite directions because display and invoice-conversion paths have different input/output currencies. See [Architecture-Diagrams Section 5.4 and 5.5](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md) for the full worked examples, including tax-inclusive math.
 
 > **Warning.** Never charge from display amounts. Always use the invoice conversion path with the locked rate.
 
@@ -75,7 +75,7 @@ On the invoice, the primary monetary fields (`Total`, `SubTotal`, `Tax`, `Discou
 | `LineItem.Amount` | `LineItem.AmountInStoreCurrency` |
 | `LineItem.Cost` | `LineItem.CostInStoreCurrency` |
 
-Reporting queries always use the `*InStoreCurrency` fields so totals can be summed across invoices without looking up historical exchange rates. See [Architecture-Diagrams.md Section 5.6](../../Architecture-Diagrams.md) for the full field matrix.
+Reporting queries always use the `*InStoreCurrency` fields so totals can be summed across invoices without looking up historical exchange rates. See [Architecture-Diagrams.md Section 5.6](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md) for the full field matrix.
 
 ## How Display Conversion Works
 

docs/documentation/notifications/notification-system.md

@@ -2,7 +2,7 @@
 
 Merchello uses Umbraco's built-in notification system to broadcast events throughout the application. When something happens -- an order is created, a product is saved, a shipment status changes -- a notification is published. Your code can subscribe to these notifications to extend Merchello's behavior without modifying the core.
 
-Merchello's two integration bridges ([Email](../email/email-overview.md) and [Webhooks](../webhooks/webhooks-overview.md)) are also notification handlers, so everything you read below applies to them as well. For the full notification inventory and handler priority table see [Architecture-Diagrams.md §8](../../Architecture-Diagrams.md).
+Merchello's two integration bridges ([Email](../email/email-overview.md) and [Webhooks](../webhooks/webhooks-overview.md)) are also notification handlers, so everything you read below applies to them as well. For the full notification inventory and handler priority table see [Architecture-Diagrams.md §8](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md).
 
 ## Base Classes
 
@@ -246,4 +246,4 @@ Merchello includes several built-in notification handlers. Verify priorities aga
 - [Fulfilment System](../fulfilment/fulfilment-overview.md)
 - [UCP Protocol](../ucp/ucp-overview.md)
 - [Background Jobs](../background-jobs/background-jobs.md)
-- [Architecture Diagrams - Notification System](../../Architecture-Diagrams.md)
+- [Architecture Diagrams - Notification System](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md)

docs/documentation/orders/orders-overview.md

@@ -1,6 +1,6 @@
 # Orders and Invoices Overview
 
-Merchello uses a three-level hierarchy for commerce transactions: **Invoices** contain **Orders**, and Orders contain **Shipments**. The invoice is the financial contract; orders are fulfilment units; shipments are packages. Full domain model: [`Invoice.cs`](../../../src/Merchello.Core/Accounting/Models/Invoice.cs), [`OrderStatus.cs`](../../../src/Merchello.Core/Accounting/Models/OrderStatus.cs). See [Architecture Diagrams §2.4](../../Architecture-Diagrams.md) for the full service catalog.
+Merchello uses a three-level hierarchy for commerce transactions: **Invoices** contain **Orders**, and Orders contain **Shipments**. The invoice is the financial contract; orders are fulfilment units; shipments are packages. Full domain model: [`Invoice.cs`](../../../src/Merchello.Core/Accounting/Models/Invoice.cs), [`OrderStatus.cs`](../../../src/Merchello.Core/Accounting/Models/OrderStatus.cs). See [Architecture Diagrams §2.4](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md) for the full service catalog.
 
 ## The Hierarchy
 
@@ -115,7 +115,7 @@ Line items represent individual products or charges on an order:
 
 ## Invoice Source Tracking (Invariant)
 
-The [`Invoice.Source`](../../../src/Merchello.Core/Accounting/Models/InvoiceSource.cs) property tracks where and how an invoice was created — essential for analytics and auditing. **Preserve these semantics in every invoice-creating flow.** See [Architecture Diagrams §2.4](../../Architecture-Diagrams.md) for the full source-type catalog.
+The [`Invoice.Source`](../../../src/Merchello.Core/Accounting/Models/InvoiceSource.cs) property tracks where and how an invoice was created — essential for analytics and auditing. **Preserve these semantics in every invoice-creating flow.** See [Architecture Diagrams §2.4](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md) for the full source-type catalog.
 
 | Property | Description |
 |----------|-------------|

docs/documentation/payments/payment-system-overview.md

@@ -2,7 +2,7 @@
 
 Merchello's payment system is built around a provider-based architecture. Payment providers (Stripe, PayPal, etc.) are plugins that handle the specifics of each payment gateway, while [`IPaymentService`](../../../src/Merchello.Core/Payments/Services/Interfaces/IPaymentService.cs) owns the payment lifecycle — recording payments, dedupe, refunds, and status.
 
-> **Single source of truth:** Never recompute payment status, refund totals, or balance-due in controllers, views, or JS. Call [`IPaymentService.CalculatePaymentStatus`](../../../src/Merchello.Core/Payments/Services/Interfaces/IPaymentService.cs#L114) (sync, on already-loaded payments) or `GetInvoicePaymentStatusAsync` (async, fetches payments for you). See [Architecture Diagrams §2.6 Payments](../../Architecture-Diagrams.md).
+> **Single source of truth:** Never recompute payment status, refund totals, or balance-due in controllers, views, or JS. Call [`IPaymentService.CalculatePaymentStatus`](../../../src/Merchello.Core/Payments/Services/Interfaces/IPaymentService.cs#L114) (sync, on already-loaded payments) or `GetInvoicePaymentStatusAsync` (async, fetches payments for you). See [Architecture Diagrams §2.6 Payments](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md).
 
 ## Key Concepts
 
@@ -79,7 +79,7 @@ POST /api/merchello/checkout/process-payment (or GET /checkout/return for redire
 Redirect to /checkout/confirmation/{invoiceId}
 ```
 
-> **Digital-only invoices** auto-complete after a successful payment — the `DigitalProductPaymentHandler` (subscribed to `PaymentCreatedNotification`) issues download tokens and marks the order complete. See [Digital Products](../products/digital-products.md) and [Architecture Diagrams §2.12](../../Architecture-Diagrams.md).
+> **Digital-only invoices** auto-complete after a successful payment — the `DigitalProductPaymentHandler` (subscribed to `PaymentCreatedNotification`) issues download tokens and marks the order complete. See [Digital Products](../products/digital-products.md) and [Architecture Diagrams §2.12](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md).
 
 ---
 
@@ -179,7 +179,7 @@ Full interface: [`IPaymentService.cs`](../../../src/Merchello.Core/Payments/Serv
 
 ## Notifications
 
-Payment events dispatch notifications that email, webhook, and custom handlers subscribe to. See [Architecture Diagrams §8](../../Architecture-Diagrams.md) for the full handler priority ordering.
+Payment events dispatch notifications that email, webhook, and custom handlers subscribe to. See [Architecture Diagrams §8](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md) for the full handler priority ordering.
 
 | Notification | Fired when | Handlers include |
 |--------------|------------|------------------|

docs/documentation/payments/saved-payment-methods.md

@@ -285,4 +285,4 @@ The currency comes from the invoice — the service does not take a `CurrencyCod
 - **Authentication required** — Storefront endpoints return `401` for unauthenticated requests.
 - **Consent tracking** — `ConsentDateUtc` and `ConsentIpAddress` are recorded when a method is saved.
 - **Expiry detection** — Methods are automatically flagged as expired based on `ExpiryMonth`/`ExpiryYear`.
-- **Idempotency** — Pass an `IdempotencyKey` on saved-method charges and refunds to make retries safe (see [Payment System Overview](payment-system-overview.md#idempotency--dedupe-invariant)).
+- **Idempotency** — Pass an `IdempotencyKey` on saved-method charges and refunds to make retries safe (see [Payment System Overview](payment-system-overview.md#idempotency-dedupe-invariant)).

docs/documentation/upsells/upsells-overview.md

@@ -269,4 +269,4 @@ Upsell rules are created and managed in the Merchello backoffice. Configuration
 - [Checkout Overview](../checkout/)
 - [Payments: Saved Payment Methods](../payments/saved-payment-methods.md) -- required for post-purchase upsells
 - [Email System](../email/email-overview.md) -- rendering upsells in transactional email
-- [Architecture-Diagrams Section 2.15](../../Architecture-Diagrams.md) -- upsell service map
+- [Architecture-Diagrams Section 2.15](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md) -- upsell service map

docs/documentation/webhooks/webhooks-overview.md

@@ -309,4 +309,4 @@ Source: [WebhooksApiController.cs](../../../src/Merchello/Controllers/WebhooksAp
 - [Email System](../email/email-overview.md)
 - [Background Jobs](../background-jobs/background-jobs.md)
 - [UCP Protocol](../ucp/ucp-overview.md) (uses a separate ES256-signed webhook stream for agents)
-- [Architecture Diagrams - Webhooks](../../Architecture-Diagrams.md)
+- [Architecture Diagrams - Webhooks](https://github.com/YodasMyDad/Merchello/blob/main/docs/Architecture-Diagrams.md)