spike: return enums as camelCase strings consistently

Đang mở
  • Có gì không ổn?
#428 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, openapi
Lĩnh vực
api, backend-api-design

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C#
Star
1
Fork
0
Merge trung bình
2 giờ 2 phút
Pull request đã merge (30 ngày)
98

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của nevridge/TaskFlow

Tất cả issue của nevridge/TaskFlow

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.