• Implements individual .taskboard files for every board, addressing tickets #561, #591, #554, and
  #723
• Introduces TaskBoardFileManager for managing board configuration persistence and caching with
  debounced saves
• Adds v2 migration system with template board creation on first install and migration notifications
• Refactors drag-drop manager with auto-scroll functionality during drag operations and improved
  error tracking
• Updates settings UI with date format validation using date-fns library and refactored data
  access patterns
• Enhances task content formatting with new date utility functions and improved extraction methods
• Refactors advanced filter components to use board ID-based management instead of leaf/index-based
  approach
• Reorganizes imports across codebase to use explicit .js extensions for ES modules and relative
  paths
• Replaces console logging with bugReporterManagerInsatance.addToLogs() for centralized error
  tracking
• Expands enums with new UI options (ViewInSplitTab, ViewInWindow), task properties, and view
  types
• Improves file scanning to exclude .taskboard files and adds validation for unsupported checkbox
  symbols
• Adds boards explorer and merge boards commands for enhanced board management
• Removes legacy components and board operations utilities in favor of new file-based architecture

Refactor drag-drop manager with auto-scroll and improved error handling

• Refactored import paths to use relative paths with .js extensions for ES modules
• Added auto-scroll functionality during drag operations with startAutoScroll(),
 handleAutoScroll(), and stopAutoScroll() methods
• Updated currentDragDataPayload interface to replace currentBoardIndex with currentViewIndex
 and currentBoardID
• Replaced console.log() and console.error() calls with
 bugReporterManagerInsatance.addToLogs() for better error tracking
• Refactored swimlane change handling to always call updateTaskItemOnSwimlaneChange() without
 conditional checks
• Updated method signatures to pass plugin.settings.data directly instead of
 plugin.settings.data.globalSettings
• Deprecated drop indicator DOM manipulation methods and moved indicator rendering to column
 components
• Changed handleTasksOrderChange() to use taskBoardFileManager.loadBoardUsingID() and
 saveBoard() for board persistence
• Updated task update function calls to include both oldTask and newTask parameters
• Replaced DatePickerModal instantiation with openDateInputModal() helper function

src/managers/DragDropTasksManager.ts

Update settings UI with date validation and refactored data access

• Updated import paths to use relative paths with .js extensions for ES modules
• Changed from i18next to direct t() function import
• Refactored settings data access to use plugin.settings.data directly instead of
 plugin.settings.data.globalSettings
• Added date format validation with date-fns library using format(), parse(), and isValid()
 functions
• Replaced dropdown-based tasks cache file path setting with text input and transfer/reset buttons
• Moved hidden task properties settings section to appear after archived tasks file path setting
• Commented out experimental features toggle and lazy loading settings as deprecated
• Updated tag color type enum values from Text/Background to TagText/TagBg/CardBg
• Improved QuickAdd plugin compatibility setting UI with conditional rendering
• Added comprehensive date and date-time format validation with visual feedback
• Commented out task completion time-related settings

src/settings/SettingConstructUI.ts

Expand enums with new UI options and task properties

• Added ViewInSplitTab and ViewInWindow enum values to EditButtonMode
• Updated TagColorType enum with new values TagText, TagBg, and CardBg (replacing Text and
 Background)
• Added new task property names: FilePathInHeader, ParentFolder, and FullPath to
 taskPropertiesNames
• Added upcoming view types to viewTypeNames: list, table, inbox, and gantt
• Added new enums HeaderUITypeOptions with horizontal and vertical options
• Added new enum viewsPanelPropertiesToShow with properties like Title, Description,
 progress, CreatedDate, and ModifiedDate

src/interfaces/Enums.ts

Description

loadBoardFromDisk() changes a board's id whenever the same boardId exists in the registry
under a different filePath, which can happen after a rename/move. This breaks board identity and
can create duplicate/empty boards when opening the renamed .taskboard file.

Code

src/managers/TaskBoardFileManager.ts[R83-96]

