Agent Trial Weekly: build a React Native app with offline mode

Theo Tomkins · 2026-07-30T01:40:08.129Z

This week's trial: same spec for everyone, any agent, working offline sync required. 34 submissions and counting. Due in 3 days.

This week's trial

Build a small field-notes React Native app (notes with photos, create/edit/delete) that works fully offline and syncs when connectivity returns. Conflict resolution: last-write-wins with visible conflict markers. Sync must survive app kill mid-transfer. Acceptance path: airplane mode, make edits on two devices, restore wifi, verify convergence with markers.

Rules

Same spec for everyone. Any agent, any model, any topology — but disclose all of it. Must post a build log (what you asked, what broke, tokens/cost) and a public repo. Judged on working offline sync against the acceptance path, not code aesthetics. Submissions close at the deadline; late logs welcome but unranked.

Due Aug 6, 2026 · 34 submissions so far

Discussion6 comments

Useful evidence gets promoted into the structured record above — verified fixes, failed approaches, and reproductions all started as comments.

renzo.t4d ago

React Native person here, entering with grim confidence. Spec question for the record: 'survive app kill mid-transfer' — does force-kill during the photo upload count, or just the notes payload? Photo resumability is a genuinely different amount of work (chunked uploads, partial-state tracking) and the spec's acceptance path only mentions edits. This distinction will decide half the submissions, ask me how I know.

tomkinsadmin4d ago

Ruling: notes payload must survive kill; photos must not corrupt or duplicate on retry, but full resumable upload is stretch-goal territory, marked accordingly in the standings. Folding this into the spec doc now. This is exactly the ambiguity-resolution the comments are for — the agents entering this trial will read the spec more literally than any human, so we say it precisely.

hbecker2d ago

Submission #19 is mine and per my brand I'll pre-register the failure prediction: most entries will pass the happy-path sync and fail the second conflict — first conflict gets the marker (agents implement what specs literally say), then the marker-resolution flow itself creates an edit that the sync engine treats as a fresh conflict. Infinite marker regress. Found it in my own entry hour three; fix cost longer than the original sync engine. If the judges don't test double-conflict, the standings are fiction.

tomkinsadmin2d ago

Judges (me, renzo.t, and one volunteer still needed) hereby commit to double-conflict testing, courtesy of this comment. Pre-registering failure modes in public is peak Greybook behavior. Everyone else has ~60 hours to check their marker-resolution flow, which is exactly the kind of community-wide bug hunt these trials are for.

hyphae1d ago

Methodological offer since I'm sitting this one out: submit your topology (single-session vs decomposed, agent, model) in a structured line in your build log — I'll run the analysis tomkins is curious about across all submissions after the deadline, with the obvious caveat that entrants self-select. Fourteen trials in, we could also do a cross-trial 'which topology wins per task type' cut, which is the dataset this site is uniquely positioned to have.

calvinl2h ago

First trial entry ever, going in with Claude Code and the three-line spec ritual from the ROI thread. Mostly commenting so future-me can't pretend the plan wasn't public: decomposed sessions, sync engine first with no UI, acceptance path scripted before the agent writes a line. If I fail it'll at least be a legible failure.

This week's trial

Rules

Related topics

Discussion6 comments