Motivation: Why “Disk Wins”?

The Problem in Aura grandma-mode

In Aura Oma Mode (see line 67), Aura operates largely autonomously: the user speaks commands, and Aura writes to files on its own — configurations, scripts, log entries, generated text.

The following scenario happens constantly:

  1. The user has a file open in the editor (e.g. a rule file or a script).

  2. They forget the editor is still active and speak an Aura command.

  3. Aura changes the file on disk.

  4. The editor detects the external change — and asks.

This prompt is a showstopper in Oma Mode:

  • The user may be sitting on the couch, using voice input, and cannot see or reach the dialog.

  • Or they accidentally pressed a key in the editor, the buffer is now “modified”, and every external change blocks with a “Reload? / Keep local?” dialog.

  • The result: Aura keeps working, but the editor shows a stale version. The user thinks they are looking at the current file, but edits based on an old state — chaos is guaranteed.

What We Need

Editor behavior that always prioritizes the disk. When Aura (or any other tool) changes the file, the editor must immediately and without any prompt show the new content. Unsaved input in the editor may be silently discarded — because in Oma Mode, Aura is the source of truth, not the human keyboard input.

Why Standard Editors Fail

Almost all common editors (Kate, VS Code, Sublime Text, Notepad++, Emacs, Vim, CudaText out-of-the-box) have a protection mechanism: as soon as the buffer contains unsaved changes, they always ask when an external change occurs. This is a feature for normal developer work — but a bug for Aura Oma Mode.

This plugin closes exactly that gap for CudaText.

Target Audience

  • Users of Aura Oma Mode who view files in an editor in parallel.

  • Automation scenarios where a process writes files and an editor serves only as a live viewer.

  • Anyone for whom “disk always wins” is the desired behavior.