Team only · not indexed
How we act at an event
Six documents. Not fourteen folders. When something fails on the floor, open these in this order. Do not argue from memory. For “what changed in this build,” use Release notes.
Live-incident order
- API contract — what mobile sent, what backend must return, who owns the status code.
- Network evidence — last request, status, body message. Until the in-app diagnostics screen exists, capture Charles / Proxyman or the Axios response in a screenshot. Never paste tokens or passwords.
- Scenario matrix — what should happen for this status, online or offline.
- Ownership row — mobile vs backend vs contract vs data vs device. Classify before assigning blame.
- Incident log — write the entry while the evidence is still on the device.
- Decision log — only if the debate is “why did mobile do that on purpose.”
- Release notes — requirement → why → what → status for this version (and past versions).
Sentence to use when someone says “it’s the mobile app”
“Let’s classify it first. Mobile owns the request, local queue, and UI. Backend owns eligibility, badge validity, and HTTP status. If the status is 4xx/5xx with a backend message, that is not a rendering bug. If the device saved offline because the request timed out, that is the documented fallback in the scenario matrix.”
The documents
- Product & businessWhat are we building, and why?Staff badge check-in at events. Not attendee registration. Use this when someone asks what the app is for.
- Scenario matrixWhat should happen in every situation?Success, failure, and offline paths for login, space, scan, sync, export, and logout. This is the live-event playbook.
- Architecture & data flowHow does the application actually work?Traced UI → Redux → domain → AsyncStorage → API → native. Source of truth, write/read paths, and cold trails.
- API contracts, ownership & decisionsWho owns each behavior, and why was it built this way?Exact request/response shape mobile sends, layer ownership, and the decision log. This is the no-blame document.
- Risks, known issues & incidentsWhat can go wrong, and what already did?Duplicated scan paths, status-code mismatches, persistence risks, and a copy-paste incident template.
- Release notes & requirement changesWhat changed in this version, and why?Versioned requirement → why → what → status. Use for PM reviews, store release copy, and “why did we change that?”
What we are not doing
- Not creating a 14-folder tree (01-business … 14-risks). Those topics collapse into the docs above (including release notes).
- Not logging passwords, JWT secrets, bearer tokens, or full personal data. Diagnostics stay metadata-only.
- Not treating verbal explanations as the record. If it mattered at an event, it goes in the incident log.