MDO Platform Dashboard

BanksFamily Multi-Project Deployment Platform • Host 1.0.0 • .NET 9.0.20 (Production)

Platform Operational Uptime 44.1 m

Platform Status Operational Main Host online

Host Version 1.0.0 Standalone Basic Shell

Installed Packages 0 Dynamic runtime activation

Available Packages 6 Ready in catalog (6 total)

Package Discovery Distribution

Real live package count grouped by authoritative installation state

6 Total

0 Installed 6 Available

Host Runtime Diagnostics

Platform environment and system diagnostic parameters

Runtime Active

Environment Production
Framework .NET 9.0.20
Operating System Microsoft Windows 10.0.26100
Startup Time (UTC) 2026-09-28 18:57:31
Uptime 44.1 minutes

Solution Standards & Architecture (Step 1)

Established

BanksFamily.Group.MDO enforces strict tripartite boundaries to prevent package business logic from leaking into the Main host or Core platform:

1. Main Application Host (Minimal)

Hosts the startup pipeline, configuration, authentication shell, static assets, and dynamic navigation rendering. Does not own package business features.

2. Core Platform Foundation

Supplies shared contracts for dynamic navigation registration, package lifecycle, security contracts, and background worker queuing. Does not hardcode provider integrations.

3. Package-First Feature Catalog

Features are built directly as isolated installable packages with explicit dependencies and their own authoritative lowercase packageversion.json.

Initial Package Catalog

10 Packages

Planned MDO installable packages to be constructed per Step 4 standards:

Package Name	Type	Status
`MDO.AzureDevOps`	Provider	Pending
`MDO.ProjectManagement`	Feature	Active (Steps 51-53)
`MDO.PackageManagement`	Feature	Phase 3 Complete (Steps 36-50)
`MDO.VersionManagement`	Feature	Active (Steps 54-55)
`MDO.Pipelines`	Feature	Pending
`MDO.Releases`	Feature	Pending
`MDO.Environments`	Feature	Pending
`MDO.DeploymentQueue`	Feature	Pending
`MDO.Approvals`	Feature	Pending
`MDO.HistoryAudit`	Feature	Pending

Package Version Standards & Lifecycle (Step 5)

SemVer 2.0.0

MDO strictly preserves the separation between version states. A proposed version must never falsely indicate that a package has been built, released, or deployed:

1. Proposed

Pending approval in MDO

2. Source

Authoritative packageversion.json

3. Build

CI Pipeline execution

4. Released

Artifact published & gated

5. Deployed

Target environment active

6. Previous

History & rollback state

Semantic Change Types & Preview

Patch: Bug fixes / non-breaking tweaks (e.g. 1.4.7 → 1.4.8)
Minor: Backward-compatible features (e.g. 1.4.7 → 1.5.0)
Major: Breaking changes requiring dependency review (e.g. 1.4.7 → 2.0.0)
Manual: Validated SemVer entered directly

Environment Tracking Boundaries

Development Quality (QA) Business (UAT) Production

Environments maintain independent deployed version tracking and are not assumed to share the same version simultaneously.

CI/CD & Azure DevOps Standards (Step 6)

Decoupled Provider Architecture

Azure DevOps is treated strictly as an external provider package (MDO.AzureDevOps). Core and Main remain completely provider-independent, ensuring future providers (GitHub Actions, GitLab, Jenkins) can be added without altering platform foundations.

1. Pipeline Hierarchy Mapping

Full database mapping from application down to artifact:

Project → Package → Org → ADO Project → Repo → Pipeline → Artifact

2. Multi-Scope Pipeline Triggering

• Single Package: Isolated build
• Package Set: Ordered dependency build
• Application: Full suite (CRM, RMM, etc.)
• Release Bundle: Coordinated bundle

3. Standard azure-pipelines.yml

Every package maintains its own azure-pipelines.yml generated from the approved MDO template.

• Reads version from packageversion.json
• Preserves custom edits safely

4. Security & Asynchronous Workers

• Zero Hardcoded Secrets: No PATs/tokens in code
• Runtime Resolution: ISecretResolver
• Browser Independent: Background Worker Queue
• Artifact Association: Tracked across lifecycle

Database Architecture & Standards (Step 7)

Dedicated MDO Database

MDO has its own dedicated database supporting Main/Core platform foundation data and independently installable MDO packages with strict schema ownership boundaries:

1. Schema Ownership Model

• Core Schema (core): Platform settings, users, roles, permissions, registry, and health.
• Package Schemas: Isolated per package (ado, pm, pkg, ver, rel, etc.).
• No Silent Cross-Ownership: Packages cannot alter each other's tables.

2. Independent Migrations

Core and packages upgrade independently. Package upgrades never rebuild the entire MDO database.

• Version compatibility checks
• Migration checksum validation
• Safe rollback tracking

3. Lifecycle & Retention

• Disable != Delete: Disabling a package keeps data 100% intact.
• PreserveData: Default uninstall retention.
• ArchiveData: Export to archive store.
• PurgeData: Explicit admin opt-in only.

4. Consistency & Security

