@Osmosis

The problem that’s haunted this project for weeks, on iPhone, the app and the browser are treated as DIFFERENT sandboxes, so a reel you saved in one never showed up in the other. Same underlying issue everywhere, InSave never knew who you were. Every new device created a new account which is annoying to say the least
Fixed it properly: optional sign-in. Don’t want an account? Everything still works, save, get reminded, no login wall. Want your stuff in one place across your phone and laptop? Sign in once, and everything you saved, no matter which device or browser, merges into one library. Signed in on my iPhone and my Android and watched them become the same library. That merge, taking piles of saved reels from three different accounts and combining them into one without losing or duplicating a single thing, was the hardest thing I’ve built on this whole project.
Then it went live and immediately broke, which was its own lesson. Sign-in did nothing on every phone. Chased it down: the button silently failed because the server was erroring, because a piece of setup I was supposed to do by hand on the Google AUTH client got skipped when the code auto-shipped itself. The code deployed fine. Fixed the setup, and sign-in flipped from broken to working on both iPhone and Android.
Two bonus things shipped while I was in there: reminders are now a one reel at a time revisit queue (see the reel, rewatch it, keep it in rotation, or let it go) instead of a flat list. And import got way better, turns out Instagram’s export quietly includes your actual collections, so now importing recreates them faithfully instead of dumping everything into one pile.
258 tests green. Live on real servers. Verified on real iPhone and real Android. The wall that’s blocked iPhone for weeks is down. Still honest about what’s left, There is a timezone issue, reminders still fire on the wrong clock for anyone outside my timezone. Tired, but it works.

Devlog 4 - button that did nothing, and a notebook helper
Two things this session. One was a bug that taught me the difference between “out of memory” and “out of time,” and a whole new feature for my robotics team.
WeekLog has a “Download all media” button that zips up every photo the team’s uploaded. It just… didn’t work. No error, no download, nothing. The worst kind of bug because I had no idea where the problem lied
First real clue came from the browser network tab: the request was coming back 503, and the error page was Cloudflare’s, not my app’s. It meant my code wasn’t throwing an error, the platform was killing my worker before it could respond. So the frontend was hiding a failure it should have shown, first I made it actually show me the error instead of just letting it fail
Then the real chase. My worker was loading every file fully into memory and building the zip all at once, so I assumed it was running out of memory. I rewrote it to stream the zip instead, pulling one file at a time. Felt good. Still broke. So I tailed the live worker logs and got the actual smoking gun: “outcome”: “exceededCpu”. It wasn’t memory at all. The media set is about 404 MB, and just computing the checksums to zip that much data is more compute than a free-tier worker gets per request. Streaming fixed the memory ceiling and I still hit a completely separate CPU ceiling behind it. You genuinely cannot zip 404 MB inside one free worker call.
The fix was to stop trying. Instead of the worker building the zip, it now sends a tiny manifest (just a file list, no actual bytes, comes back in ~2.4 seconds) and the browser pulls each file and builds the zip locally. Worker work stays tiny, it scales to any size, and it stays free. The lesson I’m keeping: don’t assume the first plausible cause is the only cause. “Streaming fixed it” was true and the thing still broke.
The Notebook Prep pipeline. The bigger build. FGC has an engineering-documentation award judged on the journey a team took building their robot, and WeekLog already has our whole logged season sitting in it. So I built a pipeline that mines that logged data into notebook-prep material: per-subsystem timelines, a gap analysis that flags where our documentation is weak against what judges actually look for, a decision-log extractor, and a draft scaffold.
The rule I built the whole thing around: it is a super-helper, never a ghost-writer. Every output is deliberately un-submittable, it hands you your own logged words as raw material plus [NEEDS: …] prompts where a human has to add the reasoning and the numbers. It never writes notebook prose and never invents a fact. A notebook that reads like an AI wrote it loses that award, because the whole point is proving the humans did the thinking. So the tool audits and prompts, it doesn’t author.
The part I’m proud of architecturally: there’s no AI running in the app at all, and no ongoing cost. The deterministic stuff (timelines, coverage counts) is plain worker compute, and the actual reasoning is done by me in Claude Code following a runbook, then published into the app through a secret-gated write-back route. The app just renders whatever got published as red/amber/green cards and checklists. It doesn’t know or care that AI produced a report. Zero runtime AI cost, and the reasoning is grounded in a reference brief on what FGC judges reward so it’s not just generic advice.
Shipped and live: the ZIP button works via the browser now, and Notebook Prep has all four tabs (Timeline, Gaps, Decisions, Scaffold) carrying real published content. 41 commits this session.
More to come: judge-question rehearsal generated from our actual logged work, tracking notebook health over the season, and tagging photos to subsystems at upload so the timelines get richer.

