Changelog

All notable changes to the application and documentation are tracked here (consolidated).

Application Releases

3.2.3 (2025-10-17) — Dashboard Hardening

Issue #56 — Hardened home dashboard for selective runtime modes (--ux, --saf-orchestrator).
routes.py: logging on index, safe defaults, graceful fallback.
features/dashboard/lib/dashboard_service.py: completed fallback keys, info/debug logs.
Result: no 500 on / across modes; clearer diagnostics.

3.2.2 (2025-10-17) — CLI Runtime Modes (Phase 1)

Issue #47 — Single entrypoint main.py with normalized flags.
Only-mode: --ux, --monitoring [DATASOURCE], --rule-engine; disable in default: --no-monitoring, --no-rule-engine.
--port, --db-instance; --help lists valid monitoring datasources.

3.2.1 (2025-10-13) — Monitoring UX + Offset & SSL Stabilization

AVEVA client 401 refresh + diagnostics; monitoring scan_error enrichment.
Restart endpoints respect offset_seconds; monitoring UI spacing improvements.

2025-10-17

Issue #50 — follow-up: Trial request no longer requires SSO to submit.
Anti-abuse added to Trial form: honeypot (hp_contact) and IP rate‑limiting (3 requests / 5 minutes).
Trial page copy updated to advise using Google/Microsoft email for later SSO.
Admin review remains read‑only at GET /admin/trials; one JSON per request saved under instance/public/trial_requests/.
See details: docs/notes/issue-50.md

RACEMES - Changelog

Version 3.2.3 (October 17, 2025) - Dashboard Hardening

ԣ� COMPLETED: Issue #56 �� Dashboard Hardening for Selective Runtime Modes

Hardened the main Dashboard (home) to render reliably under selective runtime modes (--ux, --saf-orchestrator) without 500s, adding safe defaults and targeted logging.

Changes

routes.py: Added logging on index route, verified registered blueprints, and ensured safe defaults to avoid template key errors. Graceful fallback rendering on exceptions.
features/dashboard/lib/dashboard_service.py: Completed fallback dict (added missing keys), added info/debug logs, returned consistent structure even on errors.
Lazy imports in Orchestrator routes to avoid circular imports/side effects during app startup.

Outcome

No 500 on / across modes; dashboard renders with meaningful zeros/defaults when data sources are unavailable.
Clear logs for diagnostics in selective runtime scenarios.

Version 3.2.2 (October 17, 2025) - CLI Runtime Modes (Phase 1)

ԣ� COMPLETED: Issue #47 �� CLI runtime modes for selective component startup

Introduce runtime modes via single entrypoint (main.py) to start selected components and enable workload partitioning.

Features

Single entrypoint retained (main.py), backwards-compatible: no flags �� Web + Monitoring + Rule Engine.
Only-mode (union semantics): --ux, --monitoring [DATASOURCE], --rule-engine.
Disable flags (default mode only): --no-monitoring, --no-rule-engine.
Server option: --port <int> (default 5000).
DB override: --db-instance <name|URI> (alias: --db-istance).
Help enhanced: --help lists allowed monitoring datasources.
Logging: resolved run-set, datasource selection, and Phase 1 warnings.

Monitoring Datasources (allowed values)

connect-data-source, azure-iot-hub, opc-ua-server, mqtt-broker, modbus-tcp, rest-api

Phase 1 Constraints

Datasource is validated against a fixed allowlist; stream-level sharding not applied yet.
Requires exactly one active APIConfiguration when a DATASOURCE is provided.

Validation (smoke tests)

Help output includes allowed datasources: ԣ�
Parser only-mode union logic: ԣ� (--ux --monitoring --rule-engine �� union)
Misuse detection: ԣ� (--ux --no-monitoring fails fast with clear error)
Monitoring-only manual run observed to start APScheduler and remain active (user log): ԣ�

Documentation

Added docs/CLI_RUNTIME_MODES.md with flags, precedence, examples, and notes.

Version 3.2.1 (October 13, 2025) - Monitoring UX + Offset & SSL Stabilization

ԣ� COMPLETED: Review passed for Issue #45 (Offset + SSL) and Monitoring UX

Fixes & Improvements

