FGC WeekLog

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.

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.

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
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.