191-baseline-compare-operator-mode (#223)
## Summary <!-- Kurz: Was ändert sich und warum? --> ## Spec-Driven Development (SDD) - [ ] Es gibt eine Spec unter `specs/<NNN>-<feature>/` - [ ] Enthaltene Dateien: `plan.md`, `tasks.md`, `spec.md` - [ ] Spec beschreibt Verhalten/Acceptance Criteria (nicht nur Implementation) - [ ] Wenn sich Anforderungen während der Umsetzung geändert haben: Spec/Plan/Tasks wurden aktualisiert ## Implementation - [ ] Implementierung entspricht der Spec - [ ] Edge cases / Fehlerfälle berücksichtigt - [ ] Keine unbeabsichtigten Änderungen außerhalb des Scopes ## Tests - [ ] Tests ergänzt/aktualisiert (Pest/PHPUnit) - [ ] Relevante Tests lokal ausgeführt (`./vendor/bin/sail artisan test` oder `php artisan test`) ## Migration / Config / Ops (falls relevant) - [ ] Migration(en) enthalten und getestet - [ ] Rollback bedacht (rückwärts kompatibel, sichere Migration) - [ ] Neue Env Vars dokumentiert (`.env.example` / Doku) - [ ] Queue/cron/storage Auswirkungen geprüft ## UI (Filament/Livewire) (falls relevant) - [ ] UI-Flows geprüft - [ ] Screenshots/Notizen hinzugefügt ## Notes <!-- Links, Screenshots, Follow-ups, offene Punkte --> Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #223
This commit is contained in:
parent
65e10a2020
commit
f7bbea2623
5
.github/agents/copilot-instructions.md
vendored
5
.github/agents/copilot-instructions.md
vendored
@ -167,6 +167,8 @@ ## Active Technologies
|
||||
- PostgreSQL via Laravel Eloquent with one new table `tenant_triage_reviews` and no new external caches or background stores (189-portfolio-triage-review-state)
|
||||
- PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, existing `BaselineCompareService`, `BaselineSnapshotTruthResolver`, `BaselineCompareStats`, `RelatedNavigationResolver`, `CanonicalNavigationContext`, `BadgeCatalog`, and `UiEnforcement` patterns (190-baseline-compare-matrix)
|
||||
- PostgreSQL via existing `baseline_profiles`, `baseline_snapshots`, `baseline_snapshot_items`, `baseline_tenant_assignments`, `operation_runs`, and `findings` tables; no new persistence planned (190-baseline-compare-matrix)
|
||||
- PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, Tailwind CSS v4, existing `BaselineCompareMatrixBuilder`, `BadgeCatalog`, `CanonicalNavigationContext`, and `UiEnforcement` patterns (191-baseline-compare-operator-mode)
|
||||
- PostgreSQL via existing baseline, assignment, compare-run, and finding tables; no new persistence planned (191-baseline-compare-operator-mode)
|
||||
|
||||
- PHP 8.4.15 (feat/005-bulk-operations)
|
||||
|
||||
@ -201,8 +203,7 @@ ## Code Style
|
||||
PHP 8.4.15: Follow standard conventions
|
||||
|
||||
## Recent Changes
|
||||
- 191-baseline-compare-operator-mode: Added PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, Tailwind CSS v4, existing `BaselineCompareMatrixBuilder`, `BadgeCatalog`, `CanonicalNavigationContext`, and `UiEnforcement` patterns
|
||||
- 190-baseline-compare-matrix: Added PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, existing `BaselineCompareService`, `BaselineSnapshotTruthResolver`, `BaselineCompareStats`, `RelatedNavigationResolver`, `CanonicalNavigationContext`, `BadgeCatalog`, and `UiEnforcement` patterns
|
||||
- 189-portfolio-triage-review-state: Added PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, existing `WorkspaceOverviewBuilder`, `TenantResource`, `TenantDashboard`, `PortfolioArrivalContext`, `TenantBackupHealthResolver`, `RestoreSafetyResolver`, `BadgeCatalog`, `UiEnforcement`, and `AuditRecorder` patterns
|
||||
- 188-provider-connection-state-cleanup: Added PHP 8.4.15 + Laravel 12, Filament v5, Livewire v4, Pest v4, existing `ProviderConnection` model, `ProviderConnectionResolver`, `ProviderConnectionStateProjector`, `ProviderConnectionMutationService`, `ProviderConnectionHealthCheckJob`, `StartVerification`, `ProviderConnectionResource`, `TenantResource`, system directory pages, `BadgeCatalog`, `BadgeRenderer`, and shared provider-state Blade entries
|
||||
<!-- MANUAL ADDITIONS START -->
|
||||
<!-- MANUAL ADDITIONS END -->
|
||||
|
||||
@ -0,0 +1,13 @@
|
||||
# Requirements Checklist: Baseline Compare Matrix: High-Density Operator Mode
|
||||
|
||||
- [x] Spec candidate check is complete and scores the candidate before approval.
|
||||
- [x] The spec is explicitly scoped as a follow-up to the existing workspace matrix rather than a new domain truth.
|
||||
- [x] Multi-tenant dense mode is defined as the primary operator-density gain.
|
||||
- [x] Single-tenant compact mode is defined as a separate adaptive presentation path.
|
||||
- [x] Filters, legends, actions, and refresh surfaces are explicitly compressed as supporting context.
|
||||
- [x] Visible-set-only semantics and existing RBAC rules are preserved.
|
||||
- [x] No new persisted artifact, state family, or generalized UI framework is introduced.
|
||||
- [x] Manual presentation override is local to the route and not stored as domain truth.
|
||||
- [x] Functional requirements include mode selection, action calming, filter workflow, and last-updated visibility.
|
||||
- [x] Definition of done is testable and aligned with operator scanability rather than generic visual polish.
|
||||
- [x] Tasks are grouped by user story and include focused verification work.
|
||||
@ -0,0 +1,501 @@
|
||||
openapi: 3.1.0
|
||||
info:
|
||||
title: Baseline Compare Matrix Operator Mode Internal Surface Contract
|
||||
version: 0.1.0
|
||||
summary: Internal logical contract for adaptive operator-density rendering on the existing baseline compare matrix route
|
||||
description: |
|
||||
This contract is an internal planning artifact for Spec 191. The affected surface
|
||||
still renders HTML through Filament and Livewire. The schemas below define the
|
||||
bounded request-scoped presentation models and staged filter interactions that must
|
||||
be derivable from existing Spec 190 matrix truth before the operator-density
|
||||
refactor can render safely.
|
||||
servers:
|
||||
- url: /internal
|
||||
x-baseline-compare-operator-mode-consumers:
|
||||
- surface: baseline.compare.matrix
|
||||
sourceFiles:
|
||||
- apps/platform/app/Filament/Pages/BaselineCompareMatrix.php
|
||||
- apps/platform/resources/views/filament/pages/baseline-compare-matrix.blade.php
|
||||
mustRender:
|
||||
- reference
|
||||
- presentation_state
|
||||
- support_surface_state
|
||||
- applied_filters
|
||||
- tenant_summaries
|
||||
- dense_rows_or_compact_results
|
||||
- last_updated_at
|
||||
- auto_refresh_state
|
||||
mustAccept:
|
||||
- mode
|
||||
- policy_type
|
||||
- state
|
||||
- severity
|
||||
- tenant_sort
|
||||
- subject_sort
|
||||
- subject_key
|
||||
mustStage:
|
||||
- selectedPolicyTypes
|
||||
- selectedStates
|
||||
- selectedSeverities
|
||||
paths:
|
||||
/admin/baseline-profiles/{profile}/compare-matrix:
|
||||
get:
|
||||
summary: Render the existing baseline compare matrix using adaptive operator-density presentation
|
||||
operationId: viewBaselineCompareOperatorMode
|
||||
parameters:
|
||||
- name: profile
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
- name: mode
|
||||
in: query
|
||||
required: false
|
||||
schema:
|
||||
$ref: '#/components/schemas/PresentationMode'
|
||||
- name: policy_type
|
||||
in: query
|
||||
required: false
|
||||
schema:
|
||||
type: array
|
||||
items:
|
||||
type: string
|
||||
- name: state
|
||||
in: query
|
||||
required: false
|
||||
schema:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/MatrixCellState'
|
||||
- name: severity
|
||||
in: query
|
||||
required: false
|
||||
schema:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/FindingSeverity'
|
||||
- name: tenant_sort
|
||||
in: query
|
||||
required: false
|
||||
schema:
|
||||
type: string
|
||||
- name: subject_sort
|
||||
in: query
|
||||
required: false
|
||||
schema:
|
||||
type: string
|
||||
- name: subject_key
|
||||
in: query
|
||||
required: false
|
||||
schema:
|
||||
type: string
|
||||
responses:
|
||||
'200':
|
||||
description: Rendered matrix plus adaptive operator-density read models
|
||||
content:
|
||||
text/html:
|
||||
schema:
|
||||
type: string
|
||||
application/vnd.tenantpilot.baseline-compare-operator-mode+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/BaselineCompareOperatorModeBundle'
|
||||
'403':
|
||||
description: Actor is in scope but lacks workspace baseline view capability
|
||||
'404':
|
||||
description: Workspace or baseline profile is outside actor scope
|
||||
/internal/workspaces/{workspace}/baseline-profiles/{profile}/compare-matrix/apply-filters:
|
||||
post:
|
||||
summary: Apply staged heavy filters to the operator-density matrix route
|
||||
operationId: applyBaselineCompareOperatorFilters
|
||||
parameters:
|
||||
- name: workspace
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
- name: profile
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
requestBody:
|
||||
required: true
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/MatrixFilterDraft'
|
||||
responses:
|
||||
'200':
|
||||
description: Updated operator-density bundle using the applied filter state
|
||||
content:
|
||||
application/vnd.tenantpilot.baseline-compare-operator-mode+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/BaselineCompareOperatorModeBundle'
|
||||
'403':
|
||||
description: Actor is in scope but lacks workspace baseline view capability
|
||||
'404':
|
||||
description: Workspace or baseline profile is outside actor scope
|
||||
/internal/workspaces/{workspace}/baseline-profiles/{profile}/compare-matrix/reset-filters:
|
||||
post:
|
||||
summary: Reset staged and applied heavy filters for the operator-density matrix route
|
||||
operationId: resetBaselineCompareOperatorFilters
|
||||
parameters:
|
||||
- name: workspace
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
- name: profile
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Updated operator-density bundle with default filter state restored
|
||||
content:
|
||||
application/vnd.tenantpilot.baseline-compare-operator-mode+json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/BaselineCompareOperatorModeBundle'
|
||||
'403':
|
||||
description: Actor is in scope but lacks workspace baseline view capability
|
||||
'404':
|
||||
description: Workspace or baseline profile is outside actor scope
|
||||
components:
|
||||
schemas:
|
||||
PresentationMode:
|
||||
type: string
|
||||
enum:
|
||||
- auto
|
||||
- dense
|
||||
- compact
|
||||
MatrixCellState:
|
||||
type: string
|
||||
enum:
|
||||
- match
|
||||
- differ
|
||||
- missing
|
||||
- ambiguous
|
||||
- not_compared
|
||||
- stale_result
|
||||
FindingSeverity:
|
||||
type: string
|
||||
enum:
|
||||
- low
|
||||
- medium
|
||||
- high
|
||||
- critical
|
||||
FreshnessState:
|
||||
type: string
|
||||
enum:
|
||||
- fresh
|
||||
- stale
|
||||
- never_compared
|
||||
- unknown
|
||||
TrustLevel:
|
||||
type: string
|
||||
enum:
|
||||
- trustworthy
|
||||
- limited_confidence
|
||||
- diagnostic_only
|
||||
- unusable
|
||||
AttentionLevel:
|
||||
type: string
|
||||
enum:
|
||||
- aligned
|
||||
- review
|
||||
- refresh_recommended
|
||||
- needs_attention
|
||||
MatrixReference:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
required:
|
||||
- baselineProfileId
|
||||
- baselineProfileName
|
||||
- referenceState
|
||||
- assignedTenantCount
|
||||
- visibleTenantCount
|
||||
properties:
|
||||
baselineProfileId:
|
||||
type: integer
|
||||
baselineProfileName:
|
||||
type: string
|
||||
referenceSnapshotId:
|
||||
type:
|
||||
- integer
|
||||
- 'null'
|
||||
referenceState:
|
||||
type: string
|
||||
assignedTenantCount:
|
||||
type: integer
|
||||
visibleTenantCount:
|
||||
type: integer
|
||||
MatrixFilterDraft:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
required:
|
||||
- selectedPolicyTypes
|
||||
- selectedStates
|
||||
- selectedSeverities
|
||||
- tenantSort
|
||||
- subjectSort
|
||||
properties:
|
||||
selectedPolicyTypes:
|
||||
type: array
|
||||
items:
|
||||
type: string
|
||||
selectedStates:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/MatrixCellState'
|
||||
selectedSeverities:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/FindingSeverity'
|
||||
tenantSort:
|
||||
type: string
|
||||
subjectSort:
|
||||
type: string
|
||||
focusedSubjectKey:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
MatrixPresentationState:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
required:
|
||||
- requestedMode
|
||||
- resolvedMode
|
||||
- visibleTenantCount
|
||||
- activeFilterCount
|
||||
- hasStagedFilterChanges
|
||||
- autoRefreshActive
|
||||
- canOverrideMode
|
||||
properties:
|
||||
requestedMode:
|
||||
$ref: '#/components/schemas/PresentationMode'
|
||||
resolvedMode:
|
||||
type: string
|
||||
enum:
|
||||
- dense
|
||||
- compact
|
||||
visibleTenantCount:
|
||||
type: integer
|
||||
activeFilterCount:
|
||||
type: integer
|
||||
hasStagedFilterChanges:
|
||||
type: boolean
|
||||
autoRefreshActive:
|
||||
type: boolean
|
||||
lastUpdatedAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
canOverrideMode:
|
||||
type: boolean
|
||||
MatrixTenantSummary:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
required:
|
||||
- tenantId
|
||||
- tenantName
|
||||
- freshnessState
|
||||
- differingCount
|
||||
- missingCount
|
||||
- ambiguousCount
|
||||
- trustLevel
|
||||
properties:
|
||||
tenantId:
|
||||
type: integer
|
||||
tenantName:
|
||||
type: string
|
||||
freshnessState:
|
||||
$ref: '#/components/schemas/FreshnessState'
|
||||
lastComparedAt:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
format: date-time
|
||||
differingCount:
|
||||
type: integer
|
||||
missingCount:
|
||||
type: integer
|
||||
ambiguousCount:
|
||||
type: integer
|
||||
trustLevel:
|
||||
$ref: '#/components/schemas/TrustLevel'
|
||||
maxSeverity:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
DenseCellView:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
required:
|
||||
- tenantId
|
||||
- subjectKey
|
||||
- state
|
||||
- freshnessState
|
||||
- trustLevel
|
||||
- attentionLevel
|
||||
properties:
|
||||
tenantId:
|
||||
type: integer
|
||||
subjectKey:
|
||||
type: string
|
||||
state:
|
||||
$ref: '#/components/schemas/MatrixCellState'
|
||||
freshnessState:
|
||||
$ref: '#/components/schemas/FreshnessState'
|
||||
trustLevel:
|
||||
$ref: '#/components/schemas/TrustLevel'
|
||||
severity:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
attentionLevel:
|
||||
$ref: '#/components/schemas/AttentionLevel'
|
||||
reasonSummary:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
primaryDrilldownUrl:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
secondaryDrilldownUrls:
|
||||
type: object
|
||||
additionalProperties:
|
||||
type: string
|
||||
DenseSubjectRowView:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
required:
|
||||
- subjectKey
|
||||
- displayName
|
||||
- policyType
|
||||
- deviationBreadth
|
||||
- missingBreadth
|
||||
- ambiguousBreadth
|
||||
- trustLevel
|
||||
- cells
|
||||
properties:
|
||||
subjectKey:
|
||||
type: string
|
||||
displayName:
|
||||
type: string
|
||||
policyType:
|
||||
type: string
|
||||
baselineExternalId:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
deviationBreadth:
|
||||
type: integer
|
||||
missingBreadth:
|
||||
type: integer
|
||||
ambiguousBreadth:
|
||||
type: integer
|
||||
maxSeverity:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
trustLevel:
|
||||
$ref: '#/components/schemas/TrustLevel'
|
||||
cells:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/DenseCellView'
|
||||
CompactSubjectResultView:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
required:
|
||||
- tenantId
|
||||
- subjectKey
|
||||
- displayName
|
||||
- policyType
|
||||
- state
|
||||
- freshnessState
|
||||
- trustLevel
|
||||
properties:
|
||||
tenantId:
|
||||
type: integer
|
||||
subjectKey:
|
||||
type: string
|
||||
displayName:
|
||||
type: string
|
||||
policyType:
|
||||
type: string
|
||||
state:
|
||||
$ref: '#/components/schemas/MatrixCellState'
|
||||
freshnessState:
|
||||
$ref: '#/components/schemas/FreshnessState'
|
||||
trustLevel:
|
||||
$ref: '#/components/schemas/TrustLevel'
|
||||
severity:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
reasonSummary:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
primaryDrilldownUrl:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
runUrl:
|
||||
type:
|
||||
- string
|
||||
- 'null'
|
||||
MatrixSupportSurfaceState:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
required:
|
||||
- legendMode
|
||||
- showActiveFilterSummary
|
||||
- showLastUpdated
|
||||
- showAutoRefreshHint
|
||||
- showBlockingRefreshState
|
||||
properties:
|
||||
legendMode:
|
||||
type: string
|
||||
showActiveFilterSummary:
|
||||
type: boolean
|
||||
showLastUpdated:
|
||||
type: boolean
|
||||
showAutoRefreshHint:
|
||||
type: boolean
|
||||
showBlockingRefreshState:
|
||||
type: boolean
|
||||
BaselineCompareOperatorModeBundle:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
required:
|
||||
- reference
|
||||
- presentation
|
||||
- supportSurface
|
||||
- appliedFilters
|
||||
- tenantSummaries
|
||||
properties:
|
||||
reference:
|
||||
$ref: '#/components/schemas/MatrixReference'
|
||||
presentation:
|
||||
$ref: '#/components/schemas/MatrixPresentationState'
|
||||
supportSurface:
|
||||
$ref: '#/components/schemas/MatrixSupportSurfaceState'
|
||||
appliedFilters:
|
||||
$ref: '#/components/schemas/MatrixFilterDraft'
|
||||
tenantSummaries:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/MatrixTenantSummary'
|
||||
denseRows:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/DenseSubjectRowView'
|
||||
compactResults:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/CompactSubjectResultView'
|
||||
166
specs/191-baseline-compare-operator-mode/data-model.md
Normal file
166
specs/191-baseline-compare-operator-mode/data-model.md
Normal file
@ -0,0 +1,166 @@
|
||||
# Data Model: Baseline Compare Matrix: High-Density Operator Mode
|
||||
|
||||
## Overview
|
||||
|
||||
This follow-up introduces no new persisted entity. It reuses the existing Spec 190 matrix truth and adds derived presentation models for operator density, staged filtering, and non-blocking status cues.
|
||||
|
||||
## Existing Source Truths Reused Without Change
|
||||
|
||||
### Baseline compare truth from Spec 190
|
||||
|
||||
The following derived or canonical inputs remain authoritative and are not redefined by this spec:
|
||||
|
||||
- workspace-scoped baseline reference truth
|
||||
- visible tenant summaries
|
||||
- subject summaries
|
||||
- subject-by-tenant matrix cells
|
||||
- compare-start availability and existing drilldown destinations
|
||||
|
||||
This spec changes how those inputs are rendered and interacted with, not how they are computed.
|
||||
|
||||
## New Derived Presentation Models
|
||||
|
||||
### MatrixPresentationState
|
||||
|
||||
**Type**: request-scoped page presentation contract
|
||||
**Source**: route/query state + visible tenant count + existing run state
|
||||
|
||||
| Field | Type | Notes |
|
||||
|------|------|-------|
|
||||
| `requestedMode` | string | `auto`, `dense`, or `compact` from route/query state |
|
||||
| `resolvedMode` | string | Final mode used for rendering: `dense` or `compact` |
|
||||
| `visibleTenantCount` | integer | Existing visible-set count from the matrix bundle |
|
||||
| `activeFilterCount` | integer | Count of currently applied filters |
|
||||
| `hasStagedFilterChanges` | boolean | Whether filter draft state differs from applied state |
|
||||
| `autoRefreshActive` | boolean | True when background polling is active because compare work is queued or running |
|
||||
| `lastUpdatedAt` | datetime or null | Timestamp for the currently rendered matrix data |
|
||||
| `canOverrideMode` | boolean | Whether the operator may locally switch away from `auto` |
|
||||
|
||||
### MatrixFilterDraft
|
||||
|
||||
**Type**: request-scoped staged filter model
|
||||
**Source**: page form state only
|
||||
|
||||
| Field | Type | Notes |
|
||||
|------|------|-------|
|
||||
| `selectedPolicyTypes` | array<string> | Draft policy-type filter selection |
|
||||
| `selectedStates` | array<string> | Draft state-group selection |
|
||||
| `selectedSeverities` | array<string> | Draft severity selection |
|
||||
| `tenantSort` | string | Current tenant sort choice |
|
||||
| `subjectSort` | string | Current subject sort choice |
|
||||
| `focusedSubjectKey` | string or null | Optional current subject focus |
|
||||
|
||||
### DenseSubjectRowView
|
||||
|
||||
**Type**: request-scoped dense-mode row view
|
||||
**Source**: existing subject summary + existing matrix cells
|
||||
|
||||
| Field | Type | Notes |
|
||||
|------|------|-------|
|
||||
| `subjectKey` | string | Stable row key |
|
||||
| `displayName` | string | Primary row label |
|
||||
| `policyType` | string | Compact secondary label |
|
||||
| `baselineExternalId` | string or null | Optional secondary context |
|
||||
| `deviationBreadth` | integer | Existing subject summary metric |
|
||||
| `missingBreadth` | integer | Existing subject summary metric |
|
||||
| `ambiguousBreadth` | integer | Existing subject summary metric |
|
||||
| `maxSeverity` | string or null | Existing subject summary severity |
|
||||
| `trustLevel` | string | Existing subject summary trust |
|
||||
| `cells` | array<DenseCellView> | One condensed cell per visible tenant |
|
||||
|
||||
### DenseCellView
|
||||
|
||||
**Type**: request-scoped dense-mode cell view
|
||||
**Source**: existing matrix cell + existing tenant summary freshness
|
||||
|
||||
| Field | Type | Notes |
|
||||
|------|------|-------|
|
||||
| `tenantId` | integer | Visible tenant identifier |
|
||||
| `subjectKey` | string | Subject row key |
|
||||
| `state` | string | Existing Spec 190 state |
|
||||
| `freshnessState` | string | Freshness signal shown in compact form |
|
||||
| `trustLevel` | string | Trust signal shown in compact form |
|
||||
| `severity` | string or null | Optional attention signal |
|
||||
| `attentionLevel` | string | Derived presentation label such as `aligned`, `refresh_recommended`, or `needs_attention` |
|
||||
| `reasonSummary` | string or null | Short secondary explanation for compact reveal surfaces |
|
||||
| `primaryDrilldownUrl` | string or null | Preferred next follow-up action |
|
||||
| `secondaryDrilldownUrls` | array<string, string> | Additional compact follow-up links when available |
|
||||
|
||||
### CompactSubjectResultView
|
||||
|
||||
**Type**: request-scoped single-tenant row view
|
||||
**Source**: one visible tenant summary + existing matrix cell + existing subject summary
|
||||
|
||||
| Field | Type | Notes |
|
||||
|------|------|-------|
|
||||
| `tenantId` | integer | The single visible tenant in compact mode |
|
||||
| `subjectKey` | string | Stable subject key |
|
||||
| `displayName` | string | Primary subject label |
|
||||
| `policyType` | string | Secondary grouping/context |
|
||||
| `state` | string | Existing Spec 190 state |
|
||||
| `freshnessState` | string | Compact freshness label |
|
||||
| `trustLevel` | string | Compact trust label |
|
||||
| `severity` | string or null | Optional attention indicator |
|
||||
| `reasonSummary` | string or null | Short explanation line |
|
||||
| `primaryDrilldownUrl` | string or null | Main follow-up action |
|
||||
| `runUrl` | string or null | Secondary run-level follow-up |
|
||||
|
||||
### MatrixSupportSurfaceState
|
||||
|
||||
**Type**: request-scoped supporting-context contract
|
||||
**Source**: page state + existing legends + refresh metadata
|
||||
|
||||
| Field | Type | Notes |
|
||||
|------|------|-------|
|
||||
| `legendMode` | string | `grouped`, `collapsed`, or equivalent compact support behavior |
|
||||
| `showActiveFilterSummary` | boolean | Whether applied filters are summarized inline |
|
||||
| `showLastUpdated` | boolean | Whether the page displays last-updated metadata |
|
||||
| `showAutoRefreshHint` | boolean | Whether passive auto-refresh copy is visible |
|
||||
| `showBlockingRefreshState` | boolean | Reserved for deliberate user-triggered reloads only |
|
||||
|
||||
## Rendering and Resolution Rules
|
||||
|
||||
### Mode resolution rules
|
||||
|
||||
1. If `requestedMode = auto` and `visibleTenantCount > 1`, resolve to `dense`.
|
||||
2. If `requestedMode = auto` and `visibleTenantCount = 1`, resolve to `compact`.
|
||||
3. If a manual override is present, use it unless it would produce an invalid empty layout.
|
||||
4. Manual override remains route-local and must never be persisted as product truth.
|
||||
|
||||
### Dense-mode rules
|
||||
|
||||
- The subject column remains sticky during horizontal scroll.
|
||||
- The primary visible content per cell is state, trust, freshness, and attention.
|
||||
- Long explanatory text and repeated action links do not render as the dominant cell body.
|
||||
|
||||
### Compact single-tenant rules
|
||||
|
||||
- The tenant header does not repeat as a pseudo-column structure.
|
||||
- Each subject entry shows one primary status line and a reduced set of secondary metadata.
|
||||
- Existing subject focus and drilldown continuity remain available.
|
||||
|
||||
### Filter workflow rules
|
||||
|
||||
- Heavy multi-select filters use staged state first and apply only when the operator confirms.
|
||||
- Applied filter count and scope summary reflect the applied state, not merely the draft state.
|
||||
- Reset may clear both draft and applied state in one explicit action.
|
||||
|
||||
### Status signal rules
|
||||
|
||||
- `blocking refresh` is reserved for deliberate user-triggered reload or recalculation moments.
|
||||
- `auto-refresh active` indicates passive polling while compare work is still queued or running.
|
||||
- `lastUpdatedAt` reflects the timestamp of the rendered matrix payload, not merely the latest compare run in the system.
|
||||
|
||||
### Safety rules
|
||||
|
||||
- No rendering path may widen tenant visibility beyond the existing visible set.
|
||||
- No presentation-state change may change the underlying compare state, trust, or freshness semantics.
|
||||
- No grouped legend or compact cell may invent new status vocabulary outside existing centralized badge semantics.
|
||||
|
||||
## Relationships
|
||||
|
||||
- One `MatrixPresentationState` governs one rendered matrix page.
|
||||
- One `MatrixFilterDraft` belongs to one `MatrixPresentationState`.
|
||||
- In dense mode, one `DenseSubjectRowView` maps to many `DenseCellView` entries.
|
||||
- In compact mode, one visible tenant yields many `CompactSubjectResultView` entries.
|
||||
- One `MatrixSupportSurfaceState` coordinates legends, refresh hints, and active-filter summaries for the same page render.
|
||||
200
specs/191-baseline-compare-operator-mode/plan.md
Normal file
200
specs/191-baseline-compare-operator-mode/plan.md
Normal file
@ -0,0 +1,200 @@
|
||||
# Implementation Plan: Baseline Compare Matrix: High-Density Operator Mode
|
||||
|
||||
**Branch**: `191-baseline-compare-operator-mode` | **Date**: 2026-04-11 | **Spec**: `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/191-baseline-compare-operator-mode/spec.md`
|
||||
**Input**: Feature specification from `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/191-baseline-compare-operator-mode/spec.md`
|
||||
|
||||
**Note**: This plan formalizes the existing 191 spec slice and keeps the work strictly inside the already-shipped Spec 190 matrix surface.
|
||||
|
||||
## Summary
|
||||
|
||||
Refactor the existing workspace baseline compare matrix into an adaptive operator-density surface. The route, baseline reference, visible-set-only truth, compare-start behavior, and drilldowns stay unchanged, but the page gains local presentation-mode state, dense multi-tenant scanning, compact single-tenant rendering, staged heavy-filter application, grouped legends, and clearer separation between blocking refresh, passive auto-refresh, and last-updated status.
|
||||
|
||||
## Technical Context
|
||||
|
||||
**Language/Version**: PHP 8.4.15
|
||||
**Primary Dependencies**: Laravel 12, Filament v5, Livewire v4, Pest v4, Tailwind CSS v4, existing `BaselineCompareMatrixBuilder`, `BadgeCatalog`, `CanonicalNavigationContext`, and `UiEnforcement` patterns
|
||||
**Storage**: PostgreSQL via existing baseline, assignment, compare-run, and finding tables; no new persistence planned
|
||||
**Testing**: Pest feature tests and browser smoke coverage run through Laravel Sail
|
||||
**Target Platform**: Laravel monolith web application under `apps/platform`
|
||||
**Project Type**: web application
|
||||
**Performance Goals**: Improve scan throughput without increasing query shape beyond Spec 190, keep heavy filter changes non-chatty, and preserve DB-only render-time matrix surfaces
|
||||
**Constraints**: No compare-logic change, no new persistence, no hidden-tenant leakage, no generalized density framework, no provider or panel changes, and no new asset pipeline
|
||||
**Scale/Scope**: One existing matrix page, one existing Blade view, one existing builder, one logical contract file, and focused feature plus browser regressions
|
||||
|
||||
## Constitution Check
|
||||
|
||||
*GATE: Passed before Phase 0 research. Re-checked after Phase 1 design and still passing.*
|
||||
|
||||
| Principle | Pre-Research | Post-Design | Notes |
|
||||
|-----------|--------------|-------------|-------|
|
||||
| Inventory-first / snapshots-second | PASS | PASS | The spec changes presentation only and keeps Spec 190 truth sources intact. |
|
||||
| Read/write separation | PASS | PASS | `Compare assigned tenants` remains the only mutation and is unchanged. |
|
||||
| Graph contract path | N/A | N/A | No new Graph behavior or contract-registry work is introduced. |
|
||||
| Deterministic capabilities | PASS | PASS | Existing capabilities remain canonical and unchanged. |
|
||||
| Workspace + tenant isolation | PASS | PASS | Visible-set-only aggregation and drilldown scope remain unchanged. |
|
||||
| RBAC-UX authorization semantics | PASS | PASS | Existing `404` vs `403` semantics and server-side enforcement remain unchanged. |
|
||||
| Run observability / Ops-UX | PASS | PASS | Compare-run truth is reused exactly as in Spec 190; this spec only clarifies the visual cues around it. |
|
||||
| Data minimization | PASS | PASS | No new data copies, exports, or persisted UI artifacts are introduced. |
|
||||
| Proportionality / anti-bloat | PASS | PASS | The work stays local to one page and does not add a new abstraction or stored artifact. |
|
||||
| Persisted truth / behavioral state | PASS | PASS | Presentation mode and staged filter state remain request-scoped only. |
|
||||
| UI semantics / few layers | PASS | PASS | Existing state, trust, freshness, and severity semantics are reused rather than redefined. |
|
||||
| Filament v5 / Livewire v4 compliance | PASS | PASS | The work remains inside the existing Filament page and Livewire-backed route. |
|
||||
| Provider registration location | PASS | PASS | No provider changes are required; Laravel 11+ registration remains in `bootstrap/providers.php`. |
|
||||
| Global search hard rule | PASS | PASS | No new searchable resource or page is introduced. |
|
||||
| Destructive action safety | PASS | PASS | No destructive action is added. Existing confirmation behavior for compare-start remains unchanged. |
|
||||
| Asset strategy | PASS | PASS | No new assets are required. Existing deployment behavior for `cd apps/platform && php artisan filament:assets` remains unchanged. |
|
||||
|
||||
## Filament-Specific Compliance Notes
|
||||
|
||||
- **Livewire v4.0+ compliance**: This plan remains on Filament v5 + Livewire v4 and does not introduce legacy APIs.
|
||||
- **Provider registration location**: No panel or provider changes are needed; Laravel 11+ provider registration remains in `bootstrap/providers.php`.
|
||||
- **Global search**: The feature does not add a new globally searchable resource. Existing baseline-resource search behavior is unchanged.
|
||||
- **Destructive actions**: No new destructive action is introduced. Existing compare-start actions remain confirmation-gated where already defined.
|
||||
- **Asset strategy**: No new global or on-demand asset registration is planned. Deployment handling of `cd apps/platform && php artisan filament:assets` remains unchanged.
|
||||
- **Testing plan**: Extend the existing matrix feature, builder, guard, and browser suites to cover presentation mode, staged filter application, and non-blocking status surfaces.
|
||||
|
||||
## Phase 0 Research
|
||||
|
||||
Research outcomes are captured in `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/191-baseline-compare-operator-mode/research.md`.
|
||||
|
||||
Key decisions:
|
||||
|
||||
- Keep the existing matrix route and truth model and change presentation only.
|
||||
- Resolve `auto`, `dense`, and `compact` mode from visible tenant count, with a route-local override only.
|
||||
- Make dense mode state-first rather than action-first.
|
||||
- Render single-tenant review as a compact compare list rather than a one-column matrix.
|
||||
- Convert heavy filters to staged apply/reset semantics.
|
||||
- Replace the long policy-type checkbox stack with a more compact operator-first selector.
|
||||
- Group legends into compact support context and separate blocking refresh from passive auto-refresh and last-updated cues.
|
||||
- Reuse existing drilldown and visible-set semantics unchanged.
|
||||
|
||||
## Phase 1 Design
|
||||
|
||||
Design artifacts are created under `/Users/ahmeddarrazi/Documents/projects/TenantAtlas/specs/191-baseline-compare-operator-mode/`:
|
||||
|
||||
- `research.md`: decisions and rejected alternatives for local operator-density work
|
||||
- `data-model.md`: request-scoped presentation models for mode state, staged filters, dense rows, compact results, and support-surface state
|
||||
- `contracts/baseline-compare-operator-mode.logical.openapi.yaml`: internal logical contract for adaptive rendering and staged filter application
|
||||
- `quickstart.md`: implementation and verification sequence for the follow-up spec
|
||||
|
||||
Design decisions:
|
||||
|
||||
- `auto` remains the default requested mode and resolves to `dense` for multiple visible tenants and `compact` for exactly one visible tenant.
|
||||
- Manual mode override remains route-local and must never become stored product truth.
|
||||
- Dense mode reuses existing compare truth but condenses cell content to state, trust, freshness, and attention.
|
||||
- Compact mode reuses the same truth but removes pseudo-matrix structure once only one visible tenant remains.
|
||||
- Heavy filter inputs stage locally and apply explicitly; lightweight route-state changes may remain immediate.
|
||||
- Grouped legends, passive auto-refresh, and last-updated signals become support context rather than competing top-level content.
|
||||
|
||||
## Project Structure
|
||||
|
||||
### Documentation (this feature)
|
||||
|
||||
```text
|
||||
specs/191-baseline-compare-operator-mode/
|
||||
├── plan.md
|
||||
├── research.md
|
||||
├── data-model.md
|
||||
├── quickstart.md
|
||||
├── spec.md
|
||||
├── tasks.md
|
||||
├── contracts/
|
||||
│ └── baseline-compare-operator-mode.logical.openapi.yaml
|
||||
└── checklists/
|
||||
└── requirements.md
|
||||
```
|
||||
|
||||
### Source Code (repository root)
|
||||
|
||||
```text
|
||||
apps/platform/
|
||||
├── app/
|
||||
│ ├── Filament/
|
||||
│ │ └── Pages/
|
||||
│ │ └── BaselineCompareMatrix.php
|
||||
│ └── Support/
|
||||
│ └── Baselines/
|
||||
│ └── BaselineCompareMatrixBuilder.php
|
||||
├── resources/views/filament/pages/
|
||||
│ └── baseline-compare-matrix.blade.php
|
||||
└── tests/
|
||||
├── Browser/
|
||||
│ └── Spec190BaselineCompareMatrixSmokeTest.php
|
||||
├── Feature/
|
||||
│ ├── Baselines/
|
||||
│ │ └── BaselineCompareMatrixBuilderTest.php
|
||||
│ ├── Filament/
|
||||
│ │ └── BaselineCompareMatrixPageTest.php
|
||||
│ └── Guards/
|
||||
│ └── ActionSurfaceContractTest.php
|
||||
└── Unit/
|
||||
└── Badges/
|
||||
```
|
||||
|
||||
**Structure Decision**: Keep the work inside the existing Spec 190 matrix implementation surface. This is a presentation refactor of one existing page and its supporting builder/view behavior, not a new domain slice or a new application area.
|
||||
|
||||
## Complexity Tracking
|
||||
|
||||
| Violation | Why Needed | Simpler Alternative Rejected Because |
|
||||
|-----------|------------|-------------------------------------|
|
||||
| None | N/A | The follow-up stays within the existing page, builder, and test surfaces and introduces no new structural violation. |
|
||||
|
||||
## Proportionality Review
|
||||
|
||||
- **Current operator problem**: The matrix already answers the right governance question, but not with enough density or calmness for repeated operator scanning.
|
||||
- **Existing structure is insufficient because**: The current single rendering shape tries to serve both multi-tenant and single-tenant workflows, so supporting context, action repetition, and cell chrome are too heavy in both cases.
|
||||
- **Narrowest correct implementation**: Keep the same route, truth sources, drilldowns, and compare semantics while adding route-local presentation state, denser rendering, and staged filter application.
|
||||
- **Ownership cost created**: Additional view-state logic, a logical contract file, and focused regression coverage for mode resolution, filter workflow, and status visibility.
|
||||
- **Alternative intentionally rejected**: A generalized density framework, a separate dense-report route, or a stored matrix artifact were rejected because the problem is local to the existing matrix surface.
|
||||
- **Release truth**: current-release operator workflow compression
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
### Phase A — Presentation Mode Contract
|
||||
|
||||
- Add route-local `auto`, `dense`, and `compact` mode state.
|
||||
- Resolve the active mode from visible tenant count unless manually overridden.
|
||||
- Expose `lastUpdatedAt`, `hasStagedFilterChanges`, and passive auto-refresh state to the page.
|
||||
|
||||
### Phase B — Dense Multi-Tenant Surface
|
||||
|
||||
- Keep the subject column sticky during horizontal scroll.
|
||||
- Condense dense cells to state, trust, freshness, and attention signals.
|
||||
- Move repeated actions into compact secondary affordances without breaking drilldown continuity.
|
||||
|
||||
### Phase C — Compact Single-Tenant Surface
|
||||
|
||||
- Replace pseudo-matrix rendering with a compact subject-result list when only one visible tenant remains.
|
||||
- Remove repeated tenant headers and duplicated secondary metadata.
|
||||
- Preserve subject focus and the existing compare/finding/run destinations.
|
||||
|
||||
### Phase D — Supporting Context Compression
|
||||
|
||||
- Convert heavy matrix filters to staged apply/reset behavior.
|
||||
- Replace the current long policy-type control with a more compact selector.
|
||||
- Group or collapse legends.
|
||||
- Separate blocking refresh from passive auto-refresh and last-updated status.
|
||||
|
||||
### Phase E — Verification
|
||||
|
||||
- Extend focused feature coverage for mode resolution, staged filter behavior, and support-surface state.
|
||||
- Extend browser smoke coverage for one dense-mode path and one compact-mode path.
|
||||
- Keep existing Spec 190 matrix truth, drilldown continuity, and RBAC guarantees green.
|
||||
|
||||
## Risk Assessment
|
||||
|
||||
| Risk | Impact | Likelihood | Mitigation |
|
||||
|------|--------|------------|------------|
|
||||
| Dense mode becomes another framework | Medium | Low | Keep presentation logic local to the matrix page and avoid generalized shared abstractions. |
|
||||
| Compact mode hides too much follow-up value | Medium | Medium | Preserve one clear primary drilldown per subject and keep existing follow-up destinations intact. |
|
||||
| Staged filtering feels slow or unclear | Medium | Medium | Show explicit staged/applied state and keep reset obvious. |
|
||||
| Manual override confuses operators | Low | Medium | Keep `auto` as the default and surface the resolved mode clearly. |
|
||||
| Last-updated and auto-refresh cues drift out of sync | Medium | Low | Derive both cues from the same rendered matrix payload and active-run state. |
|
||||
|
||||
## Test Strategy
|
||||
|
||||
- Extend `BaselineCompareMatrixPageTest` for requested vs resolved mode, active filter application, compact vs dense rendering, and non-blocking refresh cues.
|
||||
- Extend `BaselineCompareMatrixBuilderTest` for any new derived presentation metadata required by the page.
|
||||
- Keep `ActionSurfaceContractTest` green so calmer actions do not regress the surface contract.
|
||||
- Extend `Spec190BaselineCompareMatrixSmokeTest` to prove one dense-mode and one compact-mode operator path on the Livewire page.
|
||||
- Run the focused Sail verification pack from `quickstart.md` and re-run `update-agent-context.sh copilot` after the plan is finalized.
|
||||
70
specs/191-baseline-compare-operator-mode/quickstart.md
Normal file
70
specs/191-baseline-compare-operator-mode/quickstart.md
Normal file
@ -0,0 +1,70 @@
|
||||
# Quickstart: Baseline Compare Matrix: High-Density Operator Mode
|
||||
|
||||
## Goal
|
||||
|
||||
Turn the existing baseline compare matrix into a denser operator surface without changing its underlying compare truth. Multi-tenant use should favor high-density cross-tenant scanning, while single-tenant use should collapse into a calmer compact comparison view.
|
||||
|
||||
## Implementation Sequence
|
||||
|
||||
1. Add page-level presentation state.
|
||||
- Add `auto`, `dense`, and `compact` route-local mode state.
|
||||
- Resolve the active mode from visible tenant count unless the operator explicitly overrides it.
|
||||
- Expose `lastUpdatedAt`, staged-filter state, and passive auto-refresh state on the page.
|
||||
|
||||
2. Build the dense multi-tenant rendering contract.
|
||||
- Keep the subject column sticky.
|
||||
- Reduce dense-cell chrome to state, trust, freshness, and attention.
|
||||
- Move repeated follow-up links into compact secondary affordances.
|
||||
|
||||
3. Build the compact single-tenant rendering contract.
|
||||
- Replace the pseudo-matrix layout with a compact subject-result list.
|
||||
- Remove repeated tenant headers and repeated metadata blocks.
|
||||
- Preserve subject focus and existing drilldowns.
|
||||
|
||||
4. Compress supporting context.
|
||||
- Convert heavy filters to staged apply/reset semantics.
|
||||
- Replace the current long policy-type list with a more compact operator-first control.
|
||||
- Group or collapse legends so they remain available without dominating the page.
|
||||
- Separate blocking refresh from passive auto-refresh and last-updated status.
|
||||
|
||||
5. Extend regression coverage.
|
||||
- Cover mode resolution, dense multi-tenant layout, compact single-tenant layout, staged filters, and non-blocking refresh cues.
|
||||
- Keep existing Spec 190 matrix truth, drilldown continuity, and RBAC guarantees green.
|
||||
|
||||
## Suggested Test Files
|
||||
|
||||
- `apps/platform/tests/Feature/Filament/BaselineCompareMatrixPageTest.php`
|
||||
- `apps/platform/tests/Feature/Baselines/BaselineCompareMatrixBuilderTest.php`
|
||||
- `apps/platform/tests/Feature/Guards/ActionSurfaceContractTest.php`
|
||||
- `apps/platform/tests/Browser/Spec190BaselineCompareMatrixSmokeTest.php`
|
||||
|
||||
## Minimum Verification Commands
|
||||
|
||||
Run all commands through Sail from `apps/platform`.
|
||||
|
||||
```bash
|
||||
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Filament/BaselineCompareMatrixPageTest.php
|
||||
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Baselines/BaselineCompareMatrixBuilderTest.php
|
||||
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Guards/ActionSurfaceContractTest.php
|
||||
cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Browser/Spec190BaselineCompareMatrixSmokeTest.php
|
||||
cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent
|
||||
```
|
||||
|
||||
## Manual Acceptance Checklist
|
||||
|
||||
1. Open a baseline profile whose matrix has multiple visible tenants and confirm `auto` resolves to dense mode.
|
||||
2. Verify the first subject column remains visible while horizontally scrolling dense mode.
|
||||
3. Confirm dense cells foreground compare state, trust, freshness, and attention before links or long prose.
|
||||
4. Open a matrix that resolves to one visible tenant and confirm `auto` resolves to compact mode instead of a one-column matrix.
|
||||
5. Change heavy filters and confirm the page stages those changes until the operator applies them.
|
||||
6. Confirm active filter count and filter summary reflect the applied state clearly.
|
||||
7. Confirm legends are still understandable but no longer dominate the top of the page.
|
||||
8. Trigger or observe queued/running compare work and confirm passive auto-refresh does not look like a permanent blocking load.
|
||||
9. Confirm the page shows when the current matrix payload was last updated.
|
||||
10. Verify tenant compare, finding, and run drilldowns still preserve the existing matrix context.
|
||||
|
||||
## Deployment Notes
|
||||
|
||||
- No migration is expected.
|
||||
- No new asset registration is expected.
|
||||
- No queue topology change is expected because compare execution semantics stay unchanged.
|
||||
111
specs/191-baseline-compare-operator-mode/research.md
Normal file
111
specs/191-baseline-compare-operator-mode/research.md
Normal file
@ -0,0 +1,111 @@
|
||||
# Research: Baseline Compare Matrix: High-Density Operator Mode
|
||||
|
||||
## Decision: Keep the existing matrix route and truth model, and change presentation only
|
||||
|
||||
### Rationale
|
||||
|
||||
Spec 190 already established the correct workspace route, the correct baseline reference model, and the correct visible-set-only compare truth. The operator-density follow-up should stay on `/admin/baseline-profiles/{record}/compare-matrix` and must not introduce a second route, a second report artifact, or a second source of matrix truth.
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
- Add a separate `dense report` page: rejected because it would duplicate the same baseline-scoped workflow on a second route.
|
||||
- Add a stored matrix snapshot: rejected because the operator problem is scan efficiency, not missing persistence.
|
||||
|
||||
## Decision: Resolve presentation mode from visible tenant count, with a local override only
|
||||
|
||||
### Rationale
|
||||
|
||||
The core operator split is real: one visible tenant is a compact review problem, while several visible tenants create a cross-tenant scan problem. The narrowest implementation is one requested mode (`auto`, `dense`, or `compact`) and one resolved mode at render time. `auto` should remain the default, while manual override stays local to the matrix route and must not become stored user preference or domain truth.
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
- Separate feature flags or separate navigation entries for each mode: rejected because the matrix should remain one operator surface.
|
||||
- Persist mode preference per user: rejected because the current need is local workflow control, not profile-level personalization.
|
||||
|
||||
## Decision: Dense mode must be state-first, not action-first
|
||||
|
||||
### Rationale
|
||||
|
||||
In multi-tenant reading, the primary questions are where drift exists, how severe it is, whether the signal is trustworthy, and what deserves follow-up next. Dense cells should therefore foreground compare state, trust, freshness, and attention, while detailed reasons and repeated links move into compact secondary affordances.
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
- Keep the current repeated open-link pattern in every cell: rejected because repeated actions visually outrank the state being scanned.
|
||||
- Remove cell-level follow-up completely: rejected because the matrix must remain a decision surface, not a dead-end report.
|
||||
|
||||
## Decision: Single-tenant mode should be a compact compare list, not a one-column matrix
|
||||
|
||||
### Rationale
|
||||
|
||||
Once only one visible tenant remains, the value of cross-tenant columns disappears. The surface should switch to a shorter subject-result list that reuses the same truth but removes repeated tenant headers, empty width, and oversized cell chrome.
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
- Reuse dense mode even for one tenant: rejected because it preserves the wrong reading model.
|
||||
- Route single-tenant viewing away to the tenant compare page: rejected because the operator still started from the workspace baseline matrix context and should not lose that context automatically.
|
||||
|
||||
## Decision: Heavy filters should use staged apply/reset semantics
|
||||
|
||||
### Rationale
|
||||
|
||||
The current matrix is dense enough that chatty recomputation on every multi-select click works against operator flow. Policy types and other heavy matrix filters should stage changes locally, show that staged state clearly, and apply them deliberately. This improves calmness and makes the surface feel less like a form page.
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
- Keep all filters live: rejected because heavy multi-select controls create noisy redraw behavior.
|
||||
- Convert every filter to manual apply: rejected because lightweight interactions such as mode switching or focused-subject clearing should remain immediate.
|
||||
|
||||
## Decision: Replace the long policy-type checkbox stack with a more compact operator-first selector
|
||||
|
||||
### Rationale
|
||||
|
||||
The policy-type filter is the most visually expensive control on the page. The follow-up spec should use a denser selection pattern such as searchable multi-select, type-to-find, or another compact control that exposes the same filter truth without the current long vertical list.
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
- Keep the long checkbox list and only restyle it: rejected because vertical space is the actual product problem.
|
||||
- Hide policy type filtering behind a modal by default: rejected because the filter remains core enough to deserve immediate access.
|
||||
|
||||
## Decision: Legends should become grouped support context, optionally collapsible
|
||||
|
||||
### Rationale
|
||||
|
||||
State, freshness, and trust legends remain semantically valuable, especially for onboarding or occasional operators, but they should no longer compete with the matrix for top-of-screen attention. Grouped, compact legend blocks are the narrowest way to preserve semantics while reducing dominance.
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
- Remove legends entirely: rejected because trust and freshness semantics still need an on-page reference.
|
||||
- Leave three separate full-width legend sections: rejected because they displace the primary working surface.
|
||||
|
||||
## Decision: Separate loading, auto-refresh, and last-updated cues
|
||||
|
||||
### Rationale
|
||||
|
||||
Spec 190 already exposed the risk of background polling reading like permanent blocking load. This follow-up should make three states explicit: active loading for user-triggered refresh, passive auto-refresh while queued or running compare work exists, and last-updated time for the currently rendered matrix.
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
- Reuse one generic refresh chip for all states: rejected because operators cannot tell whether the page is blocked or simply polling.
|
||||
- Hide refresh state entirely: rejected because operator trust depends on understanding when the matrix is current.
|
||||
|
||||
## Decision: Reuse the existing drilldown and visible-set semantics without change
|
||||
|
||||
### Rationale
|
||||
|
||||
This spec is a presentation refactor, not a navigation or authorization redesign. The existing tenant compare, finding, run-detail, and canonical-navigation context from Spec 190 remain correct and should carry forward unchanged.
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
- Introduce a dense-mode-specific drilldown model: rejected because it would create new behavior where existing follow-up paths are already sufficient.
|
||||
- Add aggregated hidden-tenant remainder summaries: rejected because visible-set-only semantics explicitly avoid hidden-tenant leakage.
|
||||
|
||||
## Decision: Validate primarily with focused page, builder, guard, and browser coverage
|
||||
|
||||
### Rationale
|
||||
|
||||
The highest-risk changes are mode resolution, dense-cell hierarchy, compact single-tenant rendering, filter apply behavior, and non-blocking refresh cues. These are best covered with focused feature tests plus one browser smoke path for the interactive Livewire surface.
|
||||
|
||||
### Alternatives considered
|
||||
|
||||
- Browser-test every combination exhaustively: rejected because most of the behavior is deterministic and cheaper to validate through feature tests.
|
||||
- Limit validation to visual inspection: rejected because mode resolution and filter workflow are important enough to guard in CI.
|
||||
214
specs/191-baseline-compare-operator-mode/spec.md
Normal file
214
specs/191-baseline-compare-operator-mode/spec.md
Normal file
@ -0,0 +1,214 @@
|
||||
# Feature Specification: Baseline Compare Matrix: High-Density Operator Mode
|
||||
|
||||
**Feature Branch**: `191-baseline-compare-operator-mode`
|
||||
**Created**: 2026-04-11
|
||||
**Status**: Draft
|
||||
**Input**: User description: "Spec Candidate 190b — Baseline Compare Matrix: High-Density Operator Mode"
|
||||
|
||||
## Spec Candidate Check *(mandatory — SPEC-GATE-001)*
|
||||
|
||||
- **Problem**: The current baseline compare matrix is semantically strong but still too visually heavy for repeat operator use, especially when several visible tenants must be scanned quickly.
|
||||
- **Today's failure**: Operators reach the right truth, but the page spends too much space on supporting context, repeated actions, and vertically expensive cells. Multi-tenant comparison is slower than it should be, and single-tenant viewing still feels like a stretched matrix instead of a compact operator surface.
|
||||
- **User-visible improvement**: The same matrix route becomes faster to scan, calmer to use, and more obviously centered on drift detection. Multi-tenant work gets a true dense scan mode, while single-tenant work gets a compact compare list.
|
||||
- **Smallest enterprise-capable version**: Rework the existing matrix route with adaptive presentation only: `auto` mode picks dense multi-tenant view for more than one visible tenant and compact single-tenant view for one visible tenant, while filters, legends, actions, and refresh feedback are compressed without changing compare logic.
|
||||
- **Explicit non-goals**: No change to compare truth, no new finding semantics, no new persisted matrix artifact, no generalized table engine, no mobile-first redesign, no broader design-system rewrite.
|
||||
- **Permanent complexity imported**: One page-level presentation-mode contract, denser cell-layout rules, compact control behavior, route/query persistence for local mode override, and focused regression coverage for the new operator surface behavior.
|
||||
- **Why now**: Spec 190 established the truthful workspace compare surface. The next real bottleneck is not domain correctness but operator throughput and scan efficiency on the page that now exists.
|
||||
- **Why not local**: Small CSS-only tweaks will not solve the actual product problem because the core issue is presentation mode, action hierarchy, and default information density rather than isolated spacing bugs.
|
||||
- **Approval class**: Workflow Compression
|
||||
- **Red flags triggered**: `New Meta-Infrastructure` risk if presentation-mode work grows into a reusable UI framework. Defense: this spec keeps all mode logic page-local to the existing baseline compare matrix and forbids a generalized density framework.
|
||||
- **Score**: Nutzen: 2 | Dringlichkeit: 1 | Scope: 2 | Komplexität: 2 | Produktnähe: 2 | Wiederverwendung: 1 | **Gesamt: 10/12**
|
||||
- **Decision**: approve
|
||||
|
||||
## Spec Scope Fields *(mandatory)*
|
||||
|
||||
- **Scope**: workspace
|
||||
- **Primary Routes**:
|
||||
- `/admin/baseline-profiles/{record}/compare-matrix` as the existing workspace matrix route that gains dense and compact operator modes
|
||||
- `/admin/baseline-profiles/{record}` as the existing baseline profile detail that remains the canonical entry point into the matrix
|
||||
- `/admin/t/{tenant}/baseline-compare` as the existing tenant drilldown destination
|
||||
- `/admin/findings` and finding detail as the existing follow-up destinations
|
||||
- Monitoring run-detail routes as existing compare-run drilldowns
|
||||
- **Data Ownership**:
|
||||
- Workspace-owned baseline profile, snapshot, and assignment truth remain unchanged.
|
||||
- Tenant-owned compare runs and findings remain unchanged.
|
||||
- Presentation mode, filter compaction, and dense cell rendering remain derived UI behavior only and introduce no new persisted truth.
|
||||
- **RBAC**:
|
||||
- Matrix access remains gated by workspace membership plus `WORKSPACE_BASELINES_VIEW`.
|
||||
- `Compare assigned tenants` remains gated by `WORKSPACE_BASELINES_MANAGE`.
|
||||
- Tenant and finding drilldowns continue to enforce their existing tenant-scope capabilities such as `TENANT_VIEW` and `TENANT_FINDINGS_VIEW`.
|
||||
- Presentation-mode changes MUST NOT widen visibility, leak hidden tenants, or relax `404` vs `403` semantics already established in Spec 190.
|
||||
|
||||
## UI/UX Surface Classification *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Surface Type | Primary Inspect/Open Model | Row Click | Secondary Actions Placement | Destructive Actions Placement | Canonical Collection Route | Canonical Detail Route | Scope Signals | Canonical Noun | Critical Truth Visible by Default | Exception Type |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| Workspace baseline compare matrix | Workspace matrix / operator surface | Explicit subject, cell, and tenant drilldown controls | forbidden | Header controls, compact cell action slot, focused subject utilities | none | `/admin/baseline-profiles/{record}/compare-matrix` | same route with filter and presentation state | Active workspace, baseline profile, visible tenant count, active filter count, presentation mode, last updated | Baseline compare matrix | Drift hotspots, trust, freshness, and next follow-up path | dense-grid + compact-single-tenant exception |
|
||||
|
||||
## Operator Surface Contract *(mandatory when operator-facing surfaces are changed)*
|
||||
|
||||
| Surface | Primary Persona | Surface Type | Primary Operator Question | Default-visible Information | Diagnostics-only Information | Status Dimensions Used | Mutation Scope | Primary Actions | Dangerous Actions |
|
||||
|---|---|---|---|---|---|---|---|---|---|
|
||||
| Workspace baseline compare matrix | Workspace operator | Matrix / triage surface | Where is the meaningful drift across the visible tenant set, how trustworthy is it, and where should I go next? | Subject-by-tenant state, trust, freshness, severity or attention signal, visible-set filter scope, mode, last updated | Raw reason codes, run identifiers, detailed evidence gaps, low-level compare metadata | compare state, freshness, trust, severity/attention | `simulation only` for compare start; otherwise read-only | Compare assigned tenants, apply or reset filters, switch presentation mode, focus subject, drill into compare/finding/run | none |
|
||||
|
||||
## Proportionality Review *(mandatory when structural complexity is introduced)*
|
||||
|
||||
- **New source of truth?**: no
|
||||
- **New persisted entity/table/artifact?**: no
|
||||
- **New abstraction?**: no
|
||||
- **New enum/state/reason family?**: no
|
||||
- **New cross-domain UI framework/taxonomy?**: no
|
||||
- **Current operator problem**: The matrix already answers the right governance question, but not with enough density or calmness for repeated operator scanning.
|
||||
- **Existing structure is insufficient because**: The current single rendering shape tries to serve both multi-tenant and single-tenant use cases, so supporting context, cell chrome, and repeated actions stay too heavy for both.
|
||||
- **Narrowest correct implementation**: Keep the same route, same truth sources, same drilldowns, and same compare semantics while adding one adaptive presentation contract and denser default rendering.
|
||||
- **Ownership cost**: More page-view branching, additional view-state tests, and stricter UI regression coverage for density, action noise, and status visibility.
|
||||
- **Alternative intentionally rejected**: A generalized dense-table framework or a second persisted reporting artifact was rejected because this need is local to the baseline compare matrix.
|
||||
- **Release truth**: current-release operator workflow compression
|
||||
|
||||
## User Scenarios & Testing *(mandatory)*
|
||||
|
||||
### User Story 1 - Scan multi-tenant drift in dense mode (Priority: P1)
|
||||
|
||||
As a workspace operator, I want the matrix to switch into a true high-density view when multiple visible tenants are in scope so I can read drift patterns quickly without losing the subject axis.
|
||||
|
||||
**Why this priority**: Multi-tenant scanning is the core operator value of the matrix. If this remains visually slow, the page does not earn its workspace-level role.
|
||||
|
||||
**Independent Test**: Open the matrix for a baseline profile with multiple visible tenants and verify that one subject row and one tenant column remain readable in a dense layout with a sticky subject column and compact cell states.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** a baseline profile with more than one visible assigned tenant, **When** the operator opens the matrix route in auto mode, **Then** the page renders the dense multi-tenant mode with one subject row per baseline subject and one tenant column per visible tenant.
|
||||
2. **Given** the operator scrolls horizontally in dense mode, **When** the matrix remains wider than the viewport, **Then** the first subject column stays visible and anchored for cross-tenant reading.
|
||||
3. **Given** a dense-mode cell represents a visible tenant and subject, **When** the page renders it, **Then** the primary visible signal is the technical state plus condensed trust and freshness rather than a block of repeated links or prose.
|
||||
|
||||
---
|
||||
|
||||
### User Story 2 - Work a single visible tenant in compact mode (Priority: P2)
|
||||
|
||||
As a workspace operator, I want the matrix to stop pretending to be multi-tenant when only one visible tenant remains so the screen becomes shorter and calmer.
|
||||
|
||||
**Why this priority**: A single-tenant compare surface should not spend horizontal and vertical space simulating columns that do not exist.
|
||||
|
||||
**Independent Test**: Open the matrix for a baseline profile where only one tenant is visible and verify that the page uses a compact compare-list mode instead of the dense cross-tenant layout.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** exactly one visible assigned tenant after RBAC scoping, **When** the operator opens the matrix in auto mode, **Then** the page renders compact single-tenant mode instead of dense mode.
|
||||
2. **Given** compact mode is active, **When** the operator scans a subject entry, **Then** repeated labels, repeated badges, and repeated action chrome are reduced compared with the current matrix surface.
|
||||
|
||||
---
|
||||
|
||||
### User Story 3 - Use filters, legends, and status surfaces without losing the matrix (Priority: P2)
|
||||
|
||||
As a workspace operator, I want supporting controls to stay available but compact so the matrix remains the primary working surface above the fold.
|
||||
|
||||
**Why this priority**: Filtering, legends, and refresh status are necessary, but they should support the matrix rather than compete with it.
|
||||
|
||||
**Independent Test**: Open the matrix, apply policy-type or state filters, and verify that active filter count, filter application, legend compaction, and refresh signals remain visible without dominating the page.
|
||||
|
||||
**Acceptance Scenarios**:
|
||||
|
||||
1. **Given** the operator changes multi-select filters, **When** those changes are staged, **Then** the page uses an explicit apply or reset pattern for heavy filter changes instead of re-rendering noisily on every click.
|
||||
2. **Given** active compare runs or polling are present, **When** the matrix refreshes in the background, **Then** the operator sees a non-blocking update signal and a page-level freshness hint rather than a permanent loading impression.
|
||||
3. **Given** the operator already understands the legends, **When** the page loads in daily-use mode, **Then** legends are grouped and visually compact, with deeper explanation still available on demand.
|
||||
|
||||
### Edge Cases
|
||||
|
||||
- If total assigned tenants are greater than one but only one tenant is visible to the current actor, auto mode MUST choose compact mode, not dense mode.
|
||||
- If the operator manually overrides `auto` to `dense` or `compact`, the override MUST stay local to the matrix route and MUST NOT create a persisted user preference or domain artifact.
|
||||
- If filters reduce the visible row set to zero, the page MUST preserve the active mode and still show a clear empty state.
|
||||
- If compare runs are queued or running while the page is open, the refresh signal MUST remain distinct from a blocking loading state.
|
||||
- If dense mode cannot fit all compact cell details legibly, secondary detail MUST move behind tooltip, popover, expand, or a deliberate drilldown instead of widening every cell again.
|
||||
|
||||
## Requirements *(mandatory)*
|
||||
|
||||
**Constitution alignment (required):** This follow-up spec changes only the operator presentation of the existing matrix surface. It introduces no new Microsoft Graph path, no new baseline or finding truth, and no new mutation beyond the already-existing compare-start behavior.
|
||||
|
||||
**Constitution alignment (PROP-001 / ABSTR-001 / PERSIST-001 / STATE-001 / BLOAT-001):** The feature must remain a local presentation refactor on top of Spec 190. It MUST NOT introduce a new persisted report, a new compare artifact, a new domain state family, or a reusable density framework.
|
||||
|
||||
**Constitution alignment (OPS-UX):** Any compare-start controls remain bound to the existing `baseline_compare` run semantics from Spec 190. This spec only changes the presentation around those controls and their feedback, not the run model.
|
||||
|
||||
**Constitution alignment (RBAC-UX):** All existing `404` versus `403` semantics, visible-set-only counts, drilldown authorization, and capability checks remain unchanged. Dense or compact mode MUST never reveal more tenant truth than the current actor can already see.
|
||||
|
||||
**Constitution alignment (BADGE-001):** Dense and compact mode MUST reuse centralized state, freshness, trust, and severity badge semantics. This spec MUST NOT create page-local status colors or a second status vocabulary.
|
||||
|
||||
**Constitution alignment (UI-FIL-001):** The matrix page should continue to use Filament-native sections, actions, and shared primitives. The dense matrix body and compact single-tenant layout may use custom Blade composition where Filament's one-axis primitives are insufficient, but the page MUST avoid inventing a local semantic component framework.
|
||||
|
||||
**Constitution alignment (UI-NAMING-001):** Operator-facing labels must stay aligned with the vocabulary established in Spec 190, including `Baseline compare matrix`, `Compare assigned tenants`, `Reference snapshot`, `Visible tenants`, and the existing compare-state labels.
|
||||
|
||||
**Constitution alignment (UI-CONST-001 / UI-SURF-001 / UI-HARD-001 / UI-REVIEW-001):** The matrix remains a workspace operator surface with explicit inspect controls and forbidden row click. The primary working surface is the matrix body, while filters, legends, and status strips become supporting context.
|
||||
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-191-001 Primary working surface**: The matrix body MUST become visually dominant over reference context, filters, legends, and refresh hints.
|
||||
- **FR-191-002 Auto presentation mode**: The page MUST support an `auto` presentation mode that chooses dense multi-tenant mode when more than one visible tenant is in scope and compact single-tenant mode when exactly one visible tenant is in scope.
|
||||
- **FR-191-003 Manual override**: The page MUST allow a local manual override between `auto`, `dense`, and `compact` presentation without persisting that choice as domain truth or a stored user preference.
|
||||
- **FR-191-004 Dense multi-tenant layout**: Dense mode MUST render one subject row and one visible-tenant column with a sticky first subject column.
|
||||
- **FR-191-005 Dense cell contract**: Dense mode cells MUST default to compact state, trust, and freshness signals. Detailed reasons, long helper text, and multiple secondary links MUST NOT dominate the default cell chrome.
|
||||
- **FR-191-006 Single-tenant compact layout**: Compact mode MUST render a shorter subject-result list optimized for one visible tenant instead of a pseudo-matrix with repeated tenant headers and oversized cells.
|
||||
- **FR-191-007 Action calming**: Repeated follow-up actions such as tenant compare, finding, or run links MUST become visually secondary. The default focus in dense or compact mode MUST remain the compare state, not the link chrome.
|
||||
- **FR-191-008 Filter density**: The page MUST show active filter count and active filter scope clearly while keeping the filter zone visually compact.
|
||||
- **FR-191-009 Heavy-filter workflow**: Policy type and other heavy multi-select filters MUST use an explicit apply/reset interaction instead of forcing a full matrix recompute on every click.
|
||||
- **FR-191-010 Policy type usability**: Policy type filtering MUST be faster than the current long checkbox stack, for example by searchability, type-to-find behavior, or another equally compact operator-first selector.
|
||||
- **FR-191-011 Legend compression**: State, freshness, and trust legends MUST remain available but MUST be grouped and visually compressed so they do not displace the matrix in daily use.
|
||||
- **FR-191-012 Honest status transitions**: The page MUST distinguish between active loading, background auto-refresh, and last-updated freshness so operators can tell whether the matrix is recalculating or simply polling for updates.
|
||||
- **FR-191-013 Last updated visibility**: The page MUST show a page-level or matrix-level freshness hint indicating when the currently rendered matrix data was last refreshed.
|
||||
- **FR-191-014 Visible-set truth preserved**: Dense and compact mode MUST preserve the visible-set-only semantics already defined in Spec 190 for all counts, subject breadth, and drilldowns.
|
||||
- **FR-191-015 Drilldown continuity preserved**: Switching presentation mode MUST NOT break subject focus, tenant drilldowns, finding drilldowns, or return-path continuity already established on the matrix route.
|
||||
- **FR-191-016 No compare-logic changes**: This spec MUST NOT change how drift, trust, freshness, severity, or evidence gaps are calculated.
|
||||
- **FR-191-017 No new persistence**: This spec MUST NOT introduce a new matrix snapshot, portfolio report, stored view preference, or any other new persisted artifact.
|
||||
- **FR-191-018 Automated regression coverage**: Automated coverage MUST prove mode selection, sticky dense layout, compact single-tenant layout, filter apply/reset behavior, legend compression, non-blocking refresh state, and preservation of existing drilldowns and RBAC semantics.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- No change to baseline compare logic or evidence resolution
|
||||
- No new matrix export or stored report artifact
|
||||
- No new generic dense-table framework for other pages
|
||||
- No new finding workflow or remediation workflow
|
||||
- No mobile-first redesign of the matrix surface
|
||||
- No cross-workspace or tenant-vs-tenant compare feature
|
||||
|
||||
## Assumptions
|
||||
|
||||
- Spec 190 remains the canonical domain-truth foundation for the matrix.
|
||||
- Existing builder outputs can be extended or re-rendered without introducing new persistence.
|
||||
- Existing drilldown URLs and canonical navigation context can carry any local presentation override that must survive navigation.
|
||||
- Existing badge semantics already cover the status information needed for denser rendering.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Spec 190 baseline compare matrix route and builder
|
||||
- Existing matrix page and view
|
||||
- Existing badge semantics for state, freshness, trust, and severity
|
||||
- Existing tenant compare, finding, and run-detail destinations
|
||||
|
||||
## Risks
|
||||
|
||||
- Dense mode could drift into a local mini-framework if rendering rules become over-generalized.
|
||||
- Compacting actions too aggressively could hide next steps instead of calming them.
|
||||
- Apply/reset filtering could feel slower if the staged-filter state is not clearly signaled.
|
||||
- Manual mode override could create confusion if `auto` behavior and override state are not explicit.
|
||||
|
||||
## Review Questions
|
||||
|
||||
- Does the page now clearly separate supporting context from the primary working surface?
|
||||
- Is dense mode truly optimized for cross-tenant scanning rather than just a tighter version of the old layout?
|
||||
- Is single-tenant mode clearly calmer and shorter than the current matrix?
|
||||
- Are repeated actions secondary without becoming hard to discover?
|
||||
- Are filter count, legend compression, and last-updated feedback visible without dominating the page?
|
||||
- Does the spec stay local to the matrix surface and avoid importing a reusable UI framework?
|
||||
|
||||
## Definition of Done
|
||||
|
||||
This feature is complete when:
|
||||
|
||||
- the existing matrix route supports `auto`, `dense`, and `compact` presentation behavior,
|
||||
- multi-tenant auto mode renders a clearly denser matrix with a sticky subject column,
|
||||
- single-tenant auto mode renders a compact compare-list presentation instead of the current matrix-heavy layout,
|
||||
- supporting context is visibly lighter than the matrix body,
|
||||
- repeated per-cell or per-row actions no longer dominate the reading flow,
|
||||
- active filters are counted and heavy filters use an explicit apply/reset pattern,
|
||||
- legends remain available but are grouped and visually compressed,
|
||||
- page-level refresh and last-updated signals are honest and non-blocking,
|
||||
- no compare logic, trust logic, freshness logic, or RBAC semantics have changed,
|
||||
- and focused feature plus browser coverage proves the new operator-density behavior.
|
||||
146
specs/191-baseline-compare-operator-mode/tasks.md
Normal file
146
specs/191-baseline-compare-operator-mode/tasks.md
Normal file
@ -0,0 +1,146 @@
|
||||
# Tasks: Baseline Compare Matrix: High-Density Operator Mode
|
||||
|
||||
**Input**: Design documents from `/specs/191-baseline-compare-operator-mode/`
|
||||
**Prerequisites**: `plan.md`, `spec.md`, `research.md`, `data-model.md`, `quickstart.md`
|
||||
|
||||
**Tests**: Tests are REQUIRED. Extend Pest feature coverage and browser smoke coverage around the existing matrix route.
|
||||
**Operations**: This feature reuses existing `baseline_compare` run truth only. No new `OperationRun` type, no new run-summary contract, and no new notification channel should be introduced.
|
||||
**RBAC**: Existing workspace and tenant visibility rules from Spec 190 remain authoritative. Tasks must preserve visible-set-only aggregation and existing `404` vs `403` behavior.
|
||||
**Operator Surfaces**: The affected operator surface is the existing workspace baseline compare matrix route, with additive presentation changes only.
|
||||
**Filament UI Action Surfaces**: The matrix page keeps explicit drilldown controls and forbidden row click. No destructive action is added.
|
||||
**Badges**: Dense and compact rendering must continue to use centralized matrix state, trust, freshness, and severity semantics.
|
||||
|
||||
**Organization**: Tasks are grouped by user story so each operator-density improvement can be implemented and verified independently.
|
||||
|
||||
## Phase 1: Setup (Presentation Seams)
|
||||
|
||||
**Purpose**: Prepare focused acceptance seams for adaptive presentation work.
|
||||
|
||||
- [ ] T001 [P] Add presentation-mode acceptance scaffolds in `apps/platform/tests/Feature/Filament/BaselineCompareMatrixPageTest.php` and `apps/platform/tests/Browser/Spec190BaselineCompareMatrixSmokeTest.php`
|
||||
- [ ] T002 [P] Extend surface-contract guard coverage for calmer matrix actions in `apps/platform/tests/Feature/Guards/ActionSurfaceContractTest.php`
|
||||
|
||||
**Checkpoint**: The test suite has clear seams for dense mode, compact mode, and action-noise expectations.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: Foundational (Blocking Operator-Density Contract)
|
||||
|
||||
**Purpose**: Establish page-level presentation state and derived view metadata before reshaping the UI.
|
||||
|
||||
**⚠️ CRITICAL**: No story work should begin until the presentation contract is stable.
|
||||
|
||||
- [ ] T003 Add `auto`, `dense`, and `compact` presentation state handling plus route persistence in `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php`
|
||||
- [ ] T004 [P] Add derived density metadata for compact cell summaries and compact single-tenant summaries in `apps/platform/app/Support/Baselines/BaselineCompareMatrixBuilder.php`
|
||||
- [ ] T005 [P] Add page-level last-updated and staged-filter metadata in `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php`
|
||||
|
||||
**Checkpoint**: The page can resolve presentation mode and expose the supporting state required for dense and compact rendering.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: User Story 1 - Scan multi-tenant drift in dense mode (Priority: P1) 🎯 MVP
|
||||
|
||||
**Goal**: Make multi-tenant reading materially denser and faster without changing compare truth.
|
||||
|
||||
**Independent Test**: Open the matrix with multiple visible tenants and verify dense mode, sticky subject behavior, and state-first cells.
|
||||
|
||||
### Tests for User Story 1
|
||||
|
||||
- [ ] T006 [P] [US1] Add dense multi-tenant page coverage in `apps/platform/tests/Feature/Filament/BaselineCompareMatrixPageTest.php`
|
||||
- [ ] T007 [P] [US1] Extend browser smoke coverage for dense-mode scanning in `apps/platform/tests/Browser/Spec190BaselineCompareMatrixSmokeTest.php`
|
||||
|
||||
### Implementation for User Story 1
|
||||
|
||||
- [ ] T008 [US1] Render the dense multi-tenant matrix shell with sticky subject-column behavior in `apps/platform/resources/views/filament/pages/baseline-compare-matrix.blade.php`
|
||||
- [ ] T009 [US1] Reduce dense-cell chrome to compact state, trust, freshness, and attention signals in `apps/platform/resources/views/filament/pages/baseline-compare-matrix.blade.php`
|
||||
- [ ] T010 [US1] Calm repeated cell and tenant actions into compact secondary affordances in `apps/platform/resources/views/filament/pages/baseline-compare-matrix.blade.php` and `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php`
|
||||
- [ ] T011 [US1] Run focused US1 verification against `apps/platform/tests/Feature/Filament/BaselineCompareMatrixPageTest.php` and `apps/platform/tests/Browser/Spec190BaselineCompareMatrixSmokeTest.php`
|
||||
|
||||
**Checkpoint**: Multi-tenant scanning is visibly denser and the matrix body reads as the primary working surface.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: User Story 2 - Work a single visible tenant in compact mode (Priority: P2)
|
||||
|
||||
**Goal**: Replace pseudo-matrix rendering with a compact comparison surface when only one visible tenant remains.
|
||||
|
||||
**Independent Test**: Open the matrix with one visible tenant and verify compact mode in auto state plus drilldown continuity.
|
||||
|
||||
### Tests for User Story 2
|
||||
|
||||
- [ ] T012 [P] [US2] Add compact single-tenant coverage in `apps/platform/tests/Feature/Filament/BaselineCompareMatrixPageTest.php`
|
||||
|
||||
### Implementation for User Story 2
|
||||
|
||||
- [ ] T013 [US2] Resolve auto-to-compact presentation behavior for one visible tenant in `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php`
|
||||
- [ ] T014 [US2] Render the compact single-tenant compare list in `apps/platform/resources/views/filament/pages/baseline-compare-matrix.blade.php`
|
||||
- [ ] T015 [US2] Preserve subject focus and drilldown continuity across compact-mode state in `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php`
|
||||
- [ ] T016 [US2] Run focused US2 verification against `apps/platform/tests/Feature/Filament/BaselineCompareMatrixPageTest.php`
|
||||
|
||||
**Checkpoint**: One-tenant viewing is materially shorter and calmer than the current matrix surface.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: User Story 3 - Use filters, legends, and status surfaces without losing the matrix (Priority: P2)
|
||||
|
||||
**Goal**: Compress supporting context so it stays useful without pushing the matrix down or increasing visual noise.
|
||||
|
||||
**Independent Test**: Apply filters, inspect legends, and observe background refresh behavior without losing scanability.
|
||||
|
||||
### Tests for User Story 3
|
||||
|
||||
- [ ] T017 [P] [US3] Add filter apply/reset and legend-compaction coverage in `apps/platform/tests/Feature/Filament/BaselineCompareMatrixPageTest.php`
|
||||
- [ ] T018 [P] [US3] Add non-blocking refresh and last-updated browser coverage in `apps/platform/tests/Browser/Spec190BaselineCompareMatrixSmokeTest.php`
|
||||
|
||||
### Implementation for User Story 3
|
||||
|
||||
- [ ] T019 [US3] Convert heavy matrix filters to a staged apply/reset workflow in `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php` and `apps/platform/resources/views/filament/pages/baseline-compare-matrix.blade.php`
|
||||
- [ ] T020 [US3] Replace the current policy-type control with a faster compact operator-first selector in `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php`
|
||||
- [ ] T021 [US3] Group or collapse legends and lighten supporting context hierarchy in `apps/platform/resources/views/filament/pages/baseline-compare-matrix.blade.php`
|
||||
- [ ] T022 [US3] Render page-level last-updated, polling, and manual-refresh signals without blocking the matrix in `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php` and `apps/platform/resources/views/filament/pages/baseline-compare-matrix.blade.php`
|
||||
- [ ] T023 [US3] Run focused US3 verification against `apps/platform/tests/Feature/Filament/BaselineCompareMatrixPageTest.php` and `apps/platform/tests/Browser/Spec190BaselineCompareMatrixSmokeTest.php`
|
||||
|
||||
**Checkpoint**: Filters, legends, and status surfaces support the operator without visually competing with the matrix.
|
||||
|
||||
---
|
||||
|
||||
## Phase 6: Polish & Cross-Cutting Concerns
|
||||
|
||||
**Purpose**: Finalize copy, formatting, and the focused verification pack.
|
||||
|
||||
- [ ] T024 [P] Review `auto`, `dense`, `compact`, `last updated`, and action-copy vocabulary in `apps/platform/app/Filament/Pages/BaselineCompareMatrix.php` and `apps/platform/resources/views/filament/pages/baseline-compare-matrix.blade.php`
|
||||
- [ ] T025 [P] Run formatting with `cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent`
|
||||
- [ ] T026 Run the focused verification pack against `apps/platform/tests/Feature/Filament/BaselineCompareMatrixPageTest.php`, `apps/platform/tests/Feature/Baselines/BaselineCompareMatrixBuilderTest.php`, `apps/platform/tests/Feature/Guards/ActionSurfaceContractTest.php`, and `apps/platform/tests/Browser/Spec190BaselineCompareMatrixSmokeTest.php`
|
||||
|
||||
---
|
||||
|
||||
## Dependencies & Execution Order
|
||||
|
||||
### Phase Dependencies
|
||||
|
||||
- **Setup (Phase 1)**: starts immediately.
|
||||
- **Foundational (Phase 2)**: depends on Setup and blocks presentation work.
|
||||
- **US1 (Phase 3)**: depends on Phase 2 and is the MVP.
|
||||
- **US2 (Phase 4)**: depends on Phase 2 and can follow US1 once the page contract is stable.
|
||||
- **US3 (Phase 5)**: depends on Phase 2 and should land after dense and compact structure are in place.
|
||||
- **Polish (Phase 6)**: depends on the desired user stories being complete.
|
||||
|
||||
### Within Each User Story
|
||||
|
||||
- Add or extend the story tests first.
|
||||
- Land page-state changes before view-branching where possible.
|
||||
- Keep each story independently shippable and verifiable.
|
||||
|
||||
### Parallel Opportunities
|
||||
|
||||
- `T001` and `T002` can run in parallel.
|
||||
- `T004` and `T005` can run in parallel after `T003` defines the presentation contract.
|
||||
- Within US1, `T006` and `T007` can run in parallel before `T008` through `T010`.
|
||||
- Within US3, `T017` and `T018` can run in parallel before `T019` through `T022`.
|
||||
|
||||
## Implementation Strategy
|
||||
|
||||
1. Lock the presentation contract and route state first.
|
||||
2. Deliver dense multi-tenant mode as the MVP operator gain.
|
||||
3. Deliver compact single-tenant mode as the adaptive counterpart.
|
||||
4. Compress filters, legends, and status surfaces last so they match the final page structure.
|
||||
5. Finish with copy review, formatting, and the focused verification pack.
|
||||
Loading…
Reference in New Issue
Block a user