TenantAtlas/specs/225-assignment-hygiene/spec.md

Feature Specification: Assignment Hygiene & Stale Work Detection

Feature Branch: 225-assignment-hygiene
Created: 2026-04-22
Status: Draft
Input: User description: "Assignment Hygiene & Stale Work Detection"

Spec Candidate Check (mandatory — SPEC-GATE-001)

• Problem: Findings can enter a hidden decay path after assignment. Work disappears from the assignee's personal queue when access changes, remains pointed at assignees who no longer have tenant access or were soft-deleted, or stays in_progress long after meaningful work stopped.
• Today's failure: Operators can trust My Findings, intake, and notifications only until assignment truth drifts. Broken or stalled work then becomes harder to see than normal backlog, so accountability gaps survive longer than they should.
• User-visible improvement: One workspace-safe hygiene report and one overview signal expose broken assignments and stale in-progress work with clear reasons, owner context, and one drilldown into the existing finding detail for repair.
• Smallest enterprise-capable version: Add one canonical read-first hygiene report, one bounded derived hygiene reason vocabulary over existing finding and membership truth, and one workspace overview drill-in signal. Reuse existing finding detail actions for repair instead of inventing a new fixing workflow.
• Explicit non-goals: No automatic reassignment, no load balancing, no absence-management model, no new notification channel, no comments or ticketing, no bulk repair workflow, and no second findings state store.
• Permanent complexity imported: One canonical hygiene report page, one overview summary signal, one bounded derived hygiene-query contract, one small hygiene reason vocabulary, and focused regression coverage for cross-tenant visibility, classification, and drill-in safety.
• Why now: Spec 219 clarified owner versus assignee, Spec 221 created My Findings, Spec 222 created shared intake, and Spec 224 added notifications. The next missing slice is to keep those workflow surfaces trustworthy after work is assigned and begins.
• Why not local: A tenant-local filter or one extra badge would still leave hidden backlog distributed across many tenants and would not answer the cross-tenant question "which assigned work is no longer healthy right now?"
• Approval class: Core Enterprise
• Red flags triggered: One bounded derived reason vocabulary and one new canonical cross-tenant report surface. Scope remains acceptable because the feature derives from existing finding, membership, and lifecycle truth instead of adding persistence or automation.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexität: 1 | Produktnähe: 2 | Wiederverwendung: 1 | Gesamt: 10/12
• Decision: approve

Spec Scope Fields (mandatory)

• Scope: canonical-view
• Primary Routes:
  • /admin/findings/hygiene as the new canonical findings hygiene report
  • /admin as the workspace overview where the hygiene signal links into the report
  • /admin/t/{tenant}/findings/{finding} as the existing repair drilldown destination
• Data Ownership: Tenant-owned findings remain the only source of truth. The hygiene report is a derived cross-tenant view over existing finding lifecycle, responsibility, due-state, workflow-activity, tenant-entitlement, and assignee user soft-delete truth. No new persisted hygiene table or flag is introduced.
• RBAC: Workspace membership is required for the canonical hygiene report in the admin plane. The report route itself remains available to workspace members and renders only rows, counts, filter values, and drill-in CTAs for tenants they may already inspect; a workspace member with zero visible hygiene records receives an empty report rather than a route-level 403. Repair actions continue to reuse the existing tenant findings assign workflow and authorization on the finding detail surface. Non-members and out-of-scope users remain deny-as-not-found. Members missing the required capability remain forbidden on protected drilldown destinations.

For canonical-view specs, the spec MUST define:

• Default filter behavior when tenant-context is active: The hygiene report always keeps its fixed hygiene scope. When an active tenant context exists, the page additionally applies that tenant as a default prefilter while allowing the operator to clear only the tenant prefilter, not the hygiene scope itself.
• Explicit entitlement checks preventing cross-tenant leakage: Rows, counts, filter values, summary drill-ins, and empty-state hints are derived only from findings in tenants the current user may already inspect. Hidden tenants contribute nothing to the hygiene report or the overview signal.

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed; otherwise write N/A)

