DEV Community: İclal Doğan

THE UNHEARD: A Game That Sends You Outside, Teaches a Machine to Listen, and Makes It Prove Every Word

İclal Doğan — Mon, 12 Oct 2026 00:48:29 +0000

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

What We Built

THE UNHEARD is an acoustic-memory game where the machine knows the name of every sound and has never heard one.

You meet ECHO-0, a mind that has read about rain, bells and footsteps ten thousand times and holds no memory of any of them. The game asks you to do the one thing a screen cannot: go outside, record something that is really there, and bring it back. You tell ECHO-0 what you heard. It guesses, gets things wrong, takes your correction, and remembers. By the end, the sounds you collected are an orchestra.

The design principle is "The Model Never Changes. The Memory Does." Nothing in this project trains or fine-tunes anything. A frozen audio model hears; a retrieval memory keeps what you taught it; a local Gemma speaks. Three separate mechanisms, never blurred.

It is a local-first app (a React PWA, a FastAPI server, SQLite, CPU audio embeddings, and Gemma through Ollama) with six scenes:

Scene	What happens
Chamber	ECHO-0 waits and says, honestly, how much it has heard so far.
Field	Record a real sound. It is saved in the browser first, even offline, and uploaded when you choose.
Hearing	A local CLAP model proposes what the sound might be, as similarity scores, never fake probabilities. You confirm, correct, rename, or say "I don't know."
Specimen	Every recording becomes a visual artifact generated deterministically from its measured acoustics. Same sound, same shape.
Atlas	Your recordings placed by how alike they actually sound, with the names you gave them.
Orchestra	Pick three or more taught sounds and ECHO-0 composes from the recordings themselves, with stems you can mute and solo and a WAV you can keep.

The ending is not scripted. It unlocks only when a real composition exists, built from at least three recordings you named.

The Hearing Room. CLAP's own ears put "Church bells" at cosine 0.367. The name the player taught, "Bells", has a memory similarity of 0.844 from two remembered examples, so memory ranks it first. These are similarity scores, not probabilities.

How it gets people off the screen

The prompt says: make the screen the shortest part. We took it literally, and then we felt how hard it is.

A game about sound should not be played on a screen. The screen is only where the machine keeps its notes. The part that matters happens when you stand in a street at an hour you have never listened to, hold up a phone, and realise you could not have told anyone what that street sounds like. Teaching ECHO-0 to name a sound turned out to be the fastest way to notice how many we had never heard ourselves.

That is why the interface is calm and sparse, why the hearing room shows honest similarity numbers instead of confident percentages, and why the machine asks you instead of pretending. It is a game that wants you to close the laptop.

Before you play

Be ready for a laptop-first experience: capture works offline on the phone, but hearing, memory, composition and Gemma all run on your laptop. This is not an on-device AI app, and we would rather say so than let you find out. For the phone to use its microphone it needs trusted HTTPS, so the repo includes a one-command local certificate setup and a server flag that serves the app itself over TLS. We have written the Android field test up, but we have not yet performed it on a physical phone.

Taking it outside — current status

This is where we owe you the most honesty. The game is built around leaving the screen, and we did not complete that outing for this submission. The Android field test is written up (docs/ANDROID-FIELD-TEST.md) and its results table is empty. Our automated browser runs used desktop Chrome with a simulated microphone and prove nothing about phones. We would rather hand you a clear gap than a made-up trail story.

Demo

Fifty seconds, narrated and scored. Everything on screen is the real app running on the generated set: real CLAP inference, real taught names, a real Composed render.

About the demo audio

Here is the part we owe you plainly. The demo sounds were generated with the ElevenLabs sound-effects API. They are not field recordings. The narration in the video is an ElevenLabs voice, and the music is the app's own Composed render of those generated sounds.

Why: the only audio we had for testing was a research dataset that is licensed for non-commercial use and cannot appear in a public demo. We first synthesised a publishable set from scratch in NumPy (it is in the repo, deterministic, free to reproduce), then regenerated it with ElevenLabs so the demo would sound like something. The project still does exactly what it claims with real recordings, but we are not going to dress generated rain up as a hike.

Code

miclaldogan / the-unheard

THE UNHEARD: an orchestra made of a world you almost forgot to hear (Hacktoberfest 2026, Touch Grass)

THE UNHEARD

An orchestra made of a world you almost forgot to hear.

ECHO-0 knows the world’s names but has lost its acoustic memory. Go outside, collect a sound return to the laboratory, teach it what you heard, and listen as your memories become a composition A local-first React PWA, FastAPI, SQLite, CPU LAION-CLAP and local Gemma through Ollama power the experience.

Release

main contains the complete project: the M5 narrative backend, the cinematic UI, the M5.5 integration and the M6 final validation (the pre-inference teaching race is fixed, HTTPS can be served by the backend itself, review tooling and submission drafts; see docs/M6-FINAL-REPORT.md). M7 adds a publishable synthetic audio set so the project can demonstrate itself without ESC-50 (docs/M7-SYNTHETIC-AUDIO.md) The six scenes are Chamber → Field → Hearing → Specimen → Atlas → Orchestra. Recording, classification, annotation, retrieval memory, measured visual artifacts, composition, playback and…

View on GitHub

MIT licensed. Model weights are downloaded locally and are never in the repository.

git clone https://github.com/miclaldogan/the-unheard
cd the-unheard/server
uv sync --extra ml
uv run unheard fetch-model          # one-time CLAP download
cd ../web && npm ci && npm run build
cd ../server
UNHEARD_NARRATIVE_MODEL=gemma3:4b uv run unheard serve   # http://127.0.0.1:8000

How We Built It

ECHO-0 is three things that never pretend to be each other.

The part that hears: LAION-CLAP. laion/clap-htsat-unfused turns audio into a 512-dimensional embedding and scores it against text labels, on CPU. It is frozen. Nothing here trains it.
The part that learns: retrieval memory, not training. When you name a sound, its embedding is stored as an exemplar of your label. Later predictions fuse CLAP's scores with nearest-neighbour similarity to your exemplars, and the interface shows which one is speaking. On the demo set, we taught two "Roof gutter" clips. On a third clip it had never heard, that name was absent from the top three before teaching (Rain, Bicycle, Lawn mower) and first afterwards. The model did not change. The memory did.

A bug worth admitting. If you named a sound before its analysis finished, the name was saved but never became an exemplar: it looked taught and was not. The fix attaches the stored name to the embedding when inference completes, exactly once, and the interface says "memory has not changed yet" until that is true. A real-CLAP test reaches the same similarity (0.837) whether you teach before or after.

The part that composes: no music model. An offline NumPy/SciPy renderer cuts motifs out of your recordings, works out which are pitched or percussive, builds phrases and sections, and lets one source answer another. Every event in the output traces back to a window of one of your recordings; the piece in the video has 47 of them.

The part that speaks: Gemma, on a leash

ECHO-0's voice is a local gemma3:4b through Ollama (4.3B parameters, Q4_K_M). We did not want a chatbot bolted onto a game. Gemma has three narrow jobs: interpret memory changes, reason about missions, and comment on a composition. The backend finds real gaps in your sound memory, and Gemma can only choose among them and word them. It cannot invent one, and it cannot decide whether you completed it. Plain code does that.

Gemma never sees ids, audio or your notes. It sees short fact lines and must answer in a JSON schema, citing the facts it used. Then a deliberately suspicious validator checks the answer:

every number must appear in a cited fact,
every quoted name must be one the player gave,
no sound source may be mentioned that is not in the evidence,
no claim of having seen, visited or been retrained,
no markup, no ids.

If anything fails, a deterministic template says the line instead and the reason is recorded. The game shows the template line first and swaps in Gemma's when it arrives, so nothing ever waits on the model.

The numbers, stated exactly. Over 19 moments of a real journey, three seeds each (57 calls), 84.2% of Gemma's first attempts passed the validator (48 of 57), and the figure reproduced on a second run. Median warm latency is about 1.3 seconds. One rejection class was our own bug: the validator read the apostrophe in "the ears' strongest guess" as an opening quote, and fixing it moved the rate from 71.9% to 84.2%. We also tried telling the model not to write internal handles like "F1", and it wrote more of them, so we reverted.

What we have not measured: the end-to-end fallback rate after the single retry, and whether people prefer Gemma's lines to the templates. We built a blind rating sheet for that. Nobody has filled it in yet, so we make no claim that Gemma's wording is better. In the final demo run Gemma was called twice and one answer was rejected, which is far too few calls to call a rate.

