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
- 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.
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.
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.
- 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.
