Mockarty Tasks — built-in issue tracker

Mockarty Tasks is a lightweight issue tracker built into the platform: projects,
a Kanban board, sprints, a backlog, analytics — deeply linked to your test
cases, runs and findings, so a bug lives next to the test that reproduces it.

Open it from the sidebar: Tasks (/ui/tasks).

Turning the tracker on or off

The tracker ships inside the Processing & Communications module and is on by default in every
namespace whose plan includes it. A team that keeps its tasks elsewhere (for example in Jira) turns it
off per namespace: Settings → TMS Settings → Issue Tracker (the issueTrackerEnabled toggle).
While it is off, the tracker API answers with a self-explanatory feature_disabled error that points
at this switch.

Projects

Everything lives in a project: it owns the issue key prefix (ABC-123), the
workflow, components, versions and the member list. Create one from the project
selector in the toolbar.

• Key prefix is unique per namespace; a duplicate prefix is rejected with
  a clear conflict error.
• Merge projects: preview the source and target before merging. The target
  must be a different visible project in the same namespace. A merge gives
  source issues new keys under the target prefix and closes the source project
  together with the move. If anything fails, no issue is moved. The response
  contains an old-to-new keyMap; a merge of more than 10,000 issues is refused
  so the response remains bounded. Existing sprint membership is cleared.
  Issues already in the Recycle Bin move with the project and remain restorable
  in the target project; they are included in the preview count and merge limit.
• Delete a project: a project with open issues or boards returns a conflict
  with their count. Choose recursive deletion to move the project, every open
  issue and every open board to the Recycle Bin in one operation. Restore the
  project first, then restore the issues and boards you need individually. New
  components and versions cannot be added while the project is in the bin.
• Visibility: a project is namespace (everyone in the namespace) or
  private (creator, lead, explicit members, admins). Private cascades to the
  project’s issues everywhere — boards, search, analytics. Only project members
  can create boards or sprints within a private project.
• Per-issue privacy: an epic (or any issue) can additionally be marked
  private with its own member list; children inherit it. Secured issues are
  hidden everywhere, reports included. Search, compact lists, dependency graphs,
  sub-task trees, and test-case links only show issues you can access. Cloning
  an issue does not copy children or relations that you cannot see.
• Test-case links: an issue can be linked only to an existing, open test case
  in the same namespace. Repeating the link keeps the existing association.
  Unlinking removes it from the issue view; the closed link is cleared after
  the configured retention period.
• Workflow: pick a preset (kanban / simple / bugflow) or configure per
  project in Settings → Workflow, with an optional override per issue type
  (Jira-style scheme: a default flow plus, say, Bug flow for bugs). The board
  shows the default flow’s columns; a card whose type follows another flow sits
  in the column of its lane (to do / in progress / done). Inside the issue, the
  status list and the quick transitions come from the workflow of its type,
  so you are never offered a move the tracker would refuse. Invalid drop targets
  dim while dragging, per card type.

Issue types

Built-in types: Bug, Story, Task, Epic, Sub-task. Every card,
list row and the issue itself show the type as a coloured icon badge (bug, bookmark,
check, bolt, list), so you can tell an epic from a bug at a glance; epics roll up
their children.

Changing the type. Filed a bug as a task? Open the issue: the Type control is
the first thing in the status bar. Click it, pick the new type — it saves at once and
the change is recorded in the issue history. The same hierarchy rules as in Jira apply:
a sub-task needs a parent (set the parent first), an epic cannot have a parent, an
issue that already has sub-tasks cannot become a sub-task, and the issue’s current
status must exist in the new type’s workflow — otherwise the tracker tells you what to
change first.

The board

One column per workflow status, drag-and-drop between columns (workflow-gated;
closing transitions ask for a resolution, Jira-style).

Fast paths on the board:

• Quick-add: the + Add issue slot at the bottom of every column — type a
  title, press Enter.