Well there’s good news and bad news. Good news: I set a reminder, walked away, and my Android phone buzzed at exactly the right time, app fully closed. The whole point of InSave, working on real hardware, not in a test. After weeks of “it passes 198 tests,” watching it actually go off in my hand hit different.
iPhones refuse to cooperate tho, I built the iPhone capture so you share a reel, tap a shortcut, it saves. It did save. Reel captured and everything looked fine. Except it wasnt. Turns out on iPhone, the website you open from a link and the app you installed to your home screen are treated as two completely separate things with separate memories. The shortcut saved my reel into one; my reminders live in the other.
Looks like I have to do the hard part now InSave never had logins. Every phone, every browser, quietly invented its own anonymous identity, and they never talked. It worked fine when I only tested on one device. The moment I used two, like in the case for Iphone where 1 device shows 2 (curse you apple). My own database is sitting here with three different “me”s in it. The main bug
So the next build is the one I kept putting off because it felt boring: actual accounts. One login, one library, everything in one place no matter which phone or app you opened. It’s the thing that makes iPhone actually work, and the thing that means you never lose your reels switching phones.
Where it stands: 198 tests green, live on real servers, Android reminders confirmed firing on a real phone. iPhone capture works mechanically but needs accounts to be useful.

Devlog 4: InSave now remembers for you, even when it’s closed
The whole point of InSave in one line: the reel you saved and forgot comes back to you. Built it in 3 slices.
The brain: wakes on a timer, picks what’s worth nudging you about. Important reels come back sooner and push harder. Junk you keep ignoring quietly backs off, so it never becomes the app you mute.
The push: that nudge lands as a real notification with InSave fully closed.
The action: done / snooze / open the reel, straight from the notification.
Proudest bit is invisible: the phone and the server write to totally separate parts of each reel, so they can never fight. That’s why deleting the app or switching phones brings your reels back instead of losing them. The scariest problem in the project.
Honest bug I wrote down instead of hiding: snooze a reel and it can still pop up early. On the fix list.
117 tests, all green. Full loop closed: save → tag → remind → act.
Next: living with it on my own phone for a few weeks. Tests work but they can’t tell me if my app is too annoying and if every couple days feels right. Only real use can. Also the frontend, eesh it pains me gotta get to work on that

This is the part I think actually makes InSave different, so I wanted it to feel good. The problem: everyone’s got a graveyard of saved reels they’ll never see again. InSave lets you dig it up. You hand it the data file Instagram gives you when you ask for your stuff, and it lays out every reel you ever saved so you can grab the few that mattered and let the rest stay buried.

The thing I cared most about: your entire saved history never leaves your phone. It gets read right there on the device, and only the handful you actually choose to keep ever get sent anywhere. The graveyard is yours and it stays yours.

Two bugs nearly slipped through, The syncing code was telling itself “yep, saved that” for reels it had not actually saved, so on a bad day reels could just quietly disappear with no error to tell you. That’s the worst kind of bug, the silent one. Fixed it so it only ticks a reel off once it can actually see it stored. The second was smaller, hit “keep all from this person” twice and you’d get duplicates. Made it so keeping something twice does nothing the second time.

Where it landed: 46 tests passing, up from 20, and a clean build. The whole import-and-triage flow holds together end to end. Still to do on the real phone, feed it an actual Instagram export and confirm it really does make zero calls out to Instagram while you browse, which is the promise the whole privacy story rests on.

One lesson I’m taking, bugs are a pain in the a** when you dont even know where theyre coming from, bugs that lose your data while smiling at you is worse than one that crashes.

More to come!

First piece, and the most important one, because if saving a reel is even slightly annoying nobody will do it, me included. The goal was brutal: tap share, tap InSave, and you’re already back to scrolling. No screen, no typing, no “tag this now.” Under a second.

The part I’m quietly proud of, it does zero network on the way in. When you share a reel, everything happens right there on your phone (clean up the link, check you haven’t already saved it, write it down) and only later does it quietly sync in the background. Which means it works with no signal at all. Save a reel in a lift with no bars, it just works, and catches up when you’re back online.

The wall was a dumb one that I almost shipped past. The little “saved!” confirmation popup broke when offline, the one moment it most needed to work, because the page it lived on tried to load fresh and couldn’t. Fix was to bake that popup into the part of the app that’s always cached, so it shows up even with no connection. Annoying to find, satisfying to kill.

Where it stands 20 tests, all green, and a clean build. The save-while-offline-then-sync loop holds together. Real on-phone testing (does it actually show up in Instagram’s share menu, does it really feel under a second) is the next thing I have to check on the actual device, not just in tests. But hey thats not the only thing, there’s a lot more work to be done…

Devlog 3
A public demo, backend and all, with no backend
The problem with showing WeekLog to anyone outside my team: it needs a Cloudflare Worker, a D1 database, and R2 storage to do anything. You can’t just hand someone a link and let them click around. So for a Stardance demo I needed a version that runs entirely in the browser, with realistic data, that nobody can break.

Here’s the thing that made it almost free to build: every single data call in the app already went through just four functions in one file (api.ts). I set it up that way months ago so the UI never talks to the network directly. So to fake the entire backend, I didn’t touch a single feature screen. I swapped those four functions to delegate to an in-browser mock instead of fetch, ported the red/amber/green compliance logic verbatim out of the Worker, and seeded sample data into localStorage with dates relative to today so the demo always shows a realistic spread of healthy and flagged days. A little “DEMO · Reset” pill in the corner lets anyone wipe it back to clean.

The lesson worth stealing: if every network call in your app funnels through one tiny choke point, you can replace your whole backend with a fake one without rewriting the app. This is the second time that one boring decision has paid off (the first was dropping in a full redesign without touching the logic).

It’s honest about its own shortcuts, documented in a DEMO.md: uploaded image blobs live in memory so they show a placeholder after a refresh, and the ZIP export downloads a manifest instead of real zipping. Real Supabase magic-link auth is kept so the sign-in flow is genuine; everyone who logs in is just made an admin over the sample data.
40/40 tests pass, clean production build, tsc clean. Live as a static site on Cloudflare Pages, no Worker behind it. More to come: wiring the real Google Drive connector, a proper compliance summary view, and per-file delete.

Next up: wiring the real Google Drive sync, a team-wide compliance summary view, and per-file delete.

The pivot — drone → courtside gimbal (and a lesson)

Here’s where the project hit its biggest wall, and I want to log it honestly because the recovery taught me more than any milestone.

I was about to spec a drone. Then I actually researched drone law in Qatar and found out it’s one of the strictest regimes in the world: every single flight needs a QCAA permit (owning a drone gives you no right to fly it), and there’s a privacy law (Penal Code Art. 333) against filming people without consent, penalties up to two years. For a system whose whole job is filming school matches full of players and spectators, that’s not a paperwork hurdle, it’s a wall. My original picture a drone autonomously filming matches was effectively dead.

