CAPSTONE LOCAL DEVELOPMENT CHECKLIST
====================================

Approved title (DO NOT CHANGE):
WEB-BASED REPORTING MANAGEMENT SYSTEM FOR HAZARDOUS TREES NEAR RESIDENTIAL AREA IN BARANGGAY TUPSAN PEQUEÑO

Project location: C:\xampp\htdocs\tupsan
Development setup: Local XAMPP only
Version control: No Git; use timestamped local backups and database exports
Last updated: July 21, 2026

CHECKBOX GUIDE
--------------
[x] Completed
[ ] Not completed
[!] Requires adviser/client confirmation


PHASE 1 - LOCAL BACKUP (COMPLETED)
----------------------------------
[x] Copy the complete local project.
[x] Verify that the source and backup contain the same 38 files.
[x] Verify that source and backup sizes match.
[x] Export the tupsan_db MySQL database.
[x] Back up the capstone manuscript.
[x] Create this local master checklist.

Backup folder:
C:\xampp\htdocs\tupsan_backups\phase1_20260721_192459

Backup contents:
- project\        Complete project copy
- database\       tupsan_db.sql
- documentation\  Capstone1 HazardousTreesReporting.docx


PHASE 2 - MANUSCRIPT AND SYSTEM ALIGNMENT (COMPLETED)
-----------------------------------------------------
[x] Keep the approved title exactly as written.
[x] Document the application as native PHP without CodeIgniter.
[x] Remove unrelated "Scoring and Tabulation System" content.
[x] Remove school-event, judge, organizer, and real-time scoring references.
[x] Remove staff-attendance claims because attendance is outside the system scope.
[x] Align the mobile-only limitation with the responsive web system.
[x] Align the location limitation with the GPS and map-selection behavior.
[x] Remove AI analysis from the application and manuscript.
[x] Replace the ERD with the proposed final native PHP/MySQL data model.
[x] Replace the staff/admin use-case figure and align its narrative.
[x] Review DFD Level 0 and Level 1 against the planned final workflow.
[x] Replace the system architecture and role-based system flow figures.
[x] Verify that Microsoft Word opens the revised 95-page manuscript.
[x] Verify that the approved title remains unchanged.

Phase 2 completion notes:
- Final back end: Native PHP with PDO and MySQL.
- AI analyzer endpoint, interface, JavaScript, and API credential were removed.
- Revised manuscript: Capstone1 HazardousTreesReporting.docx
- Pre-Phase 2 backup: C:\xampp\htdocs\tupsan_backups\phase2_before_20260721_193201
- Completed Phase 2 backup: C:\xampp\htdocs\tupsan_backups\phase2_completed_20260721_194909


PHASE 3 - OFFICIAL BARANGAY INFORMATION
---------------------------------------
[x] Confirm the official municipality and province: Mahinog, Camiguin (PSA PSGC).
[x] Confirm the barangay hall coordinates: 9.189704, 124.770560 (DICT document).
[!] Obtain or validate the official barangay boundary with the LGU.
[x] Correct conflicting municipality/province values in the database seed.
[x] Use the same barangay information on every page and report.
[!] Store the validated boundary for server-side location checking.

Phase 3 progress notes:
- Canonical native-PHP location config: config/barangay.php
- PSGC barangay code: 1001803014
- The existing working polygon is stored server-side but is explicitly marked
  provisional_pending_lgu_validation. Do not use it as an official boundary
  until the Mahinog/Tupsan Pequeño LGU validates or replaces it.
- Removed two wrong-location duplicate reference points from the live database.
- Corrected the live database and recalculated stored barangay-hall distances.
- Pre-Phase 3 code/database backup:
  C:\xampp\htdocs\tupsan_backups\phase3_before_20260721_195514
- Completed Phase 3 code/database backup:
  C:\xampp\htdocs\tupsan_backups\phase3_completed_20260721_200454
- Code/database/checklist only. The manuscript was not edited in Phase 3.


