Reviewing files that changed from the base of the PR and between de06201 and 67482c0.

• docs/tasks-done/task-2025-12-04-fix-nullable-schema-types.md (1 hunks)
• src-tauri/src/commands/files.rs (4 hunks)
• src-tauri/src/schema_merger.rs (4 hunks)
• src/hooks/editor/useEditorActions.ts (3 hunks)
• src/hooks/editor/useEditorHandlers.test.ts (2 hunks)
• src/hooks/useEditorFileContent.ts (1 hunks)
• src/store/editorStore.ts (6 hunks)
• test/dummy-astro-project/.astro/collections/notes.schema.json (1 hunks)
• test/dummy-astro-project/.astro/settings.json (1 hunks)
• test/dummy-astro-project/src/content.config.ts (1 hunks)
• test/dummy-astro-project/src/content/notes/frontmatter-preservation-test.md (1 hunks)
• test/dummy-astro-project/src/content/notes/nullable-schema-test.md (1 hunks)

• GitHub Check: Analyze (rust)

test/dummy-astro-project/.astro/settings.json (1)

3-3: Verify the necessity of committing this test fixture change.

This is an auto-generated settings file in the test project directory. The timestamp modification appears to be a touch update rather than a functional change. Test fixtures and configuration files that are auto-generated by the build or test tooling should typically not be committed to version control, or the PR description should clearly explain why this file has been modified.

Confirm whether this change is intentional and necessary for the PR to function correctly, or if it should be excluded from the commit.

src-tauri/src/schema_merger.rs (4)

418-444: LGTM! Well-structured nullable type handling.

The prioritisation of nullable primitive, array, and enum extraction before falling back to string is correct. This directly addresses issue #68 where z.number().nullish() was incorrectly typed as "string".

---

446-486: Solid implementation with appropriate guards.

The logic correctly identifies nullable primitives while properly deferring strings with enum values to the dedicated enum handler. The explicit 2-element check and type matching are robust.

---

520-556: LGTM! Correctly extracts nullable enums.

The logic properly identifies nullable enum patterns by checking for both a null type and a string type with enum values. The catch-all _ => {} is appropriate here since the function needs to examine all schemas in the union.

---

1264-1304: Excellent regression test for issue #68.

The test explicitly documents the bug and verifies both lat and lng fields are correctly typed as "number" regardless of the order of elements in the anyOf array. This directly validates the fix for the reported issue.

src/hooks/editor/useEditorHandlers.test.ts (1)

28-28: LGTM! Mock state correctly extended.

The addition of isFrontmatterDirty to the mock store state and its initialisation to false aligns with the new editor store field. This ensures tests remain compatible with the updated store interface.

Also applies to: 74-74

src/hooks/useEditorFileContent.ts (1)

39-45: LGTM! Correctly resets frontmatter dirty state on load.

Resetting isFrontmatterDirty: false when syncing from disk ensures the editor correctly treats loaded content as clean. This is essential for the save flow to preserve original frontmatter formatting when only content has changed.

test/dummy-astro-project/src/content/notes/nullable-schema-test.md (1)

1-31: LGTM! Useful test fixture for nullable schema types.

The test file provides concrete test data for verifying nullable enum and array handling. The frontmatter values correctly exercise the new nullable schema paths (status, keywords, scores).

Note: The static analysis warnings are false positives — the grammar check misunderstands the technical documentation context, and "tag input" vs "text field" are distinct UI element types, not duplications.

src/hooks/editor/useEditorActions.ts (3)

32-39: LGTM! Clean destructuring of frontmatter state.

The addition of rawFrontmatter and isFrontmatterDirty to the destructured state is well-organised and follows existing patterns.

---

73-82: Core fix for issue #68 — preserves raw frontmatter when unedited.

The conditional logic correctly determines which frontmatter representation to send:

• When isFrontmatterDirty is true: sends the parsed frontmatter object (user made sidebar edits)
• When false: sends rawFrontmatter to preserve original YAML formatting and type information

This ensures that numeric values like lat/lng remain as numbers when only the content body is edited.

---

91-95: LGTM! Correctly resets dirty flags after save.

Resetting both isDirty and isFrontmatterDirty to false after a successful save ensures the editor state accurately reflects that all changes have been persisted.

test/dummy-astro-project/src/content/notes/frontmatter-preservation-test.md (1)

1-36: LGTM! Clear test documentation.

