Technical Requirement Document

1. Baseline and architecture

The current website distributes PakoReady_Buttons_Fixed.apk, Android package appinventor.ai_neiladame0.PakoReady_Buttons_Fixed, version 1.0 / code 1. The replacement APK’s signature was verified and its SHA-256 is published in downloads/release.json. A related editable source, PakoReady_Buttons_Fixed.aia, was inspected and preserved in submission/. Its source project namespace remains appinventor.ai_neiladame0.PakoReady_2; a reproducible build match has not been established. The supplied source archive is preserved without editing any blocks. This package differs from the original download, so Android treats saved data separately. The project proposal PDF describes this button-fix release and the companion website.

2. Mobile implementation

The App Inventor source defines Screen1, DisasterGuide, DecisionGuide, KitChecklist, Assessment, EmergencyContacts, EvacuationDirectory and About. Screen designer components define the native interface; Blockly event blocks implement navigation, selection, validation and storage. Guides and decision nodes are compiled into components/blocks. Bundled JSON files document reference content and sample data; the runtime does not parse those files as its content engine.

3. Platform and dependencies

APK manifest inspection reports minimum Android SDK 14, target SDK 36, version name 1.0 and version code 1. The manifest declares INTERNET and READ_EXTERNAL_STORAGE permissions. Minimum SDK metadata is not a compatibility test; device and Android-version testing is still required. There is no supplied iOS binary, backend server, database service, login service or push-notification integration.

4. Storage contract

TR-01 — Device-local TinyDB shall use namespace PakoReady. Checklist tags are kit.v1.Supply1 through kit.v1.Supply21 and store each supply state.

TR-02 — Assessment tags are assessment.v1.answers, assessment.v1.score, assessment.v1.percent, assessment.v1.summary and assessment.v1.recommendations. Scoring shall reject incomplete input before storing a new result.

TR-03 — Three contact slots use contact.v1.1.name / contact.v1.1.phone through contact.v1.3.name / contact.v1.3.phone. Phone validation accepts 3–15 digits, an optional leading plus and ordinary phone formatting (spaces, hyphens and parentheses).

TR-04 — directory.v1.records shall retain local user records. A record carries a facility name, public address, type, contact information and user-reported check date/source. Bundled templates are distinct from saved user records.

TR-05 — No cloud backup or synchronization is implemented. Reset/remove operations shall require confirmation where present. Uninstall and clear-data behavior shall be explained to users.

5. Navigation and external intents

Home opens the named module screens; module Back / Home returns to Home. User-initiated contact actions open a tel: URI in an external dialer. Map actions use geo:0,0?q= with the selected public address; they do not obtain device GPS location. Source buttons open HTTPS pages. Missing compatible handlers shall produce an understandable fallback message. The application shall not automatically call, transmit location or dispatch assistance.

6. Web documentation implementation

index.html, styles.css and script.js implement the landing page without a build system. A Help disclosure links to docs/prd.html and docs/trd.html and opens the same content in native HTML dialog elements. Each dialog has an accessible name, scrollable content, a close control and a standalone-page link. Native modal behavior contains keyboard focus; closing restores focus to the triggering link. Escape, backdrop closing and mobile navigation shall be checked. The same document content is inserted into the proposal so the website and submission agree.

7. Security, privacy and reliability

The app shall store planning information locally without an account requirement. External destinations open only on user action. It shall distinguish personal entries and sample facilities from independently verified information. The static site uses local fonts, document resources and relative APK links. privacy.html explains local records, deletion, permissions, external services and website visits; support.html provides installation help and contact details. APK signing, SHA-256 integrity and AAB availability shall be recorded separately; possession of an APK does not establish Play Store publication. Content-review dates in the source are historical annotations, not evidence of current agency endorsement.

8. Build and release procedure

Import the preserved AIA into compatible MIT App Inventor tooling. Review blocks, assets and permissions; test each screen and local persistence; retain the signing key securely; and export a signed APK and, where supported, a signed AAB. Compare the resulting package identity and version with the intended release. Publish the landing page and upload the source, releases, assets and PDF to the shared submission folder. Neither a signing key nor a release AAB was supplied in this workspace.

9. Verification plan and limits

Static verification covers AIA screens, block strings and TinyDB tags; APK manifest metadata; document content; and local file references. Browser verification shall cover Help dialog selection, keyboard closure, focus restoration and mobile layout. Android runtime checks should exercise all guide selections and decision paths, checklist reset and restart persistence, five-question scoring, contact validation, directory add/remove and external-intent fallbacks. Record observed results in submission/verification.txt. Untested cases remain pending and must not be represented as passed.

10. Traceability

PR-02 and PR-03 map to DisasterGuide and DecisionGuide; PR-04 maps to TR-01; PR-05 to TR-02; PR-06 to TR-03 and external intents; PR-07 to TR-04 and external intents; PR-08 to About and the web dialog implementation. Release artifacts and unresolved submission fields are recorded in submission/README.txt.