Published diagrams can no longer be editor previews

The last 24 hours in Nima Project had commits in four repositories:

  • nikki-asteinza-web
  • publish-service
  • nima-editor
  • world-cup-porra

The list looks scattered.

A personal home page, a publish service, the desktop editor and a social football pool do not look like the same problem.

But across these hours all four hit the same rule:

a published surface can no longer inherit the behavior of an internal preview.

That showed up in two ways:

  • in Notipad and nikki-asteinza-web, because a published Mermaid block could no longer behave like a nice embedded editor block;
  • in Ultimate Porra, because entry, voting and modal layers could no longer afford decorative or ambiguous feedback once users were operating the product for real.

Nikki's home stopped sketching an idea and started publishing a timeline

The most visible front was nikki-asteinza-web.

Within less than a day, several commits landed in sequence:

  • Use sequence diagram for home trajectory
  • Use CV timeline Gantt on home
  • Reposition full-stack training in home Gantt
  • Shorten Gantt labels on home
  • Correct home trajectory dates
  • Show full yearly Gantt range

This was not a simple visual preference between one Mermaid type and another.

It was the moment Nikki's trajectory on the home page stopped being an approximate narrative device.

The sequence diagram worked for exploration.

The Gantt forces a different contract:

  • which dates are exact and which periods overlap;
  • where the full-stack upgrade actually begins;
  • how much room each stage needs to stay readable;
  • and how that whole shape behaves once published outside the editor context.

That is why highly specific follow-up fixes appeared right after: shorter labels, repositioned training, corrected dates and a full yearly range.

The useful lesson is this:

once a timeline becomes public interface, it can no longer live on narrative intuition; it starts depending on data precision, viewport and real readability.

Publish had to admit Mermaid was not just content

The strongest commit chain was in publish-service:

  • Use shared Mermaid Gantt styling
  • Version published editor CSS assets
  • Render published Gantt in wide scroller
  • Zoom out published Gantt timeline
  • Publish site static assets
  • Version published static asset references
  • Fit published Gantt gutter dynamically

And in parallel, nima-editor pushed the same conversation into the source of truth:

  • Share Mermaid Gantt scroll styling
  • Tune shared Mermaid Gantt gutter

This matters because Mermaid is no longer treated like an embedded SVG that the web can somehow absorb later.

The contract is much more explicit now:

  • the editor defines shared styling for Gantt diagrams;
  • publish stops hand-copying that layer and reuses it;
  • published documents get a wider scrollable container for real timelines;
  • the gutter is no longer a fragile constant and starts adapting dynamically;
  • and published static assets are versioned so CSS and resources do not depend on stale cache.

That last point looks like infrastructure, but it is really about reading.

If you change diagram behavior but the browser serves old CSS, the reader does not see the new contract.

They do not see a partial improvement.

They see a broken publication.

The chat conversation was clearer than the changelog

The commits explain what changed.

The chat explained why with much less politeness.

In the June 22 session, the feedback was extremely concrete: drop the blue glow on the diagram preview, remove every hover affordance, and lay the flow diagrams out in two columns.

That feedback summarizes the product error better than any diff.

The problem was not a missing CSS rule.

The problem was letting the published web keep visual signals that belong to an interactive preview:

  • blue glow;
  • hover affordance;
  • and the feeling of a block that should respond like a tool, not like reading surface.

Once a diagram is published, the reader does not need to remember that it comes from a rich editor.

They need stable, readable content.

No decorative noise.

No inherited editor states.

Ultimate Porra learned the same rule by a different route

In world-cup-porra the form was different, but the product pressure was the same.

The commits inside the window were:

  • Show winner-only vote feedback
  • Unify vote points feedback styling
  • Improve entry dashboard and voting UX
  • Fix modal scrim hover state

Taken together, they tell one story:

the app can no longer mix primary feedback, secondary actions and visual decoration as if the user were still exploring a prototype.

Now entry and voting flows have to make it clearer:

  • which feedback actually matters when reading a prediction;
  • where copy and reuse actions belong;
  • what result context already needs to be visible from the dashboard;
  • and that a scrim is a focus layer, not something that should answer to hover.

That connects directly with the publish lesson.

In both cases, the same anti-pattern is being corrected:

a mature interface can no longer react as if everything were an internal exploration surface.

What really changed in these 24 hours

The superficial version would be this:

  • Nikki replaced one diagram with another and adjusted dates;
  • publish fixed Mermaid Gantt and versioned assets;
  • the editor shared styles;
  • Ultimate Porra polished dashboard, voting and modal behavior.

The useful version is different:

Nima Project became stricter about separating what belongs to the editor from what belongs to the published product.

That forces several decisions at once:

  • a public timeline needs exact data, not just a persuasive story;
  • a published diagram needs scroll, gutter and width designed for real reading;
  • the styles that define that reading cannot fork between editor and publish;
  • and a product microinteraction must justify its presence instead of inheriting hover or glow by habit.

What I take from this stretch

  • Mermaid stops being "rich content" once users depend on it to understand a trajectory.
  • Publishing well is not only about rendering Markdown; it also means governing shared CSS, cache and versioned assets.
  • A long Gantt does not fail because it is large; it fails when it is published with rules built for smaller blocks.
  • Hover becomes debt when it does not communicate a real action.
  • When a public surface still feels like a preview, the problem is not visual: the contract between tool and product is still unfinished.

These 24 hours were not about making prettier diagrams.

They were about something more serious:

deciding that published output can no longer behave like an editor approximation, because it is already occupying the place of the final interface.


Part of my product and platform notes. Follow the blog or contact me.