AVEVA Client: 401 token refresh + single retry; request diagnostics (status/url/error)
Monitoring Engine: scan_error events enriched with HTTP diagnostics
Restart endpoints: rispettano offset_seconds salvato (prima fase �ǣburst�� eliminata)
Monitoring UI: griglia pi+� compatta; colonne ravvicinate senza ridurre il font; Actions visibile con �ǣShow Disabled�� senza sticky

Commits

982c1df Fix: apply offset on restart endpoints and enrich diagnostics
a1d13ec UI: tighten Monitoring grid spacing, keep Actions visible (no sticky)

Validation

ԣ� Offset distribution stabile su restart singolo e bulk ԣ� Nessuna saturazione pool/SSL nei test locali ԣ� Migliore usabilit+� griglia Monitoring con Show Disabled

Version 3.2 (October 3, 2025) - Virtual Streams Phase 2

ԣ� COMPLETED: Virtual Streams Rule Engine Integration

Major Achievement: Virtual Streams fully integrated as first-class data sources for Rule Engine with simplified cross-rule reusability.

Key Features Delivered

Simplified Naming Convention: {variable_name} only (enables cross-rule reusability)
Rule Engine Integration: Full support for Virtual Streams as data sources
UI Integration: Virtual Streams visible in Instance Mapping with [VS] marker
Cross-Rule Reusability: Same variable name = same Virtual Stream across different rules
Logging Component: Dedicated "Virtual Streams" component in System Console Log
Bug Fix: Monitoring service errors resolved for non-numeric streams

Technical Implementation

VirtualStreamsService: Simplified naming convention with automatic create/update
RuleEngine: Helper method _get_stream_by_name() with VirtualStreamProxy duck-typing
PlaceholderResolver: Virtual Streams fallback in placeholder resolution
AssetsService: Extended get_active_streams() to include Virtual Streams
routes.py: Legacy endpoint compatibility maintained

Validation Results

ԣ� Virtual Stream Creation ԣ� Instance Mapping UI ԣ� Rule Evaluation ԣ� Event Generation ԣ� Cross-Rule Reusability ԣ� Monitoring Service (no errors for non-numeric streams) ԣ� Logging Component

Version 3.1 (October 1, 2025) - Templates Feature-First Architecture

ԣ� COMPLETED: Templates 100% Migrated to Feature-First Structure

Major Achievement: Complete template reorganization from monolithic to feature-first architecture.

Migration Summary

Phase 1: 15 templates (base, errors, cognition, documentation) ԣ�
Phase 2: 8 templates (6 configuration + 2 admin) ԣ�
Phase 3: 10 templates (3 assets + 5 monitoring + 2 rules) ԣ�
Phase 4: 5 templates (3 dashboard + 2 actions) ԣ�

Results

Templates Migrated: 38/38 (100%)
Templates Remaining in Root: 0
Routes Updated: 40+ route references
Template Inheritance: 38 references updated to shared/base.html
Zero Regressions: All pages functional
Git History: Preserved via git mv

Final Structure

templates/
��������� shared/               # Base template + components + errors
��������� features/            # Feature-organized templates
���   ��������� configuration/
���   ��������� admin/roles/
���   ��������� assets/
���   ��������� monitoring/
���   ��������� rules/
���   ��������� dashboard/
���   ��������� actions/
���   ��������� cognition/
���   ��������� documentation/
��������� public/
��������� auth/
��������� form_builder/

Version 3.0 (September 30, 2025) - Full-Stack Architecture Modernization

ԣ� COMPLETED: Backend Feature-First + Frontend Modular Architecture

Major Achievement: Complete architectural transformation from monolithic to enterprise-grade modular architecture with ZERO REGRESSIONS.

Backend Feature-First Architecture ԣ�

Routes Status: 10/10 critical routes fully functional (100% success rate)

Key Achievements: - Blueprint System: 14 registered blueprints with 310+ active routes - Service Layer: Complete business logic separation for all features - Template Updates: All 50+ template references updated to blueprint endpoints - Route Organization: Clean separation with proper URL prefixes - Features Extracted: 7/7 features operational (Dashboard, Configuration, Assets, Monitoring, Events, Rules, Actions, Admin)

