TenantAtlas/specs/424-security-defaults-content-backed-comparable-support/tasks.md

# Tasks: Spec 424 - Security Defaults Content-Backed Comparable Support

**Input**: [spec.md](./spec.md), [plan.md](./plan.md), user-provided Spec 424 draft
**Prerequisites**: Completed read-only Specs 414, 415, 417, 418, 419, 420, 421, and 423; existing Coverage v2 registry/capture/read-model; existing Sail/Pest platform test workflow.

**Scope Reminder**: Implement support for `securityDefaults` only. Do not add certification, restore/apply, customer-facing output, Review Pack/report/export output, new dashboard, route, navigation, migration, table, live docs fetch, direct HTTP/Graph SDK bypass, or additional Entra resource types. The only allowed migration-file edit is the one-row fresh-install seed alignment for `securityDefaults` in `2026_06_26_000419_expand_tenant_configuration_workloads.php`.

## Test Governance Checklist

- [x] Lane assignment is named and is the narrowest sufficient proof for Security Defaults source, capture, identity, compare/render, redaction, claims, scope, and Product Surface behavior.
- [x] New or changed tests stay in the smallest honest family; browser coverage is explicit only if rendered output changes.
- [x] Shared helpers, factories, seeds, fixtures, and context defaults stay cheap by default.
- [x] Planned validation commands cover the change without pulling unrelated lane cost.
- [x] Browser proof is explicitly `N/A - no rendered UI surface changed` if no rendered output changes, and required if rendered output changes.
- [x] Human Product Sanity and Product Surface implementation-report close-out are planned where applicable.

## Phase 1: Preflight and Evidence Gate

- [x] T001 Record branch, HEAD, dirty state, activated skills, hard-gate status, and implementation start timestamp in `specs/424-security-defaults-content-backed-comparable-support/implementation-report.md`.
- [x] T002 Verify completed Specs 414, 415, 417, 418, 419, 420, 421, and 423 are read-only dependency context and record no completed-spec rewrites in `implementation-report.md`.
- [x] T003 Inspect current `securityDefaults` registry row and default-seeding sources in `apps/platform/app/Services/TenantConfiguration/ResourceTypeRegistry.php` and `apps/platform/database/migrations/2026_06_26_000419_expand_tenant_configuration_workloads.php`; record source class, support state, coverage level, evidence state, claim state, restore tier, metadata, and whether fresh-install seed alignment is needed.
- [x] T004 Inspect `apps/platform/app/Services/TenantConfiguration/CoverageSourceContractResolver.php`, `apps/platform/config/graph_contracts.php`, `apps/platform/app/Services/TenantConfiguration/CoverageIdentityStrategyRegistry.php`, and `apps/platform/app/Services/TenantConfiguration/SupportedScopeResolver.php` to confirm current contract, identity, and supported-scope gaps.
- [x] T005 Inspect `apps/platform/app/Services/TenantConfiguration/GenericContentEvidenceCaptureService.php` and fake Graph response patterns to determine whether Security Defaults singleton payloads can be captured through the existing path.
- [x] T006 Stop and amend `spec.md`/`plan.md` before runtime implementation if support requires a schema migration, a migration-seed edit beyond the one-row `securityDefaults` alignment in `2026_06_26_000419_expand_tenant_configuration_workloads.php`, new table, new capture start action, new route/navigation/dashboard, restore/apply, certification, customer output, direct HTTP, live docs fetch, or a broad singleton framework.

## Phase 2: Tests First - Source Contract, Capture, and Identity

- [x] T007 [P] Add source-contract resolver tests proving `securityDefaults` blocks as `capture_blocked_missing_contract` before mapping and resolves only through an explicit approved contract after mapping.
- [x] T008 [P] Add graph contract tests proving the Security Defaults contract has a stable resource path, v1/default source version, safe select/volatile-field behavior, and no beta/certification default.
- [x] T009 [P] Add registry tests proving `securityDefaults` remains non-restorable, claim-limited/internal-only, not customer-facing, and not certified.
- [x] T010 [P] Add capture eligibility tests proving missing contract, missing permission, unsupported source, and beta-disabled source do not create fake evidence or promote coverage.
- [x] T011 Add feature tests proving a successful fake provider response persists one Security Defaults resource/evidence row with raw payload, normalized payload, payload hash, source metadata, redacted permission context, `operation_run_id`, `workspace_id`, `managed_environment_id`, and same-scope `provider_connection_id`.
- [x] T012 Add feature tests proving provider connection and OperationRun scope mismatches fail before capture.
- [x] T013 [P] Add identity strategy tests proving Security Defaults uses canonical identity, never display-name-only stable identity, and blocks/limits unsafe identity states.
- [x] T014 [P] Add supported-scope tests proving any Security Defaults scope is internal/operator-only and forbidden scope names such as `entra_certified`, `entra_full_coverage`, `entra_restore_ready`, or `m365_certified` are absent.

