ivanpaulovich/todo

This system is a task management application built on .NET Core that implements Clean Architecture principles to separate domain logic from infrastructure concerns. It provides both a command-line interface and a Web API for creating, listing, updating, and deleting todo items, with persistence backed by SQL Server, local files, GitHub Gists, or in-memory storage. The codebase includes comprehensive unit, integration, and acceptance tests to verify core use cases and presentation layers.

The InMemoryGateway module now provides an in-memory implementation of the item gateway, allowing the application to store and retrieve todo items without a database. This includes an InMemoryContext that initializes with sample data, an InMemoryItemGateway that implements CRUD operations (Add, Delete, Get, List, Update) against an in-memory collection, and a ResponseHandler that collects responses for list and todo use cases.

source/TodoList.Infrastructure/InMemoryGateway · high confidence

The application now supports saving and loading todo items to a local JSON file (\.todolist\) in the user's home directory. This new \FileSystemItemGateway\ implementation handles CRUD operations by serializing items to and deserializing from JSON, ensuring data persists across sessions without requiring an external database.

source/TodoList.Infrastructure/FileSystemGateway · high confidence

New shell scripts have been added to the scripts directory to simplify local development setup. The sql-docker-up.sh script pulls the Microsoft SQL Server 2017 Docker image, starts a container named sql1 on port 1433, and resets the SA user password. The sql-connect.sh script provides a command to execute sqlcmd inside the running container to interact with the TodoItemsDB02 database.

scripts · high confidence

The TodoList.ConsoleApp has been introduced with a new entry point and startup logic that allows users to select the data storage backend by setting the 'Environment' configuration value in appsettings.json. Depending on the environment (Development, Staging, Production, or Cloud), the application automatically configures the corresponding persistence layer: in-memory storage, file system, SQL Server, or GitHub Gist. This enables users to switch between local and cloud-based data storage without changing code.

source/TodoList.ConsoleApp · high confidence

The core application logic for managing todo items has been implemented in the UseCases layer. This includes the \Todo\ use case for creating new items, \List\ for retrieving and formatting the item collection, \Do\ and \Undo\ for toggling completion status, \Rename\ for updating item titles, and \Remove\ for deleting items. These components rely on the \IItemGateway\ for data persistence and specific boundary interfaces for request/response handling.

source/TodoList.Core/UseCases · high confidence

The TodoList Web API is introduced, providing HTTP endpoints to create, list, rename, complete, undo, and delete todo items. The API uses a clean architecture with controllers delegating to use cases and presenters. Persistence is configured via dependency injection: the default development environment uses an in-memory gateway, while the production environment switches to a SQL Server backend using Entity Framework Core, with the connection string defined in appsettings.Production.json. Swagger UI is enabled for API documentation.

source/TodoList.WebApi · high confidence

This change introduces the initial codebase for a task management application built on Clean Architecture principles. It establishes the project structure with a .NET Core solution containing a Console App, Web API, Core domain, and Infrastructure layers, alongside Unit, Integration, and Acceptance test projects. The repository is initialized with essential documentation including a README, Code of Conduct, and Contributing guidelines, as well as CI/CD configuration via Appveyor. The CHANGELOG records early fixes for file system adapter permissions and the addition of Gist storage support.

(repo-wide) · high confidence

The core domain model for the application has been established with the addition of the Item entity, which supports creating, renaming, completing, and undoing tasks, along with a static Restore method for persistence reconstruction. An IItem interface defines the contract for these operations, and a DefaultEntitiesFactory has been introduced to instantiate new todo items, providing a concrete entry point for creating items within the system.

source/TodoList.Core/Entities · high confidence

This change establishes the foundational structure for the TodoList application's core logic by introducing a set of new interfaces and classes within the \Boundaries\ and \Gateways\ namespaces. It defines the command-based execution model through \IUseCase\ and \IRequest\ interfaces, alongside specific request/response types for operations like listing, adding, renaming, removing, and undoing items. Additionally, it introduces the \IItemGateway\ interface to abstract data persistence operations, providing a clear contract for how the core domain interacts with external storage mechanisms.

source/TodoList.Core/Boundaries · high confidence

The core library now includes dedicated exception types, BusinessException and InfrastructureException, which inherit from the standard Exception class. These classes allow the application to distinguish between business logic violations and infrastructure-level errors, enabling more precise error handling and reporting for users.

source/TodoList.Core/Exceptions · high confidence

The application now supports storing and syncing todo list data using a GitHub Gist. This change introduces the GistGateway infrastructure, which reads and writes item data to a JSON file hosted on GitHub, allowing users to maintain their task lists via cloud storage instead of local-only persistence.

source/TodoList.Infrastructure/GistGateway · high confidence

The application now supports storing todo items in a SQL Server database via a new Entity Framework Core gateway. This change introduces the SqlContext DbContext, a SqlItemGateway implementation of the IItemGateway interface, and an initial migration that creates the 'Item' table and seeds it with seven default tasks. A ContextFactory is also added to support design-time operations like migrations by reading the connection string from appsettings.Production.json.

source/TodoList.Infrastructure/EntityFrameworkGateway · high confidence

