spike: return enums as camelCase strings consistently

Abierto
  • ¿Algo no está bien?
#428 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp, openapi
Área
api, backend-api-design

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
1
Forks
0
Merge medio
2 h 2 min
PR fusionados (30 d)
98

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nevridge/TaskFlow

Todos los issues de nevridge/TaskFlow

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.