TenantAtlas/specs/433-exchange-credential-permission-evidence-support/spec.md

Feature Specification: Exchange Credential and Permission Evidence Support

Feature Branch: 433-exchange-credential-permission-evidence-support Created: 2026-07-07 Status: Implemented Input: User-provided Spec 433 draft for Exchange credential and permission evidence support.

Preparation Selection

• Selected candidate: Spec 433 - Exchange Credential and Permission Evidence Support.
• Source location: User-provided attachment pasted-text.txt, titled Spec 433 - Exchange Credential & Permission Evidence Support.
• Why selected: docs/product/spec-candidates.md states that the automatic next-best-prep queue is empty and manual-promotion only, but the user supplied an explicit P0 draft. Spec 432 is implemented and validated as the production-runner boundary. The next narrow blocker is first-class, scoped, current, redaction-safe credential and permission evidence for that runner gate.
• Roadmap relationship: Continues the Exchange/Teams Coverage v2 sequence after Specs 429-432. Spec 431's historical "Spec 433" label for content-backed evidence promotion is superseded by the Spec 432 follow-up decision; that promotion is now Spec 434. This spec prepares Spec 434 without itself capturing Exchange configuration evidence.
• Completed-spec guardrail result: Specs 429-432 are completed implementation context and were not modified. Spec 432 implementation report records PASS and proves the disabled default, production runner gate, runtime readiness checker, credential resolver, permission evaluator, process executor, argument-vector command construction, output guards, timeout/concurrency guards, sanitized OperationRun context, no evidence rows, no UI/routes/jobs/schedules/listeners, no migration, and no tenant_id. No existing specs/433-* package existed before this preparation.
• Smallest viable implementation slice: Evidence-readiness support for the existing Spec 432 Exchange PowerShell runner gate and existing provider capability/readiness evaluation. The slice refines or extends existing provider credential, permission evidence, capability, and runner-gate code so TenantPilot can decide whether live invocation is allowed, while still making live invocation safely block when supported credential or verified permission evidence is absent.
• Feature description fed into Spec Kit: Prepare first-class Exchange PowerShell credential and Exchange.ManageAsApp permission evidence support for the existing Spec 432 runner gate, preserving workspace/managed-environment/provider-connection scope, redaction, provider capability accuracy, no evidence promotion, no new routes/pages/navigation/assets/global-search surfaces, no Exchange calls, no PowerShell execution, no customer claims, and no tenant_id.

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: Spec 432 can block or gate Exchange PowerShell production execution, but the credential and permission evidence feeding that gate is still too implicit. Credential accessibility, wrong-scope states, permission evidence source/currentness metadata, and combined readiness truth are not first-class enough for safe live invocation decisions.
• Today's failure: TenantPilot could overclaim exchange_powershell_invoke support from admin consent, stale Exchange.ManageAsApp rows, client-secret credentials, wrong-scope details, or incomplete certificate metadata. It could also make the production runner appear ready without durable evidence of credential accessibility and permission currentness.
• User-visible improvement: Operators and reviewers gain a truthful internal safety claim: Exchange PowerShell live invocation is either backed by current, scoped credential and permission evidence, or it blocks with a precise sanitized reason. No Exchange configuration evidence or customer claim is created.
• Smallest enterprise-capable version: Use or narrowly extend existing ProviderCredential, ManagedEnvironmentPermission, provider capability evaluation, and Spec 432 runner gates. Implement explicit states and tests for credential readiness, Exchange.ManageAsApp permission evidence, combined readiness, and no-promotion guarantees.
• Explicit non-goals: No Exchange provider calls, no PowerShell execution, no tenant configuration evidence rows, no raw/normalized Exchange payload, no content-backed/comparable/renderable/certified/restore/customer-ready promotion, no new UI/routes/navigation/Filament/Livewire/assets/global search, no new jobs/schedules/listeners, no Review Pack/report/PDF output, no Teams, no Exchange Admin API, no Exchange-specific credential table, no secret material column, no tenant_id, no legacy shim, no fallback reader.
• Permanent complexity imported: May add a narrow combined readiness evaluator and explicit evidence states/reason mappings. May add minimal provider-agnostic credential or permission metadata only if existing fields cannot safely represent evidence readiness. This imports focused service/test complexity but no customer-facing semantic framework.
• Why now: Spec 432 intentionally left live invocation blocked until credential and permission evidence can be proven safely. Spec 434 content-backed evidence promotion must not start until this prerequisite is explicit, scoped, current, and auditable.
• Why not local: Local checks inside the runner or capability evaluator would duplicate readiness truth and increase overclaim risk. The readiness decision must be testable at the provider capability gate and at the Spec 432 runner gate.
• Approval class: Core Enterprise.
• Red flags triggered: New state/reason vocabulary and possible new metadata. Defense: each state changes execution behavior, provider capability support, auditability, or redaction safety. Metadata is allowed only if existing provider-agnostic models cannot represent current evidence safely.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 1 | Wiederverwendung: 2 | Gesamt: 10/12
• Decision: approve as a narrow backend evidence-readiness prerequisite for Exchange PowerShell live invocation gates.

Spec Scope Fields (mandatory)

• Scope: canonical-view / environment-bound provider readiness and operation execution boundary.
• Primary Routes: Existing provider connection and required-permissions/readiness surfaces only; no new route is added.
• Data Ownership: Existing ProviderCredential is scoped through ProviderConnection; existing ManagedEnvironmentPermission is workspace + managed-environment scoped and must include provider-connection scope in durable metadata or an equivalent provider-agnostic field. OperationRun remains execution truth only. No tenant_id ownership truth.
• RBAC: Workspace and managed-environment entitlement remain required before invoking the gate. Non-member or wrong-scope access returns 404. Member missing provider-run capability returns 403 or repo-equivalent. Provider capability support is never authorization by itself.

For canonical-view specs:

• Default filter behavior when tenant-context is active: Existing workspace/managed-environment/provider-connection scoping remains unchanged.
• Explicit entitlement checks preventing cross-tenant leakage: Credential, permission, provider capability, and runner-gate checks must require matching workspace_id, managed_environment_id, and provider_connection_id before any readiness pass.

No Legacy / No Backward Compatibility Constraint (mandatory)

TenantPilot is pre-production unless this spec explicitly records a compatibility exception.

• Compatibility posture: canonical replacement/addition only.
• Legacy aliases, fallback readers, hidden routes, duplicate UI, old labels, or historical fixtures kept?: no.
• Why clean replacement is safe now: Exchange PowerShell live invocation is still gated and not a shipped customer capability. Old credential/permission ambiguity should be replaced or blocked rather than carried as compatibility behavior.

UI Surface Impact (mandatory - UI-COV-001)

Does this spec add, remove, rename, or materially change any reachable UI surface?

• No UI surface impact
• Existing page changed
• New page/route added
• Navigation changed
• Filament panel/provider surface changed
• New modal/drawer/wizard/action added
• New table/form/state added
• Customer-facing surface changed
• Dangerous action changed
• Status/evidence/review presentation changed
• Workspace/environment context presentation changed

UI/Productization Coverage (mandatory when UI Surface Impact is not "No UI surface impact"; otherwise write N/A - no reachable UI surface impact plus rationale)

This spec adds no new route, page, component, navigation item, action, asset, global-search behavior, credential-management UI, permission-management UI, customer route, report, or Review Pack output. However, it changes the existing provider capability/readiness truth consumed by rendered surfaces, so existing status presentation can change without editing UI files.

• Affected existing surfaces: provider connection capability/readiness presentation, environment required-permissions provider-capability section, and verification-assist provider-capability presentation where those surfaces already render ProviderCapabilityEvaluator/registry output.
• Surface intent: show only canonical supported/not-supported/blocking readiness states and safe high-level blocker labels.
• Forbidden default content: raw credential material, raw permission details, raw provider payloads, OperationRun context, provider-native tenant IDs as ownership truth, stack traces, stdout/stderr, and unredacted diagnostics.
• No new affordance: no new primary action, repair CTA, destructive action, or customer-visible Exchange evidence claim is introduced.

Product Surface Impact (mandatory for UI-affecting specs; otherwise write N/A - no rendered product surface changed plus rationale)

