ahmido
8cffdbdb2c
Implemented the final operator workflow for the Governance Inbox. This includes refactoring the inbox page, updating finding resources, adding UI enforcement policies, updating related blade views, and adding comprehensive tests for operator workflow and scope contracts. Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #418
118 lines
3.8 KiB
Markdown
118 lines
3.8 KiB
Markdown
# 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
|