maaz519
5abee1b5b7
Versioned, per-topic project memory (index + entries): IIOS overview, the generic-safety rule, run/test + the replay.spec flake workaround, recent features (Supabase auth, reactions/pins/saves, mentions, media, notifications), the chat-web consumer, and workflow conventions. CLAUDE.md points to it as the accumulating-notes companion to the canonical rules. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.5 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| feedback_generic_safety | THE |
|
The kernel must stay generic. No 'dm' / 'group' / 'reaction' / 'emoji' / 'mention'
literals in kernel or messaging logic. If a reviewer asked "is this a chat backend now?" the
answer must stay no.
Why: IIOS is a generic interaction OS; chat is one consumer. Baking chat meaning into the kernel destroys reuse (support/community/meetings share the same core).
How to apply: domain meaning lives in exactly three places, never the kernel —
- OPA policy (
DevOpaPort→ real OPA): DM-cap, group-admin, governed-join, media limits, notification triggers. - Opaque attributes the kernel stores but never interprets:
thread.metadata.membership(dm/group), interaction annotations (opaqueannotationType+value→ app writesreaction/pin/save),mentions[](opaque userId notify-list; kernel never parses@). - The app (chat-web): rendering + product semantics.
Reading an opaque attr inside a policy/notification gate (membership === 'dm' in
DevOpaPort or notification.projector.ts) is OK — that file IS the policy plane. Everywhere
else, keep generic. Verify before committing:
grep -rniE "'dm'|'group'|reaction|emoji" packages/iios-service/src | grep -v spec — hits only
in policy/notification/app-facing layers or comments. Also run pnpm boundary.
Related: project_iios_overview.