docs(web-ui/dashboard): document merge_config_pr approval card rendering
- 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.
This commit is contained in:
parent
d13ed94309
commit
f90c4a0ca9
1 changed files with 27 additions and 13 deletions
|
|
@ -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`.
|
||||
|
|
|
|||
Loading…
Reference in a new issue