# E-Bidding isolated demo checkpoint — 2026-09-27

## Status

**BLOCKED before test-schema creation.** No DEMO users, agencies, groups, bids, votes, files, or database schema were created in this run. No project source/configuration files were changed.

## Safety boundary

- The live application services remain on their existing endpoints: MariaDB `3306`, Backend `8787`, Portal `4173`.
- Backend health at `http://127.0.0.1:8787/api/health` returned `ok=true` and `databaseConfigured=true`.
- No listener was present on test ports `3307` or `8788`.
- No SQL was issued and no existing business records were changed. In particular, this run did not write to `tourist_grouping_db`, group `#115`, or group `#102`.
- MariaDB datadir/recovery backups and main Backend/Portal processes were left alone.

## Evidence and blockers

- Existing opt-in integration test: `test/server/destination_poll_vote_database_test.dart`. It requires an isolated schema named `tourapp_poll_vote_test_*` and explicit `TRAVELIN_POLL_TEST_DB_*` variables; it skips if those are absent. No test DB variables are configured in this shell.
- The Backend supports explicit `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, `DB_PASSWORD` overrides and `TRAVELIN_PORT`; this allows a test-only instance on `8788` without using the main app database, provided every DB variable is supplied and the name is guarded against `tourist_grouping_db`.
- The checked-in base SQL `database/tourist_grouping_db_complete.sql` includes business data as well as schema. It must **not** be imported wholesale into a test schema. Provisioning must use schema-only DDL and the required migrations/catalog reference data, never users or business rows from the main DB.
- The running Portal login page opened successfully at `http://127.0.0.1:4173/agency/login`. It is the main Portal, so no DEMO login was attempted there.
- Android device `emulator-5554` (Android 14 / GM1910) became `device`/online after `adb reconnect offline`. No Flutter login/UI test was run because no isolated test Backend exists yet; the app must not be pointed at `8787` for this demo.
- phpMyAdmin at `127.0.0.1/phpmyadmin` was not reachable (`ERR_CONNECTION_REFUSED`), and no authorized DB-administration credential/session is available to this task. The app DB config file was not opened or printed.

The main blocker is therefore database provisioning authority, not an Admin Portal session or an inference about existing Agencies. Do not infer that approved Agencies are absent from a `401`; that response only shows that the current request had no session.

## Exact provisioning authority required

An authorized MariaDB operator must provision a fresh, empty test schema and a schema-scoped account. The operator needs:

- `CREATE DATABASE` (global/server-level authority to create the new schema);
- `CREATE USER` (global authority to create the new app account);
- `GRANT OPTION` for the privileges granted to that account.

The application/test account should receive privileges only on the new test schema, for example `GRANT ALL PRIVILEGES ON <test_schema>.*` (not `*.*`). Use a generated password entered via a secure local environment mechanism; do not put it in this checkpoint, source control, launcher text, or logs. If the operator prefers to create the schema/account, provide only the schema name, host, username, and password through a protected local channel/environment.

Recommended names are `tourapp_ebidding_demo_20260927` for the schema and a distinct local-only account such as `tourapp_ebidding_demo_app`. Do not copy any business rows from `tourist_grouping_db`.

## Repeatable continuation once provisioned

1. Verify the schema is empty and its name is not `tourist_grouping_db`; load only schema DDL plus the current migrations and reference catalog needed by the demo.
2. Set all five `DB_*` values explicitly for the test process and set `TRAVELIN_PORT=8788`; assert `DB_NAME` equals the exact test schema before launch. Do not set `TRAVELIN_ENABLE_DEVELOPMENT_ACCOUNTS` unless its fixture behavior has been reviewed.
3. Start a separate Backend process on `8788`; verify health, then create three clearly labeled DEMO members and two DEMO Agencies in that database only. Any approved/test status must be explicit test setup and must not claim a real license was verified.
4. Use the existing register/login and group/matching/bid/voting routes. Keep payment-provider calls disabled. Store every created DEMO ID and keep the successful fixture for the presentation.
5. Verify cross-agency bid ownership, outsider voting, duplicate submission prevention, and winner finalization through the test API; then use the test-only Portal configuration and Flutter `--dart-define`/existing API override only if confirmed to point to port `8788`.
6. Cleanup, if later requested, must first assert the exact schema name/prefix and remove only that test schema/data. Never run cleanup against the main schema.

## Current demo inventory

| Item | Result |
| --- | --- |
| DEMO schema / DB user | Not created; blocked on DB provisioning authority |
| DEMO Agency A/B | Not created |
| DEMO members/group/bids/votes | Not created |
| API E-Bidding result | Not run; no isolated test DB/backend |
| Browser Portal | Main login page opens; DEMO authenticated flow not run |
| Flutter Emulator | Online after ADB reconnect; DEMO flow not run |
| #115 / #102 | No writes made by this run |

## Follow-up: provision authorization check

Read-only recheck on 2026-09-27:

- Backend health still returns `ok=true` and `databaseConfigured=true`; this confirms the main app can connect, but does **not** reveal `CURRENT_USER()` or effective grants.
- MariaDB is listening on `3306`; the existing Backend is on `8787`; there is no test listener on `8788`.
- No SQL console or authorized phpMyAdmin session is available (`127.0.0.1/phpmyadmin` is not listening). No password was tried, and no account/grant was changed.
- Effective grants for the configured account therefore remain **unverified**; do not infer either sufficient or insufficient grants from API health.

### One-time local DBA SQL

Run this in the existing local MariaDB admin console (not against a different server). The first two statements are read-only. If the schema or account already exists, stop and inspect instead of changing/reusing it.

```sql
SELECT CURRENT_USER();
SHOW GRANTS;

-- Read-only inspection of the app account variants defined by project SQL;
-- a statement may report that an account does not exist in the live server.
SHOW GRANTS FOR 'travelin_app'@'localhost';
SHOW GRANTS FOR 'travelin_app'@'127.0.0.1';

SELECT SCHEMA_NAME
FROM information_schema.SCHEMATA
WHERE SCHEMA_NAME = 'tourapp_ebidding_demo_20260927';

SELECT User, Host
FROM mysql.user
WHERE User = 'tourapp_ebidding_demo_20260927_app';

-- Run only if both checks above returned no rows.
CREATE DATABASE `tourapp_ebidding_demo_20260927`
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATE USER 'tourapp_ebidding_demo_20260927_app'@'127.0.0.1'
  IDENTIFIED BY '<replace locally with a generated random password; do not save/share it>';

GRANT ALL PRIVILEGES ON `tourapp_ebidding_demo_20260927`.*
  TO 'tourapp_ebidding_demo_20260927_app'@'127.0.0.1';

SHOW GRANTS FOR 'tourapp_ebidding_demo_20260927_app'@'127.0.0.1';
```

The admin identity executing this requires `CREATE DATABASE`, `CREATE USER`, and `GRANT OPTION` for privileges granted. The new app account has no global grants; its privileges are scoped to the test schema. Do not grant it privileges on `tourist_grouping_db` or `*.*`. Set Backend `DB_HOST=127.0.0.1`, `DB_PORT=3306`, `DB_NAME=tourapp_ebidding_demo_20260927`, `DB_USER=tourapp_ebidding_demo_20260927_app`, the generated `DB_PASSWORD` via a protected local environment, and `TRAVELIN_PORT=8788` only after these statements succeed.

After the DBA command succeeds, resume at schema-only DDL/migrations; never import the complete SQL dump containing business data. No DEMO records or test services were created in this follow-up.