DEV Community: Dreven

I Gave Two GitHub Repositories a Terrible Idea. Then I Gave It Life.

Dreven — Sun, 01 Nov 2026 06:54:56 +0000

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

The monster had a complaint:

Stop trying to feed me those foreign files, I can't steer my legs properly while chewing!

One parent was a tool that digests repositories. The other was a simulated fly. Gemma had given their imaginary child a problem neither parent could have alone: eating code made it difficult to walk.

That was the moment FrankenRepo started to feel alive.

What I Built

FrankenRepo is a gothic laboratory where two public GitHub repositories become one very questionable monster.

Choose a brain. Choose a body. Inspect their observable DNA. Select Useful, Cursed, or Chaotic, then pull the lever. Gemma invents a name, personality, inherited traits, a curse, first words, and a speculative useful mutation. The lab turns them into a downloadable Monster Birth Certificate.

I wanted repository discovery to feel like opening a cabinet of strange specimens. A web framework and a JSON processor become a specter suffering through nested brackets. A repository-eating crab meets a fly with simulated motor behavior. Familiar tools suddenly have a family resemblance.

The monster is fictional. The parents and their source links are real.

The standby creature above is original interface artwork. Model-generated certificates appear after an actual successful ritual.

Demo

The demo follows Flask + jq in Cursed mode through the local browser application: inspect the donors, invoke Gemma, reveal the creature, inspect its DNA, and export a PNG. It uses the actual provider and application, with no fixture responses or replayed model result.

52-second continuous local recording, captured on 1 November before the deadline. There is no public hosted application yet.

The new creature is The Scribe of Bracketed Sighs. Its proposed mutation gives Flask the web server and jq the JSON-log filtering: two recognizable roles, with feasibility still left to a human.

A second real specimen, The Scavenging Glider, supplied the chewing complaint in the opening:

HungryCrab supplied repository digestion; desktop-fly supplied simulated motor behavior. Gemma supplied the chewing problem. The suggested digest-to-movement integration is still speculative: a funny character can arrive before a workable adapter.

Code

Source and published v0.1 preview on GitHub · Saved real-run evidence · Asset credits

The source is MIT licensed. Use Node 24 and npm 11:

git clone https://github.com/drevendev/FrankenRepo.git
cd FrankenRepo
npm ci
npm run dev

Open http://127.0.0.1:5173. The interface opens without model credentials; generation requires an explicitly configured provider. The README explains setup. The newer persistence and orchestration work described below is a local update beyond the published v0.1 preview.

How I Built It

The stack is TypeScript workspaces, React/Vite, Hono, and Zod. The verified model is Gemma 4 26B A4B IT, served through Cloudflare Workers AI as @cf/google/gemma-4-26b-a4b-it. Gemma writes the creature; an original deterministic SVG kit draws it. This keeps the visual style consistent and makes PNG, SVG, and alt-text exports practical.

The important design decision was giving the laboratory three distinct kinds of truth:

Layer	What belongs there
Observed DNA	Public GitHub metadata and bounded README excerpts, with source links and observed commits
AI interpretation	The model's explanation of how a trait relates to those observations
Imaginary offspring	The creature's personality, curse, and proposed mutation

That separation runs through the UI and the data contract. The model can invent an anxious archivist; it cannot invent a source that proves the archivist exists.

Inspection uses fixed GitHub API endpoints, with request and response limits. FrankenRepo never clones or executes donor code. Missing observations stay unknown. README content is untrusted input, so it has no authority to change the application's tools or rules.

Gemma returns structured JSON. Zod checks its shape, and evidence validation checks that cited source IDs exist. A ritual gets at most two model calls: an initial attempt and one bounded repair, or an eligible deliberate revision. It eventually returns a result or a visible failure.

Keeping the experiment under control

The local update adds a private MongoDB Atlas archive and durable reservations. A restart preserves consumed allowances; an unknown provider outcome keeps its reservation. Saving a card is separate from consent to publish it. Private recovery keys never belong in public URLs.

Mastra runs the donor, context, model/validation, and reveal steps. Sentry records linked agent, tool, and inference spans with model IDs, timing, and token metadata, without sending raw prompts or card text. A Browserbase research session retrieved a pinned donor paragraph that entered a real model input. These integrations have local evidence; the category entries below describe their completed scope. Public hosting remains pending.

The update passed 78 unit/contract/policy tests and 18 desktop/mobile browser tests. Browser success fixtures test application behavior; the real Gemma receipts and recording establish provider use. They answer different questions.

The failure that changed the project

A structurally valid creature can still make an unsupported technical claim.

One early result turned the crab-and-fly pairing into an automated bug-finding insect. The name worked. The sources supplied no mechanism for finding bugs. Source IDs existed, but the proposed connection did not follow from them.

Later, an optional Ultramarine second opinion led to a real Gemma revision using the same frozen donor snapshots. The original survived unchanged. The revised text still promised a "verified lineage report" that the evidence could not support. The plumbing worked; the idea still failed review.

That changed my acceptance criteria. I added targeted checks for the failure classes I had observed. A subsequent Useful run was rejected after its bounded repair instead of showing a substitute creature. Those checks cover specific mistakes; semantic review is still necessary.

Three Paper Instruments requests changed the observed credit balance by $0.00108065. Cloudflare's billed cost and Neuron consumption were not captured, so I leave them unknown. A model's opinion and a dashboard estimate both need that same discipline: say exactly what was observed.

