# UI-004 Governance Inbox

| Field | Value |
| --- | --- |
| Route | `/admin/governance/inbox` |
| Source | `GovernanceInbox` |
| Area / scope | Governance / workspace |
| Archetype | Findings / Inbox |
| Design depth | Strategic Surface |
| Repo truth | repo-verified |
| Screenshot | `../screenshots/desktop/ui-004-governance-inbox.png` |
| Browser status | Re-validated through Spec 346 browser smoke and spec-local screenshots. |

## Before / After Hierarchy

Before Spec 346:

1. Secondary scope chips
2. Decision workbench
3. Detail aside
4. Queue context by source family

After Spec 346:

1. Operator summary with direct `Next recommended action`
2. Primary inbox lanes
3. Recently resolved secondary disclosure
4. Source detail disclosure
5. Diagnostics disclosure

## Current Productized Model

Governance Inbox now behaves as the operator command surface for governance follow-up, not as a section-first technical list.

The first screen answers:

- What is open right now?
- What is the next recommended item?
- Which lane is it in?
- Why does it matter?
- What is the next action?
- Which source, proof, or review surface is linked?

## Lane Model

Primary active lanes are derived from existing repo-backed entries only:

- `Needs triage`
- `Requires decision`
- `Risk / exception review`
- `Evidence required`
- `Blocked`

Secondary disclosure:

- `Recently resolved` comes from the existing Decision Register builder and stays visually subordinate to active work.

Intentionally omitted:

- `Review-ready` is not shown because the current page has no bounded repo-backed review-ready truth.

## Scope Contract

- Governance Inbox remains workspace-owned.
- Visible local scope uses canonical `environment_id`.
- Clean entry stays workspace-wide and does not inherit remembered environment scope.
- Clear-filter behavior returns to the clean workspace URL.
- Governance Inbox first-party links do not emit retired public query aliases:
  - `tenant`
  - `tenant_id`
  - `managed_environment_id`
  - `environment`
  - `tenant_scope`
  - `tableFilters`

## Operator Workflow Notes

- Active work is grouped by operator path, not by source family.
- The first viewport promotes a prioritized top item with a direct primary action instead of an indirect lane-review CTA.
- Each active card keeps one dominant next action, with title, lane/status, environment, reason, and impact visible.
- Linked records, source, owner/due, evidence, accepted-risk/decision detail, and secondary actions stay available under `More context`.
- Zero-count lanes are demoted into compact `Clear` chips/status instead of equal-weight lane cards.
- Existing source-family context is still available under `Source detail`.
- Diagnostics remain collapsed and source-owned.
- Emitted `#lane-*` links are covered by browser smoke so the target lane scrolls/anchors correctly.

## Customer / Legal Language Boundary

The page remains internal/operator-facing and uses safe operational wording such as:

- `accepted risk`
- `decision`
- `requires attention`
- `blocked`
- `open review context`

It avoids legalistic or customer-signoff claims.

## Deferred Follow-Ups

Not addressed inside Spec 346:

- Provider-readiness/onboarding productization beyond truthful existing links
- Review-ready derivation on the inbox itself
- New mutation workflows or new governance persistence
- Customer portal / PSA handoff

## Current Outcome

Spec 346 now addresses the main productization gap identified in the earlier audit, but the spec is intentionally not closed in this pass:

- one dominant queue-clearing model now exists
- evidence/status/next-action are separated at the card level
- the first viewport now exposes a direct recommended item and primary action
- zero-lane weight and mobile card density are bounded
- source-family detail no longer dominates the first screen
- workspace/environment scope stays explicit and stable