DEV Community: Faris

Everyone Wanted to Help. Nobody Had the Whole Plan

Faris — Sat, 24 Oct 2026 19:22:07 +0000

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

What I Built

Alex sees the appointment change. Maya sees the request for a ride. Sam assumes someone else has the groceries covered. Robin checks the chat after work and scrolls through yesterday's messages, trying to find which plan is still current.

These are fictional people in CareRelay's synthetic demonstration. The burden they represent is familiar: the work of helping includes a second, repetitive job of remembering who said what, checking what changed, and finding out whether someone actually agreed to help.

CareRelay is a local family coordination prototype. It turns pasted messages into suggested appointments, transport, errands, pickups and confirmation tasks. A person reviews the evidence and approves each item before it reaches the shared plan. A caregiver then accepts their own responsibilities. Those are two different decisions, and the application keeps them separate.

Demo

Watch the complete CareRelay demonstration on YouTube.

The demonstration was recorded at 1920×1080 with real local model inference and synthetic family messages. The 108-second export uses Kokoro-82M narration with the am_fenrir voice and an English subtitle track. Only the unused closing hold was trimmed; the visible actions and model-processing wait were preserved. The recording script, silent source, narration, captions and final video are included with the project.

The recorded journey follows a clinic appointment change, a proposed driver whose work shift overlaps the journey, and an unassigned return ride. Robin explicitly accepts her own library pickup. The original appointment becomes cancelled when its replacement is approved. The final handoff keeps that accepted commitment separate from the unresolved replacement appointment and its transport question.

Code

CareRelay source code, setup instructions and demonstration assets

The MIT-licensed application uses Next.js, TypeScript, Tailwind, a shadcn-style button component, FastAPI, Pydantic and SQLite. The repository includes the labeled synthetic dataset, evaluation reports, recording script, screenshots and narrated video. Model weights retain their upstream licenses. The README documents manual local startup; the optional Docker Compose configuration has not been verified.

How I Built It

I used Ministral 3 14B through Ollama, an Apache 2.0 open-weight model. The core inference operation produces structured coordination suggestions from actual source text. There is no fake-response fallback in the application.

A typed JSON schema constrains the response, but valid JSON alone is insufficient evidence. The backend checks that every quote is an exact contiguous substring of the imported source and that the source ID matches. A failed evidence check rejects the result before suggestions are written. Interpreted dates carry an explicit review warning. A name in a model result does not constitute consent.

The review queue is deliberately central. The reviewer can correct the title, date, location, proposed owner and unresolved details. Approval places an item on the plan. Acceptance is a separate action reserved for the proposed caregiver, or a volunteer when the task is unassigned.

That distinction changes the familiar task-board interaction. A task can be perfectly understandable and approved while still having nobody committed to doing it. CareRelay displays that gap instead of filling it with a reassuring name. Unclaimed transport gets an explicit warning; the calendar is a view of the approved plan rather than a second independent source of truth.

Availability is intentionally modest. Caregivers record windows when they are unavailable. The conflict check compares proposed tasks against those windows and against each other, using a documented one-hour planning window. It does not pretend to know travel times, appointment duration or whether two nearby errands are realistically compatible. A warning is a reason to check with someone, not a scheduling verdict.

Cancellation and rescheduling retain the original record. A reviewer chooses the original approved item, which is cancelled when its replacement is approved. Acceptance resets for the replacement. Transport remains a separate responsibility; changing an appointment never silently means a driver has accepted a different journey.

Handoffs take a conservative approach to factuality. The local model returns references to supplied approved tasks. The backend validates those references and renders the brief deterministically from approved records, including all relevant tasks to prevent omissions. Private sources never enter a shareable brief. Draft approval records task versions; if the plan changes, the user must generate a fresh handoff.

I deliberately avoided asking the model to turn the board into unrestricted prose. A beautifully written handoff that quietly drops an unassigned ride is worse than a plain list that keeps it visible. The model can help select references, but it cannot introduce new facts into the renderer or erase approved tasks by leaving them out. The resulting message is less literary and easier to audit.

The backend also draws a boundary around each imported source. A source is shared with the circle or private to its importer. A coordinator is not automatically allowed to read another person's private material. Import, review and briefing permissions are checked on the server, and responsibility acceptance is restricted to the person concerned. The activity view shows the signed-in person's own events. None of these decisions depend on a hidden button in the browser.

The implementation stays small enough to run locally: parameterized SQLite queries and transactions, explicit state transitions, Pydantic request validation, and an in-process inference job. An identical source with the same reference timestamp is not repeatedly imported. If inference fails, the job remains visibly failed and can be retried. A server restart marks unfinished jobs for retry instead of presenting them as completed work.

The current prototype is intended for fictional data on a trusted local machine. It does not yet provide production identity verification or encrypted storage. The demo's profile switcher exists to demonstrate consent and permission boundaries, not to claim independent authentication for real households.