Validation Results: ԣ� Homepage (302) ԣ� Configuration (302) ԣ� Assets (302) ԣ� Monitoring (302) ԣ� Events (302) ԣ� Rules (302) ԣ� Actions Builder (302) ԣ� Actions Executions (302) ԣ� Admin Users (302) ԣ� Admin Profile (302)

Frontend Modular Architecture ԣ�

Performance Improvements: - Template Size: 433KB �� 40KB (-91% reduction) - CSS Extraction: 1,267 lines �� external 32KB stylesheet (form-builder.css) - JavaScript Modularization: 9,275 lines �� external 348KB script (form-builder.js)

Technical Optimizations: - JSON memoization for performance - DOM batching for efficient updates - Centralized store pattern - Zero regressions with surgical refactoring approach

Architecture Evolution Summary

From Monolithic to Feature-First (2025)

September-October 2025: Complete transformation to enterprise-grade modular architecture

Before: - Monolithic routes.py with 300+ routes - Mixed business logic and presentation - Template references scattered across codebase - 433KB single-file form builder template

After: - 14 blueprints with clean separation - Service layer pattern throughout - Feature-organized template hierarchy - Modular CSS/JS architecture - Virtual Streams integration

Results: - ԣ� Zero regressions - ԣ� 100% functionality preserved - ԣ� Enterprise-grade maintainability - ԣ� Production ready

Last Updated: October 13, 2025

RACEMES - Changelog

Version 3.2.3 (October 17, 2025) - Dashboard Hardening

ԣ� COMPLETED: Issue #56 �� Dashboard Hardening for Selective Runtime Modes

Hardened the main Dashboard (home) to render reliably under selective runtime modes (--ux, --saf-orchestrator) without 500s, adding safe defaults and targeted logging.

Changes

routes.py: Added logging on index route, verified registered blueprints, and ensured safe defaults to avoid template key errors. Graceful fallback rendering on exceptions.
features/dashboard/lib/dashboard_service.py: Completed fallback dict (added missing keys), added info/debug logs, returned consistent structure even on errors.
Lazy imports in Orchestrator routes to avoid circular imports/side effects during app startup.

Outcome

No 500 on / across modes; dashboard renders with meaningful zeros/defaults when data sources are unavailable.
Clear logs for diagnostics in selective runtime scenarios.

Version 3.2.2 (October 17, 2025) - CLI Runtime Modes (Phase 1)

ԣ� COMPLETED: Issue #47 �� CLI runtime modes for selective component startup

Introduce runtime modes via single entrypoint (main.py) to start selected components and enable workload partitioning.

Features

Single entrypoint retained (main.py), backwards-compatible: no flags �� Web + Monitoring + Rule Engine.
Only-mode (union semantics): --ux, --monitoring [DATASOURCE], --rule-engine.
Disable flags (default mode only): --no-monitoring, --no-rule-engine.
Server option: --port <int> (default 5000).
DB override: --db-instance <name|URI> (alias: --db-istance).
Help enhanced: --help lists allowed monitoring datasources.
Logging: resolved run-set, datasource selection, and Phase 1 warnings.

Monitoring Datasources (allowed values)

connect-data-source, azure-iot-hub, opc-ua-server, mqtt-broker, modbus-tcp, rest-api

Phase 1 Constraints

Datasource is validated against a fixed allowlist; stream-level sharding not applied yet.
Requires exactly one active APIConfiguration when a DATASOURCE is provided.

Validation (smoke tests)

Help output includes allowed datasources: ԣ�
Parser only-mode union logic: ԣ� (--ux --monitoring --rule-engine �� union)
Misuse detection: ԣ� (--ux --no-monitoring fails fast with clear error)
Monitoring-only manual run observed to start APScheduler and remain active (user log): ԣ�

Documentation

Added docs/CLI_RUNTIME_MODES.md with flags, precedence, examples, and notes.

Version 3.2.1 (October 13, 2025) - Monitoring UX + Offset & SSL Stabilization

ԣ� COMPLETED: Review passed for Issue #45 (Offset + SSL) and Monitoring UX

Fixes & Improvements

