uto_manager/master_development_plan.md

Master Development Plan: Flutter-Based Military Unit Task Organization Enterprise System (U.S. Army 2026 Doctrine)Executive Architectural Strategy & Cross-Platform Engine DesignThe modern military operational environment demands command and control (C2) software capable of rapidly modeling, manipulating, and displaying unit task organizations (UTOs) that conform to evolving force structures. The objective of this development plan is to establish the software architecture, technical specifications, domain data models, and deployment roadmap for a cross-platform application developed in Flutter. The platform creates, visualizes, and validates U.S. Army unit task organizations starting at the individual soldier position level and building up to multi-domain brigade formations. The application targets three primary operating environments: Microsoft Windows x64 desktop, modern web browsers via WebAssembly and CanvasKit, and mobile devices running Android.To achieve native operational performance across these diverse targets from a single Dart code base, the system relies on a multi-tiered layered clean architecture integrated with a reactive state management paradigm. Flutter's underlying rendering model, which utilizes the Impeller engine on native platforms and CanvasKit on the web, allows for consistent low-level GPU drawing routines. This design separates platform-specific visual rendering from domain validation logic, ensuring that Army Modified Table of Organization and Equipment (MTOE) business rules execute identically regardless of whether the software runs on a command post Windows workstation or an Android tactical tablet.Platform TargetPrimary Deployment MechanismTarget Performance BaselinePlatform-Specific Integration RequirementsWindows x64Native Executable (.msi / .exe)60 FPS under 5,000+ active graph nodesFull keyboard shortcut integration, multi-window support, precision mouse wheel pan/zoom, high-DPI scaling.WebWebAssembly (WASM) / CanvasKit60 FPS under 2,000+ active graph nodesOptimized asset loading, IndexedDB persistence, memory-bounded canvas surface allocation.AndroidNative Package (.apk / .aab)60 FPS under 1,500+ active graph nodesTouch-optimized gesture targets, drag threshold haptics, responsive bottom-sheet inspectors, battery profiling.The technical foundation decouples the presentation layer from underlying data persistence. The architecture employs a state management approach using reactive primitives (such as BLoC or Signals) to broadcast atomic state changes across UI components. When a planner moves an individual position slot or an entire maneuver platoon across the visual workspace, the state layer processes the interaction as a structural transaction. The transaction evaluates unit attachment rules, checks command relationships, updates spatial relationships, and notifies the visual canvas without triggering full widget tree rebuilds.[Presentation Layer: CustomPainter / InteractiveViewer / Responsive Shell] │ ▼ [Application State Layer: BLoC / Signals / Super Drag-and-Drop Pipeline] │ ▼ [Domain Layer: MTOE Doctrinal Rules Engine / Structural Validation] │ ▼ [Infrastructure Layer: Drift SQLite / IndexedDB / Protobuf Codecs] Cross-platform drag-and-drop interactions require careful handling to bridge desktop mouse interactions and mobile touch events. While standard Flutter gesture detectors handle basic internal drag events, complex cross-component canvas dragging across different viewports is implemented using specialized abstraction wrappers like super_drag_and_drop. This ensures that drag payloads—containing unit identifiers, subordinate hierarchies, and associated equipment data—retain structural integrity during movement across the organizational workspace.Interactive Visual Canvas Architecture & Visual Drag-and-Drop SubsystemRendering thousands of hierarchical military elements—from a four-man infantry fire team to a 4,500-soldier Brigade Combat Team—requires a visual graph engine optimized for low-latency spatial transformations. Standard Flutter layout widgets like NestedScrollView, Row, or Column are inadequate for large dynamic diagrams due to the rendering overhead of heavy widget trees. Consequently, the platform's visualization engine uses a hybrid architectural approach combining Flutter's low-level CustomPainter API with tailored spatial indexing.Visual Engine StrategyCore Architectural ImplementationScalability ThresholdLatency & Performance ProfilePackage-Based (diagram_editor / graph_edit)Pre-built node widgets managed by interactive controllers and built-in serialization codecs.500 – 1,000 active nodes before frame dropping occurs.Fast initial development velocity; frame rates decrease when rendering large, fully populated brigade trees.Bespoke CustomPainter EngineDirect GPU canvas drawing calls (drawPath, drawParagraph, drawRect) bypassing the Widget layer.10,000+ active nodes using viewport spatial culling.Maximum rendering performance; requires custom code for viewport matrices, node hit testing, and collision routing.The bespoke canvas engine uses a custom viewport management layer wrapping a CustomPainter instance inside a multi-touch InteractiveViewer. Viewport transformations (pan offsets and scale factors) are maintained in a 4x4 matrix ($M$). To maintain a consistent 60 FPS frame rate when rendering large formations, the painter executes spatial culling on every paint pass. The engine calculates the visible canvas bounding box by multiplying the screen dimensions ($S$) by the inverse transformation matrix ($M^{-1}$):$$\text{Viewport}{\text{visible}} = M^{-1} \times S$$Nodes and parent-child connection lines falling outside this calculated bounding box are skipped during the paint() execution pass, avoiding unnecessary GPU rasterization and text layout computations.Organizational visual layouts strictly enforce standardized military hierarchical tree structures using an adapted Reingold-Tilford tree layout algorithm. The position of any node N at echelon level L is calculated dynamically based on subordinate subtree widths, ensuring clean horizontal separation across functional branches (Maneuver, Fires, Reconnaissance, Engineer, Sustainment) and vertical alignment across echelons (Brigade, Battalion, Company, Platoon, Squad, Team, Individual Position).[Brigade Headquarters (O-6)] │ ├─── [Infantry Battalion (O-5)] ─── [Rifle Company (O-3)] ─── [Rifle Platoon (O-2)] │ │ │ └─── [Rifle Squad (E-6)] │ │ │ ├─── [Alpha Team Leader (E-5)] │ │ ├─── Automatic Rifleman (E-4) │ │ ├─── Grenadier (E-4) │ │ └─── Rifleman (E-3) │ └─── [Bravo Team Leader (E-5)] │ ├─── Combat Medic (E-4) │ ├─── sUAS Drone Operator (E-4) │ └─── Rifleman (E-3) │ └─── [Field Artillery Battalion (O-5)] The visual drag-and-drop re-parenting engine follows a deterministic event state machine:Selection and Payload Isolation: Initiating a drag gesture captures the target node identifier, isolates its complete subordinate subtree, and extracts it into an overlay rendering layer.Spatial Collision and Validation: As the dragged node moves across the workspace, the engine executes spatial proximity queries against a Quadtree spatial index containing candidate parent nodes.Doctrinal Relationship Evaluation: The domain engine evaluates proposed parent-child connections against Army structural rules. Attaching a Rifle Squad to an Infantry Platoon renders a green target highlight, whereas attempting to attach a Fire Team directly to a Brigade Headquarters displays an invalid red indicator unless designated as a detached element.Drop Execution and Re-indexing: Releasing the node executes a re-parenting command, updates relational keys in the local store, triggers the Reingold-Tilford layout recalculation, and notifies the visual painter via optimized shouldRepaint calls.Military Domain Model & Expanded Personnel Position SyntaxThe platform models military task organizations down to individual soldier positions across all Combat Arms, Combat Support (CS), and Combat Service Support (CSS) Career Management Fields (CMFs). The software structures formations around Military Occupational Specialties (MOS), pay grades, leadership responsibilities, and Line Item Numbers (LIN) defined by Army doctrine.The domain model represents an individual soldier as a personnel record that fills an authorized position slot within a specific organizational unit. A unit (such as a Rifle Squad, Medical Evacuation Section, or Signal Network Platoon) contains a collection of position slots and subordinate elements.Domain AttributeData TypeValidation ConstraintsOperational DescriptionUnit IDUUID v4Non-null, unique keyUnique database identifier for the operational formation.EchelonEnumBrigade, Battalion, Company, Platoon, Section, Squad, TeamTactical command level governing hierarchy rules.Doctrinal BranchEnumInfantry, Medical, Fires, Signal, Cyber/EW, Aviation, LogisticsFunctional branch governing duty slot requirements.Position TitleStringStandardized military title dictionaryOfficial duty title (e.g., "Platoon Leader", "Combat Medic Specialist").Duty MOSStringStandardized 3-character/digit codeRequired specialty code (e.g., "11B", "68W", "13F", "25H", "17E").Authorized RankEnumE-1 through E-9, W-1 through W-5, O-1 through O-10Required pay grade for the duty slot.Key Leader FlagBooleanTrue / FalseIdentifies primary command nodes for command availability checks.Assigned PersonnelObject (Optional)Single active assignment limitLinks an individual soldier record to the authorized slot.Individual position definitions within the system populate a multi-branch dictionary representing combined-arms force structures:[Individual Personnel Record] ──(Fills 0..1)──> [Authorized Position Slot] ──(Belongs to)──> [Unit Node] │ (Assigned Duty MOS) │ ▼ [MTOE Specialty Standard] Core Duty Positions Across Functional BranchesInfantry & Tactical Maneuver:Platoon Leader (MOS 11A / O-2/O-1): Directs tactical maneuver, fires, and force protection for the platoon.Platoon Sergeant (MOS 11B / E-7): Senior non-commissioned officer managing logistics, soldier welfare, and tactical movement execution.Squad Leader (MOS 11B / E-6): Leads a 9-soldier maneuver element.Team Leader (MOS 11B / E-5): Directs a 4-soldier tactical fire team.Automatic Rifleman (MOS 11B / E-4): Operates primary automatic weapon systems (e.g., XM250 NGSW-AR).Grenadier (MOS 11B / E-4/E-3): Operates area-denial grenade launcher systems.Rifleman (MOS 11B / E-3/E-2): Core dismounted combatant equipped with the XM7 service rifle.Medical & Health Services (CMF 68):Combat Medic Specialist (MOS 68W / E-4/E-5): Attached to maneuver platoons or organic to battalion medical platoons; provides immediate tactical combat casualty care (TCCC), point-of-injury triage, and battlefield stabilization.Medical Evacuation NCO (MOS 68W / E-6): Coordinates ground ambulance (AMPV/M113) or air ambulance (HH-60M) medevac assets within the Brigade Support Battalion (BSB) or Aviation Battalion.Treatment NCO (MOS 68W / E-6): Operates Role 1/Role 2 Battalion Aid Stations (BAS) to process casualties.Field Artillery & Fire Support (CMF 13):Joint Fire Support Specialist / NCO (MOS 13F / E-4 to E-6): Organic to field artillery target acquisition elements but forward-deployed with maneuver companies and platoons to call for, adjust, and coordinate artillery, mortar, and close air support fires.Field Artillery Automated Tactical Data System (FAATDS) Operator (MOS 13D / E-4): Computes firing data at battery/battalion Fire Direction Centers (FDC).Signal & Communications Network (CMF 25):Network Communication Systems Specialist (MOS 25H / E-4/E-5): Installs, operates, and maintains tactical satellite terminals, line-of-sight communications, and IP network backbones at company, battalion, and brigade command posts.Cyber & IT Specialist (MOS 25B / E-4/E-5): Configures tactical tactical router stacks, battle management software, and command post servers.Electromagnetic Warfare & Cyber (CMF 17):Electromagnetic Warfare Specialist (MOS 17E / E-4 to E-6): Assigned to Multi-Domain Effects Platoons (MDEP) and brigade electronic warfare sections; executes direction-finding, electronic attack, GPS spoofing mitigation, and electromagnetic spectrum monitoring.Unmanned Aerial Systems & Robotics (CMF 15 / Multi-Branch):sUAS / FPV Drone Operator (MOS 15W or 11B/19D with sUAS Certification / E-4/E-5): Serves in Hunter-Killer Platoons (HKP) and company sUAS teams; operates short/medium-range reconnaissance drones and First-Person View (FPV) loitering munitions.Tactical UAS Operator (MOS 15W / E-4/E-5): Operates higher-echelon unmanned aircraft (e.g., MQ-9A Reaper or launched effects) within Combat Aviation Brigades.Logistics, Supply, & Ordnance (CMF 91 / 92):Unit Supply Specialist / NCO (MOS 92Y / E-4 to E-6): Manages unit MTOE property accounts, coordinates Class I (rations), Class V (ammunition), and Class IX (repair parts) supply distribution within Forward Support Companies (FSC).Automated Logistical Specialist (MOS 92A / E-4): Manages supply warehouse operations at the Brigade Support Battalion.Wheeled / Tracked Vehicle Mechanic (MOS 91B / 91A / E-4/E-5): Executes battlefield maintenance and recovery for ISV, Stryker, Bradley, and Abrams vehicle fleets.Combat Engineers (CMF 12):Combat Engineer (MOS 12B / E-4 to E-6): Conducts obstacle breaching, route clearance, minefield emplacement, and urban mobility tasks within Sapper platoons.Validation logic in the domain layer runs continuously to identify structural anomalies. The engine flags MOS misalignments when a soldier's primary MOS does not match the authorized slot code (e.g., a 11B assigned to a 68W medic slot). It highlights rank mismatches, vacant leadership slots, and missing critical support roles (such as a maneuver platoon lacking an attached 68W medic or 13F fire support specialist), ensuring complete operational readiness visibility.Doctrinal Unit Templates (2026 / Army 2030 Baseline)The application includes pre-configured, standardized doctrinal templates representing the U.S. Army's 2026 force structures. These templates allow planners to instantiate complete, structurally accurate combined-arms formations in a single action. [Brigade Combat Team / Brigade] │ ┌──────────────────┬───────────────────┼───────────────────┬──────────────────┐ │ │ │ │ │ [Maneuver Bns (x3)] [Cavalry Sqn] [Field Artillery Bn] [Brigade Engineer Bn] [Brigade Support Bn] Mobile Brigade Combat Team (MBCT)In accordance with Army modernization directives, standard Infantry Brigade Combat Teams (IBCTs) transition to Mobile Brigade Combat Teams (MBCTs). The MBCT addresses light infantry mobility constraints by integrating the M1301 Infantry Squad Vehicle (ISV) across maneuver elements.MBCT Rifle Squad Architecture: Structured around the "Squad as a System" (SaaS) concept, the MBCT rifle squad comprises 9 dismounted soldiers optimized to deploy from a single ISV platform. The squad consists of 1 Squad Leader (E-6), 2 Team Leaders (E-5), 2 Automatic Riflemen equipped with the XM250 Next Generation Squad Weapon-Automatic Rifle (NGSW-AR), 2 Grenadiers equipped with XM7 rifles and M320 launchers, 1 Rifleman/sUAS Drone Operator, and 1 Rifleman.MBCT Rifle Platoon Structure: Contains a Platoon Headquarters (Platoon Leader O-2/O-1, Platoon Sergeant E-7, Radio Operator 25H/E-3, attached Combat Medic 68W/E-4, attached Fire Support NCO 13F/E-6), three 9-soldier Rifle Squads, and an integrated weapons section. Tactical ground movement is provided by an organic fleet of ISVs.Multi-Domain Additions: Modernized MBCT templates include the Multi-Domain Effects Platoon (MDEP), which provides electronic warfare (17E), counter-unmanned aerial systems (C-sUAS), and electromagnetic spectrum operations. Hunter-Killer Platoons (HKPs) combine small unmanned aerial systems (sUAS) with precision targeting assets.Stryker Brigade Combat Team (SBCT)The SBCT serves as the Army's medium combined-arms force, balancing rapid operational deployment with dismounted infantry capability.Maneuver Element: Comprises three Stryker Infantry Battalions, each organized with a Headquarters and Headquarters Company (HHC) containing organic medical platoons (68W), signal sections (25H), and sniper sections.Cavalry Reconnaissance Squadron: Features an HHT, three Stryker Cavalry Troops, and an Anti-Tank Troop equipped with 9 Stryker Anti-Tank Guided Missile (ATGM) vehicles.Field Artillery & Sustainment: Contains a Field Artillery Battalion with three batteries of M777A2 155mm towed howitzers (24 tubes total), a Brigade Engineer Battalion (BEB) containing signal (25H), military intelligence, and combat engineer (12B) companies, and a Brigade Support Battalion (BSB) for medical, distribution, and maintenance execution.Armored Brigade Combat Team (ABCT)The post-2023 / 2026 ABCT structure standardizes three Combined Arms Battalions (CABs) to balance heavy armor firepower with mechanized infantry dismounts.Combined Arms Battalions (x3): Formed as two Armor-Heavy CABs and one Infantry-Heavy CAB. Armor-Heavy CABs contain an HHC, two Tank Companies (14 M1A2 SEPv3 Abrams tanks each), and one Mechanized Infantry Company (14 M2A3/A4 Bradley IFVs). HHC elements integrate Battalion Medical Platoons (68W), Mechanic Sections (91A/91B), and Scout Platoons.Armored Cavalry Squadron: Contains an HHT, three Armored Cavalry Troops (equipped with Bradley Fighting Vehicles and JLTVs), and one organic Tank Troop (14 M1A2 Abrams).Artillery & Engineering: Supported by a Field Artillery Battalion with three batteries of M109A7 Paladin 155mm self-propelled howitzers (18 total systems) and a Brigade Engineer Battalion providing Sapper platoons (12B) directly to each CAB.Combat Aviation Brigade (CAB)Under the Army 2030 force design, Combat Aviation Brigades were streamlined through the divestment of standalone Air Cavalry Squadrons in FY2025/2026. CAB structures are organized into Heavy and Light divisional aviation profiles.Heavy Combat Aviation Brigade: Configured with an Attack Aviation Battalion (24 AH-64E Apache Guardian helicopters, pilots 153A, crew chiefs 15T), an Assault Helicopter Battalion (30 UH-60M Black Hawks, 12 CH-47F Chinooks), an Air Ambulance Company (15 HH-60M medevac helicopters operated by 68W flight medics and 153A aviators), and an Aviation Support Battalion (ASB) for intermediate maintenance (15B/15D/15G) and supply distribution (92Y).Light Combat Aviation Brigade: Contains an Attack Reconnaissance Battalion (AH-64E assets integrated with Troop F MQ-9A Reaper / sUAS teams), an Assault Helicopter Battalion (UH-60M and CH-47F elements), an Assault Helicopter Battalion (Medical), and an Aviation Support Battalion.Brigade Template TypeManeuver BattalionsOrganic ReconnaissanceOrganic Fires & ArtilleryPrimary Vehicle / PlatformMobile BCT (MBCT)3x Mobile Infantry Battalions1x Cavalry Squadron1x Artillery Bn (2x 105mm, 1x 155mm Towed)M1301 Infantry Squad Vehicle (ISV)Stryker BCT (SBCT)3x Stryker Infantry Battalions1x Stryker Cav Sqn + Anti-Tank Troop1x Artillery Bn (3x 155mm M777A2 Towed)Stryker Infantry Carrier Vehicle (8x8)Armored BCT (ABCT)2x Armor-Heavy, 1x Infantry-Heavy CAB1x Armored Cav Sqn (with Tank Troop)1x Artillery Bn (3x 155mm M109A7 Paladin)M1A2 SEPv3 Abrams / M2A3/A4 BradleyCombat Aviation Brigade1x Attack Aviation Bn, 1x Assault Helicopter BnIntegrated sUAS / Troop F AssetsPrecision Air-Delivered Munitions (JAGM/Hellfire)AH-64E / UH-60M / CH-47F AircraftUI/UX Framework & MIL-STD-2525D Symbology Subsystem AnalysisThe user interface implements a three-pane workstation configuration designed for high data density and efficient workspace interaction.┌────────────────────────────────────────────────────────────────────────────────────────┐ │ Main Military Application Header (Echelon Selector, Doctrinal Mode, Export Tools) │ ├───────────────────────┬────────────────────────────────────────┬───────────────────────┤ │ Left Panel: │ Central Visual Workspace: │ Right Panel: │ │ Doctrinal Templates │ Interactive Node-Graph Engine │ Node Inspector │ │ & Component Palette │ (Panning, Zooming, Drag-and-Drop) │ & Position Editor │ │ │ │ │ │ - 2026 MBCT Template │ [Brigade HQ] │ - Unit ID & Name │ │ - 2026 SBCT Template │ │ │ - Assigned MOS │ │ - 2026 ABCT Template │ ├── [Infantry Bn] │ - Personnel Search │ │ - 2026 CAB Template │ │ └── [Rifle Platoon] │ - Weapon Assignment │ │ - Echelon Blocks │ └── [Artillery Bn] │ - Readiness Status │ ├───────────────────────┴────────────────────────────────────────┴───────────────────────┤ │ Status Bar (Viewport Scale Factor, Active Node Count, MTOE Validation Status) │ └────────────────────────────────────────────────────────────────────────────────────────┘ The workstation layout organizes core workflows into functional zones:Left Panel (Template & Component Palette): Collapsible sidebar containing drag-and-drop building blocks, including complete 2026 brigade templates, battalion/company frameworks, and standalone duty position slots across all branches (Infantry, Medical, Signals, EW, UAV, Supply).Central Visual Workspace: Main interactive area hosting the infinite graph canvas, displaying hierarchical unit lines, command relationships, manning levels, and MIL-STD-2525D tactical map symbols.Right Panel (Node Inspector & Position Editor): Context-sensitive inspector that updates upon selecting a unit or soldier node. It provides editing controls for duty titles, personnel assignments, MOS qualifications, rank requirements, organic equipment allocations, and operational readiness toggles.Third-Party Package & Library Evaluation for MIL-STD-2525 SymbologyRendering standard military symbology in accordance with MIL-STD-2525D/E requires constructing complex 2D vector graphic compositions featuring geometric frames, main function icons (e.g., medical cross, signal lightning bolt, artillery cannon, infantry rifles), status modifiers, and multi-line textual annotations. [ Echelon Modifier: ║║ (Platoon) ] │ ┌────────────────┴────────────────┐ │ ┌─────────────────────────┐ │ │ │ Friendly Frame (┌┐) │ │ │ │ │ │ │ │ Function Icon: + │ │ <── Text Designator: "1/A/1-187 IN (MED)" │ │ (Medical Cross) │ │ │ │ │ │ │ └─────────────────────────┘ │ └─────────────────────────────────┘ Evaluating third-party packages, external Javascript libraries, and native C/Rust interop options reveals three distinct implementation strategies for cross-platform Flutter rendering:Integration ApproachTechnical MechanismPlatform SuitabilityPerformance & Memory OverheadArchitectural Trade-Offsmilsymbol.js via JS Interop / QuickJSUses the open-source milsymbol JavaScript library via dart:js_interop on Web, and an embedded QuickJS engine / Headless WebView on Windows and Android.Outstanding native execution on Web; requires embedded JS runtimes on Windows and Android.Low on Web; higher memory footprint and asynchronous string passing latency on native mobile/desktop platforms.Complete MIL-STD-2525D compliance out-of-the-box; introduces external JavaScript execution runtime dependencies on desktop/mobile platforms.Rust Native Core (milsymbol-rs via FFI)Compiles a Rust-based 2525 renderer into native C-shared libraries (.dll for Windows, .so for Android, WebAssembly .wasm for Web) bound via Dart FFI.Uniform high performance across Windows, Android, and Web Assembly.Sub-millisecond rasterization speed; minimal CPU and memory overhead.Maximizes performance and platform consistency (used in native C2 clients like OmniTAK); requires cross-compiling native binaries for target toolchains.Bespoke Native Dart Vector Engine (xml + path_drawing)Parses modular SVG component files directly using pure Dart xml and path_drawing packages into cached native Flutter Path primitives.100% native execution across Windows, Web, and Android without external runtimes.Direct GPU canvas drawing via CustomPainter; zero context-switching overhead.Eliminates third-party engine dependencies; requires building an internal SIDC symbol-code lookup map and bundling SVG asset sets.Selected Symbology ArchitectureTo ensure zero external native binary dependencies while maintaining maximum frame rates on low-power tactical Android tablets and WebAssembly deployments, the system adopts a hybrid vector pipeline:Web Target: Directly interfaces with milsymbol.js via lightweight Dart JS Interop (dart:js_interop) to output inline SVG paths.Native Targets (Windows & Android): Utilizes a native Dart parser that decodes SVG vector paths using path_drawing into immutable Path instances. Symbol components are cached in a thread-safe LRU memory cache indexable by 15-digit Symbol Identification Codes (SIDC).A complete tactical symbol is drawn on the GPU canvas by layering visual primitives:$$\text{Tactical Symbol} = \text{Frame}{\text{Affiliation}} + \text{Icon}{\text{Function}} + \text{Modifier}{\text{Echelon}} + \text{Text}_{\text{Designator}}$$The painter renders a friendly blue frame, places the functional icon (such as medical cross, infantry cross-rifles, or signal lightning bolt), applies echelon modifiers (such as vertical bars for platoons or crosses for battalions), and appends unit text designators alongside.The UI adjusts dynamically across supported hardware targets:Windows Desktop: Displays all three panes concurrently, supporting keyboard navigation (Ctrl+Z undo, Ctrl+F search, Ctrl+D duplicate sub-tree), mouse-wheel pan/zoom, multi-node box selection, and right-click context menus.Web (WASM): Matches the desktop layout while optimizing canvas surface memory and enabling responsive panel toggles for narrower browser windows.Android Tablet/Mobile: Replaces side panels with slide-out bottom sheets and navigation drawers. Touch targets expand to a minimum size of 48x48 dp, and tap-and-hold radial menus replace desktop right-click interactions.Implementation Roadmap, Persistence Architecture, & Performance HardeningSystem implementation follows a five-phase development lifecycle spanning 24 weeks, transitioning from baseline architecture to production platform distribution builds.[Phase 1: Architecture & Data Foundations (Weeks 1-4)] │ ▼ [Phase 2: Canvas Graphics Engine & Gesture Subsystem (Weeks 5-9)] │ ▼ [Phase 3: 2026 Doctrinal Templates & Symbology Engine (Weeks 10-14)] │ ▼ [Phase 4: Persistence, Validation Rules, & Export Engine (Weeks 15-19)] │ ▼ [Phase 5: Platform Optimization, Profiling, & Hardening (Weeks 20-24)] Phase 1: Architecture & Data Foundations (Weeks 1 – 4): Establish the layered clean architecture codebase, define core Dart domain entities (covering Infantry, Medical, Signal, EW, UAV, Supply, and Engineer positions), construct serialization schemas, and configure continuous integration pipelines for Windows, Web, and Android targets.Phase 2: Canvas Graphics Engine & Gesture Subsystem (Weeks 5 – 9): Build the bespoke CustomPainter rendering layer inside an InteractiveViewer, implement Quadtree spatial indexing, integrate matrix viewport transformations, and construct the cross-platform drag-and-drop state machine.Phase 3: 2026 Doctrinal Templates & Symbology Engine (Weeks 10 – 14): Construct pre-configured template libraries for Mobile BCTs, Stryker BCTs, Armored BCTs, and Combat Aviation Brigades. Implement the hybrid MIL-STD-2525D symbology pipeline.Phase 4: Persistence, Validation Rules, & Export Engine (Weeks 15 – 19): Integrate the Drift transactional database for local storage, construct the real-time MTOE domain validation engine, and develop data export modules supporting JSON, Protobuf, and vector PDF chart rendering.Phase 5: Platform Optimization, Profiling, & Hardening (Weeks 20 – 24): Execute performance profiling using Flutter DevTools, offload heavy graph calculations to background Dart Isolates, isolate visual layers with RepaintBoundary widgets, and assemble release packages (.msi, WASM, .apk).Data persistence utilizes Drift (a type-safe reactive SQLite abstraction layer) on Windows and Android, mapping seamlessly to IndexedDB when running in web environments.Table NamePrimary KeyForeign Key ReferencesStorage Purposeunitsunit_id (UUID)parent_unit_id -> units(unit_id)Stores organizational structure, echelons, and hierarchy links.position_slotsslot_id (UUID)unit_id -> units(unit_id)Stores authorized duty titles, MOS requirements (11B, 68W, 13F, 25H, 17E, 92Y, etc.), and pay grades.personnelsoldier_id (UUID)slot_id -> position_slots(slot_id)Stores soldier profiles, MOS qualifications, and readiness states.templatestemplate_id (UUID)NoneStores serialized JSON structures for 2026 force templates.Performance hardening strategies keep rendering latency below critical limits:Dart Isolates: Layout algorithms (such as Reingold-Tilford tree positioning) and heavy MTOE validation logic run within background Dart Isolates, preventing computational spikes on the main UI thread.Layer Isolation: The canvas separates static elements (grid lines, parent-child link lines) from dynamic elements (active node drag previews) using distinct RepaintBoundary widgets, ensuring that dragging an item only repaints the modified overlay layer.Path Optimization: Vector paths for MIL-STD-2525D symbols are parsed once upon application launch, cached as binary Path objects in memory, and rendered via canvas.drawPath() offset calls, eliminating runtime XML parsing overhead.Operational Extensibility & Architectural AnalysisDeveloping command and control software requires accommodating evolving force structures, varying deployment environments, and network constraints. Analyzing the second- and third-order impacts of key architectural decisions ensures long-term operational viability.[2026 Army Force Structure Updates] │ ▼ [Externalized JSON Template Rules] ──► Decouples doctrine from binary code updates │ ▼ [Offline-First Drift/SQLite Engine] ──► Ensures continuous operation during network loss │ ▼ [Delta Command Synchronizer] ──► Minimizes bandwidth overhead across contested tactical networks Adapting to Future Doctrinal ReformsThe transition from Infantry BCTs to Mobile BCTs—alongside ongoing modifications to Combat Aviation Brigades—demonstrates how military force designs evolve over time. Hardcoding unit structures directly into UI code would require full application re-compilation and distribution for every doctrinal update.To solve this issue, the platform externalizes force structure definitions into serialized JSON schema files loaded at runtime. When Army force managers modify an MTOE standard (such as adjusting dismount counts within an ISV rifle squad or adding unmanned system operators to a battalion staff), system administrators simply issue an updated JSON definition file. The domain engine parses the new file, updates the template library, and applies the revised validation rules across active task organizations without requiring client binary patches.Gesture Subsystem InteroperabilityEngineers constructing multi-platform drag-and-drop systems must account for differences in input hardware. Desktop mouse interactions offer precise point selection, whereas touch inputs on mobile devices introduce gesture ambiguity, such as distinguishing between panning a graph view and selecting a node for re-parenting.The application resolves input conflicts using an adaptive gesture pipeline. Mouse interactions initiate node drag operations immediately upon exceeding a 2-pixel movement threshold. On touch interfaces, dragging requires a long-press gesture (200ms) accompanied by haptic feedback before unlinking a node from the canvas. This distinction prevents accidental structural changes when users pan across large organizational diagrams on mobile or tablet displays.Offline-First Operation in Contested Network EnvironmentsTactical command posts frequently operate in contested communications environments characterized by bandwidth constraints or intermittent network loss. The application prioritizes an offline-first transactional data model to maintain operational utility under degraded conditions.All user interactions, node re-parenting operations, and personnel assignments write directly to the local transactional database (Drift/SQLite). When network connectivity is degraded or lost, the application continues to operate locally without interruption. When connectivity is restored, a delta synchronization engine transmits queued atomic command events (such as AttachNode or AssignPersonnel) rather than re-transmitting entire organizational models. This event-driven synchronization approach minimizes bandwidth consumption and prevents data conflicts across distributed command elements operating in contested environments.