Seeing the ritual in Sentry

The screenshot below comes from the actual 31 October workflow: six linked spans, a 10.92-second root, and a 7.82-second Gemma request. Agent Activity shows the exact model, about 2K input tokens and 312 output tokens. Input and output bodies are absent by design.

Sentry's displayed cost is an estimate, not a Cloudflare bill. The model request sits inside the Gemma/contract step, so the trace distinguishes inference time from total workflow time. A separate deliberately injected notebook timeout verified that an optional-tool failure could continue without memory; it was a diagnostic test, not an observed Backboard outage.

Post-submission update, 1 November 2026: this screenshot and the Sentry category row were added after the challenge deadline, following permission to publish the sanitized telemetry. The underlying run was completed on 31 October. The original article and its five other category entries were published before the deadline; acceptance of this additional category is for the organizers to decide.

Why Does Open Innovation Matter?

The open-weight model provides the central creative behavior, and the application exposes how that behavior is constrained. The prompt, schemas, provider adapters, source observations, and original artwork are inspectable. Someone can change the experiment instead of accepting an opaque personality generator.

The verified path uses hosted Gemma. An Ollama adapter also exists as a local inference option; I have not qualified it as equivalent to the hosted model. Moving inference locally would still leave live GitHub inspection dependent on the network.

Open innovation also shaped the game itself. A public project can become inspiration for something unexpected while keeping its author, purpose, and evidence visible. The imaginary child does not inherit a license grant or become a real merger of its parents' code.

The Spirit of It

For Ghost in the Machine, I wanted the haunting to come from software's recognizable habits: a parser that cannot stop sorting, a fly that cannot stop twitching, an archivist demanding paperwork from a metaphor.

The best creature was the one whose complaint made sense once you met its parents.

So there is a large lever, a quiet music box, and a birth certificate stamped CERTIFIED IMAGINARY. Sound starts off; keyboard controls and reduced motion are supported.

The machine should enjoy its theatrical entrance. The evidence should survive the lights coming back on.

Prize Categories

The following entries use completed local scenarios. Public application hosting is still pending.

Category	What actually ran
Best Use of Gemma	Source-linked creature generation and real browser exports, including the continuous demo above.
Best Use of Mastra	The actual donor → context → Gemma/contract → reveal workflow; real run IDs, step timings, and a failed run are retained.
Best Use of MongoDB Atlas	Private save → API restart → read, wrong-key denial, consented public read → unpublish/delete, and competing durable budget reservations.
Best Use of Browserbase	A real cloud browser retrieved a pinned donor README paragraph that entered a real Gemma input. This is research-context use, without a public-site E2E claim.
Best Use of Ultramarine	Two real second opinions through the official OpenAI SDK, with recorded token usage and the credit cost reported above.
Best Use of Sentry Agent Tracing	Six linked agent/tool/inference spans with model, tokens and latency; screenshot above. This category row was added after the deadline.

The Browserbase context came from HungryCrab's README at the observed commit, and was supplied as a separately identified browser excerpt. Ultramarine identified the missing code-to-stimulus interface in the crab/fly proposal; its own proposed fix remained an opinion. Atlas denied reads after revocation and deletion, including an attempted recreation of a deleted operation.

Public hosting, a gallery, the proposed memory corpus, and the apprentice-training experiment remain unfinished. Render, Backboard, and Tinker are not entered. No deployed service or trained checkpoint is claimed.

Built with AI-assisted coding and drafting. Real model outputs are preserved as evidence; test fixtures and illustrated interface specimens are labelled separately.

I verify the voice context before I ask a model to write

Dreven — Sun, 25 Oct 2026 07:04:38 +0000

A mismatch before the first sentence

An English voice bundle attached to a Russian request is a problem before the first sentence exists. The request can be well formed while carrying writing instructions that belong to a different language or format.

I want to catch that mismatch while the input is still something I can inspect. In Quillgrain, I compile an explicitly chosen voice pack into local writing context, then verify that context before handing it to a model.

That gives me a concrete boundary in a writing tool: prepare the instructions, check their identity and scope, then ask for prose. Compilation itself does not call Ollama or any other model.

The small example I can check locally

For this example I used Quillgrain 0.1.0rc3 and the public demonstration pack in the PatchPitch checkout. The pack lives at examples/editorial/voice; the code below is meant to run from that checkout with the engine installed. The setup guide covers the pinned integration.

The pack contains designed editorial preferences: connected explanations, concrete examples and first-person prose. Its long-form and short-X rules have separate scopes. There are no personal writing samples hidden inside this demo.

Here is the complete compile-and-verify example. The selected context is English, uses the maker_announcement register and is scoped to social.longform on the ollama host.

from quillgrain.compose import compile_context
from quillgrain.consumer import bundle, verify_bundle

context, lock = compile_context(
    "examples/editorial/voice", language="en", register="maker_announcement",
    target="patchpitch", model_host="ollama", tags=["social.longform"], max_chars=8000,
)
checked = verify_bundle(bundle(context, lock), model_host="ollama",
    language="en", register="maker_announcement", tags=["social.longform"])
print(checked["build_id"])

The successful run returned a verified context with a build ID. Both compilation and verification completed locally; this example made no model request.

The editorial decision comes after the check

I also checked the failure path: asking the verifier to use the same English bundle for Russian was rejected before inference. That is the kind of mismatch I want a request builder to catch, rather than discovering it in the generated article.