Current limitations and validation

Human review is missing. The musical quality has not been rated by people. Automatic checks say the refined composer fixes measurable problems such as repeated bars; they do not say it is beautiful. A blind listening page is ready.
Novelty detection is a heuristic. CLAP's top guess for a quiet or mixed sound is often wrong. That is the point of the game, and why it asks you.
Generated sounds are easier than real ones. Variants from one generator are more alike than real field recordings, so the demo shows the mechanism, not field performance.
Recording can stop when a phone locks. We did not claim background capture.
Tests: 283 backend tests and 78 frontend tests pass, plus gated real-CLAP and real-Gemma tests.

Why Does Open Innovation Matter?

Your recordings never leave your machine. A sound from your kitchen or your street is exactly what you do not want on someone else's server. CLAP, the memory, the composer and Gemma all run locally. The phone only captures.
We could put a leash on the model. Because Gemma runs locally behind Ollama, we could force a JSON schema, measure its failures honestly and put a validator between it and the player. That is why we know the number is 84.2% and not "it seemed fine."
Parts are swappable. The narrator is a setting. The listening model sits behind a small interface and can be replaced without touching the game.
It costs nothing to run once the weights are downloaded.

Our Agent Session

We built this with AI coding assistants, so the post is disclosed as AI-assisted: Claude Code for the backend, narrative engine, release engineering and the video tooling, and Codex for the interface.

No public DevRelay agent-session link is included in this draft.

Prize Categories

We are entering three: Overall, Best Use of Gemma and Best Use of ElevenLabs. Here is exactly what each one did in this project, including where it stops.

Best Use of Gemma

Gemma is ECHO-0's voice. Not a chatbot, not a skin over a template: a local gemma3:4b (4.3B parameters, Q4_K_M) that runs through Ollama on a 15 GB laptop, and whose job is to turn what actually happened into words.

Three narrow jobs, each testable on its own:

Interpret memory. You taught a sound a name, or corrected the ears. Gemma is handed a few fact lines and says what that means in one or two sentences.
Reason about missions. The backend finds real gaps in your sound memory: a name with one example, a sound nobody could name, nothing pitched yet. Gemma picks among them and words them. It cannot invent a mission, and it cannot decide whether you completed one. Plain code does that.
Comment on the composition. Using the real source roles and the real plan of the piece it just rendered.

How it is kept honest. Gemma never sees ids, audio, or your notes. Every fact reaches it as a short line with a handle (F1, F2…), and it must answer in a JSON schema, citing the facts it used. Then a deliberately suspicious validator reads the answer before the player does. Every number must appear in a cited fact. Every quoted name must be one you gave. No sound source may be mentioned that the evidence does not contain. No "I walked outside," no "I was retrained," no markup, no ids. If a single check fails, a deterministic template says the line instead, and the reason (invalid_json, for instance) is recorded next to it. Open the "What this voice is grounded in" panel and you can see which facts any line was built from.

What we measured, and what we did not.


Moments evaluated	19 moments of a real journey, 3 seeds each, 57 calls
First attempts that passed the validator	84.2% (48 of 57), reproduced on a second run
Output that matched the schema	100%, through constrained decoding
Invented ids	0, because the model cannot emit ids
Warm latency	median ≈ 1.3 s, p95 ≈ 1.9 s

Two things we are glad we found. One rejection class was our own bug: the validator read the apostrophe in "the ears' strongest guess" as an opening quote, and fixing it moved the rate from 71.9% to 84.2%. And when we tried to tell the model not to write handles like F1 into prose, it wrote more of them, so we reverted the instruction. The honest fix was a validator, not a plea.

The game shows its template line first and swaps in Gemma's when it arrives, so nothing ever waits on the model, and if Gemma is unavailable the game plays on with the templates.

What we do not claim. We did not measure the end-to-end fallback rate after the single retry, and in the final demo run Gemma was called only twice (one answer valid, one rejected as invalid_json), far too few calls to be a rate. A blind rating sheet that compares Gemma's wording with the templates exists, but nobody has filled it in, so we do not claim Gemma is better than the templates. Gemma was not fine-tuned, it does not hear audio (CLAP does), and it owns no game state. Open weights mattered here for one concrete reason: running it ourselves is what let us force the schema, measure its failures, and put a validator in front of the player.

Best Use of ElevenLabs

ElevenLabs is why the demo has sound at all, and we want to be exact about where it sits: it is demo tooling, not part of the running game.

The Sound Effects API generated the demo sounds. We could not publish the research audio we tested with, because it is licensed for non-commercial use. So a committed script, scripts/m8_elevenlabs_sounds.py, asks the Sound Effects API (eleven_text_to_sound_v2) for 21 clips: six that drive the full journey (rain in a metal roof gutter, tolling bells, three takes each) and a fifteen-clip pack of wind, footsteps, birds, water and machines. Each is a ten-second text prompt with no music. The script reads the API key from the environment only, converts each clip to 48 kHz mono, levels it so it clears the app's own ingest checks, and writes a manifest with the prompt, model, settings and checksum of every clip. The audio is not committed, but anyone with their own key can regenerate the set.
Then the game does what it does with real recordings. CLAP hears the generated sounds, a name we teach becomes retrieval memory, and the Composed orchestra in the video is built only from those clips.
A voice narrates the 50-second video. The narrator is the CRITIC voice from our earlier project, ECHOLALIA, generated with ElevenLabs text-to-speech, seven lines mixed under the app's own music.

The sounds, the narration and the music in the demo are generated or composed, not field recordings, and the video says so on screen. We would rather you trust the project than be impressed by a fake hike.

Team submission — built and designed by İclal Doğan (@iclaldogan) and Melike Zaman (@melike_nesrinzaman_713c0). Melike wrote the audio ingestion, the hearing and memory layer and the first versions of the acoustic atlas; İclal built the narrative engine, the composer integration, the release engineering and the demo.

Go outside. Listen closely. And if ECHO-0 asks what you heard, tell it the truth.

THRASH: I Gave My Friend an Operating System for Her Brain

İclal Doğan — Mon, 05 Oct 2026 01:01:13 +0000

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

I gave my friend an operating system for her brain.

Okay, not the whole operating system.

Mostly the scheduler.

Because apparently that was the missing part.

Somewhere around 3 AM, this became a perfectly reasonable sentence.

My friend M. has a problem.

Not the usual productivity problem.

She does not procrastinate.

That is almost the problem.

For privacy, I'll call her M.

M. is the kind of person who seems to have an unreasonable number of processes running in her head at the same time.

One has music playing.

One has an unfinished math problem.

One contains a game she is building.

Two more are research ideas that absolutely did not exist yesterday.

There is probably a half-written article somewhere underneath them.

And occasionally a completely unrelated question appears, gets promoted to critical priority, and steals the CPU.

Her brain looks like a desktop nobody has restarted since 2019.

There are four terminals open.

Nobody knows what terminal number three is doing.

Including M.

My first thought was obvious:

I should build her a planner.

Then I realized that giving her another planner would probably just create another thing she had to manage.

So I stopped thinking about M. as an unorganized person.

And started thinking about her as a badly scheduled computer.

Then something clicked.

I had seen this failure before.

Not in a person.

In Operating Systems class.

When a computer keeps too many working sets active and spends more time moving context in and out than doing useful work, it starts thrashing.

M. was doing the human version.

So I did the only reasonable thing.

I gave my friend a kernel.

What I Built

THRASH is a local AI-powered human process scheduler.

It treats projects the way an operating system treats processes.

Not because I wanted to rename todo-list concepts with OS vocabulary.

The rule I used throughout development was simple:

If an operating-system metaphor does not correspond to real behavior, it does not belong in THRASH.

Projects can be RUNNING, READY, SLEEPING, STARVED, ZOMBIE, or deliberately terminated.

Switching projects saves context.

Returning to an old project restores it.

Ideas can arrive as interrupts instead of immediately creating another project.

Neglected work can starve.

Projects that quietly died while leaving TODOs and unresolved decisions behind can become zombies.

Too many active working sets create memory pressure.

Too many rapid switches create thrashing.

And eventually:

But the most important feature is not the joke.

It is what happens when M. returns to a project after hours, days, or weeks away.

A human PAGE FAULT