Surface / Change	Operator-facing surface change?	Native vs Custom	Shared-Family Relevance	State Layers Touched	Exception Needed?	Low-Impact / N/A Note
Findings hygiene report	yes	Native Filament page + existing table, filter, text-column, and empty-state primitives	Same findings workflow family as My Findings, intake, and finding detail	table, fixed hygiene reason views, row drill-in, tenant prefilter, summary counts	no	Read-first report only; no new mutation family
Workspace overview hygiene signal	yes	Native Filament widget or summary primitives	Same workspace-overview attention family as other /admin signals	embedded summary, drill-in CTA, visible-scope counts	no	Small entry signal only; not a second report

Decision-First Surface Role (mandatory when operator-facing surfaces are changed)

Surface	Decision Role	Human-in-the-loop Moment	Immediately Visible for First Decision	On-Demand Detail / Evidence	Why This Is Primary or Why Not	Workflow Alignment	Attention-load Reduction
Findings hygiene report	Primary Decision Surface	A workspace operator reviews decayed assignments or stalled in-progress work and decides what needs reassignment or manual follow-up first	Tenant, finding summary, hygiene reason, owner, assignee, due or overdue state, and last meaningful workflow activity	Full finding detail, evidence, audit trail, exception context, and existing assignment actions after opening the record	Primary because this is the first dedicated cross-tenant repair surface for work that has fallen between intake, personal execution, and normal notifications	Follows the operator's repair workflow instead of forcing tenant-by-tenant hunting for broken work	Removes repeated search across My Findings, intake, tenant lists, and overdue-only scans
Workspace overview hygiene signal	Secondary Context Surface	An operator lands on /admin and needs to know whether workflow hygiene already requires attention before choosing another work surface	Current unique hygiene issue count, a short description derived from broken-assignment and stale-in-progress counts, and one CTA into the report	Full report and finding detail after drill-in	Secondary because it points to the real repair surface rather than becoming its own queue	Keeps workspace home aligned with findings workflow integrity	Avoids opening multiple findings pages just to discover whether hidden backlog exists

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

Surface	Action Surface Class	Surface Type	Likely Next Operator Action	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 / Justification
Findings hygiene report	List / Table / Bulk	Read-only Registry / Report Surface	Open the affected finding and repair responsibility from the existing detail workflow	Finding	required	Utility filters and tenant-prefilter clear affordances stay outside row action noise	none on the report; dangerous actions remain on the existing finding detail	/admin/findings/hygiene	/admin/t/{tenant}/findings/{finding}	Active workspace, optional active-tenant prefilter, tenant column, hygiene reason filters	Findings / Finding	Which findings have broken assignment truth or stalled in-progress work, and why	none
Workspace overview hygiene signal	Utility / System	Read-only Registry / Report Surface	Open the hygiene report	Explicit summary CTA	forbidden	Summary strip only	none	/admin	/admin/findings/hygiene	Active workspace and visible-scope counts	Findings hygiene	Whether any visible findings workflow hygiene issue already needs attention	Embedded summary drill-in that stays read-only and points into the canonical report rather than becoming its own queue surface

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

