Final Milestone Deliverables

1. Meeting Notes

Weekly Meetings

2. Finalized Project Documentation

2.1 Final SRS

Software Requirements Specification

2.2 Final Design

3. Project Review

Executive Summary

Project Status Summary:
The project reached its final milestone with the main backend, web, and Android mobile components implemented. NEPH provides an emergency coordination platform focused on disaster preparedness and response, including user authentication, profile and privacy management, emergency help requests, volunteer availability, safety circles, nearby visible users, gathering areas, notifications, and admin monitoring flows.
Deliverable Status:
The final deliverables include the deployed web application, deployed backend API, Android APK release, final demo data, release notes, setup documentation, and project documentation. The system is available through the production web and backend deployments, while the Android application is delivered as a signed APK.
Final Release Notes:
The final release includes the web admin/dashboard experience, backend API routes, Android mobile application, Docker-based local deployment setup, PostgreSQL migration flow, and final Boğaziçi demo seed data. The release supports emergency help request creation, volunteer assignment visibility, assigned request tracking, safety status updates, safety circles, nearby user awareness, gathering area discovery, announcements, and notification-related flows.
Process Improvements:
Throughout the project, the team improved its Git workflow, issue and pull request management, subgroup coordination, API-contract discipline, documentation quality, and testing practices. Backend, web, and mobile subgroups became more aligned over time through shared data contracts, integration testing, and release-focused verification.
Final Milestone Demo Reflections:
The final milestone demo showed that the main user journeys work across the project components. The demo scenarios connected mobile emergency flows, volunteer response, safety circle awareness, nearby residential-area users, gathering areas, admin coordination, announcements, and live help request visibility. Preparing the demo also helped the team identify final data needs, UI polish points, and the importance of having reliable demo seed data.
What Could Have Been Done Differently:
At the beginning of the project, the team was divided mainly into backend and frontend subgroups. Later, we moved toward a more full-stack working style, where team members became more involved across backend, web, and mobile responsibilities. If we had adopted this approach earlier, integration problems could have been noticed sooner and team members would have had a better understanding of the whole system.

4. Progress Based on Teamwork

4.1 Team Contribution Summary

Team Member	Contributions (Elaborated Summary)	Major PRs/Issues
Kağan Can	Coordination and location model: coordinated cross-functional final-milestone work and helped align backend, web, Android, and documentation priorities around demo-critical flows. Separated operational location from residential/profile location so availability, assignment, map, and privacy behavior could use the correct location source. Map and request stabilization: improved Android map/resource-map behavior with viewport-based discovery, loading/state feedback, and final map stabilization. Also handled Request Help, Gathering Areas, and location-selection fixes that reduced final-demo risk. Release support: contributed to setup/release documentation and final documentation cleanup.	#428, #531, #602, #439, #532, #603, #623
Ethem Erinç Cengiz	Mobile redesign and full-stack implementation: redesigned the Android mobile UI from the ground up with a Compose design system, reusable components, refreshed navigation/app shell, and updated auth, home, profile, notification, map, and request/help screens. Authentication, profile, and parity: implemented Google Sign-In across backend, web, and Android; removed unsupported social-login behavior; fixed login/signup separation; improved auth branding; and contributed to profile, onboarding, DOB/name, and location-sharing consistency. Maps, admin, and stabilization: contributed to shared map/location infrastructure, viewport-based discovery, Android current-location map behavior, Gathering Areas/Help Request Map reliability, News & Announcements parity, admin users/moderation flows, and backend/Android/Playwright regression tests.	#398, #399, #401, #518, #535, #556, #562, #605, #607, #620
Rojhat Delibaş	Notifications and safety circles: implemented the notification infrastructure with in-app and FCM support and delivered trusted safety-circle functionality for emergency awareness flows. Help-request reliability: hardened secure guest request behavior and changed request creation to happen on form submission instead of too early in the flow. Offline and final fixes: added nearby-visible-user caching for offline/residential-area awareness and closed final Android regressions around safety-circle timestamps, Request Help edit labels, and edit-location prefill.	#344, #355, #427, #456, #592, #593, #616, #618
Mehmet Can Gürbüz	Backend, DevOps, and admin flows: contributed core backend and operational work, including the aggregate emergency overview/admin endpoints and help request Map, created DB server and DB migration workflow, implemented CI/CD workflows and provide AWS EC2 deployment/runtime stability. Map, filtering, and UI support: implemented or supported Help Request Map filters, Gathering Areas category/filter improvements, notification-page clarity, onboarding/branding UI work, and mobile/web consistency fixes. Release synchronization: helped keep the final release path aligned by synchronizing the main branch with development and supporting migration/workflow stability.	#329, #490, #493, #503, #523, #533, #536, #626,#259
Alper Kartkaya	Emergency-critical Android reliability: implemented the Android offline-first architecture with Room persistence, sync-operation queueing, WorkManager synchronization, retry/conflict handling, and UI feedback for pending/failed emergency operations. Cross-platform feature work: delivered Android E2E/fake-backend testing infrastructure, backend-backed announcements with admin CRUD, safety status and emergency-mode flows, dark theme support, and contextual mobile self-onboarding. Final readiness: handled final demo admin seeding, release notes/setup documentation, branch synchronization support, and late regression fixes for mobile navigation, Request Help editing, and display consistency.	#265, #300, #313, #359, #413, #467, #572, #625
Berat Sayın	Privacy, security, and account lifecycle: improved privacy/security behavior across Android and web, including the Privacy & Security page, privacy-setting persistence, account deletion, and fresh re-signup handling. Request and helper-detail quality: made selected help-request fields optional, improved helper/detail display behavior, and fixed mobile crashes or save-flow problems around privacy/account screens. Time and notification polish: improved Today/Yesterday timestamp presentation and notification timezone handling for clearer user-facing history.	#356, #357, #444, #463, #501, #504, #563, #565, #585, #586
Gülce Tahtasız	Availability and location semantics: improved availability and operational-location behavior, including route-distance support, operational-location refresh, request-help location snapshots, and stale-location handling for availability. Profile, privacy, and consent: fixed Android profile residential-location handling, updated request-help health-sharing consent, and refactored privacy settings around location/health visibility behavior. Demo and usability support: added demo data seeding, directions actions, and related final-demo support so map/location flows were easier to demonstrate and verify.	#408, #424, #442, #445, #453, #459, #519, #525, #570, #573

4.2 Status of Requirements

Completed

Requirement	Status	Notes
1.1.1.1	Completed	Users can specify profession.
1.1.1.2	Completed	Users can specify expertise areas.
1.1.1.5	Completed	Expertise/profession fields can be updated after registration.
1.1.2.1	Completed	Email/password sign-up exists.
1.1.2.2	Completed	Email verification flow exists.
1.1.2.5	Completed	Terms acceptance is required.
1.1.3.1	Completed	Height/weight are supported in profile/physical info.
1.1.3.2	Completed	Date of birth is supported.
1.1.3.3	Completed	Gender is supported as optional profile data.
1.1.3.4	Completed	Physical information can be updated.
1.1.4.1	Completed	Medical history/conditions are supported.
1.1.4.2	Completed	Chronic diseases are supported.
1.1.4.3	Completed	Allergies are supported.
1.1.4.4	Completed	Medications are supported.
1.1.4.5	Completed	Blood type is supported.
1.1.4.6	Completed	Health information can be updated.
1.1.5.1	Completed	Country/city and administrative location fields are supported.
1.1.5.2	Completed	Optional current location sharing is supported.
1.1.5.3	Completed	Location information can be updated.
1.1.6.1	Completed	Privacy settings control visible profile/location/health data.
1.1.6.4	Completed	Account deletion / soft deletion flow exists.
1.1.6.5	Completed	Location visibility controls exist.
1.1.6.6	Completed	Health information visibility controls exist.
1.1.7.2	Completed	Notification system supports assignments, announcements, and emergency-related updates.
1.2.1.1	Completed	Volunteers can activate Available to Help status.
1.2.1.2	Completed	Volunteers can deactivate availability.
1.2.2.1	Completed	Availability changes are stored locally while offline.
1.2.2.2	Completed	Availability changes sync after reconnect.
1.2.2.3	Completed	Help requests can be created offline.
1.2.2.4	Completed	Help request need type is supported.
1.2.2.5	Completed	Help request description is supported.
1.2.2.6	Completed	Low-context/default handling exists for missing request details.
1.2.2.7	Completed	Help requests are stored locally until connectivity returns.
1.2.2.8	Completed	Pending help requests synchronize automatically.
1.2.2.9	Completed	Matching can occur after synced requests reach the backend.
1.2.2.10	Completed	Mobile UI displays local/sync status.
1.2.2.11	Completed	Offline sync worker handles automatic synchronization.
1.2.2.12	Completed	Manual refresh/sync-like actions exist in relevant screens.
1.2.3.1	Completed	Active help requests are evaluated for assignment.
1.2.3.2	Completed	Assignment considers availability, distance, urgency, and expertise signals.
1.2.3.4	Completed	Request status lifecycle is displayed.
1.2.3.5	Completed	Assigned helper can cancel assignment.
1.2.3.6	Completed	Requester/helper flows support resolving requests.
1.2.4.1	Completed	Help request details and urgency are visible.
1.2.4.2	Completed	Help requests have map/location views.
1.2.4.4	Completed	Assigned helper information is visible to requester.
1.2.4.5	Completed	Users can view and track their own help requests.
1.2.5.1	Completed	Matched users can access contact information.
1.2.5.2	Completed	Contact access is limited through assignment/request ownership flows.
1.3.1.1	Completed	Web landing/home page exists.
1.3.1.2	Completed	Emergency numbers page exists.
1.3.1.3	Completed	Gathering areas map exists.
1.3.1.4	Completed	News and announcements are available.
1.3.2.1	Completed	Web login and profile update flows exist.
1.3.2.2	Completed	Operational emergency actions are mainly mobile-focused.
1.3.3.1	Completed	Admins can view registered users.
1.3.3.2	Completed	Admins can view help requests/statuses.
1.3.3.3	Completed	Admins can ban/suspend users.
1.3.3.6	Completed	Admins can create/update/delete announcements.
1.3.3.7	Completed	Admin stats and emergency overview endpoints exist.
1.4.1.1	Completed	In-app notifications and notification list exist.
1.4.1.2	Completed	Request and assignment statuses are displayed.
2.1.1	Completed	Background sync is handled without blocking main UI flows.
2.2.1	Completed	Mobile app supports cached/offline critical flows.
2.2.2	Completed	Sync retry/backoff behavior exists through WorkManager policies.
2.2.3	Completed	Room persistence restores local state after restart.
2.2.4	Completed	Critical offline writes are persisted before sync.
2.3.1	Completed	Offline local storage and later sync are implemented.
2.3.2	Completed	Deterministic conflict/recovery policies exist.
2.3.3	Completed	Local/server consistency is restored after synchronization.
2.4.1	Completed	Production deployment uses HTTPS endpoints.
2.4.2	Completed	Admin capabilities are protected by role-based middleware.
2.4.3	Completed	Privacy controls and optional location sharing reduce unnecessary exposure.
2.5.1	Completed	Offline/sync states are shown in mobile flows.
2.6.1	Completed	Emergency events use consistent timestamps in backend/offline records.
2.7.1	Completed	Core mobile flows are implemented with native Android/Compose and local persistence.
2.7.2	Completed	Offline-first flows support poor connectivity conditions.

In Progress / Partially Completed

Requirement	Status	Notes
1.1.1.3	In Progress	Users can declare skills/expertise and volunteer categories, but a full “resources/supplies offered” workflow is limited.
1.1.1.4	In Progress	Expertise has verification fields, but a complete verification workflow is not fully visible.
1.1.1.6	In Progress	Verified/unverified expertise is represented in data, but end-to-end UX appears partial.
1.1.2.3	In Progress	Full name is supported in profile completion, not necessarily in the initial sign-up step.
1.1.2.4	In Progress	Phone number is supported in profile completion, not necessarily in the initial sign-up step.
1.1.6.2	In Progress	Sensitive data is stored with access controls, but full secure-storage guarantees are not fully documented.
1.1.6.3	In Progress	Passwords are hashed and HTTPS is used, but field-level encryption for personal/health data is not clearly implemented.
1.2.3.3	In Progress	Matching considers expertise/availability, but strict matching against every skill/resource category is partial.
1.2.4.3	In Progress	Users can become available and be assigned, but a separate “offer to help” submission flow is not fully implemented.
1.3.3.5	In Progress	Help requests can be resolved through request/assignment flows, but a dedicated admin resolve action is not clearly exposed.
2.4.4	In Progress	Mobile uses local persistence/session storage, but platform-backed encryption for all sensitive local data is not fully clear.

Not Started / Not Evident

Requirement	Status	Notes
1.1.7.1	Not Started	A full user-facing report/flag mechanism is not evident in current routes/UI.
1.3.3.4	Not Started	Dedicated admin assignment override functionality is not evident.

4.3 API Endpoints

4.3.1 API Documentation

API Documentation

4.3.2 Sample Usage Scenarios

Scenario 1: User Checks In to a Safety Circle

Endpoint: PATCH /api/safety-circles/{circleId}/check-in

Scenario Description: A user marks themselves as safe, shares their location, and the circle detail is returned with updated member safety information.

Request

curl -X PATCH "https://api.neph.app/api/safety-circles/demo_scenario2_circle_alper_family/check-in" \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "safe",
    "shareLocationConsent": true,
    "note": "I am safe near the gathering area.",
    "location": {
      "latitude": 41.0842,
      "longitude": 29.0211,
      "accuracyMeters": 18,
      "source": "gps",
      "capturedAt": "2026-05-15T10:05:00.000Z"
    }
  }'

Response

{
  "safetyStatus": {
    "userId": "demo_scenario2_alper",
    "status": "safe",
    "shareLocationConsent": true,
    "note": "I am safe near the gathering area.",
    "latitude": 41.0842,
    "longitude": 29.0211,
    "updatedAt": "2026-05-15T10:05:02.000Z"
  },
  "circle": {
    "circleId": "demo_scenario2_circle_alper_family",
    "name": "Alper Family",
    "ownerUserId": "demo_scenario2_alper"
  },
  "members": [
    {
      "userId": "demo_scenario2_alper",
      "role": "owner",
      "status": "safe"
    },
    {
      "userId": "demo_scenario2_sibling",
      "role": "member",
      "status": "not_safe"
    }
  ]
}

Scenario 2: Nearby Visible Users for Emergency Awareness

Endpoint: GET /api/safety-status/visible?nearby=true

Scenario Description: A user views nearby people whose privacy settings and safety status make them visible in the same residential area.

Request

curl "https://api.neph.app/api/safety-status/visible?nearby=true" \
  -H "Authorization: Bearer <ACCESS_TOKEN>"

Response

{
  "safetyStatuses": [
    {
      "userId": "demo_scenario2_rojhat",
      "firstName": "Rojhat",
      "lastName": "Demo",
      "status": "safe",
      "note": "I am safe and nearby.",
      "profileVisibility": "PUBLIC",
      "locationVisibility": "PUBLIC",
      "city": "Istanbul",
      "district": "Besiktas",
      "neighborhood": "Levazim",
      "updatedAt": "2026-05-15T10:06:00.000Z"
    }
  ]
}

Scenario 3: Admin Publishes an Emergency Announcement

Endpoint: POST /api/admin/announcements

Scenario Description: An admin creates a public announcement that can be shown on the web and mobile clients.

Request

curl -X POST "https://api.neph.app/api/admin/announcements" \
  -H "Authorization: Bearer <ADMIN_ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Water distribution point updated",
    "content": "The temporary water distribution point has moved to Akatlar Culture Center."
  }'

Response

{
  "announcement": {
    "announcementId": "ann_2c8f1b",
    "title": "Water distribution point updated",
    "content": "The temporary water distribution point has moved to Akatlar Culture Center.",
    "createdByUserId": "admin_001",
    "createdAt": "2026-05-15T10:10:00.000Z",
    "updatedAt": "2026-05-15T10:10:00.000Z"
  }
}

Scenario 4: Admin Sends a Location-Based Emergency Broadcast

Endpoint: POST /api/notifications/admin/broadcast/emergency

Scenario Description: An admin sends an emergency broadcast notification to users within a radius of an incident location.

Request

curl -X POST "https://api.neph.app/api/notifications/admin/broadcast/emergency" \
  -H "Authorization: Bearer <ADMIN_ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Aftershock warning",
    "body": "Please move away from damaged buildings and follow official instructions.",
    "location": {
      "latitude": 41.0842,
      "longitude": 29.0211,
      "radiusKm": 3
    },
    "maxRecipients": 5000
  }'

Response

{
  "broadcastId": "broadcast_8df1e0d1-9db2-40d7-b66d-4a6f9c7f6b1",
  "recipientCount": 12,
  "deliveredCount": 12
}

4.4 User Interface / User Experience

4.4.1 UI Code References

The repository code links for the implemented web and Android user interface designs are provided in the following wiki page:

Final UI UX Code References

4.4.2 Screenshots of New or Significantly Modified Interfaces

Screenshots of the new or significantly modified interfaces developed in the final milestone are provided below.

Web Application Screenshots

Admin emergency overview

Admin emergency history

Admin emergency analytics / insights

Admin deployment monitoring

Admin announcements management

Gathering areas map

News / announcements page

Privacy and security page

Android Mobile Application Screenshots

Home screen with safety and emergency actions

Request help flow

My help requests / request tracking

Assigned request screen
Assigned request screen

Safety circles screen

Nearby visible users screen

Help request map

Notifications screen

Emergency numbers screen

Privacy and security screen

4.5. Utilized Standards

4.5.1 Summary

The project applies the following W3C and web-related standards in the final release:

Standard	Where It Is Applied	Evidence
WCAG 2.1	Web and Android UI accessibility decisions such as readable labels, clear validation messages, contrast, predictable navigation, and structured forms	Final UI UX Code References
HTML Living Standard / Semantic HTML	Web application pages, form structure, layout structure, and navigational elements	Web app source
WAI-ARIA / Accessible Interaction Patterns	Buttons, inputs, form controls, navigation components, and interactive UI elements	Web UI components
CSS Responsive Design	Web pages and shared layout components for different viewport sizes	Web layout components

4.5.2 Deep Dive

Standard 1: WCAG 2.1

Standard followed: WCAG 2.1

Relevant development artifacts:

Relevant implementation parts:

WCAG-related design decisions are reflected in shared components such as buttons, inputs, selection controls, section headers, helper texts, status badges, empty states, page containers, and screen layouts.

Reasoning:

NEPH is an emergency preparedness and response application, so users may interact with the system under stress, poor connectivity, or limited attention. The interface therefore prioritizes perceivable and understandable content through readable labels, clear section headings, direct validation messages, consistent button placement, high-contrast text/background combinations, and grouped forms. These choices support WCAG 2.1 principles such as perceivability, operability, understandability, and robust interaction.

Standard 2: HTML Living Standard / Semantic HTML

Standard followed: HTML Living Standard / Semantic HTML

Relevant development artifacts:

Relevant implementation parts:

The web application is organized into page-level routes, reusable layout components, navigation components, page containers, section headers, forms, content cards, and feature-specific views.

Reasoning:

Semantic page structure makes the web application easier to navigate, maintain, and understand. It also helps separate different user intents such as authentication, emergency information, profile management, privacy settings, maps, announcements, and admin monitoring. This structure supports accessibility and improves the clarity of the user experience.

Standard 3: WAI-ARIA / Accessible Interaction Patterns

Standard followed: WAI-ARIA and accessible interaction patterns

Relevant development artifacts:

Relevant implementation parts:

The implementation uses reusable controls for buttons, password fields, text inputs, text areas, select inputs, checkboxes, radio groups, toggles, verification code inputs, navigation bars, and route-aware layouts.

Reasoning:

Accessible interaction patterns make the interface predictable across the product. Users encounter the same interaction model in authentication, profile editing, privacy settings, admin dashboards, notifications, and emergency-related screens. This consistency reduces cognitive load and helps users complete actions quickly, which is especially important in emergency workflows.

Standard 4: CSS Responsive Design

Standard followed: CSS responsive design practices based on W3C CSS standards

Relevant development artifacts:

Relevant implementation parts:

Responsive behavior is handled through reusable page containers, navigation components, layout shells, feature-specific page layouts, map views, forms, cards, and admin dashboard views.

Reasoning:

The web application must remain usable across different screen sizes and device conditions. Responsive layout decisions help users access emergency information, maps, announcements, profile settings, and admin views without relying on a single desktop-only layout. This supports the project’s usability, accessibility, and portability goals.

4.6. Testing & Quality Assurance

4.6.1 Test Execution Reports

The project uses GitHub Actions workflows to validate the backend API, web application, Android application, and end-to-end user flows. The commands used by CI are documented in the workflow files.

Layer	CI / Report Evidence	Commands / Scope
Backend API	Backend CI	`npm run test:unit`, `npm run test:integration`
Web Application	Web CI	`npm run build`
End-to-End Tests	E2E CI	`npm run test:e2e`, Playwright report artifacts
Mobile Unit Tests	Android CI	`./gradlew :app:testE2eUnitTest`
Mobile APK Build Check	Android CI	`./gradlew :app:assembleE2e`, `./gradlew :app:assembleE2eAndroidTest`

Backend and Android tests were also executed locally during final report preparation.

Layer	Local Result Summary
Backend API Unit Tests	27 test suites passed, 367 tests passed, 0 failed
Android Unit Tests	27 test suites passed, 176 tests passed, 0 failed

4.6.2 New Test Evidence

Backend API Tests

Relevant backend tests include unit and integration coverage for authentication, profiles, help requests, availability, assignments, notifications, announcements, safety status, safety circles, gathering areas, operational location, location, and admin emergency monitoring.

Web Application Tests

Relevant web tests cover final user flows such as admin dashboard views, admin users, admin history, admin insights, deployment monitoring, gathering areas, help request map, profile/privacy, navigation, onboarding, news fallback, theme toggle, and password reset.

Web E2E tests

Mobile Application Tests

Relevant Android tests cover offline sync, request help, profile/location payloads, safety status, safety circles, nearby users, gathering areas, help request map filtering, assigned request mapping, onboarding, and authenticated E2E behavior.

4.6.3 Impact Analysis

Coverage

The test suite covers critical final functionality including safety status updates, safety circles, nearby visible users, announcements, notifications, admin emergency monitoring, gathering areas, offline synchronization, and mobile request-help flows.

Bug Detection

The tests helped protect the project against regressions and edge cases around invalid request payloads, status transitions, location data, offline synchronization conflicts, Android repository-to-API payload mapping, admin dashboard data loading, map behavior, and privacy/visibility logic.

Readiness

The CI workflows and local test reports provide evidence that the final release was validated across backend, web, mobile, and end-to-end layers. Together, they support the stability of the final demo scenarios and the core emergency preparedness flows expected from NEPH.

4.7. Demo Reflections & Notes

The final demo consisted of three connected scenarios that demonstrated the main emergency preparedness and response flows of NEPH across the Android application, backend, and web/admin interfaces. The scenarios were designed to show the system as a realistic emergency coordination platform rather than a collection of isolated features.

Demo Notes

