This is the client-only workspace for Onlo’s native mobile messenger. It reuses the Onlo WebChat AI pipeline; it does not contain or change the Onlo server, database, AI pipeline, or Operator backend.

The complete v1 contract is canonical. Local implementation uses redacted fixtures and synthetic test data.

This status is release-candidate evidence, not publication or physical-device certification.

All four are RC ready; publication remains pending physical-device qualification and the external ownership/signing actions recorded in the release manifest.

• Work from the local dev integration branch; main is the protected release branch.
• Use the approved v1 wire contract in docs/api-contract.md and packages/protocol.
• Keep the Onlo server repository and Operator backend out of scope for this workspace.
• Obtain a short-lived user JWT from an Operator backend when testing identified flows; never add it, a signing secret, a chat token, or customer data to this repository.

docs/              Product, integration, architecture, and v1 API contract
contracts/v1/      Language-neutral request and response examples
packages/protocol/ Shared TypeScript contract types
packages/ios/      Native iOS core foundation
packages/android/  Native Android core foundation
packages/react-native/ Canonical @onlo/react-native facade
packages/flutter/  Canonical onlo_flutter facade
sdk/react-native/  Legacy reference only; excluded from root workspaces
conformance/       Cross-SDK lifecycle and protocol scenarios
examples/          Local host foundations (no keys, JWTs, or signing code)
examples/merchant-backend/ SDK-team-only synthetic Merchant authentication/JWT simulator
examples/ios-local-e2e/ SDK-team-only installable iPhone Simulator E2E host

1. Read the canonical contract and select the build origin → production uses https://onlo.ai; staging/review injects its exact HTTPS origin through release configuration.
2. Implement and test native behavior with redacted fixtures and mock transport → no live customer data, credentials, or attachment URLs are required.
3. Verify the implemented React Native and Flutter native adapters in real host builds → JavaScript and Dart remain free of credentials and identified state.
4. Run shared manifest checks, then platform conformance when native toolchains are available → public-service E2E uses an enabled testing target and synthetic data.

The canonical public host API is documented in the integration guide. It includes initialize({ sdkKey }), loginUnidentifiedUser(), loginIdentifiedUser({ userJwt }), host-controlled present(), and awaited logout().

• Reuse the existing WebChat AI pipeline; do not create a mobile-only AI pipeline.
• Store rotating credentials only in native protected storage. Do not use AsyncStorage, plain files, JavaScript/Dart state, or logs for credentials or identified data.
• Retain one stable clientMessageId across every retry. Do not drop queued messages to make room.
• Revoke and partition User A’s state before User B can access the SDK after logout or account switch.
• The v1 contract limits images to JPEG, PNG, or WebP, 8 MiB each, and five per message.
• Do not commit, push, publish, deploy, release, or modify GitHub settings without explicit approval.

npm run typecheck
npm run test:protocol-fixtures
npm run test:conformance
npm run test:hygiene
npm run check:hygiene

The shared commands validate types, fixtures, conformance manifests, and repository hygiene; they do not replace native/device evidence. Package-specific commands and exact current gates are in the development and go-live guide. The legacy React Native prototype is not a supported package or fallback.

Merchant app integration needs only the iOS merchant example: a public SDK key, the merchant backend’s authenticated JWT callback, and a host-owned Support action. The separate merchant-backend simulator is SDK-team local test infrastructure, not part of that integration.

• iOS and Android implement the same confirmed v1 flows and pass shared conformance scenarios.
• React Native and Flutter delegate all secure/session/outbox/UI behavior to the native core on the active OS.
• An Operator app presents the messenger from a host-owned entry point and never ships a signing secret.
• Logout and account switching make old identified history, outbox rows, credentials, read state, and push associations inaccessible before another account can use the messenger.

• Contributor quick start
• Integration guide
• Development and go-live guide
• v1 API contract
• Client contract gap review
• Architecture
• Four-client delivery plan
• Conformance scope