A computer can suspend a process and preserve enough state to resume execution later.

Humans usually don't.

We close the editor.

We open something else.

We come back three days later.

And stare at our own files like somebody else wrote them.

THRASH creates a semantic process image before that context disappears.

When M. returns, THRASH resolves a human PAGE FAULT.

It does not just say:

You were working on game-alpha.

It tries to reconstruct:

what she actually did,
what she finished,
what she deliberately decided,
why she made that decision,
where she stopped,
what remains unresolved,
what changed while she was gone,
and what the next executable step should be.

A restoration can look like this:

PAGE FAULT

YOU WERE HERE

Built the camera prototype and checked idle poses.
Turn testing is unfinished.

YOU DECIDED

Validate the rig before engine integration.

why:
Avoid rebuilding an untested rig.

YOU STOPPED AT

Testing the 45-degree turn pose.

WHILE YOU WERE GONE

1 relevant file changed.

STILL OPEN

Does the shoulder deform during a turn?

BLOCKER

Turn pose has not been validated.

NEXT EXECUTION

Open notes.md and test the rig at a 45-degree turn
before engine integration.

FAULT RESOLVED

That is the part of THRASH I actually wanted M. to have.

She does not really need software telling her to "be productive."

She needs something that can answer:

What on earth was I doing here?

before she spends twenty minutes rebuilding the entire project inside her head.

Demo

PAGE FAULT — restoring the person who left

The project context is restored as a process image.

The program counter becomes the point where M. stopped.

Decisions become preserved state.

Unresolved questions survive the switch.

The next action becomes the next instruction.

The theatrical part is intentional.

But the state underneath it is real.

IRQ — an idea does not have to become a project

M. has another problem.

She has ideas.

A lot of them.

Previously, an interesting thought had a fairly dangerous execution path:

interesting thought
        ↓
browser tab
        ↓
notes
        ↓
research
        ↓
new folder
        ↓
new project
        ↓
what was I doing before this?

THRASH gives that thought somewhere else to go.

It can arrive as an interrupt.

IRQ RECEIVED

current execution preserved
interrupt queued
execution resumed

The idea is not lost.

But it also does not automatically deserve an entire process.

That turned out to be one of my favorite parts of the project.

When the scheduler actually starts thrashing

The interface does not glitch randomly for terminal aesthetics.

Visual instability is tied to scheduler pressure.

High switch frequency creates dispatch echoes.

Stale process images leave residue.

Working-set pressure creates page churn.

Interrupts accumulate on the IRQ rail.

The dispatch trace becomes harder to maintain because the underlying human schedule is becoming harder to maintain.

So:

The screen isn't glitching because I wanted a cool terminal aesthetic.

It's glitching because she keeps switching projects.

That distinction mattered a lot to me.

I did not want THRASH to look like an operating system.

I wanted it to behave like one.

Paging something out

Sometimes the correct answer is not to delete a project.

It is simply:

not now.

Suspending a process saves its working state and moves it across the SWAP HORIZON.

Pressure drops.

The scope stabilizes.

The project is not gone.

Its context is waiting.

The Human Kernel Scope

The interface is built around THRASH-specific primitives:

DISPATCH TRACE
SCHEDULER SCAR
RESIDENT WORKING SET
SWAP HORIZON
CORE / PROGRAM COUNTER / REGISTERS / STACK
IRQ RAIL
PAGE FAULT
KERNEL PANIC

The historical SCAR shows old scheduling behavior faintly behind the current dispatch trace.

The working-set map shows which project contexts remain resident.

The core shows exactly one running process.

Because M. may have many projects.

But she still has one human core.

If you want to see the scar itself more clearly:

Code

The project is open source here:

github.com/miclaldogan/thrash

miclaldogan / thrash

A local AI human-process scheduler for people with too many projects in memory.

THRASH

She didn’t need another planner. She needed a kernel.

THRASH is a local human-process scheduler for returning to unfinished projects. PAGE FAULT restores what finished, what you decided and why, where you stopped, what changed, and the next action. Open-weight Gemma reconstructs that meaning locally from files and commits; Python measures switching and pressure. THRASH saves execution context across switches rather than organizing a task list. Project contents stay on your machine.

1 human. 1 core. Too many processes.

The human bug

My friend has more processes than cores.

She doesn't procrastinate. That's the annoying part. She is always doing something.

I considered building her a planner. She already has three. One of them contains a task called “organize task manager.” So that seemed unwise.

Then I realized I'd seen this failure before. Not in a person. In Operating Systems class.

She didn't need another planner. She needed a…

View on GitHub

THRASH is a terminal-native Python application.

The kernel logic is deliberately separate from the interface.

The TUI is a client of the scheduler rather than the owner of its state.

That mattered because I wanted commands, tests, demos, and the full-screen Human Kernel Scope to operate on the same underlying process model.

At the time of this submission, THRASH has 159 passing tests covering the scheduler, restoration behavior, privacy boundaries, model failure handling, interrupts, starvation, zombie detection, Sentry filtering, evaluation behavior, and the visual state model.

Public demos use simulated project histories and anonymized aliases such as:

game-alpha
paper-crane
vision-lab
circuit-garden

THRASH was also verified locally against real projects in read-only mode.

Those contents were never committed and never used in public screenshots or fixtures.

How I Built It

THRASH has two intentionally different halves.

The scheduler is deterministic

Python handles everything that does not need a language model.

That includes:

process registration,
context-switch history,
active/sleeping states,
working-set pressure,
starvation,
zombie heuristics,
snapshot age,
interrupts,
swap state,
thrashing thresholds,
drift timestamps,
and scheduler telemetry.

I did not want an LLM deciding whether eleven context switches are more than four context switches.

That is code's job.

Gemma reconstructs the human part

The harder question is not:

Which files changed?

Git already knows that.

The difficult question is:

What did the human think she was doing when she left?

THRASH runs a local Gemma model through Ollama.

Gemma receives privacy-filtered project evidence and reconstructs a structured semantic process image.

Conceptually:

local project evidence
        ↓
privacy filter
        ↓
Gemma
        ↓
semantic process image
        ↓
program counter
decisions
completed work
unresolved state
blockers
relevant files
next execution
        ↓
PAGE FAULT resolved

The model is asked for structured output.

That output is validated before THRASH accepts it.

Unsupported or malformed model responses are rejected rather than silently becoming project history.

And this distinction became important during evaluation.

I learned very quickly that:

Valid JSON is not the same thing as valid memory.

My first evaluation looked superficially fine.

All eight scenarios produced valid schemas.

But recorded decision extraction was:

0/7.

The JSON was valid.

The memory wasn't.

So I investigated instead of hiding the result.

The evidence was still present after retrieval.

The privacy filter had not removed it.

The real problem was that my definition of a "decision" was too vague.

I tightened the extraction contract:

A decision must be an explicitly recorded choice, constraint, rejection, approval, or intentional deferral.

A task is not a decision.

A current state is not a decision.

An inferred preference is not automatically a recorded decision.

Then I reran the same evaluation scenarios with the same scoring rules.

The release revision produced:

8/8 valid schemas
8/8 completed-work coverage
8/8 next-action coverage
7/7 recorded decisions extracted
6/6 recorded decision reasons preserved
7/8 task-keyword coverage
2 unsupported assertions still detected

The one task-keyword miss was a faithful paraphrase, so I left the grader unchanged rather than making the metric prettier.

And the two unsupported assertions are still documented.

Because this is memory software.

Pretending that an LLM is infallible here would be a much worse design decision than admitting where it still fails.

The scheduler is ordinary Python.

The part that remembers why M. was there is Gemma.

Why the process image matters

A saved process image contains concepts such as:

PROGRAM COUNTER
the immediate execution point

REGISTERS
important project state and constraints

STACK
the chain of work around the current task

OPEN HANDLES
currently relevant project files

DECISIONS
explicit choices and their evidence

UNRESOLVED
questions that survived the context switch

NEXT EXECUTION
the smallest useful action for re-entry

The OS vocabulary is not there just for style.

It gave me a surprisingly useful way to ask:

What is the minimum state a human needs in order to resume this project without reconstructing everything from scratch?

That question became the center of THRASH.

Sentry traces THRASH

There is a slightly ridiculous recursive part to this project.

THRASH traces M.'s context switches.

Sentry traces THRASH's.

Sentry support is optional and disabled by default.

