# Round 2 checkpoint — Task 3: thesis/system alignment

Date: 2026-09-27

## Documents reviewed

- Latest accessible thesis by modification time: `C:\Users\Asus\Downloads\256 EDIT FINAL FINAL.docx` (modified 20 Sep 2026; 795 paragraphs, 19 tables). Reviewed relevant scope, process, database, GUI, test-result and conclusion sections. No Word file was changed.
- `docs/DEFENSE_GUIDE.md` (read in full). Its Matching V2 formula, 24-hour waiting, consent-based alternative, poll-vs-agency-voting distinction, privacy, and no-escrow notes mostly match current source. Suggested additions: exact voting/poll close rules, current DB tables, and precise limits on live test evidence.

## Comparison matrix

| Thesis section / claim | Current implementation | Suggested correction | Priority |
|---|---|---|---|
| §1.3.1.2, Fig. 3.30: user searches/reviews suggested groups and manually requests to join | Preference submission creates a waiting record; server-side deterministic Matching V2 auto-assigns when a compatible cluster reaches minimum size 3. Country is a hard constraint; score threshold is 70 with Interests/Budget/Period 40/30/30 and a 20% budget-difference gate. | Replace search → choose group → manual join as the primary flow with preference → waiting → automatic assignment. Keep browse/search only as a separate discovery action if it remains in the project scope. | HIGH |
| No persistent matching countdown/alternative timing is described | Matching waiting deadline is server-owned/persisted, default 24 hours and environment-configurable. Alternative recommendations appear only after the waiting deadline; user consent changes current destination while preserving original destination. | Add waiting start/deadline, reload continuity, timeout state, and explicit accept/continue-waiting branches to workflow and tests. | HIGH |
| §1.3.1.3 says generic Group Poll | Destination Poll is a post-match planning flow distinct from agency voting: Region/City first; Place/Activity opens only for the group’s finalized city. Current catalog lookup prefers poll catalog, then legacy `tour_groups`; city-specific options retain their source city and package image. | Name the two poll stages and distinguish them from Agency Bid Voting in process text, DFD, GUI, and table schema. | HIGH |
| Poll close/tie behavior is unspecified | City round closes when all active members vote, or after 24 hours only when participation is a strict majority; otherwise waits without a winner. City ties preserve round history and open a tie-only round. Place poll uses the same participation gate and returns ranked aggregate counts. | Add quorum, waiting, tie-round, and city-gates-place rules. Show results as provisional until final. | HIGH |
| Agency lead/bidding descriptions do not state vote privacy | Approved Agency sees permitted group detail and aggregate Poll interest only, not member-level poll choices. Backend applies winner/ownership rules; completed/dissolved-group bids are history-only based on group lifecycle. | Update Agency data-flow/privacy text to describe aggregate-only polls and remove any implication of access to individual choices or unrestricted chat history. | HIGH |
| §3 process 4.3–4.4: aggregate votes and declare winner at end of period without deterministic tie rule | Agency voting lifecycle is open → closed → finalized; each member has one vote and can change it before deadline. Highest count wins; ties use lower price, earlier submission, then bid id. Finalize is idempotent; Payment accepts only the finalized winning bid. | State the eligibility, deadline, winner/tie ordering, finalization, and winner-only payment reference. Keep this distinct from Destination Poll rules. | HIGH |
| §1.3.1.3/§3 process 5.2: central escrow and successful transfer after slip verification | No escrow. Payment uses the development verifier only in development/test; production needs a configured real verifier. Slip checks expected amount/receiver/reference/date/duplicate and records pending/waiting/paid/failure status. No real provider was called in this round. | Remove claims of escrow/custody or real bank verification. Describe development verification as a demo/testing path and real-provider integration as future work. | HIGH |
| §1.3.1.1 claims SMS OTP; §1.3.4.1.2 claims Dwell Time/Feed Algorithm | Current auth uses established app authentication, not SMS OTP. Matching uses explicit travel preferences and deterministic rules; it does not use dwell-time/feed behavior. | Remove SMS OTP and Dwell Time/Feed Algorithm from implemented scope; if academically useful, label only as future work, not current functionality. | HIGH |
| §3.2.2 and §4.1 ER diagrams describe seven entities; data dictionary is limited to User/Preference/Group/Agency/Package/Bid/Payment | Current system also relies on `group_members`, poll/options/votes/rounds, voting rounds/votes, notification, travel-document, journey/meeting, trip-review and verification records. | Refresh logical/physical ERD and data dictionary to match the schema actually used; include only deployed/current tables and label optional/future entities accurately. | HIGH |
| Figs. 3.30–3.34 and Chapter 4 screenshots/tests show earlier group-join and generic payment flow; Chapter 4 tables 4.1–4.4 cover only selected screens | Current UI includes waiting/matched states, Poll entry/results, voting status/deadline, winner-only Payment, development slip status, Journey and post-trip review. Current-round emulator tests used mocked HTTP; they were not live database E2E. | Replace outdated screenshots and update test table with reproducible setup, fixture-vs-live distinction, expected/actual results and limitations. Do not claim a continuous live E2E unless later completed. | MEDIUM/HIGH |
| §5.1/§5.2 summarize successful search, join, bidding, payment and review | The summary is directionally true for parts of the system but conflates manual join with current automatic matching and could imply real payment. This round did not establish a new continuous live E2E. | Rewrite summary after clarifying automatic lifecycle and demo payment scope; qualify test coverage and avoid claiming unverified live end-to-end results. | HIGH |

