fix: API compatibility with latest TaskNotes plugin (fixes #2)

[diegomarzaa]

Summary

Fixes #2 - HTTP 400 error when using CLI commands with the latest TaskNotes plugin.

Problem

The current TaskNotes plugin API has different behavior than expected by the CLI:

• GET /api/tasks with query parameters returns HTTP 400
• POST /api/tasks/query exists but returns 0 tasks regardless of filters

Solution

Implemented client-side filtering as a workaround:

Changes to lib/api.js:

• listTasks(): Now uses GET /api/tasks without params and filters client-side
• queryTasks(): Handles FilterParser AST format for advanced filtering client-side
• searchTasks(): Implements client-side title search
• Added helper methods: getAllTasks(), evaluateGroup(), evaluateNode(), evaluateCondition()

Changes to commands/projects.js:

• Fixed project filtering to handle [[wikilink]] format in project names
• showProject() and showProjectStats() now properly match tasks to projects

Testing

Tested with TaskNotes plugin v4.2.1. All CLI commands now work correctly:

• tn list (with all filter options: --today, --completed, --overdue, --filter)
• tn search
• tn projects list/show/stats
• All other commands that depend on task listing

[LostLaplace]

Great work! This resolves the issue I had opened.

[beorn]

Alternative approach: Use POST /api/tasks/query directly

I hit the same issue and found that POST /api/tasks/query works correctly - it's only GET /api/tasks with query parameters that returns the 400 error. GET /api/tasks without params still works fine.

Instead of fetching all tasks and filtering client-side, you could build a proper FilterQuery object and use the query endpoint:

async listTasks(filters = {}) {
  const conditions = [];
  const timestamp = Date.now();
  let condIndex = 0;

  const makeCondition = (property, operator, value) => ({
    type: 'condition',
    id: `cond_${timestamp}_${condIndex++}`,
    property,
    operator,
    value
  });

  // Note: TaskNotes default completed status is 'done'
  if (filters.completed === 'true') {
    conditions.push(makeCondition('status', 'is', 'done'));
  } else if (filters.completed === 'false') {
    conditions.push(makeCondition('status', 'is-not', 'done'));
  }

  if (filters.scheduled_after) {
    conditions.push(makeCondition('scheduled', 'is-on-or-after', filters.scheduled_after));
  }
  if (filters.scheduled_before) {
    conditions.push(makeCondition('scheduled', 'is-on-or-before', filters.scheduled_before));
  }
  if (filters.due_before) {
    conditions.push(makeCondition('due', 'is-before', filters.due_before));
  }

  const filterQuery = {
    type: 'group',
    id: `root_${timestamp}`,
    conjunction: 'and',
    children: conditions
  };

  return this.queryTasks(filterQuery);
}

Pros of server-side filtering:

• Works with pagination (large vaults)
• Handles complex filter logic the API already supports
• Less data transferred

Pros of your client-side approach:

• Works even if the query endpoint has bugs
• Simpler to reason about

Tested with TaskNotes v4.2.1 and the query endpoint works. Up to you which approach you prefer!