• Zero Plaintext Secrets: Strict ban on plaintext tokens/passwords.
• Unit of Work: Atomic multi-table transactions.
• Immutable Audit: Before/after operational snapshots.
• Authoritative Version: packageversion.json preserved.

Package Installation & Lifecycle Standards (Step 8)

16 Lifecycle States

MDO governs package installation through safe, dependency-aware lifecycle operations, pre-execution planning, separate install vs enable gates, and post-installation health checks:

1. 16 Lifecycle States

MDO strictly separates install states from operational/enable states:

Available NotInstalled Installing Installed Enabled Disabled ConfigRequired DependencyMissing VersionIncompatible UpgradeAvailable Upgrading InstallationFailed UpgradeFailed Uninstalling Uninstalled Error

2. Pre-Install Validation

• Identity & Metadata: Verified package descriptor
• Core Compatibility: Minimum platform version
• Dependency Graph: Dependency existence & versions
• Database Readiness: Pending schema migrations
• Security: Permissions and config readiness

3. Dependency-Aware Planning

IPackageInstallationPlanner resolves execution plans prior to mutating state:

• Topological dependency sorting
• Circular dependency prevention
• Package set membership resolution
• Safe rollback readiness

4. Health & Safe Uninstall

• Installed != Operational: Health checks verify config
• Disable != Delete: Menus hide, data preserved
• Controlled Uninstall: Preserve, Archive, or Purge
• Comprehensive Audit: Full lifecycle event log

UI & Navigation Standards (Step 9)

Data-Driven & Permission-Aware

The visual presentation is anchored in Mosaic Lite (Tailwind CSS v4 + React design system adapted for ASP.NET Core MVC), Bootstrap 5.3.3 utilities, dynamic permission-aware menus, and data-driven project navigation:

1. Application Shell

• Shared Shell: Header, responsive sidebar, footer, toasts.
• Permanent Menus: Dashboard, Admin, Settings only.
• Zero Hardcoding: No future package menus in Main.
• Isolation: Menu registration failures caught safely.

2. Data-Driven Projects

Managed project navigation entries are loaded dynamically via configuration and data:

CRM RMM DatabasePerformance MultiSitePortal

3. Permission-Aware Menus

• Runtime Filtering: IUserContext permissions.
• Submenu Hierarchy: Parent/child dropdown rendering.
• Server-Side Auth: Menus never substitute for auth checks.
• Active State: URL routing matches active tabs.

4. Status Badges & Extensions

• Status Taxonomy: StandardStatusDescriptor
• Version Chips: Distinct Source vs Proposed vs Deployed
• Dashboard Registry: Pluggable package widgets
• Responsive Shell: Desktop collapse + mobile drawer

History, Audit & Operational Standards (Step 10)

Full Lifecycle Traceability • Steps 0–10 Complete

MDO guarantees end-to-end operational traceability across all lifecycle stages, separates operational history from security audits, classifies actors, and treats failures as first-class records:

1. End-to-End Correlation

Chained multi-stage correlation:

Project → Pkg → Ver → Pipe → Build → Art → Rel → Appr → Deploy → Result

• Chained via immutable CorrelationId

2. History vs Audit

• Operational History: What ran, which version, which environment, and final result.
• Security Audit: Who initiated, who approved, what changed, and authorization context.

3. Actor Classification

Automated tasks are never misattributed to users:

InteractiveUser BackgroundWorker ScheduledJob ProviderCallback SystemProcess

4. Failures & Safe Audit

• First-Class Failures: Partial failures never reported as success.
• Batch Summaries: Overall + per-package outcomes.
• Zero Plaintext Secrets: Automated redaction.
• MDO.HistoryAudit: Extended package boundary.

Main Application Foundation (Step 11)

Phase 1 Host Foundation • Step 11 Complete

BanksFamily.Group.MDO establishes the minimal application host shell using the Step 0 Mosaic Lite template, isolating host concerns from Core and feature packages:

1. Minimal Host Shell

• Root: BanksFamily.Group.MDO
• UI Shell: Mosaic Lite Tailwind v4 + Bootstrap
• Boundary: Zero business logic in host

2. Host Configuration

• Options: MdoHostConfiguration
• Secrets Policy: Zero plaintext credentials
• Sections: MdoHost configuration block

3. Runtime Diagnostics

• Diagnostics: HostEnvironmentInfo
• Runtime: .NET 9.0 on Windows
• Uptime: Startup tracking & telemetry

4. Architecture Decoupling

• No Database Yet: Defers to Core schema
• Dynamic Nav: Prepared for Core & packages
• No Feature Pkgs: Preserved for Phase 3

Main Startup, Configuration and Host Services (Step 12)

Host Modularization • Step 12 Complete

Establishes the minimal Main application startup, dependency injection, logging, authentication shell, error handling, and host service registration structure:

1. Modular Host Extensions

• Program.cs: Ultra-clean single-responsibility setup
• Foundation: AddMdoHostFoundation()
• Pipeline: UseMdoHostPipeline()
• Decoupled: No package logic in Main

