did sprint 0

sprints/sprint0/sprint0.md

@@ -1,28 +1,41 @@
 # **Project Overview**
 
 ## **Application Vision/Goal:**
-[Describe the overall purpose and vision of the application. What problem does it solve? Who is the target audience?]
+
+The two main public transit providers for Binghamton University students are OCCT and BC buses. Each provider has their own routes, schedules, and quirks, making the simple question “how do I get there” surprisingly difficult to answer, especially in a timely manner. This project will pull data from both services to get people to their destinations. 
+
+Users will be able to input a start and end location and the app will respond with a route using either, both or neither bus providers to get there.
 
 ## **Scope:**
-[List the major features and functionalities that define the scope of the project. Keep this high-level to avoid feature creep.]
+
+Allow viewing bus routes and pick start and end point and get bus route between them.
 
 ## **Deliverables:**
-[List what will be delivered by the end of the project, such as a working MVP (Minimum Viable Product), specific features, documentation, etc.]
+
+Google maps which you can click on 2 points to get route between them and get a visual of the bus routes for current time.
 
 ## **Success Criteria:**
-[Define what will make this project successful. Examples include meeting deadlines, delivering core functionality, or achieving performance benchmarks.]
+
+Making something which is more functional than [Spencer's HackBU 2024 project](https://git.pagwin.xyz/Pagwin/BinghamonBetterBus), ([Video demo](https://youtu.be/5WcKPhMqveY)) hackBU project doesn't handle Broome county buses due to a bug and suggests comically bad bus routes.
 
 ## **Assumptions:**
-[List any assumptions about the technology, users, or resources that could impact development.]
+
+- etaSPOT data is reasonably accurate
+- Broome county GTFS data is reasonably accurate
+- Google maps will continue to exist and allow for drawing of path on map
 
 ## **Risks:**
-[Identify potential risks and challenges, such as technical limitations, resource constraints, or dependency issues.]
+
+- if we want/need static OCCT data that will involve manual work
+- potential combinatorial explosion causing calculation to take too long
 
 ## **Design / Architectural Review:**
-[Outline the initial thoughts on application architecture. Will it be monolithic or microservices? Will it use a database? What major components will be included?]
+
+Client server split maybe database
 
 ## **Test Environment:**
-[Define how the application will be tested. Will you use automated tests? What environment will the tests run in?]
+
+Unit tests for the backend.
 
 ---
 
@@ -30,19 +43,29 @@
 
 ## **Team Members:**
 
+- Spencer Powell
+- Levi Lesches
 
 ## **Team Roles:**
 
-
+- Spencer: server
+- Levi: client
 
 ## **Team Norms:**
 
-
+- handle CI for their side of the app
 
 ## **Application Stack:**
 
-
+- Caddy for reverse proxy
+- Flutter for client
+- Google Maps API for visual
+- Nodejs + Typescript for backend
+- sqlite for db
 
 ### **Libraries/Frameworks:**
 
-
+- JSON for api
+- etaSpot for dynamic OCCT info
+- maybe scraping for static OCCT info
+- GTFS data for static BC info