Add repository abstractions and in-memory adapters for Core V2

[Lakes41]

Difficulty

Medium

Type

Architecture / Persistence

Background

Core services need a persistence boundary, but the early V2 implementation should not be blocked by choosing or configuring a production database.

Problem

Business logic cannot be implemented cleanly if services either contain hard-coded mock data or depend directly on a database client.

Expected Outcome

Core has repository interfaces plus deterministic in-memory implementations suitable for development and service-level testing.

Suggested Implementation

• Define repository contracts for Guilds, Passes, Members, and Activity where required.
• Keep repository contracts expressed in Core domain types.
• Implement in-memory adapters for development and tests.
• Support basic create/get/list/update behaviour.
• Ensure adapters can later be replaced by production persistence without changing service consumers.

Acceptance Criteria

• Repository interfaces exist for required persisted domains.
• In-memory adapters implement those interfaces.
• Services can receive repositories through dependency injection or equivalent composition.
• No service directly imports a database driver.
• Repository behaviour has unit tests.
• Test state can be reset deterministically.
• Typecheck and tests pass.

Likely Affected Files/Directories

• src/repositories/
• src/adapters/memory/
• src/services/
• test/

[abojeEdwin]

Hi maintainer, I've gone through the issue and I have a clear understanding of the fix for this issue. I'd love to be assigned to this issue. Thank you

[rupesh-kumar-sah]

Hello @maintainers,

I can tackle Add repository abstractions and in-memory adapters for Core V2. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in Adamantine-guild/guildpass-core
• Core Implementation: Build Add repository abstractions and in-memory adapters for Core V2 with clean React/Next.js components, responsive styling, and proper loading/error boundaries.
• Quality Assurance: Add component unit tests and ensure zero TypeScript/ESLint warnings.

Ready to deliver a clean, tested PR within 12–24 hours. Please assign!