PHASE 4 - LOCAL XAMPP AND MOBILE ACCESS
--------------------------------------
[x] Confirm Apache and MySQL automatically start for demonstrations.
[!] Reserve 192.168.1.6 for the XAMPP computer in the Wi-Fi router.
[x] Make BASE_URL configurable for localhost and local-network access.
[x] Allow Apache through Windows Firewall on the private network only.
[x] Configure local HTTPS for mobile GPS access.
[x] Test HTTP/HTTPS from the XAMPP computer using localhost and 192.168.1.6.
[!] Test from an Android phone on the same Wi-Fi network.
[!] Test from another laptop on the same Wi-Fi network.

Phase 4 progress notes:
- Local HTTPS address: https://192.168.1.6/tupsan/
- Plain LAN HTTP automatically redirects to HTTPS. Localhost HTTP remains
  available for development.
- Apache2.4 and MySQL are installed as Automatic Windows services and running.
- Firewall access is limited to TCP 80/443, Private profile, LocalSubnet.
- MySQL port 3306 was not opened to the LAN.
- Local certificate SANs: localhost, tupsan.local, 127.0.0.1, 192.168.1.6.
- Install tools\phase4\Tupsan-HTRS-Local-CA.crt on controlled demonstration
  phones/laptops before testing HTTPS and GPS.
- Setup instructions: tools\phase4\LOCAL_NETWORK_SETUP.txt
- Reusable administrator setup script: tools\phase4\setup_local_xampp.ps1
- The current address comes from DHCP. Router access is required to reserve it.
- Pre-Phase 4 code/database and old Apache SSL backup:
  C:\xampp\htdocs\tupsan_backups\phase4_before_20260721_202045
- Completed Phase 4 code/database and public SSL configuration backup:
  C:\xampp\htdocs\tupsan_backups\phase4_completed_20260721_203334
- Code/XAMPP configuration/checklist only. The manuscript was not edited.


PHASE 5 - SECURITY
------------------
[x] Remove the hard-coded AI API credential.
[!] Rotate or deactivate the exposed AI API credential in the provider console.
[x] Move application secrets outside publicly accessible source files.
[x] Create a dedicated MySQL account instead of using root.
[x] Replace the known default administrator password.
[x] Disable debug output for the evaluation build.
[x] Add login-attempt throttling.
[x] Enforce actual idle-session expiration.
[x] Recheck user role and account status on protected requests.
[x] Enable secure session cookie settings under HTTPS.
[x] Convert destructive GET actions to POST with CSRF validation.
[x] Archive users instead of permanently deleting them.
[x] Protect personal information according to user role.
[x] Add security headers where appropriate.

Phase 5 completion notes:
- Private application configuration: C:\xampp\private\tupsan_env.json
- Private evidence storage: C:\xampp\private\tupsan_data\uploads
- First administrator login instructions:
  C:\xampp\private\TUPSAN_ADMIN_FIRST_LOGIN.txt
- The administrator must replace the temporary password on first login. Delete
  the first-login text file after the new password is safely recorded.
- The application uses the least-privilege tupsan_app database account.
- Evidence files are served only through authenticated, role-aware media.php.
- Login throttling, administrator/staff first-login password changes, secure
  cookies, security headers, private evidence, resident ownership, server-side
  coordinate validation, and suspended-session invalidation were tested
  successfully through local HTTPS.
- The previously exposed AI key is absent from active code. Deactivation in the
  external AI provider account remains a manual account-owner action.
- Pre-Phase 5 code/database/Apache backup:
  C:\xampp\htdocs\tupsan_backups\phase5_before_20260721_203823
- Completed Phase 5 code/database/public Apache configuration backup:
  C:\xampp\htdocs\tupsan_backups\phase5_completed_20260721_210739
- Private credentials and evidence are intentionally excluded from the backup
  under the Apache document root.
- Code/database/checklist only. The manuscript was not edited in Phase 5.


PHASE 6 - DATABASE IMPROVEMENTS
-------------------------------
[x] Create a report_assessments table.
[x] Create a tree_cutting_schedules table.
[x] Create a notifications table.
[x] Create or expand activity/audit logging.
[x] Separate resident-reported severity from staff-verified severity.
[x] Store inspection findings and verified hazard indicators.
[x] Store recommended action and actual action taken.
[x] Store scheduling and completion information.
[x] Categorize evidence as initial, inspection, before, or after evidence.
[x] Add user archive fields instead of destructive deletion.
[x] Replace COUNT(*) + 1 report-code generation.
[x] Use transactions when saving reports, evidence, and status history.
[x] Ensure database indexes support report filters and dashboards.

