docs: publish architecture and context graph overview

README.md

@@ -9,7 +9,9 @@ Morrow Desk is the first application. It combines a support desk, customer direc
 
 > **Project status:** early V1. The architecture and core Desk flows are implemented and tested, but Morrow does not yet claim production readiness. A deployed Worker is not, by itself, an operational support desk.
 
-[Project site](https://codeyogi911.github.io/morrow-site/) · [V1 contract](docs/product-v1.md) · [Roadmap](docs/roadmap.md) · [Architecture](docs/architecture.md)
+[Project site](https://codeyogi911.github.io/morrow-site/) · [V1 contract](docs/product-v1.md) · [Roadmap](docs/roadmap.md) · [Architecture overview](docs/architecture-overview.md) · [Architecture reference](docs/architecture.md)
+
+![Morrow Desk architecture overview](docs/assets/architecture-overview.svg)
 
 ## Why agent-first
 
@@ -41,7 +43,7 @@ morrow/
 ├── apps/
 │   └── desk/          # Buildable Desk Worker, migrations, tests, assets, and configs
 ├── packages/          # Future reusable modules, extracted only behind proven interfaces
-├── docs/              # Product contract, architecture, ADRs, deployment, and roadmap
+├── docs/              # Product contract, architecture visuals, ADRs, deployment, and roadmap
 ├── scripts/           # Repository-wide publication and history gates
 └── .github/           # CI, security scanning, and contributor templates
 ```

docs/architecture-overview.md

@@ -0,0 +1,19 @@
+# Architecture overview
+
+![Morrow Desk architecture overview](assets/architecture-overview.svg)
+
+Morrow Desk is one Cloudflare Worker with narrow channel adapters, deep business modules, and Cloudflare-managed storage and delivery services. This diagram describes the implemented V1 architecture; the binding details remain in [the architecture reference](architecture.md) and [V1 product contract](product-v1.md).
+
+## How to read the diagram
+
+- **Operator plane:** agent clients reach MCP and the small `/ops` recovery surface only through verified Cloudflare Access identity.
+- **Customer channels:** the public portal, knowledge base, browser voice, email, and signed WhatsApp ingress enter through channel-specific security boundaries.
+- **Adapters:** MCP, portal, email, WhatsApp, voice, and `/ops` authenticate, translate, and render. They do not own business policy.
+- **Deep modules:** Communications, Helpdesk, Directory, CRM, Operations, and Improvement own their state, lifecycle, revisions, evidence, and public interfaces.
+- **Platform:** D1 holds canonical business state, private R2 holds originals, queues and cron isolate asynchronous work, one Durable Object owns a verified voice session, and Workers AI, Images, Email Service, and external providers remain bounded infrastructure.
+
+The normal truth flow is: authenticate, load a bounded workspace, commit state plus audit and receipt, deliver asynchronously, then observe the business outcome. Provider acceptance and successful business outcome are deliberately different states.
+
+## Context direction
+
+Morrow already composes revisioned cross-module context through public interfaces. A richer relationship view should extend that boundary as a rebuildable projection, not let agents query module tables or receive an unbounded graph dump. See the [bounded context graph proposal](context-graph.md).

docs/architecture.md

@@ -1,5 +1,7 @@
 # Architecture
 
+For the system at a glance, start with the [architecture overview](architecture-overview.md). This document defines the detailed boundaries behind that diagram.
+
 Morrow Desk is one Cloudflare Worker with Hono JSX server rendering, static assets, D1, a private R2 bucket, Email Service, a rate-limit binding, and a retry cron. The V1 product has no browser SPA or live-chat state. Verified browser voice support adds one Agents SDK Durable Object: Turnstile and a short-lived email OTP bind a customer identity to one WebSocket connection, then narrow bridge methods can open Helpdesk cases or read status only for that verified email. The model never supplies the customer identity. Portal branding is deployment data behind one shared validator: `/ops/settings` and the admin-only MCP customization tool write the same bounded identity, asset URL, color, and font fields and emit the same audit event. Customer email templates are separate audited deployment data: the admin MCP tool validates known brace placeholders, stores plain-text and Markdown variants, and sanitizes rich HTML before it enters the durable outbox.
 
 ## Deep modules
@@ -61,3 +63,5 @@ Email places the capability in the URL fragment of `/requests/access`, so it is
 Workspace settings and operators are deployment-wide. Directory identity, context envelopes, operation closures, audit, operation receipts, attachments, delivery, provenance, and inactive improvement records are shared substrate. A business module may reuse that substrate but cannot reach into another module's tables or lifecycle logic.
 
 See [ADR 0001](adr/0001-agent-first-suite.md) for the long-term module rule and [ADR 0002](adr/0002-agent-first-desk-crm-foundation.md) for the Desk + CRM and closed-loop decisions.
+
+A richer cross-module relationship view is proposed as a rebuildable, read-only projection in [the bounded context graph proposal](context-graph.md). It is not part of the implemented V1 architecture or a source of business truth.