CommunityPro / CommunityPro/community-pro-api
Mentorship: mentor directory endpoints (Phase 6.6 backend)
- Dominant language
- C#
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
## Scope
Public-to-members directory the frontend grid consumes.
| Method | Path | Auth | Notes |
|---|---|---|---|
| GET | `/mentorship/mentors` | active member | paginated; filters: `expertiseTag`, `acceptingOnly=true` |
| GET | `/mentorship/mentors/{id}` | active member | mentor detail incl. expertise, capacity headroom, availability summary |
## Rules
- Enrich with member card data (display name, title, avatar) via the Members module **public contract** — no cross-module DbContext reach-ins.
- Exclude mentors whose underlying member is not `Active` (pending/deactivated must never surface — query level, not UI level).
- `acceptingOnly` filters on `IsAcceptingMentees` **and** actual capacity headroom (belt and braces — the flag can lag).
- Detail endpoint exposes weekly availability in the mentor's timezone plus the IANA id, so the booking UI can convert client-side.
## Error codes
`mentorship.not_found`
## Dependencies
Blocked by #9. Capacity headroom needs #10's `Mentorship` table (soft — can land computing headroom as capacity until M2 merges).
## Acceptance criteria
- [ ] Deactivated/pending members filtered out (tested)
- [ ] Tag filter matches case-insensitively
- [ ] Pagination + deterministic ordering (accepting first, then newest opt-in)
### Conventions (project-wide, non-negotiable)
- .NET 9, records for immutable shapes, file-scoped namespaces, primary constructors where they read well. Minimal-API endpoints grouped per module via `IEndpointModule.MapEndpoints`.
- `Result` (SharedKernel) instead of exception-driven control flow. Endpoint results map failures to ProblemDetails with the stable error codes listed above — the frontend keys off them.
- Module owns its EF Core `DbContext` mapped to its own Postgres schema. Modules never reference each other's internals — cross-module needs go through a public contract interface or an in-process domain event (`IEventPublisher`).
- All external calls (GitHub, Stripe, Brevo, Cloudinary, Meilisearch) behind interfaces owned by the consuming module.
- Every list endpoint paginated (offset is fine). xUnit tests in `tests/CommunityPro.Tests//` following the existing harness patterns (see `Members/MembersTestHarness.cs`).
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the dependency issues #9 and #10, then inspect the Members public contract and tests/Members/MembersTestHarness.cs for the existing module patterns. Trace the mentorship endpoint registration through IEndpointModule.MapEndpoints and verify the listed filters, ordering, pagination, member-status exclusion, capacity handling, timezone data, and mentorship.not_found mapping with xUnit tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, postgresql
- Domain
- api, backend, databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100