@royg51

Devlog #8 — QA Sandbox & Production Hardening

CourtQuest is getting closer to the point where I can stop worrying about whether the foundation works and focus on actually building the product.

This week I worked on making testing safer and more realistic by adding an admin-only QA sandbox. Instead of creating random test tournaments in production, admins can now create clearly labeled [QA] tournaments that use the same tournament, bracket, registration, and Google Sheets code paths as real events.

The QA tournaments are private by default, isolated from the normal public tournament listings, and designed to be completely disposable. The teardown process also has multiple safety checks so it refuses to delete anything that isn’t explicitly marked as a QA sandbox tournament.

I also added automated tests covering:

Admin-only access to the QA sandbox
QA tournament creation and deletion
Public/private visibility isolation
Bracket generation
Protection against deleting real tournaments
Database cleanup after teardown
Google Sheets API error handling

The project now has a much stronger CI pipeline as well, with TypeScript checks, linting, unit tests, production builds, and Playwright E2E tests running automatically on pull requests.

One important thing I learned during this process is that passing a local test doesn’t necessarily prove a third-party integration works in production. Google Sheets is a good example: the automated tests can verify the application logic, but the actual organizer-owned Google Sheet flow still needs to be tested against the production OAuth/API environment.

At this point, CourtQuest isn’t “finished” in the sense that there are no more features to build. But the core platform is becoming something I can confidently build on instead of constantly worrying about breaking the foundation.

Next up: finish validating the QA sandbox, run the real production Google Sheets flow, and then get back to shipping actual CourtQuest features.

RoyOS Devlog #3

RoyOS is starting to feel less like a prototype and more like an actual operating system for autonomous work.

This week I focused heavily on reliability and the boundary between Jarvis and the RoyOS runtime.

Jarvis now handles conversational tasks directly through Claude, while RoyOS acts as the durable background worker for longer-running jobs. That separation has made the whole system much more predictable.

I also tightened up the RoyOS bridge and safety system. Jobs are forced into a scratch environment during testing, live writes require explicit authorization, and destructive operations still require human approval.

The runtime is now passing all tests, and the bridge has been heavily regression-tested as well.

The biggest lesson from this stage has been that an autonomous system doesn’t just need intelligence. It needs state, provenance, permissions, retries, observability, and clear failure behavior.

There’s still work to do, especially around getting more complex multi-step objectives to complete reliably, but the foundation is becoming much stronger.

Next up: continuing to push RoyOS toward a system that can take a real objective, break it into durable work, execute it safely, and report the result without needing constant supervision.

Devlog #1

I started Stock Predictor as a project to explore how financial analysis tools actually work under the hood. Instead of trying to build another app that claims to predict stock prices, I wanted to focus on historical analysis, technical indicators, risk metrics, backtesting, and portfolio simulation.

I built the application with a React/TypeScript frontend and FastAPI/Python backend, then gradually added features like historical pattern detection, ETF exploration, comparisons, and an educational Learn section.

A major part of the project has also been making the methodology transparent and avoiding misleading conclusions. The public demo now runs on synthetic data so it can be shared publicly without redistributing market data without the necessary licensing rights.

There is still more I want to improve, but getting the project from an idea into a fully tested, publicly accessible application has been the biggest milestone so far.

Turning NeuroForge into an actual engineering system

When I first started NeuroForge, it was mostly a polished frontend concept for an AI engineering platform. It looked cool, but the optimization was basically a demo.

I’ve been changing that.

The current version actually solves a structural optimization problem. A natural-language engineering brief gets converted into a structured specification, a baseline truss is sized, and NeuroForge runs real finite-element analyses on thousands of candidate designs.

The engine now includes:

2D truss FEA using the direct stiffness method
Cholesky factorization
stress, deflection, self-weight, and Euler buckling checks
constrained evolutionary optimization
simulated annealing and random search
reproducible seeded experiments
experiment history and generation-by-generation results