Phase 6 completion notes:
- Live migration: database\migrations\phase6_database_improvements.sql
- The database now contains 13 tables. New tables are report_code_sequences,
  report_assessments, tree_cutting_schedules, notifications, and activity_logs.
- Resident-reported severity is preserved separately from the optional official
  staff-verified severity. Existing report severity data was migrated safely.
- Existing evidence was categorized as initial evidence and linked to its
  uploader. New evidence records include a lifecycle category.
- Report codes use an atomic yearly sequence. A 12-worker concurrency test
  produced 12 unique sequential codes with no collision.
- Report submission saves its code, report, evidence, status history, and audit
  record in one transaction. Invalid evidence was verified to roll everything
  back without consuming a report number.
- Report workflow updates save the report, status history, audit record, and
  resident notification in one transaction.
- Assessment, recommended-action, scheduling, completion, notification, audit,
  and evidence-category storage are ready for their later user-interface phases.
- Pre-Phase 6 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase6_before_20260721_212630
- Completed Phase 6 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase6_completed_20260721_215555
- Code/database/checklist only. The manuscript was not edited in Phase 6.


PHASE 7 - RESIDENT ACCOUNT MANAGEMENT
-------------------------------------
[x] Validate resident name, email, phone, and address.
[x] Prevent duplicate accounts.
[x] Add a complete privacy and consent notice.
[x] Add resident profile updating.
[x] Prevent suspended users from continuing an existing session.
[x] Finalize a password-recovery procedure for local deployment.

Phase 7 completion notes:
- Live migration: database\migrations\phase7_resident_accounts.sql
- The database now contains 14 tables. The new password_reset_attempts table
  stores only hashed email identifiers and IP addresses for request throttling.
- Self-registration, staff-assisted registration, and resident profile editing
  share server-side validation for full name, email, Philippine mobile number,
  and address. Mobile numbers are normalized to 09XXXXXXXXX.
- New accounts are rejected when either their email or mobile number already
  belongs to an account. A MySQL named lock also prevents concurrent requests
  from creating the same phone number. The database unique email constraint
  remains an additional protection.
- Two pre-existing demonstration residents already share 09123456789. These
  legacy records were preserved because deleting or changing user data was not
  authorized; all new registrations and profile changes are blocked from using
  that existing number.
- Public notice: privacy.php. Registration stores the consent timestamp and
  notice version. Face-to-face staff must attest that the notice was presented
  and that the resident gave consent.
- Resident profile: resident\profile.php. Changes require the current password,
  reject duplicate identity/contact details, invalidate other sessions, and log
  only the names of changed fields rather than personal values.
- Web recovery uses one-hour, single-use tokens, generic anti-enumeration
  responses, request throttling, password-change timestamps, session
  invalidation, and audit logging.
- Offline administrator procedure: tools\security\LOCAL_PASSWORD_RECOVERY.txt
  CLI utility: tools\security\reset_user_password.php
- Repeatable verification: tools\tests\phase7_verification.php (21 checks) and
  tools\tests\run_phase7_http.ps1 (13 HTTPS checks). Both passed with temporary
  users and credentials removed afterward.
- The canonical SQL imported successfully into an empty temporary database and
  produced 14 tables, all Phase 7 columns, and seed settings.
- Pre-Phase 7 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase7_before_20260721_220557
- Completed Phase 7 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase7_completed_20260721_223239
- Code/database/checklist only. The manuscript was not edited in Phase 7.


PHASE 8 - MOBILE REPORT SUBMISSION
----------------------------------
[x] Capture the device GPS location.
[x] Validate latitude and longitude ranges in PHP.
[x] Validate the location against the barangay boundary in PHP.
[x] Display a clear outside-barangay error.
[x] Make captured resident coordinates read-only where required by scope.
[x] Allow authorized staff to correct coordinates after verification.
[x] Require a meaningful title and description.
[x] Record observable hazard indicators.
[x] Require at least one photograph.
[x] Support direct rear-camera capture on mobile devices.
[x] Compress large photographs before upload.
[x] Display upload/submission progress.
[x] Prevent accidental duplicate submissions.
[x] Generate and display a reliable unique report code.

