Skip to content

Final Milestone Deliverables

Jump to bottom
Bora Aydemir edited this page May 16, 2026 · 32 revisions

Final Milestone Deliverables

Due dates: Software release 12.05.2026, 22:00 · Other deliverables 16.05.2026, 22:00

Group Number: 3

1. Meeting Notes

2. Finalized Project Documentation

3. Project Review

3.1 Executive Summary

3.1.1 Project Status Summary

AccessMap (Neighborhood Accessibility Mapper) is, at the Final Milestone, a deployed cross-platform application — web (Vercel) and Android (APK release) — backed by a Django REST Framework API on a managed Supabase database. The full obstacle lifecycle is end-to-end: a guest can browse the map and inspect existing reports; a registered user can submit an outdoor or indoor obstacle report with a mandatory photo; the community can upvote or flag the report, automatically transitioning it from Unverified to Confirmed once the threshold (lowered for Trusted Contributors) is reached; an Infrastructure Authority can mark a Confirmed obstacle as "Resolved – Awaiting Validation" with a post-repair photo and notes; the original reporter and all upvoters are notified asynchronously and can cast "Confirm Resolution" votes that close the issue; and an Admin can prune malicious reports and suspend abusive accounts through the moderation queue. Mobility-aware routing is integrated via Valhalla with verified outdoor obstacles passed as exclusion polygons, and route preferences (avoid stairs, avoid steep slopes, maximum slope gradient) persist on a per-user Mobility Profile alongside saved places (Home / Work) and a Trust Score with a Trusted Contributor badge.

Everything in functional groups 1.1.1 – 1.1.8, 1.2.1 – 1.2.5, and the asynchronous notification layer of 1.2.6 is implemented, tested, and deployed — see the detailed status in §4.2. The handful of partials are scoped, documented behaviours rather than missing functionality: password-reset email delivery depends on SMTP env configuration in the deployed environment, the in-app notifications_enabled toggle is wired in the backend but not yet surfaced as a profile control on the frontend, the decay_unverified_reports command works but is not yet attached to a scheduler, building-entrance snapping for routing is not implemented (routes terminate at the user-selected coordinate), and performance / WCAG / iOS-build claims are met structurally but not validated by formal benchmarks or audits. Two items were intentionally descoped during the milestone: the citizen-facing "Propose Resolution with photo" flow (1.1.6.3) was kept exclusively inside the Authority workflow (1.1.7.4) to avoid two divergent resolution paths, and account-level spam detection (1.2.6.1) was deferred — moderation remains report-level via the SPAM_FLAG_THRESHOLD queue.

3.1.2 Status of Deliverables

