It has been exactly three months since the last major architecture log. Figranium initially started as a raw backend project back in December 2025, built under a strict microservice framework to see how far we could push deterministic web interaction. While the core structural design was incredibly solid, stepping away from the codebase for a brief period provided the exact operational clarity needed to realize what this platform actually needs to be to survive in production environments.

The broader browser automation and scraping ecosystem right now is completely obsessed with fully autonomous AI "agents." The industry is rushing to build systems that capture a generic screenshot, dump a messy DOM tree into a context window, and blindly ask a language model, "Where should I click next?" It looks fantastic in a 30-second conceptual video. In the real world, it is slow, wildly expensive to scale, and incredibly fragile—the moment a dynamic wrapper shifts by ten pixels, or a heavy infinite-scroll script delays a lazy-loaded container, the AI hallucinates, throws a generic error, and runs up a massive API bill.

Figranium is built on an entirely opposite philosophy: 100% deterministic, predictable execution. We believe that AI is an incredible design assistant for building workflows, but it should never be the fragile, unpredictable pilot sitting in the runtime cockpit during production execution.

Our upcoming release, v0.13.0, drops tomorrow on June 29, and it introduces a massive architectural pivot to lock in that exact promise. Here is a deep dive into what we are changing, what we are intentionally breaking, and why we are cleaning house.

---

Retiring the Legacy NPM Package#

The single biggest decision in v0.13.0 is an intentional step backward in distribution to make a massive leap forward in stability: we are officially retiring the NPM version of Figranium.

When building a reliable browser automation engine, forcing users to manage their own local Node.js environments, conflicting global npm dependencies, and operating-system-specific Playwright browser binaries is a recipe for a support nightmare. If a developer attempts to spin up a script on Windows, macOS, or a custom Linux distro, local environment variations inevitably introduce tiny, unpredictable edge cases. If a tool’s core value proposition is that it never breaks, you cannot start the user journey on top of a fragile, unpredictable installation layer.

Moving forward, Figranium is strictly containerized. We have completely refactored, rebuilt, and verified the entire environment layout using Docker. By packaging the Express backend, the Vite/React UI components, and the exact required Chromium/Playwright execution binaries into an isolated sandbox, we ensure complete environment isolation.

Whether you are spinning it up locally on a workstation or self-hosting it on a remote cloud platform like Render, the execution layer is identical every single time. It completely slashes configuration friction and removes cross-compatibility bugs from the equation entirely.

---

Technical Overhauls & New Features in v0.13.0#

This milestone isn't just a structural pivot; it's a massive optimization pass. Over the last few days, we’ve executed a heavy codebase cleanup to strip out unused components, drop dead utility code, and ensure everything compiles smoothly within the new Docker container.

Beyond the cleanup, v0.13.0 addresses two major areas of feedback regarding how Figranium interfaces with target web environments:

1. Un-breaking the Legacy AI Selector Generation

Our core engine is anchored to explicit CSS selectors and robust Playwright syntax extensions (like exact text matching via :has-text(), visibility filters via :visible, and deep shadow-root piercing using the >> operator). Our legacy AI selector generation tool was architected to analyze structural element fragments and intelligently map out clean, human-readable selector strings.

In recent builds, this legacy AI pipeline broke completely, hitting a technical snag that caused it to fail silently and refuse to return candidates. We have gone back into the backend orchestration logic to repair this generation breakdown, ensuring that the legacy engine once again successfully returns valid selector targets without stalling or snapping.

2. The AI vs. Native Browser Tool Toggle

To preserve complete user control, we are introducing a prominent configuration toggle right inside the settings menul. Users can now choose exactly how they want to extract selectors:

• AI Selector Generation Mode: Best for rapid prototyping or dealing with highly complex, dynamic wrappers where the legacy LLM mapping schema can quickly output structural logic candidates.
• Native Browser Selection Tool: Best for absolute engineering precision, allowing power users to click directly on the live viewport to snap an exact, deterministic identifier string using our custom script inspector.

3. Tablet UI and Layout Responsiveness

As part of our commitment to maintaining a polished, aesthetics-focused interface, we spent time squashing interface bugs across varied display form factors. Most notably, we resolved a layout collision visible on tablet and iPad viewports. In previous builds, the dashboard header container lacked proper flex-shrink rules, causing the search bar to compress directly into the Export action button group when screen real estate got tight. The layout now utilizes responsive breakpoints and flexible wrapping, maintaining clean visual hierarchy across all viewports.

---

The Architecture Strategy Moving Forward#

An empty community Discord server or a quiet, low-traffic GitHub repository is entirely normal for an open-source project moving through the v0.x developmental stages. We have zero interest in running a loud, hyped-up marketing funnel, nor are we trying to pitch a half-baked AI prototype to a mass market for temporary internet points.

We are building a highly stable, open-source control plane designed strictly for developers and systems designers who require data pipelines that do not crash when a third-party website tweaks its layout.

With the codebase officially cleaned up, the legacy NPM baggage removed, and the entire platform securely containerized inside Docker, v0.13.0 establishes the rock-solid baseline required as we march toward a stable, production-ready v1 release later this year.

The update goes live tomorrow, June 29. Pull the latest Docker template from the repo, spin up the container, and put the new selector toggle through its paces.