How Neura is built

Summary

The engineering notes behind the library: how claims get verified before they ship. Neura's drop-in promise is only as good as its receipts, so the receipts are the process - every compatibility statement on this site traces to a check that ran against the real thing.

Verified against sources, not documentation

Pixel parity, measured

Component styling was audited by rendering identical markup under the original stylesheet and Neura's, then pixel-diffing the results. The whole library was also swapped into a live Nsys portal and compared page by page (login, dashboards, admin, dialogs, header menus), landing within 0.07% per page. Deliberate divergences are documented, not silent.

Behavioral contracts, executed

Where the predecessor's documentation and its source disagreed (and they did), the source wins: legacy APIs were probed by running the original library's code and asserting Neura's implementation against its actual output, quirk-for-quirk. The compatibility layer also went through a full source audit of the consuming platform, so every legacy call site is known, covered, or documented as dead code.

Three test layers, all green before every commit

Unit (component logic through public APIs), contract (build invariants that guard the failure modes that actually bit: alias coverage, bundle contents, the full API surface), and browser (real keyboard and pointer interaction in Playwright, including reduced-motion and forced-colors emulation). The kitchen sink renders every component on one page backed by a zero-console-errors spec.

Depth as default

Full RTL via logical properties and direction-aware JS, 42 interface-language packs (honestly labeled machine-translated until natively reviewed), keyboard models for every interactive component, and an accessibility layer verified under real emulation. The parts one-off UI code never gets right are the parts that are tested hardest here.

How a change lands

A change isn't done when the code works: the three test layers must pass, the reference page and llms.txt must describe the new behavior exactly, and the changelog entry must say what changed and why, including what was tried and reverted. The documentation conventions are strict on purpose: demos run exactly the code shown next to them, and the predecessor library appears only where compatibility itself is the subject.