AVEVA Client: 401 token refresh + single retry; request diagnostics (status/url/error)
Monitoring Engine: scan_error events enriched with HTTP diagnostics
Restart endpoints: rispettano offset_seconds salvato (prima fase �ǣburst�� eliminata)
Monitoring UI: griglia pi+� compatta; colonne ravvicinate senza ridurre il font; Actions visibile con �ǣShow Disabled�� senza sticky

Commits

982c1df Fix: apply offset on restart endpoints and enrich diagnostics
a1d13ec UI: tighten Monitoring grid spacing, keep Actions visible (no sticky)

Validation

ԣ� Offset distribution stabile su restart singolo e bulk ԣ� Nessuna saturazione pool/SSL nei test locali ԣ� Migliore usabilit+� griglia Monitoring con Show Disabled

Version 3.2 (October 3, 2025) - Virtual Streams Phase 2

ԣ� COMPLETED: Virtual Streams Rule Engine Integration

Major Achievement: Virtual Streams fully integrated as first-class data sources for Rule Engine with simplified cross-rule reusability.

Key Features Delivered

Simplified Naming Convention: {variable_name} only (enables cross-rule reusability)
Rule Engine Integration: Full support for Virtual Streams as data sources
UI Integration: Virtual Streams visible in Instance Mapping with [VS] marker
Cross-Rule Reusability: Same variable name = same Virtual Stream across different rules
Logging Component: Dedicated "Virtual Streams" component in System Console Log
Bug Fix: Monitoring service errors resolved for non-numeric streams

Technical Implementation

VirtualStreamsService: Simplified naming convention with automatic create/update
RuleEngine: Helper method _get_stream_by_name() with VirtualStreamProxy duck-typing
PlaceholderResolver: Virtual Streams fallback in placeholder resolution
AssetsService: Extended get_active_streams() to include Virtual Streams
routes.py: Legacy endpoint compatibility maintained

Validation Results

Version 3.1 (October 1, 2025) - Templates Feature-First Architecture

ԣ� COMPLETED: Templates 100% Migrated to Feature-First Structure

Major Achievement: Complete template reorganization from monolithic to feature-first architecture.

Migration Summary

Phase 1: 15 templates (base, errors, cognition, documentation) ԣ�
Phase 2: 8 templates (6 configuration + 2 admin) ԣ�
Phase 3: 10 templates (3 assets + 5 monitoring + 2 rules) ԣ�
Phase 4: 5 templates (3 dashboard + 2 actions) ԣ�

Results

Templates Migrated: 38/38 (100%)
Templates Remaining in Root: 0
Routes Updated: 40+ route references
Template Inheritance: 38 references updated to shared/base.html
Zero Regressions: All pages functional
Git History: Preserved via git mv

Final Structure

templates/
��������� shared/               # Base template + components + errors
��������� features/            # Feature-organized templates
���   ��������� configuration/
���   ��������� admin/roles/
���   ��������� assets/
���   ��������� monitoring/
���   ��������� rules/
���   ��������� dashboard/
���   ��������� actions/
���   ��������� cognition/
���   ��������� documentation/
��������� public/
��������� auth/
��������� form_builder/

Version 3.0 (September 30, 2025) - Full-Stack Architecture Modernization

ԣ� COMPLETED: Backend Feature-First + Frontend Modular Architecture

Major Achievement: Complete architectural transformation from monolithic to enterprise-grade modular architecture with ZERO REGRESSIONS.

Backend Feature-First Architecture ԣ�

Routes Status: 10/10 critical routes fully functional (100% success rate)

Frontend Modular Architecture ԣ�

Technical Optimizations: - JSON memoization for performance - DOM batching for efficient updates - Centralized store pattern - Zero regressions with surgical refactoring approach

Architecture Evolution Summary

From Monolithic to Feature-First (2025)

September-October 2025: Complete transformation to enterprise-grade modular architecture

Before: - Monolithic routes.py with 300+ routes - Mixed business logic and presentation - Template references scattered across codebase - 433KB single-file form builder template

After: - 14 blueprints with clean separation - Service layer pattern throughout - Feature-organized template hierarchy - Modular CSS/JS architecture - Virtual Streams integration

Results: - ԣ� Zero regressions - ԣ� 100% functionality preserved - ԣ� Enterprise-grade maintainability - ԣ� Production ready

Last Updated: October 13, 2025

RACEMES - Changelog

