Desktop App Foundation v1
The local foundation turns the existing Integration Studio handoff into a runnable loopback application without choosing a permanent desktop framework. It preserves the exact resolver contract, validates the first-party bootstrap before sending text, and records action authorization as a separate non-executing step.
Run from the extracted root package
Use Python 3.10 or newer. The presentation shell and network client use only the Python standard library. The existing repository test suite may use its declared development dependencies, but no additional desktop framework is required for this foundation.
Keep desktop_foundation.py, desktop_app/, integration_studio.py, integration_readiness.py, machine_agent_contract.py, and docs/ together.
The server rejects non-loopback binds and does not make a remote request during import or startup.
Add --open-browser to request the operating system’s default browser.
python -m desktop_app --open-browserpython desktop_foundation.py \
--recipe workflow-routing \
--output desktop-state.jsonThe generated state carries a recomputable SHA-256 digest and deterministic history. The browser prototype keeps state in memory; closing it discards live evidence and the next start returns to offline mode.
First-release workflow
Select one of the five canonical use cases. The app regenerates and verifies the unchanged deterministic Integration Studio kit.
Replay all six fixed fixtures. Only resolved-valid receives the exact code and registry version; the other five retain no identity fields.
After a user checks the consent control, fetch the body-free bootstrap and verify its canonical origin, readiness, and same-origin resolver request.
Send only the exact expression and optional known language. Preserve the full returned envelope and every abstention or error.
Record a policy outcome and reason. The prototype performs no memory write, route, tool call, publication, spend, deletion, or other side effect.
Local security and privacy
127.0.0.1 or localhost; remote interfaces are rejected.X-Embedded-Semantics-Desktop: 1.expression and optional language.Fail-closed behavior
Reject the bootstrap before an expression is sent.
Record request/service error evidence; assign no ConceptCode.
Record malformed or unsupported evidence; assign no ConceptCode.
Preserve unknown_expression; do not guess or synthesize identity.
Preserve ambiguous_expression; do not choose from candidates.
Preserve the error evidence; do not convert HTTP success or failure into semantic success.
Optional local-model boundary
A local LLM is an advisory client capability, not registry authority. It may help the user identify the exact expression to send or explain already-selected public evidence. It cannot invent, repair, translate, normalize, approximate, or select a ConceptCode.
The user-selected expression, optional known language, user-selected public resolver evidence, and the public tool contract.
Credentials, hidden prompts, unrelated private conversation or files, automatic background exports, or action authority.
The user explicitly enables HTTPS. The resolver envelope is validated by the client record contract. Independent policy controls every external side effect.
Reversible architecture decision
It proves product flow, security boundaries, and state semantics without locking the project into a desktop framework before platform evidence exists.
Promising packaging candidate, but the required Rust/platform toolchain is not assumed here.
Mature but too heavy to select before measured packaging and maintenance evidence.
Viable native option, deferred until dependency, licensing, and platform tests are authorized.
Next bounded phase
The next phase should pick one target operating system, wrap the existing local state/API boundary, measure accessibility and bundle behavior, define update provenance and rollback, and produce an unsigned local test artifact before any distribution signing or app-store work.