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

Tasks: Exchange Credential and Permission Evidence Support

Input: Design documents from specs/433-exchange-credential-permission-evidence-support/ Prerequisites: spec.md, plan.md, Spec 432 implementation report, current repo source truth Tests: Required. Runtime behavior changes must use Pest 4 focused unit/feature tests. Focused browser proof is required for existing provider capability/readiness surfaces because evaluator output is rendered there.

Test Governance Checklist

• Lane assignment is named and is the narrowest sufficient proof for the changed behavior.
• New or changed tests stay in the smallest honest family, and any PostgreSQL/heavy/browser addition is explicit.
• Shared helpers, factories, seeds, fixtures, provider setup, permission setup, and OperationRun context defaults stay cheap by default or isolated behind explicit opt-ins.
• Planned validation commands cover the change without pulling in unrelated lane cost.
• Browser proof is planned for existing provider capability/readiness surfaces.
• Human Product Sanity and Product Surface implementation-report close-out are planned for existing provider capability/readiness surfaces.
• Any material budget, baseline, trend, or escalation note is recorded in the implementation report.

Phase 1: Preflight and Repo Truth

Purpose: Confirm Spec 433 starts from the implemented Spec 432 boundary and does not rewrite completed specs.

• T001 Capture branch, HEAD, and git status --short.
• T002 Confirm Specs 429-432 are completed read-only context and are not edited.
• T003 Confirm Spec 432 implementation report is PASS and has no open merge-blocking runtime safety findings.
• T004 Inspect apps/platform/app/Services/TenantConfiguration/ExchangePowerShellCredentialReferenceResolver.php.
• T005 Inspect apps/platform/app/Services/TenantConfiguration/ExchangePowerShellPermissionEvidenceEvaluator.php.
• T006 Inspect apps/platform/app/Services/TenantConfiguration/ExchangePowerShellProductionRunner.php and ExchangePowerShellInvocationGate.php.
• T007 Inspect apps/platform/app/Support/Providers/Capabilities/ProviderCapabilityEvaluator.php and ProviderCapabilityRegistry.php.
• T008 Inspect apps/platform/app/Models/ProviderCredential.php, ProviderCredentialKind.php, ManagedEnvironmentPermission.php, and related migrations.
• T009 Confirm no Exchange calls, no PowerShell execution, no evidence promotion, no new UI/routes/jobs/schedules/listeners, no customer output, and no tenant_id are planned; identify existing provider capability/readiness surfaces that will need browser proof.

Checkpoint: Preflight confirms only Spec 433 implementation work is in scope.

Phase 2: Data Model Decision

Purpose: Decide whether existing provider-agnostic fields are sufficient before any schema work.

• T010 Document whether ProviderCredential fields can safely represent credential kind, source, accessibility, currentness, expiry, and verified/observed metadata without migration, and identify which credential states are repo-observable versus fail-closed equivalents.
• T011 Document whether ManagedEnvironmentPermission plus details can safely represent Exchange.ManageAsApp source, observed, verified, provider connection scope, currentness, and evaluator metadata without migration, including the current managed_environment_id + permission_key uniqueness and provider-connection matching through details.
• T012 If no migration is needed, add or update tests proving the existing fields/details are sufficient for all gate states.
• T013 If migration is needed, stop implementation and update spec.md plus plan.md with exact fields, ownership semantics, constraints/indexes, rollback posture, and proportionality review before adding schema code. N/A - no migration was needed.
• T014 After an approved migration amendment, add the narrowest provider-agnostic migration and PostgreSQL/schema tests proving no Exchange-specific table, no secret material column, no raw provider payload column, no UI state column, no tenant_id, and reversible/drop-safe behavior where practical. N/A - no migration was added.
• T015 Record the data-model decision, no-migration or migration proof, and proportionality review in the implementation report.

Checkpoint: Data model path is explicit and provider-agnostic.

Phase 3: Credential Evidence States

Purpose: Make credential readiness explicit, scoped, and redaction-safe.

• T016 Extend or refactor ExchangePowerShellCredentialReferenceResolver to return repo-canonical states for ready, missing, unsupported, expired, inaccessible, wrong-scope, unvalidated, and unknown credentials where repo-owned fields or an approved metadata migration make those states observable; otherwise return safe fail-closed equivalents.
• T017 Keep client_secret blocked for Exchange PowerShell live invocation.
• T018 Add or confirm certificate credential handling for missing metadata, expired reference, inaccessible reference, wrong scope, unsupported reference, unvalidated reference, and supported-safe reference when explicitly enabled; unobservable states must collapse to tested safe blockers.
• T019 Add or confirm federated credential handling for missing, unsupported, wrong scope, inaccessible, unvalidated, and supported-safe states when repo/deployment support exists; unobservable states must collapse to tested safe blockers.
• T020 Add or confirm managed identity handling; if not first-class in ProviderCredentialKind, keep it explicitly blocked or add the enum only with proportionality and tests.
• T021 Ensure credential state context contains only safe metadata such as kind label, state, timestamps, IDs allowed by repo policy, and redaction markers.
• T022 Add unit tests for missing, client-secret, certificate expired, certificate unsupported, repo-observable certificate inaccessible/wrong-scope or their safe fail-closed equivalents, federated unsupported, managed identity unsupported, unknown kind, and supported-safe credential paths.
• T023 Add redaction tests proving no private key, certificate password, client secret, token, authorization header, raw vault secret, raw credential payload, or sensitive exception reaches OperationRun context, logs, or returned readiness envelopes.

