When choosing a diary text editor, do not decide on the autosave label alone. Autosave may preserve a change, yet it cannot correct a writer who leaves yesterday’s file open and types today’s entry into the wrong path. A safer adoption decision evaluates the date rule, a today-only update, neighboring-day controls, and a month-folder recovery copy. Only rows with evidence receive a Pass.
This article separates Rune Studio’s public specification at Stage 3 from the existing manual file operation at Stage 4. The on-screen autosave firing, unsaved indicator, and encoding warning were not observed. The measured manual result is therefore not presented as an autosave result. The central question is whether the complete diary-protection routine is acceptable without depending on autosave alone.
Make the date rule authoritative
For September 2026, define the authoritative set as 30 files from diary/2026/09/2026-09-01.md through 2026-09-30.md. Zero-padded months and days keep lexical order aligned with calendar order. If the naming rule is ambiguous, a recovered paragraph still may not prove which day owns it.
Use DIARY-614 as a unique end marker in the current-day specimen. Name a related image assets/2026-09-30-river.jpg and give it meaningful alternative text such as “A walker beside the river at dusk.” A generic name such as image1.jpg does not identify the memory when the image is inspected by itself six months later.
Collaborative journals and cloud synchronization are outside this article’s scope. The date path identifies the local record, the current-day file is the editing source, and the copied month folder is the recovery unit.
Decide with one pass, hold, and fail table
Evaluate a candidate from top to bottom. Hold means that the required event has not been observed. Fail means that observed data contradict the acceptance condition.
| Evaluation axis | Pass condition | Evidence available now | Current decision | Example failure |
|---|---|---|---|---|
| Date rule | The September 2026 source has 30 fixed names from 09-01 through 09-30 with no gap or duplicate |
30 date-based files were prepared at Stage 4 | Pass | Missing, duplicate, or wrong-month file |
| Today-only update | Three paragraphs and the marker exist only in today’s file, and only today’s mtime advances | Manual write returned one DIARY-614-30-NEW and an mtime change |
Pass for the manual operation | Another date changes or today’s text is absent |
| Neighboring-day control | September 29, September 30, and October 1 are compared; the neighboring content and mtimes remain unchanged | The changed-file list contained only today, and the prior-day marker remained | Pass within existing Stage 4 evidence | Previous or next day changes |
| Monthly duplication | diary/2026/09/ is copied to archive/2026-09/; all 30 entries, three representative notes, and required assets read back |
Only one current-day file was copied | Hold | Wrong count, content mismatch, or broken asset reference |
| Autosave firing | A change made without manual save reads back from the same path after the required condition | Stage 3 documentation only | Hold | Treating an unobserved trigger as a pass |
The autosave row may remain on Hold while a conditional workflow retains manual save and verified recovery copies. Conversely, a future Pass for autosave cannot rescue a workflow that fails the date rule or monthly recovery row.
Stage 3: the public product specification
Rune Studio’s current Mac documentation states that it autosaves 1.2 seconds after an edit. It also states that autosave pauses while the selected encoding cannot represent a character. The public specification also describes a file tree for managing local manuscript, reference, and image files.
These are documented boundaries, not a record that the September diary specimen fired autosave after 1.2 seconds. The encoding warning, pause, correction, and resume sequence was not observed either. The accurate wording is “documented at Stage 3; interface firing not observed at Stage 4.” No cloud-sync or collaboration capability is implied.
Stage 4: what the existing manual operation established
The dedicated temporary workspace contained 30 fixed-name files for September 2026. Only the current-day file received a manual write. Its mtime changed, and readback returned three paragraphs with exactly one DIARY-614-30-NEW marker. The changed-file list contained only that date, while the prior-day control retained its existing marker.
The same marker was read after the tab and workspace were closed and reopened. The current-day file was also copied to a separate recovery folder, and the marker read back from that one copied file. This evidence supports the manual today-only write, mtime change, neighboring-date control, reopen, and one-file recovery copy.
It does not support the autosave trigger, 1.2-second firing, or an on-screen unsaved state. It also does not establish duplication of the entire month folder, a relative image or reference link, or asset resolution after copying. Those rows remain on Hold.
Control the current day with three dates
A today-only decision uses the previous day, current day, and next day together. If September 30, 2026 is the current day, record the full paths, content identifiers, and mtimes for September 29, September 30, and October 1 before and after the controlled change. Reading today’s paragraph alone cannot exclude a wrong-month or same-name copy.
If autosave is evaluated later, keep this three-date control as its own row. Use disposable duplicates, change only today’s file without manual save, and judge the autosave row only after its result exists. The documented 1.2-second value by itself is not a Pass. No interface indicator or firing time should be inferred before it is observed.
Read the 30-file month copy and its assets
Create the month-end return point by copying diary/2026/09/ to archive/2026-09/ without moving the source. Count all 30 files, then open three representatives: the first day, a middle day, and the final day. A total of 30 can still hide an empty file or a note from another month.
In the copied 2026-09-30.md, check DIARY-614 and the relative image reference. If an image sits outside the month folder, the copied note may no longer reach the same relative path. Copy a month specimen containing one image and open assets/2026-09-30-river.jpg from the archived note before marking the asset row as Pass.
The existing Stage 4 evidence covers a copy of one current-day file, not all 30 files and not an image reference. Keep the copied month read-only after verification so that the next month’s writing does not begin inside the recovery source.
Adoption conclusion without autosave dependence
The adoption decision starts with the date rule, today-only update, neighboring-day control, and monthly duplication. Rune Studio’s autosave and encoding boundary are relevant Stage 3 specifications. The existing Stage 4 evidence reaches only the manual write, mtime, three paragraphs, one DIARY-614-30-NEW marker, neighboring control, reopen, and one current-day recovery copy.
The present result is therefore: Pass for the date rule, manual today-only update, and the existing neighboring-day control; Hold for monthly duplication, asset readback, and autosave firing. Keep manual save and month-end recovery in the workflow while those rows remain pending. Current Mac product information is available on the Rune Studio website, but adoption should rest on rows supported by evidence rather than on the feature name alone.