sgermosen/StreamingFromFiles

This system is a .NET-based backend architecture comprising multiple services for managing user accounts, processing media files, and handling book data. It features an API for authentication and image management, a background service for encoding MP4 videos in Azure, and a worker service that processes text files into CSVs. The domain layer supports audit tracking and database migrations, while the infrastructure handles Azure storage and external API integrations.

Added appsettings.Development.json files for the WorkerService, BgServicex, and EngineAPI components, and updated the README to describe the project's purpose of uploading video files to Azure storage.

(repo-wide) · high confidence

The EngineAPI is introduced as a new .NET Core service providing user account management (registration, login, password reset, email confirmation), JWT-based authentication, and multi-language support via cookies and route constraints. It also includes an image upload and retrieval endpoint, a custom bad-request parser for consistent error responses, and middleware for error handling and JWT validation.

Src/EngineAPI · high confidence

Added a new background worker service that monitors a specified input folder for new text files. When a file is created, the service reads the content, fetches book data from an external API (or uses cached data), and writes the results to a CSV file in an output folder. This introduces a new pipeline for processing book records via file system events.

Src/WorkerService · high confidence

The BgServicex project is introduced, providing a background service that monitors a local folder for new MP4 files. When a file is created, the service records the event in a SQL database and initiates an Azure Media Services encoding job. The implementation includes configuration wrappers for Azure credentials, an upload service for Azure Blob Storage, and utility classes for authentication and environment variable loading.

Src/BgServicex · high confidence

Added the \ApplicationDataContext\ with support for \ApplicationUser\, \Image\, \ImageType\, and \EventFile\ entities, enabling database migrations and audit tracking (created/updated/deleted by user). The \ApplicationUser\ entity extends ASP.NET Identity with \FullName\, \Identification\, \EmployeeNumber\, and \StoreCode\ fields. A \CurrentUser\ model and \CurrentUserFactory\ are provided to extract user claims from the HTTP context, which is then used by the data context to populate audit fields (\CreatedAt\, \CreatedBy\, \UpdatedAt\, \UpdatedBy\, \DeletedAt\, \DeletedBy\) on save.

Src/Domain, Src/Transversal · high confidence

The repository now includes five new .NET project files (BgServicex, Domain, EngineAPI, Transversal, and WorkerService) that establish the initial architecture and dependency graph. These files define the target frameworks (net5.0 and net6.0) and declare the specific NuGet packages required for each component, such as Azure Storage, Entity Framework Core, Serilog, and various Microsoft.AspNetCore and Microsoft.Extensions libraries.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 36 → 35 (-0.2)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 56 → 55 (-0.9)
• Architecture 88 → 88 (+0.0)
• Maturity 40 → 42 (+1.2)
• Readiness 28 → 28 (+0.0)
• Security 60 → 55 (-5.8)
• Accessibility 32 → 32 (+0.0)

• Inconsistent method naming convention in AccountService. Some methods use camelCase (sendVerificationEmail) while others use PascalCase (RegisterUserAsync, ResetPasswordAsync, ConfirmEmailAsync). Additionally, some methods are synchronous (send...) while others are explicitly async (Async suffix).
• Inconsistent method naming for storage operations. 'UploadBlobAsync' is used for uploads, but 'DeleteBlobAsync' and 'DeleteFile' are used for deletions. One uses 'Blob' and the other 'File'.
• Inconsistent naming for ViewModel/DTO/Response classes. The codebase mixes suffixes: some use 'ViewModel', some 'Request', some 'Response', and some have no suffix or use 'DTO'. For example, password reset uses both 'ResetPasswordRequest' and 'ResetPasswordViewModel'.
• Inconsistent naming for audit fields. Some are simple (Updated, CreatedBy), while others include the entity name (DeletedUser, CreatedUser). Also, 'Deleted' is a boolean or status, while 'DeletedUser' is a string/ID.
• Inconsistent naming for properties in RegisterViewModel. 'ConfirmPassword' and 'Password' are clear, but 'ImageFile' and 'Identification' are less consistent with the rest of the codebase which often uses 'Id' or 'Identification' for different concepts.
• Inconsistent naming for storage managers. The interface is 'IStorageManager', but the implementations are 'AzureStorageManager' and 'LocalStorageManager'. This is actually consistent with the interface, but the interface name 'IStorageManager' is generic compared to the specific implementations.
• Inconsistent naming for unique identifiers. Some entities use 'Id' (Account, EventFile), while others use 'Identification' (ApplicationUser). This suggests 'Identification' might be a business key or a different type of ID.
• LLM evaluation failed
• Medium CVE: Microsoft.Data.SqlClient 2.0.1
• Monorepo: only 1 of 3 solutions was scored
• No exposed public API
• early-stage repository — too little history to judge knowledge freshness
• git history depth insufficient
• git history depth insufficient
• single-maintainer — knowledge-concentration (bus factor) risk

• CommentedOutCode (Src/EngineAPI/Controllers/AccountController.cs)
• CommentedOutCode (Src/EngineAPI/Startup.cs)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Duplicated block (13 lines × 2) (Src/Domain/Entities/ApplicationUser.cs)
• End-of-life runtime: .NET net5.0
• End-of-life runtime: .NET net6.0
• The interface IStorageManager and its implementations AzureStorageManager and LocalStorageManager define the method for uploading blobs. However, LocalStorageManager also defines a method DeleteBlobAsync for deletion, while the interface and the Azure implementation use DeleteFile (in LocalStorageManager) or do not explicitly show a delete method in the interface signature provided (though IStorageManager is listed with UploadBlobAsync). More critically, LocalStorageManager has both UploadBlobAsync and DeleteBlobAsync, but the interface IStorageManager only lists UploadBlobAsync. If IStorageManager is the contract, DeleteBlobAsync in LocalStorageManager is an inconsistency if it should be DeleteFileAsync to match DeleteFile, or if the interface should include it. However, the clearer inconsistency is within LocalStorageManager itself: it has UploadBlobAsync and DeleteBlobAsync, but also DeleteFile. This suggests a confusion between 'Blob' and 'File' terminology for the same underlying storage concept in the local manager.
• WriteOnlyPrivateField (Src/EngineAPI/Filters/MyAccionFilter.cs)

• Unchanged — 18 HTTP endpoints

• Unchanged — 2 containers · 0 contexts · 0 edges

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

sgermosen/StreamingFromFiles was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.