Reference: docs/product/standards/product-surface-contract.md.

• Product Surface Contract applies?: yes - provider capability/readiness state changes are rendered by existing surfaces.
• Page archetype: existing provider readiness/capability surfaces.
• Primary user question: Is this provider connection ready for Exchange PowerShell live invocation?
• Primary action: none added; existing actions and authorization remain unchanged.
• Surface budget result: no new surface budget is introduced; changed output must reuse existing status slots and avoid extra panels, tables, or diagnostics.
• Technical Annex / deep-link demotion: OperationRun remains internal execution truth, not customer proof. Raw evidence, credential details, permission details, IDs used only for scope checks, provider diagnostics, and logs stay out of default product views.
• Canonical status vocabulary: existing ProviderCapabilityStatus/provider-readiness status vocabulary must be reused unless a new state has direct behavior consequences and passes proportionality review.
• Visible complexity impact: neutral-to-reduced; existing surfaces should become more truthful without adding default-visible technical detail.
• Product Surface exceptions: none.

Browser Verification Plan (mandatory)

• Browser proof required?: yes, focused read-only smoke after implementation because existing provider capability/readiness surfaces render changed status truth.
• No-browser rationale: N/A.
• Focused path when required: existing Provider Connection capability/readiness view and existing Environment Required Permissions / verification-assist provider-capability section for a fixture with not-ready and ready-equivalent states.
• Primary interaction to execute: open the existing surfaces, confirm no new navigation/action appears, confirm readiness state is canonical and redacted, and confirm wrong-scope/stale/missing evidence does not display as ready.
• Console, Livewire, Filament, network, and 500-error checks: required for the focused paths.
• Full-suite failure triage: only failures tied to changed provider capability/readiness surfaces block this spec; unrelated browser debt is documented separately.

Human Product Sanity Check (mandatory)

• Required?: yes.
• No-human-sanity rationale: N/A.
• Reviewer questions: Does the existing surface answer readiness without exposing technical payloads? Is there one clear status? Are raw evidence/OperationRun/provider details demoted? Are no new repair or destructive actions introduced?
• Planned result location: implementation report / PR close-out.

Product Surface Merge Gate Checklist (mandatory)

• No-legacy posture or approved exception recorded.
• Product Surface Impact is completed for existing provider capability/readiness surfaces.
• Browser proof is planned for existing provider capability/readiness surfaces.
• Human Product Sanity is planned for existing provider capability/readiness surfaces.
• Product Surface exceptions are documented or none.
• Implementation report will state Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, tests/browser result, deployment impact, visible complexity outcome, and no completed-spec rewrite assertion.

Cross-Cutting / Shared Pattern Reuse

• Cross-cutting feature?: yes.
• Interaction class(es): Provider capability/readiness, OperationRun execution truth, credential evidence, permission evidence. Existing rendered provider readiness/capability surfaces can change status output through existing data flow.
• Systems touched: Existing ExchangePowerShellCredentialReferenceResolver, ExchangePowerShellPermissionEvidenceEvaluator, ExchangePowerShellProductionRunner, ExchangePowerShellInvocationGate, ProviderCapabilityEvaluator, ProviderCapabilityRegistry, ProviderCredential, ManagedEnvironmentPermission, ProviderConnection, and tenantpilot config.
• Existing pattern(s) to extend: Provider credential/reference architecture, managed-environment permission evidence, provider capability evaluation, OperationRun context sanitization, Spec 432 runner gate.
• Shared contract / presenter / builder / renderer to reuse: Provider operation/capability contracts, existing provider readiness/capability render paths, and OperationRun lifecycle. No new UI presenter, renderer, or runtime Product Surface framework.
• Why the existing shared path is sufficient or insufficient: Existing paths are sufficient for operation truth, runner gating, provider scope, and initial fail-closed behavior. They are insufficient for first-class inaccessible credential state, configurable or justified permission currentness, source/observed/verified metadata, and one combined readiness result consumed consistently by capability and runner gates.
• Allowed deviation and why: A narrow readiness evaluator or provider-agnostic metadata extension is allowed if it replaces implicit scattered checks with one testable execution gate. Broad provider frameworks, evidence writers, and UI frameworks are forbidden.
• Consistency impact: exchange_powershell_invoke capability and the Spec 432 runner gate must agree on readiness. Both must block client-secret/admin-consent-only/missing/stale/wrong-scope cases.
• Review focus: Verify no overclaim, no secret material, no raw provider payloads, no evidence promotion, and no parallel Exchange mini-platform.

