Skip to content
CAI
Software that uses CAICheck a score

gftf2011/clean-react-todolist

53.1

Weak · 20 September 2026

3.7k

lines of production code

TypeScript

primary language

4

measurements over time

CAI band scale
CAI trend line
CAI lens gauges

What this system is

This system is a React-based single-page application for managing user authentication and a paginated list of notes. It implements a Clean Architecture pattern with a backend API for sign-up, sign-in, and note CRUD operations, utilizing an in-memory database. The frontend features a comprehensive UI with atomic design components, Redux state management, and local storage caching for offline note persistence.

Features

Add page factory components for authentication and todo management

New factory components have been added to wire presentation pages with their respective use cases and routing logic. The sign-in and sign-up pages are now wrapped in SignedInRoute to handle post-login redirection, while the home, todos, add-todo, and edit-todo pages are wrapped in PrivateRoute to enforce authentication. These factories inject specific use cases (such as create, update, delete, and find notes) and validation logic into the corresponding UI components, establishing the wiring for the application's core user flows.

src/main/factories/presentation/pages · high confidence

Added TypeScript declaration files for SVG imports and Vite client types

The project now includes \src/custom.d.ts\ to declare the module type for \.svg\ files, allowing them to be imported as default exports, and \src/vite-env.d.ts\ to reference Vite's client types, ensuring proper TypeScript support for the build environment.

src · high confidence

Added cache note management strategies

New presentation strategies have been introduced to handle adding, updating, and deleting notes within the local storage cache. These strategies implement the Strategy pattern to manage note persistence, including logic for paginating notes based on a configurable limit, handling navigation flags (previous/next), and enforcing constraints such as preventing the deletion of unfinished notes or updating non-existent ones.

src/presentation/strategies · high confidence

Added caching proxy for note retrieval

A new \FindNotesCacheUseCaseProxy\ has been introduced in the use-cases layer to cache paginated notes in local storage. When retrieving notes, the proxy first checks if the requested page is already stored; if not, it fetches the data via the underlying use case, saves it to storage, and returns the result. This optimization reduces redundant data fetching for previously viewed pages.

src/use-cases/proxies · high confidence

Added factory functions for note and authentication use cases

This change introduces factory functions in the use-case factories layer to instantiate and wire up core application logic. Specifically, it adds factories for creating, deleting, finding, and updating notes, as well as for sign-in and sign-up operations. These factories handle dependency injection by providing the HTTP client and base URL to the use-case implementations. Additionally, the find-notes factory wraps the implementation with a caching proxy using local storage, while the sign-in and sign-up factories decorate the use cases with a cache invalidation decorator to ensure data consistency after authentication.

src/main/factories/use-cases · high confidence

Added protected route components for access control

New route wrapper components have been introduced to manage user access based on authentication state. The PrivateRoute component restricts access to its children unless a valid access token is present in storage, redirecting unauthenticated users to the sign-in page. Conversely, the SignedInRoute component allows access only when an access token exists, redirecting users to the todos page if they are already signed in. These components are exported from the proxies index to be used by the application's routing configuration.

src/main/proxies · high confidence

Initial application entry point and routing setup

The application now includes a main entry point that initializes the React root and renders the Router component, establishing the foundation for client-side navigation and global style integration.

src/main · high confidence

Initial design system styles for UI components

This change introduces the foundational styling layer for the application's user interface by adding SCSS files for core HTML elements. It defines consistent visual properties for buttons (including variants like primary, secondary, danger, and sizes from xxs to xxl), input fields, text areas, and logos. The styles enforce a reset for padding and margins, set a default font family, and import external Google Fonts, establishing a baseline look and feel for form controls and interactive elements across the presentation layer.

src/presentation/styles · high confidence

Initial implementation of the presentation component layer

This change introduces the complete presentation layer for the application, organized using an atomic design structure. It adds foundational atoms (Button, Input, Link, Logo, TextArea, and a set of icons), reusable molecules (form controls, social media links, a loading screen, a navbar, pagination, toast notifications, and todo cards), and complex organisms (a responsive header with mobile navigation, a footer with social links, and a paginated todo list). Additionally, it provides page-level components for Home, Sign-In, Sign-Up, Add Todo, Edit Todo, and the main Todos list, along with corresponding layout templates that wire these components together.

src/presentation/components · high confidence

