Refine TallyFlow architecture to exactly 5 components

- MongoDB nested inside Core (no longer 6th component)
- IoT → Core connection is dashed (optional)
- Print includes Print UI + Print API note
- Capture shown as native app (not Go/Vue)
- Core Web UI and Print UI as differentiated sub-boxes
- Strict focus on the 5 components: Core, Assets, Print, Capture, IoT

TallyFlow/TallyFlow-Architecture.md

@@ -2,33 +2,43 @@
 
 **Diagram:** [[TallyFlow-Architecture-Diagram.html]]
 
-## Overview (Source-Verified)
+## Overview (5 Components)
 
-TallyFlow's architecture is centered on **TallyFlow Core**, which serves as the single integration hub and owns the primary data store.
+TallyFlow is built around exactly **five primary components**, with **Core** as the central hub that owns the database.
 
-**Core** consists of:
-- Go backend (API layer, business logic, using Echo/gRPC patterns)
-- Vue.js 2 web frontend (tallyflow-web) for asset management, reporting, and configuration
-- MongoDB database (owned by Core) storing the asset registry, tags, photo metadata, zones, events, and audit history
+### 1. Core (Central)
+- Go backend + Vue.js Web UI
+- Owns MongoDB (assets, tags, photos, zones, events)
+- Single API integration point for all other components
+- Handles configuration, reporting, and orchestration
 
-All other components communicate exclusively through Core's REST + WebSocket APIs.
+### 2. Assets (Mobile)
+- Flutter native mobile application
+- Lightweight inventory, geiger-style seek & find, enrollment, zone moves
+- Communicates with Core via REST/WebSocket API
 
-**TallyFlow Assets (Mobile)** is a Flutter application focused on field operations: lightweight inventory, geiger-counter-style seek & find, fast enrollment, zone movements, and shipping workflows. It syncs with Core.
+### 3. Print
+- Flutter + Rust implementation
+- Zebra ZPL-compatible label printing and RFID encoding
+- Includes **Print UI** for configuration
+- Can also be driven directly via the **Print API**
 
-**TallyFlow Capture** (PhotoTag) is implemented as a Go microservice (photomicroservice) that handles photo + barcode association for quality control and visual documentation. It stores photo metadata in its own MongoDB collections but registers assets and events back to Core.
+### 4. Capture (PhotoTag)
+- Native mobile application (not Go/Vue)
+- Associates photos with barcodes, work orders, and metadata
+- Focused on quality control and visual documentation
+- Sends data to Core via API
 
-**TallyFlow Print** is a Flutter + Rust application that generates Zebra ZPL-compatible labels and RFID encodings, with optional auto-registration into Core.
+### 5. IoT
+- Rust-based service
+- Integrates fixed RFID readers (Impinj, Zebra) and environmental sensors
+- Pushes tag events and sensor data to Core (optional / dashed connection)
 
-**IoT** is a Rust-based service (tallyflow-iot) that ingests data from fixed RFID readers (Impinj, Zebra) and environmental sensors, pushing real-time tag events and sensor data to Core.
+**MongoDB** is not a standalone component — it is fully owned and managed inside Core.
 
-This structure was verified by inspecting the repositories in `~/src/` (tallyflow-web, photomicroservice, tallyflow-iot, tallyflow_mobile, tallyflow-print, etc.).
+## Data Flows
+- **Assets, Print, Capture** → Core: Solid lines (primary, always-available flows)
+- **IoT → Core**: Dashed line (optional, event-driven)
+- Core Web UI and Print UI are shown as sub-elements within their respective components
 
-## Key Data Flows
-- **Assets (Mobile) ↔ Core**: Enrollment, inventory updates, seek/find sync via API
-- **Capture → Core**: Photo metadata and QC records
-- **Print → Core**: Print jobs and optional asset registration
-- **IoT → Core**: Real-time tag/sensor events
-- **Core ↔ MongoDB**: Core owns and directly manages all persistent data (assets, photos, zones, history)
-- **Core Web UI (Vue.js)**: Operator interface for the full system
-
-Core is the only component that directly owns the database. All other modules are clients or data producers that route through Core.
+This structure was verified by reviewing the actual source repositories in `~/src/`. All external modules interact exclusively through Core’s API layer.