# ASIS Template DEV Notes Review

## Summary
The ASIS .NET template is a multi-project solution scaffold for a web application with shared contracts, database access, scheduled tasks, and an optional Blazor client. The notes below capture the main role of each project and the key conventions to keep aligned when extending the template.

## Root packaging project
- This is the template packaging repo, not the runtime app.
- It builds the distributable template package and controls template composition, substitutions, and included files.
- Bump the package version before publishing and keep generated artifacts excluded.

## Web project
- ASP.NET Core Razor Pages host and main startup project.
- Wires app configuration, auth, Serilog, EF Core, hosted services, pages, APIs, tag helpers, and static assets.
- Auth is optional in the template; startup should stay aligned with the deployment environment.

## Shared project
- Shared library for helpers, enums, and cross-project contracts.
- Used by Web, Blazor, Database, and ScheduledTasks.
- Keep it framework-agnostic and watch enum or helper changes that can ripple across projects.

## Database project
- EF Core data layer containing the DbContext, entities, migrations, and configuration conventions.
- Handles schema rules such as enum storage, soft delete behavior, and seed data.
- Keep scheduled-task seed data and enum values in sync.

## ScheduledTasks project
- Runtime support library for built-in C# tasks and PowerShell-based tasks.
- Contains the base task model, task factory, built-in task discovery, and execution result types.
- Task IDs, reflection-based discovery, and cancellation handling must stay consistent.

## Blazor project
- Blazor WebAssembly client for reusable UI components and client-side helpers.
- Depends on Shared and expects to be hosted by the Web app.
- Keep component APIs stable when consumed by Razor Pages or shared UI flows.

## Quick review notes
- The template is intentionally modular, with each project focused on a single responsibility.
- Shared contracts, enum values, and task identifiers are the most common cross-project coupling points.
- Changes should be checked against packaging rules and generated output expectations before publishing.