diff --git a/docs/agile docs/Sprint 5/Sprint Journal 5.md b/docs/agile docs/Sprint 5/Sprint Journal 5.md
index c8e7feff..e0e50b8e 100644
--- a/docs/agile docs/Sprint 5/Sprint Journal 5.md
+++ b/docs/agile docs/Sprint 5/Sprint Journal 5.md
@@ -1 +1,41 @@
# Sprint Journal 5
+
+# 1. Adoption Plan
+
+**1) Date that you wrote this journal entry.**
+
+Friday, May 2
+
+**2) Is your product ready for adoption?**
+
+- *Describe the current state of your product's development at the time of writing this journal entry.*
+- *Give a comprehensive risk/benefit analysis of your product by stating at least 5 risks or benefits of using your product*
+- *Is it right to encourage people to adopt your product in its current state? Or will you continue developing instead? Explain your decision.*
+
+---
+
+Our product is not ready for adoption. Currently, our product displays the frontend calendar and supports adding/removing events. However, we still need to work on managing events, adding/removing/managing deadlines, and scheduling time to work on deadlines. Ideally, we also want to have certain stretch goals, such as calendar integration. Since we do not have our planned features fully implemented yet, our product is not adoptable right now.
+
+Below are 5 risks and benefits for using the product.
+
+- **Benefit**: Users can think more intentionally about work habits when using our product to create a schedule.
+- **Risk**: We do not have a mobile-friendly way to use the product now, since calendaring is largely done on mobile nowadays.
+- **Risk**: We have not confirmed whether our product works at scale.
+- **Risk**: The product does not have any ways to incentivize users following their schedules.
+- **Risk**: The product lacks notification functionality, which is an important aspect for keeping users accountable to the plans they make on the app.
+
+Given these risks and the missing features, it is not right to encourage people to adopt our product. Many features are not fully working and the optimization of our product at a large scale is unconfirmed. We seek to complete the feature set initially planned and make the software user-friendly and mobile-friendly before encouraging users to adopt it.
+
+**3b) Continued development plan (if not ready for adoption)**
+
+- *Will your product be ready for adoption after some future work? Why or why not? (Don't be too hard on yourself if you decide not. Many software products make their most important impact as a learning experience for the development team rather than by reaching target users. It's totally fine if that's the case for your product. We are responsible to only encourage others to use our software when it is right to do so.)*
+- *If you answered yes to the previous question, what future work is needed before adoption? Aim high. You will not be evaluated on completing all the future work.*
+- *If you answered no, what future work is needed for you to tie off the loose ends of your product and feel satisfied in your learning?*
+
+---
+
+We are not sure right now about whether our product is ready for adoption. We initially planned on making the scheduling algorithm as an integral part of our product. However, we realized we also lacked skills in the user-facing and business-logic aspects, which are fundamental to all software products today. This meant that we spent a significant amount of time learning how to implement the basic frontend and backend logic of our app, preventing us from engaging with the scheduling algorithm significantly. Therefore, the readiness for adoption of our product would depend on the feasibility to complete our scheduling algorithm.
+
+If the scheduling algorithm is found to be doable without significant research, or if this is a solved problem, then our product will be ready for adoption. Future work at this point would likely involve creating a frontend that is user-friendly and accessible while providing users access to the scheduling algorithm from a calendar interface. This would include adding the remaining features we plan to implement, including managing events and implementing deadlines. Furthermore, we would want to make our application usable from mobile devices. We would also need to ensure reliability through expanding the scope of our testing and ensuring our product performs at scale.
+
+Otherwise, we may determine our product is not ready for adoption after some future work, because the future work is too significant. We can tie up loose ends through delivering a generic calendar app without a polished scheduling algorithm. In such an app, we would further develop our user interface so that it is consistent with industry standards, completing our implementation of event and deadline management. We would also improve our code documentation and test coverage. This will make us satisfied in our learning through gaining the fundamental understanding needed to create a full-stack web application, which will be useful for future projects or jobs we pursue individually.
diff --git a/docs/dev docs/general bugs fixed/frontend-turbo-failing.md b/docs/dev docs/bugs-fixed-report/frontend-turbo-failing.md
similarity index 100%
rename from docs/dev docs/general bugs fixed/frontend-turbo-failing.md
rename to docs/dev docs/bugs-fixed-report/frontend-turbo-failing.md
diff --git a/docs/dev docs/general bugs fixed/port-already-in-use.md b/docs/dev docs/bugs-fixed-report/port-already-in-use.md
similarity index 100%
rename from docs/dev docs/general bugs fixed/port-already-in-use.md
rename to docs/dev docs/bugs-fixed-report/port-already-in-use.md
diff --git a/eslint.config.mjs b/eslint.config.mjs
index 5bad6edd..5571e808 100644
--- a/eslint.config.mjs
+++ b/eslint.config.mjs
@@ -25,7 +25,9 @@ export default [
React: 'readonly',
exports: 'readonly',
HTMLInputElement: "readonly",
- HTMLFormElement: "readonly"
+ HTMLFormElement: "readonly",
+ setInterval: "readonly",
+ clearInterval: "readonly",
},
},
plugins: {
diff --git a/frontend/package.json b/frontend/package.json
index 92b0dd60..441191f2 100644
--- a/frontend/package.json
+++ b/frontend/package.json
@@ -10,6 +10,9 @@
"test": "vitest"
},
"dependencies": {
+ "@fortawesome/fontawesome-svg-core": "^6.7.2",
+ "@fortawesome/free-solid-svg-icons": "^6.7.2",
+ "@fortawesome/react-fontawesome": "^0.2.2",
"@fullcalendar/core": "^6.1.17",
"@fullcalendar/daygrid": "^6.1.17",
"@fullcalendar/interaction": "^6.1.17",
diff --git a/frontend/src/app/dashboard/calendar/page.tsx b/frontend/src/app/dashboard/calendar/page.tsx
index cf308b5e..4a13a143 100644
--- a/frontend/src/app/dashboard/calendar/page.tsx
+++ b/frontend/src/app/dashboard/calendar/page.tsx
@@ -30,6 +30,7 @@ import axios from 'axios';
import { backendBaseUrl } from '@/lib/utils';
interface Event {
+ start_time?: Date | string;
id: number | string; // your backend sometimes uses uuid string, sometimes number
title: string;
end_time: Date | string | null;
@@ -102,7 +103,7 @@ export default function Home() {
const extractedEvents = response.data.map((event: Event) => ({
id: event.id,
title: event.title,
- start: event.start ? new Date(event.start) : undefined,
+ start: event.start_time ? new Date(event.start_time) : undefined,
end: event.end_time ? new Date(event.end_time) : undefined,
allDay: event.allDay ?? false, // default to false if undefined
// Optional: You could add more fields here if FullCalendar needs
diff --git a/frontend/src/components/Help.tsx b/frontend/src/components/Help.tsx
index 2c2524e7..1f2e5199 100644
--- a/frontend/src/components/Help.tsx
+++ b/frontend/src/components/Help.tsx
@@ -43,6 +43,7 @@ export const Help = () => {
return (