DEV Community: Rohan Saxena

DEAD AIR: I Built a Haunted System That Won’t Acknowledge Goodbye

Rohan Saxena — Sat, 31 Oct 2026 21:18:10 +0000

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

What I Built

I restart the worker. The message arrives again. Another record appears in the archive, but the queue still says pending. The obvious fix has made the evidence stranger.

DEAD AIR is a browser horror investigation set inside an abandoned operations console. Meridian Systems closed in 2019. At 02:13, one connection remains active, repeating: “Please don’t shut it down. I’m still here.” You are the incoming archive operator. Your first job is to discover why the machine cannot finish a delivery.

The loop is concrete: notice an anomaly, inspect the queue, follow a trace, compare explanations, change something, then observe the consequence. Restarting is a temptation, not a required mistake. Pausing is useful too: it contains retries while leaving the pending message and evidence intact. Feedback shows attempts, stored records, queue status, and the acknowledgement route, with links back to the relevant trace.

MORA, the maintenance operator, helps investigate. It can question a theory, point toward discovered evidence, or explain a recovery procedure when explicitly asked. Its confidence is part of the atmosphere; its authority is deliberately limited.

Story spoilers: what the haunting becomes

The voice belongs to Ada Ward in an old family recording. Elena, her daughter, asked the system to preserve an archive until someone could take over. MORA mistook an archived sentence for a present-tense request. The mystery turns from rescue toward memory, attribution, and an obligation without an ending.

There are two main endings, Preserve and Silence, with four authored outcome variations. An optional custody comparison asks whose name belongs on a recording: the original speaker’s, or the account attached to its delivery. The player can prepare a verified index or leave uncertain attribution sealed. That decision changes what either final choice leaves behind. Preparing an export never establishes that another person received it.

Demo

Play DEAD AIR

Watch the captioned gameplay demo

The recording follows an isolated, fresh investigation through a restart, an evidence-based MORA exchange, recovery, and an archive decision. An explicit warning precedes the story revelation. It records actual gameplay rather than reconstructed dialogue.

The free Render demo uses temporary server saves and can take about a minute to wake after inactivity. Exporting keeps a copy of the investigation and discovered fictional evidence; it is not a backup of playable server progress or a bundle of audio recordings. Sound is optional, and comfort controls reduce motion and visual effects.

Code

Source code on GitHub

The repository contains the simulator, authored evidence, MORA prompts and tool boundaries, SQLite migrations, tests, deployment configuration, and reproducible recording script. The rules behind every consequence can be read without asking the model what happened.

How I Built It

The application uses Next.js, TypeScript, and SQLite. A pure transition function owns game state: queue attempts, committed records, discovered evidence, repair settings, custody decisions, and endings. Actions carry versions and unique identifiers, so stale updates are rejected and repeated submissions do not repeat an operation.

The operational failure is delivery after commit: VAULT stores a result, but its acknowledgement never reaches RELAY. A retry can therefore append another record even though the original write succeeded. Idempotency and a functioning return path solve different parts of the problem. Earlier duplicates remain as history; they do not imply corrupted recordings.

MORA uses gemma-4-26b-a4b-it through Google AI Studio. Its read-only tools inspect discovered evidence, observed traces, recent events, and available actions. A knowledge projection withholds unrecovered documents. Responses must cite discovered evidence and suggest legal actions. The model cannot perform repairs, create evidence, or select an ending.

I bounded the entire tool loop to thirty seconds, added a per-session inference lease, and capped shared concurrency and hourly usage in SQLite. Model calls happen outside write transactions. Scripted fallback still compares evidence and offers progressive hints. Suggestions tied to an earlier state are retired when the investigation changes.

One practical challenge was the native SQLite dependency inside Docker. The recorded container build initially lacked the Python and compiler tools needed to build it. I added those tools to the build stage, while keeping them out of the runtime image. This was packaging work with a visible consequence: the same persistence layer could start in the container.

Before deployment, 56 unit and integration tests passed. Sixteen production-browser scenarios passed across the initial run and targeted fixes, including all four outcomes, reload restoration, fallback, stale suggestions, and missing-save recovery. Type checking, linting, and the production build also passed. Earlier repository records separately document live Google evaluations and Docker checks.

