Public blog markdown

Why the main-site blog should not fork the content system

A polished main-site blog should not come at the cost of a second authoring workflow.

# Why the main-site blog should not fork the content system

Moving the final public blog to `parametrig.com/blog` was the right branding
move.

But that does not mean the authoring model should move with it.

## Presentation and authoring are different concerns

The final public surface should live on the main site because that is where the
brand, navigation, and corporate context belong.

The authoring source should stay in one place because that is how we avoid:

- duplicated markdown pipelines
- conflicting canonical URLs
- two sets of discovery artifacts
- editorial drift between repositories

## The practical contract

So the long-term contract is:

- author once in `docs`
- export structured blog artifacts
- render the final presentation from `web`

That gives us both:

- one content system
- one polished public destination

## Why this matters later

This becomes even more important once non-engineers are publishing content.

The more people involved, the more expensive it becomes if the system asks them
to guess which repository is the "real" source of a post.