Surface	Primary Persona	Decision / Operator Action Supported	Surface Type	Primary Operator Question	Default-visible Information	Diagnostics-only Information	Status Dimensions Used	Mutation Scope	Primary Actions	Dangerous Actions
Findings hygiene report	Workspace operator, tenant manager, or findings workflow steward	Decide which broken or stalled finding needs repair first	Read-first workflow hygiene report	Which visible findings are no longer in a healthy execution path, and what kind of repair do they need?	Tenant, finding summary, owner, assignee when present, hygiene reason, due or overdue state, and last meaningful workflow activity	Raw evidence, run context, audit trail, and full lifecycle history after opening the finding	lifecycle, responsibility validity, work freshness, due urgency	none on the report itself; existing tenant finding surfaces keep their current mutation scopes	Open finding, apply filters, clear tenant prefilter	none
Workspace overview hygiene signal	Workspace member with findings visibility	Decide whether findings workflow hygiene already needs review now	Summary drill-in	Do I need to repair hidden or stalled findings work before I continue elsewhere?	Unique hygiene issue count, a short description derived from broken-assignment and stale-in-progress counts, and one CTA	none	issue presence, reason composition, visible scope	none	Open findings hygiene	none

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no
• New persisted entity/table/artifact?: no
• New abstraction?: yes — one bounded derived hygiene-query contract over existing finding lifecycle, responsibility, tenant-entitlement, and assignee user soft-delete truth
• New enum/state/reason family?: yes — one bounded derived hygiene reason vocabulary for broken assignment and stale in progress
• New cross-domain UI framework/taxonomy?: no
• Current operator problem: Assigned findings can disappear from personal execution surfaces or remain stuck in in_progress without one truthful repair view, which weakens trust in the broader findings workflow.
• Existing structure is insufficient because: My Findings answers "what is assigned to me," intake answers "what is still unassigned," and notifications answer "what just happened." None of those surfaces answers "what assigned or in-progress work is now unhealthy across my visible tenants?"
• Narrowest correct implementation: Add one derived cross-tenant hygiene report and one overview signal, reuse existing detail actions for repair, and keep hygiene truth derived rather than persisted.
• Ownership cost: Ongoing maintenance for one small reason vocabulary, one canonical report query, overview summary assertions, and regression coverage for tenant-safe classification.
• Alternative intentionally rejected: Automatic reassignment, reminder loops, or a new workflow engine were rejected because they act on the problem before operators have one trustworthy view of the problem.
• Release truth: Current-release truth. This feature makes the current findings workflow honest and repairable now rather than preparing a future autonomous routing system.

Compatibility posture

This feature assumes a pre-production environment.

Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.

Canonical replacement is preferred over preservation.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Feature
• Validation lane(s): fast-feedback, confidence
• Why this classification and these lanes are sufficient: The feature is proven by visible operator behavior on one canonical cross-tenant report and one workspace summary signal. Focused feature coverage is sufficient to prove classification truth, visibility boundaries, tenant-prefilter behavior, and drill-in safety without introducing browser or heavy-governance cost.
• New or expanded test families: Add focused hygiene-report visibility tests, hygiene-classification tests for broken assignment and stale work, overview-signal count tests, and tenant-prefilter empty-state tests.
• Fixture / helper cost impact: Moderate. Tests need findings with explicit owner and assignee combinations, stale and fresh workflow timestamps, entitlement-lost and soft-deleted assignee cases, and mixed visible versus hidden tenant memberships.
• Heavy-family visibility / justification: none
• Special surface test profile: global-context-shell
• Standard-native relief or required special coverage: Ordinary feature coverage is sufficient, plus explicit proof that healthy unassigned intake backlog does not leak into the hygiene report, hidden-tenant findings never appear in rows or counts, and one finding with multiple hygiene reasons is counted once.
• Reviewer handoff: Reviewers must confirm that broken-assignment classification is derived from current tenant entitlement and assignee soft-delete truth rather than stale cached assumptions, that stale work does not collapse into overdue-only logic, that report rows remain read-first, and that the overview signal matches the canonical report under the same visible scope.
• Budget / baseline / trend impact: none
• Escalation needed: none
• Active feature PR close-out entry: Guardrail
• Planned validation commands:
  • cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Findings/FindingsAssignmentHygieneReportTest.php
  • cd apps/platform && ./vendor/bin/sail artisan test --compact tests/Feature/Findings/FindingsAssignmentHygieneClassificationTest.php tests/Feature/Findings/FindingsAssignmentHygieneOverviewSignalTest.php

User Scenarios & Testing (mandatory)

User Story 1 - See broken assignments in one repair view (Priority: P1)

As a workspace operator, I want one cross-tenant report of findings whose assignment is no longer actionable, so I can repair hidden backlog before it silently disappears from personal work surfaces.

Why this priority: This is the smallest slice that closes the trust gap left after assignment. If broken assignments remain invisible, the newer findings queues and notifications are not reliable enough to operate on.

Independent Test: Can be fully tested by seeding assigned findings where the assignee no longer has current tenant access or the assignee user record is soft-deleted, then verifying that the report shows those rows with owner context and safe drilldown.

Acceptance Scenarios:

1. Given an open finding is still assigned but the assignee no longer has current entitlement to inspect that tenant, When an entitled workspace operator opens the hygiene report, Then the finding appears with the hygiene reason broken assignment.
2. Given an open finding is assigned to a user whose account was soft-deleted, When an entitled workspace operator opens the hygiene report, Then the finding appears with the hygiene reason broken assignment.
3. Given a finding belongs to a hidden tenant, When the current user opens the hygiene report, Then that finding contributes nothing to rows, counts, filter values, or empty-state hints.

---

User Story 2 - Detect stalled in-progress work before it becomes hidden backlog (Priority: P1)

As a findings workflow steward, I want stale in_progress work surfaced separately from normal overdue work, so I can intervene on work that stopped moving without assuming every overdue finding is stale.

Why this priority: Stale work detection is the second half of hygiene. Without it, the product can only detect broken assignees, not stalled execution.

Independent Test: Can be fully tested by seeding fresh and stale in_progress findings across visible tenants and verifying that only stale findings appear with the correct reason while fresh or merely overdue findings stay out of the report.

Acceptance Scenarios:

1. Given an open finding has remained in_progress with no meaningful workflow activity for seven consecutive days, When an entitled workspace operator opens the hygiene report, Then the finding appears with the hygiene reason stale in progress.
2. Given an open finding is overdue but has recent meaningful workflow activity, When an entitled workspace operator opens the hygiene report, Then the finding does not appear solely because it is overdue.
3. Given one finding has both a broken assignment and stale in-progress work, When the hygiene report is rendered, Then the finding appears as a single row with both reasons visible and contributes one unique issue to summary counts.

---

User Story 3 - Discover hygiene issues from the workspace overview (Priority: P2)

As a workspace member with findings visibility, I want the workspace overview to show whether findings workflow hygiene already needs attention, so I can enter the repair report without scanning multiple pages.

Why this priority: The canonical report is valuable only if operators can discover it in normal workspace navigation. A small summary signal is the narrowest discoverability improvement.

Independent Test: Can be fully tested by seeding both visible hygiene issues and a zero-issue visible scope, loading /admin, verifying the attention-state and calm-state signal variants, and following the CTA into the canonical report.

Acceptance Scenarios:

1. Given the current user has visible hygiene issues across one or more tenants, When the user opens /admin, Then the workspace overview shows one findings hygiene signal with the correct unique issue count.
2. Given the current user has no visible hygiene issues, When the user opens /admin, Then the workspace overview shows the same findings hygiene signal in a calm state with zero visible issues, calm descriptive copy, and the canonical CTA into the report.
3. Given the current user opens that signal, When the CTA is used, Then the user lands on /admin/findings/hygiene with the same visible-scope truth.

Edge Cases

• A single finding may have multiple hygiene reasons at once; the report must show one row per finding and surface all applicable reasons without duplicating counts.
• An unassigned finding in normal intake scope is not a hygiene issue by itself; it remains handled by the intake workflow unless it independently qualifies as stale in_progress work.
• A resolved, closed, or otherwise terminal finding must leave the hygiene report immediately even if it was previously stale or broken.
• An active tenant prefilter may produce an empty hygiene report while other visible tenants still contain issues; the empty state must explain the filter boundary instead of claiming no issues exist anywhere.
• A finding may remain accountable to an owner even when its assignee is broken; owner context must stay visible so repair can start from the correct person.

Requirements (mandatory)

Constitution alignment (required): This feature adds no Microsoft Graph calls, no new write path, and no new OperationRun. It introduces one canonical admin-plane report and one overview signal derived from existing finding, lifecycle, membership, and assignee user soft-delete truth. Repair continues through existing tenant findings actions and their current audit coverage.

Constitution alignment (TEST-GOV-001): The proof burden is focused feature coverage for hygiene classification, visibility boundaries, tenant-prefilter behavior, workspace overview signal consistency, and drill-in safety. No browser or heavy-governance lane is required.

Constitution alignment (RBAC-UX): The feature operates in the admin /admin plane for the canonical report and overview signal, with tenant entitlement enforced per finding before disclosure and before drilldown to /admin/t/{tenant}/findings/{finding}. Non-members or out-of-scope users continue to receive 404. In-scope users lacking the existing findings view capability continue to receive 403 on protected drilldown destinations, while the workspace report itself renders only the rows they may inspect. Repair actions continue to reuse the existing findings assign authorization on the tenant detail surface. No raw capability strings, role checks, or second permission system may be introduced.

