An “autosave included” label is not enough to select a text editor for a large manuscript. Use a 24-chapter, 480,000-character sample to separate published specifications, static source/localization checks, and existing CLI manual-write evidence. An autosave event that was not observed must remain an open acceptance item, not a success story.
Fix the 24-chapter baseline before comparing candidates
Define the values that must survive before judging any candidate. The dedicated sample had 24 H1 chapter headings, 20,000 characters per chapter, and 480,000 characters in total; its large-file flag was true. One SAFE-664-NEW marker was added to a duplicate, manually written, and counted again after readback.
| Acceptance item | Before manual write | After manual write | After readback | Pass rule |
|---|---|---|---|---|
| Chapter headings | 24 | 24 | 24 | Keep all 24 |
| Characters | 480,000 | 480,000 | 480,000 | Keep 480,000 |
SAFE-664-NEW |
0 before edit | 1 | 1 | Read back one marker |
| Modification time | Baseline | Changed | File located | Identify the saved file |
This table proves only the manual route. It does not prove that autosave produced the same result. Keep named chapter milestones as a separate recovery layer so the live file and the “return to this structure” copy have different jobs.
Keep three evidence layers separate
Evaluate the candidate through three evidence layers.
| Evidence | What it supports | What it does not support |
|---|---|---|
| Published specification (Stage 3) | A stated 1.2-second autosave delay and a pause while an unconvertible character remains | Firing, pausing, or resuming on the current machine |
| Static source/localization check | Connected logic and message resources for autosave conditions and encoding protection | Warning rendering, saved-state rendering, or runtime timing |
| Existing CLI/output verification (Stage 4) | Manual write, mtime change, and readback of 24 chapters, 480,000 characters, and one marker | Autosave firing, pause, resume, or notification |
Static alignment makes the feature a candidate for evaluation. It is not evidence that the interface completed the route. Never turn “the code and messages exist” into “the current screen succeeded.”
Define the autosave acceptance decision
Complete this ticket on a disposable duplicate before accepting autosave for production work.
| Evaluation item | Pass condition | Current evidence | Current decision |
|---|---|---|---|
| Trigger | The target file mtime changes without manual save | Published specification only | Unobserved |
| Readback | Reopen with 24 chapters, 480,000 characters, and one unique marker | Manual route passed | Autosave unobserved |
| Saved state | Distinguish unsaved from saved state | Static resources only | Unobserved |
| Recovery point | Select a milestone from before a chapter reorganization | Available as an operating practice | Acceptable |
If any runtime row remains unobserved, keep the autosave candidate on hold. Continue manual saves and named copies such as novel-ch08-before-reorder.txt. This does not deny the documented feature; it means the evidence required to depend on it for the production manuscript is incomplete.
Put an encoding stop line before acceptance
Treat encoding protection as a stop condition, not an invitation to save faster. If an unconvertible candidate remains, record the character, location, approved substitute, and target encoding. Do not promote that state to a milestone.
The published specification says autosave pauses while an unconvertible character remains. Static inspection found corresponding logic and localized message resources. This cycle did not operate or observe the warning, pause, or resume after correction. Those rows therefore stay open in the acceptance ticket.
Accept the candidate only after conversion candidates are cleared, the save destination is known, and readback returns the same 24 chapters, 480,000 characters, and unique marker. Otherwise retain a UTF-8 duplicate, manual saves, and chapter milestones.
Keep unobserved rows out of the success column
For Rune Studio, the verified set consists of the published specification, static resource alignment, and the manual-write/readback baseline. Autosave firing, encoding pause/resume, and interface state were not observed, so this article does not claim that they succeeded.
Fix the baseline first, use encoding issues as a stop line, and keep milestones until every required runtime row is observed. That turns autosave and encoding safeguards into a defensible selection method for a large manuscript. Current Mac specifications are available on the Rune Studio website.