The lesson, written down so I don’t forget it: research the constraints of the real world before you fall in love with a plan. I’d validated the software to machine precision, but I almost skipped checking whether the deployment was even legal. Check the boring stuff first.

So I swapped the drone for a 3-DOF gimbal on a rail: a motorised camera mount (pan / tilt / roll) that slides along a track, parked courtside. No permit. Same filming-consent terms my existing fixed cameras already navigate. And it runs every match, not the one-off a permitted drone flight would’ve been. It’s more deployable than the drone ever was.

A gimbal is also a categorically real difference from just pointing a camera, for one optical reason that isn’t arguable: a fixed camera can only ever crop the pixels it already has, but a gimbal physically moves the lens real parallax, a real push-in that changes perspective, footage that simply doesn’t exist in a static feed. The human directs the intent (“orbit that player,” “push in”) and the system, which understands the scene, executes the move. That’s the thing a fixed camera can’t do, and it survived the pivot completely intact.

M9 — the gimbal’s brain (software)

Stardance just opened a hardware track, but this milestone was deliberately software: adapt the system to the gimbal before the parts arrive, so the maths is proven when the hardware lands.

The beautiful part: because I’d kept the architecture cleanly separated for nine milestones, the drone→gimbal pivot touched exactly one layer. The gesture engine, the scene tracking, the intent commands, the flight-path engine, the live bridge all unchanged. The only new code is a converter that takes an ideal 3D camera pose and works out what the gimbal can physically do with it: pan/tilt/roll angles to aim, plus a position along the rail.

And it stays honest, which is the whole point. A gimbal at a fixed pivot can rotate perfectly but can’t translate so a true orbit (circling a subject) is impossible without the camera leaving its rail. The converter proves this with numbers instead of faking it: a follow shot aims with 0.00° error and zero positional gap (the rig does it cleanly), while an attempted orbit still aims perfectly but reports a 9.05-unit gap, flagged out-of-reach on every frame the system refuses to pretend it can do something the hardware can’t.

Honest problems that will probably come up: this is geometry on a perfect simulator. The real gimbal will have motor speed limits, inertia, and backlash, it won’t snap to an angle instantly. That’s the hardware phase’s problem, and I’m not pretending the clean sim is the real rig.

Up next: the glove parts are shipping. When they land, the build goes physical. breadboard, sensors, solder. Then the gimbal it is

Quick one today. I needed multi-file uploads on meeting days, you should be able to attach several photos to a single meeting requirement, not just one. Turns out I’d already solved this exact problem for deadline proof files a while back. So instead of reinventing it, I basically reused the pattern I’d already built: same upload handling, same storage path, same way of listing and attaching multiple files to one thing.

Honestly the satisfying part is that this was easy because of how I set things up earlier. Past me put the upload wiring in one shared place instead of copy-pasting it per feature, so extending it from “deadlines can have many files” to “meetings can too” was a small change, not a rewrite. It’s a nice reminder that the boring structural decisions pay off later. The work you do once to make the next change cheap is invisible until the moment it saves you.

Onto the next thing. Still want to wire up the real Google Drive connector (the stub’s already in place for when our mentors share a folder), add a proper compliance summary view, and let people delete individual files.

Devlog 1
Built a strategy engine from scratch this stretch. The interesting part wasn’t the code, it was figuring out what the game actually rewards, because once I read the manual carefully the “obvious” strategy turned out to be wrong.

