DEV Community: Iqbal Taufiqurrochman

Sloth Handover: three lines for standup from an open-weight model

Iqbal Taufiqurrochman — Thu, 22 Oct 2026 21:39:17 +0000

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

What I Built

Sloth Handover turns a messy git log into the three lines you actually say at standup.

Paste your commits, or press Use the sample repo, and an open-weight model returns:

Done — what the week actually finished
Next — what the log implies is still open
Blocked — or "Nothing blocked", when the log says so
Minutes saved — a deliberately rough estimate, clamped between 5 and 45

No account, no database, no stored history. The log goes to the model, the reply is checked against a schema, and nothing is written down. The empty state is one screen and one textarea:

Demo

Live: https://sloth-handover.vercel.app
The sample button loads a 12-commit week from a fictional project, complete with a merge, a revert and a version bump, so the whole thing runs in one click.

Code

Repository: https://gitlab.com/iqbal_taufiqurrochman/sloth-handover (MIT)
Run it locally:

git clone https://gitlab.com/iqbal_taufiqurrochman/sloth-handover.git
cd sloth-handover
nvm use
npm install
cp .env.example .env   # add OPENROUTER_API_KEY
npm run dev

To run the same prompt with no API key and no network:

ollama pull gemma3:27b
AI_PROVIDER=ollama npm run dev

To have the server read a repository directly instead of pasting:

GIT_REPO_PATH=/path/to/repo npm run dev

How I Built It

SvelteKit 3 with Svelte 5 runes, Tailwind 4, adapter-vercel, Node 22. One page, one endpoint, no database.

The AI layer is a small provider interface with two implementations: OpenRouter calling google/gemma-3-27b-it (open weights), and Ollama running the same model family locally. One prompt, one schema, two transports; switching is one environment variable.

The prompt is strict on purpose: three lines, past tense, start with a verb, no file paths, no invented work, and "Nothing blocked" when the log is quiet. The reply must parse as JSON and pass a shape check; minutes_saved is clamped so the model cannot claim it saved four hours. The endpoint sanitises the log, caps it at 8,000 characters, rate-limits eight requests per IP per ten minutes in memory, and answers 400, 429 or 502 with a sentence instead of a stack trace.

I tested the plumbing with a local OpenAI-compatible stub before spending a real model call: happy path, one-character log (400), malformed JSON (400), rate limit (429). Then the real call: 12 commits in, three accurate lines out, 3.4 seconds. It ignored the merge and the version bump, noticed the revert, and correctly said nothing was blocked.

Two things that bit me along the way:

Vite loads .env into import.meta.env, not process.env, while the server code reads process.env. I load the file in vite.config.js; on Vercel the platform supplies the variables and there is no file to load.
The GitLab repository already had an initial commit, so the first push was rejected. Rebased onto origin/main, kept the project README, pushed again.

Why Does Open Innovation Matter?

The model is the point, not a black box behind a paywall. Gemma 3 27B has open weights, so the same prompt can run through a hosted API for a public demo or through Ollama on a laptop with the network unplugged. A reader can check the licence, swap the provider in one file, or self-host the whole thing for free. That is the difference between an AI feature and AI you can own.

It changes the privacy story too. With Ollama, the commit log never leaves the machine. With the hosted demo, commit subjects do go to OpenRouter, which is why the app stores nothing and says so plainly. I would rather state that trade-off than pretend a thin wrapper is local-first.

The code is MIT, and the prompt, the schema and the failure paths are all in the repository. If the model gets a line wrong, you can see exactly what it was asked and change it.

My Agent Session

Sloth Handover: build and deploy notes

You

Build and submit the Hacktoberfest Week 3 challenge. Submission is enough, no prizes. Use SvelteKit and Vercel, OpenRouter for AI.

Agent

Picked Sloth Handover: paste a git log, and an open-weight Gemma model writes Done / Next / Blocked plus an estimate of minutes saved. No database, no accounts, no stored logs.

▸ write SvelteKit 3 scaffold, AI provider switch, prompt, schema, endpoint, page

Input

SvelteKit 3 scaffold, AI provider switch, prompt, schema, endpoint, page

Output

OpenRouter default, Ollama for fully local inference, JSON validated before render

Agent

