ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
f746373113
TenantAtlas/docs/product/spec-candidates.md
Ahmed Darrazi f746373113 feat: add operations auto-refresh pass
2026-03-08 11:34:09 +01:00

7.2 KiB
Raw Blame History

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-08

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
  • Monitoring hub calmer polling / less UI noise
  • 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

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