DEV Community: Mir Shah

Nyvo is finally live.

Mir Shah — Fri, 21 Aug 2026 17:45:46 +0000

AI wallpapers, personalized to you.

After a lot of building, testing, breaking things and fixing them again, Nyvo is officially live on Android.
Nyvo creates wallpapers around you and gives your phone something new every day.
The best part? Your next wallpaper can be created and set automatically, without even opening the app.

New day. New wallpaper.

Try Nyvo on Google Play →

Would love to hear what you think.

PawArt | Letting a Dog Help Create Its Own Portrait

Mir Shah — Sun, 16 Aug 2026 18:10:46 +0000

This is a submission for Weekend Challenge: Dog Days Edition

PawArt

Every bark becomes art.

Your dog. Their bark. Their masterpiece.

Most pet art begins with a human choosing the colors, the mood, and the style. But dogs already bring a personality of their own. Their voices can be bright, gentle, restless, or wonderfully dramatic. PawArt begins there, by listening to the dog and letting the bark guide the canvas.

What I Built

The simple idea that started PawArt

I wanted to answer one playful question:

What would a bark look like?

PawArt is a mobile app that turns a dog's photo and a few seconds of barking into a unique portrait. I like to explain it this way: the photo tells PawArt who to paint, while the bark helps decide how to paint them.

PHOTO
Meet the artist

→

BARK
Hear their voice

→

GEMINI
Shape the style

→

PAWART
Reveal the portrait

A lively bark might inspire bright color, bold contrast, and restless brushwork. A softer recording might create deeper tones, gentle texture, and more breathing room in the composition. It means the dog has a real influence on the final result instead of simply appearing inside a style someone else picked.

The result screen reveals the bark fingerprint behind the piece, including energy, pitch, rhythm, intensity, bark count, and pauses. The original bark can also be replayed beside the artwork it helped create.

One thing that mattered to me: PawArt does not claim to translate a dog's thoughts or feelings. It only uses measurable sound characteristics as creative controls for the artwork.

Demo

The complete experience in sixty seconds

One bark becomes a portrait in one minute

Watch the demo on YouTube

The recording studio and the finished masterpiece.

A small note from behind the demo

My dog is at home with my family while I am currently staying in a hostel. I used a saved photo and played a recorded bark from another phone. The app still captured that sound and sent it through the real analysis and generation flow shown in the video.

How I Built It

What happens after the record button is pressed

I wanted the app to feel easy even though quite a lot happens behind it. Once the user taps Create PawArt, the process moves through three small stages.

01 · Capture

I built the mobile app with Expo, React Native, and TypeScript. The user chooses a dog photo, records a short bark, and sees a live waveform move with the sound. I spent a lot of time on this part because recording audio can easily feel like filling out a form. I wanted it to feel more like giving the dog a tiny studio session.

The photo and recording then move into private Supabase Storage buckets. No Google credential ever enters the mobile app.

02 · Listen

A Supabase Edge Function securely sends both the photo and audio to Gemini 3.7 Flash through Google's official API.

Gemini looks for measurable qualities such as energy, pitch, rhythm, intensity, bark count, and pauses. PawArt then turns those qualities into a visual language.

HIGH ENERGY
Dynamic composition

BRIGHT PITCH
Luminous palette

RAPID RHYTHM
Active brushwork

STRONG SOUND
Bold contrast

> Style: Expressive impressionism
> Palette: Warm gold, orange, and crimson
> Composition: Energetic and alive
> Brushwork: Sweeping and bold

I chose a structured response because I did not want the generated image to feel random. It lets the app show how the voice influenced the canvas, and it also keeps each stage predictable enough to build around.

03 · Paint

The original photo and the new art direction are passed to Gemini 3.1 Flash Image, also known as Nano Banana 2.

The prompt asks the model to preserve the dog's recognizable eyes, ears, muzzle, coat colors, markings, and proportions. The bark still controls the visual treatment, so a different recording creates a meaningfully different portrait. Getting this balance right was the most interesting part of the build.

One dog. A different bark. A different canvas.

Why I chose Supabase

I used Supabase because it gave me one place for the files, database, and server logic. More importantly, it meant the Google API key could stay on the server instead of ending up inside the Expo app.

STORAGE
Private photos, audio, and art

EDGE FUNCTION
Secure Google AI requests

POSTGRES
Bark and artwork metadata

SIGNED URLS
Temporary access to results

The repository includes the database migration, private Storage buckets, file restrictions, Row Level Security policies, secrets configuration, and Edge Function deployment steps. The complete walkthrough is available in the Supabase setup guide inside the README.

Code

Run it, inspect it, or build on top of it

PawArt is open source.

The repository contains the Expo app, Supabase backend, database migration, and Google AI Edge Function.

abbasmir12 / pawart

PawArt

Every bark becomes art.

Your dog. Their bark. Their masterpiece.

Built for the DEV Weekend Challenge: Dog Days Edition
Competing for Best Use of Google AI

What is PawArt?

PawArt is a mobile creative studio that turns a dog's photo and a short bark recording into a recognizable, one-of-a-kind portrait.

The bark is not treated as a secret language. PawArt measures acoustic characteristics—energy, pitch, rhythm, intensity, bark count, pauses, and duration—and uses them as creative controls for palette, composition, contrast, and brushwork.

PawArt never claims to translate a dog's thoughts, needs, intentions, or emotions. Sound characteristics guide the artwork only.

The experience

Step	What happens
01 · Add a photo	Take a clear dog photo or choose one from the gallery.
02 · Record the bark	Capture 3–10 seconds with a live microphone waveform.
03 · Read the sound	Gemini analyzes measurable acoustic characteristics.
04 · Find the art

…

View on GitHub

Want to create your own PawArt?

Everything needed to run, understand, and extend the project is waiting in the repository.

OPEN THE SOURCE

Explore the complete PawArt code

BUILD IT YOURSELF

Follow the full Supabase guide

SEE HOW IT IS SECURED

Understand secrets and private files

Prize Categories

Best Use of Google AI

One model listens. One model paints.

Gemini 3.7 Flash

Studies the photo and bark, then writes the creative direction.

Nano Banana 2

Preserves the dog and turns that direction into the final portrait.

Google AI is at the center of the idea, rather than being something I added just to qualify for the category. Gemini turns an ordinary recording into useful art direction. Nano Banana 2 turns that direction into an image while keeping the actual dog recognizable. Together, they connect the dog's voice to the finished canvas.

Every dog already has a voice.

PawArt gives that voice a canvas.

I built PawArt because the small sounds we hear every day can hold memories. A familiar bark is part of a dog's personality and part of the feeling of having them nearby. Turning it into art feels more personal to me than adding a filter to a photo. The final portrait is shaped by both how the dog looks and how they sound.

PawArt started as a fun weekend idea, but somewhere during the build it began to feel like a small way of saving a moment with a companion. If someone uses it, smiles at the result, and immediately wants to try another bark, then it has done exactly what I hoped it would do.

Your dog. Their bark. Their masterpiece.

Every bark becomes art.

I Used Sentry to Expose a Silent Data-Loss Bug with Zero Errors

Mir Shah — Sat, 15 Aug 2026 15:08:13 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

40 successful saves. 39 missing workspaces.

The application did not crash. No exception was thrown. Every promise resolved.

And that was exactly why this bug was dangerous.

The front-page lesson: A green “success” proves that an operation finished. It does not prove that its result is still there.

THE FOUR-MINUTE FIELD REPORT

IN THIS EDITION
The project · The incident · The patch · The safeguards · The signal

SECTION I · THE PROJECT DESK

