Part of #517.
Context
Confirmations render in the terminal today, and truapi-host dev auto-approves every one of them. A product developer therefore never sees what a user sees, and code that mishandles a denied permission still looks correct locally. Auto-approval should be the shortcut, not the whole experience.
The CLI already serves the bridge the product loads, so it can also draw host-owned UI into the page, the way a mobile host draws its own sheet over a product.
Required behavior
- The bridge can render permission and confirmation prompts as an overlay in the product page, owned by the host and not by the product.
- Prompts sit close enough to the mobile hosts that a developer feels the same interruption, including denial.
- Manual approval is the default for those prompts; auto-approve stays opt-in for scripted runs.
- The terminal transcript still records every request, so
--script and CI runs are unaffected.
- Products with no standing grant get the full prompt path, which is what makes this useful for developers outside the trusted set.
Related: docs/rfcs/0002-permission-model.md.
Part of #517.
Context
Confirmations render in the terminal today, and
truapi-host devauto-approves every one of them. A product developer therefore never sees what a user sees, and code that mishandles a denied permission still looks correct locally. Auto-approval should be the shortcut, not the whole experience.The CLI already serves the bridge the product loads, so it can also draw host-owned UI into the page, the way a mobile host draws its own sheet over a product.
Required behavior
--scriptand CI runs are unaffected.Related:
docs/rfcs/0002-permission-model.md.