Phase 8 completion notes:
- Live migration: database\migrations\phase8_mobile_report_submission.sql
- The database now contains 15 tables. report_observations stores the hazards
  visible to the resident separately from the official report_assessments table.
- The PHP server validates coordinate ranges and checks every submitted point
  against the same configured polygon displayed by the browser. Outside points
  receive a clear error and no partial report is saved.
- The configured polygon is still provisional_pending_lgu_validation. Phase 8
  enforces it as the current working service boundary, but it must not be called
  the official political boundary until the LGU validates or replaces it.
- GPS/map-captured resident coordinates are read-only in the resident form and
  are preserved permanently as resident_latitude/resident_longitude. Authorized
  staff may correct the operational map point after field verification only
  with a reason; the correction actor, time, reason, old point, and new point
  are audited.
- Report titles require 8-200 characters and at least two words. Descriptions
  require 30-2000 characters and at least five words. Address/landmark,
  nearest-house distance, severity, and at least one visible hazard indicator
  are also validated in PHP.
- At least one genuine image is required. Up to five approved image/video files
  are accepted at 10MB each and 35MB combined. Evidence, observation, report,
  status history, and audit data remain inside one database transaction.
- The mobile form includes an environment-facing camera input. Supported modern
  browsers resize large non-GIF photographs to at most 1920 pixels and encode
  them as JPEG before upload when that reduces file size.
- XMLHttpRequest upload progress shows preparation/upload percentage and clear
  retry messages. The submit button is locked while a request is active.
- Each form receives a random one-time submission token stored in the session
  and a database unique constraint. Repeated or network-retried requests return
  the original report instead of creating a duplicate.
- Repeatable verification: tools\tests\phase8_verification.php (14 checks) and
  tools\tests\run_phase8_http.ps1 (10 local HTTPS workflow checks). All passed,
  and temporary users, reports, evidence, audit entries, files, and test
  databases were removed afterward.
- The canonical SQL imported successfully into an empty temporary database and
  produced all 15 tables, Phase 8 columns, observations, and seed settings.
- Pre-Phase 8 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase8_before_20260721_224052
- Completed Phase 8 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase8_completed_20260721_230115
- Code/database/checklist only. The manuscript was not edited in Phase 8.


PHASE 9 - HAZARD ASSESSMENT
---------------------------
[!] Approve the hazard criteria with the adviser and barangay personnel.
[x] Record distance from the nearest residence.
[x] Record lean direction and structure exposure.
[x] Record dead/broken branches, trunk damage, root damage, and decay.
[x] Record power-line contact or proximity.
[!] Calculate a transparent suggested priority from approved parameters.
[x] Require staff to provide the official verified severity.
[x] Display the basis for the priority result.
[x] Remove AI image analysis from the required system and source code.

PHASE 9 IMPLEMENTATION NOTES (2026-07-22)
- Code implementation is complete in native PHP. The manuscript was not edited.
- The deterministic, non-AI rubric is versioned as draft-2026-07-22-v1 and is
  visibly marked provisional_pending_adviser_barangay_approval.
- Staff must record an inspection date, nearest-residence distance, lean
  direction, and an explicit Yes/No answer for all six field indicators.
- The server calculates and stores a 0-100 suggested priority with an eight-row
  explanation. Draft thresholds are Low 0-24, Medium 25-49, High 50-74, and
  Critical 75-100.
- Authorized staff independently select the official severity. A written reason
  is required when that decision differs from the calculated suggestion.
- Official severity can only be changed through the complete hazard assessment;
  the general status form cannot bypass the assessment requirement.
- Assessment changes write an audit record and local resident notification.
  Staff and residents can view the recorded basis, result, recommendation, and
  any official override reason.
- The schema migration was first restored and tested in an isolated database.
  The live database remains at 15 tables with all 7 Phase 9 columns; original
  data counts remained 4 users, 1 report, and 1 evidence record.
- Automated verification passed: 12 calculation/schema checks and 8 HTTPS
  permission, validation, persistence, audit, notification, and display checks.
- Adviser/barangay approval and any resulting score recalibration remain pending;
  therefore the two approval-dependent checklist items correctly remain [!].
- Pre-Phase 9 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase9_before_20260722_194153
- Completed Phase 9 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase9_completed_20260722_195808