Constitution alignment (UI-FIL-001): The report and overview signal must use native Filament page, table, filter, stat, and empty-state primitives or existing shared UI helpers. Hygiene reasons remain plain-text reason labels in the report and do not introduce a new BADGE-001 status mapping. No local status language, ad hoc color system, or custom badge markup may be introduced for hygiene reasons.

Constitution alignment (UI-NAMING-001): The canonical operator-facing vocabulary is Findings hygiene, Broken assignment, Stale in progress, Open finding, and Open findings hygiene. Terms such as repair record, workflow defect, or queue health object must not replace the finding domain language in primary labels.

Constitution alignment (DECIDE-001): The hygiene report is a primary repair surface because it answers one operator question in one place: which findings workflow items are no longer healthy? The overview signal is a secondary drill-in only and must not become a second report.

Constitution alignment (UI-CONST-001 / UI-SURF-001 / ACTSURF-001 / HDR-001): The hygiene report has exactly one primary inspect model: the finding. Row click is required. There is no redundant View action. Utility controls such as tenant filter and hygiene reason filters stay outside row action noise. Dangerous lifecycle actions remain on the existing finding detail instead of being promoted into the report. The workspace overview signal remains a summary drill-in surface with one explicit CTA.

Constitution alignment (UI-SEM-001 / LAYER-001 / TEST-TRUTH-001): Direct mapping from current queues is insufficient because healthy assigned work, unassigned intake work, and unhealthy hidden backlog are different operator questions. This feature solves that by adding one derived hygiene interpretation over existing domain truth rather than a persisted workflow mirror. Tests must prove visible workflow consequences, not thin presentational indirection.

Functional Requirements

• FR-001: The system MUST provide a canonical findings hygiene report at /admin/findings/hygiene for the current user's visible tenant scope.
• FR-002: The hygiene report MUST include only non-terminal findings that satisfy at least one hygiene reason. It MUST NOT duplicate healthy assigned work or ordinary intake backlog.
• FR-003: The feature MUST derive hygiene truth from existing finding lifecycle, responsibility, tenant-entitlement, and assignee user soft-delete truth without introducing a persisted hygiene flag, table, or workflow state.
• FR-004: The system MUST classify broken assignment when a non-terminal finding still has an assignee but that assignee cannot currently act on the finding because they no longer have current tenant entitlement or the assignee user record is soft-deleted.
• FR-005: The system MUST classify stale in progress when a non-terminal finding remains in_progress with no meaningful workflow activity for seven consecutive days.
• FR-006: Meaningful workflow activity for stale detection MUST reset when responsibility or lifecycle state changes in a way that materially advances the finding, including assignment changes, start-progress transitions, or reopen-driven lifecycle resets.
• FR-007: Overdue status and stale-work status MUST remain separate dimensions. A finding MUST NOT enter the hygiene report solely because it is due soon or overdue.
• FR-008: If one finding satisfies multiple hygiene reasons, the report MUST render that finding once and show all applicable reasons without duplicating unique issue counts.
• FR-009: The report MUST show by default the tenant, finding summary, accountable owner, current assignee when present, hygiene reason or reasons, due or overdue state, and last meaningful workflow activity timestamp.
• FR-010: The hygiene report MUST remain read-first. Its only primary inspect model is the finding, reached through row click into the existing tenant finding detail route.
• FR-011: The hygiene report MUST NOT introduce inline reassignment, bulk reassignment, auto-fix actions, or a second repair workflow. Existing tenant finding actions remain the place where repair happens.
• FR-012: The workspace overview at /admin MUST expose one findings hygiene summary signal that shows the current unique visible issue count, a short description derived from broken-assignment and stale-in-progress counts, and drills into the canonical hygiene report. When the current user has no visible hygiene issues, the same signal MUST render calm-state copy with zero visible issues and the same canonical CTA.
• FR-013: When tenant context is active, the hygiene report MUST prefilter to that tenant while preserving the fixed hygiene scope. Operators MUST be able to clear only the tenant prefilter.
• FR-014: Hidden tenants MUST contribute nothing to hygiene rows, counts, filter values, or empty-state hints.
• FR-015: Existing My Findings and intake contracts MUST remain unchanged. Healthy assigned work stays discoverable through My Findings, normal unassigned backlog stays discoverable through intake, and the hygiene report exists only for findings workflow items that would otherwise become hidden or misleading.
• FR-016: The report MUST provide fixed reason filters for All issues, Broken assignment, and Stale in progress.
• FR-017: The filtered-empty state MUST explain when the current tenant prefilter is narrowing visible issues and provide exactly one CTA that clears the tenant prefilter back to all visible tenants.
• FR-018: The feature MUST NOT add automatic reassignment, scheduled escalation, or a second notification channel. Any later automation MUST be a separate spec built on top of this repair surface.

