# TourApp Final QA — 2026-09-27

Status: **PARTIAL — available non-destructive verification completed; Full Live E2E BLOCKED**. This report separates fixture assertions, emulator fixture rendering, live HTTP, Browser UI, and read-only MariaDB evidence. No full live E2E claim is made. No functional runtime failure was reproduced in the exercised flows; security findings and untested paths remain below.

Follow-up checkpoint dated 2026-09-28 is appended at the end. It supersedes the earlier service-availability statement: on the follow-up check MariaDB, Backend, and Portal were not running. Earlier test results and DB snapshot evidence retain their original 2026-09-27 scope.

Launcher recheck dated 2026-09-28 is also appended below. It supersedes the stopped-service status after the validated launcher was run.

## Flutter checkpoint

- `flutter analyze`: PASS, no issues (15.9 seconds).
- `flutter test --machine`: PASS, **177 actual tests passed, 1 skipped**. The 44 hidden runner/loading events are not counted as tests.
- The skipped test is the opt-in real Destination Poll database vote test. Its test database variable was explicitly blanked for this run; it did not connect/write to the main database.
- `flutter test integration_test -d emulator-5554 --machine`: PASS, **4 tests**, 236.7 seconds. Agency rating/privacy, Matching navigation, Japan Region/City → Place/Activity, and Trip Rating/keyboard all passed on the real emulator. Services are in-memory/MockClient: **not live API E2E**.
- Evidence: `final_qa_20260927_flutter_analysis.txt`, `final_qa_20260927_flutter_tests.jsonl`, `final_qa_20260927_flutter_tests.stderr.txt`.

## Backend checkpoint

- `dart analyze server`: PASS, no issues.
- **86 Backend tests** are included in the 177-test run; they are not additional tests to add to that total. Some are source/migration string-contract checks, not database execution.
- Existing read-only SQL consistency audit: current lifecycle inconsistencies **0**, accepted legacy payment exceptions **1**, accepted completed-trip bid recycle **1**.
- A read-only connection using the exact local MariaDB access already used by `start_tourapp.bat` succeeded on port 3306. `information_schema.USER_PRIVILEGES` confirms local administration can CREATE/CREATE USER/grant. The earlier checkpoint's claim that no SQL administration channel is available is superseded. No credentials were guessed and no privilege/database was created in this QA run.
- No isolated `tourapp*test*` or `tourapp*demo*` schema was returned by the read-only schema-name query. Write-based live E2E remains BLOCKED until an isolated fixture database is prepared; QA continues on other sections.
- Evidence: `final_qa_20260927_backend_analysis.txt`, `final_qa_20260927_db_consistency.txt`.

## Portal checkpoint

- `npm.cmd run lint`: PASS, exit 0.
- `npm.cmd run typecheck`: PASS, exit 0.
- `npm.cmd run build`: PASS, exit 0, Vite 7.3.6, 59 modules, JS 351.36 kB (gzip 101.43 kB), CSS 18.12 kB.
- No Portal unit/browser test script is defined in package.json. Build success does not establish authenticated UI behavior.
- Browser public Agency login/register and Admin login rendered. At width 390 the measured document width was 375 (no horizontal document overflow); desktop Admin at 1440 had scrollWidth=1440. Agency `/agency/bids` redirects to Agency login and `/admin/users` to Admin login without sessions. No warning/error console entries were returned. Authenticated pages remain unverified.
- One browser automation click failed to resolve a DOM node; direct navigation to the observed registration URL worked. This is a tooling limitation, not a reproduced application defect.
- Evidence: `final_qa_20260927_portal_lint.txt`, `final_qa_20260927_portal_typecheck.txt`, `final_qa_20260927_portal_build.txt`.

## Integration checkpoint

Live unauthenticated HTTP: **20/20 protected JSON read endpoints returned 401**, covering group/chat/matching/poll/offers/rating/notifications/documents/payment/journey/trip-hub/Agency/Admin. **5/5 private document endpoints returned 401**; an invalid Agency session returned 401; one encoded traversal request returned 404. No session was fabricated or user login guessed.

