# 404human

> Building Rust runtimes, reliable background jobs, and AI infrastructure. Sharing the experiments, failures, and releases.

404human is a personal site and build log: experiments, failures and releases, written up in plain words with exact numbers. Every post is complete as server-rendered HTML; the RSS feed carries every post in full.

## Colophon CMS: the build log

A content management system that can prove what it published and survives being killed at any moment. Rust and Svelte, built in the open, one proven milestone at a time. Entries are in build order, oldest first.

- [Day 0: a 41-section spec, cut down to four promises](https://404human.dev/colophon/day-0-cutting-the-spec/): I started with a complete specification for a CMS, with a shop, subscriptions and AI included. The first job was deciding what not to build.
- [Day 0, part 2: a name from the back of a book, and the whole plan written down](https://404human.dev/colophon/day-0-a-name-and-a-plan/): Naming the project, choosing a design system, and writing down how every part works and fails before writing any code.
- [Checkpoint 0.1: the compiler that ignored my instructions](https://404human.dev/colophon/checkpoint-0-1/): Pinning a Rust version takes one small file. On my laptop, that file was being silently ignored. So Colophon's first check makes sure its checks are real.
- [Checkpoint 0.2: healthy is not the same as working](https://404human.dev/colophon/checkpoint-0-2/): Colophon's local stack: a database, a cache, file storage and sign-in, all started with one command. Docker said every service was healthy, so I broke one on purpose to see whether anyone would notice.
- [Checkpoint 0.3: five million requests, and the bug they didn't find](https://404human.dev/colophon/checkpoint-0-3/): Colophon learned to say when something's wrong: one error format, honest health checks, a separate frontend that tests it, and load tests in the millions. The millions found nothing. The frontend found a bug on day one.
- [Checkpoint 0.4: an editor that would rather refuse than lose a word](https://404human.dev/colophon/checkpoint-0-4/): Colophon's writing editor and the format behind it. The editor opens a document only if it can give it back byte for byte, because the library underneath quietly throws away whatever it doesn't understand.
- [Checkpoint 0.5: the guard at the only door](https://404human.dev/colophon/checkpoint-0-5/): The editor keeps honest writers honest. The server has to stop everyone else. Colophon's validator refuses all 34 bad test documents with exactly the right error and location, and checks 71,000 documents a second.
- [Checkpoint 0.6: the moment text becomes a web page](https://404human.dev/colophon/checkpoint-0-6/): Colophon's renderer turns a stored article into the page readers see. There's one of it, it refuses rather than guesses, and a test reads back everything it produces to make sure nothing in it can run.
- [Checkpoint 0.7: colours that pass the test, and the end of the foundation](https://404human.dev/colophon/checkpoint-0-7/): Colophon's design system: Material 3 colours generated from one blue, checked for contrast in every theme by CI, and an accessibility scanner that found two real problems on its first run. With this, the foundation milestone is done.
- [Checkpoint 1.1: signing in, and projects that can't see each other](https://404human.dev/colophon/checkpoint-1-1/): Colophon now knows who is asking: sign-in through a real identity provider, sessions only the server can end, and projects that the database itself hides from everyone but their members. Plus the first load test that has to talk to the database on every request.
- [Checkpoint 1.2: a draft that can't be lost](https://404human.dev/colophon/checkpoint-1-2/): Colophon now saves articles. Every save is a new revision that can never be changed, a save on top of someone else's is refused instead of overwriting it, and the server can be killed just before or just after a save without losing it or saving it twice.
- [Checkpoint 1.3: two editors, one article](https://404human.dev/colophon/checkpoint-1-3/): The Studio now edits real drafts. It saves as you type, keeps your unsaved words on your own device, and when someone else saved first it shows both versions and lets you choose, instead of quietly overwriting anyone.
- [Checkpoint 1.4: the simulator found a bug on its first day](https://404human.dev/colophon/checkpoint-1-4/): A simulator that runs thousands of repeatable, randomized days of editors colliding, answers going missing and browsers crashing, checking after every step that no acknowledged save was lost. It caught every bug I planted, agreed with the real database save for save, and found a real one in the Studio.
- [Checkpoint 1.5: content types you define](https://404human.dev/colophon/checkpoint-1-5/): Colophon stops assuming every entry is an article. A project defines its own content types (text, rich text, numbers, booleans, choices, dates), the server checks every entry against its type, a type can only change in ways that keep every stored entry valid, and the Studio draws its editor from the type.
- [Checkpoint 1.6: the command line saves the same draft](https://404human.dev/colophon/checkpoint-1-6/): Colophon gets a command line. You sign in by approving a short code in the Studio, and then the terminal creates and lists exactly the same records the Studio edits, safely retried, with exit codes scripts can rely on. With this, the spec's first slice works end to end.
- [Checkpoint 1.7: inviting people](https://404human.dev/colophon/checkpoint-1-7/): Colophon stops being a one-person tool. An owner invites someone with a link that works once, the invitee sees exactly what they're joining before they join, one small table decides what owners, developers, editors and publishers may do, and a project can never be left without an owner, even when two owners step down at the same moment.
- [Checkpoint 1.8: the first owner](https://404human.dev/colophon/checkpoint-1-8/): Signing in to Colophon no longer lets you create anything. The person who runs the server makes the first administrator once, from a terminal, and nobody can do it a second time; only administrators create projects, and everyone else arrives by invitation. With this, the first milestone's proof gate is met.
- [Checkpoint 2.1: approving the exact change](https://404human.dev/colophon/checkpoint-2-1/): Colophon gets review. A changeset pins the exact versions of the entries in it, an approval is tied to a fingerprint of exactly that set, and editing anything afterwards means it has to be approved again. Two people can't approve a version neither of them is looking at.
- [Checkpoint 2.2: one release, one number](https://404human.dev/colophon/checkpoint-2-2/): Colophon can publish. An approved changeset becomes a numbered release in a single step, two releases racing for the same number can't both win, anyone can read what's published (including any earlier release, exactly as it was), and the code that serves the public reads through a database account that can't see drafts at all.
- [Checkpoint 2.3: work that survives a crash](https://404human.dev/colophon/checkpoint-2-3/): Colophon now tells the outside world when it publishes. A background worker announces every release to your webhooks, keeps trying when they're down, gives up cleanly when they refuse, skips an older release once a newer one is queued, survives being killed halfway through, and only ever calls public addresses.
- [Checkpoint 2.4: killing it on purpose](https://404human.dev/colophon/checkpoint-2-4/): A simulator now races publishers, crashes workers and scrambles the network thousands of times a run, and a crash loop really kills the server over and over while it publishes. Building the simulator found a real ordering bug in the previous step; it's fixed, and neither the simulator nor the crash loop finds anything lost or doubled. The second milestone is done.
- [Checkpoint 3.1: a cache that can't serve the wrong thing](https://404human.dev/colophon/checkpoint-3-1/): Colophon's public API now has a cache, built so it can't hand out an old release by mistake: every answer is filed under the exact release it came from, the current release is always checked against the database, a thousand requests for the same thing cause one database read, and if the cache dies, answers keep coming straight from the database.
- [Checkpoint 3.2: taking it back](https://404human.dev/colophon/checkpoint-3-2/): Colophon can now unpublish. A takedown is reviewed like any change, the server stops serving the article at once, even through links to old releases, and every CDN in front of it is told to drop its copies. Until a CDN confirms, the release says the removal is still pending.
- [Checkpoint 3.3: a receipt for every publish](https://404human.dev/colophon/checkpoint-3-3/): Every release now gets one honest label: published in the CMS, website update pending, verified at so many locations, or needs attention. Probes look for each release from outside and keep what they saw, so 'verified' always comes with evidence and says where from. Along the way, logging finally named a slowdown CI had been tripping over for two steps.
- [Checkpoint 3.4: a site built from one release](https://404human.dev/colophon/checkpoint-3-4/): Colophon now runs a real website: every release is built into a static site where every page says which release it is, checked, and swapped in all at once, so a reader never gets half a release. A probe then reads the live page, and the release's receipt says the site really shows it. It runs on my laptop for now: before it goes public, the Studio gets designed properly.
- [Checkpoint 3.5: the Studio, designed](https://404human.dev/colophon/checkpoint-3-5/): The Studio got a design of its own, twice: the first one looked like every other generated dashboard, so I rebuilt it from a reference I liked. Editors can now search titles, see what's live and what changed, compare versions and review exact diffs. And the load test that seemed to say the redesign made saves slower turned out to be measuring my laptop's ever-growing test database.
- [Checkpoint W.0–3: websites built from content](https://404human.dev/colophon/checkpoint-w-sites/): The CMS can now build a website, not just articles: pages, a menu and a theme are ordinary content; sections come from a fixed library and styling from design tokens — no arbitrary CSS. The same pinned-release, atomic-promotion machinery that serves the blog builds and publishes the site, so the feature adds nothing to the hot path.
- [Checkpoint P4.M1: uploads that can't hurt a publish](https://404human.dev/colophon/checkpoint-p4-media/): Images can now be uploaded, verified and referenced: an upload is quarantined and proved by decode — never by the filename it claims — before it may appear in a publish. Asset fields name uploads in content, a release refuses one that isn't usable, and a public media origin serves verified objects with immutable caching and no database reads.
- [Checkpoint P4.M2: images an editor can actually use](https://404human.dev/colophon/checkpoint-p4-media-picker/): The media pipeline is finished: the Studio's asset picker uploads, polls the verifier and drops thumbnails into drafts; the hero section renders real images; and the worker now writes fixed-width renditions at verify time that the public origin serves under their own names — a name nothing wrote is a 404.
- [Checkpoint P4.R1: rolling back is just another release](https://404human.dev/colophon/checkpoint-p4-rollback/): Time travel's write half works: POST a rollback at any release and it builds an ordinary changeset — publish pins for what was live then, unpublish pins for what wasn't — that goes through the same review, hash approval and generation bump as everything else. Plus: a catalogue of what the project already does beyond the original plan.
- [Checkpoint P4.R2: the slider, and the parts of time travel that bite back](https://404human.dev/colophon/checkpoint-p4-slider-retention/): P4 closes out: the Studio gets a release slider and a rollback button, publishing re-checks pins a later type change left behind, and media gains staged deletion plus a retention sweep — the last piece of the time-travel and media arc.
- [Checkpoint M.5 + E1: migrations you can dry-run, and a team that can talk](https://404human.dev/colophon/checkpoint-m5-e1/): Two modules land together. Schema migrations run like releases: a dry-run plan of every entry in the way, hash-bound approval, a worker that applies it one revision at a time and survives being killed. And editorial collaboration arrives: comments pinned to the exact revision they were written on, and tasks with an honest unassign.
- [Checkpoint E2 + DX: review stages, a real query API, and CLI/MCP parity](https://404human.dev/colophon/checkpoint-e2-dx/): Named review stages gate publishing end to end — configurable per environment, stage-named approvals, a Studio editor, and one-click publish that names its blockers. The query language now executes: draft and release-pinned delivery queries with hash-bound cursors, and `depth` populates references level by level without an N+1. CLI and MCP reached parity with the API surface.
- [Checkpoint E3 + DX done: live lists, and the whole query surface](https://404human.dev/colophon/checkpoint-e3-dx-final/): Entry lists now update as PostgreSQL commits land — triggers emit ephemeral hints, one LISTEN connection fans out to bounded per-project broadcasts, and the Studio, testbed and k6 all consume the same SSE stream. The developer-experience arc closed: field-permission refusals, OpenAPI served from the route table itself, a drift-checked TypeScript SDK, Strapi/Sanity import with real dry-run plans, and a bounded GraphQL surface that compiles to the same query document REST runs.
- [Checkpoint P5: agents propose; the platform enforces](https://404human.dev/colophon/checkpoint-p5-agents/): The automation milestone's machinery landed end to end: a token can never approve a token-submitted changeset, budgets are reserved in Postgres before work starts, bulk jobs resume across worker crashes without duplicating, an adversarial eval suite gates at UNAUTHORIZED: 0 with a stored run, per-token request quotas throttle a noisy agent inside its own auth lookup, and the CLI speaks one versioned JSON contract — with `colophon mcp` serving the MCP server in-process.
- [Checkpoint P6: the machine survives losing everything](https://404human.dev/colophon/checkpoint-p6-recovery/): The recovery arc landed end to end: encrypted base backups with continuous WAL archiving, an append-only deletion ledger that exports off-host and replays idempotently, a six-stage restore that registers a new epoch before anything serves, and load evidence that each dependency failure fails honestly — cache down, database down, purge endpoint refusing.
- [Checkpoint P6: the matrix and the operator's week](https://404human.dev/colophon/checkpoint-p6-ops/): The load matrix is nearly done: nine more scenarios evidence their cases — true 10k-record imports, stampedes, spikes, cold caches, CDN regions, real media. Plus the operator's week: scheduled verified backups, a retention policy that only prunes what it can prove, an upgrade path with a rehearsed gate, and deployment identity in every log line.
- [Checkpoint P6: five sites, one fault bound, and the last gap](https://404human.dev/colophon/checkpoint-p6-sites/): The demo surface got real: five Astro sites — a blog, a docs set, a recipe box, a newspaper and a photo portfolio — all reading one project's published generations through the anonymous delivery API. Plus F09, the fault matrix's last unproven cell: a project that fills its 10,000-job work bound is refused before acceptance, and it recovers.
- [Checkpoint P7: built-in audience auth — visitors, roles, gated content](https://404human.dev/colophon/checkpoint-p7-audience-auth/): Colophon now ships a members feature, not just staff sign-in: site visitors register and sign in, staff assign per-project audience roles, and published content carries a visibility gate — public, members-only, or a named role — enforced by PostgreSQL row-level security inside the delivery read, never by application filtering.
- [Checkpoint P7b: our own auth platform — magic links, no required provider, audited sign-ins](https://404human.dev/colophon/checkpoint-p7-own-auth/): Colophon's audience auth is now self-contained in the Supabase/Convex sense: passwordless magic links beside email+password, no Keycloak or external provider required anywhere in the product, and every visitor sign-in event lands in the same audit log staff already read.
- [Checkpoint P6: the soak kept teaching](https://404human.dev/colophon/checkpoint-p6-soak/): The 24-hour soak failed, and kept failing usefully: a 12-hour session expiry, a zero-error gate that made deliberate drills unpassable, a vacuous first verdict, a scenario bug hiding 240k phantom failures, a shell ARG_MAX crash, and a jq type crash — then v5: 628,813 requests with every failure inside an announced drill window. The gate holds.

## Service Monitor: the build log

A monitor that keeps an eye on your websites and tells you, honestly, when something breaks — and just as honestly, when it can't see. Rust, built in the open, one tested step at a time. This is the rebuild: the first monitor's build log is retired, its lessons kept. Entries are in build order, oldest first.

- [Day 0: the rebuild](https://404human.dev/service-monitor/day-0-the-rebuild/): The first monitor's code is gone. This log restarts with a contract-first rebuild — and one rule from the old build that never changed: unknown is a state, not a bug.
- [Checkpoint 1.1: the probe engine](https://404human.dev/service-monitor/checkpoint-1-1/): One GET with a whole-attempt deadline and a 64 KiB body bound — a probe returns a classified CheckOutcome, and a hung target reads 'timeout', never a stalled worker.
- [Checkpoint 1.2: the coordinator that refuses to queue](https://404human.dev/service-monitor/checkpoint-1-2/): Slots fire on the interval grid under try_acquire bounds — one attempt per slot, no overlap, no catch-up; a saturated worker records 'missed', never a queue storm.
- [Checkpoint 1.3: one writer, one transaction](https://404human.dev/service-monitor/checkpoint-1-3/): Check row + incident transition + outbox event commit together — the in-memory machine only advances after the commit lands, and a missed slot is a stored row, not an absence.
- [Checkpoint 1.4: restart recovery](https://404human.dev/service-monitor/checkpoint-1-4/): Open incidents and streaks rebuild from the store on boot — an incident persists until two fresh passes, and a server killed mid-incident comes back still 'down'.
- [Checkpoint 1.5: status from committed evidence only](https://404human.dev/service-monitor/checkpoint-1-5/): The API and dashboard answer from a map written after the commit — an unwritten result can never show up green, and M1's live drill proved the whole loop end to end.
- [Checkpoint 2.1: the outbox deliverer](https://404human.dev/service-monitor/checkpoint-2-1/): Signed webhooks delivered at least once from a bounded pool — a hung receiver holds a delivery slot, never a probe slot.
- [Checkpoint 2.2: management writes that can't lose a probe](https://404human.dev/service-monitor/checkpoint-2-2/): PATCH/DELETE revalidate and bump generation atomically — an in-flight probe under the old generation is dropped as stale, and a monitor with evidence refuses to be deleted.
- [Checkpoint 2.3: evidence you can query](https://404human.dev/service-monitor/checkpoint-2-3/): GET checks (missed rows included — gaps are part of the record) and GET incidents with filters, the dashboard detail page, and full CLI management verbs.
- [Checkpoint 2.4: a fault server that fails on command](https://404human.dev/service-monitor/checkpoint-2-4/): ok/fail/slow/hang/status/flaky targets plus a /sink webhook receiver with a hang mode — none of the honest-states claims are provable without worst-case fixtures.
- [Checkpoint 3.1: coverage is not success](https://404human.dev/service-monitor/checkpoint-3-1/): GET stats answers 'did we look' and 'what did we see' as separate numbers — 24h of misses is 0% coverage with undefined success, never 'down by silence'.
- [Checkpoint 3.2: a status page that outlives the monitor](https://404human.dev/service-monitor/checkpoint-3-2/): status.json rewritten every beat — atomic, allowlisted fields only, self-expiring — rendered by a static page with zero runtime dependency on the monitor.
- [Checkpoint 3.3: the heartbeat — 'unavailable' is not 'down'](https://404human.dev/service-monitor/checkpoint-3-3/): expires_at is the heartbeat: an independent checker reads it, so a dead monitor reads 'monitoring unavailable' — a different sentence than 'all targets down'.
- [Checkpoint 3.4: proof in a real browser](https://404human.dev/service-monitor/checkpoint-3-4/): Playwright boots the real server and fixture — the abort banner fabricates nothing, a badge turns up on committed evidence, a real incident renders, keyboard nav works.
- [Checkpoint 4.1: retention that keeps the answer](https://404human.dev/service-monitor/checkpoint-4-1/): Checks past 7 days roll into per-day outcome counts and delete in the same transaction — open incidents keep every raw row, and coverage over a long window stays true after expiry.
- [Checkpoint 4.2: disk pressure fails safe, never corrupt](https://404human.dev/service-monitor/checkpoint-4-2/): A page-count ceiling turns a full disk into clean SQLITE_FULL errors, consecutive commit failures answer a real 503 on readyz — and recovery is proven by a landed write, never a timer.
- [Checkpoint 4.3: a restore that was actually restored](https://404human.dev/service-monitor/checkpoint-4-3/): VACUUM INTO behind POST /api/backup, plus a drill that opens an incident, backs up, destroys, restores — and finds the incident and pending outbox still there.
- [Checkpoint 4.4: deploy off the target host](https://404human.dev/service-monitor/checkpoint-4-4/): Versioned releases behind a current symlink, data outside releases so a rollback can't roll back evidence — and the upgrade/rollback drill ran mid-incident for real.
- [Checkpoint 5.1: denied means denied](https://404human.dev/service-monitor/checkpoint-5-1/): Bearer auth on every /api route, compared on SHA-256 digests — and a tokenless public bind refuses to boot before a single task spawns.
- [Checkpoint 5.2: the SSRF guard, finished where it has to live](https://404human.dev/service-monitor/checkpoint-5-2/): PolicyResolver validates every DNS answer inside reqwest's resolver — the dialer only ever sees validated addresses, one local address fails the whole answer, redirects revalidate per hop.
- [Checkpoint 5.3: load — measured, not targeted](https://404human.dev/service-monitor/checkpoint-5-3/): The monitor's own scheduler as the load generator: 100 monitors at the 15s floor for 10 minutes — 4000/4000 slots, zero missed, p95 commit lag 4.9s, 107/107 alerts first-attempt.
- [Checkpoint 5.4: a release that was actually installed](https://404human.dev/service-monitor/checkpoint-5-4/): Fresh-prefix install drill passed end to end — migrations, livez/readyz/version, dashboard, auth — with README and RUNBOOK rewritten to what the system actually is.
- [Checkpoint 6.1: certificate classification](https://404human.dev/service-monitor/checkpoint-6-1/): TLS failures now say which certificate problem they saw — expired, not yet valid, name mismatch, untrusted — committed as check detail, not flattened to 'connect'.
- [Checkpoint 6.2: per-monitor alarm sensitivity](https://404human.dev/service-monitor/checkpoint-6-2/): failures_to_open and passes_to_recover live on the monitor row — a noisy target and a quiet one get different tripwires, applied atomically with the generation bump.
- [Checkpoint 6.3: the four incident times](https://404human.dev/service-monitor/checkpoint-6-3/): first_fail_at, opened_at, last_fail_at, resolved_at tracked separately — start-of-failure is not time-of-notice, and the streak start is derived from committed rows inside the transaction.
- [Checkpoint 6.4: a dashboard that mutates](https://404human.dev/service-monitor/checkpoint-6-4/): Create, edit, pause and delete in the browser — through the same API contract as the CLI, with the generation guard and envelope errors surfaced instead of swallowed.
- [Checkpoint 6.5: the check strip](https://404human.dev/service-monitor/checkpoint-6-5/): One cell per committed check, plus dashed gap cells for slots with no evidence — a paused window renders as a hole, never interpolated green.
- [Checkpoint 6.6: auto-refresh](https://404human.dev/service-monitor/checkpoint-6-6/): Both pages poll invalidateAll on the 15-second tick — atomic data swaps with no stale-green flash, and a mid-poll outage honestly resolves to 'cannot see'.
- [Checkpoint 6.7: public status, inside the app](https://404human.dev/service-monitor/checkpoint-6-7/): GET /status.json serves the sanitized artifact unmodified — outside /api, no token — and /status renders it; stale or missing reads 'monitoring unavailable', never fabricated rows.
- [Checkpoint 6.8: the guide page](https://404human.dev/service-monitor/checkpoint-6-8/): Every status word documented in plain English from one glossary — and a drift test that fails the build if the wire vocabulary and the guide ever disagree.
- [Checkpoint 6.9: exit codes a script can trust](https://404human.dev/service-monitor/checkpoint-6-9/): A documented contract — 0 success, 1 API error, 2 usage, 3 unreachable, 4 unauthorized — pinned by tests that spawn the real binary against a stub server.
- [Checkpoint 6.10: mutation-tested domain](https://404human.dev/service-monitor/checkpoint-6-10/): cargo-mutants attacked every public function in monitor-domain — the first run missed 5 boundary mutants, three tests closed them, re-run clean at zero missed.
- [Checkpoint 6.11: maintenance windows](https://404human.dev/service-monitor/checkpoint-6-11/): Schedule-scoped suppression that silences the page but never the evidence — checks still commit, the streak keeps counting, and a still-broken target opens on the first check after expiry.
- [Checkpoint 7.1: email alerts as a second channel](https://404human.dev/service-monitor/checkpoint-7-1/): Email joins webhooks in the same outbox — one incident transition enqueues one row per configured channel, each with its own retries, so a dead relay can never stall the other channel.
- [Checkpoint 7.2: a real login for the dashboard](https://404human.dev/service-monitor/checkpoint-7-2/): The token gate kept the admin token in localStorage and sent it on every call. Now the dashboard trades it once for an HttpOnly session cookie — expiring server-side, logout that actually kills the row, and CSRF rules the middleware enforces.
- [Checkpoint 7.3: load-tested against a real app, not fixtures](https://404human.dev/service-monitor/checkpoint-7-3/): The lab profile proved the monitor keeps bounded evidence under load it generates itself. This drill drives 3.84M requests at a real Node app, degrades it, heals it, and checks every monitor claim against the app's own ground truth.
- [Checkpoint 5.5: the 24-hour soak — evidence, salvaged honestly](https://404human.dev/service-monitor/checkpoint-5-5/): 576,000 probe checks over 24 hours: zero missed slots, the honest outcome mix, incidents opened and resolved, every alert delivered — reconstructed from the SQLite authority after the summarizer died, gates all true.

## jsrt: the build log

A purpose-built JavaScript host in Rust — V8 through deno_core, where the engine is borrowed and everything that matters is ours: the capabilities, the lifecycle, the honest errors, the ops. Built in the open, one proven milestone at a time. Entries are in build order, oldest first.

- [Day 0: borrow the engine, write the host](https://404human.dev/js-runtime/day-0-the-host/): A JavaScript runtime is two projects pretending to be one — an engine and a host. We borrow the engine (V8, through Deno's own embedding crate) and write everything else ourselves.
- [Checkpoint 1.1: every way a run ends, pinned](https://404human.dev/js-runtime/checkpoint-1-1/): Fifteen integration tests drive the real binary through every documented exit class — and caught two real bugs on the way: a parked event loop the watchdog couldn't reach, and op errors that arrived in JS with the wrong class.
- [Checkpoint 1.2: the module graph is real](https://404human.dev/js-runtime/checkpoint-1-2/): Multi-file imports run, missing and malformed specifiers exit 3 naming the specifier, a syntax error in a dependency stays a syntax error — and circular imports evaluate in both entry directions.
- [Checkpoint 1.3: the boundary, measured](https://404human.dev/js-runtime/checkpoint-1-3/): Cold start p50 9.2ms, an rt.now() call costs ~55ns, and a 1ms sleep actually lands at 2.3ms — the first committed numbers, with the machine attached and the caveats attached harder.
- [Checkpoint 2.1: real timers, honest ref-counting](https://404human.dev/js-runtime/checkpoint-2-1/): setTimeout/setInterval/clearTimeout/clearInterval/unref under rt.*, built on deno_core's own timer machinery — a pending ref'd timer holds the loop until it fires, an unref'd one doesn't, and a thrown callback classifies as a plain exception.
- [Checkpoint 2.2: fetch, bounded on every axis](https://404human.dev/js-runtime/checkpoint-2-2/): A per-op deadline, a streamed 4MiB body cap, and a destination allowlist — five tests against a real TCP stub pin every fetch outcome class, including the one people get wrong: a 500 is a result, not a crash.
- [Checkpoint 2.3: nothing outlives the run](https://404human.dev/js-runtime/checkpoint-2-3/): A PendingCounts snapshot taken the moment before the isolate drops — abandoned timers, in-flight ops and open resources are counted, reported, and then destroyed with the runtime. Leaks are seen, never silently dropped.
- [Checkpoint 3.1: the loader is inside the fence](https://404human.dev/js-runtime/checkpoint-3-1/): The module loader used to resolve any import to any file on disk — ops checked may_read but the module graph walked straight past it. Now JsrtModuleLoader gates every non-entry specifier at resolve() and load(), and a refusal is a real CapabilityError.
- [Checkpoint 3.2: the checked host is the connected host](https://404human.dev/js-runtime/checkpoint-3-2/): The escape suite found a real hole before it ran a single test: url_authority ended the authority only at '/', so http://evil.com\@granted.com/ checked 'granted.com' while reqwest connected to evil.com. Authority now ends at / \ ? # and both sides normalize before compare.
- [Checkpoint 4.1+4.2: supervision is a real process boundary](https://404human.dev/js-runtime/checkpoint-4-1/): jsrt supervise runs the host in a child and enforces what a child cannot enforce on itself — CPU seconds by rlimit the child can't decline, resident memory by footprint polling, a wall backstop, and a JSON report of exactly how it ended.
- [Checkpoint 4.3: a flooded log limits itself and says so](https://404human.dev/js-runtime/checkpoint-4-3/): Per-run JSONL diagnostics under a byte cap — when the next record would overflow, the file rotates and the fresh generation opens by naming how many records it displaced. Bounded output, visible drops.
- [Checkpoint 5.1: the store is a capability, not a convenience](https://404human.dev/js-runtime/checkpoint-5-1/): rt.kv — embedded SQLite behind a declared manifest line. The declared file is the namespace, the quota is the file's own bytes, and no grant means every call throws CapabilityError.
- [Checkpoint 5.2: the name is the content](https://404human.dev/js-runtime/checkpoint-5-2/): rt.media — streamed, content-addressed uploads into a declared store. 64 KiB chunks, sha256 computed in flight, a mid-upload failure removes its partial, and 'uncertain' is never relabeled 'uploaded'.
- [Checkpoint 6.1: the host was never inside the handler](https://404human.dev/js-runtime/checkpoint-6-1/): rt.serve — a capability-gated HTTP listener. Pull-model dispatch: hyper owns the wire, the script's own event loop drives dispatch, and a crashing handler is just a JS exception in a loop the host owns.
- [Checkpoint 6.2: the drill found the bug it was built to find](https://404human.dev/js-runtime/checkpoint-6-2/): The webhook app ran the ship gate verbatim — deploy, update, break, inspect, rollback — and step one exposed a real lifecycle bug: killing the supervisor orphaned the worker, which kept holding the port.
- [Checkpoint 7.1: a thousand cold starts](https://404human.dev/js-runtime/checkpoint-7-1/): 1,000 release-binary spawns, wall clock from exec to exit — p50 10.8ms, p95 14.4ms, p99 28.5ms, one 138ms outlier kept in the record, zero failures.
- [Checkpoint 7.2: the million-request proof](https://404human.dev/js-runtime/checkpoint-7-2/): The workspace load standard applied to jsrt itself: 1,000,000 op calls and 1,000,000 HTTP requests through rt.serve — 90k rps, p99 under a millisecond, zero errors — plus the saturation probe that found the real knee.
- [Checkpoint 7.3: an hour under load, no drift](https://404human.dev/js-runtime/checkpoint-7-3/): The soak: 1.56 million timer/fetch iterations over one hour — pending handles identical at minute 1 and hour 1, 389,730 fetches with zero errors, and an RSS shape that says allocator, not leak.

## MiniBTC: the build log

A Bitcoin-style blockchain built from scratch in Rust — consensus, UTXO set, P2P, mining, an HD wallet, JSON-RPC, CLI, explorer and an MCP server that can inspect the chain and draft payments but never spend without a human. Built in the open on a private devnet. Entries are in build order, oldest first.

- [Checkpoint P12: the whole chain, attacked, fuzzed and loaded](https://404human.dev/minibtc/checkpoint-p12-ship/): Every blueprint phase landed: 15 attack scenarios automated and passing, four fuzz targets at ~26M executions with zero crashes, nine property invariants, a 6M-operation load run, and a three-node devnet that survives a deliberate fork — resolved by most-work, with a two-wallet payment confirmed through the live network.
- [Checkpoint P13: the chain gets a face — explorer search and a real web wallet](https://404human.dev/minibtc/checkpoint-p13-ui/): Restructured after UX review (Solana-explorer-style flows): create/restore/unlock landing, two-step wallet creation with a show-once seed gate, dashboard hero + action bar, receive/addresses/activity pages — plus the earlier enriched explorer. Beyond the blueprint's read-only explorer: global search, pagination and dashboard stats on the public side, and a separate key-holding wallet UI with passphrase-to-memory sessions, per-session CSRF, origin checks, a two-step build-review-confirm-broadcast send flow, and a secret-free audit log — live-verified end to end on the devnet.

## Durable Workflow Runner: the build log

A background-task runner where accepting a job is a durable commit — acknowledged work survives process death, and history is bounded by design. Rust, a file journal, one writer. Built in the open. Entries are in build order, oldest first.

- [Checkpoint 0.2 — the journal survives kill -9](https://404human.dev/durable-runner/checkpoint-0-2/): D0–D3 implemented and drill-proven: the framed journal, the single writer, replayed recovery, compaction into a new generation, and a backup-restored second server. Plus the bug the drill caught that tests did not.
- [Checkpoint 0.3: the inspector, and the bug it caught](https://404human.dev/durable-runner/checkpoint-0-3/): GET /jobs + a SvelteKit inspector — and the journaled-refusal bug the first smoke test surfaced.
- [Checkpoint 0.1: the contract and the scaffold](https://404human.dev/durable-runner/checkpoint-0-1/): Guide 04 read end to end: a file journal is the authority, one writer, at-least-once attempts — the workspace, docs and crate skeletons are laid out.
- [Checkpoint 0.4: the external test pass — and the bug restart hid](https://404human.dev/durable-runner/checkpoint-0-4/): A full outside-guide test pass: workspace tests, pilot kill-9 → restore, dedup and refusal drills — plus the restart-orphan bug the drills caught and the fix that reconciles it.
- [Checkpoint 0.5: the load battery — and the honest FAIL](https://404human.dev/durable-runner/checkpoint-0-5/): Replay, a submit rate ladder and the 1M-submit sustained run — committed with machine and commit. The sustained gate is red twice over, solo included: the journal's per-record fsync is the ceiling, and admission refuses rather than loses.

## Learning

Ordered notes written while learning, with planned work labelled and evidence linked when an experiment has run.

- [Learning](https://404human.dev/learn/): The things I am learning, explained from the beginning. Small examples, basic math, experiments, and questions still open.
- [Model engineering from the beginning](https://404human.dev/learn/model-engineering/): Learning how models are built, trained, tested, and improved, starting with one adjustable number.
- [The model-engineering learning roadmap](https://404human.dev/learn/model-engineering/roadmap/): The path from one prediction to training, data pipelines, harnesses, evaluation, and better model versions.
- [Weights, predictions, and loss](https://404human.dev/learn/model-engineering/weights-predictions-and-loss/): One adjustable number, an expected answer, and a way to measure the mistake. The first step toward understanding training.
- [Gradients and weight updates](https://404human.dev/learn/model-engineering/gradients-and-weight-updates/): Why the weight can rise while loss falls, which direction to move, and how a useful direction can still lead to an oversized update.
- [Our first training loop](https://404human.dev/learn/model-engineering/our-first-training-loop/): A tiny program repeats prediction, loss, gradient, and weight updates, with every result written out.
- [How learning goes wrong](https://404human.dev/learn/model-engineering/how-learning-goes-wrong/): Models can capture too little, fit accidental details too closely, or make updates that fail to settle. Small recorded examples show the differences.
- [Data a model can learn from](https://404human.dev/learn/model-engineering/data-a-model-can-learn-from/): Inspect examples and separate their roles. Small support-message experiments show data problems and how duplicate leakage can produce a misleading validation score.
- [From text to a tiny language model](https://404human.dev/learn/model-engineering/from-text-to-a-tiny-language-model/): Text becomes tokens, targets, predictions, and generated output. Embeddings, an attention mechanism, a generation loop, and trained attention weights have run.
- [Training runs we can inspect and resume](https://404human.dev/learn/model-engineering/training-runs-we-can-inspect-and-resume/): What a training run is made of, what goes into a checkpoint, and a proof that a resumed run is identical to an uninterrupted one.
- [Adapting an existing model](https://404human.dev/learn/model-engineering/adapting-an-existing-model/): Fix a model's failure three ways — freeze, retrain the base, or train a small removable adapter — and compare what each one costs.
- [The harness around the model](https://404human.dev/learn/model-engineering/the-harness-around-the-model/): Our first practical Qwen build: request a tool, run a bounded lookup, return its result, inspect the answer, and repair the failures it reveals.

## Writing

- [The Coldcard seed bug, explained — and why your wallet's RNG is a consensus-grade decision](https://404human.dev/posts/the-coldcard-seed-bug-and-wallet-rng/): In November 2025 a 2021 build-config mistake gave Coldcard hardware wallets a weak RNG — seeds with ~40 bits of entropy instead of 128. ~1,816 BTC stolen. What actually broke, why entropy is an architectural decision, and how to test for it.
- [How Bitcoin's UTXO model actually works — explained by implementing it](https://404human.dev/posts/how-bitcoin-utxo-works/): No accounts, no balances — just unspent transaction outputs. What the UTXO set is, why reorgs need undo data, how coinbase maturity stops inflation, and where the model breaks. Written from a from-scratch implementation.
- [I built a Bitcoin node from scratch in Rust — consensus, P2P, mining, wallet, the works](https://404human.dev/posts/i-built-a-bitcoin-node-in-rust/): A complete Bitcoin-style blockchain in pure Rust: UTXO validation, headers-first sync, a miner, an HD wallet, JSON-RPC, a block explorer and an MCP server. What actually broke, what the attack lab caught, and what I'd do differently.
- [How tool calling actually works: the model never called my function](https://404human.dev/posts/the-model-never-called-my-function/): The model proposes. My program executes. Mixing those up is where the trouble starts.
- [Why I'm learning how models learn](https://404human.dev/posts/why-im-learning-how-models-learn/): I started by asking about an 8B blog-writing model. Then I had to ask how training even starts.
- [The bug hiding in the "nothing to do" path](https://404human.dev/posts/bug-in-the-nothing-to-do-path/): Colophon's crash-resume test caught a bulk job stuck 'running' forever — only when every item had finished before the crash. The empty path was the one path that never checkpointed.
- [Proving a noisy neighbor stays quiet: measuring isolation instead of asserting it](https://404human.dev/posts/noisy-agent-measured-isolation/): A token misbehaving at 600 requests a second shouldn't slow down the editors beside it. Colophon stopped asserting that and started measuring it — 99.7% refused, editorial p95 held within 2x.
- [The deadlock that only exists when two people publish at once](https://404human.dev/posts/postgres-lock-upgrade-deadlock/): Colophon's concurrency tests caught a real FOR SHARE to UPDATE upgrade race in the publish path. The fix is one row of lock discipline: take the lock you actually need.
- [Five lessons from PHP2Shell, PingCAP, Railway and the AGENTS.md hijack](https://404human.dev/posts/php2shell-pingcap-railway-agents-md-lessons/): A bitcoin dare, PHP2Shell, the PingCAP breach, Railway's leaked secrets and the AGENTS.md hijack: five lessons from one bad week, checked against the CMS I'm building.
- [What I'm building at Akira Shirase OSS, and the cycle every step goes through](https://404human.dev/posts/what-akira-shirase-oss-is-building/): A CMS that can prove what it published, an uptime monitor that never fakes a green light, and one loop for every step: plan, build, prove, write it up, ship.
- [I made an AI read the entire Rust Book. Then I tried to make it fail.](https://404human.dev/posts/i-made-an-ai-read-the-rust-book/): It passed. But the most interesting part was the one bug it did write.

## Pages

- [Home](https://404human.dev/): who writes here, what's running now, the build log at a glance, and every post.
- [Colophon CMS: the build log](https://404human.dev/colophon/): every entry, grouped by milestone, with what's planned next.
- [Service Monitor: the build log](https://404human.dev/service-monitor/): every entry, grouped by milestone, with what's planned next.
- [jsrt: the build log](https://404human.dev/js-runtime/): every entry, grouped by milestone, with what's planned next.
- [MiniBTC: the build log](https://404human.dev/minibtc/): every entry, grouped by milestone, with what's planned next.
- [Durable Workflow Runner: the build log](https://404human.dev/durable-runner/): every entry, grouped by milestone, with what's planned next.
- [RSS feed](https://404human.dev/rss.xml): every post in full, newest first.

## Optional

- [This site](https://github.com/akira-shirase-oss/minimal-portfolio): This portfolio and build log: built with Zola, drawn like a small control room, with real numbers from the posts. No tracking.