The audience responded positively to all three scenarios. The instructors and teaching assistants appreciated that the scenarios were coherent, easy to follow, and directly connected to the core purpose of the project. The demo flow helped show how help requests, volunteer availability, assigned request tracking, safety statuses, safety circles, nearby visible users, gathering areas, announcements, notifications, and admin monitoring work together in a realistic emergency context.

During the presentation, some parts of the demo drew visible surprise and interest, especially where multiple features interacted with each other. The safety circle and nearby user flows were particularly useful for showing that privacy settings, location visibility, and safety status data were not just separate profile fields, but actively affected what users could see in the application. The gathering areas and admin-side flows also helped communicate the broader emergency coordination role of the platform.

The prepared demo data played an important role in making the scenarios clear. Since the scenarios depended on specific users, locations, safety statuses, safety circles, and visibility settings, having deterministic mock data made the presentation smoother and reduced uncertainty during the live demonstration.

Reflections

The final demo showed that NEPH is strongest when its features are presented as connected emergency workflows. Instead of demonstrating screens one by one, the scenarios made it possible to explain why each feature exists and how it supports emergency preparedness, response, and coordination.

The feedback from the audience was generally positive. The three scenarios were well received, and the team was appreciated for presenting a more polished and coherent product compared to the earlier milestones. The demo also showed that the improvements made after the MVP milestone had a clear impact on the final presentation quality, especially in terms of scenario design, UI clarity, and cross-platform consistency.

Overall, the demo confirmed that the final release covers the main flows expected from the project. It also highlighted the importance of realistic scenario planning, reliable demo data, and privacy-aware emergency features. The team left the demo with a clearer understanding that strong feature implementation alone is not enough; the features also need to be presented through realistic stories that make their value easy to understand.

5. Individual Contributions

Kagan Can (Frontend, Mobile, Backend, DevOps)

Responsibilities

During this milestone, I worked across frontend, mobile, backend, and DevOps. In addition to implementation work, I acted as a cross-functional coordinator for the team by organizing issue planning, prioritizing demo-critical fixes, preparing AI-assisted development prompts, coordinating PR/release flow, supporting deployment decisions, and helping the team keep the project aligned before the final demo.
Main Contributions
- Coordinated final milestone planning, issue grooming, release preparation, demo preparation, and PR quality review.
- Prepared and managed issue definitions for major final-stage improvements, especially around maps, location, operational location, Android CI, emergency usability, demo data, and release documentation.
- Implemented and fixed major Android/mobile flows, especially around location, maps, Request Help, Gathering Areas, safety status, availability, and Android release readiness.
- Implemented backend and integration changes for operational location, volunteer availability, stale-location guards, advanced matching, request metadata, and demo data.
- Supported frontend/web integration and cleanup tasks, especially around location selection, map behavior, API alignment, and release documentation.
- Helped resolve deployment, release, branch synchronization, dependency/security, migration workflow, API base URL, and Android release Google Sign-In configuration issues.
Significant Issues (Strict Limit)

Code-related issues:
1. #428 - Separate Residential and Operational Location Flows: Planned and implemented the separation between residential/profile location and operational/emergency location. Related implementation includes PR #439, PR #443, PR #446, and PR #447.
2. #531 - Implement Viewport-Based Marker Discovery for Resource Maps: Implemented Android/backend viewport-based discovery for resource maps through PR #532, followed by stabilization work in PR #553, PR #599, and PR #623.
3. #494 - Mobile maps do not load across Android map surfaces: Fixed shared Android map loading and Gathering Areas map behavior through PR #495 and PR #526.
Non-code-related / coordination issues:
1. #602 - Prepare final release submission docs and env examples: Prepared final evaluator-facing setup, release, environment, and demo documentation through PR #603.
2. #304 - Copilot Document: Created AI/development guidance documentation for consistent AI-assisted implementation through PR #305.
3. #627 - Meeting #12: Organized final-stage coordination around presentation scenarios, role review, rehearsal helper text, and data strategy before the final demo.
Code-Related Issues

My code-related work mainly focused on Android/mobile stabilization, map/location infrastructure, backend emergency coordination logic, advanced matching, volunteer availability, Request Help behavior, and release-critical bug fixes. The most representative code issues are listed above under the strict-limit significant issues section, and the full implementation evidence is listed through my PRs below.
Non-Code-Related Issues

My non-code work mainly involved project coordination, issue planning, release management, documentation, AI-assisted development organization, meeting/demo preparation, and PR quality review. The most representative non-code issues are listed above under the strict-limit significant issues section.
Pull Requests

Created / authored PRs since 7 April 2026 (this milestone only):
Reviewed PRs since 7 April 2026 (this milestone only):
Conflict Resolution
- Helped resolve task ownership and PR overlap issues by coordinating responsibilities and prioritizing demo-critical work.
- Helped resolve web/backend API contract mismatches by aligning frontend/mobile payload expectations with backend endpoint behavior.
- Helped resolve Android release-build confusion around Google Sign-In by identifying release configuration problems and updating the Android release workflow/configuration through PR #566.
- Helped resolve local/server/production environment mismatches around API base URLs, backend connection behavior, Nginx/PM2 deployment, production migrations, branch synchronization, and final release workflow.
AI Transparency & Documentation
- I used *Codex, **OpenCode, and *GitHub Copilot for implementation support, debugging, PR drafting, and code-level iteration.
- I used ChatGPT for project planning, issue preparation, feature ideation, debugging strategy, review text preparation, documentation drafting, release/demo planning, and report preparation.
- AI tools were used as assistants; final decisions, integration checks, PR submissions, and coordination responsibility remained mine.
- The following links are representative ChatGPT conversation logs showing different types of AI usage. I had additional similar AI-assisted chats during the project, but only representative examples are included here:
Individual Testing Efforts

My testing efforts during this milestone focused on the features and fixes I implemented or directly supported. I added and updated focused automated tests for Android, backend, unit and integration, migration, mapping, location, availability, safety status, request history, operational location, and resource-map behavior.

In addition to automated tests, I also performed local manual verification for several demo-critical flows. I used Android Studio to run and inspect the mobile application, used Docker Compose to run the local backend/database environment, and manually checked affected web and Android flows after implementation or debugging. These checks included location selection, current-location behavior, Request Help, Gathering Areas, Help Request Map, availability, safety status, profile/location flows, and release-critical Android behavior.

The following source-code links are the relevant testing evidence for the tests I added or updated in my authored PRs during this milestone. Some of these are shared test suites, so they may contain both previously existing coverage and the additional cases I added during this milestone.

Android test source files:
Backend test source files:
Additional Information

Beyond implementation, I took a leading coordination role during this milestone. I prepared and organized many issues, helped direct AI-assisted development, supported teammates with review/implementation prompts, managed release and branch synchronization work, prepared final release documentation, supported demo scenario planning, and helped keep the project focused on the most important final-demo risks.

Ethem Erinç Cengiz (Frontend, Mobile, Backend)

Responsibilities

During this milestone, I worked as a cross-platform contributor across web, Android, backend integration, and testing / QA. I implemented complete product flows end-to-end, including frontend and mobile interfaces, backend/API behavior, authentication and authorization, Google OAuth / Google Sign-In, profile and location data flows, map/location infrastructure, Gathering Areas, Help Request Map, admin coordination features, user moderation, notifications, announcements/news, and final-stage stabilization.

My main responsibilities included building and polishing the web and Android user experience, connecting those screens to backend APIs, implementing or adjusting backend behavior where needed, aligning request/response contracts, updating automated tests, and manually verifying cross-platform flows. I worked especially on the web and Android auth flows, Google OAuth authorization/configuration, profile/location handling, current-location behavior, shared map integration, API-backed Gathering Areas, admin dashboard/moderation mechanisms, Android map reliability, and final demo-critical bug fixes.
Main Contributions
- Implemented cross-platform auth and identity flows across backend, web, and Android, including email/password auth, guest access, protected routing, Google OAuth / Google Sign-In, provider cleanup, consent and redirect behavior, Android/Web configuration, and final auth-related regression fixes.
- Built and stabilized profile, onboarding, privacy, and location data flows across web, Android, and backend, including first/last name alignment, DOB handling, health/profile fields, privacy/location sharing, coordinate metadata, current-location persistence, location search, map/dropdown synchronization, and stale form state fixes.
- Implemented shared map/location infrastructure and resource-map behavior across web, including reusable Leaflet map integration, map picker behavior, current-location controls, viewport-based marker discovery, stale marker protection, provider/fallback handling, Gathering Areas, Help Request Map, filtering, live current-location markers, and Android map loading/current-location reliability.
- Implemented admin coordination and moderation features across backend and web, including emergency overview/history/analytics, operational emergency fields, deployment monitoring, Users tab, filtering/pagination, user ban/unban actions, ban reason/timestamp persistence, banned-user auth enforcement, requester/volunteer side effects, and related test coverage.
- Redesigned the entire Android mobile application UI from the ground up, rebuilding the mobile experience with a consistent Compose-based design system, shared theme tokens, reusable components, improved navigation structure, and refreshed screens across authentication, home, profile, notifications, request/help flows, maps, and core user journeys.
- Implemented announcements/news and notification improvements across platforms, including backend-driven Android announcements, web fallback cleanup, announcement detail navigation, English timestamp formatting, Android notification unread badge behavior, timestamp formatting, load-more state, and logout cleanup.
- Added and maintained automated test coverage across web E2E, backend integration/unit, and Android unit tests for auth, Google OAuth, admin dashboard/moderation, maps, profile/location sync, Gathering Areas, Help Request Map, notifications, and announcements/news parity.
- Supported final-stage stabilization and demo readiness by handling review feedback, CI failures, flaky E2E assertions, map/auth/profile regressions, mock/demo data needs, acceptance-test planning, and manual smoke checks across web and Android.
Significant Issues (Strict Limit)

Code-related issues:
1. #286 - Build shared map and location infrastructure: This was one of my broadest cross-platform implementation areas. I worked on the shared map/location foundation and multiple dependent features across web, Android, and backend-connected flows, including manual location selection, current-location sharing, profile location persistence, Gathering Areas, shared Leaflet map integration, viewport-based discovery, and Android current-location map behavior. Related PRs include #312, #315, #316, #323, #330, #331, #346, #390, #392, #562, and #620.
2. #507 - Keep only Google social login on Web and Mobile, remove Apple/Facebook providers, and make Google sign-in fully functional: I implemented and stabilized Google social authentication across backend, web, and Android. This included removing unsupported Apple/Facebook social login UI, keeping Google as the only social provider, adding backend Google token verification and Google user mapping, adding/configuring Google OAuth fields, separating login/signup modes, handling consent and redirect behavior, exposing environment/config values, and improving Android/Web Google Sign-In robustness. Related PRs include #535 - feat(auth): implement Google Sign-In across Web and Android, #556 - fix(auth): improve Google sign-in flow across Android and web, and #560 - fix(android): allow non-com emails in auth validation.
3. #508 - Android UI Improvements - New App Shell, Shared Components, and Screen Polishing: I contributed to the full Android UI/UX improvement effort. This included refreshing theme tokens, adding shared display components, flattening reusable UI components, restructuring the app shell/navigation, polishing auth screens, improving home/profile/notifications screens, wiring notification badges, applying a flat UI pass across feature screens, and adding Settings dark mode toggle support. Related implementation was delivered through #518 - feat/Android UI overhaul: app shell/navigation redesign, shared UI system, and cross-screen consistency pass.
Non-code-related / coordination issues:
1. #376 - Prepare acceptance test for helper availability and matching flow: I prepared acceptance-test planning for the helper availability and matching flow, including prerequisites, step-by-step verification, expected results, and a structure for recording test outcomes. This helped clarify how the availability/matching behavior should be validated from a user-flow perspective.
2. #369 - Define Data Strategy: I supported data strategy and demo/test data planning by helping align realistic test/demo data needs with the system flows used in development and the final presentation. This included thinking about realistic users, emergency/request data, map/location behavior, and scenario-aligned data preparation.
3. #258 - Writing the Meeting Report 8: I prepared the report for Meeting 8, linked to the related meeting issue #257, and contributed to keeping team coordination and meeting documentation up to date.
Code-Related Issues

