feat(gain-web): Tirith trust manager pane (write-side, depends #162)

[thehoff]

Background

ContextCrawler's Tirith gate ([#33 / #32] context) blocks commands at the loopback hook layer, then writes downgrade events to `~/Library/Application Support/contextcrawler/downgrades.jsonl`. When the gate fires on a legitimate command, the escape hatch is `tirith trust add --scope repo --rule <rule_id>` from the shell.

The dashboard's Security pane (#171) shows every downgrade. It doesn't let you act on them.

Problem

A real operational flow looks like:

1. Hoff runs `agy --add-dir ...` for peer review.
2. Tirith gate flags `agy` as an editable / path / URL token because the prompt body includes `https://` examples.
3. Block lands in the Security pane.
4. Hoff has to flip to a shell, recall the rule_id, run `tirith trust add`, re-run the command.

The roundtrip breaks the dashboard's promise of "glanceable status" — every action requires context-switching back to terminal.

Proposed scope

First write-side feature on the dashboard

This is the first feature that mutates state from the loopback UI. Pattern to establish for later write features (#TBD #175 council annotations, etc.).

New endpoints

```
GET /api/security/trust → list current entries from tirith trust list --json
POST /api/security/trust → add an entry (body: {host, scope, rule_id})
DELETE /api/security/trust/ → remove
```

All three shell out to the `tirith trust` CLI — never poke Tirith's config files directly (config schema is upstream-owned).

Frontend behaviour

• New "Trust manager" sub-pane under Security
• Each recent downgrade row gets an inline [Trust this rule] button
  • Click → modal showing the suggested `{host, scope, rule_id}` populated from the downgrade event
  • Explicit confirm required — two-step interaction, not one-click (this is a security control we're loosening)
  • Modal also shows the blast radius: "this will allow any command matching from in "
• Existing entries listed in a table with [Revoke] button per row

Loopback-only contract preserved

Server still binds 127.0.0.1 only. No CSRF protection needed (loopback + no shared cookies). But:

• Log every write action to `~/Library/Application Support/contextcrawler/trust_actions.jsonl` (timestamp, action, payload) — gives an audit trail mirroring the gate's own logs.
• Display the most recent 10 trust changes in the pane so the user always sees what was last modified.

Out of scope (v1)

• Editing rule definitions (only add/remove existing rules).
• Bulk operations.
• Trust suggestions / ML-driven recommendations.
• Anything that talks to a remote Tirith server.

Effort

M. ~1 week.

• 3 endpoints + tests (incl. CLI subprocess wrapping with proper error surfacing): 2 days
• Frontend pane + modal + confirm UX: 2 days
• Audit log + display: 1 day
• Doc + screenshot + peer-review pair: 1 day

Why now

Single-model pick (Claude only in 3-way brainstorm 2026-05-25), but the operational gap is real. Closes the loop between "I see the block in the dashboard" and "I can act on it without flipping back to shell". Becomes the pattern for all future write-side features.

Dependencies

• feat(gain): --web flag — local dashboard server #162 (dashboard surface) — merged or about-to-be
• feat(gain-web): security + supply-chain pane (tier 1 / depends #162) #171 (Security pane) — merged or about-to-be

Risk

Loosening the gate from the UI is a security-relevant action. The two-step confirmation + audit-log + blast-radius display are non-negotiable parts of v1; do not ship the endpoint without them.

[thehoff]

Status 2026-08-19: not started. No commits, no branch, no PR.

First write-side pane — establishes the write-mutation pattern that #177 (the other write-side pane) will reuse. hooks/trust.rs + hooks/tirith_gate.rs exist (CLI side: tirith trust add/remove/list); dashboard needs the 3 endpoints + Trust manager sub-pane + two-step confirm modal + trust_actions.jsonl audit.

Per the issue's Dependencies section (quoted): "#162 (dashboard surface) — merged or about-to-be. #171 (Security pane) — merged or about-to-be." #162 is shipped; #171 is code-complete on the closed PR #178 branch (fb9130bf tier 1 — security pane) but not yet in develop. #171 is a sibling read-only pane, not a runtime blocker for this write-side work, but landing first keeps the SPA+nav consistent.

Loopback-only contract is already enforced (server binds 127.0.0.1). Audit log + blast-radius display in the modal are non-negotiable v1 — do not ship without them, per the issue's own risk section. Effort M (~1 week).