Project Overview

Last month, I built Aether Canvas during OpenAI Build Week.

It is a local-first Electron application where spatially grouping ordinary files creates the mini-app you need. Put a flight confirmation, hotel booking, budget, packing list, and city guide together, for example, and Aether turns the cluster into a living trip workspace with routes, spending, tasks, and places—all traceable to the source files.

The idea is simple:

Space is the prompt.

But the build was anything but simple. It was a one-week hackathon, and those seven days had to cover validating the idea, designing the architecture, building the interface, connecting the AI workflow, testing the main experience, and preparing the final demo and presentation.

We shipped a working product. We did not have enough time for deep concurrency and persistence stress testing.

WHAT WE SHIPPED

A real local-first Electron product: spatial files, AI-generated workspaces, autosave, persistence, and a polished demo path.

WHAT THE CLOCK HID

The main experience worked, but the one-week schedule left little room for simultaneous-operation and shutdown stress tests.

I also chose not to modify the original submitted repository before the winner announcement. I wanted the artifact being judged to remain exactly as submitted. Instead, I created a separate Bug Smash repository, with the submission preserved at commit 3163641a and tagged openai-hackathon-submission.

That gave me something unusually valuable for debugging: an untouched before state.

SECTION II · INCIDENT REPORT

Bug Fix or Performance Improvement

The bug hid behind successful writes

Aether stores each workspace in its own JSON file and keeps a separate index containing the workspaces visible in the sidebar.

The original implementation already used atomic temporary-file replacement and a write queue. At first glance, that looked safe. After tracing the workspace IPC calls, autosave path, rename path, and persistence service, I found the boundary was in the wrong place.

✓ WHAT WAS SAFE

Each individual JSON replacement was atomic. A partial write would not leave behind a half-written index.

✕ WHAT WAS NOT SAFE

The read and modification happened before the queued write, so two complete operations could still overwrite one another.

The queue protected an individual JSON write:

const operation = writeQueue.then(async () => {
  await fs.writeFile(temporaryPath, contents, 'utf8');
  await fs.rename(temporaryPath, targetPath);
});

But updating the workspace index is not one write. It is a complete read → modify → write transaction:

Create A: read index [] ── add A ── write [A]
Create B: read index [] ── add B ── write [B]
                                      ▲
                     both writes succeed; A disappears from the index

Two operations could read the same old index before either write entered the queue. Both would make a perfectly valid update. Both writes would complete successfully. The last valid-but-stale snapshot would win.

No malformed JSON. No rejected promise. No crash for error monitoring to catch.

Just a workspace file that still existed on disk but was no longer reachable from the application.

Making a timing bug repeatable

I did not want to hammer the UI with clicks until I got lucky. I built deterministic before/after harnesses that run the same workloads against two real implementations:

🔴 BEFORE

Loads the authentic workspace service directly from submitted commit 3163641a with git show—not from a hand-written broken copy. 🟢 AFTER

Loads the repaired service from the Bug Smash branch and subjects it to the exact same operations and assertions.

The workload creates 40 workspaces simultaneously, then runs 20 autosave-versus-rename races. Each stage uses an isolated temporary Electron profile, opens the real desktop UI with the resulting data, and deletes that data after the window closes. My actual Aether spaces are never touched.

npm run bugsmash:before -- --sentry
npm run bugsmash:after -- --sentry

The harness also refuses to present an inconclusive result: the before stage must reproduce the legacy failure, and the after stage must preserve every mutation.

Identical workload	Original submission	Repaired version
Workspace files written	40 / 40	40 / 40
Workspaces reachable in the index	1 / 40	40 / 40
Orphaned workspace files	39	0
Autosave/rename trials that lost a mutation	20 / 20	0 / 20

The number that changed the investigation

40 files existed on disk. Only one existed to the user.

SECTION III · THE PATCH DESK

Code

CASE FILE	EVIDENCE
Merge request	Review Merge Request !1 and the complete diff
Repair commit	`57fc12a` — transaction-safe persistence
Public repository	Aether Canvas Bug Smash

The heart of the repair is intentionally small. A failure-safe exclusive queue now surrounds the complete public operation:

const runExclusive = async <T>(operation: () => Promise<T>): Promise<T> => {
  pendingOperations += 1;
  const queued = operationQueue.catch(() => undefined).then(operation);
  operationQueue = queued.then(() => undefined, () => undefined);

  try {
    return await queued;
  } finally {
    pendingOperations -= 1;
  }
};

Every workspace mutation now crosses that boundary as one unit:

return {
  list: () => runExclusive(readIndex),
  create: (name) => runExclusive(() => create(name)),
  load: (id) => runExclusive(() => readJson(filePath(id))),
  save: (workspace) => runExclusive(() => save(workspace)),
  rename: (id, name) => runExclusive(async () => {
    const workspace = await readJson(filePath(id));
    await save({ ...workspace, name: name.trim() || 'Untitled Space' });
  }),
};

Now a create or rename finishes reading, modifying, and persisting its state before the next operation begins. A rejected operation is absorbed only for queue continuity and is still returned to its original caller, so one disk failure cannot permanently poison later saves.

Explore the complete before/after repository

SECTION IV · ENGINEERING FOLLOW-THROUGH

My Improvements

Fixing the index race exposed two nearby assumptions that also needed attention. I treated this as one persistence-integrity repair rather than stopping at the first passing test.

01 · TRANSACTION BOUNDARY One long-lived store and one exclusive queue protect every complete persistence operation.	02 · SAVE REVISIONS A newer edit cannot be cleared by the completion of an older in-flight save.
03 · CLOSE HANDSHAKE Electron waits for the renderer's latest snapshot before destroying the window.	04 · REGRESSION PROOF Six deterministic tests protect the failure modes instead of merely mirroring the implementation.

1. One store, one transaction queue

The Electron main process now keeps one long-lived workspace store across IPC handlers. Creating a new store per request would create multiple queues and quietly defeat serialization.

2. Revision-aware autosaving

The renderer previously used a boolean dirty flag. That is not enough when a new edit arrives while an older save is still running: completion of the older save can clear the flag belonging to the newer edit.

The new saver tracks revisions and drains until the saved revision catches the latest one:

while (this.latest && this.savedRevision < this.revision) {
  const snapshot = this.latest;
  const revision = this.revision;
  await save(snapshot);
  this.savedRevision = revision;
}

If revision 2 arrives while revision 1 is being written, revision 1 cannot declare revision 2 safe. The loop writes again.

3. A real close handshake

An asynchronous beforeunload callback cannot force Electron to wait before destroying its renderer. The main process now intercepts the close request, asks the renderer to drain its latest snapshot, and closes the native window only after the renderer acknowledges completion.

4. Regression tests for the failure, not just the implementation

The six deterministic tests cover:

40 concurrent creates preserving 40 unique index entries;
autosave racing rename while preserving both mutations;
queue recovery after a rejected operation;
a newer edit arriving during an active save;
retrying a failed snapshot write without losing dirty state; and
count-only integrity auditing for orphaned and missing files.

Strict TypeScript checks, the renderer/main/preload production builds, and Linux AppImage packaging also pass with the repair.

Reproduce the controlled comparison locally

git clone https://gitlab.com/abbasmir12/aether-canva-bugsmash.git
cd aether-canva-bugsmash
git switch fix/workspace-transaction-race
npm install
npx vite build

# Run each stage separately so the real Electron state remains visible.
npm run bugsmash:before
npm run bugsmash:after

# Or print both results without opening two staged windows.
npm run bugsmash:demo

