App Guide and Runtime

Overview

App Guide and Runtime: Actual FPH LAN EMS app guide covering runtime, SQLite, SPA shell, local HTTPS, DNS/mDNS, LiveKit, Android wrapper, packaging, and certification. This page is written for event leads, LAN operators, check-in staff, POS staff, roster leads, local admins, and support reviewers, so it uses operational language: what the area is for, what can change, what can go wrong, and what proof another reviewer should expect.

EMS LAN work should be treated as an accountable handoff, not as a private technical action. The source context for this page is fph-lan-ems, partner dashboard Offline Snapshot and Sync History, EMS LAN support routes, and the completed EMS LAN task history.

Scope

Area	What this page covers
Product area	EMS LAN
Docs stage	Reference
Practical scope	Capacitor Android wrapper behavior, device permissions, native scanner/NFC, notifications, and WebView lifecycle
Primary outcome	keep an event operating on a trusted local network when internet access is unreliable, then return offline work to the online dashboard with reviewable proof

Routes and surfaces

Route or surface	Why it matters	Verification proof
/login	Surface, route, host, or integration context readers should have open while following this page.	Confirm the page, host, event, environment, or integration is the one currently being reviewed.
/control-room	Surface, route, host, or integration context readers should have open while following this page.	Confirm the page, host, event, environment, or integration is the one currently being reviewed.
/admin/:eventId/:surface	Surface, route, host, or integration context readers should have open while following this page.	Confirm the page, host, event, environment, or integration is the one currently being reviewed.
/workspace/:eventId/:surface	Surface, route, host, or integration context readers should have open while following this page.	Confirm the page, host, event, environment, or integration is the one currently being reviewed.

Page-specific records

Record or contract	What it represents	Verification proof
.lan-data	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.
SQLite database	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.
Runtime logs	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.
TLS certificates	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.
LiveKit credentials	Record or contract family that can be read, exported, changed, imported, reconciled, or used as support evidence.	Keep the record ID, count, status, timestamp, or owner needed for another reviewer to verify the handoff.

Decision owners

Audience	Responsibility	Verification proof
Server operators	Reader group expected to make or review decisions from this page.	Make sure this group has the required access and escalation path before relying on the workflow.
Support leads	Reader group expected to make or review decisions from this page.	Make sure this group has the required access and escalation path before relying on the workflow.
Release reviewers	Reader group expected to make or review decisions from this page.	Make sure this group has the required access and escalation path before relying on the workflow.

Mental model

The safe way to use this page is to follow the record, not the screen. A screen, route, file, or response is useful only when staff can connect it to the actor who used it, the record it changed, and the proof that remains afterward.

Use this sequence before relying on the page:

1. Identify the exact event, route, file, account, device, or record family.
2. Confirm which system is the source of truth at this step.
3. Check the role, local account, attendee account, machine token, or service caller.
4. Make the narrowest action that matches the workflow.
5. Verify the result where the next reviewer will look.

Inputs, options, and records to check

Shared item	What it means	Verification proof
Snapshot file	Carries event data into or out of the offline environment.	Event ID, export time, format, file owner, and import history match.
Local SQLite records	Hold LAN-local check-in, claim, POS, inventory, HR, roster, communications, account, and token state.	Local counts are compared to online records after import.
Operator or device identity	Shows who acted in the local environment.	Local user, machine token, Android device, or server operator is named.
Exception notes	Explain manual decisions made while disconnected.	A later reviewer can identify what happened and who owns follow-up.

Operating sequence

Step	Action	Stop if
1	Confirm scope before acting.	The event, file, route, environment, user, or device is unclear.
2	Check authority before changing state.	The actor can view information but should not make this decision.
3	Review the visible option, file, route, or record effect.	The action affects access, money-adjacent records, public information, offline state, or external services without a reviewer.
4	Complete the action only after the expected result is known.	Staff cannot say what success and failure should look like.
5	Save handoff evidence.	The result exists only in memory, chat, or an unsafe screenshot.

Flowchart

flowchart TD
  source["<b>Online source</b><br/>Partner dashboard event records<br/><i>Docs: Event Management</i>"] --> file["<b>Snapshot file</b><br/>Exported event copy with metadata<br/><i>Docs: File Formats and Schema</i>"]
  file --> local["<b>App Guide and Runtime</b><br/>Local operation or reference check stores evidence for later import"]
  local --> returned["<b>Returned snapshot</b><br/>Local changes and audit notes leave the venue"]
  returned --> history["<b>Sync history</b><br/>Dashboard import summary and reconciliation evidence<br/><i>Docs: LAN Sync History</i>"]
  click source "/event-management/" "Open Event Management docs"
  click file "/ems-lan/reference/file-formats-and-schema/" "Open file reference"
  click history "/ems-lan/surfaces/lan-sync-history/" "Open sync history docs"

Verification

Check	Evidence to keep
Scope check	Event ID, route family, file name, record ID, environment, account, or device name.
Actor check	Staff role, attendee account, local user, machine token, service caller, or external system.
Result check	Updated record, imported count, response body, audit entry, local note, sync-history row, or visible status.
Exception check	Warning, skipped row, validation error, denied permission, partial result, or fallback decision.
Handoff check	Named owner and next action for anything unresolved.

Common mistakes

Mistake	Why it causes problems	Recovery
Treating a visible screen as complete proof.	Screens may be filtered, stale, local-only, or scoped to one actor.	Check the underlying record, route evidence, sync history, or audit trail.
Acting without naming the actor.	Permissions and side effects depend on who or what made the request.	Repeat the check with the correct staff role, attendee account, local user, or service caller.
Skipping evidence because the action looked successful.	Support cannot distinguish success, partial success, retry, or workaround later.	Capture timestamp, record ID, result, and reviewer note before closeout.

Related pages

• Pre-Event Readiness
• Export LAN Snapshot
• Operate LAN Check-In
• Import LAN Snapshot
• Reconcile After Import
• EMS LAN Data Records