fix: Include project description in generated note instead of discarding it

[cr7pt0gr4ph7]

The "Create New Project" modal has a "Description" field, whose value was simply discarded instead of being included anywhere.

Summary by CodeRabbit

• New Features

  • When creating a project manually, you can provide a description that will be used directly in the generated project content.
  • If no description is provided, the original inbox item text is used as fallback.
  • Reasoning text for manually created projects has been standardized for consistency.

• Tests

  • Added tests verifying description usage and fallback behavior.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a new optional description field to GTDProcessingResult, introduces a private formatDescription helper in src/file-writer.ts that prefers an explicit description over the original inbox item, and updates NewProjectModal to publish a fixed reasoning string and the new description. Tests updated accordingly.

Changes

Cohort / File(s)	Summary
File writer src/file-writer.ts	Added private formatDescription(originalItem, sourceNoteLink?, description?); replaced direct formatOriginalInboxItem usage with formatDescription across template substitutions and fallback content so provided result.description is used when present.
Processing result type & creator src/types/gtd.ts, src/new-project-modal.ts	GTDProcessingResult now includes description?: string. NewProjectModal.createProject sets reasoning to "User created project directly" and populates the new description field from user input.
Tests tests/file-writer.test.ts, tests/new-project-modal.test.ts	Added/updated tests validating: when description is provided it's used verbatim (no "Original inbox item:" prefix); when empty/undefined, fallback uses formatted original inbox item; expected reasoning string in new-project tests.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 A pen and a nibble, tidy and bright,
I tuck descriptions in, gentle and right.
If you write it yourself, I use what you say,
Otherwise I echo the inbox that day.
Hop—project assembled, neatly in sight.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding support for project description in generated notes rather than discarding it, which aligns perfectly with the core objective and file changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 590e65b and 9a6e5a0.

📒 Files selected for processing (5)

• src/file-writer.ts
• src/new-project-modal.ts
• src/types/gtd.ts
• tests/file-writer.test.ts
• tests/new-project-modal.test.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• src/file-writer.ts

🧰 Additional context used

🧬 Code graph analysis (1)

tests/file-writer.test.ts (2)

src/types/gtd.ts (1)

• GTDProcessingResult (16-34)

tests/__mocks__/obsidian.ts (1)

• TFile (3-11)

🔇 Additional comments (5)

src/types/gtd.ts (1)

24-24: LGTM!

The optional description field is well-defined with a clear comment explaining its purpose. The type and optionality are appropriate for storing user-provided descriptions.

tests/new-project-modal.test.ts (2)

163-164: LGTM!

The test expectations correctly reflect the new behavior where reasoning is a fixed constant and description is passed as a separate field.

---

207-225: LGTM!

This test correctly verifies that an empty description is passed through as an empty string while maintaining the fixed reasoning value. The test name accurately describes the scenario.

tests/file-writer.test.ts (1)

494-570: Excellent test coverage for description handling!

These three tests comprehensively cover all scenarios for the new description field:

1. Description provided → used directly without prefix
2. Description empty → falls back to "Original inbox item:" format
3. Description undefined → falls back to "Original inbox item:" format

The tests verify both positive expectations (content contains) and negative expectations (content does not contain), ensuring the behavior is correct.

src/new-project-modal.ts (1)

326-327: LGTM! Clean separation of reasoning and description.

The changes correctly implement the intended behavior:

• reasoning is now a consistent constant for all manually created projects
• description carries the user-provided content (trimmed)

The use of trim() ensures whitespace-only input becomes an empty string, which the tests confirm will fall back to the "Original inbox item:" format in the file writer.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[tavva]

Thanks @cr7pt0gr4ph7!