OperationRun UX Impact

• Touches OperationRun start/completion/link UX?: yes, backend context and runner gate safety only. No rendered start, notification, or deep-link behavior changes.
• Shared OperationRun UX contract/layer reused: OperationRunService, existing Spec 432 invocation gate context, and existing sanitized failure/summary patterns.
• Delegated start/completion UX behaviors: N/A - no toast, run link, artifact link, browser event, queued DB notification, or rendered surface.
• Local surface-owned behavior that remains: none.
• Queued DB-notification policy: N/A.
• Terminal notification path: unchanged central lifecycle behavior if a run reaches terminal status.
• Exception required?: none.

Provider Boundary / Platform Core Check

• Shared provider/platform boundary touched?: yes.
• Boundary classification: mixed. Exchange permission and credential requirements are provider-owned; scope, provider capability, OperationRun, credential-reference metadata, and permission-evidence currentness are platform-core safety seams.
• Seams affected: credential reference evaluation, permission evidence evaluation, provider capability support, runner-gate readiness, OperationRun context, and optional provider-agnostic metadata.
• Neutral platform terms preserved or introduced: provider connection, credential reference, permission evidence, currentness, observed at, verified at, source, readiness, blocked reason, workspace, managed environment.
• Provider-specific semantics retained and why: Exchange.ManageAsApp, Exchange PowerShell invocation, and related credential kind behavior are retained only within the Exchange runner readiness boundary.
• Why this does not deepen provider coupling accidentally: No provider-specific table, route, UI component, customer vocabulary, compare semantics, restore semantics, or platform ownership key is introduced. Any new persistence must be provider-agnostic.
• Follow-up path: document-in-feature. Content-backed evidence, compare/render/certification, restore, Teams, customer output, and broader provider readiness UX remain follow-up specs.

UI / Surface Guardrail Impact

Existing operator-facing provider capability/readiness surfaces can show changed readiness results. Guardrail impact is limited to those existing status slots; no new UI files, routes, navigation, actions, dashboard widgets, customer surfaces, or global search behavior are introduced.

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no for Exchange configuration evidence; possible provider-agnostic evidence metadata only if existing fields cannot represent credential/permission readiness safely.
• New persisted entity/table/artifact?: no by default. A minimal provider-agnostic migration may be added only after proving existing ProviderCredential and ManagedEnvironmentPermission.details are insufficient.
• New abstraction?: possibly one combined readiness evaluator, justified to remove duplicate readiness decisions between provider capability and runner gate.
• New enum/state/reason family?: yes, bounded credential/permission/readiness blocker states with direct execution consequences.
• New cross-domain UI framework/taxonomy?: no.
• Current operator problem: Prevent false Exchange PowerShell readiness and protect live invocation from unsafe credentials, stale/wrong-scope permissions, and redaction failures.
• Existing structure is insufficient because: Spec 432 has resolvers/evaluators, but current repo evidence shows hard-coded 30-day permission currentness, permission source/observed/verified metadata living implicitly in details, no explicit inaccessible credential state, no managed identity enum case, and no single combined readiness result shared by capability and runner gate.
• Narrowest correct implementation: Refine the existing resolver/evaluator/capability path and add one combined readiness result if needed. Add metadata only provider-agnostically and only when existing fields cannot safely prove the gate.
• Ownership cost: Additional focused service/test surface and possibly a small provider-agnostic migration that future provider readiness work must respect.
• Alternative intentionally rejected: Treat admin consent, last_checked_at, or provider connection existence as sufficient; create Exchange-specific tables; or fold the logic into UI copy or customer claims.
• Release truth: Current-release safety prerequisite before Exchange content-backed evidence promotion.

Data Model Decision Boundary

The implementation must begin with a data model assessment:

• Current ProviderCredential has provider_connection_id, type, credential_kind, source, encrypted hidden payload, last_rotated_at, and expires_at.
• Current ProviderCredentialKind includes client_secret, certificate, and federated; managed identity is not currently a first-class enum case.
• Current ManagedEnvironmentPermission has workspace_id, managed_environment_id, permission_key, status, last_checked_at, and JSONB details; the current table is unique by managed_environment_id + permission_key, not by provider_connection_id.
• Current ExchangePowerShellPermissionEvidenceEvaluator uses Exchange.ManageAsApp, last_checked_at, and scoped details values, with a hard-coded 30-day threshold.

Preferred result: no migration, with proof that existing fields and safe details metadata are sufficient. In the no-migration path, permission evidence remains one row per managed environment and permission key; readiness may pass only when details explicitly matches the evaluated provider connection, workspace, managed environment, and provider, and nonmatching or missing details must fail closed. No fallback-to-latest or fallback-to-admin-consent behavior is allowed.

Allowed fallback: minimal provider-agnostic metadata migration for credential accessibility/source/observed/verified/currentness or permission source/observed/verified/currentness. If implementation finds that a migration is required, runtime implementation MUST stop before adding schema code and update this spec.md plus plan.md with the exact fields, ownership semantics, constraints/indexes, rollback posture, and proportionality review. Forbidden: Exchange-specific credential or permission tables, secret material columns, raw provider payload columns, UI state tables, and tenant_id.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Unit tests for credential evidence states, permission evidence currentness/scope/source metadata, combined readiness, provider capability status, and redaction. Feature tests for runner-gate integration, OperationRun context safety, no evidence/no product promotion/no new UI/no trigger/no tenant_id. Focused browser proof for existing provider capability/readiness surfaces.
• Validation lane(s): fast-feedback and confidence focused Pest lanes; PostgreSQL lane if a migration or JSONB/index behavior is added; focused read-only browser smoke for existing provider capability/readiness surfaces.
• Why this classification and these lanes are sufficient: The runtime change is evidence-readiness and local gate evaluation with no live provider execution, but provider capability/readiness output is rendered by existing surfaces.
• New or expanded test families: New Spec 433 unit/feature tests under existing TenantConfiguration/provider capability test locations.
• Fixture / helper cost impact: Explicit workspace, managed environment, provider connection, credential, permission evidence, capability, and OperationRun fixtures. Helpers must remain explicit/feature-local or opt-in.
• Heavy-family visibility / justification: Focused browser proof is required only because existing status surfaces render provider capability/readiness output. PostgreSQL validation is required only if schema or JSONB/index behavior changes.
• Special surface test profile: Existing Provider Connection and Environment Required Permissions / verification-assist provider-capability surfaces only.
• Standard-native relief or required special coverage: no new rendered surface, but existing rendered readiness status requires focused browser proof and Human Product Sanity.
• Reviewer handoff: Reviewers must confirm no credential material, no raw permission payload, no provider calls, no PowerShell execution, no evidence rows, no new UI, no jobs/schedules/listeners, no tenant_id, and no overclaiming provider capability.
• Budget / baseline / trend impact: none expected unless migration or broader feature-test setup materially expands runtime.
• Escalation needed: reject-or-split if implementation attempts Exchange capture, PowerShell execution, new UI, route/job/schedule/listener triggers, customer output, or Exchange-specific persistence.
• Active feature PR close-out entry: Guardrail / credential and permission evidence readiness / existing provider capability/readiness surfaces browser-checked, no new rendered UI surface introduced.
• Planned validation commands:
  • cd apps/platform && ./vendor/bin/sail artisan test --filter=Spec433 --compact
  • cd apps/platform && ./vendor/bin/sail artisan test --filter=Spec432 --compact
  • selected Spec 431, Spec 430, Spec 426/427, Spec 417, Spec 419/420, and provider capability regressions
  • focused read-only browser proof for existing provider capability/readiness surfaces after implementation
  • cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent
  • git diff --check
  • PostgreSQL lane if a migration is added

User Scenarios & Testing (mandatory)

User Story 1 - Credential Evidence Blocks Unsafe Credentials (Priority: P1)

As a security reviewer, I need Exchange PowerShell credential evidence to distinguish missing, unsupported, expired, inaccessible, wrong-scope, unvalidated, unknown, and ready states, so unsafe credentials cannot pass the live invocation gate.

Why this priority: Credential proof is the first hard stop before any live Exchange PowerShell invocation.

Independent Test: Unit tests prove client_secret blocks, missing credentials block, expired certificates block, inaccessible references block distinctly, unsupported certificate/federated/managed-identity states block unless explicitly supported, and no credential material appears in OperationRun context or loggable envelopes.

Acceptance Scenarios:

1. Given a provider connection with only a client-secret credential, When Exchange PowerShell readiness is evaluated, Then readiness blocks with a secret-based credential reason.
2. Given a certificate credential reference that is expired, inaccessible, wrong-scope, or unsupported, When readiness is evaluated, Then each case returns a distinct safe blocker state.
3. Given any credential payload contains secret-like values, When readiness is evaluated or OperationRun context is written, Then raw material never appears.

User Story 2 - Permission Evidence Is Scoped and Current (Priority: P1)

As a provider readiness reviewer, I need Exchange.ManageAsApp evidence to be scoped to the same workspace, managed environment, and provider connection and to be current, so admin consent or stale/wrong-scope rows cannot enable live invocation.

Why this priority: Permission overclaim is the main way a configured provider connection could be mislabeled as invocation-ready.

Independent Test: Unit/feature tests prove admin consent alone blocks, missing/unvalidated/stale evidence blocks, wrong workspace/environment/provider-connection evidence blocks, and current verified scoped evidence can pass the permission gate without creating configuration evidence.

Acceptance Scenarios:

1. Given only permissions.admin_consent, When exchange_powershell_invoke is evaluated, Then capability is not Supported.
2. Given Exchange.ManageAsApp evidence older than the currentness threshold, When readiness is evaluated, Then stale evidence blocks.
3. Given permission evidence for another provider connection, When the runner gate evaluates readiness, Then wrong-scope evidence blocks before process execution.

User Story 3 - Combined Readiness Drives Capability and Runner Gate (Priority: P1)

As an implementation reviewer, I need one combined Exchange invocation readiness result used by provider capability and the Spec 432 runner gate, so the platform cannot show Supported while the runner blocks for evidence, or vice versa.

Why this priority: Readiness drift between capability evaluation and runner execution would recreate the false-calm problem this spec exists to prevent.

Independent Test: Tests prove combined readiness requires both credential evidence and permission evidence, returns safe blocker states, and is consumed by both ProviderCapabilityEvaluator and ExchangePowerShellProductionRunner or their repo-canonical equivalents.

Acceptance Scenarios:

1. Given valid permission evidence but unsupported credential evidence, When capability is evaluated, Then exchange_powershell_invoke is not Supported.
2. Given supported credential evidence but stale permission evidence, When runner readiness is evaluated, Then live invocation remains blocked.
3. Given both evidence paths are current, scoped, and safe, When readiness is evaluated, Then the result may pass the invocation gate but still does not create Exchange configuration evidence or customer claims.

User Story 4 - Evidence Readiness Does Not Promote Product Claims (Priority: P1)

As a release reviewer, I need credential and permission readiness to remain an internal runner prerequisite, so TenantPilot does not claim Exchange settings were captured, compared, rendered, certified, restorable, or customer-ready.

Why this priority: Credential and permission evidence only permits a later live invocation gate; it is not Exchange configuration evidence.

Independent Test: Feature/guard tests prove no TenantConfigurationResourceEvidence rows, no raw/normalized Exchange payload, no content-backed/comparable/renderable/certified/restore/customer state, no new UI/routes/assets/global search, no jobs/schedules/listeners, no migration with tenant_id, no Exchange-specific credential table, and no raw details on existing provider readiness surfaces.

Acceptance Scenarios:

1. Given a readiness pass, When persistence is inspected, Then no Exchange configuration evidence row or raw provider payload exists.
2. Given Spec 433 changed runtime artifacts, When guard scans run, Then no new routes, UI files, jobs, schedules, listeners, customer output, or global search changes are present.
3. Given provider capability is Supported, When customer/report surfaces are inspected, Then no customer-facing Exchange evidence or certification claim exists from this spec.