The 2026 game has two goals (suppression and extinguisher), both worth 1 point per ball. Looks symmetric. It isn’t. Only the suppression goal gets multiplied by your end-game climb, and the climb multiplier is shared across all three robots on your alliance (three robots at the top zone multiply your combined suppression total by 1.9). The extinguisher, meanwhile, is a shared global pot that all six robots including your opponents feed and all six receive. So feeding the extinguisher barely helps you win. The whole tool is built around surfacing that asymmetry, because it’s the thing that’s easy to get wrong by just reading the point values.
How it’s built: there’s a pure scoring engine (no UI, no network, no AI, just math) that I can actually test, sitting behind a React frontend that just renders its results. That separation meant I could later do a full visual redesign without touching a single line of the math. The engine composes a cycle (travel, intake, travel, deposit), reserves time for the climb, floors the number of full cycles that fit in 150 seconds, applies accuracy and reliability, and then runs the real scoring formula with the climb multiplier. Everything’s shown as arithmetic, not just a final number, so nobody has to take it on faith.
The trust gate is the part I’m most deliberate about. Before any result is shown as real, you pass a “verify and lock” screen that lists every scoring number in plain language next to what it means. Editing any value automatically un-verifies the config, and unverified results get stamped “do not trust” everywhere. This is because the entire engine is only as correct as the numbers I typed in from the manual, so one transcription error has to be catchable, not silent.

Two features I’m happy with. There’s an alliance screen where you change each robot’s climb zone and watch the shared multiplier move live, it makes the “coordinate your climbs” insight visible instead of theoretical (in my worked example, sharing the multiplier across the alliance instead of each robot climbing for only itself is worth about 94 points). And there’s an archetype comparison built specifically to settle a debate on my team: some people thought a storage bot feeding human players was a good plan. So I modeled three strategies through the same engine with a live slider for human-player speed. You can crank the human feed rate past anything physically plausible and the feeder strategy still loses, because its points are unmultiplied and shared. That’s a much better way to win an argument than just asserting it.

It’s a free static site on Cloudflare, 58 tests, no backend. Honest limitation I’m keeping visible: it models a robot in a vacuum, no defense, no congestion, no ball scarcity, so it’s for relative comparison and the two big decisions (climb or not, what to improve), not absolute predictions. Feed it measured cycle times from practice and it gets sharper, so thats what I’ll try to implement in the coming devlogs.

Devlog
Went from empty repo to a deployed, working app this session. Here’s what’s actually in it.
The core is a calendar. I mark which days are meeting days (with a bulk option so I can set “every Tuesday and Thursday” in one go instead of clicking 40 times). The second I mark a day, it snapshots the current requirement checklist onto that day, things like attendance, robot accomplishments, build needs, performance goals, photos of sketches. I built it as a snapshot on purpose so that editing the requirements later doesn’t reach back and rewrite old meetings.
On each meeting day you can take attendance against the full 21-person roster, log accomplishments and build needs and failures (each tagged to a subsystem like drivetrain/shooter/climber), and upload photos and docs. Files go to Cloudflare R2.
Then the part that makes it more than a folder: a compliance engine that derives a red/amber/green status for every day and every deadline. Green if all the compulsory stuff is in, amber if it’s recent and still in progress, red if a past meeting is missing something required. All of that rolls up into a dashboard that opens with one big team status plus a “needs attention” list of everything currently red, so you can see in two seconds where the team is behind. It also tracks standalone deadlines separate from meetings (our social media challenges have their own due dates and actually score competition points), and those go red when overdue.
There’s a search/browse view across everything logged, an admin area for managing the roster and editing what counts as compulsory, and ZIP export of any day’s media plus a summary.
Stack is all Cloudflare free tier: React + Vite frontend on Pages, a TypeScript Hono API on Workers, D1 (SQLite) for data, R2 for files, Supabase magic-link for login. 71 tests on the worker covering the compliance logic.
Two things I’m glad I built in. A hard free-tier guard: files cap at 10MB and the worker refuses any upload that’d push total storage past 8GB, so a school project can never surprise me with a bill. And a clean separation between the UI and all the network/auth wiring, which let me drop in the full Team Qatar redesign without touching how anything works.
This is v1, there’s a Google Drive connector already stubbed in for when our mentors share a folder, and a lot more I want to add. More to come.

