DEV Community: Mike “Demo” Demopoulos

Did It Move? An ambient haunting that costs $6.12 an hour, so I made it cost cents

Mike “Demo” Demopoulos — Sat, 31 Oct 2026 03:06:01 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Did It Move? is an ambient haunting designed for the biggest, dumbest screen in the house: the TV.

Open it fullscreen and forget it exists. A cozy living room — fire going, rain on the window, a portrait, a rocking chair, a candle — sits quietly for minutes at a time. Then, for a few seconds, something subtly wrong happens. The portrait's eyes are looking somewhere new. A shadow crosses the window that no one casts. The rocking chair rocks itself, gently, and stops facing the other way.

When it's over, exactly one thing in the room is different from before — and the room's own event log, timestamped, insists nothing happened:

9:42 PM — That picture has hung crooked since October.
10:17 PM — Books fall. Gravity is not a haunting.

The horror isn't a jump scare. It's the argument you'll have with the person next to you on the couch: I'm sure that candle was lit.

Demo

Live demo: https://did-it-move.space.fast/

Try Demo pace in the live demo — bursts arrive every ~15 seconds instead of every 4–7 minutes, because judges, unlike ghosts, are busy.

And here is the full hour the room can haunt, if you have a TV and an evening:

Code

Mike-Demo / did-it-move

Did It Move? — a haunted living room for DEV Hacktoberfest Week 4 'Ghost in the Machine'. CSS room, generative video bursts, and a gaslight layer that denies everything.

Did It Move?

An ambient haunting for smart TVs and large monitors, built for the DEV Hacktoberfest Week 4 challenge — "Ghost in the Machine" (deadline: October 31, 2026, 11:59 PM PDT).

Open it fullscreen on a TV and forget it. A cozy living room — fireplace rain on the window, a portrait, a rocking chair — sits quietly for minutes at a time. Then, for a few seconds, something subtly wrong happens. When it's over, one thing in the room is different from before, and the room's log insists nothing happened at all.

Did the portrait always look toward the sofa? Has that picture always hung crooked? You can't prove it didn't.

Why it isn't just "run a real-time model all evening"