Functional Requirements

• FR-433-001: The implementation MUST keep Spec 433 evidence-readiness only and MUST NOT call Exchange, run PowerShell, or create Exchange configuration evidence.
• FR-433-002: Credential readiness MUST be evaluated from existing provider credential/reference architecture unless a minimal provider-agnostic metadata migration is proven necessary.
• FR-433-003: client_secret credentials MUST block Exchange PowerShell live invocation.
• FR-433-004: Credential evaluation MUST distinguish missing, unsupported, expired, inaccessible, wrong-scope, unvalidated, unknown, and ready states where those states are observable from repo-owned fields or a spec-approved metadata migration; otherwise it MUST collapse the unobservable condition into a safe repo-canonical fail-closed state with tests.
• FR-433-005: Certificate credentials MUST either be supported through safe reference metadata or explicitly block with tested certificate-specific reasons.
• FR-433-006: Federated and managed-identity credentials MUST either be supported with explicit repo/deployment proof or explicitly block with tested reasons.
• FR-433-007: Credential evaluation MUST never expose private keys, certificate passwords, client secrets, tokens, authorization headers, raw vault payloads, raw environment dumps, or raw provider errors.
• FR-433-008: Permission readiness MUST evaluate Exchange.ManageAsApp or a repo-canonical equivalent as explicit evidence separate from admin consent.
• FR-433-009: Admin consent alone MUST NOT make exchange_powershell_invoke Supported and MUST NOT pass the runner gate.
• FR-433-010: Permission evidence MUST be scoped to the same workspace, managed environment, and provider connection before passing readiness, and MUST NOT pass through fallback-to-latest, fallback-to-first, or admin-consent-only behavior.
• FR-433-011: Permission evidence MUST block when missing, unvalidated, stale, wrong workspace, wrong environment, wrong provider connection, unsupported provider, revoked/absent, or unknown.
• FR-433-012: Permission currentness MUST be configurable or the fixed threshold MUST be explicitly justified and tested.
• FR-433-013: Permission evidence source, observed, captured, verified, auditor/observer where applicable, and evaluator version metadata MUST be represented first-class enough for gate evaluation or documented as a safe existing details structure.
• FR-433-014: A combined Exchange invocation readiness evaluator or repo-canonical equivalent MUST require credential readiness and permission evidence readiness before returning a live-invocation-ready state.
• FR-433-015: exchange_powershell_invoke provider capability MUST be Supported only when combined readiness passes.
• FR-433-016: The Spec 432 production runner gate MUST consume the combined readiness result or repo-canonical equivalent before process execution.
• FR-433-017: OperationRun context MAY record only safe readiness and blocker states; it MUST NOT record credential material, raw permission payloads, raw provider payloads, or sensitive exception messages.
• FR-433-018: The implementation MUST prove no evidence rows, raw Exchange payloads, normalized Exchange payloads, content-backed state, compare/render/certification state, restore state, or customer claim is introduced.
• FR-433-019: The implementation MUST prove no new route, Filament page, Livewire component, navigation item, global search change, asset, job, schedule, or listener is introduced; existing provider capability/readiness surfaces may only reflect changed evaluator output through existing rendering paths.
• FR-433-020: Any migration MUST be provider-agnostic, reversible where practical, tested, and must not contain Exchange-specific table names, secret material, raw provider payloads, UI state, or tenant_id.

Non-Functional Requirements

• NFR-433-001: All tests MUST be deterministic and offline; no test may require Exchange Online connectivity, Microsoft credentials, PowerShell execution, or installed Exchange modules.
• NFR-433-002: All new or changed state names MUST have behavior consequences and remain bounded to credential/permission/readiness gates.
• NFR-433-003: Query and lookup behavior MUST enforce workspace, managed-environment, and provider-connection scope before returning readiness.
• NFR-433-004: Redaction MUST be tested across OperationRun context, returned readiness envelopes, failure messages, logs where testable, and persisted metadata.
• NFR-433-005: Implementation MUST remain Sail-first locally and Dokploy-aware for staging/production. Any new env key must default fail-closed and be documented.

