Aufgaben und Status

/aufgaben provides list and Kanban views over shared and private task boards. The status configuration is workspace-global: every task board uses the same ordered set of columns.

Work in the list

The web list is a dedicated scroll region with a sticky header. Select a column header to sort by task, client, assignee, priority, due date, or status; select the active header again to reverse the order. Assignee, priority, due date, and status can be changed directly in the row. Compact list and Kanban surfaces show priority as a single traffic-light flag: green for low, orange for medium, and red for high or urgent. The list intentionally omits automation metadata and uses only compact delegate and delete actions.

Selecting a task row opens its full detail page. The detail metadata shows both the current assignee and the task creator; the creator is immutable and uses the creator's current profile display name or email. The current board, filters, search, list order, and List/Kanban mode are carried into the detail route, so the back action returns to the exact Aufgaben view that opened the task. Kanban cards use the same full-detail navigation.

The web detail page uses a ticket-style two-column layout: the left column holds the title, description, source, attachments, and the comment thread (composer on top, newest comments first); the right sidebar holds a status quick-select, a Details panel (assignee, creator, priority, due date, board, contact, tags), and collapsible More fields (CRM and follow-up fields) and Completion and deal panels, followed by the created/updated timestamps. Status, assignee, and priority save immediately through PATCH /api/aufgaben/{id} with only the changed field; attachments can be added at any time via the button or drag and drop. The remaining fields still use the pencil edit mode. The layout switches on the width of the content pane (container query at 880px), so the sidebar stacks below the content when the chat panel narrows the page.

The Apple clients use the same compact information hierarchy in their task list: title first, followed by assignee, the color-coded priority flag, due date, and status. Native task details show the immutable creator directly after the assignee in both read and edit modes. iPhone and iPad continue to push a dedicated native detail screen, while macOS keeps its native split-detail behavior. When the detail screen is at least 820pt wide (macOS, iPad landscape), it mirrors the web layout with the content on the left and the Details card as a fixed-width sidebar on the right; narrower screens keep the single-column order.

Configure the board

Use the circular Configure board action beside the List/Kanban switch to:

• rename any status without changing its stable key;
• add a status with category open, in_progress, waiting, or done;
• reorder columns for every board;
• delete a non-system status after selecting another status for all affected tasks and scheduled tasks.

The system keys offen, in_bearbeitung, and erledigt can be renamed and reordered. They cannot be deleted, and their categories remain locked to open, in_progress, and done. Custom labels are shown verbatim in every UI language. A built-in status whose label is unset uses the localized German, English, or Italian label.

Category semantics, rather than a particular label, drive behavior. Every status outside category done counts as unfinished; overdue views, Mandant summaries, and agent tools follow that rule. The dashboard's Open tasks KPI is intentionally narrower: it counts the first configured open status across all boards, says so below the value, and opens the Aufgaben view with that same all-board/status scope. The urgent, overdue, and upcoming-task dashboard widgets also open the all-board unfinished view that supplies their data. New tasks use the first ordered open status. The literal optional key wiedervorlage continues to enable its follow-up-date workflow only while that key exists.

Agents discover the current configuration with aufgaben_list_statuses and manage it with aufgaben_manage_statuses. Task tools accept configured keys and return the current valid-key list for invalid input.

Web owns status configuration editing in this release. Apple clients render configured statuses but do not edit the workspace-global configuration yet.

Microsoft To Do / Outlook sync

Tasks from Microsoft To Do (the task lists behind Outlook) can be mirrored into Clapilot boards through the Microsoft 365 connection under Settings -> App Verbindungen:

1. Enable Aufgaben (To Do) on the Microsoft 365 card. Connections created before this feature must use Reconnect once so Microsoft grants the Tasks.Read permission; mail, calendar, contacts, and files keep working meanwhile.
2. Open Details and choose, for each To Do list, the Clapilot board it is mirrored into (or Do not sync). Saving the mapping runs a sync right away.
3. Use Sync tasks on the card whenever you want to pull the latest Outlook changes.

The first sync imports every task of a mapped list; later syncs use the Microsoft Graph delta query and only transfer changes. Mirrored tasks are ordinary Clapilot tasks with an Outlook origin badge (web) or the Microsoft To Do · <list> origin label (Apple clients).

Phase 1 is deliberately one-way (Outlook → Clapilot):

• Title, notes (HTML is converted to text), due date, importance (low/normal/high → niedrig/mittel/hoch), and status are mirrored. An active Outlook reminder is added as the last line of the description because Clapilot tasks have no reminder field.
• Status follows the board's status categories: notStarted → first open status, inProgress → in_progress, waitingOnOthers/deferred → waiting, completed → done. A local status in the same category (for example a custom column) is kept until Outlook reports a real transition.
• When an Outlook task changes, Outlook wins for the mirrored fields. Board, assignee, comments, attachments, and client links you set in Clapilot are never touched.
• A task deleted in Outlook is not deleted in Clapilot: it stays on its board as a normal local task, so no comments or attachments are lost.
• Each Outlook task is identified by its Graph id, so repeated syncs never create duplicates. Deleting a mirrored task in Clapilot does not delete it in Outlook; it is re-created only if it changes in Outlook again.
• Changes made in Clapilot are not written back to Outlook. Bidirectional sync, background/automatic sync, and Graph change notifications are planned follow-ups.

