Phlosion | Software Product Lab

Software product lab

Phlosion is a software product lab for full-stack services, local AI systems, desktop tools, web surfaces, and C++ game/runtime work. The lab keeps the software itself in focus: what it does, how it is built, and where each build could go next.

Explore products View demos

Apps: Web + mobile
AI: Local systems
Tools: Desktop workflows
Games: Playable prototypes
Engines: Runtime systems

Products

Software experiments built like products.

Each build starts from a real workflow or learning goal, then follows through into architecture, interface design, testing, packaging, documentation, and release paths.

Active build

Pokemon Go Nexus

Collection + trade app / Full-stack product platform

An active full-stack Pokemon Go platform for managing collections, browsing variants, finding trainers, proposing trades, and syncing updates across web/mobile clients and backend services.

Frontend

React
TypeScript
Vite
Expo
Vitest

Backend

Go
net/http
chi
Fiber
Node
Express
MongoDB
Kafka
MySQL
Postgres/PostGIS

Delivery

Docker
NGINX
GitHub Actions

Product scope

Nexus is built as a product system, not a single app screen: collection management, public trainer views, search/list/map discovery, trade lifecycle flows, cached Pokemon data, service-worker batching, offline cache hydration, Kafka-backed persistence, SSE updates, and production-oriented deployment work all sit in one monorepo.

Workflow and surface

Delivery surface: React/Vite web app, Expo mobile path, auth, Pokemon API, users/search/events/location services, receiver/storage pipeline, and NGINX routing.
User/workflow fit: Collection and trade software needs rich variant modeling, trusted account state, location-aware discovery, offline-friendly local storage, live sync, and deployment paths that can support hosted communities.

System behavior

Product surface: The web app covers registration/login, account settings, collection browsing, Pokédex and owned-instance overlays, tag buckets, public trainer collections, search, map results, trade proposals, and trade status review.
Sync model: Client edits update local state, persist for offline recovery, queue receiver batches, flow through authenticated Go ingestion into Kafka/MySQL, then return through SSE and missed-update readers.
Service topology: Auth runs on Express/MongoDB; Pokemon data uses Go net/http plus chi over SQLite; users/search/events/receiver/storage/location services use Go, MySQL, Kafka, and PostGIS behind NGINX route namespaces.
Delivery discipline: The repo includes Docker/compose service boundaries, GitHub Actions CI/deploy workflows, Vitest and browser-proofing paths, service tests, health/readiness probes, metrics, Trivy/SBOM checks, and deployment notes.

Where next

Next build: The strongest next step is frontend product work: turning the existing service depth into a smoother collection, discovery, and trade-planning experience.
Expansion path: The backend can keep growing through paired service and interface features, such as community matching, notifications, calculators, and ranking signals.
Blocker: The backend is close to production-ready; the harder remaining work is time and a UI/UX layer that makes the complex data and trade flows feel clear enough to trust.
Release path: If the product becomes production viable, the deployment target should move from local server hardware toward cloud hosting with the existing CI/deploy workflow shape.

Codebase signals

Frontend workspace: The frontend is a workspace with React 19, TypeScript 6, Vite 8, Expo mobile work, shared contracts, shared UI tokens, SSE context, and Playwright/Vitest coverage.
Mobile path: The Expo React Native app consumes shared contracts and has shipped vertical slices for auth, trainer search, Pokemon catalog, collection editing, search, trades, account/register, and mutation sync.
Backend services: The backend combines the cached Go Pokemon API, hardened auth, user overview/public snapshots, trade/wanted search, location autocomplete/geocode/reverse lookup, receiver ingestion, storage persistence, and events streaming.

View demo View repository

Active build

WinRift

Game analytics app / Full-stack analytics platform

A full-stack League of Legends analytics rebuild for matchup-specific builds, champion guides, live match scouting, summoner profiles, tier lists, and win-condition analysis.

Frontend

React
TypeScript
Vite
TanStack Query
Vitest

Core analytics

Go
net/http
ClickHouse
Riot API

Delivery

Docker
GitHub Actions

Product scope

WinRift collects Riot match and timeline payloads, normalizes builds and matchup context into ClickHouse, serves precomputed analytics through a Go API, and presents practical champion, rune, item, summoner, and live-game views in a React app.

Workflow and surface

Delivery surface: React/Vite web app, Go API, Riot-aware collector worker, monitor process, ClickHouse schema/read models, Docker Compose stack, and private-LAN deployment flow.
User/workflow fit: Game analytics software needs trustworthy collection, patch-aware storage, rate-limit discipline, fast read models, and UI that explains matchup-specific choices without pretending live data is deterministic coaching.

