🧑‍💻 chore(logging): say which field failed to decode, not just that one did

[hub2rock]

Twice now a PLANKA schema drift has arrived as "couldn't read the server's response" — once for the terms payload, once on the projects screen — and both times finding the culprit meant querying the API by hand and diffing payloads against the models.

That guesswork was never necessary. DecodingError knows exactly which key failed and where; it was being thrown away, because localizedDescription on it is always the same sentence regardless of the cause.

Change

Both decode sites now log the diagnosis alongside the type and path:

missing key 'role' at included.users[3]
expected Bool at included.users[0].isDeactivated
null where non-optional String expected at included.users[0].role
corrupted value at items[2].createdAt: Date string does not match format

The generic copy stays on screen — this is for the log, where BoardlyLog.tag(.network) already reports decode failures.

Privacy

Only the shape is reported: coding path, expected type, reason. No decoded value is included, so nothing a user typed can reach the log through this. (dataCorrupted carries the decoder's own debugDescription, which describes a format problem — a malformed date, say — not user content.)

Tests

181 passing, 5 new, covering each DecodingError kind, a failure at the root object, and non-decoding errors keeping their own description.

Context

The projects-screen decode failure that prompted this is not fixed here — it is still unidentified, because the models match planka-openapi.json exactly, so the drift is between the spec and the live server. This is what makes the next report diagnosable from a log line instead of a round of API archaeology.

🤖 Generated with Claude Code