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.