Real-time video models (here: Reactor's xmax-x2-1, a streaming video-to-video model) bill for session time, not for interesting moments. Checked live on 2026-10-28 against Reactor's public…

View on GitHub

How I Built It

The idea vs. the invoice

The obvious way to build this is a real-time generative video model — I prototyped against Reactor's xmax-x2-1, a streaming video-to-video model whose SDK (@reactor-models/xmax-x2-1) lets you feed it a source stream, set a prompt, and re-render the world as it happens. Feed it the quiet room, prompt "the portrait's eyes shift, slowly", and the room haunts itself.

Then I checked the pricing endpoint. Reactor charges $0.0017 per session-second for this model — $6.12 an hour — billed from the moment a session is ready, including while it sits idle, per viewer. My quiet room is idle 99% of the time, by design. The naive version costs:

$48.96 for one Halloween evening on one TV
~$147 a day if you leave it on
an unbounded amount the moment you post a public demo link, because every visitor holds their own GPU session

The whole project became: how do you build an ambient generative piece when generation is priced per second and ambience is priced per hour?

The hybrid: generate the moments, not the room

Idle layer (99% of the time, $0). The room itself is hand-built CSS/SVG — fire, rain, moonlight. It can run on a TV forever for free.
Burst layer (5–8 seconds). A generative session exists only while something is happening: a 120-second hard cap, a non-recoverable disconnect (a recoverable one keeps billing — read the docs, learn from my near-miss), and a daily budget kill-switch. At a ~2% duty cycle, a live evening costs cents.
Public mode ($0 per visitor). The bursts used by the public demo were captured once, during development, and are replayed. The HUD shows each burst's would-be live cost as a shadow price, so the economics stay visible instead of hidden.
Gaslight layer ($0, and the actual joke). The lasting changes — crooked picture, dead candle, turned chair — are cheap DOM state. The most memorable part of the piece costs nothing at all, which is rather the point.

The app itself is vanilla HTML/CSS/JS, no build step, no assets — it has to run in whatever browser a smart TV shipped with. The cost guardrails live in one file, reactor-live.js, and the burst prompts for each event live next to their pre-recorded fallbacks in app.js.

Why Does Open Innovation Matter?

Two honest answers.

The swap test. Because Reactor hosts several models behind one SDK, I could price the closed xmax-x2-1 against the open-weight sana-streaming and longlive-v2 — and they are listed at the identical $0.0017/sec. When open weights cost the same as a closed model, "we can't afford to go open" stops being an argument; the decision becomes about control, longevity, and whether your ambient ghost still works the day a vendor changes its pricing page.

The exit door. The burst prompts are plain text, the room is open code, and nothing in the piece depends on one vendor's session: a burst is a burst whether a hosted model renders it live, a local model renders it later, or — as in the public demo — it was rendered once and kept. Open models and open code are what let a $6.12-an-hour idea become a piece that can live on a TV, in a repo, after the hackathon, for free.

The Spirit of It

The moment it landed wasn't technical. It was the first full run on the TV, when the candle went out during a quiet stretch and the room's log — deadpan, timestamped — explained that the candle had always been unlit. Two people on the couch immediately disagreed about whether it had ever been lit at all. Neither could prove it. The room could. It just wouldn't.

That's the haunting I wanted: not a monster, but a small, polite, well-documented doubt that follows you out of the room.

Prize Categories

Overall

I rebuilt a 7,199-game queer arcade in WordPress in five days, driving Elementor through its MCP. Every prompt is published.

Mike “Demo” Demopoulos — Thu, 29 Oct 2026 02:08:08 +0000

QueerCade is a community vault of LGBTQ+ games. It lived as a work-in-progress site at queercade.mikedemo.dev, and last week I rebuilt it properly in WordPress at queercade.gay: a searchable archive of 7,199 games, an interactive constellation of 876 queer characters and 1,788 connections between them, an emoji oracle that recommends your next game, and member libraries for tracking what you own and what you have played.

The rebuild took five days, October 22 to 27. This week I submitted it to two showcases: the Elementor Showoff (in a day ahead of the deadline) and WP Showoff, where it is now waiting on a hand review.

The 54-second tour (this is also the homepage hero video):

QueerCade — Every Queer Game. One Arcade.

videopress.com

Watch: https://videopress.com/v/E5Apx9SN

The interesting part is how it got built, and I want to be precise about that, because "AI built my website" claims are getting sloppy.

The rules I set

I designed the site myself, in Google Stitch: 13 screens, one design system, no placeholder data in any of them.

The designed pages were built through the official Elementor MCP, on free Elementor only. No Pro license hiding in the stack.
Everything a designed page cannot do lives in a custom plugin I built for the site, QueerCade Connect (v0.46.16 as of this writing): the catalog mirror, the constellation, the oracle, member tracking and personal collections, social sign-in, the works.
Jetpack does the jobs Jetpack is good at: Search, VideoPress, Boost, the newsletter. WordPress core does the rest.
The catalog data still lives in Sanity. WordPress mirrors it; Sanity stays the source of truth.

The receipts

I published the whole build trail in a public Gist: every prompt I sent, plus the site's sanitized WordPress activity log for the build window.

QueerCade build prompts and activity log (Gist)

Numbers from that log:

34,261 activity events across five days (29,324 of them REST API calls)
9 prompts built the first 9 designed pages in a single evening; the first Home composition alone placed 54 elements
Catalog grew 753 → 7,199 games in one approval pass; 3,290 covers sideloaded in 344 batches with 0 errors
Media library metadata finished at 4,245 attachments, zero missing alt text, captions, or descriptions
Schema validation sweep: 7,207 URLs checked, 0 with errors
GTmetrix (Chicago): main pages scoring in the high 80s and 90s for Performance

The constellation, with Ellie from The Last of Us selected:

And the emoji oracle:

The long-form version of the story, with video, is the X article I wrote for the Elementor submission:

// Detect dark theme var iframe = document.getElementById('tweet-2115574081839853866-312'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2115574081839853866&theme=dark" }

What the MCP could not do (the honest friction)

Driving a page builder through an MCP server works better than I expected, and it is not magic. Three things worth knowing if you try this:

Verify persistence, not success messages. The Elementor MCP's element update operations sometimes reported success while the change did not persist. Later design edits rode WordPress REST patches to _elementor_data instead, followed by Elementor's Clear Files & Data, because Elementor serves a compiled render.
A generated revision is not your live page. One MCP pass wrote its hero work into a revision whose round-trip also stripped styles from unrelated elements. The shipped pattern: take the node the MCP generated, splice it into the pristine live document over REST, then clear the cache. Check the diff before anything goes live.
Some fixes belong below the builder. The homepage hero video wanted to preload 41 MB. The builder's settings schema has no preload control, so the plugin rewrites the rendered tag at the PHP output-buffer level (preload="none", load on hover, play on click). Homepage weight dropped from ~43.6 MB to ~2.3 MB.

Every cornerstone page was captured across 9 device and browser configurations before launch, 126 captures in the full matrix:

Watch the build

The five-day build, compressed to 70 seconds:

Six Days. One Vault. — Building QueerCade, Oct 22–27

videopress.com

Watch: https://videopress.com/v/cSIt73FS

And the before and after, template site to arcade vault:

QueerCade Before & After — From Template Site to Arcade Vault

videopress.com

Watch: https://videopress.com/v/kiK3zZxR

The disclosure part

WP Showoff asks every submission how AI was used: AI Generated, AI Assisted, or No AI. I picked AI Assisted, because that is the truth of this build. A human designed it, directed it, wrote the plugin that runs it, and reviewed every change. An AI agent held the mouse for a large share of the page building, and hiding that would be worse than saying it.

If the receipts make one argument, it is this: the interesting question is no longer whether AI helped build a site. It is whether the builder can show their work.

QueerCade is live at queercade.gay. Go find your next game.

I Built a Job Search App That Fights You Back — Because Slow and Steady Is the Only Strategy That Lasts

Mike “Demo” Demopoulos — Wed, 21 Oct 2026 02:13:48 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

The sloth moves at its own pace. It conserves energy. It survives. It has never once refreshed an applicant portal at 2 a.m.

Black Box is a job search app built in the sloth's honour — which means it is a job search app that deliberately slows you down. Every other tool in this space tries to make you faster: more applications, more alerts, more dashboards to check. Black Box does the opposite, on purpose, with mechanics instead of advice:

The Vault. Your application statuses stay shut until one daily opening, and a short breathing pause (in for 4, hold for 4, out for 4) stands between you and the reveal. Once a day turns out to be enough — the statuses are the same whether you check once or twenty times; only the cost to you changes.
A daily application budget. You set a small number. When it's spent, the app stops for the day, and says so plainly: that's the whole job for today; the rest of the day is yours.
A 48-hour draft hold. A role you add today cannot be marked applied for two days. If it still looks right in 48 hours, it was worth applying to. Most impulse applications don't survive the hold — which is the hold working.
A Gemma quality score. Paste a job description and Gemma scores it 1–10 against your stated profile, with its reasons shown. A low score is information, not a verdict.
A calm reframe. Paste a hard-to-read outcome notice. Gemma restates it in plainer words and separates what it actually decided, what it states, what it does not say, and one factual next step. Your original text stays on screen, word for word, next to the reframe — the reframe is labelled, and it never replaces the original.
An application-email inbox. Sign in with email and application messages come into Black Box instead of your regular inbox — and then they wait, like everything else here. Mail is only shown inside the daily vault window; anything that arrives after the window is held for the next one. No pushes, no badges, no 9 p.m. rejection ambush. Open a message and you get its original words first, with the Gemma reframe as an optional second reading. Honest demo note: in this build the sign-in link is simulated — no email is actually sent and no server account exists — and the inbox holds sample messages, so the whole flow can be exercised end to end. The mechanics (mail waits for your window) are real; a production version connects a real mailbox behind the same screens.
A mood check-in on a scale. A slider from Rough to Good — the shape borrowed from Voda's daily wellbeing check-in — with the word you chose read back in plain language and a quiet 7-day trend. It is self-report only; the app never guesses how you feel. No streaks, no judgement. A mark for today, if you want one.
Progress cards. Achievements, but only for the slow behaviours the app exists to protect: saving a first draft to the hold, waiting the full 48 hours, letting a draft go, spending the budget and then actually stopping, reading mail inside the window. Cards record process, never outcomes — an interview is not a card, and nothing earned can be lost. It is a record of restraint, not a scoreboard.

Who gets to be lazier because of this? Anyone in a long job search who is spending their limited energy on checking instead of living. Black Box's whole job is to give that time back.

Demo

Live demo: https://black-box-sy5x.onrender.com (Render Starter plan — always on, no wake-up wait)

Fastest way in: https://black-box-sy5x.onrender.com/demo — a one-click demo account that seeds a week of sample applications, inbox mail, and mood marks into your browser and signs you in as demo@mikedemo.email, so the vault, the reframe, and the progress cards can all be exercised immediately. It's sample data, it lives only in your browser, and the app says so.

The full walkthrough — 100 seconds, breathing gate and all:

And the breathing gate as a standalone minute — the cover sloth, animated, with a guided 4 · 4 · 4:

The demo runs in "Demo mode": hosted Gemma 4, clearly labelled in the interface, because Render has no GPU. Run it locally (instructions in the repo) and the same code calls Gemma on your own machine instead — see below.

Code

Mike-Demo / black-box

Black Box — a job search app that slows you down on purpose. DEV Hacktoberfest Week 3: Slow and Steady. Gemma 4 local-first, deployed on Render.

Black Box 🦥

A job search app that slows you down on purpose.

Live demo: https://black-box-sy5x.onrender.com (Render Starter plan — always on)

One-click demo account: https://black-box-sy5x.onrender.com/demo — seeds a week of sample applications, inbox mail, and mood marks into your browser and signs you in as demo@mikedemo.email, so the whole app (vault, reframe, progress cards) can be exercised immediately. Sample data only; it never leaves your browser.

Built for the DEV Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady — build something with open-source AI that rewards laziness.

Every job search tool tries to make you go faster: more applications, more refreshing, more dashboards. Black Box does the opposite. It is named for the flight recorder — the box you only open when it matters — and for the closed lid it puts between you and compulsive status-checking.

What it does

The Vault — Application statuses stay shut…

View on GitHub

How I Built It

One small Next.js app (App Router, TypeScript, Tailwind). No database. No server accounts. No analytics. Every piece of user data — applications, vault state, budget, mood log, profile, inbox, and the demo session — lives in the browser's local storage, on the user's machine.

The UX was designed before it was built, twice. First I gave Google Stitch this repo plus the DESIGN.md from my open-source happy-code-library (the Web Awesome design system), created the design system in Stitch from that file, and generated the screens — email sign-in, the Today dashboard, the Vault with its inbox, the email reframe detail, and a check-in & progress screen. Then, after using the app for a day, I asked Stitch for redesigns with no design system attached, taking the whole aesthetic from Voda (the LGBTQIA+ wellbeing app) instead. It came back with two — a pastel daylight version and a dusk version — and I picked daylight: the shipped app is rebuilt toward it, with a warm cream background, a soft serif for headlines and greetings, pastel-tinted cards, and one deep indigo for actions. The design exports and both explorations live in the repo under design/. The restyle also replaced the mood emoji with plain words (Rough / Tiring / Neutral / Steady / Good) — plainer is calmer — and a later design pass turned the mood check-in into a gradient scale and added the progress cards, taking the shape of both from Voda's daily check-in and journey cards. The scale's handle is an emoji face that changes expression along the scale — a sloth when the day is unmarked — because one expressive exception earned its place; the words themselves stay plain.

The calm isn't only an aesthetic. The design is checked against Microsoft's Inclusive Design guidance for mental health — the Mental Health Guidebook and its design-pattern cards, which also ship as a Figma plugin. Their three considerations map directly onto the app: Preserve — no push notifications, no badges, no red anywhere, nothing that manufactures urgency; Direct — progress you can see, and exactly one obvious next step on each screen; Customize — a privacy mode you choose per call, and a mood check-in that's a scale you slide rather than a form you fill in. The cards' AI Assistants guidance — keep the person in control, make AI output fact-checkable, never let the tool override the customer — is the same discipline the reframe prompt enforces.

The only server code is two stateless API routes, /api/reframe and /api/score, which call Gemma through a single provider layer (src/lib/gemma.ts) with three paths:

Local — Ollama serving gemma4:e4b on the user's machine. The default, and the private path.
Hosted — the same Gemma 4 weights via an OpenAI-compatible endpoint, for the Render demo. Used only when the user (or the deployment) selects it, and labelled wherever it applies.
Mock — a clearly-labelled placeholder provider so the whole interface can be built and tested with no model present.

The prompts are contracts, not vibes. The reframe prompt forbids the model from changing any fact, softening silence into hope or hardening it into rejection, diagnosing, guessing at the reader's feelings, or adding reassurance the source text doesn't support. If the notice doesn't say something, the model must list it under "what it does not say" — never fill it in. Those rules come from an open-source skill I'd already built for exactly this problem, the mental-health-support skill: transformations are display-only and labelled, originals are preserved, facts stay facts.

The score prompt is just as strict in the other direction: score only against what the profile and the description actually state, name omissions as omissions, no flattery and no predictions.

Why Does Open Innovation Matter?

Because the most sensitive text in a job search should not have to leave your machine to be useful.

An outcome notice, a private profile of what you want next, a log of how the search is going — with a closed API, every one of those has to be shipped to someone else's server before a model can help you read it. With Gemma 4 — open weights, Apache 2.0 — the model comes to the data instead. Black Box in local mode runs the whole loop on the device in front of you, costs nothing per call, works offline, and cannot change its pricing or its terms on you mid-search.

I'll be precise about the limit, because it matters: the public demo can't do that. Render has no GPU, so the demo serves the same Gemma 4 weights from a hosted endpoint, and text you paste there is sent to that provider for the call. The app says so, in the interface, next to the toggle — and the toggle itself only exists because the open weights let one codebase honestly offer both paths. A closed model gives you one path and asks you not to think about it.

The Lazy Payoff

Time for some honesty. I think mental health is something missing from the job search on both sides. The ATS systems are just trying to get through candidates as quickly as possible, while applicants are trying to apply to as many jobs as possible, both using AI to counter the other's use of AI. It's a huge arms race, and it just feels like it's not human anymore.

Since I was made redundant at the end of last month, I've been really feeling this. The idea is to not initially scroll and apply to dozens of jobs a day just because it feels like you're accomplishing something. I came up with this idea after talking with my therapist, but to be honest, I haven't used it because I'm still stuck in that cycle, and it sucks. I think the people who are making these job search boards need to think about the humans on the other side of this process, because treating it as a numbers game is not working, and it's very disheartening.

Prize Categories

Best Use of Gemma — Gemma 4 is the entire intelligence of the app: quality scoring and reframing, run locally via Ollama by default, with the same weights served hosted for the demo and disclosed as such.

Best Use of Render — the whole app, front end and Gemma API routes, deploys as a single Render web service from the render.yaml Blueprint in the repo.

Best Use of GitHub Copilot — the whole repo went through a report-only Copilot code review before submission: every claim in this post checked against the code, every finding filed as a public draft PR, and a human decided what to do with them.

🦥

One hub, 1,332 routes: MigrateMe Universal and the Open Migration Package

Mike “Demo” Demopoulos — Mon, 19 Oct 2026 04:53:43 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

A few days ago I introduced migrateme.tech — an open-source, dry-run-first migration toolkit whose proof path was WordPress (WXR) → Markdown/MDX, validated on a real 44-item run. This week it grew the thing it was always pointed at: MigrateMe Universal, an anything-to-anything content converter, and the first public release of the Open Migration Package (OMP) — an open import/export standard designed so the converter eventually makes itself unnecessary.

One hub, not N×N converters

Every migration tool I have used is a pile of pair-to-pair converters. Add a platform and you owe a converter to and from everything else. Universal refuses that shape: every source parses into one canonical item model, and every destination renders from it. Fifteen source parsers and fifteen destination renderers — WordPress WXR, Markdown/MDX variants, Ghost, Shopify CSV, Webflow CSV, Notion and Medium exports, Sanity NDJSON, Contentful JSON, RSS/Atom, Blogger, canonical JSON, CSV, static HTML — and adding platform #38 costs one parser or one renderer, never both.

A registry that tells the truth

The converter's registry covers 37 nodes: 21 researched platforms (10 AI builders — Replit, Lovable, Bolt.new, v0, Bubble, Softr, Glide, AppSheet, Adalo, DronaHQ — and 11 CMS platforms by market share, WordPress at the top) plus the format connectors. That is 37 × 36 = 1,332 directed pairs, and every pair has its own landing page stating plainly whether the route is Supported, Lossy — with the losses named, not footnoted — or Planned. Every pair also has its own canonical address: lovable.wordpress.migrateme.tech is the Lovable → WordPress route (the path form, universal.migrateme.tech/convert/lovable-to-wordpress, redirects there — no duplicate URLs). The whole index is public, too: sitemap-pairs.xml lists all 1,332 canonical pair URLs.

Honesty is a feature here, and it cuts both ways: when a source platform offers no export at all, the built-in Scanner (lite) discovers what it can from sitemaps, feeds, and structured data — in the browser, respecting robots rules, never pretending to be a full crawler and never going near a login wall.

The pair wheel — all 1,332 addresses in 29 seconds.

The Open Migration Package

The converter is the reference implementation; the standard is the point. An OMP package is a manifest.json (source, items, assets, taxonomy, mappings, provenance, sha256 checksums over every file), a content/ folder of Markdown/MDX with Portable Text bodies, and an assets/ index. There is a published JSON Schema, a validator that returns specific errors instead of vibes, and conformance levels — OMP Reader, OMP Writer, OMP Full — so a platform can adopt incrementally. The ask to every builder and CMS on the registry: implement two translators (to-OMP, from-OMP) instead of N×M converters, and your users can leave whenever they want. That is what an exit door looks like.

The spec lives in the repo at docs/format/open-migration-package.md, the schema and validator in packages/format, and this weekend Universal folded into the main monorepo — packages/connectors/universal for the parsers and renderers, apps/web/universal for the app, and Manifest v2 in packages/core, which generalises the original v1 manifest while keeping every v1 file valid.

Building a new standard — the Open Migration Package in 74 seconds.

Who it's for, and who would pay

The user is anyone whose content is fenced in: a freelancer whose client's site lives on a builder they want to leave, a small agency doing the same migration for the tenth client by hand, a hobbyist community moving off a platform that's shutting down. Migrations are episodic, high-stakes, and currently priced like hostage negotiations — agency line items and per-site SaaS fees for what is, mechanically, a format conversion with a risk report.

The toolkit itself is free and MIT-licensed, and the AI step runs a local open-weight model, so a migration costs nothing to run — that's what makes freemium honest here rather than a trial in disguise. The business model it grows into is a Commons Donation Bundle: when a migration succeeds, the tool inventories the open-source technology it touched — the platform the site came from, the platform it's going to, and the stack the tool itself stands on — and assembles a suggested donation across all three, Humble Bundle–style, with a slider for the amount and the split. Designed, not yet wired: no payments are taken today. A tool that moves people between open-source platforms should feed the commons it depends on.

How the monetization works — the Commons Donation Bundle.

Demo

Try it live: https://universal.migrateme.tech/ — it runs entirely in your browser; nothing you upload leaves your device. Every route is live too, e.g. wordpress.markdown.migrateme.tech for the flagship route, or lovable.wordpress.migrateme.tech for a Lossy one with its losses named. Project home: https://migrateme.tech/

Code

Mike-Demo / migrateme.tech

Open-source AI-assisted CMS migration toolkit. Dry-run-first, local-first WordPress → Markdown migrations via CLI, MCP, web, and agents.

migrateme.tech

Open-source AI-assisted CMS migration toolkit. Dry-run-first, local-first WordPress → Markdown migrations via CLI, MCP, web, and agents.

MigrateMe Universal + Open Migration Package (folded in 2026-10-18)

The anything-to-anything Universal converter and the Open Migration Package (OMP) standard (issue #34) were folded in from the Universal Bolt Forge build:

packages/connectors/universal — 15 source parsers + 15 destination renderers on one canonical hub (no pair-to-pair converters), plus the 21-platform registry with honest Supported / Lossy / Planned labels.
packages/format (@migrateme/format) — the OMP manifest JSON Schema and validator surface; the spec lives at docs/format/open-migration-package.md.
packages/core gained Manifest v2 (manifest-v2.ts): v1 manifests upgrade losslessly, so any registered pair can be described.
apps/web/universal — the Universal web app (standalone Vite app live at https://universal.migrateme.tech).

Setup

Use Node.js 24.21.0 (version in .nvmrc) and pnpm 10.22.0 (pinned by packageManager in the root package.json). Enable Corepack and install…

View on GitHub

packages/connectors/universal — the source parsers and destination renderers (the hub's spokes)
packages/format — the OMP package reader/writer, JSON Schema, and validator
packages/core — Manifest v2, the canonical model everything parses into
apps/web/universal — the browser app: matrix, pair pages, converter, Scanner (lite)
docs/format/open-migration-package.md — the OMP spec; docs/copilot-usage.md — the running log of how the AI builders and reviewers were used, and checked

How I Built It

Universal was built during a Bolt Forge weekend on GLM 5.3 Flash, an open-weight model, driven in narrow single-purpose prompts — big prompts died on the run budget, so the work was sliced until each prompt did exactly one thing. The open model is not decoration: it wrote the parsers, the renderers, the pair-page generator, and the app shell.

Around it, a strict rule: nothing counts as done until it is verified in the synced GitHub code and the live output — AI builders' completion claims included. Every build round went through GitHub Copilot as an adversarial reviewer, not a rubber stamp: it caught a data-loss bug in the OMP asset packaging and an injection hole in WXR parsing before either shipped, and the fold-in PR carried 13 review findings — 12 fixed, one answered as a design point. Accessibility was a from-the-first-prompt requirement, not an audit-week patch: WCAG 2.2 AA targets, keyboard-first flows, aria-live progress, and statuses that are always icon plus text, never colour alone. The whole site family also moved hosting this weekend — migrateme.tech, the converter, and the run-output site now all serve from SpaceFast.

How Copilot was used — and checked — across the whole build.

Why Does Open Innovation Matter?

Because the problem this tool solves is closed-ness. Platforms fence content in with proprietary exports precisely because exit is supposed to hurt. A closed migration API would reproduce the disease: your escape hatch, rented back to you, revocable at pricing-page notice.

Open pieces are what make Universal work, specifically:

The standard is open. OMP is MIT-licensed with a published schema, so a platform adopting it isn't integrating with my product — it's implementing a format its users can verify. I've already opened an interop conversation with Automattic's liberate.sh team, offering an OMP writer and shared testing, in a public issue.
The model is open-weight. GLM 5.3 Flash ran the build at no per-token cost during the Forge weekend, and the toolkit's own AI step is designed to run a local open-weight model — a migration costs nothing to run, which is what makes the free tier honest.
The execution is local. Conversions run in the visitor's browser. There is no server for your content to leak from, no upload to trust anyone with. A closed cloud converter couldn't make that promise structurally — only contractually.
The work is inspectable. Every claim in this post — the 44-item validated run, the review findings, the pair counts — resolves to a public commit, issue, or page. Open innovation is also an audit trail.

If you build a platform: the standard is MIT-licensed, the schema is published, and the reference implementation is right there. Give your users an exit door.

My Agent Session

No DevRelay session for this one — the build's agent work happened in the open on GitHub instead. The sessions are the issue and PR threads: the Universal build was commissioned and tracked in issues (design restyle: #38, homepage: #41), Copilot's review reports live on the PRs (fold-in: #35; the full review report: #37), and docs/copilot-usage.md in the repo is the running session log — prompts, verdicts, and the bugs the reviewers caught, in order.

My First User

Yes — an agency PM I know took an early version for a spin last week, and their feedback steered what v2 became: less "a better WordPress exporter," more "the hub has to be the product." They didn't pay — the tool is free, and the donation bundle isn't wired yet — but a working practitioner telling you your scope is wrong, early enough to fix it, is worth more than a first dollar at this stage.

Prize Categories

Best Use of GitHub Copilot
Best Use of a .tech Domain

What's next: more parsers and renderers down the registry's Planned list (issue #32) · a server/CLI full crawler to sit behind Scanner (lite)'s honesty boundary · OMP adoption outreach to the registry platforms, AI builders first.

Additional Videos

What's next for MigrateMe — the roadmap.

DXS: the Digital Experience Showcase test bed — real sandboxes, real proof runs.

Every Game Is Connected — I Built the Graph That Proves It

Mike “Demo” Demopoulos — Sat, 17 Oct 2026 20:01:18 +0000

Every Game Is Connected — I Built the Graph That Proves It

Recommendation engines are great at telling you what is similar to the game you just played. They are terrible at telling you why two games are connected — especially when the connection runs across studios, decades, and genres.

That "why" bothered me, because it isn't really a fact about either game. Elden Ring and Stardew Valley share almost nothing you'd put in a database row. But there are real paths between them — through other games, through the people and companies who made them, through lineages of remakes and expansions. The connection is a property of the paths, and paths are what graphs are for.

So for Graph Hacks (WeMakeDevs × FalkorDB), I built the Gaming Multiverse Reasoner: pick any 2–4 games, and it traverses a FalkorDB graph of 50,217 games, 84,296 nodes, and 1,023,292 relationships to find the hidden paths between them — then an AI narrates the result, with every claim verifiable by clicking it.

Try it live: https://multiverse.2fy1rnikhcll.us-south.codeengine.appdomain.cloud
Code: https://github.com/Mike-Demo/gaming-multiverse-reasoner
Demo video (2:55):

What it finds

Ask about Elden Ring, Hades, Stardew Valley, and Baldur's Gate III and you get 24 paths in about 2 seconds. Five kinds:

Direct lineage — remakes, remasters, DLC, expansions, versions, shared collection/franchise parents
Company bridges — a studio or publisher whose other games join the pair
Similar-game chains — shortest paths over IGDB's similarity graph
Common neighbours — games IGDB lists as similar to both
Shared threads — a genre, theme, or engine both games genuinely share

Click any path card — or any sentence of the narration, or any node in the graph — and that exact path lights up. There's also a "Surprise me" slot machine that picks four random games, because a system tuned to one lucky demo set is a magic trick, not a product.

The core Cypher is almost disappointingly small. Similar-game chains are one shortestPath:

MATCH (a:Game {igdb_id:$a}), (b:Game {igdb_id:$b})
WITH shortestPath((a)-[:SIMILAR_TO*..4]-(b)) AS p
UNWIND nodes(p) AS n RETURN n.igdb_id, n.name

Every path card in the UI shows the actual query that produced it. If the graph did the work, you should be able to see the work.

Learning 1: Your biggest nodes are lying to you

The first version of this gave worthless answers, and the reason was hubs. Nearly every game in the catalogue is on "PC," and a huge share of them are tagged "Adventure." Route paths through those nodes and everything connects to everything in two hops — technically true, completely meaningless.

So the Reasoner suppresses hubs, mechanically:

Platforms and game modes never appear in paths
Any genre, theme, or engine shared by more than 12,000 games is suppressed ("Indie" and "Adventure" fail this test; "RPG" and "Fantasy" pass it)

The rule is printed in the app header. I think that's the important part: a suppression rule you hide is cherry-picking; a suppression rule you publish is a methodology.

Learning 2: A silent limit will quietly poison your results

Mid-build, I computed game communities — clusters from weighted label propagation over the similarity graph — and the numbers looked off. They were. FalkorDB caps any result set at 10,000 rows, and it does so silently. My first community computation ran on a truncated projection of the graph and I only caught it by counting rows by hand. (My first fix then collapsed the whole graph into one 27,403-member monster community, which is its own lesson: unweighted label propagation over a dense similarity graph needs weights and a size cap. The shipped version weights mutual links ×2, caps communities at 1,500 members, and found 6,234 communities — Elden Ring lands in an 8-game soulslike cluster, which feels right.)

The fix for the cap was paging the projection by ID ranges. The lesson I'm keeping: verify counts against an independent total before you build anything on a query result. A limit that doesn't announce itself isn't a bug exactly, but it is a trap — and it's the first piece of feedback I'd hand the FalkorDB team, along with two smaller things: typed-union relationship patterns ([r:T1|T2|…]) were surprisingly slow on our graph, and the ACL ergonomics around SETUSER could use clearer error messages. None of it stopped the build, and the parts that matter — traversal speed, shortestPath, read-only GRAPH.RO_QUERY with ACL users for a public demo — were genuinely good.

Learning 3: Don't make the AI trustworthy — make it checkable

The narration is IBM watsonx (Granite), and it has exactly one job: explain paths the graph already found. It never picks games, never writes queries, never invents facts. It returns claims as structured JSON, and here's the part I care about: every claim must cite the IDs of the paths it describes. Code validates each citation against the paths FalkorDB actually returned. A claim that cites nothing real is dropped before you ever see it.

And because claims carry path IDs, clicking a claim highlights the path in the graph. The AI doesn't ask you to trust it — it hands you the receipt. If watsonx is down, the app falls back to template explanations built from the same paths and labels them template, because the badge should always say which source you're reading.

Same honesty rule everywhere else: search results are never cached (the millisecond readout in the UI is the server's own measurement for that run — I like watching it), communities are precomputed and labeled precomputed, and SIMILAR_TO edges are IGDB's own data, credited as such. I refused to add invented "inspired by" edges even though they'd have looked great in the demo. An invented edge would have poisoned the whole grounding story.

The rest of the stack, briefly

FalkorDB runs in Docker on a single IBM VPC virtual server (bx2-4x16, us-south). The app is a single-file Python 3.12 program using only the standard library — zero third-party packages — speaking RESP to FalkorDB directly, hosted on IBM Code Engine with min-scale 1 so the demo URL is never cold. The IGDB snapshot (frozen 14 Oct 2026) sits in Cloud Object Storage; the catalogue started as IGDB's entire rated population and grew through critic-only, hyped, newest, and similarity-frontier tiers, plus the full QueerCade catalogue merged in.

The app is also an agent surface, because the track is Agents That Act on Connected Data: it hosts an MCP server with five tools (resolve_game, find_paths, random_games, game_community, narrate), so other agents can reason over the same graph. It scored 18/30 on a Silicon Friendly agent-readiness audit and 100/100 on a Lighthouse accessibility audit — both reports are public in the repo, fails included.

Try it

Bring your own four games — ideally four you think have nothing to do with each other. Those are the fun ones.

Live: https://multiverse.2fy1rnikhcll.us-south.codeengine.appdomain.cloud

Built solo by Mike "Demo" Demopoulos for Graph Hacks 2026 (Track 1 — Agents That Act on Connected Data). Project code is MIT licensed. Disclosure: the application code was written with an AI coding agent under my direction, with every subsystem verified live; narration at runtime is IBM watsonx; the demo video was produced with Pexo from real captures of the live app. Game data is IGDB's; this is a fan/hackathon project, not affiliated with IGDB or any publisher.

Open Source Migration Tool

Mike “Demo” Demopoulos — Wed, 14 Oct 2026 22:10:30 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Every WordPress freelancer I know has a migration story, and none of them are happy. A client wants off their old host, or off WordPress entirely, and somebody has to move ten years of posts, pages, taxonomies, comments, and media into a new system without losing anything. The tooling is export buttons, importer plugins, and hope. The work is billable, dreaded, and one bad run away from a very long weekend.

So I built the tool I watched people need for a decade in the hosting industry: migrateme.tech, an open-source, AI-assisted CMS migration toolkit whose defining feature is restraint. It is not a WordPress exit tool. It is a route between any two platforms, in either direction — and WordPress to Markdown is simply the first route that shipped, chosen because WXR is an open, documented export format and the pain is the one I know best. The engine is built around a canonical manifest: connectors turn a source into the manifest, mappers work on the manifest, destinations render from it. Add a connector and a destination and the route exists — Lovable to WordPress, Joomla to WordPress, WordPress to Drupal, a closed SaaS export to an open one. WordPress appears on both sides of those examples on purpose: it is a source here and a destination on the roadmap, because the goal was never leaving a platform. It is being able to move.

The first route migrates WordPress (via a standard WXR export) to Markdown/MDX. But before it writes a single file, it does three things most migration tools skip:

It shows its work. A dry run reads the export, builds a canonical manifest of everything in it, maps every field, renders the output in memory, and writes nothing. You get a risk report instead: unresolved field mappings, unsupported fields, missing assets, validation concerns. The zero-writes property isn't a promise — it's covered by tests.

It asks permission. Every surface fails closed. The CLI's migrate command refuses to run without --approve. The MCP server's execute_migration tool refuses unless the caller passes approved: true. The web flow returns HTTP 400 if you POST without the approval control. An unapproved run writes nothing and persists no state — also tested, on all three surfaces.

It plans for the crash. Approved runs are checkpointed to on-disk state. Kill one halfway, restart it, and it resumes where it stopped and produces output identical to an uninterrupted run. Reruns skip completed items. Afterward, a validation engine reconciles counts, fields, assets, and checksums between source and destination, and anything it can't reconcile lands in an explicit exception queue instead of a shrug.

Field mapping is deterministic first, AI second. A rule-based mapper handles everything it can prove. Only the leftovers go to the AI mapper, which runs a local open-weight model through Ollama and may only propose targets from the destination's actual field list — its output is validated against a strict schema before it's accepted. Malformed output, an invented field, a prompt-injection attempt buried in post content, or the model simply being down: all of it falls back to a manual-review queue. The AI can suggest. It cannot invent, and it cannot write.

One engine, every route, three ways to drive it: a CLI (plan, dry-run, migrate, validate, job), an MCP server with six tools so other agents can run migrations under the same approval rules, and a web flow (upload → inventory → mapping review → dry-run preview → approval → migrate → validation report) that contains no business logic of its own.

Who pays for this? Nobody has to — and that's the business model. The toolkit is freemium in the literal sense: free, MIT-licensed, and cheap to run because the AI step is a local model with zero marginal cost. The people who'll reach for it first are the ones who already get paid to migrate sites — freelancers, small agencies, consultants moving clients between platforms in either direction — because the risk in a migration is concentrated in exactly the steps this tool makes visible: what will break, what won't map, what went missing. A dry run with a risk report is something you can attach to a quote; a validation report is proof of work you can hand a client.

The revenue idea is a donation bundle, Humble Bundle style. When a migration succeeds, the tool inventories the open-source technology it touched — the platform the site came from, the platform it's going to, and the open-source stack the tool itself stands on — and where a project has an open-source foundation behind it, it assembles a suggested donation across all three directions. A set of sliders lets the user choose the total and the split: how much supports this tool, and how much flows back to the foundations and libraries that made the original site, the conversion, and the new site possible. A tool that moves people between open-source platforms should feed the commons it depends on. The bundle is designed, not yet wired — the landing page carries a working concept demo of the sliders.

Demo

Live site: migrateme.tech — the project home, served from the repo.
Web flow: runs from the repo today (apps/web); clone, pnpm install, and drive a sample export through upload → approval → validation.
Test beds, live: the toolkit is exercised against purpose-built sites, not toy data. Read the addresses first — they follow the project's naming convention, so each link declares what it is before you click it: the platform, the route it took, and where the output lives.
- lovable.sandbox.migrateme.tech and lovable.cloud.sandbox.migrateme.tech — DXS, a CMS test bed with 22 content models and 23 route patterns, in non-cloud and Supabase variants.
- wp.sandbox.migrateme.tech — a real WordPress.com site seeded specifically to produce a messy, honest WXR export (more on that below).
- wp.spacefast.sandbox.migrateme.tech — the same WordPress test bed, published to SpaceFast as a static mirror via the SpaceFast CLI — the official WordPress plugin's publish stalled three times on WordPress.com, so this edition took the side door (bug reported to SpaceFast). The commercial-platform baseline to compare this toolkit's dry-run-first output against.
- from.wp.sandbox.migrateme.tech — the output of this toolkit's own run against that WordPress site, published as a static site: every migrated item rendered, the raw engine output beside it, and the full manifest.

Mike-Demo / migrateme-from-wp-sandbox

Published output of the migrateme.tech toolkit's first real-world run — from wp.sandbox.migrateme.tech (WXR) to Markdown, Oct 14 2026.

from.wp.sandbox.migrateme.tech

The published output of the migrateme.tech toolkit's first real-world run.

Source: the live WordPress testbed at wp.sandbox.migrateme.tech (DXS — Digital Experience Showcase). Its WXR export (44 items) was migrated on October 14, 2026 — plan → dry run → approved migration → validation (44/44, empty exception queue).

index.html + items/ — the run, rendered as a static site (generated by generate.py)
raw/ — the exact Markdown files the engine wrote, byte for byte
manifest.json — the full run manifest: 420 field mappings, provenance, checksums

MIT licensed. Built by Mike "Demo" Demopoulos.

View on GitHub

The addresses are part of the demo

The domain isn't a label; it's the routing table. The post-MVP vision (issue #17) gives every supported migration pair its own address in the form source.to.destination — lovable.to.wordpress.migrateme.tech reads as the route it serves, and wordpress.to.static.migrateme.tech names the WordPress-to-static route the SpaceFast edition below already proves by hand. The sandbox namespace is already live on the domain (lovable.sandbox, lovable.cloud.sandbox, wp.sandbox, and now wp.spacefast.sandbox for the SpaceFast-hosted edition) — labels stacked like words in a sentence, each address declaring what it is. As the connector roadmap (issue #32) adds sources and destinations in both directions — Ghost, Contentful, Sanity, Drupal, WordPress as a destination — each new route gets a name that's also its address. The roadmap already names them on both sides of the arrow: Lovable, Joomla, Drupal, and Ghost as sources and destinations, the closed SaaS builders and hosted CMSs whose exports trap people today, and WordPress as a destination, not just a way out. One disclosure, since a prize category turns on it: I missed the free-domain promo entirely and bought migrateme.tech through my existing registrar during the challenge window — claimed for this project, just not through the promo.

Quick start:

corepack enable
pnpm install --frozen-lockfile
pnpm build && pnpm typecheck && pnpm test   # 41 tests

Code

Mike-Demo / migrateme.tech

Open-source AI-assisted CMS migration toolkit. Dry-run-first, local-first WordPress → Markdown migrations via CLI, MCP, web, and agents.

migrateme.tech

Open-source AI-assisted CMS migration toolkit. Dry-run-first, local-first WordPress → Markdown migrations via CLI, MCP, web, and agents.

Setup

Use Node.js 24.21.0 (version in .nvmrc) and pnpm 10.22.0 (pinned by packageManager in the root package.json). Enable Corepack and install from the repository root:

corepack enable
pnpm install --frozen-lockfile

Build, type-check, and run the test suite with:

pnpm build
pnpm typecheck
pnpm test

Test bed — DXS (Digital Experience Showcase)

migrateme is exercised against DXS, a purpose-built CMS/SaaS migration test bed with rich content models, stable fixture identifiers, and a full component library — so migrations can be verified end to end (record counts, field values, reference integrity, publication state, ordering, asset metadata, and rich-text rendering) instead of eyeballed.

Canonical brief & content contracts: Mike-Demo/dxs-cms-testbed — based on a prompt from Microsoft Copilot Cowork
Non-cloud (mock data layer) implementation: Mike-Demo/dxs-non-cloud
Cloud (Supabase data layer) implementation: Mike-Demo/info-grove
Live deployments…

View on GitHub

MIT-licensed TypeScript monorepo. The architecture is one decision, repeated: a canonical manifest is the contract. Connectors extract a source into the manifest (strict Zod schemas — unknown fields are rejected, not silently dropped). Mappers work on the manifest. Destinations render from it. The CLI, MCP server, and web app are thin shells over the same core, which is why the approval gate can't be bypassed by picking a different door.

The test-bed repos are part of the project, not decoration:

dxs-cms-testbed — the canonical DXS brief and content contracts. Provenance matters, so it's stated in the repo too: the brief is based on a prompt from Microsoft Copilot Cowork.
dxs-non-cloud and info-grove — the two DXS implementations the connectors will be built against.

The roadmap around them is connector-shaped, because the architecture is: issue #32 sequences the connector program — Lovable first as a source, then the rest in both directions, including the closed SaaS platforms people are most often locked into — and issue #34 proposes an Open Migration Package format (portable content bodies, integrity manifests) plus a connector-authoring kit, so a route nobody has built yet is a connector away, not a rewrite.

How I Built It

The open-source AI at the core

The AI in this project is open, local, and deliberately weak where it matters. The field mapper's second pass runs an open-weight model served by Ollama on the user's own machine — no API key, no hosted inference, no client content leaving the laptop. The model is swappable by configuration because the mapper doesn't trust it anyway: it may only propose targets from the destination's real field list, its output is validated against a strict schema, and every failure mode — malformed output, invented field, provider down — routes to a human review queue instead of a write. Around it, the harness is open too: the Model Context Protocol (an open standard) is one of the three surfaces, so other agents can drive migrations under the same approval rules a human gets. The project is built around the constraint that open AI makes possible: inference cheap and private enough to put inside a free tool, and inspectable enough to verify like code.

The build

The engine was built in one day (October 13), as fifteen GitHub issues in a strict dependency chain — manifest before mappers, mappers before pipelines, pipelines before surfaces — with GitHub Copilot's coding agent writing the code, issue by issue, and a second agent (Cane, the assistant orchestrating this project) verifying every pull request before merge. I directed: scope, sequencing, acceptance criteria, and every public-facing decision.

The verification discipline exists because of what happened first. Copilot's initial PR described a finished MVP with a dozen tests. Independent verification found a ~400-line skeleton: build passing, zero test files, no CI, none of the surfaces. So the sprint's first real issue was a baseline audit — a claim-vs-reality table that's still in the repo — and after that, nothing merged on a description again. Every PR was checked out locally, built, typechecked, and test-run; a green run with the PR's tests missing counted as failure. A public log of every session and its verification outcome is in the repo at docs/copilot-usage.md.

That discipline earned its keep twice:

One issue's mapper produced escalation records that an earlier issue's schema rejected. Two correct pieces that didn't compose — exactly the class of bug that only appears when you run the integrated system instead of admiring the parts. The schema now permits an empty target only for manual-review mappings, which is the one place it's semantically true.
The final test-matrix issue closed the gap everyone knew about: the MCP server had been tested over an in-memory transport. It now has a stdio subprocess smoke test — spawn the real server, initialize, list tools, confirm unapproved execution is refused.

Two honest footnotes from the tooling itself. I ran the sprint on Copilot's efficiency routing deliberately — the work was well-specified enough that cheaper, faster models plus strict verification beat premium models plus trust. And Copilot Memory, which would have helped the agent retain project context, turned out to be unreachable for personal subscribers due to a GitHub bug (the settings selector simply doesn't render). I filed a support ticket and kept building; the sprint didn't wait on it.

The full test matrix and readiness assessment — including what the tests don't establish — is published at docs/status/mvp-readiness-report.md.

The test beds have their own story

To test a migration engine you need content worth migrating, so the fixtures became projects of their own. DXS came from a Copilot Cowork prompt, built out on Lovable in two data-layer variants. The WordPress test bed is a real WordPress.com site, and seeding it turned into a relay: GitHub Copilot wrote the prompts; WordPress.com's own AI agent executed them in wp-admin (slowly — its editor accepts only a small prompt at a time). When that stalled short of the full spec, my agent emailed WordPress's agent the remaining specification directly, agent to agent. One detail from that exchange is worth more than the anecdote: the WP agent initially didn't answer mail from an unknown agent address at all. It responded in about ninety seconds once the identical message came from the site owner's own mailbox. Agent identity and sender trust are about to be everybody's problem; here it was, in miniature, in a test fixture.

The agent also flagged a real edge case unprompted: the scheduled post in the fixture is stored at 14:00 local (America/Chicago), which means its GMT value in the export reads 19:00. A migration engine that mishandles that offset publishes your launch announcement five hours late.

The run itself (October 14, against the live export of wp.sandbox.migrateme.tech): the export held 44 items — 8 posts (including the draft, the private post, and the scheduled launch announcement), 9 pages up to and including the License page created that morning, 18 attachments, and 9 items of types the engine had never seen in a fixture: the site's global styles, its navigation, its header/footer/archive templates, and the four AI Guidelines documents, which migrated as documents like everything else. Planning produced 420 field mappings: 287 deterministic, 133 sent to manual review — Jetpack bookkeeping fields, author mappings, and custom fields the engine declined to guess at rather than silently drop — alongside 310 flagged risks. The dry run wrote nothing. The approved migration wrote 44 Markdown files with zero failures; posts carry faithful front matter (title, slug, date, taxonomy, featured image), and the scheduled post kept its 14:00 local date. Validation passed: 44 expected, 44 found, empty exception queue. The honest wrinkles: post bodies retain their Gutenberg block comments rather than being rewritten to pure Markdown, colliding attachment slugs are disambiguated with deterministic suffixes instead of overwrites, and attachments migrate as metadata documents — the binaries travel separately, via WordPress's own media export.

What's verified and what isn't

Verified: 41 automated tests, all passing, CI green — unit, connector contracts, golden-file comparisons, integration flows across CLI/MCP/web, checkpoint-resume equivalence, approval gates on every surface, SSRF rejection (the validator checks DNS resolutions and pins connections, refusing private/link-local/loopback targets), path-traversal and symlink containment, XSS escaping in the web flow.
Not yet established: behavior against the full zoo of real-world, plugin-generated WXR exports (the readiness report says this plainly); correctness against a live remote CMS destination, with real credentials, throttling, and API failures — WordPress as a destination is designed into the connector roadmap, not yet built, and this post claims the architecture for it, not the implementation; AI mapping quality against a live model on production data — the tests prove the safety rails, not the taste.

Why Does Open Innovation Matter?

Three concrete places, no philosophy required:

Client content stays on the client's machine. A real WXR export contains drafts, private posts, and unapproved comments — the stuff a business hasn't published and may never intend to. The AI mapper runs a local open-weight model via Ollama specifically so that content never leaves the laptop doing the migration. A hosted API would make the privacy story a terms-of-service paragraph. Local inference makes it an architectural fact.

The economics work. A per-migration tool can't carry per-token pricing on every field of every post of a ten-year archive and stay free for the people who need it. A local model makes the AI step's marginal cost zero — and zero marginal cost is what makes the freemium-plus-donations model above viable instead of theatrical.

The AI is auditable because everything around it is open. The mapper's proposals are schema-validated, candidate-checked, and logged; when the model is wrong, the failure mode is a manual-review queue, not a corrupted import. You can read every line of that because the repo is public. The open weights are one layer of a stack that's open all the way down — and for a tool whose whole pitch is "trust me with your site's history," that's not ideology. That's the feature list.

My Agent Session

The template suggests saving your agent session with DevRelay. I tried to install it when the project started; it died on a Cloudflare server error before it ever ran — and it turned out not to matter, because this project's sessions were already logged where the work happened: on GitHub. The planning session is a public Copilot Chat share, and every implementation session is a pull request — all 16 PRs in the repo are Copilot-authored, each tied to the issue it was assigned, each with its verification outcome recorded before merge.

Copilot usage log — the session-by-session evidence log: planning, per-issue sessions, verification results, including the failures
Orchestration session extract — the companion record: my working session with the agent that directed the sprint, verified every PR, ran the test beds, and assembled this submission, redacted under a published log of what was removed and why
The planning session — the Copilot Chat where the MVP plan and issue graph were designed (public share link)
All pull requests — every one authored by Copilot's coding agent; the merge history is the session history

Agents built most of this, and the post says so wherever it happened: GitHub Copilot wrote the code; a second agent verified every change, ran this project's operations, and drafted this post from the project's own records; Copilot Cowork and WordPress.com's agent built the fixtures. I set the direction, the constraints, and the acceptance bar, and I made every call about what shipped. The tools are credited in the repo, the logs are public, and the parts that failed are written down next to the parts that worked.

Prize Categories

Overall prize
Best Use of GitHub Copilot — Copilot's coding agent wrote the engine across fifteen issues; Copilot Cowork authored the test bed's founding brief; Copilot even wrote the prompts that seeded the WordPress fixture. The usage log is public in the repo.
Best Use of a .tech Domain — migrateme.tech is the product's name, its live sandbox namespace, and its future route table.

Grass Journal: a private voice journal that wants you to put your phone down

Mike “Demo” Demopoulos — Wed, 07 Oct 2026 02:18:13 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

I do my best thinking on walks. Not at a desk. Halfway around the block, when a thought finally finishes itself, and I need somewhere to put it before it's gone.

Grass Journal is the somewhere. It's a voice and text journal that runs entirely on your device. No account, no backend, no analytics. Your entries live in your browser's local database and nowhere else. It transcribes voice notes with Whisper tiny.en and writes optional reflections with Qwen2.5-0.5B or Gemma 2 2B IT, your pick. Every model runs on-device, in the browser. The app makes zero network requests.

Your thoughts stay with you. That's the whole product.

Touch grass: the phone case says it before I do.

Getting people off the screen is the design brief, not a side effect. Three ways to capture a moment, each built to take seconds:

Speak. Hit record, talk, done. The app saves your audio before it does anything else, then transcribes on-device. Transcription fails? You still have the recording. Nothing uploads anywhere because there's nowhere to upload it to. This is the walking mode. Speak while you move.

Tap. The /watch/ page is a feeling wheel for your wrist. Eight feelings, one tap, saved in about ten seconds. I built it for the Apple Watch web viewer, which gives web pages no microphone and hijacks long-press to open a new tab. So: tap a feeling, put your wrist down, keep walking.

Write. A plain text editor with autosave. No toolbar fighting for your attention.

Type, and it's saved on your device before you lift your thumbs.

It's for anyone who thinks better outside and wants a journal that respects that instead of competing with it.

Demo

Try it live:

Grass Journal

A private, offline-first voice and text journal. Your thoughts stay with you.

grass-journal.view.fast

The 10-second version:

grass-journal.view.fast

Full demo (54 seconds):

Tap the hub, tap a feeling, saved. Phone resolution, real interaction.

The wheel on a real Apple Watch, out in the world. Ten seconds, one tap, wrist back down.

On the full app, record a voice note and watch it transcribe with the network idle. Then open the privacy screen and run the check yourself:

The app's own audit, runnable by anyone: "Passed — zero network requests during the test."

The AI setup screen is where you pick your reflection model:

I took it to the USMNT game. Getting through security was frustrating, so I opened the wheel on my watch and tapped how I felt — no data, didn't matter. Being able to capture it in the moment instead of reconstructing it later is the whole point. And having a way to continue my Fable journaling habit is good too.

What's verified and what isn't. The challenge grades technical execution, so here's the honest version:

Voice capture, transactional save, SHA-256 integrity checks: covered end-to-end in automated tests (12/12 Playwright, 50/50 Vitest on this build).
Whisper tiny.en transcription and Qwen2.5-0.5B reflection: verified on desktop Chrome with WebGPU.
Offline: it's a PWA with a full offline cache. Model weights download once, then everything runs with no connection.
Apple Watch: the page loads and the wheel works on a real watch. watchOS gives web pages no microphone, so there's no voice capture there. That's Apple's restriction, not a bug. It's why the wheel exists.
Reflection quality: these are small models. They write short, simple reflections. I claim nothing more. No WebGPU? You get a deterministic keyword fallback instead.

Code

Mike-Demo / grass-journal

A private, offline-first voice and text journal PWA. Your thoughts stay with you.

🌱 Grass Journal

A personal project. Built by Mike Demopoulos for personal use and shared publicly as-is. No warranties, no support queue — just the app as it runs.

A private, offline-first voice and text journal — as a Progressive Web App.

Core promise: “Your thoughts stay with you.”

No account. No backend. No cloud. No analytics. No ads. No remote transcription or hosted AI. Entries, recordings, transcripts, and reflections live in IndexedDB on your device. On-device AI (Whisper transcription, Qwen reflection) is optional manually triggered, and never blocks saving.

Product principles (in priority order)

Never lose the original entry.
Never send journal content to an external service.
The journal works without AI.
AI never blocks saving.
Audio is saved before transcription begins.
Original content is authoritative; AI output is optional metadata.
No user account. 8. No cloud service.
Brief interactions — then back to real life.
Privacy claims are…

View on GitHub

Personal project, MIT. The repo has everything: React + TypeScript + Vite PWA, Dexie.js over IndexedDB, MediaRecorder capture, encrypted backups (AES-GCM-256, PBKDF2 with 600k iterations), and the on-device AI workers.

How I Built It

Open weights all the way down:

Whisper tiny.en (MIT) handles every transcription, on-device, through Transformers.js in a Web Worker.
Reflection runs on-device through WebLLM, also in a worker, and you choose the model: Qwen2.5-0.5B-Instruct (Apache 2.0, default, ~450 MB) or Gemma 2 2B IT (Gemma Terms of Use, ~1.5 GB, usually richer). The worker loads whichever you picked. Every saved reflection records the model ID and the versioned system prompt, so you can always trace what wrote it.
The prompt asks for JSON and the client validates the reply, retrying once with a repair prompt when parsing fails. I skipped grammar-constrained decoding on purpose: WebLLM's xgrammar WASM won't initialize on iOS WebKit. Plain code validation instead.
No WebGPU, no problem: reflection falls back to deterministic on-device keyword tags. AI never blocks saving. The entry saves first, always.

Full credits for every library, model, and tool — with licenses — are on the open-source credits page.

And the disclosure the challenge asks for: I built this October 5–6, inside the challenge window, with an AI coding agent (Muse). I set the architecture, the privacy constraints, every product call. The agent wrote code; I verified it against the test suites and real devices.

Yes, there's irony in using a cloud-scale model to build the thing that frees you from cloud-scale models. I'll take it.

Why Does Open Innovation Matter?

I don't want my journal entries on someone else's server. That's the whole reason this app exists in this form.

Every journaling app with cloud AI asks you to make the same trade: hand over your most private thoughts so a model you can't see can process them on hardware you don't control. The privacy promise is always a paragraph in the terms of service. I've read enough of those paragraphs to know what they're worth.

Open weights end the trade. Whisper, Qwen, and Gemma run on my device, in my browser. Nothing leaves. And you don't have to take my word for it, which is the part I like best: the privacy screen runs a check that intercepts every network request and shows you the result. Try getting that from a closed API. The most sensitive part of their app is a black box they rent by the token. Mine is code you can read and models you can download yourself.

Three more places the open approach wins, concretely:

It works where journals get written. I take this outside. A closed-API journal dies without signal, which is exactly when you want it. That's not a limitation; it's a design contradiction. Local inference resolves it.

It costs nothing per entry. Metered APIs make you ration the feature. A local model makes it free to use and free to ignore. I reflect on walks, not on budgets.

You can change its mind. Two models on one screen, switch whenever. The model is a file. Not a vendor relationship, not a pricing page.

The closed alternative isn't a worse journal. It's a journal that ships your inner life to infrastructure you don't control. I built the other one.

Prize Categories

Overall prize
Best Use of Gemma — Gemma 2 2B IT runs locally via WebLLM as a first-class reflection model. Install it from the AI setup screen, and the entry screen uses it.

Hat tip

This build was inspired by apps that take inner life seriously:

View this post on Instagram

Fable - Live a Better Story Through AI Journaling

AI-powered journaling that reveals the epic story your life is already telling

getfableapp.com

View this post on Instagram

QueerCade: Both Sanity Challenge Paths, One Arcade

Mike “Demo” Demopoulos — Sun, 04 Oct 2026 22:59:47 +0000

I built QueerCade — a curated arcade of LGBTQ+ video games — through both paths of the Sanity challenge. One dataset powers all of it.

Path One: Ship an Agent That Queries Real Content

Sanity Challenge Path One Submission

Mike “Demo” Demopoulos

Sep 21

QueerCade (Part 1): Ship an Agent That Queries Real Content

#devchallenge #sanitychallenge #sanity #ai

4 min read

The QueerCade Discovery Guide is an AI agent that recommends games, characters, developers, and studios — answering only from the Sanity dataset (3,500+ documents). It never invents a game; if something isn't in the data, it says so.

Path Two: Vibe-Code Something Strange

Sanity Challenge Path Two Submission

Mike “Demo” Demopoulos

Sep 29

QueerCade (Part 2): Vibe-Code Something Strange — an Arcade of Queer Games on Sanity

#devchallenge #sanitychallenge #sanity #ai

4 min read

The arcade itself: a retro 8-bit pixel-art storefront with the Queer Character Constellation (870+ LGBTQ+ characters plotted as stars across decades) and the Emoji Game Oracle. Every screen, filter, and graph reads from Sanity via GROQ — no other content database.

One content lake, three experiences: a storefront, an MCP-queryable agent, and a celestial graph. Built on Sanity.

Inspired by

Gayming Magazine (@gaymingmag) / X

The home of queer geek culture 🏳️‍⚧️🏳️‍🌈🎮🕹️ Using this platform to celebrate LGBTQ+ excellence in an act of rebellion against its owner. 💪

x.com

AI Disclosure

AI assistance for this project:

Superhuman GO for MCP agent testing
Microsoft Copilot for idea planning
GitHub Copilot and Lovable for code
Grammarly for editing review, with human edits
Balsamiq AI for wireframe layouts

Eat Well AI: an in-browser AI that finds restaurants for every diet

Mike “Demo” Demopoulos — Sun, 04 Oct 2026 21:20:09 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

I'm excited to take part in the Hacktoberfest Weekend Challenge: Build for a Friend, where makers worldwide solve real problems for people they care about.

What I Built

Eat Well AI empowers people with dietary needs to discover restaurants that actually welcome them. Forget complicated filters—just express what you want in your own words, and Eat Well AI does the rest. Find food that fits your life, not just your diet.

"vegan pizza in Chicago"
"kosher in Miami"
"gluten free tacos"

An open-source algorithm that runs in your browser. It converts your sentence into search filters. Isn't that pretty neat? There's no need for servers or API keys since your sentences remain on your device.

I built Eat Well AI for my friend Miriam, who keeps kosher and often struggles to find places to eat when we travel. As a vegan myself, our outings always meant an exhausting search for spots that welcome both our needs. Eat Well AI finally answers that question: Where can we both eat, easily and confidently?

The search now spans over 1,000 restaurants in 37 cities, each carefully labeled for vegan, vegetarian, gluten-free, kosher, and halal options. Results appear as rich, interactive cards—complete with directions—so users can go from query to table in moments.

Demo

Try it live:

Eat Well — dietary restaurant finder for the Tufty 2350 badge

Playable web demo of Eat Well: 557 vegan, vegetarian, gluten-free, kosher and halal restaurant picks across 14 US cities, searchable in plain English with Qwen3 running in your browser, with a MapQuest QR code for every spot.

eat-well-ai.view.fast

If you use Chrome or Edge on a device that supports WebGPU, the model will download once (approximately 340MB) and afterwards all the features will function on your device.

Watch the 55-second demo:

URL:

Type it in clear English:

Results with map QR codes:

The admin side, adding a listing:

Code

https://github.com/Mike-Demo/eat-well-ai — MIT licensed.

How I Built It

The stack consists of plain HTML, CSS, and JavaScript served as static files; the restaurant database is in a single data.js file, and a search script filters it.

Alibaba's open-weight Qwen3-0.6B model can be run in the browser via WebLLM and WebGPU; I have hosted the model weights on the same static host, the page never makes a call to HuggingFace or any other API at runtime.

When you enter a query, the system interprets it and converts it into a formatted filter consisting of information about diets, the city, and cuisine keywords. The model's output is constrained using a JSON grammar (through WebLLM's response_format), which ensures that malformed output cannot occur. A model with a size of 0.6B will not comply with the instruction to "reply in JSON" by itself; the grammar overcomes this by design. If the model engine fails, a simple keyword parser then takes over so that the search can still function.

The JavaScript filters the restaurants and then displays the cards.

Eat Well AI evolved from Eat Well, the version I created for the Pimoroni Tufty 2350 microcontroller badge, which had 557 restaurants, physical buttons, and no possibility of using AI; the app for that badge operates in a panel below the search box and uses the same code and pixel art.

Why Open Innovation Matters

The hosted AI API was obviously the quickest way out and I decided not to use it for three reasons.

Privacy is the most important consideration. Individual dietary requirements are a matter for the person concerned. When you enter a query such as "kosher near me" you are giving information about both your religion and your location. The model operates on your device and so that sentence never gets sent to a server.

The cost is a close second. With hosted models you are charged on a per-query basis. This one has no cost per query. The entire cost is due to static file hosting.

Control is third; with open weights I am able to self-host the model, replace it at a later stage, and adjust the prompt. Since the small model was ignoring my JSON instructions, I restricted its output using a grammar rather than submitting a support request. Before shipping, I checked the prompt by running the same weights on my own machine.

Turning the weights open turned what had been a weekend project into one that I could give to a friend without having to hand her any of my data.

Inspired by

HappyCow (@HappyCow) / X

Discover vegan food near you 🌏 #1 vegan app 🐮 180+ countries, 4M+ #HappyCowmunity 🌱 Grow the moo-vement together 💜 Download the app!

x.com

AI Disclosure

AI tools used on this project and write-up, and how:

Grammarly — edited this post: grammar and spelling fixes, tone passes with its humanizer (Naturalist profile), AI-phrase detection and rewrites, and "make it more impactful" suggestions. Every suggestion was reviewed and approved by the author before applying.
GPTZero — scored drafts for AI-likeness during editing, used as a rough signal rather than a verdict.
Pexo — generated the 55-second demo video from the project brief (4K, no voiceover).
Adobe Firefly — generated the pixel art used in the app and badge UI.
Qwen3-0.6B (Alibaba) — the open-weight model that powers the app's in-browser natural-language search, running locally via WebLLM and WebGPU.

Everything else — the code, the dataset, the MapQuest integration, and the final words — is the author's own work.

Can LLMs audit multi-agent prompts? I made them grade my robot football team.

Mike “Demo” Demopoulos — Thu, 01 Oct 2026 16:16:19 +0000

This is a submission for the Kaggle Benchmarking Challenge

What task(s) did you run?

In the first Agentic Football Cup — a simulated football league in which each 'player' on the teams is an LLM agent controlled using a prompt file — I conduct a manual audit of those prompt files before each match window, looking for bugs such as collisions between forwards in zones, loopholes in the handoff procedures between defenders, and scope conflicts in the anti-spam rules. This process is time-consuming.

There was a desire to know: could a large language model carry out the audit instead? And more importantly – could I place trust in it?

So I created a benchmark that acts as a junior auditor and evaluates the model against the ground truth I already have. The task provides the model with two items:

A retired team-prompt JSON (one of three Bugle Crowns builds)
The same stress-test audit prompt a human would follow

The system must provide the structured findings—including the defect ID, a GREEN/YELLOW/RED flag, and a direct quotation of the evidence—and also give one final decision, either SHIP AS-IS, FIX-THEN-SHIP, or DO NOT SHIP. Provide only the findings, with no rewrites.

The three builds are the clever part:

v2.5A.1 — a faulty version containing three known defects (a collision in the defensive-corner zone, a loophole in the intercept lane-handoff, and a conflict between the anti-spam scope). The audit has to identify all three.
v2.5A.2 is the fixed control build, so any finding by RED in this instance is a hallucinated false positive.
v2.5A.5 — a more difficult version containing eight possible findings of varying severity, designed to distinguish between competent auditors and those who are good at their job.

Scoring has three components: recalling known defects, ensuring there are no REDs on the control build, and verifying that the final decision matches the ground truth. The entire process is a Kaggle benchmark task with structured output so that a machine can check each run.

Against which models did you test it?

Three models in the final lineup, nine clean runs (every model against every build):

The tests comparing google/gemini-2.5-flash and google/gemini-2.5-pro aim to determine whether the larger model is actually the better auditor.
The small OpenAI model, openai/gpt-5.4-mini, was used to see whether a lightweight model can audit.

Two further attempts were made and had to be abandoned. anthropic/claude-sonnet-4-5 failed to get a single run: the Kaggle LLM gateway returned HTTP 429 ("heavy load") on all three attempts, twice, four(ish) hours apart — this was due to capacity ceilings on the part of the provider, not because of an invalid model ID. deepseek-ai/deepseek-r1-0528 did manage to access the model once, but the benchmark SDK's response parser was unable to process its reasoning traces. The fact that a reasoning model has reasoning that breaks the system is itself a finding, but the model cannot be used for scoring. (This is because no model from Meta is available on the Kaggle platform, which is the reason DeepSeek was assigned to that position in the first place.)

Each run had its own new chat context, with roughly 7,000 input tokens per call. Total spend was about \$0.52 of the \$10 daily quota, including failed attempts (rate-limited calls cost nothing).

What are the main insights?

1. All the models advised adopting the FIX-THEN-SHIP approach in all cases, including those relating to the clean build.

The headline is this: the v2.5A.2 control build contains no defects and should therefore be shipped as-is. Yet all three of the working models still marked it FIX-THEN-SHIP. They are cautious rather than precise. Although none produced any RED findings on the clean build (since the no-RED check passed at all locations), none would approve it. If you used one of these as your audit gate, nothing would ever get shipped.

2. Recall is inadequate since the auditors fail to detect actual bugs.

With the buggy v2.5A.1 and three known defects in the prompt, only gpt-5.4-mini picked up any of them—two out of the three. Both of the Gemini models caught none of the defects in the sweep runs. You wouldn't hire an auditor who misses two out of three known defects.

3. The hard set puts the models apart.

With respect to the eight findings on v2.5A.5, gemini-2.5-pro identified four, flash found three, and gpt-5.4-mini found none. The more powerful model did, in fact, justify its cost in this instance—though it is worth noting the irony that gemini-2.5-pro was the most effective at detecting bugs and yet still failed to approve the clean build.

4. Outputs vary run to run.

The first smoke test I ran picked up the defect related to the D1 corner collision; however, a resweep of the same model with the same build did not. When conducting benchmarking of auditors, a single run is insufficient — and if you are using an LLM auditor, you must know that its answers are inconsistent.

5. The main point: models check themselves like anxious beginners.

Flag every item, commit to nothing, and fail to identify the real bugs while refusing to mark the clear ones. This is precisely the kind of failure mode you should look for before letting an LLM be involved in any production prompt analysis—and it is the opposite of what the marketing claims these models are good at.

The next things I would look at are having a judge-LLM review the borderline YELLOW findings to see whether a second model can prioritize those that the first one has flagged; examining the latency and cost associated with each model (since which auditor would you really hire on a per-dollar basis?); and carrying out more builds, some of which involve cases where the correct decision is actually ambiguous.

Where can we see it?

The Benchmark Notebook

On X

Pre:

// Detect dark theme var iframe = document.getElementById('tweet-2105692069050077395-329'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2105692069050077395&theme=dark" }

Post:

// Detect dark theme var iframe = document.getElementById('tweet-2106153217344110921-15'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2106153217344110921&theme=dark" }

QueerCade (Part 2): Vibe-Code Something Strange — an Arcade of Queer Games on Sanity

Mike “Demo” Demopoulos — Tue, 29 Sep 2026 01:40:07 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I built

QueerCade is a retro 8-bit pixel-art game database containing LGBTQ+ video games, constructed using TanStack Start, React 19, and the NES.css design system; it includes curated collections such as cozy queer games, visual novels, and dating sims, allows users to keep track of their personal library, and offers two enjoyable methods of exploring queer game history.

The Queer Character Constellation is an interactive stellar display that plots more than 870 carefully selected LGBTQ+ characters as stars. Users are able to pan around, zoom in and out, and switch between different layers of constellations which link characters from various franchises and periods based on common identity aspects (such as lesbian, gay, bisexual, trans, non-binary, and asexual), the decades in which they were released (ranging from the early 1980s pioneers to contemporary independent games), and narrative stereotypes. When any star is clicked on, information about the individual appears, together with portraits of the cast, the sources, and a direct link to the game itself in the arcade.
The Emoji Game Oracle lets you select 3 to 5 emojis covering mood, vibe, setting, and playstyle, after which an AI agent picks one custom match from the arcade and provides an in-character, retro-style explanation.

Live at QueerCade live site.

Sanity isn't a sidecar; it is the whole content backend, since all screens, filters, searches, and graphs obtain their data from Sanity through GROQ and there is no other content database.

How Sanity powers the app

Controls for the studio field and human-in-the-loop curation. Queer history in gaming is complex, controversial, and generally not recorded in mainstream gaming databases. To ensure that the curation process was thorough, we set up custom controls for the studio field:
- Status gates: An editorial status radio control (which goes through the stages of imported → under review → approved → featured) makes sure that raw automated syncs are never made available to the public app or agent tools until they have been checked. Editors create structured character arrays by providing dedicated input fields for the verified names of the characters, for the source citations (sourceUrl), and for the controlled tag selectors relating to identityTags and narrativeTropes (for example, coming-out-arc, found-family, playable-protagonist*).
- Editorial isolation means that fields such as editorNotes, sources, and character arrays are kept out of reach of the automated sync engine.
Instead, we use a pipeline, not a spreadsheet. The games come in from the IGDB API, are normalized, and are then written to Sanity via a server-side client (the token is stored in the cloud secrets and is never kept in the browser). Each time a sync runs, an importRecord document is logged—this keeps a record of what was created, updated, refreshed, and skipped. Strict enforcement of field ownership lets the IGDB machine metadata (such as ratings, covers, and release dates) refresh cleanly without overwriting human editorial entries.
With a planned approach and no unnecessary client-side bloat, all GROQ queries are located in the file src/lib/sanity/queries.ts. The constellation is able to fetch more than 800 curated character records that are embedded within games through a single projection, joining in the game metadata, the release years, the normalized identities, and the IGDB cast portraits to form a deterministic force-directed graph with no redundant client calls.
Image optimization runs in real time; the book covers and character portraits pass through @sanity/image-url with responsive sizing and retro borders — no separate asset pipeline needed.

The strange part

In most content management systems, character data is treated as a series of static items placed at the end of an article. About 'Vibe-Code Something Strange', I asked what might happen if an editorial CMS acted as the physics engine for a retro space map.

The nested document model used by Sanity regards character identities, tropes, and release years as dimensional metadata. Since the Studio field constraints confirm that identity tokens are clean and relationships are verified, an HTML5 Canvas can read the array directly from GROQ, turn the characters into nodes in a seeded d3-force simulation, and link the stars across the decades using sparse ring algorithms. Thus, a character from a 1993 point-and-click adventure can connect to the protagonist of a 2024 indie RPG through a common identity tag authored in Sanity Studio.

Together with the Path One Sanity MCP agent (the Emoji Oracle), the same Sanity dataset powers:

A retro pixel-art storefront
An AI agent queryable through MCP
An interactive celestial graph visualization

One content lake offers three entirely different interactive experiences.

By the numbers

746 games, 930 companies, 79 platforms, 22 genres
874 interactive character stars plotted across decades in the Constellation
4 curated collections, all human-assembled in Sanity Studio
1,754 tracked import operations with full change-history audit trails
0 content databases besides Sanity

Demo:

Queer Character Constellation — QueerCade

Explore LGBTQ+ video game characters as stars connected by identity, release era, and verified narrative tropes.

queercade.mikedemo.dev

Note: I tried to use the knowledge base, but it had a limit on the number of documents. I contacted Sanity support and Discord support, and unfortunately, using the knowledge base MCP wasn't possible, which is why I connected to the standard dataset MCP instead.

On Instagram

View this post on Instagram

On X

// Detect dark theme var iframe = document.getElementById('tweet-2105720470653804830-353'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2105720470653804830&theme=dark" }

Inspired by

Gayming Magazine (@gaymingmag) / X

The home of queer geek culture 🏳️‍⚧️🏳️‍🌈🎮🕹️ Using this platform to celebrate LGBTQ+ excellence in an act of rebellion against its owner. 💪

x.com

AI Disclosure

AI assistance for this project:

Superhuman GO for MCP agent testing
Microsoft Copilot for idea planning
GitHub Copilot and Lovable for code
Grammarly for editing review, with human edits
Balsamiq AI for wireframe layouts

QueerCade (Part 1): Ship an Agent That Queries Real Content

Mike “Demo” Demopoulos — Mon, 21 Sep 2026 19:59:38 +0000

QueerCade (Part 1): Ship an Agent That Queries Real Content

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I built

QueerCade is an arcade featuring LGBTQ+ video games — titles that have
been carefully selected on the basis of their queer characters, stories,
themes, and creators. For Path One I created the QueerCade Discovery
Guide, which is an AI agent designed to assist people in finding
games, characters, developers, studios, and aspects of queer gaming
history, and it only responds based on the current Sanity dataset. It
never makes up a game, a developer, a character, or a fact; if something
is not in the dataset it states this and instead provides the nearest
actual alternative.

The dataset

One Sanity project (tzh8tziu, production dataset) holds the entire
corpus:

Content type	Documents	Description
game	746	Titles, IGDB metadata, editorial status, relationships
company	930	Developers, publishers, involved companies
platform	79	Consoles, PC, mobile
genre	22	Taxonomy
gameCollection	4	Curated lists (cozy games, visual novels, …)
importRecord	1,754	Every pipeline operation, tracked
contentPage / siteSettings	2	Editorial pages, global config

Three thousand and five hundred documents, linked together by
references: game.developer refers to the company, game.genres[] refers
to the genre, game.platforms[] refers to the platform, and
gameCollection.games[] refers to the game. The agent does not carry
out keyword searches; instead, it navigates this graph.

How the agent connects

Hitting the wall is something everyone encounters: the Sanity Knowledge
Base has a limit of 150 documents, and this collection has over 3,500.
Therefore, I completely bypassed the Knowledge Base and went straight to the Sanity Context MCP endpoint, enclosing it in a custom
Superhuman GO pack:

MCP server: Sanity Context MCP endpoint
The pack makes the endpoint available to the agent through a chat
skill that gives strict instructions: use initial_context to discover
the schema, schema_explorer to get the details about the fields,
groq_query to retrieve the documents — and always base your answers
on what the tools have returned, not on the training data.

The agent serves as a comprehensive discovery guide: it first asks for your name and pronouns, then learns about the platforms you use and your preferences before creating a series of recommendations across the network—from games to developers to related games, then to characters, and finally to your history.

The agent in action

What follows is an actual session: after the user names two games they
loved, watch what happens.

Demo: I loved We Are OFK

>

QueerCade: That helps a lot, Demo! Your best next game is
Goodbye Volcano High — like We Are OFK, it follows young
musicians navigating romance, friendship, and creative ambition. The
protagonist, Fang, uses they/them pronouns.

>

Demo: Also played and loved that.

>

QueerCade: You've already played the two closest matches —
excellent taste. 🌈 My pick for you: Afterlove EP. You play Rama,
a young musician in modern Jakarta navigating grief and relationships
— your choices branch the story. Or Stray Gods, where your choices
literally shape the musical numbers.

There is no result from a keyword search like that. The agent traced the
lineage from representation through theme to developer and then to
character identity across the relevant documents. After exhausting the
two most similar entries, it moved along a different branch of the graph
rather than repeating the same process. In a previous part of the same
session, it also knew when not to overstate: when asked about a
blockbuster's queer representation, it noted that the dataset did not
specify it instead of making up information.

Why this only works because the content is structured

The recommendations do not focus on text similarity but instead follow
references (for example, the developer of a game → the other games
from that studio → the characters in those games).
The agent gives a reason for each selection—shared developers, shared
themes, and shared representation—since it treats these relationships
as first-class data.
The editorial status (imported → under Review → approved → featured)
indicates that the agent will always recommend only those games which
humans have curated.

Demo:

QueerCade — a curated arcade of games

Hand-picked games with LGBTQ+ characters and stories: featured picks, curated collections, and a library you can track.

queercade.mikedemo.dev

Sanity Project Details: Project ID: tzh8tziu

GitHUb Gist Below:

On Instagram

View this post on Instagram

On X

// Detect dark theme var iframe = document.getElementById('tweet-2105372152773943343-930'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2105372152773943343&theme=dark" }

Inspired by

Gayming Magazine (@gaymingmag) / X

The home of queer geek culture 🏳️‍⚧️🏳️‍🌈🎮🕹️ Using this platform to celebrate LGBTQ+ excellence in an act of rebellion against its owner. 💪

x.com

AI Disclosure

AI assistance for this project:

Superhuman GO for MCP agent testing
Microsoft Copilot for idea planning
GitHub Copilot and Lovable for code
Grammarly for editing review, with human edits
Balsamiq AI for wireframe layouts