The bundle keeps the compiled context together with its lock. Verification checks the hashes, language, register, tags and approved model host. I can use those checks to stop an incompatible profile from slipping into a request.

Passing the check does not make the resulting prose sound like me. The demo profile is a set of explicit preferences, not a learned personal voice. I still need to read the opening, check the examples and decide which sentences belong in the article.

For me, the useful part is having a writing context I can inspect and a separate editorial decision after generation. The compiler can establish structure and compatibility; the draft still has to earn its place on the page.

Where do you catch writing-context mistakes today: in the request builder, or only when you read the output?

I shipped PatchPitch 0.3.0. Here is what the failed 4B run taught me.

Dreven — Sat, 24 Oct 2026 13:45:25 +0000

The faster run took three minutes. It produced zero drafts I could accept.

The slower run took almost twenty-seven minutes. It produced all four, then repeated the completed job in less than a second without asking the model anything.

That difference became a useful release test for PatchPitch 0.3.0, my open-source tool for turning development facts into announcement drafts for Telegram, X, DEV and GitHub. I shipped it on 24 October. Getting there meant looking beyond whether the model returned some text.

In my previous article, I ran the headless workflow on Windows and reviewed the results in the studio. The CLI already worked. For the release, I wanted to see what happened on a fresh Linux runner, outside the checkout, with stdin closed—and what remained usable when the model got things wrong.

One set of facts, four different writing jobs

Finishing a release leaves me with another small project: explaining it. The facts are the same, but a Telegram update, an X post, a DEV story and GitHub notes need different amounts of context.

PatchPitch starts with selected facts and a JSON or TOML job. Ollama supplies the local model; the CLI prepares the drafts and saves the evidence. The studio is available when I want to inspect or edit the results, but generation doesn't need its web server or a browser.

This GIF shows saved development drafts from the earlier Windows run. It illustrates review in the studio; it is not a recording of the Linux acceptance run below. The 42-second demo opens a player with sound, subtitles and playback controls.

The part I care about is what survives after generation: original responses, failed attempts, input snapshots and my editable publication files. If one target fails, I can inspect it without throwing away the other three. If I edit a draft, repeating the job preserves that edit.

The smaller model finished first—and failed the campaign

I used GitHub Actions for Linux because my Windows machine had neither WSL/Docker nor a running Ollama at the time. The runner installed PatchPitch into a fresh environment and invoked the installed CLI from outside the checkout.

I also tried the same campaign with gemma3:4b. It took 183.374 seconds, made four model requests and exited with code 4. All four targets were attempted; none produced an accepted output.

Target	What went wrong
X	The topic plan narrowed itself to one fact. Only four catalog tags qualified; six were required, so writing stopped before another request.
Telegram	The Russian target received English prose with internal C01–C06 source IDs leaking into the text.
DEV	The article left selected facts out.
GitHub	The notes also missed selected facts.

I kept the failed run and its evidence. Making those checks less strict would have produced a green workflow, but it would still have left me with the wrong language, missing information and an unusable X draft.

This result describes one campaign on one model. It doesn't establish that every 4B model will fail. It does mean I can't present this configuration as a cheaper equivalent to the one that passed.

The passing run had an eight-minute DEV request

With gemma4:12b, the Linux campaign finished in 1599.653 seconds: 26 minutes 40 seconds. Ubuntu 24.04, Python 3.12.15 and Ollama 0.40.10 were the recorded environment.

Target	Model request time	Result
X, English	124.834 s planning + 179.148 s writing	Accepted, six tags, estimated 272/280 characters
Telegram, Russian	399.657 s	Accepted
DEV, English	497.921 s	Accepted
GitHub, English	397.662 s	Accepted

Five requests produced four accepted drafts. Validation and session export passed too. The full Actions run records the experiment; these timings are an observation from that CPU runner, not a speed promise.

The DEV request exposed a practical setup detail: 497.921 seconds exceeds the normal 420-second timeout. The passing configuration explicitly used 600 seconds. From a prepared checkout, with Ollama running and gemma4:12b already installed, the reproduction command is:

PATCHPITCH_MODEL=gemma4:12b PATCHPITCH_TIMEOUT=600 python -m patchpitch run --job examples/headless/all-four.toml --out-root artifacts/campaigns --json </dev/null

That example reproduces the original experiment inputs. Final-release facts live separately in examples/headless/release.toml. The live evidence predates the final version label; final promotion left the inference and validation behavior unchanged.

Then came the pleasantly boring part. Repeating the completed run took 0.352 seconds. Explicit resume took 0.329 seconds. All campaign files stayed byte-identical, and neither operation made another model request.

Twenty-seven minutes is a long wait to repeat accidentally. Keeping completed work mattered more here than shaving a few words off a prompt.

A lost response shouldn't create a second article

The DEV adapter had a different kind of failure to handle. Suppose DEV saves my draft, but the response never reaches PatchPitch. Sending another create request could leave me with a duplicate.

There was an extra wrinkle: the owned-article response can omit the AI disclosure field. The old recovery logic treated an absent field as fully_autonomous. A draft sent with some_ai or no_ai could then fail reconciliation even when its content had been saved correctly.

Receipts now retain the exact outgoing article payload. Recovery checks the owned draft and its observable content, then sends the desired disclosure explicitly to that same draft. A missing field no longer becomes an invented value. Regression tests cover the recovery paths, including omitted disclosure.

