v2.60.0

Added

• The status is available when creating a task, not just when editing one (#807). @thesoundhead
  pointed out that the new-task dialog offers no status, although what people write down is often
  something they have already started. The field was not forgotten - it sat behind the edit branch.

  The second half of the problem was on the server, and it was the more unpleasant one. POST /tasks has validated a supplied status against the allowed values since forever, and never wrote
  it. A value that is checked and then silently discarded is the worse half of both: opening up the
  form alone would have changed nothing, and nothing anywhere would have said so.

  Creating with a status is a status change - it merely starts from open instead of from a
  stored value. It therefore runs through the same transition handling as editing and ticking off:
  reward ledger, completion history, and the follow-up instance of a recurring series. Filling only
  the column would have given the point ledger and the history two sets of books, where the same
  finished task counted differently depending on whether it was created done or ticked off done.
  Sending archived on creation falls back to the first status rather than filing the task away:
  the archive has been its own axis since #688, and creating a task in order to put it away in the
  same breath is not creating a task.

• The wall mode can be started where it ends (#915). It could only be switched on under
  Settings, Personal, Appearance - but it was left on the overview. You walked out where you could
  not walk in. The entry point now sits in the overview toolbar as an icon button, the literal
  counterpart to the exit on the wall surface. The settings route stays: it is the long way with an
  explanation beside it, this is the short one at the place where it takes effect.

  There is deliberately no switch governing whether that button appears. It would sit in the same
  settings the mode itself already lives in - two switches for one thing, and you would have to find
  the second one to be rid of the first. There is no device-shape rule either: a wrongly hidden
  entry point is unfindable again and would only move the problem. The exit toast, which used to
  point into the settings because that was the only way back, now names the button instead.

• A kitchen timer on the wall (#844). @Gensokian asked for a timer plus a cross-device
  notification and then scaled the wish back himself: "honestly just the timer on the wall". That
  notification is precisely what would have forced a server-side timer, because a phone suspends the
  page as soon as the screen locks. What remains runs in the browser of the device that hangs on the
  wall anyway and does not go to sleep: no endpoint, no table, no migration. Five presets, no number
  field - from two metres a keypad is not operable - and a chime built from three synthesised tones
  rather than an audio file that would have to be vendored, served and cached.

  The screensaver had to come along. It covers the surface after five idle minutes, and a
  countdown that expires behind a photo is not a timer. It now reads the same attribute the timer
  sets, one source and two readers; the attribute drops the moment the timer rings, so an
  unacknowledged timer cannot disable the screensaver for good.

  The mode was built as a display-only surface, and that promise turns out to be narrower than its
  name: the exit has been there since day one, so it was never button-free - it leads nowhere and
  changes nothing in the household. The timer does not break that, it marks its edge. wall-mode.js
  therefore gained an admission rule rather than a named exception - a control may go on the wall
  when it does not navigate, changes nothing server-side, stays on this device, and is operable from
  two metres - because an expiry date on something meant to stay would be a lie in a comment.

Fixed

• A monthly series on the 29th to 31st no longer skips a month. Found while looking into a
  request for "last day of the month", and it is not the bug the request suggested. The clamp that
  was supposed to move a 31 March onto 30 April never took effect: setUTCMonth() had already
  rolled over on a date still carrying the 31st - a 31 February silently becomes 3 March in
  JavaScript - and the last-day correction was then computed for the month the overflow had landed
  in.

  So the short month did not fall back to its last day. It fell out entirely. A monthly task on
  the 31st arrived in seven months out of twelve; on the 30th and the 29th, February was missing.
  With an interval of two months the rhythm broke on top of that, because the skipped month shifted
  it: from 31 July it went three months on instead of two. It affected tasks and calendar events
  alike, since both walk the same function occurrence by occurrence.

  Existing series need no migration and compute correctly from their next occurrence onwards. This
  does move dates in existing installations, in the direction the user meant. What it does not fix,
  and what now says so in the code: because the next occurrence is computed from the clamped date, a
  series begun on 31 January stays on the 28th from February onwards, and a yearly series on 29
  February never returns to the 29th (#978). For that the rule itself would have to carry the
  intended day.

• Scrolling the task board on a phone no longer drags cards along (#808). @thesoundhead
  suggested distinguishing a long press from a short one - which is exactly what the app's shared
  drag wrapper has done all along for the shopping list and the category manager. The board did not
  use it: it carried two drag implementations of its own, native drag-and-drop for the mouse and a
  hand-written touch simulation beside it. The touch half did have a threshold, just the wrong kind:
  eight pixels of distance and no time at all. Anyone scrolling had those eight pixels within a
  blink, and the gesture then lost its scrolling. Both are gone; holding picks a card up, swiping
  stays scrolling, and the mouse still drags immediately.

  The advance-status button on each card is excluded from dragging - it was excluded in the old
  touch handler too, and that single line was the easiest thing to lose in the switch. Of everything
  on a card it can least afford to become a drag surface, because it is also the board's keyboard
  path.