Saltar a contenido

ADR-018: Build Tasklist completo

  • Status: Accepted
  • Date: 2026-05-14
  • Tags: webapps, tasklist, build-vs-buy

Context and Problem Statement

Tasklist es el UI donde users humanos hacen claim/complete de user tasks. ¿Build completo, replicar enfoque de ADR-010 (hybrid), o reusar herramienta externa?

Decision Drivers

  • User tasks son core feature de Camunda value prop
  • NO existe equivalent APM o tool externo para human tasks
  • Business users esperan UI tipo Tasklist
  • Forms rendering requires custom logic
  • End users no usan CLI

Considered Options

  1. Build Tasklist completo (~8K LOC)
  2. Skip, expose only REST API (users construyen su UI)
  3. Build minimal stub (search + complete básico)
  4. Reusar Camunda Tasklist (auth integration complex)

Decision Outcome

Chosen option: Build Tasklist completo porque: - User tasks son irreemplazables (no hay equivalent SaaS) - End users (business) require UI usable - Forms rendering requires custom integration - ROI es claro (sin esto, no hay producto)

Positive Consequences

  • Core feature funcional
  • End user experience optimizada
  • Forms con JSON Schema integradas
  • Real-time updates posibles
  • Mobile-friendly responsive

Negative Consequences

  • ~8K LOC inicial
  • Maintenance burden ongoing
  • UI design + UX investment

Por qué NO hybrid (vs ADR-010)

Operate puede ser hybrid porque APM tools existen. Tasklist NO porque:

Feature Equivalente externo?
List "my tasks" assigned NO
Claim atomic NO (requires engine write)
Complete con form NO
JSON Schema form rendering NO en monitoring tools
Real-time notifications NO en monitoring tools
Mobile-friendly NO en monitoring tools

APM/CLI no son alternativas para human task workflow.

Scope detallado

Ver analysis/operate-tasklist-mvp-detailed para spec completo. Resumen:

Sprint 1 — Mis tasks + claim

  • Lista "Mis tasks" (assigned to me)
  • Lista "Available" (puedo claim)
  • Filtros básicos
  • Claim atomic

Sprint 2 — Complete con forms

  • Detalle de task + variables
  • JSON Schema form rendering (rjsf)
  • Complete con result variables
  • Server-side validation (AJV)

Sprint 3 — Search + sort + delegation

  • Search en variables (FTS)
  • Sort por priority/dueDate/created
  • Reassign task (admin)
  • Audit log

Tasklist + Operate Inspector como mismo SPA

Considerar bundle Operate Inspector + Tasklist como single SPA:

mvp-webapp/
├── /tasklist/...    (end users)
├── /inspector/...   (operators)
└── /admin/...       (admins, Identity UI)

Shared: - Auth flow - API client - UI primitives (buttons, modals, tables) - WebSocket/SSE connection

Single React app, route-based feature split. Reduces total to ~12K LOC (vs 18K si separados).

Stack

  • React + Tailwind CSS
  • TanStack Query (data fetching + cache)
  • react-jsonschema-form (forms)
  • react-router (routing)
  • ~vite o Next.js (build)

Mobile considerations

Tasklist usado en mobile más que Operate. Design responsive desde día 1:

  • Mobile-first CSS
  • Touch-friendly buttons (44x44 min)
  • Simplified navigation
  • PWA opcional