Перенес workflow

requirements/Architectural constraints.md

@@ -1,111 +1,50 @@
+# Architectural Constraints
 
-**`docs/adr/0001-new-runtime.md`**
-```md
-# ADR 0001: Create a new runtime project instead of evolving the legacy ConfigManager model
+## Main constraints
 
-## Status
+1. `Worker` is the primary runtime abstraction.
+2. `ApplicationModule` assembles the application and registers workers.
+3. Business behavior should live outside worker lifecycle code.
+4. The platform should avoid queue-centric abstractions as first-class architecture.
+5. Utility components are allowed only when they remain optional and transparent.
 
-Accepted
+## Worker constraints
 
-## Context
+Worker should own:
+- thread/process lifecycle
+- execution strategy
+- graceful stop
+- runtime state
+- health state
 
-The previous generation of the application runtime was centered around a timer-driven execution model:
-- a manager loaded configuration
-- a worker loop periodically called `execute()`
-- applications placed most operational logic behind that entry point
+Worker should not own:
+- large business workflows
+- domain rules
+- parsing plus persistence plus integration logic in one class
 
-That model is adequate for simple periodic jobs, but it does not match the direction of the new platform.
+## Business-code constraints
 
-The new platform must support:
-- task sources
-- queue-driven processing
-- multiple parallel workers
-- trace propagation across producer/consumer boundaries
-- richer lifecycle and status management
-- health aggregation
-- future admin web interface
-- future authentication and user management
+Business routines and services should own:
+- business decisions
+- external integration calls
+- persistence
+- domain validation
 
-These are platform concerns, not business concerns.
+They should not own:
+- platform lifecycle
+- worker supervision
+- runtime status management
 
-We also want business applications to describe only business functionality and rely on the runtime for infrastructure behavior.
+## API constraints
 
-## Decision
+Public API should stay small and clear.
 
-We will create a new runtime project instead of implementing a `V3` directly inside the current legacy ConfigManager codebase.
-
-The new runtime will be built around a platform-oriented model with explicit concepts such as:
-- `RuntimeManager`
+Prefer:
 - `ApplicationModule`
-- `TaskSource`
-- `TaskQueue`
-- `WorkerSupervisor`
-- `TaskHandler`
-- `TraceService`
-- `HealthRegistry`
+- `Worker`
+- runtime services
+- utility queue
 
-The old execute-centered model is treated as a previous-generation design and is not the architectural basis of the new runtime.
-
-## Rationale
-
-Creating a new runtime project gives us:
-- freedom to design the correct abstractions from the start
-- no pressure to preserve legacy contracts
-- cleaner boundaries between platform and business logic
-- simpler documentation and tests
-- lower long-term complexity than mixing old and new models in one codebase
-
-If we built this as `V3` inside the old project, we would likely inherit:
-- compatibility constraints
-- mixed abstractions
-- transitional adapters
-- conceptual confusion between periodic execution and event/queue processing
-
-The expected long-term cost of such coupling is higher than creating a clean new runtime.
-
-## Consequences
-
-### Positive
-
-- the platform can be modeled cleanly
-- business applications can integrate through explicit contracts
-- new runtime capabilities can be added without legacy pressure
-- mail_order_bot can become the first pilot application on the new runtime
-
-### Negative
-
-- some existing capabilities will need to be reintroduced in the new project
-- there will be a temporary period with both legacy and new runtime lines
-- migration requires explicit planning
-
-## Initial migration target
-
-The first application on the new runtime will be `mail_order_bot`.
-
-Initial runtime design for that application:
-- IMAP polling source
-- in-memory queue
-- parallel workers
-- business handler for email processing
-- message marked as read only after successful processing
-
-Later:
-- swap IMAP polling source for IMAP IDLE source
-- keep the queue and worker model unchanged
-
-## What we intentionally do not carry over
-
-We do not keep the old architecture as the central organizing principle:
-- no `execute()`-centric application model
-- no timer-loop as the main abstraction
-- no implicit mixing of lifecycle and business processing
-
-## Follow-up
-
-Next design work should define:
-- core platform contracts
-- package structure
-- runtime lifecycle
-- queue and worker interfaces
-- config model split between platform and application
-- pilot integration for `mail_order_bot`
+Avoid:
+- legacy abstractions preserved only for compatibility
+- specialized platform roles without strong need