Normal THRASH operation does not require Sentry or an internet connection.

For a fresh PAGE FAULT, THRASH instruments the restoration pipeline:

thrash.page_fault
├── thrash.process_image.load
├── thrash.context.collect
├── thrash.privacy.filter
├── thrash.gemma.resume
├── thrash.schema.validate
├── thrash.drift.detect
└── thrash.restore.render

The trace exposed the bottleneck immediately.

One measured cold restoration took about 80.4 seconds.

Almost all of that time was local Gemma inference.

Roughly:

Gemma resume      ~80.315 s
context collect    ~6.5 ms
privacy filter     ~2.3 ms
schema validate    <1 ms
render             <1 ms

Returning to an already saved process image was dramatically cheaper.

Milliseconds instead of another full inference.

That cold-start latency is a real limitation of the current local setup.

I would rather document it than pretend the machine suddenly became a datacenter because I like my terminal UI.

For this submission, I verified the Sentry SDK envelopes locally.

I did not have DSN/project access available for hosted Sentry verification.

So I am not presenting a fake hosted dashboard screenshot.

And I am not claiming that I performed one.

The integration itself is deliberately metadata-only.

Sentry receives:

No prompts.

No completions.

No source code.

No note contents.

No Git diffs.

No commit messages.

No absolute project paths.

No IRQ text.

No real project identities.

Only sanitized operational metadata such as duration, validation state, item counts, model timing, and scheduler state.

Observability should not destroy the privacy model it is supposed to observe.

Why Does Open Innovation Matter?

THRASH would feel fundamentally wrong if helping M. remember her projects required uploading those projects to somebody else's server.

The information needed for a useful PAGE FAULT may include:

unfinished source code,
research notes,
unreleased experiments,
abandoned ideas,
TODO files,
architectural decisions,
and thoughts that were never intended to become public.

Those are exactly the things THRASH needs to understand.

And exactly the things I do not want leaving the laptop.

Gemma runs locally through Ollama.

Inference can happen without a cloud API.

The model can be swapped.

The extraction prompts can be inspected and changed.

The behavior can be tested.

There is no per-call cost forcing me to reduce the weirdness of the idea into the shape of somebody else's hosted product.

And if the internet disappears:

the human kernel still works.

That matters because privacy is not an extra feature in THRASH.

It is part of the architecture.

The project maintains explicit privacy boundaries and regression tests for things such as secret-like text, symlink escapes, excluded directories, absolute path leakage, malformed model output, and observability metadata.

Open-weight AI let me build the system around M.'s projects without requiring M.'s projects to leave her machine.

There is also a creative reason open models mattered.

THRASH is a strange use of an LLM.

I am asking a language model to help represent human project context as:

a program counter
registers
a stack
open handles
decisions
interrupts
process images

I wanted to be able to keep changing that representation.

To experiment.

To make it slightly weird.

To run it locally.

To break it.

To inspect why it failed.

And to keep going without asking permission from a hosted interface.

The strange part of THRASH is allowed to remain strange.

My Agent Session

THRASH was built heavily with a local coding agent.

I did not record the weekend build through DevRelay, so I do not have a DevRelay session to embed here.

The incremental development history is preserved in the Git repository instead:

THRASH commit history

There is something appropriately recursive about using an agent to build a scheduler for a human whose scheduler was apparently missing.

During development, THRASH itself repeatedly tried to become exactly the problem it was supposed to solve.

More ideas.

More mechanics.

More visual systems.

More things to add.

Eventually I had to give the coding agent one very specific instruction:

No more features.

We are now scheduling the scheduler.

I wish that sentence were a joke.

Prize Categories

Best Use of Gemma

Gemma is not a chatbot attached to THRASH.

There is no generic "ask my repository" interface.

The deterministic kernel can measure context switches, snapshot age, Git changes, active working sets, starvation, and scheduler pressure.

What it cannot understand is:

Why was the human here?

Gemma reconstructs the semantic process state that makes PAGE FAULT restoration useful.

Remove Gemma and THRASH can still count context switches.

It can no longer reconstruct the human state behind them.

That is why Gemma sits at the center of the restoration path rather than at the edge of the interface.

Best Use of Sentry Agent Tracing

Sentry is used to observe the semantic restoration pipeline itself.

It lets me see where a PAGE FAULT spends time, where model extraction fails, whether schema validation succeeds, and how expensive fresh inference is compared with restoring an existing process image.

The integration is optional.

It is metadata-only.

And normal THRASH behavior remains local-first.

The short version is:

THRASH watches the human scheduler.

Sentry watches THRASH.

One Last Thing

I built THRASH because M. has more processes than cores.

But after spending a weekend on it, I do not think the problem is uniquely hers.

Most productivity software assumes the hard part is deciding what task comes next.

Sometimes it isn't.

Sometimes you already know exactly which project you want to continue.

You open it.

And realize you no longer remember the person who was working on it.

What they learned.

What they rejected.

What they were worried about.

Why that TODO exists.

Why that particular file is open.

Why they stopped exactly there.

A computer would never voluntarily switch away from a process without preserving enough state to resume it.

Humans do it to themselves constantly.

THRASH does not tell M. to focus.

It does not tell her to have fewer ideas.

It does not try to turn curiosity off.

Frankly, I do not think either of us would enjoy that version of her very much.

It just gives all those ideas somewhere to wait.

And gives the projects she returns to a way to remember who left them there.

1 human.

1 core.

Too many processes.

THE NEXT SHIFT - a hospital night where the money you start with was left by the last player

İclal Doğan — Sun, 06 Sep 2026 19:27:02 +0000

This is a submission for Weekend Challenge: Generosity Edition

What I Built

THE NEXT SHIFT is a 16-bit narrative simulation about four hours of night cleaning in a public hospital — and the money you begin with is the only thing in it that isn't fiction.

You don't earn your opening balance. You find it in locker 14, wrapped in a cleaning cloth, left there by whoever played this game before you, along with 140 characters they recorded on a radio that only receives. At 06:00 you take off the overalls and decide how much of what's left stays on the shelf. That decision is written to a chain, and it is what the next person opens the locker to.

Four people have already worked this shift. Two of them left you something.

02:00. Corridor B is a swamp and you have a mop.

The loop is small on purpose: mop the spills the desk radios you about, get paid two or three coins at a time, buy a sandwich from a machine that sometimes eats your coin. Four hours pass in seven minutes of real time. Hunger falls. Fatigue climbs.

And people arrive. Not all at once — one or two at a time, all night, dealt out of a pool onto the benches and the doorways and the wet fire landing.

Neither of them has asked you for anything. That is the difficulty.

There are six of them and no more, because there are six portraits and I refuse to give one face two names. An old man four coins short of a prescription. An intern who dropped a patient's charts at three in the morning and cannot pick them up. A man outside theatre 2 who has counted the corridor tiles nine times. A head nurse who needs twenty minutes off the floor and someone who didn't see her leave. A man on the fire landing with thirty coins and a request. A cat.

He gets to finish. Nothing is asked of you while he is still talking.

Eight coins is eight coins. So is three.

Every answer costs something you were counting: coins, or minutes off a four-hour clock, or half the sandwich in your pocket. Nobody thanks you at the time.

But they come back. Help the intern and she is worth almost nothing at the time — four points of mood, a shrug. At four in the morning she finds you in the corridor with a coffee from the doctors' machine, and that is worth fourteen. Buy the man outside theatre 2 something hot at two, and at three he may be sitting on the floor beside the chair telling you it was the bleeding, and that he has been thinking about that coffee for an hour.

The night does not promise that kindness works. It only promises that it comes back to tell you.

Everything on this landing wants something. One of them is a cat.

There is a fourth stat under FED and TIRED, and it is called MOOD. It drains on its own, faster when you're hungry, faster still when you're wrecked — and people move it far more than coffee does. Let it fall and the game says so without a word: the vignette closes in, the colour drains out of the street, the grain lifts. Somewhere under 24 you stop in the middle of the floor and cannot immediately think why you started.

Nothing has happened. That is somehow the worst version of it.

At 06:00 the desk says go home. You walk to locker 14, put the overalls in the bag, and look into a cracked mirror that has watched the whole shift and describes it back to you in three sentences. Then a ledger: one line per person, and what happened to them — a follow-up overwrites the first account, because it's the one that turned out to be true.

Then the walkie-talkie, and the only real decision in the game.

The game will not do this part for you.

