forgejo_admin/westside-ai-assistant
1
0
Fork 0
Code Issues 13 Pull requests Projects Releases Packages Wiki Activity Actions

Spike: Coach-level assistants — permissions, GroupMe groups, multi-role architecture #22

New issue
Open
opened 2026-03-30 18:15:11 +00:00 by forgejo_admin · 0 comments
forgejo_admin commented 2026-03-30 18:15:11 +00:00
Owner
Copy link

Type

Spike

Lineage

Standalone — emerged from V1 go-live session. Expanding Nemo beyond admin-only.

Repo

forgejo_admin/westside-ai-assistant

Question

How should we architect multi-role AI assistants so that coaches get scoped read-only access to their team data through GroupMe, without exposing admin operations or other teams' data?

Sub-questions:

  1. One bot registered to multiple GroupMe groups, or one bot per group?
  2. How do we map a GroupMe sender to a Keycloak identity and role?
  3. What tool subset does each role get, and how does the tool registry enforce it?

What to Explore

  • GroupMe group structure: Teams already have groupme_group_id in basketball-api. Can we register Nemo in team groups? Or do coaches need separate "Coach + Nemo" groups?
  • Identity mapping: GroupMe sender_id → Keycloak user. Options: (1) lookup table in Nemo's DB, (2) registration flow where coach links accounts, (3) group-based inference (Kings Coaches group = Kings coach role)
  • basketball-api RBAC: Review /coaches/me and coach-scoped endpoints. What data does a coach already have access to via the API?
  • Tool scoping: Can the tool registry's enabled flag be extended with a roles: [admin, coach] field? Or separate tool directories per role?
  • Architecture: One Nemo deployment handling all groups with role-based tool selection vs separate services
  • Token cost: estimate Haiku cost per coach group per month (assume 20 messages/day)

Success Criteria

  • Architecture note created: arch-multi-role-westside-ai-assistant with permissions matrix and GroupMe group strategy
  • User story notes created for coach role
  • Identity mapping approach decided with evidence (not opinion)
  • Follow-up implementation tickets created from findings
  • Or: "not feasible yet" conclusion with reasoning

Time-box

Maximum: 1 session. If unanswered, document findings and escalate to Lucas.

Related

  • project-westside-ai-assistant — parent project
  • arch-domain-westside-ai-assistant — current admin-only architecture
  • story-westside-ai-assistant-read-ops — V1 admin story this expands
### Type Spike ### Lineage Standalone — emerged from V1 go-live session. Expanding Nemo beyond admin-only. ### Repo `forgejo_admin/westside-ai-assistant` ### Question How should we architect multi-role AI assistants so that coaches get scoped read-only access to their team data through GroupMe, without exposing admin operations or other teams' data? Sub-questions: 1. One bot registered to multiple GroupMe groups, or one bot per group? 2. How do we map a GroupMe sender to a Keycloak identity and role? 3. What tool subset does each role get, and how does the tool registry enforce it? ### What to Explore - **GroupMe group structure**: Teams already have `groupme_group_id` in basketball-api. Can we register Nemo in team groups? Or do coaches need separate "Coach + Nemo" groups? - **Identity mapping**: GroupMe `sender_id` → Keycloak user. Options: (1) lookup table in Nemo's DB, (2) registration flow where coach links accounts, (3) group-based inference (Kings Coaches group = Kings coach role) - **basketball-api RBAC**: Review `/coaches/me` and coach-scoped endpoints. What data does a coach already have access to via the API? - **Tool scoping**: Can the tool registry's `enabled` flag be extended with a `roles: [admin, coach]` field? Or separate tool directories per role? - **Architecture**: One Nemo deployment handling all groups with role-based tool selection vs separate services - **Token cost**: estimate Haiku cost per coach group per month (assume 20 messages/day) ### Success Criteria - [ ] Architecture note created: `arch-multi-role-westside-ai-assistant` with permissions matrix and GroupMe group strategy - [ ] User story notes created for coach role - [ ] Identity mapping approach decided with evidence (not opinion) - [ ] Follow-up implementation tickets created from findings - [ ] Or: "not feasible yet" conclusion with reasoning ### Time-box Maximum: 1 session. If unanswered, document findings and escalate to Lucas. ### Related - `project-westside-ai-assistant` — parent project - `arch-domain-westside-ai-assistant` — current admin-only architecture - `story-westside-ai-assistant-read-ops` — V1 admin story this expands
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo_admin/westside-ai-assistant#22
No description provided.