{"id":51145299,"url":"https://github.com/magnexis/the-unlocker","last_synced_at":"2026-06-26T02:03:56.797Z","repository":{"id":355655186,"uuid":"1229025844","full_name":"magnexis/the-unlocker","owner":"magnexis","description":"The Unlocker is a safe, local-first modding platform for desktop applications and game-adjacent tools.  It combines a WPF desktop manager, a Vite + React marketplace frontend, a Go API gateway, Ruby and .NET registry services, Rust and .NET background workers, a mod SDK, packaging tools, policy controls, sample mods, etc.","archived":false,"fork":false,"pushed_at":"2026-05-04T16:19:54.000Z","size":654,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-06-13T00:23:17.096Z","etag":null,"topics":["csharp","modding-tools","open-source","typescript"],"latest_commit_sha":null,"homepage":"","language":"C#","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/magnexis.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":"SUPPORT.md","governance":null,"roadmap":"ROADMAP.md","authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-05-04T16:13:06.000Z","updated_at":"2026-05-05T15:46:36.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/magnexis/the-unlocker","commit_stats":null,"previous_names":["theworker02/the-unlocker","magnexis/the-unlocker"],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/magnexis/the-unlocker","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/magnexis%2Fthe-unlocker","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/magnexis%2Fthe-unlocker/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/magnexis%2Fthe-unlocker/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/magnexis%2Fthe-unlocker/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/magnexis","download_url":"https://codeload.github.com/magnexis/the-unlocker/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/magnexis%2Fthe-unlocker/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34799572,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-26T02:00:06.560Z","response_time":106,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["csharp","modding-tools","open-source","typescript"],"created_at":"2026-06-26T02:03:51.153Z","updated_at":"2026-06-26T02:03:56.784Z","avatar_url":"https://github.com/magnexis.png","language":"C#","funding_links":[],"categories":[],"sub_categories":[],"readme":"# The Unlocker\n\n[![Version](https://img.shields.io/badge/Version-1.1.3-0F766E)](ROADMAP.md)\n[![License: Apache 2.0](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](LICENSE)\n[![.NET](https://img.shields.io/badge/.NET-8.0-512BD4?logo=dotnet\u0026logoColor=white)](https://dotnet.microsoft.com/)\n[![React](https://img.shields.io/badge/React-19-61DAFB?logo=react\u0026logoColor=0B1020)](frontend/marketplace)\n[![TypeScript](https://img.shields.io/badge/TypeScript-5-3178C6?logo=typescript\u0026logoColor=white)](frontend/marketplace)\n[![Go API](https://img.shields.io/badge/Go-API%20Gateway-00ADD8?logo=go\u0026logoColor=white)](backend/go-api)\n[![Ruby](https://img.shields.io/badge/Ruby-Registry-CC342D?logo=ruby\u0026logoColor=white)](backend/ruby-registry)\n[![Rust](https://img.shields.io/badge/Rust-Worker-000000?logo=rust\u0026logoColor=white)](backend/rust-worker)\n[![Docker](https://img.shields.io/badge/Docker-Compose-2496ED?logo=docker\u0026logoColor=white)](deploy/docker-compose.yml)\n[![OpenAPI](https://img.shields.io/badge/OpenAPI-Go%20Gateway-6BA539?logo=openapiinitiative\u0026logoColor=white)](backend/go-api)\n[![Platform](https://img.shields.io/badge/Platform-Modding%20SDK-1D4ED8)](TheUnlocker.Modding.Abstractions)\n[![Security](https://img.shields.io/badge/Safety-SDK%20Extension%20Points-success)](SECURITY.md)\n\nThe Unlocker is a safe, local-first modding platform for desktop applications and game-adjacent tools.\n\nIt combines a WPF desktop manager, a Vite + React marketplace frontend, a Go API gateway, Ruby and .NET registry services, Rust and .NET background workers, a mod SDK, packaging tools, policy controls, sample mods, and root-level GitHub documentation.\n\nThe goal is simple:\n\nGive players, mod authors, teams, and publishers a clean way to discover, validate, install, update, disable, inspect, and recover mods without turning the application into a risky pile of manual file copies.\n\nThe project is built around explicit extension points.\n\nMods declare what they are, what they depend on, what permissions they request, what app or game versions they support, and what safe services they want to use.\n\nThe platform then handles the hard parts:\n\n- Discovery\n- Validation\n- Dependency resolution\n- SAT-style version solving\n- Version checks\n- Package integrity\n- Signing\n- Trust policy\n- Policy-as-code\n- Multi-registry federation\n- Hosted build farm workflows\n- Cloud profile sync\n- Remote orchestration\n- Compatibility lab results\n- Runtime observability\n- Sandboxed service access\n- Profiles\n- Recovery\n- Marketplace browsing\n- Versioned API access\n- Registry workflows\n- Diagnostics\n- Developer tooling\n\nThe Unlocker does not provide tools for licensing bypasses, anti-cheat bypasses, ownership bypasses, authentication bypasses, integrity-check evasion, or arbitrary patching of protected third-party applications.\n\nIt is a modding platform, not a bypass toolkit.\n\n---\n\n## Project Snapshot\n\n| Symbol | Area | What It Means |\n| --- | --- | --- |\n| [D] | Desktop | WPF manager, local profiles, recovery, diagnostics, and safe mod controls. |\n| [M] | Marketplace | Vite + React interface for mods, modpacks, trust, policy, publishers, and docs. |\n| [A] | API | Go public gateway with OpenAPI, auth gates, security headers, and `/api/v1` routes. |\n| [R] | Registry | Ruby and .NET registry services for accounts, package metadata, moderation, and storage. |\n| [W] | Workers | Rust and .NET workers for scans, compatibility jobs, build farm tasks, and webhooks. |\n| [S] | Security | Signing, permissions, policy simulation, trust scoring, quarantine, and recovery. |\n| [K] | SDK | Stable abstractions, sample mods, templates, analyzers, and author tooling. |\n| [G] | GitHub | Root docs, CI, issue templates, PR template, screenshots, and contributor guidance. |\n\n| Preview | Surface |\n| --- | --- |\n| \u003cimg src=\"assets/screenshots/marketplace.png\" alt=\"Marketplace preview\" width=\"420\"\u003e | [M] Marketplace browsing with trusted mod cards and filters. |\n| \u003cimg src=\"assets/screenshots/mod-detail.png\" alt=\"Mod detail preview\" width=\"420\"\u003e | [M] Mod detail view with versions, trust state, permissions, and install links. |\n| \u003cimg src=\"assets/screenshots/onboarding.png\" alt=\"Onboarding preview\" width=\"420\"\u003e | [D] First-run onboarding for game, registry, role, and local defaults. |\n| \u003cimg src=\"assets/screenshots/platform.png\" alt=\"Platform preview\" width=\"420\"\u003e | [G] Platform capability dashboard for registry, workers, policy, and release systems. |\n\n---\n\n## Table Of Contents\n\n- [Project Snapshot](#project-snapshot)\n- [Visual Section Guide](#visual-section-guide)\n- [Purpose](#purpose)\n- [Why This Exists](#why-this-exists)\n- [What It Does](#what-it-does)\n- [Current Status](#current-status)\n- [Major Platform Upgrades](#major-platform-upgrades)\n- [UI Screenshot Previews](#ui-screenshot-previews)\n- [Architecture At A Glance](#architecture-at-a-glance)\n- [Repository Layout](#repository-layout)\n- [Technology Stack](#technology-stack)\n- [Quick Start](#quick-start)\n- [Run Everything With Docker Compose](#run-everything-with-docker-compose)\n- [Run The Containerized Release](#run-the-containerized-release)\n- [Run The Desktop App](#run-the-desktop-app)\n- [Run The Marketplace Frontend](#run-the-marketplace-frontend)\n- [Run The Ruby Registry Facade](#run-the-ruby-registry-facade)\n- [Run The Go API Gateway](#run-the-go-api-gateway)\n- [Run The Rust Worker](#run-the-rust-worker)\n- [Run The .NET Registry API](#run-the-net-registry-api)\n- [Run Tests](#run-tests)\n- [Create And Package A Sample Mod](#create-and-package-a-sample-mod)\n- [Mod Author Workflow](#mod-author-workflow)\n- [Registry And Marketplace Workflow](#registry-and-marketplace-workflow)\n- [Persistent Accounts And Onboarding](#persistent-accounts-and-onboarding)\n- [Mod Safety Model](#mod-safety-model)\n- [Security Boundary](#security-boundary)\n- [Configuration](#configuration)\n- [Documentation Index](#documentation-index)\n- [Feature Inventory](#feature-inventory)\n- [Roadmap Snapshot](#roadmap-snapshot)\n- [GitHub Readiness](#github-readiness)\n- [Contributing](#contributing)\n- [Support](#support)\n- [License](#license)\n\n---\n\n## Visual Section Guide\n\nThis README uses simple bracket symbols so the long project overview is easier to scan on GitHub.\n\n| Symbol | Sections |\n| --- | --- |\n| [0] | Purpose, why the project exists, current status, and platform goals. |\n| [1] | Screenshots, UI previews, architecture, repository layout, and stack overview. |\n| [2] | Quick start, Docker Compose, desktop app, marketplace frontend, backend services, and tests. |\n| [3] | Mod author workflow, registry workflow, accounts, onboarding, safety, and configuration. |\n| [4] | Documentation index, feature inventory, roadmap, GitHub readiness, contributing, and support. |\n| [S] | Security boundary, policy simulation, trust controls, signing, quarantine, and recovery. |\n\n---\n\n## Purpose\n\nThe Unlocker exists to make mod management feel like a real platform.\n\nMany modding setups start with a folder, a handful of DLLs, a README, and a lot of trust.\n\nThat works for tiny experiments.\n\nIt becomes painful when mods have dependencies.\n\nIt becomes risky when updates request new permissions.\n\nIt becomes confusing when two mods touch the same system.\n\nIt becomes fragile when a game or app update changes compatibility.\n\nIt becomes hard to support when a user says, \"It crashed,\" and nobody knows which package, version, profile, dependency, or setting caused it.\n\nThe Unlocker is meant to solve those problems with structure.\n\nIt is built as a platform layer between the application, the mod author, the user, and the registry.\n\nThe platform provides:\n\n- A desktop manager for installed mods and recovery tools.\n- A marketplace frontend for browsing registry content.\n- A Go API gateway for versioned client-facing routes.\n- Registry APIs for packages, versions, moderation, and metadata.\n- Worker services for package scanning, compatibility checks, webhooks, and diagnostics.\n- SDK abstractions for safe app extension points.\n- CLI tooling for validating, packaging, signing, and publishing mods.\n- Documentation that makes the repository understandable on GitHub.\n\nThe Unlocker is designed to be useful locally first.\n\nIt can run without a hosted marketplace.\n\nIt can read local folders.\n\nIt can load local manifests.\n\nIt can package and inspect local mods.\n\nIt can also grow into a hosted ecosystem with accounts, publishers, package storage, registry metadata, marketplace browsing, compatibility data, and team policies.\n\n---\n\n## Why This Exists\n\nThe original idea was a content manager.\n\nThe manager needed to scan a local directory, discover optional packages, and show whether they were available or active.\n\nThat quickly turned into a broader platform design.\n\nUseful modding requires more than \"DLL exists, load it.\"\n\nIt needs a stable contract between the host app and mods.\n\nIt needs a manifest format that can be validated.\n\nIt needs configuration so users can enable and disable code mods.\n\nIt needs dependency resolution so shared mods load first.\n\nIt needs compatibility checks so old packages do not silently break.\n\nIt needs isolation so dependencies collide less often.\n\nIt needs logs so failures can be understood.\n\nIt needs UI controls so users do not edit JSON by hand.\n\nIt needs a packaging workflow so authors can ship repeatable artifacts.\n\nIt needs a registry so users can find updates and known compatibility notes.\n\nIt needs recovery tools so one bad package does not ruin the whole app.\n\nThat is why The Unlocker now includes desktop, frontend, backend, runtime, SDK, CLI, templates, tests, examples, and deployment pieces.\n\nThe project is intentionally ambitious.\n\nIt is also intentionally bounded.\n\nThe Unlocker supports sanctioned SDK extension points.\n\nIt does not attempt to bypass protected logic in third-party software.\n\n---\n\n## What It Does\n\nAt a high level, The Unlocker lets users manage safe mods and packages.\n\nThe desktop app can:\n\n- Discover local modules.\n- Discover local mods.\n- Read `mod.json` manifests.\n- Show installed mods.\n- Enable mods.\n- Disable mods.\n- Apply profiles.\n- Validate dependency chains.\n- Show missing dependencies.\n- Show permission requests.\n- Show trust warnings.\n- Simulate what a mod can access.\n- Import packages.\n- Roll back package versions.\n- Enter recovery mode.\n- Export diagnostics bundles.\n- Show major platform services in the `Major Platform` tab.\n- Summarize observability, federation, policy, build farm, sync, and self-update capabilities.\n\nThe marketplace frontend can:\n\n- Let users create an account.\n- Let users sign in.\n- Restore browser sessions.\n- Show first-run onboarding.\n- Browse registry mods.\n- Filter by game or adapter.\n- Filter by trust level.\n- Show health status.\n- Show the `/platform` capability page.\n- Link into desktop install flows.\n\nThe registry backend can:\n\n- Serve mod metadata.\n- Accept package records.\n- Track crash reports.\n- Create scan jobs.\n- Store accounts and sessions.\n- Store onboarding preferences.\n- Proxy data from the .NET registry API when configured.\n\nThe Go API gateway can:\n\n- Serve versioned `/api/v1` routes for clients.\n- Report API health.\n- Proxy mod list and detail requests.\n- Proxy job creation.\n- Proxy crash report submission.\n- Forward authorization and API key headers.\n- Return safe local fallback metadata when the registry facade is unavailable.\n- Expose `GET /api/v1/platform/major-upgrades` for shared platform capability metadata.\n\nThe workers can:\n\n- Consume queued jobs.\n- Run package scan steps.\n- Process compatibility checks.\n- Prepare hosted build farm and compatibility lab jobs.\n- Handle webhook delivery flows.\n- Support future reproducible build verification.\n\nThe SDK can:\n\n- Define stable mod contracts.\n- Expose safe services.\n- Limit access through permissions.\n- Provide event, command, menu, theme, settings, asset, and panel extension points.\n\nThe CLI can:\n\n- Validate manifests.\n- Package mods.\n- Sign packages.\n- Diagnose SDK and packaging issues.\n- Support future publish flows.\n\n---\n\n## Current Status\n\nThe repository is organized as a platform monorepo.\n\nIt has working project scaffolds across .NET, React, Ruby, Go, and Rust.\n\nThe current implementation focuses on safe extension workflows, mod package structure, registry metadata, local development, and platform documentation.\n\nSome pieces are production-shaped scaffolds.\n\nSome pieces are complete enough for local testing.\n\nSome pieces are intentionally marked as future platform work.\n\nThe root documentation is designed to make those boundaries clear.\n\nUse this README as the starting point.\n\nUse the linked documents for deeper implementation details.\n\n---\n\n## Major Platform Upgrades\n\nThe latest platform phase adds the domain services and UI/API surfaces for TheUnlocker to behave more like a complete modding ecosystem.\n\nThe major additions are documented in [MAJOR_PLATFORM_UPGRADES.md](MAJOR_PLATFORM_UPGRADES.md).\n\nThe short version:\n\n- Multi-registry federation can search official, private, local development, and game-specific community registries.\n- Hosted build farm models queue reproducible builds with signatures, SBOM generation, package scans, and provenance attestations.\n- Publisher economy models support verified publishers, donations, paid listings, licensing, teams, collaborators, and revenue reporting.\n- The SAT-style dependency solver handles candidate versions, version ranges, required dependencies, optional dependencies, peer dependencies, conflicts, game constraints, SDK constraints, and lockfile output.\n- Cloud profile sync can snapshot installed mods, profiles, favorites, ratings, load order, trust decisions, and account state across devices.\n- Remote desktop orchestration can create install commands for online desktop clients.\n- Compatibility lab jobs model adapter-based sandbox tests that collect logs and detect crash/freeze signals.\n- Workflow automation rules support event-driven actions such as disabling risky mods after a game update or exporting diagnostics after a crash.\n- Modpacks are now product-like artifacts with versions, maintainers, changelogs, screenshots, lockfiles, compatibility matrices, install links, and rollback points.\n- Runtime observability tracks load duration, memory deltas, event handlers, commands, exceptions, last successful load, and adapter-provided FPS impact.\n- Policy-as-code evaluates unsigned mod rules, allowed registries, blocked permissions, required trust levels, and blocked package IDs.\n- The extension marketplace model lets developers publish game adapters, UI themes, package format plugins, scanner plugins, marketplace panels, and workflow actions.\n- The AI compatibility assistant analyzes manifests, logs, crash stacks, dependency graphs, permissions, and targets to suggest fixes.\n- Desktop self-update models support stable, beta, and nightly release channels with signatures, changelogs, health checks, and rollback plans.\n\nThese are not invasive runtime patches or bypass tools. They are explicit platform services that keep mod loading, publishing, and recovery inspectable.\n\nVisible surfaces:\n\n- Go API: `GET /api/v1/platform/major-upgrades`\n- Go API: `GET /api/v1/platform/product-upgrades`\n- Go API: `GET /api/v1/install-pipeline`\n- Go API: `GET /api/v1/dependency-graph`\n- Go API: `GET /api/v1/modpacks/cloud`\n- Go API: `GET /api/v1/build-farm/jobs`\n- Go API: `GET /api/v1/docs-hub`\n- Go API: `GET /api/v1/account/security`\n- Go API: `GET /api/v1/marketplace/collections`\n- Go API: `GET /api/v1/compatibility/lab`\n- Go API: `GET /api/v1/compatibility/signals`\n- Go API: `GET /api/v1/ai/compatibility`\n- Go API: `GET /api/v1/packages/diff`\n- Go API: `GET /api/v1/install-queue`\n- Go API: `GET /api/v1/publishers/dashboard`\n- Go API: `GET /api/v1/publishers/analytics`\n- Go API: `GET /api/v1/recovery/plan`\n- Go API: `GET /api/v1/workflows/rules`\n- Go API: `GET /api/v1/admin/moderation`\n- Go API: `GET /api/v1/devices/fleet`\n- Go API: `GET /api/v1/notifications`\n- Go API: `GET /api/v1/policy/effective`\n- Go API: `GET /api/v1/registry/health`\n- Go API: `GET /api/v1/registries/federation`\n- Go API: `GET /api/v1/trust/reputation`\n- Go API: `GET /api/v1/releases/desktop`\n- React marketplace: `/platform`\n- React marketplace: `/operations`\n- React marketplace: `/publisher-analytics`\n- React marketplace: `/cloud-modpacks`\n- React marketplace: `/docs-hub`\n- React marketplace: `/collections`\n- React marketplace: `/compatibility`\n- React marketplace: `/assistant`\n- React marketplace: `/package-diff`\n- React marketplace: `/lab`\n- React marketplace: `/builds`\n- React marketplace: `/control-center`\n- React marketplace: `/devices`\n- React marketplace: `/federation`\n- React marketplace: `/trust`\n- React marketplace: `/releases`\n- React marketplace: `/governance`\n- WPF app: `Major Platform` tab\n\n### Product Upgrade Surfaces\n\nThe latest product phase adds concrete surfaces for the full set of requested upgrades.\n\nIdentity and sessions:\n\n- Production-style account auth is represented with bcrypt password hashing, refresh tokens, token revocation, login audit events, trusted-device lists, password reset hooks, and email-verification state.\n- Account settings expose display name, registry URL, primary game, password update, and trusted-device management.\n\nSync and installation:\n\n- Desktop-to-cloud sync snapshots installed mods, profiles, favorites, registry settings, trust decisions, and recovery history.\n- Device fleet orchestration tracks online desktop clients, trusted-device status, active profiles, pending commands, and push-install readiness.\n- The real install pipeline is modeled as eight gates: download, hash verification, signature verification, scanning, dependency resolution, permission approval, atomic install, and rollback record.\n\nPublishing and modpacks:\n\n- The publisher portal surface groups uploads, changelogs, screenshots, signing keys, analytics, crash reports, and moderation status.\n- Publisher Analytics Center reports install trends, conversion funnel, crash rate, ratings, version adoption, top mods, and moderation outcomes.\n- The hosted Build Farm Center shows reproducible build jobs, worker pools, SBOM status, signature decisions, malware scan gates, provenance attestations, artifact hashes, and promotion rings.\n- Registry Federation Center shows official, private, local, and community registry health with policy-aware search results and blocked package decisions.\n- Modpack Studio models lockfile-backed packs with graph preview, compatibility warnings, export links, and shareable install links.\n- Cloud Modpack Sharing Center exposes immutable lockfiles, one-click install links, compatibility status, trust decisions, rollback versions, update rings, maintainer metadata, and package badges.\n- Marketplace collections support featured packs, editor picks, starter packs, and community lists.\n- AI Compatibility Assistant Center shows advisory load-order fixes, bridge patch hints, permission warnings, migration notes, and evidence from lab, graph, manifest, and trust data.\n- Package Diff Center compares two mod versions before update, including permission changes, dependency changes, file hashes, settings migrations, changelog notes, rollback metadata, and the final approval decision.\n\nTrust and recovery:\n\n- Risk score explanations list positive and negative factors such as trusted signatures, safe permissions, reports, crash history, suspicious imports, and unsigned binaries.\n- Trust \u0026 Reputation Center combines package risk scores, publisher reputation, active advisories, quarantine recommendations, and policy version context into one review surface.\n- Enterprise Policy Simulation Lab previews allow, review, and block outcomes before a policy is rolled out to users.\n- The policy lab explains which rules fired, what permissions were requested, which registries were involved, and which update rings require consent.\n- Security hardening now requires well-formed bearer tokens or scoped TheUnlocker API keys for protected Go API routes.\n- Go API responses include baseline browser security headers such as `X-Content-Type-Options`, `X-Frame-Options`, `Referrer-Policy`, and `Cross-Origin-Resource-Policy`.\n- Crash recovery wizard steps cover safe mode, disabling recent changes, rollback, log inspection, and diagnostics upload.\n- Publisher verification models GitHub organization checks, domain checks, signed releases, badges, and trust history.\n- Desktop release center exposes stable, beta, and nightly update channels with signed-update policy, rollout percentages, release health, and rollback planning.\n\nDeveloper and ecosystem:\n\n- Plugin Marketplace entries cover game adapters, UI panels, scanners, workflow actions, themes, and package formats.\n- Workflow automation rules model pre-launch save backup, crash disablement, game-update responses, and stable-ring-only updates.\n- Compatibility intelligence tracks anonymous install and crash signals to warn about mod combinations that fail together.\n- Compatibility Lab Center shows adapter coverage, worker queue depth, sandbox test jobs, crash signatures, and release recommendations before a modpack is promoted.\n- Local Developer Mode supports symlinked mod projects, hot reload, manifest validation, rebuild loops, and streamed logs.\n- The in-app documentation hub points users to SDK docs, manifest schema, packaging, signing, sample mods, and troubleshooting.\n\n---\n\n## UI Screenshot Previews\n\nThese screenshots were captured from the running Vite + React marketplace.\n\nTracked screenshot assets live in `assets/screenshots/`.\n\n| Marketplace | Mod Detail |\n| --- | --- |\n| \u003cimg src=\"assets/screenshots/marketplace.png\" alt=\"Marketplace screenshot\" width=\"480\"\u003e | \u003cimg src=\"assets/screenshots/mod-detail.png\" alt=\"Mod detail screenshot\" width=\"480\"\u003e |\n| Browse trusted mods, filter by game and trust level, and follow install links. | Review package details, versions, permissions, trust state, and compatibility metadata. |\n\n| Onboarding | Platform |\n| --- | --- |\n| \u003cimg src=\"assets/screenshots/onboarding.png\" alt=\"Onboarding screenshot\" width=\"480\"\u003e | \u003cimg src=\"assets/screenshots/platform.png\" alt=\"Platform capability screenshot\" width=\"480\"\u003e |\n| Configure first-run role, primary game, registry URL, and safe local defaults. | Inspect platform capabilities across registry, workers, policy, build farm, and release systems. |\n\n---\n\n## Architecture At A Glance\n\nThe Unlocker is split into layers.\n\nEach layer has a separate responsibility.\n\n```text\nUser\n |\n | uses\n v\nDesktop WPF App                         Browser Marketplace\n |                                      |\n | uses safe SDK services               | calls REST APIs\n v                                      v\nModding Runtime                    Go API Gateway\n |                                      |\n | validates and loads mods             | exposes /api/v1 routes\n v                                      v\nMod SDK Abstractions              Ruby Registry Facade\n |                                      |\n | shared with mods                     | stores accounts and sessions\n v                                      v\nSample Mods                       .NET Registry API\n                                        |\n                                        | package metadata, moderation, Swagger\n                                        v\n                                  MongoDB / Redis / MinIO\n                                        |\n                                        v\n                              Rust Worker / .NET Worker\n```\n\nThe desktop app is not supposed to own registry logic.\n\nThe frontend is not supposed to own backend logic.\n\nThe SDK is not supposed to depend on the WPF app.\n\nThe runtime is not supposed to depend on marketplace UI.\n\nThe registry is not supposed to be a random file dump.\n\nThose boundaries keep the system easier to reason about.\n\n---\n\n## Repository Layout\n\n```text\n.\n|-- .github/\n|   |-- ISSUE_TEMPLATE/\n|   |-- workflows/\n|\n|-- backend/\n|   |-- ruby-registry/\n|   |   |-- app.rb\n|   |   |-- config.ru\n|   |   |-- Dockerfile\n|   |   |-- Gemfile\n|   |\n|   |-- go-api/\n|   |   |-- cmd/\n|   |   |-- internal/\n|   |   |-- Dockerfile\n|   |   |-- go.mod\n|   |\n|   |-- rust-worker/\n|       |-- Cargo.toml\n|       |-- src/\n|\n|-- deploy/\n|   |-- docker-compose.yml\n|   |-- marketplace.Dockerfile\n|   |-- registry-api.Dockerfile\n|   |-- worker.Dockerfile\n|   |-- README.md\n|\n|-- examples/\n|   |-- asset-importer-mod/\n|   |-- command-mod/\n|   |-- event-mod/\n|   |-- menu-item-mod/\n|   |-- settings-mod/\n|   |-- theme-mod/\n|   |-- tool-panel-mod/\n|\n|-- frontend/\n|   |-- marketplace/\n|       |-- src/\n|       |-- package.json\n|       |-- vite.config.ts\n|\n|-- schemas/\n|   |-- mod.schema.json\n|\n|-- templates/\n|   |-- theunlocker-mod/\n|\n|-- TheUnlocker/\n|   |-- WPF desktop application\n|\n|-- TheUnlocker.Adapter.Minecraft/\n|-- TheUnlocker.Adapter.TestKit/\n|-- TheUnlocker.Adapter.Unity/\n|-- TheUnlocker.Adapter.Unreal/\n|\n|-- TheUnlocker.ApiDocs.Web/\n|-- TheUnlocker.GameAdapters.Abstractions/\n|-- TheUnlocker.Marketplace.Web/\n|-- TheUnlocker.Modding.Abstractions/\n|-- TheUnlocker.Modding.Runtime/\n|-- TheUnlocker.Modding.TestHarness/\n|-- TheUnlocker.ModPackager/\n|-- TheUnlocker.Registry.Server/\n|-- TheUnlocker.Registry.Worker/\n|-- TheUnlocker.Sdk.Analyzers/\n|-- TheUnlocker.Tests/\n|\n|-- SampleMod/\n|\n|-- ARCHITECTURE.md\n|-- BACKEND.md\n|-- CLI.md\n|-- CODE_OF_CONDUCT.md\n|-- CONTRIBUTING.md\n|-- FRONTEND.md\n|-- INDEX.md\n|-- LICENSE\n|-- MOD_SCHEMA.md\n|-- MODPACKS.md\n|-- PLATFORM_PHASE_6.md\n|-- PROJECT_STRUCTURE.md\n|-- README.md\n|-- REGISTRY.md\n|-- ROADMAP.md\n|-- SECURITY.md\n|-- STACK.md\n|-- SUPPORT.md\n|-- TheUnlockerWorkspace.slnx\n```\n\n---\n\n## Technology Stack\n\nThe platform uses multiple technologies intentionally.\n\nThe desktop app and mod runtime are .NET because the target application is a C# desktop ecosystem.\n\nThe marketplace frontend is Vite + React + TypeScript because it gives a fast development loop and a clean browser UI path.\n\nThe Ruby registry facade is a lightweight Dockerized API layer for fast iteration.\n\nThe Go API gateway is a versioned client-facing API layer for desktop, marketplace, CLI, and automation clients.\n\nThe Rust worker is a small background service for queue-driven jobs and package processing.\n\nMongoDB stores registry records.\n\nRedis stores background queues and transient job state.\n\nMinIO or another S3-compatible service stores packages and media.\n\nDocker Compose ties the local platform together.\n\nThe major pieces are:\n\n- `.NET 8`\n- `WPF`\n- `xUnit`\n- `Vite`\n- `React`\n- `TypeScript`\n- `Ruby`\n- `Sinatra`\n- `Go`\n- `net/http`\n- `Rust`\n- `Axum`\n- `MongoDB`\n- `Redis`\n- `MinIO`\n- `Docker Compose`\n- `OpenAPI / Swagger`\n\nSee [STACK.md](STACK.md) for the full stack direction.\n\n---\n\n## Quick Start\n\nThis is the shortest path for checking that the repository builds.\n\nOpen PowerShell at the repository root.\n\n```powershell\ndotnet build .\\TheUnlockerWorkspace.slnx\n```\n\nRun the .NET tests.\n\n```powershell\ndotnet test .\\TheUnlocker.Tests\\TheUnlocker.Tests.csproj\n```\n\nCheck the CLI doctor command against the sample mod.\n\n```powershell\ndotnet run --project .\\TheUnlocker.ModPackager -- doctor .\\SampleMod\n```\n\nBuild the marketplace frontend.\n\n```powershell\ncd frontend/marketplace\nnpm install\nnpm run build\n```\n\nCheck the Rust worker.\n\n```powershell\ncargo check --manifest-path .\\backend\\rust-worker\\Cargo.toml\n```\n\nCheck the Ruby registry syntax.\n\n```powershell\nruby -c .\\backend\\ruby-registry\\app.rb\n```\n\nCheck the Go API.\n\n```powershell\ncd backend/go-api\ngo test ./...\ncd ../..\n```\n\nPackage the sample mod.\n\n```powershell\ndotnet run --project .\\TheUnlocker.ModPackager -- package .\\SampleMod .\\packaged-mods\n```\n\n---\n\n## Run Everything With Docker Compose\n\nThe local stack is defined in [deploy/docker-compose.yml](deploy/docker-compose.yml).\n\nThe Compose project name is pinned to `theunlocker`, so Docker creates containers like `theunlocker-mongo-1` and `theunlocker-redis-1`.\n\nStart it from the repository root.\n\n```powershell\ndocker compose -f .\\deploy\\docker-compose.yml up --build\n```\n\nStop it when finished.\n\n```powershell\ndocker compose -f .\\deploy\\docker-compose.yml down\n```\n\nUseful local URLs:\n\n- React marketplace: `http://localhost:5173`\n- Ruby registry facade: `http://localhost:4567`\n- Go API gateway: `http://localhost:8088`\n- Rust worker health: `http://localhost:7070/health`\n- .NET registry API: `http://localhost:5077`\n- Legacy .NET marketplace: `http://localhost:5080`\n- MinIO console: `http://localhost:9001`\n\nDocker Compose is the best option when you want MongoDB, Redis, object storage, API services, worker services, and the frontend running together.\n\nFor focused development, run individual pieces directly.\n\n---\n\n## Run The Containerized Release\n\nThe release-style stack is defined in [deploy/docker-compose.release.yml](deploy/docker-compose.release.yml).\n\nIt includes the React UI, Go API gateway, Ruby registry facade, .NET registry API, .NET worker, Rust worker, MongoDB, Redis, and MinIO.\n\nStart it from the repository root.\n\n```powershell\ndocker compose --env-file .\\deploy\\release.env.example -f .\\deploy\\docker-compose.release.yml up --build -d\n```\n\nOpen the UI.\n\n```text\nhttp://localhost:8080\n```\n\nUseful release URLs:\n\n- React marketplace UI: `http://localhost:8080`\n- Go API gateway: `http://localhost:8088`\n- Ruby registry facade: `http://localhost:4567`\n- .NET registry API: `http://localhost:5077`\n- Rust worker health: `http://localhost:7070/health`\n- MinIO console: `http://localhost:9001`\n\nStop the release stack.\n\n```powershell\ndocker compose -f .\\deploy\\docker-compose.release.yml down\n```\n\nRelease deployment notes live in [CONTAINER_RELEASE.md](CONTAINER_RELEASE.md).\n\n---\n\n## Run The Desktop App\n\nBuild the solution first.\n\n```powershell\ndotnet build .\\TheUnlockerWorkspace.slnx\n```\n\nRun the WPF desktop app.\n\n```powershell\ndotnet run --project .\\TheUnlocker\n```\n\nThe desktop app is responsible for local mod management.\n\nIt is where installed mods, profiles, recovery flows, local packages, trust policy, and diagnostics come together.\n\nUse the desktop app when testing:\n\n- Local mod folders\n- Enable and disable toggles\n- Package import\n- Permission review\n- Rollback\n- Recovery center\n- Local development links\n- Diagnostics exports\n\n---\n\n## Run The Marketplace Frontend\n\nGo to the marketplace folder.\n\n```powershell\ncd frontend/marketplace\n```\n\nInstall dependencies.\n\n```powershell\nnpm install\n```\n\nStart Vite.\n\n```powershell\nnpm run dev\n```\n\nOpen the frontend.\n\n```text\nhttp://localhost:5173\n```\n\nBuild for production.\n\n```powershell\nnpm run build\n```\n\nPreview the production build.\n\n```powershell\nnpm run preview\n```\n\nThe frontend calls marketplace API routes through the Go gateway at `/go-api/api/v1`. The Docker image also exposes `/api/*` as a browser-friendly alias for `/api/v1`.\n\nThe production Nginx config exposes the Go gateway through both `/api/` and `/go-api/`.\n\nFor example:\n\n```text\nhttp://localhost:5173/go-api/api/v1/health\n```\n\nWhen running with Docker Compose, the proxy path is configured by the deployment setup.\n\nWhen running locally by hand, point Vite or your reverse proxy at the Go API gateway. The gateway can proxy selected internal calls to the Ruby registry facade.\n\nThe frontend currently includes:\n\n- Sign in\n- Create account\n- Session restore through `localStorage`\n- First-run onboarding\n- Marketplace health display\n- Mod search\n- Game filter\n- Trust filter\n- Install deep links\n\nSee [FRONTEND.md](FRONTEND.md) for details.\n\n---\n\n## Run The Ruby Registry Facade\n\nGo to the Ruby service.\n\n```powershell\ncd backend/ruby-registry\n```\n\nInstall dependencies.\n\n```powershell\nbundle install\n```\n\nRun the service.\n\n```powershell\nbundle exec rackup -o 0.0.0.0 -p 4567\n```\n\nHealth check:\n\n```text\nhttp://localhost:4567/health\n```\n\nThe Ruby service currently provides:\n\n- Registry health\n- Account creation\n- Sign in\n- Sign out\n- Session restore\n- Onboarding persistence\n- Mod listing\n- Mod details\n- Mod metadata creation\n- Crash report submission\n- Job creation\n\nImportant endpoints:\n\n- `GET /health`\n- `POST /auth/register`\n- `POST /auth/login`\n- `POST /auth/logout`\n- `GET /auth/session`\n- `POST /onboarding`\n- `GET /mods`\n- `GET /mods/:id`\n- `POST /mods`\n- `POST /jobs/:type`\n- `POST /crash-reports`\n\nSee [BACKEND.md](BACKEND.md) for backend details.\n\n---\n\n## Run The Go API Gateway\n\nGo to the Go API service.\n\n```powershell\ncd backend/go-api\n```\n\nRun tests.\n\n```powershell\ngo test ./...\n```\n\nStart the service.\n\n```powershell\ngo run ./cmd/server\n```\n\nHealth endpoint:\n\n```text\nhttp://localhost:8088/health\n```\n\nOpenAPI spec:\n\n```text\nhttp://localhost:8088/openapi.json\n```\n\nAPI docs landing page:\n\n```text\nhttp://localhost:8088/docs\n```\n\nVersioned health endpoint:\n\n```text\nhttp://localhost:8088/api/v1/health\n```\n\nThe Go API gateway currently exposes:\n\n- `GET /health`\n- `GET /openapi.json`\n- `GET /docs`\n- `GET /api/v1/health`\n- `POST /api/v1/auth/register`\n- `POST /api/v1/auth/login`\n- `POST /api/v1/auth/refresh`\n- `POST /api/v1/auth/logout`\n- `GET /api/v1/me`\n- `GET /api/v1/sync/{userId}`\n- `GET /api/v1/account/settings`\n- `POST /api/v1/account/settings`\n- `GET /api/v1/mods`\n- `GET /api/v1/mods/{id}`\n- `POST /api/v1/jobs/{type}`\n- `POST /api/v1/crash-reports`\n- `GET /api/v1/platform/major-upgrades`\n\nBy default it proxies to:\n\n```text\nhttp://ruby-registry:4567\n```\n\nFor local direct execution, set:\n\n```powershell\n$env:REGISTRY_BASE_URL = \"http://localhost:4567\"\n$env:PORT = \"8088\"\ngo run ./cmd/server\n```\n\nThe gateway forwards `Authorization` and `X-Api-Key` headers so future authenticated clients can call a stable Go API surface while the registry implementation continues to evolve.\n\n---\n\n## Run The Rust Worker\n\nCheck the worker.\n\n```powershell\ncargo check --manifest-path .\\backend\\rust-worker\\Cargo.toml\n```\n\nRun the worker.\n\n```powershell\ncargo run --manifest-path .\\backend\\rust-worker\\Cargo.toml\n```\n\nHealth endpoint:\n\n```text\nhttp://localhost:7070/health\n```\n\nThe Rust worker is intended for queue-driven jobs such as:\n\n- Package scan jobs\n- Hash verification jobs\n- Compatibility jobs\n- Webhook jobs\n- Reproducible build jobs\n- Future background processing that should not block API requests\n\n---\n\n## Run The .NET Registry API\n\nBuild the solution.\n\n```powershell\ndotnet build .\\TheUnlockerWorkspace.slnx\n```\n\nRun the registry API.\n\n```powershell\ndotnet run --project .\\TheUnlocker.Registry.Server\n```\n\nThe registry API is the deeper .NET backend for:\n\n- Package metadata\n- Registry storage abstractions\n- Mongo or JSON storage switching\n- Moderation\n- Advisories\n- Webhooks\n- Package uploads\n- Compatibility records\n- Swagger/OpenAPI\n\nSee [REGISTRY.md](REGISTRY.md) for registry behavior.\n\n---\n\n## Run Tests\n\nRun all .NET tests.\n\n```powershell\ndotnet test .\\TheUnlocker.Tests\\TheUnlocker.Tests.csproj\n```\n\nBuild the frontend.\n\n```powershell\ncd frontend/marketplace\nnpm run build\n```\n\nCheck Ruby syntax.\n\n```powershell\nruby -c .\\backend\\ruby-registry\\app.rb\n```\n\nCheck Go.\n\n```powershell\ncd backend/go-api\ngo test ./...\ncd ../..\n```\n\nCheck Rust.\n\n```powershell\ncargo check --manifest-path .\\backend\\rust-worker\\Cargo.toml\n```\n\nThe test suite currently covers core modding and package behavior.\n\nFuture test coverage should continue expanding around:\n\n- Registry routes\n- Worker jobs\n- Auth flows\n- Onboarding persistence\n- Frontend components\n- Package signing\n- Dependency resolution\n- Rollback\n- Lockfile behavior\n- Analyzer code fixes\n\n---\n\n## Create And Package A Sample Mod\n\nThe repository includes [SampleMod](SampleMod/) and multiple example mods under [examples](examples/).\n\nBuild the sample mod.\n\n```powershell\ndotnet build .\\SampleMod\n```\n\nRun the packager doctor command.\n\n```powershell\ndotnet run --project .\\TheUnlocker.ModPackager -- doctor .\\SampleMod\n```\n\nPackage the sample mod.\n\n```powershell\ndotnet run --project .\\TheUnlocker.ModPackager -- package .\\SampleMod .\\packaged-mods\n```\n\nThe package workflow should:\n\n- Find `mod.json`\n- Validate required fields\n- Validate version strings\n- Validate permissions\n- Validate entry DLL\n- Compute hashes\n- Create a distributable package\n\nSee [CLI.md](CLI.md) for CLI commands.\n\nSee [MOD_SCHEMA.md](MOD_SCHEMA.md) for manifest fields.\n\n---\n\n## Mod Author Workflow\n\nA typical mod author flow looks like this:\n\n1. Install the SDK abstractions package.\n2. Create a mod project.\n3. Implement the mod lifecycle.\n4. Declare metadata in `mod.json`.\n5. Declare permissions.\n6. Declare dependencies.\n7. Add settings if needed.\n8. Run local validation.\n9. Package the mod.\n10. Sign the package if publishing.\n11. Test in local development mode.\n12. Publish to a registry when ready.\n\nThe intended CLI shape is:\n\n```text\nunlocker-mod init\nunlocker-mod validate\nunlocker-mod package\nunlocker-mod sign\nunlocker-mod publish\nunlocker-mod doctor\n```\n\nThe intended template shape is:\n\n```powershell\ndotnet new theunlocker-mod -n MyFirstMod\n```\n\nThe mod author should reference the SDK abstraction project, not the full WPF app.\n\nThat keeps the mod API stable and small.\n\nThe SDK layer lives in [TheUnlocker.Modding.Abstractions](TheUnlocker.Modding.Abstractions/).\n\nThe runtime layer lives in [TheUnlocker.Modding.Runtime](TheUnlocker.Modding.Runtime/).\n\n---\n\n## Registry And Marketplace Workflow\n\nA registry workflow looks like this:\n\n1. Publisher creates an account.\n2. Publisher signs in.\n3. Publisher uploads package metadata.\n4. Registry creates scan jobs.\n5. Worker processes scan jobs.\n6. Registry stores scan results.\n7. Moderation approves, rejects, or quarantines a package.\n8. Marketplace shows approved versions.\n9. Desktop installs through a deep link or direct package flow.\n10. Desktop verifies hash and signature.\n11. Desktop validates manifest and lockfile.\n12. Desktop installs atomically.\n13. Desktop records rollback history.\n\nMarketplace pages should eventually include:\n\n- Screenshots\n- Media galleries\n- Changelogs\n- Markdown descriptions\n- Publisher profiles\n- Compatibility badges\n- Ratings\n- Reviews\n- Install buttons\n- Modpack pages\n- Collections\n- Risk scores\n- Advisories\n\nThe current React frontend is the browser-facing foundation.\n\nThe .NET marketplace project remains available for legacy or comparison scenarios.\n\n---\n\n## Persistent Accounts And Onboarding\n\nThe marketplace now starts with a sign-in or create-account flow.\n\nAccounts are stored by the Ruby registry facade.\n\nSessions are bearer-token based.\n\nThe frontend stores the session response in `localStorage`.\n\nOn reload, the frontend calls `/auth/session` to confirm the token is still valid.\n\nIf the token is invalid or expired, the local session is cleared.\n\nIf the account has not completed onboarding, the onboarding screen is shown.\n\nOnboarding currently stores:\n\n- Role\n- Primary game or runtime\n- Registry URL\n- Completion status\n\nThis supports persistent sessions across browser refreshes.\n\nThe current auth implementation is suitable as development scaffolding.\n\nProduction hardening should add:\n\n- BCrypt, Argon2, or another proper password hashing strategy.\n- Secure cookie support if the deployment wants cookie sessions.\n- CSRF protection for cookie-based flows.\n- Email verification.\n- Password reset.\n- OAuth providers.\n- JWT sessions or signed opaque token storage.\n- Rate limiting.\n- Login audit records.\n- Device/session management.\n\n---\n\n## Mod Safety Model\n\nThe Unlocker safety model is based on explicit capabilities.\n\nMods should not receive the whole application object.\n\nMods should receive a limited context.\n\nThat context should expose only approved services.\n\nExample service categories:\n\n- Menu items\n- Asset registry\n- Notifications\n- Settings\n- Events\n- Themes\n- Commands\n- Tool panels\n- Document panels\n- Game adapters\n\nExample permissions:\n\n```json\n{\n  \"permissions\": [\n    \"ReadAssets\",\n    \"AddMenuItems\",\n    \"SendNotifications\"\n  ]\n}\n```\n\nThe runtime should compare requested permissions against policy.\n\nThe UI should show the permissions in plain language.\n\nThe user or administrator should approve permissions before enabling a mod.\n\nThe mod context should expose only the approved services.\n\nThis is how The Unlocker avoids the \"every mod gets everything\" problem.\n\n---\n\n## Security Boundary\n\nThe Unlocker supports safe, cooperative mod loading through SDK extension points.\n\nIt does not support:\n\n- Licensing bypasses\n- Ownership bypasses\n- Authentication bypasses\n- Anti-cheat bypasses\n- Integrity-check evasion\n- Arbitrary patching of protected third-party code\n- Runtime injection into protected applications\n- Circumventing access controls\n\nThe platform is meant for applications and games that intentionally expose safe modding surfaces.\n\nSecurity features in the project include:\n\n- Manifest validation\n- Permission declarations\n- Trust levels\n- Signature records\n- Hash verification\n- Policy gates\n- Quarantine flows\n- Crash disablement\n- Diagnostics bundles\n- Risk scoring\n- Package scanning hooks\n- Registry moderation\n- Audit logs\n- Enterprise policy concepts\n\nSee [SECURITY.md](SECURITY.md) for more detail.\n\n---\n\n## Configuration\n\nThe platform uses local configuration for development and service configuration for registry deployments.\n\nImportant local concepts:\n\n- Mod folders\n- Module folders\n- Profiles\n- Active profile\n- Enabled mods\n- Trust policy\n- Registry URL\n- Local development links\n- Rollback history\n- Diagnostics logs\n\nImportant registry concepts:\n\n- `MONGO_URL`\n- `REDIS_URL`\n- `MINIO_ENDPOINT`\n- `DOTNET_REGISTRY_URL`\n- `SESSION_SECRET`\n- `Registry:StorageProvider`\n- API keys\n- OAuth credentials\n- Signing keys\n- Trusted publishers\n- Enterprise policy\n\nFor Docker Compose development, prefer environment variables defined by [deploy/docker-compose.yml](deploy/docker-compose.yml).\n\nFor local direct execution, set the variables in your shell.\n\nExample:\n\n```powershell\n$env:MONGO_URL = \"mongodb://localhost:27017/theunlocker_registry\"\n$env:REDIS_URL = \"redis://localhost:6379\"\n$env:SESSION_SECRET = \"replace-this-for-local-dev\"\n```\n\n---\n\n## Documentation Index\n\nAll major documentation is kept at the repository root for easy GitHub browsing.\n\nPrimary docs:\n\n- [INDEX.md](INDEX.md) - Documentation index and reading order.\n- [ARCHITECTURE.md](ARCHITECTURE.md) - System architecture and boundaries.\n- [PROJECT_STRUCTURE.md](PROJECT_STRUCTURE.md) - Folder and project organization.\n- [STACK.md](STACK.md) - Frontend, backend, runtime, and deployment stack direction.\n- [DATABASE_OWNERSHIP.md](DATABASE_OWNERSHIP.md) - Source-of-truth map for backend-owned collections.\n- [ADR_0001_API_GATEWAY.md](ADR_0001_API_GATEWAY.md) - Decision record for the public Go gateway.\n- [ADR_0002_DATABASE_OWNERSHIP.md](ADR_0002_DATABASE_OWNERSHIP.md) - Decision record for data ownership.\n- [ADR_0003_RELEASE_PIPELINE.md](ADR_0003_RELEASE_PIPELINE.md) - Decision record for release artifacts.\n- [FRONTEND.md](FRONTEND.md) - Vite + React + TypeScript frontend guide.\n- [BACKEND.md](BACKEND.md) - Go, Ruby, Rust, and .NET backend guide.\n- [REGISTRY.md](REGISTRY.md) - Registry API and marketplace backend behavior.\n- [CLI.md](CLI.md) - Mod packager and author CLI commands.\n- [SECURITY.md](SECURITY.md) - Safety model, trust, signing, policy, and boundaries.\n- [MOD_SCHEMA.md](MOD_SCHEMA.md) - `mod.json` manifest schema.\n- [MODPACKS.md](MODPACKS.md) - Modpack, lockfile, and profile concepts.\n- [ROADMAP.md](ROADMAP.md) - Future platform roadmap.\n- [MAJOR_PLATFORM_UPGRADES.md](MAJOR_PLATFORM_UPGRADES.md) - Federation, hosted builds, SAT solving, sync, orchestration, workflow, observability, policy, extension marketplace, AI assistant, and updater details.\n- [PRODUCT_UPGRADES.md](PRODUCT_UPGRADES.md) - Account auth, cloud sync, install pipeline, publisher portal, modpack studio, recovery, trust explanations, developer mode, collections, and docs hub surfaces.\n- [PLATFORM_PHASE_6.md](PLATFORM_PHASE_6.md) - Larger platform expansion phase.\n- [CONTRIBUTING.md](CONTRIBUTING.md) - Contributor guide.\n- [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) - Community behavior expectations.\n- [SUPPORT.md](SUPPORT.md) - Support and issue guidance.\n- [CONTAINER_RELEASE.md](CONTAINER_RELEASE.md) - Release-style Docker Compose stack with a React UI.\n- [LICENSE](LICENSE) - Apache License 2.0.\n\nDeployment docs:\n\n- [deploy/README.md](deploy/README.md) - Docker Compose and service deployment notes.\n- [deploy/docker-compose.yml](deploy/docker-compose.yml) - Local service stack.\n- [deploy/marketplace.Dockerfile](deploy/marketplace.Dockerfile) - Marketplace container.\n- [deploy/registry-api.Dockerfile](deploy/registry-api.Dockerfile) - Registry API container.\n- [deploy/worker.Dockerfile](deploy/worker.Dockerfile) - Worker container.\n\nSchema docs:\n\n- [schemas/mod.schema.json](schemas/mod.schema.json) - JSON Schema for mod manifests.\n\nProject entry points:\n\n- [TheUnlockerWorkspace.slnx](TheUnlockerWorkspace.slnx) - Solution file.\n- [TheUnlocker](TheUnlocker/) - WPF desktop app.\n- [frontend/marketplace](frontend/marketplace/) - React marketplace.\n- [backend/ruby-registry](backend/ruby-registry/) - Ruby registry facade.\n- [backend/go-api](backend/go-api/) - Go API gateway.\n- [backend/rust-worker](backend/rust-worker/) - Rust worker.\n\n---\n\n## Feature Inventory\n\nThe following list gives a broad view of what the platform is designed to cover.\n\n### Desktop\n\n- Installed mod list\n- Enable toggles\n- Disable toggles\n- Local mod discovery\n- Local module discovery\n- Local package import\n- Drag and drop install concept\n- Package validation\n- Manifest validation\n- Dependency display\n- Load order display\n- Dependency graph preview\n- Compatibility report\n- Profile switching\n- Game-specific profiles\n- Recovery center\n- Safe mode startup\n- Crash disablement\n- Rollback history\n- One-click rollback concept\n- Trust policy editor\n- Permission simulator\n- Permission review timeline\n- Mod health dashboard\n- Advanced log search\n- Diagnostics export\n- Crash upload UI concept\n- Offline marketplace cache\n- Backup and restore\n- Notification center\n- Theme and plugin extension gallery\n- Local development mode\n- Hot refresh concept\n- Protocol handler for `theunlocker://install`\n- Protocol handler for modpack install links\n- Modpack lockfile install flow\n- Desktop self-update concept\n- Major Platform tab\n- Cloud profile sync snapshot model\n- Remote install orchestration model\n- Workflow automation rule model\n- Runtime observability summary\n\n### Marketplace\n\n- Vite frontend\n- React UI\n- TypeScript types\n- Account creation\n- Sign in\n- Sign out\n- Session restore\n- First-run onboarding\n- Real routes for `/mods/:id`, `/publishers/:id`, `/modpacks/:id`, `/cloud-modpacks`, `/platform`, and `/settings`\n- Marketplace filters\n- Trust filter\n- Game filter\n- Mod cards\n- Install deep links\n- Health status\n- Platform capability page\n- Future media galleries\n- Future changelog pages\n- Future markdown descriptions\n- Future publisher profiles\n- Future ratings\n- Future reviews\n- Future compatibility badges\n- Future mod collections\n- Future modpacks\n- Cloud modpack sharing with immutable lockfiles, install links, compatibility status, and rollback metadata\n- AI compatibility assistant with reviewable suggestions and evidence\n- Package diff center with permission, dependency, file, migration, changelog, and rollback review\n- Publisher analytics center with installs, conversion, crash health, ratings, adoption, and moderation outcomes\n\n### Registry\n\n- Go API gateway\n- Versioned `/api/v1` routes\n- OpenAPI output at `/openapi.json`\n- Mongo-backed mod reads and writes when configured\n- API health endpoint\n- API proxying to registry facade\n- Ruby registry facade\n- .NET registry API\n- MongoDB storage\n- JSON storage fallback concept\n- Storage provider switching\n- Mod metadata routes\n- Package upload concepts\n- Moderation queue\n- Advisories\n- Publisher workflows\n- Crash report ingestion\n- Job creation\n- Health checks\n- API keys\n- Scoped API key concepts\n- OAuth concepts\n- Role-based access control concepts\n- Webhooks\n- HMAC webhook signatures\n- Delivery logs\n- Dead-letter queue concepts\n- Audit logs\n- Signed registry index snapshots\n- Vulnerability advisories\n- Compatibility database\n- Package provenance\n- Reproducible build verification\n- Private registries\n- Organization accounts\n- Publisher teams\n- Enterprise policy sync\n- Federated registries\n- Mirrors\n- CDN support\n- Major platform capability feed\n- Hosted build farm model\n- Publisher economy model\n- Trust and reputation engine\n\n### Workers\n\n- Rust worker service\n- .NET worker service\n- Redis job queue\n- Package scan jobs\n- Compatibility lab jobs\n- Webhook delivery jobs\n- Reproducible build jobs\n- Hosted build farm jobs\n- Crash triage jobs\n- Worker heartbeat\n- Queue depth metrics\n- Dead-letter concepts\n- Retry concepts\n- Duration tracking concepts\n- Structured logging concepts\n- Metrics concepts\n- Tracing concepts\n\n### Mod Runtime\n\n- Manifest-based discovery\n- Enable and disable config\n- Dependency sorting\n- Missing dependency handling\n- Optional dependency model\n- Peer dependency model\n- Dependency version ranges\n- SAT-style dependency solving\n- Lockfile generation from solver output\n- Version compatibility checks\n- SDK compatibility checks\n- Load phases\n- Async lifecycle concept\n- Assembly load context isolation\n- True unload verification concept\n- Crash protection\n- Per-mod diagnostics\n- Per-mod settings\n- Typed settings\n- Event bus\n- Event schema registry concept\n- Command registration\n- Menu registration\n- Theme provider registration\n- Asset importer registration\n- Tool panel registration\n- Document panel registration\n- Permission-gated services\n- Capability token concept\n- Policy engine\n- Mod migration system\n- Health tracking\n- Load time tracking\n- Exception tracking\n- Services used tracking\n- Runtime observability metrics\n- AI compatibility assistant analysis\n- Extension marketplace package model\n\n### Security\n\n- Manifest validation\n- Hash verification\n- Digital signatures\n- Public key trust records\n- Key rotation\n- Key revocation\n- Trust levels\n- Package quarantine\n- Permission consent\n- Permission diff on update\n- Risk scoring\n- Antivirus adapter concepts\n- ClamAV adapter concept\n- YARA adapter concept\n- Scan rules\n- Package reputation score\n- Enterprise mode\n- Admin-managed policies\n- Private registry policies\n- Allowlists\n- Blocklists\n- Audit logs\n- Signed registry snapshots\n- Package provenance\n- SBOM generation concept\n- SLSA or in-toto attestation concept\n\n### Developer Experience\n\n- Stable SDK abstractions\n- Mod test harness\n- Roslyn analyzers\n- Analyzer code fixes\n- Analyzer tests\n- `dotnet new` mod template\n- Template package concept\n- Sample mod project\n- Example mod gallery\n- CLI doctor command\n- CLI validate command\n- CLI package command\n- CLI sign command\n- CLI publish command\n- Manifest JSON Schema\n- VS Code extension concept\n- Visual Studio extension concept\n- API docs generation\n- Markdown docs generation\n- HTML docs generation\n- CI templates for mod authors\n- Local registry emulator concept\n- Adapter SDK\n- Adapter test kit\n\n### Game Adapters\n\n- Unity adapter\n- Unreal adapter\n- Minecraft adapter\n- Multi-game adapter direction\n- Steam library scan concept\n- Unity folder detection\n- Unreal folder detection\n- Minecraft folder detection\n- Adapter capability declarations\n- Adapter compatibility tests\n- Fake game fixtures\n- Launch profiles\n- Launch arguments\n- Sandbox test jobs\n\n### Modpacks\n\n- Modpack project mode\n- `unlocker.json`\n- `unlocker.lock.json`\n- Lockfile resolver\n- Exact version pinning\n- Package hash pinning\n- Modpack export\n- Modpack import\n- Cloud modpack sharing\n- Maintained collections\n- Curated modpacks\n- Update rings\n- Stable ring\n- Beta ring\n- Nightly ring\n- Canary rollout concept\n- Automated update rollback\n- Compatibility patch marketplace\n\n---\n\n## Roadmap Snapshot\n\nThe near-term roadmap should focus on making the core platform feel real end to end.\n\nHigh-impact next work:\n\n- Harden authentication with real password hashing.\n- Add API tests for auth and onboarding.\n- Add frontend component tests.\n- Add desktop protocol handler implementation.\n- Add complete install queue UI.\n- Add package import rollback.\n- Add Mongo repositories for every registry route.\n- Add Redis worker dashboard.\n- Add object storage implementations.\n- Add package signing UX.\n- Add publisher upload wizard.\n- Add registry admin UI.\n- Add compatibility lab runner.\n- Add dependency graph viewer in WPF.\n- Add real modpack lockfile resolver.\n- Add SDK analyzer NuGet package.\n- Add dotnet template package.\n- Add GitHub Actions release workflow.\n\nLong-term platform goals:\n\n- Hosted registry server\n- Web marketplace\n- One-click installs\n- Publisher portal\n- Organization accounts\n- Private registries\n- Cloud modpack sharing\n- Package reputation scores\n- Compatibility intelligence\n- Enterprise policy sync\n- Federation\n- Mirrors\n- SBOM generation\n- Provenance attestations\n- Automated compatibility lab\n- Desktop self-update\n- Full observability\n\nSee [ROADMAP.md](ROADMAP.md) for more.\n\n---\n\n## GitHub Readiness\n\nThis repository is organized for GitHub browsing.\n\nThe documentation is root-level.\n\nThere is no `/docs` folder required for the main reading path.\n\n| Symbol | GitHub Surface | Status |\n| --- | --- | --- |\n| [G1] | Root README with screenshots, badges, quick start, stack notes, safety boundary, and doc links. | Ready |\n| [G2] | Root documentation set with architecture, backend, frontend, security, registry, roadmap, support, and ADRs. | Ready |\n| [G3] | `.github/ISSUE_TEMPLATE` with bug and feature request forms. | Ready |\n| [G4] | `.github/pull_request_template.md` with verification and safety checklist. | Ready |\n| [G5] | `.github/workflows/dotnet-ci.yml` covering .NET, frontend, Go, Rust, and Ruby checks. | Ready |\n| [G6] | `.github/workflows/release.yml` for release packaging flow. | Ready |\n| [G7] | `.devcontainer/` and `justfile` for repeatable contributor setup. | Ready |\n| [G8] | `assets/screenshots/` with tracked UI previews for GitHub readers. | Ready |\n\nIncluded repository files:\n\n- `.gitignore`\n- `.gitattributes`\n- `.editorconfig`\n- `.dockerignore`\n- `LICENSE`\n- `CODE_OF_CONDUCT.md`\n- `CONTRIBUTING.md`\n- `SUPPORT.md`\n- GitHub issue templates\n- Pull request template\n- GitHub Actions workflow\n- GitHub Actions release workflow\n- Devcontainer setup\n- `justfile` task runner\n- Root documentation index\n\nGenerated artifacts should not be committed.\n\nDo not commit:\n\n- `bin/`\n- `obj/`\n- `node_modules/`\n- `dist/`\n- `target/`\n- temporary package output\n- local secrets\n- local database files\n\nCommit source, schemas, docs, project files, lockfiles, and reproducible configuration.\n\nRecommended pre-push checks:\n\n```powershell\ndotnet build .\\TheUnlockerWorkspace.slnx\ndotnet test .\\TheUnlocker.Tests\\TheUnlocker.Tests.csproj --no-build\ncd frontend\\marketplace; npm run build\ncd ..\\..\\backend\\go-api; go test ./...\n```\n\n---\n\n## Contributing\n\nContributions should preserve the safety boundary.\n\nGood contributions include:\n\n- Better manifest validation\n- Clearer docs\n- Safer runtime services\n- Stronger package verification\n- UI improvements\n- Tests\n- Example mods\n- Analyzer rules\n- Registry route implementations\n- Worker job implementations\n- Deployment hardening\n- Accessibility improvements\n\nAvoid contributions that:\n\n- Add bypass behavior\n- Add protected-app patching behavior\n- Add ambiguous security claims\n- Couple mods to the full desktop app\n- Hide permissions from users\n- Load unvalidated packages\n- Skip dependency checks\n- Store secrets in source\n\nBefore opening a pull request:\n\n1. Build the solution.\n2. Run tests.\n3. Build the frontend.\n4. Check Ruby syntax.\n5. Check Rust.\n6. Update docs if behavior changed.\n7. Add or update tests for risky changes.\n\nRecommended checks:\n\n```powershell\ndotnet build .\\TheUnlockerWorkspace.slnx\ndotnet test .\\TheUnlocker.Tests\\TheUnlocker.Tests.csproj\ncd frontend/marketplace\nnpm install\nnpm run build\ncd ../..\nruby -c .\\backend\\ruby-registry\\app.rb\ncargo check --manifest-path .\\backend\\rust-worker\\Cargo.toml\n```\n\nSee [CONTRIBUTING.md](CONTRIBUTING.md).\n\n---\n\n## Support\n\nUse [SUPPORT.md](SUPPORT.md) for support expectations.\n\nWhen reporting an issue, include:\n\n- Operating system\n- .NET SDK version\n- Node version\n- Ruby version\n- Rust version\n- Docker version if using Compose\n- Exact command that failed\n- Error output\n- Relevant mod manifest\n- Relevant package metadata\n- Steps to reproduce\n\nFor crash reports, include a diagnostics bundle when possible.\n\nFor security issues, avoid posting exploit details publicly.\n\n---\n\n## License\n\nThe Unlocker is licensed under the Apache License, Version 2.0.\n\nSee [LICENSE](LICENSE).\n\n---\n\n## Final Notes\n\nThe Unlocker is meant to be a serious foundation for safe modding workflows.\n\nIt starts local.\n\nIt scales toward hosted registry workflows.\n\nIt gives mod authors a stable SDK.\n\nIt gives users visibility and recovery tools.\n\nIt gives publishers a path toward signed, reviewed releases.\n\nIt gives teams a path toward policies and private registries.\n\nMost importantly, it keeps the platform centered on cooperative extension points.\n\nThat boundary is what lets the project grow without becoming a mess.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmagnexis%2Fthe-unlocker","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmagnexis%2Fthe-unlocker","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmagnexis%2Fthe-unlocker/lists"}