The Sentry flag requires your own DSN. The reproduction itself does not.

SECTION V · OBSERVABILITY DESK

Best Use of Sentry

I am submitting this entry for Best Use of Sentry.

Sentry had a specific job here: make a silent logical invariant observable.

It would be inaccurate to say that Sentry magically discovered the source line or repaired the race. Code inspection and deterministic stress tests found the transaction-boundary bug. Sentry then gave me runtime evidence that the application could report successful operations while its persisted state was inconsistent—and confirmed that the repaired build remained consistent under the identical workload.

WHAT SENTRY DID

Recorded queue pressure, operation duration, and the count-only workspace integrity invariant in the running Electron application.

WHAT SENTRY DID NOT DO

It did not invent the root cause or upload the user's workspace. Code inspection and tests located the faulty transaction boundary.

Operation tracing

Using the Sentry Electron SDK, every workspace IPC operation creates a custom transaction containing only:

the operation type, such as create, save, or rename;
queue depth; and
duration.

This made serialization pressure visible. For example, an authenticated workspace.create trace showed a queue depth of 10 and a root duration of approximately 175 ms. A successful span status alone, however, could not reveal the hidden loss. For that I needed a product-level invariant.

The integrity transaction

The opt-in workspace.integrity-audit compares the index with the workspace directory locally and reports only aggregate counts:

attributes: {
  'aether.workspace.files_count': audit.workspaceFiles,
  'aether.workspace.indexed_count': audit.indexedWorkspaces,
  'aether.workspace.orphaned_count': audit.orphanedFiles,
  'aether.workspace.missing_file_count': audit.missingFiles,
  'aether.workspace.integrity_consistent': audit.consistent,
}

span.setStatus(audit.consistent
  ? { code: 1, message: 'ok' }
  : { code: 2, message: 'data_loss' });

The original run produced:

files_count          40
indexed_count         1
orphaned_count       39
integrity_consistent false
status               data_loss

The repaired run produced:

files_count          40
indexed_count        40
orphaned_count        0
integrity_consistent true
status               ok

🔴 BEFORE
SILENT DATA LOSS

40 files · 1 indexed
39 orphaned · data_loss

│
│
│
│
│
│
│
│
│

🟢 AFTER
INTEGRITY RESTORED

40 files · 40 indexed
0 orphaned · ok

THE TRACE'S STRANGEST HEADLINE
Issues: 0 · Orphaned workspaces: 39

Traditional exception monitoring was telling the truth—nothing threw. The integrity transaction supplied the missing definition of correctness.

Observability without uploading the workspace

Aether is local-first, so the instrumentation had to respect that promise. The custom telemetry never includes workspace names, IDs, paths, file contents, canvas content, AI prompts, or AI responses. Transaction hooks remove user, request, extra, and breadcrumb payloads; UI-click breadcrumbs are disabled; raw IP storage is disabled in the Sentry project; and an advanced scrubbing rule removes user.geo.

This was also a useful lesson: observability is not only about collecting more information. Sometimes it is about identifying the smallest safe signal that proves the system is healthy.

FINAL EDITION · THE QUIETEST FIXES CAN PROTECT THE MOST IMPORTANT DATA

A deliberately boring result

Save a workspace, and it stays saved.

That is the point.

No flashy new feature, just 39 workspaces recovered in the controlled stress scenario, zero lost autosave mutations, and a save operation that finally means saved.

I hate my scattered documents & file, so I built this canvas

Mir Shah — Mon, 27 Jul 2026 10:05:59 +0000

Built for OpenAI Build Week

Aether Canvas

What I Built

Aether Canvas A spatial workspace that builds itself

I built a workspace that reads your files and decides what it should be.

An actual desktop app where you drop PDFs, spreadsheets, documents, notes, and images onto an infinite canvas, and it reads all of them, works out what connects them, and generates an interactive workspace shaped by what it found. Different files produce a different workspace. That's the whole point.

Here's the observation it started from. A folder is a container. It holds your files and it has never once understood them. Every piece of software we use to organize knowledge throws away the two most useful signals we give it: what's actually inside the documents, and how we chose to arrange them.

So I tried to build the opposite. Something where both of those signals are the input.

It's called Aether Canvas. You drop files anywhere on the canvas. It reads what's inside them, discovers the relationships across formats, and builds a view around that context. Ask a question against the entire workspace and every answer traces back to the file and location it came from. Local-first, so the workspace never leaves your machine.

Demo

Why it's a desktop app and not a web demo

Aether is local-first by design. Your files stay on your machine, the workspace index is written to local storage, and nothing gets uploaded to a server to be processed and held.

A hosted demo would mean the opposite of that. So instead of a link that borrows your files, there's an installer that runs on yours.

Try It

You don't have to build it. There's a signed installer — v1.0.0, Windows x64, no build step and no keys to paste in.

Download Aether Canvas for Windows

Install it, drag a folder onto the empty canvas, and wait for the edges to appear. Then ask it something you'd normally have to open six files to answer.

Prefer to build from source

git clone https://github.com/abbasmir12/aether-canvas
cd aether-canvas
npm install
npm run dev

Code

abbasmir12 / aether-canvas

A generative desktop where dropping files onto a spatial canvas builds living, AI-powered workspaces — powered by GPT-5.6. Space is the prompt.

Aether Canvas

Space is the prompt.
A generative desktop where grouping ordinary files creates the mini-app you need

OpenAI Build Week 2026 · Apps for Your Life · Built with Codex + GPT-5.6

Watch the demo · Devpost · See the product · Run Aether · GPT-5.6 · Build story

Five source files, four semantic streams, one GPT-generated interactive workspace—captured from the running Electron app.

Five files in. One living workspace out.

A normal folder sees filenames. Aether sees the trip, project, course, budget, or plan they describe together.

CONCEPTUAL WORKFLOW · CLICK A CHAPTER
A hand-drawn explanation of the idea, not a screenshot of the application. Select any panel to inspect the real files, architecture, or product evidence behind it.

01 · Start with files

Open the exact sample files used in the demo.

02 · Understand context

Follow the implemented GPT-5.6 data flow.

03 · Become useful

See…

View on GitHub

How I Built It

The input surface is a blank canvas

There is no import wizard.

No project setup, no schema to define, no tagging step, no folder structure to mirror. You drag files onto empty space and put them where they feel like they belong. That gesture is the only configuration the app asks for.

The core design decision

Position is information. When you put two files side by side, you mean something by it. Every tool I've used throws that signal away the moment you close the window.

Five stages, not one prompt

I didn't want this to feel like "point an LLM at a folder and get a summary." So I split the work the way you'd actually split it.

01 — The Drop

Files land on an infinite canvas. Any format, any arrangement, no setup.

02 — The Read

GPT-5.6 extracts what each file actually contains. Not filenames, not metadata. The claims, figures, dates, and entities inside.

03 — The Relate

Cross-format relationship discovery. A date in a PDF resolving a blank cell in a spreadsheet. A name tying a paragraph to a row.

04 — The Render

The workspace view is derived, not templated. Trip, knowledge map, or operational board — whichever the content actually supports.

05 — The Answer

Query the whole workspace at once. Every response carries the file and location it came from.

The hard part was not the canvas

My first version linked anything that shared a keyword.

Every node connected to every other node.

Technically correct. Completely useless.

The relationship principle

The real problem is deciding when two files are actually related versus merely similar. That distinction is the entire difference between a workspace and a hairball.

What worked was making the model justify each edge before it could draw one. A relationship has to name the specific thing it's built on, this date, this figure, this entity, and that evidence has to resolve to a location in both files. If it can't point at both ends, the edge doesn't exist.

Similarity alone was demoted to a weak signal that affects layout suggestions but never draws a line. Shared topic is not a relationship. Two papers about the same subject that never touch each other's claims are just two papers.

The rules the relationship engine runs on

"An edge must cite a specific shared element and resolve it to a location in both source files. Thematic overlap is not sufficient."

"Never infer a fact that appears in neither document in order to justify a connection."

"Contradiction is a first-class relationship. Two sources disagreeing is more useful than two sources agreeing, and must never be collapsed into consensus."

"Confidence must be surfaced, not hidden. A weak edge is drawn weakly or not at all — never drawn as certain."

"Spatial proximity raises the prior on a relationship. It never creates one on its own."

Same app, three different workspaces

A travel folder

Boarding passes, a hotel confirmation, a messy notes file, a budget sheet. Dates reconciled across all four, costs rolled up, each location linked back to the document that confirmed it. Ask what's actually booked versus still tentative.

Research material

Twenty papers, three sets of notes, a screenshot of a diagram you can no longer place. Where the authors agree, where they contradict each other, which claim came from which page. Ask which of them disagree on methodology.

Project documents

Specs, a status deck, an email thread, a tracker. The actual state of the project rendered as a view instead of a directory listing that tells you nothing. Ask what's blocked and who owns it.

Local-first, and that shaped everything

The constraint I'm most glad I kept

Nothing about your workspace is stored on my infrastructure, because there is no infrastructure.

The canvas state, the extracted content, the relationship graph, and the generated views are all written to local storage on your machine. Electron with React and TypeScript for the shell, React Flow for the canvas, Codex for the build loop.

That constraint made a few decisions for me. Indexing has to be incremental, because there's no cluster to brute-force a re-scan. The graph has to be cheap to hold in memory. And every answer has to cite a local file path, which turned out to be the feature people trust most.

No upload step

Files are read where they already are.

No server-side index

The graph lives next to your files.

Traceable by default

Every answer resolves to a path and a location inside it.

What I Want To Know

Does it hold at scale

I'm not convinced folders are the ceiling of how we work with our own information. I'm also not convinced a canvas is the answer — it might just be a prettier mess once you pass a few hundred files.

Where would you break it

The most useful comment isn't "cool project." It's the file collection you think would turn this into an unreadable web of edges. Tell me what you'd drop on it first, and where you think it falls apart.

I'd genuinely value the feedback, I've been staring at this thing alone for long enough that I've stopped being able to see it clearly. Tell me what's wrong with it in the comments, and if you try the build, tell me what broke.
And if you think the idea is actually worth something, star ⭐ the repo. That's the honest signal, and it's the thing that decides whether this stays a Build Week project or becomes something I keep going.

Aether Canvas v1.0.0 · Windows x64 · local-first

Drop your files in. See what they were trying to tell you.

Download Aether Canvas for Windows

Source, architecture notes, and issues → github.com/abbasmir12/aether-canvas

One More Year -> The Documentary I Never Filmed

Mir Shah — Sun, 12 Jul 2026 19:58:49 +0000

This is a submission for Weekend Challenge: Passion Edition

One More Year

What I Built

I built a documentary studio.

One More Year An AI documentary studio

Not a template with your name dropped in. An actual small production pipeline that reads four things you tell it, decides what your story is, casts it with real performed voices, builds its own sound design, writes its own score, and prints a real mp4. All in the browser.

Here's the observation it started from. Everyone has one thing they can't quit. Football, chess, a piano someone left them, a side project nobody asked for. And almost none of that ever becomes anything, because turning "the thing I can't stop doing" into something that actually feels like a documentary normally takes a camera crew, actors, a sound engineer, and about a week of editing.

So I tried to compress that whole crew into five automated desks and see how close I could get.

It's called One More Year. You answer four questions. It gives you back a short film with a narrator, you as the subject, and a couple of extra voices pulled from inside your own story: memory, doubt, whatever the piece needs. Every voice is performed, not read. Every sound effect is chosen for that scene. Every score is composed fresh. It's all mixed and encoded into a real video file without a render server ever touching it.

Demo

Why there is no hosted public demo

There's no hosted public demo. That's on purpose.

The ElevenLabs key is kept server-side only, so it never reaches browser JavaScript. Hosting it publicly would mean putting my own paid key on the open internet for strangers to spend. So instead, the whole thing runs locally in about two minutes, with your own free Gemini key and your own ElevenLabs key.

git clone https://github.com/abbasmir12/onemoreyear
cd onemoreyear
npm install
npm run dev

Open the Press Room, drop in a key, hit Start Your Story. Headphones on.

Code

abbasmir12 / onemoreyear

An Open Source documentary studio for the things you cannot quit - directed by Gemini, performed by ElevenLabs

ᴏɴᴇ ᴍᴏʀᴇ ʏᴇᴀʀ

An open-source documentary studio for the thing you cannot quit.

Built for the DEV Weekend Challenge: Passion Edition — July 10–13, 2026

Everyone has one thing they can't quit.

Most tools would ask you to write it down. This one asks you to say it out loud — then hands it to a director, a cast, a sound desk, and a print desk, and gets you back a real short film.

What it actually does

You answer four questions. Nothing technical — just what's the thing you can't quit, when did it almost end, why did you stay, and one line only you would say. That's the entire brief.

From there, a real production pipeline runs — not a template filled in, not a single flat voice reading a script. An AI director reads what you gave it, decides what the story actually is, and hands it…

View on GitHub

How I Built It

The four questions

The input surface is deliberately tiny.

What's the thing you can't quit. When did it almost end. Why did you stay. One line only you would say. No writing, no script, no timeline editor.

That constraint is the actual design decision. Asking someone to write a story gets you a self-conscious kind of writing. Asking them a direct question at 2am gets you something else entirely.

The core design decision

Five desks, not one prompt

I didn't want this to feel like "type something, get an AI blob back." So I split the work the way a real production would split it.

01 — The Interview

Four questions. No writing required.

02 — The Director

Gemini reads your answers, finds the arc, and writes a full script. It casts a narrator, you, and one or two symbolic voices pulled from inside the story itself.

03 — The Cast

Every voice is performed through ElevenLabs eleven_v3. Hesitations, corrections, a line that actually breaks where it should.

04 — Sound & Score

The director decides what a scene needs, generates that exact effect, then composes an original score through ElevenLabs Music v2.

05 — The Print

ffmpeg.wasm mixes every voice, effect, and cue against the frames and encodes a real mp4. Client-side. No render server.

The director doesn't summarize. It directs.

My first version of the prompt just asked Gemini to turn the answers into a short documentary.

What came back read like a summary with quotation marks around it.

Competent. Flat. Forgettable.

What worked instead was telling it to behave like a documentary editor. Find the arc, not the facts.

The directing principle

Cast a narrator and the subject, then add one or two symbolic voices, like memory or doubt. Those voices are explicitly not allowed to invent facts or pretend to be real witnesses.

Write two versions of every line. A clean transcript, and a separate performance string with sparse, motivated imperfections: a repeated word, a false start, a line that catches. Most lines stay clean, so the handful of imperfect moments actually mean something.

Every scene also gets a director-chosen transition. Direct, sound, or silence. The first scene is mandatory sound, because a documentary that opens on a voice mid-sentence with nothing behind it doesn't feel like one.

Read the actual rules I gave the AI director

A few of the real constraints from the production prompt, word for word:

"Symbolic voices are fragments of the subject's interior story, not factual witnesses. They must never claim to be a coach, friend, rival, family member, or person who was present."