My code-related work was full-stack and cross-platform. I worked on frontend/web, Android/mobile, backend service/API behavior, database-related fields/migrations where needed, and automated tests. The main areas were auth and Google OAuth, profile/location data flows, map/location infrastructure, Gathering Areas, Help Request Map, admin dashboard, user ban/unban moderation, Android UI improvements, notifications, announcements/news parity, and final-stage stabilization.

For many features, I worked on both the user-facing screen and the connected backend/API behavior. In auth and Google Sign-In, I worked on backend OAuth support, web behavior, Android behavior, authorization/configuration issues, consent handling, and tests. In maps/location, I worked on UI, current-location handling, API data, provider fallback behavior, marker discovery, shared map integration, and E2E/unit coverage. In admin moderation and dashboard features, I worked on the admin UI, backend endpoints, authorization checks, operational side effects, analytics queries, and tests.
Non-Code-Related Issues

My non-code work mainly involved regression triage, review follow-up, final demo preparation, acceptance-test planning, mock/demo support, meeting/report documentation, PR readiness checks, and cross-platform consistency review. I helped identify and resolve cases where frontend, Android, backend, and tests had diverging behavior or expectations, especially in auth, Google OAuth, profile/location, maps, admin flows, announcements, and final demo scenarios.
Pull Requests

Created / authored PRs since 7 April 2026:
Reviewed PRs since 7 April 2026:
Conflict Resolution
- Helped resolve web / Android / backend inconsistencies in auth, profile/location state, Google OAuth, admin behavior, maps, announcements/news, and tests.
- Helped resolve Google OAuth issues involving backend fields, web login/signup mode separation, Android release/debug client configuration, consent behavior, redirect behavior, and environment variables.
- Helped resolve map-loading and map-refresh problems across web and Android by debugging shared Leaflet behavior, viewport discovery, current-location state, stale markers, and provider fallback behavior.
- Helped resolve Gathering Areas provider and fallback issues by aligning backend/provider behavior with user-facing web and Android states.
- Helped resolve profile/location mismatches by aligning UI fields, backend payloads, DOB behavior, health/profile fields, coordinate metadata, and location persistence.
- Helped resolve admin moderation and analytics inconsistencies by tightening backend side effects, authorization checks, UI states, and E2E/backend tests.
- Helped resolve CI and automated test failures by updating tests after API/UI behavior changed and stabilizing flaky E2E assertions.
AI Transparency & Documentation

I used GitHub Copilot actively throughout implementation, debugging, testing, and PR preparation. Copilot was used as a development assistant for architecture checks, regression investigation, and test updates.

A public shareable Copilot chat URL could not be generated from the current environment, so the prompt history is documented below.

Copilot prompt history

Asked to connect Android News and Announcements screens to backend announcements.
Asked to fix parity issues between Android and web News behavior.
Asked to prevent silent fallback behavior on web News pages.
Asked to update E2E fallback tests to match explicit error behavior.
Asked to replace Android auth heart icons with the NEPH app logo.
Asked for investigation of Request Help edit, navigation, and local-first synchronization behavior.
Asked to implement initial current-location startup behavior on Android Help Request Map.
Asked to implement initial current-location startup behavior on Android Gathering Areas Map.
Asked to add a live current-location marker on both Android maps.
Asked to keep map fetch behavior correct after location changes.
Asked to verify zoom and pan still trigger viewport-based data refresh.
Asked to ensure no broad fetch is triggered outside discovery constraints.
Asked to ensure visible-area fetch behavior remains correct.
Asked to diagnose why viewport changes sometimes did not refresh map results.
Asked whether current branch changes caused the map regression.
Asked to redesign live location marker style to differ from Gathering Area markers.
Asked to revert marker style back to the original green live marker.
Asked to commit Android map changes and prepare a PR title and description.
Asked to explain exactly what changed for the viewport refresh issue.
Asked to create an empty commit to retrigger GitHub CI.
Asked to fix CI failures in Android E2E unit tests.
Asked to update map tests after shared map API signature changes.
Asked to update viewport key test expectations after precision-format change.
Asked to address review feedback about initial global fetch racing with current-location startup.
Asked to make first-run permission and fallback behavior explicit rather than silent.
Asked to add initial fallback messages for denied permission and unavailable location.
Asked to commit review-fix changes for map behavior.
Asked to generate demo SQL mock data for a safe user and an admin user scenario.
Asked to generate a bcrypt password hash for demo credentials.
Asked to align mock data with existing database tables and contracts.
Asked for inventory of all Android app screens and reusable UI components.
Asked for a repository-wide social authentication inventory across web, Android, and backend.
Asked for a repository-wide map codebase analysis across web, Android, and backend.

Individual Testing Efforts

My testing effort focused on the full-stack flows I implemented or stabilized: auth, Google OAuth, profile/location sync, Gathering Areas, Help Request Map, admin dashboard/moderation, notifications, announcements/news parity, and map/current-location behavior.

I added and updated automated tests across web E2E, backend integration/unit, and Android unit tests. I also manually verified affected flows on web and Android, including login/signup, Google Sign-In, profile editing, current-location sharing, map picker behavior, Gathering Areas, Help Request Map, admin dashboard, user ban/unban, notifications, announcements, and final demo scenarios.

Test-related PRs include:

#620 — Android current-location map behavior tests, especially Leaflet map viewport/current-location behavior.
#605 — News & Announcements parity fallback E2E coverage.
#562 — Web viewport marker discovery and map E2E tests.
#560 — Android auth validation test coverage for non-.com emails.
#556 — Google social login flow regression tests.
#535 — Google Sign-In backend/auth test coverage.
#530 — Onboarding E2E updates for profile field changes.
#518 — Android UI overhaul with Android E2E coverage.
#401 — Profile name/DOB backend unit, integration, and onboarding E2E tests.
#400 — Android profile location payload tests.
#399 — Admin ban/unban moderation backend and web E2E tests.
#398 — Admin users listing/filtering tests.
#392 — Profile location sync backend and web E2E coverage.
#390 — Gathering Areas provider resilience and E2E coverage.
#350 — Admin deployment monitoring backend and E2E tests.
#348 — Admin emergency insights backend and E2E tests.
#347 — Admin operational emergency history/overview tests.
#331 — Device location sharing E2E coverage.
#330 — Gathering Areas page E2E coverage.
#321 — Onboarding location E2E stabilization.

Android test source files:
- android/app/src/test/java/com/neph/features/auth/util/AuthValidationTest.kt
- android/app/src/test/java/com/neph/features/profile/data/ProfileRepositoryLocationPayloadTest.kt
- android/app/src/test/java/com/neph/ui/map/LeafletMapWebViewTest.kt
Backend test source files:
- backend/tests/integration/modules/admin/admin-deployment-monitoring.integration.test.js
- backend/tests/integration/modules/admin/admin-emergency-analytics.integration.test.js
- backend/tests/integration/modules/admin/admin-emergency-history.integration.test.js
- backend/tests/integration/modules/admin/admin-emergency-overview.integration.test.js
- backend/tests/integration/modules/admin/admin-users.integration.test.js
- backend/tests/integration/modules/auth/auth.integration.test.js
- backend/tests/integration/modules/gathering-areas/gathering-areas.integration.test.js
- backend/tests/integration/modules/gathering-areas/gathering-areas.provider-failures.integration.test.js
- backend/tests/integration/modules/help-requests/help-requests.integration.test.js
- backend/tests/integration/modules/location/location.integration.test.js
- backend/tests/integration/modules/profiles/profiles.integration.test.js
- backend/tests/unit/modules/admin/service.test.js
- backend/tests/unit/modules/announcements/routes.test.js
- backend/tests/unit/modules/auth/controller.test.js
- backend/tests/unit/modules/auth/middleware.test.js
- backend/tests/unit/modules/auth/routes.rate-limit.test.js
- backend/tests/unit/modules/auth/service.test.js
- backend/tests/unit/modules/profiles/service.test.js
- backend/tests/unit/modules/profiles/validators.test.js
Web test source files:
- web/e2e/admin-dashboard.spec.js
- web/e2e/admin-deployment-monitoring.spec.js
- web/e2e/admin-history.spec.js
- web/e2e/admin-insights.spec.js
- web/e2e/admin-users.spec.js
- web/e2e/gathering-areas.spec.js
- web/e2e/help-request-map.spec.js
- web/e2e/navigation.spec.js
- web/e2e/news-fallback.spec.js
- web/e2e/onboarding.spec.js
- web/e2e/profile-and-privacy.spec.js
- web/e2e/profile-location-sync.spec.js

Additional Information

A large part of my contribution was full-stack ownership of user-facing flows. I implemented both the visible web/Android experience and the backend/API behavior, data contracts, state handling, tests, and regression fixes behind those flows. This was especially important for auth/Google OAuth, profile/location flows, maps, Gathering Areas, Help Request Map, admin coordination, notifications, and announcements/news. I also contributed heavily to final-stage stabilization to make these flows reliable in real end-to-end demo scenarios.

Rojhat Delibaş (Backend, Mobile, Frontend)

1. Responsibilities

I worked as a backend/mobile-focused contributor with additional web support responsibilities during the final milestone. My main responsibility was to make emergency communication, safety awareness, and request-help flows reliable enough for the final release and demo. In practice, this meant implementing notification infrastructure, trusted safety circles, nearby visible users, Android request-help fixes, backend API behavior, final regression tests, and demo-critical data/visibility reasoning.

I also contributed to cross-platform integration work where backend behavior had to be reflected correctly in Android and web clients. This included Android FCM push integration, in-app notification support, web notification visibility, safety-circle UI behavior, nearby-user offline cache behavior, and release-stability fixes close to the final submission.

2. Main Contributions

Implemented notification infrastructure with in-app and FCM push support through Issue #289, Issue #291, and PR #344. This included backend notification routes, persistence, delivery records, preferences, Android FCM token registration, Android notification handling, a web notifications page, and unread badge support.
Expanded final notification coverage through PR #521. This connected notification-producing behavior to announcements, availability, help requests, safety circles, and safety status flows, and added tests around these notification paths.
Implemented trusted safety circles through PR #427. This added backend routes, database support, Android repository/UI integration, circle creation, invites, membership display, member safety status visibility, and check-in-related behavior.
Added safety-circle owner management and final polish around ownership behavior through commits and integration work after the initial safety-circle implementation. This included ownership transfer behavior, leaving/deleting restrictions, and Android UI polish around circle details.
Implemented and improved privacy-aware nearby visible users with offline support through PR #456, PR #500, PR #502, and Issue #471. This work connected backend safety-status visibility rules with Android cached/offline nearby-user behavior and current-location refresh.
Fixed final Android request-help regressions through PR #593, PR #616, and PR #618. These fixes prevented premature help request creation, corrected edit-mode labels, and preserved location fields when editing existing help requests.
Added and expanded tests for backend notification behavior, auth/rate-limit behavior, safety circles, safety status, nearby visible users, Android request-help behavior, Android timestamp formatting, and final regression cases. Evidence includes PR #344, PR #351, PR #521, PR #592, PR #616, and PR #618.

3. Significant Issues

The most significant issues I worked on after the previous milestone are grouped below. I limited each category to the top three items as requested.

4. Code-Related Issues Resolved or Reviewed — Top 3

