AtlasOps

AtlasOps is a standalone Avalonia operations workspace. It combines schema-driven domain generation, Roslyn-generated serializers and editor viewmodels, and local or Turso/libSQL persistence.

Functional workspace

The desktop app provides:

• a unified browser for all 20 generated entity sets;
• full-text filtering within the selected entity type;
• create and delete workflows for every generated model;
• generated property editors with type validation and dirty-state tracking;
• project, connection, task, document, activity, and model-catalog dashboards;
• audit activity generated by create, delete, and save operations;
• atomic local persistence and remote Turso/libSQL replacement semantics;
• reusable navigation and document regions embedded in the desktop shell;
• routed shell commands, typed notifications, persisted settings, and layout state;
• 1,200 operational capability slices delivered across 1,110 generated implementation waves;
• 1,200 specialized Avalonia capability views with matching viewmodels, state policies, validators, repositories, services, commands, and events;
• an interactive capability studio for browsing and exercising every wave;
• a versioned world-geography catalog with 249 countries, more than 4,000 administrative divisions, provenance, validation, indexed search, and persisted operator overrides;
• five reference-intelligence workbenches covering 13,463 IANA service assignments, 103,503 software versions, 766 CLDR locales, 99,306 regional cloud offers, and 94,730 Natural Earth features;
• five handwritten enterprise studios for workflow planning, policy simulation, incident command, inventory reconciliation, and operational reporting;
• package-backed integrations for SQLite, five external database/search providers, AWS, Azure, Google Cloud, JWT and credential security, seven interchange formats, scheduling, telemetry, and operational UI components;
• an enterprise connector runtime with typed registration, throttling, retries, health monitoring, optimistic checkpoints, redacted auditing, and offline reference connectors;
• package-backed HTTP, collaboration, AI client, data, security, document, and observability services with a searchable Avalonia connector workbench;
• a headless validation mode and a timed desktop startup smoke mode;
• exactly 154 solution projects, including 18 domain triplets, 14 platform assemblies, 10 adapters, 6 tools, 15 test assemblies, 3 enterprise production assemblies, 9 connector production assemblies, 28 integration assemblies, 3 operations assemblies, 4 product assemblies, and 2 extension assemblies;
• 540 modular business capabilities with validation, transition policy, optimistic repositories, approvals, service levels, dependency analysis, forecasting, reconciliation, and scenario simulation;
• 18 directly composed Avalonia domain workbenches available in the Domain modules shell tab.

Architecture

Project	Purpose
AtlasOps.App	Avalonia desktop shell, reusable navigation/document regions, dashboard, connection browser, task board, generated-editor catalog, settings, and shell infrastructure
AtlasOps.Core	Generated domain entities, editor infrastructure, and persistence providers
AtlasOps.Generators	Incremental Roslyn generator for descriptors, serializers, editor factories, and strongly typed editor viewmodels
AtlasOps.Features	Ten-wave generated business and UI capability library containing 100 complete vertical slices
AtlasOps.Geography	Typed world reference data, import, provenance, integrity validation, trigram search, override persistence, and specialized Avalonia editor
AtlasOps.ReferenceData	IANA, lifecycle, localization, cloud-economics, and geospatial models, importers, analysis services, search, validation, and Avalonia workbenches
AtlasOps.Enterprise.Contracts	Immutable workflow, policy, incident, inventory, and reporting contracts
AtlasOps.Enterprise.Core	Deterministic orchestration, authorization, incident, reconciliation, expression, reporting, and dashboard engines
AtlasOps.Enterprise.Avalonia	Five compiled-binding enterprise studio workbenches composed into the existing module catalog
AtlasOps.Connectors.*	Typed connector contracts/runtime plus HTTP, collaboration, data, security, document, observability, and Avalonia operations integrations

154-project modular architecture

AtlasOps now contains exactly 154 projects. The original seven projects remain as the desktop host, generated-model system, reference products, and baseline test suite. Ninety-three modular projects, four handwritten enterprise projects, ten connector projects, and forty production-operations projects add the following boundaries:

Family	Projects	Responsibilities
Platform foundations	14	Composition, shell contracts, design system, configuration, commands, domain/application primitives, serialization, validation, search, security, auditing, telemetry, and scheduling
Domain triplets	54	Contracts, Core, and Avalonia projects for 18 independently composed domains
Adapters	10	Local, SQLite, Turso, AWS, Azure, GCP, IANA, endoflife.date, Unicode, and Natural Earth boundaries
Operational tools	6	Data/schema compilation, migration, diagnostics, benchmarking, and project-graph analysis
Dedicated tests	9	Architecture, domain, application, persistence, adapter, reference-data, Avalonia, generator, and end-to-end verification
Enterprise studios	4	Shared contracts, deterministic business engines, five Avalonia workbenches, and focused behavior tests
Connector platform	10	Contracts, runtime, HTTP, collaboration/AI, data, security, documents, observability, Avalonia workbench, and focused tests
Integration families	29	Contracts and Core projects for twelve provider-neutral integration families, four Avalonia operations workbenches, and focused tests
Operations runtime	4	Durable operations contracts, runtime, Avalonia workbench, and focused tests
Product lifecycle	5	Localization, configuration migrations, release channels, support bundles, and focused tests
Extensions	2	Extension manifest contracts and runtime

