Die Aufgaben-Schicht (tools/chemenu/tasks/protocol.py) kennt keine Aufwandsschätzung. Betreiberwunsch vom 2026-09-25, entstanden bei #139 (CalDAV-Provider): Schätzungen sollen übertragen werden, wo der Adapter es kann; wo nicht, gehen sie verloren.
Dieses Issue steht auf eigenen Beinen. Hintergrund: In #119 war die Schätzung mit Soll-Ist-Rückmeldung das Topkriterium der Werkzeugwahl für Super Productivity (SP). Die private Instanz stellt mit #139 auf CalDAV um und verliert diese Rückmeldung dort; die Umstellung nimmt das in Kauf.
Auslöser (prio/waiting)
Es gibt einen Konsumenten. Heute liest oder schreibt keine Stelle eine Schätzung: weder wikitool review noch task new noch task list. Ein Protokollfeld ohne Leser wäre Vorrat, und jedes Protokollfeld bindet jeden Adapter (#128 Regel 1). Denkbare Konsumenten:
task new --estimate <dauer> beim Ingest oder im Rückblick
eine Rückblick-Prüfung auf Posten ohne Schätzung
eine Tagesplanung, die Schätzungen gegen verfügbare Zeit summiert
Zu entscheiden, sobald der Auslöser eintritt
D1 – Welcher Konsument zuerst? Er bestimmt, ob das Feld nur geschrieben (create_item), nur gelesen (OpenItem) oder beides wird.
D2 – Was geschieht bei einem Provider ohne Schätzfeld? Der Betreiberwunsch lautet „geht verloren“. Das kollidiert mit einem Präzedenzfall: create_item legt einen Posten nie ohne den verlangten WAITING-Status an (#132), eine verlangte Eigenschaft wird also bisher nie still verworfen. Vorschlag: Der Posten wird angelegt, die Schätzung verworfen, und die Ausgabe sagt das ausdrücklich („Provider speichert keine Schätzung“, Exit 0). Weder Stille noch Exit 1. Dafür braucht jeder Adapter eine abfragbare Fähigkeit (z. B. supports_estimate), statt dass der Aufrufer den Provider kennt (#128 Regel 2).
D3 – Abbildung je Provider.
SP hat ein natives Schätzfeld, dessen Name und Bedeutung nach #135 an der SP-Dokumentation zu prüfen sind, nicht am Feldnamen.
CalDAV hat ESTIMATED-DURATION aus dem IETF-Draft zu VTODO-Erweiterungen oder alternativ eine X--Eigenschaft. iOS Erinnerungen erhält unbekannte Eigenschaften (verifiziert in #139); sichtbar wäre der Wert aber weder in iOS noch in Nextcloud Tasks.
Azure DevOps (#128) hat mehrere Kandidaten (Original Estimate, Remaining Work, Story Points), eine offene Frage aus #128.
Akzeptanzkriterien (vorläufig, bis D1–D3 entschieden sind)
Ein Adapter ohne Schätzfeld verwirft eine übergebene Schätzung nie still; die Ausgabe nennt den Verlust.
Ob ein Adapter Schätzungen trägt, ist abfragbar, ohne dass ein Aufrufer, ein Skill oder eine Instruction den Provider kennt; test_task_tracker_skills_name_no_provider bleibt grün.
Jeder vorhandene Adapter ist gegen Fixtures getestet: trägt ihn, oder meldet den Verlust.
tools/CONTRACT.md und INSTALL.md nennen das Feld und sein Verhalten je Provider; docs verify, instructions verify, pytest grün.
Abhängigkeiten
Keine blockierenden. Berührt #139 (CalDAV-Provider wird ohne Schätzung gebaut) und #128 (Azure DevOps, offene Frage zum Schätzfeld).
Die Aufgaben-Schicht (`tools/chemenu/tasks/protocol.py`) kennt keine Aufwandsschätzung. Betreiberwunsch vom 2026-09-25, entstanden bei #139 (CalDAV-Provider): **Schätzungen sollen übertragen werden, wo der Adapter es kann; wo nicht, gehen sie verloren.**
**Dieses Issue steht auf eigenen Beinen.** Hintergrund: In #119 war die Schätzung mit Soll-Ist-Rückmeldung das Topkriterium der Werkzeugwahl für Super Productivity (SP). Die private Instanz stellt mit #139 auf CalDAV um und verliert diese Rückmeldung dort; die Umstellung nimmt das in Kauf.
## Auslöser (`prio/waiting`)
**Es gibt einen Konsumenten.** Heute liest oder schreibt keine Stelle eine Schätzung: weder `wikitool review` noch `task new` noch `task list`. Ein Protokollfeld ohne Leser wäre Vorrat, und jedes Protokollfeld bindet jeden Adapter (#128 Regel 1). Denkbare Konsumenten:
- `task new --estimate <dauer>` beim Ingest oder im Rückblick
- eine Rückblick-Prüfung auf Posten ohne Schätzung
- eine Tagesplanung, die Schätzungen gegen verfügbare Zeit summiert
## Zu entscheiden, sobald der Auslöser eintritt
- [ ] **D1 – Welcher Konsument zuerst?** Er bestimmt, ob das Feld nur geschrieben (`create_item`), nur gelesen (`OpenItem`) oder beides wird.
- [ ] **D2 – Was geschieht bei einem Provider ohne Schätzfeld?** Der Betreiberwunsch lautet „geht verloren“. Das kollidiert mit einem Präzedenzfall: `create_item` legt einen Posten nie ohne den verlangten `WAITING`-Status an (#132), eine verlangte Eigenschaft wird also bisher nie still verworfen. Vorschlag: Der Posten wird angelegt, die Schätzung verworfen, und die Ausgabe sagt das ausdrücklich („Provider speichert keine Schätzung“, Exit 0). Weder Stille noch Exit 1. Dafür braucht jeder Adapter eine abfragbare Fähigkeit (z. B. `supports_estimate`), statt dass der Aufrufer den Provider kennt (#128 Regel 2).
- [ ] **D3 – Abbildung je Provider.**
- SP hat ein natives Schätzfeld, dessen Name und Bedeutung nach #135 an der SP-Dokumentation zu prüfen sind, nicht am Feldnamen.
- CalDAV hat `ESTIMATED-DURATION` aus dem IETF-Draft zu VTODO-Erweiterungen oder alternativ eine `X-`-Eigenschaft. iOS Erinnerungen erhält unbekannte Eigenschaften (verifiziert in #139); sichtbar wäre der Wert aber weder in iOS noch in Nextcloud Tasks.
- Azure DevOps (#128) hat mehrere Kandidaten (Original Estimate, Remaining Work, Story Points), eine offene Frage aus #128.
## Akzeptanzkriterien (vorläufig, bis D1–D3 entschieden sind)
- [ ] Ein Adapter ohne Schätzfeld verwirft eine übergebene Schätzung nie still; die Ausgabe nennt den Verlust.
- [ ] Ob ein Adapter Schätzungen trägt, ist abfragbar, ohne dass ein Aufrufer, ein Skill oder eine Instruction den Provider kennt; `test_task_tracker_skills_name_no_provider` bleibt grün.
- [ ] Jeder vorhandene Adapter ist gegen Fixtures getestet: trägt ihn, oder meldet den Verlust.
- [ ] `tools/CONTRACT.md` und `INSTALL.md` nennen das Feld und sein Verhalten je Provider; `docs verify`, `instructions verify`, `pytest` grün.
## Abhängigkeiten
Keine blockierenden. Berührt #139 (CalDAV-Provider wird ohne Schätzung gebaut) und #128 (Azure DevOps, offene Frage zum Schätzfeld).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Die Aufgaben-Schicht (
tools/chemenu/tasks/protocol.py) kennt keine Aufwandsschätzung. Betreiberwunsch vom 2026-09-25, entstanden bei #139 (CalDAV-Provider): Schätzungen sollen übertragen werden, wo der Adapter es kann; wo nicht, gehen sie verloren.Dieses Issue steht auf eigenen Beinen. Hintergrund: In #119 war die Schätzung mit Soll-Ist-Rückmeldung das Topkriterium der Werkzeugwahl für Super Productivity (SP). Die private Instanz stellt mit #139 auf CalDAV um und verliert diese Rückmeldung dort; die Umstellung nimmt das in Kauf.
Auslöser (
prio/waiting)Es gibt einen Konsumenten. Heute liest oder schreibt keine Stelle eine Schätzung: weder
wikitool reviewnochtask newnochtask list. Ein Protokollfeld ohne Leser wäre Vorrat, und jedes Protokollfeld bindet jeden Adapter (#128 Regel 1). Denkbare Konsumenten:task new --estimate <dauer>beim Ingest oder im RückblickZu entscheiden, sobald der Auslöser eintritt
create_item), nur gelesen (OpenItem) oder beides wird.create_itemlegt einen Posten nie ohne den verlangtenWAITING-Status an (#132), eine verlangte Eigenschaft wird also bisher nie still verworfen. Vorschlag: Der Posten wird angelegt, die Schätzung verworfen, und die Ausgabe sagt das ausdrücklich („Provider speichert keine Schätzung“, Exit 0). Weder Stille noch Exit 1. Dafür braucht jeder Adapter eine abfragbare Fähigkeit (z. B.supports_estimate), statt dass der Aufrufer den Provider kennt (#128 Regel 2).ESTIMATED-DURATIONaus dem IETF-Draft zu VTODO-Erweiterungen oder alternativ eineX--Eigenschaft. iOS Erinnerungen erhält unbekannte Eigenschaften (verifiziert in #139); sichtbar wäre der Wert aber weder in iOS noch in Nextcloud Tasks.Akzeptanzkriterien (vorläufig, bis D1–D3 entschieden sind)
test_task_tracker_skills_name_no_providerbleibt grün.tools/CONTRACT.mdundINSTALL.mdnennen das Feld und sein Verhalten je Provider;docs verify,instructions verify,pytestgrün.Abhängigkeiten
Keine blockierenden. Berührt #139 (CalDAV-Provider wird ohne Schätzung gebaut) und #128 (Azure DevOps, offene Frage zum Schätzfeld).