ahmido
110245a9ec
Some checks are pending
Main Confidence / confidence (push) Waiting to run
## Summary - add a shared provider target-scope descriptor, normalizer, identity-context metadata, and surface-summary layer - update provider connection list, detail, create, edit, and onboarding surfaces to use neutral target-scope vocabulary while keeping Microsoft identity contextual - align provider connection audit and resolver output with the neutral target-scope contract and add focused guard/unit/feature coverage for regressions ## Validation - browser smoke: opened the tenant-scoped provider connection list, drilled into detail, and verified the edit/create surfaces in local admin context ## Notes - this PR comes from the session branch created for the active feature work - no additional runtime or persistence layer was introduced in this slice Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #274
41 lines
3.8 KiB
Markdown
41 lines
3.8 KiB
Markdown
# Research: Provider Identity & Target Scope Neutrality
|
|
|
|
## Decision 1: Use one small shared target-scope descriptor instead of a broad provider identity framework
|
|
|
|
- **Decision**: Introduce one small shared descriptor for provider connection target scope and reuse it across the provider connection resource, onboarding, validation, and audit wording.
|
|
- **Rationale**: The current release needs one neutral shared truth for multiple real surfaces, not a generalized provider marketplace or identity framework. A small descriptor layer is enough to keep shared language neutral while still letting Microsoft-specific detail remain contextual.
|
|
- **Alternatives considered**:
|
|
- Page-local label cleanup only: rejected because it would leave the shared contract Microsoft-shaped underneath.
|
|
- Broad provider identity abstraction: rejected because there is still only one shipped provider runtime and the current hotspot is narrower than that.
|
|
|
|
## Decision 2: Keep Microsoft tenant and directory details as provider-owned contextual metadata
|
|
|
|
- **Decision**: Retain `entra_tenant_id`, authority-tenant details, consent wording, and Microsoft verification details only as contextual provider-owned metadata on Microsoft paths.
|
|
- **Rationale**: Operators still need Microsoft-specific identifiers for consent and troubleshooting, but those identifiers should not define the default meaning of a provider connection on generic shared surfaces.
|
|
- **Alternatives considered**:
|
|
- Remove Microsoft-specific details from the UI entirely: rejected because the current product still needs them on Microsoft-only workflows.
|
|
- Keep them as the default connection summary: rejected because that preserves the current provider-boundary drift.
|
|
|
|
## Decision 3: Neutralize shared Filament surfaces first, not every provider term in the repo
|
|
|
|
- **Decision**: Limit the first slice to provider connection list, detail, create, edit, onboarding provider setup, and shared audit or validation wording directly tied to those surfaces.
|
|
- **Rationale**: These are the concrete operator-facing hotspots already named in the spec. A repo-wide terminology sweep would widen scope without improving the core shared contract any faster.
|
|
- **Alternatives considered**:
|
|
- Rename every provider-related term immediately: rejected because it would turn one bounded hotspot into a broad copy and architecture sweep.
|
|
- Leave onboarding for later: rejected because it would preserve two competing interpretations of the same connection truth.
|
|
|
|
## Decision 4: Anchor neutrality in shared resolution and mutation paths, not only in UI labels
|
|
|
|
- **Decision**: Update the existing provider connection and identity-resolution outputs plus mutation and audit wording so shared surfaces all consume the same neutral target-scope semantics.
|
|
- **Rationale**: UI-only changes would be fragile because validation, audit prose, and future surfaces would still source their meaning from Microsoft-shaped service outputs.
|
|
- **Alternatives considered**:
|
|
- Keep service outputs unchanged and translate everything in Filament only: rejected because future surfaces would likely repeat the same drift.
|
|
- Replace the entire provider identity stack: rejected because the current hotspot is limited to shared target-scope meaning.
|
|
|
|
## Decision 5: Enforce the contract with focused guardrails, not browser coverage
|
|
|
|
- **Decision**: Add focused unit and feature guard coverage for neutral target-scope descriptors, shared surface labels, onboarding reuse, and audit wording.
|
|
- **Rationale**: The risk is semantic drift in shared provider connection truth, not browser-only interaction. Narrow unit and feature coverage are the cheapest proof.
|
|
- **Alternatives considered**:
|
|
- Browser tests: rejected because they add cost without proving unique behavior for this slice.
|
|
- Manual review only: rejected because the feature exists to stop the same hotspot from reopening quietly. |