Create a project brief on what a WatchTower is, who it serves, and what problems we are solving first. [#1]
Finalize Sprint 1 MVP definition with strict feature boundaries to avoid overbuilding. [#2]
Draft functional and non-functional requirements for WatchTower MVP. [#3]
Create user stories for Sprint 1 and near-term backlog aligned to personas and MVP. [#4]
Document Sprint 1 planning and workflow in one place. [#5]
Set up research docs structure and collect individual research notes. [#6]
Prepare Sprint 1 design artifacts for dashboard structure and core incident flow. [#7]
Create initial GitHub backlog for Sprint 1 and future-ready placeholders for Sprint 2+. [#8]
Set up and populate Sprint 1 meeting/process evidence required by the course. [#9]
Sprint 2
Split into two teams for prototype and have a shared evaluation criteria so both prototypes stay aligned to one WatchTower product [#20]
Define one shared event schema and API contract for both prototype teams.[#21]
Create a working Prototype 1 front-end from event ingestion to dashboard rendering with test coverage on what works.[#22]
Create a working Prototype 2 front-end from SDK integration to dashboard rendering with test coverage on what works.[#23]
Use proffessor feedback to guide Apply professor guidance to both prototypes:
Minimal mobile usability
Clear access to full desktop experience
Priority-based sizing/color emphasis using progressive disclosure
Make document structure more intutive and make it easier to find stuff and create JSDoc standards for code base[#26]
Create a plan for separating the monitored test app from the WatchTower repo, without migrating.[#27]
Create a sprint-end comparison readout for both prototypes using the agreed rubric then use that to guide what prototype to use (1,2, or hybrid)[#28]
Sprint 3
Current Standup meetings documentation is messy and not updated, change structure to be more readable and easier to update in the future[#45]
Update ADR to reflect new backend technologies.[#53]
Add filters for querying database.[#54]
Write SDK logic to send correct JSON messages to the correct endpoints as defined in Course-Project\src\prototype_1\server\server-1.1.js.[#55]
Look at Course-Project\docs\design\event-schema-v1.md and Course-Project\src\prototype_1\server\server-1.1.js to make sure that all fields of event schema can be captured and filled out. If required, research any new APIs that will enable this. If any fields cannot be captured, then state so and briefly explain why.[#56]
Merge Frontend Candidates [#57]
Sprint 4
Create WatchTower landing page content and information architecture [#60]
Implement landing page UI with Login / Sign Up CTA [#61]
Build static Login and Sign Up screens [#62]
Navigation polish (Back, Return Home, and route consistency) [#63]
UI quality pass to reduce AI-generated look and improve visual coherence [#64]3
Change the logo to be only one since there is no difference between the dark mode and light mode logo.[#71]
Research Clerk and Resend as possible integrations for WatchTower. The goal is to evaluate whether Clerk should be used for login/authentication and whether Resend should be used to send email alerts when WatchTower detects high-risk issues.[#78]
Polishing up UI[#87]
Sprint 5
Use Clerk API to implement authorization for sign in page and update ADR.[#95]
Setup PostgreSQL for the app and migrate existing SQLite code to work with PostgreSQL. Make sure to link to Clerk IDs down the line. Update ADR to include PostgreSQL. [#96]
Work on the implementation of BEACON API and Navigation Timing API[#97]
Add three new technologies to ADRs:[#108]
Render
PostgreSQL (update ADR 3)
Supabase
Research how to set up a custom sending domain so WatchTower can send alert emails from a branded address (e.g. alerts@watchtower.dev) instead of a default provider address. This is a prerequisite for the Resend email alert integration (issue #78). Covers domain registration, DNS record setup (SPF, DKIM, DMARC), and verifying the domain with Resend.[#109]
Implement Gmail API with Nodemailer OAuth2 to send alert emails from WatchTower when an error threshold is crossed. Based on the research in docs/research/email-domain-research.md (#109).[#114]
Update the backend/user profile flow so the dashboard displays the currently signed-in user’s real name/profile information instead of a hardcoded name. When a user signs in, the app should pull the correct user information and expose it to the frontend.[#117]
Implement backend support for email notifications/Google email alerts. The system should be able to send an email notification when alerts or errors pass a defined threshold, such as more than 5 alerts.[#118]
Migrate user data into Supabase so authenticated users can be stored, retrieved, and viewed correctly from the database. The backend should make sure user records are created or synced properly when users sign in.[#119]
Create a little Health status logic + reliability explanation for consumer to understand ‘health metric’[#122]
If this section displays most recent issues (not highest severity), rename “Top 3 Issues” to “Latest Issues” and update subtitle/description copy to match behavior.[#123]
Add missing Y-axis labels, fix or remove empty/broken graphs (including latency graphs), and replace unclear placeholders (like em dashes) with meaningful fallback text.[#124]
Ensure active issues count renders correctly and add a clear severity legend for Critical/Warning/Info with consistent visual definitions.[#125]
Apply threshold-based status colors:[#126]
Errors: 0 = green, 1–10 = yellow, 10+ = red
Latency: <200ms = green, 200–800ms = yellow, 800ms+ = red
Apply similar status color rules to health, active issues, and response latency.
Remove AI-looking emojis and polish headings/descriptions so copy is professional, readable, and consistent across dashboard pages.[#127]
Test and fix responsive behavior across desktop, tablet, iPhone, and smaller phones:[#128]
Sidebar icon alignment
Overlapping text/cards
Wrapping/spacing issues during resize
Use Polypane for cross-viewport validation.
Remove hardcoded display name and role values from UI and replace with neutral placeholder or config-driven values.[#129]
Fix off-centered layout on landing page and properly center hero and main content blocks across common viewport sizes.[#130]
Improve hero section quality:[#131]
headline clarity
subheading hierarchy
CTA emphasis
overall visual balance inspired by modern SaaS/product websites
Add a product preview section showing what WatchTower does, including a dashboard screenshot/mockup and concise feature explanation.[#132]
Add a visible Privacy Policy link/page that explains tracked data types (activity, errors, performance) and basic user-data handling expectations.[#133]
A lot of the documentation has not been updated to reflect our current product and architecture, make the changes to the docs to reflect these changes[#143]
The profile display name is stored under a single generic localStorage key (watchtower_profile_name), shared across all users on the same browser. This causes two bugs:[#149]
If user A sets a custom display name, then signs out and user B signs in, user B sees user A’s name.
If user B signs out and user A signs back in, user A’s custom name is gone (overwritten by Clerk name on every login).
Fix the backend/data logic for the dev dashboard widgets .[#120]
most-clicked features
severity/diagnostic controls,
custom activity over time.
These sections should either show real tracked data or be adjusted so they are not static, broken, or misleading.