AppStd/DigitalData.TaskFlow
8
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f8e877ac06ff42e9d4def04cc09fcdd132513469
DigitalData.TaskFlow/AGENTS.md
TekH b3b52a8c48 Update documentation for repo structure and DB practices 
Added detailed sections to `AGENTS.md`:
- "Repo Snapshot (verified)" to describe the .NET 8 solution structure and current implementation state.
- "High-value Commands" with instructions for building and running the solution.
- "Architecture That Matters During Edits" to outline dependency direction, key libraries, and response contract.
- "Current Implementation Gaps (easy to miss)" to highlight incomplete implementations and areas needing verification.
- "Config/Security Gotcha" to warn about sensitive data in `appsettings.json`.

Updated `README.md`:
- Added "Wichtiger Hinweis zu DB-Spaltennamen" to explain DB column mapping practices and emphasize the need for final verification of stored procedure result sets.
- Clarified that DB field names are mapped only in the Infrastructure layer, not in Domain models.
2026-10-10 11:15:10 +02:00

2.2 KiB
Raw Blame History

AGENTS

Repo Snapshot (verified)

  • This is a .NET 8 solution with 4 projects: API (src/presentation/DigitalData.TaskFlow.API), Application, Domain, Infrastructure.
  • Program.cs only wires DI + Swagger + MapControllers; there are currently no controller classes, so no HTTP endpoints are exposed yet.
  • There is no test project in the repository right now.

High-value Commands

  • Restore/build whole solution from repo root:
    • dotnet restore DigitalData.TaskFlow.sln
    • dotnet build DigitalData.TaskFlow.sln
  • Run API project:
    • dotnet run --project src/presentation/DigitalData.TaskFlow.API/DigitalData.TaskFlow.API.csproj
  • Focused build for one layer:
    • dotnet build src/core/DigitalData.TaskFlow.Application/DigitalData.TaskFlow.Application.csproj

Architecture That Matters During Edits

  • Dependency direction is strict: API -> Application -> Domain; Infrastructure depends on Application + Domain and is injected by API.
  • Application layer uses MediatR + FluentValidation pipeline behavior (ValidationBehavior<,>) + AutoMapper profile (ApplicationMappingProfile).
  • Response contract is centralized in Domain ApiEnvelope<T> + MetaEntry; use ApiEnvelopeFactory for consistent meta.code/message mapping.
  • Infrastructure registers TaskFlowDbContext and repository interfaces in DependencyInjection.cs; missing ConnectionStrings:TaskFlowDb throws at startup.
  • DB row-shape models (for procedures/views) live in Infrastructure (Persistence/Models), not in Domain.

Current Implementation Gaps (easy to miss)

  • DocumentRepository and WorkflowRepository.CloseAsync are still baseline/stub implementations returning placeholder data.
  • WorkflowListingReadModel column mapping is based on read-only DB metadata and observed SP result sets; final shape must be re-verified from DB metadata (sp_describe_first_result_set or equivalent) before production hardening.
  • Swagger:EnabledInProduction exists in config model but is not used in Program.cs yet.

Config/Security Gotcha

  • src/presentation/DigitalData.TaskFlow.API/appsettings.json currently contains a concrete SQL connection string and a MediatR license key; treat this file as sensitive and avoid propagating those values in docs, logs, or commits.
Reference in New Issue View Git Blame Copy Permalink