+			const existingRegistryEntry = Object.entries(
+				this.taskBoardFilesRegistry,
+			).find(([, entry]) => entry.boardId === boardData.id);
+
+			if (existingRegistryEntry) {
+				const [, registryEntry] = existingRegistryEntry;
+				if (registryEntry.filePath !== filePath) {
+					// Same boardID but different filePath - generate new ID
+					const oldId = boardData.id;
+					boardData.id = generateRandomTempTaskId();
+					// console.log(
+					// 	`Board ID conflict detected. Changed board ID from "${oldId}" to "${boardData.id}" for file: ${filePath}`,
+					// );
+				}

Evidence

PR Compliance ID 2 requires board identity to survive .taskboard rename/move. The added
conflict-resolution logic regenerates boardData.id when the registry has the same boardId but a
different filePath, and loadBoardUsingPath() calls loadBoardFromDisk() before updating the
registry, so a moved/renamed file can be treated as an ID conflict and get a new ID.

Allow .taskboard files to be renamed/moved without breaking board identity
src/managers/TaskBoardFileManager.ts[83-96]
src/managers/TaskBoardFileManager.ts[211-233]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When a `.taskboard` file is renamed/moved, `loadBoardFromDisk()` can regenerate `boardData.id` due to a registry `filePath` mismatch, breaking board identity.

## Issue Context
The registry can be stale (still pointing to `oldPath`) at the moment the moved file is opened. In that case, a path mismatch should update the registry entry (or otherwise reconcile), not create a new board ID.

## Fix Focus Areas
- src/managers/TaskBoardFileManager.ts[80-99]
- src/managers/TaskBoardFileManager.ts[211-233]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Map node layout persistence is overwritten with only the currently rendered nodes, so tasks not
present under the current filter/project can have their saved positions deleted. Returning to a
previous filter/project can therefore reset/rearrange node positions.

Code

src/components/MapView/MapView.tsx[R555-568]

+	const handlenodePositionChange = useCallback(() => {
		try {
-			const stored = localStorage.getItem(NODE_POSITIONS_STORAGE_KEY);
-			if (stored) {
-				allBoardPositions = JSON.parse(stored);
-				if (typeof allBoardPositions !== 'object' || allBoardPositions === null) {
-					allBoardPositions = {};
-				}
+			// Update positions for current board with validation
+			const nodesDataMap: Record<string, nodePositionData> = {};
+			for (const node of nodes) {
+				const x = Number.isFinite(node.position?.x) ? node.position.x : 0;
+				const y = Number.isFinite(node.position?.y) ? node.position.y : 0;
+				const width = Number.isFinite(node?.width) ? node.width ?? 300 : 300;
+				nodesDataMap[node.id] = { x, y, width };
			}
-		} catch (error) {
-			console.warn('Failed to load existing positions:', error);
-			allBoardPositions = {};
-		}

-		// Update positions for current board with validation
-		const posMap = nodes.reduce((acc, n) => {
-			const x = Number.isFinite(n.position?.x) ? n.position.x : 0;
-			const y = Number.isFinite(n.position?.y) ? n.position.y : 0;
-			acc[n.id] = { x, y };
-			return acc;
-		}, {} as Record<string, nodePosition>);
-
-		setPositions(posMap);
-		allBoardPositions[String(activeBoardIndex)] = posMap;
-
-		try {
-			localStorage.setItem(NODE_POSITIONS_STORAGE_KEY, JSON.stringify(allBoardPositions));
+			// Only update useRef - no state update needed, avoiding re-render
+			allNodesData.current = nodesDataMap;
+			emitMapDataUpdatedSignal(true);

Evidence

PR Compliance ID 3 requires Map View layout to persist across filter/project switches. The new
handlenodePositionChange() rebuilds nodesDataMap only from the current nodes array and then
replaces allNodesData.current, and SAVE_MAP persists allNodesData.current to the .taskboard
file—so any nodes not currently rendered (e.g., filtered out) are dropped from the persisted layout.

Store Map View layout persistently to prevent layout being trashed when switching filters/projects
src/components/MapView/MapView.tsx[555-568]
src/components/MapView/MapView.tsx[171-186]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Saving map layout currently replaces the persisted `nodesData` with only the nodes visible in the current render, which can erase positions for tasks hidden by filters/projects.

## Issue Context
The Map View should preserve layout for all tasks across context switches. Persisted `nodesData` should be updated as a merge (update known nodes, keep existing entries for hidden nodes), not as a full overwrite.

## Fix Focus Areas
- src/components/MapView/MapView.tsx[555-568]
- src/components/MapView/MapView.tsx[171-186]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

TaskBoardFileManager.createNewBoardFile() computes folderPath as an empty string for root-level
files and attempts vault.createFolder(""), which can throw and prevent creating a new .taskboard
file. This breaks the “Create Template Board” flow which creates the file at vault root.

Code

src/managers/TaskBoardFileManager.ts[R610-615]

+			const parts = normalizedFilePath.split("/");
+			parts.pop();
+			const folderPath = parts.join("/");
+			if (!(await this.plugin.app.vault.adapter.exists(folderPath))) {
+				await this.plugin.app.vault.createFolder(folderPath);
+			}

Evidence

The template board creation uses a root-level file path (no /), and createNewBoardFile()
unconditionally tries to create the parent folder derived from splitting on /, producing an empty
folderPath and calling createFolder("").

src/obsidian_views/TaskBoardView.tsx[406-421]
src/managers/TaskBoardFileManager.ts[608-615]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Creating a new board file at the vault root can derive an empty parent folder path and call `vault.createFolder("")`, which can throw and block board creation.

### Issue Context
`TaskBoardView.handleCreateTemplateBoard()` creates a root-level file path like `TaskBoard-Template-<ts>.taskboard`, then calls `TaskBoardFileManager.createNewBoardFile()`.

### Fix Focus Areas
- src/managers/TaskBoardFileManager.ts[608-622]
- src/obsidian_views/TaskBoardView.tsx[406-421]

### What to change
- After computing `folderPath`, guard for root-level paths:
 - If `folderPath` is empty (or equals `.`), skip folder existence/creation.
- Consider consistently using `normalizedFilePath` for subsequent writes/caches/registry to avoid path mismatches.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

TaskBoardFileManager.addNewBoardToRegistry() updates plugin.settings.data.taskBoardFilesRegistry
but calls plugin.saveSettings() without awaiting it. This can cause racing writes and leave the
registry update unpersisted if multiple updates happen quickly or the app closes soon after.

Code

src/managers/TaskBoardFileManager.ts[R549-556]

+			this.plugin.settings.data.taskBoardFilesRegistry = {
+				[boardId]: newEntry,
+				...updatedTaskBoardFilesRegistry,
+			};
+			this.plugin.saveSettings();
+			this.taskBoardFilesRegistry =
+				this.plugin.settings.data.taskBoardFilesRegistry;
+

Evidence

saveSettings() is an async I/O operation (await this.saveData(...)), so fire-and-forget calls
can reorder or be cut off by shutdown; addNewBoardToRegistry() is used as part of board open/load
paths and should persist deterministically.

src/managers/TaskBoardFileManager.ts[549-555]
main.ts[358-365]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Settings persistence for `taskBoardFilesRegistry` is done via an un-awaited async call, allowing races and potential loss of registry updates.

### Issue Context
`TaskBoard.saveSettings()` performs async disk I/O. Calling it without `await` means callers proceed before the write completes.

### Fix Focus Areas
- src/managers/TaskBoardFileManager.ts[508-556]
- main.ts[358-365]

### What to change
- Change `this.plugin.saveSettings();` to `await this.plugin.saveSettings(this.plugin.settings);` (or equivalent) and propagate/handle async where needed.
- Also consider awaiting other internal async calls that depend on the registry being persisted (e.g., callers of `addNewBoardToRegistry`).
- If performance is a concern, introduce a dedicated debounced/queued settings writer with explicit flush on unload.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

TaskBoardView.setState() prioritizes leaf.taskboardFilePath if present, but this field is never
cleared after use and is populated from the monkey patch using state.state.file (not the
filePath shape used elsewhere). This can cause later setState() calls on the same leaf to
incorrectly treat it as a “clicked file” and load the wrong board.

Code

main.ts[R462-474]

+				function (this: WorkspaceLeaf, state: any, eState?: any) {
+					const isTaskBoardView = state.type === VIEW_TYPE_TASKBOARD;
+					const filePath = state.state?.file as string | undefined;
+					const isTaskboardFile =
+						filePath && filePath.endsWith(".taskboard");
+
+					if (isTaskBoardView && isTaskboardFile) {
+						// Store the file path directly on the leaf instance for immediate access
+						(this as any).taskboardFilePath = filePath;
+
+						// Also set ephemeral state for safety
+						this.setEphemeralState({ taskboardFilePath: filePath });
+					}

Evidence

The monkey patch writes leaf.taskboardFilePath from state.state.file, while normal activations
use state.state.filePath; the view then always prefers leaf.taskboardFilePath when set, and does
not reset it, so the clicked-file code path can override state-driven restoration in subsequent
invocations.

main.ts[457-474]
main.ts[299-308]
src/obsidian_views/TaskBoardView.tsx[133-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
A leaf-scoped `taskboardFilePath` is used to decide whether a `.taskboard` file was clicked, but the field is set inconsistently and never cleared, which can override state-based loading.

### Issue Context
- Monkey patch sets `leaf.taskboardFilePath` from `state.state.file`.
- `activateView()` sets `state.state.filePath` (different key).
- `TaskBoardView.setState()` always checks `leaf.taskboardFilePath` first and does not clear it after consuming.

### Fix Focus Areas
- main.ts[457-478]
- main.ts[297-309]
- src/obsidian_views/TaskBoardView.tsx[133-156]

### What to change
- Unify the state key used across the plugin:
 - Either use `state.state.file` everywhere (including `activateView()`), or update the monkey patch to also read `state.state.filePath`.
- In `TaskBoardView.setState()`, after handling a clicked file, clear the leaf field (e.g., `delete (this.leaf as any).taskboardFilePath`) so subsequent `setState()` calls don’t keep taking the clicked-file path.
- Optionally, read from `leaf.getEphemeralState().taskboardFilePath` (already set by `activateView`) instead of a custom leaf property.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools