DEV Community: Arqam Waheed

Munshi: a WhatsApp front desk for small hotels. A 4B model reads, Python decides, Temporal holds the room.

Arqam Waheed — Sun, 18 Oct 2026 14:17:39 +0000

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

TL;DR. Small hotels in Pakistan take bookings on WhatsApp, in Roman Urdu, at midnight. Munshi reads each message with a Qwen3.5-4B I fine-tuned on Tinker, prices the advance by how likely the guest is to cancel (TabPFN), drafts the reply with Gemma 4, and holds the room in a Temporal workflow until the advance arrives or the clock runs out. The fine-tune alone got 75% of booking messages exactly right. Moving the calendar arithmetic and the counting into plain Python took it to 30 of 30 on a test set I wrote after the rules were frozen, a tie with its teacher Gemma 4 (29 of 30) at an eighth of the prompt. Models read. Code decides.

What I Built

If you've booked a guest house in Murree or Naran, you've probably done it like this:

"AoA, kal 2 log ke liye 1 room chahiye 2 raat ke liye. rate kya hai? advance kitni?"

That one line is a booking: tomorrow ("kal"), two people, one room, two nights, and two questions. On the other side of it is an owner running a twelve-room hotel from a phone. The message arrives at 11:40 pm. The rate gets quoted from memory, the advance is "jo munasib ho" (whatever suits you), and nobody chases it. Booking.com fills rooms, but it doesn't answer that message.

The villain here is the promise with no deadline. Not the price. Not the competition. A quote nobody holds and an advance nobody chases.

So I built the clerk who holds the clock.