System behavior

Product surface: The app supports universal champion/Riot ID lookup, champion guides, role-aware build advice, tier lists, summoner profiles, live match scouting, and win-condition reads.
Collection model: A Go worker collects Riot match, timeline, rank, and alias data with per-platform budgets, Retry-After backoff, auth-failure exits, and raw payload retention for current and recent patches.
Analytics store: ClickHouse stores raw payloads, normalized participants, matchups, events, and summary/read-model tables so older raw data can be archived while app-facing trends stay available.
Operations loop: Docker Compose runs ClickHouse, API, worker, monitor, and web surfaces; GitHub Actions builds core images, deploys to a private server, and keeps monitor/alerting paths documented.

Where next

Next build: The strongest next step is validating worker health, email alerting, and collection quality against the production-style private server setup.
Analytics path: Tier-list and win-condition scoring should keep being tested against larger samples so the read models stay useful instead of merely decorative.
Frontend path: More smoke/e2e coverage around live-match and champion-guide flows would protect the most user-facing routes as the analytics surface grows.
Release path: Before any public API deployment, the project needs tighter public access policy, stronger auth boundaries, and a clear stance on Riot-owned assets and live-game UX.

Codebase signals

Web workspace: The frontend uses React 19, TypeScript, Vite, TanStack Query, Vitest, Testing Library, and route performance smoke tests for champion, summoner, tier-list, and live-match flows.
Go core: The core workspace owns the API, collector worker, monitor, patch archive tool, Riot proxying, static-data cache, analytics endpoints, and ClickHouse integration.
Docs and safety: The repo includes architecture, Riot API behavior, data dictionary, collector runbook, ClickHouse queries, patch lifecycle, storage policy, policy-safe live UX, public readiness, and deployment notes.

View demo View repository

Active build

Track Extract

Audio separation app / Desktop AI workflow engineering

A local-first desktop app for importing audio, choosing curated stem-separation workflows, running offline AI renders, previewing stems, and exporting DAW-ready files.

Desktop shell

React
TypeScript
Vite
Tauri
Rust

ML engine

Python
Demucs
audio-separator
FFmpeg

Workflow data

JSON
Vitest
GitHub Actions

Product scope

Track Extract wraps stem-separation models in a practical desktop workflow: audio import, project/session management, curated workflows, model registry state, background jobs, progress events, local previews, and stable export naming all sit around a Python-owned engine.

Workflow and surface

Delivery surface: Tauri 2 desktop shell, React/TypeScript interface, thin Rust command bridge, Python ML engine, model/workflow registries, job events, stem preview, and export paths.
User/workflow fit: Local ML audio tools need predictable project folders, curated model choices, safe installs, cancellable offline jobs, progress feedback, and exports that fit real DAW workflows.

System behavior

Producer workflow: The app supports drag/drop and file-picker import, TrackExtract Projects folder creation, workflow/model selection, queued/preparing/running/complete/failed/cancelled job states, stem preview, and export formats.
Engine boundary: Rust stays intentionally thin: it handles desktop plumbing, command/event forwarding, process cancellation, local media URLs, path resolution, and the bridge to the Python engine.
Separation providers: Python owns Demucs, audio-separator, and stub/test render providers, plus project/session state, jobs, installs, catalog sync, output folders, and model registry semantics.
Workflow depth: The registry covers quick vocal splits, full six-stem separation, instrument-only renders, custom workflows, and multi-step vocal cleanup chains inspired by UVR-style processing.

Where next

Next build: The key release step is packaging the Python engine cleanly so non-developer desktop installs can run the separation workflow without manual environment setup.
Model path: The model catalog can grow into more curated installable workflows, especially around audio-separator discovery, UVR references, source links, and license-aware install states.
Workflow path: Batch processing, resumable jobs, stronger cancellation behavior, and DAW export templates would turn the prototype into a smoother studio utility.

Codebase signals

App shell: The UI is a React 19 and TypeScript Vite app inside Tauri 2, with browser development mode sharing the same local Python engine state as the desktop window.
Python package: The canonical engine is packaged as trackextract_engine and exposes python -m trackextract_engine for the Rust bridge and future CLI/service paths.
Verification: The local check path covers registry generation/validation, workflow validation, Python engine tests, frontend tests, production frontend build, Rust tests, linting, and formatting.

View demo View repository

Engine prototype

Pokemon Autochess

Game/runtime prototype / C++ systems learning lab

An engine-first C++20 auto-battler prototype with SDL2 platform work, OpenGL and Direct3D 12 rendering, Lua gameplay, VFX tooling, content pipelines, and tests.

Runtime core

C++20
CMake
vcpkg

Platform + rendering

SDL2
OpenGL
Direct3D 12

Gameplay data

Lua
sol2
JSON

Product scope

Autochess is a learning-focused runtime systems project: the current game is one client of reusable engine work around board state, combat simulation, renderer parity, scripting, data cooking, tooling, and packaged tests.

Workflow and surface

Delivery surface: Game loop architecture, combat simulation, scripting, rendering experiments, tests, and tooling.
User/workflow fit: A game prototype needs fast iteration, deterministic runtime behavior, renderer flexibility, content validation, and tests that keep experiments honest.

System behavior

Engine layers: CMake targets separate engine core, platform, rendering, runtime, VFX support, game objects, executable, tools, tests, and aggregate builds.
Rendering: The project maintains OpenGL and Direct3D 12 backend work with shared presentation rules, shader/resource caches, model loading, and smoke paths.
Gameplay runtime: GameRuntime and GameSession wire placement, combat, rounds, shop, movement, bench/cards, unit interaction, UI, battle feed, and health bars.
Tooling: VFX previewers, JSON config validation, content cooking, packaged bundles, release scripts, installer support, and headless tests support repeatable iteration.

Where next

Next build: The prototype needs more playable content: additional 3D Pokemon models, attacks, mechanics, VFX, and staged encounters that move closer to a Kanto-inspired progression.
Blocker: The main constraint is the 3D world, VFX, and content layer. The runtime has useful systems, but a complete game needs authored stages, richer assets, visual feedback, tuning, and playtesting.
Product path: The right direction is to keep engine work tied to visible gameplay stages so rendering, scripting, combat, and VFX improvements stay grounded in playable behavior.

Codebase signals

C++ stack: The vcpkg manifest includes SDL2, SDL2_ttf, glad, GLM, Lua, sol2, nlohmann-json, fastgltf, and stb.
Game scripting: Lua scripts drive combat timing, shop roll logic, UI/debug events, state flow, phase transitions, and tuning overrides.
Test posture: The repo includes headless smoke tests, invariants, optional GL smoke draw, optional runtime smoke, CI build/test/data validation, and debug state snapshots.

View demo View repository

Host-run system

Jarvin

Local AI system / Model-adjacent product engineering

A private host-run assistant platform around local models, voice workflows, memory, safe tools, integrations, planning, and shared desktop/mobile clients.

Host service

Python
FastAPI
SQLite

Local AI loop

llama.cpp
Ollama
Whisper ASR

Client surfaces

React
Tauri

Product scope

Jarvin is not a custom foundation model; it demonstrates the product software around local models: voice, memory, tools, integrations, and proactive assistant behavior that can be evaluated and owned.

Workflow and surface

Delivery surface: Assistant clients, tool routing, local model workflows, memory, voice loops, and host orchestration.
User/workflow fit: Useful assistants need privacy boundaries, inspectable tools, persistent memory, and clients that make local model work feel practical.

System behavior

Local host: A FastAPI service started from the trusted machine owns ASR, local LLM routing, TTS, persistence, integrations, and frontend serving.
Voice loop: Remote phone voice captures microphone audio, uploads it for host transcription, routes the turn through chat/tools, and plays reply audio on the client.
Client surfaces: A shared React shell powers the browser app, Tauri desktop app, and Tauri Android shell without splitting product UI into separate codebases.
Tool domains: Deterministic planners and tools handle weather, reminders, routines, workspace/repo tasks, web research, calendar actions, and daily briefs.

Where next

Next build: The next meaningful work is research: better planning loops, clearer tool-evaluation boundaries, and stronger tests for instruction following.
Blocker: Local model quality is the main constraint. Stronger GPUs would make larger local LLMs practical and reduce the amount of product logic spent compensating for weak instruction following.
Product path: The platform can become more useful by tightening the assistant loop around reliable memory, voice behavior, and controlled tool execution rather than chasing novelty.

Codebase signals

Assistant boundary: Natural-language flexibility is routed through constrained planners so side effects can stay inspectable, confirmable, and host-controlled.
Persistence: SQLite stores conversation, profile, reminder, and routine state on the host, keeping clients thin and replaceable.
Local model layer: llama.cpp and optional Ollama backends sit behind a runtime router, with Whisper ASR and local TTS completing the voice path.

View demo View repository

Packaged release

Cipher Snagem Editor

Desktop tooling / Cross-platform support tooling

A Windows-first, cross-platform .NET/Avalonia remake of legacy Pokemon Colosseum and XD modding tools with safe workspace flows and release packaging.

Desktop app

.NET 10
AvaloniaUI
C#

Game data

GameCube ISO
Binary formats

Release targets

Windows
Linux
Release packaging

Product scope

Cipher studies prior Swift/macOS tooling and turns that preservation work into release-grade support software: a modern desktop UI, safe ISO workspace boundaries, parser/codec coverage, documentation, and downloadable artifacts.

Workflow and surface

Delivery surface: Avalonia UI, parser/codec systems, safe workspace flows, tests, packaging scripts, and releases.
User/workflow fit: Community tools need familiar workflows, Windows support, safe file boundaries, documentation, and releases that non-authors can actually run.

System behavior

Release targets: One shared codebase ships separate Colosseum Tool and Pokemon XD: Gale of Darkness tool targets for the two legacy workflows.
Parity focus: The project studies original Swift/macOS tools, storyboards, parsers, binary formats, and behavior to preserve familiar editor workflows.
Data safety: The repo excludes game files and centers safe ISO workspace flows, generated artifacts, local fixtures, and clear legal/data hygiene boundaries.
Distribution: GitHub Actions-backed release packaging covers Windows portable zips, Ubuntu/Debian packages, Linux portable archives, and repeatable release workflow notes.

Where next

Current state: The core scope is essentially complete: a Windows/Linux-friendly GUI path for the original Swift/macOS editor concept, with packaging and release hygiene.
Future path: A later, separate version could become a deeper modding suite for authoring-heavy work like VFX, Pokemon models, animations, and richer game-data editing.
Blocker: That expansion is a different product scope, with more reverse-engineering risk and more content-authoring complexity than the parity-focused editor line.

Codebase signals

.NET desktop stack: The app targets net10.0 with Avalonia UI, Fluent styling, CommunityToolkit.Mvvm, nullable C#, and shared editor libraries.
Verification: Tests cover codec, archive, schema, parity, texture, script, patching, UI contracts, and smoke/probe workflows.
Project scope: The README explicitly frames this as the stable legacy-editor parity line, not a general-purpose authoring suite.

View demo View repository

Pokemon- and League-related projects are portfolio, learning, analytics, and community-support work. They are not affiliated with, endorsed by, or sponsored by Nintendo, The Pokemon Company, Niantic, Riot Games, or related rights holders.

Site builds

The web surfaces are part of the lab.

The resume site and Phlosion itself are treated as software work too: brand presentation, content modeling, metadata, deployment, responsiveness, and clear navigation paths.

Live site

Resume site build

AdamWentworth.ca

A personal resume site with education, experience, skills, selected projects, SEO metadata, sitemap output, and PDF resume access.

Brand surface: Adam Wentworth brand system
Delivery surface: Static Astro site, structured resume content, downloadable PDF, responsive layout, and deployable build output.
User/workflow fit: A resume surface has to stay fast, direct, scannable, and easy to connect back to experience, project work, and contact paths.

Astro
TypeScript
CSS
Vercel

Open site

Live site

Software product lab surface

Phlosion.com

This product-lab site collects software builds with brand assets, product constraints, demo surfaces, repository evidence, and social metadata.

Brand surface: Phlosion brand system
Delivery surface: Next.js App Router site, Tailwind-backed styling, optimized media, generated social card, and responsive showcase sections.
User/workflow fit: A product-lab site has to make varied work feel coherent without flattening the technical depth or product direction of each build.

Next.js
TypeScript
Tailwind CSS
Vercel

Open site

Demos

The products need to be seen in motion.

This is the lab bench for product footage, screenshots, interface flows, release artifacts, and runtime loops. Some views use captured product media; others stage the behavior each build is designed to show.

Active build

App walkthrough

A walkthrough surface for browsing a collection, searching Pokemon, inspecting map results, and reviewing account workflows.

Open collection
Search and map
Inspect workflows

Collection workspace: Browse variants, owned instances, caught/trade/wanted states, and tag-driven views.
Search and map: Switch between trainer search, Pokemon filters, list results, and map-backed discovery.
Workflow depth: Move through instance overlays, account lifecycle, edit surfaces, and trade-planning paths as the product grows.

Open repository

App demo

Collection

Favorites-first collection browsing with owned-instance overlays and live Pokemon artwork.

Screens

Contact

Resume, GitHub, and email.

AdamWentworth.ca covers background and experience. Phlosion keeps the software builds, product direction, and implementation evidence in focus.

Email Resume site GitHub