If one list fails (for example because it was deleted in To Do), its error is shown next to that list in the mapping and the other lists still sync. The one-off CSV import remains available for other task sources.

Agents do not get a separate Microsoft To Do tool in this phase: mirrored tasks are regular aufgaben rows, so the existing task tools already read and edit them, while starting the sync stays a user action on the connection card.

Duplicate protection for agent-created tasks

Tasks created by agents and automations (for example benchmark or Symphony follow-up tickets) are protected against accidental duplicates. A retried create is recognised by its idempotency key or, when none was given, by a still-open task with the same title on the same board created within the last 24 hours; in both cases the existing task is returned instead of a second one. Tool success is tied to the stored task id, so a failed reload after saving no longer looks like a failed create. Tasks entered manually in the app are not affected; the agent can pass allow_duplicate when a second task with the same title is really intended.

Comments and mentions

Task detail pages carry a comment thread with attachments. Typing @ in the comment composer opens a mention autocomplete listing the workspace agent first, followed by all workspace members; the list narrows as you type and inserts a handle the comments API can resolve (whitespace-stripped display name, or the email local part when no display name is set). The web composer supports arrow-key navigation, Enter/Tab to accept, and Escape to dismiss. The Apple clients show the same suggestions as a tappable list above the composer while an @token is being typed at the end of the draft.

Mentioning the agent (@<agent-handle>, or the generic @angela alias) triggers an asynchronous agent reply in the thread. The reply and the Delegate to agent action both run through the native ClapilotAICore runtime (clapilot-agent /internal/chat/completions); the legacy compat gateway is only used when the configured runtime provider is not native.

Boards per Agent löschen

Der Agent kann über aufgaben_delete_board leere Boards löschen. Bei „lösche die BM-Boards“ ermittelt er zuerst die passenden Board-IDs über aufgaben_list_boards und verwendet den gleichen Service wie die UI. Die konfigurierte Freigabe für Agenten-Löschaktionen gilt auch hier.

Enthält ein Board Aufgaben, wird die Löschung ohne ausdrücklich ausgewähltes move_tasks_to_board_id abgelehnt. Mit Zielboard werden alle Aufgaben erhalten und dorthin verschoben. Eine erzwungene Löschung der Aufgaben (force) ist nicht vorgesehen. Standard-Boards und aktive Boards selbstständiger Agenten sind geschützt. Private Boards sind nur für ihren Owner löschbar; geteilte Boards bleiben wie in der UI für authentifizierte Workspace-Nutzer bearbeitbar.

Löschung und Audit werden atomar gespeichert. Wiederholungen melden „bereits gelöscht“, ohne erneut zu löschen oder zu protokollieren. Im Skills-Mode: clapilot-cli aufgaben delete-board --board-id <uuid>, optional mit --move-tasks-to-board-id <ziel-uuid>; tasks bleibt als englischer Familienname unterstützt.

Status audit trail

Every task status change is recorded in aufgaben_status_events by a database trigger, so no writer can change a status without leaving a trace. Each event stores the previous and new status, the time, the actor type (user, agent, symphony, fleet, system, or unknown), actor ID/label, source, reason, evidence (for example the linked pull request), and the Postgres application_name of the writing process (clapilot-web, clapilot-agent, clapilot-symphony, clapilot-task-scheduler, clapilot-db-tool). Events are kept when the task is deleted: aufgabe_id has no cascading foreign key, and each event stores a snapshot of the task title (aufgabe_titel) at the time of the change.

Writers attribute themselves by setting the transaction-local clapilot.status_actor setting to a JSON object in the same statement as the update (or, for multi-statement transactions, on the same connection right before the update). Every authenticated status write records the signed-in user: the task API (PATCH /api/aufgaben/{id}), the Delegate to agent action (POST /api/aufgaben/{id}/delegate), and deleting a custom status with task reassignment (DELETE /api/aufgaben/statuses/{key}?reassign_to=...). The agent tools aufgaben_create_task, aufgaben_update_task, and aufgaben_move_status record the agent session and run, and Symphony records its job. Writers that do not set an actor still appear with actor type unknown and their application_name.

Creating a task also writes an event, because a task can be created directly in a target status (including a done status). Every creation event snapshots the creating user as evidence.task_created_by, and a creation whose writer set no actor — for example POST /api/aufgaben — is attributed to that user with source aufgaben.erstellt_von. The creator therefore stays visible even after the task row is deleted.

To find out who closed a task:

SELECT created_at, aufgabe_titel, from_status, to_status, actor_type, actor_id, source, reason, evidence, db_application_name
FROM aufgaben_status_events
WHERE aufgabe_id = '<task-id>'
ORDER BY created_at;