Refactoring published and private content

Once the repository structure was clearer, I cleaned up how posts and projects are shown or hidden. I did not want every content file to be treated as either fully public or completely absent.

The workflow needed to answer two separate questions:

• is this entry ready to participate in the site?
• if it participates, should production show it?

Those decisions are related, but they are not the same.

The frontmatter shape

Posts and projects now use two explicit fields:

published: true
private: false

published controls whether the entry is part of the site at all. private controls whether it should stay out of production builds.

That distinction gives me a useful review state. I can render a draft locally, check the layout and metadata, and still keep it away from the public site until it is ready.

The filtering rule

The implementation is intentionally small: unpublished entries are hidden, public entries are visible, and private entries are only available outside production.

Keeping that behavior in the shared content helper means the route pages do not need to repeat the same checks. Posts and projects can both use the same rule before sorting or filtering by locale.

Why this helps

This changed how safe content work feels. I can create or revise a post without immediately deciding that it belongs on the live site.

It also helps with project pages. Some portfolio entries need more review because they include older work, external links, images, or technical claims. Keeping those entries visible locally gives me room to refine them without deleting drafts or weakening the publishing workflow.

Tradeoffs

The tradeoff is one more frontmatter field to maintain. That is acceptable because the behavior is explicit and easy to inspect in each file.

The important part is that templates and prompts respect the same default. New content can start private, then become public only when the page is intentionally ready.

Result

This refactor made the content workflow less brittle. It gave me a clear path for working on drafts, reviewing them locally, and publishing them only when they are meant to be public.