coms3011a-lab1/docs/AI_USAGE.md

AI Usage

AI tools were used during the development of Planner Danner to assist with planning, frontend implementation, debugging, database integration, testing, and documentation.

The AI tools used were:

• ChatGPT
• Copilot
• OpenAI Codex

AI assistance was used throughout the development process, but outputs were reviewed and adjusted where they did not match the project requirements, existing design, or expected behaviour.

Full AI Transcripts

The full AI development transcripts are included in this repository. Original shared conversation links are also provided where available.

• ChatGPT Transcript — Original ChatGPT conversation
• Copilot Transcript — Original Copilot conversation
• OpenAI Codex Transcript

The sections below summarise the main constraints, corrections, debugging decisions, and implementation choices shown in those transcripts.

Constraints Given to AI

Different constraints were given throughout development depending on the task being worked on.

Important constraints included:

• Preserve the existing Planner Danner visual design, including the general colours, fonts, card style, and three-column layout.
• Avoid unnecessary changes to functionality that was already working.
• Keep the three fixed task statuses: Todo, In-Progress, and Complete.
• Do not introduce Overdue as another task status.
• Archive tasks rather than deleting them.
• Keep archived tasks viewable.
• Derive overdue state from the due date and task status instead of storing it as a database field or status.
• Store tasks persistently in SQLite.
• Preserve the four required task fields: Title, Description, Due Date, and Topic.
• Ensure tests do not use or modify the real data/planner.sqlite database.
• Use a temporary or throwaway SQLite database for automated testing.
• Make automated tests deterministic.
• Provide one documented command that runs the complete automated test suite.
• Do not change working application functionality merely to make testing easier unless required for testability.
• When writing final documentation, inspect the actual repository and do not invent dependencies, commands, functionality, files, or transcripts.

For the automated testing stage, Codex was specifically instructed to test real application behaviour including task creation, editing, archiving, overdue derivation, and sorting.

---

Planning and Early Development

ChatGPT and Copilot were used during the earlier stages of the project while I was learning how to structure the application using Next.js.

I began with a working Next.js project containing a welcome page and an early three-column task dashboard. The early version stored tasks only in React state and did not yet have SQLite persistence.

AI assistance was used to plan how the application could be split into reusable components such as:

• Board.tsx
• Column.tsx
• AddTaskForm.tsx
• TaskCard.tsx

The early planning also identified the major remaining Lab 1 requirements, including:

• SQLite persistence
• task creation and editing
• archiving
• fixed task statuses
• task sorting
• overdue indication
• automated testing
• documentation

Some early suggestions were not kept in the final implementation. For example, better-sqlite3 was initially suggested for SQLite access. The final application instead uses Node.js's built-in node:sqlite API.

---

Code Generation and Implementation

AI was used to assist with implementation at several stages.

During the frontend stage, ChatGPT and Copilot assisted with:

• restructuring the dashboard into reusable components;
• creating the Add Task modal;
• adding task cards;
• implementing task status controls;
• adding sorting controls;
• improving the consistency of the Planner Danner design.

Later, OpenAI Codex was used to refactor and complete the application functionality.

Codex changed the task implementation to use a shared task model and a single collection of tasks. The board then filters that collection into the three task statuses rather than maintaining unrelated task arrays.

Codex also added the persistent application layer, including:

• db/schema.sql
• lib/db.ts
• lib/tasks.ts
• the /api/tasks API
• task creation
• task editing
• task archiving
• task status updates
• archived-task viewing
• sorting
• overdue indication

The local SQLite database is created at data/planner.sqlite and is excluded from version control.

---

Debugging and Corrections

AI output was not always accepted as generated. Several issues required correction or redirection during development.

Preserving the Planner Danner Design

During the frontend work, generated code changed parts of the existing visual design.

I rejected this change and explicitly told the AI that it had changed my design and that the same fonts, colours, and overall visual style needed to be maintained throughout the project.

Subsequent work was therefore directed to preserve the existing Planner Danner appearance rather than replacing it with a new design.

Task Status Movement Bug

An early implementation used the index of a task inside a filtered column when changing its status.

After applying the suggested code, the task still did not move correctly. I reported that there was still no change.

This caused the implementation to be investigated further. The problem was identified as a mismatch between the task's index inside a filtered column and its position in the complete task array.

The later implementation improved this further by using each task's unique database id when changing status rather than depending on array indexes.

In-Progress Tick Indicator

In a later Codex session, the status circle displayed a tick for a task that was only In-Progress.

I specifically requested that the tick should not appear while a task is In-Progress.

Codex then updated TaskCard.tsx so the tick is displayed only when the task status is Complete.

Documentation Structure

The first final-documentation approach placed most of the required documentation inside README.md.

I later changed this approach because I wanted the repository documentation to be clearer for the marker.

The final repository therefore uses separate Markdown files:

• docs/THIRD_PARTY_CODE.md
• docs/DATABASE_DESIGN.md
• docs/RUNNING_IT.md
• docs/AI_USAGE.md

The main README remains concise and links to each documentation file.

Documentation Verification

Codex was instructed not to invent project details when preparing the final documentation.

It inspected the actual package.json, database schema, Node version, and available npm scripts before documenting them.

When some server verification commands became unnecessarily long-running, that process was stopped and redirected back to documentation-only work rather than allowing unrelated commands to continue indefinitely.

---

Automated Testing Assistance

Codex was given explicit testing constraints before generating the automated test suite.

The tests were required to:

• exercise real task behaviour;
• use a temporary SQLite database;
• never modify data/planner.sqlite;
• be deterministic;
• run through a single npm command;
• include archiving and overdue behaviour where practical.

Five behavioural tests were created.

They cover:

1. Creating a task and persisting all four required fields.
2. Editing a task and persisting the changed values and status.
3. Archiving a task without deleting it.
4. Deriving overdue correctly without storing Overdue as a task status.
5. Sorting tasks deterministically by topic, status, and due date.

The tests use TASKS_DB_PATH to point the database layer at a temporary SQLite file instead of the normal development database.

The complete test suite runs with:

npm test