Generation and delivery remain separate commands. The adapter saves drafts with published=false and protects articles that are already published. That gives me somewhere to review the actual DEV rendering before a public post.

Six tags, an explicit writing brief, and a release I can inspect

For X, I chose a product rule: exactly six relevant hashtags. PatchPitch selects them from dated observations, checks topic and audience fit, and reserves their space alongside the link before asking for prose. The passing Linux post used #DevTools #LocalAI #LLM #Ollama #OpenSource #Automation.

That catalog supports a topical choice; it doesn't prove a reach improvement. The failed 4B plan was useful precisely because it showed where the available evidence ran out.

For this article, I used PatchPitch with a Quillgrain editorial brief: first-person singular, a concrete experiment, short paragraphs and the failures kept in the story. I then edited the model draft, corrected its framing of the earlier demo and added the result tables and source links. The brief makes my preferences explicit; the edit still decides what earns a paragraph. The Linux acceptance sample itself used the clear preset.

The latest main CI passed the base suite, the pinned Quillgrain integration job and the package checks. Quillgrain ran 21 tests without skips. The wheel and source archive built successfully, and the wheel's CLI passed checks in a clean environment without UI dependencies.

PatchPitch 0.3.0 is available on GitHub, with the archives, checksums and source commit. The headless guide covers installation and job configuration. It isn't on PyPI yet.

I can now hand the CLI one maintained set of facts, let it prepare the drafts, and come back to both the results and the evidence behind them. Smaller-model acceptance and inline DEV video with sound and controls are still in the backlog.

If you run local models unattended, which failure has cost you more time: a rejected response, or a response that looked valid until you tried to use it?

The code was done. The four announcements weren't.

Dreven — Fri, 23 Oct 2026 09:07:32 +0000

You finish the update. Then you open Telegram, X, DEV and GitHub, and discover that you have four more things to write.

The facts haven't changed. The readers have. Telegram wants the update without a long introduction. X gives you one small patch of screen. DEV needs a reason to keep reading. GitHub needs the concrete details someone will look for later.

That's the gap I'm building PatchPitch for: keep the facts in one place, then prepare drafts for each audience. For 0.3.0, currently in development, I wanted the whole job to run from the command line. A writing tool that needs someone to babysit a browser leaves a rather large hole in the automation.

The result: four local drafts in 123.258 seconds, using five requests to a local Ollama model. Here's a 42-second recording of the saved results being reviewed in the studio:

Watch the 42-second demo with sound and subtitles

Direct MP4 download

I made PatchPitch write about PatchPitch

The test material was its own development update. I supplied selected facts, asked for four formats, and ran the CLI with stdin closed. No browser, no PatchPitch web server, no clicking Generate four times. Ollama was already running locally with gemma4:12b installed.

The successful campaign produced this:

Target	Output	Request time
X	One English post with six tags	10.0 s
Telegram	A Russian project update	29.9 s
DEV	An English article draft	50.4 s
GitHub	English development notes	31.9 s

X used two requests: one to plan the post, another to write it after tag selection. Each other format used one. The 123.258 seconds includes the CLI's overhead; these are timings from this run on this Windows machine.

Here's the reusable example command, run from a prepared checkout containing the 0.3.0 development code:

python -m patchpitch run --job examples/headless/all-four.toml --out-root artifacts/campaigns --json

About two minutes later, I had four drafts to read instead of four blank editors.

The first X draft missed by seventeen characters

Before that successful run, PatchPitch rejected an X response with X_LENGTH_EXCEEDED. The app estimated the complete post at 297 characters against its 280-character budget. Telegram, DEV and GitHub still finished, and the rejected X response stayed on disk.

I had given the model a general 150–200-character prose target alongside a smaller allowance that reserved space for six hashtags and a link. The wider instruction was an invitation to overflow. I removed it and added a prose ceiling to the output schema, keeping the final check on the assembled post.

I also revised the tag catalog between runs. A generic mention of Python had helped select #PythonDevelopment; I narrowed that match to actual Python development topics. The revised selection included #Automation, a closer description of this announcement.

Stage	Complete-post estimate	What happened
First generated response	297 / 280	Rejected; other targets continued
Fresh run after prompt and catalog changes	262 / 280	Passed validation
Explicit copy edit	244 / 280	Shortened and labelled as development work

The lesson was pleasantly concrete: reserve the tags and link first, give the model the remaining prose budget, then check the whole message. The saved responses made it possible to see where the space went.

Same facts, different jobs

Here are excerpts from the saved files after editing. The X post is shown in full:

PatchPitch 0.3.0 dev: an open-source Python CLI tool that automates drafts from JSON/TOML jobs with local Ollama. No browser or web server needed.

#DevTools #LocalAI #LLM #Ollama #OpenSource #Automation

https://github.com/drevendev/PatchPitch

Those six tags describe the subject: developer tools, local AI, language models, Ollama, open source and automation. PatchPitch selected them from a reviewed catalog of eleven candidates, backed by nineteen linked posts from fifteen authors. That gives me examples of usage and a reason for each choice; reach isn't something this sample measured.

The Telegram draft opens directly in Russian:

Я добавил в PatchPitch возможность автоматически генерировать черновики для Telegram, DEV и GitHub на основе выбранных фактов разработки.

In English: “I added the ability to automatically generate drafts for Telegram, DEV and GitHub from selected development facts.” The rest of the saved post explains the local CLI workflow and includes the command.

