Extra routing details on relayed messages are stored but ignored unless a server flag turns them on.
Relay envelope routing is parsed but the flag deciding whether it counts as a human turn falls back to off.
tengu_hearth_resolved_rows Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.239: not a boolean we can read
Read once, for one account on one subscription tier, against v2.1.239. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
Messages arriving through the projects relay (a Slack-style delivery path) can carry extra routing fields, which are always parsed and stored, but whether such a message counts as a real human turn is decided by tengu_hearth_resolved_rows, whose in-source fallback is "off". Only "full" or "model_only" are accepted; anything else stays off, and the telemetry reason flag_off is recorded.
- Fields accepted: up to 8 message ids matching
/^cmsg_[A-Za-z0-9]{1,128}$/, a rows schema withauthor_kindof owner/member/agent/system,whereof timeline or thread, plusthread_ts,written_atandtruncated, and a thread timestamp. - They are persisted with the message, stripped by the same scrubber that removes the verified-Slack-turn marker, and change how the turn is presented to the model.
- Nothing in this build sets the flag, so the real value comes from remote config.
- None of these names exist in v2.1.238.
tengu_hearth_resolved_rows
Strings lifted out of the shipped bundle, so the claim above can be checked against them.