Portal Vite `/api/health` proxy returned HTTP 200. MariaDB process count is one, PID 23208, executable `C:\xampp\mysql\bin\mysqld.exe`; main Backend/Portal remain running. Emulator was online; ADB reverse mapping was missing and was restored using the existing launcher's `adb reverse tcp:8787 tcp:8787` operation. Full launcher was not executed because its Backend bootstrap can seed accounts if it starts a new process. Static duplicate-process guards and the read-only readiness query were inspected instead.

Main Flutter app was rebuilt/restored with `flutter run -d emulator-5554 --no-resident --no-pub` (exit 0) after the integration harness installation. Actual Windows emulator UI was inspected: Guest Home → AI preference form → scrolling structured controls → back to Home worked, with no visible overflow in the inspected screens. No preference/login was submitted. The app is left on Guest Home. This manual UI check is separate from the four emulator fixture tests.

Main MariaDB/Backend/Portal were not restarted. Gemini success from `round1_poll_auth_gemini_checkpoint_20260927.md` is reused without a new external call. No payment provider was called.

## Feature acceptance matrix

PASS applies only to the evidence stated in its row; PARTIAL means automated/limited checks passed while authenticated/live behavior is still unverified.

| Feature | Result | Evidence and practical limit |
| --- | --- | --- |
| Guest Home / AI entry / back navigation | PASS | Actual restored Flutter app on emulator; manually opened shared preference form, scrolled, returned Home. Only inspected screens are covered. |
| Member register/login / access | PARTIAL | Login widget suite 4 tests; guest/member widgets in full suite; live unauthenticated guards 401. Valid live member login, registration persistence, Google/Apple sign-in not exercised. |
| Gemini interest extraction | PASS (prior live evidence) | Round 1 authorized `/api/analyze` HTTP 200; no external request repeated. Current AI/local-parser tests pass. This is not an availability guarantee at demonstration time. |
| Matching V2 / waiting / alternatives | PARTIAL | Engine 13, matching API 4, waiting policy 3, waiting view 5 tests; emulator mock matching navigation 1. No current isolated DB assignment/concurrency test. |
| Group membership / Chat | PARTIAL | Group service 8 and relevant widget tests; actual unauthenticated state/messages 401; membership/count DB checks zero. No live member chat send/receive this run. |
| Destination Poll lifecycle | PARTIAL | Policy 14; contract/catalog/migration tests; Japan emulator city→place→summary fixture. Real vote persistence test skipped; no real votes sent. |
| Poll aggregate/privacy/chat refresh | PARTIAL | Entry widget suite 12 includes return-refresh; Agency privacy source-contract test; async lead repository 2. Authenticated Agency response/UI still unverified. |
| Poll images | PARTIAL | All eight China local image/attribution checks pass; Japan fixture uses package assets and renders on emulator. Not an exhaustive live visual audit of every country/catalog row. |
| Agency profile average/count/empty/privacy | PARTIAL | Page 3 tests, source contract 2, emulator fixture 1; read-only live eligible agency_rating aggregate: agency 3 = 4.0 / 1 review, agency 27 = 5.0 / 2 reviews. No authenticated API/UI comparison with these live values. Comments not published. |
| Multi-agency bids / ownership | PARTIAL | Agency/Admin API suite 15 uses fake repository/private file store. No new bids or real multi-company session flow. |
| Agency Voting / finalize / tie | PARTIAL | Policy 13: 1/3 and 2/3 stay open, 3/3/deadline close, highest votes, price/time/id tie, repeated finalize, winning-only payment. Unit policy tests do not prove SQL races/transactions. |
| Demo payment / slip | PARTIAL | Verifier 5, migration 1, winning-bid policy coverage. Wrong amount/receiver/reference/date/provider failure covered in fixtures. No live slip upload, duplicate-payment concurrency, or real provider call. |
| Notifications | PARTIAL | Service 3, widget 1, migration 1; unauthenticated API 401, DB owner/dedupe counts zero. Actual event production/reminder timing not tested live. |
| Travel Documents | PARTIAL | Upload 3, service 2, widget 1, migration 1; private unauthorized HTTP 401; supplemental DB owner/winner checks zero. Winning/non-winning/suspended Agency passport access and safe replacement need isolated live tests. |
| Trip Hub | PARTIAL | Service 1, migration 1, protected HTTP 401. Live payment/document readiness and acknowledgements not written. |
| Journey / completion | PARTIAL | Migration and lifecycle-related checks, protected HTTP 401, existing DB winner consistency zero. No trip status transition executed. |
| Trip Rating | PARTIAL | Full widget suite plus emulator rating/IME/layout fixture; no real review sent and no review changed. |
| Agency registration/approval/login | PARTIAL | Fake repository auth/approval tests; actual public Browser forms; no successful live Agency login or license upload this run. |
| Marketplace / lead detail / aggregate | PARTIAL | Await/connection regression 2; privacy contract 1; protected live API 401. Protected Browser `/agency/leads/115` not authenticated. |
| My Bids current/history (#39/#102) | PARTIAL | Real read-only DB state confirmed; repository effective lifecycle regression passes. Actual Agency list/history UI needs authorized session. |
| Agency travelers / Journey pages | BLOCKED (authenticated UI) | No authorized Agency session used. API denies anonymous requests; fixture/source checks cannot replace actual protected-page review. |
| Admin management / roles | PARTIAL | API fixture and reset/migration contracts pass; Browser `/admin/users` redirects to login; live Admin reads deny anonymous users. No successful live Admin session. |
| Portal responsive/public states | PASS (limited pages) | Agency login/register, Admin login at 390px; desktop Admin 1440px, no measured horizontal document overflow; no console warnings/errors. Private-page responsive/empty/error states remain untested. |
| Backend static quality | PASS | `dart analyze server` no issues; 86 backend tests within full suite. |
| Flutter static/unit/widget quality | PASS | `flutter analyze` no issues; 177 passed, 1 isolated DB test skipped. |
| Portal lint/typecheck/production build | PASS | All three npm scripts exit 0. No browser/unit test runner defined in package.json. |
| API unauthenticated/private guards | PASS (limited) | 20 JSON reads + 5 private GETs + 1 invalid-session request return 401; one encoded traversal returns 404. Does not prove every authenticated cross-role case. |
| DB consistency/schema compatibility | PASS (read-only checks) | 33 tables all InnoDB; both waiting timestamp columns exist; existing audit current issues=0; NULL-safe supplemental document owner/winner issues=0. No physical storage recovery/check performed. |
| Credential hygiene / local DB privilege | FAIL (security finding) | Legacy SQL has literal DB credentials; local root connection accepts the launcher's no-password invocation with broad grants. Details below, values omitted. |
| Launcher/connectivity | PARTIAL | One mysqld, expected binary; guard source reviewed; launcher DB readiness query channel works; Portal proxy 200; ADB reverse restored. Full double-click/duplicate-launch cycle not executed. |
| Complete Matching→Poll→Bids→Voting→Payment→Completion→Rating | BLOCKED (Full Live E2E) | Isolated DB/harness config absent. No write-based business operation was run on the main database. |

## Read-only live data findings

- Public `POST /api/groups` returned HTTP 200 with 77 groups. A narrow field-name check found no password_hash/passport_number/passportNumber/authToken/token keys; this is not a general PII audit.
- Bid **39**, group **102**: raw bid `submitted`, group `open`, members 0, meeting `completed`, no journey row. Existing effective-status test maps this case to `trip_completed` and inactive/history. No cancellation or history update was attempted.
- Bid **49**, group **115**: raw bid `selected`, group `confirmed`, members 2, meeting `completed`, no journey row. These are the state observed in this run; the older assumption that this bid must remain active is no longer applicable. No member/status/vote was changed to accommodate a test.
- Legacy `pay_id=2` is retained as the accepted exception. Current paid automatic-group payments pass the audit's finalized-winner check.
- Agency rating read-only query used `agency_rating`, joined review bid/group/package/agency and required the same user's paid payment plus completed meeting. It did not query or display customer comments, names, emails, or phone numbers.
- One supplementary query initially used `j.status` instead of the actual `journey_status` column and returned SQL 1054. The QA query was corrected after inspecting the column metadata. This was a diagnostic-query mistake, not an application SQL failure; the repository already uses `j.journey_status`.

## Confirmed findings, environment issues, and coverage gaps

### High — credential material embedded in legacy setup SQL

`database/travelin_trip_data.sql` has four literal `IDENTIFIED BY` declarations (lines 5, 7, 12, 14). Reproduce safely by checking only whether those declarations exist; do not print their values. This creates exposure risk if the setup source is distributed and reused. A narrow built-Portal scan found zero Google-key-shaped strings, but no claim of an exhaustive secret scan is made.

Not changed: safely resolving existing credentials requires coordinated account/configuration rotation, which is excluded by this QA request. Do not include this SQL or credential files in thesis screenshots or public source delivery without a separate credential-cleanup review.

### High for deployment — privileged local database access without a supplied password

The exact local client invocation used by `start_tourapp.bat` successfully authenticated as root@localhost over TCP 3306 without a supplied password (`--no-defaults` was used for the QA probe). Read-only metadata confirms CREATE USER and grantable broad privileges. MariaDB listens on `::`; firewall/external reachability was not tested. Reproduce with the existing launcher's read-only SELECT readiness operation. No password guess or privilege change was performed.

This does not establish that the database is reachable from another machine. It does mean this environment has not passed production/network security hardening. Keep the demonstration local; authentication/binding hardening should be coordinated separately rather than changing the recovered server here.

### Medium — audit SQL has NULL-sensitive document checks

The existing document ownership predicate uses `<>` against LEFT JOIN nullable fields; missing rows can yield SQL UNKNOWN and avoid being counted. Supplemental read-only checks explicitly tested missing finalized rounds/users and NULL-safe winner mismatch and found **0** current issues. The audit script was left unchanged because membership/history exception semantics require a deliberate review; no business data was repaired. This is a test/audit coverage gap, not proof of corrupt data.

### Readiness limitation — health is configuration-only

`/api/health` currently writes `databaseConfigured: true` without querying the database in that request. Therefore the health response alone is not evidence of a live DB connection; this run separately proved it with read-only SQL and the public groups API. A database-outage scenario was not reproduced because stopping MariaDB was excluded. Do not call this an observed outage bug.

### Environment issue resolved

Emulator was online but had no ADB reverse mapping. Applied the launcher's existing `adb reverse tcp:8787 tcp:8787`; verified the mapping. No source/configuration file changed. Main Flutter build restored and left on Guest Home after fixture tests.

### Coverage gaps requiring isolated data / authorized sessions

- Full persistent E2E with two Agencies, three members, poll/vote/finalize/slip/documents/completion/review.
- Simultaneous SQL matching/finalization, duplicate payment/slip racing, transaction rollback/retry, and private document replacement/cross-access on a real isolated DB.
- Successful live Admin/Agency/member login, session expiry/suspension after login, Google/Apple login.
- Authenticated Agency #39 history rendering, live lead #115 aggregates with no per-user poll choices, and Admin/private-document preview.
- Every protected Flutter/Portal screen's loading/error/empty state and every country image on a real logged-in app.
- Full launcher double-click/re-run acceptance. Only static guard, one actual DB process, readiness query, proxy and ADB checks were performed.

No new small product bug requiring a safe code fix was reproduced, so no subsystem code was changed and no redundant regression test was added. Existing relevant regressions ran once; large suites were not rerun.

## Commands and evidence inventory

| Command/check | Result | Evidence type/count |
| --- | --- | --- |
| `dart analyze server` | exit 0 | Static analysis; 0 issues |
| `flutter analyze` | exit 0 | Static analysis; 0 issues |
| `flutter test --machine` | exit 0 | 177 pass, 1 skip; includes 86 backend tests |
| `flutter test integration_test -d emulator-5554 --machine` | exit 0 | 4 emulator-rendered fixture tests; not live backend |
| `npm.cmd run lint` | exit 0 | ESLint |
| `npm.cmd run typecheck` | exit 0 | TypeScript |
| `npm.cmd run build` | exit 0 | Production compilation/bundle |
| `flutter run -d emulator-5554 --no-resident --no-pub` | exit 0 | Restored main app; real Guest UI observed |
| Local HTTP authorization probes | PASS | 26 requests returned 401; traversal 404 |
| Public groups / Portal health proxy | HTTP 200 | Live API/MariaDB SELECT; 77 groups / proxy connectivity |
| Existing consistency SQL in READ ONLY transaction | PASS | Current issues 0; accepted exceptions reported separately |
| Protected #102/#115 hash comparison | PASS | Same SHA-256 before/after live checks |

Machine JSON output contains hidden test-runner/loading events; the report excludes these from test counts. The DB test skip is intentional because no isolated database is configured. Results from earlier checkpoints are explicitly labeled prior evidence, not counted again.

## Files and operational changes

- Authored/updated report: `audit/final_qa_20260927.md`.
- New QA artifacts: `audit/final_qa_20260927_*.txt`, `*.json`, and `*.jsonl` (analyzer/build/test output, aggregate DB evidence, HTTP statuses, snapshot hashes). No raw row dumps or credentials were written to these files.
- Normal generated build outputs updated by Flutter and Portal builds; no application source, schema, migration, launcher, Matching/Voting/Payment rule changed.
- ADB reverse mapping restored; main Flutter debug APK reinstalled after integration tests. No accounts/reviews/business fixture rows created; no cleanup SQL required or run.

## Demonstration readiness

**READY FOR LIMITED LOCAL DEMONSTRATION: YES, with the above limits.** Static quality and current tests pass; public Portal pages, Flutter Guest navigation, and four emulator fixture workflows are verified. Current read-only DB checks pass.

**FULL LIVE END-TO-END ACCEPTANCE: NO.** Do not describe this run as a successful live multi-agency auction/payment/trip chain. Before relying on that scenario in the defense, prepare an isolated fixture DB using the now-verified local administration channel and complete the authenticated flow. Previous provisioning blocker was an access-discovery gap; schema/credentials/harness preparation still has not been performed. Payment evidence is development/fixture only; no real-money verification is claimed.

## Data safety

No business-data write, schema change, account creation/reset, vote, bid, payment, document or review submission was performed. MariaDB datadir and recovery backups are untouched. Existing fixtures were not deleted.

Protected snapshot covered group rows, user group/status links, memberships, bids, voting rounds/votes, destination polls/votes, meetings, and payments for groups #102/#115. Both snapshots have SHA-256 **C55D8D61E2047C8EB0CEF06E939CFBEE7F84DCC55DBD1C7B3BF50A83B661DFDA** (35 output lines). Raw data was hashed in memory, not saved. The comparison covers those selected records during the live-check interval; it is not a claim of a whole-database physical checksum. All direct QA SQL sessions used READ ONLY transactions. Main MariaDB stayed on the same PID; it was not stopped or restarted.

## Follow-up checkpoint — 2026-09-28

Scope was limited to the reported SQL credential material, the launcher's MariaDB readiness command, and current process/listener availability. Full QA, test suites, ADB, and application flows were not rerun.

### Classification

- **Confirmed application bugs:** none found in this follow-up.
- **Confirmed source security exposure:** `database/travelin_trip_data.sql` contains four literal `IDENTIFIED BY` declarations at lines 5, 7, 12, and 14. Their values were not printed, copied to evidence, or checked into this report. This confirms plaintext credential-like material in the setup SQL; it does not prove those values are current or that this script was executed against the recovered database.
- **Root account behavior:** `start_tourapp.bat` runs the MariaDB client as `root` and supplies no password argument. The client may still read option files. The 2026-09-27 Final QA separately ran the same read-only query with `--no-defaults` and it succeeded, establishing that root login without an option-file password worked then. The launcher-equivalent and `--no-defaults` probes attempted on 2026-09-28 could not authenticate because no server was listening; current root authentication and grants therefore remain **not reverified**. Earlier read-only grant metadata showed broad local privileges. No password or grant was changed.
- **Current availability blocker:** the 2026-09-28 process check found zero `mysqld.exe` processes and zero port-3306 listeners. Backend port 8787 and Portal port 4173 also had no listeners; their HTTP health requests were unavailable. No service was started or restarted during this follow-up.
- **Testing limits:** the previous isolated-write E2E remains blocked. No ADB check was needed while Backend was unavailable; the prior checkpoint records the restored reverse mapping and emulator fixture results.
- **Deferred work:** authenticated live workflows, isolated database E2E, a true database liveness health probe, comprehensive role-crossing checks, and broader responsive coverage remain outside this focused follow-up.

### Priority before demonstration

**CRITICAL — restore local service availability.** The current machine cannot demonstrate login or API-backed features while MariaDB, Backend, and Portal are stopped. The owner should start MariaDB only with the previously validated persistent-console procedure (`C:\xampp\mysql_start.bat`), confirm the existing process/listener is singular and the read-only DB readiness query succeeds, then start Backend and Portal once. If startup reports an error, stop there and preserve the logs for diagnosis; do not use XAMPP's detached MySQL start path or launch a second server.

**BEFORE DEMO / SOURCE HANDOFF — remove credential exposure and reduce database privilege.** Keep the demo local until the account issue is handled. The legacy SQL's literal credentials should be removed from any source bundle distributed outside the owner-controlled machine, and any account whose secret was exposed should be rotated through the supported account-management path. Replace Backend's root access with a least-privilege application account; keep migration administration separate if schema migrations require elevated rights. Update the readiness query and phpMyAdmin configuration only after the replacement account has been verified. Do not expose the recovered MariaDB to other machines; external reachability was not assessed.

**FUTURE — verification improvements.** Prepare an isolated test schema for write-based E2E, make `/api/health` perform a bounded DB liveness query, and complete authenticated Portal/Flutter coverage. Existing test/build evidence from 2026-09-27 remains valid for that code state and was not rerun.

### Safe credential-change plan (not executed)

1. After MariaDB is stable, inventory only the accounts and settings actually used by Backend, launcher, and phpMyAdmin. Do not put credential values or authentication hashes in command output, issue logs, or checkpoints.
2. Back up the relevant configuration files and account/grant definitions to a local, access-restricted, timestamped location outside Git. Preserve the existing recovery backups and datadir unchanged. Verify the backup can be read by the owner before modifying accounts.
3. Create and verify a dedicated least-privilege Backend account, preferably against an isolated schema first. Store its randomly generated secret in an owner-controlled protected environment/configuration, not SQL source or Git. Confirm application reads, authentication, and required runtime writes before reducing root access.
4. Change root and any exposed legacy account only after confirming a separate administrative login and phpMyAdmin access. Apply only the reviewed grants required by the application; do not edit MariaDB privilege tables directly.
5. Roll back by restoring the protected configuration/grant backup and prior connection settings if the new account fails. Keep the previous administrative path available until Backend, Portal, and phpMyAdmin have all been verified. Never restore or overwrite the datadir as a credential rollback method.

### Changes and safety

No application, launcher, SQL, configuration, credential, schema, or business-data file was changed. No regression test was needed because no product code was changed. The only edit is this follow-up checkpoint in the existing QA report. No MariaDB data files, recovery backups, groups #115/#102, or other business rows were accessed or modified during this follow-up; because the server was down, the prior #115/#102 snapshot remains the latest comparison rather than a new 2026-09-28 verification. No test fixture was created or cleaned up.

**Current demonstration status: BLOCKED until the owner restores MariaDB, Backend, and Portal using the validated startup path.** The 2026-09-27 limited-demo evidence remains historical evidence; it does not mean the services are available now.

## Launcher and credential recheck — 2026-09-28

`start_tourapp.bat` was run once with a normal command window. Before and after it ran, the same MariaDB PID 9404, Backend PID 7180, and Portal PID 472 were serving the expected ports; each port had one listener. The existing MariaDB process uses `C:\xampp\mysql\bin\mysqld.exe`; its parent command references `C:\xampp\mysql_start.bat`, confirming the Persistent Console startup path. The launcher reused MariaDB, Backend, and Portal; it did not start duplicate processes. The Flutter app package had a running process on the already-online Android emulator after launcher execution. No XAMPP Control Panel Start action was used.

### Readiness evidence

- MariaDB 3306: PASS. The launcher-options query and a second query with `--no-defaults` both succeeded as `root@localhost`, returned port 3306, datadir `C:/xampp/mysql/data/`, and a user-row count. These were read-only SELECTs. One `mysqld.exe` and one listener remained.
- Backend 8787: PASS for service/DB availability. `/api/health` returned `ok=true` and `databaseConfigured=true`; the separate SQL query proves a live DB query worked. The health field alone remains configuration-only.
- Agency/Admin Portal 4173: PASS. HTTP returned 200 and the open Browser UI visibly showed the Admin Login form. No credentials were entered.
- Flutter User App: PARTIAL. The emulator was online, ADB reverse `tcp:8787` was present, and package `com.travelin.app` had a running process after launcher execution. Successful account authentication was not tested because no authorized login credential was supplied; no login attempt was made. The earlier login widget tests remain the automated evidence.
- Launcher duplicate protection: PASS for this run. The MariaDB, Backend, and Portal listener counts stayed at one and their process IDs were unchanged across the launcher call. The main launcher console remained open.

**CRITICAL service-availability issue: RESOLVED.** MariaDB, Backend, Portal, and the Flutter app process are now up through the requested launcher flow. This resolves the stopped-service finding; it does not claim a successful credential login or long-duration stability test.

### Current credential exposure and remediation plan

- The source SQL still has four literal password declarations at lines 5, 7, 12, and 14. Their values were not displayed or copied to an artifact. It is unverified whether the script created any current account; do not assume the values are active.
- The launcher invokes MariaDB's client as `root` without a password argument. Both the exact launcher-style read-only invocation and the explicit `--no-defaults` invocation succeeded, so the client does not need an option-file password for this root connection. `CURRENT_USER()` returned `root@localhost`. Read-only privilege metadata showed broad grantable global privileges for root host entries. The server listens on `::`; external reachability was not tested.
- Dependency mapping for a future change: the Dart server reads `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, and `DB_PASSWORD` from its environment. The launcher readiness check independently hardcodes `root` and queries `tourist_grouping_db`; that check must move to the verified application account as part of a coordinated credential change. phpMyAdmin's account/config dependency still needs inspection before root changes.
- Safe sequence remains: first verify a restricted timestamped backup of relevant account/grant definitions and configuration outside Git; prepare and test a least-privilege Backend account (plus a separate migration account only if needed); update the Backend and launcher readiness settings; verify DB query, Backend, Flutter API path, Portal, and phpMyAdmin; only then tighten root and any exposed legacy account. Keep the old admin path until all checks pass. Roll back by restoring the protected grants/configuration and prior connection settings, never by restoring or overwriting the datadir. No password/account/grant change was made in this run.

### Diagnostic-output handling and data safety

One broad diagnostic search unintentionally read rows from a SQL backup and emitted password hashes in the tool output. The hashes were not copied to a file or this report, but the tool output is part of this conversation and should be treated as exposed. No live database rows were accessed or changed by that search. Before source handoff, the owner should restrict that backup from distribution and rotate affected accounts through the approved account-management process. I did not alter or remove the backup.

This launcher recheck issued read-only SQL only. It did not change schema, accounts, business rows, the datadir, or recovery backups. Groups #115 and #102 were not queried or changed in this recheck; the prior 2026-09-27 protected snapshot remains the latest direct comparison. No test suite or Full Live E2E was rerun.

**Current readiness:** local system startup is restored and the CRITICAL availability issue is resolved. Flutter process/API routing is ready, but valid login authentication remains unverified. Resolve credential exposure and replace Backend root access before distributing source; do not expose this MariaDB listener to other machines based on this local-only check.