Issue	Why It Was Significant
#289 — Implement in-app notifications and #291 — Implement push notifications	Added the final notification infrastructure used by assignment, announcement, safety-circle, safety-status, and system update flows. This connected backend persistence, Android FCM support, web notification display, and preference handling.
#471 — Add privacy-aware manual offline cache refresh for current location	Made nearby visible users usable under poor connectivity by combining backend visibility rules with Android offline cache and current-location refresh behavior. This was important for final demo scenario reliability.
#589 — Help request is created before selecting request details	Fixed a final-demo-critical Android flow where a help request could be created before the user filled in the form. This reduced accidental incomplete emergency requests and made the request-help UX more trustworthy.

5. Non-Code-Related Issues Resolved — Top 3

Issue / Artifact	Related PR(s) / Evidence	Why It Was Significant
Final demo safety-circle and nearby-user scenario preparation	Final demo scenario data reasoning and presentation preparation	The final demo scenario depended on precise relationships between users, safety circles, safety statuses, profile visibility, location visibility, and residential-area matching. I helped reason about why users appeared or did not appear in nearby-user flows and what data had to exist for the scenario to work reliably.
Notification setup and configuration documentation	#344	The notification implementation required documenting new environment/configuration behavior, Firebase/FCM-related setup, backend secrets, Android config, and notification cleanup behavior so the feature could be maintained and deployed safely.
Final API / demo-data documentation support	Final deliverables preparation and scenario documentation support	Helped prepare final milestone documentation around API endpoints, scenario data requirements, and demo behavior so the delivered implementation could be explained clearly in the final wiki/report.

6. Pull Requests

Personal PRs I created that were merged on or after April 7, 2026:

PR	Area	Summary
#252 — Update email verification flow	Backend / auth	Routed verification emails to the frontend verification flow and returned an access token after successful verification.
#344 — Build notification infrastructure with in-app and FCM push support	Backend / mobile / web	Added notification DB migrations, backend APIs, notification preferences, Android FCM integration, notification screen integration, and web notification UI.
#351 — Scope login rate-limit per email+IP	Backend / security	Improved login rate-limiting behavior and added regression coverage.
#355 — Secure guest request flow while keeping guest create	Backend / help requests	Secured guest request access without removing guest help request creation.
#427 — Implement trusted safety circles	Backend / mobile	Added trusted safety-circle backend APIs, database model, Android data/UI integration, invites, members, and visibility behavior.
#456 — Cache nearby visible users for offline access	Mobile / backend	Added Android offline cache support for nearby visible users and backend safety-status visibility support.
#491 — Fix Android lifecycle timestamp timezone display	Mobile bug fix	Fixed Android request lifecycle timestamp display and added mapping/formatting tests.
#500 — Add manual current-location offline nearby refresh	Mobile / offline cache	Added manual nearby-user refresh based on current location and offline cache state.
#502 — Add current location offline nearby refresh	Backend / mobile	Connected current-location nearby refresh to backend visibility behavior and Android cached nearby-user data.
#521 — Expand notification coverage	Backend / tests	Expanded notification-producing behavior and tests across announcements, availability, help requests, safety circles, and safety status flows.
#592 — Safety circle check-in timestamp formatting	Mobile bug fix	Fixed safety-circle timestamp formatting and added regression coverage.
#593 — Defer help request creation until form submit	Mobile bug fix	Prevented creating incomplete help requests before the request-help form is submitted.
#616 — Update request help edit action label	Mobile bug fix	Changed Android edit-mode action label from create wording to edit-specific wording and added tests.
#618 — Preserve help request edit location prefill	Mobile bug fix	Preserved existing address and coordinate fields when editing help requests after partial remote refreshes.

7. Conflict Resolution

I handled several integration and stabilization issues during the final milestone, especially where backend behavior, Android UI state, and final-demo expectations overlapped.

The largest integration point was the notification infrastructure in PR #344. This branch touched backend migrations, notification routes, notification services, availability hooks, help-request hooks, Android Firebase configuration, Android notification token synchronization, and web notification UI at the same time. While integrating this work, I had to make sure notification creation did not break existing availability and assignment flows. A later stabilization commit restored assignment behavior after a broken merge around availability logic: commit e47148d.

The safety-circle work also required careful integration because it connected new backend tables/routes with Android navigation and safety-status visibility behavior. I followed up the initial implementation with owner-management and UI-polish work so that ownership transfer, leave/delete restrictions, circle detail display, and member safety states remained consistent with the backend rules.

The nearby visible users feature required conflict-safe integration between backend privacy/visibility logic and Android offline caching. Since this feature depended on current location, saved residential area, safety status, and privacy settings, I handled the implementation in multiple PRs to avoid mixing too many risks at once: PR #456, PR #500, and PR #502.

Close to the final release, I resolved smaller but demo-critical Android regressions in request-help and safety-circle screens. PR #593, PR #616, and PR #618 helped keep the final mobile demo flow consistent by preventing premature request creation, correcting edit-mode wording, and preserving request location data.

8. AI Transparency & Documentation

I used OpenAI ChatGPT / Codex as a supervised engineering assistant during the final milestone. I mainly used it for backend/mobile implementation reasoning, debugging, regression-test planning, and integration review. AI-generated outputs were treated as draft suggestions; I reviewed the codebase, checked existing architecture, adapted suggestions to the repository, and made the final implementation decisions myself.

Prompt Log History

Asked for guidance on designing a backend notification module with notification persistence, notification types, unread counts, read/unread state, and recipient-based listing.
Asked how to structure notification routes, controller/service/repository layers, validators, and tests consistently with the existing backend module architecture.
Asked how to model notification devices and delivery records for FCM push notification support.
Asked how to integrate notification creation into existing help request and availability flows without breaking assignment behavior.
Asked how to support notification preferences globally and per notification type.
Asked how Android should register and unregister FCM device tokens with the backend.
Asked how to handle Android Firebase Messaging Service integration and token synchronization after login/logout.
Asked how to expose notification data on the web client and show unread notification state in navigation.
Asked for review ideas around notification edge cases such as missing recipients, invalid notification types, admin-only notification creation, disabled push preferences, and stale availability expiration.
Asked for regression-test ideas for notification creation, notification listing, unread count, mark-as-read, device registration, notification preferences, and background cleanup behavior.
Asked how to design trusted safety circles in the backend using circle, membership, invite, and ownership concepts.
Asked how to structure safety-circle routes for creating circles, listing circles, showing members, inviting users, accepting/rejecting invites, leaving circles, deleting circles, and transferring ownership.
Asked how safety-circle visibility should interact with safety status and privacy rules.
Asked how to prevent invalid ownership/member operations, such as inviting yourself, inviting an existing member, leaving a circle as owner, or transferring ownership to a non-member.
Asked how Android should represent safety circles, member lists, invite state, and safety status display in the UI.
Asked how to handle safety-circle check-in behavior and how it should update or reuse the user’s safety status.
Asked how to format and test safety-circle check-in timestamps on Android.
Asked for backend integration-test cases for safety-circle creation, invites, member visibility, ownership transfer, leave/delete behavior, and conflict cases.
Asked for Android UI/state handling ideas for showing circle members, owner actions, accepted members, pending invites, and safety status summaries.
Asked how to implement privacy-aware nearby visible users using profile visibility, location visibility, safety status, and location data.
Asked how nearby-user visibility should work for users in the same residential area versus users discovered through current location.
Asked how Android should cache nearby visible users for offline access.
Asked how to design manual current-location refresh behavior while preserving offline fallback data.
Asked how to model nearby-user cached entities and DAO access in the Android local database.
Asked how to avoid showing users who should be hidden because of privacy settings, missing safety status, or missing location data.
Asked how to test nearby-visible-user repository behavior with cached responses, failed refreshes, and current-location queries.
Asked how backend safety-status visibility endpoints should validate current-location query parameters.
Asked for edge cases around nearby users, such as stale location data, missing safety status records, private profiles, and users outside the visible area.
Asked why the Android Home “I Need Help” action could create a help request before the user completed the request details form.
Asked how to defer help request creation until the final form submission while preserving the intended navigation flow.
Asked how to avoid clearing or changing safety/request state too early when entering the request-help flow.
Asked how edit mode in the Request Help screen should differ from create mode.
Asked how to update the primary action label so edit mode shows “Save Changes” instead of “Send Help Request.”
Asked for regression-test ideas for create/edit action label selection.
Asked why existing location fields could disappear when editing a help request after a partial remote refresh.
Asked how to preserve previous country, city, district, neighborhood, extra address, latitude, and longitude values when remote mapping returns partial data.
Asked for tests that verify edit-form location prefill and coordinate preservation.
Asked how to handle timezone display for Android request lifecycle timestamps.
Asked how to test request lifecycle formatting so requester-facing and helper-facing screens display consistent time values.
Asked how mapping tests should verify assigned request and my-help-request display fields.
Asked how to keep guest help request creation available while preventing guests from accessing or modifying unrelated requests.
Asked how guest access tokens should be validated against a specific help request.
Asked for backend service/controller test cases for guest request access, invalid guest tokens, owner access, and forbidden cross-request access.
Asked for regression-test coverage ideas after implementing notifications, safety circles, nearby users, and request-help fixes.
Asked how to split tests between backend unit tests, backend integration tests, Android repository tests, and Android UI/presentation tests.
Asked how to review final milestone changes for risky integration points before merge.
Asked for edge cases around notification hooks affecting availability/assignment behavior.
Asked for edge cases around safety-circle ownership and member state consistency.
Asked for edge cases around offline nearby-user cache behavior and failed network refreshes.
Asked for edge cases around request-help edit mode, partial location refresh, and form hydration.
Asked how to safely integrate notification hooks into availability and help-request services without changing existing assignment semantics.
Asked how to reason about merge conflicts when notification infrastructure and availability assignment logic touched the same backend service files.
Asked how to restore assignment flow behavior after resolving notification-related integration issues.
Asked how to keep Android nearby-user, safety-circle, and request-help fixes small enough to review near the final deadline.

AI Usage Boundaries

I did not provide secrets, credentials, API keys, production tokens, private SSH keys, or private user data to AI tools.
I did not use AI output as final code or final documentation without manual review.
I checked suggestions against the existing repository structure before applying them.
I verified PR links, issue links, test paths, and implementation scope manually.
Final implementation, testing, integration, and submitted report content remained my responsibility.

9. Individual Testing Efforts

Test / Evidence	Related PR(s)	Contribution
`backend/src/modules/auth/routes.js`, `backend/tests/unit/modules/auth/routes.rate-limit.test.js`	#351	Added regression coverage for email+IP scoped login rate limiting after the previous milestone.
`backend/tests/integration/modules/notifications/notifications.integration.test.js`, `backend/tests/unit/modules/notifications/*`	#344	Covered notification creation, listing, read/unread behavior, preferences, device registration, admin-only creation, and notification validation/service behavior.
`backend/tests/integration/modules/notifications/notification-jobs.integration.test.js`	notification test commits	Added DB-backed stale-expiration coverage for notification/availability-related background behavior.
`backend/tests/unit/modules/*/service.test.js` notification-producing flow tests	#521	Expanded coverage for notification-producing behavior across announcements, availability, help requests, safety circles, and safety statuses.
`backend/tests/integration/modules/safety-circles/safety-circles.integration.test.js`	#427	Covered safety-circle backend behavior such as circle creation, membership, invites, ownership, and member status visibility.
`backend/tests/integration/modules/safety-status/safety-status.integration.test.js`	#456, #502	Covered safety-status visibility behavior used by nearby visible users and privacy-aware discovery.
`android/app/src/test/java/com/neph/features/nearbyusers/data/NearbyVisibleUsersRepositoryTest.kt`	#456, #500, #502	Added Android repository tests for nearby visible users, offline cache behavior, and refresh behavior.
`android/app/src/test/java/com/neph/features/safetycircles/presentation/SafetyCirclesFormattingTest.kt`	#592	Added regression coverage for safety-circle check-in timestamp formatting.
`android/app/src/test/java/com/neph/features/requesthelp/presentation/RequestHelpActionLabelTest.kt`	#616	Added regression coverage for create/edit mode action label selection in the Request Help screen.
`android/app/src/test/java/com/neph/features/requesthelp/data/RequestHelpOfflineMappingTest.kt`	#618	Added regression coverage to preserve previous address and coordinate fields when editing a request after partial remote mapping.
`android/app/src/test/java/com/neph/features/requesthelp/data/RequestLifecycleFormattingTest.kt`, `AssignedRequestRepositoryMappingTest.kt`, `MyHelpRequestsRepositoryMappingTest.kt`	#491	Added Android lifecycle timestamp formatting and mapping coverage for request/assignment displays.

