Feature: autosave + external file watch for live reload

[RobinDev]

Context

Currently the editor only persists changes on explicit Ctrl+S / Save (app/src/state/editor/io.ts saveDocument, dispatched from MenuBar.tsx and TitleBar.tsx). The .audapolis file is also read once at open time into the Redux store — there is no file watcher, so external modifications to the document (e.g. by a script editing document.json inside the zip) are never reflected in the UI until the user closes and reopens the file.

Proposal

Two related, opt-in behaviors:

1. Autosave — debounced save (e.g. 2–5s after last edit) when the document is dirty and has a known path. Configurable in settings; off by default to preserve current behavior.
2. External-change watch + auto-reload — on open, watch the .audapolis path with chokidar. On external change, if the in-memory document has no unsaved edits, transparently reload it; if there are unsaved edits, prompt the user (keep mine / load disk / diff).

Use case

Enables scripted/background pipelines (batch transcript corrections, programmatic edits, sync with external tools) that update the file on disk while the editor stays open — turning audapolis into a live view of an externally-managed document.

Offer

Happy to implement this as a PR if the maintainers are interested. Would appreciate guidance on:

• Desired default (off / on with conservative debounce).
• Conflict UX for the "unsaved edits + external change" case.
• Whether autosave should also write through to the zip on every save, or stage to a side file first to avoid corruption on crash.

[pajowu]

Probably won't happen with the current file format. Especially with larger media files, saving can take some time. Interrupting the save and/or start another save at the same time can easily lead to file corruption.

An open audapolis document is decidedly not live-shared (for this see our transcribee project). Unless I see an actual human with a real-world use-case for this, I don't think we will change that.

Diffing two audapolis documents and displaying a useful conflict resolution UI is also a big project ux-wise.

I'll close this for now, happy to reopen if someone shows me a good reason to implement this (or other maintainers deem it a good idea to reopen it).

[RobinDev]

Thanx for quick reply.

I see an actual human with a real-world use-case

My first use case :

• remove fill words & cie via open code in a parallel terminal when i am doing the editing job via the audapolis UI