Skip to content

KTP Life App Developer Setup

Goal

Give an approved contributor a repeatable path from repository access to a healthy local development build without placing private environment values or production access in public documentation.

Before you begin

You need:

  • Git;
  • Node.js 22.22.1 or the product team's currently approved Node line;
  • npm 10.9.4 or the version pinned by the client repository;
  • access to the canonical mobile client repository;
  • approved development-only backend configuration through the KTP secret-management process; and
  • an Android emulator, an iOS Simulator on macOS, or a compatible physical device.

A development build and physical device are needed for reliable camera and push-notification testing. TestFlight is for approved beta testing, not a substitute for a contributor's development environment.

Access boundary

Repository membership, Expo/EAS access, backend development access, signing, store accounts, and environment values are granted by role. Never share a personal login or copy values from another contributor. Production access is not required for routine feature development.

The canonical organization-owned repository URL has not yet been confirmed for publication. Obtain it through the approved Technology onboarding route.

Local setup

From the approved client repository:

npm ci
npm start

Common development commands are:

npm run android
npm run ios
npm run web
npm run prebuild

Create the local environment file described by the client repository. Values intended for the Expo client are bundled into the application and must be treated as public configuration; never place server secrets, service-role keys, calendar credentials, signing material, or recovery codes in client-prefixed variables.

Generated native projects should remain uncommitted unless the maintainers explicitly adopt a native-project source strategy.

Required quality checks

Run the client repository's current commands before requesting review:

npm test
npm run typecheck
npm run lint

Use the formatting command only when you intend to apply repository-wide formatting rules:

npm run format

Continuous integration is authoritative. Based on the supplied client documentation, CI checks lint, TypeScript, and Jest, including date behavior in multiple time zones.

First-run verification

Use approved development accounts and synthetic or non-production records.

  • [ ] Chapter selection loads
  • [ ] A development account can sign in and sign out
  • [ ] Home and Calendar load the expected test chapter data
  • [ ] Network loads the test chapter roster
  • [ ] The current member profile loads and approved edits persist
  • [ ] RSVP changes succeed and recover after a failed request
  • [ ] Offline state appears and data refreshes after reconnecting
  • [ ] Camera permission and attendance scanning work on a compatible device
  • [ ] Push-notification registration behaves as expected on a physical device
  • [ ] No test created or changed real production member or attendance records

Contribution workflow

  1. Choose an issue owned by your team and clarify the member outcome.
  2. Work from a short-lived branch.
  3. Trace the affected route, component, hook, transformer, backend contract, and policy boundary.
  4. Add or update tests for behavior, transformations, validation, dates, routing, and failure states.
  5. Check loading, empty, error, offline, and accessible interaction states.
  6. Update feature documentation and release notes in the same change.
  7. Request review from the domain team and a maintainer who understands the affected data or authorization boundary.
  8. Wait for CI and required approval before merging.

Public versus restricted setup documentation

Public page Restricted engineering runbook
Supported tool versions and generic commands Environment values and secret-distribution steps
Repository structure and review expectations Production project identifiers and administrators
Synthetic-data verification checklist Production logs, incident evidence, and recovery actions
Team responsibilities and release gates Signing credentials, store access, and emergency deployment
Safe troubleshooting symptoms Exploit details, sensitive schemas, or member-specific debugging

Facts still needed

  • canonical repository and whether it is intended to be public;
  • authoritative Node/npm files and upgrade policy;
  • supported operating systems and device matrix;
  • development environment owner and reset process;
  • approved test accounts and synthetic-data seed process;
  • code-review count and CODEOWNERS;
  • branch protection and merge requirements; and
  • private vulnerability-reporting route.