The workflow
You mentioned in #89 and #91 that having AI write project files directly has worked well for you. That is exactly how I use Compositor: an agent (via compositor-mcp, a small Node server over the documented .comp format) edits the package on disk while the document is open in the app, and I keep working on it by hand.
What happens today
Compositor does not notice when the package it has open changes on disk. After the agent adds a layer, the only way to see it is to close the tab and reopen the file (I ended up scripting ⌘W + reopen). docs/project-format.md and a quick grep confirm there is no file presenter or watcher today, so this is expected behaviour, not a bug.
Proposal
When the open document's package changes on disk and the document has no unsaved edits, reload it in place: same tab, same viewport and zoom, layer selection kept when the layer still exists, undo history cleared (it is session-only already, per the format doc).
When the document does have unsaved edits, don't touch it; show the standard non-blocking "The file has been modified by another application" sheet with Revert / Keep Mine, like TextEdit and Xcode do.
Implementation sketch, kept small:
- adopt
NSFilePresenter on the document (or NSDocument's built-in presentedItemDidChange), which is what AppKit expects for package documents and needs no polling;
- coalesce notifications for ~200 ms, since a package save touches
manifest.json plus several PNGs;
- go through the existing
ProjectStore.load path so all validation rules apply, and ignore our own coordinated saves.
Why it fits
It makes the "AI writes the file, I finish in the app" loop you described work without an in-app MCP, a plugin API or any new surface: any tool that writes a valid .comp benefits, not just agents (Git checkouts, syncing folders, a script that batch-updates layers).
I'm happy to send a PR along these lines if the behaviour sounds right to you; wanted to check the shape first since you've been clear about keeping the app's scope tight.
The workflow
You mentioned in #89 and #91 that having AI write project files directly has worked well for you. That is exactly how I use Compositor: an agent (via compositor-mcp, a small Node server over the documented
.compformat) edits the package on disk while the document is open in the app, and I keep working on it by hand.What happens today
Compositor does not notice when the package it has open changes on disk. After the agent adds a layer, the only way to see it is to close the tab and reopen the file (I ended up scripting ⌘W + reopen).
docs/project-format.mdand a quick grep confirm there is no file presenter or watcher today, so this is expected behaviour, not a bug.Proposal
When the open document's package changes on disk and the document has no unsaved edits, reload it in place: same tab, same viewport and zoom, layer selection kept when the layer still exists, undo history cleared (it is session-only already, per the format doc).
When the document does have unsaved edits, don't touch it; show the standard non-blocking "The file has been modified by another application" sheet with Revert / Keep Mine, like TextEdit and Xcode do.
Implementation sketch, kept small:
NSFilePresenteron the document (orNSDocument's built-inpresentedItemDidChange), which is what AppKit expects for package documents and needs no polling;manifest.jsonplus several PNGs;ProjectStore.loadpath so all validation rules apply, and ignore our own coordinated saves.Why it fits
It makes the "AI writes the file, I finish in the app" loop you described work without an in-app MCP, a plugin API or any new surface: any tool that writes a valid
.compbenefits, not just agents (Git checkouts, syncing folders, a script that batch-updates layers).I'm happy to send a PR along these lines if the behaviour sounds right to you; wanted to check the shape first since you've been clear about keeping the app's scope tight.