What’s included • specs/039-inventory-program/ — program/epic overview (vision + phased plan) • specs/041-inventory-ui/ — UI skeleton (Inventory list, Coverage, Sync Runs) • specs/042-inventory-dependencies-graph/ — dependency graph skeleton (assignments/filters/scope tags → later) • specs/043-cross-tenant-compare-and-promotion/ — compare/promotion skeleton (read-only first; writes gated later) • specs/044-drift-mvp/ — drift detection skeleton (read-only by default) Why We need a clear, spec-first structure for: • separating Inventory (“last observed”) from Snapshots/Backups (immutable) • scaling to MSP / multi-tenant workflows (portfolio, compare, monitoring) • making future modules (security suite, drift, promotion) consistent with the Constitution (fail-safe, auditability, contract-driven Graph) Scope / Non-goals (this PR) • No implementation tasks executed • No DB migrations, services, jobs, or UI changes • No changes to Graph contracts or supported policy types Review focus • Naming/numbering and folder structure (spec.md, plan.md, tasks.md for each spec) • Scope boundaries and non-goals across 041–044 • Alignment with Constitution principles (tenant isolation, read-only default for analysis, explicit gating for high-risk writes) Follow-up (next PRs) • Spec 040: Inventory Core (data model + selection hash + missing semantics + NFRs + tests) • Implementation PRs will be split per spec (040 → 041 → 042/043/044) ⸻ Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local> Reviewed-on: #42
2.0 KiB
2.0 KiB
Feature Specification: Cross-tenant Compare and Promotion
Feature Branch: feat/043-cross-tenant-compare-and-promotion
Created: 2026-01-07
Status: Draft
Purpose
Enable safe cross-tenant comparison of inventory and, optionally, controlled promotion workflows.
Comparison is read-only by default. Any write/promotion behavior must be explicitly gated, audited, and separately authorized.
User Scenarios & Testing
Scenario 1: Compare two tenants (read-only)
- Given the operator has access to Tenant A and Tenant B
- When they select two tenants and a set of policy types
- Then they can see differences in presence and key metadata
Scenario 2: Compare with a stable reference
- Given a reference selection scope
- When the operator runs comparison
- Then results are stable and reproducible for that scope
Scenario 3: Promotion is explicitly gated (optional)
- Given promotion is enabled by policy
- When the operator initiates promotion
- Then the system requires explicit confirmation and records an audit event
Functional Requirements
- FR1: Support selecting two tenants within authorized scope.
- FR2: Provide read-only diff views based on inventory metadata and stable identifiers.
- FR3: Provide exportable comparison results.
- FR4: If promotion is included:
- require explicit enablement
- require explicit confirmation per operation
- record audit logs
- support dry-run/preview
Non-Functional Requirements
- NFR1: Enforce tenant isolation and least privilege across tenant selection and data access.
- NFR2: Comparison must not expose secrets or unsafe payload fields.
Success Criteria
- SC1: Operators can identify which tenant differs for a given policy type in under 2 minutes.
- SC2: Read-only comparisons are reproducible when run again with the same scope.
Out of Scope
- Bulk remediation without preview/confirmation.
Related Specs
- Program:
specs/039-inventory-program/spec.md - Core:
specs/040-inventory-core/spec.md - Drift:
specs/044-drift-mvp/spec.md