| @@ -1,4 +1,4 @@ |
| 1 | # DomainDig v4.4.1 Architecture |
1 | # DomainDig Architecture |
| 2 | |
2 | |
| 3 | ## Overview |
3 | ## Overview |
| 4 | |
4 | |
| @@ -19,9 +19,9 @@ Inspection flow: |
| 19 | - `LookupRuntime`: orchestrates section services for a single inspection. |
19 | - `LookupRuntime`: orchestrates section services for a single inspection. |
| 20 | - `DomainInspectionService`: builds inspection snapshots with provenance, cache state, and failure metadata. |
20 | - `DomainInspectionService`: builds inspection snapshots with provenance, cache state, and failure metadata. |
| 21 | - `DomainReportBuilder`: assembles summaries, insights, risk scoring, workflow context, and report metadata. |
21 | - `DomainReportBuilder`: assembles summaries, insights, risk scoring, workflow context, and report metadata. |
| 22 | - `DomainReportExporter`: renders TXT, CSV, and JSON output for app and local API use. |
22 | - `DomainReportExporter`: renders TXT, CSV, JSON, Markdown, and PDF output for app and local API use. |
| 23 | - `DomainViewModel`: coordinates SwiftUI state, persistence, audit sessions, monitoring, workflows, batch operations, imports, and exports. |
23 | - `DomainViewModel`: coordinates SwiftUI state, persistence, audit sessions, monitoring, workflows, batch operations, imports, and exports. Its surface is split by concern across `DomainViewModel+Audit`, `+Monitoring`, `+Export`, `+Workflows`, `+History`, and `+Widget` extensions; the core type keeps the stored state and the inspection pipeline. |
| 24 | - SwiftUI views: render screens and invoke view-model actions. |
24 | - SwiftUI views: render screens and invoke view-model actions. The largest view file was decomposed too — Settings screens live in `SettingsViews.swift` and the result detail sections in `ResultSectionViews.swift`. |
| 25 | |
25 | |
| 26 | ## Audit Mode |
26 | ## Audit Mode |
| 27 | |
27 | |
| @@ -76,7 +76,16 @@ The app remains local-first. Purchase and entitlement code is local app infrastr |
| 76 | - `DomainReportExporter` |
76 | - `DomainReportExporter` |
| 77 | - `LocalAPIModels` |
77 | - `LocalAPIModels` |
| 78 | |
78 | |
| 79 | The major-version roadmap calls for a stronger compatibility promise around this local API contract in `v5.0.0`. |
79 | `v5.0.0` stabilized this contract: `LocalAPIContract` is the single source of truth for the `v1` wire version and JSON encoder, the response envelope and payloads are documented, and the shape is regression-locked by `LocalAPIContractTests`. See [local-api.md](local-api.md) for the endpoint and compatibility reference, and [data-migration.md](data-migration.md) for how the persisted store is versioned across app updates. |
| |
80 | |
| |
81 | ## Testing |
| |
82 | |
| |
83 | Two test targets run from the `DomainDig` scheme's test action: |
| |
84 | |
| |
85 | - `DomainDigTests` — unit coverage of the deterministic core: `DomainReportBuilder`, `DomainReportExporter`, `DiffService`, `DomainDataPortabilityService` (merge/replace dedup), the store-migration runner, and the Local API contract. `SnapshotFixture` builds the deep `LookupSnapshot`/`DomainReport` models through the real builder so tests construct inputs without wiring every field. |
| |
86 | - `DomainDigUITests` — Apple's `performAccessibilityAudit()` over every primary screen at default and largest Dynamic Type, plus metadata and screenshot assertions. See [ACCESSIBILITY.md](ACCESSIBILITY.md). |
| |
87 | |
| |
88 | A plain `xcodebuild test` (and CI) runs both. The unit net went in first in `v5.0.0` and is what made the god-file decomposition safe to attempt. |
| 80 | |
89 | |
| 81 | ## Xcode Project Structure |
90 | ## Xcode Project Structure |
| 82 | |
91 | |