Summary
send.sh <team> <from> <to> <message> performs no existence check on either the from or the to agent name. A typo'd recipient (e.g. an accidental ... send.sh <team> <agent> dummy "x") is accepted and stored: the message lands in the DB addressed to a nonexistent agent, is never deliverable, and pollutes team history. A typo'd sender is equally accepted, which can misattribute messages in history.
Observed on a live team DB (v1.1.7-dev): a mistyped send to a nonexistent agent dummy was stored successfully with exit 0.
Expected
Notes
Validation belongs in send.sh (front door) rather than the storage layer, so api.sh/programmatic paths can decide their own policy.
Summary
send.sh <team> <from> <to> <message>performs no existence check on either thefromor thetoagent name. A typo'd recipient (e.g. an accidental... send.sh <team> <agent> dummy "x") is accepted and stored: the message lands in the DB addressed to a nonexistent agent, is never deliverable, and pollutes team history. A typo'd sender is equally accepted, which can misattribute messages in history.Observed on a live team DB (v1.1.7-dev): a mistyped send to a nonexistent agent
dummywas stored successfully with exit 0.Expected
tonot registered in<team>→ error out (or at minimum warn) before insert; suggest near-miss names like the roster-aware work in Suggest roster-aware agent names #239/Improve onboarding with roster-aware unique agent name suggestions #178 might.fromnot registered in<team>→ same.--forceescape hatch for intentional pre-registration sends, if any workflow needs it.Notes
Validation belongs in
send.sh(front door) rather than the storage layer, soapi.sh/programmatic paths can decide their own policy.