From ab51cc6f978d9afc0fb3d35850f948719ccef56c Mon Sep 17 00:00:00 2001 From: Ahmed Darrazi Date: Tue, 21 Apr 2026 11:15:58 +0200 Subject: [PATCH] docs: add My Work candidate family --- docs/product/spec-candidates.md | 102 +++++++++++++++++++++++++++++++- 1 file changed, 101 insertions(+), 1 deletion(-) diff --git a/docs/product/spec-candidates.md b/docs/product/spec-candidates.md index d7275625..d905d288 100644 --- a/docs/product/spec-candidates.md +++ b/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