Architecture
Use products independently. Connect them deliberately.
Each Runic tool works on its own. Integrations connect products, external frameworks, or tooling without making a core depend back on them. Those integrations stay in separate packages. The SDK package set releases together; independently owned products release on their own schedules.
Why this matters
Add an integration without adopting a stack
Choose one product first. When two products need to meet, add the integration that owns that behavior; neither core changes direction.
A concrete example
Windows and Views keep rendering in the frontend
Runic Application defines explicit .NET Window and View contracts and generates ordinary TypeScript clients. Svelte, React, Vue and Angular render those contracts with their own components; the application model does not own a framework's visual tree.
Portable cores
Cores stay portable
Runic Assets owns no host. Runic Translations begins with .NET but defines language-neutral contracts.
SDK release boundary
One coordinated SDK package set
The runic-sdk repository supplies SDK libraries, tools and templates through NuGet and npm. Command Line and Translations, including Translations Editor, have their own repositories and release lifecycles. CS-WebUI remains an independent upstream compatibility product; the SDK includes the Runic.Application integrations.
Integration ownership
Behavior stays with the product that defines it
Runic.Assets owns asset behavior within the SDK monorepo. Package
boundaries preserve that ownership when a product connects to an external
framework or development tool.
Application boundary
The editor uses the translation system
Runic Translations owns schemas, compiler behavior, runtime contracts, generators, and authoring APIs. Runic Translations Editor uses its packages and APIs as a downstream desktop application and owns translator UX. It is released with the Translations project, outside the SDK package catalog.
Preview compatibility
Pin the exact versions
Pin exact preview versions within each product family. Rebuild generated Window and View clients and retest after SDK upgrades. Compatibility is verified in consuming applications, frontend builds, and, where applicable, NativeAOT runs.
UI-independent contracts
Define the schema before choosing the renderer
Explicit partial Window and View types are the contract authority. The build inspects the compiled application after MVVM generators run and emits C# attachments and ordinary TypeScript modules. UI frameworks own rendering while .NET scopes ViewModels, logical Views, commands, and operations.