WorkspaceOngoing · English

Building a Portfolio—and the System That Keeps It Evolving

Role
Independent Product Designer / Designer–Builder
Timeline
Jun 2026–Present
Status
Ongoing independent project
Portfolio workspace displayed on a laptop above a dark sculptural plinth
Portfolio reconstruction. A presentation image of the current Portfolio workspace, used to establish the product direction. It is not a photographed device or an independent historical release.

The project began as a low-budget attempt to build a distinctive, self-maintainable portfolio with AI. It became a longer-term product problem: how could visual tools, engineering tools, content, code, and versions evolve together without losing design intent or prior decisions?

Google AI Studio explored visual prototypes. Claude Code and Codex handled code comprehension, differential integration, debugging, and maintenance. DeepSeek API supported part of the earlier Claude Code workflow as a lower-cost model option. GitHub preserved version state; Vercel reached a working deployment; the Cloudflare path remains unresolved.

This is an evolving independent project. It does not yet claim verified traffic, hiring conversion, task-completion, or performance improvements.

Experience

A working spatial portfolio with a conventional Selected Work path

Next outcome
Content

Distinct responsibilities for projects, tags, assets, case studies, and site copy

Next outcome
Evidence

Independent case-study routes for three real projects in the Aug 2 system snapshot

Next outcome
Governance

Durable product boundaries, implementation records, and shared AI working rules

From full handoffs to bounded diff sync

Google AI Studio could reach the intended visual atmosphere faster, while engineering tools were better at understanding the repository, components, and build constraints. The tools were complementary, but they did not naturally share one project context.

Passing a complete generated package preserved visual detail but could overwrite local improvements and made comparison more expensive with every version. Rewriting the result as a UI specification was safer, but flattened motion, component behavior, image relationships, and atmosphere.

I changed the unit of handoff. The running Next.js repository remained the current state; visual output became a candidate change; and the engineering tool first identified differences and dependencies before integrating only the approved scope.

Full-package handoff

Rejected as the default
  1. 1Visual output
  2. 2Reinterpret the page
  3. 3Overwrite risk

Bounded synchronization

Current working method
  1. 1Current system + candidate diff
  2. 2Impact check
  3. 3Local merge
  4. Verification

Bounded diff sync describes the current working method; it is not an automated synchronization product.

Tags are not Projects

The first working version already contained the spatial workspace, tag launchers, central project folder, and identity cards. It proved the experiential direction could run—but it also exposed a structural error: early generated concepts treated About Me, HMI, AI Related, and Design System as folders or projects in a strict tree.

The first working portfolio workspace with tag launchers, a central folder, and identity cards
Source evidence. First working workspace prototype, June 2026. Its interface labels, numbers, and version copy document that moment; they are not current project claims.

I separated reusable Tags from independent Projects. A Project owns a stable identity, public name, content, assets, and case-study narrative, and can connect to multiple Tags. Tags support interest-led discovery. The Mac OS folder remains the unfiltered route to all projects.

This model supports multiple discovery paths and independent case-study pages while preserving stable project identities for future localization and genuine historical versions.

HMI
Design System
AI Related

One independent project

Stable identity · content · assets · case study

Mac OS folder → All projects

The website became a product

Once the prototype entered Next.js, GitHub, and real deployment environments, looking correct locally was no longer enough. Visual fidelity and motion had to be evaluated alongside build health, content traceability, platform compatibility, and regression risk.

  1. 01

    Visual intent

    Approved prototype direction and interaction behavior

  2. 02

    Product code

    Components, types, dependencies, and build state

  3. 03

    Content & assets

    Project-owned sources with stable references

  4. 04

    Git history

    Version record, rollback context, and shared baseline

  5. 05

    Deployment

    Vercel working; Cloudflare unresolved

Deployment stayed honest

Vercel has hosted a working deployment, although access from mainland China is unstable. Cloudflare was genuinely attempted and remains unresolved; it is documented as an open constraint rather than presented as a launch success.

One product, many future states

The portfolio is one living product. Minor versions continue along the main line. An archive route or historical entry only becomes justified when a real major experience has been superseded. V1/V2 entries remain future work because no public historical releases exist yet.

The workflow became a Portfolio Operating System

Tools can change, so a rigid ‘design goes to A, development goes to B’ pipeline would not preserve continuity. The durable system is the responsibility boundary and the shared product state.

I initially used Claude Code as the primary engineering collaborator in VS Code. As Codex provided more complete workspace integration, it became the main collaborator and Claude Code shifted to a supporting role. The change did not trigger another rebuild; it pushed scattered decisions into durable system records.

Experience layer

Demonstrates spatial organization, interaction craft, and visual judgment.

  • Spatial workspace
  • Windows and motion
  • Conventional project paths

Content layer

Lets projects, classifications, media, and narratives evolve without becoming the same entity.

  • Project
  • Tag
  • Asset
  • Case Study
  • Global content

Governance layer

Preserves durable boundaries, current implementation, and scoped change so the next collaborator does not restart the project.

  • Portfolio OS
  • Current System
  • Migration plans
  • Audits
  • AI Working Agreement

Portfolio Operating System is a system-level description of this portfolio’s experience, content, and collaboration model—not a separate software product.

What the project proves—and what remains open

The outcome is not the number of AI tools involved. It is the ability to define content entities, set boundaries between visual and engineering work, protect an existing product state, distinguish evidence from inference, and turn temporary decisions into a system future collaborators can follow.

Experience

Spatial workspace and conventional project browsing

Current implementation
Content

Project–Tag relationships, project assets, and independent case studies

Current implementation
Collaboration

Bounded differential integration around a Git baseline

Qualified; not automated
Governance

Product boundaries, current-state records, plans, audits, and shared rules

Current implementation
Deployment

Working Vercel deployment; unresolved Cloudflare route

Qualified / unresolved

Still open

  • Archive one verifiable AI Studio-to-repository diff and a complete handoff case.
  • Generate and verify the final Project–Tag diagram from current structured data.
  • Document the final deployment decision after the Cloudflare path is resolved or abandoned.
  • Define performance, reading-behavior, and recruiting outcomes only after stable data exists.
  • Create V1/V2 history only after a real major experience has been replaced.