PHASE 10 - STAFF FACE-TO-FACE TRANSACTION
-----------------------------------------
[x] Search for an existing resident by email or phone.
[x] Reuse an existing resident account when found.
[x] Register a new resident when no matching account exists.
[x] Allow staff to capture a report on the resident's behalf.
[x] Capture GPS and evidence during the staff transaction.
[x] Link the report to both the resident and registering staff member.
[x] Provide the resident with the generated report code.

PHASE 10 IMPLEMENTATION NOTES (2026-07-22)
- Code implementation is complete in native PHP. The manuscript was not edited.
- Staff use one three-step transaction screen: exact resident lookup, report
  capture, and report-code handoff. Name-based resident browsing is disabled.
- Exact email and normalized Philippine mobile searches reuse an active resident
  account. A new account can be registered only through the no-match branch.
- New face-to-face accounts require recorded privacy consent, retain the
  assisting staff attribution, and force the resident to change the temporary
  password after first sign-in.
- The staff report form reuses the server-enforced GPS range, provisional
  barangay boundary, required photograph, approved evidence types, file limits,
  observable hazard fields, locked coordinates, and duplicate-token controls.
- Reports separately store the resident owner, the user who entered the report,
  and the resident_web/staff_ftf submission channel. All Phase 1-9 reports were
  safely backfilled as resident web submissions.
- A staff-assisted report writes its initial status log, privacy-safe activity
  audit, evidence uploader, and local resident notification in one transaction.
- The completed screen prominently shows the generated TUP-YYYY-NNNNN report
  code and provides a printable receipt for the resident.
- Automated verification passed: 9 schema/attribution checks, 12 HTTPS Phase 10
  permission and workflow checks, and 78 earlier regression checks. All 46 PHP
  files passed syntax validation.
- The live database remains at 15 tables. Original data counts remained 4 users,
  1 report, and 1 evidence record after all temporary fixtures were removed.
- Pre-Phase 10 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase10_before_20260722_200311
- Completed Phase 10 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase10_completed_20260722_201947


PHASE 11 - REPORT MANAGEMENT WORKFLOW
-------------------------------------
[x] Enforce: Submitted -> Pending -> Verified -> In Progress -> Resolved.
[x] Allow Rejected only through a valid review path.
[x] Restrict staff assignment to authorized users.
[x] Restrict updates to assigned staff and administrators.
[x] Require inspection findings before verification.
[x] Require a rejection reason.
[x] Require assigned staff before In Progress.
[x] Require action taken, completion date, and after evidence to resolve.
[x] Reject invalid status transitions in PHP.
[x] Record every important change in the audit history.

PHASE 11 IMPLEMENTATION NOTES (2026-07-22)
- Code implementation and hardening are complete in native PHP. The manuscript
  was not edited.
- The enforced workflow is Submitted -> Pending -> Verified -> In Progress ->
  Resolved. Rejected is available only after Pending review; Resolved and
  Rejected are terminal states.
- Verification requires a completed Phase 9 hazard assessment with official
  severity and inspection findings. In Progress requires an active assigned
  staff member.
- Resolution requires meaningful action-taken notes, a valid completion date,
  and at least one approved photograph in the after_action evidence stage.
- Rejection requires a meaningful resident-visible reason. Invalid skipped,
  backward, terminal, and unauthorized transitions are rejected in PHP and
  rechecked inside a database transaction with row locking.
- Assignment/notes changes are audited. In-progress assignments cannot be
  changed, terminal workflow details cannot be edited, and assessments cannot
  be changed after verification or closure.
- Every valid transition writes a status log, privacy-safe activity audit, and
  local resident notification. Residents see completion date, completed staff,
  action taken, and after-action evidence in the report view.
- Automated verification passed: 11 schema/rule checks, 11 HTTPS lifecycle
  checks, and 78 earlier regression checks. Temporary fixture users, reports,
  uploads, and databases were removed.
- Pre-Phase 11 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase11_before_20260722_203700
- Completed Phase 11 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase11_completed_20260722_204439


