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

Manage a Pokemon Go collection, plan raid and Max Battle teams, compare PvP options, find nearby trainers, and organize trades in one connected workspace.

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

The app connects variant and instance tracking with a regional Pokédex, raid counters, Max Battle planning, PvP rankings and team tools, community rankings, trainer profiles, friends, and shareable Trade Boards. Local persistence and queued sync support collection work between connections.

Workflow and surface

Delivery surface: React/Vite web app, Expo React Native preview, shared product logic, and services for accounts, Pokemon data, discovery, trades, and live sync.
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: Collection tags and instance editing, a regional Pokédex, raid and Max Battle planners, PvP rankings and IV analysis, trainer search and maps, community rankings, trade preferences and activity, shareable boards, friends, and account security.
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

Native validation: Build the current native preview and complete physical-device route, navigation, performance, and trade workflow checks before changing the mobile release default.
Product refinement: Refine collection, discovery, and trade workflows using the existing raid, Max Battle, PvP, and community tools as part of the complete trainer journey.
Evidence boundary: The showcase runs the migration branch’s responsive web interface against live services using a real trainer account. It pairs overall rankings with the trainer’s own Pokémon; private profile and account fields are hidden. Native release checks remain separate.
Release path: Keep web delivery and native rollout decisions tied to their own verified builds, with updated capture coverage and deployment checks before each release.

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 native migration branch implements the main app routes with Expo React Native and shared product logic. Browser parity and workflow checks support the preview; physical-device, standalone-build, and iOS release checks remain open. The production mobile default remains the WebView shell.
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

Active build

HAVEN

Home infrastructure security / Security-focused systems product

A self-hosted security observatory for understanding trusted computers, private-network services, managed appliances, browser posture, and account hygiene.

Hub + trust

Go
SQLite
WebAuthn
net/http

Console + desktop

React
TypeScript
Vite
Electron

Endpoints + delivery

Windows
Linux
Docker
GitHub Actions

Product scope

HAVEN centralizes the view without centralizing collection. Native agents observe their own hosts and send bounded, mutually authenticated reports to a Go hub, while the console separates verified protection, expected services, findings, and unavailable evidence instead of compressing them into an opaque security score.

Workflow and surface

Delivery surface: Go and SQLite hub; unprivileged Windows and Linux agents; responsive React console; hardened Electron client; and a resource-bounded Docker deployment path.
User/workflow fit: Security posture has to stay explainable and privacy-bounded: report only evidence HAVEN can verify, keep credentials and payloads out of collection, and never turn constrained owner actions into an arbitrary remote shell.

System behavior

Cross-platform posture: Unprivileged Windows and Linux collectors report explainable update, firewall, encryption, boot-integrity, remote-access, listener, and agent-health evidence.
Service-aware networking: HAVEN distinguishes enrolled peers, observed private endpoints, expected listeners, service drift, and grouped Internet relationships without packet capture or retained remote-endpoint history.
Broader security context: Managed-appliance health, browser hardening, privacy-bounded cookie-domain metadata, and an encrypted account-hygiene notebook bring related owner decisions into one surface.
Controlled response loop: Server-classified alerts, acknowledgement and snooze controls, generic encrypted push messages, diagnostics, backups, and constrained passkey-confirmed actions favor review over alarmism.

Where next

Pre-release hardening: Continue threat-model review, upgrade and recovery testing, schema-compatibility work, and long-running observation tests before treating HAVEN as dependable infrastructure.
Distribution path: Finish repeatable signing, installation, update, and rollback paths for the hub, Windows and Linux agents, and desktop client.
Coverage without overreach: Broaden useful endpoint and appliance evidence only where it remains read-only, explainable, portable, and inside the documented privacy boundary.

Codebase signals

Explicit trust boundaries: The design documents what HAVEN can verify, what stays owner-reported, and what it intentionally refuses to collect or control.
Hardened surfaces: TLS 1.3 mutual authentication protects agent reports, sensitive owner state is encrypted at rest, and the Electron client exposes no Node, filesystem, shell, preload, or IPC bridge.
Verification discipline: Go and frontend invariant tests, race detection, coverage gates, vulnerability checks, signed release inputs, bounded fixtures, and a synthetic-only portfolio mode support safer iteration.

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

Active build

BinderLedger

Collection + market app / Full-stack self-hosted product platform

A condition-aware catalog, collection, watchlist, market, and assisted-recognition platform for legacy trading cards, beginning with English Pokemon printings from the Wizards era through the EX era.

Universal client

Expo
React
TypeScript
TanStack Query

API + data

Go
net/http
PostgreSQL

Vision + delivery

Python
OpenCV
Tesseract OCR
Docker
GitHub Actions

Product scope

BinderLedger treats a collectible as more than a card name. Set, edition, finish, language, grading state, and condition remain explicit across catalog search, collection records, watchlists, market history, and scan candidates, all behind a universal Expo client and a small-server Go/PostgreSQL platform.

Workflow and surface

Delivery surface: Universal Expo client for web, iOS, and Android; Go JSON API; PostgreSQL catalog; ingestion workers; OpenCV/Tesseract recognition; and resource-conscious Docker operations.
User/workflow fit: Collector software must distinguish exact printings and conditions, preserve source and price quality signals, stay inside provider quotas, protect private card media, and make uncertain recognition results reviewable.

System behavior

Exact-printing catalog: Catalog records preserve set, edition, finish, language, variant, and card numbering so distinct printings are not collapsed into one result.
Condition-aware market: Near Mint, Lightly Played, Moderately Played, Heavily Played, and Damaged observations remain separate, with movement snapshots plus stale and thin-data indicators.
Collector workflows: The responsive client covers catalog and set browsing, card details, collection state, printing- or set-level watchlists, market rankings, movers, and native camera capture.
Assisted recognition: A Python worker combines perspective correction, image features, and OCR to rank verified candidates while keeping final card confirmation with the collector.

Where next

Release boundary: Accounts, ownership, named lists, and isolated staging need to land before the current trusted-network API can become a wider multi-user product.
Catalog path: Continue the approved pre-Diamond-and-Pearl catalog expansion while preserving provider budgets, exact identifiers, condition history, and explicit data-quality signals.
Recognition path: Evaluate recognition against trustworthy real-device photographs and resolve provider-plan and card-image rights before broadening distribution.

Codebase signals

Clear system boundaries: Expo owns presentation and device capabilities, the Go API owns domain rules and JSON contracts, PostgreSQL is the source of truth, and workers stay behind those boundaries.
Quota-aware ingestion: Collection jobs cache provider responses, resume interrupted work, upsert idempotently, enforce request budgets, and keep raw payloads and downloaded media outside the repository.
Operational discipline: CI verifies the client and Go services, builds and scans deployment images, emits software bills of materials, and deploys commit-addressed containers to a constrained private-network host.

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, Creatures, GAME FREAK, The Pokemon Company, Niantic, Riot Games, any data provider, 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

Explore a real trainer’s collection, trades, and community. Compare overall Raid, Max, and PvP results with My Pokémon in desktop and mobile web layouts; the native app remains in preview.

Collect and discover
Plan your battles
Connect and trade

Collection workspace: Browse variants, owned instances, caught/trade/wanted states, and tag-driven views.
Battle tools: Compare overall recommendations with your own raid attackers, Max Battle parties, complete PvP teams, and caught Pokémon IV ranks.
Trainer community: Find trainers, compare community demand, review trade activity, share a Trade Board, and manage friends and account settings.

Open repository

App demo

Collection

Move from the full catalog to a real trainer’s catches and favorites, then inspect recorded moves, IVs, and catch details.

Screens

Browse 70 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