I also started adding a machine-learning layer. NeuroForge can generate datasets from simulation runs and train surrogate models to approximate the expensive simulation. I added polynomial ridge regression, an MLP, and Gaussian-process regression, along with held-out evaluation using MAE, RMSE, R², and prediction intervals.

The interesting part was that the results were not uniformly great. The surrogate learned mass extremely well, but predicting constraint feasibility was much harder. That gave me an actual research problem to work on instead of just another feature to add.

I also added constrained Bayesian optimization and NSGA-II for multi-objective optimization, so NeuroForge can now explore tradeoffs like mass versus compliance and display the resulting Pareto frontier.

The whole thing runs in the browser with the engineering engine separated from the React UI and heavy computation moved into a Web Worker.

Next I’m working on per-member surrogate models and uncertainty-aware candidate screening, which should make the ML system much better at predicting whether a design will actually satisfy the engineering constraints.

Devlog #7

Continued pushing CourtQuest from a polished tournament platform toward something that could actually be trusted to run real events. This session focused heavily on production-readiness, reliability, and security, with extensive testing of real tournament workflows across players, organizers, referees, spectators, and admins. Found and fixed several important concurrency and edge-case issues involving duplicate registrations, concurrent bracket generation, match completion, referee attribution, tournament lifecycle transitions, email behavior, and session/role changes. Also improved observability and performance by strengthening error reporting, adding missing-service alerts, optimizing hot tournament routes, improving live-state polling, and removing unused dependencies.

Enabled RLS across the Supabase databse.

Continued validating the redesigned platform through real rendered production builds instead of relying only on code inspection, fixing additional issues discovered in the process. The interactive tournament archive and history experience was also confirmed as CourtQuest’s main signature feature, using real tournament photography, real results, and an evolving timeline rather than artificial 3D content. CourtQuest is now much closer to a real production tournament operating system, with the remaining work focused primarily on deployment configuration, final production checks, and human-gated launch decisions rather than major feature or redesign work.

Devlog #6

Continued rebuilding CourtQuest into a more complete tournament platform, focusing on improving the experience across the entire tournament lifecycle. Redesigned key organizer, referee, player, and spectator workflows, including live scoring, tournament operations, scheduling, check-in, brackets, and tournament health monitoring. Added new features like tournament duplication, waitlist management, schedule conflict detection, and a tournament attention system to help organizers quickly identify issues. Also introduced new broadcast-style experiences, an interactive tournament history timeline, cinematic tournament moments, and a redesigned homepage experience built around real CourtQuest events and media. Continued improving mobile responsiveness, accessibility, reliability, and overall consistency across the platform while testing everything against real workflows. CourtQuest is becoming a much more complete tournament operating system rather than just a tournament website.

Devlog #5

Continued developing CourtQuest with a focus on strengthening the tournament management experience and making the platform more production-ready. Worked on improving tournament workflows across organizers, referees, and players, while refining how different tournament stages, matches, and results are managed. Continued improving the dashboard experience with clearer data presentation and more useful tournament statistics. Also worked through backend and database improvements to make the platform more reliable as the number of tournaments and participants grows. Spent time testing existing workflows, fixing edge cases, and cleaning up smaller issues across the application. CourtQuest is getting much closer to being something that can actually be used to run real tournaments end-to-end, rather than just a prototype.

Devlog #2

Recently, I have been focused on turning RoyOS into a more capable autonomous agent runtime.

I built out multi-agent delegation, allowing agents to create and delegate tasks to other specialized agents while keeping permissions and delegation depth strictly bounded.

I also improved agent creation and validation, so dynamically generated agents have to pass validation before they can run.

A major focus was reliability and safety. RoyOS now supports persistent runtime state, task recovery after crashes, structured execution events, replanning, and approval states.

I also found and fixed a filesystem security issue involving dangling symlinks that could allow an agent to write outside the allowed directory. I added regression and mutation tests to make sure the fix actually holds.

The test suite has now grown to passing many tests with TypeScript compiling cleanly.

