DEV Community: Arqam Waheed

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.

I Made My AI Models Argue, Then Let Hermes Be the Judge

Arqam Waheed — Sat, 30 May 2026 16:00:54 +0000

This is a submission for the Hermes Agent Challenge: Build With Hermes Agent

TL;DR — Ask any judgment call and three different AI models argue it out, then Hermes hands down one verdict, a confidence score, and exactly why they split. Every verdict, dissent, and mind-changed-in-debate is written into Hermes' own memory, so the next question re-weights the jurors before they ever vote. The judging is a pure function over that memory: no memory, no weights, no verdict. Three models, one verdict, $0.

What I Built

An LLM once talked me into the wrong database with total confidence. One smooth, authoritative answer. I shipped it. It cost me a weekend and a migration I'm still not over.

The villain here is single-model overconfidence: you get one polished reply, and the disagreement that should have warned you is invisible. You never see the other opinions, because you only asked one model.

So I stopped trusting one model. I convened a jury.

Council takes any judgment call ("Postgres or Mongo?", "is this PR safe to merge?", "is this clause risky?") and asks three different models, lets them disagree, then has Hermes deliver one verdict, a confidence score, and exactly why they split. Three models, one verdict, $0.

You ask a question. Council fans it out to three jurors (two free OpenRouter models from different families and one local model via Ollama), each takes a position with reasons. Then, if they disagree, a second deliberation round runs: each juror sees the others' answers and either holds or changes its mind, so the council debates instead of just voting once. Hermes then judges the deliberated opinions: a single verdict, a confidence score (high when they agree, low when they split 2-1), and a "why they disagreed" panel. Every verdict is remembered, a council skill learns which juror to trust for which kind of question, and the agent can even propose its own trust adjustments for you to approve.

The whole product is one question box. Everything interesting happens behind it, and the rest of this post is mostly pictures of that "behind."

Demo

Repo: https://github.com/ArqamWaheed/council

Live demo: https://council-jet-kappa.vercel.app/
Hermes orchestration is local-only (no Hermes binary on serverless); the hosted demo runs the same UI via OpenRouter/mock. Run locally for the real hermes -z path.

Try "Should a 3-person startup use microservices?" and open the dissent panel.

Local, one command (runs at $0 in offline mock mode, no key needed):

git clone https://github.com/ArqamWaheed/council && cd council && ./setup_hermes.sh && python server.py

Architecture, in pictures

I think the design is easiest to see, so here's the system as a sequence of images. Each caption is the explanation.

The core loop. One question, three independent Hermes subagents (2 hosted + 1 local) fanned out in parallel, then a fourth Hermes run (the foreman) synthesizes one verdict. Every arrow is the same hermes -z interface; nothing talks to a model directly.

The bet. A hosted model and an on-device model sit on the same jury, swapped with a single --provider/--model flag, no code change. This model-agnosticism is the one Hermes property the whole project is built on.

The UX surface. Confidence is high when jurors agree and drops on a 2-1 split. The dissent panel is collapsed by default, and you expand it exactly when the confidence number makes you nervous.

The actual product. A confident single answer hides this; Council makes the disagreement the headline. Getting the clustering right here was subtle (see "What I learned" below).

The headline feature: a council that **deliberates, not just votes. After round 1, disagreeing jurors get a second Hermes pass where they read each other's arguments and may hold or change their vote. A "⇄ changed" badge marks the ones that moved, and the confidence dial actually climbs when a 2-1 split is talked into agreement.

The agentic learning loop, human-in-the-loop. Hermes proposes; you approve or dismiss. Approved rules persist client-side and ride along with the next convene call.

Persistence the judge can verify. Verdicts are mirrored into Hermes' own memory, so recall is Hermes doing the work; proof lives in docs/hermes-proof/04-memory-recall.txt.

Code

Repo: https://github.com/ArqamWaheed/council

Interesting files:

hermes_run.py (the Hermes CLI driver every juror/judge call goes through)
run_council.py (orchestration + the deterministic judge + Hermes foreman + the --reflect loop)
skills/council/SKILL.md (the juror-weighting brain Hermes edits)
server.py (the /api/reflect + /api/learn endpoints)
index.html (the designed verdict UI with the foreman TTS readout and localStorage persistence).

Proof that Hermes is genuinely in the loop (subagent transcripts, skill diff, memory recall) is in docs/hermes-proof/.

# hermes_run.py: every juror/judge call is a real Hermes run
def ask(prompt, provider, model, skills=None, timeout=120):
    cmd = [binary(), "--provider", provider, "--model", model]
    if skills: cmd += ["--skills", skills]
    cmd += ["-z", prompt]                       # -z = one-shot, final answer on stdout
    return subprocess.run(cmd, capture_output=True, text=True, timeout=timeout).stdout

# jurors.py: fan out one Hermes subagent per juror, in parallel
with ThreadPoolExecutor(max_workers=len(roster())) as pool:
    opinions = list(pool.map(lambda c: ask_juror(*c), enumerate(roster())))

How I Used Hermes Agent

Why Hermes at all: the model-agnostic core. Hermes lets you point at any provider and swap with a flag, no code change. Council is built on top of that one property: the jurors are different models, and Hermes is the only piece that makes "different models" cheap. The clearest proof is the third juror: it runs locally via Ollama while the other two are hosted on OpenRouter, and all three answer through the exact same hermes -z interface (the model-agnostic diagram above). A hosted model and an on-device model, sitting on the same jury, no code change: that's model-agnosticism you can see. I genuinely didn't see another entry in this challenge exploit it; everyone picked one model and moved on. That's the whole bet.