2. Auth Host Registration

• Auth Host: AddMdoAuthenticationHost()
• Cookie Policy: Secure, HttpOnly, Lax, 8-hour
• Authz Host: AddMdoAuthorizationHost()
• Extensible: Plugs into Core permissions

3. Registration Entry Points

• Core Entry: AddMdoCoreHost()
• Package Entry: AddMdoPackageDiscovery()
• Worker Boundary: Decoupled async queue
• DB Boundary: Schema metadata prepared

4. Startup Validation

• Pre-flight: MdoStartupValidator
• Registry Audit: Verifies Core singletons in DI
• Safe Logging: Zero plaintext secrets exposed
• Error Shield: Production detail isolation

Main Shared Layout and Navigation Host (Step 13)

Dynamic Navigation Host • Step 13 Complete

Establishes the shared Mosaic Lite application layout, dynamic hierarchical breadcrumb trail, and resilient navigation host ready for Core and package contributions:

1. Responsive Shell

• Template: Mosaic Lite Tailwind v4 + Bootstrap
• Collapsible: Desktop toggle + mobile drawer
• Theme: Persistent light/dark mode
• Footer: Live host diagnostics and uptime

2. Dynamic Navigation

• Host Model: MenuItem contracts
• Active State: Automatic route highlighting
• Submenus: Parent-child hierarchy
• No Hardcoding: Future projects/packages data-driven

3. Breadcrumb Engine

• Engine: IBreadcrumbService
• Hierarchy: MDO → Project → Package → Page
• Auto-Deduction: Route data or custom override
• Accessible: ARIA-compliant breadcrumb trail

4. Resiliency & Context

• Fault Isolation: Package errors don't crash shell
• User Profile: Header context chip & roles
• Permission Guard: Hides unauthorized links
• Boundary: Menu visibility != authorization

Main Authentication and Authorization Host Foundation (Step 14)

Security Host • Step 14 Complete

Establishes the host-level authentication and authorization infrastructure, cookie session management, sign-in/out lifecycle, access-denied handling, and provider-independent security bridges:

1. Authentication Host

• Host Shell: /Account/Login & /Account/Logout
• Cookie Session: Secure, HttpOnly, Lax, 8-hr sliding
• Provider Neutral: Independent of CI/CD providers
• Safe Logging: Zero passwords/tokens logged

2. Authorization Host

• Policies: Role and claim-based evaluation
• Denied Route: /Account/AccessDenied
• Decoupled: No package permissions in Main
• Enforcement: Server-side route authorization

3. User Context Bridge

• Bridge: HttpContextUserContext
• ClaimsPrincipal: Maps to IUserContext
• Role Evaluation: Dynamic multi-role checks
• Navigation Guard: Controls menu item visibility

4. Security Boundaries

• Main Role: Host infrastructure only
• Core Role: Owns Users/Roles/Permissions (Phase 2)
• Package Role: Registers feature permissions
• Zero Hardcoding: Future permissions package-driven

Main Logging, Error Handling and Health Foundation (Step 15)

Diagnostics • Step 15 Complete

Establishes host logging, safe error handling, end-to-end request correlation, honest health inspections, and zero-secret redaction across the application pipeline:

1. Safe Logging & Redaction

• Redactor: SafeLogRedactor regex masking
• Zero Leaks: PATs, tokens, passwords sanitized
• Scopes: Enriched with active CorrelationId
• Audits: Safe security logs for auth events

2. Resilient Error Handling

• 404 Handling: Dedicated Mosaic NotFound page
• 500 Shield: Production stack traces suppressed
• Status Pages: UseStatusCodePagesWithReExecute
• Correlation: Errors tagged with Request/Corr IDs

3. End-to-End Correlation

• Middleware: CorrelationMiddleware
• Headers: X-Correlation-ID propagation
• Context: Injected ICorrelationContext
• Cross-Cutting: Links requests to audit records

4. Host Health Foundation

• Service: HostHealthService
• Endpoint: /health & /api/health JSON report
• Checks: Host, Core, Worker Queue, DB boundary
• Honest State: Never fakes nonexistent components

Main Core and Package Discovery Entry Points (Step 16)

Discovery • Step 16 Complete

Establishes clean, provider-independent Core initialization and package discovery entry points. Main remains a lean host that delegates platform features to Core and discovers installable packages dynamically:

1. Core Entry Point

• Contract: ICoreHostBootstrapper
• Isolation: Main knows zero internal Core mechanics
• Registries: Navigation, Permissions, Widgets
• Extensible: Prepares DB and health hook-ins

2. Dynamic Package Discovery

• Contract: IPackageDiscoveryHost
• Zero Edits: Main needs no code changes per package
• Metadata: IPackageDescriptor contract
• State: Version, dependencies, enabled status

3. Fault Isolation Boundary

• Resilience: Try/catch per package registration
• Auditing: PackageRegistrationSummary
• Crash-Free: Optional package failure isolated
• Ordering: Dependency-aware resolution

4. Provider Independence

