Project Portfolio
Codename: The Union Ledger
Game Application Designed and Developed by Nerdy Tech Geeks
This site is structured as a professional project portfolio for ValkenRoot. It explains what was built at each version, what design and technical thinking shaped it, how the architecture matured, and why the project was rebuilt into the current V1.0 direction.
Executive Summary
ValkenRoot began as a dark industrial fantasy concept and progressively evolved into a structured application and platform design. Each version clarified gameplay identity, world systems, product surfaces, infrastructure, and operational maturity.
V1.0 is the first version that formalizes the project as a fullstack platform with explicit boundaries, importer-driven content, disciplined delivery, and architecture shaped around long-term runtime and operations needs.
Current Lead Version
This is the current version and the one that reflects what is actively being built now. It stays at the top because it shows the present state of the work. The versions below explain how the project got here.
Earlier versions proved the world and product ambition, but they also showed that the project needed stronger boundaries to scale. V1.0 exists because world complexity, runtime goals, data depth, and live operations demands could not safely keep growing inside a looser prototype structure.
The rebuild was driven by the need for repeatable imports, deliberate service ownership, environment-aware deployment, future simulation work, and a structure that could support both creative world design and disciplined engineering delivery.
The V1.0 direction was built from the inside out. First came system planning, source data modeling, handoff structure, and operational roles. Then came the implementation foundation: repository, CI/CD, schema, local stack, importer, seeded data, and the first API surfaces.
That sequence was intentional. It reduced rework and forced the project to grow on real content and real boundaries instead of placeholder mocks.
V1.0 formalizes delivery around GitLab CI/CD so the project can move from local engineering work into repeatable validation, packaging, and deployment. Delivery is treated as part of the architecture, not as a final-step add-on.
That means source control, validation gates, build outputs, container packaging, environment promotion, and operational visibility are designed as one connected system.
Docker is the immediate packaging and runtime target for the web app, API, workers, monitor, and support services. It gives ValkenRoot a predictable delivery baseline for local development, controlled staging, and repeatable environment setup.
Kubernetes is the scaled deployment target once the platform grows into a fuller operational model. The same validated images and service boundaries move forward into orchestrated deployment, service discovery, scaling, and environment isolation.
Approach
The implementation path was designed to grow on imported source data rather than placeholder mocks. That is why the importer, schema, seed waves, and release-aware content flow were prioritized early in V1.0.
ValkenRoot is not only a player-facing surface. It also requires governance, simulation, and operational visibility. Those concerns were deliberately separated so player experience, admin control, and system monitoring do not collapse into one unsafe interface.
Identity, role boundaries, and monitoring were treated as architecture requirements, not optional additions. That thinking is visible in both the planning structure and the current V1.0 diagrams.
Each version proves something different: concept, gameplay identity, world scale, platform direction, system layering, runtime ambition, staged validation, and finally formal rebuild. The history shows how the project matured.
Version Progression
V1.0 stays on top because it reflects what is currently being built. After that, the sections below are arranged in progression order so the story reads from the beginning forward: how ValkenRoot started, what changed at each version, and how each stage fed the next.
The first version established the creative identity of ValkenRoot: industrial fantasy, layered labor society, salvage, dangerous mobility, and a basin-city world governed by power and scarcity.
The goal here was not technical completeness. It was to define the project’s thematic center strongly enough that every later system could inherit a coherent tone and purpose.
Good systems only matter if they serve a clear project identity. This version established the setting logic and emotional weight that later gameplay, application, and infrastructure decisions were designed to preserve.
This is where the project started making stronger claims about what kind of game experience it actually wanted to be.
The emphasis shifted toward contracts, survival, factions, and a more grounded operator fantasy. The project began distinguishing itself from a generic fantasy adventure by centering labor, risk, and institutional pressure.
This version gave the project its behavioral identity. Without this phase, later architecture could have been competent but generic. The product shape became clearer because the play shape became clearer.
The setting became broader, more layered, and more structurally useful. Districts, regions, settlements, and faction presence started behaving like data as much as atmosphere.
The work here was about making the world legible and scalable. A project like ValkenRoot cannot survive if the setting remains only descriptive; it has to be partitionable, referenceable, and eventually implementable.
This stage laid the groundwork for later data modeling. Many of the later world, zone, and geography decisions only work because the setting was expanded in a way that made structure visible.
The core project question shifted from "what is this world?" to "what does this become as an application?"
This stage focused on identifying actual product surfaces: codex, characters, contracts, world reference, and administration. The project needed clearer user surfaces and logic zones rather than only more lore.
This was the first serious move toward fullstack thinking. It made later backend, schema, and importer work much more natural because the user-facing surfaces had already been conceptually separated.
This version is where the project began separating major concerns instead of letting everything live in one conceptual bucket.
The design effort here focused on layers: user roles, service ownership, content structure, administrative control, and what the system would eventually need to support as it became more than a prototype.
Without this layering step, later versions would have been forced to retrofit structure into an already tangled model. This is one of the key bridges from prototype thinking into platform thinking.
This is the version where ValkenRoot stopped behaving like a rich setting project and started behaving like a candidate live-world platform.
The important shift here was recognizing that contracts, factions, incidents, and the world itself should not remain static. Governance, persistent world pressure, and afterlife logic all started to move from narrative ideas into system design.
This version exposed the scale problem. Once live-world behavior became part of the vision, the project needed stronger service separation, monitoring, async thinking, and more explicit operational boundaries.
This version represents the point where deployment and service coordination started to matter in a real operational sense. It acts as the proving ground before the new V1.0 rebuild takes over.
The main concern here was not inventing more features. It was validating whether the project could be run, staged, and reasoned about as a real deployed system. This is where environment boundaries and service coordination became far more important.
Without a version like this, V1.0 would risk being planned in a vacuum. V0.6 is the operational memory that informs the later rebuild: what deployment friction exists, where auth and service shape matter, and what the next architecture must improve.
Security Posture
V1.0 security is being shaped around role separation, protected delivery, private internal services, and stronger resistance to hostile access. The security model is being built as part of the platform architecture so that gameplay, governance, deployment, and monitoring evolve with clearer boundaries from the start.
By V1.0, ValkenRoot is no longer only a game concept or a content-heavy design exercise. It is becoming a real application platform with multiple user types, privileged roles, protected data, CI/CD delivery, and internal operational surfaces. That makes security part of the architecture story rather than a separate later concern.
This section shows how the project is being shaped to withstand misuse, privilege abuse, and hostile access while still preserving the intended Player, Dungeon Master, and Overlord workflows.
Players should be able to reach their own account, character, progression, campaign-linked gameplay surfaces, and approved public reference content.
They must not be able to reach importer tooling, Overlord governance, monitor administration, unrelated campaign data, or infrastructure-facing controls.
This boundary matters because player access is the most numerous and most exposed surface in the system. If it is not tightly scoped, normal gameplay identity can become an entry point into privileged platform behavior.
Dungeon Masters should be able to manage the campaigns they control, inspect campaign-linked characters, and operate encounter or campaign-specific tools.
They must not receive global world-governance powers, unrestricted importer access, or direct control over broader platform operations.
The key security design choice is that DM authority is campaign-scoped rather than global. A Dungeon Master is powerful inside the campaigns they run, but that should never collapse into system-wide administrative authority.
Overlord is treated as a privileged application role with authority over world governance, release-aware content direction, and high-level intervention surfaces.
Even then, Overlord should not automatically imply infrastructure administration, unrestricted CI/CD access, or direct database control without separate operational privileges.
This separation is deliberate. Overlord is the highest application-governance role, but it is still not meant to be a blanket superuser over hosting, secrets, data stores, or deployment systems.
Attackers are assumed to probe public APIs, replay tokens, enumerate identifiers, abuse privileged endpoints, and look for weak staging or default credentials.
The response is deny-by-default access, stronger edge filtering, rate limiting, private service networking, and enough telemetry to expose abuse early.
This card makes the threat model explicit: ValkenRoot assumes public-facing surfaces will be probed, so the framework is being shaped to resist enumeration, privilege escalation, and staging mistakes rather than trusting that those things will not happen.
The current design is strongest in role modeling, identity direction, and planned control boundaries.
It is still immature in applied controls such as strict CORS, route-level auth enforcement, hardened validation defaults, rate limiting, and importer protection.
In portfolio terms, this means the project already understands what needs to be protected, but some of the live defensive controls still need to be fully enforced in code and deployment.
ValkenRoot already has a good architectural understanding of assets, actors, and operational surfaces.
The main gaps are in Protect, Detect, Respond, and Recover: security controls, abuse detection, response playbooks, and restore-tested recovery are not yet fully implemented.
The strongest current position is in Identify, because actors, services, and system roles are already being mapped clearly. The weaker areas are the operational disciplines that must come with an exposed or semi-exposed platform.
The project is strong in planning and secure-by-design intent across the software lifecycle.
It still needs security to become a real SDLC gate through CI checks, environment separation, release controls, and operational policy enforcement.
This is an important distinction for V1.0: the planning is secure-by-design in intent, but the secure development lifecycle still has to be turned into concrete engineering rules and deployment gates.
The architecture is ready for practical hardening through configuration baselines, secrets discipline, and vulnerability management.
The biggest missing pieces are dependency scanning, secure configuration baselines, and stronger handling of credentials, internal service exposure, and monitoring.
This is the most practical hardening lens for the current stage because it translates architecture into service baselines, vulnerability management, and safer defaults that can actually be enforced during delivery.
These are the highest-priority weaknesses because they sit directly on the boundary between the intended role model and the real attack surface. They represent the difference between good architectural intent and a launch-ready defensive posture.
The hardening path is to put Cloudflare edge protection in front of the public surface, enforce strict role boundaries inside the API, keep internal services private, add GitLab security gates to delivery, and feed security telemetry into the monitoring stack.
That gives ValkenRoot a practical launch-ready baseline while preserving the longer path toward richer world systems, operations tooling, and governance layers.
The emphasis is on realistic hardening rather than overbuilding: secure the edge, secure the roles, secure the pipeline, secure the internal services, and make abuse visible enough that the team can respond early.
