openvisual - Moses Yebei

The Problem

Teams want quick diagram drafts from plain-language descriptions, but most AI diagram tools send text to a cloud service, require API keys, or produce static images you cannot edit. OpenVisual addresses that by running a local Ollama model and rendering editable diagrams on your own machine, with no network calls beyond http://127.0.0.1:11434.

What This Does

OpenVisual is a Tauri 2 desktop app that turns text prompts into editable Excalidraw diagrams. The flow: you paste text, click generate, a local Ollama model returns a structured description, and a deterministic layout engine in src/diagrams/layouts/ computes coordinates, colors, and strokes. The result opens in an editable canvas you can rearrange, restyle, save, and export.

The app supports six diagram types (flowchart, timeline, hierarchy, comparison, cycle, hub-and-spoke) and three detail levels. It also offers local transformations—regenerate, simplify, add detail, change type—all driven by the same AI pipeline in src/ai/.

How It Is Wired

Execution starts at src/main.tsx, which mounts src/App.tsx. The React frontend calls src/ai/client.ts, which sends prompts to the Rust backend via Tauri commands defined in src-tauri/src/commands/ollama.rs. That backend makes the only outbound network call—a POST to http://127.0.0.1:11434 (a compile-time constant). The response returns to src/ai/pipeline.ts, which parses and validates it via src/ai/parser.ts, then passes the structured diagram to src/diagrams/convertToExcalidraw.ts for rendering.

The layout engine in src/diagrams/layouts/ is the core: flowchart.ts, timeline.ts, hierarchy.ts, comparison.ts, cycle.ts, and hubSpoke.ts each compute node positions deterministically. src/diagrams/layout.ts routes to the correct layout based on the diagram type. The src/store/appStore.ts manages application state, and src/storage/ handles persistence via IndexedDB (db.ts) and project management (projects.ts).

The widest blast radius sits in src/ai/pipeline.ts—every generation, regeneration, and transformation flows through it. Changing the prompt format or parsing logic there affects all six diagram types. The src/diagrams/layouts/ directory is a close second; each layout file is independent, but layout.ts is the routing hub that ties them together.

How To Use It

From the README, the setup is:

brew install ollama && ollama serve
ollama pull qwen3:4b
npm install && npm run tauri dev

Configuration is minimal—no environment variables or API keys. The only external dependency is a running Ollama server with a model pulled. The app checks for Ollama on first run via the onboarding dialog in src/components/onboarding/OnboardingDialog.tsx.

Real-World Use

A product manager drafts a feature flow in plain English: "New user signs up, verifies email, sets up profile, then sees the dashboard." OpenVisual generates a flowchart with those four nodes, which the PM drags into a better order, exports as PNG, and drops into a spec doc. The same prompt always produces the same layout—deterministic, so it is safe for version control.

Code Health & Issues

Med - No screenshots in docs/ despite the README requesting four specific captures; the demo GIF placeholder remains. Documentation is incomplete for a user-facing product.
Med - The src-tauri/capabilities/default.json and src-tauri/tauri.conf.json are present, but the security posture beyond the compile-time Ollama URL constant is not documented in a way that an auditor could verify without reading Rust source.
Low - scripts/sync-excalidraw-assets.mjs and the Vite plugin for local fonts are custom build tooling; they work but add maintenance surface area.

Tests are present (13 files), CI exists in .github/workflows/ci.yml, and a release workflow is configured. No structural red flags were detected.

The Bottom Line

OpenVisual is a well-architected local-first tool that solves a real pain point—editable AI diagrams without cloud dependencies. The deterministic layout engine and strict privacy boundary are its strongest assets. It is ready for a developer audience that already runs Ollama, but the missing screenshots and demo assets will hurt adoption with non-technical users.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

127 files

TypeScript53
TSX18
Markdown10
JSON7
Rust7
YAML5

React

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["src<br/>68 modules"] g1["(root)<br/>3 modules"] g2["scripts<br/>2 modules"] g1 -->|1| g2

Module dependencies

The 10 most depended-upon modules of 73, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_ugin_local_excalidraw_assets["vite-plugin-local-excali"] n1_vite_config["vite.config"] n2_eslint_config["eslint.config"] n3_ripts_sync_excalidraw_assets["sync-excalidraw-assets"] n4_src_App["App"] n5_src_ai_client["client"] n6_src_ai_parser_test["parser.test"] n7_src_ai_parser["parser"] n8_src_ai_pipeline_test["pipeline.test"] n9_src_ai_pipeline["pipeline"] n1_vite_config --> n0_ugin_local_excalidraw_assets

Dependencies

9 of 40 declared dependencies are a major version behind. Resolved 31 of 40 against the registry.

Package	Declared	Latest	Behind
`jsdom`	^28.0.2	30.0.1	2 major
`typescript`	~5.9.3	7.0.2	2 major
`@eslint/js`	^9.39.5	10.0.1	1 major
`@testing-library/jest-dom`	^6.9.1	7.0.1	1 major
`@vitejs/plugin-react`	^5.1.0	6.0.5	1 major
`eslint`	^9.39.0	10.8.1	1 major
`globals`	^16.5.0	17.11.0	1 major
`vite`	^7.1.12	8.2.1	1 major

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high1

medium5

low1

Pin third-party GitHub Actions to a commit SHAhigh3 occurrences

.github/workflows

dtolnay/rust-toolchain@stable, swatinem/rust-cache@v2, tauri-apps/tauri-action@v0

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/ci.yml

1 workflow(s) declare no permissions

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

2 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/ci.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Review the install lifecycle script and disable scripts in CImedium

package.json

postinstall

Install scripts are the execution vector for every npm compromise from event-stream onward, and a postinstall that fetches a binary makes the build depend on a URL nobody reviews.

Fix: Move the work into an explicit build step, or set ignore-scripts in CI and run it by name.

Set timeout-minutes on the workflow jobslow2 occurrences

.github/workflows/ci.yml

2 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.