The console application now uses a \TodoItemsController\ to route command-line inputs (add, remove, list, rename, complete, undo, and gist configuration) to their respective use cases, and introduces specific presenters (\ListPresenter\, \TodoPresenter\) to format and display user-facing output with color-coded status indicators. This change separates the command execution logic from the presentation layer, allowing for clearer handling of success messages, empty states, and infrastructure errors in the terminal interface.

source/TodoList.ConsoleApp/Controllers · high confidence

The console application now features a new command-line interface that replaces the previous argument handling with a structured parser. This change introduces a \CommandArgsParser\ for robust tokenization (including quoted strings) and a \CommandParser\ that routes arguments to specific command handlers. Users can now interact with the app using a variety of aliases for commands such as \do\, \list\, \remove\, \rename\, \undo\, \help\, and \interactive\, as well as new commands for managing Gist persistence (\gist-token\, \gist-id\).

source/TodoList.ConsoleApp/Commands · high confidence

Added acceptance test for console application help output; Added integration tests for file system, SQL, and GitHub Gist storage gateways; Added test coverage report for TodoList unit tests; Added unit tests for Console and Web API UI layers; Added unit tests for core use cases.

This change introduces the initial project structure for the TodoList application, defining seven project files across the core, infrastructure, console app, web API, and test suites. The solution targets .NET Core 2.2 and .NET Standard 2.0, establishing the foundational dependencies required for the application to run. Key libraries included are Entity Framework Core 2.2.4 for database interactions, Swashbuckle 4.0.1 for API documentation, Octokit 0.32.0 for GitHub integration, and xUnit 2.4.1 with Moq 4.10.1 for testing.

(dependencies) · high confidence

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

• CAI 43 → 42 (-0.8)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 76 → 65 (-11.1)
• Architecture 85 → 85 (-0.6)
• Maturity 45 → 49 (+4.1)
• Readiness 32 → 33 (+1.0)
• Security 43 → 40 (-3.1)

• Bounded contexts not declared
• Duplicated block (7 lines × 2) (source/TodoList.WebApi/Startup.cs)
• High CVE: Microsoft.NETCore.App 2.2.0
• High CVE: Microsoft.NETCore.App 2.2.0
• High CVE: NewtonSoft.Json 12.0.1
• Medium CVE: Microsoft.AspNetCore.App 2.2.0
• Medium CVE: Microsoft.NETCore.App 2.2.0
• Medium CVE: System.Data.SqlClient 4.6.0
• Medium CVE: System.Data.SqlClient 4.6.1
• No exposed public API
• Test runner surfaced no tests
• The README describes only the ConsoleApp project (the single .NET Core Global Tool) and omits any mention of the TodoList.WebApi or TodoList.Infrastructure projects it depends on. (README.md)
• Thin analysable surface across projects
• redundant comment (source/TodoList.ConsoleApp/Commands/CommandArgsParser.cs)
• single-maintainer — knowledge-concentration (bus factor) risk

• Duplicated block (12 lines × 2) (source/TodoList.WebApi/Startup.cs)
• Duplicated block (16 lines × 2) (source/TodoList.WebApi/Startup.cs)
• Duplicated block (18 lines × 3) (source/TodoList.ConsoleApp/Commands/DoCommand.cs)
• End-of-life runtime: .NET netcoreapp2.2
• High CVE: Microsoft.NETCore.App 2.2.0
• High IaC: WD-COMPOSE-0002 (source/docker-compose.yml)
• Inconsistent naming for Use Case classes. The 'Rename' and 'Do' use cases follow the pattern of using the verb/noun directly (Rename, Do), while 'Remove' uses the verb. However, looking at the broader context of 'Todo' (which implies creating a new item) and 'Undo', the pattern is inconsistent. Specifically, 'Do' is a very generic verb, whereas 'Remove', 'Rename', 'Undo' are specific actions. More critically, 'Do' is likely intended to represent 'Add' or 'Create' a todo item, making 'Do' a poor and inconsistent name compared to the specific action verbs used elsewhere (Remove, Rename, Undo).
• Inconsistent naming in test classes. Most test classes use the Use Case name directly (e.g., RemoveUseCaseTests, RenameUseCaseTests, DoUseCaseTests). However, 'MarkItemIncompletedTests' uses a descriptive behavior name rather than the Use Case name (which is likely 'Undo' or 'MarkIncomplete' based on the method 'MarkItemIncompletedSuccess'). Additionally, 'TodoUseCaseTests' is vague compared to 'RemoveUseCaseTests'. If the Use Case is 'Todo' (create), it should be 'TodoUseCaseTests' for consistency with 'RemoveUseCaseTests', but 'Todo' is a noun, not a verb like 'Remove'. If the Use Case is 'Add', it should be 'AddUseCaseTests'. The inconsistency lies in mixing Use Case names with behavior descriptions or vague nouns.
• Medium IaC: WD-DOCKER-0003 (source/Dockerfile)
• Medium IaC: WD-DOCKER-0003 (source/Dockerfile)
• No SBOM
• No artifact signing
• No build provenance
• No dependency advisory monitoring

• Unchanged — 6 HTTP endpoints

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

ivanpaulovich/todo 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.