This test file provides clear instructions and expected behaviours for frontmatter preservation testing. The documentation of both preserved and re-serialised scenarios is helpful for validation.

src/store/editorStore.ts (1)

19-20: LGTM! Correct dirty state tracking implementation.

The isFrontmatterDirty flag is properly integrated:

• Initialised to false and reset on file open/close operations
• Set to true when frontmatter is updated via updateFrontmatter or updateFrontmatterField
• Intentionally NOT modified in setEditorContent, which correctly preserves the distinction between content-only and frontmatter edits

This implementation aligns with the PR's objective to track frontmatter modifications separately from content changes.

Also applies to: 47-47, 70-70, 101-101, 125-125, 147-147

test/dummy-astro-project/.astro/collections/notes.schema.json (1)

50-90: LGTM! Nullable schema types correctly defined.

The three new properties follow the correct anyOf: [type, null] pattern for nullable types:

• status: nullable enum with valid values
• keywords: nullable array of strings
• scores: nullable array of numbers

These additions align with the PR's objective to support nullable schema types and match the Zod definitions in content.config.ts.

test/dummy-astro-project/src/content.config.ts (1)

48-51: LGTM! Zod schemas correctly defined for testing.

The nullable Zod schemas match the JSON Schema definitions and provide comprehensive test coverage for:

• Nullable enums (status)
• Nullable string arrays (keywords)
• Nullable number arrays (scores)

These test schemas align with the PR's objective to support nullable schema types properly.

src-tauri/src/commands/files.rs (4)

364-378: Consider defensive check for impossible state.

The match logic correctly handles the three scenarios:

1. Frontmatter edited → use parsed and normalize
2. Frontmatter unchanged → preserve raw formatting
3. No frontmatter → content only

However, consider adding a defensive check for the impossible case where both frontmatter and raw_frontmatter are Some:

 let new_content = match (frontmatter, raw_frontmatter) {
     // Frontmatter was edited - reorder and normalize
     (Some(fm), _) => rebuild_markdown_with_frontmatter_and_imports_ordered(
         &fm,
         &imports,
         &content,
         schema_field_order,
     )?,
+    // Defensive: If both are present, prefer parsed (shouldn't happen from frontend)
+    (None, Some(_)) => {
+        return Err("Invalid state: received both frontmatter and raw_frontmatter".to_string());
+    },
     // Frontmatter unchanged - preserve original (non-empty)
     (None, Some(ref raw)) if !raw.trim().is_empty() => {
         rebuild_markdown_with_raw_frontmatter(raw, &imports, &content)?
     }
     // No frontmatter at all (None, None, or empty string)
     _ => rebuild_markdown_content_only(&imports, &content)?,
 };

Actually, on second thought, the current pattern (Some(fm), _) already handles this by giving precedence to parsed frontmatter. The code is correct as-is.

---

716-755: LGTM! Raw frontmatter preservation correctly implemented.

The rebuild_markdown_with_raw_frontmatter function correctly:

• Preserves the raw frontmatter string exactly as-is (no normalisation)
• Handles imports and content with proper spacing
• Ensures consistent newline handling

The blank line before imports (line 733) is always added because this function is only called when raw frontmatter is non-empty (guarded in save_markdown_content line 373), ensuring consistency with the normalised path.

---

758-786: LGTM! Content-only rebuild correctly implemented.

The rebuild_markdown_content_only function properly handles the case where there's no frontmatter:

• Includes imports if present
• Adds appropriate spacing between imports and content
• Ensures trailing newline

The spacing logic is consistent with the other rebuild functions.

---

1589-1649: Excellent test coverage for new rebuild functions.

The test suite comprehensively covers:

• Raw frontmatter preservation including datetime format (lines 1589-1605)
• Raw frontmatter with imports (lines 1607-1620)
• Content-only rebuild without imports (lines 1622-1635)
• Content-only rebuild with imports (lines 1637-1649)

These tests validate the key behaviours of the frontmatter preservation feature.

docs/tasks-done/task-2025-12-04-fix-nullable-schema-types.md (1)

1-688: Comprehensive documentation of implemented features.

This documentation thoroughly explains:

• The nullable schema types problem and solution approach
• The frontmatter preservation feature with architecture diagrams
• Implementation details with code examples
• Test plans and success criteria
• Edge cases and gotchas

The documented implementation aligns with the code changes reviewed in editorStore.ts and files.rs. This serves as excellent reference documentation for future maintainers.