pdd sync normalizes API field names, breaking calls to backends with mixed conventions

[Serhan-Asad]

Bug

When pdd sync regenerates code from a prompt, it normalizes API request field names to a single convention (e.g., all event_id snake_case), even when the backend endpoints use mixed conventions that must be matched exactly.

Reproduction

Our backend has inconsistent field naming across endpoints (this is a separate issue, see #181):

Endpoint	Expected field	Convention
hackathonEvent	event_id	snake_case
hackathonTeam	event_id	snake_case
hackathonSubmission (list)	eventId	camelCase
hackathonSubmission (vote)	eventId, submissionId	camelCase

Our manually written api.ts correctly used the right field name for each endpoint. When we ran pdd update to capture this as a prompt, then pdd sync to regenerate, the sync output normalized all field names to event_id/submission_id, breaking the submission endpoints.

Diff showing the bug:

# Our working code (correct):
- const data = await callFunction('hackathonSubmission', { action: 'list', eventId }, token);
+ const data = await callFunction('hackathonSubmission', { action: 'list', event_id: eventId }, token);

# Sync changed eventId → event_id, but the backend expects eventId

The prompt specified the correct contracts:

fetchAllSubmissions(eventId, token?) — lists all submissions for the event, returns data.submissions ?? []

But the LLM generating code from the prompt normalized the field names for consistency, not realizing they must be exact.

Impact

• API calls silently fail or return empty results because the backend doesn't recognize the wrong field name
• This is hard to catch without integration testing — the generated code compiles fine

Expected Behavior

pdd sync should preserve exact field names from the prompt. If the prompt specifies { action: 'list', eventId }, the generated code should use eventId, not event_id.

Suggested Fix

1. The prompt format could support explicit API contract blocks (like OpenAPI-style schemas) that the LLM is instructed not to normalize
2. Or pdd sync could diff against the existing code and flag field name changes as potential regressions
3. Or the pdd update step could capture exact API call signatures as constraints in the prompt

Related

• PDD generates inconsistent field naming across modules (snake_case vs camelCase) #181 — Backend generates inconsistent field naming (root cause)
• This issue is about sync not preserving the correct field names during regeneration