PocketPi
Browse documentation

Start here

OverviewGetting startedThe mental model

Use the runtime

Run the simulatorPi Agent and workspaceInstall and manage AppsESP32-P4 reference targetESP32-S3 supported target

Build Apps

App developer guideBuild your first AppApp source and packageData and migrationsActions and ToolsView and interactionNetworking and native servicesApp resourcesSchedulesPackage and updateTesting and debugging

Understand the runtime

Runtime flowGuests and lifecycleLayers and ownershipHarness boundary

Security

Trust and capabilitiesData isolationLifecycle and recovery

Reference

App manifestPocketPi APIView APICLI referenceLimits and compatibility

Examples

Exa App walkthroughRobinhood App walkthrough

Project

Current boundariesValidation status

Validation status

Validation is reported by evidence tier. Dates and counts below are the latest records checked into upstream/main; they are not a substitute for rerunning acceptance on a new commit, provider configuration or physical board.

Evidence ladder

repository source
  → Rust/App contract tests
  → simulator end-to-end
  → ESP32-P4 and ESP32-S3 release builds
  → physical boot/display/touch/storage per board
  → fresh Wi-Fi/provider/App end-to-end

Recorded on 2026-08-24

  • 57 Rust tests completed without failure.
  • workspace Clippy passed with warnings denied.
  • Pi Agent assets, shared View SDK, simulator, ESP32-P4 release firmware and ESP32-S3 release firmware built.
  • core tests covered viewport propagation and scaling, minimum touch targets, App lifecycle, SQLite ownership and model/Tool contracts.
  • physical P4 coverage includes the Agent, workspace, schedules, App install/update/uninstall, display/touch, Wi-Fi and direct model providers.
  • physical S3 coverage includes boot, 480×800 logical scanout, GT911 touch, integrated Wi-Fi, workspace Tool Calls, ordinary App install and an Exa request.

Evidence remains board-specific

P4 has the broader reference-target history, including update and uninstall. S3 physical evidence proves the shared runtime and source App contract on its current board composition, but it does not inherit P4-only stress or lifecycle results. Long-running latency, display stability and memory-pressure testing remain separate acceptance work on both targets.

Current automated contract coverage

  • View and Action LRUs retain the three most recent ordinary Guests.
  • Tool routing selects each App's declared Action.
  • App revisions coalesce at a foreground frame boundary.
  • code-only update preserves data and native credentials.
  • schema update rejects missing steps and preserves rows.
  • boot finishes an approved update interrupted before activation.
  • schedule success records only after the Action completes.
  • Projection/SQLite errors propagate rather than becoming an empty View.
  • uninstall removes App-owned routes, runtimes, schedules, credentials and data.

Not yet implied by those checks

  • phone upload on every network topology;
  • a fresh live provider call for every current commit;
  • unattended long-duration memory pressure;
  • physical acceptance of a future DeepSeek Harness build;
  • a future third-board port or a web Playground.

How to report a new result

Record the exact commit, build command, board/host, provisioned backend, whether storage was erased, the observable pass/failure and the highest completed tier. Keep failures such as Wi-Fi association or DHCP timeout attached to the network-dependent acceptance instead of calling a successful boot complete end-to-end validation.

Checked-in evidence summary: README current validation ↗.