archetech / archon / 32646167150

95%

push

github

fix(dmail): Make cc optional, and name the field that was wrong (#932)

* fix(dmail): Make cc optional, and name the field that was wrong

Closes #424.

`keymaster create-dmail msg.json` failed with "Invalid parameter: list"
whenever the JSON omitted cc: verifyDmail passed message.cc straight to
verifyRecipientList, which rejects undefined. Reproduced before fixing --
omitted cc threw, `cc: []` worked.

The one-line default in the issue treats the symptom. The cause is that
DmailMessage declared `cc: string[]` required, which is why no TypeScript
caller ever saw this and every JSON file, REST body and Python caller did.
cc is now optional on the input type, which is what the wire format has
always allowed. Making it honest surfaced five call sites that assumed
presence, one of them in Herald. verifyDmail returns
`DmailMessage & { cc: string[] }` so everything downstream of normalisation
stays clean rather than needing `?? []` scattered through it; DmailItem.cc
stays required, because a stored dmail has been normalised.

The error also named the wrong thing. "Invalid parameter: list" is the name
of verifyRecipientList's own argument, so a caller could not tell which
field was at fault -- and omitting the genuinely required `to` reported the
same string. verifyRecipientList now takes the field name, and reports
dmail.to or dmail.cc.

Python had the identical bug, same message, at core.py:2984. Fixed the same
way, which the parity contract requires anyway.

Removed the workaround in the MCP schema. It defaulted cc purely to dodge
this, with a comment saying so -- one consumer immunised while the CLI and
REST still crashed. It is now `.optional()`, matching the type, and the test
that encoded the workaround asserts the real contract instead.

2265 JS tests, 187 Python, typecheck 0, lint clean. Mutation-tested:
reverting the default in either language fails the new regression tests.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* fix... (continued)

3854 of 4341 branches covered (88.78%)

Branch coverage included in aggregate %.

5 of 5 new or added lines in 2 files covered. (100.0%)

8484 of 8794 relevant lines covered (96.47%)

690.73 hits per line