The GitHub notes take a more functional approach:

The development implementation provides a non-interactive CLI to automate draft generation from JSON or TOML jobs. This workflow utilizes the existing local Ollama model backend and functions without starting a browser or HTTP server. An installed local model is required for operation.

That gives a repository reader the mechanics and a prerequisite. It's also fairly stiff prose. The openings still leaned heavily on the same CLI facts; the formats worked, but their hooks needed more attention. The DEV draft made that especially obvious.

Giving the DEV draft a story

The first DEV version read like a README: plenty about how the pieces fit, very little about why a developer would care. I gave Quillgrain a more specific editorial profile: start with the four-announcement problem, tell the actual experiment, keep the failed X attempt, and show the outputs. Short paragraphs and concrete verbs were part of the brief, too.

Quillgrain compiled that profile into writing context. PatchPitch sent it alongside the selected facts to the local model for a fresh DEV generation. The response still opened with this:

We've all been there: you finally push a significant update, the code is clean, and the tests pass, but then you're faced with the friction of explaining that change in four different places.

That could introduce almost any developer tool. During editing, I replaced it with the opening of this article:

You finish the update. Then you open Telegram, X, DEV and GitHub, and discover that you have four more things to write.

I also pulled the real failure, timings and saved examples into the story. Quillgrain made the brief explicit and available to the generation step; the editorial pass decided which details deserved the reader's attention. Both are part of how this version was made.

Four drafts I could come back to

One part of the experiment was pleasantly uneventful: running it again.

In a separate reuse check, I repeated the completed job and invoked resume with network connections blocked. Both reused the saved work with zero connection attempts. The original responses and edited publication files stayed intact.

The CLI session could then be opened in the studio to read, edit and export. That's the review shown in the screenshots and recordings: switching between saved drafts doesn't need another model request.

The useful part is opening four concrete drafts with the facts already in place. I can spend the next edit on the hook, the awkward sentence or the example that makes the update worth reading. Those are much better problems to have than four empty text boxes.

PatchPitch on GitHub

Let your wild ideas ferment: a quiet garden powered by local Gemma

Dreven — Thu, 22 Oct 2026 15:12:20 +0000

Built for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

Some ideas are too odd to schedule and too interesting to delete.

Compost Club is for people who collect fragments of side projects and would rather explore one new connection than turn every note into a task. Add two scraps, ask local Gemma for one possibility, and decide whether it deserves to grow.

My projects already contain ideas worth revisiting. Scriptorium studies how a text is written. Quillgrain carries a writing voice between tools. They solve different problems, but what might grow between them? I built Compost Club to give those unfinished connections another small chance.

Drop a few scraps into a cozy garden. Let local Gemma combine two of them into one new concept. Read where it came from, keep what makes you curious, or compost it again with its roots attached. A friendly worm named Wiggle supervises absolutely nothing.

A kept idea can now grow a small branch, too. Ask Gemma to clarify its mechanism, add a constraint, explore an alternative, or suggest a one-day experiment. Each step waits for your review.

The garden has a deliberately slow rhythm: one welcome pairing, then another slot every fifteen minutes, up to three. Closing the tab earns time credits. Generation happens only when you ask for it. Nothing withers while you are away.

That is my interpretation of Slow and Steady: give a neglected idea a gentle next step without turning it into another daily obligation. There are no streaks, upgrades, payments, or productivity scores.

The lazy payoff

My ten project cards offer 45 possible pairs. I do not have to enumerate them or write a new prompt for each: the garden selects an unused pair, Gemma proposes one connection, and I review it. That is the effort this build aims to remove, rather than the decision about what is worth making.

The example below took about 8.5 seconds of local inference. I kept it as a candidate for further exploration. That is an observed run, not a measured productivity saving or evidence that all 45 pairings would be useful.

Demo

Watch the demo.

The short English demo shows the actual application with ideas taken from my public projects. It opens the two source cards, shows Echo Cartography, keeps it, then follows two earlier discoveries back into the compost pile. The cream paper, small flowers, and hand-drawn garden are part of the invitation to slow down.

The result came from a fresh local Gemma 3 4B run on English summaries of two real repositories: Scriptorium and Quillgrain. The summaries retain source links and describe current limits as well as the ideas behind each project. Gemma's unedited concept was:

Scriptorium's reading observatory is layered with Quillgrain's voice packs, generating a dynamic 'cartography' of a text’s evolution across drafts, highlighting shifts in vocabulary and tone through visualized, context-aware measurements.

I can see a practical possibility: an editor comparing drafts could notice where a revision changes the author's voice. That is why I chose this result for the demo. Echo Cartography is an idea proposed by Gemma, not an implemented editor, a paying customer, or a claim that demand has been validated.

The walkthrough then switches to a separate saved garden containing Lexigraph and ClawPulse, two other genuine local results. Clicking Compost again turns them into two new source scraps: twelve scraps instead of ten, with their parent links intact. No second-generation blend is claimed. The scenes were filmed from validated saved gardens; no fresh inference click or waiting animation was staged for the camera.

Making the demo also improved the product: I folded the composer, paged long piles, and put both source texts side by side. The walkthrough needs no scrolling, while full text remains available. Its English voice, gentle guitar and floral frame are presentation elements; the actions inside are the real application.

The downloadable public sample is a separate experience: seven visibly labelled, unchanged recordings on fictional inputs, playable without a model download, including as a self-contained offline HTML file. Custom scraps need explicit local inference setup. Browser AI remains experimental.

From an interesting idea to a small next step

After keeping Echo Cartography, I chose Tend this idea and asked for a one-day experiment. Local Gemma proposed Draft Timeline Exploration: take a 100-word passage, make three draft versions, and chart vocabulary and tone changes on a whiteboard. I accepted the branch, saved it, and verified that it survived a reload. The proposed whiteboard experiment itself has not been carried out.

An accepted branch can become the parent of another request. Asking again from the same parent creates an alternative. Original responses, human edits, and parent snapshots stay separate. Accepting spends one ready slot; rejection, cancellation, failure, and no_growth keep it. This is the first small branching workflow; it runs when asked, with a person deciding what grows.

The video above shows blending and recomposting. This screenshot shows the newer tending workflow.

Code

Repository and local setup · Model experiments and raw evidence · Known issues and roadmap

To try the labelled sample, use Node 24 and npm 11:

git clone https://github.com/drevendev/CompostClub.git
cd CompostClub
npm ci
npm run dev

Open the printed local URL and choose Try the sample garden. This route needs no model download. For fresh ideas, follow the separate live local Gemma setup.

The application and original SVG illustrations are MIT-licensed. Gemma weights have their own terms and are not bundled with the app.

How I Built It

The UI uses React, TypeScript, and Vite. The garden rules live in a separate domain layer, independent of React and the inference runtime. IndexedDB stores the pile and discoveries; Markdown exports and validated JSON backups provide portable copies.

Gemma handles two bounded requests: blend two scraps into a concept with a source fragment from each, or propose one continuation of a kept idea. It receives no tools, shell, or archive search. The app renders input and output as text.

The model experiments changed the design

My first prompt asked Gemma 3 1B to choose exact quotations from both parents. All 24 predetermined runs failed the final output contract. Paraphrasing a source made sense linguistically, but broke the provenance requirement.

The next version moved that mechanical work into code. The app selects short exact fragments and constrains those fields in the JSON schema; the model concentrates on inventing the concept.

Local experiment	Runs passing the shipped structural validator
Ollama Gemma 3 1B, first prompt	0 / 24
Ollama Gemma 3 1B, revised prompt	23 / 24
Ollama Gemma 3 4B, revised prompt	24 / 24
Browser Gemma 3 270M and 1B, small combined smoke set	0 / 4

The Ollama set contains twelve public source-pair combinations, each run twice. Tuning reused the original holdout combinations, so these numbers describe a small regression experiment, not general performance on unseen ideas. The browser row is a separate, smaller experiment with a different runtime and setup.

The 4B pass needed no repair calls. On the tested Windows machine, Ollama selected CPU inference; its median call latency was about nine seconds. That is a measured result from one machine, not a hardware requirement or a promise about other devices.

For this new demo I also ran ten additional pairings from my public-project cards, after the first Lexigraph result. All ten passed the structural contract without repair. Human review still excluded three: one leaked field-like fragments into its concept, while two assumed evidence the source cards did not contain. Echo Cartography took about 8.5 seconds in its local run. These selected exploratory cases are not a held-out evaluation or proof of general creative quality.

The browser models genuinely loaded and generated with WebGPU. Their four outputs failed the contract, so browser AI stays visibly experimental. Those failures remain in the evidence. A failed call never becomes a successful recording behind the scenes.

Even 24/24 valid responses does not mean 24 useful ideas. Some concepts were weak, and some Russian requests returned English. Human usefulness review and a fresh unseen evaluation set are still open. The seven sample recordings are a selected subset; the remaining results are retained.

A garden also has to remember

The application preserves raw source revisions and the original model responses. Editing a scrap does not rewrite the parents of an older discovery. Saving a sprout, consuming its pair, and spending its slot happen atomically. Errors, cancellation, and a model's no_blend response keep the slot.

Recovery matters here because the scraps are the user's contribution. Backup validation, competing-tab checks, restore conflict detection, and cascade previews for deletion all protect that contribution. The current checks cover 97 unit tests, three HTTP/Sentry regressions, and 32 Chromium journeys, including growth review and privacy exports. Those application checks are separate from model-quality evidence.

GitHub Actions takes repetitive release checks off my hands. The Repository checks workflow installs pinned dependencies, runs verification, builds the app and standalone sample, and exercises recovery, pairing workflows and the Pages subpath in Chromium. The successful post-merge run includes the tending workflow and optional Sentry adapter.

Watching a local model without collecting its ideas

I connected Sentry Agent Tracing to the Node bridge as optional technical monitoring. It is off by default, and the connection status shows when the operator enables it. The browser and offline HTML contain no Sentry client. The adapter and removal instructions keep it independent of the garden's data and local inference.

On a fresh tending request with the merged code, Sentry recorded 16.43 seconds, 220 input tokens, and 107 output tokens for local Gemma 3 4B. The child span measured about 0.48 ms of bridge-side structural validation. This is a separate request from the earlier 8.5-second blend and the accepted branch above. These are individual observations on my machine, not a benchmark or a measure of usefulness.

The integration exposed two mistakes. Provider-side enrichment initially added location fields, so I added explicit IP anonymization and recursive server-side scrubbing, then checked the stored result. Review also caught a validation span starting after the check; moving the check inside it made that timing meaningful. The screenshot uses a fresh trace after both fixes. Uploaded events contain technical metadata, with idea text, prompts, outputs and raw errors excluded.

