spike: return enums as camelCase strings consistently

オープン
  • 何か問題がありますか？
#428 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
csharp, openapi
領域
api, backend-api-design

調査の方向性

Start by tracing JsonSerializerOptionsProvider and the response DTOs and mappers named in the issue: JournalTodosController, ProjectsController, and TaskItemsController. Then inventory status and priority strings across the web, MCP server, plugin text, fixtures, database storage, and OpenAPI output. Deliver a short plan answering the six listed questions, recommending the order relative to #399, and naming follow-up issues; make no production code changes.

索引モデルが issue の本文から書いたものです。

説明

tech-debt

Related to #399 (moves Status and Priority into TaskFlow.Contracts). Found while auditing the CLAUDE.md rules for #400.

Problem

The API sends task status and priority in a different casing than it accepts and than its own OpenAPI document describes.

  • The JSON enum converter uses the camelCase naming policy (JsonSerializerOptionsProvider). Any field typed as the Status or Priority enum, such as request DTOs, is camelCase on the wire. The generated client types match: Status = 'draft' | 'todo' | 'completed' | 'blocked' | 'inProgress'.
  • Several response DTOs fill Status and Priority with enum.ToString() into a string field (JournalTodosController, ProjectsController, TaskItemsController, and the details payloads on log entries). The converter never runs for those, so responses are PascalCase: "status": "Completed" (confirmed against the live API).
  • Requests accept either casing, so nothing fails. The cost is code that bridges the two shapes:
    • the web has about 36 uses of normalizeStatus and REQUEST_STATUS and about 25 strict PascalCase comparisons, and src/lib/task-status.ts exists mainly to convert between them;
    • the generated client types responses as string, so the compiler cannot check status values in responses;
    • the MCP client matches "Blocked" and "Completed" with OrdinalIgnoreCase;
    • eight agent and skill files tell Claude to write PascalCase, which pushes new code toward the workaround.

Target

Return enums as camelCase strings everywhere, through the converter, with the response DTO fields typed as the enum. Then the wire format is consistent, the generated client has real unions for responses, and the casing bridge in the web and the MCP client can go.

PascalCase everywhere (dropping the naming policy) is the alternative if the spike finds a reason camelCase is wrong. Leaving it as it is stays on the table as the cost baseline.

What the spike answers

  1. Every place that produces or consumes a status or priority string: response DTOs, mappers, details payloads on log entries, the web, the MCP server and plugin text, ux-test fixtures, test fixtures. Give a count and a list.
  2. How the database stores the enums, and whether anything persisted depends on the casing (for example, log entry details already written with PascalCase).
  3. Rollout order and version skew: the web ships with the API, but the MCP plugin runs from a local install. Which consumers must tolerate both casings during the change, and for how long.
  4. How this fits with #399: should the enums move into TaskFlow.Contracts first, and should the MCP server adopt the enum (with the same converter) instead of strings? Adopting the enum would also make its comparisons case-insensitive by construction.
  5. OpenAPI: confirm the generated client output for responses after the change and list the diff it would produce.
  6. Whether the work splits into separate issues (API and contract, web cleanup, MCP cleanup) or is one change, and in what order.

Deliverable

A short plan on this issue: the answers above, a recommended order relative to #399, and the issues to open. No production code changes.

Out of scope

Changing any other field's casing, the property naming policy, or adding API versions.

主要言語
C#
スター
1
フォーク
0
平均マージ
2時間 2分
マージ済み PR（30日）
98

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

nevridge/TaskFlow のほかの issue

nevridge/TaskFlow の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。