Software-Development Fields and a Bigger Template Catalog for Tasks Boards

Boards created from Tasks' Software Development template used to be indistinguishable from any other board — there was no stored marker saying "this is a dev board," and the new-task dialog offered nothing more than a free-text "Name or user id" field for assigning work. Two releases together close that gap.

Real dev-workflow fields

Software Development boards now carry an actual board_type marker, and tasks on them gain the fields a dev team expects: issue type, a checklist with acceptance criteria, comments, a proper sprint entity (alongside the legacy sprint string field, kept until nothing reads it anymore), manually-added PR/commit/branch links, dependencies with cascade-aware handling, milestones, and one level of real subtasks with a done-rollup back to the parent. The assignee field became an actual picker backed by a new GET /api/team endpoint, replacing the old free-text input.

All of this landed as additive D1 migrations — ten of them across the two releases — already applied to production, with 195 tasks-worker vitest tests covering the new fields and dependency logic.

Ten new templates

The template catalog grew by ten hand-authored boards: bug tracking, helpdesk, content calendar, event planning, hiring, QA cycle, feature/epic roadmap, scrum sprint board, release planning, and critical path. Save-as-template and list-templates are now wired to a workspace-private is_template column that existed in the schema but was previously unused by any code path.

What's still pending

The migrations and worker routes are live on production D1; the worker and frontend deploy for the newest of the two releases was still pending as of this writing, so give it a little time to reach every workspace.