Collections and entries
Editing an Astro content entry's frontmatter as fields, and the rule that keeps the rest of the file exactly as it was.
An Astro project with a src/content folder gets a Collections tab in the
project panel, listing each collection and the entries inside it.
Opening an entry
Click one and it opens two ways at once: as a panel of fields, and as an ordinary file in a coding pane.
The fields panel reads the entry’s frontmatter and gives you a control per key — a line of text as a text field, a list as a list you can add to and remove from, nested objects nested. The body of the markdown stays in the pane.
The two stay in step. Edit the file in the pane and the fields follow; save a field and the pane follows.
Saving
There is a Save button and Cmd/Ctrl+S. There is no autosave, whatever the manual-save preference says — that preference sets the coding panes’ rhythm, not this one.
Autosaving as you type was built and taken out again. It put a write every half second against a live file watcher and a coding pane that can hold the same entry, and the problems were all in the seams between those three writers.
What a save actually does
It replaces one line, or one run of list-item lines. Nothing else.
A field remembers the line it came from. Saving replaces the value on that line and writes the file back otherwise untouched — so key order, comments, the body, your quoting style, and anything the reader did not understand all stay exactly as they were, because nothing rebuilds them.
That is the whole safety argument for editing somebody’s content files at all.
It is held to a no-op test: load an entry, write every value back as itself, and the bytes must be identical. That has caught three real faults that would otherwise have reached a file — single quotes coming back as double, a list swallowing the blank line after it, and an entry written one line off.
What it will not do
Reorder blocks, add one, or remove one. Moving a run of lines shifts everything below it, and everything below it is where the other fields think they live.
The coding pane does that, and the fields panel re-reads afterwards.
Only entries
The fields panel edits collection entries. It does not edit .astro pages.
Not because the machinery could not be extended, but because editing page source needs two things FEWD does not have: a marker saying the developer intends it, and a proof that saving would keep everything. Until both exist, a page is edited as code.
Alongside a git-based CMS
Where a client is editing the same entries through a git-based CMS, you are both writing the same files in the same repository, and your changes meet in git rather than fighting over a document.
Pull before you start rather than after you have finished. Their edits are ordinary commits to content files — normal git hygiene, nothing special to these apps.