docs(tickets): switch import source to project-board sweep after live probe

docs/superpowers/specs/2026-10-01-ticket-import-all-design.md

@@ -35,20 +35,35 @@ und plant danach den Tag (bestehender FillMyDay-Lauf). Auslösbar per Button und
 
 ### 1. Datenquelle (`Worker/Tickets/`)
 
-`BandelTicketClient.GetAssignedItemsAsync(ct)`:
+**Sweep über alle Projekt-Boards** — nur Routen, die `BandelTicketClient` schon hat und die seit
-`GET /api/ticketsystem/pat/me` (userName) → `GET /api/ticketsystem/users/username/{u}` (userId) →
+2026-09-01 live verifiziert sind: `GET /api/Navigation/sidebar` (alle sichtbaren Projekte) →
-`GET /api/board/global/{userId}`. Filter wie bisher: `ticketAssignees[].assigneeName == userName`
+pro Projekt `GET /api/Board/project/{id}`. Filter, `statusId ∈ {1, 2}`:
-und `statusId ∈ {1, 2}`.
 
-> ⚠️ **Erster Implementierungsschritt: live verifizieren**, bevor ein DTO geschrieben wird —
+- Ticket (Board-Item): `ticketAssignees[].assigneeName == userName`
-> liefert das globale Board Tasks/Subtasks (itemType 2/3) samt `parentId`/Parent-Titel und
+- Task (`tasks[]` am Board-Item): **`ticketTaskAssignees[].assigneeName`** == userName —
-> Projekt? Feldweise über alle Datensätze prüfen, nicht an einem Sample (siehe Memory
+  unabhängig davon, wem das Parent-Ticket gehört (730/732 hängen an 728 von marcel.sievers).
-> `ticketsystem-integration`: `assigneeName` war im DTO vorhanden und live immer null).
-> Fallback, falls nicht: das Ticket-MCP `list_assigned_items` zeigt, dass die Daten existieren —
-> dessen Route in `Bandel.APIs`/TicketSystem-MCP nachschlagen.
 
-Ebenfalls live prüfen: `PATCH /api/ticket/{id}/status` für ein Item vom Typ Task (Write-back muss
+Projekt-Titel kommt aus der Sidebar, Parent aus dem umschließenden Board-Item.
-für Tasks/Subtasks funktionieren; laut Bandel.APIs-Breadcrumb dieselbe Tabelle).
+`TicketBoardItem` bekommt `Tasks` (`id`, `title`, `statusId`, `hasChildren`,
+`ticketTaskAssignees`).
+
+**Live-Befund 2026-10-01** (7 Projekte, ~1,2 s): exakt die 10 offenen Items, die das Ticket-MCP
+`list_assigned_items` liefert — 665, 593 (+595/596/598/668), 1014, 1016, 1017, 730, 732.
+Verworfen wurde `GET /api/board/global/{userId}`: liefert kein Projekt, braucht eine userId, die
+`/pat/me` nicht hergibt (`/users/username/{u}` = 401 mit PAT), und ist **nicht** auf den
+Token-Inhaber beschränkt (`global/22` lieferte 147 fremde Items).
+
+Subtasks (Ebene 3): live existiert keiner (`hasChildren` überall false). Board-Tasks mit
+`hasChildren = true` werden übersprungen.
+<!-- ponytail: keine Rekursion über GET /api/item/{id}/children — nachrüsten, sobald Subtasks real vorkommen -->
+
+**Offen, manuell zu prüfen:** `PATCH /api/Ticket/{id}/status` auf einem **Task** (nicht Ticket) —
+nicht live getestet, weil es ein Schreibzugriff aufs Firmensystem ist. Laut Bandel.APIs-Breadcrumb
+gleiche Tabelle, Statusrecht u.a. für Assignees. Scheitert es, loggt `TicketStatusSync` nur eine
+Warnung (wirft nie) → beim ersten echten Lauf im Worker-Log prüfen.
+
+Details pro Item für die Beschreibung: `GET /api/ticket/{id}` (live: liefert `description`,
+`parentTicketID`).
 
 ### 2. `TicketImportService`