railwaysystem/docs/iot/ROUND5V2_ACCEPTANCE.md

# Round 5V-2 — authorization received, restore prerequisite blocked

Date: 2026-10-14. Branch `fix/iot-safety-hardening`; starting commit
`5560a3ac0456b694609cdf9f21f7f59810950d76`. The user explicitly approved the
non-destructive migration on the named QA database, but not bypassing backup or
restore proof, database creation/deletion, privilege expansion or hardware control.

## Fresh actual database evidence

Read-only JDBC inspection connected only to
`192.168.139.218:4321/railwaysystem_fusion_qa_20261013`, using `fusion_qa_app`.
The server returned `KingbaseES V009R003C018`, database name exact, current schema
`public`, internal server endpoint `172.17.0.5:54321`. `transaction_read_only=on`,
repeatable-read transaction ended in rollback. No DDL/DML was issued.

- Base tables: public54, iotlocks9. Counts: train_student47, train_enrollment57,
  train_accommodation34, lock_auth10, lock_command15. No personal rows were printed.
- Round 5S lifecycle metadata is absent. Existing schema/index definitions remain
  in their pre-migration state. Historical LEGACY defaults cannot be claimed applied.
- App role is not superuser/createdb/createrole; no CREATE on either application
  schema, affected tables owned by kingbase. Existing DML grants were inspected,
  not exercised. Extra TRUNCATE/TRIGGER/REFERENCES on public.sys_menu,
  public.sys_notice_read, public.sys_role_menu remain unchanged pending admin review.
- An initial read-only table-inventory query through information_schema.tables
  returned SQLSTATE42501. The probe now reuses the already-readable pg_tables
  catalog view and completes successfully without extra grants.

Evidence: `scripts/qa/QaDatabaseProbe.java` and private
`.qa-runtime/round5v2-preflight.log` (metadata/counts only).

## Migration scope PASS; runtime DDL semantics BLOCKED

Full 005 content was reviewed and independently allowlisted: 20 statements,
16 ADD COLUMNs and 4 CREATE INDEXes (2 unique), all limited to the two approved
`iotlocks` tables. No DROP/TRUNCATE/DELETE/UPDATE/GRANT or sequence reset.
SHA256: `90648b6ac67470f9a14f0795c4479dfb4811d4907e41a13ee5eeada16582b87f`.
The file was not changed. Additive scope is verified, but actual Kingbase DDL
transaction rollback, null-key uniqueness, repeated execution and lock behavior
have NOT been tested because the prerequisite restore gate is blocked.

## Concrete backup/restore blockers

1. No sys_dump/sys_restore/ksql/pg_dump/pg_restore on local PATH or in the scoped
   common install/download locations checked. A PostgreSQL client was not installed
   or substituted as evidence of Kingbase compatibility.
2. Docker CLI and Docker.app exist, but the configured desktop-linux daemon socket
   does not exist; docker info fails. No usable local Kingbase restore instance
   was discovered or supplied. No Docker startup, install, database creation,
   network modification or engine initialization was performed.
3. Existing SSH alias wzbmatebook is reachable, but no vendor tools were found on
   PATH or in the bounded /opt, /usr/local, /usr/lib, /home/wzb search; no matching
   database/container process was reported. This is only a scoped resource check,
   not a claim that no vendor installation exists anywhere.
4. Existing SSH authentication to database host 192.168.139.218 as configured user
   wzb was denied. No password guessing, root fallback, new host-key acceptance,
   remote installation or server changes were attempted.
5. Protected local QA configuration is 0600 and contains the usable app credential.
   No explicit QA DDL-management connection or isolated restore connection was
   found among its keys. Web-admin login keys are NOT treated as database-admin
   credentials. The application role was not elevated or used to attempt DDL.

BACKUP_CREATED = BLOCKED: no new native consistent backup.
ISOLATED_RESTORE_VERIFIED = BLOCKED: no actual isolated database restore.
Previous private XML snapshots remain protected but do not satisfy either result.
Therefore formal migration and all dependent phases stop, as explicitly required.

## Work completed without migration

- Frontend production build rerun successfully from this archive, using its own
  declared dependencies/lockfile and Quill transpilation configuration. Evidence:
  `.qa-runtime/round5v2-frontend-build.log`. No Antigravity temporary path was used.
- 11 QA-tool tests rerun successfully. The modified Java probe actually compiled
  and ran on Java21 against Kingbase in read-only mode. No critical backend source
  changed; prior 85 JUnit results are historical evidence, not a new Kingbase run.
- Runbook and migration plan now acknowledge authorization and identify restore
  prerequisites, rather than incorrectly saying user approval is still missing.
- New Spring Boot/Redis/Chrome was not started; no old experiment backend or fake
  API substituted. Full login/routes, original homepage/charts, nine IoT pages and
  accommodation software E2E remain BLOCKED, not PASS.
- Safety defaults remain MQTT Mock, real writes false, whitelist empty, face HTTP
  disabled, OpenAPI/QA control interfaces disabled. No real device operation occurred.

## Required inputs to unblock this same workflow

Provide a matching licensed Kingbase native tool location, an **already existing
and approved** independent restore instance/database with protected connection
configuration, and the existing authorized DDL-management connection for this QA
database. Do not send passwords in chat. No new database or expanded app privilege
is requested or inferred. Once those inputs exist, prove restore first, then follow
the migration plan and run actual Kingbase transactions, startup and Chrome E2E.

SOFTWARE_QA_READY = BLOCKED.
READY_FOR_SUPERVISED_HARDWARE_TEST = BLOCKED.