Checkpoint: Credential evidence is explicit and cannot leak credential material.

Phase 4: Permission Evidence States

Purpose: Make Exchange.ManageAsApp evidence current, scoped, and auditable.

• T024 Extend or refactor ExchangePowerShellPermissionEvidenceEvaluator to use Exchange.ManageAsApp or repo-canonical equivalent as explicit permission evidence.
• T025 Preserve admin-consent-not-sufficient behavior.
• T026 Enforce workspace, managed environment, provider, and provider connection scope for permission evidence with no fallback-to-latest, fallback-to-first, or admin-consent-only pass behavior.
• T027 Enforce missing, unvalidated, stale, wrong workspace, wrong environment, wrong provider connection, unsupported provider, revoked/absent, and unknown blocker states.
• T028 Make permission currentness threshold configurable or explicitly justify and test the existing fixed 30-day threshold.
• T029 Add or prove source, observed, captured, verified, auditor/observer where applicable, and evaluator version metadata in first-class fields or safe details.
• T030 Add unit tests for missing, unvalidated, stale, wrong workspace, wrong environment, wrong provider connection, unsupported provider, admin-consent-only, verified current scoped evidence, and the current one-row-per-environment/permission-key no-migration behavior.
• T031 Add feature tests proving wrong-scope and stale permission evidence block before process execution and do not create evidence rows.

Checkpoint: Permission evidence is scoped, current, and separate from admin consent.

Phase 5: Combined Readiness

Purpose: Keep provider capability and runner gate aligned on one evidence truth.

• T032 Add ExchangePowerShellInvocationReadinessEvaluator or repo-canonical equivalent if existing paths cannot share one readiness result.
• T033 Ensure combined readiness requires both credential readiness and permission evidence readiness.
• T034 Ensure combined readiness returns safe ready_for_live_invocation or blocked states without raw credential, permission, provider, stdout, stderr, or exception payloads.
• T035 Add tests proving valid permission plus unsupported credential blocks.
• T036 Add tests proving supported credential plus missing/stale/wrong-scope permission blocks.
• T037 Add tests proving current scoped credential and permission evidence may pass readiness without creating Exchange configuration evidence or customer claims.

Checkpoint: Combined readiness is the single source consumed by later capability and runner tasks.

Phase 6: Provider Capability Integration

Purpose: Prevent exchange_powershell_invoke overclaiming support.

• T038 Update ProviderCapabilityEvaluator so exchange_powershell_invoke is Supported only when combined readiness passes.
• T039 Keep capability status values within existing ProviderCapabilityStatus unless a new status is explicitly justified by behavior, Product Surface impact, proportionality review, and tests.
• T040 Add tests proving admin consent alone does not produce Supported.
• T041 Add tests proving client-secret credentials do not produce Supported.
• T042 Add tests proving missing credential, unsupported credential, missing permission, stale permission, wrong-scope permission, unsupported provider, and unknown evidence do not produce Supported.
• T043 Add or update provider capability registry tests only if registry definitions change, and record the expected rendered impact on existing provider capability/readiness surfaces.

Checkpoint: Provider capability support matches credential and permission evidence truth.

Phase 7: Spec 432 Runner Gate Integration

Purpose: Make the production runner consume first-class readiness before any process execution.

• T044 Wire ExchangePowerShellProductionRunner or repo-canonical runner gate to combined readiness before runtime/process execution.
• T045 Preserve disabled default and explicit invocation + production-runner config gates from Spec 432.
• T046 Store only safe readiness/blocker state in OperationRun context.
• T047 Do not add a new OperationRun type unless implementation finds an unavoidable reason and updates spec/plan before continuing.
• T048 Add feature tests proving runner blocks before process execution when credential or permission readiness fails.
• T049 Add feature tests proving OperationRun context includes only safe state and no raw credential material, raw permission payload, raw provider payload, raw stdout/stderr, or sensitive exception detail.

Checkpoint: Runner gate consumes evidence readiness safely and remains no-promotion.

Phase 8: No-Promotion and Surface Guards

Purpose: Prove credential/permission evidence does not become Exchange configuration evidence or a new product surface, and that existing readiness surfaces stay canonical and redacted.

• T050 Add tests proving no TenantConfigurationResourceEvidence or repo-equivalent evidence rows are created.
• T051 Add tests proving no raw Exchange payload, normalized Exchange payload, content-backed state, comparable state, renderable state, certified state, restore-ready state, customer-ready state, report output, Review Pack output, or PDF output is introduced.
• T052 Add guard scans/tests proving no new route, Filament page, Livewire component, navigation item, asset, global search change, dashboard/readiness badge, customer route, credential management UI, or permission management UI is introduced.
• T053 Add guard scans/tests proving no job, schedule, listener, or console trigger can invoke Exchange PowerShell from this spec.
• T054 Add guard scans/tests proving no Exchange-specific credential table, Exchange-specific permission table, legacy shim, fallback reader, dual write, or tenant_id ownership path is introduced, and existing provider readiness/capability surfaces do not default-render raw credential, permission, provider, OperationRun, stdout/stderr, or scope-diagnostic payloads.

Checkpoint: No evidence, product claim, UI, trigger surface, or ownership drift exists.

Phase 9: Regression and Validation

Purpose: Prove Spec 433 did not regress the Exchange/Teams sequence or provider readiness behavior.

• T055 Run focused Spec 433 unit and feature tests.
• T056 Run Spec 432 production runner boundary regressions.
• T057 Run Spec 431 invocation gate/security regressions.
• T058 Run Spec 430 adapter contract regressions.
• T059 Run selected Spec 426 and Spec 427 no-promotion/source-contract regressions where available.
• T060 Run selected Spec 417 identity, Spec 419 registry, and Spec 420 generic evidence regressions where available.
• T061 Run provider capability registry/evaluator regressions.
• T062 If migration is added, run PostgreSQL/schema validation lane. N/A - no migration was added; Sail migration check reported nothing to migrate.
• T063 Run focused read-only browser proof for existing provider capability/readiness surfaces.
• T064 Complete Human Product Sanity for existing provider capability/readiness surfaces.
• T065 Run Pint for dirty/new files.
• T066 Run git diff --check.
• T067 Capture final git status --short.

Checkpoint: Focused tests, regressions, formatting, and diff checks are documented.

Phase 10: Implementation Report

Purpose: Close out the implementation with evidence, matrices, and residual risks.

• T068 Create specs/433-exchange-credential-permission-evidence-support/implementation-report.md.
• T069 Record candidate gate result, branch/HEAD, dirty state before/after, files changed, and activated skills/gates.
• T070 Record Spec 432 prerequisite proof and completed-spec read-only proof.
• T071 Record data-model decision, migration/no-migration proof, and proportionality review.
• T072 Record credential evidence model proof, credential kind matrix, repo-observable versus fail-closed state proof, wrong-scope proof where observable, and credential redaction proof.
• T073 Record permission evidence proof, Exchange.ManageAsApp proof, admin-consent-not-sufficient proof, currentness proof, metadata proof, wrong-scope proof, one-row-per-environment/permission-key decision, and no-fallback proof.
• T074 Record combined readiness proof, provider capability proof, runner gate integration proof, and expected existing surface impact.
• T075 Record OperationRun context safety, no evidence, no compare/render/certification, no restore/customer claim, no new UI/route/job/schedule/listener, no tenant_id, no raw details on existing provider readiness/capability surfaces, and no mini-platform proof.
• T076 Record Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, browser proof result, Human Product Sanity result, deployment impact, visible complexity outcome, no completed-spec rewrite assertion, tests run, deferred work, and follow-up candidates.
• T077 Include credential matrix, permission matrix, migration/no-migration matrix, product-surface/browser matrix, and no-promotion matrix.

Checkpoint: Implementation report is complete and reviewable.

Explicit Non-Goals During Implementation

• No Exchange provider calls.
• No PowerShell execution.
• No evidence persistence or promotion.
• No content-backed, comparable, renderable, certified, restore-ready, or customer-ready state.
• No new UI/routes/navigation/global search/assets; existing provider capability/readiness surfaces may only reflect changed evaluator output through existing canonical/redacted rendering.
• No jobs/schedules/listeners that invoke the runner.
• No customer reports, Review Pack output, or PDF output.
• No Teams, Exchange Admin API, broader Exchange target types, or customer claims.
• No Exchange-specific credential or permission table.
• No secret material columns.
• No tenant_id ownership truth.
• No Exchange mini-platform, legacy shim, fallback reader, or dual write.

Dependencies and Execution Order

• Phase 1 preflight blocks all implementation.
• Phase 2 data-model decision blocks migration or metadata changes.
• Credential and permission evidence phases block combined readiness.
• Combined readiness blocks provider capability and runner gate integration.
• No-promotion and surface guards must pass before validation and report close-out.
• Focused browser proof and Human Product Sanity must run after provider capability integration and before implementation report close-out.