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

This is publishing infrastructure, not the robotics project the portfolio is intended to feature. There is no public SLAM demo, external repository link, newsletter delivery, or syntax highlighting yet.

The next useful step is to use the same structure for a substantive robotics project once the implementation and evidence exist.