Autosave can help protect a writing draft, but it should not be the only acceptance condition. A safer editor evaluation begins with the authoritative file path, encoding, modification time, and a unique end marker. It then asks whether a separately named recovery version can be read back. If the actual autosave trigger has not been observed, that row stays pending instead of being inferred from documentation.
The adoption decision is therefore about the whole protection routine, not a verdict on the autosave label alone. A candidate can remain usable with manual save and milestone copies while an interface-dependent row is on hold, but it cannot receive credit for an event that was never observed.
This distinction matters because “the product documents autosave” and “this manuscript was autosaved in this test” are different claims. The first is a Stage 3 product specification. The second would require an observed Stage 4 operation. The evaluation below keeps those evidence levels separate and uses manual save plus recovery copies while the interface-dependent event remains unverified.
Fix the authoritative path before evaluating protection
Use chapters/01.md, chapters/02.md, and chapters/03.md as the live manuscript files. Reserve a dated path such as milestones/2026-09-01/01.md for a separately named recovery version. The live file is the writing source; the milestone is a readback source, not a second place to continue drafting.
For every candidate editor, record the full path, encoding, line-ending policy, starting modification time, expected character count, and one unique marker. SAVE-611 can label the test, but the decisive specimen marker is SAVE-611-C1-NEW. A marker is useful only when its exact count is checked, because an older copy could contain a similar phrase.
Make the adoption decision with a pass, hold, and fail table
Do not reduce draft protection to one yes-or-no autosave claim. Judge each control separately.
| Control | Acceptance condition | Evidence available now | Decision | Safe action while pending |
|---|---|---|---|---|
| Authoritative file | Full path resolves to chapters/01.md |
Three fixed-name chapter files were prepared | Pass | Record the path before editing |
| Manual readback | Expected count, marker, content, and later mtime agree after reopen | 1,200 characters and one SAVE-611-C1-NEW were read back |
Pass | Keep manual save in the workflow |
| Encoding | The intended encoding is recorded and the file reads back without replacement characters | Encoding is part of the acceptance procedure; no warning event was observed | Hold | Use the approved encoding and stop on warnings |
| Autosave firing | An edit made without manual save survives after the documented delay and reopen | Product documentation only; no firing event was observed | Hold | Do not remove manual save |
| Separately named version | A dated recovery copy opens from its recorded path with matching content | Recovery naming is defined, but this article-specific copy was not measured | Hold | Create and verify a copy at milestones |
A failure means observed data contradict the expected path, count, marker, encoding, or timestamp. A hold means the required event was not observed. Neither should be converted into a pass merely because the feature is expected to work.
Stage 3: what the public specification says
Rune Studio’s current Mac documentation states that edits are saved after 1.2 seconds. It also states that autosave pauses while the selected encoding cannot represent a character and that the app warns about this condition.
Those statements define the expected trigger and its encoding boundary. They do not prove that an autosave event fired for chapters/01.md during the recorded operation. The accurate conclusion is therefore “documented at Stage 3, not observed at Stage 4.” This wording also avoids promising an unconditional save when an encoding problem is present.
Stage 4: what the manual file operation established
A dedicated temporary workspace contained three fixed-name chapters of 1,200 characters each. A manual write to chapters/01.md changed that file’s modification time. Readback returned 1,200 characters and exactly one SAVE-611-C1-NEW marker. After the tab and workspace were closed and reopened, the character count, marker, and content still matched.
This is useful evidence for file identity and recovery discipline. It shows that the intended path accepted a controlled manual write and that the result could be read again after reopen. It does not show that the on-screen autosave timer fired, that an unsaved indicator appeared, or that an encoding warning paused and resumed saving.
Evaluate candidates without depending on autosave alone
Start with a duplicate, not the only manuscript. Record its full path and baseline mtime. Confirm the intended encoding, make a controlled manual change, save it, and reopen the exact same path. Compare the expected count, the unique marker, the modification time, and the content. Then create a separately named milestone version and read that copy from its own path.
These checks answer practical questions even when autosave remains pending: Did the writer modify the correct source? Did the intended encoding preserve the text? Did the timestamp advance? Did the exact marker survive? Is there a version with a different name and role to return to? An editor candidate passes the current evaluation only on the rows supported by those results.
If you later choose to test autosave in the installed interface, add it as a separate row. Use a disposable duplicate on the same storage location, make an edit without manual save, wait beyond the documented interval, and compare the file after reopen. Until that event is actually observed, keep its decision as Hold. The same rule applies to the documented encoding pause: do not claim a warning or resume sequence that was not seen.
Make the recovery version a different role
Autosave preserves the latest accepted state; it is not a record of every editorial decision. A milestone copy should therefore have a dated name and a clear purpose, such as “before structural rewrite,” “chapter complete,” or “delivery candidate.” Do not edit the milestone as if it were the live chapter.
After creating a milestone, verify one representative file immediately. Compare its count and marker with the live source, record the copy path, and keep the result with the evaluation table. If the copy is missing or differs, the recovery row fails even when the live file is healthy.
For the current evidence set, the defensible outcome is narrow and useful: authoritative-path control and manual readback pass; autosave firing, the encoding warning sequence, and the article-specific milestone copy remain on hold. Rune Studio’s documented Mac behavior can be reviewed on the Rune Studio website, while adoption should continue to rest on the path, encoding, mtime, marker, and separately named version that were actually checked.
The practical protection policy is simple: keep manual save and dated recovery copies until every interface-dependent row has its own observation. That protects the draft without turning an unobserved autosave event into a claim of success.