Initial project scaffolding with Clean Architecture and Vite tooling

The repository is initialized with a React.JS application structure based on Clean Architecture, utilizing Vite as the build tool and Vitest for testing. This entry establishes the foundational configuration, including TypeScript settings, ESLint and Prettier rules, and a design system with predefined SCSS variables for theming. It also includes the initial HTML entry point, a comprehensive README detailing the project's architectural concepts and design patterns, and configuration for SonarCloud quality analysis.

(repo-wide) · high confidence

Initial routing setup with Redux integration

The application now includes a central router configuration that defines navigation paths for home, sign-in, sign-up, add-todo, todos, and edit-todo pages. These routes are wired to presentation components via factory functions and are rendered within a ReduxRouterDomProvider, establishing the core navigation structure backed by Redux state management.

src/main/routes · high confidence

Initial server implementation with authentication and note management

The server now provides a complete backend API for user authentication and note management using an in-memory database. Users can sign up and sign in to receive access tokens, which are required to create, retrieve (with pagination), and update the completion status of notes. The API endpoints are versioned under /api/V1 and enforce basic validation for request bodies and user existence.

server · high confidence

Introduce HTTP and Local Storage infrastructure gateways

The infrastructure layer now provides concrete implementations for core communication and persistence needs. An Axios-based HTTP client has been added to handle API requests (GET, POST, PATCH, PUT, DELETE) and standardize response/error handling, while a singleton Local Storage wrapper has been introduced to manage key-value data persistence in the browser. These components expose the necessary interfaces for use cases to interact with external services and local state.

src/infra · high confidence

Introduce Redux Toolkit state management for notes

The presentation layer now uses Redux Toolkit to manage application state, replacing previous mechanisms. This change introduces a new store configuration that combines reducers for the current note (handling title and description updates) and paginated notes (managing note lists, pagination state, and limits). Corresponding action creators and slice definitions are provided to allow components to update and reset note-related data.

src/presentation/state-manager · high confidence

Introduces structured error classes for use-case validation

This change adds a new set of specific error classes within the \src/use-cases/errors\ directory, including \CacheRevalidationError\, \EmailAlreadyExistsError\, \EmailDoesNotExistsError\, \InvalidCredentialsError\, \InvalidNoteInformationError\, \InvalidTokenError\, \NotAllowedActionError\, \PasswordDoesNotMatchError\, \RequiredFieldError\, \ServerError\, \ServiceUnavailableError\, and \UnknownError\. These classes are exported via a central \index.ts\ file, providing developers with distinct error types to handle specific failure scenarios—such as authentication issues, validation failures, and server errors—more precisely than generic error handling.

src/use-cases/errors · high confidence

Introduction of HTTP client interface and types

A new HTTP client gateway interface has been added to the application's use-case ports, defining the contract for making HTTP requests. This change introduces a standardized \HttpClient\ interface with a \request\ method, along with supporting types for HTTP methods, request payloads, and response structures including a comprehensive \HttpStatusCode\ enum. This provides a consistent abstraction for network communication within the use-case layer.

src/use-cases/ports/gateways/http-client · high confidence

Introduction of core domain data models

The application now defines the fundamental data structures for the domain layer. Users are represented by a User model containing identification, name, email, and password fields, while notes are defined by a Note model including an identifier, title, description, completion status, and timestamp. These types are exported via a central index to support the rest of the application's logic.

src/domain/models · high confidence

Introduction of domain use-case interfaces for authentication and note management

The \src/domain/use-cases\ directory now defines the contract layer for core application capabilities. This includes interfaces for user authentication (\SignInUseCase\, \SignUpUseCase\) and comprehensive note lifecycle management (\CreateNoteUseCase\, \FindNotesUseCase\, \UpdateNoteUseCase\, \UpdateFinishedNoteUseCase\, \DeleteNoteUseCase\). These interfaces, built upon a shared \UseCase\ base, standardize the input/output structure (such as \accessToken\ requirements and \Note\ model returns) that implementing services must adhere to, establishing the foundation for the application's business logic.

src/domain/use-cases · high confidence

New storage gateway interface defined

A new Storage interface has been introduced in the use-case ports layer, defining a contract for local storage operations including set, get, and clear methods, along with a KEYS enum for standard keys like ACCESS\_TOKEN and NOTES.