10. Additional Information

Beyond individual feature PRs, I also contributed to final demo readiness by helping reason about the scenario-specific data required for safety circles and nearby visible users. This included user relationships, location matching, profile visibility, location visibility, safety statuses, and why certain users would or would not appear in the Android nearby users screen.

My final milestone work was concentrated on making the project feel like a connected emergency product rather than separate screens. Notifications connected backend events to users, safety circles connected trusted people, nearby visible users connected location/privacy logic to emergency awareness, and the request-help fixes made the most important Android emergency flow less error-prone before the final demo.

Mehmet Can Gurbuz (DevOps, Backend, Frontend, Mobile)

Responsibilities

During this milestone, I actively contributed across DevOps, backend, frontend, and mobile domains. My main ownership areas were backend and DevOps, while I also supported web and mobile implementation tasks when needed. In addition to coding work, I contributed to bug-fix coordination and project documentation activities.

Main Contributions

Took core responsibility in backend-focused implementation and integration workflows.
Managed and supported AWS EC2 server-related operational tasks for deployment/runtime continuity.
Worked on backend integration points to keep service communication stable across components.
Contributed to database migration workflows, including migration consistency, execution reliability, and environment alignment.
Worked on project workflow files (CI/CD) to improve automation reliability for build, test, migration, and release processes.
Contributed to web and mobile issues that required cross-platform alignment.
Participated in bug-fix cycles for stability, release readiness, and final-stage quality improvements.
Supported non-code project work, including documentation and process-level contributions.

Significant Issues (Strict Limit)

Code-related issues

Non-code-related / coordination issues

#92 - [Backend][DOC] Define backend API conventions (error format, status codes, auth context) - Established shared backend API/error conventions to reduce implementation ambiguity across teams.
#109 - [DOC] Writing the Meeting Report - Documented meeting outcomes and decisions to keep milestone execution traceable.
#369 - [DOC] Define Data Strategy - Clarified data strategy decisions that supported consistent implementation and release preparation.

Code-Related Issues

My code-related work mainly focused on backend service development, integration reliability, database migration stability, CI/CD workflow updates, server-side deployment readiness, and cross-layer issue resolution affecting web/mobile clients. I contributed to migration execution flow and workflow-file improvements to reduce deployment and release friction. The most representative items are listed above in the strict-limit section, and the full implementation evidence can be attached through my authored PRs.

Non-Code-Related Issues

My non-code work included milestone planning, documentation, and coordination support that directly improved delivery quality: I helped define and track issues, contributed to key documentation outputs (including meeting/report and data-strategy related work), and supported workflow-level alignment so backend, web, and mobile tracks stayed synchronized during final-stage development and release preparation.

Pull Requests

Created / authored PRs since 7 April 2026 (this milestone)

Reviewed PRs since 7 April 2026 (this milestone)

Conflict Resolution

