PROGRAMME: Intent Browser — full implementation roadmap

# Intent Browser implementation programme

## Product thesis
Services provide authenticated data, domain rules, and executable capabilities. The browser/runtime owns the user's presentation, personal context, orchestration, and authorization. AI proposes representations and plans; deterministic software owns permissions, dispatch, verification, receipts, and recovery.

This repository should **not** become another browser with an AI chat sidebar. The primary product object is a persistent workspace that remains useful after the originating conversation is closed and when inference is unavailable.

## Product invariants
- Persistent workspace, not conversation, is the durable unit of state.
- Personal / Original / Evidence views remain synchronized but distinct.
- Every rendered action maps to an installed, authorized capability.
- Models and external agents never authorize themselves.
- Local/offline/hybrid modes are explicit; no hidden cloud fallback.
- Source observations, user overlays, and inferred/derived claims remain distinct.
- Risky writes are prepared, approved, committed, independently verified, and reconciled when ambiguous.
- Computer control prefers APIs/semantic accessibility over pixels/coordinates.
- Generated UI is declarative and bounded by default; generated executable code runs only through the extension review/sandbox path.
- Direct UI interactions such as sorting/filtering/navigation do not require an LLM.
- The user can stop execution, inspect accessed data/destinations, correct memory, export data, and return to the authentic source UI.

## Programme phases
- **P0** — Feasibility, contracts, security model, fixtures
- **P1** — Persistent local-first runtime
- **P2** — Connector-centric personalized interfaces
- **P3** — Complete harness, coding agents, PC execution
- **P4** — Full core feature alpha, trusted writes, automation
- **P5** — Adaptive reusable desktop beta
- **P6** — Multi-device platform, SDK, ecosystem
- **P7** — Daily-driver general release
- **P8** — Dedicated desktop session / OS distribution
- **K0–K4** — Separate Rust-kernel research and delivery programme

## Engineering strategy
Rust owns the trusted supervisor, contracts, policy/capability broker, semantic/evidence model, workspace state, transaction journal, connector broker, desktop broker, extension host, and evaluation harness. Chromium/CEF, local inference runtimes, speech engines, and external coding agents remain replaceable workers/adapters behind explicit contracts.

## Release definition
A capability is not "done" because a demo or model says it worked. It is done when its stated acceptance criteria, conformance tests, security constraints, recovery behavior, and supported-platform matrix pass.

## Anti-wrapper release test
For supported workflows the user must be able to:
1. Create a useful source-backed workspace.
2. Close the conversation and restart.
3. Continue using deterministic workspace interactions.
4. Inspect original sources and evidence.
5. Disable inference without losing the application.
6. Change agent/model providers without losing workspace/task state.
7. Execute only explicitly authorized capabilities.
8. Receive a verified result or an honest unresolved/reconciliation state.

## Workstream epics
- [ ] #13 Runtime and contracts
- [ ] #14 Authority and security
- [ ] #15 Conventional browser and compatibility
- [ ] #16 Workspace experience
- [ ] #17 Semantic and evidence substrate
- [ ] #18 Connector platform and domain packs
- [ ] #19 Intent-driven UI and portable applications
- [ ] #20 Harness and required provider integrations
- [ ] #21 Built-in local intelligence
- [ ] #22 Speech and contextual interaction
- [ ] #23 Desktop and native execution
- [ ] #24 Coding workspace and artifacts
- [ ] #25 Research and synthesized publications
- [ ] #26 Trusted transactions
- [ ] #27 Shopping, bidding and post-purchase
- [ ] #28 Social, communications and calendars
- [ ] #29 Inspectable memory and learned workflows
- [ ] #30 Schedules, events and attention
- [ ] #31 Sync, mobile and collaboration
- [ ] #32 Extensions, SDKs and ecosystem
- [ ] #33 Evaluation, release and daily-driver quality
- [ ] #34 Standalone OS and Rust-engine programme

## Backlog structure
Implementation issues use stable IDs (`CORE-*`, `SEC-*`, `WEB-*`, `WS-*`, `DATA-*`, `CONN-*`, `UI-*`, `AGENT-*`, `LOCAL-*`, `VOICE-*`, `PC-*`, `CODE-*`, `RES-*`, `TX-*`, `SHOP-*`, `SOC-*`, `MEM-*`, `AUTO-*`, `MESH-*`, `SDK-*`, `EVAL-*`, `OS-*`). IDs are part of the architecture and should not be recycled.

No implementation files, tests, or single entry point are named; begin by reading the P0 feasibility, contracts, security model, and fixtures goals, then trace how they support the Rust-owned supervisor and capability broker. Done is not defined by a demo: the relevant phase must meet stated acceptance criteria, conformance tests, security constraints, recovery behavior, and supported-platform requirements.

Written by the indexing model from the issue text.