From e1136ac6e9026219523e217ed5f8d53fd3fead82 Mon Sep 17 00:00:00 2001 From: ahmido Date: Thu, 30 Apr 2026 14:41:01 +0000 Subject: [PATCH] Merge platform-dev into dev (automated) (#309) Automatischer Commit und PR erstellt auf Anfrage. Co-authored-by: Ahmed Darrazi Reviewed-on: https://git.cloudarix.de/ahmido/TenantAtlas/pulls/309 --- .specify/research_t186.md | 5 + docs/HANDOVER.md | 5 + docs/PERMISSIONS.md | 198 +++++--------- docs/PROJECT_SUMMARY.md | 5 + docs/README.md | 60 +++++ .../2026-03-15-audit-spec-candidates.md | 5 + docs/audits/README.md | 10 + ...nterprise-architecture-audit-2026-03-09.md | 5 + docs/audits/legacy-orphaned-truth-audit.md | 5 + .../semantic-clarity-spec-candidates.md | 5 + ...ntpilot-architecture-audit-constitution.md | 5 + docs/product/discoveries.md | 44 +--- docs/product/implementation-ledger.md | 43 +-- docs/product/operator-semantic-taxonomy.md | 5 + docs/product/principles.md | 5 + docs/product/prompts/README.md | 11 + docs/product/roadmap.md | 98 +++++-- docs/product/spec-candidates.md | 248 ++++++++++++++---- .../admin-canonical-tenant-rollout.md | 5 + .../canonical-tenant-context-resolution.md | 5 + docs/research/filament-v5-notes.md | 5 + ...den-master-baseline-drift-deep-analysis.md | 5 + .../m365-policy-coverage-gap-analysis.md | 5 + docs/security/REDACTION_AUDIT_REPORT.md | 5 + docs/strategy/domain-coverage.md | 5 + docs/strategy/product-vision.md | 27 ++ docs/strategy/website-working-contract.md | 5 + docs/ui/action-surface-contract.md | 5 + docs/ui/filament-table-standard.md | 5 + docs/ui/operator-ux-surface-standards.md | 5 + .../ui/shared-diff-presentation-foundation.md | 5 + spechistory/spec.md | 5 + .../IMPLEMENTATION_STATUS.md | 5 + .../MANUAL_TESTING_CHECKLIST.md | 5 + specs/feat/700-bugfix/plan.md | 26 -- specs/feat/700-bugfix/spec.md | 29 -- specs/feat/700-bugfix/tasks.md | 20 -- 37 files changed, 605 insertions(+), 334 deletions(-) create mode 100644 docs/README.md create mode 100644 docs/audits/README.md create mode 100644 docs/product/prompts/README.md delete mode 100644 specs/feat/700-bugfix/plan.md delete mode 100644 specs/feat/700-bugfix/spec.md delete mode 100644 specs/feat/700-bugfix/tasks.md diff --git a/.specify/research_t186.md b/.specify/research_t186.md index 23773aa9..f1b5d9ea 100644 --- a/.specify/research_t186.md +++ b/.specify/research_t186.md @@ -1,5 +1,10 @@ # Research T186 — settings_apply capability verification (LEGACY / DEPRECATED) +> **Status:** Superseded +> **Last reviewed:** 2026-04-30 +> **Use for:** Historical investigation context only if a later Settings Catalog write-path regression needs provenance +> **Do not use for:** Active feature research or current implementation truth + > DEPRECATED: Do not add new research notes under `.specify/`. > Active feature research should live under `specs/-/`. > Legacy history lives under `spechistory/`. diff --git a/docs/HANDOVER.md b/docs/HANDOVER.md index 06362df3..7352a629 100644 --- a/docs/HANDOVER.md +++ b/docs/HANDOVER.md @@ -1,5 +1,10 @@ # TenantPilot / TenantAtlas — Handover Document +> **Status:** Needs Review +> **Last reviewed:** 2026-04-30 +> **Use for:** Handover context, repo snapshot orientation, and migration-era operational notes +> **Do not use for:** Current implementation truth or current branch state without repo verification + > **Generated**: 2026-03-06 · **Branch**: `dev` · **HEAD**: `da1adbd` > **Stack**: Laravel 12 · Filament v5 · Livewire v4 · PostgreSQL 16 · Tailwind v4 · Pest 4 diff --git a/docs/PERMISSIONS.md b/docs/PERMISSIONS.md index 6eabcb8b..9a904612 100644 --- a/docs/PERMISSIONS.md +++ b/docs/PERMISSIONS.md @@ -1,154 +1,90 @@ # Microsoft Graph API Permissions -This document lists all required Microsoft Graph API permissions for TenantPilot to function correctly. +> **Status:** Reference +> **Last reviewed:** 2026-04-30 +> **Use for:** Current repo-based Microsoft Graph permission reference for implemented platform features +> **Do not use for:** Future roadmap permissions or final tenant-specific grant truth without checking the repo and the live tenant posture -## Required Permissions +This document summarizes the permission registry currently defined in: -The Azure AD / Entra ID **App Registration** used by TenantPilot requires the following **Application Permissions** (not Delegated): +- `apps/platform/config/intune_permissions.php` +- `apps/platform/config/entra_permissions.php` -### Core Policy Management (Required) -- `DeviceManagementConfiguration.Read.All` - Read Intune device configuration policies -- `DeviceManagementConfiguration.ReadWrite.All` - Write/restore Intune policies -- `DeviceManagementApps.Read.All` - Read app configuration policies -- `DeviceManagementApps.ReadWrite.All` - Write app policies +These config files are the repo source of truth for currently implemented permission requirements. -### Scope Tags (Feature 004 - Required for Phase 3) -- **`DeviceManagementRBAC.Read.All`** - Read scope tags and RBAC settings - - **Purpose**: Resolve scope tag IDs to display names (e.g., "0" → "Default") - - **Missing**: Backup items will show "Unknown (ID: 0)" instead of scope tag names - - **Impact**: Metadata display only - backups still work without this permission +## Scope Rules -### Group Resolution (Feature 004 - Required for Phase 2) -- `Group.Read.All` - Resolve group IDs to names for assignments -- `Directory.Read.All` - Batch resolve directory objects (groups, users, devices) +- The list below describes the current repo-required Microsoft Graph permissions for implemented features. +- This document does not promote roadmap or research-only permissions to required status. +- `granted_stub` values in `intune_permissions.php` are display aids for the UI, not the canonical required-permission list. +- Unless stated otherwise, these are application permissions. -## How to Add Permissions +## Current Required Permissions -### Azure Portal (Entra ID) +### Intune Configuration, Backup, Restore, and Drift -1. Go to **Azure Portal** → **Entra ID** (Azure Active Directory) -2. Navigate to **App registrations** → Select your TenantPilot app -3. Click **API permissions** in the left menu -4. Click **+ Add a permission** -5. Select **Microsoft Graph** → **Application permissions** -6. Search for and select the required permissions: - - `DeviceManagementRBAC.Read.All` - - (Add others as needed) -7. Click **Add permissions** -8. **IMPORTANT**: Click **Grant admin consent for [Your Organization]** - - ⚠️ Without admin consent, the permissions won't be active! +| Permission | Why the repo requires it | +|---|---| +| `DeviceManagementConfiguration.Read.All` | Read Intune device configuration policies for inventory, backup, settings normalization, and drift flows | +| `DeviceManagementConfiguration.ReadWrite.All` | Execute restore and other write flows for Intune device configuration policies | +| `DeviceManagementApps.Read.All` | Read Intune app configuration and assignments for sync and backup | +| `DeviceManagementApps.ReadWrite.All` | Restore and manage Intune app configuration and assignments | +| `DeviceManagementServiceConfig.Read.All` | Read enrollment restrictions, Autopilot, ESP, and related service configuration | +| `DeviceManagementServiceConfig.ReadWrite.All` | Restore and manage enrollment restrictions, Autopilot, ESP, and related service configuration | +| `DeviceManagementScripts.Read.All` | Read device management scripts and remediations for sync and backup | +| `DeviceManagementScripts.ReadWrite.All` | Restore and manage device management scripts and remediations | -### PowerShell (Alternative) +### Conditional Access And Policy Coverage -```powershell -# Connect to Microsoft Graph -Connect-MgGraph -Scopes "Application.ReadWrite.All" +| Permission | Why the repo requires it | +|---|---| +| `Policy.Read.All` | Read Conditional Access and related identity policy surfaces used for backup, preview, and versioning | +| `Policy.ReadWrite.ConditionalAccess` | Manage Conditional Access policies for controlled restore or admin-managed write paths | -# Get your app registration -$appId = "YOUR-APP-CLIENT-ID" -$app = Get-MgApplication -Filter "appId eq '$appId'" +### Directory, Groups, And Intune RBAC Foundations -# Add DeviceManagementRBAC.Read.All permission -$graphServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'" -$rbacPermission = $graphServicePrincipal.AppRoles | Where-Object {$_.Value -eq "DeviceManagementRBAC.Read.All"} +| Permission | Why the repo requires it | +|---|---| +| `Directory.Read.All` | Directory lookups and tenant-health-oriented checks | +| `Group.Read.All` | Assignment name resolution, group mapping, group directory cache, backup metadata enrichment, and drift context | +| `DeviceManagementRBAC.Read.All` | Read Intune RBAC settings and scope tags for metadata enrichment and assignment-aware flows | +| `DeviceManagementRBAC.ReadWrite.All` | Manage scope tags for foundation backup and restore workflows | -$requiredResourceAccess = @{ - ResourceAppId = "00000003-0000-0000-c000-000000000000" - ResourceAccess = @( - @{ - Id = $rbacPermission.Id - Type = "Role" - } - ) -} +### Entra Admin Roles Evidence -Update-MgApplication -ApplicationId $app.Id -RequiredResourceAccess $requiredResourceAccess +| Permission | Why the repo requires it | +|---|---| +| `RoleManagement.Read.Directory` | Read directory role definitions and assignments for Entra admin roles evidence and findings | -# Grant admin consent -# (Must be done manually or via Graph API with RoleManagement.ReadWrite.Directory scope) +## Not Currently Required By Implemented Features + +These permissions may appear in research, roadmap ideas, or tenant-specific grants, but they are not part of the current required-permission registry: + +- `SharePointTenantSettings.Read.All` is a roadmap or research permission until SharePoint tenant settings are actually implemented. +- Exchange Online or Defender for Office 365 PowerShell permissions are not current repo requirements because those integrations are not implemented as production features. +- `DeviceManagementManagedDevices.ReadWrite.All` may appear in fixtures or grant stubs, but it is not listed in the current required-permission registry. + +## Grant And Verify + +1. In Entra ID, open the TenantPilot app registration. +2. Add the required Microsoft Graph application permissions from the tables above. +3. Grant admin consent for the tenant. +4. In the application, use the required-permissions or permission-posture surfaces to compare granted versus required permissions. +5. If the platform still shows stale permission state, clear caches with: + +```bash +cd apps/platform && ./vendor/bin/sail artisan cache:clear ``` -## Verification +## Least-Privilege Notes -After adding permissions and granting admin consent: - -1. Go to **App registrations** → Your app → **API permissions** -2. Verify status shows **Granted for [Your Organization]** with a green checkmark ✅ -3. Clear cache in TenantPilot: - ```bash - php artisan cache:clear - ``` -4. Test scope tag resolution: - ```bash - php artisan tinker - >>> use App\Services\Graph\ScopeTagResolver; - >>> use App\Models\Tenant; - >>> $tenant = Tenant::first(); - >>> $resolver = app(ScopeTagResolver::class); - >>> $tags = $resolver->resolve(['0'], $tenant); - >>> dd($tags); - ``` - Expected output: - ```php - [ - [ - "id" => "0", - "displayName" => "Default" - ] - ] - ``` - -## Troubleshooting - -### Error: "Application is not authorized to perform this operation" - -**Symptoms:** -- Backup items show "Unknown (ID: 0)" for scope tags -- Logs contain: `Application must have one of the following scopes: DeviceManagementRBAC.Read.All` - -**Solution:** -1. Add `DeviceManagementRBAC.Read.All` permission (see above) -2. **Grant admin consent** (critical step!) -3. Wait 5-10 minutes for Azure to propagate permissions -4. Clear cache: `php artisan cache:clear` -5. Test again - -### Error: "Insufficient privileges to complete the operation" - -**Cause:** The user account used to grant admin consent doesn't have sufficient permissions. - -**Solution:** -- Use an account with **Global Administrator** or **Privileged Role Administrator** role -- Or have the IT admin grant consent for the organization - -### Permissions showing but still getting 403 - -**Possible causes:** -1. Admin consent not granted (click the button!) -2. Permissions not yet propagated (wait 5-10 minutes) -3. Wrong tenant (check tenant ID in app config) -4. Cached token needs refresh (clear cache + restart) - -## Feature Impact Matrix - -| Feature | Required Permissions | Without Permission | Impact Level | -|---------|---------------------|-------------------|--------------| -| Basic Policy Backup | `DeviceManagementConfiguration.Read.All` | Cannot backup | 🔴 Critical | -| Policy Restore | `DeviceManagementConfiguration.ReadWrite.All` | Cannot restore | 🔴 Critical | -| Scope Tag Names (004) | `DeviceManagementRBAC.Read.All` | Shows "Unknown (ID: X)" | 🟡 Medium | -| Assignment Names (004) | `Group.Read.All` + `Directory.Read.All` | Shows group IDs only | 🟡 Medium | -| Group Mapping (004) | `Group.Read.All` | Manual ID mapping required | 🟡 Medium | - -## Security Notes - -- All permissions are **Application Permissions** (app-level, not user-level) -- Requires **admin consent** from Global Administrator -- Use **least privilege principle**: Only add permissions for features you use -- Consider creating separate app registrations for different environments (dev/staging/prod) -- Rotate client secrets regularly (recommended: every 6 months) +- Read-only evaluation or inventory-focused setups can often begin with the read permissions only. +- Any real restore or write lane needs the corresponding `ReadWrite` permission set. +- Conditional Access write access should be treated as a higher-risk permission and granted only when the restore or admin-write lane is intentionally enabled. +- Scope-tag restore paths require `DeviceManagementRBAC.ReadWrite.All`, not just the read permission. ## References -- [Microsoft Graph API Permissions](https://learn.microsoft.com/en-us/graph/permissions-reference) -- [Intune Graph API Overview](https://learn.microsoft.com/en-us/graph/api/resources/intune-graph-overview) -- [App Registration Best Practices](https://learn.microsoft.com/en-us/azure/active-directory/develop/security-best-practices-for-app-registration) +- [Microsoft Graph permissions reference](https://learn.microsoft.com/en-us/graph/permissions-reference) +- [Microsoft Intune Graph overview](https://learn.microsoft.com/en-us/graph/api/resources/intune-graph-overview) +- [App registration security best practices](https://learn.microsoft.com/en-us/azure/active-directory/develop/security-best-practices-for-app-registration) diff --git a/docs/PROJECT_SUMMARY.md b/docs/PROJECT_SUMMARY.md index 7fa84041..e90bc67f 100644 --- a/docs/PROJECT_SUMMARY.md +++ b/docs/PROJECT_SUMMARY.md @@ -2,6 +2,11 @@ --- +> **Status:** Needs Review +> **Last reviewed:** 2026-04-30 +> **Use for:** Fast repository orientation, stack overview, and high-level product scope context +> **Do not use for:** Current implementation truth or completion status without repo verification + **Overview:** - **Purpose:** Intune management tool (backup, restore, policy versioning, safe change management) built with Laravel + Filament. - **Primary goals:** policy version control (diff/history/rollback), reliable backup & restore of Microsoft Intune configuration, admin-focused productivity features, auditability and least-privilege operations. diff --git a/docs/README.md b/docs/README.md new file mode 100644 index 00000000..1acf3daa --- /dev/null +++ b/docs/README.md @@ -0,0 +1,60 @@ +# TenantPilot Documentation Index + +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Navigating current documentation sources and understanding how to maintain them with low overhead +> **Do not use for:** Assuming any document is implementation truth without repo verification + +## Current Source of Truth + +- `docs/product/roadmap.md` - current product roadmap and prioritization context +- `docs/product/spec-candidates.md` - active spec candidate queue +- `docs/product/principles.md` - product and architecture principles +- `docs/strategy/product-vision.md` - long-term product vision +- `docs/strategy/domain-coverage.md` - domain and coverage strategy + +## Product Operations + +- `docs/product/discoveries.md` +- `docs/product/implementation-ledger.md` +- `docs/product/prompts/` +- `docs/product/standards/` + +## Technical Research + +- `docs/research/` + +## UI Standards + +- `docs/ui/` + +## Audits + +- `docs/audits/` + +## Security And Access References + +- `docs/PERMISSIONS.md` +- `docs/security/` + +## Historical Or Superseded Material + +- `docs/audits/archive/` +- audit-derived candidate documents that are marked `Historical`, `Superseded`, or `Needs Review` + +## Lightweight Maintenance Model + +- Keep only the current source-of-truth documents actively maintained. +- Update a document when the underlying roadmap, policy, or decision actually changes. +- Mark older material with status headers instead of rewriting it to feel current. +- Prefer archive or superseded markers over deletion. +- Verify implementation claims against repo code, specs, and tests. + +## Rules For Agents + +- Treat docs as guidance, not implementation truth. +- Verify implementation claims against repo code. +- Specs are not automatically implemented. +- Tests are not automatically executed. +- Historical audits may be outdated. +- Prefer current roadmap and spec-candidates for prioritization. \ No newline at end of file diff --git a/docs/audits/2026-03-15-audit-spec-candidates.md b/docs/audits/2026-03-15-audit-spec-candidates.md index ba437d81..e1eb1b73 100644 --- a/docs/audits/2026-03-15-audit-spec-candidates.md +++ b/docs/audits/2026-03-15-audit-spec-candidates.md @@ -1,5 +1,10 @@ # Audit-Derived Spec Candidates +> **Status:** Superseded +> **Last reviewed:** 2026-04-30 +> **Use for:** Historical context on audit-driven candidate clustering from March 2026 +> **Do not use for:** The current candidate queue; use `docs/product/spec-candidates.md` instead + **Date:** 2026-03-15 **Source audit:** [docs/audits/tenantpilot-architecture-audit-constitution.md](docs/audits/tenantpilot-architecture-audit-constitution.md) plus first-pass repo scan driven by [ .github/prompts/tenantpilot.audit.prompt.md ](.github/prompts/tenantpilot.audit.prompt.md) diff --git a/docs/audits/README.md b/docs/audits/README.md new file mode 100644 index 00000000..cad9ab9e --- /dev/null +++ b/docs/audits/README.md @@ -0,0 +1,10 @@ +# TenantPilot Audits + +> **Status:** Reference +> **Last reviewed:** 2026-04-30 +> **Use for:** Historical and current audit findings +> **Do not use for:** Current implementation truth without repo verification + +Audits are point-in-time assessments. They may be outdated after implementation. + +Use current source files, specs, tests, and product roadmap to verify whether a finding still applies. \ No newline at end of file diff --git a/docs/audits/enterprise-architecture-audit-2026-03-09.md b/docs/audits/enterprise-architecture-audit-2026-03-09.md index 64d26177..bf3d22fc 100644 --- a/docs/audits/enterprise-architecture-audit-2026-03-09.md +++ b/docs/audits/enterprise-architecture-audit-2026-03-09.md @@ -1,5 +1,10 @@ # Enterprise Architecture Audit — TenantPilot / TenantAtlas +> **Status:** Historical +> **Last reviewed:** 2026-04-30 +> **Use for:** Original architecture diagnosis and historical context for scope, panel, and RBAC design discussions +> **Do not use for:** Current architecture truth without repo verification + **Date:** 2026-03-09 **Auditor role:** Senior Enterprise SaaS Architect, UX/IA Auditor, Security/RBAC Reviewer **Stack:** Laravel 12, Filament v5, Livewire v4, PostgreSQL, Tailwind v4 diff --git a/docs/audits/legacy-orphaned-truth-audit.md b/docs/audits/legacy-orphaned-truth-audit.md index c4fe4d72..211da452 100644 --- a/docs/audits/legacy-orphaned-truth-audit.md +++ b/docs/audits/legacy-orphaned-truth-audit.md @@ -1,5 +1,10 @@ # Repo-wide Legacy / Orphaned Truth Audit +> **Status:** Needs Review +> **Last reviewed:** 2026-04-30 +> **Use for:** Cleanup investigations and historical context on legacy truth collisions in the repo +> **Do not use for:** Current implementation truth without repo verification + **Date**: 2026-03-16 **Scope**: Full codebase — models, migrations, enums, services, jobs, observers, Filament resources, policies, capabilities, badges, tests, factories **Method**: Systematic source-of-truth tracing across all layers diff --git a/docs/audits/semantic-clarity-spec-candidates.md b/docs/audits/semantic-clarity-spec-candidates.md index e5f3382a..4e6fe4f0 100644 --- a/docs/audits/semantic-clarity-spec-candidates.md +++ b/docs/audits/semantic-clarity-spec-candidates.md @@ -1,5 +1,10 @@ # Semantic Clarity — Spec Candidate Package +> **Status:** Superseded +> **Last reviewed:** 2026-04-30 +> **Use for:** Historical reasoning behind the semantic clarity cleanup program and its original packaging +> **Do not use for:** The current candidate queue, current spec numbering, or current implementation truth without repo verification + **Source audit:** `docs/audits/semantic-clarity-audit.md` **Date:** 2026-03-21 **Author role:** Senior Staff Engineer / Enterprise SaaS Product Architect diff --git a/docs/audits/tenantpilot-architecture-audit-constitution.md b/docs/audits/tenantpilot-architecture-audit-constitution.md index d3a1034b..e18d6d95 100644 --- a/docs/audits/tenantpilot-architecture-audit-constitution.md +++ b/docs/audits/tenantpilot-architecture-audit-constitution.md @@ -1,5 +1,10 @@ # TenantPilot Architecture Audit Constitution +> **Status:** Reference +> **Last reviewed:** 2026-04-30 +> **Use for:** Audit standards, architectural review criteria, and repo-level safety review framing +> **Do not use for:** Current implementation truth or roadmap priority without repo verification + ## Purpose This constitution defines the non-negotiable architecture, security, and workflow rules for TenantPilot / TenantAtlas. diff --git a/docs/product/discoveries.md b/docs/product/discoveries.md index 822a9814..b578bcb7 100644 --- a/docs/product/discoveries.md +++ b/docs/product/discoveries.md @@ -1,47 +1,25 @@ # Discoveries +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Parking implementation findings and follow-up ideas that are not yet part of the active roadmap or candidate queue +> **Do not use for:** Active priority order once an item is already tracked in the roadmap or spec-candidates +> > Things found during implementation that don't belong in the current spec. > Review weekly. Promote to [spec-candidates.md](spec-candidates.md) or discard. Items that are already tracked in [spec-candidates.md](spec-candidates.md) or [roadmap.md](roadmap.md) should not remain here. -**Last reviewed**: 2026-03-15 +**Last reviewed**: 2026-04-30 --- -## 2026-03-15 — Queued execution trust relies too much on dispatch-time authority +## 2026-04-30 — 2026-03-15 architecture hardening cluster moved out of discoveries - **Source**: architecture audit -- **Observation**: Queued jobs still rely too heavily on the actor, tenant, and authorization state captured at dispatch time. Execution-time scope continuity and reauthorization are not yet hardened as a canonical backend contract. -- **Category**: hardening -- **Priority**: high -- **Suggested follow-up**: Track in [../audits/2026-03-15-audit-spec-candidates.md](../audits/2026-03-15-audit-spec-candidates.md) as Candidate A: queued execution reauthorization and scope continuity. - ---- - -## 2026-03-15 — Tenant-owned query canon remains too ad hoc -- **Source**: architecture audit -- **Observation**: Tenant isolation is broadly present, but many tenant-owned reads still depend on repeated local `tenant_id` filtering instead of a reusable canonical query path. This increases drift risk and weakens wrong-tenant regression discipline. -- **Category**: hardening -- **Priority**: high -- **Suggested follow-up**: Track in [../audits/2026-03-15-audit-spec-candidates.md](../audits/2026-03-15-audit-spec-candidates.md) as Candidate B: tenant-owned query canon and wrong-tenant guards. - ---- - -## 2026-03-15 — Findings lifecycle truth is stronger in docs than in enforcement -- **Source**: architecture audit -- **Observation**: Findings workflow semantics are well-defined at spec level, but architectural enforcement still depends too much on service-path discipline. Direct or bypassing status mutations remain too plausible. -- **Category**: hardening -- **Priority**: high -- **Suggested follow-up**: Track in [../audits/2026-03-15-audit-spec-candidates.md](../audits/2026-03-15-audit-spec-candidates.md) as Candidate C: findings workflow enforcement and audit backstop. - ---- - -## 2026-03-15 — Livewire trust-boundary hardening is still convention-driven -- **Source**: architecture audit -- **Observation**: Complex Livewire and Filament flows still expose too much ownership-relevant context in public component state. This is not a proven exploit in the repo today, but the hardening standard is not yet explicit or reusable. -- **Category**: hardening -- **Priority**: medium -- **Suggested follow-up**: Track in [../audits/2026-03-15-audit-spec-candidates.md](../audits/2026-03-15-audit-spec-candidates.md) as Candidate D: Livewire context locking and trusted-state reduction. +- **Observation**: The queued execution, tenant-query-canon, findings-enforcement, and Livewire trust-boundary items from the 2026-03-15 audit are now tracked through promoted specs and the roadmap hardening lane. They no longer belong in `discoveries.md` as open findings. +- **Category**: documentation +- **Priority**: low +- **Suggested follow-up**: Use `roadmap.md` and `spec-candidates.md` for current hardening follow-through; keep `discoveries.md` for new findings that are not yet tracked elsewhere. --- diff --git a/docs/product/implementation-ledger.md b/docs/product/implementation-ledger.md index 8bec9042..095c7c69 100644 --- a/docs/product/implementation-ledger.md +++ b/docs/product/implementation-ledger.md @@ -1,5 +1,10 @@ # TenantPilot Implementation Ledger +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Repo-based implementation status and product-surface maturity assessment +> **Do not use for:** Roadmap priority, spec priority, or proof that tests were executed in the current branch + ## Purpose Dieses Dokument beschreibt den aktuellen repo-basierten Implementierungsstand von TenantPilot. Es ergaenzt `roadmap.md` und `spec-candidates.md`, ersetzt sie aber nicht. @@ -15,7 +20,7 @@ ## Purpose ## Current Product Position -TenantPilot ist aktuell ein starkes internes Governance- und Operations-Produkt mit belastbaren Foundations fuer Execution Truth, Baselines/Drift, Findings, Evidence, Reviews, Review Packs, Supportability, Telemetry und Safety Controls und inzwischen repo-real umgesetzten Customer-safe Review Consumption, Risk-Acceptance/Exception-Workflow, Findings-/Governance-Inboxen und einer DE/EN-Locale-Foundation. Die Repo-Wahrheit liegt damit klar ueber einer simplen Lesart von "R1 done / R2 partial". Gleichzeitig ist das Produkt noch nicht voll als kundenseitig konsumierbare Portfolio- und Commercial-Plattform ausgereift: Cross-Tenant-Workflows, Compare/Promotion, Billing-/Lifecycle-Reife und Private-AI-Governance bleiben unvollstaendig. Zusaetzlich zeigt der Repo-Stand weiterhin eine schmale Findings-Cleanup-Lane: sichtbare Lifecycle-Backfill-Runtime-Surfaces, `acknowledged`-Kompatibilitaet und fehlende explizite Creation-Time-Invariant-Absicherung sollten als getrennte Folgespecs behandelt werden. +TenantPilot ist aktuell ein starkes internes Governance- und Operations-Produkt mit belastbaren Foundations fuer Execution Truth, Baselines/Drift, Findings, Evidence, Reviews, Review Packs, Supportability, Telemetry und Safety Controls sowie einer repo-real umgesetzten ersten Customer-Review-Surface, Risk-Acceptance/Exception-Workflow, Findings-/Governance-Inboxen und einer DE/EN-Locale-Foundation. Die Repo-Wahrheit liegt damit klar ueber einer simplen Lesart von "R1 done / R2 partial". Gleichzeitig ist das Produkt noch nicht voll als kundenseitig konsumierbare Portfolio- und Commercial-Plattform ausgereift: Die Customer-Review-Surface ist noch eher eine operator-led customer delivery view im Admin-Kontext als eine voll produktisierte, kundensichere Governance-of-Record Consumption-Flache; dazu bleiben Cross-Tenant-Workflows, Compare/Promotion, Billing-/Lifecycle-Reife und Private-AI-Governance unvollstaendig. Zusaetzlich zeigt der Repo-Stand weiterhin eine schmale Findings-Cleanup-Lane: sichtbare Lifecycle-Backfill-Runtime-Surfaces, `acknowledged`-Kompatibilitaet und fehlende explizite Creation-Time-Invariant-Absicherung sollten als getrennte Folgespecs behandelt werden. ## Status Model @@ -41,7 +46,7 @@ ## Roadmap Coverage Summary | Roadmap Area | Status | Evidence Level | UI Ready | Tested | Sellable | Notes | |---|---|---:|---|---|---|---| | R1 Golden Master Governance | adopted | strong | yes | repo tests, not run | yes | Baselines, Drift, Findings und OperationRun-Truth sind breit im Produkt verankert. | -| R2 Tenant Reviews, Evidence & Control Foundation | adopted | strong | yes | repo tests, not run | yes | Reviews, Evidence, Review Packs, Customer Review Workspace und Control-/Exception-Layer greifen als reale Governance-Surface zusammen. | +| R2 Tenant Reviews, Evidence & Control Foundation | adopted | strong | yes | repo tests, not run | almost | Reviews, Evidence, Review Packs, Customer Review Workspace und Control-/Exception-Layer greifen als reale Governance-Surface zusammen, aber die Customer-Consumption-Productization bleibt unvollstaendig. | | Alert escalation + notification routing | implemented_verified | strong | partial | repo tests, not run | yes | Alert-Regeln, Dispatch, Cooldown und Quiet Hours sind real. | | Governance & Architecture Hardening | implemented_partial | strong | partial | repo tests, not run | foundation-only | Viele Hardening-Slices sind bereits im Code, die Lane bleibt aber aktiv. | | UI & Product Maturity Polish | implemented_partial | strong | partial | partial repo tests, not run | no | Empty States, Navigation, Localization und read-only Review-Polish sind real, aber kein geschlossenes Theme-Completion-Signal. | @@ -50,12 +55,12 @@ ## Roadmap Coverage Summary | R1.9 Platform Localization v1 | implemented_verified | strong | yes | repo tests, not run | foundation-only | Locale-Resolver, Override/Praeferenz, Workspace-Default, Fallback und lokalisierte Notifications sind repo-real. | | Product Scalability & Self-Service Foundation | implemented_partial | strong | yes | repo tests, not run | almost | Onboarding, Support, Help und Entitlements sind weit; Billing, Trial und Demo-Reife fehlen. | | R2.0 Canonical Control Catalog Foundation | implemented_verified | strong | partial | repo tests, not run | foundation-only | Bereits implementiert und in Evidence/Reviews referenziert, aber kein eigenstaendiger Kundennutzen-Surface. | -| R2 Completion: customer review, support, help | adopted | strong | yes | repo tests, not run | yes | Customer Review Workspace, Support Diagnostics/Requests und Help-Katalog sind repo-real. | +| R2 Completion: customer review, support, help | implemented_partial | strong | yes | repo tests, not run | almost | Customer Review Workspace, Support Diagnostics/Requests und Help-Katalog sind repo-real, aber die Customer-Review-Consumption ist noch nicht voll productized. | | Findings Workflow v2 / Execution Layer | adopted | strong | yes | repo tests, not run | almost | Triage, Ownership, My Work, Intake, Governance Inbox, Exceptions und Alerts/Hygiene sind real; Cross-Tenant-Decisioning bleibt spaeter. | | Policy Lifecycle / Ghost Policies | specified | weak | no | no | no | Als Richtung sichtbar, aber nicht als repo-verifizierter Workflow. | | Platform Operations Maturity | implemented_partial | strong | yes | repo tests, not run | almost | System Panel, Control Tower und Ops Controls sind real; CSV/Raw Drilldowns bleiben offen. | | Product Usage, Customer Health & Operational Controls | adopted | strong | yes | repo tests, not run | almost | Diese Mid-term-Lane ist im Repo bereits substanziell vorhanden. | -| Private AI Execution & Usage Governance Foundation | planned | none | no | no | no | Keine belastbare AI-Governance-Foundation im Repo. | +| Private AI Execution Governance Foundation | planned | none | no | no | no | Keine belastbare AI-Governance-Foundation im Repo. | | MSP Portfolio & Operations | implemented_partial | medium | partial | repo tests, not run | foundation-only | Portfolio-Triage ist da; Compare/Promotion und Decision Workboard fehlen. | | Human-in-the-Loop Autonomous Governance | planned | none | no | no | no | Kein repo-verifizierter Decision-Pack- oder Approval-Workflow jenseits des jetzigen Exception-/Review-Layers. | | Drift & Change Governance | implemented_partial | strong | yes | repo tests, not run | almost | Drift review, accepted-risk governance, exception validity und Governance-Inbox-Surfaces sind repo-real; portfolio-weite Eskalation bleibt offen. | @@ -75,7 +80,7 @@ ## Implemented Capabilities | Evidence snapshots | implemented_verified | yes | yes | repo tests, not run | yes | foundation-only | `app/Models/EvidenceSnapshot.php`; `app/Services/Evidence/EvidenceSnapshotService.php`; `tests/Feature/Evidence/*` | | Tenant reviews | implemented_verified | yes | yes | repo tests, not run | yes | almost | `app/Models/TenantReview.php`; `app/Services/TenantReviews/TenantReviewService.php`; `tests/Feature/TenantReview/*` | | Review pack generation and export | implemented_verified | yes | yes | repo tests, not run | yes | yes | `app/Models/ReviewPack.php`; `app/Services/ReviewPackService.php`; `tests/Feature/ReviewPack/*` | -| Customer review workspace | implemented_verified | yes | yes | repo tests, not run | yes | yes | `app/Filament/Pages/Reviews/CustomerReviewWorkspace.php`; `tests/Feature/Reviews/*`; `tests/Browser/Reviews/CustomerReviewWorkspaceSmokeTest.php` | +| Customer review workspace | implemented_partial | yes | yes | repo tests, not run | yes | almost | `app/Filament/Pages/Reviews/CustomerReviewWorkspace.php`; `tests/Feature/Reviews/*`; `tests/Browser/Reviews/CustomerReviewWorkspaceSmokeTest.php` | | Alerts and notification routing | implemented_verified | yes | partial | repo tests, not run | yes | yes | `app/Services/Alerts/AlertDispatchService.php`; `tests/Feature/*Alert*` | | Provider health, onboarding readiness and required permissions | adopted | yes | yes | repo tests, not run | yes | almost | `app/Jobs/ProviderConnectionHealthCheckJob.php`; `app/Services/Onboarding/OnboardingLifecycleService.php`; `app/Filament/Pages/TenantRequiredPermissions.php` | | Permission posture reporting | implemented_verified | yes | yes | repo tests, not run | yes | yes | `app/Services/PermissionPosture/PermissionPostureFindingGenerator.php`; `tests/Feature/PermissionPosture/*` | @@ -110,7 +115,7 @@ ## Foundation-Only Capabilities ## Partial Capabilities -- Customer-facing review consumption: Tenant Reviews, Evidence Snapshots, Review Packs und der Customer Review Workspace sind repo-real, aber portfolio-weite Consumption- und Sharing-Patterns bleiben offen. +- Customer-facing review consumption: Tenant Reviews, Evidence Snapshots, Review Packs und der Customer Review Workspace sind repo-real, aber die Surface bleibt noch operator-led im Admin-Kontext; customer-safe wording, evidence summarization boundaries, audit-grade access semantics und calmer consumption states brauchen ein eigenes Productization-Follow-up. - Findings Workflow v2: Triage, Assignment, My Work, Intake, Governance Inbox, Exceptions und Notifications sind vorhanden; spaetere Cross-Tenant-Decisioning-Layer und Cleanup debt um Lifecycle-Backfill-Surfaces, `acknowledged`-Kompatibilitaet und explizite Creation-Time-Invarianten bleiben offen. - Product scalability and self-service: Onboarding, Support, Help und Entitlements sind weit, Billing-, Trial- und Demo-Reife aber nicht. - MSP portfolio operations: Portfolio-Triage ist vorhanden, Cross-Tenant Compare und Promotion fehlen. @@ -119,7 +124,7 @@ ## Partial Capabilities ## Planned But Not Implemented -- Private AI Execution & Usage Governance Foundation +- Private AI Execution Governance Foundation - Human-in-the-Loop Autonomous Governance - Standardization & Policy Quality / Intune Linting - PSA / Ticketing Handoff @@ -132,9 +137,10 @@ ## Release Readiness | Release / Theme | Readiness | Notes | |---|---|---| | R1 Golden Master Governance | implemented | Die zentrale Governance- und Execution-Layer ist repo-verifiziert und breit adoptiert. | -| R2 Tenant Reviews & Evidence Packs | implemented | Reviews, Evidence Snapshots, Review Packs, Customer Review Workspace und Exception-/Accepted-Risk-Workflow sind repo-real; breitere Commercial-Polish-Themen bleiben separat. | +| R2 Tenant Reviews & Evidence Packs | implemented | Reviews, Evidence Snapshots, Review Packs, Customer Review Workspace und Exception-/Accepted-Risk-Workflow sind repo-real; die Customer-Review-Productization bleibt aber als sellability follow-up offen. | | R3 MSP Portfolio OS | foundation only | Portfolio-Triage und Governance-Surfaces sind da, aber Compare/Promotion und portfolio-weite Action-Layer fehlen. | -| Later Compliance Light | foundation only | Canonical Controls, Evidence und Exceptions existieren als Grundlage; ein Compliance-Produkt ist nicht repo-proven. | +| Compliance Evidence Mapping v1 | foundation only | Canonical Controls, Evidence, Stored Reports und Exceptions existieren als Grundlage; eine customer-safe Mapping-Layer ist nicht repo-proven. | +| Governance-as-a-Service Packaging v1 | foundation only | Review Packs, Exports, Evidence und Accepted-Risk-Truth sind repo-real; eine wiederholbare management-taugliche Governance-Verpackung ist nicht repo-proven. | ## Commercial Readiness @@ -142,14 +148,14 @@ ### Demo-ready - Baseline compare and drift walkthroughs - Review pack generation and export -- Customer-safe review workspace walkthroughs +- Customer review workspace walkthroughs with operator guidance - Provider health, onboarding readiness and required permissions - Support diagnostics - Permission posture and Entra admin roles reporting ### Almost sellable -- Review-driven governance workflow rund um Tenant Reviews, Customer Review Workspace, accepted risks und Review Packs +- Review-driven governance workflow rund um Tenant Reviews, Customer Review Workspace, accepted risks und Review Packs, aber noch nicht als vollstaendig productisierte customer-safe consumption experience - Baseline drift and restore governance - Findings workflow mit persönlicher Inbox, Intake, Governance Inbox und Exception-Handling - Alerting and run visibility for governance operations @@ -174,39 +180,46 @@ ### Foundation-only ### Not sellable yet - Cross-Tenant Compare and Promotion v1 +- Compliance Evidence Mapping v1 +- Governance-as-a-Service Packaging v1 - Private AI Execution Governance Foundation - External Support Desk / PSA Handoff -- Compliance Light product layer ## Open Gaps & Blockers | Gap | Type | Impact | Roadmap Area | Recommended Spec | |---|---|---|---|---| +| Customer review productization remains incomplete | Sellability blocker | The repo has a real read-only customer review surface, but it still sits too close to operator/admin semantics and does not yet enforce a fully customer-safe consumption contract for findings, evidence, accepted risks, and audit-grade access/download flows | R2 completion / Customer review | P0 Customer Review Workspace Productization v1 | | Decisioning still spans multiple repo-real inboxes | UX blocker | My Findings, Intake, Governance Inbox und Exception Queue sind real, aber Operators springen weiter zwischen mehreren Spezial-Surfaces und es gibt noch keinen portfolio-weiten Action-Layer | Findings Workflow / MSP Portfolio | P1 Governance Decision Surface Convergence | | Findings lifecycle backfill runtime surfaces remain productized | Cleanup blocker | Runbooks, commands, capabilities and tenant actions still expose a pre-production repair path that should not ship as product truth | Findings Workflow / Legacy Removal | P1 Remove Findings Lifecycle Backfill Runtime Surfaces | | Legacy `acknowledged` status compatibility still survives | Semantics blocker | Status helpers, filters, badges, capability aliases and tests keep non-canonical workflow semantics alive | Findings Workflow / RBAC | P1 Remove Legacy Acknowledged Finding Status Compatibility | | Creation-time finding invariants are implied but not explicitly protected | Integrity blocker | Future finding generators could regress into partial lifecycle writes and recreate the need for repair tooling | Findings Workflow / Data Integrity | P1 Enforce Creation-Time Finding Invariants | | Cross-tenant compare and promotion is not repo-proven | Release blocker | MSP portfolio story remains partial | MSP Portfolio & Operations | P1 Cross-Tenant Compare and Promotion v1 | | Entitlements stop short of full commercial lifecycle | Commercialization blocker | Plan gating exists, but trial, grace and suspension semantics remain incomplete | Product Scalability & Self-Service Foundation | P2 Commercial Entitlements and Billing-State Maturity | +| Compliance-oriented control mapping is not productized | Moat blocker | Canonical controls and evidence exist, but the product still lacks a bounded customer-safe layer that maps technical truth into control/readiness language | Compliance Evidence Mapping | P2 Compliance Evidence Mapping v1 | +| Review truth is not yet packaged as a repeatable MSP deliverable | Sellability blocker | Review packs and evidence are real, but recurring management-ready governance packaging still depends on manual interpretation and presentation | Governance-as-a-Service Packaging | P2 Governance-as-a-Service Packaging v1 | | Support requests do not hand off to an external desk | Commercialization blocker | Support operations still depend on manual follow-through outside the product | R2 completion / Support | P2 External Support Desk / PSA Handoff | -| AI governance foundation is absent | Architecture blocker | Future AI features would risk trust and policy drift if added directly | Private AI Execution & Usage Governance | P3 Private AI Execution Governance Foundation | +| AI governance foundation is absent | Architecture blocker | Future AI features would risk trust and policy drift if added directly | Private AI Execution Governance | P3 Private AI Execution Governance Foundation | | Roadmap understates current repo truth | Architecture blocker | Prioritization can drift because strategy docs still lag neuere Review-, Findings- und Localization-Surfaces | Product planning / roadmap maintenance | none - docs alignment | | Test files were not executed for this ledger update | Testing blocker | This document relies on code plus test presence, not live runtime validation | all areas | none - run targeted suites | ## Recommended Next Specs +- `P0 Customer Review Workspace Productization v1`: turns the existing admin-plane handoff into a more explicit customer-safe review consumption contract with calmer wording, progressive disclosure, explicit access states, and auditable download/view semantics. - `P1 Governance Decision Surface Convergence`: verbindet My Findings, Intake, Governance Inbox, Customer Review Workspace und Exception Queue zu weniger Operator-Journeys und bereitet die Portfolio-Ebene vor. - `P1 Remove Findings Lifecycle Backfill Runtime Surfaces`: removes visible pre-production repair tooling from runbooks, commands, actions, capabilities and deploy/runtime hooks. - `P1 Remove Legacy Acknowledged Finding Status Compatibility`: collapses findings workflow semantics onto the canonical `triaged` model and removes stale RBAC/query aliases. - `P1 Enforce Creation-Time Finding Invariants`: proves that new findings are lifecycle-ready at write time so no repair backfill has to return later. - `P1 Cross-Tenant Compare and Promotion v1`: needed to move from portfolio visibility to portfolio action. - `P2 Commercial Entitlements and Billing-State Maturity`: extends the already real entitlement substrate into a usable commercial lifecycle. +- `P2 Compliance Evidence Mapping v1`: should start as one bounded versioned overlay that maps existing technical truth into one customer-safe control/readiness view and one reuse path into review or export surfaces. +- `P2 Governance-as-a-Service Packaging v1`: should start as one on-demand management-ready governance package built from existing review-pack, evidence, and accepted-risk truth rather than a broad recurring reporting suite. - `P2 External Support Desk / PSA Handoff`: extends support requests beyond internal persistence. - `P3 Private AI Execution Governance Foundation`: should exist before feature-level AI adoption, not after it. ## Roadmap Drift Notes -- `roadmap.md` understates current R2 completion. Customer Review Workspace, published review handoff, review-pack downloads und der Finding-Exception-/Risk-Acceptance-Workflow sind bereits repo-real. +- `roadmap.md` understates current R2 implementation depth, but the ledger had overstated sellability. Customer Review Workspace, published review handoff, review-pack downloads und der Finding-Exception-/Risk-Acceptance-Workflow sind repo-real; the remaining gap is customer-safe productization, not review-foundation absence. - `roadmap.md` understates findings workflow maturity. My Findings, Intake, Governance Inbox und Exception Queue existieren bereits im Repo. - `roadmap.md` understates localization maturity. Locale resolution order, Workspace-Default, User-Praeferenz, lokalisierte Notifications und Fallback-Tests sind implementiert. - `roadmap.md` understates the current R2 control foundation. Canonical controls, stored reports, permission posture and Entra admin roles are already repo-real, not just near-term ideas. @@ -214,7 +227,7 @@ ## Roadmap Drift Notes - `roadmap.md` understates operational maturity. Product telemetry, customer health and operational controls are already implemented and wired into the system panel. - `roadmap.md` understates commercial foundations. A workspace entitlement resolver, plan profiles and enforcement points already exist, even though full billing-state maturity does not. - The roadmap is now better at describing still-missing portfolio- und commercial-Layer than the current state of review/findings/localization implementation. Cross-Tenant Compare and Promotion, full billing-state maturity, external PSA handoff and AI Governance still look genuinely unimplemented. -- The main drift pattern is underestimation, not overestimation. Customer-facing review consumption is no longer the clearest missing piece; portfolio action and commercial lifecycle are. +- The main drift pattern is still underestimation, but customer-review sellability now needs a more precise reading: the missing piece is no longer basic review read-only access, but the final customer-safe productization layer over an already real surface. ## Evidence Sources diff --git a/docs/product/operator-semantic-taxonomy.md b/docs/product/operator-semantic-taxonomy.md index f6a4adef..bf4e4bc6 100644 --- a/docs/product/operator-semantic-taxonomy.md +++ b/docs/product/operator-semantic-taxonomy.md @@ -1,5 +1,10 @@ # Operator Semantic Taxonomy +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Canonical operator-facing vocabulary for lifecycle, outcome, evidence, and actionability states +> **Do not use for:** Inventing local synonyms or assuming every product surface already fully conforms without repo verification +> > Canonical operator-facing state reference for the first implementation slice. > Downstream specs and badge mappings must reuse this vocabulary instead of inventing local synonyms. diff --git a/docs/product/principles.md b/docs/product/principles.md index 89baaba1..d3bcbbab 100644 --- a/docs/product/principles.md +++ b/docs/product/principles.md @@ -1,5 +1,10 @@ # Product Principles +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Stable product and architecture principles that should shape specs, UX, and implementation choices +> **Do not use for:** Assuming every principle is already enforced everywhere in code without repo verification +> > Permanent product principles that govern every spec, every UI decision, and every architectural choice. > New specs must align with these. If a principle needs to change, update this file first. diff --git a/docs/product/prompts/README.md b/docs/product/prompts/README.md new file mode 100644 index 00000000..75871bfd --- /dev/null +++ b/docs/product/prompts/README.md @@ -0,0 +1,11 @@ +# Product & Roadmap Prompts + +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Reusable roadmap, productization, and portfolio audit prompts +> **Do not use for:** Direct implementation without converting outputs into specs or verified planning artifacts + +This folder contains reusable prompts for roadmap analysis, productization audits, and product strategy reviews. + +Prompts are not specs. +Prompts are tools to generate, validate, or refine roadmap and spec-candidate decisions. \ No newline at end of file diff --git a/docs/product/roadmap.md b/docs/product/roadmap.md index 6518dff0..f26e066c 100644 --- a/docs/product/roadmap.md +++ b/docs/product/roadmap.md @@ -1,9 +1,16 @@ # Product Roadmap +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Current product roadmap, release themes, and prioritization context +> **Do not use for:** Implementation truth, spec completion status, or delivery guarantees without repo verification +> > Strategic thematic blocks and release trajectory. > This is the "big picture" — not individual specs. +> +> Queue boundary: the active candidate queue lives in `spec-candidates.md`; older audit-derived candidate packages are historical inputs only. -**Last updated**: 2026-04-25 +**Last updated**: 2026-04-30 --- @@ -16,6 +23,26 @@ ## Release History | **R2 "Tenant Reviews, Evidence & Control Foundation"** | Evidence packs, stored reports, canonical control catalog, permission posture, alerts | **Partial** | | **R2 cont.** | Alert escalation + notification routing | **Done** | +## Current Productization & Moat Priorities + +This is the repo-based prioritization overlay for the next sellable lanes. The bottleneck is no longer raw backend truth alone. The next roadmap slices should make existing governance foundations customer-safe, decision-centered, auditable, and MSP-sellable before opening more backend-only islands. + +| Order | Theme | Repo truth | Product posture | Why now | Candidate posture | +|---|---|---|---|---|---| +| 1 | Customer Review Workspace Productization v1 | Reviews, Evidence Snapshots, Review Packs, Customer Review Workspace, and accepted-risk foundations are repo-real | fast sellable | clearest sellability blocker between current repo truth and a customer-safe governance-of-record surface | active P0 candidate | +| 2 | Risk Acceptance & Accountability productization | Exception / risk-acceptance workflow is repo-verified, but customer-safe accountability presentation is not fully productized | fast sellable | strong MSP and German midmarket moat around documented decisions, expiry, reviewability, and audit trail | fold into Customer Review Workspace Productization and review/reporting follow-through, not a new greenfield foundation | +| 3 | Governance Decision Surface Convergence | Governance Inbox, My Findings, Intake, and Exception Queue are repo-real, but convergence is not | almost | reduces admin-tool sprawl and turns multiple queue surfaces into calmer decision work | active P1 candidate | +| 4 | Compliance Evidence Mapping v1 | Canonical controls, evidence, stored reports, reviews, and findings foundations are repo-real; customer-safe compliance mapping is not | foundation-only | strong governance moat for compliance-oriented MSP and Mittelstand reviews without certification claims | active P2 candidate | +| 5 | Governance-as-a-Service Packaging v1 | Review packs, exports, evidence, and accepted-risk foundations are repo-real; recurring executive/MSP packaging is not | foundation-only | turns governance truth into a repeatable MSP deliverable instead of one-off manual reporting | active P2 candidate | +| 6 | Cross-Tenant Compare & Promotion v1 | Portfolio triage exists; compare and promotion are not repo-proven | not implemented | strongest MSP multiplier after customer-safe review and decision workflows are calmer | active P1 candidate | +| 7 | Private AI Execution Governance Foundation | Spec 248 exists, but no repo-real governed AI execution layer is proven | only spec / not implemented | strategic moat later, but not ahead of current productization and portfolio-action gaps | keep as later strategic lane, not near-term blocker | + +Explicit anti-sprawl boundaries for this priority set: + +- Do not reopen risk acceptance as a broad new foundation theme; reuse the existing exception/risk-acceptance workflow and productize its customer-safe accountability trail. +- Do not reopen private AI as a fresh roadmap idea; the foundation already exists at spec level and should remain behind current customer-facing and MSP-facing sellability gaps. +- Do not prioritize Tenant Trust Score / public governance profile, insurance connectors, Copilot shadow-IT governance, local-first/on-prem proxy, or a standalone Betriebsrat mode before customer-safe review consumption, decision convergence, compliance mapping, governance packaging, and compare/promotion are materially clearer. + --- ## Active / Near-term @@ -51,6 +78,8 @@ ### R1.9 Platform Localization v1 (DE/EN) UI-Sprache umschaltbar (`de`, `en`) mit sauberem Locale-Foundation-Layer. Goal: Konsistente, durchgängige Lokalisierung aller Governance-Oberflächen — ohne Brüche in Export, Audit oder Maschinenformaten. +Repo reality: Die Locale-Foundation ist bereits repo-real. Der verbleibende Gap ist kein greenfield Localization-Foundation-Spec mehr, sondern Surface-Adoption, Copy-/Glossary-Vervollständigung und Regression-Hardening auf customer- und governance-nahen Oberflächen. + - Locale-Priorität: expliziter Override → User Preference → Workspace Default → System Default - Workspace Default Language für neue Nutzer, User kann persönliche Sprache überschreiben - Core-Surfaces zuerst: Navigation, Dashboard, Tenant Views, Findings, Baseline Compare, Risk Exceptions, Alerts, Operations, Audit-nahe Grundtexte @@ -64,7 +93,7 @@ ### R1.9 Platform Localization v1 (DE/EN) - Search/Sort/Filter auf kritischen Listen für locale-sensitives Verhalten prüfen - QA/Foundation: Missing-Key Detection, Locale Regression Tests, Pseudolocalization Smoke Tests für kritische Flows -**Active specs**: — (not yet specced) +**Queue status**: no standalone active candidate right now; remaining localization work should be folded into customer-facing productization and UI-maturity follow-through unless a narrower repo-real gap emerges. ### Product Scalability & Self-Service Foundation Self-service and supportability foundation that keeps TenantPilot operable as a low-headcount, AI-assisted SaaS instead of drifting into manual onboarding, manual support, and founder-dependent customer operations. @@ -110,10 +139,10 @@ ### R1.x Foundation Hardening — Governance Platform Anti-Drift ### R2 Completion — Evidence & Exception Workflows - Review pack export (Spec 109 — done) -- Exception/risk-acceptance workflow for Findings → Spec 154 (draft) +- Exception/risk-acceptance workflow for Findings → Spec 154 (repo-real foundation; the next product gap is accountability-trail productization in customer-safe review, expiry/re-review visibility, and management-ready reporting) - Formal evidence/review-pack entity foundation → Spec 153 (evidence snapshots, draft) + Spec 155 (tenant review layer / review packs, draft) - Workspace-level PII override for review packs → deferred from 109 -- Customer Review Workspace / Read-only View v1 → sharpen customer-facing review consumption: baseline status, latest reviews, findings, accepted risks, evidence/review-pack downloads, customer-safe redaction, and no admin/remediation actions +- Customer Review Workspace Productization v1 → sharpen customer-facing review consumption: baseline status, latest reviews, findings, accepted risks, evidence/review-pack downloads, customer-safe redaction, calmer access states, and no admin/remediation actions - Support Diagnostic Pack → connect tenant/review/finding/report/operation contexts into a reusable support bundle before support demand scales - In-App Support Request with Context → attach the relevant diagnostic pack and ticket reference to support workflows without creating a separate support data model - Product Knowledge & Contextual Help → reuse canonical glossary, outcome/reason semantics, and report/finding terminology as the product-help source layer @@ -127,10 +156,24 @@ ### Findings Workflow v2 / Execution Layer - Reuse the existing alerting foundation for assignment, reopen, due-soon, and overdue notification flows - Keep comments, external ticket handoff, and cross-tenant workboards as later slices instead of forcing them into the first workflow iteration -### Policy Lifecycle / Ghost Policies -Soft delete detection, automatic restore, "Deleted" badge, restore from backup. -Draft exists (Spec 900). Needs spec refresh and prioritization. -**Risk**: Ghost policies create confusion for backup item references. +### Workspace, Tenant & Managed Object Lifecycle Governance +Strategic lifecycle taxonomy for workspaces, tenants, managed provider objects, evidence, backups, restoreability, export, retention, and purge. +**Goal**: Prevent local lifecycle fixes such as “Ghost Policies” from introducing inconsistent deletion semantics before TenantPilot has one enterprise-grade lifecycle model. + +TenantPilot must distinguish at least these lifecycle 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 + +**Roadmap posture**: Strategic P2 enterprise-trust candidate, not immediate implementation. This should not block Customer Review Workspace Productization, Governance Decision Surface Convergence, or Cross-Tenant Compare & Promotion. + +**Important boundary**: Do not implement a narrow policy-only ghost lifecycle patch, Laravel `SoftDeletes` rollout, workspace deletion flow, tenant deletion flow, purge engine, or retention framework before this lifecycle taxonomy is agreed. + +**Spec candidate**: `Workspace, Tenant & Managed Object Lifecycle Governance v1` in `docs/product/spec-candidates.md`. ### Platform Operations Maturity - CSV export for filtered run metadata (deferred from Spec 114) @@ -166,7 +209,7 @@ ### Additional Solo-Founder Scale Guardrails - Vendor Questionnaire Answer Bank: reusable security/procurement answers aligned with the Security Trust Pack, product data model, Microsoft permissions, hosting, AI usage, subprocessors, retention, backup, deletion, and incident handling - Product Intake & No-Customization Governance: feature-request intake, roadmap-fit classification, no-custom-work policy, customer exception handling, productization rules, and a clear path from request → candidate → spec → release or rejection - Support Severity Matrix & Runbooks: P1–P4 definitions, incident vs support vs bug vs feature request distinction, response expectations by plan, escalation rules, known-issue handling, and internal support runbooks -- Data Retention, Export & Deletion Self-Service: customer-facing and operator-facing flows for export, archive, deletion request handling, trial data expiry, workspace deactivation, and evidence/report retention visibility +- Data Retention, Export & Deletion Self-Service: customer-facing and operator-facing flows for export, archive, deletion request handling, trial data expiry, workspace deactivation, and evidence/report retention visibility; depends on the shared Workspace, Tenant & Managed Object Lifecycle Governance taxonomy before destructive or retention-sensitive flows are implemented - Business Continuity / Founder Backup Plan: access documentation, secret management, emergency contacts, deployment and restore runbooks, incident templates, DNS/domain/hosting ownership, billing access, and vacation/sickness fallback **Active specs**: — (not yet specced; guardrail track, only product-impacting items should become specs) @@ -182,12 +225,13 @@ ### Product Usage, Customer Health & Operational Controls **Depends on**: Self-Service Tenant Onboarding & Connection Readiness, Support Diagnostic Pack, Plans / Entitlements & Billing Readiness, ProviderConnection health, OperationRun truth, Findings workflow, StoredReports / EvidenceItems, and audit log foundation. **Scope direction**: Start with privacy-aware product telemetry, derived customer/workspace health indicators, and a minimal operational controls registry. Avoid building a full analytics platform, CRM, or customer-success suite in the first slice. -### Private AI Execution & Usage Governance Foundation +### Private AI Execution Governance Foundation Strategic AI platform foundation for using AI inside TenantPilot without hard-coding public cloud AI calls, leaking tenant data, losing cost control, or forcing later rewrites. **Goal**: Make AI local/private-first, explicitly governed, budgeted, cacheable, auditable, and human-approved. External public AI providers are disabled by default and only usable through workspace-level opt-in, data classification, redaction, usage limits, and approval gates. **Why it matters**: TenantPilot sells governance, compliance readiness, evidence, and tenant trust. AI cannot be bolted on through direct feature-level API calls. The platform needs a reusable execution boundary so support summaries, finding explanations, review packs, decision packs, and customer communications can use AI later without rebuilding privacy, cost, provider, approval, and audit controls each time. **Depends on**: Product Knowledge & Contextual Help, Support Diagnostic Pack, Decision Pack Contract & Approval Workflow, Product Usage & Adoption Telemetry, Plans / Entitlements & Billing Readiness, Operational Controls & Feature Flags, Security Trust Pack Light, audit log foundation, and workspace/RBAC isolation. **Scope direction**: Build the foundation before broad AI features: AI use case registry, AI provider registry, workspace AI policy, AI data classification, AI context builders, AI policy gate, AI budget gate, AI result store/cache, AI usage ledger, and AI audit trail. Start with local/private and customer-hosted model compatibility; keep external provider support optional and explicit. +**Priority note**: This remains strategic, but it should stay behind current customer-review productization, decision convergence, compliance mapping, governance packaging, and compare/promotion gaps. **Core principles**: - AI is never called directly from feature code; every AI action goes through governed use cases, policy gates, budget gates, context builders, provider adapters, cache/result storage, and audit trails @@ -212,7 +256,7 @@ ### AI-Assisted Customer Operations AI-assisted customer operations layer for support, reviews, summaries, release communication, and customer-facing explanations, explicitly bounded by private AI execution policy, human approval, and product auditability. **Goal**: Use AI to prepare, summarize, classify, and draft customer operations work while keeping tenant-changing actions, customer commitments, legal statements, and external communications under human approval. **Why it matters**: TenantPilot can stay lean only if support, customer reviews, release communication, and diagnostics are structured enough for AI assistance without becoming ungoverned automation or uncontrolled public-model data processing. -**Depends on**: Private AI Execution & Usage Governance Foundation, Product Knowledge & Contextual Help, Support Diagnostic Pack, In-App Support Request, StoredReports / EvidenceItems, Findings workflow maturity, release-note discipline, and company support-desk structure. +**Depends on**: Private AI Execution Governance Foundation, Product Knowledge & Contextual Help, Support Diagnostic Pack, In-App Support Request, StoredReports / EvidenceItems, Findings workflow maturity, release-note discipline, and company support-desk structure. **Scope direction**: Start with AI-generated support summaries, finding explanations, tenant review summaries, diagnostic summaries, release-note drafts, and support-response drafts. Prefer local/private execution for tenant/customer data. Avoid autonomous tenant remediation, automatic risk acceptance, automatic legal commitments, or customer-facing messages without review. ### Decision-Based Operating Foundations @@ -221,12 +265,14 @@ ### Decision-Based Operating Foundations **Why it matters**: Governance inboxes, actionable alerts, and later autonomous-governance features will fail if they land on top of detail-heavy, entity-first navigation. This is the UX/product prerequisite layer for the later MSP Portfolio OS direction. **Depends on**: Current constitution and action-surface hardening, operator-truth work, existing navigation/context specs. **Scope direction**: First the constitution/rule delta, then a surface / IA classification of current product surfaces, then bounded retrofits that demote detail-first flows behind progressive disclosure instead of creating more top-level pages. +**Concrete next slice**: `Governance Decision Surface Convergence` is the repo-based follow-up. Do not reopen the first Governance Inbox as a greenfield concept. ### MSP Portfolio & Operations (Multi-Tenant) Multi-tenant health dashboard, SLA/compliance reports (PDF), cross-tenant troubleshooting center. **Source**: 0800-future-features brainstorming, identified as highest priority pillar. **Prerequisites**: Decision-Based Operating Foundations, Cross-tenant compare (Spec 043 — draft only). **Later expansion**: portfolio operations should eventually include a cross-tenant findings workboard once tenant-level inbox and intake flows are stable. +**Concrete next slice**: `Cross-Tenant Compare & Promotion v1` is the repo-based move from portfolio visibility toward portfolio action. ### Human-in-the-Loop Autonomous Governance (Microsoft-first, Provider-extensible Decision-Based Operating) Continuous detection, triage, decision drafting, approval-driven execution, and closed-loop evidence for governance actions across the Microsoft-first workspace portfolio, while keeping the decision model provider-extensible for later non-Microsoft domains. @@ -260,12 +306,12 @@ ### PSA / Ticketing Handoff Outbound handoff from findings into external service-desk or PSA systems with visible `ticket_ref` linkage and auditable "ticket created/linked" events. **Scope direction**: start with one-way handoff and internal visibility, not full bidirectional sync or full ITSM modeling. -### Compliance Readiness & Executive Review Packs -On-demand review packs that combine governance findings, accepted risks, evidence, baseline/drift posture, canonical control coverage, and key security signals into one coherent deliverable. CIS-aligned baseline libraries plus NIS2-/BSI-oriented readiness views depend on the Canonical Control Catalog and Evidence-to-Control mapping and remain explicitly without certification claims. Executive / CISO / customer-facing report surfaces alongside operator-facing detail views. Exportable auditor-ready and management-ready outputs. -**Goal**: Make TenantPilot sellable as an MSP-facing governance and review platform for German midmarket and compliance-oriented customers who want structured tenant reviews and management-ready outputs on demand. -**Why it matters**: Turns existing governance data into a clear customer-facing value proposition. Strengthens MSP sales story beyond backup and restore. Creates a repeatable "review on demand" workflow for quarterly reviews, security health checks, and audit preparation. -**Depends on**: Canonical Control Catalog Foundation, Evidence-to-Control mapping, StoredReports / EvidenceItems foundation, Tenant Review runs, Customer Review Workspace / Read-only View, Findings + Risk Acceptance workflow, evidence / signal ingestion, export pipeline maturity. -**Scope direction**: Start as compliance readiness and review packaging. Avoid formal certification language or promises. Position as governance evidence, management reporting, and audit preparation. +### Compliance Evidence Mapping v1 +Versioned mapping layer that connects technical findings, accepted risks, evidence, and review outcomes to customer-safe control and readiness views without certification claims. +**Goal**: Translate existing governance truth into control- and audit-ready language for German midmarket and compliance-oriented customers while keeping technical findings clearly separate from regulatory interpretation. +**Why it matters**: Canonical controls and evidence are already repo-real foundations. The missing value is not another control catalog, but a customer-safe mapping layer that explains why a finding matters, what evidence exists, and which control or readiness statement it supports. +**Depends on**: Canonical Control Catalog Foundation, Evidence-to-Control mapping, StoredReports / EvidenceItems foundation, Tenant Review runs, Customer Review Workspace Productization, Findings + Risk Acceptance workflow, and export maturity. +**Scope direction**: Start with versioned control interpretations plus one bounded overlay layer. Avoid certification promises, legal guarantees, or framework-specific deep branching inside the platform core. **Modeling principle**: Compliance and governance requirements are modeled through a framework-neutral canonical control catalog plus technical interpretations and versioned framework overlays, not as separate technical object worlds per framework. Readiness views, evidence packs, baseline libraries, and auditor outputs are generated from that shared domain model. **Layering**: @@ -280,6 +326,13 @@ ### Compliance Readiness & Executive Review Packs - Keep ISO / COBIT semantics in governance-assurance and ISMS-oriented overlays rather than introducing a second technical control universe - Avoid framework-specific one-off reports that bypass the common evidence, findings, exception, and export pipeline +### Governance-as-a-Service Packaging v1 +Recurring governance deliverables for MSPs and customer stakeholders built on review packs, accepted risks, evidence, and control mapping. +**Goal**: Let MSPs deliver monthly or quarterly governance packages without manual screenshot decks, Excel exports, or ad-hoc PowerPoint work. +**Why it matters**: This is the commercial layer that turns already-strong review, evidence, and accepted-risk foundations into a repeatable MSP revenue surface. TenantPilot should sell not only truth capture, but calm customer-safe governance reporting. +**Depends on**: Customer Review Workspace Productization, Compliance Evidence Mapping v1, Review Packs, StoredReports / EvidenceItems, Findings + Risk Acceptance workflow, export pipeline maturity, localization, and entitlements. +**Scope direction**: Start with executive summary, top findings, accepted risks, open decisions, evidence links, management-ready review-pack export, and bounded MSP branding. Avoid CRM/newsletter tooling, PSA replacement, or raw operator-data dumps as the default output. + ### Entra Role Governance Expand TenantPilot's governance coverage into Microsoft Entra role definitions and assignments as a first-class identity administration surface. **What it means**: Inventory and visibility for built-in and custom role definitions. Visibility into role assignments and governance-relevant changes. Review-ready representation of identity administration posture. @@ -331,15 +384,15 @@ ## Infrastructure & Platform Debt | Item | Risk | Status | |------|------|--------| | No explicit company automation roadmap linkage | Risk that sales, support, billing, legal, and customer communication become founder-only manual work | Covered by Solo-Founder SaaS Automation & Operating Readiness | -| No product-level entitlement foundation yet | Later pricing, trial, retention, export, user, and tenant limits may require invasive retrofits | Covered by Product Scalability & Self-Service Foundation | +| No shared lifecycle taxonomy for workspace, tenant, managed-object, retention, export, purge, and restoreability states | Local fixes such as ghost-policy handling, workspace deactivation, tenant removal, retention, or purge can create inconsistent deletion semantics and audit gaps | Covered by Workspace, Tenant & Managed Object Lifecycle Governance candidate | | No structured support diagnostic bundle yet | Support cases require manual context gathering across tenants, runs, findings, providers, and reports | Covered by Product Scalability & Self-Service Foundation | | No formal security trust pack yet | Enterprise sales and customer security reviews require repeated manual explanations | Covered by Solo-Founder SaaS Automation & Operating Readiness | | No product usage/adoption telemetry yet | Founder cannot see onboarding drop-off, feature adoption, trial health, or support-triggering surfaces without manual investigation | Covered by Additional Solo-Founder Scale Guardrails | | No customer health score yet | Churn, inactive customers, stale reviews, unhealthy provider connections, and unresolved high-risk findings may be noticed too late | Covered by Additional Solo-Founder Scale Guardrails | | No explicit operational controls / feature flags lane | Incidents or risky features may require code changes or manual database intervention instead of safe operator controls | Covered by Additional Solo-Founder Scale Guardrails | -| No private AI execution foundation yet | Future AI features may call model providers directly, leak tenant context, become hard to audit, or require rewrites to support local/private models | Covered by Private AI Execution & Usage Governance Foundation | -| No AI usage budgeting / cost governance yet | AI-assisted summaries, decision packs, reviews, and support workflows may create uncontrolled compute/API costs and queue pressure | Covered by Private AI Execution & Usage Governance Foundation | -| No AI data classification / context-builder boundary yet | Raw provider payloads, personal data, or customer-confidential tenant context could be over-shared with models instead of sanitized purpose-specific context | Covered by Private AI Execution & Usage Governance Foundation | +| No private AI execution foundation yet | Future AI features may call model providers directly, leak tenant context, become hard to audit, or require rewrites to support local/private models | Covered by Private AI Execution Governance Foundation | +| No AI usage budgeting / cost governance yet | AI-assisted summaries, decision packs, reviews, and support workflows may create uncontrolled compute/API costs and queue pressure | Covered by Private AI Execution Governance Foundation | +| No AI data classification / context-builder boundary yet | Raw provider payloads, personal data, or customer-confidential tenant context could be over-shared with models instead of sanitized purpose-specific context | Covered by Private AI Execution Governance Foundation | | No no-customization governance yet | Customer-specific requests can silently turn the product into consulting work and create hidden maintenance obligations | Covered by Additional Solo-Founder Scale Guardrails | | No business-continuity / founder-backup plan yet | Solo-founder operations create continuity risk for incidents, illness, vacation, access recovery, and customer trust | Covered by Additional Solo-Founder Scale Guardrails | | No `.env.example` in repo | Onboarding friction | Open | @@ -356,7 +409,7 @@ ## Priority Ranking (from Product Brainstorming) 1. Product Scalability & Self-Service Foundation 2. Product Usage, Customer Health & Operational Controls -3. Private AI Execution & Usage Governance Foundation +3. Private AI Execution Governance Foundation 4. Decision-Based Operating / Governance Inbox 5. MSP Portfolio + Alerting 6. Drift + Approval Workflows @@ -373,6 +426,7 @@ ## How to use this file - **Big product and operating themes** live here. - **Concrete spec candidates** → see [spec-candidates.md](spec-candidates.md) +- **Lifecycle / deletion / retention work must be taxonomy-first**: do not promote narrow ghost-policy, workspace deletion, tenant deletion, purge, or retention specs until the shared Workspace, Tenant & Managed Object Lifecycle Governance candidate defines the platform semantics. - **Company automation / solo-founder operating items** live here as strategic tracks first; only product-impacting or repeatable engineering work should become spec candidates. - **Solo-founder guardrails** should remain visible even when they are not immediate product specs, because they define what must become measurable, controllable, delegable, or documented before customer volume grows. - **Governance positioning is Microsoft-first, provider-extensible**: roadmap language should keep the initial product scope focused on Microsoft tenant governance while avoiding unnecessary Microsoft-only coupling in platform-level abstractions. diff --git a/docs/product/spec-candidates.md b/docs/product/spec-candidates.md index a7fd663e..a07e3dcd 100644 --- a/docs/product/spec-candidates.md +++ b/docs/product/spec-candidates.md @@ -1,9 +1,14 @@ # 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-28 +> **Last reviewed**: 2026-04-30 > **Basis**: `implementation-ledger.md`, `roadmap.md`, current `specs/` truth --- @@ -19,70 +24,115 @@ ## Candidate Rules - 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 v1 +### Customer Review Workspace Productization v1 - **Priority**: P0 -- **Why this stays active**: The repo already has strong internal review foundations: tenant reviews, evidence snapshots, review packs, redaction paths, entitlements, audit, and RBAC-aware surfaces. What is still missing is the customer-safe read-only consumption layer that turns those internal assets into a clearly sellable review product. -- **Roadmap relationship**: R2 completion / customer-facing review consumption. +- **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` - - `EvidenceSnapshot` - `ReviewPack` + - `EvidenceSnapshot` + - `Finding` + - accepted risks / exceptions workflow - existing redaction behavior + - stored reports and canonical control catalog foundations - workspace entitlements - - tenant/workspace RBAC and audit foundations + - tenant/workspace RBAC, audit, localization, and workspace-isolation foundations - **Scope**: - - customer-safe read-only workspace or view for latest review state - - latest findings and accepted risks in customer-safe form - - review-pack download surface with existing redaction rules - - explicit absence of admin or remediation actions - - clear authorization boundaries for customer and read-only viewers + - 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**: - - admin settings - - remediation actions - - raw operator diagnostics - - a broader customer portal rewrite - - billing or contract workflows + - 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**: - - an authorized customer or read-only actor can open the review workspace - - latest review status, accepted risks, and key findings are visible without exposing admin controls - - review-pack downloads respect existing redaction and entitlement rules + - 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 - - audit-sensitive or operator-only data is not exposed through this surface -- **Notes**: This is the clearest repo-derived blocker between current internal review strength and a cleaner sellable release. + - 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 -### Decision-Based Governance Inbox v1 +### Governance Decision Surface Convergence - **Priority**: P1 -- **Why this stays active**: Findings, alerts, operation runs, review-pack generation, and portfolio triage already exist, but operators still work across several surfaces. The next maturity step is a single decision-oriented work surface, not more raw detail pages. +- **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 operator-facing inbox for high-signal governance work - - grouping or prioritization across findings, alerts, stale runs, and related attention signals - - direct action links into compare, finding review, review-pack generation, or triage paths - - auditable state changes such as snooze, assign, or acknowledge where already supported + - 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**: - - one surface shows prioritized governance work from more than one underlying signal family - - actions route to existing product truth rather than duplicating state + - 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 and authorization boundaries -- **Notes**: Important, but not a P0 release blocker while Customer Review Workspace is still missing. + - 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 @@ -112,32 +162,6 @@ ### Cross-Tenant Compare and Promotion v1 - audit trail exists for compare and promotion entry points - the slice refreshes or narrows Spec 043 instead of reopening it as a vague ambition -### Localization v1 -- **Priority**: P1 -- **Why this stays active**: The repo and roadmap both indicate this is still absent. It is not a backend foundation gap; it is a product maturity gap that will get more expensive as the governance surface grows. -- **Roadmap relationship**: R1.9 Platform Localization v1. -- **Dependencies**: - - existing status and terminology catalogs - - contextual help boundaries - - notification and UI copy inventory on critical surfaces - - locale resolution rules for workspace, user, and system context -- **Scope**: - - `de` and `en` on core governance surfaces - - locale resolution order and fallback behavior - - locale-aware formatting for dates, times, and numbers - - stable machine and export formats that remain non-localized -- **Non-scope**: - - public website localization - - broad documentation translation - - retrospective translation of every legacy free-text record - - marketing copy systems -- **Acceptance criteria**: - - core navigation, dashboard, findings, baseline compare, alerts, and operations surfaces support `de` and `en` - - no raw translation keys appear on critical UI paths - - fallback to English is controlled and predictable - - locale-aware formatting does not affect audit or export truth - - targeted regression coverage exists for fallback and key critical flows - ### 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. @@ -256,6 +280,63 @@ ### Commercial Entitlements and Billing-State Maturity - 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. @@ -292,7 +373,55 @@ ## 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. -- `Policy Lifecycle / Ghost Policies`: still a valid gap, but not ahead of Customer Review Workspace or Cross-Tenant Compare. +### 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. @@ -312,6 +441,8 @@ ## Promoted to Spec - 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`) @@ -353,4 +484,5 @@ ## Superseded / Removed From Active Queue - `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. diff --git a/docs/research/admin-canonical-tenant-rollout.md b/docs/research/admin-canonical-tenant-rollout.md index d2201fa3..16475051 100644 --- a/docs/research/admin-canonical-tenant-rollout.md +++ b/docs/research/admin-canonical-tenant-rollout.md @@ -1,5 +1,10 @@ # Admin Canonical Tenant Rollout +> **Status:** Historical +> **Last reviewed:** 2026-04-30 +> **Use for:** Historical rollout notes for the admin canonical tenant transition +> **Do not use for:** Current implementation truth without checking the corresponding specs and code + ## Purpose Spec 136 completes the workspace-admin canonical tenant rule across admin-visible and admin-reachable shared surfaces. Workspace-admin requests under `/admin/...` resolve tenant context through `App\Support\OperateHub\OperateHubShell::activeEntitledTenant(request())`. Tenant-panel requests under `/admin/t/{tenant}/...` keep panel-native tenant semantics. diff --git a/docs/research/canonical-tenant-context-resolution.md b/docs/research/canonical-tenant-context-resolution.md index 13567c8d..588538de 100644 --- a/docs/research/canonical-tenant-context-resolution.md +++ b/docs/research/canonical-tenant-context-resolution.md @@ -1,5 +1,10 @@ # Canonical Tenant Context Resolution +> **Status:** Historical +> **Last reviewed:** 2026-04-30 +> **Use for:** Historical context for the canonical tenant resolution rule and exception model +> **Do not use for:** Current path truth or current panel behavior without repo verification + ## Canonical Rule - Tenant-panel and tenant-scoped flows keep panel-native tenant semantics through `Filament::getTenant()` / `Tenant::current()`. diff --git a/docs/research/filament-v5-notes.md b/docs/research/filament-v5-notes.md index c7dc91ad..2a8b83b6 100644 --- a/docs/research/filament-v5-notes.md +++ b/docs/research/filament-v5-notes.md @@ -1,5 +1,10 @@ # SECTION A — FILAMENT V5 NOTES (BULLETS + SOURCES) +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Filament v5 reference notes and framework-specific decision checks when local behavior is uncertain +> **Do not use for:** Assuming local implementation already follows every note without repo verification + ## Versioning & Base Requirements - Rule: Filament v5 requires Livewire v4.0+. When: Always when installing/upgrading Filament v5. When NOT: Never target Livewire v3 in a v5 codebase. diff --git a/docs/research/golden-master-baseline-drift-deep-analysis.md b/docs/research/golden-master-baseline-drift-deep-analysis.md index c548e0b1..e5cbe14f 100644 --- a/docs/research/golden-master-baseline-drift-deep-analysis.md +++ b/docs/research/golden-master-baseline-drift-deep-analysis.md @@ -1,5 +1,10 @@ # Golden Master / Baseline Drift — Deep Settings-Drift (Content-Fidelity) Analysis +> **Status:** Reference +> **Last reviewed:** 2026-04-30 +> **Use for:** Deep drift-engine research, architectural rationale, and fidelity trade-off analysis +> **Do not use for:** Current implementation truth or roadmap priority without repo verification +> > Enterprise Research Report for TenantAtlas / TenantPilot > Date: 2025-07-15 > Scope: Architecture, code evidence, implementation proposal diff --git a/docs/research/m365-policy-coverage-gap-analysis.md b/docs/research/m365-policy-coverage-gap-analysis.md index 85d6a610..ef8f1c7c 100644 --- a/docs/research/m365-policy-coverage-gap-analysis.md +++ b/docs/research/m365-policy-coverage-gap-analysis.md @@ -1,5 +1,10 @@ # TenantPilot – M365 Policy Coverage Gap Analysis +> **Status:** Reference +> **Last reviewed:** 2026-04-30 +> **Use for:** Coverage expansion planning and M365 policy gap research +> **Do not use for:** Current productization priority order without roadmap review + **Date:** 2026-03-07 **Author:** Gap Analysis (Automated Deep Research) **Scope:** Security, Governance & Baseline-relevante Policy-Familien über Microsoft 365 hinweg diff --git a/docs/security/REDACTION_AUDIT_REPORT.md b/docs/security/REDACTION_AUDIT_REPORT.md index e3aa36ea..54753c60 100644 --- a/docs/security/REDACTION_AUDIT_REPORT.md +++ b/docs/security/REDACTION_AUDIT_REPORT.md @@ -1,5 +1,10 @@ # Redaction / Masking / Sanitizing — Codebase Audit Report +> **Status:** Needs Review +> **Last reviewed:** 2026-04-30 +> **Use for:** Security and data-integrity audit findings around redaction behavior and masking risks +> **Do not use for:** Assuming every finding is still open without verifying the current codebase + **Auditor:** Security + Data-Integrity Codebase Auditor **Date:** 2026-03-06 **Scope:** Entire TenantAtlas repo (excluding `vendor/`, `node_modules/`, compiled views) diff --git a/docs/strategy/domain-coverage.md b/docs/strategy/domain-coverage.md index f9de0475..7b7c8531 100644 --- a/docs/strategy/domain-coverage.md +++ b/docs/strategy/domain-coverage.md @@ -1,5 +1,10 @@ # Domain Coverage Map +> **Status:** Reference +> **Last reviewed:** 2026-04-30 +> **Use for:** Domain classification, planning boundaries, and evaluating which Microsoft domains fit which TenantPilot product primitives +> **Do not use for:** Current release priority or implementation truth without roadmap, spec, and code verification +> > Canonical classification of Microsoft domains for TenantPilot platform planning. > This document defines which domains receive which product primitives and why. diff --git a/docs/strategy/product-vision.md b/docs/strategy/product-vision.md index e69de29b..d72d6b61 100644 --- a/docs/strategy/product-vision.md +++ b/docs/strategy/product-vision.md @@ -0,0 +1,27 @@ +# TenantPilot Product Vision + +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Long-term product direction and roadmap alignment +> **Do not use for:** Implementation truth without repo verification + +TenantPilot is a Governance-of-Record platform for Microsoft tenant governance, evidence-first reviews, MSP portfolio operations, Intune backup/restore, auditability, customer-safe review consumption, and decision-based governance workflows. + +TenantPilot is not a generic Microsoft admin mirror. + +## Core Principles + +- OperationRun Truth Layer +- Evidence-first Reporting +- Customer-safe Review Consumption +- Decision-first, diagnostics-second, evidence-third UX +- Capability-first RBAC +- Workspace-first Multi-Tenancy +- Provider-extensible Architecture +- Auditability +- MSP Portfolio Governance +- Enterprise SaaS UX over admin-tool sprawl + +## Strategic Direction + +The platform should prioritize productization of existing foundations before adding isolated technical coverage. New coverage should strengthen reviews, evidence, findings, baselines, governance inbox, or MSP portfolio workflows. diff --git a/docs/strategy/website-working-contract.md b/docs/strategy/website-working-contract.md index 5166933d..3500c432 100644 --- a/docs/strategy/website-working-contract.md +++ b/docs/strategy/website-working-contract.md @@ -1,5 +1,10 @@ # Website Working Contract +> **Status:** Reference +> **Last reviewed:** 2026-04-30 +> **Use for:** Guardrails around keeping `apps/website` an intentionally independent track +> **Do not use for:** Introducing new runtime coupling without explicit contract changes and repo verification +> > Guardrails for evolving `apps/website` as an independently evolvable track in the current repository. > This document is repo-truth-based and describes the currently verified state, not a speculative future architecture. diff --git a/docs/ui/action-surface-contract.md b/docs/ui/action-surface-contract.md index 77ef2fe9..3c037c9c 100644 --- a/docs/ui/action-surface-contract.md +++ b/docs/ui/action-surface-contract.md @@ -1,5 +1,10 @@ # Action surface contract +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Action placement and affordance rules for Filament resources, pages, and relation managers +> **Do not use for:** Skipping authorization, confirmation, or resource-specific UX review + This project enforces a small “action surface contract” for Filament Resources / Pages / RelationManagers to keep table UIs consistent, quiet, and safe. ## Inspect affordance (required) diff --git a/docs/ui/filament-table-standard.md b/docs/ui/filament-table-standard.md index 5441bc2f..15ef4bae 100644 --- a/docs/ui/filament-table-standard.md +++ b/docs/ui/filament-table-standard.md @@ -1,5 +1,10 @@ # Filament Table Standard +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Standard list-surface rules for production Filament tables +> **Do not use for:** Overriding product-specific needs without an explicit documented exception + ## Standard TenantPilot standardizes production Filament list surfaces with a convention-first model: diff --git a/docs/ui/operator-ux-surface-standards.md b/docs/ui/operator-ux-surface-standards.md index c0a67712..d555286a 100644 --- a/docs/ui/operator-ux-surface-standards.md +++ b/docs/ui/operator-ux-surface-standards.md @@ -1,5 +1,10 @@ # Operator UX & Surface Standards +> **Status:** Active +> **Last reviewed:** 2026-04-30 +> **Use for:** Audience, language, disclosure, and operator-surface rules for product UX +> **Do not use for:** Treating internal implementation structure as product IA or redefining constitution terms locally + This document defines the binding audience-and-surface contract for TenantPilot. It establishes: diff --git a/docs/ui/shared-diff-presentation-foundation.md b/docs/ui/shared-diff-presentation-foundation.md index 0112ea92..a7e2c16e 100644 --- a/docs/ui/shared-diff-presentation-foundation.md +++ b/docs/ui/shared-diff-presentation-foundation.md @@ -1,5 +1,10 @@ # Shared Diff Presentation Foundation +> **Status:** Reference +> **Last reviewed:** 2026-04-30 +> **Use for:** Reusable presentation rules for simple before/after comparison surfaces +> **Do not use for:** Domain diff logic, data fetching, or token-level compare behavior + ## Purpose Use the shared diff presentation foundation when a screen already has simple before/after data and needs: diff --git a/spechistory/spec.md b/spechistory/spec.md index 1ac2a6bb..d291eea0 100644 --- a/spechistory/spec.md +++ b/spechistory/spec.md @@ -1,5 +1,10 @@ # Feature Specification: TenantPilot v1 +> **Status:** Historical +> **Last reviewed:** 2026-04-30 +> **Use for:** Early product-history context and original v1 framing +> **Do not use for:** Current implementation truth, current roadmap priority, or current spec structure without repo verification + **Feature Branch**: `tenantpilot-v1` **Created**: 2025-12-10 **Status**: Draft diff --git a/specs/003-settings-catalog-readable/IMPLEMENTATION_STATUS.md b/specs/003-settings-catalog-readable/IMPLEMENTATION_STATUS.md index e3344649..a704fe2d 100644 --- a/specs/003-settings-catalog-readable/IMPLEMENTATION_STATUS.md +++ b/specs/003-settings-catalog-readable/IMPLEMENTATION_STATUS.md @@ -1,5 +1,10 @@ # Feature 003: Implementation Status Report +> **Status:** Needs Review +> **Last reviewed:** 2026-04-30 +> **Use for:** Historical implementation-progress context for Spec 003 +> **Do not use for:** Proof that the remaining manual verification or tests were completed in the current repo state + ## Executive Summary **Status**: ✅ **Core Implementation Complete** (Phases 1-5) diff --git a/specs/003-settings-catalog-readable/MANUAL_TESTING_CHECKLIST.md b/specs/003-settings-catalog-readable/MANUAL_TESTING_CHECKLIST.md index 5b98e306..72332835 100644 --- a/specs/003-settings-catalog-readable/MANUAL_TESTING_CHECKLIST.md +++ b/specs/003-settings-catalog-readable/MANUAL_TESTING_CHECKLIST.md @@ -1,5 +1,10 @@ # Feature 003: Manual Testing Checklist +> **Status:** Reference +> **Last reviewed:** 2026-04-30 +> **Use for:** Manual verification scenarios for Spec 003 if that surface needs targeted re-checks +> **Do not use for:** Proof that manual testing was executed or passed in the current branch + ## Prerequisites 1. **Start the application:** diff --git a/specs/feat/700-bugfix/plan.md b/specs/feat/700-bugfix/plan.md deleted file mode 100644 index 4d3427dc..00000000 --- a/specs/feat/700-bugfix/plan.md +++ /dev/null @@ -1,26 +0,0 @@ -# Implementation Plan: BaselineCompareRun model bugfix - -**Branch**: `feat/700-bugfix` | **Date**: 2026-02-20 | **Spec**: `specs/feat/700-bugfix/spec.md` - -## Summary - -Fix runtime crash caused by a missing Eloquent model referenced by a Filament dashboard widget. - -## Technical Context - -- PHP 8.4.x, Laravel 12 -- Filament v5, Livewire v4 -- PostgreSQL (Sail locally) -- Tests: Pest v4 (`vendor/bin/sail artisan test --compact`) - -## Approach - -1. Identify intended storage for baseline compare runs: - - If a `baseline_compare_runs` table already exists, implement `App\Models\BaselineCompareRun` mapped to it. - - If not, align the widget to an existing persistence type (likely `OperationRun`) without changing UX. -2. Add a regression test that exercises the tenant dashboard route and asserts a successful response. -3. Run Pint on dirty files and run the focused test. - -## Risks - -- Introducing a new model without an existing table could still fail at runtime. Prefer minimal, compatibility-first changes. diff --git a/specs/feat/700-bugfix/spec.md b/specs/feat/700-bugfix/spec.md deleted file mode 100644 index 9e903a0c..00000000 --- a/specs/feat/700-bugfix/spec.md +++ /dev/null @@ -1,29 +0,0 @@ -# Bugfix Specification: BaselineCompareRun missing model - -**Branch**: `feat/700-bugfix` -**Created**: 2026-02-20 -**Status**: Ready - -## Problem - -Navigating to the tenant dashboard (`/admin/t/{tenant}`) throws an Internal Server Error: - -- `Class "App\Models\BaselineCompareRun" not found` - -The stack trace points to the dashboard widget `app/Filament/Widgets/Dashboard/BaselineCompareNow.php`. - -## Goal - -- Tenant dashboard loads successfully. -- Baseline compare widget can safely query baseline compare run state without a fatal error. - -## Non-Goals - -- No UX redesign. -- No new baseline-compare workflow features beyond restoring runtime stability. - -## Acceptance Criteria - -- Visiting `/admin/t/{tenant}` does not throw a 500. -- The widget renders even when there are no baseline compare runs. -- A focused automated test covers the regression. diff --git a/specs/feat/700-bugfix/tasks.md b/specs/feat/700-bugfix/tasks.md deleted file mode 100644 index fc830a11..00000000 --- a/specs/feat/700-bugfix/tasks.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -description: "Tasks for feat/700-bugfix (BaselineCompareRun missing model)" ---- - -# Tasks: feat/700-bugfix - -**Input**: `specs/feat/700-bugfix/spec.md` and `specs/feat/700-bugfix/plan.md` - -## Setup -- [X] T001 Confirm whether baseline compare runs table exists - -## Tests (TDD) -- [X] T010 Add regression test for tenant dashboard (no 500) - -## Core -- [X] T020 Fix missing BaselineCompareRun reference (model or widget) - -## Validation -- [X] T030 Run Pint (dirty) -- [X] T040 Run focused tests via Sail