Verified with a local OpenAI-compatible stub first: the happy path returned JSON, a one-character log and malformed JSON both returned 400. svelte-check reported zero errors and the Vercel build succeeded.

▸ bash npm run check && npm run build

Input

$ npm run check && npm run build

Output

0 errors and 0 warnings; adapter-vercel build finished

Agent

Then a real call on google/gemma-3-27b-it with 12 commits took 3.4 seconds. It ignored the merge and version bump, noticed the revert, and reported nothing blocking.

▸ bash POST /api/handover with a 12-commit sample log

Input

$ POST /api/handover with a 12-commit sample log

Output

three accurate lines, 15 minutes saved, 3.4s latency

Agent

Pushed to GitLab after rebasing onto the repository's initial commit. A Vercel deployment exists, but the runtime still needs OPENROUTER_API_KEY set on the project before the live demo can answer.

▸ bash git rebase origin/main && git push origin main

Input

$ git rebase origin/main && git push origin main

Output

two commits on gitlab.com/iqbal_taufiqurrochman/sloth-handover

The Lazy Payoff

Standup is a short meeting wrapped in a long act of remembering. Here it is one paste and 3.4 seconds, and the result is short enough to read out loud. The laziness is aimed at the chore, not the work: the model summarises what the log already proves, and the minutes-saved number stays an estimate rather than a metric.

If it saves one round of "wait, what did I do yesterday?", it did its job.

Prize Categories

No partner technology is used, so this is entered for the overall prize only.

Jejak: a field dex where every bird you spot becomes a card you can trade

Iqbal Taufiqurrochman — Thu, 15 Oct 2026 14:16:51 +0000

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

What I Built

Jejak is a field dex. You photograph something alive, an open-weight vision model identifies it against a forkable species glossary, and the result becomes a collectible card with a rarity and a live value. Cards can be shared to a feed and sold into requests on a market board.

Who would pay for it: a nature guide running birding walks.

That is a real trade here in Indonesia. A guide in Bali or Bogor takes guests out before dawn, and the guest goes home with a camera roll and a vague memory of "a blue bird". The guide's morning is worth more if the guest leaves with an artifact: this was a Jalak Bali, this was a Cekakak Sungai — here is your collection, come back for the endemics. That is differentiation a guide can charge for, on a tour that already costs real money.

So the buyer is the operator — an individual guide, or a small eco-lodge running a few — paying a small monthly fee per guide. Which only works if the marginal cost of a catch is near zero. That constraint is the entire reason the model is open-weight, and I will come back to it.

Two segments are worth naming honestly:

The operator pays, because a takeaway their guests actually keep is cheap differentiation for a tour they already sell.
The hobbyist does not pay for the identification, but plays: because scarcity is measured from the database, the first person to catch a species holds the expensive copy and the tenth person holds a cheap one.

The problem it solves: identification apps stop at the answer. You get a name, you close the app, you never open it again. There is no record, no artifact, no reason to go out again. Jejak makes the answer the beginning of the thing — the card is the record, and the collection is the reason to look up tomorrow.

Demo

Live: [LIVE URL]
Sign in with: demo / jejak-demo-2026

The demo account is pre-seeded and the market board restocks itself, so you can catch, collect and sell without a second human being online. The best first move is Catch — upload any photo of an animal and watch the whole loop run.

Code

Repo: gitlab.com/iqbal_taufiqurrochman/jejak — MIT licensed.

npm install
cp .env.example .env        # Neon pooled URL, session secret, OpenRouter key
npm run db:push && npm run seed

How I Built It

Stack: SvelteKit 3 (JavaScript + JSDoc), Tailwind 4, Postgres on Neon through @neondatabase/serverless, deployed on Vercel.

The open-source AI at the core: the default backend is google/gemma-3-27b-it, an open-weight Gemma vision model served through OpenRouter. One call per catch does three jobs at once — identify the animal, ground the answer against my glossary, and write a short bilingual field note — returned as JSON and parsed tolerantly. Set AI_PROVIDER=ollama and the same code runs on a laptop with gemma3:4b and no network at all.

