Skip to content

Agent-trust + identity pass: make the built product match its design system (#170 P1) #174

Description

@hellno

The grounded flow audit (first step of #170, PR #172) found the app's bones strong and on-brand — the overhaul is a consistency/trust pass, not a redesign. This issue groups the four load-bearing (P1) findings into one effort an agent can pick up against the design system once #172 merges. Do these four together; they're where the "autopilot you can trust and stop" promise currently leaks.

Ground every change in DESIGN.md + the golden mockups (designs/deckard-editorial-v3.html, designs/deckard-agent-v4.html) and the audit's screenshots (docs/screenshots/audit-170/). Reuse widgets.rs / tokens.rs; don't hand-roll.

1. Wallet identity should never collapse to "Personal / Wallet"

An unnamed wallet makes the breadcrumb read the literal word "Wallet" and the page-header H1 fall back to the project name ("Personal"). DESIGN: the breadcrumb current names the entity, never the literal "Wallet"; the golden ref shows Personal › Main.

  • Derive a real default wallet name (ENS → short address → "Wallet 1"); never the literal "Wallet", never the project name as the wallet title.
  • Files: the breadcrumb + page_header in shell.rs routing; wallet display source; Settings → Profile display_name (settings.rs).
  • Evidence: audit-170/02-home-dark.png, 07-send-clearsigning.png.

2. One shared clear-signing review (kill the boxed agent-approval variant)

Send uses the transaction-as-hero review (commit_view.rs:263); the agent approval uses a different, weaker boxed key/value card (activity_view.rs:830, render_activity_review). DESIGN: "the same review renders for an agent's proposal awaiting approval… a statement, not a form… never a gray box."

  • Route the agent approval through the same transaction-as-hero engine; surface the cited/breached limit as the danger/caution line; keep the no-blind-approve invariant and the ⌘↵ approve / x deny / Esc keys.
  • Evidence: audit-170/07-send-clearsigning.png (target) vs 14-agent-approval-card.png (current).

3. Make the agent surface editable (it's a read-only policy dump today)

The agent surface has the right bones (cyan "Atlas · acting", autonomy statement, limits, budget gauge, red Revoke & STOP) but is display-only: no per-row Edit affordances, the Pause / Rotate key / Adjust limits controls render dimmed, there's no "What Atlas did" feed, and Scope is folded into one flat LIMITS list. DESIGN's agent-model pivot was "a dedicated agent surface owns editable policy + controls + its own activity… the old read-only policy dump on the home is removed" — today it moved rather than became editable.

  • Add per-row Edit, wire Pause/Rotate/Adjust, add the agent's slice of the activity feed, split Scope (allowed actions/assets, session-key expiry) from Limits. Match designs/deckard-agent-v4.html.
  • Also add an "Open agent / Atlas" ⌘K command (palette_commands.rs + shell.rs run_palette_command) — the agent surface is currently not ⌘K-reachable (CLAUDE.md violation).
  • Evidence: audit-170/11-agent-surface.png.

4. Displayed cap must equal the enforced cap

The agent advertises "Per-transaction cap 0.1 ETH / asks above 0.1", but a 0.15 ETH shield auto-approved and broadcast (shields have no per_tx_cap_wei in policy.demo.json, so they're gated only by the 0.5 daily cap). On a trust wallet the shown cap must match the enforced gate.

  • Either enforce a per-tx cap on shields or make the surface state the actual gate per action ("Shields: capped by daily budget"). Reconcile the autonomy statement, the LIMITS rows, and the policy evaluation.
  • Evidence: the agent run log in the audit + 11-agent-surface.png, 13-activity-needsyou.png.

Guardrails (it's a wallet)

Don't regress clear-signing, the no-blind-approve invariant, or STOP. Keep every action ⌘K-reachable. Full DoD + before/after screenshots per change (see CLAUDE.md §Visual verification; drive the funded just demo).

Refs #170. Details + P2/P3 backlog in docs/research/11-ia-flows-audit.md.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions