Epic: Evolve CPP Task Manager into a Robust Task Management Application

[Aaqibhafeezkhan]

Overview

Establish a structured roadmap for evolving the current C++ task manager into a maintainable, testable, and extensible task management application.

Goals

• Strengthen the task domain model and business rules.
• Separate presentation, application logic, domain logic, and persistence concerns.
• Improve task lifecycle operations and validation.
• Make persistence reliable and extensible.
• Expand automated test coverage.
• Improve usability, error handling, and documentation.
• Keep the project portable and straightforward to build with CMake.

Workstreams

1. Domain & Architecture

• Refine Task and TaskManager responsibilities.
• Separate task data, business operations, persistence, and user interaction where appropriate.
• Introduce clear interfaces between presentation and application/business layers.

2. Task Lifecycle & Features

• Create, update, complete, delete, and list tasks consistently.
• Add validation for task identifiers and required fields.
• Support useful task attributes such as priority, status, and due dates where appropriate.

3. Persistence

• Formalize loading and saving task data.
• Handle malformed or missing persistence data safely.
• Keep persistence implementation replaceable without coupling it to the UI.

4. Testing & Quality

• Expand unit tests around task behavior and manager operations.
• Add coverage for validation, persistence boundaries, and failure paths.
• Keep builds reproducible through CMake without introducing GitHub Actions.

5. User Experience

• Improve console navigation and command flow.
• Provide clear success and error messages.
• Handle invalid input without terminating unexpectedly.

6. Documentation

• Keep README documentation aligned with the actual implementation.
• Document architecture, build instructions, supported functionality, and future work.
• Maintain the existing documentation structure as the project grows.

Phase Status

• Phase 1 — Domain model and application/service architecture — Issue Refactor task domain and application architecture #2 / PR Refactor task domain and application architecture #3
• Phase 2 — Task validation and lifecycle rules — Issue Phase 2: Add task validation and lifecycle rules #4 / PR feat: enforce task validation and lifecycle rules #5
• Phase 3 — Persistence hardening and failure handling — Issue Phase 3: Harden task persistence and failure handling #6 / PR feat: harden task persistence #7
• Phase 4 — Console UX and command input handling — Issue Phase 4: Harden console UX and command input handling #8 / PR feat: harden console command handling #9
• Phase 5 — Expanded task lifecycle operations — Issue Phase 5: Expanded task lifecycle operations #10 / PR feat: implement Phase 5 task lifecycle operations #11
• Phase 6 — Task metadata, prioritization and filtering — Issue Phase 6 — Task metadata, prioritization and filtering #12 / PR feat: implement Phase 6 task metadata and filtering #13
• Phase 7 — Task due dates and overdue filtering — Issue Phase 7 — Task due dates and overdue filtering #14 / PR feat: Phase 7 task due dates and overdue filtering #15
• Phase 8 — Service-level business-logic test coverage — Issue Phase 8 — Expand automated business-logic test coverage #16 / PR Phase 8 — Expand automated business-logic test coverage #16
• Phase 9 — CLI contract and integration regression coverage — Issue Phase 9 — CLI contract and integration regression coverage #17 / PR test: add CLI contract regression coverage #18

Definition of Done

• Responsibilities are clearly separated and maintainable.
• Core task operations have predictable behavior and validation.
• Persistence is reliable and decoupled from presentation logic.
• Important behavior is covered by automated tests.
• The application remains buildable with the existing CMake workflow.
• Documentation reflects implemented functionality and explicitly identifies TBD work.
• No GitHub Actions are introduced; deployment/build execution remains manual.

Collaboration

This epic is assigned to aaqib-hafeez-khan-in and shruticparmar for shared ownership and implementation.

Workflow

Phase → Issue → implementation PR against main → request shruticparmar → self-review as a normal COMMENT → merge → update Epic.

Scope

Changes should remain focused on the task manager roadmap. Individual child issues should use focused PRs and avoid unrelated refactoring.