Noorun Nobi

Security engineering

• Sign-in: Google only. There are no passwords in the app at all, and if it ever finds an old email or password column in the users table it rebuilds the table without them. Session tokens are stored only as SHA-256 hashes, in HttpOnly SameSite cookies.
• Web-vuln defences: parameterised SQL (injection prevention), input sanitisation and XSS output-escaping, allowlists for user input, and rate-limiting on authentication and actions.
• Security review: I went through the codebase looking for what I'd learned to look for, and found three things worth fixing: a score endpoint anyone could call without logging in, a WebSocket with no cap on payload size, so one client could exhaust the server, and a rate limit that counted Cloudflare's IP instead of the visitor's, which meant it wasn't limiting anyone. I wrote them up in priority order and fixed them. Signed-out players can still submit a run, they just don't land on the board. The WebSocket one stopped mattering later, when I took multiplayer out.
• Scoring, honestly: the browser reports the score, so I don't pretend the boards are verified. Each run gets a signed, single-use token, and the server throws a score away unless it arrives with a valid unused token and is possible under the game's own rules.

Extras

• Automated smoke and browser tests, and it installs to a phone's home screen like an app.
• Version-controlled on GitHub with incremental, documented commits.

The brief

Something someone would happily open every day, with nothing in it designed to make anyone feel bad for missing a day. That's a harder brief than it sounds, because almost every convention in the genre exists to drive engagement. I worked from the research on how those interfaces land rather than trusting my instincts, and turned that into rules I couldn't talk myself out of.

What I built

• 17 puzzle families (word search, picross, mini-sudoku, anagrams, memory pairs and more), all generated client-side, with the generators run against 2,100 seeds apiece to prove they stay solvable and don't repeat themselves.
• Accessibility with tests behind it: 44 px minimum touch targets, visible focus everywhere, high-contrast, larger-text, reduced-motion and dark modes, and sensory feedback that only happens if you ask for it. All of it enforced by automated tests, so I can't quietly regress it later.
• A "calm audit" before each release: a check that no countdown mechanic has crept into the codebase, and that no pressure words have crept into the copy.
• No client-side framework and no trackers. The puzzles are plain JavaScript, generated in the browser. The server has two runtime dependencies: Express, and a JWT library it uses to check the tokens from the access proxy in front of it. Sign-in goes through Google, so I never hold anyone's password. Installable and works offline. The whole test suite has to pass before anything ships.
• Private by design: runs on the home server above with the same security-first pattern as the flagship, plus identity-based invite-only access. Only invited accounts can reach the real one. The demo above is a separate copy with no accounts at all: the server refuses every write, and it runs its own puzzle seed, so it isn't showing anyone's day.

The orchestration discipline

• Specs before code. Every feature got written down with acceptance criteria before an agent touched it. Vague instructions were far and away the biggest cause of wasted work, so I stopped allowing them.
• One agent's code reviewed by a different agent, then by me. I threw out reviews when the reasoning didn't hold up, including overruling an agent that insisted on blocking a change. I tested it myself and it was fine.
• A passing build was never enough. Every change got exercised in a real browser against a production build before it shipped. That caught things the type checker and the unit tests were happy with, including a race condition that would have quietly broken a feature forever.
• I kept the parts that carry risk. Privacy, security, deployment and the final call on whether something was good never went to an agent.

What shipped

• A touch-first infinite canvas (React, TypeScript, tldraw) with photos, notes, drawing, stickers and board export, synced between her iPad and iPhone through a Node/Express and SQLite API.
• Background removal with no cloud service involved. A quick cut-out runs on the device itself, in a Web Worker using ONNX runtime. If she wants a sharper one, the photo goes to a container on my own server: hardened, non-root, read-only, and not reachable from the internet. Either way her photos never reach a third party.
• Two separate instances on my server: a private one behind identity-based access, and a public demo that is deliberately less capable. The server refuses every write, its four boards are made up, background removal only runs in the browser, and the public build ships without my tldraw licence key, so it carries their watermark. The public source release is generated by an allowlist exporter with a leak scanner that refuses to publish if it finds an IP, a credential or a private name.

The constraint it was built around

Read-only was the requirement from the first line, not a decision I came to later. There is no way for it to restart a service and nothing happens automatically. If it finds a problem, I go and fix it. That reads like a limitation and it is the entire point, because the worst thing a monitoring tool can do is become the reason the server went down.

What I built

• One process owns the database. The collector, the web server and the notifier never open SQLite. They reach it over Unix sockets, each with its own group and env file. The web server's socket accepts sixteen named methods and no SQL, holds no file handle on the database, and never holds the Proxmox token. Compromise it and the worst it can do is close an incident it can already see.
• It works out what caused what. It knows which service sits on which machine, so one container falling over produces a single incident with an evidence timeline. Everything stacked on top of it gets attached to that same incident.
• A release isn't finished when the tests go green. Nothing counts as supported here until that exact build has survived restore, rollback, resource, access, tunnel and firewall checks, and then a full day of running without a restart. A tag on its own doesn't mean it is running anywhere.
• 115 backend tests covering the API, the collector, the database and its migrations, and the notifier, with a separate suite on the front end.
• The public version is a drill, not the real console. Every server, incident and alert in the demo above is invented. It is a static build with no analytics, no cookies and no storage, and it cannot reach anything on my network.

What it does

Pick photos or scans, put them in order, get a PDF. It runs offline and there is no account to make. The one thing it reaches the internet for is checking whether a newer version exists, and only when you press the button.

Shipping it properly

• The build now refuses to package a binary containing that path. It fails the build. A checklist would only have worked for as long as somebody remembered to read it.
• Every release is checksummed and attested. The installer, a portable zip, a SHA256SUMS.txt and a software bill of materials, all produced by the tagged build. I checked it by downloading the release back the way a stranger would. The copy sitting on my own disk proves nothing.
• The version tags cannot be moved or deleted. Blocking force pushes turned out not to be enough on its own. Deleting a tag was refused, but moving one forward still went through, because moving a tag onto a later commit counts as a fast-forward. Closing it properly took a second rule.