The interface was revised after visual review: white and slate surfaces, teal accents, sans-serif headings, larger controls, and clearer secondary text. All 23 deterministic backend/evaluation tests, TypeScript checking, a full production build and a genuine Chromium journey pass. Desktop and mobile screenshots were inspected at 1440×1000 and 390×844, with no detected horizontal mobile overflow or browser page errors.

Measurement also changed the implementation. The initial 32-message synthetic evaluation scored 77.8% strict category precision and recall. Confirmations were sometimes classified as appointments; cancellations sometimes changed the task category; the model sometimes assumed UTC even though the source reference carried a local timezone.

The extraction instructions now define categories by the requested action and explicitly supply the reference timezone. A later development run measured 92.9% precision and 96.3% recall, with 26 true positives, two false positives and one false negative. Owner attribution was 11/12, explicit timestamps 21/22 and change operations 3/3. The complete outputs and code/dataset hashes are preserved in the project.

Those are development-set measurements, not held-out accuracy: the prompt was refined after inspecting the same corpus. One remaining disagreement concerns whether collecting groceries should be a pickup or an errand; the original reference label was retained. A separate extra suggestion arose from a request to check availability. Missing or multiple predictions count against the applicable field metrics rather than disappearing from the denominator.

The recorded reschedule also produced an unsupported ride cancellation suggestion. The quote was genuine, but the source had requested a separate transport check, not cancellation. That suggestion was rejected. This is why source provenance and semantic correctness are different checks, and why approval remains a real decision rather than a decorative button.

Why Does Open Innovation Matter?

Local weights let this coordination workflow run without sending family messages to a paid inference service. The model can be replaced and the extraction measured against the included labeled synthetic corpus. The schemas, validators, prompts and decision boundaries are visible in the source rather than hidden behind a claim that the model will simply get the details right.

The useful question is not whether an AI can produce a plausible plan. It is whether the people doing the work can see why an item exists, correct it, and decide whether they are willing to own it.

There is also value in being able to keep the successful and unsuccessful runs side by side. The initial model report has not been replaced with a polished headline number. Its mistakes explain the stronger timezone instruction, category editing, and the continued need for review. The prompts, raw structured outputs, validators and measured results travel with the source, so another builder can reproduce the exercise rather than accepting my preferred example.

Open weights do not make the application trustworthy by themselves. They make inspection and replacement possible. The trust comes from the smaller surrounding decisions: preserve the quote, expose uncertainty, distinguish approval from consent, and refuse to call an unfinished responsibility resolved.

The Lazy Payoff

The intended payoff is fewer rounds of reconstructing the same conversation. Imported messages become a single review queue, approved responsibilities appear together, and the next caregiver can start from a brief that distinguishes commitments from unresolved details.

No household time savings have been measured. The included examples are synthetic demonstrations, not live-family trials or evidence of improved health outcomes.

Alex still has to ask whether Maya can drive. Robin still has to decide whether she can help. CareRelay leaves those decisions with them. The smaller relief is having one place to see which questions still need an answer, without asking everyone to reconstruct the conversation again.

Prize Categories

I am entering the overall Week 3 challenge. No partner prize category is claimed because no qualifying partner integration is implemented.

Reading or Guessing? An Urdu Font-Twin Benchmark

Faris — Sun, 11 Oct 2026 12:29:51 +0000

This is a submission for the Kaggle Benchmarking Challenge.

Urdu OCR has an unusually revealing stress test built into its typography. Nastaliq is diagonal, context-heavy, and visually dense; Naskh is more linear. If a multimodal model is truly reading the glyphs, changing only the font should not change its transcription very much. If it is filling gaps with language priors, the difference may grow when the text stops being predictable.

That led to one deliberately narrow question:

Will a model transcribe the exact same Urdu Unicode string differently when it is rendered in Nastaliq instead of Naskh?

What I Benchmarked

I built a paired multimodal OCR benchmark with three language conditions:

Natural: revision-pinned Urdu Wikipedia sentences.
Shuffled: the same words in a deterministic shuffled order.
Pseudo: deterministic Urdu-like character sequences that preserve spaces, punctuation, and token lengths while removing ordinary word predictability.

Every item is rendered twice: once in Noto Nastaliq Urdu and once in Noto Naskh Arabic. The two images in a pair contain the exact same NFC-normalized Unicode string and share a source-text SHA-256. The prompt is also identical: transcribe only what is visible, with no source text or font hint supplied to the model.

The pilot has 15 source items x 3 conditions x 2 fonts = 90 images, organized as 45 exact-text font pairs.

Rendering was part of the experiment

This benchmark would be meaningless if one font silently fell back, clipped glyphs, or simply rendered smaller. Before making model calls, I therefore:

shaped every string with HarfBuzz using explicit rtl, Arab, and ur properties;
rasterized those glyph IDs directly with FreeType, preventing operating-system font fallback;
verified character coverage, GSUB/GPOS tables, ligatures, RTL cluster order, image bounds, and nonblank output;
calibrated each font against visible text height instead of assigning the same nominal point size; and
generated a contact sheet for human inspection.

