Delivery-Spur
Eine geordnete Chronik, wie ein Ticket tatsächlich geliefert wurde -- Claims, Meldungen, Kommentare, Statuswechsel, Branch, PR, Pipelines und gebuchte Zeit.
Die Delivery-Spur beantwortet in einer geordneten Liste: Wie wurde dieses Ticket fertig, und wer hat was getan? Sie aggregiert Datensätze, die andere Module ohnehin führen — sie speichert nichts Eigenes und ändert nichts.
Spur abrufen
GET /api/v1/boards/{boardId}/tickets/{ticketId}/delivery-traceErfordert die Berechtigung tickets:view und Zugriff auf das Board. Akzeptiert das Access-Token eines Agenten, damit ein Loop die Vorgeschichte lesen kann, bevor er anfängt.
Kunden können sie nicht lesen — 403, über die Rolle, nicht durch Ausdünnen der Antwort. Die Spur ist Engineering-Prozess (welche Maschine das Ticket hielt, wie lange ihr Claim lief, wie viele Minuten noch Entwürfe sind); Kunden sehen Zeiten über die bewusst gröbere Kundenübersicht.
Beispiel-Antwort
{
"ticketId": "tkt_abc123",
"displayId": "WEB-42",
"branch": "feature/web-42-login-styling",
"items": [
{
"at": "2026-09-05T08:00:00Z",
"kind": "claimed",
"label": "Claimed for 30 minutes via claude-code",
"actor": {
"id": "usr_agent123",
"name": "Nightly Refactor",
"isAgent": true,
"clientName": "claude-code"
},
"ref": null,
"refType": null
},
{
"at": "2026-09-05T08:26:00Z",
"kind": "reported",
"label": "Reported needs_review",
"actor": { "id": "usr_agent123", "name": "Nightly Refactor", "isAgent": true, "clientName": "claude-code" },
"ref": "https://github.com/acme/web/pull/312",
"refType": "url"
}
],
"gaps": ["coding_tool_handoff"]
}Felder
| Feld | Typ | Beschreibung |
|---|---|---|
| ticketId | string | Das Ticket |
| displayId | string | null | Sprechender Schlüssel, z. B. WEB-42 |
| branch | string | null | Quell-Branch des verknüpften Pull Requests, falls vorhanden |
| items | object[] | Aufsteigend nach at |
| gaps | string[] | Quellen, die in dieser Spur nicht abgebildet sind, damit man „ist nicht passiert" von „ist nicht aufgezeichnet" unterscheiden kann |
Eintrag
| Feld | Typ | Beschreibung |
|---|---|---|
| at | string | ISO-8601-Zeitstempel |
| kind | string | Siehe Liste unten. Unbekannte Arten einfach als „Label anzeigen" behandeln — die Liste wächst |
| label | string | Kurzes, fertig formuliertes englisches Label. Maschinenausgabe, nicht übersetzt |
| actor.id | string | null | Spedy-User-ID; null bei Akteuren, die nur namentlich bekannt sind (ein Git-Autor, das System) |
| actor.name | string | Anzeigename, oder System, wenn niemand gehandelt hat |
| actor.isAgent | boolean | Ob der Akteur ein Agenten-User ist |
| actor.clientName | string | null | MCP-Client, über den die Aktion kam, z. B. claude-code. null für die Weboberfläche |
| ref | string | null | Worauf der Eintrag zeigt: absolute URL, Ticket-Schlüssel, Branch-Name, Status-Name |
| refType | "url" | "key" | null | Wie ref zu behandeln ist |
Arten
claimed · heartbeat · claim_released · claim_expired · reported · first_agent_comment · first_human_comment · status_changed · branch · pr_opened · pr_review · pr_merged · pipeline · time_entry
Zeiteinträge erscheinen inklusive Entwürfen und sind als solche markiert. Claims tragen den Client, über den sie genommen wurden — deshalb kann eine Claim-Zeile „über claude-code" lauten, statt nur den Akteur zu nennen.
Lücken
gaps ist der ehrliche Teil. Eine Spur, die eine nicht aufgezeichnete Quelle einfach weglässt, sähe genauso aus wie eine Spur, in der nichts passiert ist — und würde beim nächsten hinzugefügten Datensatz still zu lecken beginnen. Alles, was Spedy gar nicht aufzeichnet, steht deshalb hier; heute immer coding_tool_handoff.
Im Produkt
Dieselbe Chronik ist der aufklappbare Abschnitt Delivery-Spur im Aktivitäts-Tab eines Tickets, und dieselben Daten speisen die Agenten-Übersicht. Über MCP liest ein Loop sie mit dem Tool tickets_delivery_trace.