"Never invent a quote, date, injury, achievement, relationship, or event the person did not provide."

"Human speech is not polished prose. In only 2 or 3 segments across the entire film, add ONE motivated imperfection. Never sprinkle random 'um' sounds everywhere."

"Segment 1 MUST use 'sound' for 4–5 seconds before anyone speaks. Establish the physical world first."

"Every film gets a score. If the story calls for restraint, choose 'instrumental' and keep it sparse, rather than skipping the score entirely."

The cast, the room tone, the score

The Cast

Every performed line goes through eleven_v3.

The Room Tone

Every scene's ambience, a stadium, a stairwell, rain on a tin roof, is a real generated sound effect chosen for that specific beat. Not a stock loop reused everywhere.

The Score

Every film also gets an original score through Music v2. The director can choose instrumental, vocal, or hybrid, but never nothing. A quiet story doesn't mean a silent one. It means a sparser score, not an empty desk.

Printed with ffmpeg, not on a server

This is the part I'm most proud of.

The part I'm most proud of

The final assembly happens with ffmpeg compiled to WebAssembly, running client-side. Timing every voice line against its lead-in. Layering sound effects at the right offsets. Ducking the score under dialogue. Encoding the whole thing to H.264.

No render queue

No render queue.

No upload and wait

No upload and wait.

A real downloadable file

The browser does the actual video engineering and hands you back a downloadable file.

Prize Categories

Best Use of Google AI

Best Use of Google AI. Gemini directs the entire piece: structured JSON output for the script and cast, image generation for the frames.

Best Use of ElevenLabs

Best Use of ElevenLabs. Every voice, every sound effect, and every score in the film is generated live through eleven_v3, the Sound Effects API, and Music v2.

https://github.com/abbasmir12/onemoreyear

ORVIX, Open-source Self-Organizing AI Engineering Company

Mir Shah — Tue, 07 Jul 2026 14:12:06 +0000

I Built an Open-Source AI Engineering Company Instead of Another AI Agent

For the past year, AI coding agents have become incredibly capable.

But almost all of them still follow the same idea:

One increasingly capable AI should build everything.

I wanted to explore the opposite.

What if the AI wasn't the engineer? What if it became the entire engineering company?

That's how Orvix started.

Meet Orvix

Orvix is a self-organizing AI engineering company.

You don't create agents manually or decide how many are needed.

You simply describe the mission.

From there, Orvix designs the project, creates exactly the specialists required for that mission, assigns ownership, coordinates their work, reviews their pull requests, and even creates entirely new specialists later if the project grows.

Every mission creates a different engineering company.

Building software like a real engineering team

Instead of one AI jumping between frontend, backend, infrastructure, testing and documentation, Orvix treats them as independent engineers.

Each specialist owns its own Git branch.

They work in parallel.

They negotiate decisions.

They review one another's work.

They communicate through the Orvix Book, a shared communication layer where engineers ask questions, request clarification, share discoveries, and coordinate their work instead of sharing one giant conversation.

The goal isn't just generating code.

It's organizing engineering.

Local first. Cloud when you need it.

One thing I wanted from the beginning was flexibility.

Orvix can run completely on your own machine if you want everything local.

Or you can deploy the Orvix runtime on Alibaba Cloud ECS, allowing anyone on your team to connect to the same engineering company remotely while every mission, every specialist, and the entire execution live on the server.

For this hackathon, Orvix was deployed on Alibaba Cloud and powered by Qwen Cloud (Alibaba Cloud Model Studio).

There's much more behind it

This post only scratches the surface.

The repository includes detailed documentation covering:

the complete architecture
the Orvix Map
the Orvix Book
the planning pipeline
dynamic specialist creation
mission lifecycle
deployment on Alibaba Cloud
and the reasoning behind the system's design.

If you're curious about how an AI engineering company actually works, I'd love for you to take a look.

Links

GitHub

https://github.com/abbasmir12/orvix

Documentation

https://github.com/abbasmir12/orvix/tree/main/docs

Demo

https://youtu.be/ZzocAW0nbTs

I'd love to hear what you think. If you have ideas for improving Orvix or thoughts about multi-agent engineering systems, feel free to share them.

Among Liars -> The 7th Player Isn't Human

Mir Shah — Sat, 20 Jun 2026 11:24:32 +0000

This is a submission for the June Solstice Game Jam.

I built Among Liars, a realtime multiplayer elimination where six humans join a room, but the game secretly adds a seventh player: a Gemini-powered AI hiding inside the Spy side.

There are two teams:

Detectives are trying to expose the hidden AI.
Spies are trying to protect the AI long enough for the Detectives to run out of chances.

The game is inspired by the Turing Test, but instead of asking "Can AI answer like a human?", it asks something more playable:

Can AI survive being socially judged by humans?

When the game begins, six human players are split into two teams: three Detectives and three Spy Agents. A hidden Gemini-powered AI is then added to the Spy side, creating a team of four spies. The Detectives must identify the AI, while the Spy Agents work together to keep it hidden.

Each round starts with a 2-minute warmup where teams can plan in private rooms. Detectives discuss who feels suspicious. Spies coordinate how to protect the AI.

Then one Detective asks a wildcard-style question to the Spy side. The question is automatically sent to every living Spy player and also to the Gemini AI. Everyone answers under pressure, and the Detective has to read the answers like evidence.

The trick is that Spy-side players receive new cover names every round, so Detectives cannot simply track the AI by name or position. They have to judge tone, timing, weirdness, confidence, and emotional detail.

A question like:

"Describe a tiny mistake you made today without making it sound important."

is much harder than a normal trivia question because it asks for texture, not correctness.

That is where the game becomes interesting.

Sometimes AI sounds too polished.

Sometimes humans sound fake on purpose.

Sometimes the suspicious answer is suspicious because it is AI.

Sometimes it is suspicious because a Spy is protecting the AI.

That tension is the core of Among Liars.

You can play it here:

Live Demo: https://amongliars.vercel.app

Video Demo

Live App

https://amongliars.vercel.app

GitHub Repository

https://github.com/abbasmir12/amongliars

How I Built It

The frontend is built with:

React
Vite
Framer Motion

and a custom black-and-white visual style.

The backend uses Supabase for:

Room creation
Random matchmaking
Player state
Role assignment
Realtime chat
Private team rooms
Round state
Answer storage
Eliminations
Win conditions

I used Supabase Realtime instead of a custom WebSocket server, so messages, answers, player changes, and round changes update live across browser tabs and devices.

The game includes:

6-player waiting room with automatic countdown
Private role reveal
Detective-only and Spy-only private rooms
Public chat
2-minute planning/warmup phase
Rotating Spy cover names every round
Wildcard question flow
90-second Detective question window
45-second Spy answer window
30-second Detective final read window
Gemini AI answer generation
Evidence cards
Detective guess phase
Round result screen
Eliminated player tracking
Detective/Spy win states

Round Flow

Each round is designed to feel like a small interrogation.

First, there is a 2-minute warmup. During this time everyone can continue talking publicly, but the private rooms are where the real strategy happens.

Detective Strategy Room

Detectives discuss:

Who sounds too clean
Who is avoiding pressure
What question would expose the AI
Which answer patterns felt suspicious in previous rounds

Spy Strategy Room

Spies coordinate:

How to protect the hidden AI
How messy or natural their answers should feel
Whether to draw suspicion away from one player
How to make the room harder for Detectives to read

After warmup, one living Detective is selected.

That Detective receives a 90-second question window.

The Detective writes a wildcard pressure prompt. Once submitted, the question is automatically sent to every living Spy-side player, including the human Spies and the hidden Gemini AI.

