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:1mapping to ProjectConfig. - Tracks Users via
ProjectMembermapping tables supporting Role-based access control (ProjectUserRole.Admin/Member). - Holds soft references over all associated
Documentinstances.