Subagents: one real Hermes run per juror. Each juror is a genuine, isolated Hermes invocation on a different provider+model (hermes -z --provider openrouter --model … for the two hosted jurors, --provider ollama-local … for the on-device one), fanned out in parallel so no model's reasoning anchors another's (the convene-flow diagram above). Hermes does the inference; my Python (jurors.py to hermes_run.py) is just the fan-out plumbing, and every juror in the output JSON is tagged "via": "hermes". The gotcha worth flagging: Hermes enforces a 64K-context floor, which for the local model meant setting both ollama_num_ctx and a named custom_providers entry; without the named provider, --provider ollama silently routed to the wrong base URL. setup_hermes.sh encodes the working config so a judge can reproduce it in one command.

A true debate, not just a vote (round 2 is real Hermes work). This is the feature I'm proudest of. After round 1, if the jurors disagree, each one gets a second Hermes run that shows it the others' positions and lead reasons and asks it to hold or change its mind. Real jurors reconsider through the same hermes -z path as round 1, so the debate is genuine extra agentic work, not a UI flourish; mock jurors reconsider deterministically so the offline demo stays reproducible. The judge then synthesizes the verdict from the deliberated opinions, so a juror that's talked round actually moves the outcome (the deliberation diagram above). It's gated on disagreement (a unanimous round 1 skips it) and toggled with COUNCIL_DEBATE=0.

Why a skill, not a prompt, for judging. The foreman's verdict is itself a Hermes run (hermes -z --skills council) grounded in skills/council/SKILL.md, which is installed into Hermes (hermes skills list shows it). The weighting logic lives in a machine-readable weights block.

The judging brain is data, not a buried prompt. --learn and --reflect both edit this block, and the installed Hermes copy is kept in sync.

After a string of security questions, --learn appended a rule to upweight the local model on that topic (and synced the installed Hermes copy) because it had caught issues the hosted models missed:

python run_council.py --learn "Local Juror | security | 1.5"

On the next security question that juror's vote counts 1.5×, read straight back by the judge. Counterfactual: a static synthesis prompt can't get better; this does. (The before/after skill diff is in docs/hermes-proof/03-skill-learning.txt.)

Letting the agent propose its own learning, now on the web and grounded in evidence. python run_council.py --reflect (and the "Should the council reweight itself?" button in the UI) hands Hermes its own memory of past verdicts and asks it to propose one weight change, e.g. "the local juror has dissented on three database calls; upweight it." The key fix this round: the proposal is evidence-grounded, since Hermes is fed the actual dissent tally and any rule backed by fewer than two real dissents is rejected, so it can't just parrot the example baked into the skill. You then Approve or Dismiss it (the reflect-flow diagram above). That's the agentic loop done honestly: a single verdict has no ground truth, so the agent surfaces a pattern and a human confirms it's signal, not overfitting (the exact tension this post closes on). (Offline, it falls back to a deterministic heuristic so it never breaks.)

Making learning survive a stateless deploy. On a hosted demo the filesystem is read-only, so an approved rule can't be written back to SKILL.md. Council handles this honestly: approved rules are stored in the browser's localStorage and re-sent with every /api/convene call, where they're merged into the judge's weights for that request. Locally you get a persistent SKILL.md; on the web you get per-browser persistence, and either way the learning sticks.

Why memory. Each verdict is appended to a log and mirrored into Hermes' own MEMORY.md, so I can ask hermes -z "what did the council decide about auth?" and Hermes recalls it from its memory, not from my code (the memory-recall image above). Proof: docs/hermes-proof/04-memory-recall.txt.

The foreman reads the verdict aloud. The verdict card has a "the foreman reads the verdict" button (browser SpeechSynthesis, $0); Hermes also ships native TTS via hermes setup tts. On-theme and memorable: a jury foreman announcing the decision.

The build itself was agent-run. I kept a memory.md the coding agent read before each task and updated after (so context stayed cheap), committed every increment with Conventional Commits, and built the verdict UI with the frontend-design skill, which is why the confidence dial and colour-coded juror chips read as designed, not default-template AI slop. The repo's AGENTS.md + commit history show the process, not just the result.

Why these models, and the concession. Two free OpenRouter models from different families (≥64K context, since Hermes rejects smaller at startup) plus a local Ollama juror. Two honest concessions: (1) free models are slower and three calls add latency (~10-20s/verdict); (2) the free tier is aggressively rate-limited, so I hit 429s constantly while building, and Council retries and, if a juror still won't answer, falls back (Hermes to direct API to deterministic stand-in) rather than crashing the verdict, which also means the demo runs fully offline at $0. For a once-a-decision tool, I'll take it. Cost: $0.

License. MIT. Fork it, add your own jurors.

What I learned (and what's next)

The disagreement is the product. A 2-1 split is more useful than a confident single answer, so the clustering that decides "who actually disagreed" has to be right. A small local model once wrote a vague position ("to facilitate efficient integration…") whose reasons clearly endorsed Postgres; the first version mis-filed it as a dissenter. The fix: when a juror's stated position is ambiguous, fall back to reading its reasons, and ignore options only mentioned in a comparison ("better than Mongo" isn't a vote for Mongo). Now agreeing jurors cluster together, and the split count is honest.
Grounded beats glib. Letting the agent propose its own weighting only works if the proposal is tied to real evidence; an ungrounded "reflect" just echoes whatever example is in the skill.
Hermes' 64K-context floor caught a model that would've quietly underperformed.
A council should deliberate, not just vote. The round-2 debate above was the turning point: letting jurors read each other and reconsider means a juror that's genuinely persuaded moves the verdict, and you watch the confidence dial climb as a 2-1 split becomes unanimous. A one-shot vote can't do that.

Terra Triage: I Built a 3-Agent Wildlife Dispatcher That Learns From Every Referral

Arqam Waheed — Mon, 20 Apr 2026 06:34:33 +0000

