IVDNI — Building a Local-First Design Workspace

IVDNI is a browser-based, local-first visual design workspace built for direct canvas manipulation: vector paths, boolean compound operations, typography, motion prototyping and component libraries, documented at Early Access 0.2. None of it requires a continuous server connection.

The architecture departs from the conventional cloud-first pattern on purpose. The browser client is the authoritative state engine; optional cloud backup and synchronization remain available, subject to account storage limits. The network is a mirror, never the master copy.

This page is an engineering case study, not a product landing page. Where a statement describes behaviour, it rests on the project’s evidence ledger — merged pull requests, recorded commits and architecture documentation — cited inline as Evidence IVDNI-E*** throughout.

Contemporary design tools frequently make the network a hard dependency: strokes, layer creation and undo steps are mediated by remote services. When latency spikes or the connection drops, the creator’s flow breaks.

The engineering problem in IVDNI was to build a desktop-grade workspace inside the browser sandbox: responsive direct manipulation, deterministic persistence of complex documents, and structured recovery after unexpected browser termination — without megabytes of virtual-DOM framework overhead. Statements about market demand or adoption are out of scope for this case study; none are made.

Role: Founder & Independent Developer. I directed architecture decisions, defined key engineering invariants, and reviewed AI-assisted implementations against explicit acceptance criteria.

Rather than claiming solo hand-authorship of all implementation code in isolation, the development process combined solo product vision and architectural leadership with disciplined, test-gated AI-assisted development loops. Every architectural boundary, mutation invariant and data contract was personally defined, verified against those criteria, and integrated.

The client application — the Studio — is written in framework-free, vanilla JavaScript to maximize execution throughput and eliminate framework scheduling jitter. It initializes through an ordered bootstrap sequence with explicit lifecycle phases.

At its core sits a single mutation boundary: EditorActions. All canvas mutations — pointer gestures, keyboard shortcuts, intent reasoning — are linearized through it into discrete transaction units. CommandHistory uses transaction-aware commands and before/after state snapshots to support undo and redo. Heavy original image bytes live in a local AssetStore on the Origin Private File System, with IndexedDB as the fallback.

Optional server-side services run on Cloudflare Workers for authentication, cloud backup, and gated intent features, with D1 holding account identity and project metadata and R2 holding private project bytes. The split is deliberate: everything a creator draws keeps working when the right side of the diagram is unreachable.

1 · Local-first sovereignty. Browser storage is the primary source of truth. Editing never waits on a remote round-trip; the optional cloud mirror is consented, asynchronous and bounded by account storage limits.

2 · Linearized mutation gate. Nothing writes to the document tree directly. Every state transition passes through EditorActions, where invariant validation, crash logging and post-commit notification isolation run before anything commits.

3 · Guarded intent execution. AI-driven or script-generated modifications are prohibited from writing to the canvas directly. A change must pass through plan → simulate → visual preview → explicit user confirmation before it reaches the same authoritative boundary as a hand gesture.

4 · Deduplicated local assets. Images are stored once — keyed by content — in the Origin Private File System, decoupled from the lightweight JSON document tree so that binary weight never saturates editing memory.

The hardest stability problem appeared where canvas hierarchies meet rapid undo: grouped layers, boolean masks and text elements could drift into subtle desynchronization when edits were reversed in quick succession. The fix was structural, not patchwork — EditorActions transactions were linearized and post-commit notification isolation was introduced, decoupling document mutation from reactive panel updates.

Recovery was the second front. Stale browser tabs and unexpected process termination are normal events on the web, so the Studio persists document recovery checkpoints and treats their restoration as a first-class path rather than an exception handler.

Quality assurance combines unit suites, DOM integration harnesses and continuous regression runs. Pull request #191 merged a risk-scoped Editor CI workflow that partitions regression coverage across a three-shard matrix. A GitHub Actions run on PR #194’s head completed successfully on the exact commit it tested.

A golden-project regression harness guards real content behaviour — one recorded pass fixed CJK line wrapping and a truncated JPEG import in the same change. In keeping with honest disclosure, automated passes here are regression baselines, not a blanket guarantee that every future change is green.

The core systems named in this case study are merged and demonstrated on the recorded main branch. The verified deliverables: the EditorActions mutation layer (PR #142), the Studio panel and docking system (PR #156), the sitewide design-token foundation (commits 7ab6bca5, 6aa5d6b7), Collaboration 1.0 with canvas comments, object locks and ownership transfer (2026-10-30 series), and the Living Design Systems foundation of semantic graph, token linkage and agent runtime (PRs #173–#178).

One limitation is disclosed rather than hidden: a cloud-restore regression is under active investigation in issue #193 and PR #194. Tracking it in public is part of what evidence-based engineering means here.

Cloud restore. A diagnostic regression is under active investigation in issue #193 and PR #194; cloud-restore behaviour should not be assumed flawless until that closes.

Living Design Systems scope. Cross-document token batches, responsive artboard linkage and the trusted agent host remain in open, unmerged pull requests (#184–#187). They are planned work, not released features.

Design-to-code is bounded. The UI-to-Code bridge targets designated HTML and React component outputs — not arbitrary full-stack application generation.

No commercial claims. Adoption, paying-customer volume and revenue have zero evidence in the engineering record and are omitted entirely.

History is sampled. Commit and pull-request references come from a curated milestone sample, not an exhaustive repository audit.

Lesson 1 — Truthful persistence

Local-first editing requires a clear distinction between changes in memory, successful storage writes, and verified durability. Persisting in the browser sandbox — via the Origin Private File System with IndexedDB fallback — demands that heavy binary blobs, such as images, stay decoupled from the JSON state trees. Blurring that line is how editing memory saturates.

Lesson 2 — Transaction integrity

Undo/redo correctness depends on consistent state transitions, guarded mutations, and reliable failure handling. CommandHistory uses transaction-aware commands and before/after state snapshots to support undo and redo; history management cannot operate as an uncoordinated secondary layer bolted on after the fact.

Lesson 3 — Trusted AI execution

AI-generated editing plans must pass through validation, preview, explicit confirmation, and the existing authoritative mutation boundary. Permitting autonomous scripts or language models to write directly to canvas state corrupts document invariants. A disciplined plan–simulate–preview–apply boundary keeps creative control in human hands.

Active work is concluding the cloud-restore regression investigation (issue #193, PR #194). Beyond it, four Living Design Systems capabilities are in open pull requests. They are listed here as planned development: none of them is a released capability today.

About IVDNI. IVDNI is an independent product in early access. This page documents its engineering; a public product link will be added here once the canonical public URL is available.

Return to Galok work ↗