How Far the Rewrite Has Actually Traveled
OpenCut is best understood not as one finished application but as a project carrying an earlier editor into a new architectural phase. The question at the end of this series is therefore precise: how much of the proposed shared foundation is demonstrated by the current repository, how much is documented history, and how much remains a promise? Answering it gives readers a practical judgment about OpenCut's present readiness without confusing ambition with implementation.
One name, different evidence
The first fact to preserve is the relationship between OpenCut Classic and the rewrite. OpenCut's README describes the project as a free, open-source video editor for web, desktop, and mobile, then says that it is being rewritten from the ground up. It identifies the earlier version as OpenCut Classic, says the existing public site still runs that version, and points to a separate destination for the rewrite until it is ready to take over. The project itself supplies the boundary; it is not an interpretation imposed from outside.
That boundary changes what can responsibly be carried from the former editor into an account of OpenCut today. The release history is valuable evidence of the product's lineage and of the engineering problems its earlier team confronted. It records direct manipulation in the preview, organized properties controls, timeline selection and trimming, keyframes, effects, masks, audio and captions, export fixes, and increasingly formal time and track mechanisms. Those records show what OpenCut has previously built and what kinds of behavior the rewrite may need to recover or rethink.
They do not show that the rewrite currently has those features. In the current web tree, the home route is a placeholder and the editor route says “Coming soon.” The current desktop documentation says that the application is very early and currently only opens a window. The desktop shell does create Browser, Preview, Inspector, and Timeline panels, but their visible bodies display only those labels. The API exposes status, health, and echo behavior rather than editing operations. This is direct present-state evidence, and it outweighs any temptation to infer feature parity from the release notes.
The distinction is not a technicality about dates. It separates two kinds of continuity. Product continuity means that the rewrite belongs to the same OpenCut project and is responding to the needs revealed by the former editor. Implementation continuity would mean that the current code still contains, or has already ported, the former editor's scene model, renderer, storage, and commands. The repository supports the first statement. At this revision it does not support the second.
That is why the earlier feature history remains relevant without becoming a catalog. A properties panel that combines gestures with exact values illustrates a coordination problem. A keyframe graph and a timeline lane illustrate the need for a common time model. A ripple-editing algorithm illustrates the need to separate a user's command from the changes it causes elsewhere. A GPU fallback notice illustrates an operating condition that a web editor must surface honestly. Each historical example is useful because it reveals a contract the rewrite would have to honor, not because it proves the contract has already been implemented again.
OpenCut's present repository is consequently a reset with memory. It retains the product name, the conceptual four-panel editing shell, the release history, and a direction centered on a Rust core. It also makes a clean break visible: the current root Rust workspace lists the desktop application while leaving the shared crate glob commented out, and the current web and API surfaces are still scaffolds. Reading only the old capabilities would mistake memory for present state.