Developer install: run your own unreleased app on your own OctoSense, desktop and mobile #404

Requirement

A developer must be able to run their own app on their own OctoSense — desktop and mobile — before it is published, and catch there what the SDK cannot tell them: a widget the release does not define, a host method that refuses non-system apps, a provider that is not configured. The app they run must go through the same runtime, the same admission check and the same policy a store install does, so what the developer sees is what their users will get.

Today

• Every released store (desktop-v0.1.0-beta.1 through rc.1) refuses an unsigned bundle. A developer cannot install their own unreleased app into a shipped shell.
• card-host runs an unsigned bundle but registers no host services, so an app that uses mail, calendar, model or any other service cannot be exercised in it.
• The only rehearsal path (App Flow PUBLISHING §4) is a shell built from source with a local, key-signed test catalog — a maintainer's workflow, not a developer's, and unverified with a GitHub-attested release.

The developer docs therefore tell contestants that generation APIs "work on rc.1" while giving them no way to run their own app on rc.1.

Proposal

1. A developer install in the shipped shell. Behind an explicit developer toggle, the store installs a local bundle directory or pack: it runs hub check-equivalent admission on it (structure, contents, policy, listing), installs it under the same jail and policy as a store app, and marks it in the launcher and Library as developer-installed and unsigned. No catalog entry, no key, no network. Uninstall and update are the ordinary paths.
2. Mobile too. Android: a file picker or adb push into a developer inbox the shell watches. iOS: whatever the platform allows for a developer's own device; if nothing does, the gap is documented rather than papered over.
3. Same checks, not fewer. A developer install never relaxes admission or policy; it only replaces the catalog as the source of the bundle. Anything a developer install refuses, a store install would refuse too.
4. SDK side. tools/octo gains an install <shell> step that packs the bundle and hands it to the developer install, so "run it on my OctoSense" is one command from the app directory.

Relation to other work

• OctoSense Octoscript apps cannot play model.audio or model.video results: wire AudioPlayer, document Video #403 (playback) and App Hub toolbox: the dossier template; search categories; resolved_url and publisher_host #172 (API support at admission) both exist because developers cannot currently discover these gaps on a real host. This is the path that lets them.
• The per-app runtime gates are the subject of a separate, currently paused decision; this proposal is independent of it, since admission and policy apply either way.

🤖 Generated with Claude Code