This is a submission for Weekend Challenge: Earth Day Edition

TL;DR — Snap a photo of an injured animal, the right licensed rehabber gets paged in under 60 seconds. Backboard remembers every accept, decline, and "at capacity" outcome, so the next case re-ranks before it's dispatched. Memory is the product; the ranking is a pure function that cannot compute without it.

What I Built

Last spring I found a stunned songbird on the sidewalk and spent forty minutes cold-calling vets that don't take wildlife. By the time I reached an actual rehabber, the bird was gone. That's the problem I wanted to solve in a weekend.

Most dispatch apps pick the closest rehabber. Terra Triage picks the one who will actually say yes, because Backboard remembers who said no last time.

Terra Triage is a three-agent web app for people who just found an injured animal and have no idea who to call. You snap a photo, approve a single consent prompt, and under 60 seconds later a licensed wildlife rehabilitator within range has an email in their inbox with the photo, the GPS, and a one-click "accept / decline / at capacity" magic link. No account, no app, no phone tree.

The interesting part is not the first dispatch. It's the second one. Every outcome a rehabber returns (accepted, declined, at capacity, unreachable) is written back as a signal into Backboard, and the very next case reranks because of it. If Rehabber A just declined a raptor at 9:42, the 9:51 raptor won't go to them first. The memory is the product.

Three agents, one narrow job each:

Agent	Job	Model / Service
Finder	Vision triage: species, severity 1-5, safety advice	Groq Llama-4 Scout (vision), JSON mode
Dispatcher	Rank rehabbers, send the email, mint magic-link	Auth0 scoped agent token + Resend
Memory	Read and write rehabber signals that drive the ranking	Backboard (primary), Supabase mirror as fallback

Demo

Live URL: https://terra-triage.vercel.app/
60 second walkthrough:

The flow:

Open the website on a phone, snap a photo of an injured animal, and approve the location prompt.
The Finder agent returns a triage card with species, severity, and first-aid advice.
A ranked list of nearby rehabbers appears. Each card shows the Backboard-aware score, distance, capacity, and a one-tap Call button for the listed 555-01xx number.
Tap Send referral on the top pick. Auth0 asks for the referral:send scope, you consent once, and the dispatcher fires.
The success pane shows "Referral sent" next to a scoped-token badge and a View captured email link.
Open the captured email in /demo/inbox/<id>. Everything a real rehabber would see is there: photo, GPS, triage summary, accept and decline buttons.
Click Decline, at capacity from inside that email. The magic-link records the outcome and redirects to a thank-you page.
Switch to /admin. The memory timeline shows the new signal landing in Backboard, and the same case re-ranks with that rehabber demoted.

No email leaves the server during this flow. Delivery is gated behind a demo switch for this submission; why, and what the real launch path looks like, are in the sections below.

Code

ArqamWaheed / terra-triage

Terra Triage

Snap a photo of an injured wild animal and a multi-agent system identifies the species, triages the injury, and dispatches the referral to the rehabber most likely to say yes, in under 60 seconds.

What it does

Terra Triage collapses the chaotic gap between "I just found a hurt animal" and "a trained rehabber is on the way" into a single guided 60-second flow. It pairs a Groq-powered vision Finder agent, an Auth0-scoped Dispatcher agent, and a Backboard-backed Memory agent so that every referral outcome improves the next ranking. Most dispatch apps pick the closest rehabber. Terra Triage picks the one who will actually accept, because Backboard remembers who said no last time.

Nationwide coverage is seeded (250 licensed rehabbers, 5 per US state, fictional .example.org contacts using the NANPA 555-01xx block reserved for fiction) so the ranker has something to rank from day one. Every…

View on GitHub

Project structure (trimmed):

src/
├── app/
│   ├── report/                    # Anonymous intake (photo + geo)
│   ├── case/[id]/                 # Reporter-visible case page
│   ├── rehabber/outcome/[token]/  # Magic-link outcome form
│   ├── admin/cases/               # Ops console + memory timeline
│   └── api/
│       ├── admin/seed-demo-case/  # Idempotent demo seeder
│       └── auth/[auth0]/          # Auth0 login / callback / profile
├── lib/
│   ├── agents/
│   │   ├── finder.ts              # Groq vision call, JSON mode
│   │   ├── dispatcher.ts          # Rank + Resend + magic-link
│   │   └── rank-with-memory.ts    # Fuses memory signals into the rank
│   ├── memory/
│   │   ├── backboard.ts           # Real Backboard API client
│   │   └── index.ts               # Backboard-primary, local fallback
│   └── auth/
│       ├── agent-token.ts         # Scoped agent token (PAR or M2M)
│       └── magic-link.ts          # HMAC-signed, single-use tokens

How I Built It

Backboard as the protagonist

Most "memory" integrations I see treat the memory service as a prompt-context bucket: fetch recent history, stuff it into the system message, let the LLM figure it out. Terra Triage does the opposite. The ranker is a pure scoring function that cannot compute without memory first — no LLM in the hot path, no prose interpretation, just signals driving weights.

// src/lib/agents/rank-with-memory.ts
export async function rankRehabbersWithMemory(
  input: CaseInput,
  rehabbers: PublicRehabber[],
): Promise<RankedRehabber[]> {
  const signals = await getMemory().query(rehabbers.map((r) => r.id));
  return rankRehabbers(input, rehabbers, signals);
}

The scorer weights species match (0.35), distance (0.25), capacity (0.20), accept rate (0.15), and response time (0.05). Every weight except distance is sourced from Backboard. When a rehabber submits an outcome, applyOutcomeToSignals mutates the relevant keys (capacity, accept_rate, species_scope, response_ms) as a pure function and writes them back. The next ranking reflects it immediately.

The engineering lesson I did not expect. My first Backboard integration used semantic /memories/search once per rehabber, per case. That is correct-looking code and costs about $0.80 per triage at hackathon volumes.

Because all of our memory writes are structured and attributable to a rehabber id, the correct access pattern is a single paginated GET /memories and filter in application code. I rewrote it that way and the cost dropped roughly 800x (to fractions of a cent) with no change in ranking quality. Signals are encoded as TERRA_SIGNAL rehabber=<id> key=<k> value=<json> so the filter is trivial.

The final detail: FallbackMemory is a tiny proxy that prefers Backboard and mirrors every upsert to a local memory_entries table tagged source='backboard' | 'local_fallback'. If Backboard is down mid-demo, the app keeps working and the admin timeline shows a red chip so you can see the failover instead of it hiding behind a stack trace.

Auth0 for Agents: scoped consent for a destructive action

"Send referral" is the one button in this app that can annoy a real human being (emails a licensed rehabber). I treated it as an agent action that must be authorized, not a server-side formality.

// src/lib/auth/agent-token.ts (excerpt)
export async function getAgentToken(): Promise<AgentToken> {
  const session = await getSession();
  if (session?.tokenSet?.scope?.split(" ").includes("referral:send")) {
    return { token: session.tokenSet.accessToken, mode: "user-consented", scope: "referral:send" };
  }
  return mintM2MToken({ audience: env.AUTH0_AGENT_AUDIENCE, scope: "referral:send" });
}

PAR is on when the tenant allows it (AUTH0_PAR=1), so the browser never sees the full authorization params, only a request_uri handle. The custom consent_context query parameter carries human-readable context ("email Marcus at Hudson Valley Raptors on your behalf") into the consent screen. If consent is unavailable, we fall back to a scoped machine-to-machine token rather than silently downgrading the action to a service call.

The UI surfaces which mode was used with an on-screen badge. The narrator can literally point at it on camera and say "scoped." That visibility is the Auth0 story for me: agents should explain themselves, not hide.

Rehabbers do not have accounts. Their outcome submission goes through an HMAC-signed, single-use, 72-hour magic link (src/lib/auth/magic-link.ts). Single-use is enforced with a conditional UPDATE ... WHERE outcome IS NULL, so concurrent submissions for the same token are atomic at the database layer.

The rest of the stack

Finder: Groq's meta-llama/llama-4-scout-17b-16e-instruct over the OpenAI-compatible chat/completions endpoint, with response_format: { type: "json_object" }. Sub-second vision triage. Prompt shape is inlined in the system message because Groq does not support strict JSON schemas.
Supabase: Postgres, RLS, private photos bucket with short-lived signed URLs. The Finder hashes the resized JPEG bytes and caches triage results, so demo retries are free.
Resend: transactional email, gated behind a DEMO_MODE flag for this submission (more on that below).
Next.js 16 (app router) + server actions, Tailwind + shadcn/ui, Leaflet for the rehabber map.

Seeding 250 rehabbers without spamming any of them

The list you see in the demo is 250 fictional licensed rehabilitators, five per US state, generated from a deterministic script (scripts/generate-rehabber-seed.ts). Every record uses real capital and largest-city coordinates so the distance math is honest, but every email ends in .example.org (reserved under RFC 2606, can never resolve) and every phone uses the NANPA 555-0100..555-0199 block reserved for fiction. Not one of those addresses can receive mail. That is deliberate.

Two switches control delivery in production:

DEMO_MODE=1 shorts the dispatcher before Resend is ever called. The rendered email is written to a sent_emails_log table and surfaced at /demo/inbox/<referral_id>, a server-rendered viewer behind admin basic-auth. The success pane grows a View captured email link so judges can click straight from the app into the message that would have been sent. Zero outbound traffic, real referral row, real memory signal, real magic-link outcome loop.
DEMO_REDIRECT_TO=you@example.com keeps Resend in the loop but rewrites every recipient to a single verified inbox and prefixes the subject [DEMO -> original@address]. Useful for recording a live walkthrough where you want a real email to arrive on your phone.

Both paths delete the referral row if the send actually fails, so the case page never shows a phantom "awaiting response" card for a message that never left the server.

What I cut, and the real path to launch

The biggest thing I cut: real rehabber contacts.

There is no global registry of licensed wildlife rehabilitators. US coverage is fragmented state-by-state, sometimes county-by-county, and most other countries (mine included) have no centralized list at all.

The tempting fix is to scrape state-agency PDFs and let an LLM parse them into rows. I refused to ship that for three reasons: (1) scraping public directories into a third-party product violates most of those agencies' terms of use, (2) the data is stale the moment you capture it (licenses lapse, phones change), and (3) language models invent plausible-looking email addresses. Sending a real referral to a hallucinated inbox is worse than returning no results.

So the 250 rows in this build are honest placeholders that exercise the ranking math without lying to anyone. Production needs a different sourcing path, and I think there are only three real options:

Partner with the Animal Help Now 501(c)(3). AHN already runs a consented, maintained database of thousands of rehabbers across the US. A partnership integration (their pipeline, our ranking and memory layer) is the only path that ships real coverage without recreating two decades of stewardship work. This is what I would pursue first, post-hackathon.
A self-serve rehabber portal. Licensed rehabbers sign up, verify their license number against the relevant state registry, accept a Terra Triage ToS, and opt in to receive referrals. Growth is slow but consent is unambiguous and the data stays fresh because each rehabber owns their own row. This is the right fallback if #1 does not pan out.
Per-state agency MoUs. Some state wildlife agencies distribute their rehabber lists under explicit terms. Where those terms permit a downstream dispatcher, you sign a memorandum and import. Slow, jurisdiction-by-jurisdiction, but legally clean where it applies.