• Card quick-edit: click the priority pip on a card for a priority menu;
  click the avatar for an assignee picker (workspace members appear on focus,
  free id/email on Enter, one-click Unassign); double-click the title to rename
  in place (Enter saves, Esc cancels — a single click still opens the card).
• Bulk actions: select cards with their checkboxes — a floating bar offers
  status / priority / sprint / assignee / label / delete over the selection.
• Epic progress: epic cards carry a progress bar (done / total children).
• Closing an epic: finish its child issues first. A status change to a
  terminal state is refused while any child remains open, including bulk moves.
• Column collapse: the chevron in a column header collapses it into a
  narrow strip (remembered per project); click the strip to expand.
• WIP limits: click a column counter to set a soft limit — the counter
  turns red when exceeded.
• Keyboard: cards are focusable — ↑/↓ move within a column, ←/→ jump
  across columns, Enter opens the issue, Space toggles selection. c creates
  an issue, / focuses search.
• Group by: swimlanes by assignee or status.

Roadmap, timeline and calendar

Beyond the board, list and backlog, three planning views:

• Roadmap — one row per epic with a progress bar and a readable summary:
  done/total child issues with a percentage, and the schedule. An epic without
  its own dates inherits the span of its children (earliest planned start →
  latest due date), so scheduling the work items is enough to get a bar; the
  epic’s own dates always win when set. Issues count as children of an epic
  when their parent is set to it.
• Timeline — a Gantt of issues with dates. Zoom with the toolbar buttons
  or Ctrl + mouse wheel (anchored on the cursor); when zoomed in, the
  chart scrolls horizontally, issue names stay pinned on the left, and you can
  pan by dragging any empty area. Axis labels adapt from years down to single
  days. Drag a bar to reschedule; drag its edge to change just the start or
  due date.
• Calendar — a month grid; issues land on their due date. Weekends are
  shaded; hover any day and click the toggle in its corner to mark a team
  day off (or make a weekend a working day) — the setting is shared by the
  whole project team, and the header shows the month’s working-day count for
  capacity planning. Click a day to create an issue due that day.

Backlog and search

The Backlog view is a flat list of the same issues. The search box supports
plain text and MQL (Mockarty Query Language) — a JQL-style query bar with
autocomplete over fields, operators and values.

Sprints

Create sprints, drag issues in, then Start and later Complete them from
the board header (incomplete issues offer a carry-over dialog). Story points
live on the issue; the Forecast button on an active sprint analyses
committed vs completed points, days left, blockers and unassigned/unestimated
issues, and answers “are we on track?” with a recommendation.

Only one sprint in a project can be active at a time. Complete or cancel the
current sprint before starting another; a conflicting start returns an error.

Starting or completing a sprint also fires the Sprint started / Sprint
completed automation triggers. Both evaluate your rule for every issue in
the sprint — rule actions (assign, change status, comment, notify…) all act on
an issue, so there is nothing a single sprint-wide firing could do. Typical
rules: comment on everything that shipped when the sprint completes, or assign
the still-unassigned when it starts. Completing a sprint reports how many issues
were queued for rule evaluation; execution follows asynchronously and a failed
evaluation may be retried.

The issue

Click any card to open the issue: rich-text description with attachments and
inline images, comments with @-mentions, activity trail, work log with a
timer, labels, components, fix/affects versions, due date, watchers and votes.

The issue opens in a calm read view — no input chrome, just the content.
Click the pencil in the top bar, or simply click into any field, to start
editing; Save stays disabled until something actually changed. Live
widgets (comments, checklist, roles, work log, sprint) apply immediately and
never require Save.

Descriptions are shown as formatted Markdown in read view. Click the
description or its pencil to open the source editor; long descriptions scroll
inside the editor on desktop and mobile. Done returns to formatted preview
without saving, while the top-bar preview toggle also closes the source editor.
Use Save when you want to persist the change.