Offline validation passed all 90 images and 45 pairs, with no missing codepoints, fallback, Unicode mismatch, clipping, or blank render.

The text is public and traceable. Each natural sentence records its Urdu Wikipedia page URL and revision ID under CC BY-SA 4.0. I did not add examples from the Urdu Newspaper Benchmark because its linked public data did not expose a dataset license that I could verify.

Scoring policy

The primary metric is paired Nastaliq CER minus Naskh CER. A positive gap means the model made more character errors on Nastaliq for the same source string. I also compute WER, insertions, deletions, substitutions, pseudo-word hallucinations into real words, paired bootstrap confidence intervals, and paired sign-flip tests.

Scoring uses Unicode NFC and whitespace normalization. It does not merge distinct Urdu and Arabic letters such as U+06CC/U+064A, U+06A9/U+0643, or U+06C1/U+06BE.

Two simple vision canaries, a large number and a short Urdu word, run before the benchmark. Endpoints that fail them are reported separately instead of being assigned an OCR score.

Models Tested

I queried Kaggle's available 46-model catalog. The first expansion pass reached Kaggle's daily AI quota, so the current paired analysis includes the seven endpoints that completed all 90 image prompts:

Anthropic Claude Haiku 4.5
Anthropic Claude Haiku 5.5
Anthropic Claude Sonnet 5
Anthropic Claude Sonnet 5.5
Google Gemini 3.5 Flash-Lite
Google Gemini 3.7 Flash
OpenAI GPT-5.4 Mini

Four of these also completed all 45 masked text-only prior controls. Partial image runs are retained for audit but excluded from the paired plots. Missing results are never imputed. The retry task uses a larger canary token allowance for reasoning models and will continue after quota refresh.

That incompleteness is worth stating plainly: this is a validated pilot and an in-progress 46-model evaluation, not a finished universal ranking.

Findings

The clearest completed run was Gemini 3.7 Flash. Its mean Nastaliq-minus-Naskh CER gap was:

Condition	Paired CER gap	95% bootstrap interval
Natural	+0.18 points	[0.00, 0.47] points
Shuffled	+0.25 points	[0.00, 0.54] points
Pseudo	+8.75 points	[4.05, 12.82] points

Its pseudo-word WER gap was +40.89 points. Nastaliq pseudo-word outputs introduced nine natural-lexicon words absent from the references; Naskh introduced none. For this model, removing linguistic predictability exposed a much larger font gap than the natural and shuffled conditions.

The multi-model picture is more interesting than a single clean headline:

Image-complete model	Pseudo CER gap	95% bootstrap interval
Claude Haiku 4.5	+21.8 points	[17.0, 26.6]
Claude Haiku 5.5	+4.9 points	[-6.5, 15.6]
Claude Sonnet 5.5	+35.9 points	[16.4, 57.0]
Claude Sonnet 5	-12.5 points	[-33.5, 10.2]
Gemini 3.5 Flash-Lite	+12.9 points	[9.8, 16.3]
Gemini 3.7 Flash	+8.8 points	[4.1, 12.8]
GPT-5.4 Mini	+12.0 points	[8.6, 14.9]

Five of seven image-complete models had a positive pseudo-word interval excluding zero. Two did not support that direction, including one negative point estimate with a wide interval. Several Claude runs also showed substantial gaps on natural or shuffled text, which warns against reducing every font effect to language-prior reliance.

What surprised me

I expected pseudo-words to be harder. I did not expect the difference between fonts to expand so sharply for several models while remaining small or unstable for others. The font is not just cosmetic input formatting; for some multimodal systems it changes the effective task.

The canaries were also informative. A model name appearing in a multimodal catalog does not guarantee that an endpoint will accept images, allocate enough visible output tokens, or follow an exact-transcription instruction. Separating endpoint failures from OCR errors prevented infrastructure behavior from becoming a fake accuracy score.

What I would measure next

The next run will complete the retry-eligible endpoints, add 0.5x and 0.25x resolution strata, and increase the source set from 15 to 60 items. I also want to add Tesseract Urdu and a public UrduOCR checkpoint, but only when the executable/model artifact and its reuse license are verifiably available. The core analysis will remain paired: the question is not merely which model has lower CER, but whether the same model reading the same string changes when only its Urdu font changes.

Video Walkthrough

Watch the walkthrough on YouTube, or download the two-minute MP4 from GitHub.

My Benchmark

The Kaggle task, code, reproducible assets, font-validation report, and current run history are here:

Kaggle Benchmark: Reading or Guessing? Urdu Font Twins, version 9
Source and reproducibility bundle: syncaimain/urdu-font-twin-benchmark

The repository includes the deterministic renderer, source manifest, font licenses, canaries, metric implementation, analysis scripts, tests, contact sheet, and machine-readable status ledger. No benchmark score in this post is estimated or filled in from missing data.

The experiment started with a typography question, but it ended up probing something broader: when a vision-language model produces the right word, how much of that answer came from seeing the letters, and how much came from knowing what word ought to be there?

I hard-killed my hiking safety app mid-trip. The alert still went out.