What will not change is the consent requirement. Regardless of sourcing path, every rehabber in the live system needs a signed agreement covering referral delivery, PII handling, license verification, and a clear opt-out before they can be ranked. That is table stakes, not a feature.

The data model for all three paths already exists in this repo (rehabbers table with active flag, species_scope, license metadata). The discovery pipeline and ToS flow are the next weekend.

Prize Categories

Primary: Best Use of Backboard. Memory drives a computed decision, not an LLM prompt. Every rank reads signals first; every outcome writes them back; the admin timeline makes the loop visible on screen. A FallbackMemory proxy keeps the app alive if Backboard is unreachable and tags the origin so failover is auditable. The cost model went from $0.80 per triage to fractions of a cent after rewriting from per-rehabber semantic search to a single filtered list read.

Secondary: Best Use of Auth0 for Agents. The Dispatcher is a first-class OAuth client scoped to referral:send, with PAR when available and an M2M fallback, and the UI labels which mode was used. Rehabbers authenticate through HMAC-signed, single-use magic links with DB-level replay protection.

Built solo in a weekend with GitHub Copilot CLI as co-author with zero paid services.

MergeGuardian 9000: I Built an AI Code Reviewer With a 0% Approval Rate

Arqam Waheed — Tue, 07 Apr 2026 14:19:14 +0000

This is a submission for the DEV April Fools Challenge

What I Built

I've opened hundreds of pull requests in my career. Fixed typos. Refactored auth flows. Centered divs. And every single time, some reviewer finds a reason to block the merge. Not because the code is bad. Because the vibes are off.

By PR #200, I realized the problem wasn't my code. It was that no tool existed to formalize the experience of being told your perfectly working code is somehow insufficient. So I built the tool myself.

MergeGuardian 9000 is an AI-powered pull request review platform with a guaranteed 0.00% approval rate. You paste your code, pick a reviewer persona, and within seconds Google Gemini delivers a devastatingly thorough review that finds profoundly absurd reasons to block your merge.

It looks exactly like a real GitHub PR review. Verdict cards. Status checks. Inline comments. A merge button at the bottom. Except the merge button is permanently disabled. And the status checks are things like "Existential Debt Audit" and "Naming Karma Validation." And the verdict is always one of three options: changes_requested, blocked, or spiritually_rejected.

Here's the thing that makes it actually work: Gemini reads your real code. This isn't a random joke generator. Google Gemini analyzes your actual functions, your variable names, your architecture choices, and then finds deeply specific reasons why none of it is merge-worthy. Paste a function add(a, b) { return a + b } and the Guardian will explain how your function "shows a troubling belief that problems can be solved by combining things."

The Five Horsemen of Code Review

Every enterprise platform needs opinionated reviewers. MergeGuardian ships with five, each backed by its own Gemini system prompt that gives the AI a distinct personality:

Persona	Title	Blocking Style
🛡️ Guardian Core	Senior Review Orchestrator	References fake policies like "Guardian Policy 7.4.2"
📋 Compliance Beast	Chief Policy Enforcement Officer	Sees SOC2 violations in your variable names
💀 Staff Engineer of Doom	Principal Taste Architect	Has seen better implementations in languages you haven't learned yet
🤖 AI Optimizer	Metrics & Confidence Analyst	Your semantic drift score is 0.89. Acceptable range: 0.00 to 0.02.
😊 Passive-Aggressive Teammate	Friendly Neighborhood Blocker	"Just a thought, but have you considered not merging this? Totally up to you! 😊"

Each persona has its own Gemini system prompt, its own blocking patterns, and its own way of making you question your career choices. Same model. Same API. Five completely different voices. That's the fun part of Gemini's system prompt flexibility.

The Loading Theater

No enterprise tool is complete without unnecessary ceremony. When you submit a review, the Guardian runs through a 12-stage "Enterprise Review Pipeline":

The stages include gems like "Validating emotional idempotency" and "Cross-referencing naming karma." A progress bar ticks up from 0% to 100%. The final stage, "Finalizing disappointment," always fails with a red X. Because of course it does.

Here's the funny part: Gemini 2.0 Flash responds in 1-3 seconds. The loading theater takes longer than the actual AI generation. Enterprise ceremony demands it.

The Appeal System

Here's where it gets good. After your merge gets blocked, you can file an appeal. The "Senior Merge Arbitration Officer" reviews your case via a fresh Gemini call and... denies it. With even more elaborate reasoning.

Not satisfied? Escalate to the "Principal Philosophy of Code Director." Still denied. Final appeal goes to the "Supreme Architect of the Eternal Codebase." Three rounds of escalating absurdity, each powered by a separate Gemini API call with its own system prompt that shifts the AI's entire personality.

Round 3 denials hit different: "We ran your code through a quantum computer. In every possible timeline, this merge was blocked."

The Code Quality Roast

Click "Run Code Quality Analysis" and Gemini generates a full enterprise metrics dashboard for your code. The AI returns structured JSON with scores, grades, and per-metric roast explanations. Every metric is suspiciously terrible:

Semantic Cohesion: 12% ... "Your functions communicate like divorced parents at a school play"
Bus Factor Resilience: 3% ... "If you get hit by a bus, this code dies alone"
Vibe Alignment Score: 8% ... "This code has the structural integrity of a house of cards in a wind tunnel"

Overall grade: F. AI confidence: 99.7% certain this should not ship.

Bring Your Own Gemini Key 🔑

You can paste your own Google Gemini API key directly in the UI. It stays in your browser's localStorage and never goes anywhere except the app's own API routes. No .env file. No cloning repos. Just grab a free key from Google AI Studio, paste it in, and unlock AI-powered reviews instantly.

The Gemini free tier gives you 60 requests per minute and 1,000 per day. That's enough to get roasted hundreds of times without spending a cent. The entire app runs at zero cost.

Without a key the app still works perfectly. Our handcrafted fallback engine has 80+ jokes and serves the same JSON shape. But with Gemini the reviews get personal.

10 Sample PRs to Get Roasted

Don't have code handy? Pick from 10 pre-loaded PRs including "Fix typo in button label" (still gets blocked), "feat: implement entire todo app" (built during a meeting, naturally rejected), "feat: add vibe-based code generation" (the Guardian has thoughts about vibes), and "feat: decentralized merge approval via blockchain" (the MergeChain has a 0% approval rate by design).

Easter Eggs 🫖

Visit /418 and you'll find an ASCII art teapot with animated steam, a tribute to RFC 2324, and a teapot status dashboard showing: Temperature ∞°C, Brew Status: Philosophically Brewing, Capacity: Unlimited Disappointment.

The 404 page is on brand too. Even our errors reject you.

Demo

Live demo: april-fools-hackathon.vercel.app

Paste code. Pick a persona. Get blocked. Appeal. Get blocked harder. Share your rejection on Twitter.

Code

ArqamWaheed / april-fools-hackathon

🛡️ MergeGuardian 9000

The AI-powered code review platform that blocks every merge — for your own good.

"Your code compiles, tests pass, but the universe has not consented."

MergeGuardian 9000 is an enterprise-grade AI pull request review platform with a 0.00% approval rate. Paste your code, select a reviewer persona, and watch as the Guardian finds profoundly absurd reasons to block your merge.

Built for the DEV April Fools Challenge 2026.

✨ Features

5 Reviewer Personas — Each with a unique personality and blocking style:
- 🛡️ Guardian Core — Senior Review Orchestrator
- 📋 Compliance Beast — Chief Policy Enforcement Officer
- 💀 Staff Engineer of Doom — Principal Taste Architect
- 🤖 AI Optimizer — Metrics & Confidence Analyst
- 😊 Passive-Aggressive Teammate — Friendly Neighborhood Blocker
Google Gemini AI Integration — Uses gemini-2.0-flash across 3 endpoints with 8+ system prompts for contextually absurd reviews, appeal denials, and code roasts
Bring…

View on GitHub

Project Structure

src/
├── app/
│   ├── api/
│   │   ├── review/route.ts       # Main review endpoint (Gemini AI)
│   │   ├── appeal/route.ts       # Appeal escalation endpoint (Gemini AI)
│   │   └── roast/route.ts        # Code metrics roast endpoint (Gemini AI)
│   ├── 418/page.tsx              # 🫖 Easter egg
│   ├── not-found.tsx             # On-brand 404
│   ├── layout.tsx                # Root layout
│   └── page.tsx                  # Main orchestrator
├── components/
│   ├── PRHeader.tsx              # PR breadcrumb & labels
│   ├── CodeInput.tsx             # Code editor with line numbers
│   ├── SamplePRSelector.tsx      # 10 sample PR picker
│   ├── ReviewerSwitcher.tsx      # 5 persona selector
│   ├── ApiKeyInput.tsx           # Gemini API key input (localStorage)
│   ├── LoadingTheater.tsx        # 12-stage pipeline animation
│   ├── VerdictCard.tsx           # Review verdict display
│   ├── CheckRunList.tsx          # Fake status checks
│   ├── ReviewComments.tsx        # Inline review comments
│   ├── MergeBox.tsx              # Permanently blocked merge button
│   ├── AppealFlow.tsx            # 3-round appeal escalation
│   └── RoastDashboard.tsx        # Enterprise metrics roast
└── lib/
    ├── types.ts                  # TypeScript interfaces
    ├── sample-prs.ts             # 10 sample PRs, 5 personas
    ├── fallback.ts               # Review fallback (80+ jokes)
    ├── appeal.ts                 # Appeal prompts + fallback
    ├── roast.ts                  # Roast prompts + fallback
    ├── prompts.ts                # Gemini prompt builders
    └── ai.ts                     # Gemini API integration

How I Built It

The Multi-Agent Gemini Architecture

This isn't a single API call to Gemini with "be funny." MergeGuardian uses 3 distinct Gemini-powered endpoints, each with a different AI "role" and system prompt:

Endpoint	AI Role	What It Does
`POST /api/review`	Code Reviewer	Reads your actual code, generates verdict + checks + comments + block reason
`POST /api/appeal`	Merge Arbitration Officer	Reviews your appeal against the original block, always denies with escalating absurdity
`POST /api/roast`	Code Quality Analyst	Generates fake enterprise metrics with devastating per-metric explanations

Every endpoint follows the same pattern:

Build a persona-specific system prompt
Send code + context to gemini-2.0-flash via the Google Generative AI SDK
Get structured JSON back via responseMimeType: "application/json", Gemini's native structured output mode
If Gemini fails (rate limit, timeout, no key), fall back to handcrafted template engine

The fallback engines aren't afterthoughts. Each one has its own curated joke bank: 80+ review comments across 5 categories (bureaucratic, anthropomorphic, metrics, passive-aggressive, philosophical), 14 fake checks, 16 block reasons, 18 impossible next steps, 24+ appeal denial rulings, and a full library of fake enterprise metrics. The app is hilarious with or without an API key.

Here's how the review prompt works under the hood:

// Each persona gets a tailored system prompt
const PERSONA_PROMPTS = {
  guardian_core: "You are balanced but firm. Every PR has potential, but none 
    are ready. Reference fake standards like 'Guardian Policy 7.4.2'...",
  compliance_beast: "You see policy violations everywhere. Reference audit 
    trails, SOC2, change management protocols...",
  passive_aggressive_teammate: "Phrase everything as friendly suggestions 
    that are absolutely requirements. Use 'just a thought' and 
    'totally up to you' liberally. You are smiling while blocking."
};

