01 /Overview.
A visually expressive portfolio still needs the same route ownership, evidence boundaries, and performance discipline as any other product surface.
Why it matters. Recruiters need a quick path to signal; engineers need a deeper path to the source, decisions, and limitations. Those paths should share one source of truth.
Workflow. A server-rendered project index leads to one canonical case study per project, with stable source and verified-live resolvers alongside the document.
Outcome. A maintainable recruiter surface with canonical case studies, stable source/live namespaces, and explicit evidence boundaries.
02 /My contribution.
I designed and implemented the project registry, canonical route system, evidence presentation, and the rendering boundary around the existing interactive scenes.
Collaborators and attribution. Solo repository project.
Constraints.
- Project content must remain centralized and CV-scoped.
- Textual case studies should not pull the interactive 3D bundle into the initial render.
- The canonical host is configured explicitly so metadata remains on the intended public domain.
03 /System architecture.
04 /Technical implementation.
Primary technologies. Next.js · TypeScript · React · React Three Fiber · Three.js · CSS
- Canonical `/projects/[slug]` pages use static params and a shared case-study component.
- Alias and link resolution is pure data logic, with loopback and malformed URLs rejected.
- Metadata, sitemap, navigation, resume entries, and homepage cards consume the same CV registry.
Hardest engineering problem. The important boundary is separating the permanent professional namespace from changing infrastructure. A case study can remain stable even when a deployment or source provider changes.
Keep project facts centralized
The public project set, aliases, links, availability, claims, and SEO copy live in the content model rather than being repeated across route components.
Make external destinations resolvers
Live and source routes are data-driven redirects; the portfolio never embeds or proxies another application.
Defer heavy scenes
One shared Three/R3F scene loads after browser idle time and persists across recruiter routes. Reduced motion and unavailable graphics retain a static composition alongside server-rendered content.
05 /Testing and validation.
- Node test contracts cover canonical lookup, aliases, legacy redirects, availability, and malformed destinations.
- Metadata and sitemap tests cover canonical origin and public-route scope.
- Typecheck, lint, content validation, asset validation, and production build remain release gates.
06 /Results and evidence.
Repository evidence covers the Next.js App Router, TypeScript, the existing R3F/Three experience, and the project-system test contracts added here. The Vercel deployment was reachable during the 16 Sep 2026 deployment check; uptime and field performance are not inferred from that smoke check.
- The public project index is generated from the canonical CV registry.
- Source and live actions have explicit availability instead of guessed destinations.
- Public project scope
- Registry-backedCanonical CV projects in the recruiter-facing index
- Rendering boundary
- DeferredShared R3F scene loads after idle time; reduced motion retains static artwork
07 /Limitations.
- The custom-domain deployment is verified at audit time; uptime and performance traces still need ongoing measurement.
- The interactive scene remains an explanatory visualization, not an application runtime or telemetry source.
- Performance results still need to be measured on the chosen production deployment.
08 /What I would build next.
Measure the deployed case-study routes with real mobile performance traces, then add project-specific social-card artwork only if it improves sharing signal without increasing the critical path.
- A portfolio architecture should make uncertainty visible instead of hiding it behind visual polish.
- Stable internal paths are more durable than exposing infrastructure names in a CV.