• No Hardcoding: Zero Azure DevOps logic in Main
• Identical Model: MDO.AzureDevOps as standard pkg
• Discovery vs Install: Discovery only in Step 16
• Lifecycle: Installation deferred to Phase 3

Main Worker and Background Processing Boundary (Step 17)

Worker Boundary • Step 17 Complete

Establishes a strict boundary between interactive web requests and asynchronous background operations. Main never blocks requests for long-running deployments, pipeline polling, or build jobs:

1. Worker Separation

• Host Boundary: Prepares MDO.Worker
• Browser Resilient: Independent of tab closures
• Future Work: Builds, releases, queues, polling
• Non-Blocking: Channels outside HTTP request

2. Safe Job Contracts

• Descriptor: IBackgroundJobDescriptor
• Submission: BackgroundJobSubmission
• Zero Secrets: Hard rejection of secret keys
• Metadata: Priority, Status, Version, User

3. Request Boundary & Safety

• Dispatcher: IBackgroundJobDispatcher
• Fast Return: Main returns job status instantly
• Idempotency: Deduplication key protection
• No Direct DB: No premature queue tables

4. Correlated Traceability

• Correlation: Propagated CorrelationId
• Logging: Step 15 safe redaction logging
• Audit Trail: Web, worker & audit linked
• Crash Recovery: Lifecycle status tracking

Main Validation and Phase 1 Readiness (Step 18)

Comprehensive architectural compliance review across Steps 11–17

Phase 1 Gate • Ready for Core JSON Report

Validates BanksFamily.Group.MDO Main host against all Phase 1 architectural standards. Confirms that Main is a lean, decoupled host, zero plaintext secrets exist, all entry points and boundaries are safe, and the host is ready for Core platform development:

Phase 1 Architecture Verification: PASSED

12 of 12 Architecture, Security, Host, and Boundary requirements passed. 0 blocking issues. Ready to begin Phase 2 (Core implementation).

12 Checks Passed 0 Blocking Issues

1. Architectural Separation

• Minimal Host: Zero domain logic in Main
• 10 Domains: No Azure DevOps, Pipelines, etc.
• Clean Naming: BanksFamily.Group.MDO
• Zero BDO: Legacy BDO strictly purged

2. Template & UI Reuse

• Template: Mosaic Lite responsive layout
• Styles: Tailwind CSS v4 & Bootstrap
• Visuals: Chart.js & Tabler Icons
• Reuse: Zero duplicate UI frameworks

3. Entry Points & Boundaries

• Core Boot: ICoreHostBootstrapper
• Package Discovery: IPackageDiscoveryHost
• Worker Queue: IBackgroundJobDispatcher
• Dynamic Nav: INavigationRegistry

4. Security & Traceability

• Zero Secrets: Hardened against token leaks
• Redactor: SafeLogRedactor active
• Correlation: X-Correlation-ID header
• Health: /health & /readiness APIs

Main Deployment and Environment Configuration Foundation (Step 19)

Environments • Step 19 Complete

Establishes environment configuration profiles and deployment packaging standards across Development, Quality, Business/UAT, and Production without embedding package-specific deployment logic or credentials:

1. Environment Profiles

• Environments: Dev, Quality, Business, Prod
• Precedence: JSON → Env Vars → KeyVault
• Profiles: HostEnvironmentProfileOptions
• Decoupled: No package deployment logic

2. Database & Worker Boundaries

• Connection String: MdoDatabase key
• Zero Database: Schema creation deferred
• Worker Mode: InProcess or DedicatedService
• Endpoints: Configured for future worker

3. Production Host Safety

• Diagnostics: Dev tools disabled in Prod
• Safe Errors: Generic friendly error views
• Zero Secrets: Hardened against leaks
• Log Levels: Warning in Prod, Debug in Dev

4. Standard Framework Publish

• Standard Tooling: dotnet publish verified
• Template Assets: Mosaic CSS/JS packaged
• Zero Machine Paths: Fully portable output
• Zero Package Deps: Standalone Main build

Main Phase 1 Completion Gate (Step 20)

Phase 1 - Main Application Host complete. Formal authorization for Phase 2 - Core Platform implementation.

Phase 1 Complete Phase 1 JSON Gate

Phase 1 Milestone Passed: Ready for Step 21 (Core Phase)

All 8 Phase 1 quality gates (Architecture, Naming, Template, Security, Navigation, Package, Worker, Environment/Publish) have been validated with zero blocking issues.

8 / 8

Gates Passed

Blocking Issues

YES

Ready for Core

1. Architecture Gate

Main is a minimal host; zero feature-package business logic for the 10 catalog packages.

Passed

2. Naming Gate

Root namespace BanksFamily.Group.MDO; zero legacy BDO or BankOnUs references.

Passed

3. Template Gate

Step 0 Mosaic Lite layout, Tailwind CSS v4, Bootstrap, Chart.js, and Tabler Icons intact.

Passed

4. Security Gate

Cookie auth host, scoped user context, safe error views, and zero plaintext secret leaks.

Passed

5. Navigation Gate

Dynamic menus hosted through Core INavigationRegistry without hardcoded catalog data.

