Projects Feature

The Projects Feature encapsulates the creation and structural tracking of multi-repository MILTON projects.

Overview

Projects act as the foundational top-level domain within MILTON. Every Project ties together users, repositories, linked documents, and configuration profiles used throughout the remainder of the application lifecycle.

Endpoints

All project manipulation leverages FastEndpoints coupled with Wolverine CQRS messaging:

  • POST /api/projects (CreateProject.cs): Creates a new project environment (delegated to Wolverine handlers).
  • GET /api/projects (ListProjects.cs): Lists all projects providing summarized metadata (e.g., repository counts, config statuses, and temporal metadata).
  • GET /api/getprojects (GetProject.cs): Legacy fetching handler to support older internal workflows.

Client L1 Cache

The frontend reuses the project list returned by GET /api/projects through the scoped ProjectStore implementation in MILTON.Client/StateContainer/ProjectStore.cs. The store is registered in MILTON.Client/Program.cs and reused by Home.razor, ProjectLayout.razor, ProjectDashboard.razor, and ProjectConfig.razor so the project list is usually fetched once per active client scope instead of once per page.

After a successful project create in MILTON.Client/Pages/New-project.razor, the client calls ProjectStore.Clear() before redirecting to the new project’s configuration page. That explicit invalidation forces the next GET /api/projects call to include the new record.

See Client application for the full client-side cache lifecycle and invalidation rules.

Data Model Intersections

The core model behind this feature is the Project entity:

  • Has a 1:1 mapping to ProjectConfig.
  • Tracks Users via ProjectMember mapping tables supporting Role-based access control (ProjectUserRole.Admin/Member).
  • Holds soft references over all associated Document instances.