PlannerPro

A single-user tool for planning and tracking two-week sprints across several parallel software projects. Each sprint gives every project one goal, a status, and a small set of tasks with Fibonacci effort points — so you can see at a glance when a sprint is overloaded.

• Sprint Board — the current sprint, all projects side by side, with inline goal/status/task editing.
• Timeline — a rolling roadmap grid (sprints as rows, projects as columns) with per-sprint effort totals and overload flags.
• Effort awareness — Fibonacci points (1, 2, 3, 5, 8, 13, 21) on tasks; the UI warns on any task > 8 and flags a sprint whose total exceeds 24.

---

Tech stack

Layer	Technology
Front end	Angular 22 — zoneless, signal-first, standalone components, httpResource
API	.NET 10 minimal APIs, EF Core 10 (code-first)
Database	SQL Server (run as an Aspire-managed container)
Auth	ASP.NET Core Identity, single user, cookie-based, antiforgery-protected
Orchestration	.NET Aspire 13 AppHost (spins up SQL + API + Angular together)

Project layout

PlannerPro.slnx                 # solution (new .slnx format)
├─ PlannerPro.AppHost/          # Aspire orchestrator — start here
├─ PlannerPro.ServiceDefaults/  # shared telemetry/health/resilience wiring
├─ PlannerPro.Api/              # .NET 10 Web API + EF Core + Identity + seed data
└─ PlannerPro.Web/              # Angular 22 SPA

Data model (4 entities): Project · Sprint · SprintGoal (join: one row per project × sprint) · PlannerTask (under a goal).

---

Prerequisites

Tool	Version	Notes
.NET SDK	10.0+	Provides dotnet and the net10.0 target.
Node.js	≥ 24.15 (LTS 24.18 recommended)	Angular 22 requires ≥ 24.15.
npm	11+	Ships with Node.
A container runtime	Docker Desktop or Podman	Aspire runs SQL Server in a container. Must be running before you start.
Aspire CLI	13.x	Optional — you can also start the AppHost with plain dotnet run (see below).

Verify quickly:

dotnet --version   # 10.x
node --version     # v24.15+  (v24.18 LTS recommended)
docker info        # daemon reachable

---

Getting started

1. Clone and restore

git clone <your-repo-url> PlannerPro
cd PlannerPro
dotnet restore

The Angular dependencies install automatically the first time the AppHost starts. To install them ahead of time:

cd PlannerPro.Web && npm ci && cd ..

2. Configure the login user

There is one login account, seeded on first run from configuration. No credentials are committed — you supply them via user-secrets (they never touch the repo). Set them on the API project:

cd PlannerPro.Api
dotnet user-secrets set "SeedUser:Email" "you@example.com"
dotnet user-secrets set "SeedUser:Password" "a-strong-dev-password"
cd ..

If you skip this, the app still runs — it just logs a warning and creates no login user, so you won't be able to sign in.

The SQL Server container password is generated by Aspire automatically on first run and stored in the AppHost's user-secrets — you don't need to set it.

3. Run everything

aspire run

…or, without the Aspire CLI:

dotnet run --project PlannerPro.AppHost

This starts, in order: the SQL Server container → the API (which applies EF migrations and seeds data) → the Angular dev server.

4. Open the app

What	URL
Aspire dashboard (logs, traces, resource status)	printed in the console, e.g. https://localhost:17154
PlannerPro web app	http://localhost:4200
API (HTTPS)	https://localhost:7265

Log in at http://localhost:4200 with the email/password you set in step 2.

The database is seeded with three sample projects and the first three sprints of goals/tasks — deliberately tuned so sprint 1 is healthy, sprint 2 is overloaded (to show the warning), and sprint 3 is healthy again. Sprints are generated on a two-week cadence from a fixed anchor date through the end of 2027.

Data persists between runs — SQL Server uses a named Docker volume (plannerpro-sql-data). To start clean, stop the app and remove that volume: docker volume rm plannerpro-sql-data.

---

Everyday development

Work on the Angular app alone (against an already-running API) — the dev proxy forwards /api to the API; when launched by Aspire it auto-discovers the API address, otherwise it falls back to https://localhost:7265:

cd PlannerPro.Web
npm start          # ng serve on http://localhost:4200

Work on the API alone:

dotnet run --project PlannerPro.Api   # https://localhost:7265, OpenAPI at /openapi in Development

Database migrations

The API applies migrations automatically on startup. To add one after changing an entity:

cd PlannerPro.Api
dotnet ef migrations add <Name>

A design-time factory (PlannerDbContextFactory) lets dotnet ef build the model without a running database or Aspire.

---

Production build

In Release, the API builds the Angular app and serves it from wwwroot as a single same-origin deployable (no CORS, cookie auth just works). Client-side routes fall back to index.html.

dotnet publish PlannerPro.Api -c Release

This runs npm run build --configuration production and copies the output into PlannerPro.Api/wwwroot via the BuildAngularSpa MSBuild target.

Provide configuration in the hosting environment via environment variables:

Setting	Env var	Purpose
Login email	SeedUser__Email	Seeds the single user on first run.
Login password	SeedUser__Password	Seeds the single user on first run.
Database	ConnectionStrings__plannerdb	SQL Server connection string.

Auth cookies are marked Secure under HTTPS and antiforgery is enforced on all mutations — serve production over HTTPS.

---

Notes & conventions

• Angular is zoneless. State lives in signals; a native <select> must set the initial value with [selected] on each <option> (not [value] on the select) to reflect correctly.
• Antiforgery: the API issues a readable XSRF-TOKEN cookie on GETs; Angular's HttpClient echoes it in X-XSRF-TOKEN on mutations, and an endpoint filter validates it. Auth endpoints are exempt.
• Secrets never live in the repo — appsettings.json keeps SeedUser blank by design. Use user-secrets in dev, environment variables in production.