ulsklyc/yuvomi v2.32.0

on GitHub

Added

• The MCP tool list_tasks takes an include_future flag (discussion #825). It is off by
  default, which is the point: the tool now selects exactly what the app shows, so an automation is
  no longer told about a task that will not start for another week. Set it to true to get the
  scheduled ones as well. The name matches the query parameter GET /api/v1/tasks has always had,
  rather than inventing a second word for the same axis.

Fixed

• The overview now selects the same tasks as the Tasks module (discussion #825). Both answer the
  same question - "what is up?" - and each had its own copy of the rules, which had drifted. The
  module leaves out subtasks (parent_task_id IS NULL) and anything that only starts later
  (start_date); the overview knew neither rule. A subtask therefore stood in "Today at a glance" as
  a context-free line of its own, without the instruction it belongs to, and a task starting next
  week was already sitting there today. Both sides were green on their own tests - the fault lived in
  the difference between them, which is the same shape as #467 (the dashboard bypassing module
  permissions) and #769 (a writing path that never got the visibility check).

  The two shared rules now live in services/task-scope.js, the way calendar-events.js has always
  been shared between the calendar route and the dashboard. The metric tiles were changed as well,
  not just the list: urgentTasks caps at five while the counts are unbounded, so filtering only
  the list would have put two rows under a tile claiming four. What the filters must not do is run
  after the cap - the same lesson as #647.

  A third copy turned up while moving the first two. The MCP tool list_tasks had one of the two
  rules and not the other, so an automation was told about tasks that will not start for another
  week. It shares the helper now and gained an include_future flag, named like the one the REST API
  already has. MCP tools build their own queries and never pass through Express, so no path guard
  covers them - that is the same route by which the visibility check (#474) once went missing there.

  The test schema mirror turned out to be mislabelled, found while adding an entry to it for this
  fix. server/db-schema-test.js hands test suites individual migrations by version number, and
  seven of them carried the wrong one: keys 15 through 21 held the contents of 22 through 28, a
  straight offset. No suite used any of the seven, so nothing was ever red - whoever had picked one
  up would have got a schema they did not ask for. The numbers are corrected and
  npm run test:schema-mirror holds the mapping in place. It checks the weaker, workable claim
  rather than equality: an entry may not touch an object its migration does not touch. The mirror is
  deliberately an extract - it omits what a test database does not need - so a strict comparison
  would have needed more exceptions than it was worth.

  Deliberately left in the module: status, priority, person, category, tags and the archive axis
  (#688). Those are a viewer's wishes about a list, not a statement about what a list may contain at
  all. Only the two rules both sides need, and disagreed on, are shared.

  One thing fell out of the move: the module compared start_date against SQLite's date('now'),
  which is the UTC day, while start_date is a locally entered calendar day. West of UTC a task
  therefore began the evening before its start date, east of it not until the following morning. The
  shared helper takes the day as a parameter, and both callers pass their local one. CI runs in UTC,
  where the two are identical - which is exactly why this kind of fault is never visible there.