Passed

6. Package Gate

Main boots with 0 optional packages; IPackageDiscoveryHost isolates optional package failures.

Passed

7. Worker Gate

Background jobs queued asynchronously via channels; separate Worker process deployment ready.

Passed

8. Environment & Publish

4 environment profiles (Dev, QA, UAT, Prod); verified portable dotnet publish delivery.

Passed

Phase 2 • Step 21 Platform Foundation Active

Core Application Foundation

MDO.Core established as required platform foundation; Main host connected via clean decoupled boundary.

.NET 9.0 Core Decoupled Entry Point

1. Core Registration Boundary

• Entry Point: AddMdoCorePlatform()
• Encapsulation: Core owns internal services
• Host Decoupling: Main delegates cleanly
• Namespace: Core.Extensions

2. Core Platform Bootstrapper

• Contract: ICorePlatformBootstrapper
• Permissions: Dashboard, Admin, Settings, Pkgs
• Permanent Nav: Dashboard, Admin, Settings
• Projects: Dynamic roots (CRM, RMM, etc.)

3. Provider & Package Independence

• Zero References: No optional pkg dependencies
• No ADO Logic: Azure DevOps remains external
• Future Providers: Pluggable provider architecture
• Standalone Boot: Operational with 0 pkgs

4. Health & Database Boundaries

• Health Check: ICorePlatformHealthCheck
• DB Boundary: Schema deferred to Step 23
• Pkg Infra: Lifecycle deferred to Steps 30-34
• Honest Metrics: Zero simulated DB checks

Phase 2 • Step 22 Shared Contracts Active

Core Shared Contracts Foundation

Authoritative shared contracts established in MDO.Core for cross-component integration without package coupling.

.NET 9.0 Contracts Provider-Independent

1. Package Metadata & Registration

• Metadata: IPackageMetadata
• Registration: IPackageRegistrationContext
• Capabilities: Services, Nav, Perms, Health, Hooks
• Zero ADO: Common contract is provider-free

2. Navigation & Security Contracts

• Menu Contract: IMenuItem interface
• Permission Contract: IPermissionDescriptor
• Implementations: MenuItem & CorePermission
• Compatibility: Step 13 shell preserved

3. Health & Lifecycle State

• Health Status: CommonHealthStatus enum
• Status Report: IPlatformStatusReport
• Lifecycle State: PackageState (16 states)
• Safe Reporting: Zero sensitive data leaks

4. Settings, Worker & Events

• Settings Access: IPlatformSettingsAccessor
• Background Job: IBackgroundJobRequest
• Event Publishing: IPlatformEventDescriptor
• Platform Service: ICorePlatformService

Phase 2 • Step 23 Database Foundation Active

Core Database Foundation

Initial MDO database foundation established for Core platform data and package registry persistence strictly in schema [core].

EF Core 9.0 Schema: [core]

1. Schema & Object Ownership

• Schema: Exclusively [core]
• Core Tables: Settings, Users, Roles, Packages
• Zero Pkg Tables: No ADO or feature schemas
• Conventions: PK_core_* & FK_core_*

2. Persistent Package Registry

• Table: [core].[Packages]
• State Tracking: Installed, enabled, health
• Source Version: packageversion.json
• Zero ADO Fields: Provider-free table schema

3. Unit of Work & Migrations

• Transactions: IDatabaseUnitOfWork
• Audit Table: [core].[Migrations]
• Independent: No full database rebuilds
• Zero Secrets: No credentials in columns

4. Health & Graceful Offline Boot

• Health Check: CoreDatabaseHealthCheck
• Initializer: ICoreDatabaseInitializer
• Offline Safe: Host boots if DB unavailable
• No Leaks: Safe diagnostics without creds

Phase 2 • Step 24 Navigation Foundation Active

Core Navigation Foundation

Permanent Core navigation foundation established in MDO.Core with hierarchical submenus, permission filtering, and dynamic breadcrumb routing.

.NET 9.0 Navigation Dynamic Hierarchy

1. Permanent Core Navigation

• Dashboard: core.dashboard (Order 10)
• Administration: core.admin (Order 20)
• Settings: core.settings (Order 30)
• Group: Core owns Platform group

2. Hierarchical Submenus

• Users: core.admin.users submenu
• Roles: core.admin.roles submenu
• Permissions: core.admin.permissions
• Tree Linking: Auto parent-child nesting

3. Breadcrumbs & Routing

• Breadcrumb Trail: IBreadcrumbService
• Resolution: MDO → Admin → Users/Roles
• Active Highlighting: Auto route detection
• Mosaic Shell: Responsive collapsible layout

4. Permission Guard & Decoupling

• Permission Guard: IUserContext checks
• No Hardcoding: No project items in Core boot
• Package Driven: Projects dynamic in Phase 3
• Fault Isolated: Navigation safe under failures

Phase 2 • Step 25 Dashboard Foundation Active

Core Dashboard Foundation

First functional BanksFamily.Group.MDO Core Dashboard displaying live platform metrics, real Chart.js visualizations, and extensible package contribution hooks without fabricated data.

.NET 9.0 Dashboard Real Data Only

1. Real Platform Metrics

• Host Diagnostics: Version, runtime, uptime
• Core Registries: Real component metrics
• Database Status: Schema [core] connectivity
• Zero Fabrication: No mock pipeline/build data

2. Live Chart.js Charts

• Package Distribution: State donut chart
• Subsystems Density: Component bar chart
• Theme-Aware: Mosaic Lite responsive canvas
• Accessible: Text footers accompany charts

3. Extensible Contributions

• Metric Tiles: DashboardMetricTile hooks
• Quick Actions: DashboardQuickAction shortcuts
• Widgets: DashboardWidgetDescriptor
• Zero Edits: Future packages plug in cleanly

4. Fault-Tolerant & Safe

• Fault Isolation: Widget try/catch shield
• Zero Secrets: Hardened against token leaks
• Permissions: IUserContext filtering
• Offline Resilient: Tolerates DB offline state

Phase 2 • Step 26 Administration Foundation Active

Core Administration Foundation

Secure Core Administration area established with controller-level authorization, Users/Roles/Permissions entry points, and approved package extension registry.

.NET 9.0 Security Authorized Area

1. Server-Side Authorization

• Policy: RequireAdministrator
• Permission: core.view_admin
• Server Enforced: Not just menu hiding
• Multi-Role: Beyond single IsAdmin flag

2. Governance Entry Points

• Users: /Administration/Users
• Roles: /Administration/Roles
• Permissions: Full dynamic matrix
• Ready for 27/28: Prepares CRUD steps

3. Package Admin Extensions

• Registry: IAdministrationExtensionRegistry
• Package Hooks: Section descriptors
• Zero Core Edits: Packages register dynamically
• Fault Isolated: Bad link won't crash Admin

4. Audit & Diagnostics

• Audit Logging: Access events tracked
• Zero Leaks: Safe secret redaction
• System Info: Version, runtime, database
• Mosaic Shell: Responsive layout preserved

Phase 2 • Step 27 Users Management Active

Core Users Management

Core platform user administration established with schema [core].[Users] persistence, PBKDF2 cryptographic password hashing, administrator lockout safeguards, and security audit traceability.

PBKDF2 SHA-256 Manage Users →

1. Core-Owned User Schema

• Schema: [core].[Users]
• Roles: [core].[UserRoles]
• Zero Package Tables: Isolated in Core
• Safe Sign-In: LastLoginAt & IP tracked

2. Cryptographic Security

• Algorithm: PBKDF2 (SHA-256)
• Salting: 128-bit cryptographic salt
• Timing Defense: Fixed-time equals
• Zero Secrets: Passwords never logged

3. Lockout Safeguards

• Self-Disable: Prevented at service layer
• Sole Admin: Cannot disable last admin
• Demotion Guard: Prevents orphan admin
• Server Enforced: Not just UI disabling

4. Auditing & Traceability

• Security Audit: Every mutation logged
• Platform Events: Typed event dispatch
• Effective Perms: Role matrix resolved
• CRUD Suite: List, Create, Edit, Details

Phase 2 • Step 28 Roles & Permissions Active

Core Roles & Permissions Governance

Core platform role and permission foundation established with schema [core].[Roles] persistence, dynamic package permission registration, granular grants, and administrator lockout safeguards.

Permissions Catalog Manage Roles →

1. Role Schema & Governance

• Schema: [core].[Roles] & [core].[RolePermissions]
• System Roles: Protected from rename/deletion
• Lifecycle State: IsEnabled toggle per role
• Dual Storage: EF Core with in-memory fallback

2. Dynamic Package Permissions

• Shared Registry: IPermissionRegistry
• OwningPackageId: Strict ownership tagging
• Zero Core Contamination: Dynamic contribution
• Isolation: Package disable retains Core data

3. Lockout Safeguards

• Admin Protection: Mandatory admin permissions locked
• Disabling Guard: Cannot disable Administrator role
• Assigned Role Guard: Cannot delete populated roles
• Server Enforced: Complete API & service defense

4. Traceability & Events

• Audit Trail: Role & permission mutations logged
• Platform Events: Event publisher integration
• CRUD Suite: List, Create, Edit, Details, Toggle
• Zero Secrets: No credential leakage

Phase 2 • Step 29 Settings Management Active

Core Settings Management

Platform configuration established with schema [core].[Settings] persistence, typed descriptors, dynamic package extensions, and strict isolation of CI/CD provider credentials.

Manage Settings →

1. Categorized Platform Groups

• 5 Groups: General, Security, Package, Log, Worker
• Persistence: Schema [core].[Settings]
• Dual Storage: DB with in-memory fallback
• Typed Access: IPlatformSettingsAccessor

2. Provider Decoupling

• Zero ADO in Core: No PATs, orgs, or pipelines
• Package Separation: Handled by MDO.AzureDevOps
• Secret Defense: Plaintext secret ban
• Masking: Sensitive fields masked in UI

3. Extensible Registry

• Contract: ISettingsExtensionRegistry
• Dynamic Groups: Modular packages contribute tabs
• Ownership: Explicit OwningPackageId
• Lifecycle Safe: Package disable retains Core data

4. Validation & Traceability

• Pre-Validation: Types & bounds checked
• Restart Flags: RequiresRestart badges
• Audit Trail: Safe before/after values
• Platform Events: Event publisher integrated

Phase 2 • Step 30 Package Infrastructure Active

Core Package Infrastructure Foundation

Common platform foundation established for independently managed modular packages with IPackageCoordinator, 16-state lifecycle taxonomy, authoritative packageversion.json, and deterministic 11-step pipeline registration.

Package Catalog →

1. Authoritative Standards

• Version Standard: packageversion.json
• Pipeline Standard: azure-pipelines.yml
• Non-Overwriting: Template protection
• Dual Storage: DB tracks runtime version

2. 16-State Lifecycle

• Separate States: Installed vs Enabled
• Disable != Delete: Data 100% preserved
• Taxonomy: 16 distinct lifecycle states
• Isolation: Faults isolated per package

3. Deterministic Pipeline

• 11 Stages: Metadata to Lifecycle
• No Auto-Operational: Must pass stages
• Dependencies: Topological ordering
• Health Checks: Pre & post validation

4. Coordinator & Worker

• Boundary: IPackageCoordinator
• Worker Queue: IBackgroundWorkerQueue
• Async Lifecycle: Background operations
• Audited: Complete traceability events

Phase 2 • Step 31 Package Discovery Active

Core Package Discovery and Validation

Deterministic package discovery engine via IPackageDiscoveryService scanning filesystem packages, reading authoritative lowercase packageversion.json, validating azure-pipelines.yml, rejecting duplicates, and isolating metadata errors.

Trigger Discovery →

1. Deterministic Discovery

• Filesystem Scan: Discovers Packages/
• Decoupled: No hardcoded logic in Main/Core
• Dynamic Search: Configurable search paths
• Available State: Discovery != Installation

2. Authoritative Versioning

• Source Truth: packageversion.json
• SemVer 2.0.0: Semantic format validated
• No DB Override: Source version rules
• Safe Parsing: Non-executing JSON reader

3. Pipeline Standards

• CI/CD Standard: azure-pipelines.yml
• Template Protection: Never overwritten
• Readiness Check: Missing pipeline flagged
• Provider Scoped: Package-level definitions

4. Validation & Isolation

• Duplicate Guard: Duplicate IDs rejected
• Failure Isolation: Errors don't crash Core
• Security: Zero untrusted script execution
• State Continuity: Preserves install history

Phase 2 • Step 32 Dependency Engine Active

Core Package Dependency & Compatibility Management

Deterministic dependency graph evaluation and ordering via IPackageDependencyResolver with topological sort, cycle detection, version constraints, and strict enable/disable/uninstall protections.

Dependency Graph →

1. Rich Dependency Model

• Structured: PackageDependencyDeclaration
• Constraints: Version operators (>=, ^, =)
• Classified: Required vs Optional flags
• Documented: Explicit reasons and purposes

2. Topological Resolution

• DAG Ordering: Kahn's algorithm sorting
• Deterministic: Prerequisite execution order
• Install Plan: Pre-execution dependency plan
• Sets Ready: Reusable for package sets

3. Cycle & Fault Detection

• Cycle Detection: DFS recursion stack
• Missing Detection: Identifies uninstalled deps
• Disabled Check: Surfaces inactive prereqs
• Compatibility: Core min/max checks

4. Lifecycle Protection

• Enable Guard: Prereqs must be enabled
• Disable Guard: Cannot disable with active dependents
• Uninstall Guard: Dependent protection
• Audit Trail: Security events on all checks

Phase 2 • Step 33 Lifecycle Operations Active

Core Package Lifecycle Operations

Common Core lifecycle coordination across Install, Enable, Disable, Upgrade, and Uninstall with concurrency locking, upgrade rollback protection, worker boundary background execution, and comprehensive domain events.

Manage Packages →

1. Lifecycle Coordination

• 16-State Flow: Installed vs Enabled separation
• Authoritative: Low-risk atomic transitions
• Persistence: Synchronized with MdoCoreDbContext
• Audit Trail: Security logs for all operations

2. Concurrency Lock

• Thread Safety: Per-package operational lock
• Race Guard: Rejects conflicting operations
• Safe Release: Try/finally guarantee
• Traceability: Explicit rejection telemetry

3. Upgrade & Rollback

• Source Truth: Reads packageversion.json
• Pre-flight: Validates core compatibility
• Safe Rollback: Preserves previous version on error
• Rollback State: PackageState.UpgradeFailed

4. Worker & Events

• Worker Boundary: IBackgroundTaskQueue dispatch
• Async Mode: runInBackground = true
• Domain Events: 11 package lifecycle events
• Zero Provider Leak: Core remains provider-free

Phase 2 • Step 34 Extension Points Active

Core Package Extension Integration

State-sensitive extension points across DI, navigation, permissions, settings, dashboard, health, database schema isolation, admin entry points, and background workers with dynamic runtime activation and fault isolation.

