Portfolio content system

The question

How can this site publish technical work without turning unfinished ideas into public claims or making every article depend on a database?

The current answer is a small, file-based content system. Project and writing entries live as MDX, while a server-only manifest reads and validates their metadata during the build.

What exists

The system has separate project and writing collections, schemas for each content type, filename-derived slugs, calculated reading times, and production filtering for drafts. References between projects and articles are checked before pages are generated.

Known entries are prerendered as project or writing routes. A path that is not in the manifest returns the site’s not-found page.

Implementation choices

• Keep authored content in Git so writing and implementation can change together.
• Parse frontmatter once through a typed schema instead of trusting exported MDX metadata at each route.
• Require a publication date only when an entry leaves draft status.
• Keep interactive examples inside narrow Client Component boundaries.
• Render the article itself on the server so the explanation does not wait for client-side JavaScript.

How to inspect it

The content model is in lib/content.ts. Route modules under app/(site)/projects and app/(site)/writing generate known paths and route-specific metadata. The checks for this iteration are linting, TypeScript, the production build, and browser tests.

Limits

The system now publishes interactive robotics lessons, the palletizing project, and the Navier–Stokes explainer. Robotics Briefing also has a public archive and an email subscription flow.

These publishing features check structure and references. They do not establish that a lesson's mathematics is correct, that a simulation matches hardware, or that a research summary supports its claims. Each article and project still needs its own calculations, tests, sources, and stated limits.