open edit - Moses Yebei

Problem Video editors often struggle to automate the entire post‑production workflow. Writing code to transcribe, subtitle, re‑frame, or generate motion graphics typically requires multiple tools, manual coordination, and a GUI. The goal of Open‑Edit is to provide a single, agent‑driven command line that receives a natural‑language instruction and returns a finished MP4.

What This Does Open‑Edit is a Node 20+ library written in TypeScript.

cli/src/cli.ts is the public entry point; it parses command‑line arguments and dispatches to command modules under cli/src/commands/*.ts.
The transcribe command (cli/src/commands/transcribe.ts) calls cli/src/veed/transcript-mapper.ts to route speech‑to‑text through either the VEED API or local WhisperX.
generate (cli/src/commands/generate.ts) builds a recipe from a prompt, handing it to the renderer that is downloaded into the user’s app‑data folder.
preview (cli/src/preview/page/app.js) spins a lightweight Express server (see cli/src/preview/page/index.html) to show a live preview.
All state is written to a runs/ directory; the final MP4 is emitted there.

How It Is Wired

Entry point – cli/src/cli.ts → cli/src/args.ts → cli/src/config.ts.
Command dispatcher – cli/src/cli.ts calls the relevant cli/src/commands/*.ts.
External calls –
cli/src/veed/api.ts issues HTTPS requests to VEED’s REST surface.
cli/src/veed/login-page.ts and cli/src/veed/oauth.ts manage OAuth tokens, persisting them in token-store.ts.
cli/src/veed/transcript-mapper.ts routes to either veed/api.ts or local WhisperX via cli/src/commands/whisper.ts.
Renderer – cli/src/engine-release.ts downloads the binary to ~/.local/share/veed/openedit/renderer.
Preview – cli/src/preview/state.ts holds the preview session state; cli/src/preview/events.ts and cli/src/preview/media.ts serve media to the browser.

The graph is a linear chain with a few side‑channels to external services. No cycles exist; the only hub is cli/src/cli.ts, which has a 1‑to‑many fan‑out. Changing a command module requires touching only that file and its tests.

How To Use It

Setup ``sh git clone https://github.com/moses-y/open-edit cd open-edit pnpm install ` Node 20+ and ffmpeg` are required; the first run will prompt for missing tools.

Configuration VEED credentials are stored in ~/.veed/token.json. Optional environment variables: OPENEDIT_TRANSCRIPTION=whisper or veed.

Running ``sh pnpm run cli -- transcribe --input video.mp4 --output transcript.json ` The CLI accepts many sub‑commands; --help` lists them.

Real‑World Use A marketing team can run:

pnpm run cli -- generate --prompt "Create a 20‑sec title sequence in brand colors" --output title.mp4

The command uses cli/src/commands/generate.ts → cli/src/veed/fabric.ts to submit a job to VEED, then streams the MP4 back to runs/.

Code Health & Issues

435 source files, 251 TypeScript.
85 test files (cli/tests/*.test.ts), run by GitHub Actions (.github/workflows/merge-gate.yml).
No lint or type‑error failures reported in CI.
License: Apache‑2.0, no hidden secrets.

No measured issues were found. The repository is well‑structured, with a clear separation between command dispatch, external API interaction, and rendering.

Bottom Line Open‑Edit delivers a practical, agent‑driven editing pipeline that eliminates the need for a UI. Its TypeScript foundation, extensive test suite, and clear command‑line interface make it suitable for developers who want to integrate automated video production into CI/CD or chatbot workflows. The main limitation is the dependency on VEED’s paid tier for high‑volume usage, but the open‑source core remains free to extend.

What the analyser found

Deployment readiness

6/7

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

Composition

435 files

TypeScript251
Markdown59
JSON38
CSS4
HTML3
Shell2

ReactExpress

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["cli 185 modules"] g1["refs 50 modules"] g2["pipeline 11 modules"] g3["preview 6 modules"] g4["prep 4 modules"] g1 -->|89| g2 g4 -->|1| g2

Module dependencies

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

graph LR n0_cli_src_config["config"] n1_pipeline_recipes_lib["lib"] n2_cli_src_args["args"] n3_e_scripts_synth_word_timings["synth-word-timings"] n4_cli_src_veed_api["api"] n5_ipeline_recipes_template_lib["template-lib"] n6_cli_src_veed_fabric["fabric"] n7_cli_src_probe["probe"] n8_cli_src_wcag_wcag_choice["wcag-choice"] n9_cli_src_resolve_video["resolve-video"] n7_cli_src_probe --> n0_cli_src_config n6_cli_src_veed_fabric --> n4_cli_src_veed_api n6_cli_src_veed_fabric --> n2_cli_src_args n1_pipeline_recipes_lib --> n3_e_scripts_synth_word_timings n5_ipeline_recipes_template_lib --> n1_pipeline_recipes_lib n5_ipeline_recipes_template_lib --> n3_e_scripts_synth_word_timings

Dependencies

1 of 5 declared dependencies are a major version behind. Resolved 5 of 5 against the registry.

Package	Declared	Latest	Behind
`@types/node`	^22.0.0	26.2.0	4 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

medium3

low2

Make CI invoke the test suite it hashigh83 occurrences

.github/workflows

83 test files, no test command in any workflow

A green check that never executed an assertion is worse than no check, because reviewers trust it.

Fix: Add a test step to the existing workflow rather than a new workflow.

Enable Dependabot or Renovatemedium

1 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.

Move large binaries to Git LFS or out of the repositorymedium

docs/examples/openedit-launch.webp

1 blobs over 5MB: openedit-launch.webp 13.5MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Set timeout-minutes on the workflow jobslow

.github/workflows/merge-gate.yml

1 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.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

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.