UI Action Matrix (mandatory when Filament is changed)

Surface	Location	Header Actions	Inspect Affordance (List/Table)	Row Actions (max 2 visible)	Bulk Actions (grouped)	Empty-State CTA(s)	View Header Actions	Create/Edit Save+Cancel	Audit log?	Notes / Exemptions
Findings hygiene report	/admin/findings/hygiene	none	Full-row open into finding detail	none; row click is the only primary inspect affordance	none	Clear tenant filter only when a tenant prefilter causes the empty state; otherwise none	n/a	n/a	No new mutation audit because the surface stays read-only	Action Surface Contract satisfied. No redundant View action, no empty action groups, and no dangerous action promoted into the report.
Workspace overview hygiene signal	/admin	none	Explicit summary CTA into the report	none	none	none	n/a	n/a	No new mutation audit because the surface stays read-only	Embedded summary drill-in only. It points to the canonical report and does not introduce a second work surface.

Key Entities (include if feature involves data)

• Finding hygiene issue: A derived workflow integrity issue attached to a visible non-terminal finding when assignment is broken or in-progress work has stalled.
• Broken assignment: A derived reason indicating that the assigned operator can no longer act on the finding according to current tenant-entitlement or assignee user soft-delete truth.
• Stale in-progress work: A derived reason indicating that a finding has remained in_progress without meaningful workflow activity for the defined stale window.

Success Criteria (mandatory)

Measurable Outcomes

• SC-001: In acceptance review, an operator can identify why a finding appears on the hygiene report and open the correct finding in one interaction.
• SC-002: 100% of covered automated classification tests include broken-assignment and stale findings while excluding healthy assigned work, ordinary intake backlog, and merely overdue-but-active findings.
• SC-003: 100% of covered visibility tests show that hidden-tenant findings contribute nothing to hygiene rows, counts, filter values, or overview signals.
• SC-004: 100% of covered summary tests show that the workspace overview hygiene count matches the canonical report's unique visible issue count under the same scope.

Assumptions

• Existing finding lifecycle and audit-related timestamps expose enough signal to derive last meaningful workflow activity without introducing new persistence.
• The v1 stale threshold is fixed at seven days of inactivity for in_progress findings.
• Broken-assignment truth in v1 uses only current tenant entitlement and assignee user soft-delete truth already modeled by the product; no broader availability, absence, or capacity model is introduced.
• Repair continues through the existing finding detail and responsibility actions rather than directly from the hygiene report.

Non-Goals

• Automatically reassign findings, clear assignees, or mutate workflow state from the hygiene report.
• Add reminder loops or notification behavior beyond the separate notifications and escalation spec.
• Introduce team-capacity balancing, absence management, or load-distribution logic.
• Fold resolved-versus-verified outcome semantics into this spec.
• Create a second findings history, audit, or workflow-state store.

Dependencies

• Spec 111 remains the source of truth for finding lifecycle, due state, and open versus terminal semantics.
• Spec 219 remains the source of truth for owner-versus-assignee meaning.
• Spec 221 remains the source of truth for healthy personal assigned-work discovery in My Findings.
• Spec 222 remains the source of truth for normal unassigned findings intake.
• Spec 224 remains the adjacent notification slice that points operators toward work changes but does not replace a repair view for decayed assignments or stalled work.