Feature/task list keyboard project management

AGENTS.md

@@ -1,71 +1,100 @@
-# TaskNotes - Agent Development Guide
+# TaskNotes development guidance
 
-This is an Obsidian plugin. The plugin ID is `tasknotes`.
+## Project context
 
-## Build & Test
+@README.md describes the project, its purpose, and how to use it. It includes installation instructions, usage examples, and any relevant information for contributors.
+@Tasknotes-Development-Guidelines.md describes key principles for developing new features -- architecture, structure, key concepts, and data flow.
 
-```bash
-# Build the plugin and copy files to the vault's plugin directory
-npm run build:test
+This repository is a fork of TaskNotes.
 
-# After building, reload the plugin in the running Obsidian instance
-obsidian vault=test plugin:reload id=tasknotes
-```
+The current main branch tracks the latest upstream TaskNotes release.
+The branch containing the legacy custom implementation is:
 
-Always run both commands after making changes. Obsidian must be running for the CLI to work.
+- task-view-keyboard-and-project-mgmt
 
-## Useful Obsidian CLI Commands
+The legacy branch was based on TaskNotes 3.2.x.
+Current main is TaskNotes 4.11.x.
 
-```bash
-# Check for JavaScript errors after reload
-obsidian vault=test dev:errors
+We are porting selected features to the new architecture rather than
+merging the legacy branch wholesale.
 
-# View console output
-obsidian vault=test dev:console
+## Porting priorities
 
-# Run JavaScript in the Obsidian context
-obsidian vault=test eval code="app.vault.getFiles().length"
+1. Jira integration
+2. Keyboard navigation
+3. Remaining custom features, handled individually
 
-# Take a screenshot to verify UI changes
-obsidian vault=test dev:screenshot path=screenshot.png
+Preserve current upstream behavior unless a requested feature explicitly
+changes it.
 
-# Open developer tools
-obsidian vault=test devtools
-```
+Prefer adapting features to the current architecture over copying old
+classes or abstractions unchanged.
 
-## Other Build Commands
+@Daves-Custom-Features.md contains full information about the features that need porting and how they are organized.
 
-```bash
-npm test              # Run unit tests (Jest)
-npm run lint          # Lint source files
-npm run typecheck     # TypeScript type checking only
-npm run build         # Production build (without copying to vault)
-```
+## Development rules
 
-Ensure all code changes pass linting checks. Do not weaken linting rules in order to get changes to pass. 
+Before editing:
 
----
+- Inspect the current implementation.
+- Inspect the corresponding legacy implementation and its Git history.
+- Describe the proposed porting approach.
+- Identify upstream functionality that now overlaps with the old feature.
 
-When you make changes, update docs/releases/unreleased.md. If your changes are related to a GitHub issue or PR, include acknowledgement of the individual who opened the issue or submitted the PR. Do not update unreleased.md for the addition of tests; unreleased.md is user-facing. 
+While editing:
+- For any new class, module, or function, always write a doc comment for the entity explaining
+  its main responsibilities, and pre/post conditions if appropriate.
+- Whenever adding new functionality, add a comment at the point in code that is the fulcrum of the
+  new feature explaining what it is doing and why.
 
-You may update `.ops/` files locally as you work on items, but do not commit `.ops/` files. `.ops/` is local-only working state.
+After editing, run the most relevant checks:
 
-## Investigating issues
+- npm run typecheck
+- npm test -- --runInBand
+- npm run lint
+- npm run build
 
-When investigating issues, you should try your best to reproduce them first. You can do a lot with the obsidian cli tool. If you have a theory about what is causing an issue, test that theory.
+Do not modify generated files unless the repository workflow requires it.
 
-Not all reported issues will require changes to the code, and not all feature requests need to be implemented; Bases are very powerful, but can be difficult to navigate. If something is not working, or is being asked for, figure out if it is--or can be--achieved through Bases first.
+Keep changes narrowly scoped.
+Do not combine unrelated feature ports in one commit.
+Do not commit unless explicitly requested.
 
-## Prepare for a release. 
+## Command approvals
 
-When asked to prepare for a release: 
+The following commands are always considered safe and should be executed
+without asking for confirmation whenever the approval policy permits:
 
-1. Run through the @I18N_GUIDE.md and make sure translations are up-to-date (and in their target language--not English placeholders). 
-2. Make sure ALL `npm run test` tests are passing. 
-3. Make sure there are no linting errors.
-4. Make sure all items in @docs/releases/unreleased.md thank the correct issue/pr opener (double check), as well as those who have commented on the issue/pr. Make sure the copy is appropriate--it is user facing so it should not be overly technical. Make sure it is free from anything that resembles marketing copy. do not thank callumalpass 
-5. Update `.ops` draft comments and matching Pickle requests for issues addressed in release notes but not yet closed. Start from the release notes, inspect each issue/comment thread individually, make sure `draft_issue_comment` and `draft_close_reason` are appropriate, create/update/cancel closeout Pickle requests as needed, and validate both `.ops` and `.ops/_pickle`. Do not commit `.ops/` files.
-6. Move the body of unreleased.md to <VERSION NUMBER>.md, following the pattern of previous releases. Leave the comments that explain unreleased.md inside unreleased.md.
-7. Update @manifest.json and @package.json.
-8. Commit changes as "release <VERSION NUMBER>" (you can choose the version number unless it is specified).
-9. Tag the commit. (Just version number, no 'v' prefix.)
+- git show
+- git log
+- git diff
+- git grep
+- git blame
+- git status
+- git branch
+- git merge-base
+- git rev-parse
+- rg
+- fd
+- ls
+- cat
+- sed
+- find
+- npm test
+- npm run lint
+- npm run build
+
+## Code navigation
+
+Use Serena’s symbol and reference tools for semantic navigation whenever possible:
+
+- find symbol definitions
+- find references and implementations
+- inspect symbol bodies
+- make symbol-scoped edits
+
+Use ripgrep for textual searches, configuration strings, CSS classes,
+serialized identifiers, and cases where semantic lookup is inappropriate.
+
+## Internationalization
+Localize all user-facing strings. Refer to the internationalization guide @I18N_GUIDE.md.

Daves-Custom-Features.md

@@ -0,0 +1,105 @@
+## Legacy feature branch
+
+The legacy implementation is on:
+
+* `task-view-keyboard-and-project-mgmt`
+
+It was developed against TaskNotes 3.2.x and must be adapted to the current TaskNotes 4.x architecture. Treat the branch as a behavioral reference and source of tests, not as code that must be merged or copied unchanged.
+
+## Features to port
+
+### 1. Keyboard-first task-list interaction
+
+The task list supports persistent keyboard focus, visible focused and selected states, single- and multi-task selection, and commands for creating, opening, editing, filtering, scheduling, changing due dates, changing priority, changing status, assigning recurrence, assigning tags, assigning contexts, assigning projects, and deleting tasks.
+
+Keyboard behavior remains active and predictable when context menus, filters, and modals are opened or closed. Commands that operate on tasks should consistently target either the current selection or the focused task.
+
+### 2. Configurable keyboard shortcuts
+
+Task-list shortcuts are configurable in settings. The implementation includes shortcut parsing, defaults, persistence, localized settings labels, and a dedicated shortcut-editing UI.
+
+Port this feature using the current settings and input architecture rather than preserving the legacy implementation structure.
+
+### 3. Jira integration
+
+Users can import Jira issues as TaskNotes tasks through the `obsidian-jira-issue` integration.
+
+The Jira feature includes:
+
+* Configurable Jira-to-TaskNotes field mappings
+* Mapping-value previews
+* Raw Jira issue JSON inspection
+* Sensible mapping defaults
+* Jira issue backlinks
+* Sanitized imported note titles
+* Current-note project assignment
+* Localized settings and validation text
+
+Review whether TaskNotes 4.x now has import, templating, external-integration, or credential abstractions that should replace the legacy design.
+
+### 4. Manual ordering and drag-and-drop
+
+Tasks support persistent manual ordering through a `sortOrder` or equivalent ranking field.
+
+Drag-and-drop supports:
+
+* Reordering within a group
+* Moving tasks between groups
+* Dropping at the end of a list
+* Moving all selected tasks together
+* Moving tasks across multiple groups
+* Ascending and descending task-list order
+* Batched persistence and efficient list refresh
+
+Use the current TaskNotes ranking, cache, grouping, and rendering systems. Do not assume the legacy `sortOrder` implementation remains appropriate.
+
+### 5. Project-aware task workflows
+
+The current note can be used as the default project for task creation and Jira imports.
+
+Users can assign projects through task-list commands and context menus. Project subtask views should honor the same relevant filters as other task-list views.
+
+Review current TaskNotes project semantics before porting legacy modal behavior.
+
+### 6. Story-point estimation
+
+Tasks support a story-points estimate, including:
+
+* Task schema/frontmatter storage
+* A configurable default
+* Task-creation support
+* Natural-language parsing using syntax such as `^3`
+* A story-points editing modal
+* Context-menu assignment
+* Task-list display and sorting
+
+### 7. Supporting workflow and correctness improvements
+
+Preserve the intended behavior of the following improvements where still relevant:
+
+* Pre-populating task-creation natural-language input
+* Populating task titles and other values from NLP parsing
+* Keeping context menus within the viewport
+* Filtering already-applied tags and contexts from selection dialogs
+* Ctrl+Enter to save task editing
+* Shift+Enter to open task notes
+* Correct frontmatter handling for optional and array properties
+* Correct cache invalidation and list refresh after batch changes
+* Complete localization for all new user-visible text
+
+## Porting method
+
+Port one functional slice at a time.
+
+For each slice:
+
+1. Inspect the legacy commits and final legacy implementation.
+2. Locate the corresponding TaskNotes 4.x architecture.
+3. Identify functionality now provided by upstream.
+4. Write a short implementation plan.
+5. Port the behavior using current abstractions.
+6. Add or adapt tests.
+7. Run typecheck, relevant tests, lint, and build.
+8. Review the resulting diff before committing.
+
+Do not merge the full legacy branch into current main. Cherry-pick only small, isolated commits when their implementation remains compatible with the current architecture.