# 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 #<Requirement documentation issue number>` 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_<course>_<YYYY-MM-DD>.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"
~~~