The appeal system uses escalating round-based prompts. Round 1 is bureaucratic ("Your appeal has been forwarded to the Department of Merge Ethics. Average response time: 6-8 business millennia."). Round 2 gets philosophical. Round 3 goes full existential. Each round is a separate Gemini call with a different system prompt, so the AI's personality genuinely shifts as you escalate.

The Google AI Toolchain

Building 8+ system prompts for different AI characters is a lot of prompt engineering. Google AI Studio was the backbone of that process. I used the chat playground to prototype every persona voice, swapping system instructions to A/B test whether the Compliance Beast sounded different enough from the Staff Engineer of Doom. I validated that Gemini's structured output mode could handle complex nested JSON. Arrays of checks. Inline comments. Metric objects. All reliably typed. When a prompt needed iteration, I could edit the system instruction and re-run the same user input instantly.

I also used Gemini CLI (npx @google/gemini-cli) for rapid prompt testing straight from the terminal. When I wanted to quickly test how a persona responded to a specific code snippet without context-switching to the browser, I'd pipe code directly into Gemini from the command line. Useful for fast iteration on edge cases, like making sure the AI Optimizer persona generates fake metrics with decimal precision even for a one-line function.

I explored a few other Google AI features during development that didn't make the cut. Nano Banana, Google's image generation model, was tempting. I considered having it generate fake "architecture violation diagrams" as part of the review. Imagine a UML diagram of why your code is spiritually misaligned. But in testing, the text roasts were funnier than any image could be. We also looked at function calling for simulating tool-use patterns in reviews, code execution for actually running the submitted code and roasting the output, and Google Search grounding for finding real coding standards to parody. In each case, the simpler approach won. The comedy comes from Gemini playing a character and committing to the bit, not from adding complexity.

For deployment, the app is Google Cloud Run-ready. The repo includes a multi-stage Dockerfile optimized for Next.js standalone output and a cloudbuild.yaml for automated builds via Google Cloud Build. One gcloud builds submit and the app is live on Cloud Run with auto-scaling, managed TLS, and the free tier covering 2 million requests per month. The live demo runs on Vercel for convenience, but the Cloud Run configs are there and tested. Full Google stack, top to bottom.

The Stack

Technology	Role
Google Gemini API (`gemini-2.0-flash`)	AI generation (3 endpoints, 8+ system prompts, structured JSON output)
Google AI Studio	Prompt prototyping, system instruction editing, structured output validation, persona A/B testing
Gemini CLI (`npx @google/gemini-cli`)	Rapid terminal-based prompt testing during development
Next.js 14 (App Router)	Framework
TypeScript (strict mode)	Language
Tailwind CSS v3	Styling (custom `guardian` color palette)
Lucide React	Icons
Vercel	Deployment

Why It's Not Just "Call Gemini and Be Funny"

The entire comedy engine runs on Gemini playing characters. Not templates. Not mad-libs. The AI reads your code, inhabits a persona, and improvises within a structured JSON schema. That's what makes every review different.

Per-persona prompt engineering. Five distinct system prompts, each producing genuinely different blocking patterns. The Compliance Beast cites fake audit trails. The AI Optimizer invents metrics to false precision. The Passive-Aggressive Teammate smiles while destroying your confidence.

Structured JSON output. Gemini doesn't return a blob of text. It returns typed JSON with verdict, checks, comments, block reasons, and next steps via responseMimeType: "application/json". Every field maps to its own UI component. No parsing. No regex. No "please format your response as JSON." Just Gemini's native structured output mode. This is a key Google AI feature that made the whole architecture possible, letting AI-generated comedy flow directly into typed React components.

Graceful degradation. Every Gemini endpoint has a matching fallback generator that produces the exact same JSON shape. If the API is down, the demo still works perfectly. You'll never see an error state.

Three distinct AI roles. The reviewer, the arbitration officer, and the metrics analyst each have different system prompts, different response schemas, and different comedy patterns. This isn't one trick repeated three times.

Honestly, the whole reason this project exists is because Gemini turned out to be surprisingly good at playing different characters. I started with one API call and ended up with three endpoints because each "reviewer persona" needed its own voice, its own system prompt, its own response format. I prototyped all of them in Google AI Studio first, tweaking system instructions and testing structured output until the JSON was reliable and the jokes were landing. The structured JSON output made it possible to pipe AI-generated comedy directly into typed UI components without parsing nightmares. That rabbit hole is what made the project fun to build.

And I think it's fun to use because every developer has lived this. The reviewer who blocks your typo fix over "architectural implications." The one who says "just a thought" and then marks it as a blocker. MergeGuardian takes that universal pain and turns it into something you can screenshot, tweet, and argue about in Slack.

Prize Category

Best Google AI Usage

I'm submitting for Best Google AI Usage because Google Gemini isn't a feature of MergeGuardian 9000. It is MergeGuardian 9000. The entire comedy engine is Gemini playing characters and committing to the bit. Not templates. Not mad-libs. Every review is improvised.

Here's the full scope of Google AI integration:

3 Gemini-powered API endpoints, each acting as a different AI agent. The code review endpoint has 5 persona-specific system prompts. The appeal endpoint has 3 round-based system prompts that shift from bureaucratic to philosophical to existential. The roast endpoint generates structured metric data with AI explanations. That's 8+ unique Gemini system prompts across the app.

Every endpoint uses Gemini's native structured JSON output (responseMimeType: "application/json"). The AI returns typed objects with verdicts, arrays of checks, inline comments, metric scores, and denial rulings. No string parsing. No regex extraction. Just structured data flowing directly into React components.