## Phase 3: Tests First - Typed Semantics and Safety

- [x] T015 [P] Add Security Defaults typed normalizer tests covering `enabled: true`, `enabled: false`, `enabled: null`, source identity, source class, source version/schema metadata, unsupported fields, and volatile-field dropping.
- [x] T016 [P] Add deterministic compare tests covering false-to-true, true-to-false, null-to-known, added, removed, unchanged, volatile-only ignored, redacted, and unsupported-field cases.
- [x] T017 [P] Add compare importance tests proving enabled-state changes are `critical` and no broad risk-scoring framework is introduced.
- [x] T018 [P] Add render summary tests proving default-visible output shows Security Defaults enabled/disabled/unknown, evidence state, identity state, claim state, last captured, and blockers.
- [x] T019 [P] Add redaction tests proving raw payload, normalized JSON, permission context, raw Graph response, tokens, credentials, authorization headers, cookies, private keys, certificates, and unsafe OperationRun/audit metadata do not appear in summaries.
- [x] T020 [P] Add Claim Guard tests allowing only scoped internal/operator Security Defaults content-backed/comparable/renderable wording.
- [x] T021 [P] Add Claim Guard tests blocking certified, restore-ready, customer-ready, full Entra, 100 percent Entra, M365 certified, legal/regulatory, Review Pack/report/export, and restore/apply claims.

## Phase 4: Tests First - RBAC, Product Surface, and No Mini-Platform

- [x] T022 Add feature tests proving wrong-workspace/non-member access is deny-as-not-found and member missing view capability is 403 for Security Defaults evidence/render access.
- [x] T023 Add feature tests proving readonly users cannot start capture and provider connections must belong to the same workspace/managed environment.
- [x] T024 Add no-remote-render tests proving compare/render/readiness performs no Graph, TCM, HTTP, provider, Microsoft docs, or network calls.
- [x] T025 Add no-tenant-id/no-mini-platform guard tests proving no `tenant_id` ownership, no new Entra/Security Defaults table family, no route/navigation/dashboard, no restore action, no customer output, and no report/export path.

## Phase 5: Implement Source Contract and Capture Closure

- [x] T026 Add the minimal approved Security Defaults contract to `apps/platform/config/graph_contracts.php` only if the contract can be represented safely by existing graph contract conventions.
- [x] T027 Add `securityDefaults` to `CoverageSourceContractResolver` explicit mappings only after the source-contract tests prove the contract is real and safe.
- [x] T028 Update `ResourceTypeRegistry` defaults for `securityDefaults` only as far as real capture support justifies; keep `not_restorable`, no certification, no customer claims, and conservative claim state. Align the existing fresh-install seed row in `2026_06_26_000419_expand_tenant_configuration_workloads.php` only after source support is proven; stop and amend `spec.md`/`plan.md` before editing any other existing migration seed or adding a migration.
- [x] T029 Update `SupportedScopeResolver` only if implementation needs an explicit internal/operator comparable scope; do not add certified, restore-ready, customer-ready, full Entra, or broad M365 scope names.
- [x] T030 If singleton response handling needs code, add the smallest bounded change inside existing Coverage v2 source/capture machinery; do not introduce a broad singleton framework.
- [x] T031 Ensure missing contract or failed capture still creates no raw payload, no normalized payload, no content-backed evidence, and no comparable/renderable promotion.

## Phase 6: Implement Identity, Normalization, Compare, and Render

- [x] T032 Add a bounded Security Defaults identity strategy in `CoverageIdentityStrategyRegistry` or repo-equivalent strategy path.
- [x] T033 Extend `EntraComparablePayloadNormalizer` or create the smallest sibling helper needed for `securityDefaults`; normalize enabled state and diagnostics deterministically.
- [x] T034 Extend `EntraCoverageComparator` or create the smallest sibling helper needed for Security Defaults compare behavior.
- [x] T035 Extend `EntraRenderableSummaryBuilder` or create the smallest sibling helper needed for operator-safe Security Defaults summaries.
- [x] T036 Reuse `CoveragePayloadRedactor`; extend it only if focused tests prove Security Defaults-sensitive values are not already covered.

## Phase 7: Integrate Read Model, Claim Guard, and Product Surface

