133 lines
7.1 KiB
Markdown
133 lines
7.1 KiB
Markdown
# 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
|
|
- 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
|
|
|
|
```md
|
|
### 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
|
|
```
|