Grounding, not vibes. The model does not free-associate a species name. data/glossary.spesies.json is a plain, forkable, CC-BY list of around 65 Indonesian species, and the model has to pick from it. If it returns a scientific name that is not in the list, the catch is rejected. Anyone who knows more about Indonesian fauna than I do can fix the list in a pull request.

The confidence gate, which is where the game lives. Below 60% confidence the model is instructed to say so, the catch fails, and the keeper walks away with nothing — or pays 50 credits to re-analyse the same photo. Every game needs a way to lose.

Value is a live number, not a label:

value = base(rarity) × (1 + 2 / (1 + keepers_who_hold_this_species))

Scarcity is read from the database at catch time, so catching what nobody else has is worth more, and duplicates get cheap. Other keepers post requests on the market board — "I want a Jalak Bali, I pay 520 credits" — and you sell your card into that request in one transaction. The first person who catches something ends up holding the scarce copy.

Privacy as a feature rather than a promise:

What people usually do	What Jejak does
Upload the full photo	Sends a 1024px copy to the model; stores only a 320px thumbnail
Strip EXIF on the server	Strips it on the device, before a byte is sent
Trust the client	The server refuses any image that still carries an EXIF header
Keep precise GPS	Rounds to two decimals, about a kilometre
Log IP addresses	Stores a truncated SHA-256 of the caller, never the address

Full-resolution photos never reach the server. The GPS read happens locally with exifr and the JPEG is re-encoded through a canvas, which destroys the whole EXIF block on the phone.

Two serverless gotchas the community wrote about, handled in code. Delehq's Why Serverless Functions Keep Exhausting Your Postgres Connections is why this uses the Neon HTTP driver and never a raw TCP pool. Omer Hochman's Your database scales to zero. Your retry loop doesn't know that. is why only the database stage is retried, with exponential backoff — the model call is not retried blindly, because re-running a vision call you have already paid for is how you double your bill.

Why Does Open Innovation Matter?

The business only works because the model is open. A closed, metered identification API turns every guest photo into a cost line. A small monthly subscription per guide would get eaten by usage that grows with the guide's success — the better a guide does, the more they pay, and the margin inverts. Open weights on a shared endpoint make the marginal catch close to free; self-hosting Gemma on a lodge's own laptop makes it literally free after hardware. That is the difference between a nice demo and something a guide in Ubud can actually afford.

Rare species should not require a third party. Indonesia has the wildlife problems you would expect from a country with desirable songbirds. The photos are of animals at known locations. A closed API means that data leaves the building by design — the request is the data. Here the default is a hosted open model, but flipping one environment variable keeps every photo on your own machine, and the server-side EXIF rejection means the app refuses to be the weak link either way.

A local list beats a global model on local names. No frontier API knows what a Cekakak Sungai is in the way a guide does. Grounding against a CC-BY glossary means fixing that is an edit to a JSON file, not a fine-tuning run — and the same file can be translated or replaced wholesale for another country's fauna.

And no lock-in as a policy. OPENROUTER_MODEL is a string. If a better open-weight vision model ships next month, that is a configuration change, not a migration.

The honest trade-off: a closed frontier model would probably identify the hard cases — small brown birds in bad dawn light — more accurately than a 27B open-weight model does. What open bought me is the cost floor that makes the side hustle arithmetic work at all, the ability to keep guest photos on hardware the operator controls, and direct ownership of the glossary and the prompt for a niche where the honest answer from a general API is too often just "bird".

My Agent Session

[AGENT SESSION EMBED — to be filled before publishing]

My First User

[FIRST USER — to be filled before publishing]

Prize Categories

Best Use of Gemma — the default vision model is google/gemma-3-27b-it, from Google's open-weight Gemma family. It is not decoration: Gemma does the identification, the grounding against the glossary, and the bilingual field note in a single call, and the whole app is built around that one call being cheap enough to give away in a demo.

ChatTodo: A Chat Box That Stops My Friend Fatik From Double-Booking Himself

Iqbal Taufiqurrochman — Sun, 04 Oct 2026 16:29:20 +0000

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

What I Built

ChatTodo is a chat-first todo app for my friend Fatik, who meets a lot of people and keeps making appointments — client meetings, workouts, catch-ups. His problem is simple: he forgets. And when he forgets, his appointments collide — a gym session he just promised lands on top of a meeting he already made.

