Edit a generated note, without losing what the model wrote

[Optic00]

Edit a generated note, without losing what the model wrote

A generated note has been read-only since the app shipped. When the model misspells a name, mishears a company, or gets a detail wrong, there is no way to correct it.

This makes the note editable section by section, and makes that safe: the model's original output is kept, and every path that would rebuild the note asks first.

What it does

Editing. An Edit affordance in the Summary tab turns the note into a form: the body text becomes a textarea, key points and action items become editable lists with add and remove, and Key Topics gets its title and analysis. Save writes only what changed. Cancel discards. The note stays a document until you ask to edit it, which is deliberate - it is read far more often than it is written, and keeping the boundary between the model's output and your corrections visible is the point.

Nothing gets silently discarded. The model's own output is snapshotted to a <stem>_original.json sidecar at generation time. Regenerating, reprocessing or re-transcribing a note you have edited now names the sections it would replace and asks. Leaving the screen with an unsaved draft asks too.

The chat can see your corrections. The single-meeting chat context was missing participants and action items; the cross-note chat was missing participants. Both now carry them, so a name you fixed is a name the chat knows.

How it is built

• app/note-sections.js - pure, section-scoped transforms over the note body. Each replaces exactly one ## section and leaves every other byte untouched. Duplicate headings resolve last-wins, matching parseMeetingMarkdown, because a note whose model output repeated a heading would otherwise lose the edit on the next read.
• app/atomic-write.js - temp file plus rename, extracted from the pattern three handlers in main.js already used inline. The markdown branch of update-meeting previously ended in a bare writeFileSync.
• app/note-snapshot.js - the sidecar: the original fields, an edited_fields list, and the provenance of the capture. Reads never throw and return null for anything unusable, because opening a note must never fail because of its sidecar. Writes throw on a path they cannot derive from, because the alternative is overwriting the note.
• update-meeting gained the four content fields on markdown notes. It rejects a value that would forge a section boundary, rejects a line break inside a list entry, writes atomically, and snapshots lazily for notes that predate this change - accurate, because those notes have never been editable, so their current content is the model's output.
• simple_recorder.py writes the same sidecar whenever a note is generated, reading the note back and parsing it with _parse_meeting_markdown so both sides capture the same thing rather than two differently normalised versions of it.

Two things worth a reviewer's attention

The heading gate scans normalised text, not raw. Both parsers run normalizeMarkdownForParsing before splitting on ## , and that transform rewrites a reasoning close-tag glued to a heading: </think>## Summary becomes a real heading at read time. A gate anchored on ^ would pass it. The failure was not adversarial - the normaliser exists because models emit exactly that shape, so pasting model output into a field triggered it, and the forged heading then won under last-wins parsing and made the real summary read as empty, unrecoverably through the UI.

Deleting a meeting now removes the sidecar too. It is stem-derived like <stem>_reports.json and follows the same unlink-only-at-commit semantics, so an undo restores a complete meeting. Without this, a deleted meeting would have left a readable copy of its summary, action items and attendee names on disk.

Why the diff touches one thing that has nothing to do with editing

update-meeting's markdown path could report a successful save while writing nothing. A .md note whose frontmatter is missing or unclosed skipped the branch that rewrites the body, wrote the file back unchanged, and returned success: true. The My-notes autosave therefore told the user it had saved and discarded what they typed.

That is pre-existing and predates this branch. It is fixed here because this branch added the same guard for the note's structural fields and left the sibling case half-done, in the same handler, one condition apart. Leaving it would have meant shipping a handler where one kind of edit fails loudly and another fails silently.

Worth knowing how it surfaced: it was found by a review from a different model family, after ten task-scoped reviews, a whole-branch review and a fix round had all closed clean.

What the chat change does and does not send

The single-meeting chat context gained participants and action items; the cross-note context gained participants.

Action items now travel where they did not before. That is not a new class of data - the summary of the same meeting already went, and action items are part of it.

Participants currently travel as an empty list. The markdown prompt never asks the model for a ## Participants section (src/summarizer.py), so no note the current pipeline produces has one. Checked against a real install of 21 notes, 16 markdown and 5 legacy JSON: none had the field populated. The wiring is in place; the field is not yet filled by anything.

That matters for a later change, not this one. Once participants are populated - by calendar prefill or by the user typing them - real names will reach the provider on every single-meeting question, and for a cross-note question, names from every note in the corpus. On the local provider that stays on the machine; on a cloud or org provider it is an expansion of what leaves it, and it deserves a line in the release notes at that point.

Email addresses never reach a model in either case. Participants are a list of names, and the summariser is never asked to produce them.

Testing

• 24 new node:test cases across the three new modules, plus the existing suites: 513 Python, 159 vitest, typecheck clean, lint unchanged from base.
• ruff drops from 29 findings to 27 with an identical rule breakdown - two dead assignments were removed, no new class.
• e2e: a T1 spec for the interaction contract against the mock IPC, and four T2 specs against the real backend covering the write path, the rejection gate, the regenerate confirm and the delete lifecycle. All model-free, in the existing t2-macos / t2-windows lanes.

Known and deliberately left

• Sidebar, Cmd-K and deep-link navigation still unmount an open editor without asking; only the in-view back button is guarded. A router-level unsaved-changes hook is the right fix and is its own change: Note editor: navigating away via the sidebar, Cmd-K or a deep link discards an unsaved draft #447. The failure mode is always a lost draft, never one applied to the wrong note, because DetailContent is keyed on the summary file.
• A note with no generated content cannot be opened for editing, because the Edit affordance reuses the PDF export's content condition.
• The two markdown parsers still disagree on exotic whitespace (U+0085 after a reasoning tag, U+FEFF before a bullet). Pre-existing, unchanged here.
• New user-facing error strings are English literals. If the i18n work lands first, they need extracting - a string that was never extracted is precisely what the completeness gate cannot catch.