- [x] T037 Wire Security Defaults typed support into `CoverageV2ReadinessReadModel` or existing dispatch path without adding a generic registry/framework unless implementation evidence proves existing dispatch cannot remain bounded.
- [x] T038 Update `ClaimGuard` so scoped internal/operator Security Defaults content-backed/comparable/renderable claims are allowed and prohibited claims are blocked.
- [x] T039 If rendered output changes through existing read-model data, update only the Coverage v2 read model/dispatch path needed to show Security Defaults summary with native/shared Filament semantics; stop and amend `spec.md`/`plan.md`/`tasks.md` before editing Blade, Livewire, Filament Resource/Page/Widget, route, navigation, action, or other runtime UI files.
- [x] T040 Confirm no new action, route, navigation entry, dashboard, export, report, Review Pack, restore, certify, capture-start UI, or customer output was added.
- [x] T041 Confirm global search posture is unchanged because no Filament Resource is added or changed for global search.
- [x] T042 Confirm no new assets are registered and no new `filament:assets` deployment requirement is introduced.

## Phase 8: Browser Proof If Rendered Output Changes

- [x] T043 Add focused browser smoke coverage only if rendered Coverage v2 output changes.
- [x] T044 In the browser smoke, seed a workspace, managed environment, provider connection, OperationRun, and Security Defaults content-backed evidence row.
- [x] T045 Load the existing Coverage v2 readiness route, inspect Security Defaults, and assert enabled/disabled/unknown summary, comparable/renderable state, no raw payload, no secrets, no restore/certified/customer-ready claim, no new high-impact action, and no console/Livewire/Filament errors.
- [x] T046 N/A because rendered Coverage v2 output changes; focused browser proof is recorded instead.
- [x] T047 Record Human Product Sanity if rendered output changes, confirming the page is clearer or neutral and does not overclaim.

## Phase 9: Validation and Close-Out

- [x] T048 Run focused Spec 424 validation and record the result in `implementation-report.md`; Sail execution was attempted but did not progress, so local `php artisan test` fallback results are recorded.
- [x] T049 Run focused Claim Guard validation and record the result.
- [x] T050 Run any existing narrow Coverage v2 affected tests identified during implementation and record commands/results.
- [x] T051 Run formatter validation; Sail execution did not progress earlier, so local `./vendor/bin/pint --dirty --format agent` fallback result is recorded.
- [x] T052 Run `git diff --check`.
- [x] T053 Confirm no schema migration, migration-seed edit beyond the allowed one-row `securityDefaults` fresh-install seed alignment, env var, queue, scheduler, storage, or asset deployment step was introduced; record the default-seeding alignment decision. If any other migration impact was introduced, amend `plan.md` before close-out.
- [x] T054 Complete `specs/424-security-defaults-content-backed-comparable-support/implementation-report.md` with source contract result, capture/evidence matrix, identity strategy, supported-scope posture, normalizer/compare/render matrices, Claim Guard proof, redaction proof, no restore/certification/customer proof, no `tenant_id`, no mini-platform, Product Surface result, tests/browser/no-browser, deployment impact, Livewire v4 compliance, provider registration location, global search posture, destructive/high-impact action posture, asset strategy, and deferred work.
- [x] T055 Confirm no completed historical spec was rewritten, normalized, reopened, or stripped of validation/task/browser/review history.

## Dependencies and Ordering

- T001-T006 block runtime implementation.
- T007-T025 should be written before or alongside implementation.
- T026-T031 depend on source/capture tests.
- T032-T036 depend on typed semantic tests.
- T037-T042 depend on helper behavior and Claim Guard tests.
- T043-T047 depend on whether rendered output changes.
- T048-T055 close out after implementation and validation.

## Parallel Work Opportunities

- T007-T014 can be split by contract/capture/identity/supported scope.
- T015-T021 can be split by normalizer/compare/render/claim/redaction.
- T022-T025 can run in parallel with service helper implementation.
- T033-T036 can proceed in parallel after the normalizer contract is clear, but one reviewer should keep Claim Guard wording aligned.

## Implementation Guardrails

- Keep fake payload fixtures minimal and local to Spec 424 tests.
- Use existing service/test naming conventions from sibling TenantConfiguration code.
- Prefer direct concrete helper extensions over a new registry, factory, interface, or orchestration pipeline.
- Do not introduce persisted states, enums, tables, migrations, routes, navigation entries, dashboards, actions, assets, or customer outputs without stopping to amend the spec/plan.
- Treat existing migration seed data as fresh-install alignment evidence, not as an edit target unless the plan has been amended first.
- Do not rewrite completed specs to retrofit close-out wording.
- Do not use live Microsoft Graph, TCM, Microsoft docs, or HTTP calls in tests or runtime render/compare paths.

## Completion Definition

- Spec, plan, tasks, checklist, implementation report, and implementation agree on Security Defaults support or blocked status.
- Source contract, capture, evidence, identity, normalization, compare, render, redaction, Claim Guard, RBAC, no-remote, no-tenant-id, and no-mini-platform proof exist.
- Product Surface proof or exact N/A proof is recorded.
- Deployment impact is assessed as none or amended before merge.