Resolved release and branch-sync conflicts between development and main during milestone-critical merges and releases (e.g., #256, #536, #626).
Resolved CI/CD and deployment reliability issues by fixing workflow and pipeline behavior (e.g., #234, #247, #219).
Resolved migration/environment drift risk by standardizing local/prod migration flow and aligning runtime execution expectations (e.g., #260).
Resolved backend-web/admin integration mismatches during feature delivery by aligning API behavior and dashboard expectations (e.g., #329, #342, #345).

AI Transparency & Documentation

I used Codex and GitHub Copilot as implementation assistants for coding support, debugging, and iteration.
I used ChatGPT specifically for documentation support, drafting, and improving written project artifacts.
These AI tools helped me accelerate development and documentation tasks, but they were used as assistants only.
The overall control of the work, final technical decisions, integration checks, and delivered outcomes remained under my responsibility.
AI usage log:
Prompt Log History - Mehmet Can Gurbuz
Note: This log does not include every single AI interaction; it includes the representative records I currently have access to.

Individual Testing Efforts

My individual testing effort in this milestone focused on validating the backend and frontend work I implemented and reviewed. Across my authored PRs, I added or updated automated tests where needed and performed manual verification on critical flows before merge, with a focus on regression prevention, integration reliability, and final-release stability.

Test files I directly contributed to:

Additional Information

Beyond direct implementation, I contributed as a cross-functional team member by supporting backend-devops continuity, handling cross-platform issue follow-ups, and improving documentation and bug-fix quality across the milestone. I also helped keep release readiness stable through branch synchronization, migration/workflow follow-up, and practical coordination when priorities changed, which reduced integration risk and helped the team maintain delivery momentum before the final demo.

Alper Kartkaya (Backend, Frontend, Mobile, and Web)

1. Responsibilities

I worked as a full-stack/mobile-focused contributor for the final milestone. My main responsibilities were to make the emergency-critical mobile flows reliable under real disaster conditions, connect new backend capabilities to the web/mobile clients, improve final-demo readiness, and stabilize the release with tests and documentation. In practice, this meant owning or heavily contributing to Android offline-first behavior, emergency/safety flows, self-onboarding, backend-backed content, cross-platform UI consistency, and final regression fixes.

2. Main Contributions

Implemented Android offline-first architecture for emergency-critical flows via Issue #265 and PR #300.

I introduced Room-backed local persistence, sync-operation queueing, WorkManager-based synchronization, retry/conflict handling, and UI feedback for pending/failed offline operations.

Implemented safety status and emergency-mode capabilities through Issue #380 and PR #413.

This work connected mobile/web/backend pieces for safety status, emergency request state, location/visibility behavior, safety-circle-related user flows, and reliability polish for final demo scenarios.

Implemented contextual mobile self-onboarding through Issue #472 and PR #572.

The onboarding flow guides first-time mobile users inside the live application with contextual overlays, target hints, pulse animations, practice help requests, skip/completion logic, and tests.

Built news and announcements page with admin CRUD via Issue #332 and PR #359.

This replaced mock news with persisted announcements, public announcement APIs, admin create/update/delete flows, web integration, migrations, and backend test coverage.

Delivered cross-platform dark-theme support and UI polish through Issue #460 and PR #467.

This covered persisted theme preference, theme-aware logos/icons, web/mobile toggles, and regression coverage.

Implemented E2E and regression testing infrastructure through Issue #311 and PR #313.

This added Android E2E infrastructure with MockWebServer/fake backend support, UI test tags, debug-only test wiring, and documentation for repeatable test execution.

3. Significant Issues

4. Code-Related Issues Resolved or Reviewed — Top 3

Issue	Related PR(s)	Why it was significant
#265 — Implement Offline-First Architecture for Android Client	#300	Made emergency help, availability, assigned requests, and sync behavior usable even when network connectivity is unreliable.
#380 — One-tap Emergency Mode	#413	Added core final-demo emergency/safety behavior and connected mobile UI, backend persistence, and request-state transitions.
#472 — Add mobile self-onboarding tutorial after profile completion	#572	Helped first-time mobile users understand the application by guiding them through real screens instead of static documentation.

5. Non-Code-Related Issues Resolved — Top 3

Issue	Related PR(s) / artifact	Why it was significant
#624 — Ensure final submission setup includes working default admin credentials and release notes	#625, `final-milestone-release-notes.md`	Closed a final-submission risk by making demo setup and release notes explicit and reproducible.
#465 — Release v0.2.0 from development to main	#466	Coordinated a major release merge from `development` to `main`, helping keep the release branch aligned with the delivered software.
#281 — Document Offline-First Architecture and Limitations	#300, `android/README.md`	Documented how offline-first behavior works, how to run it, and what limitations remain, making the implementation maintainable for the team.

6. Pull Requests

Personal PRs I created that were merged after the previous milestone:

PR	Area	Summary
#300 — Implement android offline-first data layer and sync	Mobile / offline-first	Room database, sync queue, WorkManager sync, offline state UI, conflict/retry behavior.
#313 — Design and implement E2E tests	QA / mobile E2E	Android E2E infrastructure, fake backend support, UI testability, test documentation.
#359 — Backend-backed news announcements with admin CRUD	Backend / web	Announcement APIs, admin CRUD, web integration, tests, and migrations.
#413 — Safety status & emergency mode implementation	Backend / mobile / web	Emergency and safety-status flows, pull-to-refresh, request state handling, sync feedback.
#461 — Fallback content mechanism during API failures	UX / resilience	Fallback and retry UX for news, home previews, and gathering areas.
#462 — User account soft deletion and request state cleanup	Backend / web / mobile	Account soft deletion, anonymization, request/assignment cleanup, confirmation flows.
#466 — Release v0.2.0	Release	Merged `development` into release/main path for the v0.2.0 milestone.
#467 — Cross-platform dark theme support	Web / mobile UI	Persisted theme support, mobile/web toggles, theme tokens, and conflict-safe integration.
#572 — Contextual self-onboarding	Mobile	Interactive onboarding overlays, target hints, practice help request, and tests.
#575 — Prevent duplicate navigation stack entries	Mobile bug fix	Fixed post-edit navigation back to My Help Requests.
#576 — Theme-aware logo support for web and mobile	UI / branding	Light/dark logo switching and Android icon/branding polish.
#577 — Add theme toggle to navigation bar	UI / accessibility	Moved theme controls closer to users on web and mobile.
#611 — Prevent state restoration on Home navigation	Mobile bug fix	Fixed Home navigation after Android system-back/edit-flow interactions.
#617 — Fix help request validation/save failures during edit	Mobile bug fix	Fixed edit-form hydration, location normalization, and phone validation risks.
#622 — Null fields and first-aid expertise field	Mobile bug fix	Sanitized My Help Requests display and added regression coverage.
#625 — Final demo admin seed and release notes	Documentation / release	Added final-demo admin migration, setup docs, and release notes.

The PRs I reviewed or merged after the previous milestone:

PR	Role	Summary
#616 — Fix request help edit action label	Reviewed and merged	Reviewed and merged the Android Request Help edit-label fix so edit mode uses edit-specific action wording instead of create-flow wording.
#618 — Preserve help request edit location prefill	Reviewed and merged	Reviewed and merged the Android edit-location prefill fix so existing request location values remain visible while editing.
#623 — Viewport loading and state info	Reviewed	Reviewed final map/viewport loading stabilization and state-info polish for resource-map behavior.
#481 — Release conflicts and security alerts	Reviewed	Reviewed release-conflict and security-alert cleanup before final release synchronization.
#518 — Android UI overhaul	Reviewed	Reviewed Android app shell/navigation redesign, shared UI system, and cross-screen consistency changes.
#357 — Privacy & Security page	Reviewed	Reviewed the web Privacy & Security page contribution and its related user-facing privacy controls.
#344 — Notification infrastructure	Reviewed	Reviewed in-app and FCM notification infrastructure that supported final notification-related flows.
#579 — Clear safe status when requesting help	Reviewed	Reported and followed up on guest-user safety/help-request edge cases where the app could return to login or leave safety status inconsistent.
#482 — Sync main into development	Reviewed	Confirmed the branch synchronization looked good before the development sync was merged.
#427 — Trusted safety circles	Reviewed	Participated in the review discussion for the trusted safety-circles implementation and agreed with the implementation direction.

7. Conflict Resolution

I handled several integration conflicts and branch-synchronization problems during the final milestone:

In PR #467, I resolved the dark-theme branch against the latest development state while preserving Android back-navigation exit confirmation.
In PR #572, I repeatedly synchronized the mobile onboarding branch with development, resolving conflicts without dropping existing navigation/offline behavior.
Near the final release, I integrated small teammate/reviewer bug-fix branches and then added final regression fixes in PR #611, PR #617, and PR #622 so the final mobile demo flow remained consistent.

8. AI Transparency & Documentation

Comprehensive Log of All Prompts - Alper Kartkaya

I used the following AI tools as an implementation and review assistant during the final milestone:

OpenAI ChatGPT/Codex Free Plan with plugin oh-my-codex
Open-Source Software OpenCode with plugin oh-my-openagent
GitHub Copilot Pro Education Plan
Antigravity (Claude 4.6 and Gemini 3 Pro) with Gemini Pro Education Plan

Note on AI-assisted engineering approach:

My use of AI tools followed a planning-first workflow. I first used AI agents to help clarify requirements, decompose tasks, and draft implementation plans, specifications, PRDs, checklists, or testing strategies. I only moved to implementation after reviewing the proposed plan and deciding that it matched the project goals and repository constraints.

I also used agentic development tools as part of my engineering workflow. In this context, ULW refers to Ultrawork, used through the oh-my-codex / OMX workflow environment. OMX is a workflow layer around OpenAI Codex CLI that supports structured prompts, workflows, plans, logs, and agent-style execution. This was especially useful for larger tasks where I wanted the AI to behave less like an autocomplete tool and more like a supervised engineering assistant.

For mobile validation, I used AI-assisted tooling together with ADB and the Android emulator. This allowed the agent to launch and interact with the Android app in a test environment, inspect flows, click through emulator screens, and help verify behavior such as navigation, form submission, and UI regressions. Final decisions, acceptance of plans, code review, and integration responsibility remained mine.

Other than that, I used AI assistance for decomposing GitHub issues into implementation/checklist steps, debugging failing builds, tests, merge conflicts, and endpoint behavior, drafting or refining Kotlin/JavaScript/SQL implementation changes, generating and reviewing regression-test ideas, and preparing release notes, setup instructions, and GitHub-facing documentation.

I treated AI output as assistant-generated draft material: I reviewed code changes, adapted them to the repository architecture, checked them against existing tests/builds, and avoided presenting unverified AI output as completed work. Secrets and credentials were not included in GitHub-facing drafts.

9. Individual Testing Efforts

Test / evidence	Related PR(s)	Contribution
`AndroidE2ETest.kt`, `FakeNephBackend.kt`, `NephE2ETestEnvironmentRule.kt`	#313	Added Android E2E infrastructure and fake-backend support for realistic mobile flows without production API dependencies.
`RequestHelpOfflineMappingTest.kt`, `SyncOperationRecoveryPolicyTest.kt`	#300	Covered offline help-request mapping and sync recovery behavior so interrupted operations are not silently lost.
`announcements.integration.test.js`, `announcements/service.test.js`	#359	Added backend coverage for announcement APIs and service behavior.
`safety-status.integration.test.js`, `SafetyStatusRepositoryAndroidTest.kt`	#413	Covered safety-status API and Android repository behavior for emergency-state workflows.
`theme-toggle.spec.js`, `ThemePreferenceStoreTest.kt`	#467, #577	Added regression coverage for persisted dark/light theme behavior across web and mobile.
`RequestHelpFormStateMappingTest.kt`, `RequestLifecycleFormattingTest.kt`	#617, #622	Added final regression coverage for edit-form hydration, requester-facing display text, and helper expertise formatting.

10. Additional Information

Beyond individual feature PRs, I also contributed to final release readiness by validating final-demo admin setup, and resolving late-stage mobile regressions that would have affected the final demonstration. My contributions were concentrated on making the project usable under realistic emergency conditions: offline operation, clear safety state, resilient fallback UI, understandable onboarding, and reproducible final setup.

Berat Sayın (Mobile, Web, and Backend)

Responsibilities

During this milestone, I mainly worked on mobile, web, and backend tasks related to emergency request usability, privacy/security settings, account lifecycle behavior, location/privacy flows, and timestamp display consistency. My work focused on reducing friction in critical user flows, fixing demo/release-critical Android issues, and keeping backend, web, and mobile behavior aligned.
Main Contributions
- Made selected Request Help fields optional so users can submit emergency requests faster with fewer mandatory details.
- Implemented and stabilized Privacy & Security settings across web and Android, including visibility settings, location sharing behavior, password reset navigation, and backend-backed persistence.
- Fixed Android privacy-save regressions so privacy updates no longer overwrite unrelated cached profile data.
- Fixed Android Privacy & Security screen crash and location-permission bootstrap/default privacy behavior.
- Fixed Android account deletion and soft-deletion re-signup behavior across mobile/backend authentication flows.
- Improved timestamp formatting across Android and web by adding Today/Yesterday labels and fixing notification timezone handling.
- Added or updated focused backend, Android unit, integration, and E2E tests for the features and fixes I implemented.
Significant Issues

Code-related issues:
1. #284: Improved Request Help usability by making selected non-critical fields optional through PR #356.
2. #285: Implemented and stabilized Privacy & Security settings through PR #357, PR #444, PR #463, PR #501, and PR #565.
3. #488: Fixed Android account deletion and soft-deleted account re-signup behavior through PR #504 and PR #563.
Non-code-related issues:
1. #296 - Write Use of Standards Wikipage: Prepared the Use of Standards wiki page, documenting the standards selected for the project and how they relate to NEPH.
2. #372 - Define Acceptance Testing Strategy: Prepared the Acceptance Testing Strategy wiki page, defining how acceptance tests should be structured, executed, and evaluated for the final release.
3. #263 - Writing the Meeting Report 9: Took notes for the 15.04.2026 team meeting and prepared Meeting Report 9, including agenda items, discussion topics, and action items.
Code-Related Issues

My code-related work focused on Android/mobile stability, backend validation, web/mobile privacy parity, account deletion, location sharing, and timestamp formatting. I worked on emergency-flow usability by reducing required Request Help fields, implemented privacy/security controls across platforms, and fixed several release-critical bugs found during final integration and review.
Non-Code-Related Issues

My non-code work mainly focused on documentation and project traceability. I prepared the Use of Standards page to document the external standards selected for the project, wrote the Acceptance Testing Strategy to define a consistent validation approach for final milestone features. These documentation tasks helped clarify technical decisions, acceptance-test expectations, and post-MVP team responsibilities.
Pull Requests
Conflict Resolution
- Helped resolve backend/mobile contract mismatches around optional Request Help fields and default values.
- Fixed Android privacy-cache merge behavior where partial privacy responses could overwrite unrelated cached profile data.
- Helped align mobile/backend account deletion semantics so soft-deleted accounts and fresh re-signup behavior worked correctly.
- Fixed timestamp interpretation problems by normalizing backend notification timestamps and aligning web/mobile display behavior.
AI Transparency & Documentation
- I used Gemini CLI as an AI-assisted development tool during this milestone, mainly for implementation support, debugging assistance, and documentation wording. Since my Gemini CLI usage happened through terminal sessions and I exited the terminal after completing the related tasks, I do not have persistent or shareable conversation log links for those sessions.
- AI assistance was used only as support during development and documentation preparation. I reviewed and adapted the suggestions myself, and the final implementation decisions, code changes, tests, PR submissions, and documentation content remained my responsibility.
Individual Testing Efforts

My testing efforts focused on the features and fixes I implemented. I added and updated backend, Android unit, integration, and E2E tests for Request Help validation, privacy payload/cache behavior, profile location/privacy defaults, account deletion, authentication soft-delete behavior, and timestamp formatting.

Relevant test evidence:
Additional Information

Overall, my final milestone work contributed to making NEPH more reliable and easier to use in emergency conditions. I focused especially on flows where small bugs or unnecessary friction would strongly affect users: creating help requests, managing privacy/location sharing, deleting accounts, re-registering after deletion, and reading time-sensitive notifications/status updates.

Gülce Tahtasız (Frontend, Mobile, Backend)

Responsibilities

During this milestone, I worked across frontend, mobile, and backend. My work mainly focused on emergency/location-related user flows, Request Help usability, privacy and health-sharing behavior, operational/current location handling, route and directions support, demo data readiness, Android availability behavior, and final-stage stabilization. I also supported integration and review work around map behavior, volunteer availability, migration workflow, final demo data, and release-critical fixes.
Main Contributions
- Improved profile and helper-detail flows across Android and Web by aligning profession/expertise fields with structured options and simplifying requester-facing helper details.
- Improved Request Help behavior by simplifying help categories, making selected fields optional, and adding explicit request-level health information sharing consent.
- Updated backend, Android, offline data, and assigned volunteer flows so profile health details are only exposed when the requester gives consent.
- Refactored privacy/location settings so location sharing is managed from Privacy & Security, while profile screens remain focused on saved residential information.
- Implemented assignment route distance support and Get Directions actions across Assigned Requests, Gathering Areas, and Crisis/Help Request map surfaces.
- Added Android operational location refresh and Request Help operational location snapshots to separate emergency/current location from residential profile location.
- Added backend and Android logic for stale-location-aware volunteer availability and assignability states.
- Prepared demo seed data and later converted demo data into guarded demo migration support for realistic final-demo scenarios.
- Stabilized final-demo data and request type compatibility by normalizing Search & Rescue help request types and preserving legacy availability matching tokens.
- Improved Gathering Areas and map-related behavior by fixing filtered selection states, duplicate status text, and demo-critical map synchronization issues.
- Cleaned production-facing web pages by removing project/team-introduction content and keeping the app focused on the actual NEPH experience.
- Reviewed and supported PRs related to operational location, availability expiry, map behavior, migration workflow, final demo data, edit-request behavior, and requester-facing helper detail cleanup.

Contributed to final deliverables by preparing and adding the required application screenshots for the final submission.

Significant Issues (Strict Limit)

Code-related issues:
1. #568 - simplify request help form and add health info sharing consent: Implemented Request Help simplification and request-level health sharing consent through PR #570, including backend validation, Android offline support, assigned volunteer health visibility gating, migrations, Search & Rescue request type normalization, and related test updates.
2. #569 - move location sharing control to privacy and simplify health visibility settings: Refactored privacy/location ownership through PR #573, moving location sharing control to Privacy & Security and removing global health visibility controls from Web and Android.
3. #383 - Add demo-ready seed migrations with meaningful NEPH data: Supported final demo readiness by preparing idempotent demo seed logic and converting it into guarded demo migrations through PR #424 and PR #525.
Non-code-related / coordination issues:
1. #545 - Gathering Areas Map Does Not Sync With Active Location: Reported and helped identify a final-stage web Gathering Areas map synchronization issue.
2. #548 - Help Request Map Details Collapse Horizontally: Reported an Android Help Request Map UI bug affecting map detail usability.
3. #627 - Meeting #12: Participated in final-stage demo and release coordination around role review, rehearsal flow, presentation scenarios, and data strategy.
Code-Related Issues

My code-related work mainly focused on Request Help, privacy/location settings, operational location, volunteer availability, directions/map actions, Android location behavior, assigned request distance support, demo data infrastructure, profile/helper detail polish, and final demo stabilization. The most representative issues are listed above, and the full implementation evidence is listed through my PRs below.
Non-Code-Related Issues
Non-Code-Related Issues

My non-code work included issue reporting, review support, final demo data preparation, final deliverables screenshot preparation, release-readiness checks, and helping stabilize demo-critical flows. I especially contributed by identifying map/UI bugs, reviewing integration-heavy PRs, supporting final-stage coordination around location, availability, migrations, demo data, release behavior, and preparing screenshots for the final submission.
Pull Requests

Created / authored PRs since 7 April 2026 (this milestone only):
Reviewed / commented / participated PRs since 7 April 2026 (this milestone only):
Conflict Resolution
- Helped separate residential/profile location from operational/emergency location in Android flows.
- Helped align Request Help, volunteer availability, and map behavior with the newer operational location model.
- Helped resolve demo-readiness issues by converting standalone demo seed logic into safer guarded demo migration support.
- Helped stabilize final-stage request type compatibility by normalizing Search & Rescue values across demo data, availability matching, web map tests, Android mapping, and backend expectations.
- Helped resolve map and directions edge cases by requiring explicit destination selection and avoiding directions actions for stale/default selections.
- Helped stabilize final-stage migration, release, map, edit-request, and helper-detail issues through review/comment participation.
AI Transparency & Documentation

I used OpenAI ChatGPT / Codex as a supervised engineering assistant during the final milestone. I used it actively for implementation reasoning, code-change planning, debugging, regression-test planning, integration review, PR/report drafting, and final deliverables organization. AI assistance was especially useful for breaking down cross-platform changes across Web, Android, and backend. AI-generated outputs were treated as draft suggestions; I reviewed the repository context, adapted the suggestions to the existing architecture, tested the affected flows, and remained responsible for final implementation, integration, and submission decisions.

Prompt Log History

Asked how to inspect the repository history and identify my authored PRs, reviewed/commented PRs, issues, and commits after 7 April 2026.
Asked how to turn GitHub PR/issue/commit evidence into an individual milestone report using the same structure as a teammate’s example.
Asked how to summarize my work across frontend, Android, backend, testing, review, final deliverables, and stabilization without omitting smaller but important fixes.
Asked for implementation guidance on aligning Web and Android profile profession/expertise fields with structured dropdown and multi-select options.
Asked how to keep Complete Profile and Profile/Edit Profile flows consistent after profession, expertise, and age/profile-field changes.
Asked how to simplify requester-facing helper details in My Help Requests while avoiding confusing raw backend values.
Asked for guidance on separating residential/profile location from operational/current emergency location in Android flows.
Asked how Android profile location selection should avoid accidentally overwriting saved residential address fields.
Asked how to make Android profile location selection more predictable by keeping dependent dropdown reset behavior parent-controlled.
Asked how to design Android operational location refresh on app launch/resume without requesting permission unexpectedly or blocking startup.
Asked how to keep guest operational location local-only while syncing authenticated operational location to the backend.
Asked how Request Help should use emergency/current location snapshots instead of residential profile location.
Asked how to capture and preserve Request Help coordinates, coordinate source, captured time, and accuracy metadata.
Asked how to preserve Request Help location fields and coordinates in edit/update flows when remote mapping returns partial data.
Asked how to prevent stale draft coordinates from being reused incorrectly in Request Help.
Asked how to simplify Request Help help categories while keeping backend validation, Android mapping, web map behavior, and demo data consistent.
Asked how to add explicit request-level health information sharing consent to Request Help.
Asked how assigned volunteers should see requester health details only when the requester explicitly consents.
Asked how to update Android offline request mapping, Room schema, backend migrations, validators, repositories, and tests after adding health-sharing consent.
Asked how to normalize Search & Rescue request types across backend, Android, web crisis map, availability matching, demo data, and tests.
Asked how to preserve legacy availability matching tokens while introducing updated Request Help category names.
Asked how to move location sharing controls from profile screens into Privacy & Security on both Web and Android.
Asked how to remove global health visibility controls while preserving backend compatibility for existing privacy fields.
Asked how to update profile/privacy E2E tests after moving location sharing ownership to Privacy & Security.
Asked how to implement assignment route distance support with backend authorization checks and Android display of distance/estimated time.
Asked how to use fallback distance calculation when detailed route information is unavailable.
Asked how Android Assigned Request should handle unavailable route or destination information.
Asked how to add Get Directions actions to Web Gathering Areas, Web Crisis Map, Android Gathering Areas, Android Help Request Map, and Android Assigned Request screens.
Asked how to reuse shared directions helpers instead of implementing routing inside the application.
Asked how to ensure directions open only for explicitly selected destinations and not stale/default map markers.
Asked how to preserve marker/list selection behavior while adding directions actions.
Asked how to update E2E expectations for crisis map destination selection, map behavior, and directions actions.
Asked how to clear Gathering Areas selected items when filtering removes the selected area.
Asked how to avoid duplicate Gathering Areas status text in the web UI.
Asked how to investigate and report Gathering Areas map synchronization issues with active/current location.
Asked how volunteer availability should behave when operational location is missing, stale, or expired.
Asked how backend availability status should expose assignability state, pause reason, available-until time, and location-updated-at time.
Asked how Android should display availability pause states and guide users toward refreshing location to become assignable again.
Asked how to add notification behavior for availability pause cases without repeatedly notifying users.
Asked how to test availability pause logic in backend unit/integration tests and Android-side behavior.
Asked how to create idempotent final-demo seed data for users, profiles, volunteers, help requests, assignments, announcements, notifications, locations, and safety-related state.
Asked how to convert standalone demo seed logic into guarded demo migrations.
Asked how to make demo migrations safe to run repeatedly without deleting real data.
Asked how to normalize demo request types after Request Help category changes.
Asked how to prepare demo data that supports realistic final presentation scenarios.
Asked how to remove project/team/about/donate pages from the web app and redirect removed routes cleanly.
Asked how to update navigation tests after removing public project-introduction pages.
Asked how to review final milestone PRs for risky integration points around location, availability, maps, request editing, migrations, demo data, and release behavior.
Asked how to reason about merge conflicts when Request Help, demo data, map, availability, and migration changes touched overlapping files.
Asked how to include final deliverables work, especially preparing and adding required screenshots for the final submission.
Asked how to write the Conflict Resolution section to reflect integration support, review participation, and final-stage stabilization work.
Asked how to list relevant testing evidence from backend, Android, and web test files.
Asked how to write the AI Transparency section clearly, acknowledging active AI assistance while making the supervision and responsibility boundaries explicit.

AI Usage Boundaries

I did not provide secrets, credentials, API keys, production tokens, private SSH keys, or private user data to AI tools.
I did not use AI output as final code, final documentation, or final report content without manual review.
I checked suggestions against the existing repository structure, project conventions, and existing module boundaries before applying them.
I verified PR links, issue links, test paths, file paths, and implementation scope manually.
I used AI assistance for reasoning, code-change planning, debugging, drafting, and review support, but final implementation, testing, integration, deliverables preparation, PR submission, and report content remained my responsibility.

Individual Testing Efforts

My testing efforts focused on the features and fixes I implemented or directly supported. I added or updated backend, Android, and web E2E/unit tests around Request Help consent, assigned request routing, availability state, operational location, directions behavior, profile/privacy settings, demo data migration behavior, request type compatibility, Gathering Areas behavior, and map selection expectations.

Relevant testing evidence includes:
In addition to automated testing, I manually verified affected Android and web flows such as Request Help, profile/privacy settings, map destination selection, Get Directions actions, availability state, assigned request route information, Gathering Areas filtering, and demo data behavior.
Additional Information

Beyond direct implementation, I contributed to final-stage stabilization by reporting demo-critical bugs, reviewing location and availability PRs, supporting release/migration workflow checks, improving demo data reliability, preparing required final deliverables screenshots, and helping keep emergency-related user flows consistent across web, Android, and backend.

6. Final Software Release

6.1 Release Information

Release Name: 1.0.0
Release Tag: final-milestone
GitHub Release: 1.0.0 Final Release
Live Web Application: https://neph.app/
Live Backend API: https://api.neph.app/api
Backend Health Check: https://api.neph.app/health
Android APK: app-release.apk

6.2 Containerization and Deployment

The final release is containerized and deployed. The repository includes Docker-based setup instructions for running the backend, web application, and PostgreSQL database locally.

Relevant files:

6.3 Setup and Run Instructions

The project root README and setup documentation contain step-by-step instructions for:

running the backend API,
running the web application,
configuring environment variables,
running PostgreSQL with Docker Compose,
applying database migrations,
seeding demo/mock data,
building and running the Android application,
configuring Android API base URLs for emulator and release builds.

Setup documentation:

6.4 Environment Files

Example environment files are provided for the deployable components:

6.5 Data Seeding

The repository includes migration and demo-data instructions so the application can be populated with essential mock data for testing and demonstration.

Relevant files:

6.6 Default Credentials

Default demo credentials are documented in the final release notes and project setup instructions. These credentials allow evaluators to log in immediately with pre-created users.

6.7 Mobile Release

The Android application is delivered as a compiled APK through the official GitHub Release.

Uh oh!

Final Milestone Deliverables

Final Milestone Deliverables

1. Meeting Notes

Weekly Meetings

2. Finalized Project Documentation

2.1 Final SRS

2.2 Final Design

3. Project Review

Executive Summary

4. Progress Based on Teamwork

4.1 Team Contribution Summary

4.2 Status of Requirements

Completed

In Progress / Partially Completed

Not Started / Not Evident

4.3 API Endpoints

4.3.1 API Documentation

4.3.2 Sample Usage Scenarios

Scenario 1: User Checks In to a Safety Circle

Scenario 2: Nearby Visible Users for Emergency Awareness

Scenario 3: Admin Publishes an Emergency Announcement

Scenario 4: Admin Sends a Location-Based Emergency Broadcast

4.4 User Interface / User Experience

4.4.1 UI Code References

4.4.2 Screenshots of New or Significantly Modified Interfaces

Web Application Screenshots

Android Mobile Application Screenshots

4.5. Utilized Standards

4.5.1 Summary

4.5.2 Deep Dive

Standard 1: WCAG 2.1

Standard 2: HTML Living Standard / Semantic HTML

Standard 3: WAI-ARIA / Accessible Interaction Patterns

Standard 4: CSS Responsive Design

4.6. Testing & Quality Assurance

4.6.1 Test Execution Reports

4.6.2 New Test Evidence

Backend API Tests

Web Application Tests

Mobile Application Tests

4.6.3 Impact Analysis

Coverage

Bug Detection

Readiness

4.7. Demo Reflections & Notes

Demo Notes

Reflections

5. Individual Contributions

1. Responsibilities

2. Main Contributions

3. Significant Issues

4. Code-Related Issues Resolved or Reviewed — Top 3

5. Non-Code-Related Issues Resolved — Top 3

6. Pull Requests

7. Conflict Resolution

8. AI Transparency & Documentation

9. Individual Testing Efforts

10. Additional Information

Responsibilities

Main Contributions

Significant Issues (Strict Limit)

Code-related issues

Non-code-related / coordination issues

Code-Related Issues

Non-Code-Related Issues

Pull Requests

Created / authored PRs since 7 April 2026 (this milestone)

Reviewed PRs since 7 April 2026 (this milestone)

Conflict Resolution

AI Transparency & Documentation

Individual Testing Efforts

Additional Information

1. Responsibilities

2. Main Contributions

Implemented Android offline-first architecture for emergency-critical flows via Issue #265 and PR #300.

Implemented safety status and emergency-mode capabilities through Issue #380 and PR #413.

Implemented contextual mobile self-onboarding through Issue #472 and PR #572.

Built news and announcements page with admin CRUD via Issue #332 and PR #359.

Delivered cross-platform dark-theme support and UI polish through Issue #460 and PR #467.