• Assign to me: one click next to the Assignee field fills it with you;
  press Save to apply. The picker still searches people and agents by name.
• Roles: assign a developer, tester and analyst (plus any custom project
  roles) from one compact row — pick the role on the left, search the person
  on the right, press ＋.
• Relations: link issues (blocks / blocked by / relates to / duplicates),
  set a parent, add sub-tasks inline. The Graph button renders an
  interactive dependency graph — blocker edges are red; tap a node to highlight
  the transitive upstream blocker chain (everything that must finish first),
  double-tap to open that issue.
• Quick transitions: one-click buttons for every status the workflow
  allows from the current one.
• Move / Clone / Mirror: move an issue to another project, clone it (with
  sub-tasks), or mirror it to an external tracker (see
  External trackers).

Auto-filing from testing (intake)

The tracker can file issues automatically from platform findings: security
scans, failed test runs and test plans, perf regressions, chaos results and
contract drift. Configure per-namespace intake rules (source, minimum
severity, target glob, target project, priority mapping, labels). Recurring
findings dedup onto the existing issue — it is re-opened and gets an
occurrence comment instead of a duplicate.

SCM integration

A public webhook accepts GitHub / GitLab pushes, pull/merge requests and
pipeline events: commits and branches named after an issue key link
themselves to the issue, a fix-verb in a commit message closes it, and the
latest pipeline status shows on the ticket. Each link renders on the issue as
a row with the provider icon, the short commit SHA or MR number, the branch,
the commit subject / MR title and a live status badge (opened / merged /
closed for MRs, success / failed / running for pipelines) — hover a row for
the full details. Merge requests never close an issue automatically — one
issue often spans several MRs; when a linked MR gets merged its badge simply
flips to merged.

Analytics

Per project: burndown, velocity, cumulative flow (CFD), delivery
metrics (lead / cycle time, weekly throughput), a roadmap of epics with
child rollups, and a team view (per-person open/in-progress/done, points
and average cycle time). Tracker metrics are also available as widget-dashboard
sources. Secured (private-epic) issues are excluded from all aggregates for
non-members.

Portfolios combine progress from selected projects, including projects in
another namespace when its owner has granted portfolio access. The grant does
not open private projects or issues: their membership rules still apply. A
failed read does not return a partial rollup.

API

Base: /api/v1/namespaces/{namespace}/issuetracker. Highlights:

An issue is created with a type word — "type": "bug" (also story, task, epic,
subtask) — and every read gives that same word back in type, so you never have to
look up an identifier to find out what an issue is. A project-specific custom type has
no such word: there typeId is the answer.

AI agents

The tracker is fully drivable by AI agents — the same operations a person does on
the board are exposed as issuetracker_* MCP tools, and the built-in task_tracker
chat persona routes a natural-language request to the right one. An agent can run
the whole development loop on a task:

1. Pull work — issuetracker_issues_next returns the next unblocked issue
   assigned to the agent.
2. Orient — issuetracker_issues_get + issuetracker_issues_comments (the
   discussion thread) + issuetracker_issues_activity (status/assignee history) so
   it acts on what was already decided, not a guess.
3. Work + report — move it forward with issuetracker_issues_move (the workflow
   is enforced; an illegal transition or a close without the required resolution is
   rejected with the valid values listed), record what it did with
   issuetracker_issues_comment, and log time with issuetracker_worklog_log.

Managing the backlog and sprints is equally agent-reachable: decompose an epic
(issuetracker_issues_batch_create), manage dependencies
(issuetracker_issues_link / _relations / _remove_relation), plan and run a
sprint (issuetracker_sprints_create, _sprint_set_status to start it,
_sprint_complete to close it with carry-over), and read analytics
(_project_velocity, _sprint_burndown, _sprint_forecast). Findings from
security/test/perf/chaos/contract runs auto-file as issues via intake rules
(issuetracker_intake_rules_set), so the board keeps itself up to date with no
human in the loop.