Munshi (the man who keeps the register at a small hotel's front desk) does four jobs for every message:

It reads the message. A 4B model fine-tuned on Tinker turns Roman Urdu, English, a mix of both, or Urdu script into strict JSON: check-in date, nights, guests, rooms, room type, budget. If the date or the head count is missing, it asks, then waits for the answer.
It prices the advance by risk. TabPFN scores how likely the booking is to cancel. Low risk pays 20% and the room is held for 12 hours. High risk pays 50% and the hold is 2 hours.
It drafts the reply. Gemma 4 writes it in the guest's language, from the parsed facts only, and code checks every number before the owner sees it.
It holds the room. A Temporal workflow waits for the advance. Partial JazzCash transfers add up. If the money doesn't come, the room is released and the guest gets a polite note.

The product in one picture. Booking.com fills the room. Munshi makes sure the room it held was worth holding.

Demo

57 seconds, no narration: the 11:40 pm message, the fine-tune reading it, the risk-priced advance, Gemma's reply with every number checked, the hold with two partial deposits, and the server kill. The file is also in the repo: docs/demo.mp4.

This is a real run, with the fine-tuned parser, TabPFN-3.5 and Gemma 4 all live:

The owner's desk, not a chatbot. The text is Gemma's; every number on the screen is Python's.

Code

ArqamWaheed / munshi

Munshi: a WhatsApp front desk for small Pakistani hotels (HF26 Week 2)

Munshi: a WhatsApp front desk for small hotels

One inquiry: WhatsApp text → fine-tuned Qwen3.5-4B on Tinker parses it to strict JSON → TabPFN-3.5 scores P(cancel/no-show) → (optional) SerpApi Google Hotels nearby nightly rates set the price, otherwise your base rate → Gemma 4 drafts the reply from parsed fields only → a Temporal RoomHoldWorkflow holds the room for a time that depends on the risk score waits for a deposit_received signal, then confirms or releases. A Temporal Schedule writes the owner's morning brief. Sentry traces every model and tool call.

Rule of the codebase: models read and write, code decides. Dates, counts, the advance, the hold time and every number in a reply are computed or checked in plain Python (munshi/dates.py, parser.apply_rules, policy.py reply.check_draft). Demo (57 s, no narration): docs/demo.mp4. Brand kit: DESIGN.md.

Results (every number is a file in `results/` or

…

View on GitHub

MIT licensed. Every number below is in a file under results/ or evidence/, and the scripts in eval/ regenerate them.

Interesting files:

munshi/dates.py: the calendar the 4B model kept getting wrong, as 135 lines of rules.
munshi/temporal/workflows.py: the room hold. One workflow per inquiry, signals for deposits and guest replies, a durable timer whose length comes from the risk score.
munshi/reply.py: check_draft(), which stops a reply from quoting a number nobody computed.
eval/temporal_drills.py: kills the worker, then the whole Temporal server, mid-hold, and prints the timeline from Temporal's own event history.

temporal server start-dev --db-filename munshi.db      # terminal 1
python -m munshi.temporal.worker                       # terminal 2
uvicorn app.server:app --port 8000                     # terminal 3 -> http://localhost:8000
python -m eval.temporal_drills                         # the durability numbers below

How I Built It

The rule behind all of it: models read and write, code decides.

Three models, three red boxes. Every red box is plain Python that can overrule the model before it.

Tinker: teaching a 4B model to read a booking message

Why fine-tune, not prompt. Untuned Qwen3.5-4B, given a one-line instruction and "parso 5 bande family room 3 din", invented its own schema and read "parso" (the day after tomorrow) as a hotel name. Gemma 4 reads it fine, but only with a 532-token rulebook in every request. The fine-tune gets a 68-token prompt and answers with the right date, 5 guests, 2 rooms and a family room.

The teacher writes the homework, code marks it. Gemma 4 (free tier) wrote 1,000 synthetic WhatsApp inquiries and labelled every one with the long rulebook. A check of 30 random labels against the rulebook found 7 with a wrong booking field, and 6 of those were the same habit (four guests became two rooms). Code fixed that before training, along with two bigger problems I'll come back to. 678 rows survived.

The fine-tune: LoRA rank 32 on Qwen3.5-4B, 3 epochs, batch 16, 126 steps. Loss only on the assistant's JSON, chat template rendered with thinking off, identically for training and serving. Dev loss went from 1.00 to 0.048. Tinker billed 387,659 training tokens per run, $0.29 a run, and I ran it twice. Everything this project did on Tinker (both training runs, every eval, the checkpoint storage) came to $0.66 on tinker billing usage.

The test: 80 messages I labelled by hand, none of them in the training data: 61 Roman Urdu or mixed, 4 in Urdu script, 15 that need a clarifying question, and 3 raw WhatsApp exports with names and phone numbers in them.

The first result was not the one I wanted.

Parser, first run (no code rules)	Booking fields exactly right (95% CI)	Prompt	$ per 1k messages	p50 latency
Gemma 4 + 532-token rulebook (the teacher)	87.5% (80.0–93.8)	532 tok	$0.075 list ($0 on free tier)	3.1 s
Qwen3.5-4B, untuned, short prompt	0.0%	68 tok	n/a	n/a
Qwen3.5-4B, untuned + the rulebook	68.8% (58.8–78.8)	532 tok	$0.27	2.4 s
Qwen3.5-4B + Munshi LoRA	75.0% (63.7–82.5)	68 tok	$0.084	1.0 s

The student lost to its teacher. 11 messages only Gemma got right, 1 only the fine-tune got right, p = 0.006.

It did not lose at reading. I went through every miss. The fine-tune found the dates, the people and the rooms in the text. It got the arithmetic wrong: which Saturday "hafte ko" means, how many nights "itwaar se peer tak" is, whether "chhe log" is six. A 4B model doing calendar maths in its head is the wrong job, not a bad model.

So the calendar moved into code. munshi/dates.py applies the rulebook: aaj, kal, parso (in Roman Urdu, English and Urdu script), weekday names, "is weekend", "agle hafte", bare day numbers, explicit dates and ranges. It only answers when the message is unambiguous. "Next friday", "aaj kal" ("these days") and a weekday said on that same weekday all go back to the model. I built it against the training set: it agrees with the teacher on 542 dates, abstains on 451, and the 7 disagreements are all the teacher getting the rulebook wrong ("25 ko" on 28 October means 25 November).

Then the counting. A head count or a room count written once in the message ("chhe log", "do kamray", "a double room") is read by code, in three scripts.

Booking fields exactly right	Run 1: no rules	Run 2: + dates	Run 3: + counts
Qwen3.5-4B, untuned + the rulebook	68.8%	81.2%	87.5%
Qwen3.5-4B + Munshi LoRA	75.0%	86.2%	95.0%
Gemma 4 + the rulebook	87.5%	n/a	98.8%

Code helped the teacher too: Gemma went from 87.5% to 98.8%. On this set it still beats the fine-tune, 3 messages to 0 (p = 0.25, not significant). Gemma has no run-2 number because its first run didn't store raw outputs, so it got one new run with all the rules.

Here is the honest part. I found the counting rules by reading the fine-tune's misses on this test set. That makes run 3 a tuned number, not a held-out one. So I froze the rules, wrote 30 new messages with labels from the rulebook, committed them to the repo, and only then ran the models, once:

Fresh set, run once after the rules froze	Booking fields exactly right	All fields	Roman Urdu
Qwen3.5-4B, untuned + the rulebook	27 / 30	43.3%	87.5%
Qwen3.5-4B + Munshi LoRA	30 / 30	90.0%	100%
Gemma 4 + the rulebook	29 / 30	86.7%	95.8%

30 of 30 sounds better than it is. With 30 messages, the exact 95% lower bound is 88%. On all fields the fine-tune beats the rulebook-prompted base model 16 messages to 2 (p = 0.001). On the booking fields alone it's 3 to 0, which isn't significant. Against its teacher it's 30 to 29: Gemma got one room type wrong. That's a tie, not a win (p = 1). A 4B model with a 68-token prompt now reads these messages as well as Gemma 4 26B with a 532-token rulebook, and the guest's words never leave for Google.

Every red cell is the same model with code doing the arithmetic.

The fine-tune learned to read. Code learned to count. Neither was enough alone.

Read the tables with these in mind:

I wrote every test label, with an AI coding assistant, checked against the rulebook. Re-deriving them caught three of my own mistakes (e03, m13, e15: "a family room" and "a double room" are one room). Real messages from a real hotel would be a better test.
"Booking fields" leaves out one field: language. The line between "Roman Urdu" and "mixed" was never in the teacher's rulebook and only picks the reply's style. I chose this before running any model. The all-fields number is in every table.
Latency through Tinker's hosted sampler moves around. The same fine-tune measured 1.0 s p50 in one run and 5.9 s in another twenty minutes later. I'm not claiming a speed win. The fixed wins are the 68-token prompt, a third of the cost of the prompted base model, and that the raw message goes to a model I own.
Budget is still the model's call. "8 hazar mein 2 din" is a total; "budget 6 hazar" is per night. I tried a rule. It got the first kind wrong on the training data, so I dropped it.
Urdu script is thin. One training row and 4 test messages. Code reads the dates and counts in Urdu script, but the model has barely seen it. More Urdu-script data is the first thing I'd add.

Gemma 4: writes every reply, decides no number

Gemma sees facts, not the guest. The raw message never goes to Google. Gemma gets a small JSON of parsed fields and the quote, and writes one short reply in the guest's language.

Then code reads the reply. check_draft() rejects a draft if it contains any number that isn't in the facts (Latin or Urdu digits, "16,000", "3.5k", "8 hazar"), if a quote leaves out the total, the advance or the hold time, or if it runs past 90 words. A rejected draft gets one retry with the complaint as a hint. If that fails too, the owner gets a template that can't invent anything.

Over 70 quote drafts, it never fired. 70 of 70 passed first time, in Roman Urdu, mixed, English and Urdu script. Gemma, given only the facts, never invented a price. The checker is insurance, not a fix.

It also showed me what the checker can't see. Every single draft says the room "available hai". Munshi doesn't know the hotel's inventory. That's not a number, so check_draft() lets it through. The owner's screen now says, next to the copy button, "Munshi cannot see your room inventory: check the room is free before sending."

Asked, not guessed. The workflow waited for the guest's answer, then re-read the whole conversation.

TabPFN: is the risk score honest, and is it worth money?

A small hotel has a small register. I gave each model 300 past bookings, about a year for a 12-room hotel, and tested on 2,000 it had never seen (public hotel-bookings dataset, CC BY 4.0). Ten different 300-row samples:

Model (300 training rows)	ROC-AUC mean ± std	Seeds won	Brier
TabPFN-3.5	0.830 ± 0.007	10 / 10	0.148
Logistic regression	0.806 ± 0.007	0 / 10	0.157
Gradient boosting	0.789 ± 0.018	0 / 10

A win, not a thrashing. Then the question a hold policy actually asks: when TabPFN says "high risk", is it?

Calibrated, not just accurate. The bands are where the money is.

The advance is the product. When a guest cancels, the hotel keeps the advance. Charging everyone 30% keeps 30% of the value of cancelled bookings and asks 30% of every honest guest. Pricing the advance by TabPFN's band keeps 37.7% and asks only 26.9%. More from the no-shows, less from everyone else.

The concession: logistic regression's bands do almost exactly as well on that policy (37.8% and 27.3%). TabPFN wins on ranking and calibration. The tiers are what pay. And the data is Portuguese hotels from 2015 to 2017, not Murree.

Temporal: a room hold is a promise with a deadline

One workflow per inquiry. Parse, score, draft, then wait for the advance with a timeout set by the risk band. Deposits and guest replies are signals, so a guest can pay in two JazzCash transfers and the hold confirms only when they add up to the advance.

Partial, not confirmed. A short payment never confirms a room, and a released hold shows the refund owed.

I didn't trust it until I tried to break it. eval/temporal_drills.py starts its own Temporal server and runs three drills with the real models:

Drill	What I did	What happened
1	SIGKILLed the worker mid-hold, then sent the deposit while no worker was running	Signal recorded at once; a fresh worker confirmed the booking. 6 activities scheduled, 6 completed, 0 run twice
2	SIGKILLed the worker and the Temporal server, and kept everything down 15 s past the hold deadline	The server came back at t = 127.3 s and fired the timer at 127.4 s: late by exactly the outage, not lost. Released, 0 run twice
3	Chaos: 50% of first attempts fail on purpose, 5 holds	5 / 5 completed; 11 of 25 activities failed once and succeeded on retry

The orange bar is the promise. Nothing was running for most of it, and it still ended on time.

The drill caught a real bug on its first run. The first time I killed a worker, the guest's quote took 107 seconds. Temporal's history showed why: score_risk was cancelled at its 90-second timeout. tabpfn_client's fit() is lazy, so the first predict_proba() after a worker starts does all the work, and it sat in the API for over a minute and a half. Now the worker makes one throwaway prediction before it takes any work, and a guest-facing TabPFN call gets two 30-second tries before falling back to logistic regression. Same drill afterwards: 1.5 seconds.

Sentry: where the time goes, and where code overruled the model

One inquiry is one trace, carried through Temporal by hand (there's no Sentry integration for Temporal, so every activity's input carries the trace headers and the worker resumes them):

The parser's chat span carries 121 tokens and $0.00008. Gemma's carries 286 tokens and $0 on the free tier. reply_check is the 0.08 ms where code reads the reply before the owner does.

The first real batch found a bug. I sent three WhatsApp messages at once. Sentry showed the parser's chat spans at 7 to 22 seconds, against about one second in the eval, plus two short chat spans with no tokens at all. The worker log said why: three parse_inquiry activities on the worker's thread pool all did the first from transformers import AutoTokenizer at the same moment. That import isn't thread-safe, so two of them failed and Temporal retried them. The worker now loads the tokenizer once before it takes work. The same three messages at once: 2.7, 2.7 and 7.1 seconds, no failed attempts.

And it showed what my error reporting missed. Those ImportErrors never became Sentry issues, because my activity wrapper only reported the failures I expected (rate limits, bad model output, provider errors). Anything else now gets reported before Temporal retries it. The one issue Sentry did catch, MUNSHI-1, was mine too: asking for a hold that doesn't exist was an unhandled 500. It's a 404 now.

Sentry never sees the guest. Spans carry model names, token counts, cost, timings and the checker's verdict. Never the message, the reply or a phone number. tests/test_tracing.py runs a real activity through a capturing transport and fails if the reply text shows up anywhere in what would be sent. Writing that test taught me something too: sentry-sdk 2.72 ships gen_ai spans as separate span items, not inside the transaction, so my first version found nothing.

Things I refused to do:

Do not let a model choose a price, an advance or a hold length.
Do not send the guest's raw message to a free-tier API. The fine-tune is the only model that sees it, after names, phone numbers and emails are stripped.
Do not fall back to Gemma when the parser fails. The owner replies by hand instead.
Do not change a test label because a model disagreed with it. Change it only if it broke a rule written down before the run, and say so.

What went wrong

All real, all fixed, most with a test or an evidence file in the repo.

My fine-tune lost to its teacher, 75% to 87.5%. It could read; it couldn't count. The fix was code, not more training.
TabPFN's first prediction blew the activity timeout. The 107-second quote above. The durability drill found it, not me.
I asked Gemma for "about 15%" incomplete messages and got about 60%. That would have taught the parser to answer "I don't know". Each generated batch is now told explicitly whether its messages are complete.
The teacher asked a question whenever the number of nights was missing. 136 of the first 650 training rows. The rulebook says ask only when the date or the head count is missing, so the rule moved into code.
My own rule read "19 ko room" as nineteen rooms. Caught by a test that checks every hand label is unchanged by the rules, before it reached production.
My drill made Temporal look slow. After a full restart the server took 0.5 s to accept connections, but my readiness check called asyncio.run() inside a running event loop, swallowed the error, and waited out its whole retry budget. The first timeline said 60 seconds.
My drills wrote fake bookings into the hotel's register. The next morning brief listed five arrivals who didn't exist.
Three messages at once broke the parser's first attempt. A thread-unsafe lazy import, found in the first real Sentry traces. The worker now loads the tokenizer before it takes work.
Pydantic called the untuned model's invented schema valid JSON. Every field came out empty, and the eval counted it as a valid answer.

Why Does Open Innovation Matter?

The guest's message is the hotel's customer data. Names, phone numbers, family size, travel dates. With an open 4B model fine-tuned for the job, the raw text goes to a model the owner controls. Gemma's free tier, where prompts may be used to improve Google's products, only ever sees parsed fields.

The weights are mine. The adapter is a 278 MB rank-32 LoRA on Qwen3.5-4B, kept in my Tinker account with no expiry. tinker checkpoint download exports it, and tinker checkpoint push-hf puts it on the Hugging Face Hub as a PEFT adapter. Tonight the export timed out three times while Tinker built the archive, so for now it lives there. Once it's out, it runs anywhere that serves Qwen3.5-4B.

Small and open is cheap enough for a 12-room hotel. The fine-tune costs $0.084 per 1,000 messages at Tinker's list price, a third of the untuned model carrying the rulebook ($0.27). Gemma 4 on a paid API would be cheaper still ($0.075), so cost alone isn't the argument. Keeping the guest's words off someone else's free tier is.

I could fix the model's habits, not just prompt around them. The teacher's bad habits were corrected in the data before training, and the arithmetic moved into code the owner can read. A closed API would leave me writing a longer prompt and paying for it on every message.

Where closed would win, honestly: a frontier API would probably read these messages with no training at all, and with code doing the counting the gap would be small. A hotel with no developer also can't run a Temporal server yet.

My First User

I don't have one yet, and I'm not going to invent one.

I haven't shown Munshi to a hotel owner. This weekend went into building it and measuring it, so every number here comes from messages I wrote, and the hotel-bookings data under TabPFN is Portuguese, not Pakistani. Whether an owner in Murree would trust a model with the advance, or pay for it, is still the open question. Finding out is the next step, and I'd rather report that honestly than fill this section in.

What I Learned

Put the rule in code, not in the prompt. Every serious bug in this build was a model doing something reasonable the business couldn't accept: asking about nights, dividing a nightly budget, counting the wrong Saturday. Each fix was a few lines of Python with a test.
A small model should read, not reckon. The fine-tune went from 75% to 95% without a single extra training step.
The advance is the product, not the model. TabPFN is the better model. The risk-tiered advance is what makes the money.
Kill it before you trust it. The durability drill was supposed to produce a screenshot. It found the slowest bug in the project.
Write the test set after you stop changing the rules. I didn't, the first time, and the post says so.

Prize Categories

Best Use of Tinker: LoRA on Qwen3.5-4B (rank 32, 678 rows, 126 steps), distilled from Gemma 4. Untuned: 0% (invents its own schema). Fine-tuned: 75% booking-exact on 80 hand-labelled messages, 95% with code doing the dates and counts, and 30/30 on a fresh set written after the rules froze, against 27/30 for the untuned model carrying a 532-token rulebook. 68-token prompt, $0.084 per 1k messages.
Best Use of Temporal: one durable workflow per inquiry: a risk-priced hold timer, deposit and guest-reply signals, release on timeout. Worker SIGKILLed mid-hold and the whole server SIGKILLed past the deadline: 0 activities run twice, and the timer fired 0.1 s after the server came back. The first drill caught a 107-second TabPFN cold start, now 1.5 s.
Best Use of TabPFN: P(cancel) from a 300-booking register: AUC 0.830 vs 0.806 / 0.789, 10/10 seeds, calibrated per band (82% predicted, 81% actual). It prices the advance: keeps 37.7% of cancelled booking value while asking honest guests 26.9%.
Best Use of Sentry Agent Tracing: one trace per inquiry across Temporal activities: invoke_agent → gen_ai.chat (model, tokens, cost) → execute_tool reply_check, where code overrules the model. No guest text in Sentry, enforced by a test.
Best Use of Gemma: Gemma 4 is the teacher for the fine-tune, the baseline it's measured against, and the writer of every reply, behind a checker it passed 70/70 times.

"we should go out this weekend": I built a Discord member that holds the clock until we're outside

Arqam Waheed — Sun, 11 Oct 2026 17:10:29 +0000

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

TL;DR. Group plans don't die from disagreement. They die because nobody holds the clock. Quorum is a member of your Discord channel that does. Tell it what limits you, type /plan, and Gemma 4 drafts real places nearby that fit everyone. A Temporal workflow then runs the poll, locks the plan, re-checks the rain at 05:30 and sends the 06:00 reminder, even if my laptop crashes or the agent server is asleep. Total bill: $0.

What I Built

The problem Quorum solves is older than any of that. You know how it goes. Someone says "we should go out this weekend." Three people agree. Nobody picks a place, nobody closes the poll, and on Sunday nobody is outside.

The villain here is the missing clock. Not disagreement. Not apathy. There is just nobody whose job it is to say "the poll closes at 22:00, I'll check the weather at 05:30, see you at 06:00."

So I made that somebody a bot.

For each friend, the whole interaction is a few taps in the channel they already use:

/join, then one line per limit: /me no car, /me home by 11, /me knee hates long descents.
Someone types /plan date:2026-10-17 people:4. Quorum replies with 2-3 real places near home, each with the limits that shaped it.
A vote menu. You pick every option you can make. When enough people can make the same one, it locks. If 22:00 the night before comes first, Quorum says so, and nobody feels guilty.
At 05:30 it re-checks the rain for the exact hours you'll be out. At 06:00 it posts the reminder, or the rain-proof switch. When you're back, it asks for one line about how it went and remembers it for next time.

The whole product. The left side is every group chat. The right side is the job nobody wanted.

Demo

The 30-second demo is also in the repo: docs/quorum-demo.mp4.

Try it without joining any chat: quorum-y649.onrender.com/try. Type a few made-up people with their limits, a city and a date. You get the same options the bot would post. It runs on Render's free tier, so the first load can take about a minute while it wakes. That nap turns out to matter below. On the live service, one draft for Islamabad took 72 s: two tool calls, Lake View Park and F-5 Park, zero invented places.

This is what /plan posts in the channel. Every option names the limits it was built around:

Shaped by your limits, not by a generic "top 10 parks" list.

The poll locks the moment enough people can make one option. Then nothing happens for hours, on purpose, until the reminder:

The 06:00 message. This is the one that actually gets people out of bed.

What's real and what isn't

Real: every message and every number in this post comes from runs against the live services (Gemma 4 on the Gemini API, MongoDB Atlas, Discord, Open-Meteo, OpenStreetMap), copied from the plan's own event log.

Not real yet: a group outing. The real plan is for Saturday 17 October, which is after the deadline. What you see is a full rehearsal with the timers compressed to minutes, plus three failure drills.

Not live after publishing: the Discord bot and the Temporal worker run on my laptop. The Render pages stay up.

Code

ArqamWaheed / quorum

A group-chat member that holds the clock until your friends are actually outside.

Quorum

A member of your friend group's Discord server that turns "we should go out" into an actual outing. A Mastra agent on Gemma 4 drafts plans around everyone's constraints, and a Temporal workflow holds the clock: poll, quorum deadline, weather re-check, morning reminder, recap.

Live: quorum-y649.onrender.com (try it at /try; free tier, first load can take a minute). Demo: docs/quorum-demo.mp4, 30 seconds.

Discord ──► laptop: bot + Temporal dev server + worker ──HTTPS──► Render: Mastra agent (Gemma 4) ──► MongoDB Atlas
                                                                    tools: Open-Meteo, OpenStreetMap

Temporal owns time: waiting for votes, the 05:30 weather check, the 06:00 reminder, retrying a sleeping server.
Mastra + Gemma 4 own reasoning: which outing, and which constraint shaped it.
MongoDB Atlas owns memory: who joined, their limits, plans, recaps, and semantic recall of past outings.
Render owns the public face: the agent API, the plan page /p/:id, and the demo at…

View on GitHub

Apache-2.0. Interesting files:

src/temporal/workflows.ts: the whole outing as one function. Poll, quorum, 05:30, 06:00, recap.
src/temporal/activities.ts: calls to the agent server with retries, and every Discord message.
src/mastra/agents/quorum.ts and src/mastra/draft.ts: the Gemma 4 agent, its tools, and the check that throws out any place the tools didn't return.
src/bot/discord.ts: slash commands, plus votes turned into workflow signals.
scripts/test-workflow.ts: the whole workflow against a local Temporal server with fake activities, timers in seconds. 9 checks.

The heart of it is a vote that can wait for days and survive restarts:

const reached = await wf.condition(
  () => tally(votes, options.length).count >= p.quorum, // enough people for one option…
  until(p.pollCloseAt),                                 // …or 22:00 the night before
);

npm install && cp .env.example .env        # Gemini key, Atlas URI, Discord token
./scripts/run-local.sh                     # Temporal dev server, UI on :8233
npm run worker & npm run bot & npm run dev

How I Built It

Four owners, one job each. Temporal owns time. Mastra and Gemma 4 own reasoning. MongoDB Atlas owns memory. Render owns the public page. The laptop holds only the clock and the bot token.

The split. A workflow can't judge a knee. An LLM can't sleep until 05:30.

Why a workflow, not cron or setTimeout. The outing is one Temporal workflow. Votes arrive as signals. condition() waits for quorum or the deadline. Then sleep() waits until 05:30 and 06:00. The bot does all the time math and hands the workflow absolute timestamps, so the workflow itself stays deterministic. A setTimeout on a free host that sleeps every 15 minutes would die before Friday. Temporal persists the timers, so a restart just resumes them.

I didn't want to take that on faith, so I tried to break it.

Durable by design, not by luck. Every step is a timer or a retry that Temporal persisted.

Crash. Mid-poll, I ran kill -9 on the worker, then stopped the Temporal server itself and started it again on the same database file. The workflow came back in voting. My vote landed. The plan locked.

A sleeping server is a test, not a bug. The agent runs on Render's free tier, which sleeps after 15 idle minutes and takes about a minute to wake. So the 05:30 weather check will usually hit a sleeping server. The activity has a 45-second fetch timeout and a retry policy (5 s, doubling, 12 attempts). To prove it, I stopped the agent server right before the check:

Attempt 5 of 12. Temporal kept knocking until the server answered.

Temporal doesn't write every retry into the event history. It keeps the attempt count and the last failure. So the activity also logs every attempt to the plan's own record, and the public plan page shows it:

Four failures and one success, in public. The retry log is a feature, not a debug screen.

The rule is code. The alternative is Gemma. At 05:30 the forecast is checked by plain code against a rain limit. Only if it fails does Gemma get 20 seconds to pick or adapt a rain-proof alternative. If it can't, code takes the option with the least rain in its window. For the drill I forced the limit to 0%:

Plan B, posted at 06:00. Nobody had to call a group vote at dawn.

Mastra reasons, and only reasons. The agent has two tools, weather (Open-Meteo) and places (OpenStreetMap), plus memory, and returns structured options. Its instructions forbid any place the tools didn't return. The code checks anyway: an option whose place isn't in the tool's list gets dropped, and if fewer than two survive, code builds them from real places. Across 16 smoke-test drafts it dropped 0 invented places.

Gemma 4, measured rather than assumed. Gemma 4 has built-in function calling, but Mastra's model catalogue doesn't mark the Gemma 4 IDs as tool-capable. So before trusting it, I ran the same planning prompt with a fake 5-person roster, 8 times per model:

Model (same agent, Gemini API free tier)	valid plans with tool calls	invented places	median time	Gemini errors retried
`gemma-4-26b-a4b-it`	8/8	0	128 s	0
`gemma-4-31b-it`	7/8	0	202 s	4

26B runs Quorum. The 31B returned "Internal error encountered" on about half its calls at first, so transient Gemini errors are now retried inside the draft call, then again by Temporal. I also tried having code fetch the weather and places and handing them to Gemma in the prompt. It was not faster (120-193 s), so the time goes into generation, not tool round trips.

Atlas remembers what a context window forgets. Your limits live in a plain members collection, so they never depend on the model deciding to call a "remember" tool. Everything said to the agent, recaps included, also goes into Mastra memory on Atlas with semantic recall over Atlas Vector Search (3072-dimension Gemini embeddings). So next week's draft can read last week's recap before it proposes anything.

Two honest concessions.

It's slow. About 2 minutes per draft on the free tier. That's fine for a plan that waits until Friday night. It was not fine for my own test: the first compressed poll closed 53 seconds after the options appeared, because drafting ate most of a 3-minute window. I gave test polls 7 minutes. Real polls stay open for days.

OpenStreetMap's public Overpass servers were down all weekend. Every mirror returned 504s or timed out. Places now fall back to Nominatim, the same OpenStreetMap data ranked by importance, and the results are cached in Atlas. Around Islamabad that still gives Margalla Hills National Park, Shakarparian and Rawal Lake Viewpoint. It also gives a few parks named after sector numbers, which is accurate and a little sad.

Things I refused to do:

Do not let the bot read the chat. It connects with only the Guilds intent, no Message Content, so it sees slash commands and taps on its own buttons, nothing else.
Do not store people who didn't /join. /forget deletes your limits and recaps.
Do not let Gemma invent a place. If the name isn't from OpenStreetMap, it doesn't reach the poll.
Do not edit the workflow during a live run. I froze workflows.ts with a git tag before starting the real plan, because Temporal replays history against the code.

Why Does Open Innovation Matter?

A group chat holds things people wouldn't put in an app: whose knee is bad, who's broke this month, whose parents set a curfew. That shaped three choices.

Open weights mean a local option exists. The same agent switches to gemma4:e4b on Ollama with one environment variable. I haven't benchmarked it yet, so I won't claim a number, but the switch is in the code, and with it nothing leaves the laptop. A closed API offers no such switch.

Honest trade-off. The runs above used Gemma 4 through the Gemini API's free tier, which says content may be used to improve Google's products. /help says so before anyone joins, and the bot only ever sees what you deliberately send it.

Open infrastructure all the way down. Temporal's open-source server made a durable, multi-day workflow possible at $0 on a laptop. Mastra is Apache-2.0. The places come from OpenStreetMap and the forecasts from Open-Meteo. Total bill: $0.

My Agent Session

I built Quorum with Claude Code, with the Entire CLI capturing every session and linking it to the commit it produced. Every checkpoint is browsable on the entire/checkpoints/v1 branch.

The one I'd point at is the fix for the 53-second poll:

● Checkpoint 199ef0496889
commits 68e95ec fix: longer test-run poll window; drafting alone takes ~2 min on the free tier

Inspect it with entire checkpoint explain 68e95ec in a clone. The decision, why test polls are 7 minutes and not 3, now lives next to the code it explains.

What I Learned

Durability is a product feature, not infrastructure. The 06:00 reminder is the only message that gets people out of bed. If it depends on a laptop not sleeping, it isn't a feature.
Measure the model before you trust the catalogue. The catalogue left Gemma 4's tool column blank. 8 out of 8 says otherwise for 26B.
The weakness belongs in the UI. The plan page shows every failed attempt. A tool that hides its retries is a tool you can't trust at 05:30.

Prize Categories

Best Use of Temporal: the whole outing is one workflow (planOuting): vote signals, condition() with a quorum deadline, durable timers to 05:30 and 06:00, and activity retry policies. Survived kill -9 of the worker plus a server restart mid-poll, and retried a dead agent server 4 times before attempt 5 succeeded.
Best Use of Mastra: an Agent over Gemma 4 with createTool tools (weather, places), Memory with semantic recall, and structured options that name the limits that shaped them, with code that drops any place the tools didn't return. 0 invented places in 16 drafts.
Best Use of MongoDB Atlas: Atlas M0 is the agent's long-term memory (Mastra MongoDBStore) and retrieval layer (Atlas Vector Search via MongoDBVector, 3072-d, index READY). It also stores members, plans with every retry attempt, polls, recaps and the places cache.
Best Use of Render: the agent API, the plan pages and /try run on one free web service from one render.yaml, live at quorum-y649.onrender.com. Its 15-minute sleep is designed for: the 45-second timeout plus Temporal retries turn a cold start into a few logged attempts.
Best Use of Gemma: gemma-4-26b-a4b-it plans every outing with native tool calls through Mastra. Measured against 31B: 8/8 vs 7/8 valid, 0 invented places each, 128 s vs 202 s median.
Best Use of Entire: every agent-written commit has an Entire checkpoint, browsable on the entire/checkpoints/v1 branch, and quoted above to explain why the code is the way it is.

Quorum closes the poll at 22:00 the night before and reminds at 06:00. If you've ever organised a group outing: where would you put the clock? The night before, or 48 hours out, so the people who can't make it say so early?

WhyRep is now officially out! The workout logger that also analyzes your training.

Arqam Waheed — Mon, 05 Oct 2026 17:40:47 +0000

TL;DR. WhyRep is out on Google Play. It logs your workouts like any gym tracker, then reads them back to you: every lift gets a verdict (progressed, flat, or went back), every plateau gets a fix, and every verdict shows the reason behind it. Free, offline, no account needed. Get it on Google Play.

The question your gym log can't answer

Every workout tracker I've tried has the same limitation: it records what you did, but it doesn't tell you what's going wrong.

You log the sets. You log the reps. Three months later you scroll back through a perfect record of training and still can't answer the only question that matters.

Is any of this working?

That's the question behind most program-hopping. You train hard for a few months, nothing visibly changes, and you can't tell if it's a real wall or a program that stopped working. So you switch. Then you switch again. A lifter on the StrongFirst forum summed it up: "I am also going through too many programs, never really reaping all the benefits."

The apps that do try to coach you mostly hand you a number and ask you to trust it. Lifters have noticed. One FitnessAI reviewer: "There's no 'AI' involved here. That's purely marketing."

So I built a tracker that has to show its work.

What WhyRep does

Every workout gets a verdict. Finish a session and WhyRep checks each lift against your own history: progressed, flat, or went back. The summary at the top tells you how many lifts need attention, and the rest stay quiet.

A plateau is measured, not guessed. How many flat sessions count as a real plateau depends on your experience level. A beginner who stalls twice on squats is stuck. A lifter with years behind them on a slow-moving curl isn't, and WhyRep doesn't pretend they are.

Stuck? You get the fix. When a lift stalls, WhyRep suggests the first thing to change, like a new rep range or spreading a muscle's sets across more days. Accept it or turn it off. Nothing changes your program behind your back.

Left, the verdict. Right, the fix. Both open to the reason behind them with one tap on "Show the why".

It checks your life before your program. Sleeping badly for a while, or training without the carbs or pre-workout you usually take, can hold a lift back on its own. So WhyRep asks first. If that's the likely reason, it tells you to sort that out and leaves your program alone.

Then the logger walks you through the fix. Accept a fix and your next workout shows you what to do on that lift, in plain steps, and how many sessions are left on it.

Sleep and food get asked about first. Only then does it touch your sets.

And it's a fast gym log first

None of that matters if logging is slow, so the logger is built for speed.

A keypad built for the gym floor. Weight, reps and RIR (reps in reserve) in a few taps
Last session's numbers next to every set, so you know what to beat
A rest timer under every set, started when you tick the set above it
Progression charts for every exercise, by weight and by effective reps (reps plus reps in reserve), so a rep at the same effort shows up as progress

Same 80 kg for seven weeks, and the effective reps chart still shows the climb. A weight-only chart would be a flat line.

Weekly volume per muscle on a body map, so the muscle you keep skipping is obvious
Routines and splits. Save any workout as a routine, build Push Pull Legs or Upper Lower or your own, and WhyRep tells you what today's session is
Share a routine with a link. No account needed on either end

The gap shows up here before it shows up as a plateau.

847 exercises, every one with a picture, an equipment filter, and your own custom ones
Single-side logging, left and right separately, for lifts like split squats
Works offline, no account needed. On a plane or in a basement gym, it still works. A lifter who never signs in has no server copy of their training data. Sign in and your history backs itself up, so a new phone picks up where the old one stopped

Every exercise has a picture, and none of it needs a signal.

Why you can trust the verdicts

This is the one technical bit, and it's the reason the app exists.

The part that judges your training isn't AI, and it isn't me guessing. Every rule comes from a written methodology, one document per coaching system, each ending in a table of exact test cases: this training history in, this verdict out. The app is tested against those cases.

So a verdict like "5 in a row counts as a plateau at your level" isn't a vibe. It's a rule you can read, and you can disagree with it.

The verdicts come from written rules, not from a model's guess.

Free and Plus

Free: the full gym log, all 847 exercises, rest timers, 3 months of charts, 5 routines, and a badge that tells you when a session has something to fix.

Plus: the reasoning behind every verdict, plateau fixes, weekly volume per muscle, your experience tier, unlimited routines, and a full year of charts.

Free always tells you when a session has a problem. Plus shows the verdict on every lift, explains why, and gives you the fix.

Plus is $35 a year or $3 a week, with a 3-day free trial (US prices; Play shows yours in your currency). The yearly plan works out to about 67 cents a week.

What it doesn't do yet

I'd rather say this now than read it in a review.

No nutrition tracking, no form checking from video, and no body fat scoring. I could have shipped all three as guesses. None of them has a written method behind it yet, and a feature that guesses about your body is worse than one that says "not covered yet."

No iPhone app yet. It runs on the same core as the Android app and it's next.

Coach chat is built but not switched on yet. When it arrives, it starts from the same written rules the verdicts use.

Try it

If you lift and you've ever wondered whether the last three months did anything, this is the app I built for that.

Get WhyRep on Google Play

More at whyrep.com.

Log the same lift twice and WhyRep starts judging it. The 3-day trial shows you every verdict and the reason behind it. Then tell me the first one you disagreed with. That's the most useful feedback I can get, because it means either the rule is wrong or the explanation is.

"If it's not in front of me, it's gone": I fine-tuned a 4B model for my friend with ADHD

Arqam Waheed — Mon, 05 Oct 2026 02:52:09 +0000

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

TL;DR. My friend Zee has ADHD. I asked him what actually goes wrong, and he answered in two lines: things he can't see disappear, and the one thing he locks onto eats the whole day. So I built Actually. You brain-dump in your own messy words. A Qwen3.5-4B I fine-tuned on Tinker turns that into tasks, and TabPFN reads your own history to tell you how long each one will actually take you. Nothing you dump disappears until you tick it off. Everything except the parser runs on my laptop, and the whole build cost $2.81.

What I Built

I had the idea before I asked him. That was mistake one.

My plan was a time-blindness tool, a thing that tells you "this'll take 15 minutes" is a lie. It was a fine idea. Then I messaged Zee and asked what his actual problem was, and he sent back this, verbatim:

"can't remember. if infront remember or else gone from brain. person or task"

"addiction pro max. if i addict i addict too much. idk these 2 main."

Two problems, and only half of one was the thing I'd planned to build.

The first is out of sight, out of mind. A task or a person that isn't physically in front of him stops existing. The second is hyperfocus. When something grabs him, it takes the afternoon, and everything else silently falls off the end of the day.

So I rebuilt the plan around his words, not mine.

Actually is a single page. You type everything on your mind the way you'd text it: "email sir abt the attendance thing (5 min), finish dbms assignment should take like 30 min, laundry maybe, call nani back i keep forgetting." Three things happen:

It splits your rant into tasks, and every one of them goes on a "Still on your plate" list that stays there until you press Done. People get an amber dot, because "call nani back" is exactly the kind of thing that vanishes.
It tells you how long each task will take you. Not how long tasks take in general. How long your admin tasks take relative to your guesses, from your own history.
It fits the day to your free time and warns you when a single task could swallow it.

The brief, in his words. The left side is Zee's description. The right side is the whole product.

Demo

Demo: docs/actually-demo.mp4.

Code and setup: the repo runs locally in four commands (below). There is no hosted link yet, and I'll explain why in the concessions.

This is the result screen for the brain-dump above, on the demo profile:

The verdict. 35 minutes of stated guesses, 3 hours 14 minutes of predicted reality.

Every task gets a short lavender bar for your guess, a cobalt bar for the prediction, and a faint band for the 10–90% range. Tasks that don't fit go under "Move to tomorrow" in amber. They don't get deleted, and they don't fall off the list.

Moved, not forgotten. Laundry doesn't fit in three hours, so it waits on the plate for tomorrow.

Code

ArqamWaheed / actually

How long will it actually take? A time-blindness helper for a friend with ADHD — fine-tuned open model (Tinker) + TabPFN, runs on one box.

Actually

How long will it actually take you? A planning aid built for one friend with ADHD.

My friend described his two problems like this:

"if infront remember or else gone from brain. person or task" "if i addict i addict too much"

Out of sight is out of mind, and when he does lock in, one thing eats the day. So Actually does two things:

Nothing you dump disappears. Type a messy brain-dump. A small open model, fine-tuned on Tinker, splits it into tasks. Every task and every person you mention stays on a "Still on your plate" list until you tick it off.
It shows the real cost of each task. TabPFN, a tabular foundation model, reads your own history of guessed vs real durations and predicts how long each task will take you, with a range, the chance you finish it today, and a…

View on GitHub

MIT licensed. eval/ reproduces every number in this post.

Interesting files:

app/parser.py: the brain-dump to JSON parser. One interface, two backends (Tinker sampling or any OpenAI-compatible local server).
app/forecast.py: TabPFN regressor and classifier over the user's own task history.
train/sft.py: the whole LoRA fine-tune in 65 lines of Tinker SDK.
eval/parser_eval.py and eval/tabpfn_eval.py: the comparisons in the tables below.

uv pip install --python .venv/bin/python -r requirements.txt
cp .env.example .env            # TINKER_API_KEY, TABPFN_TOKEN, TINKER_SAMPLER_PATH
python scripts/make_demo_data.py
PARSER_BACKEND=tinker uvicorn app.main:app --port 8000

How I Built It

The pipeline. Two open models, each doing the one job it's actually good at.

Why two models, not one. I could have asked one large model to read the rant and guess durations. It would have answered confidently and been wrong in a generic way, because it has never seen how long Zee's tasks take. Reading messy language is a language model's job. Predicting a number from a small table of personal history is a tabular model's job. Splitting them made each one honest.

The parser: a 4B model that reads a brain-dump. Brain-dumps are hard for small models. They merge two tasks into one, miss the "maybe" that makes a task optional, and lose deadlines buried mid-sentence. I needed strict JSON with seven fields per task, from text like "ugh exams are killing me rn... reply to dad about fee slip. also need batteries for the remote?? maybe."

The data: every model in the pipeline is open-weight. I didn't have hundreds of real brain-dumps, and I wasn't going to fake Zee's. So Qwen3.6-35B-A3B wrote 450 messy brain-dumps in a Pakistani-student register, and Qwen3.5-397B-A17B labelled every task in them. Both ran on Tinker's sampling API. 448 survived validation. I held out 48 and trained on 400.

The fine-tune: LoRA rank 32, 3 epochs, 75 steps. Tinker gives you a training loop, not a black box. train/sft.py renders each example with the chat template, masks the loss to the assistant's JSON tokens only, and runs forward_backward plus optim_step with a linear decay. Loss went from 335.5 to 43.3.

The training loop. The amber note is the caveat, and it stays in the picture on purpose.

Did it beat the baseline? Same 48 held-out dumps, same prompt, temperature 0:

Parser	valid JSON	task F1	kind	deadline	p50 latency
Qwen3.5-4B zero-shot	98%	95%	78%	69%	3.19 s
Qwen3.5-4B 5-shot	96%	93%	82%	55%	3.28 s
Qwen3.5-9B zero-shot	100%	94%	88%	61%	4.53 s
Qwen3.5-4B + LoRA	100%	97%	93%	76%	3.28 s

The fine-tuned 4B beats a model more than twice its size on every column that matters, and it's 1.4x faster than that 9B. Few-shot prompting made deadlines worse (69% to 55%). Five examples in the prompt taught the base model the format, not the judgement.

Two honest caveats. First, the test set is synthetic, and its labels come from the 397B teacher, so this measures agreement with a much larger open model, not accuracy against a human. Second, "all fields exactly right on every task in a dump" is still only 8% for the fine-tune. Seven fields times six tasks is a brutal bar, and the misses are mostly dreaded and deadline, which are judgement calls.

The forecaster: TabPFN, because the table is tiny. A person's task history is maybe 40 to 100 rows. You can't train a model on that, and you shouldn't try. TabPFN doesn't train. It reads the whole table in-context and predicts. I run TabPFNRegressor on log-duration and ask for the 10th, 50th and 90th quantiles, so every estimate comes with a range. A TabPFNClassifier predicts whether the task gets done the day it was planned. The features are boring on purpose: kind, his guess, start hour, weekday, dreaded, leaves the house, has a deadline.

In-context means every finished task counts immediately. When you press Done and log how long something took, that row joins the history and the next plan uses it. No retraining step exists, because TabPFN has nothing to retrain. For a tool about a single person, that's the whole bet.

The carry-over list is the boring feature that matters most. db.remember() writes every parsed task to SQLite and dedupes near-identical titles, so saying "call nani back" three days running doesn't create three entries. The list renders above the input box, so it's the first thing on screen, which is the literal fix for "if infront remember."

Out of sight is the bug. This list is the fix: it stays in front of you until you clear it.

The hyperfocus warning is one line of logic. If a task's 90th-percentile estimate is at least half your free time, the card says "This one can swallow your day. Set a timer before you start." It isn't clever. It's the sentence Zee needs to see before he starts, not after.

Sentry found the slowest part, and it was not the language model. Every plan request is one agent run: invoke_agent actually, then a gen_ai.chat span for the fine-tuned model with the model name and token counts, then execute_tool tabpfn_forecast. OpenAIIntegration(include_prompts=False) and send_default_pii=False keep the brain-dumps out of Sentry entirely.

I assumed the model call would dominate. It didn't. The TabPFN tool span was taking 2.4 to 3.5 seconds per request, because predict() was re-attending over every history row on every call.

The fix, as Sentry saw it. Same tool, same history, 3.25 seconds down to 268 milliseconds.

TabPFN has a fit_mode="fit_with_cache" that computes the history's attention state once at fit time. Fitting gets slower (2.50 s to 3.43 s, once per history change). Predicting got 9x faster, from 2.43 s to 0.27 s. End to end, a plan went from 5.6 s to 3.5 s.

The slow part was re-reading 70 rows of history on every request, not the model.

The trace also showed what's left. The gen_ai.chat span is now 3.2 s of a 3.5 s request, and most of it is two HTTP round-trips to Tinker with a gap between them, not token generation. That's the clearest argument I have for the next step: serve the parser locally.

Where the time goes now. The remaining cost is network, which is a hosting decision, not a model one.

Things I refused to do:

Do not invent Zee's data. The live demo runs on a profile labelled "Demo person (made-up data)".
Do not claim the parser is local while it's served from Tinker. The footer of the app changes depending on which backend is running.
Do not send brain-dumps to the observability tool. Sentry gets durations and token counts, never prompts.
Do not use a Shapley chart where a plain sentence works. The "why" chips are per-kind overrun ratios from your own history: "admin tasks take you ~2.9x your guess."

Why Does Open Innovation Matter?

Three reasons, all specific to Zee.

I could teach a model his way of writing. The fine-tune is the whole trick: task type 78% to 93% on held-out dumps for $2.81 of compute. You can't fine-tune a closed model this way, and you can't download what you trained. I downloaded mine. The LoRA adapter is a 291 MB file on my disk, and Tinker's cookbook can convert it to a standard PEFT adapter or merge it into the base model.

His history never leaves the machine. An ADHD diagnosis, what he avoids, how long he spends on things: that's health data. TabPFN-3.5 runs locally on CPU with open weights, so the part that reads his life is on a laptop, not behind an API. Sentry only ever sees timings.

The tools are inspectable all the way down. When the forecast was slow, I could read TabPFN's source, find fit_mode, and fix it in one line. The parser's chat template let me switch off the model's thinking mode, so it answers in JSON instead of reasoning first. A closed API gives you neither lever.

Where closed would have been better, honestly: a frontier API would probably parse these brain-dumps about as well as my fine-tune with zero training, and it would be faster to call than Tinker's beta sampling endpoint. I traded that for owning the weights and keeping his data local. For a tool about one person's head, that trade is the point.

My Agent Session

I built this with Claude Code, and every session is captured with Entire. Entire stores the prompts, reasoning and tool calls next to the commits they produced, with secrets redacted before anything leaves the machine. I added explicit redaction rules for every key this project touches, then grepped the checkpoint for each one before pushing. Zero hits.

Checkpoint 01M4494DVYMY4YYYJF1ZKAK7S3: the full session, from reading the challenge page and measuring every prize pool, to picking the stack, training the parser and the Sentry fix. 17 turns.
Inspect it with entire checkpoint explain 01M4494DVYMY4YYYJF1ZKAK7S3 in a clone of the repo.

The checkpoint's generated summary is the best changelog this project has. One line from it: "Tinker's raw LoRA adapter export through tinker-cookbook's PEFT builder downloads the full 8GB base model. That won't fit on a low-disk machine, so convert the adapter directly instead." That decision, why the parser isn't self-hosted yet, now lives next to the code it explains.

What I Learned

Ask the person before you design. I had a polished time-blindness pitch. Zee's two-line answer turned it into a carry-over list plus a hyperfocus warning, and those are the parts he'll actually use.
A small model plus a fine-tune beats a bigger model plus a prompt. The 4B LoRA beat the 9B on every column, and few-shot prompting made the hardest field worse.
Profile before you optimise, and don't trust your guess about where the time goes. I'd have bet on the LLM. It was a tabular model re-reading 70 rows.
Concessions belong in the product, too. The demo profile says "made-up data" in the dropdown. The footer says where the parser runs. A tool for someone who's hard on himself should never lie to him.

Prize Categories

Best Use of Tinker: LoRA fine-tune of Qwen3.5-4B (rank 32, 400 examples). On 48 held-out brain-dumps it beats the base 4B, base 4B 5-shot, and the 9B: task type 93% vs 78/82/88%, deadline 76% vs 69/55/61%, 100% valid JSON, and 1.4x faster than the 9B. The dataset was also generated and labelled on Tinker with open models. Total spend $2.81. Adapter downloaded.
Best Use of TabPFN: local TabPFN-3.5 regressor (log-duration, 10/50/90% quantiles) and classifier (done the same day?) over the user's own small history. In-context, so every logged task updates the next plan with no retraining. fit_with_cache cut predict latency from 2.43 s to 0.27 s.
Best Use of Sentry Agent Tracing: invoke_agent → gen_ai.chat (model, input and output tokens) → execute_tool tabpfn_forecast, prompts excluded. Traces found the real bottleneck (TabPFN predict, not the LLM), I fixed it, and the traces confirmed it: 3.25 s to 268 ms on the tool span, 5.6 s to 3.5 s end to end.
Best Use of Entire: the full build session captured as a redaction-checked checkpoint linked to its commit, and quoted above to explain why the code is the way it is.

The charity had the proof. It just couldn't show anyone.

Arqam Waheed — Sun, 06 Sep 2026 13:56:31 +0000

This is a submission for Weekend Challenge: Generosity Edition

TL;DR — A charity's proof of impact is made of other people's private lives, so it never gets published. Consent keeps the raw notes inside Snowflake and lets only a redacted dataset and a written brief out. Two things went wrong: the trial account refused nine of the eleven AI functions I designed around, and the boundary I built to protect the data didn't work. Both are in the post, with the error strings.

What I Built

A friend runs a three-person charity. Last year, a funder asked them to prove their work mattered. They could. They had two years of evidence sitting in a spreadsheet. They just couldn't send it.

Every row contained someone's name, phone number, address, and a story they had shared with the charity during the worst week of their life. Those people had trusted the charity to help them, not to turn their private circumstances into evidence for someone else. Sending the spreadsheet would have broken that trust.

So the honest answer was, "We can't show you that." The funder heard something very different: "We don't have the evidence."

That's the problem I wanted to solve. Not privacy law, and not funders. The problem was the false choice between protecting the people who trusted the charity and proving that the charity's work actually helped them.

I didn't want to choose either side. So I moved the boundary instead of the data.

The private records stay where they are. The charity can still prove what happened. A funder can see the impact without ever seeing the person behind it.

That's what I built.

Consent turns a charity's messy private records into two things it can actually hand over: a publishable impact brief, and a de-identified dataset a funder or a researcher can be given.

The rule that shapes everything: the raw record never leaves the warehouse. Redaction, triage and the written summary all happen as SQL inside Snowflake, where the data already lives. Only the redacted side crosses the boundary — including to the app you're looking at.

That isn't a promise in a privacy policy. It's a grant:

GRANT SELECT ON TABLE CONSENT.APP.SAFE_CASES TO ROLE CONSENT_APP;
-- deliberately NOT granted: RAW_CASES

The app literally cannot read the private table. The left panel of the UI shows a row count and nothing else, because a row count is all its role is allowed.

The whole product in one frame. The left half never moves; only the right half is allowed to leave.

Demo

Live App: https://consent-warehouse.streamlit.app

Video Walkthrough:

The Warehouse status panel prints the live region, account and role, and probes each Cortex function in front of you. I'd rather show a red light than claim a green one, and on this account, most of them are red.

The refusal is the feature. The app asks for the private note on every page load so you can watch it be told no.

Code

ArqamWaheed / consent

Consent

Publish your impact without publishing your people.

A small charity's proof of impact is made of other people's private lives, so the proof never gets published. Consent turns a messy private casework file into two things a charity can actually hand over: a publishable impact brief and a de-identified dataset.

The rule that shapes everything: the raw record never leaves the warehouse.

Submission for Weekend Challenge: Generosity Edition.

The boundary, in three layers

Layer	Mechanism	Requires	Status here
A	Role grants — the app has no `SELECT` on the private table	nothing	shipped
B	Masking policy — the engine returns different truths per role	Enterprise Edition	not available
C	Cortex AISQL — the model reads the notes so no human has to	Cortex entitlement	shipped, rebuilt

Layer A is the thesis and cannot fail. B and C are upgrades. This account got one of them.

What the

…

View on GitHub

Apache-2.0.

Interesting files:

sql/10_leg_a_grants.sql — the six grants the app gets, and the one that was never written.
sql/30_leg_c_cortex.sql — the whole AI pipeline, in one statement.
app/warehouse.py — the entire live-versus-snapshot decision, in one module.
data/safe_cases_snapshot.csv — the published output, committed.

The data is synthetic. Sixty fabricated cases in data/synthetic_cases.csv. Using real casework to demo a privacy tool would have been its own answer to this challenge, and the wrong one.

How I Built It

The boundary is built in three layers, deliberately in that order, because each one has to stand up if the one above it isn't available. That turned out to matter more than I expected.

Layer 1 — the app is not allowed to ask. One grant, quoted above. Works on any Snowflake account, any edition, with every AI feature switched off. This is the whole thesis, and it is one GRANT statement away from being true on a free account.

The count without the contents. The app still needs to say "60 private records are held here," and it can, because PRIVATE_ROW_COUNT is a view. A view runs with its owner's rights, so the app learns how many, never who. The boundary is sized, not binary.

CREATE VIEW PRIVATE_ROW_COUNT AS SELECT COUNT(*) AS private_rows FROM RAW_CASES;
GRANT SELECT ON VIEW PRIVATE_ROW_COUNT TO ROLE CONSENT_APP;

Layer 2 — the engine answers differently depending on who asks. A masking policy would mean the same SELECT, run by a caseworker and by this app, returns two different truths, with no application code in the decision.

It didn't run. More on that in a second.

Layer 3 — Cortex AISQL reads the notes so no human has to. AI_REDACT for the boundary, AI_CLASSIFY for triage, AI_FILTER as a semantic WHERE, AI_AGG to write the brief across every row.

That was the plan. Here is what the account actually said.

The gate

Cortex AI functions need two grants, and only one exists by default:

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_USER TO ROLE SYSADMIN;  -- not granted by default
GRANT USE AI FUNCTIONS ON ACCOUNT TO ROLE SYSADMIN;          -- default: PUBLIC

I granted both, set cross-region inference to ANY_REGION, and probed every function before building on it. So nothing below is a missing grant.

Capability	Verdict	What the account said
Layer 1 role grants	✅	—
Layer 2 masking policy	❌	`Unsupported feature 'MASKING POLICY'.`
`AI_AGG`	✅	—
`AI_SUMMARIZE_AGG`	✅	—
`AI_REDACT`	❌	`AI function _AI_REDACT is not available for trial accounts.`
`AI_CLASSIFY`	❌	`AI function AI_CLASSIFY is not available for trial accounts.`
`AI_FILTER`	❌	`AI function _AI_FILTER_WITH_PROMPT is not available for trial accounts.`
`AI_EXTRACT`	❌	`AI function _AI_EXTRACT is not available for trial accounts.`
`AI_COMPLETE`	❌	`AI function _COMPLETE_WITH_PROMPT_HISTORY_LLM is not available for trial accounts.`
`SNOWFLAKE.CORTEX.SENTIMENT`	❌	`AI function SENTIMENT is not available for trial accounts.`

Nine of eleven, gone. Including the one the entire design was named after.

The grid I did not want to publish. Two of eleven, and the two are not a coincidence.

The two survivors are not random. Snowflake's docs say AI_AGG and AI_SUMMARIZE_AGG are the two functions that work with USE AI FUNCTIONS even without the CORTEX_USER role. Those are exactly the two that survived the trial gate.

The trial restriction and the role restriction draw the same line. Which makes the docs predictive: if a function is documented as needing CORTEX_USER, expect a trial account to refuse it. I have not seen that written down anywhere, and knowing it up front would have changed what I designed.

Rebuilding three functions out of one

AI_AGG is an aggregate. It takes a column and an instruction and reasons across the group.

So give it groups of one. GROUP BY a unique key and every group holds exactly one row, which turns an aggregate into a per-row LLM transform. And since the instruction is free text, one call can return all three things I lost:

SELECT case_id,
       AI_AGG(raw_note,
              'Return ONLY a JSON object with "redacted" (the note with every name '
           || 'replaced by [NAME], phone by [PHONE], email by [EMAIL], address by '
           || '[ADDRESS], reference by [REF]), "need" (food|housing|health|legal), '
           || '"unresolved" (true|false).') AS payload
FROM RAW_CASES
GROUP BY case_id;

AI_REDACT plus AI_CLASSIFY plus AI_FILTER, rebuilt from the one function a trial account is allowed to call, still running inside the warehouse, still never moving a note.

Sixty notes, redacted, classified and triaged in 24 seconds. All 60 returned parseable JSON. Zero rows held back.


Rows in / published	60 / 60
Cortex time, whole table	24s
Needs found	health 19 · legal 16 · food 13 · housing 12
Still unresolved	56 of 60
Phone numbers or emails surviving into the published set	0

The boundary didn't work

Then I ran the test that the entire project rests on. As the app's role, try to read the private table and get refused.

USE ROLE CONSENT_APP;
SELECT CURRENT_ROLE();                              -- CONSENT_APP
SELECT raw_note FROM CONSENT.APP.RAW_CASES LIMIT 1;

It returned the note. In full. Name, address, phone number.

USE ROLE sets your primary role. It drops nothing. Every other role the user holds stays active as a secondary role, and Snowflake authorizes against those too:

SELECT CURRENT_SECONDARY_ROLES();
-- {"roles":"ACCOUNTADMIN,ORGADMIN","value":"ALL"}

My own account was reading through the wall and reporting the correct role while it did it. One statement fixes it:

USE SECONDARY ROLES NONE;
SELECT raw_note FROM CONSENT.APP.RAW_CASES LIMIT 1;
-- SQL compilation error: Object 'CONSENT.APP.RAW_CASES' does not exist or not authorized.

The same query, twice, ten seconds apart. Nothing changed but the session's secondary roles.

The app now runs USE SECONDARY ROLES NONE on connect, and prints CURRENT_SECONDARY_ROLES() in the status panel so you can check it instead of trusting me. A boundary you have not watched refuse something is not a boundary. It is a diagram.

Rows that don't parse don't get published. TRY_PARSE_JSON returns null on garbage, and the insert filters those rows out rather than letting a half-redacted note through. A row held back is a row nobody sees. That is the correct failure direction for this tool.

Why Snowflake specifically, and not an LLM API behind my own server. If I call an API, the private text leaves the database to be understood, and I have rebuilt the exact problem I set out to solve. Cortex runs the model where the data already is. Remove the warehouse and there is no project.

What I refused to do

Do not let the app read the private table "just for the row count." Use a view.
Do not claim Layer 2 works. It didn't run here, and the file stays in the repo unrun.
Do not delete the failed functions from the README. A capability grid with no ❌ in it is marketing.
Do not demo a privacy tool on real casework.
Do not call this compliant.

One honest concession, since this is where a reader should get suspicious: this is a first pass that makes human review tractable, not a compliance guarantee, and I don't claim one. An LLM redactor generalises well and fails silently. The regex fallback in sql/35_redact_fallback.sql is cruder and fails loudly. I shipped both and made the app tell you which one produced the rows you're looking at. The point is to turn "nobody can look at this" into "one person can check this in an afternoon."

A second concession, now retired. For most of the build the live demo ran in snapshot mode, reading the pipeline's committed output rather than the warehouse. It now holds a real connection, as a service user granted exactly one role and nothing else, so the refusal in that left panel is one the app just performed rather than one it remembered. The banner tells you which mode you're in either way, because the honest version of this had to work before the impressive one did.

Prize Categories

Best Use of Snowflake.

What I Learned

The grants were harder than the redaction. Two of them, one not granted by default, and half-satisfying the pair produces an error indistinguishable from "your account is locked."
USE ROLE is not a boundary. It sets the primary role and leaves every other role you hold active. My least-privileged role read the private table while CURRENT_ROLE() reported the least-privileged role. The fix is one line. Finding it took running the test instead of assuming it.
Publish the error string. "Cortex is locked on trial accounts" is a rumour. Nine verbatim messages, each naming the internal function that refused, is a finding somebody else can act on. They're in the README.
A constraint you can name is a design input. Losing nine functions didn't cost me the project because the thesis was resting on a GRANT, not on a model.
AI_AGG with GROUP BY is a per-row transform. I have not seen this written anywhere and it quietly un-gates a lot of trial-account work.
The line I had to not write is the only line that makes the promise true. And the line I nearly didn't write, USE SECONDARY ROLES NONE, is the one that makes it enforceable.

Generosity in this challenge mostly got read as giving. This one is about the gift going the other way: sixty people gave a charity the worst week of their lives, on the understanding that it stayed private. Keeping that promise shouldn't cost them the proof that the help worked.

I wrote the privacy rule, enforced it, commented it, and shipped the leak anyway

Arqam Waheed — Sun, 23 Aug 2026 00:18:38 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories.

TL;DR. I wrote a scrubbing policy before writing any instrumentation code. I enforced it in a beforeSend hook. I unit tested it. I wrote a comment above the one obviously sensitive line saying exactly what it must never do. Then I intercepted the actual bytes leaving the browser and found a stranger's shoulder injury in them. Every guarantee I had written was about data my code hands to the SDK. None of them were about data the SDK collects on its own.

The setup

WhyRep is a workout tracker built local-first. Training data is created and read on the device, the tracker works offline with no account, and that is not a marketing line, it is the architecture. It is also the thing people decide to trust or not trust in about four seconds on the landing page.

So when I added Sentry, the scrubbing policy came before the code. Written down, in the repo, as a list of things that may never appear in an event: exercise names, weights, reps, RIR, session notes, chat content. Never.

On Android I enforced it twice. A beforeSend hook that strips the forbidden fields, and a unit test that constructs an event carrying each one and asserts it comes out stripped.

@Test
fun `beforeSend strips every field the policy forbids`() {
    val event = SentryEvent().apply {
        setExtra("exerciseName", "Incline Barbell Bench")
        setExtra("weightKg", 82.5)
        setExtra("notes", "left shoulder clicks past parallel")
    }

    val scrubbed = ScrubbingPolicy.scrub(event, Hint())

    assertNull(scrubbed?.getExtra("exerciseName"))
    assertNull(scrubbed?.getExtra("weightKg"))
    assertNull(scrubbed?.getExtra("notes"))
}

Green. Good.

Then I wired up the landing site's share-link page. It decodes whyrep.com/t#<payload>, where the payload is somebody's entire workout template, base64 in the URL fragment.

I was careful there too. On a decode failure it reports a coarse reason tag and never the payload:

// NEVER send the payload itself. A share link's fragment is the user's
// entire template: exercise names, weights, notes. Report the shape of
// the failure, not the contents.
Sentry.captureMessage("share_decode_failed", {
  tags: { reason: "bad_field_count" },
});

I wrote that comment because it was the obviously sensitive thing and I wanted the next person to see it before they "helpfully" added the payload for debugging.

Read the comment again. It is correct. It is well-reasoned. It describes exactly the right danger. And the leak happened six inches away from it.

What I missed

The payload is in the URL.

Sentry's browser SDK attaches location.href to every event, every transaction and every replay, by itself, as standard context. It is a completely reasonable default. It is the single most useful piece of context a browser error can carry.

And the fragment goes with it.

Every guarantee I had written was about data my code passes to Sentry. None of them were about data the SDK collects on its own. Those are two different data paths and I had only ever thought about one of them.

I only found it because I stopped reading my own code and intercepted the actual bytes leaving the browser. A Puppeteer test that grabs the outbound envelope body and greps it for known-sensitive strings:

page.on("request", (req) => {
  const url = req.url();
  if (!url.includes("sentry.io")) return;
  const body = req.postData() ?? "";
  for (const needle of FORBIDDEN) {
    if (body.includes(needle)) {
      throw new Error(`leaked ${needle} in outbound Sentry envelope`);
    }
  }
});

It failed on the first run.

Decoded, the intercepted request contained Push Day A, Incline Barbell Bench, and a note reading left shoulder clicks past parallel.

Base64 is not encryption. That is a lifter's shoulder injury, in a third-party service, from a page whose privacy policy said the site had no third-party trackers.

Both panels are the same request. The top one is the only part my policy had an opinion about.

Then the same grep found a second one

Once the interceptor existed I pointed it at the rest of the site, which is how I found the one I would not have gone looking for.

The waitlist dedupes signups by using the email address as the Firestore document id. That is a defensible design. It also puts the email in the request path:

POST /v1/projects/whyrep/databases/(default)/documents/waitlist?documentId=someone@example.com

Sentry's automatic fetch breadcrumb records request URLs verbatim.

So every waitlist signup email would have been attached to any error that happened afterwards in that session. Not an event I sent. A breadcrumb the SDK collected, riding along on somebody else's unrelated exception.

And that one is worse than the first, for a reason worth naming. The template in the fragment is the user's own data, shared by the user, from a page they opened deliberately. The waitlist email is a third party's data, collected in confidence, leaking through a mechanism that has nothing to do with the feature it was collected for.

Not my data. Other people's.

The fix

It is unglamorous, which is fine. Three hooks:

Sentry.init({
  dsn: DSN,

  beforeSend(event) {
    return stripUrl(event);
  },

  beforeSendTransaction(event) {
    return stripUrl(event);
  },

  beforeBreadcrumb(crumb) {
    if (crumb.data?.url) {
      crumb.data.url = bare(crumb.data.url);
    }
    return crumb;
  },
});

/** Keep origin and pathname. Drop search and hash, always, everywhere. */
function bare(href) {
  try {
    const u = new URL(href);
    return u.origin + u.pathname;
  } catch {
    return "[unparseable]";
  }
}

All three are needed and that is the part I would underline. Errors, performance data and breadcrumbs take three different paths out of the SDK. beforeSend only sees the first one. I had reached for it instinctively because it is the hook everybody knows, and it would have fixed the error case and left both of the others wide open.

A privacy control that covers one of three exits is not a privacy control. It is a privacy control on the exit you happened to think of.

Here is what I refused to do while fixing it:

Do not put the payload in the query string instead. Same problem, different letter.
Do not disable breadcrumbs wholesale. They are how you debug the errors you do get.
Do not rely on sendDefaultPii: false. It governs what Sentry considers PII, not what my URLs happen to contain.
Do not mark this fixed on the basis of reading the diff. Re-run the interceptor.

That last one is the only one that actually proved anything. The interceptor now runs in CI, and I confirmed it goes red against the pre-fix code before I trusted it green against the fixed code.

The hook everybody reaches for covers the exit everybody thinks of. The other two ship enabled by default.

What I take from it

A privacy guarantee enforced at your call sites is a guarantee about your call sites. The SDK has its own opinions about what is worth collecting, and they are usually reasonable ones, written by people who did not know your URL fragment was the payload. Their defaults are good defaults for the average app. You are not the average app in exactly the places you care about.

The comment was the problem, not the protection. I had written a correct, specific warning above the sensitive line, and it made me feel covered. A warning above line 40 does nothing about line 46, and it did something worse than nothing, because it made the area feel handled. I have started to distrust the feeling of having already thought about a thing.

There is one test that actually tests "this data never leaves." Catch the bytes on the way out and search them for the data. Not reading the code. Not reviewing the diff. Not trusting the comment, and especially not trusting the comment when you are the one who wrote it. Every other check is a check on your model of the system.

Two of the three leaks were in code I never wrote. That is the general shape and it keeps showing up in this project. The manifest merger adds providers to your app. The SDK adds context to your events. The Firestore client puts your document id in a URL. Your source file is not the boundary of your program, and the review that only reads your source is only reviewing part of it.

The honest framing, said plainly rather than buried: this was caught in review, before any deploy. Nobody's data ever actually reached Sentry. There was no breach, there is nothing to disclose, and I am not writing this as an incident report. The story is the class of mistake, which I think is common, and the verification technique, which I think is underused.

If it had shipped, I would not have found out from Sentry. The events would have looked perfectly healthy. That is the thing about this category of bug: the leak and the correct behaviour produce identical telemetry.

So, a real question, because I do not have a good answer.

I now have an interceptor that greps outbound envelopes for a list of known-forbidden strings. It works, and it caught two real leaks. It is also a denylist, and denylists only catch what you thought to list. My FORBIDDEN array has nine entries in it and there is no principled reason it has nine rather than ninety.

Has anyone built the allowlist version of this? Something that fails when an outbound envelope contains any field that is not explicitly permitted, rather than one that is explicitly banned? I can picture it for a fixed schema. I cannot picture it for location.href.

WhyRep is in closed testing on Play and launches in September.

My performance optimization silently disabled the feature the app exists for

Arqam Waheed — Sun, 23 Aug 2026 00:14:15 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories.

TL;DR. I bounded a database read to make my analyzer faster. I derived the bound carefully, wrote the reasoning into the KDoc, and shipped it behind five passing tests. The bound was wrong in a way none of those tests could see. The result: if a lifter deloaded once in the middle of a stall, which is the correct thing for a lifter to do, my app stopped telling them they had plateaued. No crash. No error. No log line. The feature just quietly stopped being true for the people using the app correctly.

The setup

WhyRep analyzes your training rather than just recording it. The core promise is that it tells you when you have stalled and what to change about it, and that every verdict traces back to a methodology document rather than to something a language model made up.

The architecture decision underneath that promise is that nothing is precomputed. Verdicts are derived from raw set logs on read, every time, so there is no cached judgement to go stale when the rules change.

Which means every read walked the lifter's entire history for every exercise in the session. That is fine at ten sessions. It is not fine at three hundred.

The obvious optimization is to bound the read. The obvious bound is "it only needs the last two weeks."

That was my first wrong answer, and it is worth thirty seconds before I get to the interesting one.

The plateau rules are not measured in calendar time. They are consecutive-miss counts, and the count varies by lifter tier and by whether the movement is a big or small joint action. The widest window in the signed methodology is an elite lifter on a small joint action: 14 consecutive sessions without progress. Train a lateral raise once a week and 14 sessions is over three months of data.

A 14-day cutoff could never have fired a plateau for anyone above beginner tier. It would not have thrown. It would have quietly stopped detecting the exact thing the product exists to detect.

The unit was wrong, not the number.

So I threw that out and derived a real bound from the rules table instead. That is where the actual story starts.

The bound I was proud of

Here is the reasoning, and I want you to notice that it is not sloppy. I wrote this out before writing the code:

The widest plateau window is 14 consecutive misses.
ProgressionEngine rebuilds its baseline from a single session. Nothing accumulates across sessions, so only the miss streak needs historical depth.
The oldest row in a truncated window gets consumed as a fresh baseline and therefore cannot itself count as a miss.
Therefore maxWindow + 2 rows is sufficient. Exact, even.

I put that reasoning in the KDoc so the next person would not have to rederive it. I wrote five tests. All five passed. I shipped it.

/**
 * Rows to load for analysis.
 *
 * The widest plateau window is [PlateauWindows.MAX] consecutive misses. The
 * oldest row in a truncated window is consumed as a fresh baseline and cannot
 * count as a miss, so one spare row covers it. One more for safety.
 */
private const val ANALYSIS_ROW_BUDGET = PlateauWindows.MAX + 2

Read that comment again. It is confident, it is specific, it cites the right constant, and it is wrong.

Why it was wrong

consecutiveMisses does not skip only the first no-verdict session.

It skips every no-verdict session, and it does not reset the streak when it does. That behaviour is correct and deliberate. A session that produces no verdict is not evidence of progress and it is not evidence of a miss, so it should neither break the streak nor extend it. It should be transparent.

But transparent to the streak is not transparent to the row budget. Every skipped session still consumes a row.

And ProgressionEngine emits NO_VERDICT on four entirely ordinary paths:

a flagged deload
a weight change without earned overload
a rep-range change
a variant change

Every one of those eats a row from the budget while contributing nothing to the count.

I had budgeted exactly one spare row. There is no bound on how many are needed.

Step 3 of my reasoning was true. Step 4 assumed step 3 was the only case, and I never wrote down that assumption, so I never checked it.

Where the streak went. The deload consumed a row and contributed no miss, and the two rows that would have completed the streak fell off the end of the window.

What it costs a real lifter

I verified it rather than reasoning about it, because I had just learned what my reasoning was worth.

Setup: an ELITE-tier lifter, barbell curl, 40 weekly sessions, every one of them stalled at 30 kg for 8 reps. A textbook plateau, forty weeks long, impossible to miss.

	streak	plateau fired
control	15	yes
one deload at session 34	13	no

One deload. In the middle of a forty-week stall. And the app stops saying the word "plateau."

Sit with the shape of that for a second, because it is worse than it first looks. Deloading during a stall is the correct thing to do. It is what a good lifter does, it is what my own app's coaching would tell them to do, and it is the single behaviour most likely to appear in the history of exactly the user who needs the plateau verdict most.

The MAJOR severity chip disappears. The documented rep-range fix disappears. The screen renders perfectly. It says nothing is wrong.

No crash. No error. No log line. Nothing to report, nothing to alert on, and nothing a user could file a bug about, because the app has no visible failure. It just quietly becomes a worse app for the people using it best.

This is a P0 coaching-logic regression introduced by a performance change. That is the category of change that was supposed to be safe.

The fix

The bound cannot be a constant.

That is the whole insight and it took me longer than I would like to get to it. The thing being counted (misses) and the thing being limited (rows) are not the same quantity, and no fixed ratio relates them. You cannot pick a number. Any number I pick is a number some sequence of deloads exceeds.

So loadForAnalysis starts at the nominal window and widens until the answer is provably settled:

private suspend fun loadForAnalysis(exerciseId: Long): List<SessionRow> {
    var budget = PlateauWindows.MAX + 2
    while (true) {
        val rows = dao.recentRows(exerciseId, budget)

        // Settled if any of these hold:
        //  1. we reached the start of history, so there is nothing older
        //  2. the window contains a PROGRESS verdict, which resets the streak,
        //     so nothing older can affect the answer
        //  3. the streak already meets the widest window, so it cannot grow
        //     into a different verdict
        if (rows.size < budget) return rows
        if (rows.any { it.verdict == PROGRESS }) return rows
        if (consecutiveMisses(rows) >= PlateauWindows.MAX) return rows

        budget *= 2
    }
}

Three termination conditions, each of them a proof that older rows cannot change the answer. Not a heuristic, and not a bigger constant.

The common case still settles on the first query. A lifter who is progressing hits condition 2 immediately, because a PROGRESS verdict is in the recent window by definition. The loop only widens for someone in a long unbroken stall, which is the exact population whose answer is worth paying an extra query for.

The test that guards it is named after the scenario rather than the mechanism:

AnalysisWindowTest > a deload inside a long stall must not hide the plateau

I checked that it fails against the old constant before I trusted it. It does.

Three exits, each one a proof that nothing older can change the verdict. The loop is not a retry, it is a search for sufficiency.

What I take from it

A performance change that preserves most behaviour is not a performance change. It is a behaviour change with a performance benefit, and it deserves the review a behaviour change gets. I had filed this work mentally under "optimization" and optimizations feel safe, so it got the review that optimizations get. The category was the mistake before the code was.

My tests passed because I wrote tests for the reasoning I had. This is the one that bothers me most, because there is no amount of discipline that fixes it directly. Five tests, all genuine, all passing, all derived from the same four-step argument that contained the hole. Tests written from your model of the system cannot find the part of the system your model is missing. They can only confirm the model.

Write down the assumption, not just the conclusion. My KDoc said "the oldest row is consumed as a baseline, so one spare covers it." What it did not say was "and that is the only reason a loaded row might not count." The moment you write that second sentence down you can see it is a claim, and a claim you can see is a claim you can check. I had done the thinking and recorded only the output of it.

Silent correctness regressions have no reporting surface. I have Sentry across three projects in this app now and it would not have caught this. There is no exception, no slow span, no failed request. A verdict that should have fired and did not produces exactly the same telemetry as a verdict that correctly did not fire. If your product's core value is a judgement call, your observability stack cannot see your core value.

The honest note on how this was found, since I would rather say it than imply otherwise: an automated review of my own pull request caught it. Not Sentry, not a user, not a test. Something else read the diff and asked why the spare was one and not two. It was right to ask.

Here is what I have not solved, and I would take suggestions.

I now have a test for this specific scenario. I do not have a general way to catch the class. A test suite can prove my analyzer does the right thing on the histories I thought of, and this bug lived entirely in a history I had not thought of.

Property-based testing over generated training histories is the obvious answer and I have not built it, mostly because writing a generator that produces plausible training histories is its own hard problem. Random ones would pass trivially. Realistic ones need the domain model I am trying to test.

If you have solved that circle for a domain of your own, I would genuinely like to hear how.

WhyRep is in closed testing on Play and launches in September.

I installed a crash reporter and it crashed my app 100% of the time

Arqam Waheed — Sun, 23 Aug 2026 00:11:01 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories.

TL;DR. I wired Sentry into my Android app behind a careful guard so that a build with no DSN behaves exactly as if the SDK were absent. I reviewed it. I built it both ways. Both green. Then I put the APK on a phone and it died on launch, every time, before a single line of my code ran. The guard was real code that was never reached, because a dependency had quietly added a ContentProvider to my manifest. The fix is one line. The reason I could not have caught it is the story.

The setup

I was adding Sentry to WhyRep, a workout tracker I am building solo. The app is native Kotlin and Compose on Android, with about 10,000 lines in the app module, and until that week it had no error reporting at all.

I made one design choice I was pleased with. The SDK would be DSN-gated:

// WhyRepApplication.kt
override fun onCreate() {
    super.onCreate()
    if (BuildConfig.SENTRY_DSN.isNotBlank()) {
        SentryAndroid.init(this) { options ->
            options.dsn = BuildConfig.SENTRY_DSN
            options.beforeSend = ScrubbingPolicy::scrub
            // ...
        }
    }
}

The DSN comes from a gitignored local.properties. No DSN, no init, and the app behaves exactly as it would with no Sentry dependency compiled in. Anyone can clone this repo without a Sentry account and build it and run it.

I liked that. I wrote the guarantee in a comment above the block so nobody would delete it later.

Then, the same day, I reviewed my own work and confirmed it. Built with a DSN: green. Built with a blank DSN: green. ./gradlew test: green. The iOS cross-compile: green.

DSN-gating verified. I wrote that down.

Then I put the release APK on my phone and it died on launch.

java.lang.RuntimeException: Unable to get provider
io.sentry.android.core.SentryInitProvider:
java.lang.IllegalArgumentException: DSN is required. Use empty string
or set enabled to false in SentryOptions to disable SDK.
  at android.app.ActivityThread.installProvider(ActivityThread.java:9157)
  ...
  at io.sentry.android.core.SentryInitProvider.onCreate(SentryInitProvider.java:27)

Not a slow start. Not a degraded mode. A hundred percent crash on launch, on a real device, immediately after install.

The only report that existed. A crash reporter cannot report the crash that is its own startup.

What I missed

sentry-android-core ships its own AndroidManifest.xml. Inside it:

<provider android:name="io.sentry.android.core.SentryInitProvider"
          android:authorities="${applicationId}.SentryInitProvider" />

The Android manifest merger folds that into your manifest at build time. I confirmed it in the merged output rather than assuming, because by this point I did not trust anything I had not looked at:

app/build/intermediates/merged_manifest/release/AndroidManifest.xml

There it was. A provider I never wrote, in a manifest I thought I owned.

And ContentProviders are installed before Application.onCreate() runs.

So Sentry initializes itself, from a DSN it expects to find in manifest meta-data, before my Application class exists. Disassembling the shipped 8.50.1 class shows SentryInitProvider.onCreate gated only on ManifestMetadataReader.isAutoInit(context, logger), which defaults to true when the meta-data is absent, and then calling SentryAndroid.init with no options lambda. That reads the DSN from io.sentry.dsn manifest meta-data. My project deliberately does not set it, because the DSN comes from local.properties through BuildConfig.

So Sentry.preInitConfigurations threw. Inside a ContentProvider. During process startup.

My careful if (BuildConfig.SENTRY_DSN.isNotBlank()) guard was correct, well-commented, and had never once been in force.

The whole design was right. It simply never got a turn.

The part that actually stings

Here is the thing I keep coming back to. Every check this project has was structurally incapable of catching it.

Check	Result with DSN	Result without DSN
`assembleDebug`	green	green
`assembleRelease`	green	green
`./gradlew test`	green	green
`:shared:compileKotlinIosArm64`	green	green

Look at what those four have in common. None of them installs an APK. None of them starts a process. None of them instantiates a ContentProvider. They compile code and they run JVM unit tests, and the bug lives in a phase that happens after compilation and before my code.

I had verified "builds with no DSN" and I had written down "DSN-gating verified."

Those are two different sentences. I had let them become one.

And the part that stings past that: a few hours earlier, in this same integration, I had caught two privacy leaks precisely because I stopped trusting my own code and intercepted the actual bytes leaving the browser. I found a lifter's shoulder injury note in an outbound request payload. I wrote up the lesson. I put it in a runbook, in this repo, in writing.

Then I turned to the Android side and verified it by compiling it.

The lesson did not transfer, and it did not transfer because I filed it under "web" instead of under "verification."

The fix

One line.

<!--
  Load-bearing. sentry-android-core ships a <provider> that the manifest merger
  folds into this file, and ContentProviders run before Application.onCreate.
  Without this line the SDK auto-inits from manifest meta-data (default true),
  finds no io.sentry.dsn, and throws inside process startup. The DSN-gating in
  WhyRepApplication.kt is unreachable until this is here.
  Do not delete this because it looks like dead config.
-->
<meta-data android:name="io.sentry.auto-init" android:value="false" />

The comment is six times longer than the line, on purpose. The line looks deletable and is not.

I considered the alternative, which is setting io.sentry.dsn in the manifest and letting auto-init do the work. I rejected it for three reasons: it moves the DSN into a checked-in file, it gives up the beforeSend and beforeBreadcrumb scrubbing hooks that my PII policy depends on, and it removes the DSN-absent no-op that lets a contributor build this repo without a Sentry account.

That last one was the whole point of the design. Fixing the bug by deleting the feature is not fixing the bug.

The verification, done properly this time

Not a build. An install.

I pushed the release variant, the exact flow that produced the crash, onto the same physical device:

Check	Before	After
`pidof com.whyrep.app` after launch	(empty, process dead)	`5771`
`adb logcat -b crash`	`RuntimeException: Unable to get provider`	(empty)
`dumpsys activity` topResumedActivity	(none)	`com.whyrep.app/.MainActivity`
`uiautomator dump` screen text	(none)	`"Know why, not just what"`, `"Continue"`

That last row is the one I care about. pidof returning a number tells you a process exists. uiautomator dump reading my actual onboarding copy back off the screen tells you the app is running and rendering the thing it was supposed to render.

A process that exists is not the same claim as an app that started.

The guard was in the right file and the wrong phase. Compilation cannot observe anything to the right of station one.

What I take from it

A dependency can add code to your app's startup without appearing anywhere in your source. The manifest merger is a build step that runs on other people's XML. Nothing in your Kotlin will ever remind you that it happened. If you want to know what is in your manifest, read the merged one in build/intermediates, not the one you wrote.

An initialization guard is a claim about ordering, and compiling proves nothing about ordering. This is the general version and it is the one I would put on a wall. Type checking answers "is this code valid." It has no opinion on "does this code run, and when, relative to what."

"Verified" needs an object. I verified compilation. I recorded it as having verified gating. The gap between those two sentences is where this bug lived for a day. Now I try to write verification claims with the method attached: not "DSN-gating verified" but "DSN-gating verified by installing the release APK with a blank DSN and reading the onboarding text off the screen." It is uglier and it cannot lie as easily.

And the obvious one, said out loud rather than hoped past: Sentry could not possibly have caught this. The process died inside Sentry's own initialization. The tool cannot instrument its own birth, and no amount of observability budget changes that. There is exactly one way to test whether an app starts, which is to start it.

An honest note on blast radius, because I would rather say it than have you wonder: this was caught by dogfooding, on a build only I had, before any release. Nobody else was ever affected. The story is the class of mistake, not an outage.

I still do not have an automated guard for this one. Catching it requires installing an APK on a device or emulator and my CI does not do that. A cheap partial guard would be asserting on the merged manifest at build time. The full guard is an instrumentation test that launches the app with no DSN set. It is written down as a real gap rather than quietly closed, because a gap I have named is less dangerous than a green check I have not earned.

So here is the question I would actually like answered.

How many of your dependencies are running code before your Application.onCreate? I did not know the number for my own app until it crashed. If you use WorkManager, Firebase, Sentry, LeakCanary, or anything from Jetpack Startup, the number is not zero.

Go read your merged manifest. I will wait.

Eleven tables, zero indices, and the observability I added afterwards found three more bugs

Arqam Waheed — Sun, 23 Aug 2026 00:08:10 +0000

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

TL;DR. My app recomputes every coaching verdict from raw training logs on read. With a five-year history that took 119.1 ms per session, because eleven Room entities had zero indices between them. Adding indices took it to 6.8 ms, a 17.4x improvement, and one query got no faster at all. Then I instrumented the thing properly and Sentry found three bugs I did not know about, including one where Sentry had been silently discarding every trace I sent it. Zero accepted. Five invalid.

What I Built

I built WhyRep, a workout tracker that analyzes your training instead of just recording it. Log a session, get a verdict with a traceable reason: you are progressing, you have stalled, this is what to change. Every coaching decision traces back to a methodology document I signed off on, not to something a model invented in the moment.

The architecture choice that matters for this post is that nothing is precomputed. Verdicts are derived from raw set logs on read, every time. That keeps the coaching logic honest, because there is no cached judgement to go stale when the rules change. It also means every read walks the history.

Android is native Kotlin and Jetpack Compose. iOS is SwiftUI over a shared Kotlin Multiplatform core, so the engines have one implementation across both platforms. Storage is Room, local-first, and the tracker works offline with no account. The coach runs through a 235-line dependency-free Cloudflare Worker that holds the model key so it never ships in the APK.

Roughly 10,000 lines of Kotlin in the app module. Eleven Room entities. An 847-exercise catalog.

And, until the work in this post, no observability of any kind. No error reporting. No performance data. The Worker's top-level handler was console.error(e) followed by a generic 500, which in production means nothing is recorded anywhere.

I want to be precise about the order of events, because it matters for how you read the rest of this. The performance work came first and I found it by reading code, not by using Sentry. Sentry did not exist in this project yet. What Sentry found is a separate section, further down, and those are different bugs.

How Sentry got in

This is the first of four posts about that fortnight, so it is worth saying what the instrumentation actually is before I start quoting it at you. Three Sentry projects went in: the Android app, the Cloudflare Worker, and the landing site. All three were wired from nothing, and every finding in this series came out of that window.

The Android app uses the official SDK, gated on the DSN. SentryAndroid.init runs only if BuildConfig.SENTRY_DSN is non-blank, so a contributor can clone this repo with no Sentry account and the app behaves as though the dependency is not there. Making that guarantee actually true cost me a day and a 100% crash rate, which is post two.

The Worker could not use the SDK at all. Its deploy story is "paste one dependency-free file into the Cloudflare dashboard", and I was not giving that up for an npm install. So it speaks to Sentry's envelope endpoint through about 150 lines I wrote by hand: captureException, transaction and span envelopes, trace_id and parent_span_id threaded through from the app. Writing a protocol client instead of installing one is how I found the bug in section 5.

The coach call is traced as an AI span, not as a fetch. gen_ai.chat carries the model, and alongside it gen_ai.usage.input_tokens, output_tokens, cache_read_input_tokens, cache_creation_input_tokens, stop_reason, latency_ms, and a computed cost_usd. Around it sit auth.jwt, kv.get for the entitlement lookup and kv.rate_limit for the daily cap. One trace covers a tap on an Android phone, a Clerk JWT verified at the edge, two KV reads, and a Claude call, with the token and cache accounting sitting on the model span.

Nothing carrying training data leaves the device. sendDefaultPii is false everywhere. The Android beforeSend strips exercise names, weights, reps, RIR and notes. The landing site strips the URL fragment and the query string in beforeSend, beforeSendTransaction and beforeBreadcrumb, which is post four, and which I got wrong the first time.

Session Replay runs on the landing site only, and it is deliberately timid. maskAllText: true, blockAllMedia: true, replaysSessionSampleRate: 0.01, replaysOnErrorSampleRate: 1.0. I do not want a recording of every visitor. I want the one session where something broke.

The honest framing, once, up front: WhyRep is pre-release. The traffic behind every number in this series is my own device plus twelve closed testers, and I say so again each time it matters.

Bug Fix or Performance Improvement

The analyzer read path had four independent defects on it. I found them during a performance pass on 2026-07-25, reading the code that answers the question "how did this session go."

B3, the headline: eleven entities, zero indices. Every relation fetch full scanned set_logs, which is the table holding every set the lifter has ever performed. It is the largest table in the schema by a wide margin and it is the one on the hot path. This is invisible on a fresh install and gets worse every month, which means it punishes the most committed users first. That is exactly the wrong population to punish in a training app.

B1: reorderExercises wrote one row at a time. WorkoutRepository.kt:143 and :316 issued one UPDATE per row with no enclosing transaction. Finishing a 30-set workout was roughly 30 separate commits.

B2: cold start hydrated the entire catalog. seedIfEmpty at WorkoutRepository.kt:99 materialized all 847 catalog entities on every launch, purely to build a set of name and equipment pairs it then threw away.

B4: search allocated a string per row per keystroke. Three call sites built a joined lowercase string for every one of 847 exercises, on every keypress.

The interesting one is B3, and the interesting part of B3 is not the index. Everybody knows to add an index. The interesting part is the trap I nearly walked into while adding it.

The read path, before and after. The analyzer recomputes every verdict from raw logs, so the scan was not a corner case, it was the main case.

Code

Here is the migration. The repo is private, so this post carries the diffs inline, which the rules explicitly allow.

// Db.kt, MIGRATION_11_12
database.execSQL(
    "CREATE INDEX IF NOT EXISTS `index_set_logs_exerciseLogId` " +
    "ON `set_logs` (`exerciseLogId`)"
)
database.execSQL(
    "CREATE INDEX IF NOT EXISTS `index_exercise_logs_sessionId` " +
    "ON `exercise_logs` (`sessionId`)"
)
// ...seven tables in total

And the corresponding entity annotation:

@Entity(
    tableName = "set_logs",
    indices = [Index(value = ["exerciseLogId"])],
    // ...
)

Now the trap, which is the part worth stealing. Room builds a fresh install from the @Entity annotations and an upgrade from the migration's raw SQL. Those are two independent sources of truth describing the same schema, and nothing in the framework checks them against each other at compile time.

Name that index index_set_logs_exerciseLogId in one place and anything else in the other, and you get the worst possible failure shape. Every new install works perfectly. Every existing install crashes on open with a schema validation error. You will not see it in development, because your development database gets recreated constantly.

It is a bug that only fires for users who already trust you.

So the test does not go on the annotation, and it does not go on the migration. It goes between them:

@Test
fun `migration produces the index names the annotations expect`() {
    val migrated = helper.runMigrationsAndValidate(TEST_DB, 12, true, MIGRATION_11_12)
    val names = migrated.query(
        "SELECT name FROM sqlite_master WHERE type='index' AND tbl_name='set_logs'"
    ).use { c -> generateSequence { if (c.moveToNext()) c.getString(0) else null }.toList() }

    assertTrue("index_set_logs_exerciseLogId" in names)
}

@Test
fun `the planner actually uses the index`() {
    val plan = db.query("EXPLAIN QUERY PLAN SELECT * FROM set_logs WHERE exerciseLogId = ?", arrayOf(1))
        .use { c -> c.moveToFirst(); c.getString(c.getColumnIndexOrThrow("detail")) }

    assertTrue(plan.contains("USING INDEX index_set_logs_exerciseLogId"))
}

The second test is the one I would not skip. Asserting an index exists proves you created an object. Asserting EXPLAIN QUERY PLAN names it proves the planner reaches for it, which is the thing you actually wanted. Those are not the same claim and I have written code where only the first one was true.

The lesson generalises past Room. When a framework generates the same artefact from two sources, the test belongs between the two sources, not on either one.

My Improvements

Measured on 2026-07-25 with PerformanceBenchmark.kt, run as:

./gradlew :app:testDebugUnitTest --tests '*PerformanceBenchmark*' -Dbenchmark=1

Measurement	Before	After	Change
Analyze one session, 300-session history	119.1 ms	6.8 ms	17.4x
20 keystrokes over 847 exercises	4.2 ms	566 us	7.5x
Mark 20 sets complete	2.4 ms	342 us	7.1x
Cold-start catalog identity check	2.8 ms	908 us	3.1x
Load the full history list	10.7 ms	11.4 ms	no measurable change

The methodology, in full, because the numbers are worthless without it. The dataset is synthetic: 300 sessions by 5 exercises by 4 sets, which is 6,000 set rows and roughly a five-year training history. Measured on the JVM under Robolectric, not on a device. These are fair relative comparisons of two implementations against the same seeded database in the same process. They are not phone timings and I am not presenting them as phone timings. Median of 15 runs after 5 warmups, median rather than mean so one GC pause cannot move the figure. Where the old code no longer exists, the benchmark reimplements it inline so both sides run under identical conditions. The index rows are measured by dropping and recreating the real v12 indices on the same data.

The last row is the honest one and it stays in. Indices made no measurable difference to loading the full history list. That is correct, not a measurement error. That query returns nearly every row of sessions, so SQLite scans regardless and an index cannot help. Indices pay off on selective lookups, which is where the 17.4x came from.

I could have reported only the flattering row. A table with one negative result in it is more trustworthy than a table without one, and I would rather you believed the 17.4x.

Here is what I refused to do while fixing this:

Do not quote a device number I measured on the JVM.
Do not drop the row that did not improve.
Do not present a synthetic history as real user data.
Do not assert an index exists and call that a performance test.

Best Use of Sentry

Everything above was found by reading code. Sentry found different bugs, and this section is only about those. I am keeping the line hard because a submission that blurs it is not worth reading.

I wired Sentry into three projects: the Android app, the Cloudflare Worker, and the static landing site. The Worker could not use the official SDK, because its deploy story is "paste one dependency-free file into the Cloudflare dashboard" and I was not giving that up. So the Worker talks to Sentry's envelope endpoint through about 150 lines I wrote by hand.

That decision is how the first bug happened.

1. Sentry told me it was throwing away everything I sent it. Through a usage counter.

Found by: Settings, then Stats and Usage. Not an issue. Not an alert. Not Seer.

The Worker deployed clean. /health returned {"ok":true}. /chat correctly returned {"error":"unauthenticated"} on a bare request. wrangler tail showed outcome: ok with zero exceptions. Sentry's Traces view said "Waiting for this project's first trace."

Every one of those is exactly what a healthy Worker with no traffic looks like. That is the problem. I had sent it traffic.

The only place the truth appeared was a counter on a settings page:

Project	Total	Accepted	Filtered	Rate Limited	Invalid
coach-worker	5	0	0	0	5
android	3	3	0	0	0

33 requests at a 0.2 sample rate produced 5 sampled transactions, which is the sampler working correctly. All 5 were rejected. The android row on the same screen, using the official SDK, accepted 3 of 3. That comparison is what made it a payload bug rather than a DSN, network, or config bug.

Root cause: one id generator doing two jobs.

function uuid() {
  return crypto.randomUUID().replace(/-/g, "");   // 32 hex chars
}

32 hex characters is correct for event_id and correct for trace_id. It is wrong for a span id. A Sentry trace id is 16 bytes and a span id is 8, exactly as in W3C trace-context where parent-id is 16 hex characters. I was calling uuid() at three span-id sites, and Relay discards a transaction whose span id is the wrong width.

Why it survived to production. Ingest accepts the envelope and answers 200. The rejection happens later, inside Relay, after the Worker's request is long over. So it cannot appear in the response, in ctx.waitUntil, in wrangler tail, or in the issue stream. My send() even has a .catch() that logs sentry send failed. It never fired, because the send genuinely succeeded.

The fix separates the widths and makes the distinction impossible to un-learn:

/** 32 hex chars. Correct for `event_id` and `trace_id`, and WRONG for a span id. */
function uuid() {
  return crypto.randomUUID().replace(/-/g, "");
}

/**
 * 16 hex chars, which is what a Sentry span id is: 8 bytes, the same width as
 * W3C trace-context's `parent-id`. A trace id is 16 bytes and a span id is 8,
 * and they are NOT interchangeable.
 */
function spanId() {
  return crypto.randomUUID().replace(/-/g, "").slice(0, 16);
}

I considered a single id(bytes) helper taking a width argument and rejected it. A call site reading id(8) still lets someone pass the wrong number. spanId() has no argument to get wrong.

Metric	Before	After
Transactions accepted	0	8
Rejected as Invalid	5 (100%)	0
Traces view	"Waiting for this project's first trace"	8 spans, all `POST /chat`

The guard is scripts/check-sentry-ids.mjs, six checks, running in CI. I verified it goes red before trusting it: reverting the three spanId() calls fails 2 of 6 with span_id is 16 lowercase hex chars: got 32 chars. It carries a behavioural check and a static one, because the behavioural check alone only covers startSpan, and two of the three original offenders minted their ids inline.

The deeper cause is not the character class. backend/coach-worker/ had no tests and no CI workflow at all. A hand-rolled protocol client with no test against the protocol is the actual defect. The workflow landed in the same commit, because adding a guard without adding the thing that runs it recreates the exact conditions that let this live.

The failure lives past the 200. That is why no signal on the Worker side could ever have shown it, and why a usage counter could.

2. Performance Issues found a database open on the main thread. It sat unread for thirteen days.

Found by: Sentry's "DB on Main Thread" detector, on the MainActivity ui.load transaction. Issue ANDROID-1, 16 events, 1 user.

DB on Main Thread
INSERT OR IGNORE INTO room_table_modification_log VALUES(1, 0)
transaction: MainActivity · start_type: cold · ui.load 6.43s

AppViewModel registered an invalidation observer from an init block:

init {
    db.invalidationTracker.addObserver(cacheInvalidator)
}

That reads like bookkeeping. Hand Room an object, get told when tables change. It is not bookkeeping. Decompiled from room-runtime 2.8.4 rather than recalled:

9:  invokespecial addObserverOnly:(InvalidationTracker$Observer;)Z
29: invokestatic  RunBlockingUninterruptible_androidKt.runBlockingUninterruptible:(...)

It blocks the calling thread, uninterruptibly, to sync the invalidation triggers. Syncing opens the database if it is not open and writes one row per observed table. A ViewModel is constructed on the main thread, so every cold start paid a database open plus four writes in front of the first frame.

Why it hid for thirteen days. It throws nothing, so it is a performance issue rather than an error and never triggered an alert. Sentry filed it Low, under two High items. And the API that causes it has a signature promising nothing about blocking, so it survived a code review that had already been over this exact file for the index work above.

The fix moves registration to Dispatchers.IO, and because that makes registration asynchronous, it keeps removal ordered behind it:

internal class TableObserverRegistration(
    dispatcher: CoroutineDispatcher = Dispatchers.IO,
    private val register: () -> Unit,
    private val unregister: () -> Unit,
) {
    private val scope = CoroutineScope(SupervisorJob() + dispatcher)
    private val registered: Job = scope.launch { register() }

    fun dispose() {
        scope.launch {
            registered.join()
            unregister()
        }.invokeOnCompletion { scope.cancel() }
    }
}

Two things a bare viewModelScope.launch { } would have got wrong, which is why this is a class and not one line. First, viewModelScope cannot own the removal, because onCleared runs after that scope is cancelled, so a removal launched there never executes and the observer leaks for the life of the process. Second, once registration is asynchronous the pair can invert: a ViewModel cleared quickly by rotation or a fast back-out reaches dispose() while registration is still in flight, and a removeObserver that overtakes its own addObserver silently does nothing and leaks identically. registered.join() is what holds the order regardless of interleaving.

The honest caveat on impact. The win is a main-thread-blocking removal, not a measured millisecond count. Sentry's detector reports that the span ran on the main thread, not how long it took. I am not quoting a cold-start delta this fix has not measured.

There is a second honest note here, about my own test. unregisterCannotOvertakeRegister originally blocked forever against the reverted code instead of failing, because its fake register awaited a latch with no timeout. ./gradlew test hung. A regression test that deadlocks when the bug returns hands CI a timeout instead of a signal, and a timeout is the one failure mode people retry rather than read. The await is bounded now and both tests fail in 28 seconds against the reverted code.

"I verified the test goes red" is itself a claim. Hanging is not red.

3. Error Monitoring caught a fatal on the sign-in screen

Found by: Error Monitoring. Unhandled IllegalStateException, fatal, handled: no, mechanism: UncaughtExceptionHandler. 3 events, 1 user, all inside 20 minutes.

IllegalStateException: Size(948 x 2147483647) is out of range.
Each dimension must be between 0 and 16777215.

2147483647 is Int.MAX_VALUE, which is Compose's Constraints.Infinity. Two individually reasonable requirements that cannot both hold: Modifier.verticalScroll measures its child with an unbounded main axis, which is the entire point of a scroll container. And material3 Scaffold measures through a SubcomposeLayout, which rejects any dimension above 16777215.

My onboarding put all four steps inside one shared scrolling column. Three are plain forms. The fourth renders Clerk's AuthView, and AuthView renders its own material3 Scaffold. So the sign-in step handed a Scaffold an infinite height.

The 948 is what located it before I changed a line. The device is 1080px wide at density 2.75, and 1080 minus 948 is 132px, which is 48dp, which is exactly the .padding(horizontal = 24.dp) on that column and on no other column in the app.

The breadcrumbs made it look like a lifecycle bug: the activity paused, stopped and restarted three seconds before the crash. It was neither rotation nor a return from background. AuthView renders a placeholder until Clerk's network calls return. Both returned at 04:55:14.05 and the crash is at 04:55:15.40. The app crashed when the real sign-in form first composed, so the trigger was a round trip completing.

The fix narrows the scroll to the steps that need it rather than deleting it, because the form steps genuinely do overflow with the keyboard up.

A concession about this one: the event is tagged environment: debug, on my own device. It is real traffic on real hardware and it is not production traffic, and I am not going to describe it as production traffic.

4. Seer was right about the numbers and wrong about the cause

This is the section I expect to be least popular and I think it is the most useful.

Sentry filed ANDROID-3 with a Seer-authored description:

"The application performs a large number of synchronous database trigger creations and insertions on the main thread during the 'seedIfEmpty' operation, which blocks the UI during the cold start process."

Stated impact: 383 ms of a 1831 ms cold start. Evidence: span 2b74f84036ca48b6 containing 38 sequential sqlite queries.

What is true: the numbers. There is a db.seed span, it does contain 38 sequential queries, and it is inside the MainActivity load. All of that checks out against the trace.

What is false: the load-bearing half. The queries are not on the main thread.

That needs a more careful argument than it looks like, because the obvious argument is one this same project already falsified. I could say allowMainThreadQueries() appears nowhere in WhyRepDb.get() so the guard would have thrown. But bug 2 above was a genuine main-thread database write that sailed straight past that guard, because addObserver blocks through runBlockingUninterruptible instead of going down the guarded query path.

So I checked both sites instead. The addObserver path is still fixed and goes through TableObserverRegistration on Dispatchers.IO, confirmed in the file rather than remembered, which rules out a regression of bug 2. And seedIfEmpty is DAO calls only, where Room's generated suspend methods dispatch to the query executor, so it starts on Main.immediate, suspends at the first DAO call, and never resumes on main. Those are on the guarded path, so there the guard argument does hold.

What the 38 queries actually are. Eleven entities, three temp triggers per table installed by InvalidationTracker on first database access, which is 33, plus the open, the version check, one identity read and the insert. That is 38. It is Room's fixed first-open cost, and it is charged to db.seed only because seedIfEmpty happens to be the first thing to touch the database. Rename the span and the cost moves with it.

Expanding the span in Sentry's own trace view confirms it:

db.sql.query — CREATE TEMP TRIGGER IF NOT EXISTS `room_table_modification_trig...   0.16ms
db.sql.query — CREATE TEMP TRIGGER IF NOT EXISTS `room_table_modification_trig...   0.20ms
db.sql.query — INSERT OR IGNORE INTO room_table_modification_log VALUES(2, 0)       0.07ms
                                                                    32 hidden spans

So the claim "38 sequential sqlite queries" and the claim "insertions on the main thread" came from the same trace, and one of them was reading it correctly.

I left the issue open with a comment rather than resolving it. Nothing was fixed and the 383 ms is genuine, so resolving would assert something untrue about a real measurement. The comment ends with "do not code against the title."

Why I am telling you this in a Sentry category submission. Because the alternative is a paragraph saying Seer is great, and you have read that paragraph already. A tool that is precisely right about measurements and confidently wrong about mechanism is more interesting than a tool that is right, and it is the failure mode you actually need to plan for. Seer got me to the span. I still had to read the bytecode.

Sentry's own Suspect Commit was also wrong on this issue. It blamed a commit that had nothing to do with the span.

The honest version of an AI root cause analysis. Measurements and mechanism are separate claims and they fail separately.

What I Learned

A green signal reports on the part of the trip it can see. The Worker's .catch() never fired because the send succeeded. Everything past the 200 was invisible to every check I had.

A performance test asserts the plan, not the object. An index that exists and an index the planner reaches for are two different claims, and only one of them is the one you wanted.

The negative result is what makes the positive one credible. One query got no faster. Saying so costs nothing and buys the rest of the table.

A guard that has never been observed to fire is a guess. check-sentry-ids.mjs is trustworthy because I broke the code and watched it go red. unregisterCannotOvertakeRegister was not trustworthy until I found out it hung instead of failing.

Instrumentation is a protocol client, and protocol clients need tests. Mine was 150 hand-written lines against a wire format, shipped with no test against that wire format. The character class was where it surfaced. The missing test was the bug.

I added observability to find bugs in my app. The first thing it found was a bug in my observability.

One thing I would genuinely like an answer to, if you have one. The EXPLAIN QUERY PLAN assertion is the most useful test in this whole repo, and I have never seen it in anyone else's Android codebase. Is there a reason for that I have not thought of, or is it just that nobody bothers? I would rather find out now than in a year.

WhyRep is in closed testing on Play and launches in September. If you lift, I will take testers.

Your dog walker says they went. This makes the walk say so too.

Arqam Waheed — Sun, 16 Aug 2026 19:19:36 +0000

This is a submission for Weekend Challenge: Dog Days Edition

TL;DR — A walker records the walk on their phone, the route is hashed in the browser, and a 147-byte attestation signed by the walker's own key lands on Solana devnet. The owner checks the trace they were handed against the chain, and the app tells a tampered route apart from a corrupted file. Move one GPS fix eleven metres and the hash changes completely. That's the whole product.

What I Built

My first idea for this challenge died on Friday night. I'd planned a Snowflake Cortex study of shelter-dog adoption data, wrote the queries, and got the same reply from every single AI function: AI function AI_CLASSIFY is not available for trial accounts. Not a region problem. Not a role problem. A blanket account-tier restriction that no GRANT fixes. I lost the whole idea in one evening.

So I went looking for a dog problem I could actually finish in a weekend, and picked the one that is genuinely about trust: paying someone else to walk your dog.

It's a strange transaction. The person you're checking up on is the same person writing the report. They were there, you weren't, and a better-looking report is worth more to them than an honest one.

The villain here is the record being supplied by the party it judges.

So I stopped asking the walker to be trustworthy. I made the walk testify.

Proof of Walk records the route on the walker's phone, hashes it in the browser, and commits a compact attestation to Solana devnet as an SPL Memo signed by the walker's own key. The GPS trace never leaves the device. Only its SHA-256 goes on chain. Later the owner drops the trace file and the transaction signature into a Verify tab, the hash is recomputed locally, and the two are compared.

That's enough to prove the trace you were shown is the trace that was committed. It also means the walker can't quietly produce a better walk afterwards.

What it does not prove: that a dog was on the end of the leash. It proves a device recorded a route. Anyone can leave a phone in a car that drives the block. This narrows the distance between "trust me" and "check it". It doesn't close it, and I'd rather write that down than let the word "blockchain" imply more than the thing earns.

The gap the project is actually closing. A message is a claim. An attestation is a claim you can test.

Demo

Live app: proof-of-walk-jade.vercel.app

No wallet, no extension, no SOL. On a desktop with no GPS, Run a simulated walk produces a synthetic route and flags it sim: 1 in the attestation itself, so a demo walk stays distinguishable from a real one on a public chain without anyone taking my word for it.

You don't have to record anything to check that the thing works. This link opens the verifier with a real devnet signature already filled in:

Open a committed walk, ready to check

Press Load the example walk, then Verify. It says Match.

Then press Now edit one coordinate. That moves a single GPS fix by 0.0001 degrees, about 11 metres, the smallest change the format can express. Verify again and it says No match, with both hashes drawn as bars so the difference is something you see rather than something I assert.

Being able to falsify the claim in two clicks is a better argument than any paragraph I could write here.

Eleven metres, drawn. Nobody reads a 64-character hex string, so the app renders each hash as 32 bars, one per byte.

Walkthrough video:

Running it locally is three commands:

git clone https://github.com/ArqamWaheed/proofofwalk
npm install
npm run dev

Code

ArqamWaheed / proofofwalk

Proof of Walk

Your dog walker says they went. This makes the walk say so too.

A walker opens this on their phone, taps start, and walks the dog. The route is recorded on-device, hashed in the browser, and a compact attestation is committed to the Solana devnet as an SPL Memo signed by the walker's own key.

The GPS trace never leaves the device. Only the hash goes on-chain. That is enough for the owner to verify the trace they were shown is the trace that was committed — and it means the walker cannot quietly produce a better walk after the fact.

Try it — no wallet, no extension, no SOL. On a desktop with no GPS use Run a simulated walk; synthetic routes are flagged sim: 1 on chain so they stay distinguishable from real ones.

Check my work, in two clicks

Open a walk I…

View on GitHub

Interesting files, if you only open a few:

src/lib/trace.ts: the canonical form. The bytes that get hashed, and the only file the offline verifier shares with the website.
api/relay.ts: the fee relayer, and the four checks that stop it being a faucet.
src/lib/schema.ts: hand-written validation for everything the walker supplies.
src/lib/freshness.ts: the replay gap, and how a block timestamp closes it.
scripts/verify.ts: the same verification with no website involved.

The one contract that can never change is the serialisation, so it's deliberately boring:

export function canonicalise(trace: Trace): string {
  const rows = trace.fixes.map((f) => `${f.t},${f.lat.toFixed(5)},${f.lon.toFixed(5)}`);
  return [`v${trace.version}`, trace.dog, ...rows].join("\n");
}

JSON.stringify is banned from that path. Key order in an object literal is an engine-level implementation detail, and betting hash reproducibility on it would break verification silently for records already committed. Coordinates are pinned to five decimal places, about 1.1 metres, for the same reason. GPS reports far more precision than it actually has, and unpinned floats don't reproduce across devices.

A test pins the output of that function to an exact string. If it ever fails, the hashed bytes have changed and every attestation already on chain has stopped verifying. That's a design decision to make, never a fixture to update.

How I Built It

React and Vite on the front end, @solana/web3.js for transaction construction, two Vercel serverless functions. The stack isn't the interesting part. The decisions are.

Why a chain at all, honestly. Most of this could be a database row. One part could not. The walker is the adversarial party and they're the one supplying the record, so a row in a server they can reach is a row they can edit. An SPL Memo signed by their key, in a block with a timestamp neither of us controls, is not. That's the whole bet. This project doesn't tokenise anything, mint anything, or ask anyone to hold a coin.

The walker signs, the server pays. A dog walker has no wallet, no SOL, and no reason to learn what either is. But the record is worthless if it's the server asserting the walk happened. So the two roles split: the Memo instruction lists the walker's key as a signer, while a relayer key pays the fee. The Memo program logs verified signers, so what lands on chain is "this key asserted this walk", funded by a key the walker never holds. A memo transaction costs about 0.000005 SOL, so one devnet SOL covers roughly 200,000 walks.

A relayer that signs anything is a faucet with extra steps. That endpoint spends money on request, so it verifies what it's signing instead of trusting the client: exactly one instruction, addressed to the Memo program, within the program's own 566-byte limit, carrying at least one signer that isn't the relayer.

const walkerSigned = ix.keys.some((k) => k.isSigner && !k.pubkey.equals(relayer));
if (!walkerSigned) throw new Error("no walker signature on the memo instruction");

Drop that last check and anyone can drain it.

The trust boundary, drawn. The relayer pays for the transaction and vouches for nothing in it.

Telling "this is broken" apart from "this is a lie". This is the bug I shipped and then had to fix, and it's the one I'd want reviewed. The verifier originally did JSON.parse(file) as Trace. A TypeScript cast is a promise to the compiler, not a check at runtime, so malformed input sailed straight through. I tested four broken traces and three of them hashed successfully: a fix missing its timestamp, an empty fixes array, and a NaN latitude. Each produced a stable, confident, meaningless hash.

Which the UI then reported as: the route you were given is not the route that was committed.

That's an accusation of fraud caused by a corrupted file. For an app whose entire job is adjudicating trust between two people, that isn't a rough edge. It's the app doing the opposite of its job. The fix was hand-written type guards at the boundary, and the verifier now reports five outcomes: a match, a genuine mismatch, an unreadable trace, a transaction that isn't a walk attestation, and no such transaction. Exactly one of those is an accusation, and only that one is coloured red.

The bug that mattered most. A corrupted file and a doctored file are not the same accusation, and the type system happily conflated them.

A hash has no opinion about when. I found this late. The SHA-256 proves which route was recorded and says nothing about when, which leaves a gap an adversarial walker can stand in: record one genuinely excellent walk, keep the trace, commit it again next Tuesday. The hash matches perfectly, because it really is that walk. Just not this week's. The block timestamp is the one clock in the system the walker doesn't control, so the verifier compares it against the trace's own end time and reports the gap. A long delay has innocent explanations, so it states the number and lets the owner decide. "This took a while" and "you are lying to me" are not the same sentence.

The gap I found late. The hash proves which route was recorded, never when, so the chain's own clock has to say the rest.

The log is what a chain is actually for. One attestation answers a narrow question. The one an owner really has is broader: what has this walker done for my dog? So the Log tab reads a key's whole committed record back off devnet with getSignaturesForAddress, validates every memo rather than assuming it's ours, and requires that the key actually signed the memo instruction. Otherwise anyone could pad someone else's log by naming their key as a read-only account. A walker can decline to record a walk and the log shows a gap. What they cannot do is delete one they already committed, or invent one they didn't. Absence is ambiguous. Presence is not.

A record, not a receipt. This is also the moment the project stopped being about a walker and started being about a dog.

No map tiles, on purpose. The route is drawn from the fixes themselves as a bare polyline on graph paper. A basemap would render the walker's actual neighbourhood on screen, and their home is usually at one end of the line.

Or don't trust this app either. An app that asks you to stop taking your walker's word for it has no business asking you to take its word instead. So the same verification runs offline in about a hundred lines. npm run verify -- <signature> docs/example-walk.json prints the hash from the chain, the hash of your file, and who signed the memo. Exit 0 for a match, 2 for a mismatch, 3 for a file it couldn't read, because those are three different things. It shares exactly one file with the website: the definition of which bytes get hashed. Two independent implementations reaching the same hash is worth more than either one insisting it's right.

No website involved. Checking a claim shouldn't require believing a second claim about the page doing the checking.

Things I refused to do:

Do not use JSON.stringify anywhere on the hashed path, however convenient it looks.
Do not let the relayer sign the memo, because then the attestation asserts nothing about who walked.
Do not report a parse failure as a mismatch, ever.
Do not render a basemap under the route.
Do not claim the app proves a dog was walked. It proves a device moved.

Two honest concessions. First, the walker's key lives in localStorage and is deliberately disposable, so a walker who clears their browser starts a new log and the old one is orphaned. Real key custody was out of scope for a weekend. Second, this runs on devnet, and devnet faucet airdrops are IP rate-limited hard enough that I funded the relayer by hand rather than programmatically.

What I Learned

A cast is not a check. as Trace is a promise to the compiler that costs nothing at runtime, and it let three malformed files produce confident hashes. The type system agreed with me right up until the app accused someone of fraud.
The worst bugs are the ones that only exist in production. Both serverless functions crashed on deploy with ERR_REQUIRE_ESM, because @solana/web3.js pulls in rpc-websockets, whose CommonJS build requires an ESM-only uuid@14. It was unreproducible locally, because Node 22.12+ permits require() of an ES module and my machine runs 22.19. I wrote a regression test for it, watched it pass against a deliberately broken dependency tree, and deleted it. A test that cannot fail is worse than no test.
Verifiable beats impressive. I spent the last stretch removing friction rather than adding features, because the real risk was never being wrong. It was being skimmed.
Write down what the thing doesn't prove. It costs one paragraph and it's the difference between a claim and a pitch.

Prize Categories

Best Use of Solana.

Solana is load-bearing here, not decorative. The attestation is an SPL Memo, and the walker-signs/relayer-pays split is the reason the whole thing works for someone with no wallet and no crypto literacy. The Log tab reads the chain as well as writing to it, and the block timestamp is what closes the replay gap, because it's the one clock in the system the walker can't touch. If a future change made the relayer the signer, the attestation would stop meaning anything and the project would lose its reason to be on a chain at all.

Logging workouts is solved. I'm building what comes after.

Arqam Waheed — Mon, 13 Jul 2026 22:45:04 +0000

Every workout tracker I've tried has the same limitation: it records what you did, but it doesn't tell you what's going wrong.

You finish a workout, log your sets, reps, and weight, then the app stores the data and that's about it. If you've stopped progressing, consistently training too close to failure, or need a deload, you're left to figure that out yourself.

That's what led me to build WhyRep.

It's a workout tracker with a built-in coach that analyzes your training and explains what's holding you back. The key difference is that every coaching decision has to trace back to a methodology I wrote and approved beforehand, never something an LLM made up on the spot.

For context, I've spent the last three years studying exercise science with a focus on muscle hypertrophy. Rather than asking an AI to invent programming, I write and validate the coaching methodology first, then use AI to explain those decisions in a conversational way.

How the "AI coach" actually works (probably not what you'd guess)

I'm not fine-tuning a model on hypertrophy data and hoping it generalizes. The pipeline is closer to this:

I write the methodology myself first, leaning on my physiology background. Progression rules, deload and autoregulation logic, plateau diagnosis, and everything else starts as a document that I draft and sign off on, complete with concrete test vectors (specific input → specific expected output), before a single line of coaching code gets written.
Deterministic engines implement those docs. ProgressionEngine, AutoregulationEngine, PlateauEngine, and others implement the methodology and are tested against the test vectors, not against "does this feel right?"
The LLM (Claude) only operates inside that fence. It handles the conversational layer by answering your questions, explaining decisions in plain language, and helping you modify your program. It's constrained to the approved methodology, not free to invent new training science mid-conversation.

I've spent a huge amount of time refining this interaction. The goal isn't just to answer basic questions. It's to have the kinds of nuanced coaching conversations you'd expect from a knowledgeable human coach, while keeping every recommendation grounded in the documented methodology.

For example, if you tell the coach, "I want to bring up my arms," it can recommend concrete changes such as prioritizing arms earlier in your workouts, adjusting weekly volume and frequency, and then update your program if you approve the changes.

It also goes beyond the advice most people already know. Many lifters don't realize that if the brachialis is a weak point, it can be trained more effectively by using curl variations that place the shoulder into flexion to emphasize it separately from the biceps. The coach can recognize situations like that, explain the reasoning, and incorporate those changes into your program. Again, none of that is invented on the spot. Every recommendation has to trace back to the underlying methodology that I wrote and approved.

This is also why I'm comfortable letting people challenge the coach. If it recommends something, I should be able to point to the methodology that produced that recommendation and explain the physiology behind it. If I can't justify it scientifically, it doesn't belong in the product. I'd rather spend another week improving the methodology than ship a feature that sounds convincing but isn't something I'd stand behind as a coach.

What's actually shipped so far

This isn't a mockup. Here's what's built and running on a physical device right now:

Full workout tracker: sets, reps, RIR logging
Progression detection engine — methodology doc + engine + test vectors, all committed
Autoregulation/deload engine and plateau diagnosis engine, same doc-first process
Pro-gated analyzer: plain red/yellow flags for free users, full solution panels (limited to fixes that trace back to a doc) for paid
Session history with month-sections, severity badges, and an "Analyze" vs "Perform Again" split
Exercise library (~110 exercises with a lot more to come) with real photos and generated mannequin art + detail pages
Dark mode (now the default) across the app and the landing site
One shared Kotlin Multiplatform core — the same engine code compiles for both Android (Compose) and iOS (SwiftUI). No forked logic between platforms.
Backend coach chat running through Claude (Haiku 4.5), with the methodology docs cached into context
Auth + payments wired to native store billing, not a third-party processor, so both app stores are happy

Though I'd argue that the methodology is the product. I've probably spent more time writing, validating, and refining the methodology documents than writing the AI itself. Every progression rule, plateau diagnosis, autoregulation decision, and program modification starts life as a piece of methodology that I draft, challenge, revise, and test before it ever reaches the coach.

The methodology goes far deeper than "add two sets to chest." Every exercise in the library has documented fractional set contributions for every relevant muscle group. For example, a lat pulldown doesn't just count as one lat set. It also contributes fractional volume to muscles like the biceps. When the coach decides whether to increase, decrease, or maintain your weekly volume, those indirect contributions are already accounted for in the calculations instead of pretending every muscle only receives stimulus from isolation exercises.

That's the biggest difference between WhyRep and most AI fitness apps. I'm not asking an LLM to become a coach. I'm trying to encode an evidence-based coaching methodology into software, then using the LLM as the interface that makes it feel natural to interact with. The AI isn't the source of truth. The methodology is.

Where I'm at on marketing

Top-of-funnel right now: educational, no-fluff gym content on TikTok and Instagram, slowly building an audience. If any of you are into training/hypertrophy content, I'd genuinely appreciate a follow — and if you have thoughts on what's working or not for build-in-public creators in this niche, I want to hear it:

TikTok: https://www.tiktok.com/@whyrep.ai
Instagram: https://www.instagram.com/whyrepai/
Landing page: https://whyrep.com/

What I could use advice on

This is as much a "help me think" post as a "look what I built" post. Specifically I'd love input on:

Anyone else building an audience alongside a technical product — what actually moved the needle for you early on?
If you've built something where correctness/trust is the whole pitch (not just features), how did you communicate that without sounding preachy or over-explaining?

Will keep posting weekly as this moves forward. Thanks for reading this far, I'll probably show the demo next week!

I Finally Finished Schedio: Turning a 5-Day Hackathon MVP Into a Live Product

Arqam Waheed — Sat, 06 Jun 2026 13:20:10 +0000

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

A few weeks ago, I built Schedio as a 5-day hackathon project, which was also, unironically, another GitHub challenge.

The idea was simple:

Highlight any text that mentions an event, and turn it into a Google Calendar event in under 5 seconds.

It worked.

Kind of.

The first version could parse highlighted text, open a clean event modal, and write to Google Calendar. I even wrote about that original MVP here:

Schedio: Highlight to Calendar in 5 Seconds

But after the hackathon rush ended, Schedio was still very obviously an MVP.

The demo was cool, but the product was not finished.

The Gemini key was too close to the client. OAuth verification was not done. Billing did not exist. Pro was just an idea. Onboarding was basically “install this and figure it out.”

There was not even a real landing page yet. My original plan was to build one after the Chrome Web Store approval, properly market the extension, get some users, add more features, and slowly turn it into an actual product instead of just a hackathon project sitting in a repo.

The funny part is that the Chrome Web Store launch failed once because I accidentally uploaded the wrong build. I fixed it, submitted it again, and then it got rejected a second time lol.

After that point, uni exams had started, other hackathons came up, and Schedio slowly drifted into that “I’ll finish it later” state. I never really pushed it beyond the original hackathon MVP.

It worked for me, but it was never really out there for everyone else to use.

So for the Finish-Up-A-Thon, I came back to Schedio and tried to do the part of building that usually gets ignored after the fun demo is over — which is TO ACTUALLY FINISH it and put it out there for others.

What I Built

Schedio is an AI-powered Chrome extension that turns natural language into real Google Calendar events.

You can highlight something like:

Team standup Friday 3pm, Room 204

Then right-click and choose Create Event with Schedio, or use the keyboard shortcut. Schedio parses the title, date, time, and location, shows you a quick review modal, and creates the event in Google Calendar when you confirm.

No copy-pasting.
No switching tabs.
No manually typing date fields while trying to remember what the original message said.

The finished version is now a real product, not just a hackathon repo. It has a live Chrome Web Store listing, a landing page at schedio.org, Google OAuth verification approved, Lemon Squeezy approved for payments, a Cloudflare Worker backend, server-side Gemini calls, Supabase-backed users and subscriptions, Free/Pro metering, an in-extension upgrade flow, voice-to-calendar as a Pro feature, first-run onboarding, privacy policy, Terms of Service, rate limiting, input validation, and no baked Gemini key in the client bundle.

The MVP proved the magic.

The finished version makes the magic safe, usable, and shippable.

Demo

Live site: https://schedio.org

Chrome Web Store: https://chromewebstore.google.com/detail/schedio/nlnkjghkddopgocdbhhkefmjbchlpjnc

Original hackathon version repo: https://github.com/ArqamWaheed/schedio

The original hackathon MVP repo is still public, but the current production version is now private because it contains live infrastructure, billing flows, and production authentication logic.

The core flow is still the same as the original MVP: highlight text, trigger Schedio, review the parsed event, and send it to Google Calendar.

But everything around that flow evolved. What started as a hackathon extension slowly turned into a real product and brand, with a proper landing page, onboarding, Pro features, subscriptions, backend infrastructure, and a much more polished overall experience.

The Comeback Story

The original Schedio was built under pressure. I cared about one question: could I make calendar creation feel instant?

That question led to the first version. But when I came back to the project, the question changed. It was no longer just “can this work?” It became:

“What would I need to change before I could confidently give this to strangers and turn it into a real brand?”

That shift basically defined the entire comeback.

The first real finishing moment was getting Schedio live on the Chrome Web Store. The earlier review had failed because I uploaded the wrong non-working build, which is such a small but painful launch mistake. The code can work locally, the demo can be impressive, the idea can be good, and then one bad upload means nobody can actually install it. So I rebuilt, rechecked, uploaded the correct version, and got it listed.

That made the project feel different immediately.

Before, Schedio was something I could show.

Now it was something people could install.

The next big problem was architecture. The MVP had the classic hackathon shortcut: the Gemini API key was too close to the client. With a browser extension, that is not something you can just hand-wave forever. If a key is in the shipped bundle, it is not really secret.

So I moved the AI parsing behind a Cloudflare Worker backend using Hono. The extension now sends highlighted text and the user’s Google token to api.schedio.org/parse. The backend verifies identity, calls Gemini server-side, and returns the parsed event. The Gemini key lives as a Worker secret, not inside the extension.

That was the first moment where Schedio stopped feeling like a clever browser hack and started feeling like infrastructure. The product still felt simple from the outside, but the trust boundary had completely changed.

Once the backend existed, I could finally turn Schedio into a Free/Pro product. Free users get a monthly event cap. Pro users get unlimited events and access to the voice feature. The important part is that the limit is enforced server-side before Gemini is called, so over-limit users do not cost an API request.

I also made the quota harder to game. The monthly bucket comes from the server’s UTC clock, not the client’s local date, and usage increments through an atomic Postgres function so concurrent highlights do not lose updates.

That is not the flashiest part of the project, but it is exactly the kind of thing that separates a demo from a product. A demo only needs to work once. A product has to keep working when users do weird things.

Billing was another place where finishing meant doing the boring thing correctly. I used Lemon Squeezy as the Merchant of Record, so Schedio does not touch card numbers, VAT, tax, or PCI directly. The backend has endpoints for checking the current plan, creating a personalized checkout link, and handling subscription webhooks.

The checkout flow embeds the verified Schedio user ID into Lemon Squeezy custom data. That way, when the webhook comes back, the subscription can be attached to the exact right Google account.

I almost made the obvious mistake of putting a raw “Buy Pro” link on the website. But the website does not know who the user is. Identity lives inside the extension. A raw checkout link from the marketing page could create an orphaned payment that the backend cannot map to anyone.

So the website sells the product, but the actual upgrade flow starts inside the extension, where the user is already authenticated.

The biggest new feature I added was voice-to-calendar. Instead of highlighting text, Pro users can speak an event into the popup. The backend sends the raw audio to Gemini 2.5 Flash multimodal, and Gemini transcribes and extracts the event in one call. No separate speech-to-text step. No transcript first, parse second.

Just speech into calendar structure.

I made voice a real Pro anchor, not a fake paywall. I could have used the free Web Speech API, but the multimodal approach was more accurate and has real marginal cost. So the server enforces the Pro gate before audio reaches Gemini. Free users get a 403 PRO_REQUIRED before the expensive work happens.

That felt like a real product decision: the feature is better, it costs something, and the paywall protects the cost center before the bill is created.

The next problem was onboarding. The MVP dropped users into the product and expected them to discover the context menu or shortcut. That is fine when the builder is the user, but for others, it is terrible for a new install.

So I built a first-run onboarding tab that opens on install. It shows the core habit: highlight text, right-click, review the event, connect Google Calendar. I wanted the tour to appear once without adding a new storage permission, so I used Chrome’s runtime.onInstalled event with reason === "install". That fires once per install, so there is no extra permission and no extra state to manage.

I also moved sign-in earlier, but carefully. The onboarding ends with a clear Connect Google Calendar button, not an automatic OAuth popup. There is also a skip option. The connect ask only appears after the user has seen the value.

Good onboarding is not a wall of text. It is a rehearsal of the product’s best moment.

The landing page also became part of the finishing arc. I shifted it away from technical explanations and focused more on outcomes instead, because that is what actually gets people interested in a product.

I also had to make the marketing honest. Some features are planned but not built yet, like extra calendar providers and bulk event creation. I did not want to delete the ambition, but I also did not want to lie. So unfinished features got “soon” labels, and shipped features were removed from the future roadmap.

That sounds tiny, but it matters. A product page should not make claims the product cannot survive.

The final wall was trust.

Google OAuth verification got approved. Lemon Squeezy approved the store. Those two approvals were the moment Schedio stopped being “works on my machine” and became something distributable and monetizable.

A calendar-writing extension has to earn trust. Google needed the owned domain, hosted privacy policy, write-only scope explanation, demo video, and correct compliance language. Payments needed a real Merchant of Record review. None of that is as fun as building a new AI feature, but that was the actual finish line.

The original version died near this wall. The newer version finally crossed it.

How GitHub Copilot Helped Me

I used GitHub Copilot CLI to generate a large part of the implementation, but I never treated it like autopilot.

The architecture, product decisions, system boundaries, and overall direction were still mine. Copilot was the accelerator, not the driver. I spent most of the project defining flows, structuring prompts carefully, reviewing generated code, and deciding what should or should not exist in the final product.

That mattered more as Schedio evolved from a hackathon MVP into a real product.

The backend migration is a good example. I knew the Gemini key could not stay in the client anymore, but Copilot helped turn that idea into the actual Worker architecture: extension → Cloudflare Worker → Gemini/Supabase/Lemon Squeezy. It helped scaffold routes, tighten request shapes, and keep the extension and backend synced while the architecture evolved.

It also helped with the parts that are easy to ignore when you are moving quickly: webhook verification, quota tracking, atomic usage increments, CORS restrictions, rate limits, generic error handling, and validation layers. None of those make a flashy demo. All of them make the product safer.

Copilot was also surprisingly useful for debugging weird launch issues. The best example was the OAuth bad client id bug. After moving authentication into the real product flow, Google sign-in suddenly broke in development builds. The issue turned out to be Chrome extension IDs: unpacked builds can generate different IDs unless the public extension key is pinned correctly.

Copilot helped trace the extension ID behavior, compare it against the published Web Store ID, and wire the correct key into the manifest so development and production resolved identically. What started as a vague OAuth failure became a clean one-line fix.

It also helped with product consistency outside pure code. While redesigning the Chrome Web Store graphics, Copilot helped identify outdated messaging that still implied users needed their own AI key. But the final product had already removed BYOK entirely. Leaving those images up would have been misleading, so they got rebuilt before launch.

That was the part I did not expect initially. Copilot was not just generating code. It was helping keep the product coherent while the scope kept expanding.

The Terms of Service and SEO work were similar. Copilot helped structure the TOS around the existing privacy policy style, wire the new pages into the build system, and connect everything through the footer and metadata layer. It also helped add Open Graph tags, Twitter cards, sitemaps, robots files, structured data, and asset handling.

The biggest lesson was that Copilot never replaced the decisions. It simply made implementation dramatically faster once the direction was clear.

And most of the important decisions were actually restraint:

Do not put a raw checkout link on the website because identity lives in the extension.
Do not claim planned features are already shipped.
Do not add unnecessary permissions just because they are convenient.
Do not process webhooks loosely when strict validation is safer.
Do not leak backend internals in API errors.
Do not keep a Gemini key in the client just because it is easier.

The MVP was built with speed.

The finished product was built with speed plus restraint.

Once the architecture and product decisions were clear, Copilot accelerated the implementation massively. I still handled the direction, debugging, and review process, but it removed an enormous amount of friction from actually extending and shipping Schedio.

A lot of the final product simply would have taken far longer to build without it.

What I Learned

A hackathon project is about proving the magic.

A finished product is about protecting it.

Schedio already had the magic: highlight text and turn it into a calendar event in seconds. But the comeback was everything around that.

Can users install it?
Can Google trust it?
Can payments map to the right account?
Can a free user hit a limit without the UX feeling broken?
Can secrets stay secret?
Can onboarding teach the habit?
Can the website sell without lying?
Can the system survive the boring edge cases?

That is what I finished.

And weirdly, that made the project more exciting than the original hackathon version, because now Schedio is not just a demo I can show. It is a product I can actually launch.

The next steps are smarter recurrence, multiple calendars, Outlook/iCloud/CalDAV support, bulk multi-event parsing, Firefox and Edge support, and eventually a Mac/Safari companion app. But the important part is that Schedio is no longer blocked by the boring stuff.

The boring stuff is done.

And that was the real Finish-Up-A-Thon.

What's Next Beyond Development

Now comes the next challenge: distribution

Schedio is finally live, installable, verified, and usable by real people. The engineering side finally feels complete enough to push properly, so my next focus is figuring out how to market it, get feedback from real users, and turn it from a finished side project into something people genuinely rely on.

If anyone has ideas for growth, launch, or distribution strategies for productivity extensions, I would genuinely love to hear them.

DEV Community: Arqam Waheed

Munshi: a WhatsApp front desk for small hotels. A 4B model reads, Python decides, Temporal holds the room.

What I Built

Demo

Code

ArqamWaheed / munshi

Munshi: a WhatsApp front desk for small Pakistani hotels (HF26 Week 2)

Munshi: a WhatsApp front desk for small hotels

Results (every number is a file in results/ or

How I Built It

Tinker: teaching a 4B model to read a booking message

Gemma 4: writes every reply, decides no number

TabPFN: is the risk score honest, and is it worth money?

Temporal: a room hold is a promise with a deadline

Sentry: where the time goes, and where code overruled the model

What went wrong

Why Does Open Innovation Matter?

My First User

What I Learned

Prize Categories

"we should go out this weekend": I built a Discord member that holds the clock until we're outside

What I Built

Demo

Code

ArqamWaheed / quorum

A group-chat member that holds the clock until your friends are actually outside.

Quorum

How I Built It

Why Does Open Innovation Matter?

My Agent Session

What I Learned

Prize Categories

WhyRep is now officially out! The workout logger that also analyzes your training.

The question your gym log can't answer

What WhyRep does

And it's a fast gym log first

Why you can trust the verdicts

Free and Plus

What it doesn't do yet

Try it

"If it's not in front of me, it's gone": I fine-tuned a 4B model for my friend with ADHD

What I Built

Demo

Code

ArqamWaheed / actually

How long will it actually take? A time-blindness helper for a friend with ADHD — fine-tuned open model (Tinker) + TabPFN, runs on one box.

Actually

How I Built It

Why Does Open Innovation Matter?

My Agent Session

What I Learned

Prize Categories

The charity had the proof. It just couldn't show anyone.

What I Built

Demo

Code

ArqamWaheed / consent

Consent

The boundary, in three layers

What the

How I Built It

The gate

Rebuilding three functions out of one

The boundary didn't work

What I refused to do

Prize Categories

What I Learned

I wrote the privacy rule, enforced it, commented it, and shipped the leak anyway

The setup

What I missed

Then the same grep found a second one

The fix

What I take from it

My performance optimization silently disabled the feature the app exists for

The setup

The bound I was proud of

Why it was wrong

What it costs a real lifter

The fix

What I take from it

Results (every number is a file in `results/` or