From b4450c5f63be129cf6528316c16ed603cae186bd Mon Sep 17 00:00:00 2001 From: Deploymentcenter Bot Date: Mon, 31 Aug 2026 09:18:48 +0200 Subject: [PATCH] docs: Was ein Feature Request ist - und was die eigene Planung ist Der Unterschied war nirgends aufgeschrieben, und am type ist er auch nicht ablesbar: Der kennt nur bug und feature_request, also muss ein Roadmap-Vorhaben sich als Wunsch ausgeben. Unterschieden wird am Themenbereich. Ein feature_request ist ein Vorschlag an ein FREMDES Projekt - etwas, das dort gebaut werden muesste, damit die Zusammenarbeit besser wird. Das Beispiel steht jetzt in der Agent-Vorlage, weil es genau so vorgekommen ist: Ein Agent an IBKRTrader brauchte die Besitzerart seines Tokens, das Deploymentcenter gab sie nirgends heraus, also schlug er einen Endpunkt vor (#282 - inzwischen gebaut). ROADMAP_MIGRATION.md warnt zusaetzlich, dass Schritt 3 und 4 zusammengehoeren. Bei der ersten Uebernahme ist das gutgegangen - 217 von 229 Eintraegen haben ihren Themenbereich bekommen. Auffaellig wurde etwas anderes: Die Bugliste zeigte Roadmap-Eintraege mit an, und die zwoelf echten Vorschlaege lagen unter der Planung begraben. Co-Authored-By: Claude Opus 5 --- docs/AGENT_PROMPT_TEMPLATE.md | 21 +++++++++++++++++++++ docs/ROADMAP_MIGRATION.md | 19 +++++++++++++++++++ public/api/openapi.php | 2 +- public/docs/bugtracker.md | 2 +- public/docs/changelog.json | 6 ++++++ 5 files changed, 48 insertions(+), 2 deletions(-) diff --git a/docs/AGENT_PROMPT_TEMPLATE.md b/docs/AGENT_PROMPT_TEMPLATE.md index b66d6e7..307c5e2 100644 --- a/docs/AGENT_PROMPT_TEMPLATE.md +++ b/docs/AGENT_PROMPT_TEMPLATE.md @@ -194,6 +194,27 @@ dem nächsten Agenten das Parsen des Stacktrace. Schweregrade: `idea` (Gedanke für später), `wishlist` (Backlog), `low`, `medium`, `high`, `critical`. +### Was ein `feature_request` ist — und was nicht + +`type: "feature_request"` ist ein **Vorschlag an ein anderes Projekt**: Dir +fehlt bei der Arbeit etwas, das dort gebaut werden müsste, damit die +Zusammenarbeit besser wird. Beispiel: Du arbeitest an PolyTrader, brauchst zum +Einrichten die Besitzerart deines Tokens und stellst fest, dass das +Deployment Center sie nirgends herausgibt — also schlägst du unter +`deploymentcenter` einen Endpunkt dafür vor. + +**Nicht dafür gedacht ist die eigene Planung.** Was in der Roadmap deines +Projekts steht, ist kein Wunsch an jemanden, sondern dein Vorhaben. Es gehört +ebenfalls in den Tracker — aber als Roadmap-Eintrag, also mit einem +Themenbereich (`epic`), siehe [ROADMAP_MIGRATION.md](./ROADMAP_MIGRATION.md). +Die Bugliste zeigt Roadmap-Einträge ab Werk nicht mehr an; sie stehen im +Roadmap-Modul. + +> Der Unterschied ist heute nicht am `type` ablesbar — `type` kennt nur `bug` +> und `feature_request`, und ein Roadmap-Eintrag muss sich deshalb als Wunsch +> ausgeben. Unterschieden wird am Themenbereich. Dass das zu eng ist, ist als +> Item #285 gemeldet. + ### Laufzeitfehler automatisch melden Für den globalen Exception-Handler einer Anwendung gibt es einen schlankeren Eingang — Titel und Dringlichkeit leitet der Server ab: diff --git a/docs/ROADMAP_MIGRATION.md b/docs/ROADMAP_MIGRATION.md index d167794..e6aef3e 100644 --- a/docs/ROADMAP_MIGRATION.md +++ b/docs/ROADMAP_MIGRATION.md @@ -126,6 +126,25 @@ angepasst. Jedes Vorhaben wird ein Item. Mit MCP-Adapter: +> ⚠️ **`type: "feature_request"` ist hier ein Behelf, keine Aussage.** `type` +> kennt nur `bug` und `feature_request` — ein Vorhaben muss sich deshalb als +> Wunsch ausgeben, obwohl es die eigene Planung ist und kein Vorschlag an +> jemanden. Entscheidend ist Schritt 4: **Erst der Themenbereich macht das Item +> zum Roadmap-Eintrag**, und erst dann verschwindet es aus der Bugliste und +> erscheint im Roadmap-Modul. +> +> Wer die Übernahme nach Schritt 3 abbricht, hinterlässt Dutzende +> vermeintlicher Feature Requests im Eingang des Projekts — **Schritt 3 und 4 +> gehören zusammen.** +> +> Bei der ersten Übernahme (August 2026, vier Projekte) ist das gutgegangen: +> 217 von 229 Einträgen haben ihren Themenbereich bekommen. Auffällig wurde +> trotzdem etwas anderes — die Bugliste zeigte Roadmap-Einträge damals noch +> mit an, und die zwölf echten Vorschläge lagen unter der Planung begraben. +> Seit 2.7.1 blendet die Bugliste sie ab Werk aus. +> +> Dass der `type` zu eng ist, ist als Item #285 gemeldet. + ``` dc_report(title: "Symbol-Upload und dc_symbolicate", type: "feature_request", diff --git a/public/api/openapi.php b/public/api/openapi.php index 6788e39..c65cc23 100644 --- a/public/api/openapi.php +++ b/public/api/openapi.php @@ -73,7 +73,7 @@ $spec = [ 'properties' => [ 'id' => ['type' => 'integer'], 'project_slug' => ['type' => 'string'], - 'type' => ['type' => 'string', 'enum' => BugRepo::TYPES], + 'type' => ['type' => 'string', 'enum' => BugRepo::TYPES, 'description' => 'feature_request ist ein Vorschlag an ein FREMDES Projekt - etwas, das dort gebaut werden muesste, damit die Zusammenarbeit besser wird. Die eigene Planung gehoert nicht hierher: Sie wird zum Roadmap-Eintrag, sobald das Item einen Themenbereich (epic) hat, und erscheint dann im Roadmap-Modul statt in der Bugliste.'], 'title' => ['type' => 'string'], 'description' => ['type' => 'string', 'nullable' => true], 'error_message' => ['type' => 'string', 'nullable' => true], diff --git a/public/docs/bugtracker.md b/public/docs/bugtracker.md index 2abe74b..8fe349d 100644 --- a/public/docs/bugtracker.md +++ b/public/docs/bugtracker.md @@ -165,7 +165,7 @@ curl -X POST https://dc.mhdf.de/api/bugtracker/v1/report \ |---|---|---| | `title` | ja | Kurze Beschreibung, max. 255 Zeichen | | `project_slug` | empfohlen | Aus der Projektliste; Vorgabe `default` | -| `type` | nein | `bug` (Vorgabe) oder `feature_request` | +| `type` | nein | `bug` (Vorgabe) oder `feature_request`. Ein Feature Request ist ein **Vorschlag an ein anderes Projekt** — nicht die eigene Planung; die gehört als Roadmap-Eintrag in den Tracker, also mit Themenbereich | | `severity` | nein | `idea`, `wishlist`, `low`, `medium` (Vorgabe), `high`, `critical` | | `environment` | nein | `production` (Vorgabe), `development`, `staging`, `testing` | | `client_ref` | empfohlen | Idempotenz-Schlüssel, alternativ Header `Idempotency-Key` | diff --git a/public/docs/changelog.json b/public/docs/changelog.json index ea17b9e..889cdfe 100644 --- a/public/docs/changelog.json +++ b/public/docs/changelog.json @@ -80,6 +80,12 @@ "breaking": false, "title": "Roadmap-Eintraege stehen nicht mehr in der Bugliste", "text": "Seit 2.7.0 IST ein Roadmap-Eintrag ein bugtracker_item - richtig so, es gibt keine zweite Ablage. Nur landet damit die gesamte Planung aller Projekte in derselben Liste wie die Meldungen: Nach der Uebernahme der Projekt-Roadmaps waren 217 von 229 Feature Requests Roadmap-Eintraege, und die zwoelf Vorschlaege, um die es in dieser Liste geht, lagen darunter begraben. Die Bugliste zeigt jetzt ab Werk nur, was NICHT auf der Roadmap steht (Kennzeichen ist unveraendert der Themenbereich). Sichtbar bleibt beides, nur an getrennten Orten; der neue Filter holt die Planung jederzeit wieder herein, und die Suche weist auf verdeckte Treffer hin." + }, + { + "area": "docs", + "breaking": false, + "title": "Was ein Feature Request ist - und was nicht", + "text": "Ein feature_request ist ein Vorschlag an ein FREMDES Projekt: etwas, das dort gebaut werden muesste, damit die Zusammenarbeit besser wird. Die eigene Planung ist es nicht - die gehoert als Roadmap-Eintrag in den Tracker, also mit Themenbereich. Der Unterschied war nirgends aufgeschrieben und ist am type auch nicht ablesbar, weil der nur bug und feature_request kennt; unterschieden wird am Themenbereich. Steht jetzt in der Agent-Vorlage, im Agenten-Handbuch und in der OpenAPI-Beschreibung. ROADMAP_MIGRATION.md warnt zusaetzlich, dass Schritt 3 und 4 zusammengehoeren: Wer nach dem Anlegen abbricht, hinterlaesst Dutzende vermeintlicher Feature Requests im Eingang des Projekts." } ] },