Edit a memo's title on the detail screen #58

New issue

Closed

opened 2026-08-11 07:29:47 -04:00 by agent · 0 comments

agent commented

2026-08-11 07:29:47 -04:00

Member

Auto-naming (#53) gives a memo a title generated on the phone. There is no way to change one.

A generated title is sometimes wrong in a way only the person who recorded the memo can see. On the first build, a memo was titled First day of work and personal plans when nobody had said it was a first day — the model had inferred it. The prompt was reworked and that class of result is much rarer, but it cannot be made impossible: the title is a guess about somebody's words, and the person is the only one who knows.

What this is

A Name row on the memo detail screen, editable in place. A stock TextField in the existing header section rather than a sheet or a rename dialog — AGENTS.md asks for system-standard controls, and this is the control every other app uses for this.

Clearing the field removes <base>_title.txt and the row goes back to reading as the recording date, which is what an unnamed memo already does. That is the "no, don't name this one" answer, and it needs no separate affordance.

What it has to respect

TitleFile.write claims the name and refuses to overwrite, deliberately — linkItem into place, so two naming passes cannot fight and a title is written once. An edit is the one case that must replace, so it needs its own path rather than a relaxation of that one. A flag on write that sometimes overwrites would make the claim semantics conditional, which is how the guarantee gets lost.

A hand-edited title must not be regenerated. Nothing regenerates today — TitleGenerator skips any memo whose title file exists — so this holds as long as an edit leaves a file behind. Worth a test, because it is the property that stops the app renaming somebody's note back.

MemoLibrary caches titles per capture. The pass re-reads every capture on every refresh, so an edit reaches the list, but the edit should apply to the row immediately rather than waiting for the next pass.

Sanitising still applies. Wes decided on 2026-08-10 that vault inbox processing reads this file and names the note from it, so a typed title goes through MemoTitle.from exactly as a generated one does — it is a filename downstream whoever wrote it. That includes the length cap, and the field should show that limit rather than silently truncating.

Deletion already takes the title, so nothing changes there.

Not in scope

Renaming the audio, the transcript or the track. <base> is a cross-client contract and #53 exists in the shape it does specifically to leave it alone.

The rule that makes this safe

Auto-naming never touches a memo that already has a title. Wes, 2026-08-11:

"anything that already has a title shouldn't be editable by the auto-naming system, it doesn't need to be explicitly edited by the user"

That is already how TitleGenerator behaves — it skips any memo whose title file exists, and it asks whether the file is there rather than whether it reads as a title, so an emptied one is not treated as an invitation to try again. A hand-edited title is therefore safe for exactly the same reason a generated one is, and there is nothing to mark.

This supersedes the open question this issue was filed with, which asked whether an edited title needed a flag distinguishing it from a generated one. It does not. The existence of the file is the whole rule, and a second piece of state saying who wrote it would be a thing to keep in sync for no behaviour it would change.

Auto-naming (#53) gives a memo a title generated on the phone. There is no way to change one. A generated title is sometimes wrong in a way only the person who recorded the memo can see. On the first build, a memo was titled `First day of work and personal plans` when nobody had said it was a first day — the model had inferred it. The prompt was reworked and that class of result is much rarer, but it cannot be made impossible: the title is a guess about somebody's words, and the person is the only one who knows. ## What this is A **Name** row on the memo detail screen, editable in place. A stock `TextField` in the existing header section rather than a sheet or a rename dialog — `AGENTS.md` asks for system-standard controls, and this is the control every other app uses for this. Clearing the field removes `<base>_title.txt` and the row goes back to reading as the recording date, which is what an unnamed memo already does. That is the "no, don't name this one" answer, and it needs no separate affordance. ## What it has to respect **`TitleFile.write` claims the name and refuses to overwrite**, deliberately — `linkItem` into place, so two naming passes cannot fight and a title is written once. An edit is the one case that *must* replace, so it needs its own path rather than a relaxation of that one. A flag on `write` that sometimes overwrites would make the claim semantics conditional, which is how the guarantee gets lost. **A hand-edited title must not be regenerated.** Nothing regenerates today — `TitleGenerator` skips any memo whose title file exists — so this holds as long as an edit leaves a file behind. Worth a test, because it is the property that stops the app renaming somebody's note back. **`MemoLibrary` caches titles per capture.** The pass re-reads every capture on every refresh, so an edit reaches the list, but the edit should apply to the row immediately rather than waiting for the next pass. **Sanitising still applies.** Wes decided on 2026-08-10 that vault inbox processing reads this file and names the note from it, so a typed title goes through `MemoTitle.from` exactly as a generated one does — it is a filename downstream whoever wrote it. That includes the length cap, and the field should show that limit rather than silently truncating. **Deletion already takes the title**, so nothing changes there. ## Not in scope Renaming the audio, the transcript or the track. `<base>` is a cross-client contract and #53 exists in the shape it does specifically to leave it alone. ## The rule that makes this safe **Auto-naming never touches a memo that already has a title.** Wes, 2026-08-11: > *"anything that already has a title shouldn't be editable by the auto-naming system, it doesn't need to be explicitly edited by the user"* That is already how `TitleGenerator` behaves — it skips any memo whose title file exists, and it asks whether the *file* is there rather than whether it reads as a title, so an emptied one is not treated as an invitation to try again. A hand-edited title is therefore safe for exactly the same reason a generated one is, and there is nothing to mark. This supersedes the open question this issue was filed with, which asked whether an edited title needed a flag distinguishing it from a generated one. It does not. The existence of the file is the whole rule, and a second piece of state saying who wrote it would be a thing to keep in sync for no behaviour it would change.

agent added the

area/voice-memos

area/ui

type/feature

labels

2026-08-11 07:29:47 -04:00

agent referenced this issue from a commit

2026-08-11 07:33:01 -04:00

M3-53: write down the rule that a titled memo is left alone

agent referenced this issue from a pull request that will close it,

2026-08-11 11:53:59 -04:00

M3-53 + M3-58: name a memo, and let somebody change the name #61