PHASE 12 - TREE CUTTING/TRIMMING SCHEDULE
----------------------------------------
[x] Create a schedule for an approved/verified report.
[x] Record date, time, personnel, planned action, and remarks.
[x] Show upcoming schedules on staff and administrator dashboards.
[x] Track scheduled, postponed, completed, and cancelled states.
[x] Connect schedule completion to report resolution.

- Native-PHP schedule management is available from the staff/admin sidebar and
  dashboard. Staff can manage schedules only for their assigned reports;
  administrators can manage all authorized schedules.
- Completion requires the linked report to be In Progress, meaningful actual
  action details, and after-action photo/video evidence. Completion marks the
  schedule completed and the linked report resolved in one transaction with
  report history, audit records, notifications, and completion metadata.
- Postponed work must be rescheduled before completion. Completed and cancelled
  schedules are terminal. Direct report resolution automatically closes any
  remaining active schedule for that report.
- Automated verification passed: 11 schema/rule checks, 10 HTTPS lifecycle
  checks, 121 earlier Phase 7-11 regression checks, and 52 PHP syntax checks.
  Temporary fixture users, reports, uploads, and databases were removed.
- Pre-Phase 12 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase12_before_20260722_210247
- Completed Phase 12 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase12_completed_20260722_212030


PHASE 13 - INTERACTIVE HAZARD MAP
---------------------------------
[x] Replace the fixed map iframe with an interactive report map.
[x] Draw the configured barangay boundary.
[x] Plot report markers using severity colors.
[x] Add marker clustering.
[x] Add status and severity filters.
[x] Add a legend and report-summary popups.
[x] Add satellite and street map layers.
[x] Anonymize resident information in resident/public map views.
[x] Correct broken dashboard/back links.

- `maps_3d.php` now uses Leaflet with clustered markers, severity-colored
  icons, status/severity filters, report popups, a filtered result list, and
  street/satellite/hybrid layers through the authenticated local tile proxy.
- Resident map requests are restricted to the signed-in resident's own
  non-rejected reports and use generic marker titles/location labels. Staff
  and administrators see operational report markers without resident identity
  fields. The map back link now targets the actual role dashboard route.
- The displayed boundary is the configured working polygon and remains marked
  provisional pending LGU validation; it is not described as an official
  political boundary.
- The boundary geometry now follows the detailed PSA/GeoRisk feature for
  barangay PSGC code 101803014, matching the Tupsan Pequeño shape used for
  map checking. It remains provisional until the Mahinog/Tupsan Pequeño LGU
  validates it.
- Boundary source layer: https://ulap-nga.georisk.gov.ph/arcgis/rest/services/PSA/BarangayPopMF/MapServer/0
- Automated verification passed: 11 map/configuration checks, 4 HTTPS map,
  privacy, tile-proxy, and navigation checks, 142 earlier Phase 7-12
  regression checks, and 54 PHP syntax checks. Temporary fixture users,
  reports, uploads, and databases were removed.
- Pre-Phase 13 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase12_completed_20260722_212030
- Completed Phase 13 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase13_completed_20260722_220806


PHASE 14 - LOCAL NOTIFICATIONS
------------------------------
[x] Notify staff/admin when a new report is submitted.
[x] Escalate critical reports.
[x] Notify staff when assigned.
[x] Notify residents when reports are verified or rejected.
[x] Notify residents when a schedule is created or changed.
[x] Notify residents when reports are resolved.
[x] Provide read/unread notification status.
[x] Keep email optional and SMS outside the required scope.

- `notifications.php` provides a recipient-scoped native-PHP notification
  center with All/Unread filters, individual Mark as Read controls, and a
  CSRF-protected Mark All as Read action. Resident, staff, and administrator
  headers/sidebar navigation show the unread badge.
- Resident and face-to-face submissions notify active staff/administrators;
  Critical submissions also create a critical escalation. Assignment changes
  notify the assigned staff member. Existing report status and schedule hooks
  notify residents for verification, rejection, scheduling, postponement,
  cancellation, completion, and resolution. Email remains optional and SMS is
  outside the required local scope.
- Automated verification passed: 9 notification schema/event checks, 4 HTTPS
  notification-center checks, 157 earlier Phase 7-13 regression checks, and
  57 PHP syntax checks. Temporary fixture users, reports, uploads, and
  databases were removed.
