ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects 1 Releases Wiki Activity
e1136ac6e9
TenantAtlas/docs/product/spec-candidates.md
ahmido e1136ac6e9
Some checks failed
Main Confidence / confidence (push) Failing after 54s
Details
Merge platform-dev into dev (automated) (#309) 
Automatischer Commit und PR erstellt auf Anfrage.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #309
2026-04-30 14:41:01 +00:00

36 KiB
Raw Blame History

Spec Candidates

Status: Active
Last reviewed: 2026-04-30
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

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.

Last reviewed: 2026-04-30 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.

Active Candidate Queue

P0 — Release Blockers

Customer Review Workspace Productization v1

  • Priority: P0
  • Candidate type: Productization / customer-safe consumption.
  • Why this stays active: The repo already has strong review foundations plus a repo-real CustomerReviewWorkspace page from Spec 249. What remains open is productization: the current surface still behaves more like an operator-led customer delivery view inside the admin plane than a fully customer-safe governance-of-record consumption experience.
  • Roadmap relationship: R2 completion / customer-facing review consumption and sellability polish.
  • Existing implementation context: Spec 249 (customer-review-workspace) delivered the first read-only workspace handoff. This candidate is the bounded follow-up that hardens the existing surface into a clearer customer-safe product contract instead of reopening review foundations from scratch.
  • Goal: Turn the existing customer review surface into a customer-safe, read-only review consumption experience for customer reviewers, customer admins, and auditors that answers what was reviewed, what is critical, what was accepted, what evidence exists, and what the next sensible step is.
  • Dependencies:
    • TenantReview
    • ReviewPack
    • EvidenceSnapshot
    • Finding
    • accepted risks / exceptions workflow
    • existing redaction behavior
    • stored reports and canonical control catalog foundations
    • workspace entitlements
    • tenant/workspace RBAC, audit, localization, and workspace-isolation foundations
  • Scope:
    • productize the existing customer review workspace into a clearer customer-safe read-only review consumption surface
    • keep the primary surface centered on customer review workspace, review detail, findings summary, accepted-risk summary, evidence summary, and review-pack download areas
    • visible findings semantics with severity, status, reason, impact, and recommendation in customer-safe language
    • accepted risks / exceptions shown as understandable governance decisions rather than internal workflow residue, including decision reason, accountable person or role, decision timing, expiry / re-review state, evidence linkage, and review context in customer-safe language
    • evidence snapshots shown as narrative summaries and proof pointers, not raw JSON or provider payloads
    • review-pack download area with existing redaction and entitlement rules
    • clearer control / baseline context and next-step guidance for customer reviewers, customer admins, and auditors
    • explicit audit events for workspace access, review detail access, evidence summary access, and pack downloads
    • explicit empty, permission, expired, and unavailable states
    • DE/EN-ready labels for customer-facing review text
    • progressive disclosure for technical detail instead of operator-default density
  • Non-scope:
    • a new customer portal, separate identity plane, or broader customer product shell
    • policy remediation, restore, or admin actions for customers
    • a new review engine, evidence engine, or report-generation engine
    • AI-generated summaries
    • public-link sharing without authentication or RBAC
    • raw operator diagnostics, provider-debug data, or raw evidence payloads as default-visible content
  • Decision workflow:
    • customer reviewers can read released reviews, evidence summaries, and review packs
    • customer acknowledgement can return later as a narrower v1.1 or v2 follow-up
    • no technical remediation or admin mutation lives in this workspace
  • Capability review:
    • validate or introduce customer-facing capability boundaries such as reviews.customer.view, reviews.customer.download_pack, evidence.customer.view, findings.customer.view, and risks.customer.view
    • existing operator capabilities must not automatically imply customer access
  • Export posture:
    • review packs remain the primary export and proof artifact
    • evidence stays narrative and customer-safe by default rather than raw-payload first
    • downloads must remain auditable
  • Acceptance criteria:
    • the customer-facing review workspace does not expose internal run, debug, provider, or raw JSON details by default
    • findings are shown with severity, status, reason, impact, and recommendation in customer-safe wording
    • accepted risks / exceptions are visible and understandable for non-operator consumers, including accountable role or person, decision timing, expiry or review status, and evidence linkage where product truth exists
    • evidence is summarized without exposing raw payloads by default
    • review packs are downloadable when entitlement and capability checks pass
    • each relevant view and download action produces audit evidence
    • tenant and workspace isolation are enforced and tested
    • permission gaps and expired or unavailable access states are explicit and calm
    • customer-facing labels are localization-ready
    • global search does not leak customer review or evidence artifacts into unintended discovery paths
  • Notes: This is still the clearest repo-derived P0 blocker between today's operator-strong review foundations and a cleaner customer-safe sellable release. Do not split a second broad liability / accountability foundation candidate out of this unless a narrower internal expiry-cockpit or portfolio-risk gap proves separate product value.

P1 — Enterprise Maturity

Governance Decision Surface Convergence

  • Priority: P1
  • Why this stays active: The repo already has Governance Inbox, My Findings, Intake, Exception Queue, alerts, and review-linked action entry points. The open gap is no longer the first governance inbox; it is convergence across these repo-real surfaces so operators stop hopping between adjacent work queues.
  • Roadmap relationship: Findings workflow maturity; later MSP Portfolio OS prerequisite.
  • Existing implementation context:
    • Spec 250 (decision-governance-inbox) delivered the first decision-oriented governance inbox surface.
    • Specs 221, 222, 224, 225, 230, and 231 already cover major inbox, intake, notification, and workflow-adoption slices.
    • CustomerReviewWorkspace and FindingExceptionsQueue now act as adjacent decision surfaces that should converge around one calmer operator journey instead of multiplying parallel entry points.
  • Dependencies:
    • findings workflow semantics and inbox foundations from Specs 219, 221, 222, 224, 225, 230, 231
    • alert routing foundation
    • OperationRun truth
    • portfolio triage continuity
    • customer review and exception governance surfaces where decision work overlaps
    • contextual help and reason-code surfaces where helpful
  • Scope:
    • one decision-centered operator entry model across more than one existing queue or signal family
    • reduce surface-hopping between My Findings, Intake, Governance Inbox, Exception Queue, and adjacent high-signal attention states
    • preserve direct action links into compare, finding review, review-pack generation, exception handling, or triage paths instead of duplicating domain state
    • add convergence rules, prioritization, and clearer routing before inventing more list surfaces
    • auditable state changes such as snooze, assign, or acknowledge only where those state mutations already exist as product truth
  • Non-scope:
    • rebuilding the first governance inbox from scratch
    • autonomous remediation
    • AI-generated recommendations
    • customer-facing inboxes
    • full cross-tenant workboard redesign
  • Acceptance criteria:
    • operators can start from one decision-centered surface or convergence model that spans more than one existing signal family or queue
    • existing surfaces keep one consistent routing model instead of growing more parallel queue concepts
    • actions route to existing product truth rather than creating duplicate state or duplicate work ownership
    • visibility is capability-aware and workspace-safe
    • auditable state changes are recorded where the inbox mutates work state
    • tests prove signal grouping, routing, and authorization boundaries
  • Notes: This is a follow-up to the existing Governance Inbox, not a greenfield inbox foundation.

Cross-Tenant Compare and Promotion v1

  • Priority: P1
  • Why this stays active: Portfolio triage exists, but portfolio action does not. The repo already contains an older draft spec for this direction, yet the capability is not repo-proven as a finished product workflow.
  • Roadmap relationship: MSP Portfolio & Operations.
  • Existing spec: Spec 043 exists and should be refreshed against current repo truth rather than replaced by a new broad direction.
  • Dependencies:
    • inventory foundations
    • baseline compare truth
    • restore and execution guardrails
    • audit log foundation
    • tenant and workspace isolation plus RBAC
  • Scope:
    • choose source and target tenants within allowed scope
    • show a structured compare preview
    • support a dry-run or promotion preflight before any write path
    • preserve auditability and scope boundaries
  • Non-scope:
    • blind one-click promotion
    • autonomous rollout
    • multi-cloud or multi-provider compare
    • full MSP control-plane redesign
  • Acceptance criteria:
    • operator can produce a compare preview between two allowed tenants
    • promotion path includes explicit preflight or dry-run semantics
    • authorization and tenant isolation are enforced and tested
    • audit trail exists for compare and promotion entry points
    • the slice refreshes or narrows Spec 043 instead of reopening it as a vague ambition

Remove Findings Lifecycle Backfill Runtime Surfaces

  • Priority: P1
  • Why this stays active: Repo audit shows visible runtime surfaces for a pre-production findings lifecycle repair path even though active finding generators already write the relevant lifecycle fields directly. The remaining path is not just ballast; it appears partially detached from current operational-control truth and keeps internal repair tooling productized.
  • Roadmap relationship: Findings workflow cleanup / legacy removal.
  • Dependencies:
    • current finding generators that already set lifecycle fields directly
    • system runbook registry and execution surfaces
    • tenant findings actions
    • operation catalog, capability, and seeder bindings
    • backfill jobs, runbook service, and deploy hooks
  • Scope:
    • remove the system runbook Rebuild Findings Lifecycle
    • remove the tenant action Backfill findings lifecycle
    • remove the command tenantpilot:findings:backfill-lifecycle
    • remove findings lifecycle backfill jobs, runbook services, and deploy/runtime hooks
    • remove operation-catalog, capability, seeder, and test traces that exist only for this backfill path
  • Non-scope:
    • removing the legacy acknowledged status or related compatibility helpers
    • changing normal finding workflow actions such as triage, assignment, progress, resolve, or risk acceptance
    • changing ownership, assignee, SLA, due-date, or risk-governance semantics
    • changing historical migrations or adding replacement backfills
  • Acceptance criteria:
    • no /admin surface exposes Backfill findings lifecycle
    • no system runbook exposes Rebuild Findings Lifecycle
    • tenantpilot:findings:backfill-lifecycle is no longer a supported command
    • deploy or operational hooks do not start a findings lifecycle backfill
    • findings.lifecycle.backfill is no longer used as an operational-control key, operation type, or capability
    • tests no longer expect backfill preflight, start, or completion behavior
    • normal finding workflows keep working unchanged for triage, assignment, start progress, resolve, and risk acceptance
  • Notes: This is the first and most important cleanup candidate because it removes visible product ballast without changing the canonical findings workflow semantics.

Remove Legacy Acknowledged Finding Status Compatibility

  • Priority: P1
  • Why this stays active: Repo audit indicates that acknowledged compatibility still survives in status helpers, filters, badges, capabilities, and tests even though the current operator workflow is centered on triaged. Keeping both semantics alive weakens workflow clarity and RBAC consistency.
  • Roadmap relationship: Findings workflow semantics / RBAC cleanup.
  • Dependencies:
    • finding status constants and model helpers
    • badge and filter catalogs
    • role capability mappings and capability aliases
    • workflow and bulk-action tests that still speak in acknowledge semantics
  • Scope:
    • remove Finding::STATUS_ACKNOWLEDGED
    • remove or simplify compatibility helpers that only map acknowledged to triaged
    • remove openStatusesForQuery() compatibility for acknowledged
    • remove legacy capability aliases such as tenant_findings.acknowledge
    • rename, adapt, or remove tests that only protect the old acknowledge vocabulary
    • ensure active workflow actions consistently use triage / triaged
  • Non-scope:
    • removing findings lifecycle backfill runtime surfaces in the same slice
    • changing SLA, ownership, assignee, or risk-acceptance behavior
    • introducing new workflow states or new customer-facing workflow surfaces
    • changing finding generators unless they still emit acknowledged
  • Acceptance criteria:
    • no productive code path writes acknowledged
    • no productive code path expects acknowledged as a valid workflow status
    • tenant_findings.acknowledge no longer exists as a capability or alias
    • workflow actions, filters, badges, and tests consistently use triage / triaged
    • existing finding flows remain functional from new to triaged, in_progress, resolved, and risk-accepted outcomes
  • Notes: Keep this separate from backfill removal because it reaches deeper into workflow semantics, queries, badges, and RBAC mappings.

Enforce Creation-Time Finding Invariants

  • Priority: P1
  • Why this stays active: Removing lifecycle backfills only stays safe if new findings are always created in a lifecycle-ready state. The repo already hints at good direct-write behavior, but those invariants still need explicit protection so future generators do not recreate the need for repair jobs.
  • Roadmap relationship: Findings data integrity / workflow hardening.
  • Dependencies:
    • drift and baseline compare finding generation
    • permission posture finding generation
    • Entra admin roles finding generation
    • rediscovery, reopen, and deduplication behavior around recurrence keys and lifecycle timestamps
  • Scope:
    • review active finding generators and verify lifecycle-ready creation
    • add or tighten invariant tests around canonical status, first/last seen timestamps, times_seen, sla_days, and due_at where applicable
    • verify reopen and rediscovery behavior
    • verify drift idempotency and recurrence-key semantics
    • consider a tightly bounded DB constraint only if the repo proves a safe, narrow case
  • Non-scope:
    • reintroducing any backfill or repair runtime surface
    • historical data migration work
    • forcing owner or assignee fields to become mandatory
    • introducing new finding types or broader customer review workflow changes
  • Acceptance criteria:
    • repo-verified finding generators have tests that prove lifecycle-ready creation
    • no new finding generation path relies on a later backfill or repair run
    • repeated drift detection does not create uncontrolled canonical duplicates
    • reopen or rediscovery behavior updates lifecycle fields correctly
    • accountability remains a governance state rather than a forced owner/assignee requirement
  • Notes: This should follow the visible cleanup work and protects the target state so findings do not regress back into repair-job dependency.

P2 — Commercial / Scale

Commercial Entitlements and Billing-State Maturity

  • Priority: P2
  • Why this stays active: The repo already has a real entitlement foundation and an existing spec for plans and billing readiness. The remaining gap is narrower: commercial lifecycle maturity, not inventing entitlements from scratch.
  • Roadmap relationship: Product Scalability & Self-Service Foundation.
  • Existing spec context: Spec 247 exists for Plans, Entitlements & Billing Readiness. This candidate is the follow-up gap after the current entitlement substrate, not a duplicate foundation spec.
  • Dependencies:
    • existing WorkspaceEntitlementResolver
    • workspace settings surfaces
    • review-pack entitlement gates
    • audit foundation
    • customer-facing read-only and suspension semantics where applicable
  • Scope:
    • commercial lifecycle states such as trial, grace, suspended/read-only, and active paid usage
    • clearer enforcement at key product gates
    • explicit disabled and read-only messaging distinct from authorization failures
    • audited state changes and overrides
  • Non-scope:
    • payment provider integration
    • invoicing
    • tax or accounting workflows
    • public pricing pages
  • Acceptance criteria:
    • central commercial state can be resolved for a workspace
    • at least two real behaviors are gated by lifecycle state, not scattered conditionals
    • read-only or suspended behavior preserves safe access to needed history or evidence while blocking disallowed actions
    • changes and overrides are audited
    • tests cover blocked and allowed paths

Compliance Evidence Mapping v1

  • Priority: P2
  • Why this stays active: Canonical control catalog, evidence snapshots, stored reports, review packs, findings, and accepted-risk foundations are already repo-real. The missing gap is a versioned mapping layer from technical governance truth to customer-safe control or readiness views, not another control foundation rewrite.
  • Roadmap relationship: Compliance moat / executive review follow-through.
  • Dependencies:
    • canonical control catalog foundation
    • evidence snapshots and stored reports
    • findings and accepted-risk workflow
    • tenant reviews and review-pack export
    • customer review productization and export maturity
  • Scope:
    • one versioned control interpretation layer and one bounded overlay for a first customer-safe readiness/control view
    • map findings, evidence, and accepted risks to customer-safe control views without certification claims
    • show control, evidence, and recommendation linkage in one primary review or export surface before broad multi-surface rollout
    • keep framework overlays downstream from the shared canonical control model
  • Non-scope:
    • certification claims or legal guarantees
    • hard-coded BSI, NIS2, CIS, or ISO semantics deep in the platform core
    • separate technical control object models per framework
    • full GRC suite or lawyer-facing workflow
  • Acceptance criteria:
    • one bounded overlay maps existing technical truth to a control or readiness view
    • one concrete review or export surface can show control status, evidence linkage, and recommended action from shared foundations
    • mapping versions are explicit and auditable
    • the product clearly separates technical findings from regulatory interpretation
    • no framework-specific one-off output bypasses the common evidence, findings, exception, and export pipeline
  • Smallest useful v1: start with one overlay family and one customer-safe output path. Do not start by modeling multiple frameworks, multiple customer profiles, and multiple output surfaces at once.

Governance-as-a-Service Packaging v1

  • Priority: P2
  • Why this stays active: Review packs, evidence snapshots, stored reports, customer review foundations, and accepted-risk workflow are repo-real. The missing gap is repeatable MSP/customer-safe packaging, not raw reporting substrate.
  • Roadmap relationship: MSP sellability / recurring governance service.
  • Dependencies:
    • customer review workspace productization
    • compliance evidence mapping
    • review packs, evidence snapshots, and stored reports
    • findings and accepted-risk workflow
    • localization, entitlements, and export maturity
  • Scope:
    • one on-demand management-ready governance package built from the existing review-pack and evidence pipeline
    • executive summary with customer-safe language
    • top findings, accepted risks, open decisions, and evidence links
    • bounded MSP branding and packaging rules
    • no scheduling, batching, or report-program engine in the first slice
  • Non-scope:
    • CRM, newsletter, or marketing automation
    • PSA replacement or service-desk workflow
    • raw operator-data dumps as the default deliverable
    • a separate reporting engine that bypasses existing review/evidence/export truth
  • Acceptance criteria:
    • an MSP can generate one repeatable on-demand governance package from existing review, evidence, and accepted-risk artifacts
    • the output is customer-safe and management-readable by default
    • top findings, accepted risks, open decisions, and evidence links are clearly represented
    • packaging reuses shared review/evidence/export foundations instead of creating a parallel report domain
    • bounded branding or presentation options do not weaken auditability or customer-safe defaults
  • Smallest useful v1: one management-ready package for one review context, generated on demand from existing artifacts. Leave recurring schedules, multi-pack campaigns, and broader customer-communications automation out of scope.

External Support Desk / PSA Handoff

  • Priority: P2
  • Why this stays active: In-app support requests are already repo-real. The remaining gap is external handoff and visible ticket linkage, not support-request creation itself.
  • Roadmap relationship: R2 support follow-through; later commercial scale.
  • Dependencies:
    • support request context flow from Spec 246
    • support diagnostic pack
    • audit logging
    • tenant and workspace authorization boundaries
  • Scope:
    • outbound adapter seam for one support desk or PSA target
    • store and display external ticket reference
    • auditable create or link actions
    • visible product linkage back from support requests to external references
  • Non-scope:
    • full bidirectional sync
    • SLA engine
    • generic helpdesk product
    • AI support automation
  • Acceptance criteria:
    • a support request can create or link an external ticket through one bounded adapter
    • resulting ticket reference is stored and visible in the right context
    • failures are explicit and auditable
    • tenant and workspace scope are enforced and tested
    • the slice extends the existing support-request model instead of replacing it

P3 — Later Platform Ambitions

  • No active P3 candidate from the current focus set.
  • Private AI Execution & Policy Foundation is already promoted as Spec 248 and should no longer remain in the open candidate queue.
  • Broader AI-assisted customer operations can return later as a follow-up only after Spec 248 and the current customer-facing release gaps are materially closed.

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.

Workspace, Tenant & Managed Object Lifecycle Governance v1

  • Priority: P2 — Important hardening / enterprise trust

  • Status: Strategic candidate, not ready for immediate implementation

  • Do not prep before: Customer Review Workspace, Cross-Tenant Compare & Promotion, Governance Decision Convergence, and current sellability/productization follow-through are materially closed.

  • 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: Keep as strategic candidate. Do not implement a narrow Ghost Policy spec until the lifecycle taxonomy is agreed. If provider-missing policy behavior becomes an immediate product bug, create a smaller follow-up spec named Provider-Missing Policy Visibility & Restore Continuity v1; that smaller spec must use provider_deleted_at, missing_from_provider_at, or an equivalent provider-presence field and must not use Laravel SoftDeletes or local deletion semantics.

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

  • 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)
  • 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.

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