|
|
|
|
@ -1,24 +1,63 @@
|
|
|
|
|
<!--
|
|
|
|
|
Sync Impact Report
|
|
|
|
|
|
|
|
|
|
- Version change: 1.0.0 → 1.1.0
|
|
|
|
|
- Modified principles:
|
|
|
|
|
- Safety-First Restore → Read/Write Separation by Default
|
|
|
|
|
- Auditability & Tenant Isolation → Tenant Isolation is Non-negotiable (+ Least Privilege)
|
|
|
|
|
- Graph Abstraction & Contracts → Single Contract Path to Graph
|
|
|
|
|
- Added principles:
|
|
|
|
|
- Inventory-first, Snapshots-second
|
|
|
|
|
- Deterministic Capabilities
|
|
|
|
|
- Automation must be Idempotent & Observable
|
|
|
|
|
- Data Minimization & Safe Logging
|
|
|
|
|
- Templates requiring updates:
|
|
|
|
|
- ✅ .specify/templates/plan-template.md
|
|
|
|
|
- ✅ .specify/templates/tasks-template.md
|
|
|
|
|
- ✅ .specify/templates/spec-template.md
|
|
|
|
|
- Follow-up TODOs:
|
|
|
|
|
- TODO(DELETED_STATUS): Keep “deleted” reserved for Feature 900 / Policy Lifecycle.
|
|
|
|
|
-->
|
|
|
|
|
|
|
|
|
|
# TenantPilot Constitution
|
|
|
|
|
|
|
|
|
|
## Core Principles
|
|
|
|
|
|
|
|
|
|
### Safety-First Restore
|
|
|
|
|
- Any destructive action MUST support preview/dry-run, explicit confirmation, and a clear pre-execution summary.
|
|
|
|
|
- High-risk policy types default to `preview-only` restore unless explicitly enabled by a feature spec + tests + checklist.
|
|
|
|
|
- Restore must be defensive: validate inputs, detect conflicts, allow selective restore, and record outcomes per item.
|
|
|
|
|
### Inventory-first, Snapshots-second
|
|
|
|
|
- All modules MUST operate primarily on Inventory as “last observed” state.
|
|
|
|
|
- Inventory is the source of truth for what TenantPilot last observed; Microsoft Intune remains the external truth.
|
|
|
|
|
- Snapshots/Backups MUST be explicit actions (manual or scheduled) and MUST remain immutable.
|
|
|
|
|
|
|
|
|
|
### Auditability & Tenant Isolation
|
|
|
|
|
- Every operation is tenant-scoped and MUST write an audit log entry (no secrets, no tokens).
|
|
|
|
|
- Snapshots are immutable JSONB and MUST remain reproducible (who/when/what/source tenant).
|
|
|
|
|
### Read/Write Separation by Default
|
|
|
|
|
- Analysis, reporting, and monitoring features MUST be read-only by default.
|
|
|
|
|
- Any write/change function (restore, remediation, promotion) MUST include preview/dry-run, explicit confirmation, audit logging, and tests.
|
|
|
|
|
- High-risk policy types default to `preview-only` restore unless explicitly enabled by a feature spec + tests.
|
|
|
|
|
|
|
|
|
|
### Graph Abstraction & Contracts
|
|
|
|
|
### Single Contract Path to Graph
|
|
|
|
|
- All Microsoft Graph calls MUST go through `GraphClientInterface`.
|
|
|
|
|
- Contract assumptions are config-driven (`config/graph_contracts.php`); do not hardcode endpoints in feature code.
|
|
|
|
|
- Unknown/missing policy types MUST fail safe (preview-only / no Graph calls) rather than calling `deviceManagement/{type}`.
|
|
|
|
|
- Object types and endpoints MUST be modeled first in the contract registry (`config/graph_contracts.php`).
|
|
|
|
|
- Feature code MUST NOT hardcode “quick endpoints” or bypass contracts.
|
|
|
|
|
- Unknown/missing policy types MUST fail safe (preview-only / no Graph calls) rather than guessing endpoints.
|
|
|
|
|
|
|
|
|
|
### Least Privilege
|
|
|
|
|
### Deterministic Capabilities
|
|
|
|
|
- Backup/restore/risk/support flags MUST be derived deterministically from config/contracts via a Capabilities Resolver.
|
|
|
|
|
- The resolver output MUST be programmatically testable (snapshot/golden tests) so config changes cannot silently break behavior.
|
|
|
|
|
|
|
|
|
|
### Tenant Isolation is Non-negotiable
|
|
|
|
|
- Every read/write MUST be tenant-scoped.
|
|
|
|
|
- Cross-tenant views (MSP/Platform) MUST be explicit, access-checked, and aggregation-based (no ID-based shortcuts).
|
|
|
|
|
- Prefer least-privilege roles/scopes; surface warnings when higher privileges are selected.
|
|
|
|
|
- Never store secrets in code/config; never log credentials or tokens.
|
|
|
|
|
|
|
|
|
|
### Automation must be Idempotent & Observable
|
|
|
|
|
- Scheduled/queued operations MUST use locks + idempotency (no duplicates).
|
|
|
|
|
- Long-running operations MUST create run records with status, counts, and stable error codes.
|
|
|
|
|
- Graph throttling and transient failures MUST be handled with backoff + jitter (e.g., 429/503).
|
|
|
|
|
- Failures MUST be visible and actionable (no silent best-effort).
|
|
|
|
|
|
|
|
|
|
### Data Minimization & Safe Logging
|
|
|
|
|
- Inventory MUST store only metadata + whitelisted `meta_jsonb`.
|
|
|
|
|
- Payload-heavy content belongs in immutable snapshots/backup storage, not Inventory.
|
|
|
|
|
- Logs MUST not contain secrets/tokens; monitoring MUST rely on run records + error codes (not log parsing).
|
|
|
|
|
|
|
|
|
|
### Spec-First Workflow
|
|
|
|
|
- For any feature that changes runtime behavior, include or update `specs/<NNN>-<slug>/` with `spec.md`, `plan.md`, `tasks.md`, and `checklists/requirements.md`.
|
|
|
|
|
@ -29,7 +68,19 @@ ## Quality Gates
|
|
|
|
|
- Run `./vendor/bin/pint --dirty` before finalizing.
|
|
|
|
|
|
|
|
|
|
## Governance
|
|
|
|
|
- This constitution applies across the repo. Feature specs may add stricter constraints but not weaker ones.
|
|
|
|
|
- Restore semantics changes require: spec update, checklist update, and tests proving safety.
|
|
|
|
|
|
|
|
|
|
**Version**: 1.0.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-01-03
|
|
|
|
|
### Scope & Compliance
|
|
|
|
|
- This constitution applies across the repo. Feature specs may add stricter constraints but not weaker ones.
|
|
|
|
|
- Restore semantics changes require: spec update, checklist update (if applicable), and tests proving safety.
|
|
|
|
|
|
|
|
|
|
### Amendment Procedure
|
|
|
|
|
- Propose changes as a PR that updates `.specify/memory/constitution.md`.
|
|
|
|
|
- The PR MUST include a short rationale and list of impacted templates/specs.
|
|
|
|
|
- Amendments MUST update **Last Amended** date.
|
|
|
|
|
|
|
|
|
|
### Versioning Policy (SemVer)
|
|
|
|
|
- **PATCH**: clarifications/typos/non-semantic refinements.
|
|
|
|
|
- **MINOR**: new principle/section or materially expanded guidance.
|
|
|
|
|
- **MAJOR**: removing/redefining principles in a backward-incompatible way.
|
|
|
|
|
|
|
|
|
|
**Version**: 1.1.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-01-07
|
|
|
|
|
|