- Pre-Phase 14 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase14_before_20260722_221200
- Completed Phase 14 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase14_completed_20260722_222938


PHASE 15 - MONITORING, ANALYTICS, AND EXPORTS
---------------------------------------------
[x] Show reports by status, severity, date, and location.
[x] Show pending prioritization lists.
[x] Show schedules and staff assignments.
[x] Calculate verification and resolution times.
[x] Add search and date-range filters.
[x] Add printable individual report details.
[x] Add printable monthly summaries.
[x] Add CSV export.
[ ] Add PDF export if required and time permits.

- `admin/analytics.php` provides role-aware monitoring for report status,
  severity, date range, location, prioritization, schedules, staff assignment,
  processing times, monthly volume, and CSV export. Staff analytics and exports
  are limited to reports assigned to the signed-in staff member; administrators
  can view the system-wide data.
- `admin/print_report.php` provides printable individual report details and
  `admin/print_summary.php` provides a printable monthly monitoring summary.
  Both can be saved as PDF through the browser's local print dialog, so a
  server-side PDF library is not required for this native-PHP build.
- Automated verification passed: 9 analytics query/export checks, 5 HTTPS
  analytics and print checks, 170 earlier Phase 7-14 regression checks, and
  63 PHP syntax checks. Temporary fixture users, reports, uploads, and
  databases were removed.
- Pre-Phase 15 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase15_before_20260722_224139
- Completed Phase 15 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase15_completed_20260722_225444


PHASE 16 - FUNCTIONAL AND SECURITY TESTING
------------------------------------------
[x] Test registration, login, logout, and password recovery.
[x] Test resident, staff, and administrator permissions.
[x] Test suspended account behavior.
[x] Test required GPS and barangay boundary validation.
[x] Test required photograph and invalid uploads.
[x] Test report ownership and personal-data protection.
[x] Test face-to-face registration and report submission.
[x] Test assignment, assessment, scheduling, rejection, and resolution.
[x] Test notifications, maps, searches, filters, and exports.
[x] Test mobile layout and slow-network behavior.
[x] Test database backup and restoration.
[x] Record expected result, actual result, and pass/fail for every test.

- Repeatable matrix: `tools/tests/PHASE16_TEST_MATRIX.txt` records expected
  result, actual result, pass/fail, and evidence for every Phase 16 area.
- Targeted Phase 16 verification passed: 9 CLI security/source checks and 5
  HTTPS role/mobile checks. The full Phase 7-16 regression passed with 198
  functional checks (184 earlier checks plus 14 Phase 16 checks) and 65 PHP
  syntax checks. Temporary resident, staff, administrator, report, upload,
  and database fixtures were removed.
- PHP application dates are explicitly aligned to the local XAMPP/MariaDB
  timezone (`Asia/Shanghai`) so inspection-date and workflow validation use
  one local calendar date.
- Pre-Phase 16 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase16_before_20260722_232918
- Completed Phase 16 project/database backup:
  C:\xampp\htdocs\tupsan_backups\phase16_completed_20260722_234045
- Completed Phase 16 boundary/timezone correction backup:
  C:\xampp\htdocs\tupsan_backups\phase16_boundary_fix_completed_20260723_000918


PHASE 17 - SYSTEM EVALUATION
----------------------------
[ ] Replace judge/event-organizer respondents with correct participants.
[ ] Select resident, staff, administrator, and technical evaluators.
[!] Verify the exact ISO references and selected criteria with the adviser.
[ ] Use one consistent four-point Likert scale and interpretation.
[ ] Correct the rubric whose maximum currently exceeds 4.00.
[ ] Ensure questionnaire items only evaluate implemented functionality.
[ ] Have the evaluation instrument validated by the required validators.
[ ] Conduct User Acceptance Testing.
[ ] Compute and document weighted-mean results correctly.


PHASE 18 - DOCUMENTATION AND USER MANUALS
-----------------------------------------
[ ] Prepare the resident user manual.
[ ] Prepare the staff user manual.
[ ] Prepare the administrator user manual.
[ ] Update screenshots using the completed application.
[ ] Update the database dictionary.
[ ] Update ERD, DFD, use cases, architecture, and flowcharts.
[ ] Correct unrelated project wording and typographical errors.
[ ] Document local installation, backup, restore, and troubleshooting.
[ ] Document limitations and future enhancements honestly.


