- Ya
- 22 Agosti 2026, 00:24 UTC
- Mwandishi
- kamo
- Ahadi ya
- 696d970
Four views over one draft ruleset, because there are four different questions and no single layout answers them all. Rules is what each rule does, Matrix is what the organization looks like, Simulator is what happens to two named people, Activity is what the policy is doing to everyone else. A rule is a sentence, not a form. An administrator assembling meaning out of six labelled dropdowns will misread their own policy; one reading "Sales may not chat with everyone in a different department" will not. Every editable phrase is a chip, and the sentence functions live in app/lib so they can be unit-tested -- the vocabulary crosses that boundary as data rather than as a translator, since vitest runs them in the node environment. The two ends of a one-way rule are said separately on purpose. "Sales may start chats with Engineering, who can reply only while that window stays open" describes what the engine does; any single symmetric phrasing would describe a rule that does not exist. Ordering is what first-match-wins costs, so the board pays it down: the impact of the draft is checked continuously against what is actually live, shadowed and duplicate rules are named under the rule they affect, and publishing shows how many pairs it blocks before the button. New rules and every template arrive in audit mode, where they record what they would have blocked and block nothing. The roster is annotated, not filtered. A blocked member keeps their name, photo and presence, and their chat button explains itself instead of disappearing. Also creates /api/members/directory, which ChatBox's add-members picker has been fetching since it was written -- the route never existed, so the request 404'd and the dialog rendered an empty list with nothing reporting a problem.