fix(permissions): validate network access flow
This commit is contained in:
@ -1,19 +1,10 @@
|
||||
---
|
||||
name: ticket103-network-permission-ux-surface
|
||||
description: memory note ticket103-network-permission-ux-surface
|
||||
description: Stable UX convention for agent network permissions in IdeA.
|
||||
metadata:
|
||||
type: project
|
||||
type: reference
|
||||
---
|
||||
---
|
||||
title: "Ticket #103 - UX surface for network permission"
|
||||
type: reference
|
||||
description: "Stable UX convention for exposing network permission in IdeA: Permissions panel as primary editor, Agents as compact summary, Terminal as contextual failure surface, and explicit runtime-locked state."
|
||||
---
|
||||
|
||||
# Ticket #103 — UX surface for network permission
|
||||
|
||||
- Keep a single primary edit surface in `Permissions > Système`.
|
||||
- Mirror the effective network state in the Agents list as a compact badge.
|
||||
- Use the Terminal only for contextual, actionable failures.
|
||||
- Distinguish clearly between user policy, effective state, and runtime lock.
|
||||
- If the runtime cannot elevate permission in the active session, the control must be read-only and the UI must say so explicitly.
|
||||
- Editability must follow the resolved control state, not simply whether an agent exists.
|
||||
- Non-launched agents stay editable unless a runtime lock is explicitly present.
|
||||
- Read-only messaging should be explicit only for active locked runtimes, especially external/uninspectable runtimes.
|
||||
- Effective policy labels must not be used as a proxy for editability.
|
||||
Reference in New Issue
Block a user