src/use-cases/ports/gateways/storage · high confidence

New use-case implementations for authentication and note management

The application now includes concrete implementations for user authentication (sign-in and sign-up) and note operations (create, read, update, delete, and mark as finished). These use cases handle HTTP communication with the backend API, manage error responses, and enforce input validation. Additionally, a decorator is introduced to automatically invalidate the notes cache after relevant operations, ensuring data consistency for the user.

src/use-cases · high confidence

New validation infrastructure with builder and composite patterns

The presentation layer now includes a new validation framework in src/presentation/validation, introducing a ValidationBuilder for chaining field rules (required, email, password, min/max length) and a ValidationComposite to execute multiple validators on a single input. This change adds specific validators for email format, password complexity (requiring numbers, upper/lowercase letters, and special characters, and rejecting spaces), and field length constraints, along with corresponding error classes (InvalidFieldError, RequiredFieldError) and a FieldValidation contract to standardize validation logic.

src/presentation/validation · high confidence

Architecture

Expose HTTP client and storage gateway interfaces

The application now exposes the HTTP client and storage gateway interfaces through a centralized index file, allowing use-case layers to import these dependencies from a single location.

src/use-cases/ports/gateways · high confidence

Behavioural changes

Added input validation factories for sign-in, sign-up, and note creation

New validation factory functions have been introduced for the sign-in, sign-up, and create-note flows, centralizing field-level constraints. Sign-in now validates that the email is a valid format (5–320 characters) and the password is 11–24 characters long. Sign-up enforces name and lastname fields of 5–320 characters, along with the same email and password rules. Note creation requires a title (1–120 characters) and a description (1–1000 characters). These factories are exported from the validations index for use by their respective presentation components.

src/main/factories/presentation/validations · high confidence

Introduces ReduxRouterDomProvider for unified state and routing

The application now uses a new \ReduxRouterDomProvider\ component to wrap the root of the app, which simultaneously provides the Redux store (via \react-redux\) and the React Router DOM browser router. This change centralizes the setup of state management and client-side routing, ensuring that all routed views have access to the global Redux store without needing separate provider components.

src/main/adapters · high confidence

Test coverage

Added integration tests for Footer, Header, and Paginated Todo List components; Added integration tests for application pages; Added integration tests for molecule components; Added test builders for Note and User models; Added test doubles for use cases, gateways, and validators; Added unit tests for FindNotesCacheUseCaseProxy; Added unit tests for Invalidate Notes Cache Decorator; Added unit tests for cache note strategies and visitor; Added unit tests for note and authentication use cases; Added unit tests for presentation validation components; Added unit tests for use-case error classes; New test utilities for mocking API and rendering components.

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

How this codebase got here

This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.

Score

  • CAI 63 → 53 (-9.6)
  • Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

Lenses

  • Code Health 93 → 95 (+2.2)
  • Architecture 92 → 92 (-0.2)
  • Maturity 51 → 51 (+0.0)
  • Readiness 79 → 58 (-20.8)
  • Security 70 → 78 (+7.6)
  • Accessibility 65 → 43 (-22.3)

Resolved (22)

  • Coverage not included — suite not readable by the collector
  • Dependency hygiene not measured — no supported dependency manifest was read
  • Dormant codebase
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • No exposed public API
  • Scanner failed to run — not a clean result
  • Test reliability not included
  • The README is a single page with no architecture, design, or usage description; it states the project's purpose ('show how to create an WEB APP') without explaining what the app does or its structure. (README.md)
  • …and 2 more

New (32)

  • Coverage not measured — JavaScript/TypeScript suite
  • Dependency hygiene PARTLY measured — npm pinning read, dependency currency not (no committed lockfile, so no resolved version to grade)
  • Documentation: no installation or build instructions (README.md)
  • Documentation: no usage examples (README.md)
  • End-of-life runtime: Node.js 18
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • …and 12 more

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

Survey your own repository

gftf2011/clean-react-todolist 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.

About this page

  • The score is its most recent published measurement, taken on 20 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
  • Measured at commit 2835c9a42e08fed219ea289bd520264e8b8da7ad — the exact code this score is about.
  • Scored under rubric-2026.09.15 — the same rubric and the same method as every other entry in this index.
  • Measured by watchdog.canine.dev using codehealth-analyzer preprod-28e75b8e3254.