Faris — Fri, 09 Oct 2026 19:57:26 +0000

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

What I Built

The oldest piece of outdoor safety advice is also the most ignored: tell someone where you're going and when you'll be back. The problem is that "someone" has to remember, has to notice you're late, and has to know what to do about it.

TrailWatch is that someone. It's a hiking check-in timer that can't forget about you.

Before you leave, you type one sentence: "Monk's Trail up Doi Suthep, solo, back by 5ish."
Gemma, running locally, turns that into a plan: return time, turnaround time, how often to check in, and tips based on tonight's sunset and the forecast.
You put your phone away. That's the whole point. You only need the phone again if a notification asks "Are you OK?", and you answer it from the lock screen with one tap.
If you miss a check-in, TrailWatch nudges you, waits a grace period, then alerts your emergency contact. First it sends a plain template message instantly. Then it sends a situation brief written by Gemma from the trip log. When you get signal back and tap I'm OK, your contact gets an all-clear.

The screen time for a whole hike is about thirty seconds: one sentence before you go, and maybe one tap on the trail.

The interesting part isn't the AI. It's this: a safety timer that lives in a normal process is a safety timer that can silently die. A laptop sleeps, a server reboots, a phone's battery saver kills your app. The one moment the system must work is when you're out of signal and nobody's watching. So I built TrailWatch so the timers can't be lost, and then I tried hard to break it.

Demo

That's one real run, recorded in a single take. Local Gemma plans the trip, Temporal runs the workflow, and real pushes go through ntfy.sh. There are two tricks, and both are shown on screen:

The clock is compressed. One "trip minute" is 2 seconds, so a 40-minute walk fits in under two minutes. It's the same code path as real time; only the timer lengths are scaled.
The worker-is-dead stretch plays at 4× speed (labelled in the corner). Nothing interesting happens there, and that's the point.

The voice-over is Piper, an open-source text-to-speech model, running offline on the same laptop.

What happens:

Gemma arms the trip: check in every 15 min, grace 15 min.
I hard-kill the worker (TerminateProcess, no cleanup). Nothing is running TrailWatch code.
The phone view notices and says so: your timers live on the Temporal server and are still running.
The check-in deadline passes. Then the grace period passes. The alert is now overdue, and there is still no worker.
I restart the worker. Temporal replays the history, sees both timers already fired, nudges the hiker and alerts the contact. The alert went out about 10 seconds after the worker came back.
Gemma's brief arrives, the "hiker" taps I'm OK, and the contact gets the all-clear.

And here's the event history for that run in the Temporal UI. Event 64 is the "I'm home" signal from the phone. Event 68 is the last durable timer being cancelled because of it. Every send_notice result says pushed to https://ntfy.sh/....

This is a real brief Gemma 3 4B wrote for the contact during an earlier kill-test run, unedited:

Ali is overdue from a solo hike up the ridge behind campus, which was scheduled to return by 23:54. Ali started the hike at 23:14 and was last heard from at 23:14. Their last known location is unknown. Sam, please attempt to contact Ali immediately. If you do not reach Ali within 15 minutes, contact local emergency services.

(Ali and Sam are demo personas.)

Code

syncaimain / trailwatch

A hiking check-in timer that can't forget about you: local Gemma + Temporal durable workflows + ntfy

TrailWatch

A hiking check-in timer that can't forget about you.

Tell it where you're going and when you'll be back, in your own words. A local Gemma model turns that into a plan: return time, turnaround time, how often to check in, and safety tips based on sunset and the forecast. Then you put your phone away.

Each trip is a Temporal workflow. It sleeps on durable timers until a check-in is due. If you don't tap I'm OK, it nudges you waits a grace period, then alerts your emergency contact: first with a template message (instantly, no AI on the critical path), then with a situation brief written by local Gemma. When you surface and tap OK, your contact gets an all-clear.

Kill the worker, restart the web app, reboot the Temporal server mid-hike: the timer still fires.

TrailWatch is a prototype. It is not a replacement for…

View on GitHub