All prompt engineering was done in Google AI Studio. Every persona voice was prototyped in AI Studio's chat playground. I used system instruction swapping to A/B test persona voices, validated complex nested JSON schemas in structured output mode, and iterated appeal escalation prompts until the comedic arc from Round 1 to Round 3 landed right. AI Studio was the prompt workshop. The codebase was just the final deployment.

I used Gemini CLI (npx @google/gemini-cli) for fast terminal-based prompt testing. When I needed to check how a specific persona handled a code snippet without opening AI Studio, I'd test it right from the command line. Great for edge cases and quick iterations.

The app has a Bring Your Own Key feature that links directly to Google AI Studio's API key page. Users grab a free key, paste it in, and unlock AI reviews. The Gemini free tier (60 requests/minute, 1,000/day) runs the entire app at zero cost. No billing required. No API key required for the demo either, since the fallback engine serves the same JSON shape.

I chose Gemini 2.0 Flash specifically for speed. It responds in 1-3 seconds, which means the fake 12-stage "Enterprise Review Pipeline" loading theater genuinely takes longer than the actual AI generation. The model handles persona-switching through system prompts remarkably well. Five genuinely different reviewer voices from one model.

We explored other Google AI capabilities too. Function calling for simulating tool-use patterns in reviews. Code execution for actually running submitted code and roasting the output. Google Search grounding for finding real coding standards to parody. Nano Banana for generating fake architecture violation diagrams. In each case, the simpler approach was funnier. The comedy works because Gemini inhabits a character and stays in character. Adding more features would have diluted that.

The final count: 3 Gemini-powered endpoints, 8+ system prompts, structured JSON on every call, AI Studio for prototyping, Gemini CLI for testing, Cloud Run deployment configs in the repo, BYOK with an AI Studio link, and the entire thing running on the free tier. Every review, every appeal denial, every devastating metric explanation. That's all Google.

No code was actually approved in the making of this application. Approval rate: 0.00%.

Schedio – Highlight to Calendar in 5 Seconds

Arqam Waheed — Sat, 14 Feb 2026 13:36:00 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I created a Google Chrome extension that instantly turns any highlighted text on a webpage into a Google Calendar event - no tab switching, no copy-pasting, no friction.

I thought of this idea because adding events on google calendar takes me way more time than it needs to, and there was no solution for this problem in a convenient way like I needed. I was sure that other people with no technical depth must be facing this issue to, so I decided to change that.

Schedio was built almost entirely by GitHub Copilot CLI, while I only handled setup tasks like OAuth, agent documentation, the product requirements and a little bit of manual debugging. By prompting Copilot effectively, I focused solely on the design aspects — almost no code had to be written manually, except for minor adjustments like time conversion fixes.

With schedio you just have to:

Highlight a meeting time
Right-click → "Create Event with Schedio" (or use the keyboard shortcut)
Review the pre-filled details in a sleek modal
Click "Create Event" → the event lands in your Google Calendar instantly

The project is currently under review for Chrome Web Store publication, but the source is public on my Github repo. Follow the README for setup instructions!

I will be updating this post as soon as the review is done and link the chrome extension for ease of access.

📹 Demo

Here’s a live demo of Schedio in action:

At the time of writing, Schedio isn’t yet published on the Chrome Web Store, so setup requires following the instructions in my GitHub repo. Once you’ve completed the setup, using Schedio is simple:

1) Go to Schedio Options and enter your Gemini API key to enable AI parsing. There is a public shared API key, but it may be rate-limited, so it’s recommended to add your own — it’s free!

2) Highlight text on any webpage containing event information.

3) Right-click and select "Create Event with Schedio" (or use the keyboard shortcut Alt+Shift+S). The shortcut can also be customized through the options page.

4) A sleek modal pops up, pre-filled with AI-parsed details like title, date, time, and location.

5) Review the details and click "Create Event". The event is added instantly to your Google Calendar. You’ll only need to link your Google account via OAuth the first time — after that, creating events is seamless.

My Experience with GitHub Copilot CLI

Building Schedio was my first time shipping a full Chrome extension, and it involved a lot more moving pieces than I expected. OAuth flows, Chrome extension permissions, background scripts, content script messaging, AI parsing, and Google Calendar integration all had to work together seamlessly.

I used GitHub Copilot CLI to generate most of the implementation, but I did not treat it like autopilot. I defined the architecture, structured the prompts carefully, and reviewed everything it produced. When something broke, I debugged it myself.

One issue that stood out was a silent failure when creating calendar events. The modal worked, the parsed data looked correct, but the event simply was not appearing in Google Calendar. There were no clear errors. After tracing logs across the background script and OAuth token flow, I realized the access token was expiring earlier than expected and the refresh logic was not being triggered properly. Copilot had scaffolded the initial OAuth integration, but I had to step in, inspect the token lifecycle, and restructure the flow so the token was validated before every API call. Once fixed, event creation became consistent and instant.

Another time, AI-parsed times were being converted incorrectly for users in different time zones. Instead of patching it blindly, I isolated the formatting logic, tested edge cases, and adjusted the conversion logic to normalize everything before sending it to Google Calendar.

Using Copilot CLI did not remove responsibility completely, but it was able to help me ship schedio WAY FASTER than I could ever have before. I felt a lot more productive using copilot.

Beyond Development

The help didn’t stop at coding. Copilot made it possible to ship a complete product fast. I used it to generate branding ideas, logo prompts, privacy policy drafts, and even content for demo posts. Normally, figuring all that out would take hours of brainstorming and trial-and-error. Instead, I could feed suggestions into tools like Nanobanana, tweak them, and get polished results. In just a few days, I went from concept to a fully working, branded extension with marketing-ready copy.

This approach didn’t just make development faster but it also let me release a polished, full-featured product on my first try while keeping the user experience smooth and seamless.