[Bug]: Duplicate-name handling drops the title when "Store title in filename" is enabled – deduplicated task is permanently retitled "Title-2"

[AdmiralClackington]

Bug Description

Note - I am just a big dumb idiot, and much of this was diagnosed by Claude. I did the best I could to rule out other issues, though. This bug appears in a completely fresh vault with no plugins added but tasknotes. PS - tasknotes is great. Thank you for building this.

---

With Store title in filename enabled, creating a task whose title already exists correctly deduplicates the filename (Time Entry-3.md), but the note is written without a title frontmatter field. Since the reader derives the title from the basename when no frontmatter title exists, the new task's title silently becomes Time Entry-3 instead of Time Entry – in Kanban/task views and everywhere else. The user's chosen title is lost at creation time with no indication.

Cause: commit b963845 ("Honor store title in filename frontmatter", the fix for #1623) added an unconditional delete in TaskCreationService.createTask (currently src/services/task-service/TaskCreationService.ts around line 293):

if (runtime.settings.storeTitleInFilename) {
    delete finalFrontmatter[runtime.fieldMapper.toUserField("title")];
}

That is correct when the final filename equals the title (the #1623 case), but wrong when generateUniqueFilename() had to append -N (or sanitization changed the name): then the filename can no longer carry the title, and deleting the field destroys the only place it could round-trip. The read path already prefers a frontmatter title over the basename when the field is present, so keeping it in exactly this case restores correct display without regressing #1623.

Suggested fix: make the delete conditional – only remove the title field when the generated unique filename matches the (sanitized) title, e.g.:

if (runtime.settings.storeTitleInFilename && uniqueFilename === filenameTitle) {
    delete finalFrontmatter[runtime.fieldMapper.toUserField("title")];
}

Expected behavior (and prior behavior before 4.8.0): Time Entry-3.md is created with title: Time Entry in frontmatter and displays as "Time Entry".

Reproduced in my main vault and in a fresh clean vault with only TaskNotes installed (debug info below is from the clean vault). The unconditional delete is present in the 4.11.1 release build and in current master.

Steps to Reproduce

1. Enable Store title in filename.
2. Create a task titled Time Entry – creates Time Entry.md, correctly no title field.
3. Create a second task titled Time Entry (exact same case; case variants hit a different bug: [Bug]: Task creation fails with "File already exists" when the new title differs only in letter case from an existing task file #2107.
4. Time Entry-2.md is created, but with no title field – the task now displays as "Time Entry-2" everywhere.

TaskNotes Debug Info

SYSTEM INFO:
    Obsidian version: 1.12.7
    Installer version: 1.12.7
    Operating system: Darwin Kernel Version 25.5.0: Tue Jun  9 22:26:22 PDT 2026; root:xnu-12377.121.10~1/RELEASE_ARM64_T8132 25.5.0
    Login status: not logged in
    Language: en
    Insider build toggle: off
    Live preview: on
    Base theme: adapt to system
    Community theme: none
    Snippets enabled: 0
    Restricted mode: off
    Plugins installed: 1
    Plugins enabled: 1
        1: TaskNotes v4.11.1

Affected Task Frontmatter

---
status: doing
priority: normal
dateCreated: 2026-07-09T15:13:12.616-05:00
dateModified: 2026-07-09T15:13:12.616-05:00
tags:
  - task
---
# Expected (adding "title: Time Entry" by hand fixes the display,
# confirming the read path still honors it):
---
title: Time Entry
status: doing
priority: normal
tags:
  - task
---

Relevant Bases File Content

Relevant Settings or Customizations

{
"taskIdentificationMethod": "tag",
"taskTag": "task",
"taskFilenameFormat": "zettel",
"storeTitleInFilename": true
}

Console Errors or Logs

Screenshots or Screen Recording

No response