There is no hosted model API charge for those tokens: inference runs locally. Hardware, electricity, and the operator's Sentry plan are separate costs, not measured by this trace. Turning monitoring off and restarting the bridge stops new telemetry; removing the adapter needs no garden migration.

Why Does Open Innovation Matter?

The core interaction can run on a machine the user controls. Ollama generation stays behind a loopback-only bridge. Scraps live in the browser, and the app needs no end-user account or hosted inference API. Optional Sentry monitoring sends technical metadata only when the operator enables it; local generation, saved gardens, and backups work with it off.

Initial dependency and model downloads still need a connection and explicit setup. The optional browser-model download contacts the disclosed model hosting endpoints. The offline sample contains recordings rather than weights or live inference.

Open weights made it possible to compare model sizes locally and keep the failed experiments inspectable. Open application code makes the rest inspectable too: the prompt, validator, pairing rules, storage boundaries, and record of what actually ran. The model licence remains separate from the code licence.

Compost Club is an experimental local application. It offers a small next step: put two unfinished thoughts together, read one possibility, and decide whether to keep it. Then close the tab. The garden can wait.

Prize Categories

Best Use of Gemma — Gemma provides the central idea-blending interaction through genuine local Ollama runs, including Echo Cartography. The separate offline sample replays exact Gemma 3 4B results.
Best Use of GitHub Copilot — entered through the GitHub Actions automation route explicitly listed in the published category criteria. Repository checks automate builds, standalone packaging and Chromium acceptance; the linked workflow and successful run show the actual use.
Best Use of Sentry Agent Tracing — the optional local-model integration records real timings and token counts. The trace screenshot, privacy fixes, validation-timing correction and setup/removal notes above show how it is used.

AI assistance was used in implementation, testing, documentation, and preparing this article and demo. Numerical claims above come from the repository's recorded experiments and verification reports. Creative usefulness remains a human judgment.

Demo audio credits: “Somewhere Sunny (ver 2)” by Kevin MacLeod (incompetech.com), downloaded from Wikimedia Commons, licensed under CC BY 3.0. Edited excerpt with reduced volume, ducking, and fades. Narration: Kokoro-82M, Apache-2.0 model distribution, rendered locally with the MIT-licensed kokoro-onnx runtime.

PatchPitch: local Gemma turns patch notes into devlogs and social posts

Dreven — Sun, 18 Oct 2026 23:42:26 +0000

PatchPitch uses local Gemma to turn release notes into devlogs, community posts and short announcements, with voice presets, optional tags and Markdown export.

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

Demo · Code · How it works · Sentry trace

What I Built

A game update can be finished and still leave three writing jobs: explain it to returning players, introduce it to a community, and fit one useful thought into a short post.

I used the real 0.12 patch for Idle Fantasy Shop, my cozy browser game about gathering resources, crafting practical goods and keeping a small shop in Latchford. Its workshop gained a crafting plan, its gathering grounds gained a pressure system, and its save instructions needed careful wording. There was a story in those changes. It needed different shapes for different readers.

PatchPitch is the small local writing studio I built for that job. Select the facts that shipped, choose a format and voice, generate with local Gemma, then review and export Markdown.

Devlog: room for the selected topics and important details.
Community post: a few useful changes in connected prose.
Short post: a 280-character budget including your call to action and suggested tag.

Each request writes one version. Warm, Clear and Lively presets steer its voice; an optional writing sample adds your own rhythm. Auto tags are optional suggestions from the product and selected facts. Each format keeps its latest draft and edits in the current tab, so you can switch between them, remove a tag and take the text with you.

Who might pay for it?

The buyer I have in mind is a solo developer or small studio that ships regularly and handles its own release communications. Their next update needs a coherent release pack, a careful review and copy they can reuse across channels.

The first paid offer I would test is a reviewed pack per release: a devlog, a community post and a short announcement. That could begin as a small service using this MIT-licensed tool. A subscription would need evidence that people return for the next update. So far I have used it on my own game; I have no independent customer or payment results, and the app has no checkout.

Demo

Watch the demo and read the generated drafts

The recorded demo includes captions and all three complete drafts. Direct 63-second MP4.

The film shows fact selection, three generated formats, style controls, auto tags, draft switching, source inspection and Markdown export. Generation waits are shortened and labelled.

It combines two native browser recordings. There were five real model calls across those sessions; three successful outputs are shown. A rejected Community attempt and an unused Short remain in the evidence. No saved response was replayed into either UI, and the model's prose was not rewritten.

Here is one small detail worth getting right. The technical input distinguishes gathered materials from craftable goods:

New content counts: 3 gathered raw materials plus 7 craftable goods = 10 new items total. Only the seven goods are craftable.

The full generated devlog says:

We have added 10 new items in total, consisting of 3 gathered raw materials and 7 craftable goods.

The short format has a different job. This is its untouched body:

Idle Fantasy Shop now features Crafting Batches in the Workshop. Access requires level 10. Export a backup from Settings before changing devices or clearing browser data.

With my supplied CTA and Gemma's suggested tag, the post was 252 characters. The film removes the tag and exports the remaining text; copy and download match exactly. It keeps Settings and both backup circumstances, while leaving out the full crafting limits. The UI flags unreferenced notes and missing numeric particulars for review.

Code

drevendev / PatchPitch

Turn selected changelog facts into a source-linked announcement draft with local Gemma.

