# 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.