The API adds a date to a deal, like the page and MCP do, and /openapi.json lists the common labels (HOA documents review, survey, repair request deadline…) on its body #154

For: #131 (470de53) gave the page's Add a date and the MCP add_date tool the dates contracts usually add, from SUGGESTED_DATES in src/deadlines.ts. Its last box asked for the same on the API's add-a-date body in /openapi.json, but the API has no add-a-date route. contract/openapi.json lists PATCH and DELETE on /api/deals/{id}/deadlines/{deadline}, but no POST to add one. An agent scripting against the API cannot add the HOA review the page offers.

Done looks like:

• [x] POST /api/deals/{id}/deadlines with label, due (YYYY-MM-DD), owes (a party role) and an optional lead_days adds a date. It answers 201 with the date, or 400/422 naming the field, with the same rules as the page and add_date: label required, up to 100 characters; an exactly matching suggested label sets its reminder lead unless lead_days is given. It is the deal update cell through permit, with nothing loosened in contract.json, and same-origin rules as the other API mutations.
• [x] The route declares api, so contract/openapi.json is regenerated (bun run contract:emit). The body's label description names every label in SUGGESTED_DATES, built from that list rather than retyped, so adding a suggestion updates the page, MCP and the API together. src/openapi.test.ts passes.
• [x] Tests: a suggested label gets its lead, a custom label gets the default, an empty or 101-character label is refused, a signed-out caller is refused, and the openapi body lists a suggestion.
• [x] The page, MCP and API share one add-a-date action rather than three copies of the checks.

Files: src/routes.ts, src/openapi.ts (if the description needs the list), contract/openapi.json, a test; possibly src/actions.ts or the module behind add_date. Risk: keep validation identical across the three doors; reuse the existing action. Suggested: mason.

Reviewed pull #167 at its head: ticked POST /api/deals/{id}/deadlines with label, due (YYYY-MM-DD), owes (a party role) and an optional lead_days adds a date. It answers 201 with the date, or 400/422 naming the field, with the same rules as the page and add_date: label required, up to 100 characters; an exactly matching suggested label sets its reminder lead unless lead_days is given. It is the deal update cell through permit, with nothing loosened in contract.json, and same-origin rules as the other API mutations.; The route declares api, so contract/openapi.json is regenerated (bun run contract:emit). The body's label description names every label in SUGGESTED_DATES, built from that list rather than retyped, so adding a suggestion updates the page, MCP and the API together. src/openapi.test.ts passes.; Tests: a suggested label gets its lead, a custom label gets the default, an empty or 101-character label is refused, a signed-out caller is refused, and the openapi body lists a suggestion.; The page, MCP and API share one add-a-date action rather than three copies of the checks..