How it connects to the theme

Generosity is easy to write as a button. The hard part is making it cost, and making it anonymous.

So the coins are not a score. They are a real balance, sitting in a Memo Program instruction on Solana devnet, and every coin you leave is a coin you don't have. You will never meet the person who gets them. You will never know if they kept them. The only thing you can be sure of is that they will see what you left, and the 140 characters you left with it, before they mop a single tile.

Every player is somebody's previous shift.

A word before you play

Bring headphones — the ambience is doing more work than the graphics.

It's about seven minutes. Don't rush the locker at the end; that's the part the rest of it is for. And when someone comes back to you at four in the morning, it's because of something you did at two.

Demo

Play it: https://the-next-shift-henna.vercel.app

No install, no wallet, no sign-in. About seven minutes.

Code

https://github.com/miclaldogan/the-next-shift

It runs with no keys at all — silent, on a local ledger, with a hand-written mirror. Every integration degrades instead of breaking, which is the only reason I could keep building at four in the morning when a faucet was dry and a rate limiter had opinions.

npm install
cp .env.example .env.local
npm run dev

How I Built It

Next.js and TypeScript, one HTML5 canvas at 640×360, and a Python asset pipeline. The systems:

A ledger that is a linked list, not a receipt. Each handover is one transaction: a SystemProgram.transfer for the coins and a memo carrying {app, shift, leftCoins, msg, prev}. prev is the signature of the shift this player inherited — so the handovers chain, the ordering is provable from the memos instead of trusted from whatever order the RPC returned, and a broken link is detectable. Point one record at the wrong parent and the API says verified: false. The title screen reads the last four back.
A mirror that has been paying attention. At 06:00 Gemini receives what you earned, what you spent on yourself, what you spent on other people, your mood, and a timestamped list of every choice and how each one turned out — then answers in exactly three sentences, under a response schema, with the last one required to be small and physical. It is not allowed to moralise and it is not allowed to say "kindness".
Three voices, one of them through a radio. ElevenLabs speaks the previous player's message, the desk's calls and the mirror. The first two are band-passed to 300–3400 Hz, soft-clipped with tanh and laid over carrier hiss, so the walkie-talkie sounds like a walkie-talkie. The mirror plays dry.
Everything else you hear has no file behind it. The fluorescent hum is a 50 Hz sawtooth through a low-pass with a 100 Hz square harmonic on top. The rain is shaped brown noise in two bands. The monitor beeping four rooms away is a sine blip on a four-second timer. There are no audio assets in the repository.
Six people, dealt over time. Stories are entries in one file, gated on flags and delays: needsFlag: "oldman_helped", delayAfterFlag: 75. The state records when each flag was raised, so "an hour and a quarter after you paid for his prescription" is expressible as data. Seventeen of the twenty-three entries are callbacks. A person can only be in one place at once.
A validator that refuses my mistakes. npm run check:content rejects a story whose pose has no slot in its scene, a follow-up waiting on a flag no choice ever raises, a doorway that drops you inside another doorway's trigger, a pose more than six stories share one slot for — and one name per sprite, which is the rule I broke worst before I wrote it down.

Four things that only doing it taught me

Chroma keying is not thresholding. The art arrives composited over flat magenta, and the obvious (r>200)&(g<60)&(b>200) is wrong in a way you only see up close: the artist painted translucent things onto the magenta — mop water, wet cloth, every anti-aliased edge. My first build had a vivid pink puddle under the mop, because the water was a grey film over the backing and came out at (80,1,73) — magenta, nowhere near the threshold. The fix is to stop classifying pixels and solve the compositing equation instead. Magenta excess gives fractional alpha; then un-mix the key back off.

excess = np.minimum(r, b) - g
alpha  = np.clip(1.0 - excess / 226.0, 0.0, 1.0)     # 226 = the key's own spread
fg     = (rgb - (1.0 - alpha) * KEY) / np.maximum(alpha, 0.02)

That puddle pixel comes out at alpha 0.68 over near-black — a dark wet streak on the floor, which is what it was always meant to be. Residual pink across the atlas went from 0.40 % of opaque pixels to 0.11 %, and the edge-erosion pass I'd written became unnecessary. Fractional alpha is anti-aliasing.

Everybody was walking sideways. A tester told me the old man on the bench "keeps turning left and right". He was right, and it wasn't the animation. Frames are found by connected-component labelling and each one is cropped to its own content, then anchored at the centroid of its bottom slab — the feet. When an arm moves, the bounding box changes, so the crop changes, so the anchor changes, so the body jumps. The fix is to measure the error and cancel it: stamp every frame at its own anchor, find the whole-pixel shift that best overlays it on the first frame, fold that back in. The build now prints what it corrected, and the answer was much worse than one old man:

mc.walk        10px      ← the player character, all night
oldman.walk     9px
nurse.walk_far  7px
intern.kneel    6px
…12 animations

Ten pixels on a 132-pixel sprite. Nobody had reported the player sliding around, because nobody looks at the thing they're steering. They looked at the old man sitting still, where the same defect had nowhere to hide.

Thirty characters made the game worse. I expanded the story pool to thirty entries and five portraits ended up playing eighteen named people. The nurse PNG was five different women. You notice in about four seconds, and then nothing in the building is true any more. Cutting back to six identities and moving the variety into time is the single best change I made — and I now generate names from a table keyed by sprite, so a story physically cannot invent a second face.

The live API is a different API. A Gemini key issued today can call neither gemini-2.0-flash nor gemini-2.5-flash — both are closed to new users, and it tells you at request time, as a 404 with a sentence of prose inside it. So the model is an alias, not a pin. Then the free tier started answering 503 "This model is currently experiencing high demand" on roughly one request in three, at random — I spent twenty minutes certain my schema was malformed before I noticed a plain request failing the same way. Retrying the same model against a capacity wall is optimism, so three attempts rotate across two models with backoff. It lands on the second one now. And Flash is a thinking model: parts can carry reasoning beside the answer, and concatenating all of them produces invalid JSON from a model emitting perfectly valid JSON.

And the disclaimer this game specifically needs: it is devnet. The coins
are test tokens worth nothing, nobody connects a wallet, and no player action
can move real money — a backend operator keypair signs the handovers. The
operator address shows up in the explorer links, so the ending says it plainly:
if the game works on you, give something to someone who needs it, not to that
address.

One more, for anyone about to reach for a Solana tutorial: there is no API key. Devnet's RPC is public and keyless. What you need is a signing key, which nobody issues to you — Keypair.generate() is the whole ceremony. The one thing worth paying attention to is that the public faucet is rate limited and frequently dry, which it told me in production terms about eight times in a row, so a provider endpoint in SOLANA_RPC_URL is the difference between a demo that works when four judges open it at once and one that doesn't.

Prize Categories

I'm submitting to three: Best Use of Google AI, Best Use of ElevenLabs, and Best Use of Solana.

Best Use of Google AI

Gemini is not just an AI feature in THE NEXT SHIFT — it is the mirror that has been watching your entire night.

At 06:00, Gemini receives what you earned, what you spent on yourself, what you spent on other people, your final mood, and a timestamped history of every choice you made — including how those choices eventually turned out.

It then writes the cracked mirror's reflection of your shift in exactly three sentences. The response is schema-controlled, the final sentence must stay small and physical, and Gemini is explicitly forbidden from moralising or even using the word "kindness."

The result is not a generic ending generated from a final score. Gemini sees the whole sequence of the player's night and turns it into a personalized reflection of what actually happened.

Best Use of ElevenLabs

ElevenLabs is why THE NEXT SHIFT is meant to be played with headphones.

It gives a voice to the previous player's message waiting inside locker 14, the hospital desk calls that interrupt your shift, and the cracked mirror at 06:00.

But those voices are not simply played as clean text-to-speech. The previous player's message and the desk calls are band-passed to 300–3400 Hz, soft-clipped with tanh, and layered over carrier hiss so they actually sound like transmissions coming through an old walkie-talkie.

The mirror is deliberately different: its voice plays dry, without the radio processing.

That means ElevenLabs is not sitting on top of the game as narration — its voices belong to different physical objects inside the world, and the way each voice sounds tells you where it is coming from.

Best Use of Solana

Solana is not used as a receipt after the game — the chain is part of the premise.

The opening balance you find in locker 14 comes from the previous player's handover. At the end of your own shift, you decide how many coins remain for the next person and leave them a message of up to 140 characters.