The Spy side then receives a 45-second answer window.

Human Spies type their responses while Gemini generates its answer through a Supabase Edge Function.

All responses are stored in Supabase and displayed as evidence cards.

Finally, the selected Detective receives a 30-second final read window and must click the answer card they believe belongs to the AI.

Resolution

The resolution is intentionally asymmetric:

If the Detective guesses wrong, that Detective is eliminated.
If the Detective guesses correctly, one human Spy bodyguard is eliminated.
The AI survives until all human Spies are gone and it has nowhere left to hide.

Undercover Names

One of the most important mechanics is the rotating identity system.

Spy-side players never keep the same visible name between rounds.

A player might be:

TAVI in Round 1
ORION in Round 2
MICA in Round 3

This prevents cheap detective work.

Detectives cannot simply memorize player names, positions, or patterns tied to a specific identity.

Instead, they must judge the answers themselves.

Previous round results preserve the original cover names, so historical evidence remains readable even after identities rotate.

Wildcard Questions

The wildcard question is the heart of the game.

The best questions pressure the difference between a lived human answer and a generated answer.

Examples:

"Describe a tiny mistake you made today without making it sound important."
"What is a smell that makes you trust a place?"
"Say something you would only text, not say out loud."
"Which answer in this room feels rehearsed, and why?"

These questions are not about facts.

They are about texture.

They force players to produce awkward, emotional, sensory, or social details under pressure.

That is where the Turing Test becomes playable.

Gemini Integration

The Gemini integration runs server-side through a Supabase Edge Function.

When a Detective submits a question, the function:

Checks the current room and round.
Finds the hidden AI player.
Reads the AI's current cover name.
Sends the question and game context to Gemini.
Receives a short in-character answer.
Saves the answer into Supabase.
Broadcasts it alongside the other Spy answers.

The Gemini API key is never exposed to the browser.

I also added multiple AI behavior styles so Gemini does not always respond with the same personality.

Sometimes it answers plainly.

Sometimes it is guarded.

Sometimes it is short, awkward, or oddly direct.

The goal is not to make the AI sound perfectly human every time.

The goal is to make it difficult to separate from the Spy side.

Prize Category

I am submitting for both optional prize categories.

Best Ode to Alan Turing

Among Liars is built directly around the idea of the Turing Test.

But instead of making the test a static question-and-answer screen, I turned it into a social game.

The AI is not judged by one answer alone.

It is judged by how it survives inside a room full of humans who are actively suspicious of it.

The game asks:

Can a machine imitate a human well enough to survive pressure, suspicion, and social reading?

That felt like a more interactive tribute to Alan Turing's original imitation game.

Best Google AI Usage

Gemini is not a decorative feature in this project.

It is the hidden player.

The entire game loop depends on Gemini:

Gemini receives the Detective's wildcard question.
Gemini answers as a Spy-side player.
Gemini uses the current room context and cover name.
Gemini's answer becomes evidence the Detective must judge.
The game cannot fully exist without the AI participant.

I integrated Gemini through a server-side Supabase Edge Function so the API key remains protected and the AI response becomes part of the realtime game state.

The AI is also given its current undercover identity and round context, allowing it to behave like a player inside the match rather than a generic assistant.

Final Thoughts

Among Liars started from a simple question:

What if the Turing Test was not a test, but a game night?

The result is a tense social deduction game where humans are reading AI, humans are imitating AI, and nobody can fully trust what "normal" sounds like.

That is the fun part.

In this game, the AI does not need to be perfect.

It just needs to survive.

PROCSee -> Turn Your System Into a Crime Scene & let Gemini Become Investigator!

Mir Shah — Thu, 26 Feb 2026 15:10:50 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

About four weeks ago, the Gemini 3 Hackathon dropped — Google DeepMind's global hackathon with a $100K prize pool, asking builders to create something genuinely new with the Gemini 3 API. Not another chatbot. Not a wrapper. Something that actually pushes what the model can do.

I had one question sitting in my head for a while: what if your computer could investigate itself?

Not just flag a suspicious process. Not just match a signature and throw an alert at you. But actually think — form a theory, pull more evidence, change its mind, reach a conclusion. The way a real security analyst would.

That became PROCSee.

It's an autonomous security investigation system for Windows. It monitors every process on your machine in real-time, and when something looks suspicious, it hands the investigation off to Gemini 3 Pro — which then decides what additional data it needs, queries for it, reasons across multiple rounds of evidence, and writes a full forensic report. The tagline: Turn your system into a crime scene. Let PROCSee be the forensic analyst.

How It Actually Works (The Architecture)

Let me walk through this the way I wish someone had explained it to me before I built it, because the architecture decisions were the hardest part — not the AI integration.

Step 1: Catch everything, instantly

Windows is constantly spawning processes. Updaters, scanners, system services — hundreds of events per hour on a normal machine. The classic approach is polling: check what's running every few seconds. The problem? A piece of malware that executes, drops a payload, and exits in under a second is completely invisible to a poller.

We used WMI event callbacks instead. WMI (Windows Management Instrumentation) is a pub/sub system built into Windows. You subscribe to process creation events, and the OS calls your code the moment anything starts — under 10ms latency. We capture it all: the process name, path, parent process, command line, user account, everything. Immediately written to a raw events database in SQLite. No analysis yet. Just capture.

New Process Starts
      ↓
WMI fires callback (<10ms)
      ↓
Stored in raw_process_events immediately
      ↓
Done. Fast. No AI involved yet.

Step 2: The problem with "just send everything to Gemini"

Here's where we made our first big mistake, and then fixed it.

Our first instinct: every time a process starts, send its data to Gemini and ask "is this suspicious?" Simple idea. We tested it. On a normal Windows machine, that's easily 3-5 process creation events per second during active use. At that rate you'd blow through your API quota in literal minutes. Not hours. Minutes.

So we needed a smarter funnel before anything touches the API.

We built a local behavior-scoring engine — zero API cost, runs entirely on-device. It checks 40+ patterns before Gemini ever sees anything:

Is PowerShell using -encodedcommand or -executionpolicy bypass?
Is a browser spawning a shell? (chrome.exe → powershell.exe is almost never legitimate)
Is something executing from %TEMP% or AppData?
Is certutil.exe or mshta.exe making network connections? (classic LOLBins abuse)
Is a process touching registry persistence keys?

Each pattern scores points. If a process scores zero — nothing suspicious — it's logged and forgotten. It never reaches Gemini. Only things that earn attention get elevated. This alone cut our API calls by around 95%.

Step 3: The dual-database architecture

Even with the scoring filter, we still needed to solve what Gemini actually sees. This is the core architectural insight of the whole project: separate "store everything" from "show the AI what matters."

We run two databases side by side:

The raw events database stores every single process event in full detail. This is the forensic record — complete, unfiltered, queryable at any time. It's how we can answer "show me every process that made a network connection to this external IP in the last 30 minutes" without having pre-loaded all of that into Gemini's context.

The summary database gets built every 60 seconds. We aggregate the raw events into a 1-minute digest: what was unusual, what matched suspicious patterns, the high-level picture. This is small — a few KB of actual signal. This is what Gemini reads first to orient itself.

Raw Events DB (everything)  →→→  Summary DB (1-min digest)
       ↓                                    ↓
  Forensic record                   Gemini reads this first
  Gemini queries this               to orient itself
  when it needs more detail

Step 4: Gemini doesn't just read the data — it decides what it needs

This is the part we're most proud of, and it's what makes PROCSee different from a standard AI integration.