Version 3.2.3 (October 17, 2025) - Dashboard Hardening

Ô£à COMPLETED: Issue #56 ÔÇö Dashboard Hardening for Selective Runtime Modes

Hardened the main Dashboard (home) to render reliably under selective runtime modes (--ux, --saf-orchestrator) without 500s, adding safe defaults and targeted logging.

Changes

routes.py: Added logging on index route, verified registered blueprints, and ensured safe defaults to avoid template key errors. Graceful fallback rendering on exceptions.
features/dashboard/lib/dashboard_service.py: Completed fallback dict (added missing keys), added info/debug logs, returned consistent structure even on errors.
Lazy imports in Orchestrator routes to avoid circular imports/side effects during app startup.

Outcome

No 500 on / across modes; dashboard renders with meaningful zeros/defaults when data sources are unavailable.
Clear logs for diagnostics in selective runtime scenarios.

Version 3.2.2 (October 17, 2025) - CLI Runtime Modes (Phase 1)

Ô£à COMPLETED: Issue #47 ÔÇö CLI runtime modes for selective component startup

Introduce runtime modes via single entrypoint (main.py) to start selected components and enable workload partitioning.

Features

Single entrypoint retained (main.py), backwards-compatible: no flags ÔåÆ Web + Monitoring + Rule Engine.
Only-mode (union semantics): --ux, --monitoring [DATASOURCE], --rule-engine.
Disable flags (default mode only): --no-monitoring, --no-rule-engine.
Server option: --port <int> (default 5000).
DB override: --db-instance <name|URI> (alias: --db-istance).
Help enhanced: --help lists allowed monitoring datasources.
Logging: resolved run-set, datasource selection, and Phase 1 warnings.

Monitoring Datasources (allowed values)

connect-data-source, azure-iot-hub, opc-ua-server, mqtt-broker, modbus-tcp, rest-api

Phase 1 Constraints

Datasource is validated against a fixed allowlist; stream-level sharding not applied yet.
Requires exactly one active APIConfiguration when a DATASOURCE is provided.

Validation (smoke tests)

Help output includes allowed datasources: Ô£à
Parser only-mode union logic: Ô£à (--ux --monitoring --rule-engine ÔåÆ union)
Misuse detection: Ô£à (--ux --no-monitoring fails fast with clear error)
Monitoring-only manual run observed to start APScheduler and remain active (user log): Ô£à

Documentation

Added docs/CLI_RUNTIME_MODES.md with flags, precedence, examples, and notes.

Version 3.2.1 (October 13, 2025) - Monitoring UX + Offset & SSL Stabilization

Ô£à COMPLETED: Review passed for Issue #45 (Offset + SSL) and Monitoring UX

Fixes & Improvements

AVEVA Client: 401 token refresh + single retry; request diagnostics (status/url/error)
Monitoring Engine: scan_error events enriched with HTTP diagnostics
Restart endpoints: rispettano offset_seconds salvato (prima fase ÔÇ£burstÔÇØ eliminata)
Monitoring UI: griglia pi├╣ compatta; colonne ravvicinate senza ridurre il font; Actions visibile con ÔÇ£Show DisabledÔÇØ senza sticky

Commits

982c1df Fix: apply offset on restart endpoints and enrich diagnostics
a1d13ec UI: tighten Monitoring grid spacing, keep Actions visible (no sticky)

Validation

Ô£à Offset distribution stabile su restart singolo e bulk Ô£à Nessuna saturazione pool/SSL nei test locali Ô£à Migliore usabilit├á griglia Monitoring con Show Disabled

Version 3.2 (October 3, 2025) - Virtual Streams Phase 2

Ô£à COMPLETED: Virtual Streams Rule Engine Integration

Major Achievement: Virtual Streams fully integrated as first-class data sources for Rule Engine with simplified cross-rule reusability.

Key Features Delivered

Simplified Naming Convention: {variable_name} only (enables cross-rule reusability)
Rule Engine Integration: Full support for Virtual Streams as data sources
UI Integration: Virtual Streams visible in Instance Mapping with [VS] marker
Cross-Rule Reusability: Same variable name = same Virtual Stream across different rules
Logging Component: Dedicated "Virtual Streams" component in System Console Log
Bug Fix: Monitoring service errors resolved for non-numeric streams