He's also not going to adopt a heavyweight task manager. He'd rather type a message than fight a due-date picker. So I didn't build him another app with forms. I built him a chat box.

He types the way he talks:

"besok jam 9 rapat Budi, jam setengah 10 olahraga di gym"

ChatTodo turns that into two dated todos, checks them against everything already on his plate, and warns him on the spot:

Bentrok jadwal:

"Rapat sama Budi" (Sen, 5 Okt, 09.00) vs "Olahraga di gym" (Sen, 5 Okt, 09.30)

Under the chat there's a simple dashboard: how many are pending, which are overdue, what's coming in the next seven days — enough for Fatik to glance at in the morning and close the tab.

The problem it solves for Fatik: he's the person who promises a friend a workout session and then realizes it clashes with a meeting he already agreed to. He told me he needs something to watch his appointments for him, but it has to be effortless — one box, one send button, no app to "keep up with".

Demo

Live: [DEPLOY URL]
Video demo: [RECORDING LINK]

Code

Repo: gitlab.com/iqbal_taufiqurrochman/chat-todo

Setup is three commands: npm install, cp .env.example .env (plus your Neon connection string), npm run db:push. The README walks through every environment variable.

How I Built It

Stack: SvelteKit 3 + Svelte 5 (runes), Tailwind CSS 4, Neon Postgres via Drizzle ORM, deployed on Vercel.

The open-source AI at its core:

Open-weight model via OpenRouter — the default is google/gemma-3-27b-it (Gemma is Google's open-weight family). Every chat message goes through it.
OpenAI-compatible client layer — a thin abstraction (src/lib/ai/client.ts) where baseURL and model are just two settings. Point it at OpenRouter's hosted open-weight model, or at a local Ollama server, without touching a single line of application code.
Structured extraction, not vibes — each message runs in JSON mode against a zod schema ({ type: "create" | "list" | "complete" | "delete" | "chat", ... }). The model never writes to the database directly; it proposes a typed action, my server validates it, and only then does it execute. Bad JSON = rejected = safe.

How a message flows:

The message lands in /api/chat and is persisted to the messages table
The last 10 messages + the current todo list are sent to the model (so "selesai yang rapat" finds the right todo)
The model returns one structured action; zod validates it; the server executes it
The confirmation streams back to the chat UI over SSE, and the dashboard updates

Conflict detection is mine, not the model's. When a create action lands, the server compares each new due time against every pending todo and flags anything within 60 minutes as Bentrok jadwal. The model proposes; the server double-checks — so a hallucinating model can't quietly hide Fatik's next double-booking. I tested it by pointing the app at a fake OpenAI-compatible server returning back-to-back appointments: new-vs-new, new-vs-existing, and exact-duplicate times all get caught, while unrelated dates stay quiet.

Everything that isn't the model is boring on purpose: a todos table, a messages table, and a settings key-value table. No agent framework, no vector database — the schema fits on an index card, which is exactly how Fatik's mental model of his own appointments works.

Why Does Open Innovation Matter?

Three things made this project possible because the core is open:

His data never has to land on a server he doesn't control. The whole app can run against Ollama on a laptop: set ai.base_url to http://localhost:11434/v1 on the settings page, and the same app now speaks to a model that never touches the internet. A closed API can't offer that — the request is the data, and it has to leave the building.
I can swap the model as a configuration change, not a rewrite. Because the open-weight model speaks the OpenAI-compatible dialect, changing ai.base_url + ai.model on the settings page (no redeploy) moves the app between OpenRouter's hosted Gemma and a local Ollama model. Try that with a closed provider's SDK — you're refactoring imports, not editing a text field.
It costs nothing to run for him. An open-weight model on a free-tier local runtime means his "second brain" has no subscription that can quietly lapse and take his appointments with it.

The honest trade-off: a closed model would probably parse messier sentences on the first try. What open bought me was control over exactly the things that mattered for this user — his privacy, his budget, and the freedom to tune the extraction prompt (ai.extraction_prompt, editable from the settings page) until it understood how he actually talks, without shipping a new build for every experiment.

[HANDOVER: what Fatik said after you gave it to him — the challenge gives bonus points for actually handing it over.]

Prize Categories

Overall prize only — this project doesn't use any partner technology.