TenantAtlas/specs/389-governance-inbox-resolution-intake-v1/artifacts/current-governance-inbox-inventory.md

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:

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.