1. Architectural Framework and
Layered Hierarchy
The strategic foundation of the MyDC system is
a strictly layered architecture, designed to ensure enterprise-grade stability
and total decoupling of the heavy AI logic from the Presentation layer.
Maintaining this separation is a non-negotiable architectural mandate; it
prevents the User Interface (UI) from becoming blocked during intensive
computational tasks like OCR, voice transcription, or vector generation.The
system is partitioned into five distinct layers. To ensure maintainability and
prevent the introduction of non-standard C# patterns during the autonomous
development cycle, C# projects must
match the folder structure exactly for namespaces (e.g., namespace MyDC.Core.Interfaces).|
Layer Name | Primary Responsibility | Technology Stack | Communication Protocol
|| ------ | ------ | ------ | ------ || MyDC.UI | Presentation and User
Interaction | C# WPF (MVVM) | Direct Reference (UI -> App) || MyDC.App
| Application Logic & Controller Coordination | C# .NET | Interface
Injection || MyDC.Core | Domain Layer, Interfaces, and Contracts | C#
(Class Library) | Shared Definitions || MyDC.Infrastructure |
Persistence, APIs, and File Watchers | SQLite, Kestrel, .NET | Direct Data
Access || MyDC.Bridge | AI Heavy Machinery & Python Logic | Portable
Python | gRPC (App -> Bridge) |
Architectural integrity is enforced by the
.agent/rules/ directory. These .md rulesets act as persistent memory for the
development cycle, mandating strict adherence to naming conventions and
structural boundaries. This ensures that the system maintains an
enterprise-level codebase even as complex features—such as voice transcription
via faster-whisper—are integrated.
2. The Plugin Shell:
IProfessionalAddon Contract and Dynamic Loading
The MyDC system must be built as a
"Plugin Shell" rather than a static application. This architecture
ensures the platform is future-proof, allowing professional addons (e.g.,
AutoCAD or 3D Printing modules) to be integrated without modifying the core
application logic.
2.1 The IProfessionalAddon
Interface
The IProfessionalAddon interface in MyDC.Core
serves as the mandatory contract for all extensions. Every addon must satisfy
the following:
●
Metadata: Identification via AddonName,
Version, and SupportedExtensions (e.g., .dwg, .stl).
●
Logic: Implementation of ExtractMetadata(string
path), returning technical data as key-value pairs for the EAV database model.
●
UI Components: Implementation of
GetViewerControl(string path), which must return a specialized WPF UserControl
(e.g., a 3D viewport using Helix Toolkit) for the main Viewer Pane.
2.2 Isolated Loading and the
Extension Manager
Addon discovery is managed by the "Plugin
Loader" within MyDC.Infrastructure. The system must utilize AssemblyLoadContext for dynamic loading. This modern approach is
required to provide strict isolation, allowing the system to load conflicting
dependencies (such as two different versions of a 3D library) without
compromising the stability of the hub.The
Extension Manager logic
flow is prescribed as follows:
- File
Selection:
The UI detects a file selection event.
- Plugin
Query: The
Extension Manager queries all loaded IProfessionalAddon instances.
- Support
Confirmation:
Plugins confirm support based on file extension.
- Control
Injection:
The UI dynamically swaps the active ContentControl with the
plugin’s specific UserControl.
3. Hybrid Persistence Layer:
SQLite and the Metadata Schema
MyDC utilizes a "Flexible Database"
strategy to handle disparate data types from multiple domains (e.g.,
Engineering, Academic, Hobby) without requiring frequent schema migrations.
3.1 Dual-Table Architecture
●
Files Table:
Standard schema for core tracking (FileName, FilePath, DateIndexed).
●
FileMetadata Table: Implements an Entity-Attribute-Value (EAV)
model. This allows an AutoCAD addon to store "Project Number" while a
3D Print addon stores "Filament Weight" for the same file record
within a single flexible table.
3.2 Atomic Transactions and
Referential Integrity
To prevent data corruption and orphaned
records, the system must enforce Atomic
Transactions using
SqliteTransaction. The following logic is mandatory:
- Insert
File Record:
Save primary file data.
- Row ID
Retrieval:
The system must execute SELECT last_insert_rowid();
within the same connection session to retrieve the FileId and prevent race
conditions.
- Metadata
Insertion:
Link all key-value pairs to the retrieved FileId.
- Commit/Rollback: All operations must
succeed, or the transaction is rolled back.The FileMetadata table must
utilize ON DELETE CASCADE to ensure that when a file is removed from the
index, its AI-generated metadata is automatically purged, maintaining
database cleanliness.
4. The AI Integration Bridge:
gRPC and Semantic Search
Heavy AI computation is offloaded to the
MyDC.Bridge layer. This Python-powered bridge ensures that the C# frontend
remains responsive during intensive tasks.
4.1 gRPC Communication
High-speed communication between C# and Python
is facilitated via gRPC. The Python "Heavy Machinery" hosts local
models including faster-whisper for voice transcription and the
all-MiniLM-L6-v2 transformer for vector generation.
4.2 Semantic Search Architecture
MyDC moves beyond standard SQL text matching
to implement "Semantic Meaning" search:
●
Model Selection: While LlamaSharp is a general
alternative, the system must utilize all-MiniLM-L6-v2 for generating the
384-dimension vectors.
●
Vector Storage: Vectors are stored in a virtual
table using the SQLite-vec extension.
●
Query Logic: C# queries must utilize the
vec_distance_cosine function to calculate mathematical distance between search
intent and indexed metadata. This allows a search for "Structural" to
retrieve .dwg drawings even if the specific keyword is absent from the
filename.
5. Cross-Platform
Synchronization: .NET MAUI Satellite and Kestrel API
The "Field-to-Desk" workflow allows
mobile devices to act as scanners and remote viewers for the desktop hub. This
is powered by a .NET MAUI satellite app and the MyDC.Infrastructure Kestrel Web
API.
5.1 Discovery and Communication
The mobile app must utilize mDNS/ZeroConf for
network discovery. It is hardcoded to seek a specific service string: _mydc-hub._tcp . This eliminates the
need for manual IP configuration in academic or professional environments.
5.2 Functional Requirements
●
Mobile Capture: Native camera integration for
document scanning and high-speed OCR ingestion via the Desktop API.
●
Remote Search: Querying the desktop’s vector
index from the mobile interface.
●
Offline Save: For "pinned" or
"favorited" files, the mobile app
must utilize the sqlite-net-pcl library to manage its local offline database,
distinguishing its persistence layer from the desktop's standard
Microsoft.Data.Sqlite.
6. Enterprise Deployment:
Portability and Dependency Management
The system is mandated to achieve a
"Zero-Dependency" installation, allowing it to run without
administrative rights or a pre-installed .NET/Python environment.
6.1 Portable Packaging and
Staging
True portability is enforced by the Root Relative Path Rule . The
application must use AppDomain.CurrentDomain.BaseDirectory for
all file and runtime references, ensuring the system remains functional
regardless of its installation path.
6.2 PowerShell Staging
Requirements
A PowerShell "Staging" script is
required to automate the distribution build. The script must perform the
following:
- Bundle the
self-contained .NET runtime into the root executable.
- Embed the
Portable Python distribution (python_runtime).
- Distribute
the necessary SQLite-vec and Tesseract OCR binaries.
- Mandatory
Folder Creation:
The script must explicitly create the /Addons folder in the
distribution directory to ensure immediate functionality
post-deployment.This five-phase architecture, spanning from local gRPC
bridges to cross-platform mobile satellites, fulfills the mandate for a
high-value, professional-grade document controller that is as portable as
it is powerful.
Comment Below if you want to help on this project.