Next, I’m working on getting RoyOS to reliably discover and use the actual agent definitions before moving toward production use.

Devlog #4

Made another large polish pass across CourtQuest with a focus on making the UI feel more cohesive and production-ready. Expanded the new motion system across much more of the application instead of limiting it to the landing page. Added reusable reveal animations, staggered entrances, and smoother transitions for dashboards, authentication pages, registration flows, and organizer views. Continued refining the homepage and CTA section, iterating on the hero composition to improve readability while preserving the photography. Improved consistency across typography, spacing, and visual hierarchy so different sections feel like they’re built from the same design system. Refined organizer and referee interfaces by modernizing presentation without disrupting the underlying tournament management workflows. Reworked organizer tournament statistics into a cleaner dashboard with stronger visual grouping and improved information density. Cleaned up smaller UI details throughout the site, including reducing the prominence of secondary controls that were drawing unnecessary attention. Fixed Content Security Policy configuration so embedded donation forms can load correctly. Continued improving responsive behavior and reducing layout inconsistencies across pages. Overall this session was focused on moving CourtQuest closer to a polished, cohesive sports platform by improving motion, interaction quality, consistency, and overall UX while maintaining a clean production build.

Devlog #3

Been working on CourtQuest and made a lot of progress. Improved the tournament organizer experience with new tools that make player check-in much faster and easier to manage, reducing the amount of manual work during tournament day. Continued polishing the UI/UX across the website with cleaner layouts, better spacing, smoother navigation, and lots of small quality-of-life improvements that make everything feel more intuitive. Added more motion throughout the site with subtle animations, transitions, and a few 3D effects to make the experience feel much more modern and responsive without getting in the way of usability. Also been testing the mobile experience. Still plenty left to build, but CourtQuest is starting to feel like a polished production platform instead of just another tournament website. Excited to keep pushing it forward!

Over the past few weeks, I’ve been continuing development on CourtQuest, a student-built nonprofit tournament management platform designed to make running sports tournaments easier for organizers and more engaging for players. This update has mainly focused on improving the foundation, expanding features, and pushing CourtQuest closer to a production-ready platform.

I’ve been working on a major redesign and refinement pass across the platform, focusing on: Cleaner and more modern UI/UXImproved tournament discovery, Better organizer workflows. More polished dashboards, Smoother interactions and animations, Better mobile responsiveness. The goal is to make CourtQuest feel less like a traditional tournament tool and more like a modern sports platform.

Some of the areas being improved: Tournament creation and management, Registration workflows, Participant management, Standings and rankings, Match tracking, Organizer tools, Tournament analytics. I’m also improving qualification visibility in multi-stage tournaments by adding clearer indicators showing exactly where the advancement cutoff is.

Working on the macropad hardware project by designing and iterating on the PCB in KiCad. Currently fixing issues in the schematic editor and refining component layout. Also starting to route the PCB to prepare for a more complete and manufacturable design.

Set up the core repository and development workflow for RoyOS, an agentic operating system combining a dashboard interface with an automation runtime. Structured the Next.js dashboard project, cleaned up the codebase, and prepared it for deployment.
Connected the project to GitHub and configured version control for ongoing development. Deployed the dashboard to Vercel to establish a live production environment and enable instant previews for future updates.
This session focused on foundational setup, deployment pipeline, and preparing the system architecture for continued development of agent-based workflows and runtime integration.

Built the foundational full-stack structure for CourtQuest, a tournament management platform for community and nonprofit sports organizations. Set up core architecture using Next.js, TypeScript, Prisma, and PostgreSQL, and began designing the database models for tournaments, users, roles, and matches.
Implemented early tournament logic including bracket structure planning, scheduling flow design, and groundwork for live scoring and match tracking. Started building role-based access for organizers, referees, and players, along with initial dashboard layouts for managing tournaments.
Worked on authentication flow, backend API structure, and core data relationships to support registrations, payments, and tournament creation. Continued iterating on UI components and system design to support a scalable, end-to-end tournament platform.

Started working on my macropad project!