docs: add My Work candidate family

docs/product/spec-candidates.md

@@ -5,7 +5,7 @@ # Spec Candidates
 >
 > **Flow**: Inbox → Qualified → Planned → Spec created → moved to `Promoted to Spec`
 
-**Last reviewed**: 2026-04-20 (reconciled promoted candidates with current specs)
+**Last reviewed**: 2026-04-21 (added `My Work` candidate family and aligned it with existing promoted work)
 
 ---
 
@@ -600,6 +600,106 @@ ### Surface Taxonomy & Workflow-First IA Classification
 - **Dependencies**: Decision-First Operating Constitution Hardening, existing navigation/context/action-surface specs, product surface inventory
 - **Priority**: high
 
+### Personal Work IA / My Work
+- **Type**: IA / workflow foundation
+- **Source**: admin workspace IA discussion 2026-04-21; personal work architecture candidate pack
+- **Problem**: TenantPilot now has a real assignee-facing work surface in Spec 221 (`findings-operator-inbox`), but future personal work would otherwise fragment across findings, approvals, reviews, alerts, and exception-renewal surfaces without one stable "what is my work today?" entry point.
+- **Why it matters**: This is not just a navigation tweak. As TenantPilot becomes more workflow- and decision-oriented, personally addressed actionable work needs its own IA layer. Without that layer, discoverability, counts, and operator mental models drift by domain.
+- **Proposed direction**:
+  - Add a top-level `My Work` group in the admin panel as the personal lens on domain work, not as a second monitoring tree or favorites bucket
+  - Allow only surfaces that are explicitly assigned to the current user or awaiting that user's concrete decision
+  - Keep global domain navigation canonical for browsing, reporting, and non-personal work
+  - Treat the dashboard as a signal and entry surface, not the durable home of personal queues
+  - Start with the IA contract and admission rules; do not require every future child surface to ship together
+- **Admission rules**:
+  - Personal addressability: explicit assignee, approver, or decision owner; generic responsibility is insufficient
+  - Concrete next action: triage, approve, renew, close, escalate, or equivalent; reports and diagnostics alone are out
+  - Workspace-safe scope: rows, counts, and badges stay limited to visible, authorized workspace and tenant scope
+  - Personal value-add: the surface does more than deep-link to a global list by adding personal filtering, prioritization, or decision support
+  - No replacement of domain navigation: domain collections remain canonical outside the personal lens
+- **Vehicle note**: `My Work — Assigned Findings` is already materially represented by Spec 221 (`findings-operator-inbox`) and should be treated as the first concrete child surface rather than a second open candidate.
+- **Activation rule**: Introduce `My Work` as actual top-level navigation only once at least two real personal work surfaces exist or are committed near-term. Before that, the IA contract may exist without forcing a single-link top-level group.
+- **Explicit non-goals**: Not a generic "My Area", not profile/settings relocation, not favorites/bookmarks, not a universal task engine, not a dashboard replacement, and not a notification center.
+- **Boundary with Spec 221 (Findings Operator Inbox)**: Spec 221 defines the first concrete personal findings queue. This candidate defines the durable admin-IA rule that decides when that queue graduates into a broader personal-work group and how future personal surfaces should join it.
+- **Boundary with Human-in-the-Loop Autonomous Governance / Governance Inbox**: Governance Inbox is the long-horizon cross-workflow decision cockpit with structured recommendations and controlled execution. `My Work` is the nearer-term IA layer for personally addressed queues in the existing admin workspace. It should not absorb the full governance-inbox ambition.
+- **Dependencies**: Surface Taxonomy & Workflow-First IA Classification, Spec 221 (`findings-operator-inbox`), workspace/tenant scope enforcement, future assignment and approval routing semantics
+- **Priority**: high
+
+> `My Work` candidate family: keep child surfaces and cross-cutting semantics split so prioritization can land the IA contract, the next concrete personal queues, and the routing/count foundations independently instead of turning personal work into one oversized umbrella spec.
+
+### My Work — Pending Approvals
+- **Type**: workflow execution / approvals
+- **Source**: personal work architecture candidate pack 2026-04-21; future approval-bearing workflows
+- **Problem**: Approval work would otherwise be scattered across risk acceptance, drift governance, restore, or rollout surfaces without one trustworthy personal decision queue.
+- **Why it matters**: Approval is the cleanest form of personally addressed work. If it remains buried in domain pages, operators lose the "awaiting my decision" contract.
+- **Proposed direction**: Add a personal approvals queue for decisions that explicitly await the current user's approval or rejection; show decision summary, urgency, scope, and safe drilldown; keep FYI notifications and passive review signals out.
+- **Explicit non-goals**: Notification center, knowledge-only acknowledgements, general automation orchestration, or inventing a full approval engine before approval-producing domains exist.
+- **Dependencies**: Risk acceptance lifecycle (Spec 154), drift/change approval direction, restore or rollout approval producers, routing semantics
+- **Strategic sequencing**: Strong candidate for the second real `My Work` child surface because it naturally satisfies the admission rules.
+- **Priority**: high
+
+### My Work — Assigned Reviews
+- **Type**: workflow execution / review work
+- **Source**: personal work architecture candidate pack 2026-04-21; governance/review responsibility gap
+- **Problem**: Review work can easily remain hidden in tenant review, evidence, or governance surfaces even when a specific reviewer is responsible.
+- **Why it matters**: Reviews are person-bound work, but not all reviews are findings or approvals. A dedicated personal review queue keeps governance responsibility visible without flattening everything into one findings model.
+- **Proposed direction**: Add a review queue for review packs, evidence bundles, or governance review steps explicitly assigned to the current user; emphasize due state, review scope, and next action.
+- **Explicit non-goals**: Generic reporting hub, passive read receipts, or turning `My Work` into a full collaboration suite.
+- **Dependencies**: Review-layer maturity, evidence surfaces, assignment semantics, due-date conventions
+- **Priority**: medium
+
+### My Work — Risk Acceptance Renewals
+- **Type**: workflow execution / time-bound governance
+- **Source**: personal work architecture candidate pack 2026-04-21; exception-renewal follow-up
+- **Problem**: Expiring risk acceptances or exceptions create person-addressed renewal work, but that work is neither standard findings triage nor generic monitoring.
+- **Why it matters**: Renewal work is deadline-driven and materially important, so it needs a calm but trustworthy personal queue instead of disappearing inside exception detail pages.
+- **Proposed direction**: Add a renewal queue for expiring or expired risk acceptances where the current user is owner or required approver; support renew, close, or escalate next steps.
+- **Explicit non-goals**: Full exception lifecycle redesign or generic reminder infrastructure for every dated object in the product.
+- **Dependencies**: Spec 154 (`finding-risk-acceptance`), due/expiry semantics, routing semantics
+- **Priority**: medium
+
+### My Work — Actionable Alerts
+- **Type**: alerts / workflow execution
+- **Source**: personal work architecture candidate pack 2026-04-21; action-vs-notification boundary review
+- **Problem**: Some alerts represent concrete assigned follow-up, while others are only awareness signals. Without a boundary, `My Work` either becomes noisy or misses genuine action-bearing alerts.
+- **Why it matters**: `My Work` must stay quiet and trustworthy. Admitting every notification would destroy the queue's meaning; admitting none would keep action-bearing alerts disconnected from work.
+- **Proposed direction**: Route only alerts with explicit ownership and one clear next action into `My Work`; keep generic notifications, telemetry, and passive monitoring signals outside the group.
+- **Explicit non-goals**: General notification center, chat/activity feed, or bulk alert triage system.
+- **Dependencies**: Alert infrastructure, ownership semantics, escalation rules, personal count semantics
+- **Priority**: medium
+
+### My Work — Approval & Escalation Routing
+- **Type**: foundation / routing semantics
+- **Source**: personal work architecture candidate pack 2026-04-21; ownership and fallback analysis
+- **Problem**: Personal queues become inconsistent when owner, assignee, approver, escalation target, and fallback role mean different things in each domain.
+- **Why it matters**: `My Work` cannot be trustworthy without a shared answer to "why did this item land on me?" and "who gets it if no person is assigned?".
+- **Proposed direction**: Define shared routing semantics for assignee versus owner versus approver, fallback-to-role behavior, no-assignee escalation, and future delegation boundaries; keep this as a governance contract, not a UI-only heuristic.
+- **Explicit non-goals**: Full org-chart modeling, absence management, or automatic load balancing.
+- **Dependencies**: Ownership semantics (Spec 219), findings workflow, approval-producing domains, RBAC/capability model, alerting
+- **Strategic sequencing**: Foundational before `My Work` expands beyond findings into approvals, reviews, or renewals.
+- **Priority**: high
+
+### My Work — Personal Counts & Priority Semantics
+- **Type**: foundation / queue semantics
+- **Source**: personal work architecture candidate pack 2026-04-21; count-trust and priority-shaping analysis
+- **Problem**: Once more than one personal queue exists, badges and ordering can drift, double-count, or leak hidden scope unless the inclusion and weighting rules are explicit.
+- **Why it matters**: Personal counts are operator trust surfaces. If badges are noisy, inconsistent, or scope-leaky, the IA layer becomes less usable than the domain pages it was meant to simplify.
+- **Proposed direction**: Define group-badge inclusion, visible-scope count rules, urgency weighting for overdue versus pending approval versus reopened work, and the relationship between workspace-wide truth and active-tenant context.
+- **Explicit non-goals**: Complex cross-domain scoring engine, productivity gamification, or predictive prioritization.
+- **Dependencies**: `My Work` IA, routing semantics, alerting/approval/review producers, RBAC scope enforcement
+- **Strategic sequencing**: Must exist before a multi-surface `My Work` badge ships.
+- **Priority**: high
+
+### My Work — Dashboard Signals & Personal Entry Points
+- **Type**: IA / entry-point semantics
+- **Source**: personal work architecture candidate pack 2026-04-21; dashboard-versus-nav continuity analysis
+- **Problem**: Dashboard summary cards, CTA strips, and future personal queues can easily duplicate or contradict each other unless their roles are defined together.
+- **Why it matters**: The workspace dashboard should signal personal work, not become a second queue. Operators need consistent drill-in and return behavior between the dashboard and `My Work`.
+- **Proposed direction**: Define which personal signals belong on `/admin`, when a CTA is enough versus when a nav point is required, and how context/filter carry-over works between dashboard signals and personal queues.
+- **Explicit non-goals**: Full dashboard redesign or a second summary layer that mirrors every `My Work` list.
+- **Dependencies**: Spec 221 workspace signal, `My Work` IA, dashboard surface conventions, personal count semantics
+- **Priority**: medium
+
 ### MSP Multi-Tenant Portfolio Dashboard & SLA Reporting
 - **Type**: feature
 - **Source**: roadmap-to-spec coverage audit 2026-03-18, 0800-future-features brainstorming (pillar #1 — MSP Portfolio & Operations), product positioning for MSP portfolio owners