Relevant shared rules: Establish the working context; Project and platform boundaries; Placement and data handling; Project URLs; Minimal implementation; Implementation, validation and completion.

Build a working Hungarian contact-register demo with the existing 61ade library in this PHP project. Read the project's AGENTS.md and 61ade's 61ade-consumer and 61ade-application skills first. Use the library's actual documented APIs and existing examples; do not change the library.

Environment: the application belongs in public/contact-demo/ in the sanch.hu project. Keep private PHP implementation outside the public webroot, under includes/contact-demo/. The read-only library is /space/share/libs/61ade; link only packages/php outside the public webroot and packages/frontend/dist in a dedicated public assets directory. All SQLite files and persistent demo state belong under /space/share/data/sanch.hu/contact-demo/. Use the managed development URL https://dev.sanch.hu/contact-demo/. Do not deploy or change server configuration.

The application must do the following:
- Use 61ade's sign-in, shell, table, forms, validation, registered actions and permission checks. Do not build a second admin framework or a separate login system.
- Provide a Hungarian contact list with search, column filters, sorting, creation, editing and deletion. Fields: name (required), email (required, valid and unique ignoring case), phone, company, city, postal address, notes. Give the app a clear Hungarian name and useful empty/error states.
- Import a UTF-8 CSV file with the columns name,email,phone,company,city,address,notes. Accept a UTF-8 BOM and comma or semicolon separators. Validate the whole file before writing; on error report row numbers and leave the address book unchanged. Update matching email addresses and insert new ones. Show inserted/updated counts. Limit imports to 1 MiB and 1000 contacts. Reject ambiguous headers, malformed rows, duplicate emails within a file and invalid email addresses. Use a transaction and the framework's registered-action authorization/audit path.
- Export the current address book as a downloadable UTF-8 CSV with the same columns and BOM. Properly quote values and neutralize spreadsheet formulas. Make the export importable again; document any deliberate neutralization of unsafe cell values. Provide a downloadable sample CSV with clearly fictitious Hungarian contacts at reserved example.test email addresses.
- This is a publicly linked practice demo, not a shared real address book. Each visitor gets an independent SQLite copy of a prepared sample database; the SQLite file and session state remain outside the webroot. Use the 61ade demo login demo@example.test / 61ade-demo, with only contact-management permissions, and display these public demo credentials on sign-in. Explain briefly in Hungarian that the data is temporary and only fictional contacts should be used. Expire abandoned workspaces after 24 hours, with bounded cleanup and safe handling of active workspaces. Do not run schema migrations in HTTP requests: prepare the template explicitly from CLI, then copy it for visitors.
- Keep all server operations behind framework authorization and CSRF protection. Bound inputs and escape displayed values. Never expose private data, secrets, whole library source trees or SQLite files through public links.
- Use supported 61ade components and extension points for the import/export UI. If generic CSV tooling is missing, implement the smallest contact-specific registered handlers and project module, record this boundary, and report actual framework defects separately without patching 61ade.

Finish the implementation, initialize the demo data, and exercise it with Playwright on the managed development URL. Verify sign-in, CRUD, valid CSV import, rejected CSV with no partial writes, duplicate-email behavior, export/re-import, Unicode/quoted cells, spreadsheet-formula neutralization, unauthorized access, and isolation between two browser sessions. Fix application defects and rerun the affected checks. Preserve existing unrelated work. Record the exact checks, limitations and actual framework issues in the project's documentation. Retain a short setup/run guide and the sample CSV. Report what the library supplied and what application code you had to write; do not invent a time saving or claim the first attempt passed if corrections were needed. Do not deploy.