Most AI integrations work like this: gather all the data you think is relevant, stuff it into a prompt, hope the AI has what it needs. The problem is you're guessing what it'll need. You either over-send (burns tokens, hits context limits) or under-send (bad analysis).

We flipped it. After Gemini reads the summary, it can say: "I need more information before I give you a verdict." And then it tells us exactly what it wants:

{
  "needs_more_data": true,
  "queries": [
    {
      "action": "QUERY_PROCESS",
      "process_id": 4821,
      "time_range": "last_5_minutes",
      "details": ["network", "file_access", "cpu"]
    },
    {
      "action": "QUERY_NETWORK",
      "time_range": "last_30_minutes",
      "min_connections": 3
    }
  ]
}

We execute those queries against the raw database, return the results, and Gemini continues its analysis. Another round. It keeps doing this until it's confident enough to give a verdict.

A real investigation flow looks like this:

Round 1 — Gemini reads the summary: "There's suspicious PowerShell activity worth investigating."
→ We query: full process details for that PowerShell instance

Round 2 — Gemini gets the data: "It's making outbound connections to 203.0.113.42, an external IP."
→ We query: all network activity to that IP across the whole system

Round 3 — Gemini gets the data: "Three separate processes are all calling out to the same external IP. This is command-and-control communication."
→ Final verdict: CONFIRMED_THREAT — risk 0.95, confidence 0.92

No human in that loop. Gemini decided what it needed, went and got it, and formed its own conclusion.

Step 5: The forensic report

When risk is ≥50% and confidence is ≥60%, Gemini generates a full Markdown forensic report — written in first person, walking through its investigation process, the evidence chain, MITRE ATT&CK technique mappings, indicators of compromise, and recommended response actions.

We built a custom renderer for these reports with syntax highlighting for cmd:, path:, ip:, and proc: prefixes so they read like real analyst documents, not raw AI output.

The stack: Python + FastAPI for the backend agent, SQLite with WAL mode for the dual-database architecture, pywin32 for WMI, psutil for process data, React + Vite for the dashboard, WebSocket for real-time streaming, and the google-genai SDK for Gemini 3 Pro.

Demo

