KEYLOG v2.0 VERIFICATION REPORT
15 October 2026

Environment
Laravel Framework 13.31.0, PHP CLI 8.3.6, MariaDB 10.11.14, Linux.
Composer platform resolution targets PHP 8.3.0. AdminLTE 4.0.0 and Bootstrap
5.3.8 assets are installed locally. Browser rendering uses headless Chrome
145 with desktop 1440x1000 and mobile 390x844 viewports.

Results
42 database/integration checks passed.
97 HTTP functional checks passed.
PHP source syntax checks passed. Blade template compilation passed.
Composer production installation and platform requirements passed.
Composer reported no security vulnerability advisories during resolution.
Desktop login, dashboard and key listing, and mobile pickup rendered.
Mobile layout had no page overflow and no JavaScript errors were observed.
The mobile sidebar opened and closed successfully, and the filtered report
printed to PDF with navigation hidden. Screenshots are internal QA, not
production data exports.

Database preservation
A disposable database was imported from keylog_db.sql. A separate database
was imported directly from the uploaded original SQL. Every original field
in admins, users, rooms, key_items, class_sessions, key_transactions,
user_sessions, system_settings and original edit-history tables compared equal.
The additive upgrade was rerun to confirm it does not duplicate schema/data.
The original snapshot contains 3 admins, 27 staff, 30 rooms, 18 keys,
4 class sessions, 4 staff/session assignments and 1,676 key movements.
No QA account or test movement is inserted into the deliverable SQL file.

Integration coverage
Exact framework version, timezone and literal token; support table existence;
pickup holder/room/due state; duplicate issue rejection; failed-operation
rollback; wrong-holder return rejection; return clearing holder/state and
recording room; repeated return rejection; inactive key/room and unknown
lecturer rejection; unassigned class rejection. Two independent simultaneous
pickup processes produced exactly one issue and one rejection, with one
pickup log row. An Ollama HTTP stub verified response handling, aggregate-only
context and failure fallback. It did not test a live model or hosting gateway.

HTTP coverage
Root/login routing; CSRF; guest access restrictions; bcrypt-style password
login; administrator screens and create forms; create/edit/view/print controls
for keys, rooms, lecturers, classes, resources and admins; password hash
non-disclosure; pickup/return receipts; duplicate issue validation; correction
notes; filtered CSV; print view; local assistant; unique codes; reference
constraints; valid deletion of unused records; class time ordering; stored
HTML escaping; settings save; CSV import/duplicate/invalid-user handling;
maintenance forms, bad-token denial, authenticated system check and cache
clearing; preserved kiosk PIN; kiosk/admin separation; own-session receipt
scope; logout invalidation. Tests use a disposable QA account, not a guessed
or reset production password.

Limitations and required live acceptance
The hosting account was not accessed. DNS, SSL, cPanel document-root mapping,
Apache/LiteSpeed rewrite execution, file ownership, hosting PHP extensions,
MySQL 8.0 specifically, actual printers, iOS/Android/Windows devices and the
optional remote Ollama service must be verified after deployment.
PHP 8.3.0 compatibility is enforced through Composer's platform resolution;
the executable used for the tests was PHP 8.3.6. Browser viewports are not
physical mobile device certification. Password hashes were compared exactly;
the actual users' unknown plaintext passwords were not guessed or recovered.

No claim of 100% live-production certification is made. The measured tests
above passed; README Section 12 contains the hosting acceptance checklist.

Reproducing tests
Use a disposable database only. Import the original SQL into a separate
keylog_original database and the fresh export into a disposable test database.
Set DB_HOST/DB_PORT/DB_DATABASE/DB_USERNAME/DB_PASSWORD for the disposable
server, APP_URL=http://127.0.0.1:18080 and SESSION_SECURE_COOKIE=false.
Run php tests/integration.php to create the disposable QA account and verify
the database and concurrency cases. Start the Laravel public entry point on
127.0.0.1:18080, mapping /public/system_check.php and /public/clear_cache.php
to the corresponding standalone files. Run python tests/http_test.py.
The supplied HTTP test file uses the disposable QA account and makes writes.
Do not run it on production. Raw successful results are retained in
integration_results.json and http_results.json; data_inventory.json contains
counts only. The tests require the supplied snapshot and a fresh test database
for each full run. The native Windows runtime may not support the same
concurrency process setup; conduct that test with two independent PHP workers.