Edge Cases

• Provider connection has no credential row.
• Provider credential exists but credential kind is empty, unknown, corrupted, or unsupported.
• Provider credential is certificate but expiry/currentness/accessibility metadata is missing.
• Provider credential source is present but inaccessible or wrong-scope.
• Managed identity appears in stored metadata but is not a first-class enum case.
• Exchange.ManageAsApp row exists but status is not granted.
• Exchange.ManageAsApp row is stale by threshold.
• Permission evidence details omit workspace, managed environment, provider, or provider connection.
• Permission evidence matches environment but not provider connection.
• Admin consent is granted but explicit Exchange permission evidence is missing.
• Combined readiness passes but Exchange evidence promotion remains out of scope.

Success Criteria

• SC-433-001: Focused Spec 433 tests prove all credential blocker/pass states required by this spec.
• SC-433-002: Focused Spec 433 tests prove all permission blocker/pass states required by this spec.
• SC-433-003: Provider capability tests prove exchange_powershell_invoke cannot become Supported from admin consent, client secret, missing evidence, stale evidence, or wrong-scope evidence.
• SC-433-004: Runner-gate tests prove combined readiness is required before process execution and safe blockers are stored without secrets.
• SC-433-005: Guard tests prove no evidence promotion, no product/customer claim, no new UI/trigger surface, no Exchange-specific credential table, no raw details on existing provider readiness surfaces, and no tenant_id.
• SC-433-006: Spec 432, Spec 431, Spec 430, and provider capability regressions continue to pass.

Risks

• Existing ManagedEnvironmentPermission.details may be flexible enough but not durable or queryable enough for long-term evidence gate proof.
• Adding a metadata migration could become too broad unless provider-agnostic and tightly bounded.
• Capability evaluation and runner gate logic could drift if the combined readiness result is not shared.
• Supporting certificate/federated/managed-identity pass states prematurely could imply production credential support that deployment cannot satisfy.

Assumptions

• Spec 432 PASS remains valid and has no merge-blocking runtime safety findings.
• Exchange PowerShell live invocation remains disabled by default and out of scope for this prep pass.
• Exchange.ManageAsApp is the current target permission key unless implementation finds a repo-canonical equivalent.
• Currentness can safely default fail-closed while implementation decides configurable threshold versus justified fixed threshold.

Open Questions

• Can existing ProviderCredential fields and hidden encrypted payload metadata safely represent credential accessibility/source/verified/currentness without migration?
• Can existing ManagedEnvironmentPermission.details safely represent permission source/observed/verified/evaluator metadata, or is a provider-agnostic migration needed?
• Should Spec 433 make the permission currentness threshold configurable, or explicitly justify and test the existing 30-day fixed threshold?
• Can certificate credentials safely pass in this spec, or should they remain explicitly blocked pending deployment credential support?

These questions do not block implementation only when the implementation takes the safe fail-closed path. If any answer requires new persisted fields, constraints, or first-class credential/permission scope metadata, implementation must stop and update spec.md plus plan.md before adding schema code.

Follow-up Spec Candidates

• Spec 434 - Exchange Content-Backed Evidence Promotion Slice 1.
• Exchange comparable/renderable promotion after content-backed evidence exists.
• Teams PowerShell adapter and evidence support.
• M365 customer output and claim guard for Exchange/Teams after evidence is real.

Candidate Selection Gate

PASS. The selected candidate is directly provided by the user, is not covered by an existing active or completed Spec 433 package, follows implemented Spec 432, aligns with the Exchange/Teams roadmap sequence, and is narrow enough for a bounded implementation loop. Adjacent evidence promotion, new UI, Teams, customer output, compare/render/certification, and restore work are deferred.

Spec Readiness Gate

PASS with implementation conditions. plan.md, tasks.md, and checklists/requirements.md are aligned with this corrected scope. Runtime implementation must not begin until the implementation skill re-checks Spec 432 prerequisites, repo state, the Product Surface proof plan, and the data-model decision. Any migration requirement or new rendered surface beyond existing provider readiness/capability slots requires updating this spec and plan before code changes continue.