Refactor data access to enforce strict guild-scoped multi-tenancy across members, passes, and activity

[Lakes41]

Difficulty: Advanced
Type: refactor

Background
GuildPass manages multiple guilds/communities, each with their own members, passes, and activity, per the feature list and /guilds route — implying the app is meant to be multi-tenant at the guild level.

Problem
It's not evident from the project structure that member, pass, and activity queries are consistently scoped by guildId; without enforced scoping at the data-access layer, it would be easy for a future real-backend integration to leak one guild's members/passes/activity into another guild's views.

Expected outcome
Every data query for members, passes, and activity requires an explicit guildId and is enforced at a single choke point (not just optionally passed by UI code), so cross-guild data leakage is structurally prevented.

Suggested implementation

• Introduce a GuildScopedContext (or similar) that wraps all repository/query calls with a mandatory guildId.
• Update apps/dashboard/lib/mock-data.ts accessors to require guildId as a parameter, throwing/erroring if omitted, rather than defaulting to "all guilds."
• Add a currently-selected-guild concept to the dashboard (e.g., a guild switcher in the nav) that supplies guildId to all pages via context/route params.
• Add tests asserting that querying members/passes/activity without a guild context is impossible or clearly rejected.

Acceptance criteria

• All member/pass/activity queries require a guildId
• A guild switcher exists in the UI and drives which guild's data is shown
• Tests confirm scoping cannot be bypassed
• No existing single-guild functionality regresses

Likely affected files/directories

• apps/dashboard/lib/mock-data.ts
• apps/dashboard/app/**
• apps/dashboard/components/ (guild switcher)
• packages/integration-client/

[bridgetthnkechi87-cloud]

Hello Maintainer,

I would like to work on this issue.

I understand the goal is to make GuildPass safer for multi-guild usage by enforcing guild-level scoping at the data-access layer, not only from the UI. Since members, passes, and activity belong to specific guilds, every query should require an explicit guildId so future backend integration does not accidentally expose one guild’s data in another guild’s view.

My approach would be to first review the current dashboard data flow, especially apps/dashboard/lib/mock-data.ts, member/pass/activity accessors, and the /guilds route. Then I’d introduce a focused guild-scoped access pattern, likely through a GuildScopedContext or similar helper, so repository/query calls cannot run without a selected guild.

I’d also add a simple selected-guild concept in the dashboard, such as a guild switcher, and wire member, pass, and activity pages to use that selected guildId. For testing, I’d add coverage to confirm that member/pass/activity queries require guild context and cannot silently return cross-guild data.

I’ll keep the implementation reviewable and avoid unrelated UI or backend refactors. I’ll also make sure existing single-guild behavior continues to work while improving the structure for true multi-tenant safety.

I’d be happy to take this up if assigned.

[grantfox-oss]

🦊 GrantFox — @bridgetthnkechi87-cloud has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #298)
2. Your PR will be reviewed by the Adamantine-guild maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@bridgetthnkechi87-cloud's PR #314 was approved and merged by @Lakes41.

🏆 @bridgetthnkechi87-cloud: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (401 total points). Track your full progress on GrantFox.

👏 Great work, @bridgetthnkechi87-cloud! Keep contributing to Adamantine-guild.