PHASE 19 - CAPSTONE DEFENSE PREPARATION
---------------------------------------
[ ] Create resident, staff, and administrator demonstration accounts.
[ ] Prepare reports for every severity and status.
[ ] Prepare an assigned, rejected, scheduled, and resolved report.
[ ] Include before-and-after evidence for the resolved demonstration.
[ ] Rehearse the complete resident-to-resolution workflow.
[ ] Rehearse analytics and printable report generation.
[ ] Prepare an offline/local-network contingency plan.
[ ] Create a final timestamped project and database backup.
[ ] Verify the demonstration on the actual computer and mobile phone.


PHASE 20 - REQUESTED SYSTEM REFRESH (SEPTEMBER 2026)
----------------------------------------------------
[x] Apply the supplied light eco color palette across the public, resident,
    staff, and administrator interfaces.
[x] Use the supplied barangay seal and barangay hall photograph as the default
    logo and landing-page background.
[x] Make the barangay identity, map center, service boundary, branding assets,
    and default resident language configurable by an administrator.
[x] Keep one configured barangay identity per local installation.
[x] Add English/Bisaya resident interfaces, with Bisaya as the configurable
    default, across registration, sign-in/recovery, dashboards, reporting,
    tracking, notifications, map, profile, password, and privacy flows.
[x] Keep resident registration free of government-ID requirements.
[x] Add a separate public staff application with date of birth, residential
    address, emergency contact, government-ID type, and ID image.
[x] Keep every new staff application Pending until an administrator reviews
    the privately stored identity document and explicitly approves it.
[x] Disable direct administrator creation/approval paths that could bypass the
    verified-ID application; rejected/pending applications cannot be restored
    into active staff access.
[x] Re-encode staff ID images as JPEG, store them outside the public website,
    record a SHA-256 integrity hash, and serve them only through an
    administrator-authorized endpoint.
[x] Require at least one photograph for every initial report while keeping
    video optional.
[x] Limit optional videos to 30 seconds in both the browser and server.
[x] Add a visible barangay, local date/time, GPS-coordinate, and address/
    landmark footer to photographs taken through the report camera control.
[x] Add evidence previews, image preparation/compression, upload percentage,
    byte count, speed, time remaining, slow-connection notice, and safe retry.
[x] Hard-block more than one active work schedule for the same report.
[x] Hard-block overlapping active work assigned to the same staff member.
[x] Warn about other active work on the selected calendar day.
[x] Add same-day staff work notices without claiming background push delivery.
[x] Add live local date/time and current-month operational work calendars to
    administrator and staff dashboards.
[x] Keep attendance and clock-in/clock-out outside the system scope.
[x] Add accessible password show/hide controls to sign-in and password forms.
[x] Install the branding/localization settings and staff-verification database
    migrations; the live database now contains the required 17 tables.
[x] Preserve a pre-change project/database backup at:
    C:\xampp\htdocs\tupsan_backups\phase20_before_20260907_202742
[x] Pass the Phase 20 database/source/parser suite (27 checks).
[x] Pass the Phase 20 HTTPS staff application and approval flow (5 checks),
    including cleanup of temporary users and private test ID files.
[x] Pass all Phase 7-16 CLI regressions and HTTPS workflow regressions after
    making the old English-copy assertions locale-explicit.
[!] Test the stamped camera-photo flow and responsive layout on the actual
    Android/iPhone devices that will be used during evaluation.
[!] Obtain LGU validation of the provisional service-boundary polygon before
    describing it as an official political boundary.


RECOMMENDED DEMONSTRATION FLOW
------------------------------
[ ] Resident captures GPS and submits a report with evidence.
[ ] Administrator reviews the report and assigns staff.
[ ] Staff conducts and records the verification.
[ ] Administrator/staff creates a cutting or trimming schedule.
[ ] Staff records the completed action and uploads after evidence.
[ ] Resident receives updates and views the status timeline.
[ ] Administrator generates the monitoring report.


NOTES
-----
- Make a new timestamped local backup before every database migration.
- Do not store production passwords or API credentials in documentation.
- Do not claim a feature in the manuscript unless it works in the final build.
- Do not change the approved title without formal adviser approval.