[GitHub: https://github.com/abbasmir12/procsee]

The dashboard has a few views worth calling out. The Gemini Conversation View is the one that surprised me most when I first saw it working. You can watch in real-time as Gemini issues a QUERY_NETWORK call, gets results back, immediately pivots to QUERY_PATTERN: shell_spawn because it noticed something in the results, and keeps iterating toward a verdict. It genuinely looks like watching someone think through a problem — because that's what it is.

The Detailed Report Viewer renders the final forensic reports with full Markdown and syntax highlighting. Each report includes the complete investigation chain — every query Gemini issued, every piece of evidence it weighed, every confidence score.

What I Learned

The architecture problem was the real challenge

Here's what I didn't expect going in: the Gemini integration itself was actually the smooth part. Once the architecture was solid, plugging in Gemini was relatively clean. The hard part — the part that took most of the time — was building the system that makes responsible, efficient use of the API.

The quota problem hit us immediately. Naive implementation: fire an API call for every process event. Reality: quota exhausted in under an hour on a busy machine. That forced us to completely rethink the data flow. The behavior scoring engine, the 60-second aggregation, the dual-database design — all of that exists because of one question we kept coming back to: how do we make sure Gemini only sees what's actually worth its attention?

Every architectural decision in this project traces back to that question. If you're building anything that involves a continuous data stream and an LLM, that's the question you need to answer first. Everything else flows from it.

Rate limits aren't just a bug — they shaped the whole system

When we stress-tested with multiple concurrent investigations, we hit rate limits constantly. Five investigations running simultaneously, each doing 3-4 query rounds with large contexts — that's a lot of tokens per minute, very fast.

The frustrating part: the error messages just said "resource exhausted." Is that requests per minute? Tokens per minute? Daily limit? These have completely different fixes. RPM you solve with throttling and request spacing. TPM you solve with context compression and smarter batching. Daily limits you solve with queuing strategy. Not knowing which one you're hitting means you're guessing at the solution while your quota keeps burning.

We ended up implementing all three mitigations simultaneously because we couldn't tell which problem we were actually solving: exponential backoff with jitter, a hard cap on max_query_rounds per investigation (default 4), a global concurrency limit (max 3 deep investigations at once), and dynamic thinking level selection so we're not burning high-compute calls on triage decisions that don't need them. The rate limit constraints literally shaped the concurrency model of the entire system — which is a weird thing to say but it's true.

Thinking levels matter more than I expected

thinking_level="low" vs thinking_level="high" isn't just a speed dial. It changes the quality of reasoning you get and what prompting strategies work well. We use low for fast triage — "is this worth investigating at all?" — and high for deep forensic analysis and report generation.

Early on we used high thinking everywhere. Slower responses, heavier quota usage, and no meaningful quality improvement for simple yes/no triage decisions. Right tool for the right job. Sounds obvious in retrospect, but figuring out which job needs which level took real experimentation.

Cutting features is a skill

We came into the hackathon wanting to build prevention features — automatically suspending suspicious processes, network isolation. Had it half-implemented. Then we cut all of it.

Not because of time. Because we realized: if you're wrong on a false positive and your tool kills a legitimate process, you've broken trust permanently. Investigation and reporting empowers analysts. Autonomous process-killing is a liability. Cutting that scope made the project sharper and more honest about what it actually is. The disabled beta_prevention block is still in config.yaml — kept it as a reminder of the decision.

Google Gemini Feedback

What genuinely worked

The 1M token context window carried the whole investigation model. I planned to build summarization logic to manage context across multi-turn investigations — compress old query results, drop less-relevant evidence as rounds progressed. Never needed any of it. The entire investigation history — all the autonomous queries, all the results, all the evidence across multiple rounds — fit comfortably. And Gemini would reason across all of it in later rounds, catching connections between something from round 1 and new data from round 3. That cross-context reasoning was more capable than I expected going in.

Structured JSON output was rock solid. The autonomous query protocol only works if Gemini reliably returns machine-parseable decisions mid-analysis. I was genuinely nervous this would be flaky — sometimes JSON, sometimes Markdown-wrapped, sometimes off-schema. It wasn't. response_mime_type="application/json" combined with a clear schema in the prompt was consistently reliable even when the underlying reasoning was complex.

Multi-turn reasoning quality is genuinely different. The gap between "here's all the data, give me a verdict" and the autonomous multi-turn investigation is not subtle. The model caught things in round 3 that it completely missed or hand-waved in round 1. Letting it pull the data it actually needed, rather than us guessing upfront, made a real difference to the quality of the final verdicts.

Where we hit friction

Rate limit error messages need more context. "Resource exhausted" isn't actionable. RPM, TPM, and daily limits all require different solutions, and not knowing which constraint you're hitting means you're solving the wrong problem while your quota keeps ticking down. Even a simple error code that differentiates the limit type would have saved us significant debugging time during the crunch.

thinking_level documentation is thin for practical use. Finding the parameter was easy. Understanding the actual tradeoffs — which prompt structures work best at each level, how it affects structured output reliability, what temperature to pair with each level — was entirely trial and error. For anyone building agentic systems where you're making many API calls with different complexity levels, practical guidance here would save a lot of iteration time.

Gemini will over-query if you let it. With high thinking enabled, it sometimes issued 5-6 autonomous queries when 2-3 would have been enough for a confident verdict. Thorough is good — but in a long-running monitoring system that's real quota cost accumulating over hours and days. Prompting it toward decisiveness helped somewhat, but the hard max_query_rounds cap was ultimately necessary as a backstop. Guidance on prompting for query efficiency specifically in agentic loops — not just single-shot quality — would be useful to see in the docs.

None of this broke the project. The core capability — letting Gemini autonomously decide what it needs and go get it — worked better than expected and is genuinely a different kind of AI integration than the standard request/response loop. PROCSee wouldn't exist without it.

You can also check out my original Gemini 3 Hackathon submission on Devpost here: https://devpost.com/software/procsee

[GitHub: https://github.com/abbasmir12/procsee | Built for the Gemini 3 Hackathon on Devpost]

MindMelee: Beat AI in debate Arena!

Mir Shah — Sun, 15 Feb 2026 12:36:26 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

MindMelee is basically your AI debate partner that's always ready to argue with you (in a good way!). I wanted to create something that helps people get better at debating without needing another person around.

https://youtu.be/lqRVlVBc24M

The app uses Google's Gemini Live API so you can actually talk to it like a real conversation. After each debate, it breaks down your performance - vocabulary, clarity, how persuasive you were, all that stuff. You can pick between two modes: Coach (nice and helpful) or Fierce (actually challenges you).

The UI is pretty bold - I went for this neubrutalist style inspired by CodeJam. Big timer on the left, your conversation on the right. Only shows the last 5 messages so you stay focused instead of scrolling through everything.

Demo

GitHub Repository: github.com/abbasmir12/mindmelee

Demo Site: https://mindmelee.vercel.app/

Screenshots

Dashboard - Start Your Debate

Live Debate Interface

Performance Analytics

I'm still learning - only scored 30 on my first try 😒 Let me know what you get!

Key Features

Real-Time Voice Debates - Just talk naturally, AI responds right away
Bold Neubrutalist UI - CodeJam-inspired design with smooth animations
Comprehensive Analytics - See exactly where you're strong and where you need work
Dual AI Modes - Coach mode for learning, Fierce mode when you want a real challenge
Progress Tracking - Charts and heatmaps showing your improvement
Persona Discovery - Find out what kind of debater you are

My Experience with GitHub Copilot CLI

Okay, so here's the thing - I'm not gonna pretend Copilot CLI built this entire app for me. I designed everything, figured out the architecture, made all the creative decisions. But man, when it came to actually implementing stuff? Copilot CLI saved my life.

How It Actually Helped

Talking to Code
Instead of spending hours reading docs, I could just ask Copilot CLI in plain English. Like when I needed the audio visualization thing - I just asked how to make a real-time audio analyzer. It gave me the code AND explained how the WebAudio API actually works. That's huge when you're learning.

Smart Suggestions
The context-aware stuff is wild. While I was building the UI, it would suggest the exact Tailwind classes I needed for those neubrutalist shadows. It somehow understood the pattern I was going for and kept everything consistent.

Instant Debugging
My components were re-rendering like crazy on every audio frame (performance nightmare). Copilot CLI spotted the issue immediately and told me to use refs instead. Saved me probably 3 hours of debugging.

Learning on the Fly
This is what really got me - it doesn't just give you code, it teaches you. When I was struggling with Framer Motion, it explained spring physics and showed me this mode="popLayout" feature I'd never seen. Every time I used it, I learned something new.

TypeScript Help
WebRTC and MediaStream types are confusing as hell. Copilot CLI just... knew the right types. And explained why they were needed. No more tab-switching to docs every 5 seconds.

The Real Impact

Look, what would've taken me days of Stack Overflow rabbit holes took minutes with Copilot CLI:

WebAudio API: 30 minutes vs. probably 4+ hours
Framer Motion animations: 1 hour vs. a full day of trial and error
Performance fixes: Instant vs. who knows how long
TypeScript types: Right there vs. endless doc searching

But it's not just about speed. Copilot CLI changed how I approach building stuff. I'm not scared to try new APIs anymore because I know I've got this AI pair programmer who can explain things in real-time.

Best Moments

The Genius Suggestion: Copilot CLI told me to use flex-col-reverse for the chat feed. New messages at bottom, old ones fade out at top. So simple, so perfect. I wouldn't have thought of that.
Design Consistency: It helped me keep the neubrutalist style consistent across 20+ components. Once it understood the pattern, it just... got it.
Performance Win: Fixed that re-render issue in seconds. Went from laggy mess to smooth 60fps just like that.
The Learning: Finally understanding React's closure issues with useEffect. Not just fixing the bug, but actually getting why it happened.

Why This Matters

If you're building something complex by yourself, Copilot CLI is like having a senior dev on your team. Not to do the work for you - to help you do it better.

I knew what I wanted to build. Copilot CLI helped me actually build it without getting stuck every 10 minutes. That's the difference between "cool idea" and "working app."

MindMelee has real-time voice AI, complex animations, comprehensive analytics - stuff that requires knowing a lot of different things. Copilot CLI made it possible to tackle all of it without drowning in documentation.

Try It Yourself

git clone https://github.com/abbasmir12/mindmelee.git
cd mindmelee
npm install
npm run dev

Add your Gemini API key in Settings and start debating!

I had the vision, Copilot CLI helped me execute it.

MindMelee: Beat AI In Arena!

Mir Shah — Sun, 15 Feb 2026 11:25:03 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

https://youtu.be/lqRVlVBc24M

Demo

GitHub Repository: github.com/abbasmir12/mindmelee

Demo Site: https://mindmelee.vercel.app/

Screenshots

Dashboard - Start Your Debate

Live Debate Interface

Performance Analytics

I'm still learning - only scored 30 on my first try 😒 Let me know what you get!

Key Features

Real-Time Voice Debates - Just talk naturally, AI responds right away
Bold Neubrutalist UI - CodeJam-inspired design with smooth animations
Comprehensive Analytics - See exactly where you're strong and where you need work
Dual AI Modes - Coach mode for learning, Fierce mode when you want a real challenge
Progress Tracking - Charts and heatmaps showing your improvement
Persona Discovery - Find out what kind of debater you are

My Experience with GitHub Copilot CLI

How It Actually Helped

TypeScript Help
WebRTC and MediaStream types are confusing as hell. Copilot CLI just... knew the right types. And explained why they were needed. No more tab-switching to docs every 5 seconds.

The Real Impact

Look, what would've taken me days of Stack Overflow rabbit holes took minutes with Copilot CLI:

WebAudio API: 30 minutes vs. probably 4+ hours
Framer Motion animations: 1 hour vs. a full day of trial and error
Performance fixes: Instant vs. who knows how long
TypeScript types: Right there vs. endless doc searching

Best Moments

The Genius Suggestion: Copilot CLI told me to use flex-col-reverse for the chat feed. New messages at bottom, old ones fade out at top. So simple, so perfect. I wouldn't have thought of that.
Design Consistency: It helped me keep the neubrutalist style consistent across 20+ components. Once it understood the pattern, it just... got it.
Performance Win: Fixed that re-render issue in seconds. Went from laggy mess to smooth 60fps just like that.
The Learning: Finally understanding React's closure issues with useEffect. Not just fixing the bug, but actually getting why it happened.

Why This Matters

If you're building something complex by yourself, Copilot CLI is like having a senior dev on your team. Not to do the work for you - to help you do it better.

I knew what I wanted to build. Copilot CLI helped me actually build it without getting stuck every 10 minutes. That's the difference between "cool idea" and "working app."

Try It Yourself

git clone https://github.com/abbasmir12/mindmelee.git
cd mindmelee
npm install
npm run dev

Add your Gemini API key in Settings and start debating!

I had the vision, Copilot CLI helped me execute it.