Why Does Open Innovation Matter?

Gemma is an open-weight foundation. Access to its weights makes independent adaptation and deployment possible under its applicable terms. Those are properties of the model, not features I have implemented in DEAD AIR: this version sends live inference requests to Google. It does not run inference locally or offline, and open weights do not make hosted requests private.

For this project, openness makes the boundaries inspectable. Someone can examine the prompts, change the investigation behavior, test the evidence filter, or replace authored scenarios while preserving deterministic consequences. An open-weight model also leaves room for independently adapted inference later, without making that a claim about the current application.

A closed model could implement this interaction too. The value here is an inspectable game and an adaptable model foundation, rather than a claim that one licensing model uniquely enables horror.

The current limits are small and deliberate: one fixed mystery, authored variations rather than procedural campaigns, Google quota dependence for live chat, and resettable demo saves. Replay explores different decisions; it does not promise a new culprit.

Prize Categories

Best Use of Gemma: Google-hosted Gemma acts as an investigation partner through bounded, discovery-gated tools. It helps compare theories and interpret operational history while the simulator remains responsible for truth and consequences.

Best Use of Render: The live game runs as a Docker web service on Render. The server handles the deterministic simulator, SQLite sessions, and Google inference requests; the free deployment clearly discloses its temporary saves.

ProofPack: Automating the Click-Through After the Feature Is Built

Rohan Saxena — Mon, 26 Oct 2026 04:50:30 +0000

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

What I Built

Finishing a feature often leaves another chore: click through it again, check what happened, take screenshots, and assemble an explanation someone else can follow.

I built ProofPack to handle that follow-up work.

ProofPack is an open-source, local-first application that turns a feature brief into a bounded browser demonstration with executable checks and saved evidence. It helps developers demonstrate observable behavior without manually collecting every screenshot and reconstructing every step.

The user supplies an allowlisted application URL, a description of the behavior, and expected outcomes. For example:

Create an account and a project. Log out, open a fresh browser session, and log back in. Verify that the project is still there.

An AI model creates a structured plan and chooses actions from observations of the page. A separate browser worker performs those actions, executes assertions, and records what happened.

The user receives an assertion ledger, an execution timeline, screenshots, downloadable browser traces, and Markdown or self-contained HTML reports.

The distinction I wanted to preserve is simple: asking a model what should happen is different from collecting evidence of what did happen. In ProofPack, the model proposes the work. Executable checks determine the outcome.

Demo

Watch the ProofPack demonstration on YouTube

The video shows ProofPack running locally with real Groq inference against Wikipedia. The request is to search for Go (programming language) using Wikipedia’s search field, then verify the destination URL and visible article title.

Both assertions passed in the final attempt.

Watch the connection between the request, recorded actions, assertion results, and exported evidence. The standalone HTML report includes its screenshots and opens directly from disk.

The video uses selected recording segments with waiting omitted. The article is also opened separately for review after the AI run. An earlier screenshot timeout remains in the run history; the successful retry does not erase it.

I also built two controlled target applications called LaunchDesk. They support the same account-and-project workflow, but one deliberately loses project visibility after a fresh login.

Recorded live Groq runs show the contrast: the working version passed 4/4 checks, while the broken version passed 3/4, failing the final persistence check. Screenshots preserve the observed missing project.

LaunchDesk is a controlled demonstration of the workflow. The Wikipedia example separately exercises a read-only interaction with a public website.

ProofPack itself runs locally; there is no public hosted dashboard.

Code

Source code: github.com/Rohan-Saxena644/ProofPack

The repository contains the application, separate worker, controlled targets, model adapters, verification scripts, screenshots, and recorded verification results.

To try it, install dependencies with npm ci, install Chromium with npm run browsers, copy .env.example to .env, and run npm run dev:all.

The default fixture mode needs no model key. It uses deterministic decisions with a real browser and is explicitly labeled. Live mode requires provider configuration and credentials.

The original application source is MIT-licensed. Dependencies and model weights have their own licenses.

How I Built It

The demonstrated AI configuration uses OpenAI’s open-weight GPT-OSS 120B model, identified as openai/gpt-oss-120b, through Groq’s hosted inference service. Groq serves the model; inference is not running on my laptop.