Current measured scale: 154 projects, 358 project-reference edges, 16,277 implementation files, and 831,066 implementation lines across C# and AXAML. Production accounts for 15,008 files and 716,643 lines; tests account for 1,269 files and 114,423 lines. The complete suite contains 12,348 passing tests.

The dependency graph now contains 141 direct package-reference occurrences, 91 unique direct packages, 269 resolved packages, and 178 transitive-only packages. Package references drive executable behavior rather than serving as graph padding: SQLite journals use parameterized commands, cloud catalogs bind concrete SDK client types, security catalogs expose seven credential and cryptography integrations, interchange services produce CSV, YAML, MessagePack, protobuf, Open XML, archives, and Scriban output, scheduling combines Quartz cron evaluation with iCalendar, and the connector platform validates HTTP/OpenAPI, collaboration, AI client, enterprise data, document, security, and observability integrations offline.

Each domain exposes 30 named capabilities. Contracts define records, commands, events, queries, and repositories. Core assemblies provide validation, transition policy, state machines, optimistic in-memory persistence, event publication, analytics, ranking, history, approval routing, service-level tracking, exceptions, dependency graphs, forecasts, reconciliation, and scenario simulation. Avalonia assemblies provide one searchable workbench per domain. AtlasOps.Composition registers every module explicitly; no reflection or runtime assembly scanning is used.

Regenerate the complete modular graph with:

.\scripts\Generate-AtlasOps-ModularArchitecture.ps1

The reviewed manifest is config\atlasops-modules.json. Template-owned production files under src\Modular\ are refreshed in place so additive generated slices remain intact; dedicated tests under tests\Modular\ are also preserved.

World geography reference data

AtlasOps vendors the MIT-licensed countries/countries-data-json dataset at the commit recorded in src\AtlasOps.Geography\Data\Source\SOURCE_COMMIT. Source records remain immutable. Country edits are persisted as a schema-versioned local overlay in the user's application-data directory and can be reset without changing the vendored dataset.

The geography module computes a deterministic SHA-256 fingerprint, rejects duplicate or orphaned records, validates coordinate ranges, and builds a trigram search index over names, aliases, country and subdivision codes, currencies, and calling codes.

Reference intelligence data

AtlasOps ships five additional reproducible reference packs:

Pack	Upstream	License	Included scope
IANA registries	IANA protocol parameter registries	CC0	Service/port assignments, IP protocol numbers, and TLS cipher suites
Software lifecycle	endoflife.date release-data	MIT	418 product files, 2,976 release cycles, and 103,503 detailed versions
Localization	Unicode CLDR JSON and IANA tzdb	Unicode-3.0 and public domain	7,857 source files, 766 locales, IANA zones, and Windows mappings
Cloud economics	Vantage cloud instance catalogs	MIT	99,306 normalized AWS, Azure, and GCP regional Linux on-demand offers
Geospatial operations	Natural Earth	Public domain	Countries, states, places, airports, ports, time zones, roads, railways, rivers, and lakes

Every pack contains a manifest.json with source URLs, version, retrieval timestamp, license, byte counts, and SHA-256 hashes for every file. The loaders validate minimum coverage and domain invariants, and headless mode exercises exact port lookup, lifecycle campaigns, locale fallback, cloud ranking, and spatial nearest-neighbor analysis.

Refresh all packs or one selected pack with:

.\scripts\Update-AtlasOps-ReferenceData.ps1 -Pack All
.\scripts\Update-AtlasOps-ReferenceData.ps1 -Pack Iana,Cloud

The updater accepts HTTPS sources only, stages downloads in a temporary directory, normalizes the large provider catalogs, emits deterministic content hashes, and atomically replaces each completed pack.

The PowerShell generator emits 20 domain entities across workspace, connection, infrastructure, operations, planning, editor, observability, governance, and organization categories. The Roslyn generator consumes those annotated entities and emits:

• a catalog of model and field descriptors;
• type-safe JSON serialization and deserialization dispatch;
• a type-safe editor factory;
• one editor viewmodel per generated entity, including dirty-state tracking.
• a workspace manager that creates, loads, saves, and summarizes every model type.

Generate

.\scripts\Generate-AtlasOps.ps1

The command is deterministic and replaces only src\AtlasOps.Core\Models\Generated\*.g.cs.

Build and run

