ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
6fbb5c97ad
TenantAtlas/specs/424-security-defaults-content-backed-comparable-support/tasks.md
Ahmed Darrazi 6fbb5c97ad
Some checks failed
PR Fast Feedback / fast-feedback (pull_request) Failing after 5m4s
Details
chore: complete spec 424 implementation
2026-07-01 16:40:08 +02:00

15 KiB
Raw Blame History

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

Input: spec.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

  • 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.
  • New or changed tests stay in the smallest honest family; browser coverage is explicit only if rendered output changes.
  • Shared helpers, factories, seeds, fixtures, and context defaults stay cheap by default.
  • Planned validation commands cover the change without pulling unrelated lane cost.
  • Browser proof is explicitly N/A - no rendered UI surface changed if no rendered output changes, and required if rendered output changes.
  • Human Product Sanity and Product Surface implementation-report close-out are planned where applicable.

Phase 1: Preflight and Evidence Gate

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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

  • 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.
  • 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.
  • T009 [P] Add registry tests proving securityDefaults remains non-restorable, claim-limited/internal-only, not customer-facing, and not certified.
  • 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.
  • 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.
  • T012 Add feature tests proving provider connection and OperationRun scope mismatches fail before capture.
  • T013 [P] Add identity strategy tests proving Security Defaults uses canonical identity, never display-name-only stable identity, and blocks/limits unsafe identity states.
  • 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

  • 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.
  • 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.
  • T017 [P] Add compare importance tests proving enabled-state changes are critical and no broad risk-scoring framework is introduced.
  • 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.
  • 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.
  • T020 [P] Add Claim Guard tests allowing only scoped internal/operator Security Defaults content-backed/comparable/renderable wording.
  • 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

  • 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.
  • T023 Add feature tests proving readonly users cannot start capture and provider connections must belong to the same workspace/managed environment.
  • T024 Add no-remote-render tests proving compare/render/readiness performs no Graph, TCM, HTTP, provider, Microsoft docs, or network calls.
  • 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

  • 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.
  • T027 Add securityDefaults to CoverageSourceContractResolver explicit mappings only after the source-contract tests prove the contract is real and safe.
  • 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.
  • 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.
  • 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.
  • 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

  • T032 Add a bounded Security Defaults identity strategy in CoverageIdentityStrategyRegistry or repo-equivalent strategy path.
  • T033 Extend EntraComparablePayloadNormalizer or create the smallest sibling helper needed for securityDefaults; normalize enabled state and diagnostics deterministically.
  • T034 Extend EntraCoverageComparator or create the smallest sibling helper needed for Security Defaults compare behavior.
  • T035 Extend EntraRenderableSummaryBuilder or create the smallest sibling helper needed for operator-safe Security Defaults summaries.
  • 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

  • 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.
  • T038 Update ClaimGuard so scoped internal/operator Security Defaults content-backed/comparable/renderable claims are allowed and prohibited claims are blocked.
  • 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.
  • T040 Confirm no new action, route, navigation entry, dashboard, export, report, Review Pack, restore, certify, capture-start UI, or customer output was added.
  • T041 Confirm global search posture is unchanged because no Filament Resource is added or changed for global search.
  • T042 Confirm no new assets are registered and no new filament:assets deployment requirement is introduced.

Phase 8: Browser Proof If Rendered Output Changes

  • T043 Add focused browser smoke coverage only if rendered Coverage v2 output changes.
  • T044 In the browser smoke, seed a workspace, managed environment, provider connection, OperationRun, and Security Defaults content-backed evidence row.
  • 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.
  • T046 N/A because rendered Coverage v2 output changes; focused browser proof is recorded instead.
  • 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

  • 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.
  • T049 Run focused Claim Guard validation and record the result.
  • T050 Run any existing narrow Coverage v2 affected tests identified during implementation and record commands/results.
  • T051 Run formatter validation; Sail execution did not progress earlier, so local ./vendor/bin/pint --dirty --format agent fallback result is recorded.
  • T052 Run git diff --check.
  • 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.
  • 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.
  • 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.