|
| 1 | +# runtime Specification |
| 2 | + |
| 3 | +## Purpose |
| 4 | +TBD - created by archiving change database-driven-modules. Update Purpose after archive. |
| 5 | +## Requirements |
| 6 | +### Requirement: Hybrid Module/Component Runtime |
| 7 | +The runtime SHALL load modules (ModulusModule) as deployable units and resolve components (ModulusComponent) as code units with dependency ordering. |
| 8 | + |
| 9 | +#### Scenario: Module load succeeds |
| 10 | +- **WHEN** a module is enabled and its manifest exists |
| 11 | +- **THEN** the runtime loads its assemblies in an isolated ALC (by default) |
| 12 | +- **AND** discovers all `ModulusComponent` types |
| 13 | +- **AND** builds a dependency graph from `[DependsOn]` (including cross-module dependencies) |
| 14 | +- **AND** initializes components in topological order (`ConfigureServices` then `OnApplicationInitialization`). |
| 15 | + |
| 16 | +#### Scenario: Missing files are flagged |
| 17 | +- **WHEN** a module manifest file is missing at startup |
| 18 | +- **THEN** the module state is set to `MissingFiles` |
| 19 | +- **AND** the module is skipped from the load list. |
| 20 | + |
| 21 | +### Requirement: Menu Projection |
| 22 | +Menu entries SHALL be projected to the database at install/update time and read from the database at render time. |
| 23 | + |
| 24 | +#### Scenario: Install or update module |
| 25 | +- **WHEN** a module is installed or updated |
| 26 | +- **THEN** the installer scans components for `[Menu]` (host-aware) |
| 27 | +- **AND** writes menu rows with ids like `{ModuleId}.{MenuId}` into `Sys_Menus` |
| 28 | +- **AND** replaces any existing menus for that module (bulk upsert). |
| 29 | + |
| 30 | +#### Scenario: Render menus |
| 31 | +- **WHEN** the shell renders navigation |
| 32 | +- **THEN** it queries `Sys_Menus` joined with enabled modules |
| 33 | +- **AND** does not require reflection at render time. |
| 34 | + |
| 35 | +### Requirement: Detail Content Fallback |
| 36 | +Module detail pages SHALL prefer README content and fall back to manifest description. |
| 37 | + |
| 38 | +#### Scenario: README available |
| 39 | +- **WHEN** `README.md` exists in the module folder |
| 40 | +- **THEN** its Markdown content is used for the detail view. |
| 41 | + |
| 42 | +#### Scenario: README missing |
| 43 | +- **WHEN** no `README.md` exists |
| 44 | +- **AND** `manifest.description` is present |
| 45 | +- **THEN** the manifest description is shown. |
| 46 | + |
| 47 | +#### Scenario: No content available |
| 48 | +- **WHEN** neither README nor manifest description exists |
| 49 | +- **THEN** show "No description provided." |
| 50 | + |
| 51 | +### Requirement: Module State Management |
| 52 | +Module state SHALL be persisted and enforced at startup. |
| 53 | + |
| 54 | +#### Scenario: Startup integrity |
| 55 | +- **WHEN** the application starts |
| 56 | +- **THEN** the system migrates the DB |
| 57 | +- **AND** seeds system modules (install/upgrade if missing or outdated) |
| 58 | +- **AND** marks missing manifests as `MissingFiles` |
| 59 | +- **AND** only modules with `State=Ready` and `IsEnabled=true` are loaded. |
| 60 | + |
0 commit comments