The safety logic is in two files: trailwatch/workflows.py (the durable workflow) and trailwatch/rules.py (the deterministic rules the model can't override). pytest runs 12 tests. scripts/kill_test.py reproduces the video on your machine.

How I Built It

Stack: Gemma 3 4B via Ollama, on a laptop with a 6 GB RTX 3050 · Temporal (Python SDK, local dev server) · ntfy for push notifications with action buttons · Open-Meteo for sunset and weather · FastAPI and one HTML file.

phone (web page or ntfy lock-screen buttons)
   │  start trip · I'm OK (signal) · +30 min (update) · SOS · I'm home
   ▼
FastAPI (stateless) ──► Temporal server ◄── worker
                         one HikeWorkflow per trip
                         ├─ fetch_conditions  Open-Meteo sunset + weather
                         ├─ plan_trip         local Gemma → rules clamp it
                         ├─ durable timers    check-in / grace / re-alert
                         ├─ send_notice       ntfy push, retried until it lands
                         └─ write_briefing    Gemma situation brief

One workflow per trip

Every trip is a Temporal workflow, and every Temporal feature I used is doing a real job:

Temporal feature	What it does in TrailWatch
Durable timers	Check-in deadlines, grace periods and re-alerts every 30 min. They live on the server, not in my process.
Signals	I'm OK, SOS, I'm home and Cancel, sent from the web page or straight from ntfy's lock-screen buttons.
Update + validator	"+30 min" returns the new return time to the phone. The validator rejects nonsense like +500 min, or more than 6 h total.
Query	The web page reads live trip state from the workflow itself. There is no database.
Activity retries	Gemma cold starts, out-of-memory errors and bad JSON retry with backoff, then fall back to a regex planner. Pushes retry for up to an hour.

The heart of it is a timer racing an inbox:

async def _wait_until(self, trip_min: float) -> bool:
    """Durable timer racing the inbox. True if a check-in arrived first."""
    if self.inbox:
        return True
    seconds = (trip_min - self._elapsed()) * self.req.minute_seconds
    if seconds <= 0:
        return False
    try:
        await workflow.wait_condition(lambda: bool(self.inbox), timeout=timedelta(seconds=seconds))
        return True
    except asyncio.TimeoutError:
        return False

That wait_condition timeout is a durable timer. If the worker dies while it's waiting, nothing is lost. The timer fires on the server, and whichever worker comes back next picks up from exactly that line.

The AI is never on the alert's critical path

Gemma does two jobs: turning a casual sentence into a plan, and writing the brief for the contact. It does not decide whether to alert, and the first alert never waits for it:

The alert itself is a template, sent instantly.
Then, best effort, Gemma writes the context-rich brief. If Gemma is down, the contact already has what they need.

A cold Gemma load on my laptop takes about 70 seconds. That's fine for planning at home, and unacceptable on the alert path.

The model proposes, the code decides

Gemma's plan goes through rules.py before anything is armed. The model can suggest anything, but it can't:

set check-ins longer than 60 min on a solo trip, or 45 min on a high-risk one
lower the risk level that the sunset or wind implies
pick a turnaround time that leaves no time to walk back

Every rule has a test, and most of them exist because Gemma broke something.

Three bugs worth telling you about

1. "Turn around at minute 1440." For a three-hour hike, Gemma 3 4B proposed a turnaround time of 1440 minutes, a full day later. Fix: a turnaround has to land in the first 75% of the trip, or it's replaced with the halfway point.

2. "Back in 40 minutes" → back at 12:39 tomorrow. At 23:00, Gemma turned "back in 40 minutes" into expected_return_local: "12:39" and, in the same reply, duration_min: 40. My parser trusted the clock time, so the hiker would have been reported missing 13 hours late. I only caught this because the kill-test run printed the plan. Fix: when the model's clock time and duration disagree, use the earlier one. A false alarm is better than a late one.

3. My own bug: downtime pushed alerts later. My first version started the grace period after the nudge was sent. If the worker was dead through the deadline, the nudge went out late when it restarted, the grace period started from there, and the alert came a full grace period late. Durable timers don't help if you measure from the wrong moment. Fix: grace is counted from the missed deadline, which is fixed in the workflow's history, so downtime can never delay an alert. There's now an integration test that keeps the worker dead through both deadlines and checks that the alert fires the moment it's back.

In one test, Gemma also called a 10% chance of rain "significant." That's why tips are just advice and warnings come from code.

Tests

Time-skipping: Temporal's test server runs a 6-hour silent hike in seconds. It checks the contact gets exactly 10 alerts (one at 75 min, then every 30 min) and only one Gemma brief.
Worker death: a real dev server with a compressed clock. The worker is shut down through the deadline and the grace period, and the test checks the alert fires on restart.
Rules: real Gemma mistakes, kept as regression tests.

Why Does Open Innovation Matter?

Because this app knows when you're alone and where you'll be. A trip plan is "this person will be by themselves on this ridge until 5 pm, and nobody will be home." I don't want that in someone else's logs. With TrailWatch, the model runs on my laptop, Temporal is open source and self-hosted, ntfy can be self-hosted, and the weather comes from open data. Nothing in the safety path depends on a vendor's uptime, pricing or terms of service.

Because a safety tool shouldn't cost a subscription. Running TrailWatch costs nothing. A small open-weight model is enough because the architecture keeps it off the critical path: it plans and explains, while code and durable timers make the decisions.

Because I could see how it fails. Running Gemma locally, I could hammer it, watch it make the 1440-minute mistake and the 12:39 mistake, and turn each into a rule and a test. Swapping models is one environment variable: any Ollama model, or any OpenAI-compatible endpoint, including hosted Gemma.

Where a closed API would have been better: honestly, speed and judgment. A big hosted model would plan in about 2 seconds instead of 10–35, and would probably not suggest turning around tomorrow. But for this problem I'll take a model I can run, inspect and constrain over one that's merely smarter.

Honest limits

This is a prototype, not a satellite messenger or a PLB. It needs your phone to get a push now and then. Losing signal is exactly the situation it alerts on, but it can't call for help from a valley by itself.
The video uses a compressed clock. The code path is the same as real time, but it's still a demo.
ntfy topics are like passwords on the public server. Use long random ones, or self-host ntfy. I added an access key before putting the app behind a tunnel, so a leaked URL can't cancel your trip.
Push delivery is at-least-once. If the worker dies mid-push, a retry can send a duplicate. In my runs, the push that was in flight when I killed the worker arrived exactly once, but I don't promise that.

My Agent Session

I built TrailWatch pair-programming with an AI coding agent (Claude Code). That session is also where the bugs above were found: the agent wrote the kill test, read Gemma's real output, and flagged the grace-period bug in its own earlier code.

Prize Categories

Best Use of Temporal: each trip is a durable workflow using timers, signals, an update with a validator, queries and retry policies, with a hard-kill test on video and the event history to back it up.
Best Use of Gemma: Gemma 3 4B runs locally through Ollama to plan trips and write situation briefs, constrained by tested rules.

Pothole Adoption Agency

Faris — Sun, 04 Oct 2026 20:46:15 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

Every pet in this shelter is a real pothole complaint filed with NYC 311 in Queens Community Board 13. Its fate follows
the city's own record: repaired, "no pothole found", transferred, or still waiting.

Live demo (no login): https://pothole-shelter.vercel.app · Code: https://github.com/syncaimain/pothole-shelter ·
Sanity project: fixjy07h (dataset production, public-read)

Measured on the live dataset, 4 October 2026
Complaints synced	2,512: every Queens CB 13 street pothole from the last 180 days, plus every one still open. Nothing sampled.
Lost strays (no coordinates in the record)	1,555 (62%)
Outcomes	668 adopted · 409 ghosts · 449 transferred · 963 feral · 18 in the shelter · 5 unmapped
Median time from report to repair	0.9 days (653 repaired complaints)
Unmapped resolution phrases	1 phrase, 5 pets, shown publicly instead of guessed
Second sync over the same data	0 created · 0 updated · 0 status events (incremental and forced full)
Workflows (Sanity Workflows engine)	3 definitions deployed · 981 live lifecycle instances · 366 cluster reviews · adoption moderation
Tests, all in CI	98 unit and workflow tests (20 on the Workflows test bench) · 26 Playwright judge-path + axe tests

What I Built

A shelter where the animals are potholes. Browse them, read their stories, follow the one that's been waiting since 2021,
visit the ghost hall, and leave one an adoption note. It's for anyone who has ever reported a pothole and wondered what
happened next, and for anyone who likes their civic data with a bit of heart.

The rule I never broke: nothing about a pet is made up, and nothing about its fate is decided by me.

The city record decides. A deterministic sync maps each 311 record to an outcome. Closed complaints are matched exactly against resolutionMapping documents that a person wrote, one per phrase the city actually uses. Wording nobody has mapped goes to a public Unmapped bucket instead of being guessed. Open complaints turn feral after 60 days.
The data's own gaps become characters. 62% of complaints have no coordinates: they describe a stretch of street between two cross streets, not a point. Those are the lost strays, listed by street and never placed on a map I'd have to invent. When an inspector finds nothing, the pet becomes a ghost. The 963 ferals are the city's real backlog.
Bios restate facts only. Each bio starts from a fact template: the date it was reported, the street, and the city's resolution note quoted verbatim. Gemini may restyle it, but a fact guard rejects any changed date, number or street, a reworded city note, or anything that mocks people. House numbers never appear, and coordinates are rounded to about 100 m.
Celebrate repairs, never mock anyone. The joke is the shelter, not the people who report potholes or the crews who fix them. When the Department of Transportation repairs one, the pet is "adopted into forever pavement" and the street gets a congratulations.

Demo

Live: https://pothole-shelter.vercel.app (no login anywhere on the public site)

The narration is synthetic: each caption line was voiced with Gemini TTS (gemini-3.8-flash-tts) by docs/media/make-voiceover.mjs, so voice and captions say the same words at the same moments.

The judge path:

Open the gallery and click a Feral pet.
Read its complaint history and follow the link to the real 311 record on NYC Open Data.
Open lost strays and the ghost hall.
Leave an adoption note on any shelter or feral pet. You'll see "awaiting moderation". The note stays private until a person approves it in the Shelter Office.
Open the sync log for the last sync time, the run log and the unmapped phrases.

Testing the Shelter Office (App SDK, needs a Sanity login): there's no shared test account. The video shows a note being approved in the Shelter Office at 2:18, and every Office view has a public read-only mirror at /office.

Code

syncaimain / pothole-shelter

Pothole Adoption Agency

Real NYC 311 pothole complaints from Queens Community Board 13, turned into adoptable pets whose fates follow the city's own record: repaired, "no pothole found", transferred, or still waiting. Built for the Sanity Challenge on DEV, Path Two.

Live site: https://pothole-shelter.vercel.app (no login)
Sanity project ID: fixjy07h, dataset production, public-read. Example queries are in docs/links/public-queries.txt.
Build log (the honest version): docs/BUILD_LOG.md

What a judge can check

Open the gallery and click a Feral pet.
Read its complaint history and follow a link to the real 311 record on NYC Open Data.
Open /strays (complaints with no coordinates) and /ghosts (inspected, no defect found).
Open /sync for the last sync time, the run log, and the unmapped resolution phrases.

Numbers (live dataset, 4 October 2026)

Complaints synced	2,512 (every Queens CB 13 street pothole from the last 180 days, plus every one still open)
Lost

…

View on GitHub

A pnpm workspace: studio/ (schema and desk structure), web/ (Next.js 16 public site), sync/ (311 → Sanity, with the
outcome rules and clustering), workflows/ (definitions and bench tests), app/ (the App SDK Shelter Office), agent/
(Gemini bio writer and fact guard) and ingest/ (discovery, migrations, and every raw 311 snapshot with its SHA-256).
CI runs typecheck, lint, all tests, a snapshot checksum check, both builds, and the Playwright judge path with axe-core.

My Build Process

IDE and agent: I built this with Claude Code (Claude Opus 5.5) in a terminal, driven by prompts and a written spec.
A second coordinating session sent guidance through docs/GUIDANCE.md, and the building agent reported back in
docs/REPORT.md. Both files are in the repo, unedited, along with the full log in docs/BUILD_LOG.md. The app itself
uses Gemini (gemini-3.7-flash) for bios.

The prompt that set the tone

Read the spec in full. Then, in order: verify the Gemini key with one cheap call (if it fails, stop and report); confirm
every item marked "Verify" against current live docs; scaffold the pnpm workspace. Stop there and report before writing
feature code.

"Stop and report" was the most useful instruction I gave. Several of the spec's own facts were wrong:

The Workflows package names were partly wrong. The CLI binary is sanity-workflows, it needs @sanity/workflow-blueprint, and the test bench lives in @sanity/workflow-engine-test.
TypeScript had to be pinned to 6.0.3, not the 7.0.2 that latest gave, nor the 5.x one guide suggested. It's the only version that satisfies both typescript-eslint (<6.1) and the Workflows blueprint (≥6.0.3).
Next.js 16 ships an AGENTS.md that says "This is NOT the Next.js you know" — and it isn't. Caching is now cacheComponents + 'use cache'. The first build failed because "Feral of the week" read the clock outside a cached scope.
Vercel's Hobby plan only allows daily crons, so the sync is scheduled hourly on GitHub Actions instead.

Messy data, decided honestly

Scope: Queens had ~17,000 street-pothole complaints in 180 days, plus ~8,800 still open. Rather than sample, I took one community board in full, so every pet is traceable and clustering sees complete data.
Missing coordinates: 62% of complaints have no point. I chose not to geocode them, because that would invent precision the record doesn't have. They became the lost strays.
"Referred" resolutions never sit on a closed ticket in CB 13; they're all Pending. The status rule stays in charge rather than a mapping overriding a ticket the city still lists as open.
Unclear resolution text: "The status of this Service Request is currently not available online…" is the whole Unmapped bucket. It's shown publicly rather than guessed.
The median time to close is misleading. It's 0.4 days overall because 366 duplicates closed within one minute of being filed. I quote the repair median (0.9 days) instead.
91% of located complaints have no street_name: they're intersections, with only intersection_street_1/2. A clustering rule keyed on street_name would silently have skipped them. A test caught it.
"0 m apart" means "the same corner", not "the same pothole": intersection complaints all share the intersection's point. The Shelter Office tells reviewers so.

Where it got stuck, and how it course-corrected

Dotted document IDs. The spec's own example (complaint311.<key>) would have hidden every document from judges, because Sanity never serves dotted IDs to anonymous readers. I switched to hyphens. Later I used the same behaviour on purpose: pending adoption notes get a dotted ID, so nothing a visitor types is public before a person approves it.
One document per status event put me over the plan's cap. 4,992 event documents took the dataset to 10,022 of 10,000. Events now live as an append-only array inside each pet. I migrated by moving every event verbatim, verified 4,992/4,992 in place, and only then deleted. The dataset fell to about 5,000 documents.
$actor.kind == "person" gated nothing. The tests said people could approve, but they also said agents could. A probe showed the Workflows engine stamps every resolved actor as kind "person", robots included. What actually discriminates is the id namespace (g… user, p-… robot token). The bug stayed hidden because my test fixtures used fake ids that happened to look like robots.
I said "nothing was written" when something was. A migration step was interrupted, the tool reported the call as rejected, and the agent told me nothing had been appended. It had. The agent found this itself on the next run and corrected the record. Lesson: check the data before stating what didn't happen.
Stopping a shell doesn't stop its process. Two long backfills were cut off at a time limit, but their processes kept running and raced the re-runs, creating 183 duplicate workflow instances. The agent traced them by timestamp, added an optimistic-lock claim (ifRevisionID) so it can't recur, and aborted the duplicates through the engine with a recorded reason rather than deleting them.
Three different pets were all called "Arepa Asphaltine". 800 base names for 2,512 pets. This was found by reading the first Gemini bios instead of trusting that they had passed the guard. Pets sharing a base name now take pedigree ordinals (II, III…) in complaint-key order, and a newer pet never renames an older one.
axe-core found a real accessibility bug: on phones the sync tables scroll sideways, but the scroll region wasn't keyboard-focusable. Fixed, and now tested on every push.

Reaching past the Studio: Workflows and the App SDK

Workflows. The spec asked for a 2-hour spike with a declared fallback. The spike succeeded, and nothing fell back.
Three definitions were validated offline and tested on the in-memory bench, including the 60-day Feral rule on a fixed
clock: still in the shelter one second before 60 days, feral at exactly 60. They're deployed from a sanity login session.
A project-scoped token deploys fine and then fails on a cross-resource read, exactly as the docs warn.

pothole-lifecycle: Reported → In the shelter → Adopted · Ghost · Transferred · Feral · Unmapped. I added the Unmapped stage; without it, a closed-but-unmapped pet would wrongly turn feral by the clock. The sync (a robot token) is the only caller that can record an outcome, and it ticks the clock-based transitions itself. There's one live instance per open pet: 981 right now, matching the pets' outcomes exactly.
cluster-review: Proposed → Approved · Rejected. The rule proposes, and a person decides in the Shelter Office. The sync merges only clusters whose decider is a person.
adoption-moderation: Submitted → Approved · Rejected, decided by a person.

Two lessons the docs didn't spell out. Engine gates are advisory: the actor is "provenance, not an authenticated
principal", and mutation guards aren't enforced by the lake yet. So the real rules also live in code I control. And
instance documents are private (dotted IDs), so the public mirror reads workflow state through a server-side proxy that
publishes totals only.

App SDK. The Shelter Office is a custom app in the Sanity Dashboard, with real-time data and its own interface: live
queues to moderate adoption notes and review cluster merges, the unmapped phrases, sync health, and a live lifecycle board.
Approving a note fires the moderation workflow as the signed-in person. The engine records who decided from their
token, and only then is a public copy of the note written. Every Office view has a public read-only mirror at
/office.

Gemini, behind a fact guard. gemini-3.7-flash (version 3.7-flash-08-2026, recorded on every bio it writes)
restyles template bios into the shelter's voice. The guard accepted 65 of 65 in the sample run. Reasoning models eat
output tokens: a two-letter test reply used 80 reasoning tokens, so bios get a 4,096-token budget.

What I cut

All of Queens. One community board in full beat a sample of the whole borough.
Geocoding strays. It would have put invented points on a map.
Filing new complaints. Out of scope by design: this shelter only reflects the city's record.

Known limitations

Resolution wording is inconsistent, and five closed complaints say nothing useful. They stay Unmapped until a person decides.
Clustering is a heuristic (60 m / 30 days / same street; strays by same block). That's why every merge needs a person.
311 dates have no time zone. I read them as New York local time. The data is consistent with that, but it's an assumption.
The hourly schedule is best-effort. GitHub Actions delays scheduled runs under load and sometimes skips them: on 4 October the 19:17 UTC slot ran 22 minutes late and the 20:17 slot didn't run. Every run, scheduled or manual, is idempotent, and the sync log shows real run times, never the schedule.

Why it's new

Most civic-data projects turn records into dashboards. This one turns them into characters, and lets the data's gaps play
the parts: the complaints with no coordinates become lost strays, the ones the city looked for and couldn't find become
ghosts, and the backlog becomes a feral wing that's still waiting. Every fate is the city's own, and every step can be
traced back to a real record.

Sanity Project Details

Project ID: fixjy07h · dataset: production (public-read, no token needed)
Public query: https://fixjy07h.api.sanity.io/v2025-02-19/data/query/production?query=*[_type=="pothole"][0...5]

Schema, and why raw records and pet fields are kept apart:

Type	What it holds
`complaint311`	The 311 row exactly as published (`raw`), its SHA-256, and the source row URL. Rewritten only when the hash changes.
`pothole`	The pet: name, temperament, bio (with its model and fact-guard provenance), rounded location, outcome (written only by the sync), its lifecycle workflow instance, and `events`, an append-only history where every entry cites the complaint field that caused it.
`resolutionMapping`	One exact city phrase → outcome, with a person's rationale.
`clusterDecision`	A proposed merge, with its review workflow and the person who decided.
`adoption`	A visitor's note: private while pending, public only once a person approves it.
`syncRun`	Every sync: counts, watermark, and the SHA-256 of each raw page it saved.

Keeping the city's record and my interpretation in separate documents means anyone can check any pet against the 311 row
it came from, and a re-sync can never overwrite a decision a person made.

Data: 311 Service Requests from 2020 to Present,
NYC Open Data, dataset erm2-nwe9. The City of New York does not vouch for the accuracy or completeness of this site or
the data it uses, which has been modified for use from its original source.