Skip to content

[Feature] Add repository and CRUD handlers for Status, Category, and Comment models #33

@mpaulosky

Description

@mpaulosky

Objective

Implement repository interfaces and CRUD handlers for the Status, Category, and Comment models to complete the core data persistence and API endpoint coverage for Sprint 1.

Motivation

  • Parity with Issues: Status, Category, and Comment models need the same CRUD operations (Create, Read, Update, Delete/Archive)
  • API Completeness: Enable full REST API coverage for issue metadata management
  • Vertical Slice Pattern: Each model should follow the same handler + repository + validator structure as Issues
  • Soft-Delete Consistency: Comment and other models should support archiving (IsArchived) for consistency

Scope

Models to implement handlers for:

  1. Status - Issue status options (Open, In Progress, Closed, etc.)
  2. Category - Issue categorization/tagging
  3. Comment - Comments on issues (with soft-delete support)

Deliverables per model:

  • Repository Interface (\IStatusRepository, \ICategoryRepository, \ICommentRepository)

    • Create, Read (by ID), Read (all, paginated), Update, Archive (soft-delete)
    • MongoDB-specific entity mapping (\StatusEntity, etc.)
  • CRUD Handlers (following existing Issue handler pattern)

    • \CreateStatusHandler\ / \CreateCategoryHandler\ / \CreateCommentHandler\
    • \GetStatusHandler\ / \GetCategoryHandler\ / \GetCommentHandler\
    • \ListStatusesHandler\ / \ListCategoriesHandler\ / \ListCommentsHandler\ (with pagination)
    • \UpdateStatusHandler\ / \UpdateCategoryHandler\ / \UpdateCommentHandler\
    • \DeleteStatusHandler\ / \DeleteCategoryHandler\ / \DeleteCommentHandler\ (archive)
  • CQRS Queries & Commands

    • Create/Update/Delete/List queries and commands with validators
    • Follow existing pattern: \CreateStatusCommand, \UpdateStatusCommand, etc.
  • API Endpoint Registration (in \Program.cs)

    • Wire up minimal API endpoints: POST/PUT/GET/DELETE for each model
    • Routes: /api/v1/statuses, /api/v1/categories, /api/v1/comments\
  • Folder Structure (depends on [Refactor] Reorganize Handlers folder by model domain #32)

Acceptance Criteria

  • All repository interfaces defined with proper Result return types
  • All CRUD handlers implemented and registered
  • All handlers support soft-delete (IsArchived, ArchivedBy, ArchivedAt)
  • API endpoints registered and working
  • Build succeeds with 0 errors
  • All tests pass
  • Handlers follow existing Issue handler pattern (no deviation)

Dependencies

Notes

  • Use existing Issue handlers as template for consistency
  • Consider audit trail pattern: capture \ArchivedBy\ and \ArchivedAt\ on soft-delete for all models
  • Pagination should follow Issue list pattern (page, pageSize parameters)
  • All validators should use FluentValidation like Issue validators

Related Issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestgo:needs-researchNeeds investigationrelease:backlogNot yet targetedsquadSquad triage inbox — Lead will assign to a membersquad:aragornAssigned to Aragorn (Lead)type:featureNew capability

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions