TenantAtlas/docs/product/spec-candidates.md

Spec Candidates

Concrete future specs waiting for prioritization. Each entry has enough structure to become a real spec when the time comes.

Flow: Inbox → Qualified → Planned → Spec created → removed from this file

Last reviewed: 2026-03-10

---

Inbox

Ungefiltert. Kurze Notiz reicht. Wöchentlich sichten.

• Dashboard trend visualizations (sparklines, compliance gauge, drift-over-time chart)
• Dashboard "Needs Attention" should be visually louder (alert color, icon, severity weighting)
• Operations table should show duration + affected policy count
• Density control / comfortable view toggle for admin tables
• Inventory landing page may be redundant — consider pure navigation section
• Settings change history → explainable change tracking
• Workspace chooser v2: search, sort, favorites, pins, environment badges, last activity

---

Qualified

Problem + Nutzen klar. Scope noch offen. Braucht noch Priorisierung.

Exception / Risk-Acceptance Workflow for Findings

• Type: feature
• Source: HANDOVER gap analysis, Spec 111 follow-up
• Problem: Finding has risk_accepted status but no formal exception entity. No workflow to accept risk, track justification, or expire acceptance.
• Why it matters: Enterprise compliance requires documented risk acceptance. Auditors ask "who accepted this and when?"
• Proposed direction: Exception entity linked to Finding, approval flow, expiry tracking, audit trail
• Dependencies: Findings workflow (Spec 111) complete
• Priority: high

Evidence Pack Entity

• Type: feature
• Source: HANDOVER gap, R2 theme completion
• Problem: Review pack export (Spec 109) exists, permission posture (104/105) exists, but no formal "evidence pack" that bundles these for external audit/compliance submission.
• Why it matters: Enterprise customers need a single deliverable for auditors — not separate exports.
• Proposed direction: Evidence pack = curated bundle of review pack + posture report + findings summary + baseline governance state
• Dependencies: Review pack export (109), permission posture (104)
• Priority: high

Policy Lifecycle / Ghost Policies (Spec 900 refresh)

• Type: feature
• Source: Spec 900 draft (2025-12-22), HANDOVER risk #9
• Problem: Policies deleted in Intune remain in TenantAtlas indefinitely. No deletion indicators. Backup items reference "ghost" policies.
• Why it matters: Data integrity, user confusion, backup reliability
• Proposed direction: Soft delete detection during sync, auto-restore on reappear, "Deleted" badge, restore from backup. Draft in Spec 900.
• Dependencies: Inventory sync stable
• Priority: medium

Schema-driven Secret Classification

• Type: hardening
• Source: Spec 120 deferred follow-up
• Problem: Secret redaction currently uses pattern-based detection. A schema-driven approach via GraphContractRegistry metadata would be more reliable.
• Why it matters: Reduces false negatives in secret redaction
• Proposed direction: Central classifier in GraphContractRegistry, regression corpus
• Dependencies: Secret redaction (120) stable, registry completeness (095)
• Priority: medium

Cross-Tenant Compare & Promotion

• Type: feature
• Source: Spec 043 draft, 0800-future-features
• Problem: No way to compare policies between tenants or promote configurations from staging to production.
• Why it matters: Core MSP/enterprise workflow. Identified as top revenue lever in brainstorming.
• Proposed direction: Compare/diff UI, group/scope-tag mapping, promotion plan (preview → dry-run → cutover → verify)
• Dependencies: Inventory sync, backup/restore mature
• Priority: medium (high value, high effort)

System Console Multi-Workspace Operator

• Type: feature
• Source: Spec 113 deferred
• Problem: System console (/system) currently can't select/filter across workspaces for platform operators.
• Why it matters: Platform ops need cross-workspace visibility for troubleshooting and monitoring.
• Proposed direction: New UX + entitlement model for system-level operators
• Dependencies: System console (114) stable
• Priority: low

Workspace Chooser v2

• Type: polish
• Source: Spec 107 deferred backlog
• Problem: Current chooser is functional but basic. Missing search, sort, favorites, environment badges, last activity display.
• Why it matters: MSPs with 10+ workspaces need fast navigation.
• Proposed direction: Search + sort + pins, environment badge (Prod/Test/Staging), last activity per workspace, dropdown switcher in header
• Dependencies: Workspace chooser v1 (107) stable
• Priority: low

Dashboard Polish (Enterprise-grade)

• Type: polish
• Source: Product review 2026-03-08
• Problem: Current dashboard shows raw numbers without context. No trend indicators, no severity weighting, governance card too small.
• Why it matters: First impression for evaluators. Enterprise admins compare with Datadog/Vanta/Drata/Intune Portal.
• Proposed direction: Trend sparklines, compliance gauge, severity-weighted drift table, actionable alert buttons, progressive disclosure
• Dependencies: Baseline governance (101), alerts (099), drift engine (119) stable
• Priority: medium

Operations Naming Harmonization Across Run Types, Catalog, UI, and Audit

