# PCC Student Task Manager — GitLab Epics & Issues 11 epics · 51 issues · 212 man-hours total ## How to enter 1. **Labels first** (Group → Manage → Labels): `epic::categories`, `epic::interface`, `epic::optional`, `epic::persistence`, `epic::planning`, `epic::prioritization`, `epic::quality`, `epic::semester`, `epic::setup`, `epic::tasks`, `epic::views`, `optional`, `type::documentation`, `type::feature`, `type::infrastructure`, `type::planning`, `type::testing`. 2. **Epics** (Group → Plan → Epics → New epic): paste the title, paste the description block, and add the label. 3. **Issues** (Project → Issues → New issue): paste the title and the description block. The `/estimate` and `/label` lines at the bottom are GitLab quick actions, so they set the time estimate and labels when you save. Then set the **Epic** in the issue sidebar. - Every issue goes in the team's task-manager project, **except** the Planning Phase issues, which go in **Grade Tracking Application**. 4. **Merge request** (Grade Tracking Application): create branch `docs/requirements-v2`, upload the SRS .docx to `docs/`, and open an MR titled *Requirement documentation: System Specifications v2* with `Closes #` in its description. ## Summary | # | Epic | Issues | Man-hours | |---|---|---|---| | 1 | Planning Phase | 3 | 24 | | 2 | Data Model & Persistence | 6 | 29 | | 3 | First-Run Setup & Course Settings | 3 | 14 | | 4 | Task Lifecycle Management | 8 | 28 | | 5 | Categories & Priority Levels | 3 | 12 | | 6 | Task Views & Display | 6 | 15 | | 7 | Prioritization & Alerts | 5 | 16 | | 8 | Console Interface & Input Validation | 3 | 15 | | 9 | Semester Lifecycle | 2 | 7 | | 10 | Build, Quality & Maintainability | 6 | 27 | | 11 | Optional Enhancements | 6 | 25 | | | **Total** | **51** | **212** | --- ## Epic 1: Planning Phase **Labels:** `epic::planning` **Description:** ~~~markdown ## Overview Requirements gathering, specification, review, and backlog setup for the PCC Student Task Manager. ## Scope - Second-revision System Specifications document (SRS v2) - Requirements validation follow-up with stakeholders - GitLab epics/issues aligned to the SRS, with man-hour estimates ## Requirements covered FR-014, FR-017, FR-023, FR-025, FR-028 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | Requirement documentation | — | 15 | | Create epics and issues aligned to requirements | — | 5 | | Resolve Part 4A requirements-validation questions | FR-014, FR-017, FR-023, FR-025, FR-028 | 4 | | **Total** | | **24** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 1.1 Requirement documentation **Project:** Grade Tracking Application · **Epic:** Planning Phase · **Estimate:** 15 h · **Labels:** `type::documentation` ~~~markdown ## Summary Refine the initial System Specifications into a second version using instructor feedback, and commit it to the repository via merge request. ## Requirements implemented _Process work; no product requirement._ ## Implementation notes - Source: *PCC Task Manager - System Specifications - Team 5.docx* (revisions 2026-09-27, 2026-10-03, 2026-10-04, 2026-10-05). - Functional requirements are numbered FR-001 to FR-037 (FR-032 to FR-037 optional); non-functional requirements NFR-001 to NFR-020. - Estimate basis: 5 members x ~3 h (drafting, two review meetings, revisions). ## Acceptance criteria - [ ] SRS v2 incorporates instructor feedback - [ ] Every requirement has a unique ID - [ ] Document committed on a feature branch and attached to a merge request - [ ] Merge request reviewed by at least one other team member ## Estimate **15 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). ## Requirements traceability matrix | Requirement | Epic | Issue(s) | |---|---|---| | FR-001 | First-Run Setup & Course Settings | First-run setup wizard | | FR-002 | Data Model & Persistence | Data file format and serializer; Load data file on startup (CRLF/LF tolerant); Atomic save after every change | | FR-003 | Data Model & Persistence | Save-failure notification, retry, and alternate path | | FR-004 | Data Model & Persistence; Task Lifecycle Management | Define Task and CourseSettings data structures; Quick-add a task from a name only | | FR-005 | Data Model & Persistence; First-Run Setup & Course Settings; Task Lifecycle Management | Define Task and CourseSettings data structures; Store and edit course information; Edit any user-entered task field | | FR-006 | Task Lifecycle Management | Soft-delete with confirmation and restore | | FR-007 | Task Lifecycle Management | Log an already-completed task | | FR-008 | Task Views & Display | Single-task detail view; Current, completed, and all-task lists; Show/hide completed and deleted tasks | | FR-009 | Prioritization & Alerts | Next-task ranking algorithm | | FR-010 | Prioritization & Alerts; Task Views & Display | Remaining-work total; Main-screen next task and remaining-time summary | | FR-011 | Prioritization & Alerts | Due-soon and overdue alert banner | | FR-012 | Console Interface & Input Validation | Validated input helpers with re-prompt | | FR-013 | Task Lifecycle Management | Quick-add a task from a name only; Full task entry (due date, category, priority, estimate) | | FR-014 | Data Model & Persistence; Planning Phase; Task Lifecycle Management | Resolve Part 4A requirements-validation questions; Define Task and CourseSettings data structures; Full task entry (due date, category, priority, estimate) | | FR-015 | Categories & Priority Levels; Semester Lifecycle | User-defined task categories; Carry over categories and priority levels to the new semester | | FR-016 | Categories & Priority Levels | Category default priority with per-task override | | FR-017 | Categories & Priority Levels; Planning Phase; Semester Lifecycle | Resolve Part 4A requirements-validation questions; User-defined priority levels; Carry over categories and priority levels to the new semester | | FR-018 | Data Model & Persistence; First-Run Setup & Course Settings | Define Task and CourseSettings data structures; Store and edit course information | | FR-019 | Task Views & Display | Current, completed, and all-task lists | | FR-020 | Data Model & Persistence; Task Lifecycle Management | Define Task and CourseSettings data structures; Task status and explicit-only completion | | FR-021 | Semester Lifecycle; Task Lifecycle Management | Task status and explicit-only completion; Complete course: archive the semester data file | | FR-022 | Task Views & Display | Show/hide completed and deleted tasks | | FR-023 | Data Model & Persistence; Planning Phase; Task Lifecycle Management | Resolve Part 4A requirements-validation questions; Define Task and CourseSettings data structures; Completion timestamp with custom override | | FR-024 | Task Lifecycle Management | Log an already-completed task | | FR-025 | Planning Phase; Prioritization & Alerts | Resolve Part 4A requirements-validation questions; Next-task ranking algorithm; Ranking algorithm test cases | | FR-026 | Prioritization & Alerts | Next-task ranking algorithm; Ranking algorithm test cases | | FR-027 | Prioritization & Alerts | Overdue label | | FR-028 | Planning Phase; Semester Lifecycle | Resolve Part 4A requirements-validation questions; Complete course: archive the semester data file; Carry over categories and priority levels to the new semester | | FR-029 | Data Model & Persistence | Dynamic task collection (unlimited tasks) | | FR-030 | First-Run Setup & Course Settings | Central Time date/time utilities | | FR-031 | Console Interface & Input Validation | Main menu loop and command dispatch | | FR-032 | Optional Enhancements | Sort and filter by category, priority, and status | | FR-033 | Optional Enhancements | Completed-work summary | | FR-034 | Optional Enhancements | Log actual time spent against the estimate | | FR-035 | Optional Enhancements | Latest-start-time warning | | FR-036 | Optional Enhancements | Subtasks and phases via task links | | FR-037 | Optional Enhancements | Mass and recurring task entry | | NFR-001 | Build, Quality & Maintainability; Data Model & Persistence | Atomic save after every change; Acceptance test plan and execution | | NFR-002 | Build, Quality & Maintainability; Data Model & Persistence | Save-failure notification, retry, and alternate path; Acceptance test plan and execution | | NFR-003 | Build, Quality & Maintainability; Task Lifecycle Management | Quick-add a task from a name only; Acceptance test plan and execution | | NFR-004 | Console Interface & Input Validation | Validated input helpers with re-prompt | | NFR-005 | Console Interface & Input Validation | Customizable menu | | NFR-006 | Build, Quality & Maintainability; Data Model & Persistence | Load data file on startup (CRLF/LF tolerant); Performance verification | | NFR-007 | Build, Quality & Maintainability; Task Views & Display | Current, completed, and all-task lists; Performance verification | | NFR-008 | Build, Quality & Maintainability; Data Model & Persistence | Atomic save after every change; Performance verification | | NFR-009 | Build, Quality & Maintainability | Acceptance test plan and execution | | NFR-010 | Build, Quality & Maintainability | Project skeleton and GCC build script; Acceptance test plan and execution | | NFR-011 | Data Model & Persistence | Load data file on startup (CRLF/LF tolerant) | | NFR-012 | Build, Quality & Maintainability | Coding standards: naming and function comments; README and user guide | | NFR-013 | Build, Quality & Maintainability | Coding standards: naming and function comments | | NFR-014 | Build, Quality & Maintainability | Project skeleton and GCC build script; GitLab CI warning gate | | NFR-015 | Console Interface & Input Validation | Main menu loop and command dispatch | | NFR-016 | Task Views & Display | Consistent task row formatter | | NFR-017 | Task Lifecycle Management | Default due date and notification | | NFR-018 | Prioritization & Alerts | Main-screen next task and remaining-time summary | | NFR-019 | Task Lifecycle Management | Soft-delete with confirmation and restore | | NFR-020 | Task Views & Display | Empty-list messages | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 15h /label ~"type::documentation" ~~~ ### 1.2 Create epics and issues aligned to requirements **Project:** Grade Tracking Application · **Epic:** Planning Phase · **Estimate:** 5 h · **Labels:** `type::planning` ~~~markdown ## Summary Break the SRS into GitLab epics (systems) and issues (implementation work), each with a man-hour estimate and requirement traceability. ## Requirements implemented _Process work; no product requirement._ ## Implementation notes - Every FR/NFR ID must be referenced by at least one issue. - Estimates are total man-hours (2 people x 1 h = 2 h). ## Acceptance criteria - [ ] One epic per major subsystem - [ ] Each issue lists the requirement IDs it implements - [ ] Each issue has a time estimate set ## Estimate **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 5h /label ~"type::planning" ~~~ ### 1.3 Resolve Part 4A requirements-validation questions **Project:** Grade Tracking Application · **Epic:** Planning Phase · **Estimate:** 4 h · **Labels:** `type::planning` ~~~markdown ## Summary Get answers from Dr. Sparks on the five open validation questions and fold the answers back into the SRS. ## Requirements implemented - **FR-014** — The system shall allow students to input an estimated completion time for a task, which is user-specified, defaults to 0, and may be 0 for reminder-only tasks (for example, “bring calculator”). - **FR-017** — The system shall allow students to define their own priority levels. - **FR-023** — The system shall record the date and time a task was completed and shall allow the student to enter a custom completion date and time. - **FR-025** — The system shall indicate which task the student should work on next, ranked by: (1) due date and time first, (2) the student’s priority level, (3) estimated completion time as a slight adjustment. - **FR-028** — The system shall provide a “complete course” option that archives the semester’s file, so the next launch starts a new semester. ## Implementation notes - Reminder-only (0 h) tasks: ranked with work tasks or shown separately? - Optional notes/description field per task? - Mark tasks completed after the due date as "completed late"? - Number/order of priority levels: student-defined or built-in? - Do categories and priority levels carry over to the next semester? ## Acceptance criteria - [ ] All five questions answered and recorded - [ ] SRS updated with a new revision row - [ ] Affected issues updated ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::planning" ~~~ --- ## Epic 2: Data Model & Persistence **Labels:** `epic::persistence` **Description:** ~~~markdown ## Overview In-memory data model and the on-disk data file: structures, file format, load/save, crash safety, and failure recovery. Reliability is the top-ranked NFR category, so this epic is foundational. ## Scope - Task and course-settings structures - Unbounded task storage - Data file format, loader and saver - Atomic saves and save-failure recovery ## Requirements covered FR-002, FR-003, FR-004, FR-005, FR-014, FR-018, FR-020, FR-023, FR-029, NFR-001, NFR-002, NFR-006, NFR-008, NFR-011 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | Define Task and CourseSettings data structures | FR-004, FR-005, FR-014, FR-018, FR-020, FR-023 | 4 | | Dynamic task collection (unlimited tasks) | FR-029 | 3 | | Data file format and serializer | FR-002 | 6 | | Load data file on startup (CRLF/LF tolerant) | FR-002, NFR-006, NFR-011 | 6 | | Atomic save after every change | FR-002, NFR-001, NFR-008 | 5 | | Save-failure notification, retry, and alternate path | FR-003, NFR-002 | 5 | | **Total** | | **29** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 2.1 Define Task and CourseSettings data structures **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 4 h · **Labels:** `type::feature` ~~~markdown ## Summary Define the C structs for a task and for course/settings data, shared by every other module. ## Requirements implemented - **FR-004** — The system shall create a task from a name alone. - **FR-005** — The system shall allow any user-entered field of a task to be updated after it has been created. - **FR-014** — The system shall allow students to input an estimated completion time for a task, which is user-specified, defaults to 0, and may be 0 for reminder-only tasks (for example, “bring calculator”). - **FR-018** — The system shall store the course information (student name, course name, course number, instructor) once, so the student does not need to re-enter it. - **FR-020** — The system shall allow students to mark a task status as not started, in progress, or completed. - **FR-023** — The system shall record the date and time a task was completed and shall allow the student to enter a custom completion date and time. ## Implementation notes - Task: id, name, category id, priority id, due date/time, estimate (minutes), status enum, completed-at, hidden/deleted flag, created-at. - CourseSettings: student name, course name, course number, instructor, semester end date, menu config. - Store times as `time_t` (UTC) and convert to Central Time only for input/output. ## Acceptance criteria - [ ] Header compiles cleanly under -Wall -Wextra - [ ] Every field has a comment - [ ] Reviewed by one other member ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::feature" ~~~ ### 2.2 Dynamic task collection (unlimited tasks) **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 3 h · **Labels:** `type::feature` ~~~markdown ## Summary Growable array (`realloc`, doubling) holding tasks, with add/find-by-id/remove helpers. ## Requirements implemented - **FR-029** — The system shall support an unlimited number of tasks. ## Implementation notes - No compile-time cap on task count. - Allocation failure is reported, never silently ignored. ## Acceptance criteria - [ ] 10,000 tasks can be added and listed - [ ] No leaks under a simple add/remove loop ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::feature" ~~~ ### 2.3 Data file format and serializer **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 6 h · **Labels:** `type::feature` ~~~markdown ## Summary Specify a versioned, line-oriented text format for settings, categories, priority levels, and tasks, and write it out. ## Requirements implemented - **FR-002** — The system shall save all tasks and settings to a data file and load them on startup. ## Implementation notes - First line holds a format version so future changes can migrate old files. - Escape delimiter characters inside task names. - Document the format in the README. ## Acceptance criteria - [ ] Round-trip save then load reproduces identical data - [ ] Format documented ## Estimate **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 6h /label ~"type::feature" ~~~ ### 2.4 Load data file on startup (CRLF/LF tolerant) **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 6 h · **Labels:** `type::feature` ~~~markdown ## Summary Parse the data file at launch, accepting both Windows (CRLF) and Linux (LF) line endings. ## Requirements implemented - **FR-002** — The system shall save all tasks and settings to a data file and load them on startup. - **NFR-006** — The system shall launch without a noticeable delay. - **NFR-011** — The system shall correctly read data files that use either Windows or Linux line endings. ## Implementation notes - Strip a trailing `\r` from every line before parsing. - Missing file means first run, which triggers the setup wizard. - Malformed lines: report the line number and skip, keeping the rest of the data. ## Acceptance criteria - [ ] Files saved with CRLF and with LF both load correctly - [ ] Startup with 1,000 tasks shows no noticeable delay ## Estimate **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 6h /label ~"type::feature" ~~~ ### 2.5 Atomic save after every change **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 5 h · **Labels:** `type::feature` ~~~markdown ## Summary Save immediately after every create/update/delete, using write-to-temp, flush, then rename so a crash never corrupts the last good file. ## Requirements implemented - **FR-002** — The system shall save all tasks and settings to a data file and load them on startup. - **NFR-001** — The system shall not lose any previously saved tasks if the program terminates unexpectedly. - **NFR-008** — The system shall save changes to the data file within one second after a task is created, updated, or deleted. ## Implementation notes - Write `tasks.dat.tmp`, `fflush` + `_commit`/`fsync`, then replace `tasks.dat` (on Windows, `MoveFileEx` with `MOVEFILE_REPLACE_EXISTING`). - Keep the previous file as `tasks.dat.bak`. ## Acceptance criteria - [ ] Killing the process mid-save leaves a loadable file - [ ] Save completes within 1 s of the change ## Estimate **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 5h /label ~"type::feature" ~~~ ### 2.6 Save-failure notification, retry, and alternate path **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 5 h · **Labels:** `type::feature` ~~~markdown ## Summary When a save fails, tell the user why, retry once, and if that fails keep the data in memory and prompt for an alternate save path. ## Requirements implemented - **FR-003** — The system shall notify the user when a save fails and retry the save. If the retry fails, it shall keep the in-memory data and offer an alternate path. - **NFR-002** — The system shall recover from a failed save and tell the user what happened. ## Implementation notes - Report the `strerror(errno)` text in plain language. - The alternate path is remembered for the rest of the session. ## Acceptance criteria - [ ] Read-only or locked data file triggers the notify, retry, alternate-path flow - [ ] No data is lost during the flow ## Estimate **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 5h /label ~"type::feature" ~~~ --- ## Epic 3: First-Run Setup & Course Settings **Labels:** `epic::setup` **Description:** ~~~markdown ## Overview First-run wizard, stored course information, and Central Time date/time handling used across the application. ## Scope - Setup wizard - Course info stored once and editable - Central Time conversion utilities ## Requirements covered FR-001, FR-005, FR-018, FR-030 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | First-run setup wizard | FR-001 | 5 | | Store and edit course information | FR-018, FR-005 | 3 | | Central Time date/time utilities | FR-030 | 6 | | **Total** | | **14** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 3.1 First-run setup wizard **Project:** Task manager project · **Epic:** First-Run Setup & Course Settings · **Estimate:** 5 h · **Labels:** `type::feature` ~~~markdown ## Summary On first launch (no data file), prompt for student name, course name, course number, instructor, and semester end date. ## Requirements implemented - **FR-001** — The system shall, on the first run, present a setup wizard that captures the student’s name, course name and number, instructor, and semester end date. ## Implementation notes - Uses the validated input helpers. - Semester end date must be in the future. ## Acceptance criteria - [ ] Wizard appears only when no data file exists - [ ] Entered values persist and are not asked again ## Estimate **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 5h /label ~"type::feature" ~~~ ### 3.2 Store and edit course information **Project:** Task manager project · **Epic:** First-Run Setup & Course Settings · **Estimate:** 3 h · **Labels:** `type::feature` ~~~markdown ## Summary Course information is entered once, shown in the header, and can be edited from a settings menu. ## Requirements implemented - **FR-018** — The system shall store the course information (student name, course name, course number, instructor) once, so the student does not need to re-enter it. - **FR-005** — The system shall allow any user-entered field of a task to be updated after it has been created. ## Acceptance criteria - [ ] Course info appears in the program header - [ ] Edits are saved immediately ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::feature" ~~~ ### 3.3 Central Time date/time utilities **Project:** Task manager project · **Epic:** First-Run Setup & Course Settings · **Estimate:** 6 h · **Labels:** `type::feature` ~~~markdown ## Summary Parse, format, and compare dates/times in US Central Time, including the daylight-saving changeover. ## Requirements implemented - **FR-030** — The system shall use Central Time for all dates and times. ## Implementation notes - MinGW's C runtime does not understand IANA zone names, so implement the US DST rule (2nd Sunday of March to 1st Sunday of November) over UTC `time_t`. - Single input format (e.g. `YYYY-MM-DD HH:MM`) with a date-only shortcut. ## Acceptance criteria - [ ] Unit tests cover dates either side of both DST transitions - [ ] All displayed times are Central ## Estimate **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 6h /label ~"type::feature" ~~~ --- ## Epic 4: Task Lifecycle Management **Labels:** `epic::tasks` **Description:** ~~~markdown ## Overview Creating, editing, completing, deleting, and restoring tasks, including retroactive logging of completed work. ## Scope - Quick add and full add - Edit any field - Status and explicit completion - Soft delete and restore - Default due date ## Requirements covered FR-004, FR-005, FR-006, FR-007, FR-013, FR-014, FR-020, FR-021, FR-023, FR-024, NFR-003, NFR-017, NFR-019 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | Quick-add a task from a name only | FR-004, FR-013, NFR-003 | 4 | | Full task entry (due date, category, priority, estimate) | FR-013, FR-014 | 5 | | Edit any user-entered task field | FR-005 | 5 | | Soft-delete with confirmation and restore | FR-006, NFR-019 | 4 | | Task status and explicit-only completion | FR-020, FR-021 | 3 | | Completion timestamp with custom override | FR-023 | 3 | | Log an already-completed task | FR-007, FR-024 | 2 | | Default due date and notification | NFR-017 | 2 | | **Total** | | **28** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 4.1 Quick-add a task from a name only **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 4 h · **Labels:** `type::feature` ~~~markdown ## Summary Create a task by typing only its name; all other fields take defaults. ## Requirements implemented - **FR-004** — The system shall create a task from a name alone. - **FR-013** — The system shall allow students to create a new task. - **NFR-003** — The system shall allow the user to add a new task in no more than three menu selections/prompts. ## Implementation notes - Path: main menu, then Add, then name: three prompts at most. ## Acceptance criteria - [ ] Task created with a name only in 3 prompts or fewer - [ ] Defaults applied and shown in the confirmation ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::feature" ~~~ ### 4.2 Full task entry (due date, category, priority, estimate) **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 5 h · **Labels:** `type::feature` ~~~markdown ## Summary Optional extended entry for due date/time, category, priority override, and estimated time (defaults to 0; 0 means a reminder-only task). ## Requirements implemented - **FR-013** — The system shall allow students to create a new task. - **FR-014** — The system shall allow students to input an estimated completion time for a task, which is user-specified, defaults to 0, and may be 0 for reminder-only tasks (for example, “bring calculator”). ## Implementation notes - Every field can be skipped to accept its default. ## Acceptance criteria - [ ] Estimate defaults to 0 and accepts 0 - [ ] Category default priority is pre-filled ## Estimate **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 5h /label ~"type::feature" ~~~ ### 4.3 Edit any user-entered task field **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 5 h · **Labels:** `type::feature` ~~~markdown ## Summary Select a task, then pick a field to change; the change is validated and saved. ## Requirements implemented - **FR-005** — The system shall allow any user-entered field of a task to be updated after it has been created. ## Acceptance criteria - [ ] Each user-entered field can be edited - [ ] Invalid edits are rejected with a re-prompt ## Estimate **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 5h /label ~"type::feature" ~~~ ### 4.4 Soft-delete with confirmation and restore **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 4 h · **Labels:** `type::feature` ~~~markdown ## Summary Deleting hides the task after a y/n confirmation; hidden tasks can be listed and restored. ## Requirements implemented - **FR-006** — The system shall soft-delete a task (hide it) and allow restoring it. - **NFR-019** — The system shall ask for confirmation before deleting a task. ## Implementation notes - Tasks are never physically removed from the data file. ## Acceptance criteria - [ ] Delete asks for confirmation - [ ] Deleted task disappears from default lists - [ ] Restore brings it back unchanged ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::feature" ~~~ ### 4.5 Task status and explicit-only completion **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 3 h · **Labels:** `type::feature` ~~~markdown ## Summary Status is Not Started, In Progress, or Completed, and only an explicit student action changes it. ## Requirements implemented - **FR-020** — The system shall allow students to mark a task status as not started, in progress, or completed. - **FR-021** — The system shall ensure that a task is only completed by an explicit student action; it is never auto-completed or auto-deleted. ## Implementation notes - No code path auto-completes or auto-deletes a task (including overdue tasks and the course archive). ## Acceptance criteria - [ ] Status can be set to each of the three values - [ ] Overdue tasks remain incomplete until the student acts ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::feature" ~~~ ### 4.6 Completion timestamp with custom override **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 3 h · **Labels:** `type::feature` ~~~markdown ## Summary Record the current Central Time when a task is completed, and let the student enter a different completion date/time. ## Requirements implemented - **FR-023** — The system shall record the date and time a task was completed and shall allow the student to enter a custom completion date and time. ## Acceptance criteria - [ ] Completed-at defaults to now - [ ] Custom completed-at is accepted and validated ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::feature" ~~~ ### 4.7 Log an already-completed task **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 2 h · **Labels:** `type::feature` ~~~markdown ## Summary Create a task directly in the Completed state with a completion time, for work done earlier. ## Requirements implemented - **FR-007** — The system shall allow a task to be entered directly as already completed, with a completion time. - **FR-024** — The system shall allow students to create a task that is already completed to log work that was done earlier. ## Acceptance criteria - [ ] Task appears only in the completed list - [ ] Completion time is stored as entered ## Estimate **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 2h /label ~"type::feature" ~~~ ### 4.8 Default due date and notification **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 2 h · **Labels:** `type::feature` ~~~markdown ## Summary When no due date is given, assign a default and tell the student which date was used. ## Requirements implemented - **NFR-017** — The system shall notify the user when a task is assigned a default due date. ## Implementation notes - Proposed default: semester end date. The SRS does not yet specify the default, so confirm it under the Planning Phase validation issue. ## Acceptance criteria - [ ] A message names the default date that was assigned ## Estimate **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 2h /label ~"type::feature" ~~~ --- ## Epic 5: Categories & Priority Levels **Labels:** `epic::categories` **Description:** ~~~markdown ## Overview Student-defined task categories and priority levels, with per-category default priorities. ## Scope - Priority level CRUD and ordering - Category CRUD - Category default priority with task override ## Requirements covered FR-015, FR-016, FR-017 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | User-defined priority levels | FR-017 | 5 | | User-defined task categories | FR-015 | 4 | | Category default priority with per-task override | FR-016 | 3 | | **Total** | | **12** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 5.1 User-defined priority levels **Project:** Task manager project · **Epic:** Categories & Priority Levels · **Estimate:** 5 h · **Labels:** `type::feature` ~~~markdown ## Summary Create, rename, reorder, and delete priority levels; the order defines rank for the next-task algorithm. ## Requirements implemented - **FR-017** — The system shall allow students to define their own priority levels. ## Implementation notes - Block deleting a level that tasks still use, or reassign those tasks first. - Seed defaults: High / Medium / Low. ## Acceptance criteria - [ ] Levels can be added, renamed, reordered, and deleted - [ ] Ranking uses the new order immediately ## Estimate **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 5h /label ~"type::feature" ~~~ ### 5.2 User-defined task categories **Project:** Task manager project · **Epic:** Categories & Priority Levels · **Estimate:** 4 h · **Labels:** `type::feature` ~~~markdown ## Summary Create, rename, and delete categories instead of a fixed list of task types. ## Requirements implemented - **FR-015** — The system shall allow students to define their own task categories instead of a fixed list of types. ## Implementation notes - Seed defaults: Homework, Quiz, Test, Project, Reminder. ## Acceptance criteria - [ ] Categories can be added, renamed, and deleted - [ ] Tasks show their category name ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::feature" ~~~ ### 5.3 Category default priority with per-task override **Project:** Task manager project · **Epic:** Categories & Priority Levels · **Estimate:** 3 h · **Labels:** `type::feature` ~~~markdown ## Summary Each category may carry a default priority applied to new tasks; any task can override it. ## Requirements implemented - **FR-016** — The system shall allow a category to have a default priority, which the student can override on any task. ## Acceptance criteria - [ ] New task inherits its category's default - [ ] Override persists after save/load ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::feature" ~~~ --- ## Epic 6: Task Views & Display **Labels:** `epic::views` **Description:** ~~~markdown ## Overview All read-only presentation: task detail, the current/completed/all lists, visibility toggles, consistent formatting, and the remaining-work total. ## Scope - Detail view - Three lists - Show/hide completed and deleted - Consistent row format - Empty-list messages - Remaining work ## Requirements covered FR-008, FR-010, FR-019, FR-022, NFR-007, NFR-016, NFR-020 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | Consistent task row formatter | NFR-016 | 3 | | Single-task detail view | FR-008 | 2 | | Current, completed, and all-task lists | FR-008, FR-019, NFR-007 | 4 | | Show/hide completed and deleted tasks | FR-008, FR-022 | 3 | | Empty-list messages | NFR-020 | 1 | | Remaining-work total | FR-010 | 2 | | **Total** | | **15** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 6.1 Consistent task row formatter **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 3 h · **Labels:** `type::feature` ~~~markdown ## Summary One function that prints a task row with name, category, due date, status, priority, and estimated time in fixed-width columns. ## Requirements implemented - **NFR-016** — The system shall display tasks in a consistent format, showing each task name, type, due date, status, priority, and estimated time. ## Implementation notes - Every list view uses this function. ## Acceptance criteria - [ ] All lists share identical columns - [ ] Long names are truncated cleanly ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::feature" ~~~ ### 6.2 Single-task detail view **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 2 h · **Labels:** `type::feature` ~~~markdown ## Summary Show every field of one selected task. ## Requirements implemented - **FR-008** — The system shall show all fields of one task and list all tasks, with options to show or hide completed and hidden tasks, plus a separate completed list. ## Acceptance criteria - [ ] All fields, including completed-at, are shown ## Estimate **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 2h /label ~"type::feature" ~~~ ### 6.3 Current, completed, and all-task lists **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 4 h · **Labels:** `type::feature` ~~~markdown ## Summary Three list commands: current (incomplete), completed, and all. ## Requirements implemented - **FR-008** — The system shall show all fields of one task and list all tasks, with options to show or hide completed and hidden tasks, plus a separate completed list. - **FR-019** — The system shall allow students to view three lists: current (incomplete) tasks, completed tasks, and all tasks. - **NFR-007** — The system shall remain responsive while displaying or updating the student’s tasks. ## Acceptance criteria - [ ] Each list shows the correct subset - [ ] Lists render instantly with 1,000 tasks ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::feature" ~~~ ### 6.4 Show/hide completed and deleted tasks **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 3 h · **Labels:** `type::feature` ~~~markdown ## Summary Toggles controlling whether completed and soft-deleted tasks appear in the all-tasks list. ## Requirements implemented - **FR-008** — The system shall show all fields of one task and list all tasks, with options to show or hide completed and hidden tasks, plus a separate completed list. - **FR-022** — The system shall allow students to hide and unhide completed tasks. ## Implementation notes - Toggle state persists in settings. ## Acceptance criteria - [ ] Both toggles work independently - [ ] State survives a restart ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::feature" ~~~ ### 6.5 Empty-list messages **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 1 h · **Labels:** `type::feature` ~~~markdown ## Summary Print a friendly message (e.g. "No completed tasks yet.") instead of an empty table. ## Requirements implemented - **NFR-020** — The system shall display a message instead of an empty list when there are no tasks to show. ## Acceptance criteria - [ ] Every list view has an empty-state message ## Estimate **1 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 1h /label ~"type::feature" ~~~ ### 6.6 Remaining-work total **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 2 h · **Labels:** `type::feature` ~~~markdown ## Summary Sum the estimated time of all incomplete, non-deleted tasks and display it in hours and minutes. ## Requirements implemented - **FR-010** — The system shall total the estimated time of uncompleted tasks (remaining work). ## Acceptance criteria - [ ] Total excludes completed and deleted tasks - [ ] Total updates after every change ## Estimate **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 2h /label ~"type::feature" ~~~ --- ## Epic 7: Prioritization & Alerts **Labels:** `epic::prioritization` **Description:** ~~~markdown ## Overview The next-task recommendation algorithm, overdue handling, and due-soon/overdue alerts shown without any background process. ## Scope - Ranking comparator - Overdue labeling - Alert banner - Main-screen summary ## Requirements covered FR-009, FR-010, FR-011, FR-025, FR-026, FR-027, NFR-018 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | Next-task ranking algorithm | FR-009, FR-025, FR-026 | 6 | | Ranking algorithm test cases | FR-025, FR-026 | 3 | | Overdue label | FR-027 | 1 | | Due-soon and overdue alert banner | FR-011 | 4 | | Main-screen next task and remaining-time summary | NFR-018, FR-010 | 2 | | **Total** | | **16** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 7.1 Next-task ranking algorithm **Project:** Task manager project · **Epic:** Prioritization & Alerts · **Estimate:** 6 h · **Labels:** `type::feature` ~~~markdown ## Summary Comparator for `qsort`: overdue first, then earliest due date/time, then student priority rank, with estimated time as a slight adjustment. ## Requirements implemented - **FR-009** — The system shall indicate the next task to work on through an algorithm defining order of importance. - **FR-025** — The system shall indicate which task the student should work on next, ranked by: (1) due date and time first, (2) the student’s priority level, (3) estimated completion time as a slight adjustment. - **FR-026** — The system shall rank overdue tasks at the top of the list when choosing the next task. ## Implementation notes - Tie-break on estimate (shorter first) only when due date and priority are equal. - Handling of 0-hour reminder tasks follows the Part 4A answer. ## Acceptance criteria - [ ] Documented rule set in code comments - [ ] Recommended task matches the hand-ranked expected order in test cases ## Estimate **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 6h /label ~"type::feature" ~~~ ### 7.2 Ranking algorithm test cases **Project:** Task manager project · **Epic:** Prioritization & Alerts · **Estimate:** 3 h · **Labels:** `type::testing` ~~~markdown ## Summary Table-driven tests covering overdue, same-due-date, priority ties, and zero-estimate tasks. ## Requirements implemented - **FR-025** — The system shall indicate which task the student should work on next, ranked by: (1) due date and time first, (2) the student’s priority level, (3) estimated completion time as a slight adjustment. - **FR-026** — The system shall rank overdue tasks at the top of the list when choosing the next task. ## Acceptance criteria - [ ] At least 10 cases pass - [ ] Tests run from the build script ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::testing" ~~~ ### 7.3 Overdue label **Project:** Task manager project · **Epic:** Prioritization & Alerts · **Estimate:** 1 h · **Labels:** `type::feature` ~~~markdown ## Summary Mark overdue incomplete tasks with a visible `[OVERDUE]` tag in every list. ## Requirements implemented - **FR-027** — The system shall mark overdue tasks with a visible label. ## Acceptance criteria - [ ] Tag appears on every overdue incomplete task and on no others ## Estimate **1 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 1h /label ~"type::feature" ~~~ ### 7.4 Due-soon and overdue alert banner **Project:** Task manager project · **Epic:** Prioritization & Alerts · **Estimate:** 4 h · **Labels:** `type::feature` ~~~markdown ## Summary Check due dates at startup and after every command, and print a short alert banner. No background thread or service. ## Requirements implemented - **FR-011** — The system shall show due-soon and overdue alerts at startup and with each command output with no background process. ## Implementation notes - Due-soon window: 48 h (make it a constant). ## Acceptance criteria - [ ] Banner appears at launch and after each command when applicable - [ ] No banner when nothing is due ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::feature" ~~~ ### 7.5 Main-screen next task and remaining-time summary **Project:** Task manager project · **Epic:** Prioritization & Alerts · **Estimate:** 2 h · **Labels:** `type::feature` ~~~markdown ## Summary Show the recommended next task and the total remaining estimated time above the menu. ## Requirements implemented - **NFR-018** — The system shall show the recommended next task and the total estimated time. - **FR-010** — The system shall total the estimated time of uncompleted tasks (remaining work). ## Acceptance criteria - [ ] Summary refreshes after every command ## Estimate **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 2h /label ~"type::feature" ~~~ --- ## Epic 8: Console Interface & Input Validation **Labels:** `epic::interface` **Description:** ~~~markdown ## Overview Menu-driven console interface, customizable menu, and the shared input-validation layer. ## Scope - Menu loop and dispatch - Customizable menu - Validated input helpers ## Requirements covered FR-012, FR-031, NFR-004, NFR-005, NFR-015 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | Main menu loop and command dispatch | FR-031, NFR-015 | 4 | | Customizable menu | NFR-005 | 5 | | Validated input helpers with re-prompt | FR-012, NFR-004 | 6 | | **Total** | | **15** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 8.1 Main menu loop and command dispatch **Project:** Task manager project · **Epic:** Console Interface & Input Validation · **Estimate:** 4 h · **Labels:** `type::feature` ~~~markdown ## Summary Console main loop that prints the header, alerts, summary, and menu, then dispatches the selected command. ## Requirements implemented - **FR-031** — The system shall present a menu of available actions. - **NFR-015** — The system shall have a console-based interface. ## Implementation notes - Table of `{label, handler}` entries so the menu can be customized. ## Acceptance criteria - [ ] Every feature is reachable from the menu - [ ] Clean exit saves data ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::feature" ~~~ ### 8.2 Customizable menu **Project:** Task manager project · **Epic:** Console Interface & Input Validation · **Estimate:** 5 h · **Labels:** `type::feature` ~~~markdown ## Summary Let the student reorder and hide menu items. The layout persists in settings, and a reset option restores defaults. ## Requirements implemented - **NFR-005** — The system shall have a customizable menu. ## Implementation notes - Settings and Exit can never be hidden. ## Acceptance criteria - [ ] Reordered menu persists after restart - [ ] Reset restores defaults ## Estimate **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 5h /label ~"type::feature" ~~~ ### 8.3 Validated input helpers with re-prompt **Project:** Task manager project · **Epic:** Console Interface & Input Validation · **Estimate:** 6 h · **Labels:** `type::feature` ~~~markdown ## Summary Reusable readers for integers in range, non-empty strings, menu choices, yes/no, and Central Time dates, each printing a clear error and re-prompting. ## Requirements implemented - **FR-012** — The system shall validate all inputs. - **NFR-004** — The system shall display a clear error message and re-prompt when input is invalid. ## Implementation notes - Read whole lines with `fgets` and parse them; never use bare `scanf`. - Handle EOF gracefully. ## Acceptance criteria - [ ] Garbage, empty, and out-of-range input re-prompts with a specific message - [ ] No input can crash the program ## Estimate **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 6h /label ~"type::feature" ~~~ --- ## Epic 9: Semester Lifecycle **Labels:** `epic::semester` **Description:** ~~~markdown ## Overview End-of-course archiving so the next launch starts a fresh semester. ## Scope - Complete-course archive - Carry-over decision ## Requirements covered FR-015, FR-017, FR-021, FR-028 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | Complete course: archive the semester data file | FR-028, FR-021 | 4 | | Carry over categories and priority levels to the new semester | FR-015, FR-017, FR-028 | 3 | | **Total** | | **7** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 9.1 Complete course: archive the semester data file **Project:** Task manager project · **Epic:** Semester Lifecycle · **Estimate:** 4 h · **Labels:** `type::feature` ~~~markdown ## Summary The "Complete course" command, after confirmation, renames the data file to a dated archive; the next launch runs the setup wizard. ## Requirements implemented - **FR-028** — The system shall provide a “complete course” option that archives the semester’s file, so the next launch starts a new semester. - **FR-021** — The system shall ensure that a task is only completed by an explicit student action; it is never auto-completed or auto-deleted. ## Implementation notes - Archive name: `tasks__.dat`. - Tasks are archived as-is, never auto-completed. ## Acceptance criteria - [ ] Archive file exists and is loadable - [ ] Next launch starts a new semester ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::feature" ~~~ ### 9.2 Carry over categories and priority levels to the new semester **Project:** Task manager project · **Epic:** Semester Lifecycle · **Estimate:** 3 h · **Labels:** `type::feature` ~~~markdown ## Summary Depending on the Part 4A answer, offer to copy categories and priority levels into the new semester's file. ## Requirements implemented - **FR-015** — The system shall allow students to define their own task categories instead of a fixed list of types. - **FR-017** — The system shall allow students to define their own priority levels. - **FR-028** — The system shall provide a “complete course” option that archives the semester’s file, so the next launch starts a new semester. ## Implementation notes - Blocked by the Part 4A validation issue. ## Acceptance criteria - [ ] Behavior matches the stakeholder answer ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::feature" ~~~ --- ## Epic 10: Build, Quality & Maintainability **Labels:** `epic::quality` **Description:** ~~~markdown ## Overview Build tooling, coding standards, CI, performance verification, and acceptance testing across all requirements. ## Scope - GCC build for the Windows lab machines - Coding standards and reviews - CI warning gate - Performance and acceptance testing - User documentation ## Requirements covered NFR-001, NFR-002, NFR-003, NFR-006, NFR-007, NFR-008, NFR-009, NFR-010, NFR-012, NFR-013, NFR-014 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | Project skeleton and GCC build script | NFR-010, NFR-014 | 4 | | Coding standards: naming and function comments | NFR-012, NFR-013 | 3 | | GitLab CI warning gate | NFR-014 | 3 | | Performance verification | NFR-006, NFR-007, NFR-008 | 3 | | Acceptance test plan and execution | NFR-001, NFR-002, NFR-003, NFR-009, NFR-010 | 10 | | README and user guide | NFR-012 | 4 | | **Total** | | **27** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 10.1 Project skeleton and GCC build script **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 4 h · **Labels:** `type::infrastructure` ~~~markdown ## Summary Module layout (`main.c`, `task.c`, `storage.c`, `ui.c`, `timeutil.c`, `rank.c`) plus a Makefile/batch script building with MinGW GCC on the Windows lab machines. ## Requirements implemented - **NFR-010** — The system shall be a console-based C application that runs on the Windows lab computers and compiles with GCC. - **NFR-014** — The system shall compile with no warnings using the -Wall and –Wextra compiler flags. ## Implementation notes - Flags: `-std=c11 -Wall -Wextra`. ## Acceptance criteria - [ ] Builds from a clean checkout on a lab machine with one command ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::infrastructure" ~~~ ### 10.2 Coding standards: naming and function comments **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 3 h · **Labels:** `type::documentation` ~~~markdown ## Summary Write CONTRIBUTING.md (naming conventions, purpose comment required on every function) and a merge-request review checklist. ## Requirements implemented - **NFR-012** — The system shall use meaningful names for variables and functions, so the source code can be understood by another developer. - **NFR-013** — The system shall include a comment for every function stating its purpose. ## Acceptance criteria - [ ] Standards document merged - [ ] MR template includes the checklist ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::documentation" ~~~ ### 10.3 GitLab CI warning gate **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 3 h · **Labels:** `type::infrastructure` ~~~markdown ## Summary CI job that compiles with `-Wall -Wextra -Werror` and runs the unit tests on every merge request. ## Requirements implemented - **NFR-014** — The system shall compile with no warnings using the -Wall and –Wextra compiler flags. ## Acceptance criteria - [ ] MR pipeline fails on any warning - [ ] Pipeline passes on main ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::infrastructure" ~~~ ### 10.4 Performance verification **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 3 h · **Labels:** `type::testing` ~~~markdown ## Summary Generate a 1,000-task data file and time startup, list rendering, and save. ## Requirements implemented - **NFR-006** — The system shall launch without a noticeable delay. - **NFR-007** — The system shall remain responsive while displaying or updating the student’s tasks. - **NFR-008** — The system shall save changes to the data file within one second after a task is created, updated, or deleted. ## Acceptance criteria - [ ] Startup under 1 s - [ ] Save within 1 s of a change - [ ] Results recorded in the issue ## Estimate **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 3h /label ~"type::testing" ~~~ ### 10.5 Acceptance test plan and execution **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 10 h · **Labels:** `type::testing` ~~~markdown ## Summary Write one test case per FR/NFR and run the full suite on a lab machine, offline. Estimate covers 2 people x 5 h. ## Requirements implemented - **NFR-001** — The system shall not lose any previously saved tasks if the program terminates unexpectedly. - **NFR-002** — The system shall recover from a failed save and tell the user what happened. - **NFR-003** — The system shall allow the user to add a new task in no more than three menu selections/prompts. - **NFR-009** — The system shall not require an internet connection to create, update, or view tasks. - **NFR-010** — The system shall be a console-based C application that runs on the Windows lab computers and compiles with GCC. ## Implementation notes - Includes forced-kill crash test (NFR-001) and network-disabled run (NFR-009). ## Acceptance criteria - [ ] Every requirement ID has a test case - [ ] All core tests pass - [ ] Results attached ## Estimate **10 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 10h /label ~"type::testing" ~~~ ### 10.6 README and user guide **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 4 h · **Labels:** `type::documentation` ~~~markdown ## Summary Build instructions, data file location and format, and a walkthrough of every menu command. ## Requirements implemented - **NFR-012** — The system shall use meaningful names for variables and functions, so the source code can be understood by another developer. ## Acceptance criteria - [ ] New team member can build and use the app from the README alone ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::documentation" ~~~ --- ## Epic 11: Optional Enhancements **Labels:** `epic::optional`, `optional` **Description:** ~~~markdown ## Overview Optional requirements FR-032 to FR-037. These are scheduled only after all core epics are complete. ## Scope - Sort/filter - Completed-work summary - Actual time logging - Latest-start warning - Subtasks - Recurring entries ## Requirements covered FR-032, FR-033, FR-034, FR-035, FR-036, FR-037 ## Work breakdown | Issue | Requirements | Man-hours | |---|---|---| | Sort and filter by category, priority, and status | FR-032 | 5 | | Completed-work summary | FR-033 | 2 | | Log actual time spent against the estimate | FR-034 | 4 | | Latest-start-time warning | FR-035 | 2 | | Subtasks and phases via task links | FR-036 | 6 | | Mass and recurring task entry | FR-037 | 6 | | **Total** | | **25** | --- Source: *PCC Task Manager - System Specifications - Team 5.docx* ~~~ ### 11.1 Sort and filter by category, priority, and status **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 5 h · **Labels:** `type::feature`, `optional` ~~~markdown ## Summary Sort and filter options on the list views. ## Requirements implemented - **FR-032** — The system shall allow students to sort or filter tasks by category, priority, and status. ## Acceptance criteria - [ ] Filters combine - [ ] Sort is stable ## Estimate **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 5h /label ~"type::feature" ~"optional" ~~~ ### 11.2 Completed-work summary **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 2 h · **Labels:** `type::feature`, `optional` ~~~markdown ## Summary Show the count and total estimated hours of completed tasks. ## Requirements implemented - **FR-033** — The system shall show how much work the student has already completed. ## Acceptance criteria - [ ] Summary matches the completed list ## Estimate **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 2h /label ~"type::feature" ~"optional" ~~~ ### 11.3 Log actual time spent against the estimate **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 4 h · **Labels:** `type::feature`, `optional` ~~~markdown ## Summary Add time-spent entries per task and show the remaining time versus the estimate. ## Requirements implemented - **FR-034** — The system shall allow students to log actual time spent on a task and show the time remaining against the estimate. ## Acceptance criteria - [ ] Over-estimate shown as negative remaining ## Estimate **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 4h /label ~"type::feature" ~"optional" ~~~ ### 11.4 Latest-start-time warning **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 2 h · **Labels:** `type::feature`, `optional` ~~~markdown ## Summary Warn when now is later than the due time minus the estimated time for an incomplete task. ## Requirements implemented - **FR-035** — The system shall warn the student when the latest start time for a task has passed (due time minus estimated time). ## Acceptance criteria - [ ] Warning appears in the alert banner ## Estimate **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 2h /label ~"type::feature" ~"optional" ~~~ ### 11.5 Subtasks and phases via task links **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 6 h · **Labels:** `type::feature`, `optional` ~~~markdown ## Summary Link a task to a parent task and show children indented under the parent. ## Requirements implemented - **FR-036** — The system shall support phases or subtasks by linking one task to another. ## Implementation notes - Prevent cycles. ## Acceptance criteria - [ ] Parent shows child progress ## Estimate **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 6h /label ~"type::feature" ~"optional" ~~~ ### 11.6 Mass and recurring task entry **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 6 h · **Labels:** `type::feature`, `optional` ~~~markdown ## Summary Create N tasks on a weekly or daily pattern (e.g. every Monday for 3 weeks). ## Requirements implemented - **FR-037** — The system shall support mass or recurring entries (for example, every Monday for three weeks). ## Acceptance criteria - [ ] Generated due dates are correct across DST ## Estimate **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h). --- Source: *PCC Task Manager - System Specifications - Team 5.docx* /estimate 6h /label ~"type::feature" ~"optional" ~~~