Found while validating routing for the release.
channel.routed carries a viaMention field. It is hardcoded false at server/src/routing/routes.ts:62, the only place the row is written, so it can never be true.
The reason is structural rather than a typo: choosing a coworker with @ short-circuits the router entirely, so that code never runs and no row is written at all.
What that looks like
Four routings tonight, every one viaMention=false:
01:51:21 chosen=knowledge viaMention=false fallback=true
01:49:27 chosen=risk-analyst viaMention=false fallback=false
01:47:09 chosen=risk-analyst viaMention=false fallback=false
01:39:03 chosen=knowledge viaMention=false fallback=true
And a conversation I sent to Risk Analyst through the @ picker produced a Drive call recorded against bot=risk-analyst at 01:52:39, with no channel.routed row anywhere near it. The mention worked; the trail just cannot say so.
So the audit trail answers "why did this go to Risk Analyst" for model-chosen conversations and is silent for mentioned ones, which is indistinguishable from a row that failed to write.
Two ways out, and it is a product decision
Record the mention too, with viaMention: true and the person as the reason. The trail then answers the question for every conversation, and the field earns its place. This is the one the field's existence implies was intended.
Or drop the field. If a person naming a coworker is an instruction rather than a decision worth recording, then viaMention carries no information and a constant false in a payload is worse than nothing, because a reader will reasonably infer the other case exists somewhere.
Not fixed in the validation pass, because either answer is a decision about what the trail is for rather than a bug fix.
Not urgent
Nothing is broken. Mentions route correctly, the picker works, and the Bot that answers is the one named.
Found while validating routing for the release.
channel.routedcarries aviaMentionfield. It is hardcodedfalseatserver/src/routing/routes.ts:62, the only place the row is written, so it can never betrue.The reason is structural rather than a typo: choosing a coworker with
@short-circuits the router entirely, so that code never runs and no row is written at all.What that looks like
Four routings tonight, every one
viaMention=false:And a conversation I sent to Risk Analyst through the
@picker produced a Drive call recorded againstbot=risk-analystat01:52:39, with nochannel.routedrow anywhere near it. The mention worked; the trail just cannot say so.So the audit trail answers "why did this go to Risk Analyst" for model-chosen conversations and is silent for mentioned ones, which is indistinguishable from a row that failed to write.
Two ways out, and it is a product decision
Record the mention too, with
viaMention: trueand the person as the reason. The trail then answers the question for every conversation, and the field earns its place. This is the one the field's existence implies was intended.Or drop the field. If a person naming a coworker is an instruction rather than a decision worth recording, then
viaMentioncarries no information and a constantfalsein a payload is worse than nothing, because a reader will reasonably infer the other case exists somewhere.Not fixed in the validation pass, because either answer is a decision about what the trail is for rather than a bug fix.
Not urgent
Nothing is broken. Mentions route correctly, the picker works, and the Bot that answers is the one named.