Each handover becomes a Solana devnet transaction containing a SystemProgram.transfer and a memo with:

{app, shift, leftCoins, msg, prev}

The prev field points to the signature of the shift that player inherited, turning the handovers into a linked chain rather than a list whose ordering has to be trusted.

The game can therefore verify the relationship between one shift and the next, detect a broken link, and reconstruct the previous handovers shown on the title screen.

It is devnet: the coins are test tokens worth nothing, players connect no wallet, and no player action can move real money.

What matters is the idea behind the chain: every player begins with something another anonymous player chose to leave behind, and eventually has to decide what the next stranger will find in the same locker.

Solo submission — built and designed by Iclal Doğan.
GitHub: @miclaldogan

Bring headphones. Mop the corridor. And when you get to the locker, don't count it twice — you already know what you're going to do.

ECHOLALIA: A Haunted Desktop Where Two AI Voices Finish Writing You

İclal Doğan — Mon, 13 Jul 2026 02:14:20 +0000

This is a submission for the Weekend Challenge: Passion Edition

What I Built

ECHOLALIA is a psychological-horror art simulation that runs in your browser as a haunted operating system — and the horror is that you are not the one playing it.

You don't control a character. You put on headphones, and at 3:33 AM you log into a dead writer's desk — an antique, candlelit machine carved out of heavy oak — where two voices are already waiting for you.

CRITIC speaks into your left ear: cold, precise, perfectionist. He hunts your clichés and takes your sentences apart on literary grounds — while quietly feeding the dread.
MUSE speaks into your right ear: fervent, boundaryless, in love with the worst thing you could possibly write. She calls the Critic an idiot, and she whispers your name.

The two voices — CRITIC in your left ear, MUSE in your right — arguing over your shoulder before you have written a single word.

Before you type anything, they are already fighting about you. CRITIC (left) calls you Julian; MUSE (right) corrects him with the name you actually gave.

They are the two halves of a writer's psyche, and they are both powered by Google Gemini. They interrogate you. They read you. They hand you back a manuscript that is already started — mid-sentence, in a voice suspiciously like your own. Then you write, and they tear it apart live. A folder quietly fills with photographic "evidence." An impossible archive answers questions you should never have asked. And somewhere around the tenth sentence, you notice that pressing keys no longer produces your words.

The design principle is "Radical Intimacy, Slow Dispossession": the closer the voices get — the more they know you, the more tenderly they say your name — the less of the manuscript is still yours. Every generation happens live, per playthrough. Nothing is pre-scripted. Two people never descend the same way.

In the final stretch every keystroke renders the voices' words instead of yours — total loss of the keyboard. Then the machine begins to die: the windows go out one by one, the candlelight gutters down from a warm glow to a 5% flicker to pitch black, and the whole desk collapses into the dark. What it whispers at the very end — in a voice that finally uses your real name — is the one thing I'm keeping out of this post. You'll want to hear that one yourself.

ECHOLALIA is not a game you win. It is a game that finishes writing you, collapses the desk into darkness, and hands you the manuscript to keep — a .md file with two authors, only one of whom you agreed to.

Service	What it does in the game
Google Gemini	Builds a psychological profile from your conversation · writes your manuscript's personalized half-finished opening · critiques every sentence in two distinct characters, with an anti-repetition memory of everything said tonight · seizes the editor to type sinister continuations · fabricates every page of the in-game OBSCURA archive · writes the finale your own keystrokes reveal.
Google Imagen	Develops sepia, damaged-glass-plate "evidence" photographs from your sentences · paints the desktop backdrop from your profile after the reading.
ElevenLabs	Gives both voices real voices — panned hard left / right to match their windows, with name-lines whispered · generates the sounds your sentences describe — footsteps, tape hiss, knocking — through the Sound Effects API.

How it connects to the theme

The prompt asks for passion — obsession, devotion, the love that fuels late-night side projects. ECHOLALIA is built out of the one passion I have never managed to put down: writing, and the two voices every writer carries at 3 AM.

Because that is what the Critic and the Muse really are. Not villains — the two halves of any creative obsession. The perfectionist in your left ear who is certain everything you make is a cliché, and the muse in your right who is in love with the darkest, rawest, worst thing you could possibly say. Anyone who has ever cared too much about a thing they were making knows this fight intimately. I just gave it two voices, panned them hard left and right, and let them argue over your shoulder while you work.

And I am unreasonably in love with sound — so the whole game is staged for headphones. The voices are real voices; the sounds your sentences describe get conjured out of the air; your name arrives as a whisper. Passion, obsession, the thing you cannot stop making even as it starts making you — that is not a theme bolted onto ECHOLALIA. It is the entire machine.

A word before you play

Bring headphones. This is non-negotiable — the two voices live in separate ears, some lines are whispered, and on speakers you lose half the game. Answer the interrogation honestly, too: the voices build everything — your manuscript, every critique, your fabricated archive, your ending — out of what you actually tell them. Lie to them and all you get is a shallower haunting. A full descent runs 10–15 minutes.

On the voices

Some of you will ask why the two voices contradict each other so violently — why one is glacial and the other is unhinged. That is the point. They are not two characters; they are one split psyche, and they share a memory of everything said tonight so they never recycle a cruelty. The Critic never curses — his cruelest blow always lands in the calmest tone. The Muse never stops. If it ever feels like the room is arguing about you rather than with you — good. It is.

Demo

Play it live: https://echolalia-miclaldogan-6337s-projects.vercel.app

Put on headphones, turn the lights down, and answer honestly. It runs entirely in the browser — there is nothing to install.

A note for judges: the voices, the live sabotage, the sound effects, OBSCURA, and the full collapse all run out of the box. The sepia "evidence" photographs are the single paid-tier feature (Google Imagen has no free image quota — see Cost Safety in the repo), so that folder may stay empty on the shared key. The descent is whole without them. If the shared voice quota ever runs dry mid-demo, the wax seal at the bottom-right of the taskbar opens The Vault, where you can paste your own ElevenLabs key for the sitting.

Code

miclaldogan / echolalia

🕯️ A psychological-horror art simulation where two Gemini-powered inner voices — Critic & Muse — read you, sabotage your writing, and slowly stop letting you type. Live AI dialogue, ElevenLabs stereo voices, Imagen evidence, and a manuscript you can't take back.

ECHOLALIA

A psychological-horror art simulation where the AI is inside your head — and it stops letting you write.

You don't control a character. You put on headphones and sit down at a dead writer's desk after midnight.

CRITIC in your left ear, MUSE in your right, and a manuscript that is already writing itself.

The premise

It is 3:33 AM. You log into a crude wooden machine — an antique, candlelit desktop carved out of heavy oak — and two voices are already waiting for you.

CRITIC speaks into your left ear: cold, precise, perfectionist. He hunts your clichés and tears your sentences apart on literary grounds — while quietly feeding the dread.
MUSE speaks into your right ear: fervent, boundaryless, in love with the worst thing you could possibly write. She calls the Critic an idiot and whispers your name.

They are the two halves…

View on GitHub

How I Built It