Deliverable Status Notes
Web Application (deployed) ✅ Complete Live at bounswe2026group3-azure.vercel.app.
Mobile Application (Android APK) ✅ Complete Published as a release asset on the final-milestone GitHub Release.
Backend API ✅ Complete Containerized Django REST Framework service; OpenAPI/Swagger documentation served live.
Final SRS ✅ Complete Software Requirements Specification — kept in sync with the implementation.
Final Design (UML) ✅ Complete Class Diagram, Use Case Diagram, Sequence Diagrams.
Test Execution Reports (HTML + XML) ✅ Complete Backend, Web, Mobile reports linked in §4.6. All tests passing including regressions from MVP.
New Test Evidence (Integration / E2E / UI) ✅ Complete Playwright E2E smoke suite (PR #279) plus integration and UI tests added in this milestone.
GitHub Release (final-milestone / v1.0.0) ✅ Complete Production tag on main; not marked pre-release.
README / Setup Instructions ✅ Complete docker-compose.yml, .env.example, default credentials, and data-seeding instructions in the root README.
Wiki Final Milestone Deliverables page ✅ Complete This document.
W3C Standards Compliance Documentation ✅ Complete See §4.5 — WCAG 2.1, Schema.org, GeoJSON, JWT, ISO 8601, Activity Streams 2.0.

3.1.3 Final Release Notes

Release: v1.0.0 — final-milestone (Official release) Live web app: bounswe2026group3-azure.vercel.app

Headline features added since MVP

  • Full obstacle lifecycle. Unverified → Confirmed (community-upvote-driven, threshold lowered for Trusted Contributors) → Resolved – Awaiting Validation (Authority-driven) → Closed (citizen-confirmation-gated). Markers are never silently removed; closure is community-validated.
  • Indoor / Outdoor obstacle reporting. Indoor pins render only above the High-Detail zoom threshold and are inherently excluded from routing.
  • Trust Score & Trusted Contributor badge. Reputation increments on verified contributions; guests cannot earn score (enforced structurally by the auth requirement on submission).
  • Infrastructure Authority dashboard. Filterable issue queue, mandatory post-repair verification photo on status transitions, official repair-note appending.
  • Admin moderation. System-wide flagged-reports queue, permanent deletion, account suspension / banning.
  • Async notification system. Status-change notifications delivered to reporter and upvoters; authenticated newest-first feed endpoint; backend respects per-user notifications_enabled.
  • Mobility Profile & Saved Places. Permanent profile with mobility aid type, accessibility preferences, and Home / Work shortcuts that tap-to-focus the map.
  • Obstacle-avoidance routing via Valhalla. Verified outdoor obstacles passed as exclude_locations; passive and indoor reports inherently excluded from the avoidance set.
  • Accessibility standard violation chips. Reports surface which W3C / domain accessibility standards an obstacle violates (PR #262).

Infrastructure & quality improvements

  • Containerized deployment (docker-compose.yml + Railway/Vercel pipelines).
  • Playwright E2E smoke suite gating CI (PR #279).
  • Android APK build automated through EAS / GitHub Actions.

Known limitations (see §4.2 for the full list)

  • Password-reset emails depend on production SMTP configuration (EMAIL_BACKEND defaults to console).
  • notifications_enabled toggle has no frontend control yet.
  • decay_unverified_reports runs as a command but is not yet on a scheduler.
  • No formal WCAG audit; performance / load benchmarks are unmeasured.
  • iOS lacks a production build pipeline.

3.1.4 Process Changes Since Previous Milestones

Most of these were called out as commitments in the post-MVP Project Retrospective and adopted in the weeks that followed.

  • Fixed weekly meeting cadence. Weekly Meetings #6–#9 ran every Tuesday after MVP with full team attendance and an agenda prepared in advance — replacing the inconsistent, agenda-less meetings of the first half of the semester. The effect was concretely visible: Week 9's meeting was a structured gap-analysis that produced a per-member action list against the requirements catalog.
  • Finer-grained, scope-tight GitHub issues. Post-MVP issues were opened with explicit scope, acceptance criteria, and a single owner — e.g. the Lab 8 issue cluster (#170, #171, #174, #177–#186) decomposed authority dashboard, moderation queue, decay automation, push notifications, and admin moderation UI into independently pickable units. Workload imbalance and hidden cross-team blockers — the retrospective's two biggest pain points — largely disappeared.
  • Integration & testing treated as first-class work. Following the retrospective, integration tasks were no longer folded into feature issues. A dedicated E2E test suite (Issue #178 / PR #279) was opened, and Lab 8 / Lab 9 explicitly devoted their agendas to test coverage and gap analysis.
  • Async sub-team sync on WhatsApp. Short weekly "what we did this week / what we need from you" messages between Backend, Frontend, and Mobile sub-teams reduced the cross-sub-team desyncs (mismatched endpoint contracts) we had during the MVP phase.
  • 48-hour pre-deadline merge freeze on non-critical PRs. Carried over from the MVP and reused for the final-milestone release — code-complete but non-critical PRs were held to protect the deployed build from last-minute integration regressions.
  • Branch-protection + squash-merge on main enforced consistently. Conventional Commits and feature/<issue>-<name> branch naming, established at the start of the semester, became fully consistent post-MVP — the final-milestone tag points cleanly at a main commit with no out-of-band history.

3.1.5 Final Milestone Demo Reflections

[TODO] To be completed after the demo notes are consolidated. Cover, in 3–5 short paragraphs: what landed well during the demo, what feedback the instructors / customer gave, lessons learned, and what we would change in our demo approach next time. This section is for the executive-level reflection; the raw notes belong in §4.7.

Suggested talking points (rewrite freely once notes are in):

  • End-to-end lifecycle demo across web + mobile in the scripted order from Final Demo Plan.
  • Customer / instructor reception of the Authority and Admin flows (new since MVP).
  • Any live failure, recovery, or improvisation worth recording.
  • Audience questions that surfaced gaps we should track as post-release work.

3.1.6 What Could Have Been Done Differently at the Start

In the spirit of the Project Retrospective, and looking back across the full semester rather than just post-MVP:

  • Lock the routing engine choice in week 1. The OSRM-first → Valhalla pivot (PRs #134, #138) consumed two rounds of rework and compressed the testing window for routing. An earlier spike on exclude_locations-style obstacle avoidance would have avoided the 60-metre-offset workaround entirely.
  • Stand up the test infrastructure (Playwright, backend integration harness, mobile component tests) by the end of week 3, not in the final milestone. Lab 8 / Lab 9 spent their agendas on test coverage that should have been baseline. Bugs the new tests caught late (e.g. duplicate notifications heading #270, saved-place precision #245) would have been caught when they were introduced.
  • Containerize and seed from day 1. docker-compose.yml, .env.example, default seeded users, and a data-seeding script were finalized late in the project. Doing this in the first sprint would have given every team member identical local environments and removed an entire class of "works on my machine" issues that came up around the MVP demo.
  • Write GitHub issues with full acceptance criteria from the beginning. The retrospective identified this as the single biggest lever — and post-MVP issues confirmed it. The first half of the semester suffered from one-line issues without "definition of done", which is what drove workload imbalance and the bottlenecks where one merge blocked another.
  • Decide on the resolution model (citizen-led vs. authority-led with citizen confirmation) before drafting use cases. We carried two resolution paths (1.1.6.3 citizen-proposed and 1.1.7.4 authority-led) in the SRS until late in the milestone, then collapsed to one. Locking that decision earlier would have removed a redundant entry from the requirements list and the design diagrams.

4. Progress Based on Teamwork

4.1 Team Member Contributions

Member (Surname, Name) Core Contributions (Title) Description (Brief Summary) Related PRs Related Issues
Akkaya, Ali feat(map): add reporterId, userUpvoted, userFlagged to obstacle detail Extends obstacle detail API with user interaction fields to support frontend UI states. #203 #196
Akkaya, Ali fix: use dynamic PORT for Railway nginx Updates Nginx config to use dynamic PORT variable for Railway deployment. #151 -
Akkaya, Ali fix: deploy fixes for Railway Resolves npm peer dependencies and removes duplicate URL namespace for deployment. #146 -
Akkaya, Ali feat: add Railway deployment config for frontend and backend Adds Dockerfile and Nginx configurations for static serving and backend deployment. #145 -
Akkaya, Ali feat(reports): implement POST /reports endpoint Implements obstacle reporting endpoint with photo upload, proximity deduplication, and auto-verification. #127 #124
Akkaya, Ali fix: restore deleted migrations and fix .gitignore Restores accidentally deleted database migrations and corrects .gitignore rules. #126 -
Akkaya, Ali feat: database schema, migrations & campus seed script Adds core ORM models, enumerations, and a seed script for the campus graph. #108 #79
Akkaya, Ali feat: database schema, migrations & campus seed script Configures Django settings and implements database schema based on SRS. #103 #79
Akkaya, Ali feat: implement Ali's Posts button with API integration and Dockerfile Creates a Dockerfile for the static app and integrates JSONPlaceholder API for a stub page. #70 -
Aydemir, Bora test(e2e): Playwright smoke test suite [QA] Adds Playwright end-to-end smoke tests for core user flows in CI. #279 #178
Aydemir, Bora fix(frontend): remove duplicate Notifications heading and max slope gradient input Fixes minor UI bugs in the notifications screen and mobility profile form. #270 #269
Aydemir, Bora feat(reports): accessibility standard violation chips on submit and detail Adds accessibility violation chips mapping to Turkish standards in report forms. #262 #261
Aydemir, Bora feat(frontend): tap a saved place on profile to focus it on the map (#255) Adds functionality to focus the map directly on a saved place from the profile tab. #256 #255
Aydemir, Bora refactor(frontend): drop ACTIVE pill and stub Badges card from profile (#253) Cleans up profile UI by removing unused badges and pills based on user roles. #254 #253
Aydemir, Bora feat: show progress toward verification and resolution (#240) Adds UI indicators showing current progress towards verification and resolution thresholds. #246 #240
Aydemir, Bora fix(places): accept high-precision lat/lng + surface real save errors + UX polish Increases coordinate precision for saved places and improves error handling and toast UX. #245 #232
Aydemir, Bora fix(frontend): prefix mobility profile requests with /api/ Fixes missing API prefix for mobility profile endpoints causing 404 errors. #244 #231
Aydemir, Bora feat: show UNVERIFIED reports on the map (hollow + dashed) and submit reports as UNVERIFIED by default Renders UNVERIFIED reports as hollow markers on the map and reverts auto-verify dev shortcut. #243 #235
Aydemir, Bora feat(authority): dashboard UI for infrastructure authority role Implements a dedicated dashboard UI for infrastructure authorities to resolve reports. #229 #181
Aydemir, Bora feat(frontend): merge route planning into map screen Merges the separate Plan tab into a unified Google Maps-style map overlay. #142 #141
Aydemir, Bora fix(profile): correct /users/me endpoint URL and normalize reputationPoints to trustScore Fixes profile screen empty fields by correcting endpoint URL and mapping response data. #131 #130
Aydemir, Bora feat(frontend): mobility profile Implements the Mobility Profile feature, allowing users to set and save mobility preferences. #113 #91
Aydemir, Bora feat(frontend): report obstacle Implements the Report Obstacle screen with GPS capture, photo attachment, and validation. #111 #92
Aydemir, Bora fix(frontend): auth routing Fixes critical routing and authentication state bugs introduced in a previous merge. #110 #109
Aydemir, Bora feat: add Bora Aydemir button and TheSportsDB API integration Adds a personalized button and integrates TheSportsDB API for a stub page. #72 -
Belemir, Ömer Fix/backend critical bugs Fixes indoor visibility logic, secures admin permissions, and removes redundant interactions app. #268 #263, #264, #265
Belemir, Ömer Fix/backend bugfixes Fixes indoor visibility logic, secures admin permissions, and removes redundant interactions app. #267 #263, #264, #265
Belemir, Ömer Fix/backend bugfixes Fixes indoor visibility logic, secures admin permissions, and removes redundant interactions app. #266 #263, #264, #265
Belemir, Ömer feat(users): implement GET/POST/PUT /users/me/mobility-profile endpoint Implements backend API endpoints and serializers for managing user mobility profiles. #227 #143
Belemir, Ömer fix(notifications): alias serializer fields to camelCase for frontend Fixes frontend crash by ensuring NotificationSerializer emits camelCase keys. #224 #223
Belemir, Ömer feat(users): implement GET/POST/PUT /users/me/mobility-profile endpoint Implements backend API endpoints and serializers for managing user mobility profiles. #144 #143
Belemir, Ömer feat: add campus location search and switch routing to OSRM Implements campus location search and switches routing logic from Dijkstra to OSRM pedestrian API. #129 #104, #102
Belemir, Ömer Routung Logic and some minor cleanup Implements accessibility-aware routing utilizing Dijkstra's algorithm and user mobility preferences. #122 -
Belemir, Ömer feat(auth): implement user registration endpoint with bcrypt hashing Implements user registration endpoint, User model, and BCrypt password hashing. #97 -
Belemir, Ömer feat: add omerbelemir API button with JSONPlaceholder integration Adds a personalized button that fetches and displays posts from JSONPlaceholder API. #71 -
Evren, Arif feat(backend): add Swagger UI via drf-spectacular Adds Swagger UI API documentation using drf-spectacular. #281 #280
Evren, Arif docs: rewrite README with full project overview Rewrites the README with comprehensive project documentation and setup guides. #278 -
Evren, Arif fix(reports): show CLOSED reports as read-only on detail page Updates backend and frontend to display CLOSED reports as read-only and allows all users to confirm resolutions. #271 #272
Evren, Arif fix(routing): always pass verified obstacles to Valhalla Fixes routing logic to ensure verified obstacles are consistently passed to Valhalla for avoidance. #257 -
Evren, Arif fix(deploy): install frontend deps before expo export to avoid npx pulling expo@55 Fixes Vercel deployment error by ensuring correct dependencies are installed before exporting. #249 -
Evren, Arif feat: suspend and ban user endpoints Implements admin endpoints and permission checks to suspend or ban users. #221 #164
Evren, Arif feat: flag endpoint and exclude CLOSED reports from obstacle queries Implements report flagging for moderation and explicitly excludes CLOSED reports from obstacle queries. #220 #179, #182
Evren, Arif feat: implement POST /api/reports/{id}/confirm-resolution endpoint Implements the community resolution confirmation flow to transition reports to a closed state. #195 #166
Evren, Arif feat: implement password reset request and confirm endpoints Implements backend password reset flow via email tokens. #194 #175
Evren, Arif feat: implement POST /api/reports/{id}/upvote endpoint Implements the report upvoting endpoint, promoting reports to CONFIRMED status upon reaching a threshold. #193 #174
Evren, Arif feature: Github actions for apk flow added Adds GitHub Actions workflow for automatic APK builds. #157 -
Evren, Arif hotfix: Allow CORS Enables CORS on the backend to allow requests from the frontend. #154 -
Evren, Arif feature: all reports are now verified for MVP Temporarily sets new reports to VERIFIED status by default for the MVP launch. #140 #139
Evren, Arif fixed report issue on backend Fixes report ID type in responses and updates Supabase storage client configuration. #132 -
Evren, Arif added users changes Implements user profile GET and PUT endpoints for authenticated users. #128 #121
Evren, Arif Feature/supabase connection Establishes the initial Supabase database connection and adds a backend health-check endpoint. #101 #100
Evren, Arif infra(docker): set up Docker, CI pipeline, and project configuration Configures the Docker environment, GitHub CI pipeline, and base Django application setup. #96 -
Evren, Arif feat: add Arif Evren button handler and page displaying Istanbul weather Adds a custom button that fetches and displays Istanbul weather data via the Open-Meteo API. #66 -
Kemeç, Ulaş Sertan Screen cache fixes for closed and fixing threshold logic to >= Fixes map cache syncing issues for CLOSED/new reports, repairs broken report migrations, and corrects an off-by-one threshold logic error. #274 -
Kemeç, Ulaş Sertan Feat/per trip route avoidance Replaces global avoidance metrics with a per-trip system, rendering both baseline and alternative detour routes on the map. #250 #239
Kemeç, Ulaş Sertan Feat/saved places api Implements the backend CRUD API endpoints, model definitions, and serializers for managing user-scoped saved places. #219 #199
Kemeç, Ulaş Sertan feat(reports): auto-decay stale UNVERIFIED reports to PASSIVE Adds a Django management command to automatically transition old, interaction-free unverified reports to PASSIVE status. #218 #183
Kemeç, Ulaş Sertan feat: status-change notifications + authority resolve endpoint Implements backend services and endpoints for in-app status notifications and an Infrastructure Authority report resolution endpoint. #213 #177, #172
Kemeç, Ulaş Sertan Feat/report upvote with trusted threshold Adds report upvoting endpoint, lowering verification thresholds and handling role promotions for Trusted Contributors. #191 #174, #171
Kemeç, Ulaş Sertan feat: admin endpoint to delete reports as malicious Adds an admin-only report deletion endpoint that automatically penalizes the reporter's trust score. #189 #187
Kemeç, Ulaş Sertan Feat/trust score Establishes infrastructure and services for an environment-configurable trust score award and penalty system. #188 #165
Kemeç, Ulaş Sertan fix: align backend tests with current API and fix map serializer bugs Resolves map app serializer bugs in production code and fixes various broken backend unit tests to match current APIs. #158 -
Kemeç, Ulaş Sertan fix: remove unused tabs from layout Removes placeholder bottom navigation tabs that are not yet implemented in the frontend. #155 -
Kemeç, Ulaş Sertan fix: update nginx config Updates the backend deployment Nginx server configuration details. #150 -
Kemeç, Ulaş Sertan fix: remove redundant postgre db in frontend/docker file and window Cleans up redundant PostgreSQL definitions in the frontend Dockerfile and corrects mobile map view setups. #147 -
Kemeç, Ulaş Sertan fix: correct parameter errors in engine Corrects parameter pass logic errors within the core routing calculation engine. #136 -
Kemeç, Ulaş Sertan feat: update route engine to follow paths for foot, and escape obstacles Upgrades pedestrian routing to actively avoid verified obstacles by injecting perpendicular detour waypoints into OSRM calls. #134 -
Kemeç, Ulaş Sertan feature: map obstacles endpoints for single and multiple obstacles Implements bounding box list views and individual detail endpoints for obstacle markers on the map. #125 #99
Kemeç, Ulaş Sertan Feature/report POST /report endpoint Implements core report submission logic, database models, and Supabase storage uploads for attached photos. #120 #119
Kemeç, Ulaş Sertan Feature/authorization Introduces role-based custom permission classes (IsUser, IsAuthority, IsAdmin) to secure protected backend endpoints. #95 #80
Kemeç, Ulaş Sertan feature: implement JWT auth endpoints (login, refresh, logout) Sets up backend project skeleton and implements JWT authentication endpoints with token blacklisting. #94 #89
Kemeç, Ulaş Sertan Chore/project skeleton Creates the foundational project repository folder architectures for parallel frontend and backend development. #93 #77
Kemeç, Ulaş Sertan feature: Add API calls for button 5 Implements sample API calls for an individual placeholder landing page button. #75 -
Kemeç, Ulaş Sertan Revert "feat: add Ulaş Sertan button handler displaying blog posts" Reverts the prior individual blog post listing button handler functionality. #73 -
Kemeç, Ulaş Sertan feat: add Ulaş Sertan button handler displaying blog posts Adds an individual landing page button handler that fetches and lists sample blog posts via API. #69 -
Kılıç, Ekin fix(frontend): resolve stale state in marker popup after detail view Fixes map marker popup UI corruption after returning from report details by correcting state management and data flow. #258 -
Kılıç, Ekin feat(frontend): add apply-to-authority screen (#228) Adds a frontend screen for non-authority users to apply for the infrastructure authority role. #248 -
Kılıç, Ekin fix(frontend): unwrap backend error envelope in parseDRFError (#233) Fixes error parsing to properly display backend error messages instead of [object Object] in the UI. #247 #233
Kılıç, Ekin feat(frontend): add map preview to authority report detail (#238) Adds a lightweight, non-interactive map preview to the authority report detail screen. #241 #238
Kılıç, Ekin feat(interactions): hide upvote/flag buttons from guests (partial #90) Implements guest restrictions by completely hiding upvote and flag buttons from unauthenticated users. #217 -
Kılıç, Ekin feat(map): exclude CLOSED reports from map markers (#180) Updates frontend map filters to explicitly prevent CLOSED reports from rendering as markers. #216 #180
Kılıç, Ekin Feature/trust score badge ekin Adds numerical Trust Score display and a conditional "Trusted Contributor" SVG badge to the profile screen. #215 #168
Kılıç, Ekin feat(map): Google Maps-style overlay UI with route planning Redesigns the map screen to a Google Maps-style layout, merging route planning directly into the map overlay. #135 -
Kılıç, Ekin feat: implement password reset flow (issue #83) Implements the frontend password reset flow screens and connects them to the backend API. #118 #83
Kılıç, Ekin feat: implement auth (login/register) and profile pages Sets up initial Expo configuration, API services, and UI screens for authentication and user profiles. #98 -
Kılıç, Ekin feat: add ekin button with random user API Adds a custom button that fetches and displays data from the Random User API. #68 -
Önder, Baran feat(notifications): notify reporter when their report is closed Adds an in-app REPORT_CLOSED notification triggered when a report closes via community threshold, including the closure reason and a self-notification guard. #277 #273
Önder, Baran feat(map): stale-while-revalidate refresh for obstacles Implements stale-while-revalidate map refresh on focus and 60s TTL, ensuring obstacles update smoothly without the map blanking out. #276 #275
Önder, Baran fix(map): collapse route inputs into compact bar once route is calculated Collapses the route planning input panel into a compact bar after route calculation to maximize map visibility. #260 -
Önder, Baran perf(map): debounce bounds fetch, cache icons, fix popup flash on back Improves web map performance by debouncing bounds fetch, caching DOM-heavy icons, and fixing Leaflet popup flashing bugs. #252 #251
Önder, Baran Feature/report discussion section Adds a discussion section with comments and a status change timeline to the report detail screen, including backend endpoint integration. #242 #237, #236, #234
Önder, Baran feat(routing): ensure route response fields and add serializer unit tests Ensures routing API correctly returns all fields with a 4km/h walking speed fallback and adds serializer unit tests. #230 #201
Önder, Baran feat(map): add passive obstacle toggle to map view Adds a toggle switch to the map to display or hide inactive (PASSIVE) unverified reports. #222 #186
Önder, Baran fix: implement toggle behavior for upvote and flag interactions Implements toggle behavior (ON/OFF) for upvotes and flags, enforces mutual exclusion, and adds cross-platform conflict alerts. #214 #209
Önder, Baran feat: implement notifications tab and in-app notification list Implements the notifications tab on the frontend to list status updates and manage notification preferences via the profile screen. #212 #208
Önder, Baran Feature/saved places Enables users to save frequent destinations and access them via quick-select chips during route planning and on their profile. #211 #198
Önder, Baran feat: add route summary panel to MapView (native and web) Adds a route summary panel showing total distance, estimated time, and avoided obstacles count after calculation. #210 #204
Önder, Baran Feat/indoor form fields Adds indoor reporting support with reverse-geocoded building auto-fill, floor fields, and distinct indoor map markers. #192 #173, #176
Önder, Baran Feat/obstacle interactions Adds upvote, flag, and confirm-resolution buttons to obstacle details, implementing a bottom sheet on native and inline popup on web. #190 #169, #184, #152
Önder, Baran style: improve UI aesthetics across web and mobile screens Improves overall UI aesthetics by updating search bars, input sizing, and tab bar layouts across platforms. #153 -
Önder, Baran feat: add choose-on-map location picker to report form Adds an interactive "Choose on Map" location picker to the report form for both web and mobile platforms. #149 #148
Önder, Baran fix: replace OSRM hacky rerouting with Valhalla exclude_locations Upgrades obstacle avoidance by switching routing engine to Valhalla and passing verified obstacles to exclude_locations. #138 #137
Önder, Baran fix: align frontend map API with backend response format Aligns frontend map API transformers with the backend response format to properly render fetched obstacles. #133 -
Önder, Baran feat(mobile): Implement map and route planning screens with WebView + Leaflet Implements mobile-specific map and routing screens using WebView and Leaflet, and upgrades Expo SDK to 54. #117 #114, #115, #116
Önder, Baran feat(frontend): map view and route planning screens Implements the initial web map view and route planning screens with OpenStreetMap tiles and API integrations. #112 #84, #85, #86
Önder, Baran feat: add Baran joke button with JokeAPI Adds a custom button that fetches and displays a random programming joke from the JokeAPI. #74 -

4.2 Status of Requirements

Completed = implemented + tested + documented + deployed.

1.1.1 Registration & Authentication

Requirement ID Description Status
1.1.1.1 Guest can browse the map without an account ✅ Completed
1.1.1.2 Guest can view existing obstacle pins on the map ✅ Completed
1.1.1.3 Register with valid email, full name, and birth date ✅ Completed
1.1.1.4 Secure password required during registration ✅ Completed
1.1.1.5 Registered user can log in with email and password ✅ Completed
1.1.1.6 Registered user can log out ✅ Completed
1.1.1.7 Request a password reset link via email 🟡 Partial

Notes: 1.1.1.3 — birth_date is captured at registration but is optional in the serializer rather than mandatory. 1.1.1.7 — token generation, expiry, and confirmation flow are implemented and tested, but EMAIL_BACKEND defaults to the console backend; real email delivery in the deployed environment depends on SMTP env configuration.

1.1.2 Profile & Accessibility Preferences

Requirement ID Description Status
1.1.2.1 Create a permanent Mobility Profile ✅ Completed
1.1.2.2 Select primary mobility aid from predefined categories ✅ Completed
1.1.2.3 Guest can set temporary routing preferences for one session ✅ Completed
1.1.2.4 Save frequent destinations (Home/Work) to profile ✅ Completed
1.1.2.5 View earned badges (e.g. Trusted Contributor) on profile ✅ Completed
1.1.2.6 Enable/disable in-app notifications from profile settings 🟡 Partial

Notes: 1.1.2.6 — backend fully supports and respects notifications_enabled (recipients with it disabled are skipped) and it is exposed/updatable via the profile-update serializer, but there is no in-app profile toggle control wired in the frontend yet.

1.1.3 Map Interaction & Discovery

Requirement ID Description Status
1.1.3.1 Pan and browse the interactive map freely ✅ Completed
1.1.3.2 Zoom in and out of the map ✅ Completed
1.1.3.3 Click an obstacle marker to view details and photos ✅ Completed
1.1.3.4 View indoor obstacle (POI) markers at high zoom ✅ Completed
1.1.3.5 Toggle visibility of passive (stale/unverified) reports ✅ Completed
1.1.3.6 Search for a location by text input ✅ Completed
1.1.3.7 Manually select a location by dropping a pin ✅ Completed

1.1.4 Route Planning

Requirement ID Description Status
1.1.4.1 Manually select a starting point ✅ Completed
1.1.4.2 Manually select a destination point ✅ Completed
1.1.4.3 Request a route calculation ✅ Completed
1.1.4.4 View the generated route as a static visual path ✅ Completed
1.1.4.5 View textual route summary (total distance, estimated time) ✅ Completed

1.1.5 Obstacle Reporting

Requirement ID Description Status
1.1.5.1 Initiate a new report at current GPS location ✅ Completed
1.1.5.2 Required Outdoor/Indoor context categorization ✅ Completed
1.1.5.3 Optionally select an obstacle category ✅ Completed
1.1.5.4 Required upload of at least one photo as evidence ✅ Completed
1.1.5.5 Add a text description to the report ✅ Completed

1.1.6 Verification & Community Moderation

Requirement ID Description Status
1.1.6.1 Upvote (confirm) an unverified report ✅ Completed
1.1.6.2 Flag a report as inaccurate or fake ✅ Completed
1.1.6.3 Propose a solution by uploading a "Resolved" photo ❌ Not Implemented
1.1.6.4 View the status timeline of an issue ✅ Completed

Notes: 1.1.6.3 — there is no citizen-facing "propose resolution with photo" flow; resolution-photo upload is handled exclusively by the Infrastructure Authority workflow (1.1.7.4), and citizens only cast "Confirm Resolution" votes.

1.1.7 Infrastructure Authority Operations

Requirement ID Description Status
1.1.7.1 Access a dedicated issue-management dashboard ✅ Completed
1.1.7.2 Filter reports by status ✅ Completed
1.1.7.3 Mark an issue as "Resolved – Awaiting Validation" ✅ Completed
1.1.7.4 Required post-repair verification photo on status update ✅ Completed
1.1.7.5 Append official repair notes to the issue ✅ Completed

1.1.8 Administrator Operations

Requirement ID Description Status
1.1.8.1 View system-wide queue of community-flagged reports ✅ Completed
1.1.8.2 Permanently delete malicious reports ✅ Completed
1.1.8.3 Suspend or ban abusive user accounts ✅ Completed

1.2.1 General Visualization & User Interface

Requirement ID Description Status
1.2.1.1 Render standard geographic base layers ✅ Completed
1.2.1.2 Hide indoor markers until zoom exceeds High-Detail threshold ✅ Completed
1.2.1.3 Render passive reports with a distinct semi-transparent style ✅ Completed

1.2.2 Routing Engine Logic

Requirement ID Description Status
1.2.2.1 Calculate routes on an outdoor street-network graph ✅ Completed
1.2.2.2 Exclude all "Indoor" reports from routing ✅ Completed
1.2.2.3 Exclude "Passive" reports from routing ✅ Completed
1.2.2.4 Generate routes up to the building entrance of the destination 🟡 Partial

Notes: 1.2.2.2 / 1.2.2.3 — only VERIFIED outdoor obstacles are passed to Valhalla as exclusion polygons; indoor and passive reports are inherently excluded from the avoidance set. 1.2.2.4 — routes are generated to the user-selected destination coordinate; there is no dedicated building-entrance snapping.

1.2.3 Report Lifecycle & State Management

Requirement ID Description Status
1.2.3.1 Assign initial "Unverified" status to new reports ✅ Completed
1.2.3.2 Auto-transition to "Passive" after a period with no interaction 🟡 Partial
1.2.3.3 Auto-transition to "Confirmed" when upvotes reach the threshold ✅ Completed

Notes: 1.2.3.2 — implemented and tested as the decay_unverified_reports management command, but no scheduler/cron is configured to run it automatically in the deployed environment.

1.2.4 Resolution & Validation Workflow

Requirement ID Description Status
1.2.4.1 Marker is not removed when an authority marks it resolved ✅ Completed
1.2.4.2 Status updated to "Resolved – Awaiting Validation" ✅ Completed
1.2.4.3 Notify the original reporter ✅ Completed
1.2.4.4 Notify users who previously upvoted the issue ✅ Completed
1.2.4.5 Require N "Confirm Resolution" votes to transition to Closed ✅ Completed

1.2.5 Trust & Gamification System

Requirement ID Description Status
1.2.5.1 Maintain a Trust Score per registered user ✅ Completed
1.2.5.2 Increment Trust Score when a submitted report is verified ✅ Completed
1.2.5.3 Do not increment Trust Score for guest submissions ✅ Completed
1.2.5.4 Grant "Trusted Contributor" role above the threshold ✅ Completed
1.2.5.5 Lower verification threshold for Trusted Contributors ✅ Completed

Notes: 1.2.5.3 — enforced structurally: report submission requires authentication, so guests cannot create reports that would earn a score.

1.2.6 Data Moderation & Alerts

Requirement ID Description Status
1.2.6.1 Auto-flag accounts with high volume of unverified reports as spam ❌ Not Implemented
1.2.6.2 Async notification to reporter on "Confirmed" transition ✅ Completed
1.2.6.3 Async notifications to reporter + upvoters on "Resolved – Awaiting Validation" ✅ Completed
1.2.6.4 Authenticated endpoint returning notifications, newest first ✅ Completed

Notes: 1.2.6.1 — moderation is report-level (a report reaching SPAM_FLAG_THRESHOLD flags enters the moderation queue); there is no account-level rate/volume detection that marks a user as "Potential Spam".

Non-Functional Requirements

1. Availability
Requirement ID Description Status
NFR-1.1 Available and functional as a web application ✅ Completed
NFR-1.2 Available and functional as a mobile application 🟡 Partial

Notes: NFR-1.2 — Android APK is produced via an EAS CI workflow; iOS is runnable through Expo but there is no production iOS build pipeline.

2. Performance
Requirement ID Description Status
NFR-2.1 Render map data/markers without perceptible delay 🟡 Partial
NFR-2.2 Compute routes within a reasonable time 🟡 Partial
NFR-2.3 Handle concurrent users without response-time degradation 🟡 Partial

Notes: Bbox-scoped queries, DB indexes, stale-while-revalidate caching, and select_for_update + atomic transactions address these, but there are no measured performance/load benchmarks proving the targets.

3. Reliability
Requirement ID Description Status
NFR-3.1 Do not lose user-submitted reports on internal failure ✅ Completed
NFR-3.2 Validate all user-submitted data before public display ✅ Completed
NFR-3.3 Prioritize verified data over unverified in routing ✅ Completed
NFR-3.4 Recover from unexpected failures without manual intervention 🟡 Partial

Notes: NFR-3.1 — guaranteed via atomic writes to managed PostgreSQL. NFR-3.4 — relies on the hosting platform's auto-restart; no application-level self-recovery mechanism is implemented or tested.

4. Usability
Requirement ID Description Status
NFR-4.1 Conform to WCAG 2.1 Level AA 🟡 Partial
NFR-4.2 Usable on desktop and mobile screen sizes ✅ Completed
NFR-4.3 Operable using screen readers on all platforms 🟡 Partial
NFR-4.4 First-time user can submit a report without training 🟡 Partial

Notes: NFR-4.1 / 4.3 — an accessibility-standards catalog exists for obstacle classification, but the app UI has only minimal accessibilityLabel/accessibilityRole usage and no formal WCAG audit. NFR-4.4 — the report flow is a guided step form, but no usability validation was performed.

5. Security
Requirement ID Description Status
NFR-5.1 Authenticate users before submission/data modification ✅ Completed
NFR-5.2 Transmit all data over encrypted connections ✅ Completed
NFR-5.3 Enforce role-based access control across roles ✅ Completed
6. Privacy
Requirement ID Description Status
NFR-6.1 Require explicit permission for device location ✅ Completed
NFR-6.2 Do not expose PII of users who report issues 🟡 Partial

Notes: NFR-6.2 — reporter identity in public obstacle data is limited to a UUID, but the public status-history serializer exposes the email of the actor who changed a status (changedBy), which is a PII leak that should be reduced to a display name/ID.

7. Portability
Requirement ID Description Status
NFR-7.1 Function on all major modern browsers ✅ Completed
NFR-7.2 Support current and recent iOS and Android versions 🟡 Partial

Notes: NFR-7.2 — built on Expo SDK 54 / RN 0.81 (broad OS support), but only Android has a build pipeline and there is no tested device/OS-version matrix.

8. Scalability
Requirement ID Description Status
NFR-8.1 Support multiple municipalities without degradation ❌ Not Implemented
NFR-8.2 Accommodate a growing number of reports and users over time 🟡 Partial

Notes: NFR-8.1 — there is no multi-tenant/municipality scoping; the system operates on a single shared dataset. NFR-8.2 — paginated, indexed PostgreSQL-backed design supports growth, but this is not validated by load testing.

4.3 API Endpoints

4.3.1 API Documentation

[TODO] Link to the live Swagger UI / OpenAPI documentation here. It must cover every endpoint available in the final release and be consistent with the Final SRS. Any endpoint deprecated since the previous milestone must be removed or clearly marked deprecated.

  • Live API Docs: [TODO – paste deployed Swagger/OpenAPI URL]

4.3.2 Sample Usage Scenarios

Provide four scenarios. At least three must demonstrate new functionality added after the previous milestone. Do not show simple data retrieval (e.g., "Get User Profile") — choose endpoints that involve logic (multi-step workflows, state transitions, validations, side effects).

For each scenario, include: HTTP method + URL, a one-sentence description of what the user is achieving, a multi-line curl command (using \ line continuations) with the request body and only essential headers, and the actual JSON response (truncate the middle of long lists but keep structure visible).

Scenario 1: [TODO – Name of Scenario]
  • Endpoint: [METHOD] /api/path
  • Scenario Description: [TODO – one sentence: what the user is achieving]
  • The Request:
curl -X POST "https://api.example.com/path" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "field": "value"
  }'
  • The Response:
{
  "field": "value"
}
Scenario 2: [TODO – Name of Scenario]
  • Endpoint: [METHOD] /api/path
  • Scenario Description: [TODO]
  • The Request:
curl -X POST "https://api.example.com/path" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "field": "value"
  }'
  • The Response:
{
  "field": "value"
}
Scenario 3: [TODO – Name of Scenario]
  • Endpoint: [METHOD] /api/path
  • Scenario Description: [TODO]
  • The Request:
curl -X POST "https://api.example.com/path" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "field": "value"
  }'
  • The Response:
{
  "field": "value"
}
Scenario 4: [TODO – Name of Scenario]
  • Endpoint: [METHOD] /api/path
  • Scenario Description: [TODO]
  • The Request:
curl -X POST "https://api.example.com/path" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "field": "value"
  }'
  • The Response:
{
  "field": "value"
}

4.4 User Interface / User Experience

Artifacts

  • Frontend Code (Web): [TODO – link to bounswe2026group3/frontend final commit / folder]
  • Frontend Code (Mobile): [TODO – link to bounswe2026group3/mobile final commit / folder]

Screenshots

Provide screenshots of only the new or significantly modified web and mobile interfaces developed in this milestone. Pair each image with a short description.

  • [TODO – screenshot link] — [TODO – description]
  • [TODO – screenshot link] — [TODO – description]
  • [TODO – screenshot link] — [TODO – description]

4.5 Utilized Standards

Document the key W3C standards applied in the project.

Compliance Summary

[TODO] One bulleted list of every W3C standard implemented in the final milestone release (e.g., WCAG 2.1, Activity Streams 2.0, JSON-LD, …).

  • [TODO – Standard 1]
  • [TODO – Standard 2]
  • [TODO – Standard 3]

Deep Dive

For each standard listed above, repeat the block below.

Standard: [TODO – name, e.g., WCAG 2.1]
  • Evidence: [TODO – link to the relevant Issue or Pull Request that contains the source code]
  • Code Coverage: [TODO – which file(s) / module(s) cover the standard]
  • Reasoning: [TODO – describe clearly how the implementation fulfills the requirements or intent of the standard]
Standard: [TODO – name]
  • Evidence: [TODO]
  • Code Coverage: [TODO]
  • Reasoning: [TODO]

4.6 Testing & Quality Assurance

Test Execution Reports

Verbose reports (HTML for humans, XML/JUnit for machines) for all three layers. Commit the report files to the repository (e.g., a reports/ folder) or attach them to the wiki, then link here. The reports must show all tests passing, including regressions from the previous milestone.

New Test Evidence

Direct links to the source code of the new tests added in this milestone.

  • Integration Tests (new API & service interactions): [TODO – link to source]
  • End-to-end (E2E) Tests (final user workflows): [TODO – link to source]
  • UI/UX Tests (mobile & web interfaces): [TODO – link to source]

Impact Analysis

Reflect on the value the new tests provided. Do not dryly list every test case.

  • Coverage: [TODO – which critical new functionality is now fully covered by these tests?]
  • Bug Detection: Describe at least two specific bugs or edge cases these new tests caught and that we fixed before the final release.
    1. [TODO – bug #1: what the test caught, what we fixed]
    2. [TODO – bug #2: what the test caught, what we fixed]
  • Readiness: [TODO – how does this test suite confirm the system is stable enough for an Official Release?]

4.7 Demo Reflections & Notes

Notes Taken During the Demo

[TODO – link to wiki page containing raw demo notes, or paste them inline.]

Reflections

[TODO – link to wiki page containing post-demo reflections, or paste them inline. Distinct from 3.1.5: this is the raw note-taking; 3.1.5 is the executive-level reflection.]

5. Individual Contributions

Each member adds a subsection below. Subsections are sorted alphabetically by surname. Include only contributions made since the previous milestone. Every claim must be backed by a hyperlink to a GitHub PR or Issue.

Strict limits: Top 3 issues per category (Code-Related, Non-Code-Related). Listing more than 3 per category incurs a grade penalty.

Akkaya, Ali (Subgroup: [TODO])

  1. Responsibilities: [TODO – assigned role / "Job Description", e.g., "Backend Team Lead"]
  2. Main Contributions: [TODO – execution summary: features, tasks, artifacts actually delivered this milestone]
  3. Significant Issues (Top 3 per category):
    • Code-Related:
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
    • Non-Code-Related:
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
  4. Pull Requests:
    • [#PR – TODO] – [description] – [conflict resolution, if applicable]
    • [#PR – TODO] – [description]
  5. AI Transparency & Documentation:
    • Tool summary:
      1. [TODO – Tool 1, e.g., Cursor]: [functional role: debugging, design generation, brainstorming, …]
      2. [TODO – Tool 2, e.g., Claude]: [functional role]
    • Prompts: [TODO – link to the prompts log stored in the GitHub Wiki]
  6. Individual Testing Efforts:
    • [Test name, commit #TODO] – [brief explanation]
    • [Test name, commit #TODO] – [brief explanation]
  7. Additional Information: [TODO – any other significant task not captured above]

Aydemir, Bora (Subgroup: Frontend / Mobile)

  1. Responsibilities: Owner of the React Native / Expo frontend and mobile codebase. In the final milestone my responsibility expanded from feature ownership (Report Obstacle, Mobility Profile, route planning integration during MVP) to two new areas:

    • Authority-facing frontend. End-to-end ownership of the Infrastructure Authority dashboard UI — the surface the Authority role uses to triage, resolve, and validate reports.
    • Frontend QA infrastructure. Stood up the project's first dedicated end-to-end test suite (Playwright) and wired it into CI, closing the E2E gap explicitly flagged as a milestone risk in D6 §D6.4.

    In parallel I continued contributing to design and requirements work (UML refinement, SRS revisions for new flows), to sprint planning (opening scoped issues for the team's post-MVP work), and to project-level documentation (the wiki template that the team is filling in right now).

  2. Main Contributions:

    • Authority Dashboard UI (PR #229, Issue #181). Built the dedicated dashboard surface for the Infrastructure Authority role: filterable report queue, report-detail flow with the "Mark as Resolved – Awaiting Validation" action, required post-repair photo upload, and the official repair-note field. Covers SRS 1.1.7.1 – 1.1.7.5.
    • Playwright E2E smoke test suite (PR #279, Issue #178). Added the project's first end-to-end suite (frontend/e2e/) covering core user flows — guest browse, register, login, submit report, view report detail — and wired it into the CI pipeline gated by E2E_*_URL repo variables.
    • Unverified marker rendering + auto-verify revert (PR #243, Issue #235). Rendered UNVERIFIED reports on the map with a hollow / dashed style and reverted the MVP-era auto-verify shortcut so new reports are submitted with the correct initial status (SRS 1.2.1.3, 1.2.3.1).
    • Verification & resolution progress indicators (PR #246, Issue #240). Added the progress UI showing how close a report is to the upvote-verification threshold and to the resolution-confirmation threshold, making the trust-score / community-gating logic visible to users.
    • Accessibility standard violation chips (PR #262, Issue #261). Wired the W3C / domain accessibility standards catalog into the report submit and detail flows: reports now surface which standards an obstacle violates.
    • Saved-place tap-to-focus + precision fixes (PR #256, PR #245). Made saved places (Home / Work) tappable on the profile to focus directly on the map, increased coordinate precision so saved places match map state, and surfaced real save errors instead of swallowing them.
    • Mobility profile API prefix fix (PR #244, Issue #231). Fixed silent 404s on mobility-profile requests caused by the missing /api/ prefix — a cross-team integration bug that had been swallowed.
    • Profile UI cleanup (PR #254) and Notifications / max-slope input fixes (PR #270). Removed the unused ACTIVE pill and stub Badges card based on role, fixed a duplicate Notifications heading, and fixed the max-slope-gradient input in the mobility profile form.
    • Final Milestone Deliverables wiki template. Drafted the full structure of this document (every section / subsection per the official template) with explicit English [TODO] markers so the team could fill the remaining slots in parallel.
    • Sprint planning post-MVP (Issues #170, #180, #182, #185, #186). Translated customer / TA feedback from the MVP demo into scoped, independently pickable issues that drove the team's first post-MVP sprint.

  3. Significant Issues (Top 3 per category):

    • Code-Related:
      • #235 — Show UNVERIFIED reports on the map (hollow + dashed) and submit reports as UNVERIFIED by default. Implemented as PR #243; reverted the MVP-era auto-verify shortcut and brought report lifecycle rendering in line with SRS 1.2.1.3 and 1.2.3.1.
      • #181 — Authority dashboard UI. Implemented as PR #229; net new surface for the Authority role and a hard prerequisite for the Authority demo segment.
      • #261 — Accessibility standard violation chips. Implemented as PR #262; surfaces the standards catalog (1.2.x.x family) in the report flows.
    • Non-Code-Related:
      • Final Milestone Deliverables wiki template (this document). Authored the full template structure replacing the half-Turkish placeholders and split Section 5 into one editable subsection per team member, so all seven teammates could fill their sections in parallel without coordination overhead.
      • #225 — Final Demo Plan organisation. Collaborated on structuring the scripted demo flow (scenarios A–F, role assignments, pre-seeded demo data strategy) on the Final Demo Plan wiki page.
      • Lab 8 documentation peer review. Peer-reviewed the team's Lab 8 wiki deliverables — Project Retrospective and Use of Standards — to ensure they accurately reflected the team's actual progress, architectural decisions, and roadmap before the documents were finalised.

  4. Pull Requests:

    • #279 — test(e2e): Playwright smoke test suite [QA]. New E2E suite for core flows, gated in CI.
    • #270 — fix(frontend): remove duplicate Notifications heading and max slope gradient input.
    • #262 — feat(reports): accessibility standard violation chips on submit and detail.
    • #256 — feat(frontend): tap a saved place on profile to focus it on the map.
    • #254 — refactor(frontend): drop ACTIVE pill and stub Badges card from profile.
    • #246 — feat: show progress toward verification and resolution.
    • #245 — fix(places): accept high-precision lat/lng + surface real save errors + UX polish.
    • #244 — fix(frontend): prefix mobility profile requests with /api/. Cross-team integration fix.
    • #243 — feat: show UNVERIFIED reports on the map (hollow + dashed) and submit reports as UNVERIFIED by default.
    • #229 — feat(authority): dashboard UI for infrastructure authority role.

    Conflict resolution: none of the above required non-trivial merge-conflict resolution. The merge-freeze policy in the final 48 hours and the consistent squash-merge workflow on main kept the branch history clean and rebase-friendly.

  5. AI Transparency & Documentation:

    I used two AI tools in clearly separated roles across this milestone — Gemini for the what (specification, design, planning) and Claude Code for the how (implementation, refactoring, testing). The split was intentional: Gemini is well-suited to long-form, requirement-shaped thinking (translating customer Q&A into structured requirement IDs, iterating on UML diagrams, sanity-checking scenario coverage against use cases), and Claude Code is well-suited to running directly inside the repository and producing working code that compiles, passes tests, and respects existing patterns. Gemini also frequently sat upstream of Claude Code: when I had a coding intent that was still vague (e.g. "I want to display verification progress on the map and on the report detail screen, in a way that doesn't conflict with the existing trust-score UI"), I would describe it to Gemini in conversational form, have it produce a precise, well-scoped prompt with the relevant files, constraints, and acceptance criteria, and then hand that prompt to Claude Code for execution.

    • Tool summary:
      1. Gemini (Google) — design, requirements, planning, prompt generation. Used primarily during the design and specification phases throughout the semester, and continuously during the final milestone for: (a) drafting and refining the SRS requirement hierarchy (1.x.x numbering) and translating customer-meeting transcripts and TA feedback into structured requirements; (b) iterating on UML diagrams — Class Diagram alignment between frontend models and the Django ORM, Sequence Diagram for the obstacle reporting flow, Use Case Diagram for the Municipality Resolution scenario; (c) scoping post-MVP sprint issues (acceptance criteria, dependencies, effort estimates) before opening them on GitHub; and (d) acting as a "prompt generator" upstream of Claude Code — turning a conversational coding intent into a precise, file-scoped, constraint-aware prompt. Conversation archive: gemini.google.com/app/a857719f084f36e8.
      2. Claude Code (Anthropic) — implementation, refactoring, testing, debugging. Used as the primary in-editor coding assistant: scaffolded the Playwright E2E suite (PR #279) including the page-object pattern and CI config; implemented the Authority Dashboard UI (PR #229) and the verification/resolution progress indicators (PR #246); diagnosed the silent /api/ prefix bug on mobility-profile requests (PR #244); refactored the saved-place coordinate handling for high-precision lat/lng (PR #245); and drafted the structural skeleton of this very Final Milestone Deliverables wiki page. Operated as an iterative loop: receive a Gemini-shaped prompt → implement → run lints/tests → revise based on failures.
    • Prompts: Gemini conversation archive (covers requirements, UML iteration, and prompt-generation sessions for Claude): gemini.google.com/app/a857719f084f36e8. Claude Code sessions are not centrally archived as a single transcript; the workflow and concrete usage points are described above and each PR's commit history reflects the resulting changes.

  6. Individual Testing Efforts:

    • Playwright E2E smoke suite — new this milestone. frontend/e2e/ introduced in PR #279 (Issue #178). Covers guest map browse, register, login, submit report, and report-detail flows; runs in CI gated by E2E_*_URL repo variables and MOCK=true until backend test-mode is finalised.
    • Frontend Jest component / hook / API tests — carried and extended from MVP. I authored the original suites for MobilityProfileCard (244 lines), ReportForm (120 lines), ReportSuccessScreen (77 lines), mobilityProfileApi (132 lines), useLocation (73 lines), and the reports API client (84 lines) during MVP (documented in D6 §D6.4). These suites continued to gate frontend regressions in the final milestone — the duplicate Notifications heading and max-slope-input bugs (PR #270) were caught against this baseline.
    • Manual / contract testing on cross-team integration fixes. The /api/ prefix fix (PR #244) and the saved-place precision fix (PR #245) were both validated end-to-end against the deployed backend before merge to ensure no other endpoints had silent contract drift.

  7. Additional Information:

    • Team leadership across design, role assignments, and demo flow decisions (whole project). Across the full semester I generally took the lead on design-side decisions — driving the requirements-elicitation discussions, owning the structural choices on the UML diagrams (Class Diagram alignment, Sequence Diagram for the report flow, Use Case Diagram for the Municipality Resolution scenario), and proposing the frontend/backend/mobile sub-team split and the per-feature role assignments that the team adopted. I played the same role for both the MVP demo (defining scenarios, scripted user journey, pre-seeded data strategy) and the Final Milestone demo flow (scenarios A–F, role split between web/mobile operators, presenter assignments). When a project-level decision needed to be made — what to descope, which routing approach to commit to, what the resolution model should look like, how to organize the demo — I typically opened the discussion, framed the trade-offs, and drove the team toward a concrete decision.
    • Final Milestone Deliverables template authorship. I authored the structural skeleton of this wiki page — replacing the half-Turkish placeholder content with the full English template, splitting Section 5 into one editable subsection per team member sorted alphabetically by surname, and tagging every empty slot with an explicit [TODO] marker so the team could fill remaining sections in parallel without coordination overhead. The push history on the wiki repo shows this as the initial "full template" commit and the subsequent fill-in commits.
    • Post-MVP planning ownership. Lab 8 documented this in detail: I synthesised TA and customer feedback from the MVP demo into the team's revised plan and opened five scoped issues (#170, #180, #182, #185, #186) that defined the first post-MVP sprint backlog.
    • Continuity with MVP responsibilities. The Test Plan & Coverage wiki, the Mobility Profile feature, the Report Obstacle flow, and the route-planning integration that I owned during MVP all remained under my maintenance in the final milestone; the new PRs above are extensions or corrections of those areas, not net-new ownership.

Delier, Ömer Belemir (Subgroup: [TODO])

  1. Responsibilities: [TODO]
  2. Main Contributions: [TODO]
  3. Significant Issues (Top 3 per category):
    • Code-Related:
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
    • Non-Code-Related:
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
  4. Pull Requests:
    • [#PR – TODO] – [description] – [conflict resolution, if applicable]
    • [#PR – TODO] – [description]
  5. AI Transparency & Documentation:
    • Tool summary:
      1. [TODO – Tool 1]: [functional role]
      2. [TODO – Tool 2]: [functional role]
    • Prompts: [TODO – link to prompts log]
  6. Individual Testing Efforts:
    • [Test name, commit #TODO] – [brief explanation]
    • [Test name, commit #TODO] – [brief explanation]
  7. Additional Information: [TODO]

Evren, Arif (Subgroup: [TODO])

  1. Responsibilities: [TODO]
  2. Main Contributions: [TODO]
  3. Significant Issues (Top 3 per category):
    • Code-Related:
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
    • Non-Code-Related:
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
  4. Pull Requests:
    • [#PR – TODO] – [description] – [conflict resolution, if applicable]
    • [#PR – TODO] – [description]
  5. AI Transparency & Documentation:
    • Tool summary:
      1. [TODO – Tool 1]: [functional role]
      2. [TODO – Tool 2]: [functional role]
    • Prompts: [TODO – link to prompts log]
  6. Individual Testing Efforts:
    • [Test name, commit #TODO] – [brief explanation]
    • [Test name, commit #TODO] – [brief explanation]
  7. Additional Information: [TODO]

Kemeç, Ulaş Sertan (Subgroup: [TODO])

  1. Responsibilities: [TODO]
  2. Main Contributions: [TODO]
  3. Significant Issues (Top 3 per category):
    • Code-Related:
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
    • Non-Code-Related:
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
  4. Pull Requests:
    • [#PR – TODO] – [description] – [conflict resolution, if applicable]
    • [#PR – TODO] – [description]
  5. AI Transparency & Documentation:
    • Tool summary:
      1. [TODO – Tool 1]: [functional role]
      2. [TODO – Tool 2]: [functional role]
    • Prompts: [TODO – link to prompts log]
  6. Individual Testing Efforts:
    • [Test name, commit #TODO] – [brief explanation]
    • [Test name, commit #TODO] – [brief explanation]
  7. Additional Information: [TODO]

Kılıç, Ekin (Subgroup: [TODO])

  1. Responsibilities: [TODO]
  2. Main Contributions: [TODO]
  3. Significant Issues (Top 3 per category):
    • Code-Related:
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
    • Non-Code-Related:
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
      • [#TODO] – [brief explanation]
  4. Pull Requests:
    • [#PR – TODO] – [description] – [conflict resolution, if applicable]
    • [#PR – TODO] – [description]
  5. AI Transparency & Documentation:
    • Tool summary:
      1. [TODO – Tool 1]: [functional role]
      2. [TODO – Tool 2]: [functional role]
    • Prompts: [TODO – link to prompts log]
  6. Individual Testing Efforts:
    • [Test name, commit #TODO] – [brief explanation]
    • [Test name, commit #TODO] – [brief explanation]
  7. Additional Information: [TODO]

Önder, Baran (Subgroup: Frontend)

  1. Responsibilities: Map & routing infrastructure (web and mobile), obstacle interaction system, indoor report form, notification system, report discussion section, saved places, and frontend performance optimisations.

  2. Main Contributions: Built the core map view and route-planning screens for both web (Leaflet) and mobile (WebView + Leaflet), then progressively enriched them with obstacle interactions (upvote / flag / confirm-resolution), indoor-specific form fields with auto-geocoding, a comments/discussion section on report detail, a saved-places flow, an in-app notification list, and a series of performance fixes (debounced bounds fetch, icon caching, stale-while- revalidate obstacle refresh). Also contributed backend work: Comment model

    • GET/POST endpoint, routing serialiser unit tests, and Valhalla exclude_locations integration.

  3. Significant Issues (Top 3 per category):

    • Code-Related:
      • #190 – Obstacle interactions: implemented InteractionBar (upvote/flag with optimistic updates), ConfirmResolutionButton with eligibility check, obstacle detail screen, and web/native navigation to that screen.
      • #192 – Indoor form fields: added buildingName/floor/isIndoor to the report payload, auto-filled building name via reverse geocoding, context-specific indoor obstacle categories, a distinct indoor marker icon, and cleaned up timer refs on unmount.
      • #138 – Routing engine migration: replaced the existing OSRM-based hacky rerouting logic with Valhalla exclude_locations integration, enabling proper obstacle-aware route planning; also reduced obstacle cache TTL for faster report visibility.
    • Non-Code-Related:
      • Meeting Moderation & Documentation – Facilitated weekly synchronization meetings between the frontend and backend sub-teams, and consistently documented comprehensive meeting notes to maintain team alignment throughout the milestone.
      • Routing Engine Research – Conducted research on spatial routing engines, specifically evaluating Valhalla's exclude_locations capabilities to replace geometric waypoint offsetting for robust, road-following obstacle avoidance.
      • Project Management & Issue Tracking – Actively maintained the repository's GitHub issue board by defining, organizing, and tracking milestone tasks related to map overlays, notification systems, and user interaction mechanics.

  4. Pull Requests:

    • #112 – Initial web map view and route-planning screen (Leaflet); merged after multiple package-lock conflict resolutions with main.
    • #117 – Mobile map and route-planning screens via WebView + Leaflet; fixed re-render loop causing map flicker and loading-bar resize jitter.
    • #190 – Obstacle interactions feature (InteractionBar, detail screen, upvote/flag API, ConfirmResolutionButton); reconciled server upvote count after optimistic update.
    • #192 – Indoor form fields (geocoding, categories, marker icon, tests); resolved merge conflict with main (HIGH_DETAIL_ZOOM + useRouter changes).
    • #242 – Report discussion section (Comment model, GET/POST endpoint, redesigned detail screen, status history); fixed status-history reason parsing and photo display regression.
    • #212 – Notifications tab and in-app notification list with profile toggle; added unit tests for NotificationsScreen.
    • #211 – Saved places: profile screen, map quick-select, SavePlaceModal; surfaced save errors and added modal unit tests.
    • #210 – Route summary panel added to MapView (native and web).
    • #230 – Ensured route response fields; added 4 km/h fallback for estimatedTime and serialiser unit tests.
    • #222 – Passive obstacle toggle added to map view.
    • #214 – Toggle behaviour for upvote and flag interactions; fixed showAlert recursion on native.
    • #149 – Choose-on-map location picker integrated into report form.
    • #138 – Replaced OSRM hacky rerouting with Valhalla exclude_locations; reduced obstacle cache TTL for faster report visibility.
    • #133 – Aligned frontend map API with backend response format; added obstacle prefetch on mount before map initialises.
    • #252 – Map performance: debounced bounds fetch, cached icons, fixed popup flash on back-navigation, accumulated obstacles across fetches, deferred state updates to eliminate zoom-out marker glitch.
    • #260 – Collapsed route inputs into compact bar once route is calculated.
    • #276 – Stale-while-revalidate refresh strategy for obstacle layer.
    • #277 – Push/in-app notification to reporter when their report is closed.
    • #153 – UI aesthetics pass across web and mobile screens; fixed search bar collapse on mobile and enhanced premium map styling.
    • #74 – Baran joke button with JokeAPI (Lab 5 stub-app task).

  5. AI Transparency & Documentation:

    • Tool summary:
      1. Claude (claude.ai chat): Used for planning feature implementation steps, understanding unfamiliar APIs (Valhalla, Leaflet), and debugging tricky React Native issues like WebView re-render loops and optimistic update reconciliation.
      2. Claude Code: Used to scaffold unit test suites — generated initial failing test skeletons for InteractionBar, indoor form fields, and NotificationsScreen which were then reviewed, adjusted, and completed manually before committing.
    • Prompts:
      • "I have a React Native component called InteractionBar that handles upvote and flag button taps. Can you write failing Jest unit tests for it? I want tests for: tap triggers API call, button is disabled for guest users, and count updates optimistically."
      • "My WebView map is re-rendering on every state change and causing flicker. Here is the component, what is causing it and how do I fix it?"
      • "Can you help me write a test for my SavePlaceModal that checks if the error message shows up when the save API call fails?"
      • "I am replacing OSRM with Valhalla for routing. OSRM used a hacky waypoint workaround to avoid obstacles. How does Valhalla exclude_locations work and how should I restructure my API call?"
      • "I need to add indoor-specific fields to my report form. When the user selects INDOOR context, buildingName and floor fields should appear. How should I structure the conditional rendering and what is the cleanest way to auto-fill buildingName from coordinates using reverse geocoding?"
      • "My Jest test is failing because of a missing act() wrapper when testing async state updates in my form component. Here is the error and here is the test, how do I fix it?"
      • "I want to implement stale-while-revalidate for my obstacle layer on the map. Right now I fetch fresh data every time bounds change. How can I show cached data immediately and refresh in the background?"
      • "Can you write unit tests for my routing serializer? It should always return estimatedTime and if the backend does not provide it, it should fall back to distance divided by 4km/h walking speed."
      • "I have a notifications screen that fetches a list from the API and renders it. Write me basic unit tests that check: list renders correctly, empty state shows a message, and loading spinner shows while fetching."
      • "My map popup is flashing briefly when the user navigates back to the map screen. I think it is because markers re-mount. Here is my marker rendering logic, what is the best way to fix this?"

  6. Individual Testing Efforts:

    • InteractionBar unit tests, commit 6991fc8 (#190) – Wrote failing tests for upvote tap, disabled state, and guest-user gating before implementing the component (TDD cycle).
    • Indoor form field tests, commits 0180d65 & 282e84c (#192) – Added failing tests for indoor fields, then fixed act() wrapper, clearAllMocks, and auth mock to make them pass.
    • NotificationsScreen unit tests, commit 1f1eaef (#212) – Covered notification list rendering and toggle behaviour.
    • SavePlaceModal tests, commit a63ac1f (#211) – Validated save-error surfacing and modal interaction.
    • Routing serialiser unit tests, commit 20dfbdd (#230) – Verified estimatedTime fallback and correct field serialisation.

  7. Additional Information: Worked across both web and mobile platforms simultaneously, maintaining shared Leaflet-based map logic while handling React Native-specific rendering constraints (WebView re-render loops, loading bar jitter, marker flicker) separately — a non-trivial cross-platform balancing act. Contributions were not limited to frontend; backend work included the Comment model with GET/POST endpoints, routing serialiser with estimatedTime fallback, and Valhalla exclude_locations integration. Followed a TDD approach in multiple PRs by writing failing tests before implementing the feature (InteractionBar, indoor form fields, NotificationsScreen). Several contributions were infrastructure-level rather than feature-level — notably the Valhalla routing engine migration away from OSRM and the stale-while-revalidate obstacle refresh strategy — decisions that affected the reliability and correctness of the app as a whole.

6. Final Software Release & Setup

Project

Team Members

Lab Reports

Weekly Meetings

Scenarios and Mock ups

Use Case Diagrams

Class Diagram

Sequence Diagrams

Milestone Review

Clone this wiki locally