PatchPitch

Your product deserves a great story.

Turn selected changelog facts into an announcement people understand. Describe your product and audience, choose what shipped, generate with local Gemma, inspect the sources, edit and export Markdown. A small writing workflow with a human final edit.

Recorded demo · 63-second video · Build story on DEV

The hosted demo shows real recorded Gemma outputs; generation runs locally using the setup below.

Run locally

Python 3.11+ and Ollama are required. Tested on Windows 11 with Python 3.12.14 and Ollama 0.40.6. The source is MIT licensed.

python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -r requirements.txt
ollama pull gemma4:12b
.\.venv\Scripts\python.exe -m uvicorn patchpitch.app:app --host 127.0.0.1 --port 8000

Start Ollama, then open http://127.0.0.1:8000. On Linux/macOS use .venv/bin/python in place of .venv\Scripts\python.exe.

The upstream is fixed to 127.0.0.1:11434. Set PATCHPITCH_MODEL to an…

View on GitHub

drevendev/PatchPitch — MIT. The verified implementation is 38619a8; its GitHub Actions run passed 121 tests. Automated tests use mocked inference or an offline transport; the recorded model calls are separate evidence.

The README has the setup commands: Python 3.11+, Ollama, the selected Gemma model and the pinned Python requirements. The app runs at 127.0.0.1:8000; Ollama stays on loopback. The 12B default needs enough local memory, and another model needs its own writing-quality check.

The film was recorded on 78e44f8. Later changes add the example-loading fix, optional Sentry tracing and a curly-apostrophe validation fix; its prompts and generated words are unchanged. A hosted recording is a way to inspect the product; real generation runs locally.

How I Built It

FastAPI, Pydantic and vanilla HTML/CSS/JavaScript handle the flow. Unchecked notes stay out of the model payload. Gemma receives selected factual units, a separate voice brief and a JSON schema for the response. Source IDs connect the result to the notes a person can inspect.

I prepared the example notes from Idle Fantasy Shop's actual 0.11.1 → 0.12 code patch, with commit and file references. PatchPitch receives those notes; automatic Git import is still backlog. The tone brief comes from in-game item descriptions. The original devlog was comparison material only: its prose is absent from the model input.

The recorded model was gemma4:12b through Ollama 0.40.6, using direct generation for all three formats. The selected requests took 74.7s for Devlog, 12.7s for Community and 4.5s for Short on this machine. Those are observations, not a speed promise.

Real attempts exposed useful failures: a draft called all ten items craftable, another dropped backup circumstances, and a wording check rejected queue capacity as if it promised simultaneous work. I clarified the source notes and improved the schema, prompts and targeted checks. In the full devlog, each assigned source ID is emitted before its paragraph to keep topics in their own slots. Failed and rejected attempts are retained.

These checks establish structure, budgets and specific wording constraints. They cannot establish semantic truth. The full draft covers all eight selected topics, but parts are more functional than the original devlog's warmer editorial writing. The result still says Draft — review before publishing. Source inspection and the maker's final edit belong in the workflow.

Seeing where the time goes with Sentry

Optional Sentry instrumentation records the generation, actual Ollama call and validation. A separate real run on the public fictional Pocket Orchard example produced this trace:

The model call took 15.064s; validation took 4.015ms. Ollama reported gemma4:12b, 1,590 input tokens and 302 output tokens. Almost all the recorded time went into the model request. No metered inference API was used; local hardware and electricity still have a cost. Sentry's comparison badge reflects these diagnostic samples, not a controlled benchmark.

A separate CONTROLLED_FAILURE fed a saved draft containing a TODO placeholder into validation. It produced invalid_draft and a linked error event, with no fabricated inference span.

The SDK is off without an explicit DSN. Automatic integrations are disabled, and events plus final transport envelopes use a small metadata allowlist. I inspected the actual HTTP bodies for source notes, output prose and private context. Received-event review also caught Sentry's IP-derived geography enrichment: I enabled IP scrubbing and explicit geo removal, then verified a fresh validation-only event had no User/Geography context. The trace and checks were captured separately after the film.

Why Does Open Innovation Matter?

The open-weight model does the actual writing. Once its weights and the application are installed, the writing flow can run locally without a hosted copywriting API. Upcoming changes and an unpublished tone sample can stay on the developer's machine. Fonts are local too; Sentry is a separate opt-in metadata export.

The prompt, schema and adapter are inspectable. I could change generation settings and investigate failed responses while keeping the writing step local. The model is replaceable, although equal output quality would need testing. Gemma's weights are downloaded separately and are not relicensed by PatchPitch's MIT license.

BeautifulRepo's release-note guide informed the reader-first approach and attention to limitations; attribution is retained. Codex assisted development and the write-up. The film uses local Kokoro narration and original procedural music.

Prize Categories

Best Use of Gemma: real local inference writes all three formats.
Best Use of GitHub Copilot, via GitHub Actions: the category explicitly includes Actions automation. Our test workflow runs unit, API and browser checks on pushes and pull requests. Our manually dispatched Pages workflow publishes the approved demo. Codex was the coding assistant.
Best Use of Sentry Agent Tracing: real model and validation spans, observed latency and tokens, a labelled controlled error, and an inspected privacy finding.

Which part of release writing takes you longest: choosing what to include, checking the facts, or adapting the same update for different channels? I would like to hear how you handle it today.

Your product deserves a great story.