Technical Implementation

VirtualStreamsService: Simplified naming convention with automatic create/update
RuleEngine: Helper method _get_stream_by_name() with VirtualStreamProxy duck-typing
PlaceholderResolver: Virtual Streams fallback in placeholder resolution
AssetsService: Extended get_active_streams() to include Virtual Streams
routes.py: Legacy endpoint compatibility maintained

Validation Results

Ô£à Virtual Stream Creation Ô£à Instance Mapping UI Ô£à Rule Evaluation Ô£à Event Generation Ô£à Cross-Rule Reusability Ô£à Monitoring Service (no errors for non-numeric streams) Ô£à Logging Component

Version 3.1 (October 1, 2025) - Templates Feature-First Architecture

Ô£à COMPLETED: Templates 100% Migrated to Feature-First Structure

Major Achievement: Complete template reorganization from monolithic to feature-first architecture.

Migration Summary

Phase 1: 15 templates (base, errors, cognition, documentation) Ô£à
Phase 2: 8 templates (6 configuration + 2 admin) Ô£à
Phase 3: 10 templates (3 assets + 5 monitoring + 2 rules) Ô£à
Phase 4: 5 templates (3 dashboard + 2 actions) Ô£à

Results

Templates Migrated: 38/38 (100%)
Templates Remaining in Root: 0
Routes Updated: 40+ route references
Template Inheritance: 38 references updated to shared/base.html
Zero Regressions: All pages functional
Git History: Preserved via git mv

Final Structure

templates/
Ôö£ÔöÇÔöÇ shared/               # Base template + components + errors
Ôö£ÔöÇÔöÇ features/            # Feature-organized templates
Ôöé   Ôö£ÔöÇÔöÇ configuration/
Ôöé   Ôö£ÔöÇÔöÇ admin/roles/
Ôöé   Ôö£ÔöÇÔöÇ assets/
Ôöé   Ôö£ÔöÇÔöÇ monitoring/
Ôöé   Ôö£ÔöÇÔöÇ rules/
Ôöé   Ôö£ÔöÇÔöÇ dashboard/
Ôöé   Ôö£ÔöÇÔöÇ actions/
Ôöé   Ôö£ÔöÇÔöÇ cognition/
Ôöé   ÔööÔöÇÔöÇ documentation/
Ôö£ÔöÇÔöÇ public/
Ôö£ÔöÇÔöÇ auth/
ÔööÔöÇÔöÇ form_builder/

Version 3.0 (September 30, 2025) - Full-Stack Architecture Modernization

Ô£à COMPLETED: Backend Feature-First + Frontend Modular Architecture

Major Achievement: Complete architectural transformation from monolithic to enterprise-grade modular architecture with ZERO REGRESSIONS.

Backend Feature-First Architecture Ô£à

Routes Status: 10/10 critical routes fully functional (100% success rate)

Validation Results: Ô£à Homepage (302) Ô£à Configuration (302) Ô£à Assets (302) Ô£à Monitoring (302) Ô£à Events (302) Ô£à Rules (302) Ô£à Actions Builder (302) Ô£à Actions Executions (302) Ô£à Admin Users (302) Ô£à Admin Profile (302)

Frontend Modular Architecture Ô£à

Performance Improvements: - Template Size: 433KB ÔåÆ 40KB (-91% reduction) - CSS Extraction: 1,267 lines ÔåÆ external 32KB stylesheet (form-builder.css) - JavaScript Modularization: 9,275 lines ÔåÆ external 348KB script (form-builder.js)

Technical Optimizations: - JSON memoization for performance - DOM batching for efficient updates - Centralized store pattern - Zero regressions with surgical refactoring approach

Architecture Evolution Summary

From Monolithic to Feature-First (2025)

September-October 2025: Complete transformation to enterprise-grade modular architecture

Before: - Monolithic routes.py with 300+ routes - Mixed business logic and presentation - Template references scattered across codebase - 433KB single-file form builder template

After: - 14 blueprints with clean separation - Service layer pattern throughout - Feature-organized template hierarchy - Modular CSS/JS architecture - Virtual Streams integration

Results: - Ô£à Zero regressions - Ô£à 100% functionality preserved - Ô£à Enterprise-grade maintainability - Ô£à Production ready

