Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 5787@bnt-lap001 Assistant-Session: 5db26b82-138b-40cc-9856-4d5eb0f752fd
1.4 KiB
| id | type | title | domain | repo | status | owner | topic_slug | created | updated | origin | origin_ref |
|---|---|---|---|---|---|---|---|---|---|---|---|
| MAS-WP-0012 | workplan | One outbound path and one send cap | communication | mail-address-semantics | proposed | claude | coulomb-social | 2026-10-19 | 2026-10-19 | residual | MAS-WP-0010 |
One outbound path and one send cap
Risk C in history/2026-10-19T090725Z-scope-vs-intent.md. With both
roles in one deployment, the ticket service and mas_modes.mailer each
keep their own outbox and cap. Total outbound can then reach about twice
the configured cap. They also act differently over the cap: the ticket
service keeps replies unsent, while the mailer refuses with
send-cap-reached. Principle 10 says "caps how much it can send in
total".
Route all mail through the mailer
id: MAS-WP-0012-T01
status: todo
priority: medium
Make mas_modes.mailer.Mailer the only outbound path. The ticket service
then sends through a Mailer it is given, sharing the DB or an outbox
service, instead of its own outbox table and cap. Settle one behavior
over the cap, and record it in CONTRACT.md §6. Keep the ticket service's
/outbox inspection working, and keep the deployment's --max-sent
semantics.
Test the shared cap
id: MAS-WP-0012-T02
status: todo
priority: medium
Add a test that a deployment with both roles stops at exactly N sends in
total, and that the live entrypoint still passes MAS_MAX_SENT to the
single cap.