• Type: hardening
• Source: coding discovery, operations UX consistency review
• Why it matters: Strategically important for enterprise UX, auditability, and long-term platform consistency. OperationRun is becoming a cross-domain execution and monitoring backbone, and the current naming drift will get more expensive as new run types and provider domains are added. This should reduce future naming drift, but it is not a blocker-critical refactor and should not be pulled in as a side quest during small UI changes.
• Problem: Naming around operations appears historically grown and not consistent enough across OperationRunType values, visible run labels, OperationCatalog mappings, notifications, audit events, filters, badges, and related UI copy. Internal type names and operator-facing language are not cleanly separated, domain/object/verb ordering is uneven, and small UX fixes risk reinforcing an already inconsistent scheme. If left as-is, new run types for baseline, review, alerts, and additional provider domains will extend the inconsistency instead of converging it.
• Desired outcome: A later spec should define a clear naming standard for OperationRunType, establish an explicit distinction between internal type identifiers and operator-facing labels, and align terminology across runs, notifications, audit text, monitoring views, and operations UI. New run types should have documented naming rules so they can be added without re-opening the vocabulary debate.
• In scope: Inventory of current operation-related naming surfaces; naming taxonomy for internal identifiers versus visible operator language; conventions for verb/object/domain ordering; alignment rules for OperationCatalog, run labels, notifications, audit events, filters, badges, and monitoring UI; forward-looking rules for adding new run types and provider/domain families; a pragmatic migration plan that minimizes churn and preserves audit clarity.
• Out of scope: Opportunistic mass-refactors during unrelated feature work; immediate renaming of all historical values without a compatibility plan; using a small UI wording issue such as "Sync from Intune" versus "Sync policies" as justification for broad churn; a full operations-domain rearchitecture unless later analysis proves it necessary.
• Trigger / Best time to do this: Best tackled when multiple new run types are about to land, when OperationCatalog / monitoring / operations hub work is already active, when new domains such as Entra or Teams are being integrated, or when a broader UI naming constitution is ready to be enforced technically. This is a good candidate for a planned cleanup window, not an ad hoc refactor.
• Risks if ignored: Continued terminology drift across UI and audit layers, higher cognitive load for operators, weaker enterprise polish, more brittle label mapping, and more expensive cleanup once additional domains and execution types are established. Audit/event language may diverge further from monitoring language, making cross-surface reasoning harder.
• Suggested direction: Define stable internal run-type identifiers separately from visible operator labels. Standardize a single naming grammar for operation concepts, including when to lead with verb, object, or domain, and when provider-specific wording is allowed. Apply changes incrementally with compatibility-minded mapping rather than a brachial rename of every historical string. Prefer a staged migration that first defines rules and mapping layers, then updates high-value operator surfaces, and only later addresses legacy internals where justified.
• Readiness level: Qualified and strategically important, but intentionally deferred. This should be specified before substantially more run types and provider domains are introduced, yet it should not become an immediate side-track or be bundled into minor UI wording fixes.
• Candidate quality:
  • Clearly identified cross-cutting problem with architectural and UX impact
  • Strong future-facing trigger conditions instead of vague "sometime later"
  • Explicit boundaries to prevent opportunistic churn
  • Concrete desired outcome without overdesigning the solution
  • Easy to promote into a full spec once operations-domain work is prioritized

Support Intake with Context (MVP)

• Type: feature
• Source: Product design, operator feedback
• Problem: Nutzer haben keinen strukturierten Weg, Probleme direkt aus dem Produkt zu melden. Bei technischen Fehlern fehlen Run-/Tenant-/Provider-Details; bei Access-/UX-Problemen fehlen Route-/RBAC-Kontext. Folge: ineffiziente Support-Schleifen und Rückfragen. Ein vollwertiges Ticketsystem ist falsch priorisiert.
• Why it matters: Reduziert Support-Reibung, erhöht Erfassungsqualität, steigert wahrgenommene Produktreife. Schafft typed intake layer für spätere Webhook-/PSA-/Ticketing-Erweiterungen, ohne jetzt ein Helpdesk einzuführen.
• Proposed direction: Neues SupportRequest-Modell (kein Ticket/Case) mit source_type (operation_run, provider_connection, access_denied, generic) und issue_kind (technical_problem, access_problem, ux_feedback, other). Drei Entry Paths: (1) Context-bound aus failed OperationRun, (2) Access-Denied/403-Kontext, (3) generischer Feedback-Einstieg (User-Menü). Automatischer Context-Snapshot per SupportRequestContextBuilder je source_type. Persistierung vor Delivery. E-Mail-Delivery an konfigurierte Support-Adresse. Fingerprint-basierter Spam-Guard. Audit-Events. RBAC via support.request.create Capability. Scope-Isolation. Secret-Redaction in context_jsonb.
• Dependencies: OperationRun-Domain stabil, RBAC/Capability-System (066+), Workspace-/Tenant-Scoping
• Priority: medium

---

Planned

Ready for spec creation. Waiting for slot in active work.

(empty — move items here when prioritized for next sprint)

---

Template

### Title
- **Type**: feature | polish | hardening | bug | research
- **Source**: chat | audit | coding discovery | customer feedback | spec N follow-up
- **Problem**:
- **Why it matters**:
- **Proposed direction**:
- **Dependencies**:
- **Priority**: low | medium | high