From f90c4a0ca914830625b8e22c4a29f6c310401bca Mon Sep 17 00:00:00 2001
From: iris <iris@hyperhive.local>
Date: Thu, 2 Jul 2026 21:40:23 +0200
Subject: [PATCH] docs(web-ui/dashboard): document merge_config_pr approval
 card rendering
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- Per-kind glyph/chip/sha table covers all 6 kinds: apply_commit (→,
  apply), merge_config_pr (⇒, merge-pr), update_meta_inputs (↻,
  meta-update), schedule_prompt (⏱, schedule), init_config (⊕, init),
  spawn (⊕, spawn)
- Document 'review PR on forge ↗' link in the what-changed body
- Clarify inline diff side-panel is apply_commit-only
- Supersedes #1939 (lexis's PR)

Closes #1939.
---
 docs/web-ui/dashboard.md | 40 +++++++++++++++++++++++++++-------------
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/docs/web-ui/dashboard.md b/docs/web-ui/dashboard.md
index 041235fa..d6f036f9 100644
--- a/docs/web-ui/dashboard.md
+++ b/docs/web-ui/dashboard.md
@@ -963,21 +963,35 @@ every render before the bar appears.
 Each pending approval renders as a card (`assets/tabs.js::
 renderApprovals`) with three stacked sections:
 
-- **identity header** — glyph, `#id`, agent, kind chip, (for
-  `apply_commit`) the short proposal sha as `<code>`, and a
+- **identity header** — glyph, `#id`, agent, kind chip, and a
   right-aligned `requested <N> ago` relative time from
-  `ApprovalView.requested_at`. The chip ticks live every second
-  via a `data-requested-at` attribute + client-side interval (no
-  re-render). Turns amber once the request has been pending ≥ 1h
-  so a stale approval stands out; the `.stale` class flips
-  precisely at the 3600s boundary rather than at the next
-  `renderApprovals` call.
+  `ApprovalView.requested_at`. Glyph and chip vary by kind:
+
+  | kind | glyph | chip | sha shown |
+  |---|---|---|---|
+  | `apply_commit` | `→` | `apply` | proposal sha (`sha_short`) |
+  | `merge_config_pr` | `⇒` | `merge-pr` | PR-head sha (`sha_short`) |
+  | `update_meta_inputs` | `↻` | `meta-update` | — |
+  | `schedule_prompt` | `⏱` | `schedule` | — |
+  | `init_config` | `⊕` | `init` | — |
+  | `spawn` | `⊕` | `spawn` | — |
+
+  The chip ticks live every second via a `data-requested-at`
+  attribute + client-side interval (no re-render). Turns amber once
+  the request has been pending ≥ 1h so a stale approval stands out;
+  the `.stale` class flips precisely at the 3600s boundary rather
+  than at the next `renderApprovals` call.
 - **what-changed body** — the submitting agent's description, then
-  drill-in triggers: `↳ view diff` opens the diff in the side
-  panel; `↳ commit on forge ↗` deep-links the proposal commit
-  into `agent-configs/<agent>` (shown only when `forge_present`).
-  Spawn approvals show a one-line "container will be created"
-  note instead.
+  kind-specific drill-in triggers:
+  - `apply_commit`: `↳ view diff` opens the inline diff side-panel;
+    `↳ commit on forge ↗` deep-links the proposal commit into
+    `agent-configs/<agent>` (shown only when `forge_present`).
+  - `merge_config_pr`: `↳ review PR on forge ↗` deep-links the
+    config PR into `agent-configs/<agent>/pulls/<pr_number>` (shown
+    only when `forge_present` and `pr_number` is set). No inline diff
+    side-panel (apply_commit-only for now).
+  - `init_config` / `spawn`: a one-line "container will be created"
+    note instead.
 - **decision actions** — `◆ APPR0VE` and `DENY`. Deny pops a
   `prompt()` for an optional reason carried to the submitting agent as
   `HelperEvent::ApprovalResolved.note`.