The execution path starts in a Next.js and React dashboard. The API validates the request and queues it in SQLite. A separate Node.js worker claims the job and runs Playwright Chromium, keeping long browser sessions outside the web request lifecycle.

The planner produces named goals and explicit assertion specifications. Zod validates that structure, including the requirement that every assertion belongs to exactly one goal.

During execution, the worker observes bounded page text and accessible controls. The model receives control IDs, labels, roles, relevant form state, and previously executed actions. It chooses from a small action vocabulary: fill, click, select, navigate, assert, capture, start a fresh browser context, or complete a goal.

The model cannot submit arbitrary JavaScript, selectors, shell commands, or Playwright code. The executor owns those operations.

Assertions currently check exact visible text or exact URLs. Their expected values, observed results, and evidence references are persisted. Finalization checks the ledger before accepting a pass, and report generation checks it again. Reports are assembled deterministically, so a summarizing model cannot rewrite a failed result into a success.

One implementation problem came from the meaning of past actions. Control IDs belong to individual page observations. Earlier live runs repeated work when the model interpreted old IDs against the current page. I added execution provenance, before-and-after URLs, current-goal context, and guards against unchanged repeated actions.

The Wikipedia run exposed another practical limit: long observations could exceed the provider’s token allowance, and full-page screenshots could time out. I compacted model-facing control metadata, bounded the text sent for decisions, and switched evidence capture to viewport screenshots. Text assertions scroll their target into view before capture.

Failure handling also matters. A contradicted assertion is Failed. An unavailable target, exhausted budget, or model problem is Blocked. Worker leases expose interrupted attempts; a manual retry starts fresh browser state and retains earlier evidence.

Shared quota scheduling coordinates workers using the same database, but cannot create additional provider capacity. Exact-origin restrictions constrain browser traffic. Generated passwords are substituted by the executor, masked in screenshots, and redacted from finalized traces.

Verification includes 28 automated unit and improvement tests, eight fixture browser verification groups, and seven additional production UI groups. Fixture decisions are separate from real inference. Recorded Groq runs independently exercised working and broken persistence, and the latest public-site run passed both Wikipedia checks. Type checking, lint, and the production build also passed.

Why Does Open Innovation Matter?

For ProofPack, openness makes the automation inspectable and adaptable.

The source exposes how plans are validated, which actions are permitted, how assertions work, and how evidence becomes a report. Someone can change those rules instead of depending on an opaque demonstration service.

The adapter boundary also separates model choice from browser execution. Groq with GPT-OSS 120B is the configuration I actually verified. OpenRouter and local OpenAI-compatible endpoints are implemented, but real inference through those paths remains unverified.

The current demonstration is therefore not offline. Briefs and bounded page observations are sent to Groq. Screenshots and traces remain local.

I also keep the application’s MIT license separate from model licensing. Open components offer useful control and replacement options; they do not remove the need to validate outputs or check behavior.

The Lazy Payoff

During the build, ProofPack performed the repeated account creation, project creation, logout, fresh-session login, and persistence checks against LaunchDesk. It also performed the public Wikipedia search and collected its evidence.

That replaces a concrete sequence of manual browser interactions and evidence assembly. I did not measure a comparable manual baseline, so I am not claiming a particular number of minutes saved.

The user still defines success, configures allowed targets, reviews the proposed coverage and results, and investigates failures. ProofPack does not establish that an application is bug-free or support every website workflow.

The payoff is having the exercised steps and their evidence ready to inspect, rather than having to repeat the walkthrough and piece the explanation together afterward.

FlowMedic: Investigating Broken Automations Before You Hit Retry

Rohan Saxena — Mon, 19 Oct 2026 05:04:04 +0000

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

What I Built

An order-creation workflow times out. Do you retry it?

The workflow stopped receiving a response, but the remote system might already have created the order. Another attempt could create a duplicate.

That uncertainty is the problem behind FlowMedic, an AI-powered failure investigator for freelancers and small agencies maintaining n8n automations.

These operators connect the systems businesses depend on: lead forms, CRMs, invoices, orders, and customer notifications. When something breaks, they need to reconstruct what happened, explain it to a client, and choose a sensible next step.

FlowMedic brings that investigation into one workspace. It receives an n8n failure event, gathers available evidence, and uses Gemma running locally through Ollama to produce:

A root-cause hypothesis and explanation.
References to the evidence behind it.
A proposed fix.
Missing information and retry risk.
A recovery recommendation for a human to review.

The dashboard combines those findings with execution details, an investigation timeline, and an audit history.

The intended customer is a freelancer or agency responsible for roughly 5–50 workflows. My initial pricing hypothesis is $29/month for a solo workspace. The value to validate is having useful investigation context and recovery decisions in one place.

I haven’t established willingness to pay, implemented billing, or measured customer time savings. Those are questions for customer validation rather than claims about the MVP.

Demo

FlowMedic currently runs locally. The repository includes setup instructions and three reproducible scenarios that exercise the application pipeline.

A CRM hits its rate limit

An HTTP 429 response includes a retry delay. FlowMedic investigates the evidence and offers a human-approved, bounded demo retry.

A field gets lost in translation

The receiving step expects email, while the incoming payload contains email_address. The evidence helps the operator inspect the mapping. Replaying the unchanged workflow remains blocked.

An order request times out

The request body was sent, but its remote outcome is unknown. FlowMedic flags the uncertainty and blocks blind retry.

The scenario failures and executable recovery adapter are simulated. Model inference, database persistence, Temporal orchestration, and operator decisions are real.

I also verified the integration against a local n8n 2.43.7 instance. A production webhook deliberately failed, its Error Workflow delivered the event, and FlowMedic fetched permitted workflow and execution evidence before running a Gemma investigation.

This post includes the repository and local reproduction instructions; it does not include a hosted application or video walkthrough.

Code

View FlowMedic on GitHub

The repository includes the application, importable n8n examples, scenario fixtures, setup instructions, model evaluation reports, and verification notes.

FlowMedic’s source is MIT licensed. Model weights and dependencies retain their respective licenses.

How I Built It

FlowMedic is a TypeScript pnpm monorepo built with:

Next.js for the interface.
Fastify for ingestion and operator APIs.
PostgreSQL and Drizzle for persistent incident state.
Mastra for the investigation agent and typed tools.
Gemma through Ollama for local inference.
Temporal for durable investigation and approval workflows.

How an investigation works

First, n8n reports a failure.

FlowMedic authenticates the delivery, redacts common secrets, normalizes the event, and stores it in PostgreSQL. A database uniqueness constraint protects against duplicate deliveries.

Next, Temporal coordinates the investigation.

Five typed, read-only tools gather execution details, workflow metadata, failure context, related incidents, and retry-policy evidence.

Mastra then calls Gemma with the gathered evidence.

The backend explicitly runs the tools before generation; it does not assume Gemma supports native function calling. Native structured output and Zod validation constrain the diagnosis format.

The diagnosis and recovery proposal are persisted.

The dashboard shows the explanation, supporting evidence, missing information, and proposed next step.

Finally, the workflow waits for a human decision.

The backend independently checks recovery eligibility. A model recommendation cannot authorize a retry. Only eligible demo cases can execute the simulated recovery adapter; live n8n retries remain disabled.

Temporal handles activity retries, backoff, and the approval wait. A verified worker-restart test showed an investigation continuing with its existing diagnosis and completing one simulated recovery.

What testing taught me

The verification log records 53 passing automated tests, successful typechecks and a production build, alongside actual model-backed scenario runs.

I compared Gemma 1B and 4B using the same three fixed evidence inputs. Both passed every behavioral probe in two of the three scenarios, but they failed differently. The smaller model omitted an expected field name; the larger model identified both fields but failed a retry-recommendation check.

The real n8n test exposed another limitation: the model recognized the deliberate failure but also suggested an unsupported webhook problem.

Those results remain documented. Schema-valid output can still contain an incorrect explanation. That is why FlowMedic exposes the evidence and keeps recovery authorization outside the model.

I used Codex to help implement, test, and iterate on the project.

Why Does Open Innovation Matter?

Automation logs can contain client information. Running Gemma locally gives an operator control over where investigation evidence is processed, without requiring a proprietary model API.

Open weights also let me compare model sizes on my own machine and inspect the tradeoff between runtime and output quality. The configured model and endpoint can change without replacing the surrounding incident workflow.

