# Current Governance Inbox Inventory

**Feature**: 389 - Governance Inbox Resolution Intake v1
**Captured**: 2026-06-19
**Purpose**: Inventory the existing Governance Inbox before implementation.

## Repo Safety Snapshot

- Branch before preparation: `platform-dev`
- Latest baseline commit before preparation: `83c679cf feat: add review publication proof currentness contract (#459)`
- New preparation branch: `389-governance-inbox-resolution-intake-v1`
- Worktree before creating Spec 389 artifacts: clean
- Current dirty scope after preparation: `specs/389-governance-inbox-resolution-intake-v1/` only
- Spec 386 status in repo: present and merged into platform history through `ba7622a1 feat: implement ReviewPublicationResolutionWorkflow (Spec 386) (#457)`
- Spec 387 status in repo: present and merged into platform history through `aca0b106 feat: add review publication resolution ux spec and tests (#458)`
- Spec 388 status in repo: present on current baseline through `83c679cf feat: add review publication proof currentness contract (#459)`

## Existing Route / Page / Resource

The Governance Inbox is an existing Filament Page:

- Page class: `apps/platform/app/Filament/Pages/Governance/GovernanceInbox.php`
- View: `apps/platform/resources/views/filament/pages/governance/governance-inbox.blade.php`
- Slug: `governance/inbox`
- Navigation group: workspace-wide Governance group
- Navigation label: `Governance inbox`
- Navigation sort: `5`
- Action surface declaration: list-only, read-only registry report

Spec 389 must reuse this page. It must not add a new top-level navigation item, CRUD Resource, global-search Resource, or independent Resolution Cases page.

## Existing Builder Pattern

The current page consumes `GovernanceInboxSectionBuilder`:

- Builder class: `apps/platform/app/Support/GovernanceInbox/GovernanceInboxSectionBuilder.php`
- Public entry point: `build(...)`
- Inputs include current user, workspace, authorized environments, visible finding environments, review environments, alert/finding-exception visibility, selected environment, selected family, and canonical navigation context.
- Output includes:
  - `sections`
  - `available_families`
  - `family_counts`
  - `total_count`

The builder currently owns source-family sections and returns source entries. The Filament Page normalizes those entries into first-screen operator lanes.

## Existing Source Families

Current `FAMILY_ORDER`:

1. `assigned_findings`
2. `intake_findings`
3. `finding_exceptions`
4. `stale_operations`
5. `alert_delivery_failures`
6. `review_follow_up`

Spec 389 should add only one concrete family:

```text
review_publication_resolution
```

It should be ordered so failed/blocked review publication preparation appears with other high-attention governance work, without changing the meaning of existing families.

## Existing Lane Pattern

The first screen groups normalized entries into lanes in `GovernanceInbox::lanePayload()`:

- `needs_triage`
- `requires_decision`
- `risk_exception_review`
- `evidence_required`
- `blocked`

Entries are converted by `buildOperatorItem()` into a common display shape:

- lane key and label
- title
- status label
- reason heading
- reason label
- impact label
- source label
- environment label
- context label
- owner and due labels
- evidence and exception labels
- primary action
- secondary actions
- linked records
- urgency rank

Spec 389 can map Review Publication Resolution items into existing lanes:

- `failed`, `blocked`, unsafe waiting failures: `blocked`
- `needs_attention`, `needs_recheck`, `ready_to_continue`: `requires_decision` or `evidence_required` when the reason is specifically missing proof/evidence
- `waiting`: `requires_decision` or a low-rank item, unless the existing lane language is adjusted in implementation

Any lane copy changes must stay decision-first and read-only.

## Existing Filters

The page currently exposes:

- environment filter through `environment_id`
- source-family filter through `family`

The source detail section renders family filter links and counts. Empty states adapt to environment/family filters.

Spec 389 should use:

- `family=review_publication_resolution` as the type filter equivalent
- existing `environment_id` filtering
- bounded status filtering for Review Publication Resolution inbox states
- bounded updated-date filtering for Review Publication Resolution items, limited in v1 to `Any time`, `Last 24 hours`, `Last 7 days`, and `Last 30 days`
- no generic resolution-type registry

Status and updated-date filtering must follow existing page patterns or remain tightly bounded to this family.

## Existing Action / Link Pattern

The existing renderer supports:

- one primary action per operator item
- source-family dominant action
- secondary actions
- linked records inside collapsed context
- destination URLs on source entries

Existing source families use links such as:

- Finding view/resource URLs
- Finding exception queue/resource URLs
- OperationRun links through `OperationRunLinks`
- Review context links through `EnvironmentReviewResource`
- Customer Review Workspace links

Spec 389 should use:

- default primary action: Resolution Page
- secondary action: Review detail when authorized
- optional operation action: only after scope/currentness/context/RBAC validation

No action may mutate resolution, review, report, evidence, export, OperationRun, or publish state from the inbox.

## Existing Operation Link Rendering

The current stale operation family renders OperationRun entries as a source family and uses:

- `OperationRunLinks::identifier($run)`
- `OperationRunLinks::tenantlessView($run, $navigationContext)`
- `OperationRunLinks::index(...)`

That pattern is not sufficient by itself for Spec 389 operation disclosure. Review Publication Resolution operation links need extra validation:

- same workspace
- same environment
- same EnvironmentReview where applicable
- same Resolution Case where applicable
- current step or current safe proof summary
- expected operation type
- Spec 388 currentness/visibility/usability
- `OperationRunPolicy::view`

If any check fails, the inbox must not render the OperationRun ID or URL.

## Existing RBAC and Scope Enforcement

The page enforces workspace membership on mount. Source families receive prefiltered environment arrays:

- authorized environments
- visible finding environments
- review environments

`ReviewPublicationResolutionCasePolicy::view` already verifies:

- case tenant exists
- case review exists
- user can access tenant
- case workspace matches tenant workspace
- review workspace and environment match case/tenant
- current user has `ENVIRONMENT_REVIEW_VIEW`

`OperationRunPolicy::view` already verifies:

- workspace membership
- environment entitlement for environment-scoped operations
- operation-specific view capability

Spec 389 must use these policies but operation links require additional source-context checks beyond permission.

## Existing Empty States

The page has:

- summary empty state when no lanes are visible
- lane empty states
- source-family empty states
- environment filter empty states
- family filter empty states

Spec 389 required copy:

- `No review publication work needs attention`
- `No accessible review publication work`
- `No items match this filter`

Implementation should place this copy in the new source family and page-level empty state only where it does not misrepresent other source families.

## Existing Collapsed Details

The first-screen item shows:

- status badge
- environment badge
- title
- context label
- primary action
- reason and impact

Collapsed `More context` shows:

- source
- owner / due
- evidence
- accepted-risk / decision
- linked records
- secondary actions

This matches Spec 389's detail hierarchy. Technical proof/currentness internals should remain absent or collapsed behind already-authorized source surfaces.

## Existing Review Publication Resolution Foundations

Relevant runtime files for later implementation:

- `apps/platform/app/Models/ReviewPublicationResolutionCase.php`
- `apps/platform/app/Models/ReviewPublicationResolutionStep.php`
- `apps/platform/app/Support/ReviewPublicationResolution/ReviewPublicationResolutionCaseStatus.php`
- `apps/platform/app/Support/ReviewPublicationResolution/ReviewPublicationResolutionStepStatus.php`
- `apps/platform/app/Support/ReviewPublicationResolution/ReviewPublicationProofResolver.php`
- `apps/platform/app/Support/ReviewPublicationResolution/ResolutionProofEvaluation.php`
- `apps/platform/app/Policies/ReviewPublicationResolutionCasePolicy.php`
- `apps/platform/app/Policies/OperationRunPolicy.php`
- `apps/platform/app/Filament/Resources/EnvironmentReviewResource/Pages/ResolveReviewPublication.php`

Existing case statuses:

- `open`
- `in_progress`
- `waiting_for_run`
- `blocked`
- `ready_to_continue`
- `completed`
- `cancelled`
- `superseded`

Existing step statuses:

- `pending`
- `actionable`
- `running`
- `failed`
- `completed`
- `superseded`

Spec 389 should consume these states and Spec 388 proof evaluation. It should not add a new data model or persisted status family.

## Implementation Implications

- Best fit is either a concrete `ReviewPublicationResolutionInboxProvider` or a tightly scoped builder method.
- Reuse existing page rendering wherever possible.
- Add the family to `FAMILY_ORDER` and `available_families` only when visible.
- Add classifier support for the new family in `GovernanceInbox::classifyLane()`.
- Add secondary/linked record handling only for Resolution, Review, and validated Operation links.
- Keep technical details collapsed or absent.
- Keep customer-facing surfaces untouched.
- No panel provider registration changes are needed.
- No new Filament assets are expected.