docs: record verified VM import and SSH setup

docs/geoapify-data-import.md

@@ -138,8 +138,28 @@ midnight splits. File paths passed to `--file` are relative to `server/` or
 absolute. Keep real exports out of Git; retain the original files for audit.
 
 Use the model document's GraphQL query to verify all fields after import. Check
-counts and rerun the same file to confirm zero new rows and preserved IDs. VM
-access, migrations and import must still be verified on the actual environment.
+counts and rerun the same file to confirm zero new rows and preserved IDs.
+
+### Verified VM import on 2026-10-14
+
+The first import into `tapfinder_dev` on the team VM used the implementation
+from PR #51. The database initially had no Venue tables or data. Both migrations
+were applied, and the completed 2026-10-13 source collection was imported:
+
+- First import: 51 inserted, 0 updated.
+- Repeat import: 0 inserted, 51 updated; source mappings, venue IDs and review
+  values remained unchanged.
+- 51 venues and 51 source records; all retained original metadata and attribution.
+- All 16 public fields were read through GraphQL using local backend resolvers
+  against the VM database via SSH.
+- 19 bars, 26 pubs and 6 nightclubs; 34 websites.
+- Opening hours: 24 normalized, 19 missing and 8 requiring review.
+
+Unknown hours remain `[]`, with source expressions and review reasons retained.
+Unknown prices, ratings, descriptions and images remain null, and app review
+counts start at 0. Local snapshots and the operational verification report are
+kept in the ignored `server/imports/` directory. A permanent backend service and
+frontend GraphQL integration remain separate work.
 
 ## Tests and remaining integration
 
@@ -164,8 +184,9 @@ provider terms and the API plan govern distribution. Raw source metadata is
 internal and is not exposed by the Venue API.
 
 The implementation, tests and documentation were prepared with Codex. Source
-retrieval was checked against Geoapify; database behavior was checked locally
-without writing to the VM database.
+retrieval was checked against Geoapify. Automated tests use an isolated local
+database; the separate VM migration/import check above was completed on
+2026-10-14.
 
 Primary documentation:
 

server/README.md

@@ -19,13 +19,21 @@ Only copy the example if `server/.env` does not already exist. Replace the
 password placeholder privately; never commit this file or paste credentials
 into an issue. URL-encode special characters in the password (e.g. `#` as `%23`).
 
-On the VM, the connection uses `127.0.0.1:5432/tapfinder_dev`. For a local backend,
-keep this SSH tunnel open in a separate terminal:
+On the VM, the connection uses `127.0.0.1:5432/tapfinder_dev`. VM SSH access
+requires the NTNU network or VPN. See
+[NTNU VPN setup](https://i.ntnu.no/wiki/-/wiki/Norsk/Installere+VPN) for access
+from outside the university network.
+For a local backend, open this tunnel in a regular PowerShell terminal:
 
 ```powershell
-ssh -N -L 5433:127.0.0.1:5432 YOUR_VM_USER@it2810-07.idi.ntnu.no
+ssh -N -L 127.0.0.1:5433:127.0.0.1:5432 -o ExitOnForwardFailure=yes YOUR_NTNU_USER@it2810-07.idi.ntnu.no
 ```
 
+Use your NTNU username and log in with your NTNU credentials if prompted.
+With `-N`, SSH stays running without showing a remote shell; this is expected.
+Leave the terminal open while the local backend accesses the database.
+The database password in `.env` is separate from the SSH login.
+
 The local `server/.env` then uses:
 
 ```env
@@ -151,5 +159,9 @@ included in type checking. Backend CI runs these checks on PRs. The existing
 frontend Vitest suite remains separate.
 
 The data-import implementation, tests and documentation were prepared with
-Codex and verified locally. A real VM connection and import are a separate
-operational check once credentials and the SSH tunnel are available.
+Codex. On 2026-10-14, both Venue migrations were applied to `tapfinder_dev` on
+the team VM and 51 Trondheim venues were imported. A second import inserted
+0 and updated 51, preserving IDs and review values. All 16 GraphQL fields were
+verified against this database using the local backend resolvers through SSH.
+A persistent backend service on the VM and frontend GraphQL integration remain
+separate work.