Last Updated: October 13, 2025

Documents

Changelog

Application Releases

3.2.3 (2025-10-17) — Dashboard Hardening

3.2.2 (2025-10-17) — CLI Runtime Modes (Phase 1)

3.2.1 (2025-10-13) — Monitoring UX + Offset & SSL Stabilization

2025-10-17

RACEMES - Changelog

Version 3.2.3 (October 17, 2025) - Dashboard Hardening

ԣ� COMPLETED: Issue #56 ��� Dashboard Hardening for Selective Runtime Modes

Changes

Outcome

Version 3.2.2 (October 17, 2025) - CLI Runtime Modes (Phase 1)

ԣ� COMPLETED: Issue #47 ��� CLI runtime modes for selective component startup

Features

Monitoring Datasources (allowed values)

Phase 1 Constraints

Validation (smoke tests)

Documentation

Version 3.2.1 (October 13, 2025) - Monitoring UX + Offset & SSL Stabilization

ԣ� COMPLETED: Review passed for Issue #45 (Offset + SSL) and Monitoring UX

Fixes & Improvements

Commits

Validation

Version 3.2 (October 3, 2025) - Virtual Streams Phase 2

ԣ� COMPLETED: Virtual Streams Rule Engine Integration

Key Features Delivered

Technical Implementation

Validation Results

Version 3.1 (October 1, 2025) - Templates Feature-First Architecture

ԣ� COMPLETED: Templates 100% Migrated to Feature-First Structure

Migration Summary

Results

Final Structure

Version 3.0 (September 30, 2025) - Full-Stack Architecture Modernization

ԣ� COMPLETED: Backend Feature-First + Frontend Modular Architecture

Backend Feature-First Architecture ԣ�

Frontend Modular Architecture ԣ�

Architecture Evolution Summary

From Monolithic to Feature-First (2025)

RACEMES - Changelog

Version 3.2.3 (October 17, 2025) - Dashboard Hardening

ԣ� COMPLETED: Issue #56 ��� Dashboard Hardening for Selective Runtime Modes

Changes

Outcome

Version 3.2.2 (October 17, 2025) - CLI Runtime Modes (Phase 1)

ԣ� COMPLETED: Issue #47 ��� CLI runtime modes for selective component startup

Features

Monitoring Datasources (allowed values)

Phase 1 Constraints

Validation (smoke tests)

Documentation

Version 3.2.1 (October 13, 2025) - Monitoring UX + Offset & SSL Stabilization

ԣ� COMPLETED: Review passed for Issue #45 (Offset + SSL) and Monitoring UX

Fixes & Improvements

Commits

Validation

Version 3.2 (October 3, 2025) - Virtual Streams Phase 2

ԣ� COMPLETED: Virtual Streams Rule Engine Integration

Key Features Delivered

Technical Implementation

Validation Results

Version 3.1 (October 1, 2025) - Templates Feature-First Architecture

ԣ� COMPLETED: Templates 100% Migrated to Feature-First Structure

Migration Summary

Results

Final Structure

Version 3.0 (September 30, 2025) - Full-Stack Architecture Modernization

ԣ� COMPLETED: Backend Feature-First + Frontend Modular Architecture

Backend Feature-First Architecture ԣ�

Frontend Modular Architecture ԣ�

Architecture Evolution Summary

From Monolithic to Feature-First (2025)

RACEMES - Changelog

Version 3.2.3 (October 17, 2025) - Dashboard Hardening

Ô£à COMPLETED: Issue #56 ÔÇö Dashboard Hardening for Selective Runtime Modes

Changes

Outcome

Version 3.2.2 (October 17, 2025) - CLI Runtime Modes (Phase 1)

Ô£à COMPLETED: Issue #47 ÔÇö CLI runtime modes for selective component startup

ԣ� COMPLETED: Issue #56 �� Dashboard Hardening for Selective Runtime Modes

ԣ� COMPLETED: Issue #47 �� CLI runtime modes for selective component startup

ԣ� COMPLETED: Issue #56 �� Dashboard Hardening for Selective Runtime Modes

ԣ� COMPLETED: Issue #47 �� CLI runtime modes for selective component startup