diff --git a/SOURCE.json b/SOURCE.json index 1f7f922..c515f8e 100644 --- a/SOURCE.json +++ b/SOURCE.json @@ -2,7 +2,7 @@ "repository": "Offline-Protocol/offline-protocol-agent-plugins", "source": { "repository": "Offline-Protocol/CLI", - "commit": "df32363b929581812ff26544d2b917d5fc9f241c" + "commit": "6143f12eac62445cd5f5dcd67a3c502629d7e971" }, "cliPackage": "@offline-protocol/cli@0.2.9", "generator": "scripts/export-agent-plugins.mjs", @@ -41,6 +41,6 @@ "plugins/offline-protocol/assets/logo.png": "8268382b80cd9e25a1509a1accdde7feae2233fd91bd5f041069d7fffcd8ade5", "plugins/offline-protocol/mcp.json": "4e23e03e9f73ee6e8a438285ce5a4d7e1c58011a17e636515808a16f737b30c7", "plugins/offline-protocol/plugin.json": "03909cab4db891cc751318e15892ecc0f946d3d3b45fd77203f8f5b494646327", - "plugins/offline-protocol/skills/build-with-offline-protocol/SKILL.md": "5d5731be0a4b11f18b0f003b081bfdf40f398c6a12cbe71b080eb09084296cf2" + "plugins/offline-protocol/skills/build-with-offline-protocol/SKILL.md": "0da096c6d9ab760eae1a889562ce82239c07663483a8057d07defe8669786e53" } } diff --git a/plugins/offline-protocol/skills/build-with-offline-protocol/SKILL.md b/plugins/offline-protocol/skills/build-with-offline-protocol/SKILL.md index 1cb9cbe..b17a4eb 100644 --- a/plugins/offline-protocol/skills/build-with-offline-protocol/SKILL.md +++ b/plugins/offline-protocol/skills/build-with-offline-protocol/SKILL.md @@ -27,6 +27,12 @@ The registry bundled with this CLI release pins Mesh SDK 0.31.0; telemetry in th Registry samples can lag the published packages, so check SDK calls against the installed type definitions. Facts that samples written elsewhere often get wrong: Mesh SDK event payloads use snake_case fields (`message_id`, `peer_id`, `file_id`); `protocol.on()` returns the protocol, so remove listeners with `protocol.off()`; `priority` takes the `MessagePriority` enum. The published web `@offline-protocol/id-react` 0.2.0 uses `appId` on `OfflineAppProvider` (`projectId` is deprecated). `@offline-protocol/id-react-native` is pinned at 0.3.3 in the CLI registry (appId from 0.3.2+). Flutter has a plugin preview (`offline-protocol-flutter`, the Dart package `offline_protocol` in the SDK repository) with the React Native module's transports and native surface (`MeshSdk`) from 0.31.0: it is not on pub.dev, so the app depends on its path in a checkout of the SDK. Java on the JVM (`offline-protocol-java`, on Maven Central as `com.offlineprotocol:offline-protocol-java`, JDK 22 or later), Ruby (`offline-protocol-ruby`, the `offline_protocol` gem on RubyGems from 0.31.0, Ruby 3.3 or later) and the C API (`offline-protocol-c`, `offline_protocol.h` and the shared library from the GitHub release) leave the transports to the host and take the native library from the release's desktop archives. The browser engine (`offline-protocol-web`, experimental from 0.31.0) runs a full node in a Web Worker with WebRTC, a nearby room, Nostr and, in Chromium, Web Bluetooth; its JavaScript client is built from the SDK repository and is not on npm. Python (`offline-protocol-sdk` on PyPI) and Rust (`offline-protocol` on crates.io) cover servers and desktops; with the `http` extra the Python service also serves an HTTP front, so programs that do not use the SDK call services on other devices with plain HTTP (see the `http-front` skill). Native Swift (`offline-protocol-swift`, a Swift package) and Kotlin (`offline-protocol-android`, on Maven Central as `com.offlineprotocol:offline-protocol-sdk` from 0.29.0, minSdk 24) are early previews in which the app wires transports and storage itself and API names may change. `offline-protocol-leaf` is the protocol crate firmware teams build on for ESP32 RISC-V, Cortex-M and WASI targets, with the radio, entropy, clock and storage coming from their firmware; for a ready device, Offline Protocol's IntelligenceMesh Relay (ESP32-PICO-V3-02) relays Offline Protocol mesh traffic over Bluetooth LE. The planning tools have no starter for any of these and return that limitation instead of a plan, so tell the user rather than switching frameworks silently. `.mcp.json` files written by `init_project` or a scaffold register the same pinned npx server; when this plugin already provides the server, do not add a second copy. +## Set up the developer's application (no portal) + +The local MCP server signs in with the CLI's developer session and has account tools for every portal setup step: `list_applications`, `create_application`, and, each idempotent, `app_status` (what is missing for sign-in on iOS, Android, web and server, with the fix), `detect_native_apps`, `register_native_app`, `remove_native_app`, `set_development_builds`, `set_development_mode` (simulators, emulators and Expo Go, 1-72 h), `set_production`, `set_android_degraded`, `attestation_history`, `configure_native_project` (Expo App Attest entitlement), `create_api_key` (writes the key to a gitignored env file), `set_allowed_origins`, `set_features` (telemetry, relay, proof-of-location) and `apply_project_setup` (converges to the `app` block of offline.config.json; `detect=true` registers the native apps the project ships). The same actions are CLI commands: `offline apps status`, `offline apps native …`, `offline apps origins …`, `offline apps features …`, `offline apply --detect`. If no session exists, run `offline login --email ` (it sends a code), ask the developer for the code once, and run `offline login --email --code `. + +Native OfflineID sign-in needs app attestation: register every iOS (bundle ID + Team ID) and Android (package + signing-certificate SHA-256) app the project ships, pass attestation providers to `OfflineAppProvider` (`@offline-protocol/id-react-native` 0.4.0 or later attests code requests and sign-ins; Expo: `createExpoAppIntegrityProviders` with `@expo/app-integrity`), and test on a physical device. API errors carry `data.missing` and `data.next_steps` naming the command to run; run it rather than guessing. Never send an `Origin` header from a native app to get around attestation. + ## Verify and hand off Run the checks appropriate to the edited application. State separately what compiled, what ran locally, and what was verified on physical devices. For an outage workflow, include restart, retry and recovery checks tied to the application's acceptance condition.