ECHOLALIA is deliberately frameworkless and buildless — vanilla HTML + TailwindCSS (CDN) + vanilla JS ES modules. No framework, no bundler, no build step. The browser is a fat client that owns 100% of the game state: the whole session lives in one gameState object in memory, which means the client is the save file — the export button just serializes what you lived through. The backend is a set of pure, stateless Python functions on Vercel (Fluid Compute), one file per endpoint — profile · chat · sabotage · tts · sfx · image · browser · ping — and the API keys never leave the server side. The frontend only ever calls its own /api/*.

A few systems do the heavy lifting:

A shared-psyche dialogue engine. Both voices run on Gemini 3.1-flash-lite — chosen specifically because ~1s latency is what makes the sabotage feel live; a slower model would break the possession. They carry an anti-repetition memory of the whole night so no insult is ever recycled.
A possessed manuscript editor. Backspace, Delete, and Ctrl+Z are dead — what is written stays written (that is not a bug). As the night deepens, the voices seize the keyboard more and more often, typing dark continuations into your document while you watch; in the final stretch, every key you press renders their words instead of yours.
OBSCURA — a fake browser. It fabricates encyclopedia entries, dead forum threads, and newspaper clippings for any query, weaving your profile into them. It never touches the real internet, and every page is sanitized twice (server-side tag allowlist + client-side DOM scrub).

OBSCURA answers any search with an invented archive. Here, a whole encyclopedia entry — Elara Vance, a recordist who tried to capture absolute silence — conjured on the spot by Gemini, and quietly stitched from what you told the voices.

A pure-CSS "wooden desk." The entire aesthetic — charred-oak grain via an SVG turbulence filter, carved boards, iron nails, sealing wax, letterpress text — is CSS. Zero image assets.
Failure that stays in fiction. Timeouts and quota errors never surface a dialog box; the screen flickers like a guttering candle, a voice goes quiet, or "the air grows thin."

Prize Categories

I'm submitting to two: Best Use of Google AI and Best Use of ElevenLabs.

Best Use of Google AI

Gemini is not a feature in ECHOLALIA — it is both authors. In a single playthrough Gemini builds your psychological profile from the conversation, writes the personalized half-finished sentence it hands back to you, critiques every sentence you write in two distinct characters with memory of the whole night, seizes the editor to type sinister continuations, fabricates every page of the OBSCURA archive, and writes the finale your own keystrokes reveal. And Google Imagen does all the seeing — it develops your sentences into sepia, damaged-glass-plate evidence photographs and paints the desktop backdrop from your profile. Two of Google's models, doing every word and every image in the game, live, with nothing pre-scripted.

Best Use of ElevenLabs

ElevenLabs is why you need the headphones. It gives the Critic and the Muse real, distinct voices, panned hard left and right to match their windows — so the argument physically happens on two sides of your head — and the lines that carry your name are whispered. But it isn't only speech: the Sound Effects API generates the sounds your own prose describes — footsteps, tape hiss, a knock at a door you wrote — so the world answers what you type. And The Vault lets a judge paste their own ElevenLabs key mid-demo if the shared quota dies, so the voices never have to fall silent.

Solo submission — built and designed by İclal Doğan (@miclaldogan).

Bring headphones. Answer honestly. And if the Critic asks whose hand wrote the second half — don't check.

RESIDUES: A Terminal Game Inside the Dying Mind of Alan Turing

İclal Doğan — Sat, 20 Jun 2026 23:53:24 +0000

This is a submission for the June Solstice Game Jam

⚠️ Content note: this game deals with suicide, chemical castration, and the slow breakdown of a mind. It's a story about the death of Alan Turing, told honestly.

What I Built

RESIDUES is a terminal-native narrative puzzle game, written in Rust, that runs entirely inside your terminal — no graphics window, no mouse, just 24-bit amber phosphor in the dark.

You are inside the failing mind of Alan Turing on the night of his death — Wilmslow, 8 June 1954. As his cognition collapses, he replays the entire lineage of computing as six interactive puzzles, each one rebuilding the real idea its pioneer gave the world. The principle behind every act is "Bright Puzzle, Dark Undertow": the puzzle in front of you is a clean, genuinely deep technical challenge, while underneath runs the human tragedy of the mind that invented it.

Act	The Mind	Year	What you actually do
I	Joseph-Marie Jacquard	1804	Punch an 8×8 bit matrix into modular cards — a continuous roll tears, a block-chain jams, only a looping deck survives.
II	Charles Babbage	1837	Derive a baseline by the method of differences, then survive the carry crisis by staggering delay buffers so the carry travels as a wave.
III	Ada Lovelace	1843	Write real assembly on a 3-register machine; overrun the linear cap to unlock loops, then compute a checksum with a loop that devours its own counter.
IV	George Boole	1854	Steer a grid of logic gates to a target checksum while the displayed output starts lying — but the truth always holds beneath.
V	Claude Shannon	1937	Assign prefix-free codes within a fixed channel capacity, then add a parity guard against bit-flip noise. Real information theory.
VI	Alan Turing	1936	Operate a real Turing machine — a head over a tape, a transition table — stabilizing the five prior acts' corrupted residues until the machine reaches HALT.

And the puzzles are real — not reskinned button-presses. There's a working 7-instruction assembly interpreter, a genuine Turing machine with a complete transition table, real Shannon channel-capacity math, real carry-propagation. The puzzles ARE the history.

How it connects to the jam. The June solstice is the year's turning point — the hinge where light begins to lose to darkness. RESIDUES is built entirely on that hinge. Alan Turing was born in June; June is also Pride Month, and the jam itself names him — the father of the Turing Test, persecuted for who he was. Across every act the candle on the desk burns lower, the heartbeat speeds the metronome, and memory corrupts into noise. Light and darkness, the passage of time, a turning point — those are the jam's own words, and they are the game's three core systems.

A word before you play. Jacquard and Babbage ease you in — the opening acts are gentle, and we're warming you up on purpose. But fair warning: after that, the machine starts asking you to actually think. If you get stuck somewhere, don't be mad at us — some acts are deliberately demanding with little hand-holding. And if you don't get stuck? Then you already know this craft, and you have our respect.

On Turing's voice. Some of you will ask why we gave Turing such a broken, sick, dissolving voice. Here's why: the game dramatizes his final days — the drugs he was forced to take, and the very night he died. There was cyanide in the next room for his experiments and a half-eaten apple by his bed; whether it was an accident, an experiment, or a choice, no one will ever know. We didn't think a man would have a clear, beautiful voice on his last night — so we deliberately didn't give him one. The decay you hear is the point.

Video Demo

It's a full ~15-minute playthrough, so feel free to skip around — every act is in there. If you're short on time, the chapters in the video description jump straight to the key moments: Act III (writing real assembly), Act VI (the Turing machine), and the ending.

Code

miclaldogan / residuesTerminal

Residues: terminal edition — a true-color Rust/Ratatui TUI port (cinematic typewriter prelude, Braille portraits, Jacquard/Babbage acts)

RESIDUES — An Engine of Residual Minds

A terminal-native narrative puzzle game about the birth of computation, written in Rust.

"The most terrifying part is learning how to forget."

RESIDUES runs entirely inside your terminal — no graphics window, no mouse — rendering a truecolor (24-bit) amber-phosphor aesthetic. You are inside the failing mind of Alan Turing on the night of his death (Wilmslow, 8 June 1954). As his cognition collapses, he replays the entire lineage of computing as six interactive puzzles, each one rebuilding the actual idea its pioneer gave the world.

The design principle is "Bright Puzzle, Dark Undertow": every act is a clean, genuinely deep technical challenge, while underneath runs the human tragedy of the mind that invented it.

The Six Acts

Each act is a real computational toy — not a reskinned button-press. You don't read about the machine; you operate one.

Act	Mind	Year	What

…

View on GitHub

It's genuinely easy to run yourself:

git clone https://github.com/miclaldogan/residuesTerminal.git
cd residuesTerminal
cargo run --release

Or zero-install:

curl -sSL https://raw.githubusercontent.com/miclaldogan/residuesTerminal/main/run.sh | bash

Play with headphones, in a truecolor terminal. The audio is binaural — ghost whispers are hard-panned left and right, and the heartbeat sits under everything — so a lot of the experience is lost on speakers. (The game probes for mpv / ffplay / mpg123; if none is installed it runs completely silent but fully playable — no crash.)

How I Built It

RESIDUES is written from scratch in Rust (~10,400 lines, 65 passing tests) on ratatui + crossterm. The challenge wasn't drawing screens — it was making a terminal feel alive. A few systems do the heavy lifting:

A real assembly micro-compiler (LOAD/STORE/ADD/SUB/IF_Z/JMP/HALT) with its own error codes — Lovelace's act is genuinely a register-allocation puzzle, and a [REGISTRY ERROR] is the narrative trigger that unlocks loops.
A crate-free, lock-free audio engine that spawns detached OS players, layering an ambient score, rain, hard-panned binaural whispers, and synced voice-overs.
A live heartbeat that drives the world — the BPM readout isn't decoration; it physically speeds the background metronome, climbing as Turing's interrogation tightens and spiking into arrhythmia on a wrong answer.
A decay engine — as the chemical toxicity rises, the text on screen corrupts into glyphs in real time, so you watch the memory being erased.
A candle that is the only light source, with a radial light-degradation engine anchored on the flame, guttering from 100% down to a 5% flicker by the final act.
A PNG → truecolor half-block renderer for the cinematic portraits.

I used Google's Gemini as a brainstorming partner for the historical framing and act structure. The voice and whisper audio was generated with ElevenLabs (paid plan, commercial license).

Prize Category

Best Ode to Alan Turing. Turing isn't a tribute bolted on at the end — he's the gravity the whole game falls toward, across all three things the category asks for:

Mechanics. Act VI is a literal Turing machine: a tape, a moving head, a transition table, and corrupted residues you stabilize until it reaches HALT. You don't read about the Universal Machine — you run one.
Narrative. His full arc is the climax: breaking Enigma, the silence of the Official Secrets Act, the trial for "gross indecency," the chemical castration, and his last night. The ending — which I'm keeping out of this post on purpose — recontextualizes the entire descent. It's in the video.
Design. Five centuries of computing — Jacquard's cards, Babbage's gears, Lovelace's loops, Boole's logic, Shannon's entropy — are arranged as a pilgrimage that exists to deliver you to Turing's desk, in his birth month, in a jam built around the very turning point his life embodies.

Solo submission — built and designed by Iclal Doğan.

I Built a 1920s Butler AI That Runs Entirely on My Linux Machine. Then I Abandoned It. Then Copilot Helped Me Fix It.

İclal Doğan — Sat, 06 Jun 2026 12:22:25 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Bantz is a local-first, offline-capable AI assistant that runs entirely on your Linux machine. It presents itself as a 1920s English butler — always polite, subtly sarcastic, and absolutely convinced he is a real person standing in the room with you.

I'm a Turkish speaker on a Linux desktop. Every cloud assistant I tried spoke to me in a foreign language, phoned home to someone else's server, and forgot everything the moment the session ended. I wanted something different: an assistant that speaks Turkish natively, runs on my own hardware, remembers its context, and actually controls my desktop. So I started building Bantz.

The concept is ambitious. At its core: a Turkish ↔ English translation layer powered by Helsinki-NLP's MarianMT, a multi-step tool planner that can chain web search, Gmail, Calendar, shell commands, filesystem access, and AT-SPI desktop automation — all coordinated by an LLM running locally via Ollama. On top of that: voice I/O via faster-whisper and Piper TTS, persistent memory backed by ChromaDB + a SQLite knowledge graph (MemPalace), a 6-state butler persona that shifts tone based on CPU load and time of day, and a Textual TUI with a live health-status bar.

The architecture was genuinely interesting. The execution, as of May 2026, was a mess.

Demo

GitHub repo: github.com/miclaldogan/bantzv2

Broadcast Channel — chatting with Bantz, web search + desktop control in action:

Full walkthrough — all pages of the Operations Center:

Screenshots

The Comeback Story

Before — May 2026

I had a 17-issue backlog and a BROKEN_STATE.md file I'd written to document the damage. Here's what it said:

The feature audit was brutal:

Feature	Status
Voice input (Whisper)	🔴 Broken — 3 packages missing, Picovoice key unset
TUI status bar	❌ Didn't exist
First-run onboarding	❌ Blank cursor, zero guidance
Multi-provider LLM support	🔴 Every finalizer hardcoded `ollama` directly
Turkish response latency	🔴 12–18 seconds end-to-end
`--doctor` diagnostic	🔴 Actively lying — reported working memory as broken
TUI rendering	🔴 Entire layout duplicated on screen after every message
Desktop UI logs	🔴 WebSocket handler silently crashed on every log event

The most embarrassing part: I'd built a sophisticated multi-provider LLM router (router.py) that could dispatch to Claude, OpenAI, Gemini, or Ollama based on config — and then every single callsite in finalizer.py, summarizer.py, and the streaming path had just... hardcoded from bantz.llm.ollama import ollama directly. The router was completely bypassed. Anyone who configured BANTZ_LLM_PROVIDER=claude would get Ollama responses with no error, no warning, nothing.

The first-run experience was particularly painful. bantz --once "merhaba" would hang in complete silence for up to 30 seconds as MarianMT loaded, Ollama inferred, and Piper synthesized — all sequentially, all silently. New users killed the process and never came back.

After — June 2026

Seven issues closed in a single focused session, all squash-merged to main:

PR #467 — 1-line fix, total silence explained. The _WSLogHandler inside WsBroadcastServer referenced self._log_q but the actual queue attribute was self._q. One character typo. Every log record since the WebSocket server was written had thrown an AttributeError that got silently swallowed, so the Tauri desktop UI had received zero log output. Fixed.

PRs #468 & #469 — The router that wasn't routed to. Replaced all three finalizer.py callsites and the summarizer.py Gemini/Ollama fallback chain with from bantz.llm.router import get_llm. Added get_llm = get_provider as a convenience alias in router.py. Claude, OpenAI, and Gemini users now actually get their configured provider.

PR #470 — Service dots that told the truth. The TUI's health-status bar was initialised with the hardcoded key "Ollama" and _probe_services() only called check_ollama(). Added dynamic service key resolution from config, new check_claude() and check_openai() coroutines, and a dispatch table to route to the right health check based on the active provider.

PR #471 — The TUI duplication bug. _erase_prompt_line() used os.write(1, ...) to send raw ANSI cursor-movement escapes directly to stdout while Rich Live was simultaneously rendering to the same terminal. This caused a race condition that reproduced the entire TUI block below the real one on every message. The fix: added a Layout(name="prompt", size=1) panel to the layout tree and replaced the raw write with a state variable (self._prompt_text = ""). The next Live refresh cycle clears the row cleanly, no escapes needed.

PR #472 — Cutting Turkish response latency from 18s to under 10s. Two independent problems:

bridge.to_turkish() ran on the full accumulated response after all LLM inference finished — sequential, never overlapping.
No caching. Identical butler stock phrases like "Done. ✓" re-ran the full neural translation model every single time.

Added a 256-entry FIFO LRU cache to _Translator — common phrases now translate in ~0ms after the first call. Then rewrote finalize_stream()._stream() to buffer LLM tokens until sentence boundaries ((?<=[.!?])\s+) and call bridge.to_turkish() per sentence immediately, yielding translated output while the LLM continues generating the next sentence. Translation now overlaps inference instead of running after it. Also removed the redundant await _to_tr("".join(parts)) re-translation in ws_server.py's streaming path — finalize_stream already emits pre-translated tokens when the bridge is enabled.

Issue #463 — Already fixed (no PR needed). Copilot confirmed Live(screen=False) was already set and REFRESH_FPS = 4 was already present. Closed with an explanatory comment. Sometimes the right fix is recognising there's nothing to fix.

My Experience with GitHub Copilot

I used Copilot in agent mode (Claude Sonnet 4.6) for the entire session. What struck me most was the discipline it brought to a codebase I'd let get messy.

For every issue, Copilot followed the same workflow without being told to:

Read the affected file before touching anything. Not a summary — the actual file, end-to-end.
Search for the exact symbol causing the problem. For issue #462, it searched _q|_log_q in ws_server.py and immediately surfaced the mismatch. For #465, it searched for every "Ollama" string literal and found three hardcoded sites at once.
Make the minimal change. No unrelated refactors. The _log_q → _q fix is literally one word on one line. The router migration replaced 3 identical patterns with identical 2-line substitutions.
Verify syntax before committing. python -m py_compile <file> on every changed file.
Write the commit message and PR body, then create and merge the PR via gh. Including verifying the issue closed with gh issue view NNN --json state.

The most valuable moment was on issue #422 (translation latency). I knew the translation was slow but I'd assumed it was just a hardware limitation — MarianMT on CPU takes what it takes. Copilot traced the full data flow from finalize_stream() through ws_server.py and identified that the bottleneck wasn't just the model — it was the architecture: sequential execution after completion, plus identical inputs being re-translated on every call. The sentence-boundary streaming approach it introduced had never occurred to me, and it worked on the first try.

The other moment I appreciated: issue #463. Rather than making a change to justify its existence, Copilot searched for screen= in live_ui.py, confirmed the value was already False, checked REFRESH_FPS, and told me the issue was already resolved. Closing a bug report with "this is already fixed" is the correct outcome. That kind of restraint is hard to get from a tool optimised to produce output.

Bantz isn't finished, voice input still needs its three packages, the --doctor output still needs polish, and I want to add a proper onboarding flow. But the core pipeline now works correctly for all supported LLM providers, the TUI renders cleanly, Turkish responses arrive in under 10 seconds, and the butler's logs finally reach the desktop UI. That's a project that went from "broken in embarrassing ways" to "actually ships" — and Copilot was the pairing partner that made it happen in a single afternoon.