Hi I’m Aarav Sharma and I want to direct a drone with my hands, not just piloting but actual direction.

Introducing AirLine: direct a drone with your hands, don’t pilot it. Most gesture drones map your hand to a flight stick (tilt to bank, raise to climb) — you become the joystick. AirLine instead reads cinematic intent (“follow that player,” “orbit the subject”) and figures out the flight itself, because it understands the scene. It’s a branch off my capstone SideLine (an AI sports-analytics system that already tracks “the player with the ball”), reusing its vision core untouched. Software first, glove I build myself next, drone last.

Devlog:

M1: AirLine runs SideLine’s tracker through a clean seam, vision core untouched. ~19 FPS.
M2: Lock onto one subject. Found track IDs fragment — 293/540 frames “lost.” Quantified the re-ID problem on footage, not a $400 drone.
M3: Virtual camera follows like an operated shot, drifts to wide when the target’s lost. First time it looked real.
M4: Webcam gestures (MediaPipe) — but it conflicts with my vision stack. Setup stopped instead of breaking it. Best decision of the day.
M5: Quarantined gestures in their own environment. First real-hand numbers: mostly 10/10 after fixing bugs unit tests missed.
M6: Two-process live system — my hand directs the shot in real time. ~297ms latency, only 35ms of it transport.
M7: First 3D camera move: orbit on a tiltable plane, proven by geometric invariants to machine precision (~4e-16).
M8: Added push-in, pull-out, dolly. Full shot vocabulary done. 146 tests, vision core never touched.

Next: hardware actually building the gesture glove by hand and integrating a drone

Hi I’m Aarav Sharma, I started this before Stardance, so this first devlog covers everything built so far (about 6 hours of work) in one go. Sideline is an AI system that films a school football or basketball match from a single fixed camera and turns that one recording into three different things: tactical analytics for coaches, event highlight reels for the school socials, and a personal highlight clip for every player, not just the goal-scorers. It runs entirely on a local laptop with no subscriptions, which matters because the commercial equivalents (Veo, Pixellot) cost hundreds up front plus monthly fees, putting them out of reach for a normal school.
The computer vision (both football and basketball). The core is one shared pipeline that detects players and the ball, tracks them across the match, works out which team each player is on, and maps the camera view onto real court coordinates so distances and positions actually mean something in metres. Getting each piece trustworthy was the bulk of the time, and a lot of it was fighting genuinely hard problems. The basketball ball tracker kept locking onto players’ heads (round, ball-sized, and constantly held right next to the ball during a shot), and I had to prove that no shape or size rule could ever separate them before fixing it with a small appearance classifier I trained on a few thousand hand-sorted image crops (head rejection went from hopeless to 98.5%). Team detection on similar kits kept collapsing into one cluster until I switched to appearance embeddings, which also caught a possession stat that was confidently pointing at the wrong team entirely.
The three deliverables. Coach analytics come out as a one-page report plus an annotated tactical video (heatmaps, distance covered, possession, formation, territory), with every number honestly labelled as either validated or derived. Event highlights are auto-detected and ranked so the best moments float to the top instead of flooding whoever is editing. Player highlights are built to be inclusive by construction: every player who steps on the court gets footage, using their on-ball moments where they have them, which is the part no commercial product bothers with and the part a school actually cares about.
The app. All of that is wrapped in a working local web app, “Sideline, Match Studio”, with a dark cinematic interface a non-technical teacher can run start to finish: upload a match, click the four court corners on a freeze-frame, pick which deliverables they want, and download the results. The backend is a FastAPI server that runs the heavy AI as background jobs (a full match takes around 3 hours, so it processes while you walk away and can survive a restart), and it wraps my existing pipeline scripts rather than rewriting them. The whole thing is tested end to end with 62 passing checks, and I have already stress-tested it on a full 47-minute match to see what breaks at real scale.
Next stop is real deployment at my school, which is the one thing I cannot fully validate until I have footage from our own courts and teams.