ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
788efee1c2
TenantAtlas/specs/381-provider-resource-identity-binding/checklists/requirements.md
ahmido 04d0d6184f feat(resources): implement provider resource identity binding (#452) 
Added `ProviderResourceBinding` model, migrations, policies, and supporting framework for canonical resource identity mapping as defined in Spec 381. This provides the structural capability to resolve baseline and posture discrepancies by binding logical entities across source providers to canonical identities.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #452
2026-06-15 18:45:38 +00:00

4.4 KiB
Raw Blame History

Requirements Checklist: Spec 381 - Provider Resource Identity and Binding Foundation v1

Purpose: Validate that the preparation artifacts define a bounded, implementable, constitution-aligned foundation for provider resource identity and binding decisions. Created: 2026-06-15 Feature: spec.md

Note: This checklist covers preparation quality only. It does not mark implementation work complete.

Applicability And Low-Impact Gate

  • CHK001 The spec explicitly states that no operator-facing surface or guardrail workflow surface is affected.
  • CHK002 The spec, plan, and tasks consistently classify the feature as a backend/domain foundation with no UI surface impact.
  • CHK029 The spec includes exactly one coherent UI Surface Impact decision: checked No UI surface impact with rationale.
  • CHK032 Navigation entries, Filament panel/provider changes, Livewire components, Blade views, routes, and actions were explicitly considered and excluded from v1.
  • CHK033 Browser screenshots and full page-report expectations are not required because v1 has no UI or customer-facing output change.

Provider Boundary And Vocabulary

  • CHK010 The shared provider/platform seam is identified as mixed: provider identity data is stored in platform-core persistence, while provider-specific mapping semantics stay outside core.
  • CHK011 Microsoft-specific display names, Graph endpoints, and provider-default object labels are explicitly prohibited from becoming platform-core identity truth.
  • CHK034 A fake-provider proof is required so the identity and binding foundation does not silently become Microsoft-only.

Persistence, State, And Proportionality

  • CHK035 The new provider_resource_bindings table is justified as independent, auditable product truth that outlives a run.
  • CHK036 The spec avoids duplicate active truth by using binding_status=active rather than adding a separate is_active flag.
  • CHK037 New status and resolution-mode families are justified by distinct lifecycle, audit, lookup, or future operator-action consequences.
  • CHK038 The plan keeps v1 managed-environment-scoped and defers workspace-level, baseline-profile-specific, and subject-only binding scopes.
  • CHK039 The plan reuses BaselineSubjectKey instead of introducing a parallel canonical-key taxonomy.

RBAC, Audit, And Tenant Isolation

  • CHK040 Binding reads and mutations require workspace and managed-environment entitlement.
  • CHK041 Non-member access is deny-as-not-found; entitled users missing capability receive forbidden.
  • CHK042 V1 reuses existing baseline capabilities unless the spec is updated before dedicated binding capabilities are introduced.
  • CHK043 Binding decisions and revocations require safe audit records with actor, workspace, managed environment, provider key, canonical subject key, mode, and source references.
  • CHK044 Audit metadata explicitly excludes secrets, credentials, raw provider payloads, raw Graph responses, signed URLs, stack traces, and sensitive raw JSON.

OperationRun And Runtime Truth

  • CHK019 The spec explicitly states that v1 creates no OperationRun, queued work, scheduler behavior, provider runtime calls, or Graph calls.
  • CHK045 The spec preserves current baseline compare, evidence readiness, environment review readiness, review-pack publication, and customer-facing output semantics.
  • CHK046 Follow-up matching, UI resolution, evidence/review consumption, and automatic built-in mapping work is listed as follow-up scope rather than hidden v1 behavior.

Test Readiness

  • CHK047 The test-governance lane is explicit: Unit, Feature, PostgreSQL, and targeted no-op regression tests; no Browser family.
  • CHK048 PostgreSQL validation is scoped to partial unique/index behavior that SQLite cannot prove.
  • CHK049 Tasks require authorization, audit, fake-provider, persistence, identity, and no-op runtime regression coverage.
  • CHK050 Final validation commands are concrete enough for a later implementation loop.

Review Outcome

  • CHK016 Review outcome class: acceptable-special-case.
  • CHK017 Workflow outcome: keep.
  • CHK018 Final note location: implementation close-out for specs/381-provider-resource-identity-binding/ must record validation commands, deployment impact, Livewire/Filament status, and any confirmed scope deviations.