This is a personal website. It is also a production repository.
Those statements are not in conflict. The site can contain cats, coasters, LEGO, court-audio notes, a pixel studio, and a boardwalk footer while still having typed content, release checks, security boundaries, and a clear answer to “Did this actually reach production?”
The discipline is not here to make the site feel corporate. It is here so I can keep changing it without gradually losing the parts that work.
Most of the site is Astro-generated HTML. Articles, Guides, project pages, profile material, and the authored reference content do not need a client application wrapped around them.
React islands handle the pieces that actually interact: navigation state, command search, animated scenes, live park data, and a few focused tools. The Cloudflare Worker owns dynamic routes and third-party boundaries. The default remains readable HTML.
That architecture gives each layer a job:
- Astro owns durable pages and metadata.
- Typed content and configuration own claims that should not drift between templates.
- React handles bounded interaction rather than the entire reading experience.
- The Worker keeps secrets, provider contracts, and private logic out of the browser.
It is not the only way to build a site. It is the right fit for a place where most visits begin with reading and a few paths need real application behavior.
Design consistency is not only a Figma problem. It can regress in code.
A new page can invent its own outer width. A focus ring can disappear inside an overflow-hidden card. A future-dated article can leak into RSS before it appears on the site. A generated share image can be cached forever after its source changes. A dynamic response can skip the security headers that static files receive.
The repository checks contracts like these directly. The release path includes type and content diagnostics, unit and contract tests, a static production build, Worker configuration validation, bundle and metadata checks, browser smoke coverage, contrast combinations, composition modes, and rendered layout widths.
That list is not proof of perfect accessibility or perfect performance. It is a repeatable floor. Physical screen-reader testing, field performance, provider behavior, and the live custom domain remain separate evidence.
This distinction has saved me from a lot of accidental optimism:
- A local file changed.
- The local tests passed.
- A commit exists.
- A branch was pushed.
- A pull request was merged.
- A production build completed.
- The custom domain serves that exact release.
Those are seven different facts.
Each production build publishes its release identity, and a post-deploy check waits until the live domain reports that exact release. Repository tests can prove that the code is internally consistent. They cannot prove that DNS, Cloudflare, a deploy hook, or a cached response has placed the same bytes in front of a visitor.
That is why “merged” and “live” do not get used as synonyms in the handoff.
The site has canonical guidance for brand, voice, visual behavior, project inheritance, and content truth. That may sound like an alarming amount of paperwork for a homepage with a cat in it.
The useful part is that each document answers a different maintenance question.
- What has to remain recognizably mine?
- How should technical and personal writing sound?
- Which visual roles are shared, and which artwork stays bespoke?
- What may a future project inherit without cloning this site?
- What evidence is required before a public claim appears?
Without those boundaries, a cleanup can flatten the art, a redesign can turn into a generic portfolio, and a quick copy pass can accidentally promote a concept into a product.
Documentation is not there to stop change. It lets a change be deliberate.
Production discipline can produce a sterile site if every unusual thing is treated as debt.
The pixel scenes contain exact geometry. The park maps are authored compositions. The Guide share pages use platform-required dimensions. The footer is not a generic site-footer primitive waiting to be extracted into a package.
Those values should be explainable, but they do not all need to become global tokens. The maintenance work focuses on accidental repetition: ordinary spacing, page widths, duplicated URLs, repeated status strings, and near-identical interface states.
The goal is not the smallest stylesheet or the fewest numbers. The goal is knowing why each layer exists.
I do not need this site to behave like a bank. I do need it to tell the truth, remain navigable, keep private boundaries private, and survive the next idea I add at 11:30 at night.
That is what the release system is for. It protects the readable parts, catches the boring regressions, and leaves enough room for the next authored visual to be strange on purpose.