Mastra and Temporal make the orchestration inspectable too: how evidence is gathered, how generation is validated, what happens when an activity fails, and how a human decision reaches a waiting investigation.

Local inference does not make the system free to operate. Hardware, electricity, hosting, and maintenance still matter. It does provide a path to running the core investigation without a required per-request commercial model bill.

The current application is a trusted local, single-operator MVP. Public authentication, multi-tenancy, billing, and live n8n recovery remain future work.

My next validation step is to put it in front of an automation freelancer and watch them investigate a failure from their own workflow.

Prize Categories

Best Use of Gemma: Gemma performs actual structured investigations over gathered evidence through local Ollama inference.
Best Use of Mastra: A Mastra agent generates diagnoses from typed, read-only evidence-tool results.
Best Use of Temporal: Durable workflows coordinate investigations, activity retries, backoff, and human approval, including a verified worker-restart path.

TrailTape: Step Outside, Come Back With a Story

Rohan Saxena — Sun, 11 Oct 2026 15:57:33 +0000

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

What I Built

TrailTape turns a short outdoor break into three observation missions and a journal grounded in your own notes.

I wanted something that gave me a reason to step outside without turning the whole walk into another activity on my phone. The workflow is simple: prepare before leaving, pay attention outside, and reflect after returning.

Choose your available time, surroundings, and interests. Gemma generates a mission card you can print or save before putting the screen away.

The card in my demo asks you to compare rustling leaves during a breeze, notice differences between two trees’ bark, and listen for bird calls. You don’t have to complete every mission.

After returning, you can type observations or record or upload voice notes. You review and correct the transcript before saving it. TrailTape then creates a field journal containing your original missions, observations, tentative reflections, and one suggestion for your next outing.

Source links let you return to the notes behind the journal. You can also revisit saved walks and export them as Markdown.

It’s for anyone who wants a small, achievable reason to get outside—especially when “go for a walk” feels too vague.

Demo

Try TrailTape

Watch the video walkthrough

The video demonstrates mission creation, audio uploads and transcription, saved observations, and the finished journal.

It is a live app walkthrough using scripted sample observations, rather than a recording of an outdoor field test.

Code

TrailTape on GitHub

The repository includes setup instructions, an environment-variable example, and verification notes.

How I Built It

TrailTape uses Next.js and TypeScript for the interface, an Express backend, Gemma for mission and journal generation, and a separate Whisper transcription adapter for audio notes. The application is deployed on Render.

Gemma has two roles:

Before an outing, it turns the user’s time, setting, and interests into short observation tasks.
Afterwards, it organizes saved notes into a journal and proposes a follow-up mission.

The backend validates structured model responses with Zod before the interface uses them. Journal observations retain the saved note text, and source references connect generated sections to their inputs. That makes the output easier to inspect, though it doesn’t guarantee every interpretation is correct.

Transcription is deliberately editable. A recording shouldn’t become the final record until the person who made it has checked what the model heard.

An early journal felt too generic. I refined the prompts to ask for more specific missions and reflections tied to the notes, then made the original missions and source notes easier to find in the finished journal.

Deployment also exposed a practical issue: the production install skipped the development dependencies needed to compile TypeScript. Including those dependencies during the build fixed it.

Walk history stays in browser storage. Generation and transcription use hosted APIs, so this version requires internet access and sends the relevant inputs to those providers.

I used Codex to help implement and iterate on the project.

Why Does Open Innovation Matter?

Gemma’s open weights give TrailTape options beyond one hosted API. They make it possible to explore other hosting arrangements or a future local version, subject to the model’s terms and hardware requirements.

That flexibility matters for an application built around personal observations. I chose hosted inference for this version, but local processing is a direction I can explore without replacing the core model family with a proprietary alternative.

Generation and transcription are separate adapters, which helps keep provider-specific code out of the interface. Changing providers would still need implementation and testing, but the application isn’t built entirely around one provider’s client library.

The source-linked journal reflects another priority: people should be able to inspect what the system produced. A reader can return to the original observation and decide whether a reflection is supported.

Prize Categories

Best Use of Gemma: Gemma powers the observation missions and the journal generated from saved notes.
Best Use of Render: Render hosts the Next.js interface and Express API together, providing the public application linked above.