## Figures, tables and screenshots to update later

- Replace Fig. 3.30 (Matched Groups/manual join) with the current matching waiting/countdown and automatic matched-state screens.
- Update Fig. 3.31 (Group Details & Chat) to show the Destination Poll entry/aggregate; add separate Region/City and city-bound Place/Activity result screens.
- Update Fig. 3.33 to show Agency voting deadline, current aggregate, closed/finalized status and deterministic winner; distinguish it visually from Destination Poll.
- Update Fig. 3.34 and process/table 5.2 to label development slip verification and its status states; do not depict escrow or a real provider as operational.
- Review Fig. 3.32 Agency Bidding for current lead detail and privacy boundaries. Add an Admin approval/status screen if Admin approval is described as a core flow.
- Replace Figs. 3.8 and 4.1 ER diagrams; update data dictionary tables 3.1–3.7 and process tables 3.7–3.23 for the current deployed schema and poll/voting distinction.
- Extend Chapter 4 black-box tables beyond login/group join/chat/rating to include automatic matching/wait timeout, both Poll stages and tie/waiting, Agency aggregate privacy/bid, vote/finalize tie, winner-only payment/demo slip, and post-trip rating. Explicitly mark fixture, emulator, and live-backend evidence separately.

## Suggested Chapter 4 screenshot shortlist

1. Matching waiting countdown and automatic group assignment — demonstrates Matching V2, not user-selected group joining.
2. Group chat with Poll entry and city Poll results — shows post-match planning and aggregate progress.
3. Finalized city with only its own Place/Activity choices and ranked aggregate — proves the two-stage dependency.
4. Agency lead detail with aggregate interests and anonymized group information — documents Agency privacy boundary.
5. Agency bid list/detail with active versus completed/dissolved history — shows server-derived effective status.
6. Agency voting page showing deadline and final winner, followed by the winning-bid Payment screen — demonstrates separate vote lifecycle and winner gate.
7. Slip verification progress/result marked as development/demo — prevents implying live bank integration.
8. Completed-trip review form and saved rating — documents rating after trip completion.
9. Admin Agency approval/status page, if the final report retains Admin Portal as project scope.

Screenshots should be recaptured from the current UI only; no mock screenshots were created in this audit.

## Checkpoint result

- Thesis/source comparison complete; Word not edited.
- `DEFENSE_GUIDE.md` is substantially more current than the thesis for Matching V2 and Poll concepts, but should be aligned with exact poll/voting thresholds and clearly labeled evidence limitations.
- No source code, database, business data, or recovery files were changed in this task.