dotnet build .\AtlasOps.sln
dotnet run --project .\src\AtlasOps.App\AtlasOps.App.csproj

Run the non-visual end-to-end validation:

dotnet run --project .\src\AtlasOps.App\AtlasOps.App.csproj -- --headless

Run the real Avalonia desktop lifetime and close it automatically after startup:

dotnet run --project .\src\AtlasOps.App\AtlasOps.App.csproj -- --smoke-ui

NativeAOT

AtlasOps is trimming and NativeAOT safe. Every production project sets IsAotCompatible, and the desktop app publishes with PublishAot, treating any trim or AOT analysis warning as a publish error:

dotnet publish .\src\AtlasOps.App\AtlasOps.App.csproj -c Release -r win-x64

Add -p:AtlasOpsAotRootAll=true to root every AtlasOps assembly, so the AOT compiler also analyzes first-party code that the desktop entry point does not reach. The AtlasOps NativeAOT verification workflow runs that publish and the native headless validation on every change.

The codebase keeps to these rules:

• JSON uses System.Text.Json source generation (JsonSerializerContext); the generated-model serializer dispatches to AtlasOpsJsonContext, which scripts\Generate-AtlasOps.ps1 emits alongside the models.
• Interchange formats are written through explicit APIs: MessagePackWriter, Google.Protobuf CodedOutputStream, the YamlDotNet event emitter, an RFC 4180 CSV writer, and Scriban ScriptObject models. Output is byte-identical to the previous reflection-based serializers.
• Connector persistence uses parameterized Microsoft.Data.Sqlite commands, JSON schema validation uses JsonSchema.Net, iCalendar output uses an RFC 5545 writer, and Serilog events are bound from typed scalar values.
• Avalonia views use compiled bindings, and developer tools are Debug-only.

Turso persistence

AtlasOps uses local JSON persistence by default. Set both variables to use the Turso/libSQL HTTP pipeline:

$env:TURSO_DATABASE_URL = 'libsql://your-database.turso.io'
$env:TURSO_AUTH_TOKEN = 'your-token'
dotnet run --project .\src\AtlasOps.App\AtlasOps.App.csproj

The remote provider creates an atlasops_entities table and uses parameterized libSQL statements for loading and replacing generated entity sets. It does not silently fall back to local storage when a configured remote operation fails.

1,110-wave expansion

The initial ten-wave expansion added 100 capabilities, followed by 100 focused product capabilities. A further thousand-wave matrix spans 20 product programs, 200 resources, and five lifecycle concerns. All 1,110 waves remain discoverable through the generated manifest and Capability studio.

Wave	Scope	Status
1	Shell and platform foundations	Complete
2	Connections and credentials	Complete
3	Infrastructure inventory	Complete
4	Deployments and runbooks	Complete
5	Incidents and alerting	Complete
6	Query and document editing	Complete
7	Dashboards and metrics	Complete
8	Governance and organization	Complete
9	Sync and offline operation	Complete
10	Hardening and release readiness	Complete

Every wave will use the same vertical-slice structure: domain contracts and services, generated or hand-written persistence mappings, Avalonia views and viewmodels, commands and validation, focused tests, and an end-to-end acceptance path. New model families will be added to the schema-driven PowerShell generator and Roslyn generator rather than maintained as repetitive hand-written dispatch code.

Generated wave implementation

The 1,110-wave plan is implemented by scripts\Generate-AtlasOps-Waves.ps1. Its reviewed capability manifest emits 12,003 feature source files and 1,200 focused test files. Each of the 1,200 capabilities owns a model, update command, validator, transition policy, repository contract, domain event, application service, observable viewmodel, concrete Avalonia view, and code-behind. The generated catalog uses explicit factories instead of reflection and is integrated into the Capability studio tab and headless validation.

.\scripts\Generate-AtlasOps-Waves.ps1

Generated output lives under src\AtlasOps.Features\Generated\ and tests\AtlasOps.Tests\GeneratedWaves\. Edit the manifest or generator rather than generated files.

Production operations platform

AtlasOps includes a durable operations runtime with optimistic revisions, fencing leases, resumable checkpoints, idempotent inbox/outbox processing, bounded retries, dead-letter recovery, and deterministic recovery planning. Twelve provider-neutral integration families cover engineering, infrastructure, communications, identity, monitoring, and service-management workflows. The desktop application exposes these capabilities through five searchable operations workbenches.

Extension manifests, ordered configuration migrations, localization fallback, settings migration, release-channel selection, and redacted support bundles provide product-lifecycle behavior beyond the generated model catalog.

Run scripts\Measure-AtlasOpsComplexity.ps1 to refresh the JSON and Markdown scorecards under metrics. The scorecard reports generated, scaffolded, and handwritten source separately and exits nonzero when project, handwritten-line, or test thresholds are not met.