Render and Publish

A published page can no longer load the same runtime for everything. Content has to decide which capabilities are activated and which stay out.

A published Mermaid timeline is not fixed by adding overflow. It needs a reading contract: visible scroll, measured gutter, controlled scale and labels that remain inside the first viewport.

Between June 22 and June 23, Nima Project stopped treating Mermaid, timelines and microinteractions as internal previews and started closing them as real public interface.

Between June 10 and June 11 there were almost no new commits across Nima Project. That made the lesson clearer, not smaller: producing knowledge is not enough; publishing it also depends on permissions, process identity and credentials lining up.

How the need to publish documents with the same fidelity as the editor led to extracting render, sharing visual components and turning an app into reusable services.

How I discovered that the same enriched Markdown renderer had been copied into several consumers, what each copy did, and how I planned the unification without losing visual parity.

People ask "should this become a microservice?" when they usually mean three different things. This separates the goals and gives a decision tree that avoids over-architecture.

If someone uploads Markdown to your service, you should be very clear about what happens to that content. This breaks down what is sent, what is not, and why.