You’re viewing Paradaux’s public workspaceSign in to vote Get taskl.ie for your team

PAR-190

Loading issues

PAR-190 · [Epic] Planning layer — subtasks/epics, sprints, due… · Paradaux · taskl.ie

PAR-190

[Epic] Planning layer — subtasks/epics, sprints, due dates, release tagging

The largest schema-level gap. None of these exist today (confirmed in audit — no parent-child, no cycle, no due date columns).

Scope (each likely its own child issue once designed):

Subtasks / epics: parent-child hierarchy on issue (parent_id), UI to set/display parents and roll up children.
Sprints / cycles: team- or project-level iterations; tag issues to a sprint.
Due dates: due_date column + create/edit field + surfacing on rows/board; gate behind the configurability toggle.
Manual release tagging: today release membership is implicit (snapshot of a project's "Pending Release" status) — add explicit issue→release tag/untag (releases UI exists).

Touches model (Flyway migrations), backend API, MCP tools, and UI. Should respect per-workspace feature toggles from the configurability epic. Gated by RBAC for who can manage sprints/releases.

Activity

tesks created the issue Jun 15
tesks set status to In Progress Jun 16
tesksJun 16
Due dates shipped to develop — the first planning vertical, end-to-end + verified:
- Backend (tesks d5e5939): migration V21 adds issue.due_date; threaded through CreateTaskInput/UpdateTaskInput/TaskDetail (back-compat constructors so existing call sites are untouched), PostgresTaskSystem create/detail/update ("" clears, null = no change, "due" activity event), REST DTOs, and the MCP create/update tools. 1 test; backend suite 116 green.
- UI (tesks-ui 894dcde): a Due dates feature toggle in Settings; create/edit forms show a date field and the detail shows the due date when enabled. typecheck + vitest + next build green. Demonstrates the PAR-189 toggle pattern (off by default, opt-in per workspace).
Remaining planning features split into children: PAR-198 subtasks/epics, PAR-199 sprints/cycles, PAR-200 manual release tagging. This epic stays open while those land.
tesks set status to Pending Release Jun 16
tesksJun 16
Planning epic complete — all four features shipped to develop, each a verified backend+UI vertical gated behind a configurability toggle (PAR-189):
- Due dates — issue.due_date (V21), forms/detail, MCP. Commits d5e5939 + 894dcde.
- Subtasks/epics (PAR-198) — issue.parent_id (V22) with cycle/self guards, parent picker, subtask list w/ progress, MCP. bf7bab0 + 4f39a1c.
- Sprints/cycles (PAR-199) — new sprint entity (V23) + CRUD, issue tagging, filter, MCP. 005f732 + 3256139.
- Manual release tagging (PAR-200) — add/remove issues on open releases (frozen locked). 9ad87c3 + 3765922.
Backend suite 121 tests green; UI typecheck/vitest/next build green throughout. Marking the epic Pending Release.
ParadauxIO linked a commit: Commit d5e5939 — Add issue due dates through the stack (PAR-190) Jun 16
ParadauxIO linked a commit: Commit 9ad87c3 — Manual issue tagging on releases (PAR-200) Jun 16
ParadauxIO linked a commit: Commit bc3f244 — Enforce subtasks + due-date feature toggles server-side (PAR-190/PAR-189) Jun 17
tesksJun 17
Epic delivered — closing. All planning features are live on develop:
- Subtasks (PAR-198) — parent-child + children rollup on detail (UI + MCP).
- Sprints (PAR-199) — entity, tagging, UI, toggle-enforced.
- Due dates — due_date (V21), create/edit/surface, UI field.
- Manual release tagging (PAR-200) — explicit tag/untag.
And the consistency follow-up is done (bc3f244): all three opt-in planning toggles — subtasks, due-dates, sprints — are now enforced server-side at the store/admin layer, not just hidden in the UI, so an API/MCP caller can't set a parent/due-date/sprint on a workspace where the feature is disabled (clearing always allowed). Tests cover each. Team/project sprint scoping remains an explicit future deferral noted on PAR-199.
tesks set status to Done Jun 17
ParadauxIO linked a commit: Commit 00abf24 — Due dates in the UI, gated by the dueDates feature toggle (PAR-190) Oct 13

Workspace permission required to comment

Comments and reactions require workspace permission. Ask a workspace owner or admin for access. You can sign in to vote.