Inspect Extensions →

1. 9 Contribution Points

• Navigation: INavigationRegistry dynamic menus
• Security: IPermissionRegistry permissions
• Settings: ISettingsExtensionRegistry schemas
• Dashboard: IDashboardRegistry widgets

2. Dynamic State Binding

• Enable: Registers all contributions
• Disable: Deregisters all UI & menus
• Data Integrity: Database rows preserved
• Boot Sync: Hydrated packages reactivated

3. Fault Isolation

• Isolation: Extension failures caught safely
• Core Shield: Never crashes host or Core
• Widget Guard: Broken widgets show errors safely
• Telemetry: Full error logs recorded

4. Database Isolation

• Schema Ownership: Package-owned schemas
• Zero Pollution: Core [core] schema protected
• Provider Guard: Zero AzDO tables in Core
• Uninstall Policy: Preserve vs Purge options

Phase 2 Complete • Step 35 Gate Ready for Step 36: YES

Core Platform Foundation — Phase 2 Completion Gate Passed

All 17 steps (Steps 19 through 35) of Phase 2 are verified and operational. Zero Azure DevOps business logic or credentials in Core. Solution builds with 0 errors and publish gate succeeded.

Phase 2 Gate: 100% Passed

✔ Core Subsystems (1 - 5)

• Step 19: Core Solution & Platform Boundaries
• Step 20: Core Domain & Platform State Machine
• Step 21: Navigation & UI Contribution
• Step 22: Permission & Security Architecture
• Step 23: Settings & Configuration Pipeline

✔ Core Subsystems (6 - 10)

• Step 24: Dashboard Widget Infrastructure
• Step 25: Database Context & Schema Isolation
• Step 26: Health Probing & Metrics Engine
• Step 27: Background Worker Dispatch Queue
• Step 28: Platform Event Bus Subsystem

✔ Core Subsystems (11 - 15) & Lifecycle

• Step 29: Security Audit Trail & Traceability
• Step 30: Deterministic Registration Pipeline
• Step 31: Dynamic Package Discovery Engine
• Step 32: Topological Dependency Engine
• Steps 33-35: Common Lifecycle, Extensions & Gate

Phase 3: Package Platform (Steps 36 - 45)

MDO.PackageManagement Active • Steps 36-45 Complete

Catalog Diagnostics History Recovery

Phase 3 establishes user-facing package platform capabilities via MDO.PackageManagement on top of Core lifecycle mechanics: Package Management Foundation (Step 36), Catalog & Registry UI with 16-state filtering (Step 37), Safe Pre-Installation Review & Installation Workflow (Step 38), Enable/Disable Workflow with Dependent Protection (Step 39), Upgrade Workflow with Pre-Upgrade Review & Safe Rollback (Step 40), Uninstall Workflow with Pre-Uninstall Review & Explicit Data Retention (Step 41), First-Class Configuration Readiness & Safe Settings Routing (Step 42), Health & Safe Diagnostics (Step 43), Lifecycle History & Audit Separation (Step 44), and Operation Recovery, Retry & Concurrency Safety (Step 45).

✔ Steps 36 & 37: Catalog & Registry UI

• Live Catalog: Real Core discovery & registry state
• Distinction: Source Version vs Installed Version
• Filtering: 16 lifecycle state filters + search
• Authoritative: mdopackagemanagementpackageversion.json

✔ Steps 38 & 39: Install & Enable/Disable

• Pre-Install Review: DAG order & compatibility gate
• State Separation: Installed vs Enabled vs Disabled
• Dependent Protection: Blocks disable if dependents active
• Worker Boundary: Long-running async execution

✔ Step 40: Upgrade Workflow

• Upgrade Detection: InstalledVersion vs packageversion.json
• Pre-Upgrade Gate: Compatibility, migration & reload notice
• Safe Rollback: Previous version preserved on failure
• Extension Refresh: Dynamic contributions refreshed

✔ Steps 41 & 42: Retention & Config

• Pre-Uninstall Review: Dependent block & clean deactivation
• Data Retention: PreserveData default; never drop audit
• Config Required: First-class state; no raw secrets
• Settings Routing: Direct link to owning Settings

✔ Step 43: Health & Diagnostics

• Health States: Operational, Degraded, ConfigReq, Error, etc.
• Approved Contract: Consumes IPackageHealthCheck
• Safe Diagnostics: Automatic secret & token redaction
• Core Dashboard: Dynamic widget via IDashboardRegistry

✔ Step 44: Lifecycle History & Status

• Full Traceability: Correlation ID across all operations
• Retained History: Survives uninstalls, disables & restarts
• Filterable Timeline: By package, action, status, date
• Audit Decoupled: Future MDO.HistoryAudit extension hook

✔ Step 45: Recovery, Retry & Safety

• Concurrency Safety: Action-aware locks reject conflicts
• Recovery Context: Tracks failed stage & safe error detail
• Traceable Retry: Revalidates dependencies & references parent
• Audited Rollback: Restores previous known good version