tegwick
ff1e139e8b
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
51 lines
1.4 KiB
Markdown
51 lines
1.4 KiB
Markdown
---
|
|
id: MAS-WP-0012
|
|
type: workplan
|
|
title: "One outbound path and one send cap"
|
|
domain: communication
|
|
repo: mail-address-semantics
|
|
status: proposed
|
|
owner: claude
|
|
topic_slug: coulomb-social
|
|
created: "2026-10-19"
|
|
updated: "2026-10-19"
|
|
origin: residual
|
|
origin_ref: 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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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.
|