- Shipped
- August 28, 2026 at 1:27 AM UTC
- Author
- Kamo
- Commit
- 62c4860
The retrieval filter matched a reader's tier exactly: a TEAM_MEMBER had to match aiVisibleToTeamMembers and nothing else. So an article an author had deliberately opened to Members — or to the whole public — could not be cited to a member of staff, and a members-visible article was invisible to everyone above that tier. The failure is the worst shape a retrieval bug takes. No error, no empty result: the assistant answers from whatever survived the filter, and nobody can tell that a source was withheld. It also contradicted what a person is shown reading /kb directly, so a member could read an article in the knowledge base and then be told by the assistant that it knows nothing about it. readableAudienceKeys() now returns the reader's tier and every tier below it, in step with KBService's KbReaderScope (30f2bf9): TEAM_MEMBER public + members + teamMembers MEMBER public + members absent public Two deliberate differences from KbReaderScope, both documented at the method: - An unrecognised member type is the public tier here, where KbReaderScope treats it as the plain-member tier. There a session exists and only its classification is in doubt; here the field's absence is the only signal that there is no member at all — the public widget sends nothing. - No maintainer or author exemption. Those let a person deliberately open their own or unpublished work; they are not a licence for an assistant to volunteer it into a conversation. The status filter beside this one keeps retrieval to published articles for everybody. The alternatives are nested in their own should-only filter, the shape the sourceType and status filters in this method already use, so they read as "at least one of these" ANDed with the musts rather than sitting beside them. First tests in this repo: 6, on the tier rule itself — the builder plumbing around it is not what was wrong.