Forge-Navi & Token-Navi | Joshua Phillips

The production repositories are private because they contain working project data, internal tooling, generated assets, and implementation-specific knowledge. This page documents the engineering approach and the systems I built without publishing those internals.

The Problem

Creating custom content at scale was easy to get wrong in subtle ways. A script could parse successfully and still behave incorrectly in-game. Tokens could be missing or mismatched. Naming collisions, packaging mistakes, stale compatibility assumptions, and upstream engine changes could turn a large import into a long manual debugging session.

I built Forge-Navi to make the scripting side repeatable and testable, then split visual asset production into Token-Navi so each system could have a clear responsibility.

System Design

Forge-Navi

Owns card and token semantics, Forge scripting, validation, repair workflows, compatibility knowledge, dependency checks, project state, and final release gates.

Token-Navi

Owns the visual-production pipeline for required token and card faces, including rendering, structural QA, approval tracking, and verified delivery back into the release pipeline.

Raw Set → Script / Semantic Analysis → Static + Behavioral QA → Known-Failure Classification → Grouped Repair → Token Dependency Handoff → Visual Production + Approval → Verified Import → Full-Set Regression Audit → GOLD Release Gate

What I Built

Semantic Validation

Validation goes beyond syntax. The core rule is to prove that a card behaves correctly, not merely that its script parses.

Reusable Knowledge

Verified patterns, known engine traps, prior fixes, and failure classes are retained so later sets can reuse proven solutions instead of rediscovering the same bugs.

Release Gates

Work moves through explicit audit states rather than being called finished early. Final assembly is treated as a candidate until an independent full-set audit passes.

Token Handoff Contract

Forge-Navi describes exactly what a custom token needs. Token-Navi produces and approves the visual, then returns immutable assets for verified packaging.

Upstream Compatibility

Current Forge behavior is tracked separately from stable project policy so engine changes can be absorbed without rewriting the whole system.

Automation & Tooling

The workflow uses scripted installers, validation tools, project-state tracking, repeatable repair passes, packaging checks, and regression-oriented QA.

Scale

The system has been used across a working library of more than 5,000 custom card scripts, hundreds of token definitions/assets, and dozens of custom sets. That scale is what pushed the project from ad-hoc scripting into a real production pipeline with checkpoints, repair queues, dependency contracts, and release criteria.

What This Project Demonstrates

PowerShell and scripting automation
Debugging and root-cause analysis
Static, semantic, and regression-oriented QA
Stateful production workflows and release gates
Dependency and asset-pipeline design
Compatibility work against an actively changing upstream project
Separating responsibilities between cooperating tools
Turning repeated manual failures into reusable automation

Why the Repositories Stay Private

The portfolio is intentionally the public-facing layer. The production repositories include internal knowledge bases, active project state, generated content, runtime assets, and work-in-progress tooling. Keeping those private lets me show the engineering decisions and results without publishing material that does not belong in a public showcase.