# Spec Candidates > **Status:** Active > **Last reviewed:** 2026-05-02 > **Use for:** The active repo-based queue of spec candidates that may still need new or refreshed specs > **Do not use for:** Proof that a candidate is already specced, implemented, or prioritized above the roadmap without repo verification > **Scoped maintenance:** 2026-05-02 repo-based queue re-audit plus enterprise-SaaS deep-research alignment against current `specs/` truth, including Specs 263 and current-branch 264. > > Repo-based next-spec queue for TenantPilot. > This file is not a wishlist. It tracks only open gaps that are still worth turning into new or refreshed specs. **Basis**: `implementation-ledger.md`, `roadmap.md`, current `specs/` truth --- ## Candidate Rules - Work repo-based, not roadmap-aspirational. - Do not keep implemented features as active candidates. - Do not keep already-specced foundations as active candidates unless a narrower follow-up gap remains. - P0 is reserved for blockers to the next sellable release. - P1 is for enterprise and product maturity gaps. - P2 is for commercial and scale readiness. - P3 is for later platform ambitions after current release blockers close. - Existing candidate history is preserved through `Promoted to Spec`, `Deferred`, and `Superseded / Removed` notes rather than silent deletion. ## Current Source-Of-Truth Boundary - This file is the active candidate queue. - `roadmap.md` provides strategic themes and release framing, not the canonical candidate queue. - `discoveries.md` is a staging area for findings that may later be promoted here. - `implementation-ledger.md` is maturity evidence, not a prioritization queue. - Audit-derived candidate packages under `docs/audits/` are historical inputs only unless they are explicitly promoted into this file. - The deep-research alignment reference below sharpens naming, status markers, and target sequencing without reopening already-promoted specs as active queue items. ## Deep-Research Alignment Reference (non-queue) This section is a deep-research-derived calibration layer. It is intentionally not the active queue. Use it to keep candidate naming, scope, and status language aligned with current repo truth. ### Customer Review Workspace v1 - **Status markers**: repo-verified, productization gap - **Roadmap lane**: Now - **Current repo truth**: Specs 249 and 258, plus the implementation ledger and current review surfaces, already prove the foundational and productization path for customer-safe review consumption. - **Problem**: Customer-safe review consumption remains the clearest sellability gap whenever review truth, accepted risks, evidence, and package delivery still require operator translation. - **Deep-Research-derived sharpening**: Keep the lane focused on one customer-safe read-only review surface, findings summary, accepted-risk visibility, evidence viewer, review-pack download, management summary, RBAC/capability enforcement, and audit trail. - **Non-goals**: no generic customer portal, no helpdesk surface, no raw diagnostics by default, no admin mirror. ### Decision-Based Governance Inbox + Decision Register v1 - **Status markers**: repo-verified, productization gap, roadmap recommendation - **Roadmap lane**: Now - **Current repo truth**: governance inbox, findings queues, operations attention, review follow-up, and Specs 250 and 257 already anchor the decision surface, but there is still no bounded decision-register follow-through. - **Problem**: Findings, alerts, runs, and reviews still need one calmer decision layer with ownership, due state, reason, impact, next action, linked evidence, linked `OperationRun`, accepted-risk path, closure reason, and escalation hooks. - **Deep-Research-derived sharpening**: treat the missing slice as decision-register and approval/closure follow-through over current inbox foundations, not as another queue page. - **Non-goals**: no generic Kanban board, no PSA clone, no XDR incident console. ### Governance Artifact Lifecycle & Retention v1 - **Status markers**: foundation-only, roadmap recommendation, spec candidate - **Roadmap lane**: Now - **Current repo truth**: Spec 262, the lifecycle-governance standard, review-pack retention, and artifact-truth semantics provide taxonomy-first foundations, but not a productized governance-artifact lifecycle. - **Problem**: Evidence snapshots, stored reports, review packs, and future decision records are governance artifacts and must not be treated like short-lived operational rows. - **Roadmap Recommendation**: v1 should cover artifact-type registry, immutable artifact reference, artifact state, retention state, export bundle, preserve or hold state, soft delete or hard delete semantics, suspended/read-only workspace behavior, and audit trail for export/delete/hold. - **Non-goals**: no legal case management, no full eDiscovery system, no Purview clone. ### Commercial Entitlements & Billing-State Lifecycle v1 - **Status markers**: repo-verified, foundation-only, productization gap - **Roadmap lane**: Now - **Current repo truth**: Specs 247 and 251 already ground workspace entitlements, lifecycle state handling, and read-only gating. - **Problem**: Workspace, plan, and billing state still need clearer artifact-access, archive, scheduled-deletion, and customer-trust semantics. - **Deep-Research-derived sharpening**: keep the lane framed as commercial lifecycle, workspace read-only behavior, artifact access by state, capability gating, and audited state change semantics rather than payment-engine work. - **Non-goals**: no payment gateway, no invoicing engine, no tax engine. ### External Support Desk / PSA Handoff v1 - **Status markers**: repo-verified, productization gap - **Roadmap lane**: Next - **Current repo truth**: Spec 256 and the current support-request handoff already prove a bounded create/link model. - **Problem**: MSP governance work still needs cleaner PSA/ITSM handoff with external reference continuity, evidence/context transfer, due date/status mapping, closure sync or manual reconciliation, audit trail, and webhook-ready shape. - **Deep-Research-derived sharpening**: keep PSA/ITSM as integration and handoff, not as a TenantPilot-native helpdesk. - **Non-goals**: no PSA clone, no project-management suite, no generic helpdesk. ### Customer-Facing Localization v1 - **Status markers**: foundation-only, productization gap - **Roadmap lane**: Next - **Current repo truth**: Spec 252 and the locale resolver already provide the foundation. - **Problem**: DE/EN customer-facing review consumption still lacks full glossary discipline, customer-safe labels, review-pack templates, notification text, and fallback confidence. - **Deep-Research-derived sharpening**: v1 means glossary, review-workspace strings, review-pack templates, evidence labels, status/reason/impact/next-action labels, locale-aware formatting, fallback behavior, and missing-key tests. - **Non-goals**: no full operator-UI localization in v1, no marketing translation project, no uncontrolled string extraction. ### Cross-Tenant Compare & Promotion with Lineage v1 - **Status markers**: repo-verified, productization gap - **Roadmap lane**: Next - **Current repo truth**: Spec 043 is already repo-real for compare and preflight, and Spec 264 now carries the execution follow-through on this branch. - **Problem**: portfolio action still needs governance-first execution with impact preview, promotion proposal, approval, `OperationRun` trace, before/after evidence, baseline lineage, rollback reference, and decision-record linkage. - **Deep-Research-derived sharpening**: keep this lane governance-first. It is not a generic policy-push or settings-sync surface. - **Non-goals**: no unmanaged mass remediation, no generic settings push, no admin mirror. ### Governance Service Packaging v1 - **Status markers**: repo-verified, productization gap - **Roadmap lane**: Next - **Current repo truth**: Spec 260 and current governance-package delivery cues already exist. - **Problem**: MSPs need repeatable governance-service packages with review cadence, included controls/reports, stakeholder mapping, schedule, package-specific review-pack semantics, and entitlement binding. - **Deep-Research-derived sharpening**: productize packaging as a repeatable governance service, not as one-off executive exports or bespoke customer projects. - **Non-goals**: no CRM, no PSA, no billing system. ### Enterprise Access Boundary & Support Access Governance v1 - **Status markers**: roadmap recommendation, spec candidate - **Roadmap lane**: Next when support-access gaps turn operationally acute; otherwise Later - **Current repo truth**: audit docs and handover material already show break-glass, system access, and platform support seams, but not a bounded support-access governance package. - **Problem**: support access, delegated access, and future impersonation need customer-safe auditability, reason capture, TTL, approval, operator-context banner, and exportable access logs before broader SSO/SCIM work. - **Roadmap Recommendation**: prioritize support-access request, reason required, time-limited access, capability-bound access, customer-visible audit trail, optional approval, break-glass separation, operator context banner, and exportable access log. - **Non-goals**: no full IAM suite, no immediate SCIM requirement unless separately promoted, no unrestricted impersonation. ### Private AI Execution Governance Foundation v1 - **Status markers**: repo-verified, foundation-only, later scale-layer - **Roadmap lane**: Later - **Current repo truth**: Spec 248 is already implemented as a governed AI foundation. - **Problem**: visible AI work must still avoid feature-island drift and should only ship on top of governed use-case, provider-class, policy, audit, and approval boundaries. - **Deep-Research-derived sharpening**: keep AI foundation-first. The next visible candidate is a bounded governed runtime consumer or AI-assisted review-drafting lane, not a new foundation reboot. - **Non-goals**: no public LLM by default, no autonomous remediation, no chatbot over raw tenant data, no AI without audit and policy boundaries. ## Active Candidate Queue **2026-05-01 queue re-audit result**: no safe automatic next-best-prep target remains in the active queue. The previous P0-P2 candidates were removed from the active queue because current `specs/` truth already covers them as prepared or implemented packages: - `Customer Review Workspace Productization v1` -> Spec 258 - `Governance Decision Surface Convergence` -> Spec 257 - `Cross-Tenant Compare and Promotion v1` -> refreshed Spec 043 - `Remove Findings Lifecycle Backfill Runtime Surfaces` -> Spec 253 - `Remove Legacy Acknowledged Finding Status Compatibility` -> Spec 254 - `Enforce Creation-Time Finding Invariants` -> Spec 255 - `Commercial Entitlements and Billing-State Maturity` -> Spec 251 - `Compliance Evidence Mapping v1` -> Spec 259 - `Governance-as-a-Service Packaging v1` -> Spec 260 - `External Support Desk / PSA Handoff` -> Spec 256 These packages already provide the needed preparation surface, and several now carry completed task checklists or implementation close-out history. They must not be auto-selected again by `next-best-prep`. Two manual-promotion items have since moved out of backlog status on the current repo state: - `Auditor Pack Delivery & Executive Export v1` -> Spec 263 - `Cross-Tenant Promotion Execution v1` -> Spec 264 The historical record for `Workspace, Tenant & Managed Object Lifecycle Governance v1` remains below because it was promoted intentionally, not automatically, into Spec 262 and must not re-enter the active auto-prep queue. ## Promotable Candidate Backlog **Boundary**: manual promotion only, not auto-prep. These items are intentionally outside `next-best-prep` and require an explicit product decision before any future spec refresh or follow-up work. ### Decision Register & Approval Workflow v1 - **Priority**: 1 - **Repo truth**: governance inbox and convergence are spec-backed and partly repo-real, but the bounded decision-register and approval workflow is still a distinct follow-up gap. - **Why promotable now**: it is the highest-value unspecced operator follow-through once inbox and review consumption are already grounded. - **Why manual promotion only**: this must stay a deliberate product choice because v1 should remain narrow: owner, due date, status, reason, impact, next action, linked evidence, linked `OperationRun`, accepted-risk path, closure reason, escalation hook, and optional approval or closure semantics without autonomous remediation. - **Anchors**: - `specs/250-decision-governance-inbox/spec.md` - `specs/257-governance-decision-convergence/spec.md` - `docs/product/roadmap.md` ### Governance Artifact Lifecycle & Retention v1 - **Priority**: 2 - **Repo truth**: lifecycle taxonomy, artifact-truth semantics, and point retention rules already exist, but governance artifacts still lack one productized lifecycle runtime contract. - **Why promotable now**: this is the clearest new trust and auditability gap highlighted by the deep research. - **Why manual promotion only**: it crosses lifecycle, artifact, export, retention, and suspension semantics and therefore needs an explicit product boundary rather than automatic prep. - **Anchors**: - `specs/158-artifact-truth-semantics/spec.md` - `specs/262-lifecycle-governance-taxonomy/spec.md` - `docs/product/standards/lifecycle-governance.md` ### Billing & Subscription Truth Layer v1 - **Priority**: 3 - **Repo truth**: plans, entitlements, and commercial lifecycle maturity are already spec-backed, but the billing/subscription truth layer is still missing. - **Why promotable now**: deep-research alignment moves commercial trust and lifecycle closer to the now lane, even though the remaining unspecced slice is still the narrower billing/subscription follow-through. - **Why manual promotion only**: the broad readiness work is already covered, so this should not reappear as an automatic foundation candidate. - **Anchors**: - `specs/247-plans-entitlements-billing-readiness/spec.md` - `specs/251-commercial-entitlements-billing-state/spec.md` ### Customer-Facing Localization Adoption v1 - **Priority**: 4 - **Repo truth**: the localization foundation is already spec-backed; the open gap is customer-facing adoption, glossary completion, and productized surface coverage. - **Why promotable now**: localization is now a productization follow-through task, not a greenfield foundation. - **Why manual promotion only**: the broad foundation is already covered, so only a narrower adoption slice should be promoted deliberately. - **Anchors**: - `specs/252-platform-localization-v1/spec.md` - `specs/258-customer-review-productization/spec.md` - `specs/260-governance-service-packaging/spec.md` ### Enterprise Access Boundary & Support Access Governance v1 - **Priority**: 5 - **Repo truth**: break-glass and platform access seams are documented, but no bounded support-access governance package currently exists. - **Why promotable now**: this is the narrow early access-governance slice that should happen before broad SSO/SCIM ambitions if support access and customer-visible auditability become pressing. - **Why manual promotion only**: the right cut is product-sensitive and must stay tightly bounded around support access, delegated access, TTL, approval, audit trail, and operator-context visibility. - **Anchors**: - `docs/audits/2026-03-09-enterprise-rbac-scope-audit.md` - `docs/HANDOVER.md` - `specs/065-tenant-rbac-v1/spec.md` - `specs/066-rbac-ui-enforcement-helper/spec.md` ### Stored Reports Surface v1 - **Priority**: 6 - **Repo truth**: the stored-reports substrate is already grounded by evidence and review foundations, but the product surface remains incomplete. - **Why promotable now**: this is the cleanest path from retained governance artifacts to a customer- and operator-usable surface. - **Why manual promotion only**: this is a focused product-surface follow-up, not an unprepared foundation gap. - **Anchors**: - `specs/153-evidence-domain-foundation/spec.md` - `specs/155-tenant-review-layer/spec.md` - `specs/260-governance-service-packaging/spec.md` - `docs/product/implementation-ledger.md` ### Workspace & Tenant Closure Lifecycle v1 - **Priority**: 7 - **Repo truth**: lifecycle taxonomy is already explicitly captured as a spec-backed foundation, but closure/runtime follow-through is still open. - **Why promotable now**: it is the next bounded runtime slice after the taxonomy-first package. - **Why manual promotion only**: it must remain a deliberate follow-up and not collapse back into an automatic reopening of the broader taxonomy work. - **Anchors**: - `specs/262-lifecycle-governance-taxonomy/spec.md` ### First Governed AI Runtime Consumer v1 - **Priority**: 8 - **Repo truth**: the private AI governance foundation is already spec-backed, but there is still no first real governed runtime consumer. - **Why promotable now**: it is the clearest bounded follow-up once higher-priority sellability, promotion, and commercial-truth gaps are addressed. - **Why manual promotion only**: the foundation already exists, so the next move must be an explicit runtime-use-case decision rather than a repeated foundation-prep cycle. - **Anchors**: - `specs/248-private-ai-policy-foundation/spec.md` ## Deferred / Existing Drafts Outside the Current Queue These items are still useful, but they are not the next best open specs from the current repo state. **2026-05-01 explicit promotion note**: `Workspace, Tenant & Managed Object Lifecycle Governance v1` was promoted intentionally, not automatically, into Spec 262 (`lifecycle-governance-taxonomy`). The history below is retained so the manual-promotion rationale and the auto-prep boundary remain visible. ### Workspace, Tenant & Managed Object Lifecycle Governance v1 - **Priority**: P2 — Important hardening / enterprise trust - **Status**: Promoted intentionally via explicit product decision -> Spec 262 (`lifecycle-governance-taxonomy`) - **Do not auto-prep from `next-best-prep`**: this candidate stays intentionally outside the active queue even after the 2026-05-01 repo re-audit. Promote it only through an explicit roadmap/product decision. - **Why the retained history still sits outside the active queue**: the repo now has spec-backed follow-through for customer review productization, governance convergence, compare/preflight, commercial lifecycle maturity, compliance mapping, governance packaging, support-desk handoff, and the findings cleanup trio. This lifecycle-governance work was promoted intentionally as a taxonomy-first package and must remain outside the automatic queue rather than being treated as an opportunistic next-best-prep target. - **Why this replaces `Policy Lifecycle / Ghost Policies`**: A policy-only ghost lifecycle spec risks introducing local deletion semantics, Laravel `SoftDeletes`, or overloaded `ignored_at` behavior before TenantPilot has a clear platform lifecycle taxonomy. The real roadmap-fit problem is broader: TenantPilot needs consistent lifecycle truth for workspaces, tenants, managed provider objects, evidence, backups, restoreability, export, retention, and purge. - **Problem**: Lifecycle concerns currently appear across separate product areas such as policies, restore flows, commercial state, workspace entitlements, backup history, evidence snapshots, audit, support, and workspace administration. Without one shared taxonomy, local fixes can collapse different meanings into the same field or UI label: provider object missing, local TenantPilot record deleted, operator ignored the item, workspace suspended, data retained for compliance, data eligible for purge, or restore no longer possible. - **Product goal**: Define an enterprise-grade lifecycle model before implementing destructive or retention-sensitive workflows. TenantPilot must distinguish at least these dimensions: - **Local record lifecycle**: active, archived, locally removed, purge scheduled, purged - **Provider presence lifecycle**: present, missing from provider, provider deleted, reappeared - **Operator suppression lifecycle**: visible, ignored / suppressed, restored to visibility - **Commercial / workspace lifecycle**: trial, active, grace, suspended read-only, closed - **Retention / compliance lifecycle**: retained, export requested, deletion requested, deletion scheduled, legal hold / retention hold, purge due, purged - **Restoreability lifecycle**: restorable, metadata only, blocked by dependency, not restorable, expired by retention - **Smallest useful v1**: Do not implement deletion flows immediately. First define the lifecycle taxonomy, naming rules, state boundaries, audit expectations, OperationRun expectations, retention boundaries, and implementation guardrails for future specs. - **Questions v1 must answer**: - What does “deleted” mean in TenantPilot? - What does “missing from provider” mean? - What does “ignored” mean? - What happens when a tenant is removed from a workspace? - What happens when a workspace is suspended or closed? - What data remains visible in read-only or suspended states? - What data must be exportable before deletion? - What data is retained for audit, evidence, or legal reasons? - What can be purged, and what must never be purged automatically? - Which lifecycle transitions require explicit human confirmation? - Which transitions require audit events? - Which transitions require OperationRun truth? - Which transitions affect restore eligibility? - **Explicit non-goals for v1**: - no immediate workspace deletion implementation - no immediate tenant deletion implementation - no purge engine - no hard-delete workflow - no policy-only ghost lifecycle patch - no Laravel `SoftDeletes` rollout - no migration that reinterprets existing `ignored_at` data - no new lifecycle dashboard or workboard - no new restore engine - no payment-provider or billing integration - **Expected follow-up specs after taxonomy approval**: 1. `Provider-Missing Managed Object Truth v1` — explicit provider-missing state for policies and later other managed objects, no local deletion semantics, restore continuity where backup-backed history exists. 2. `Workspace & Tenant Closure Lifecycle v1` — close workspace, remove tenant from workspace, define read-only / suspended / closed behavior, no destructive purge yet. 3. `Data Export Before Deletion v1` — export customer-owned evidence, reports, audit-relevant artifacts, restore metadata, and tenant/workspace records before deletion. 4. `Retention & Purge Governance v1` — retention periods, legal hold, purge eligibility, irreversible deletion confirmation, and audit trail. 5. `Restoreability Expiry & Evidence Retention v1` — distinguish restorable backup payloads from retained evidence/audit metadata and define when restore is no longer possible but evidence remains retained. - **Roadmap fit**: This is not a P0 sales feature. It is a P2 enterprise trust and compliance hardening candidate that becomes important before serious production customer offboarding, destructive data operations, or regulated retention commitments. It must not block Customer Review Workspace Productization, Governance Decision Surface Convergence, or Cross-Tenant Compare & Promotion. - **Candidate decision**: Explicitly promoted as Spec 262 (`lifecycle-governance-taxonomy`) through a manual product decision. Keep the promotion taxonomy-first and keep near-term policy fixes, closure flows, export-before-delete, retention/purge, and restoreability expiry as separate follow-up slices rather than treating Spec 262 as a runtime umbrella implementation. - `Workspace-level PII override for review packs`: bounded deferred follow-up from Spec 109. - `CSV export for filtered run metadata`: valid system-console follow-up, but not near the top of the queue. - `Raw error/context drilldowns for system console`: useful operator enhancement, but not ahead of current P0-P2 gaps. - UI polish snippets such as dashboard sparklines, density toggles, louder attention cards, or chooser refinements: keep out of the active spec queue until they become bounded release work. ## Promoted to Spec Historical ledger for candidates that are no longer open. Keep them here so prioritization stays clean without losing decision history. - Cross-Tenant Compare and Promotion v1 -> Spec 043 (`cross-tenant-compare-and-promotion`) - Canonical Operation Type Source of Truth -> Spec 239 (`canonical-operation-type-source-of-truth`) - Self-Service Tenant Onboarding & Connection Readiness -> Spec 240 (`tenant-onboarding-readiness`) - Support Diagnostic Pack -> Spec 241 (`support-diagnostic-pack`) - Operational Controls & Feature Flags -> Spec 242 (`operational-controls`) - Product Usage & Adoption Telemetry -> Spec 243 (`product-usage-adoption-telemetry`) - Product Knowledge & Contextual Help -> Spec 244 (`product-knowledge-contextual-help`) - Customer Health Score -> Spec 245 (`customer-health-score`) - In-App Support Request with Context -> Spec 246 (`support-request-context`) - Plans, Entitlements & Billing Readiness -> Spec 247 (`plans-entitlements-billing-readiness`) - Private AI Execution & Policy Foundation -> Spec 248 (`private-ai-policy-foundation`) - Customer Review Workspace v1 -> Spec 249 (`customer-review-workspace`) - Decision-Based Governance Inbox v1 -> Spec 250 (`decision-governance-inbox`) - Commercial Entitlements and Billing-State Maturity -> Spec 251 (`commercial-entitlements-billing-state`) - Remove Findings Lifecycle Backfill Runtime Surfaces -> Spec 253 (`remove-findings-backfill-runtime-surfaces`) - Remove Legacy Acknowledged Finding Status Compatibility -> Spec 254 (`remove-acknowledged-compat`) - Enforce Creation-Time Finding Invariants -> Spec 255 (`enforce-finding-creation-invariants`) - External Support Desk / PSA Handoff -> Spec 256 (`external-support-desk-handoff`) - Governance Decision Surface Convergence -> Spec 257 (`governance-decision-convergence`) - Customer Review Workspace Productization v1 -> Spec 258 (`customer-review-productization`) - Compliance Evidence Mapping v1 -> Spec 259 (`compliance-evidence-mapping`) - Governance-as-a-Service Packaging v1 -> Spec 260 (`governance-service-packaging`) - Provider-Missing Policy Visibility & Restore Continuity v1 -> Spec 261 (`provider-missing-policy-visibility`) - Workspace, Tenant & Managed Object Lifecycle Governance v1 -> Spec 262 (`lifecycle-governance-taxonomy`) - Auditor Pack Delivery & Executive Export v1 -> Spec 263 (`auditor-pack-executive-export`) - Cross-Tenant Promotion Execution v1 -> Spec 264 (`cross-tenant-promotion-execution`) - Queued Execution Reauthorization and Scope Continuity -> Spec 149 (`queued-execution-reauthorization`) - Livewire Context Locking and Trusted-State Reduction -> Spec 152 (`livewire-context-locking`) - Evidence Domain Foundation -> Spec 153 (`evidence-domain-foundation`) - Exception / Risk-Acceptance Workflow for Findings -> Spec 154 (`finding-risk-acceptance`) - Operator Outcome Taxonomy and Cross-Domain State Separation -> Spec 156 (`operator-outcome-taxonomy`) - Operator Reason Code Translation and Humanization Contract -> Spec 157 (`reason-code-translation`) - Governance Artifact Truthful Outcomes & Fidelity Semantics -> Spec 158 (`artifact-truth-semantics`) - Operator Explanation Layer for Degraded / Partial / Suppressed Results -> Spec 161 (`operator-explanation-layer`) - Request-Scoped Derived State and Resolver Memoization -> Spec 167 (`derived-state-memoization`) - Tenant Governance Aggregate Contract -> Spec 168 (`tenant-governance-aggregate-contract`) - Record Page Header Discipline & Contextual Navigation -> Spec 192 (`record-header-discipline`) - Monitoring Surface Action Hierarchy & Workbench Semantics -> Spec 193 (`monitoring-action-hierarchy`) - Governance Friction & Operator Vocabulary Hardening -> Spec 194 (`governance-friction-hardening`) - Governance Operator Outcome Compression -> Spec 214 (`governance-outcome-compression`) - Provider-Backed Action Preflight and Dispatch Gate Unification -> Spec 216 (`provider-dispatch-gate`) - Finding Ownership Semantics Clarification -> Spec 219 (`finding-ownership-semantics`) - Humanized Diagnostic Summaries for Governance Operations -> Spec 220 (`governance-run-summaries`) - Findings Operator Inbox v1 -> Spec 221 (`findings-operator-inbox`) - Findings Intake & Team Queue v1 -> Spec 222 (`findings-intake-team-queue`) - Findings Notifications & Escalation v1 -> Spec 224 (`findings-notifications-escalation`) - Assignment Hygiene & Stale Work Detection -> Spec 225 (`assignment-hygiene`) - Findings Notification Presentation Convergence -> Spec 230 (`findings-notification-convergence`) - Finding Outcome Taxonomy & Verification Semantics -> Spec 231 (`finding-outcome-taxonomy`) - Operation Run Link Contract Enforcement -> Spec 232 (`operation-run-link-contract`) - Operation Run Active-State Visibility & Stale Escalation -> Spec 233 (`stale-run-visibility`) - Provider Boundary Hardening -> Spec 237 (`provider-boundary-hardening`) ## Superseded / Removed From Active Queue These items were previously open candidates or roadmap-fit ideas, but should no longer stay in the active queue. - The former 2026-04-30 active P0-P2 queue was cleared on 2026-05-01 because refreshed Spec 043 and Specs 251-260 now cover those slices, and several of those packages already include implementation close-out or completed-task history. - `R2.0 Canonical Control Catalog Foundation`: remove from active candidates because the ledger shows a repo-real catalog, config, bindings, review integration, and test coverage. This is no longer an open candidate; it is an implemented foundation. - `Self-Service Tenant Onboarding & Connection Readiness`: remove from active candidates because it is already Spec 240 and the repo already shows meaningful adoption. - `Support Diagnostic Pack`: remove from active candidates because it is already Spec 241 and repo-adopted. - `Operational Controls & Feature Flags`: remove from active candidates because it is already Spec 242 and repo-adopted. - `Product Usage & Adoption Telemetry`: remove from active candidates because it is already Spec 243 and repo-adopted. - `Product Knowledge & Contextual Help`: remove from active candidates because it is already Spec 244; any remaining work should be narrower follow-ups, not a repeated top-level candidate. - `Customer Health Score`: remove from active candidates because it is already Spec 245 and repo-adopted. - `In-App Support Request with Context`: remove from active candidates because it is already Spec 246 and repo-implemented. - `Plans, Entitlements & Billing Readiness`: remove as a broad active candidate because Spec 247 already exists and the remaining open gap is narrower commercial lifecycle maturity. - `Private AI Execution & Policy Foundation`: remove from the active queue because Spec 248 already exists. - `Localization v1`: remove as a broad active candidate because the locale foundation is already repo-real; the remaining work is surface adoption, copy/glossary completion, and customer-facing polish inside narrower productization or UI-maturity follow-ups. - Company-ops items such as `Lead Capture & CRM Pipeline`, `AVV / DPA / TOM / Legal Pack`, `Vendor Questionnaire Answer Bank`, `Business Continuity / Founder Backup Plan`, and similar operating artifacts should remain outside the active product-spec queue unless a concrete product slice emerges.