# Architecture and project ownership DrakimaCore is a modular application with separate executable hosts and shared libraries. The retired root web executable must not be restored as a shortcut. Root folders such as `Services`, `Data`, `Models`, `Contracts` and `Composition` remain active source: Runtime compiles them through explicit links in its project file. ## Dependency direction ```text Domain <- Application <- Infrastructure ^ ^ +-- composition in executable hosts | Public / Studio / feature Web libraries ``` Domain owns framework-independent rules and vocabulary. Application owns use cases, ports and neutral contracts. Infrastructure implements persistence, files and provider protocols. Web libraries own HTTP, Razor and browser behavior. Hosts assemble their permitted capabilities. Runtime is a compatibility library (`DrakimaCore.dll`), not an executable and not permission to reverse these boundaries. ## Executable hosts | Host | Responsibility | Lifecycle | | --- | --- | --- | | PublicWeb | Public/member routes, room entry, shared core initialization command | Main local startup target | | StudioWeb | Staff CMS, authoring, review and operations | On demand in managed development; independent in deployment | | Workers | Projection, retention, recovery and configured job processing | Separate process; no public MVC surface | | NodeGuardian | Configured node readiness and lifecycle coordination | Supporting process, not an LLM server | `DrakimaCore.slnx` contains the ordinary application/test graph. `DrakimaCore.Full.slnx` additionally includes operator tools and the full executable set. The curated project inventory in Engineering Observatory must match the Full solution's explicit project entries; transitive projects and tool fixtures are distinct from deployable website hosts. ## Physical modules and remaining seams [Legend Maker publication](legend-publication.md) uses focused Application/Legend and Infrastructure/Legend owners, Studio author controls and Public member launchers. Executable archives live in private storage and run on a separate cookie domain through early PublicWeb middleware. This is distinct from the VN Maker's active-time battle authoring/runtime. The [Drakima Arcade](arcade.md) implementation has focused Application/Arcade and Infrastructure/Arcade owners for run admission and verified-input checkpoint acceptance. Core owns campaign/run/progress, permanent ownership/reward records and the existing credit ledger; input acceptance has no debit dependency. Verification runs outside the transaction, then a serializable compare-and-swap rechecks the owned run, release, cursor and reward versions. Protected asset delivery resolves only exact inventory hashes and current-room pack membership for the owned pinned run, preflight-verifies the original private file handle and rechecks accepted state before transfer. PublicWeb composes the actual bootstrap, shared verifier, reward writer and room projector only after explicitly configured cold release admission. Member entry and isolated HTTP then use the same Core-backed run owners. See [member activation](arcade-member-activation.md) for the current rollout record. `Tools/DrakimaCore.ArcadeTool` is the retained cold operator executable. It plans or installs the canonical three-campaign server catalog into one private deduplicated hash store, then loads the complete real project and runs bounded headless entry and checkpoint-recovery checks for all five Maidens. Ordinary install/inspect composes no website host or database. Explicit `member-plan` and `member-activate` cold-admit an exact configuration and inspect/publish the three campaign/release records in existing Core through a restricted connection. Activation is atomic and idempotent; it refuses conflicting policies/publications and foreign active-run pins without changing members, wallets, progress or schema. Installed server objects are distribution assets, with no archive, logical media tree or recovery copy. Server-catalog installation alone does not admit a JS/WASM player or enable member purchases. The current-runtime integration and `Tools/DrakimaCore.ArcadeCurrentTool` support the later quartet and compatible retained generations through explicit trusted receipts. Current local activation supersedes the historical three-campaign rollout: Campaign 1 is visible to signed-in members; Campaigns 2–4 remain Admin-only. Campaigns 1–2 are free, 3–4 use permanent ownership, and predecessor completion is independent. The current module is deliberately outside the ordinary host solution; building the website must not overwrite retained game binaries or relax their hash checks. Gynoid Creation Core is an independent local executable under `Tools/Drakima.GynoidCreationCore`, with dedicated Application/Infrastructure libraries. It runs on the creator's PC, not as a website host or home-lab worker. Only the portable media libraries are shared; no Runtime/database dependency is allowed. See [local creation](creation-core.md) for storage, provider and export boundaries. Gynoid Conversations has Application, Infrastructure and Web projects. Interview Studio has a Web project and focused application/infrastructure code. Credits has a dedicated project. Public, Studio and shared Web libraries hold their route and presentation surfaces. Media-processing libraries separate portable processing, Skia and Windows/WPF tooling. Other mature workflows still live behind Runtime-linked services. New work should strengthen a bounded owner rather than create another generic service over the same database. Move one coherent workflow with its contracts, registrations and tests. Do not change schema, routes, namespaces or serialized formats merely to make a directory tree look uniform. `SystemCatalog/manifest-index.json` selects the deployed architecture manifests. `SystemCatalog/compatibility-seams.json` records reviewed exceptions. Architecture tests and the debt ratchet reject dependency reversals and new unreviewed coupling. The catalog is a curated read model; it does not give an AI agent arbitrary repository or database access. See [feature ownership](feature-map.md) and [documentation](documentation.md). Implementation evidence: `src/DrakimaCore.Runtime/DrakimaCore.Runtime.csproj`, `hosts/`, `SystemCatalog/`, `Tests/DrakimaCore.Tests/ArchitectureBoundaryTests.cs`, `Services/Engineering/EngineeringSolutionManifest.cs`.