Why a portfolio eventually needs notes, not just project cards

Project cards and notes can live on the same site, but they do not provide the same kind of evidence.

A card helps readers quickly understand what something is and where they can see it. A note can explain why it was made that way, which trade-offs shaped it, and which results were actually verified. Putting every explanation into a card makes a project list harder to scan. Keeping only the cards leaves readers to guess many important decisions.

The main judgment is: project cards make work discoverable; notes make its methods and limitations understandable. They are not simply longer and shorter versions of the same page. They carry different responsibilities for publicly substantiating the work.

Project cards help readers find the work

In the implementation documented by the original note, cards on the project page have a fairly fixed set of contents: a project name, date, image, technology tags, and links to a demo or project page. These fields support quick comparison and selection. Readers do not have to open every project to decide whether to keep looking.

The judgments a card can support are usually narrow:

• The project is part of the site’s collection of work.
• It has a name, an image, and a basic classification.
• Readers can follow a link to an actual demo or a public project.
• The dates and tags shown on the page are explicit information in the documented data.

This information is useful, but it does not automatically explain architecture, requirements, failure paths, or ongoing maintenance. An image shows a result. It cannot substantiate the decisions behind the screen.

Notes explain how the result took shape

Notes have a different responsibility. They can turn an apparently simple result into questions readers can follow:

• What problem needed to be solved at the time?
• Which requirements were retained, and which were not implemented?
• Why was this data model, route, or interaction chosen?
• What did the tools and tests actually check?
• What remains unmeasured, or still needs a person’s subjective assessment?

This does not require a full case study for every project. A decision can become a standalone note if it offers something useful for other pages, content workflows, or development work. Conversely, if the material is just an image and an external link, a card may already be enough.

The public notes documented here cover the site rebuild, content publication, multilingual routing, verification, and AI collaboration. They are not just extended descriptions of project cards. They organize methods from the development process that can be made public and checked.

Cards and notes support different levels of evidence

The same project can appear on both the project page and in a note, but the two entry points cannot replace each other:

Entry point	Better suited to substantiating	What should not be inferred directly
Project card	The project’s existence, basic name, image, and external entry point	Architecture quality, user outcomes, or the complete development process
Public note	Recorded decisions, limitations, implementation, and verification scope	Business results, absence of problems on every device, or understanding by every reader
Actual demo page	A particular link can be opened in its documented state	Internal data models or error handling that is not demonstrated
Code or test results	The checked conditions hold within the checked scope	Devices, deployments, or usage scenarios that were not tested

Adding notes does not turn “the project exists” into “the project must be successful.” It provides more readable evidence, so readers can see where a conclusion comes from and where it stops.

Do not turn project cards into miniature articles

If every card contains background, decisions, technical details, limitations, and a long list of results, the list loses its original purpose. Readers can no longer compare projects quickly, and large amounts of text at the same level stretch the mobile page.

A more reliable division of responsibility is:

• Keep only the information needed to identify the project on its card.
• Link to an actual demo, project page, or public note when the full background is needed.
• Let a note address one main question instead of copying all the project information again.
• Do not force a project into a full case study when there is not enough source material.

The aim is not to split content into ever smaller pieces. It is to make the reading effort at each entry point clear. Cards are for browsing; notes are for understanding. They should point readers to each other rather than compete over the same content.

Notes cannot invent outcomes for a project

A note is longer than a card, but that does not permit more unsupported claims. If the available evidence consists of implementation code, screens, and build checks, those are the things it can explain. Without user research, it cannot supply reader preferences. Without traffic or collaboration data, it cannot add business results.

Likewise, a note should not repackage the dates, tags, and links on a project card into a different story. The project name, whether a link exists, and whether a feature is actually mounted all need to be checked against the real data and where it is used.

Public notes are useful because they make the scope of a judgment clearer, not because they make the results sound bigger.

When a project is worth expanding into a note

Start with a few questions:

1. Does the project involve a decision that is useful to someone other than its author?
2. Can implementation, data, or output verification support that decision?
3. Would readers miss an important trade-off if they saw only the project card?
4. Can the article answer one main question rather than retell the entire project?
5. Which material can be public, and which remains private or unconfirmed?

If the answers are all no, keep the card for now. There is no need to manufacture an article without new evidence for every project just to make Notes look populated.

If the answers are affirmative, the article can also stand without depending on a project card. Readers should leave with a way to make a judgment, not merely remember a project’s name.

How the site brings the two entry points together

In the arrangement documented here, the project page lets readers browse website and system projects, content and visual work, and a separately labeled AIGC character-visual section. Notes provides public records of architecture, content engineering, interfaces, and AI collaboration. The two entry points do not describe the same data: one emphasizes what was made, while the other explains how decisions were made and work was delivered.

This division also retains a limit: not every note needs to correspond to a single project, and not every project needs a note. Content earns its place by answering a clear reader question, not because there is still a card on the site waiting to be filled.

Project cards help readers find the work. Public notes help them understand how it took shape. When each keeps its own evidence boundaries, the site does not have to pretend that one kind of page can answer every question.

Scope of this record

This note is based on the project-page card data, external entry points, Notes content model, and existing page contracts documented in the original article. It distinguishes the responsibilities of showing work and recording methods. It does not treat project screens, a passing build, or article content as evidence of user responses, search performance, business results, or a complete case study.