Nikki Asteinza
Contact

Operations can no longer depend on implicit memory

The latest work cycle in Nima Project had changes across five areas:

  • the public pool app;
  • the product API;
  • the publishing service;
  • Nikki's public site;
  • and the shared workspace documentation.

This was not a one-feature day.

It was a day of correcting a riskier dependency:

too many surfaces were still working only if someone remembered the right context outside the surface itself.

That showed up in four different places:

  • an Ultimate Porra user still had to infer too much about language, labels and actions;
  • support still needed too much database and internal-model knowledge to inspect or fix predictions;
  • a published site could still break navigation or overflow diagrams if the reader arrived through a different generated route;
  • and Nikki's home page still made readers reconstruct a career trajectory instead of reading it as a clear sequence.

Ultimate Porra started explaining itself instead of relying on habit

The large commit in the window was Add i18n and polish Ultimate Porra UI.

By size it looks like a broad refactor.

But the deeper change is more specific: the app stops depending on fixed Spanish literals, scattered copy and structures that only work if the user already understands the product.

Several visible decisions landed here:

  • a real i18n layer appears, with es and en message catalogs, runtime and language switching;
  • the public shell gains meta description, canonical, og:* and twitter:*, so the app also explains itself outside the app;
  • entry flows, game actions, account, ranking, calendar and voting stop relying on loose strings and start living inside a message contract;
  • and the invite code stops behaving like a fuzzy secondary control and becomes a more explicit part of the flow.

This connects directly with recent product prompts.

Recent product feedback kept pushing in that direction: make invite actions easier to understand, keep join codes visible, and stop forcing users to infer state from scattered copy.

The product conclusion is straightforward:

once a social app already has access modes, games, rankings, rules, bonuses and real support work, it can no longer behave as if everyone shares the project's internal memory.

The pool admin gained eyes and hands, not just permissions

The second front was in world-cup-api and in the root documentation.

This was not only about adding one endpoint.

It was about creating a less blind way to operate real support.

First came an administrative correction flow for predictions.

That change lets support locate a game and a user through controlled admin tooling, inspect the current state and apply a bounded correction when the normal user flow is no longer the right path.

Then came complementary read flows for admin support.

At that point admin no longer only mutates.

It can also ask:

  • which games a user belongs to in one competition;
  • what prediction that user submitted for one team and one date;
  • and how that prediction is distributed across games and matches.

That matters because it changes the kind of support the system allows.

Before this, resolving a case like that depended much more on remembering tables, ids, joins and internal states.

Now the API itself starts exposing an administrative reading of the problem.

It is not just "an admin token can do anything".

It is something better:

a contract for inspecting before touching, and for correcting without opening a manual database surgery.

Publish stopped assuming the reader arrived through the "right" path

In publish-service there were two commits that are small in size and large in consequence:

  • Fix Notipad publish internal links
  • Contain published Mermaid overflow

The first one corrects a classic fragility in systems that publish Markdown to the web:

links can keep looking correct while the author navigates the content in their own head, but still fail or resolve oddly once a reader arrives through another locale or a different generated route.

The change rewrites links inside the published body according to logicalPath, locale and current route, and also adjusts default-locale redirection so it uses stable root-relative paths.

The second one fixes something equally important, even if more visual:

it stops assuming a Mermaid diagram will always fit inside the published reader container.

Instead it:

  • constrains the real width of the published document;
  • wraps Mermaid blocks explicitly;
  • and allows horizontal scrolling where necessary without breaking the whole layout.

Both fixes respond to the same class of error:

publishing is not just dumping HTML; it is guaranteeing that the final reader can navigate and understand the page without knowing the editor's internal assumptions.

Nikki's home page moved from static presentation to readable trajectory

The fourth front was nikki-asteinza-web with:

  • Add Nikki home trajectory diagram
  • Clarify home trajectory timeline

This was not "technical" in the classic code sense, but it was fully product work.

The home page already explained experience, focus and products.

What it lacked was a visible progression:

  • what belongs to the human foundation;
  • what belongs to technical accumulation;
  • where XR enters;
  • when defence appears;
  • and how all of that leads into technical leadership and platform-building.

That is why the second iteration did not stop at adding a pretty Mermaid block.

It added an explicit temporal reading instruction and reorganized the diagram as a stage-based timeline: 2015-2020, 2020-2021, 2021-2024, 2024-2025, 2025-2026 and now.

That avoids another common failure mode:

a personal website that forces the reader to reconstruct the professional narrative alone.

The home page no longer only says this is what I have done.

It starts saying this is how it connects.

What really changed in these 24 hours

The surface-level version would be:

  • Ultimate Porra gained i18n and cross-cutting UI polish;
  • the product API gained admin tooling to inspect and correct predictions;
  • publish-service fixed internal links and Mermaid overflow;
  • nikki-asteinza-web made Nikki's trajectory easier to read.

But the deeper change is more useful to write like this:

Nima Project started treating operational comprehension as part of the product.

That means several things at once:

  • a user should not depend on the default language or inherited copy to understand where they are;
  • support should not depend on SQL memory to fix a real incident;
  • a reader should not depend on entering through the "correct" route to navigate published content;
  • and a visitor on the home page should not have to guess the sequence of a professional trajectory.

What I take from this stretch

  • Locating and correcting are not separate support tasks: good admin flows need readable inspection first.
  • A real bilingual system does not end at translated content; it also touches metadata, labels, actions and navigation.
  • Robust publishing does not only generate pages: it rewrites links and contains visual blocks for actual reading conditions.
  • A technical portfolio also has information architecture; listing experience is not enough if the progression stays unclear.
  • When a surface depends on implicit memory, the problem is not the user: it is product debt.

These 24 hours did not add the loudest novelty in the project.

They added something more necessary:

the decision that every important surface should carry its own operational context inside itself, instead of asking the reader or the admin to remember it from elsewhere.

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